4 Replies Latest reply on Mar 9, 2010 11:56 PM by Brian Stansberry

    EE Module Names (JBAS-7644)

    Brian Stansberry Master

      I've been working on https://jira.jboss.org/jira/browse/JBAS-7644 and related work dealing with EE.8.1.1's and EE.8.1.2's requirements for how EE 6 modules should be named.


      The gist of the issue is the deployment descriptors for the different EE 6 component types allow configuration of a "module name".  EE.8.1.1 and EE.8.1.2 spell out rules for defaults if the module name isn't specified, and add a requirement that during deployment we ensure that the names for all modules w/in an ear are unique.


      The approach I'm taking to this is:


      • Create a new interface in jboss-metadata-common: org.jboss.metadata.javaee.jboss.NamedModule. This basically includes a getter and setter for String property "moduleName".
      • The various jboss-specific metadata classes for the EE 6 component types will implement NamedModule:
        • JBossMetaData
        • JBossWebMetaData
        • JBossClientMetaData
        • some JCA-related metadata class; need to touch base with Jesper on which.
        • logically this could be expanded to metadata types for non-EE stuff that can be packaged in an EAR, e.g. ServiceMetaData, HibernateMetaData. At this point I don't plan to do this, as there's no requirement and I don't know of a use case.
      • To org.jboss.metadata.ear.spec.ModuleMetaData, add a new read/write property "uniqueName".
      • Create a new ModuleNameDeployer that:
        • takes as inputs the above metadata classes
        • provides as outputs the above classes, plus JBossAppMetaData
        • when asked to process a DeploymentUnit, finds the relevant attached component metadata object, then checks whether the parent has a JBossAppMetaData attached
          • if no, checks if the component metadata object's getModuleName() returns null; if so creates a module name following the EE.8.1.2 rules and sets it
          • if yes, checks if the component metadata object's getModuleName() returns null; if so creates a module name following the EE.8.1.2 rules. Then cycles through the JBossAppMetaData's associated ModuleMetaData objects, calling getUniqueName() on each, looking for duplicates. If a duplicate is found, creates a new module name, looping until it finds one that is unique. Once one is found, sets it on the component metadata object and as the unique name property on the ModuleMetaData.


      It's all seems pretty straightforward; biggest hassle is it touches a bunch of different metadata projects, so actually getting it into the AS will take some coordination.


      The thing I'm going to explore now is how EJBs packaged in wars will work.




      ComponentNamingDeployer and ModuleNamingDeployer are calling JavaEEModuleInformer.getModulePath() to get a module name. I think this should be changed:


      1. JavaEEModuleInformer should add a new getModuleName() method.
      2. Implementations should implement this by calling the above referenced NamedModule.getModuleName() on the relevant metadata object.
        • 1. Re: EE Module Names (JBAS-7644)
          Carlo de Wolf Master

          I actually want the naming deployers to consume this new piece of metadata instead of fiddling other bits via informers.

          ... the name of the module is the pathname of the module in the ear file with any filename extension (.jar, .war,.rar) removed, but with any directory names included.

          We probably have pieces of code lying around everywhere that assume a (VFS) path can be hacked up for module name.

          Do you have a patch I can apply locally? (git repo? :-) )

          • 2. Re: EE Module Names (JBAS-7644)
            Brian Stansberry Master

            If the informers aren't doing anything for you besides this, then yeah, get rid of them.


            Hmm, one thing they do is deal with allowing a general purpose deployer like your naming deployers to find the relevant metadata attachment. You can't just do deploymentUnit.getAttachment(NamedModule.class) as the actual attachment is bound under key JBossWebMetaData.class, JBossMetaData.class etc. So, sounds like I should have my deployer add a second attachment of the same metadata object, this time under key NamedModule.class.


            Let me experiment a bit more today to make sure what I've done actually works beyond compiling. Then I'll figure how to get you a patch.

            • 3. Re: EE Module Names (JBAS-7644)
              Brian Stansberry Master

              The attached patch lets me deploy the AS testsuite's security-jaas.ear, which has a bunch of modules with the same name. So, I need to write unit tests and make sure that my guess as to what should happen if a DeploymentUnit has both JBossWebMetaData and JBossMetaData is correct and works. But the attached is enough to play with if you're up for it.


              It covers a bunch of different projects -- basically I opened the AS codebase in Eclipse and then added in the metadata projects.


              My guess as to what should happen if a DeploymentUnit has both JBossWebMetaData and JBossMetaData is that the same module name should be applied to both.

              • 4. Re: EE Module Names (JBAS-7644)
                Brian Stansberry Master



                This is checked in to AS trunk. I created https://jira.jboss.org/jira/browse/JBAS-7798 (assigned to you) for the work of converting the naming deployers to use the NamedModule metadata. I temporarily hacked NamingJavaEEModuleInformer.