Shortest Enterprise Java WTF

Okay, we're talking about a JSF2 application here, Java code. Aside from the "private" keywork, can anyone top this as the shortest WTF moment?

private static HttpSession httpSession;

PJH

Care to explain what the WTF is/are for the ignorant among us who don't do Java?

locallunatic

It's been a long time since I've used java, but static means it belongs to the class in general not to each instance. With it being something like HttpSession that probably means a webpage, thus one that only (properly) supports a single connection.

error

@locallunatic said:

It's been a long time since I've used java, but static means it belongs to the class in general not to each instance. With it being something like HttpSession that probably means a webpage, thus one that only (properly) supports a single connection.

True story. I had diagnose and fix exactly this problem in a web app once. It worked fine in dev (single user), but very strange things started to happen when we started testing with multiple users!

locallunatic

@joe.edwards said:

True story. I had diagnose and fix exactly this problem in a web app once.

Well if it is actually an application that is pulling data down from a web app then it could have a reason to only have a single session, I'm assuming that isn't what the code sample was but in theory it could be. I mean in theory your webapp that is pulling data from another one could only need a single connection, but the amount of stretching to build that shows a bigger WTF in the general architecture of the product.

@PJH said:

Care to explain what the WTF is/are for the ignorant among us who don't do Java?

Wouldn't say "ignorant", more likely "lucky".

This is a multiuser JSF2 application, not sure I know too many that are single user, although I guess it's possible.

The line is a static (class) member that attempts to store the session object for the current request. If you have more than one user, you'll have more than one session and any use of such a class member will cause race conditions.

Also, although session state is stored between requests, the session objects are normally reconstructed by the application server upon receiving a new request, state being reinjected into them. So saving and later attempting to use a session object risks having two objects around that each purport to be the real session. If you store attributes in one, they won't show up in the other.

BTW, when this was pointed out, a ThreadLocal appeared. Reminds me of the old quote about regexs! And this is in place to attempt to pass information through to an EJB.

Woe is me

nonpartisan

@UpNDown said:

Aside from the "private" keywork, can anyone top this as the shortest WTF moment?

inb4 "Using Java at all."

pjt33

@UpNDown said:

The line is a static (class) member that attempts to store the session object for the current request. If you have more than one user, you'll have more than one session and any use of such a class member will cause race conditions.

I'm mildly surprised that app servers aren't required to isolate requests from each other by using a classloader per request.

error

@UpNDown said:

the "private" keywork

C&CTFY

error

@joe.edwards said:

@UpNDown said:
the "private" keywork

C&CTFY

And the link disappeared. CS is TRWTF as always.

dkf

@pjt33 said:

I'm mildly surprised that app servers aren't required to isolate requests from each other by using a classloader per request.

Don't be; the overhead of doing that is very hard to keep at a sane level and Java implementations have at least in the past had immense problems with garbage collection of class loaders. Maybe things are better now, but most app server authors tend to be pretty conservative in what they assume the deployment environment can do (and with good reason; the target environment is all too often ancient due to ops being against updating things if they can get away without doing it).