8 Replies Latest reply on Sep 12, 2007 10:43 AM by Anil Saldanha

    JBossAppParsingDeployer issue

    Scott Stark Master

      A problem with the JBossAppParsingDeployer is that there can be an ear that only contains a META-INF/jboss-app.xml. This is not being processed correctly because there is no J2eeApplicationMetaData input if there is no META-INF/application.xml. We are throwing away the J2eeApplicationMetaData determined by the EARStructure deployer which is the deployer that has the implicit ear contents logic that is based on structure/annotations. We need the ability for a structure deployer to add attachments that can be used as input to parsing deployers.

      I guess the correct place for this is in the StructureMetaData/ContextInfo, however, this only supports PredeterminedManagedObjects. It would also need to support TransientManagedObjects.

        • 1. Re: JBossAppParsingDeployer issue
          Scott Stark Master

          I created JBMICROCONT-199 for this and have checked that change into the structure deployer layer. A new snapshot release is needed to allow the EARStructure to propagate the J2eeApplicationMetaData. I have tested this locally and the ear with only the jboss-app.xml is being processed correctly.

          • 2. Re: JBossAppParsingDeployer issue
            Adrian Brock Master

            This is wrong.

            e.g. What if I want to deploy an EAR programatically where I tell it upfront
            what the structure and metadata is.

            i.e. it doesn't go through either the structure or the parsing deployer,
            it uses the structure and metadata I've told it to use when I did the programmtic
            deployment.

            I'm I supposed to know to add the transient managed object that represents
            the context root to the war context I create manually, or should I expect it to
            pick it from the J2eeApplicationMetaData where I defined it?

            The correct solution is to have a seperate deployer that looks
            for application level metadata when processing subdeployments.

            In principle there is not just the context-root that can defined at the ear
            level, one could also provide things like a default "call-by-value" in jboss-app.xml, etc.

            The creator of the deployment (including the profile service) should not
            be expected to know what transient managed objects need to be created.
            That is just an implementation detail of one way the deployers can "talk to each other".

            Also to make this work at all, the transient managed objects would
            have to be serialized such that a remote caller can add this information
            and the profile service can remember what they were when re-creating the deployment,
            this doesn't sound correct to me.

            • 3. Re: JBossAppParsingDeployer issue
              Scott Stark Master

               

              "adrian@jboss.org" wrote:
              This is wrong.

              e.g. What if I want to deploy an EAR programatically where I tell it upfront
              what the structure and metadata is.

              i.e. it doesn't go through either the structure or the parsing deployer,
              it uses the structure and metadata I've told it to use when I did the programmtic
              deployment.

              Then the deployer processing has to support complete vs incomplete inputs. I can have a complete programmatic specification, or multiple partial sources as is the case where javaee naming conventions along with a jboss-app.xml is used to define the contents of an ear. I don't see how allowing the structural parse to introduce deployment metadata has any affect on a programmatic deployment.

              "adrian@jboss.org" wrote:

              I'm I supposed to know to add the transient managed object that represents
              the context root to the war context I create manually, or should I expect it to
              pick it from the J2eeApplicationMetaData where I defined it?

              The correct solution is to have a seperate deployer that looks
              for application level metadata when processing subdeployments.

              In principle there is not just the context-root that can defined at the ear
              level, one could also provide things like a default "call-by-value" in jboss-app.xml, etc.

              The creator of the deployment (including the profile service) should not
              be expected to know what transient managed objects need to be created.
              That is just an implementation detail of one way the deployers can "talk to each other".

              Right, there are multiple types of component level data that can be specified at the ear level. There are two level of metadata for the javaee components, ear and component. I don't see how introducing another deployer that maps from J2eeApplicationMetaData to the component specific value is better than having the component deployer look in two places. Something produces the J2eeApplicationMetaData (the EARStructure or another implicit AppParsingDeployer that runs when there is no application.xml, or programmatic definition), and component deployers look to the component level source and then to the ear level if needed. Nothing needs to know what the component level piece of metadata for the context-root is.

              "adrian@jboss.org" wrote:

              Also to make this work at all, the transient managed objects would
              have to be serialized such that a remote caller can add this information
              and the profile service can remember what they were when re-creating the deployment,
              this doesn't sound correct to me.

              A remote caller is passing in the ear and having the structure/regular deployers process it. A profile service impl may only be storing the raw ear with just the META-INF/jboss-app.xml and running through the full deployment processing every time, or it may be saving off all metadata as predetermined overrides. I don't see where there is an intermediate situation where a remote caller is providing transient managed objects.


              • 4. Re: JBossAppParsingDeployer issue
                Adrian Brock Master

                 

                "scott.stark@jboss.org" wrote:
                I don't see how allowing the structural parse to introduce deployment metadata has any affect on a programmatic deployment.


                Because the structural deployer is not invoked if I tell it explicitly what the
                structure of the ear is. It is also not invoked if I add a META-INF/jboss-structure.xml

                Describing the structure programmatically is just a case of adding the
                structure metadata equivalent of META-INF/jboss-structure.xml to the deployment.

                In order:
                1) Is there is a predetermined StructureMetadata attachment?
                2) Is there a META-INF/jboss-structure.xml
                3) Is it an EAR - EARStructure.

                Only if (1) and (2) fail will the EARStructure get invoked.

                So in summary you can't assume that a structural deployer will be invoked.
                It shouldn't do anything other than creating structure (and only then
                when it is invoked because there isn't an explicit structure).

                • 5. Re: JBossAppParsingDeployer issue
                  Scott Stark Master

                   

                  "adrian@jboss.org" wrote:
                  "scott.stark@jboss.org" wrote:
                  I don't see how allowing the structural parse to introduce deployment metadata has any affect on a programmatic deployment.


                  Because the structural deployer is not invoked if I tell it explicitly what the
                  structure of the ear is. It is also not invoked if I add a META-INF/jboss-structure.xml
                  ...


                  Ok, that is the real problem but I'm ignoring why this has any impact on programmatic deployments other than that to properly provide the structure metadata for an ear without an application.xml, you would have to also provide the J2eeApplicationMetaData. It is too much to assume this will also be programmatic available, so if that is what your saying I agree.

                  I have created an EARContentsDeployer that is ordered after the AppParsingDeployer and runs on ears without META-INF/application.xml to produce the implicit J2eeApplicationMetaData. The jboss-app.xml only ear is being correctly processed with this deployer in the chain.


                  • 6. Re: JBossAppParsingDeployer issue
                    Anil Saldanha Master

                    An immediate issue that I am noticing is if there exists a jboss-app.xml that defines a security domain and there is no jboss.xml in the EAR, then the ApplicationMetaData that gets generated in the process has lost the merge from the ear level settings, because the merge of the security domain is currently being done in the JBossEJBParsingDeployer.

                    So no jboss.xml, implies no invocation of the JBossEJBParsingDeployer.

                    So should this merging be also done in the EjbParsingDeployer?

                    • 7. Re: JBossAppParsingDeployer issue
                      Adrian Brock Master

                       

                      "anil.saldhana@jboss.com" wrote:
                      An immediate issue that I am noticing is if there exists a jboss-app.xml that defines a security domain and there is no jboss.xml in the EAR, then the ApplicationMetaData that gets generated in the process has lost the merge from the ear level settings, because the merge of the security domain is currently being done in the JBossEJBParsingDeployer.

                      So no jboss.xml, implies no invocation of the JBossEJBParsingDeployer.

                      So should this merging be also done in the EjbParsingDeployer?


                      The parsing deployers should not be doing anything except parsing
                      (and maybe doing things like filling in the VFS url which isn't known to the parser
                      but is in the metadata).

                      Any modification of the metadata after parsing should be in a seperate deployer.
                      The parsing deployers aren't even guaranteed to be called if the metadata is passed
                      in programmatically.