java:comp.ejb3 versus java:comp

[wolfc]

Specs require us to have java:comp as our enc name. But currently EJB3 binds all entries under java:comp.ejb3. How are we going to fix this?

In org.jboss.naming.NamingService org.jboss.naming.ENCFactory is bound under java:comp. This is a per classloader enc ObjectFactory.
In org.jboss.ejb3.EJB3Deployer org.jboss.ejb3.ThreadLocalENCFactory is bound under java:comp.ejb3. This is a per thread enc ObjectFactory.

I was thinking about creating a new ObjectFactory which delegates to either one of them and binding it in the EJB3Deployer, but that's probably nasty.

[starksm64]

The class loader based ENCFactory really should be dropped for a thread or invocation context keyed implementation. The main issue in switching is getting all of the component calls paths tied into the correct lookup mechanism. We also need a jndi Context wrapper that allows the enc context to be read-only.

This should be a common ENCMap bean that provides the various enc Contexts keyed by a unique component deployment id. The id key is what needs to be made available for the java:comp ObjectFactory via thread local or invocation context key.

[bill.burke]

what else has an ENC besides a WAR and an EJB?

EJB3 creates its own ENC and pushes/pops it onto a ThreadLocalStack that the ObjectFactory uses. Why can't a WAR do the same exact thing? Does JBossWeb control ENC creation or does Tomcat specific libraries? If JBossWeb, then it should be easy to add something to push/pop a JBossWeb created ENC and share the ObjectFactory implementation EJB3 uses.

[starksm64]

In terms of an aspect, why shouldn't pojos, mbeans, etc.?

The issue is that even with ejbs, wars, there are background container initiated invocations that today should have a class loader that ties to the old enc map, now need to have access to the key that identifies their enc. Not every container is going to be rewritten to use the aop invocation model.

[bill.burke]

Why do you even need to have an ID or an interceptor or even an invocation context? Just let the freakin container push/pop an instance of the ENC onto the ThreadLocal that the java:comp ObjectFactory uses. The current EJB3 ObjectFactory implementation knows nothing about AOP, just the ThreadLocal it uses to obtain the ENC.

[bill.burke]

org.jboss.ejb3.ThreadLocalENCFactory
org.jboss.ejb3.ThreadLocalStack

(ThreadLocalStack is in ejb3 module rather than common because I did not want to have to patch common.jar in older JBoss 4.x versions)

[starksm64]

This assumes that every callback path has an interceptor model that allows this. Its not true for either the ejb2 or web containers. Callbacks like ejb timers, activation callbacks, session events, don't have the same invocation model as requests.

There is also the issue of being able to view encs for debugging. Having a bunch of isolated encs buried in various containers vs having a map keyed by component id just seems cleaner.

[bill.burke]

This assumes that every callback path has an interceptor model that allows this. Its not true for either the ejb2 or web containers. Callbacks like ejb timers, activation callbacks, session events, don't have the same invocation model as requests.

Well, the key has to be set someplace and somewhere if your'e not using the ClassLoader as the key. EJB3 has no problem pushing/popping the ENC for EJB callbacks. Not sure why EJB2 or JBossWeb would have any problem as well.

There is also the issue of being able to view encs for debugging. Having a bunch of isolated encs buried in various containers vs having a map keyed by component id just seems cleaner.

Ok...so can we get implementing this? There should be no reason why we need to overengineer this and can have a simple static variable ConncurrentHashMap implementation for the id->ENC mapping.

I can probably figure out all the places to add the hooks in for EJB3/EJB2. For JBossWeb I made need a hint.

Bill

[bill.burke]

Do you know of a basic subset of unit tests I can run to test ENC changes for EJB2 and WAR?

[starksm64]

All the containers already have context maps that could be leveraged to pickup an enc key from. I just don't want to force an implementation detail like a thread local accessor onto all enc users.

The main enc tests are the org.jboss.test.naming.test.ENCUnitTestCase and in the web tier, org.jboss.test.web.test.EncAnnotationsUnitTestCase,EncXmlUnitTestCase,WebIntegrationUnitTestCase. The WebIntegrationUnitTestCase is too bloated with other tests and the testENCServlet, testENCServletViaInvoker tests should just be integrated into the other tests.

[bill.burke]

so as not to introduce JBoss dependencies, I could keep WARs classloader based and have EJB 2.1 and EJB 3 use a key. The only way this couldn't work is if an EJB invoked on a Servlet in the same thread. Is that even possible?

[starksm64]

Sure, especially with the asynch calls now supported. But the thread identity is not important between containers as each container has to establish the component encs since each component has its own enc. We have more flexibility in configuring how the web container behaves with jbossweb, so let's see what comes about with the ejb containers and how this could be used in jbossweb.

[bill.burke]

"Sure" as in, make it so? Keep WARs classloader based, but change EJB 2/3 to be Thread ID based? This would unblock any TCK work.

I was worried about collocated web service refs. Jason tells me currently service ref invocations always loopback over the wire, but in the future may be locally optimized.

[starksm64]

yes, get it consistent on the ejb containers and we can look at the web container later. Optimized web service calls should still go through the web container and pickup the component enc. The web component container is already decoupled from the transport layer so I don't see webservices adding any new wrinkle.

[wolfc]

I've committed a multiplexer so that java:comp now looks into both enc factories. This allows progress on TCK to continue.

Note that java:comp is a global thing and I don't see how it ('s ObjectFactory) can differentiate between a call coming from web, ejb2 or ejb3.