14 Replies Latest reply on Apr 17, 2008 5:32 AM by Alexey Loubyansky

    jee module's alt-dd

    Alexey Loubyansky Master

      I see that it has been mentioned here for the WAR modules http://www.jboss.com/index.html?module=bb&op=viewtopic&t=131976

      but that affects other modules too, e.g. EJB.

      To mee it looks like the filename should either be passed as a parameter to deploy() or be available from the DeploymentUnit. Any other ideas?

      I am looking into an EJB issue that is a consequence of this. I could dig into it further or if someone else was planning to work on this I'll jump on something else. Please let me know. Thanks.

        • 1. Re: jee module's alt-dd
          Scott Stark Master

          The only issue is how to generically integrate the alt-dd path. Most ee descriptor has an alt-dd child of the root element, so one way to handle this would be to extend AbstractParsingDeployerWithOutput to have an alt-dd property that specifies element name of the alt-dd, and createMetaData(DeploymentUnit unit, String name, String suffix, String key) would do a simple jaxp query of the document to see if alt-dd path name exists. It would have to be encapsulated in another abstract method like:

           protected abstract String getAltName(DeploymentUnit unit, String name) throws Exception;
          


          as we don't know how to obtain the input stream for the name at the AbstractParsingDeployerWithOutput level. The jaxp default impl would have to be added to AbstractVFSParsingDeployer.

          http://jira.jboss.com/jira/browse/JBDEPLOY-27


          • 2. Re: jee module's alt-dd
            Alexey Loubyansky Master

             

            "scott.stark@jboss.org" wrote:
            Most ee descriptor has an alt-dd child of the root element, so one way to handle this would be to extend AbstractParsingDeployerWithOutput to have an alt-dd property that specifies element name of the alt-dd


            I guess, I misunderstand this. AFAICS, the alt-dd is specified in the application.xml per module. Like this
            <application version="1.4"
             xmlns="http://java.sun.com/xml/ns/j2ee"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
             http://java.sun.com/xml/ns/j2ee/application_1_4.xsd">
             <module>
             <ejb>ejb.jar</ejb>
             <alt-dd>altDD_ejb.xml</alt-dd>
             </module>
             <module>
             <java>client.jar</java>
             <alt-dd>altDD_client.xml</alt-dd>
             </module>
            </application>


            The ModuleMetaData has a property for alt-dd but it's not used except in the web deployer.

            • 3. Re: jee module's alt-dd
              Adrian Brock Master

               

              "scott.stark@jboss.org" wrote:
              The only issue is how to generically integrate the alt-dd path. Most ee descriptor has an alt-dd child of the root element, so one way to handle this would be to extend AbstractParsingDeployerWithOutput to have an alt-dd property that specifies element name of the alt-dd, and createMetaData(DeploymentUnit unit, String name, String suffix, String key) would do a simple jaxp query of the document to see if alt-dd path name exists. It would have to be encapsulated in another abstract method like:

               protected abstract String getAltName(DeploymentUnit unit, String name) throws Exception;
              


              as we don't know how to obtain the input stream for the name at the AbstractParsingDeployerWithOutput level. The jaxp default impl would have to be added to AbstractVFSParsingDeployer.

              http://jira.jboss.com/jira/browse/JBDEPLOY-27


              Why don't you make an interface, e.g.
              public interface AltDD
              {
               String getAltDD();
              }
              


              Then the metadata classes could implement it and parsing deployers check it
              regardless of where it appears.

              On Alex's point, these just need to be added as attachments by the EarStructure
              and checked by the relevant parsing deployer.

              In principle it should be possible to do the same thing programmatically
              even for non-ears.
              VFSDeployment d = new VFSDeployment(ejbjar);
              d.addAttachment("EJBAltDD", "al.ternatelocation");
              


              • 4. Re: jee module's alt-dd
                Scott Stark Master

                 

                "alex.loubyansky@jboss.com" wrote:

                I guess, I misunderstand this. AFAICS, the alt-dd is specified in the application.xml per module. Like this

                ...

                The ModuleMetaData has a property for alt-dd but it's not used except in the web deployer.

                Sure, your right, I was thinking it could also show up at the descriptor level. That would be silly.

                "adrian@jboss.org" wrote:

                Then the metadata classes could implement it and parsing deployers check it
                regardless of where it appears.

                ...

                On Alex's point, these just need to be added as attachments by the EarStructure
                and checked by the relevant parsing deployer.

                Good point, the EarStructure is where this should be done. The AltDD interface would need to be in the deployer project so that the general handling of the alt path can be handled in AbstractVFSParsingDeployer.

                If were using the AltDD interface as the typed path/key, wouldn't the programtic usage be:
                addAttachment(Class<T> type, T attachment);
                VFSDeployment d = new VFSDeployment(ejbjar);
                AltDD altDD = ...("al.ternatelocation");
                d.addAttachment(AltDD.class, altDD);
                




                • 5. Re: jee module's alt-dd
                  Adrian Brock Master

                   

                  "scott.stark@jboss.org" wrote:

                  Good point, the EarStructure is where this should be done. The AltDD interface would need to be in the deployer project so that the general handling of the alt path can be handled in AbstractVFSParsingDeployer.

                  If were using the AltDD interface as the typed path/key, wouldn't the programtic usage be:
                  addAttachment(Class<T> type, T attachment);
                  VFSDeployment d = new VFSDeployment(ejbjar);
                  AltDD altDD = ...("al.ternatelocation");
                  d.addAttachment(AltDD.class, altDD);
                  



                  You could use a class rather than a String to recognise the AltDD,
                  but you'd need more than one.
                  Remember a deployment can be both an EJB and a Web Deployment,
                  e.g. webservices where the web metadata is constructed programmatically
                  by the ws deployers

                  • 6. Re: jee module's alt-dd
                    Adrian Brock Master

                     

                    "adrian@jboss.org" wrote:

                    Remember a deployment can be both an EJB and a Web Deployment,
                    e.g. webservices where the web metadata is constructed programmatically
                    by the ws deployers


                    Although I think in this case, the ws deployers run after the parsing
                    so it wouldn't actually conflict in this case.

                    • 7. Re: jee module's alt-dd
                      Alexey Loubyansky Master

                      I am trying to make it work. I don't see how I can add an attachment in the EARStructure. Instead, I am doing this in the AppParsingDeployer. I override the parse(..) method like (for now just for ejb)

                      protected EarMetaData parse(VFSDeploymentUnit unit, VirtualFile file, EarMetaData root) throws Exception
                       {
                       VirtualFile earRoot = file.getParent().getParent();
                       EarMetaData earMetaData = super.parse(unit, file, root);
                       ModulesMetaData modules = earMetaData.getModules();
                       if(modules != null && modules.size() > 0)
                       {
                       for(ModuleMetaData module : modules)
                       {
                       String alternativeDD = module.getAlternativeDD();
                       if(alternativeDD != null && module.getType() == ModuleType.Ejb)
                       {
                       VirtualFile altDDFile = earRoot.getChild(alternativeDD);
                       unit.addAttachment("ejb.altDD", altDDFile);
                       }
                       }
                       }
                       return earMetaData;
                       }


                      Then in the EjbParsingDeployer in the init(..)
                      protected void init(VFSDeploymentUnit unit, EjbJarMetaData metaData, VirtualFile file) throws Exception
                       {
                       VFSDeploymentUnit earUnit = unit.getParent();
                       if(earUnit != null)
                       {
                       VirtualFile altDD = (VirtualFile) earUnit.getAttachment("ejb.altDD");
                       if(altDD != null)
                       file = altDD;
                       }
                       super.init(unit, metaData, file);
                       }


                      Am I getting it right?

                      About the AltDD interface being in the deployers project. If metadata classes are going to implement it it would make the metadata project depend on deployers. Which doesn't seem to be a good idea to me.

                      • 8. Re: jee module's alt-dd
                        Alexey Loubyansky Master

                        A bit more generalized, how does this look? The change that is in this example in the EjbParsingDeployer could probably be in the SchemaResolverDeployer?

                        Index: org/jboss/deployment/AppParsingDeployer.java
                        + protected EarMetaData parse(VFSDeploymentUnit unit, VirtualFile file, EarMetaData root) throws Exception
                        + {
                        + EarMetaData ear = super.parse(unit,file, root);
                        + List<DeploymentUnit> children = unit.getChildren();
                        + if(children != null)
                        + {
                        + for(DeploymentUnit child : children)
                        + {
                        + String moduleName = child.getSimpleName();
                        + ModuleMetaData module = ear.getModules().get(moduleName);
                        + if(module != null && module.getAlternativeDD() != null)
                        + {
                        + VirtualFile altDDFile = unit.getRoot().getChild(module.getAlternativeDD());
                        + if(altDDFile == null)
                        + throw new IllegalStateException("Failed to locate alternative DD '" + module.getAlternativeDD() + "' in " + unit.getRoot().getPathName());
                        + child.addAttachment(child.getSimpleName() + ".altDD", altDDFile);
                        + log.info("attached alt-dd " + altDDFile + " for " + child.getSimpleName());
                        + }
                        + }
                        + }
                        +
                        + return ear;
                        + }
                         }
                        Index: org/jboss/deployment/EjbParsingDeployer.java
                         @Override
                        - protected void init(VFSDeploymentUnit unit, EjbJarMetaData metaData, VirtualFile file) throws Exception
                        + protected EjbJarMetaData parse(VFSDeploymentUnit unit, VirtualFile file, EjbJarMetaData root) throws Exception
                         {
                        - super.init(unit, metaData, file);
                        + VirtualFile altDDFile = (VirtualFile) unit.getAttachment(unit.getSimpleName() + ".altDD");
                        + if(altDDFile != null)
                        + {
                        + log.info("using alt-dd: " + altDDFile);
                        + file = altDDFile;
                        + }
                        + return super.parse(unit, file, root);
                         }


                        • 9. Re: jee module's alt-dd
                          Adrian Brock Master

                          Looks good.

                          But why are you using the unit.SimpleName() + ".altDD"
                          wouldn't it be more logical to use something like
                          EARMetaData.class.getName() + ".altDD"
                          or generically
                          getOutput().getName() + ".altDD"
                          that way you can have an altDD for every xml file in META-INF
                          with the override attachment metadata name based on the type.

                          • 10. Re: jee module's alt-dd
                            Alexey Loubyansky Master

                            I don't have strong preferences here. If it looks more logical then I'll do it that way.

                            Except as it is done now, getOutput() is available only in the module deployer. The deployer that is attaching the altDD value (AppParsingDeployer in this case) has to use class names explicitly? I did it that way because the key construction was identical everywhere and that looked easier to me.

                            • 11. Re: jee module's alt-dd
                              Adrian Brock Master

                               

                              "alex.loubyansky@jboss.com" wrote:
                              I don't have strong preferences here. If it looks more logical then I'll do it that way.

                              Except as it is done now, getOutput() is available only in the module deployer. The deployer that is attaching the altDD value (AppParsingDeployer in this case) has to use class names explicitly? I did it that way because the key construction was identical everywhere and that looked easier to me.


                              Yes, but in the standard EAR metadata you have to know the type anyway.
                               <module>
                               <ejb>ejb.jar</ejb> // Implies EjbJarMetaData.class.getName().altdd
                               <alt-dd>altDD_ejb.xml</alt-dd>
                               </module>
                              


                              But the real point is that In JBoss there can be other files in META-INF.
                              e.g. an altDD_jboss.xml for the same module
                              which could be specified in jboss-app.xml or could be specified by the deployer
                              programmatically.

                              • 12. Re: jee module's alt-dd
                                Alexey Loubyansky Master

                                I've committed the change (with a testcase) to the SchemaResolverDeployer's parse(..) method

                                VirtualFile altDD = (VirtualFile) unit.getAttachment(getOutput().getName() + ".altDD");
                                 if(altDD != null)
                                 file = altDD;


                                I am going to create a separate issue in JBAS project for ejb, client and also war(?) deployers.

                                • 13. Re: jee module's alt-dd
                                  Alexey Loubyansky Master

                                  I am going to re-open the issue and do the same for ObjectModelFactoryDeployer. This is needed for the connector alt-dd in EARs.

                                  • 14. Re: jee module's alt-dd
                                    Alexey Loubyansky Master

                                    Fixed in the AbstractVFSParsingDeployer.