1 2 Previous Next 19 Replies Latest reply on Dec 21, 2006 5:13 PM by Bill Burke

    java:comp.ejb3 versus java:comp

    Carlo de Wolf Master

      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.

        • 1. Re: java:comp.ejb3 versus java:comp
          Scott Stark Master

          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.

          • 2. Re: java:comp.ejb3 versus java:comp
            Bill Burke Master

            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.

            • 3. Re: java:comp.ejb3 versus java:comp
              Scott Stark Master

              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.

              • 4. Re: java:comp.ejb3 versus java:comp
                Bill Burke Master

                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.

                • 5. Re: java:comp.ejb3 versus java:comp
                  Bill Burke Master

                  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)

                  • 6. Re: java:comp.ejb3 versus java:comp
                    Scott Stark Master

                    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.

                    • 7. Re: java:comp.ejb3 versus java:comp
                      Bill Burke Master

                       

                      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

                      • 8. Re: java:comp.ejb3 versus java:comp
                        Bill Burke Master

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

                        • 9. Re: java:comp.ejb3 versus java:comp
                          Scott Stark Master

                          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.

                          • 10. Re: java:comp.ejb3 versus java:comp
                            Bill Burke Master

                            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?

                            • 11. Re: java:comp.ejb3 versus java:comp
                              Scott Stark Master

                              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.

                              • 12. Re: java:comp.ejb3 versus java:comp
                                Bill Burke Master

                                "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.

                                • 13. Re: java:comp.ejb3 versus java:comp
                                  Scott Stark Master

                                  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.

                                  • 14. Re: java:comp.ejb3 versus java:comp
                                    Carlo de Wolf Master

                                    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.

                                    1 2 Previous Next