long time no see, but JBoss forum addicted never become clean ;-)
I'd like to dicuss the behavior of the SFSB handle used in JBoss 3.2.7 (and later, I think) compared to JBoss 4.x .
We are migrating a large enterprise application from JBoss 3.2.7 and JDK 1.4 to JBoss 4 (JBoss 4.0.2 for now) and JDK 5.
JNDI lookup with our clients is not configured by using the default system properties. They are creating instances of InitialContext using a hashtable providing all relevant properties. We are using JRMP invocation.
It comes up, that the client stores a bean handle of a SFSB. Later on, another thread picks up this handle and calls getEJBObject(). The executing thread didn't ever do a JNDI lookup by himself for now, but wants to work with the existing session (to tell the truth, this is not what we are doing, but we are encountering the same problem within a more complex situation).
With JBoss 3.2.7, the bean handle is instanciated with the JRMPInvoker, which holds the invoker stub and finally the endpoint with the configured host (I think this information came out of the proxy which acts as bean stub). The invocation on getEJBObject() is done on this invoker and everything works like a charm ;-)
Using JBoss 4.x the implementation of StatefulHandleImpl changed. The handle is still instanciated with the invoker, but the invoker is stored only with the system property "org.jboss.ejb.sfsb.handle.V327" set. Unfortunately, the stored invoker is never used afterwards.
Instead, the handle is trying to lookup the InvocationHandler. This lookup is done using the NamingContextFactory.lastInitialContextEnv (which is stored in a ThreadLocal) or, if this context couldn't be obtained, using a new InitialContext. And this leads to a Exception, because the thread never did a lookup before (therefor no lastInitialContext) and the system properties are not set at all.
I patched the StatefulHandleImpl like this: if the property "org.jboss.ejb.sfsb.handle.V327" is set, the getEJBObject is implemented as in JBoss 3.2.7, if not, the lookup for the InvocationHandler is done like before. This patch works for me.
I'd file this as a bug in JIRA, but before doing this, I'd like to hear some other opinions.
Adrian and Scott discussed a part of my problem here: http://jira.jboss.com/jira/browse/JBAS-1479, but I think the solution provided there fixes the test suite, but not real life problems like the one above. Or did I miss anything?