3 Replies Latest reply on Jan 13, 2010 5:30 AM by wolfc

    JavaEE namespace deployers

    wolfc

      To enable the new Application Component Environment Namespaces I've created a component in Reloaded: jboss-reloaded-naming. [1]

       

      With JBNAME-37 [2] the setting up of java:comp itself can be disabled in the naming server itself. AS then needs to delegate this to org.jboss.reloaded.naming.service.NameSpaces. [3]
      NameSpaces will set up the four namespaces defined in the JavaEE 6 spec. java:global will be a simple LinkRef to the root. java:app, java:module and java:comp will be ObjectFactories return the scoped context based on the current component. [4]

       

      For a JavaEE container to be obtain a JavaEEComponent a couple of deployers need to be created.
      An AppDeployer which will setup java:global/<app-name> and store that Context into a JavaEEApplication. This will be attached to the deployment unit.
      A ModuleDeployer which creates java:app/<module-name> and again attach it to the deployment unit.
      A ComponentDeployer which in case of a Web Archive will create a LinkRef to java:module, otherwise it will create a new context. Either LinkRef or Context will be bound under java:module/<component-name>.

       

      (Note to self: the <module-name> includes the path structure within the EAR.)

       

      After this we can think about setting up a complete JSR-250 injection environment into java:comp via a standalone deployer.

       

      1. https://jira.jboss.org/jira/browse/RELOADED-9
      2. https://jira.jboss.org/jira/browse/JBNAME-37
      3. http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/reloaded/trunk/naming/src/main/java/org/jboss/reloaded/naming/service/NameSpaces.java?view=markup
      4. http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/reloaded/trunk/naming/src/main/java/org/jboss/reloaded/naming/CurrentComponent.java?view=markup

        • 1. Re: JavaEE namespace deployers
          starksm64

          The JNDIView bean needs a massive overhaul to properly display all of the namespaces.  I would like to completely move away from class loader based component namespaces. I believe an spi is needed in the naming project that the ENCFactory implements to provide read-only access to all current components for use by admin views like JNDIView. At least this issue is related:

           

          https://jira.jboss.org/jira/browse/JBAS-6001

           

          I created https://jira.jboss.org/jira/browse/JBNAME-44 to introduce the spi into naming.

          • 2. Re: JavaEE namespace deployers
            starksm64

            Never mind about JBNAME-44, the legacy ENCFactory is only used for backwards compatibility. A complete view would only be seen from the org.jboss.reloaded.naming classes, so I'll look at introducing a JNDIView class there. I'm not sure if its worth introducing an spi notion at this point.

            • 3. Re: JavaEE namespace deployers
              wolfc

              jboss-reloaded-naming does not define a contract for JavaEE* object creation, so it's effectively unaware of what's flying around. The SimpleJavaEE* classes are just simple prebuilds and aren't even used in the current integration point (jboss-reloaded-naming-deployers).

               

              We could add a registry (JNDIView) into naming and mandate a registration, but I would see that as a bit of scope creep. I think it should rather go into naming-deployers which is in charge of firing up the runtime components and can effectively wire up a registry as well.