13 Replies Latest reply on Oct 7, 2006 3:25 PM by aloubyansky

    Allowing multiple AbstractParsingDeployer to work with the s

    starksm64

      One issue I'm having right now is breaking up the web.xml to WebMetaData and jboss-web.xml to WebMetaData into two deployers that populate the same WebMetaData as is currently done via the XmlLoadable interface. This is supported by jbossxb Unmarshaller by passing in a pre-existing root.

      The AbstractParsingDeployer needs a flag to indicate whether parsing should be run even if there is an existing deployment type attachment.

        • 1. Re: Allowing multiple AbstractParsingDeployer to work with t
          starksm64

          I changed AbstractParsingDeployer to have an abstract parse(DeploymentUnit unit, VirtualFile file, T root) (not checked in yet). This introduces the same override in the ObjectModelFactoryDeployer, JAXPDeployer and SchemaResolverDeployer. This only makes sense in the ObjectModelFactoryDeployer in terms of having direct support for using the root. The jbossxb methods taking a SchemaResolver used by SchemaResolverDeployer do not take an existing root(although I don't know why they could not).

          The JAXPDeployer would have to be expanded to include a parse(DeploymentUnit unit, VirtualFile file, Document document, T root) to effectively propagate the root.

          Do these changes sound ok?

          • 2. Re: Allowing multiple AbstractParsingDeployer to work with t
            starksm64

            I have committed a change that allows propagation of an existing deployment type instance if the AbstractParsingDeployer.allowsReparse() is true. Here is the patch:

            Index: C:/svn/JBossMC/jbossmc/deployers/src/main/org/jboss/deployers/plugins/deployers/helpers/ObjectModelFactoryDeployer.java
            ===================================================================
            --- C:/svn/JBossMC/jbossmc/deployers/src/main/org/jboss/deployers/plugins/deployers/helpers/ObjectModelFactoryDeployer.java (revision 57411)
            +++ C:/svn/JBossMC/jbossmc/deployers/src/main/org/jboss/deployers/plugins/deployers/helpers/ObjectModelFactoryDeployer.java (working copy)
            @@ -61,7 +61,7 @@
             * @return the metadata
             * @throws Exception for any error
             */
            - protected T parse(DeploymentUnit unit, VirtualFile file) throws Exception
            + protected T parse(DeploymentUnit unit, VirtualFile file, T root) throws Exception
             {
             if (file == null)
             throw new IllegalArgumentException("Null file");
            @@ -70,8 +70,7 @@
             Object parsed = null;
             try
             {
            - ObjectModelFactory factory = getObjectModelFactory();
            - Object root = null;
            + ObjectModelFactory factory = getObjectModelFactory(root);
             URL url = file.toURL();
             parsed = unmarshaller.unmarshal(url.toString(), factory, root);
             }
            @@ -90,5 +89,5 @@
             *
             * @return the object model factory
             */
            - protected abstract ObjectModelFactory getObjectModelFactory();
            + protected abstract ObjectModelFactory getObjectModelFactory(T root);
             }
            Index: C:/svn/JBossMC/jbossmc/deployers/src/main/org/jboss/deployers/plugins/deployers/helpers/SchemaResolverDeployer.java
            ===================================================================
            --- C:/svn/JBossMC/jbossmc/deployers/src/main/org/jboss/deployers/plugins/deployers/helpers/SchemaResolverDeployer.java (revision 57411)
            +++ C:/svn/JBossMC/jbossmc/deployers/src/main/org/jboss/deployers/plugins/deployers/helpers/SchemaResolverDeployer.java (working copy)
            @@ -65,7 +65,7 @@
             * @return the metadata
             * @throws Exception for any error
             */
            - protected T parse(DeploymentUnit unit, VirtualFile file) throws Exception
            + protected T parse(DeploymentUnit unit, VirtualFile file, T root) throws Exception
             {
             if (file == null)
             throw new IllegalArgumentException("Null file");
            Index: C:/svn/JBossMC/jbossmc/deployers/src/main/org/jboss/deployers/plugins/deployers/helpers/JAXPDeployer.java
            ===================================================================
            --- C:/svn/JBossMC/jbossmc/deployers/src/main/org/jboss/deployers/plugins/deployers/helpers/JAXPDeployer.java (revision 57411)
            +++ C:/svn/JBossMC/jbossmc/deployers/src/main/org/jboss/deployers/plugins/deployers/helpers/JAXPDeployer.java (working copy)
            @@ -142,7 +142,7 @@
             * @return the metadata
             * @throws Exception for any error
             */
            - protected T parse(DeploymentUnit unit, VirtualFile file) throws Exception
            + protected T parse(DeploymentUnit unit, VirtualFile file, T root) throws Exception
             {
             Document document = doParse(unit, file);
             return parse(unit, file, document);
            Index: C:/svn/JBossMC/jbossmc/deployers/src/main/org/jboss/deployers/plugins/deployers/helpers/AbstractParsingDeployer.java
            ===================================================================
            --- C:/svn/JBossMC/jbossmc/deployers/src/main/org/jboss/deployers/plugins/deployers/helpers/AbstractParsingDeployer.java (revision 57411)
            +++ C:/svn/JBossMC/jbossmc/deployers/src/main/org/jboss/deployers/plugins/deployers/helpers/AbstractParsingDeployer.java (working copy)
            @@ -28,7 +28,9 @@
             import org.jboss.virtual.VirtualFile;
            
             /**
            - * AbstractParsingDeployer.
            + * AbstractParsingDeployer. Extends AbstractTypedDeployer to add a notion of obtaining an instance of the
            + * deploymentType by parsing a metadata file. Subclasses need to override
            + * parse(DeploymentUnit, VirtualFile) to define this behavior.
             *
             * @param <T> the expected type
             * @author <a href="adrian@jboss.com">Adrian Brock</a>
            @@ -51,8 +53,19 @@
             {
             return PARSER_DEPLOYER;
             }
            -
            +
             /**
            + * A flag indicating whether createMetaData should execute a parse even if a non-null metadata value exists.
            + *
            + * @return false if a parse should be performed only if there is no existing metadata value. True indicates
            + * that parse should be done regardless of an existing metadata value.
            + */
            + protected boolean allowsReparse()
            + {
            + return false;
            + }
            +
            + /**
             * Get some meta data
             *
             * @param unit the deployment unit
            @@ -65,7 +78,7 @@
             }
            
             /**
            - * Create some meta data
            + * Create some meta data. Calls createMetaData(unit, name, suffix, getDeploymentType().getName()).
             *
             * @param unit the deployment unit
             * @param name the name
            @@ -78,7 +91,8 @@
             }
            
             /**
            - * Create some meta data
            + * Create some meta data. Invokes parse(unit, name, suffix) if there is not already a
            + * metadata
             *
             * @param unit the deployment unit
             * @param name the name
            @@ -90,16 +104,16 @@
             {
             // First see whether it already exists
             T result = getMetaData(unit, key);
            - if (result != null)
            + if (result != null && allowsReparse() == false)
             return;
            
             // Create it
             try
             {
             if (suffix == null)
            - result = parse(unit, name);
            + result = parse(unit, name, result);
             else
            - result = parse(unit, name, suffix);
            + result = parse(unit, name, suffix, result);
             }
             catch (Exception e)
             {
            @@ -122,14 +136,14 @@
             * @return the metadata or null if it doesn't exist
             * @throws Exception for any error
             */
            - protected T parse(DeploymentUnit unit, String name) throws Exception
            + protected T parse(DeploymentUnit unit, String name, T root) throws Exception
             {
             // Try to find the metadata
             VirtualFile file = unit.getMetaDataFile(name);
             if (file == null)
             return null;
            
            - T result = parse(unit, file);
            + T result = parse(unit, file, root);
             init(unit, result, file);
             return result;
             }
            @@ -143,7 +157,7 @@
             * @return the metadata or null if it doesn't exist
             * @throws Exception for any error
             */
            - protected T parse(DeploymentUnit unit, String name, String suffix) throws Exception
            + protected T parse(DeploymentUnit unit, String name, String suffix, T root) throws Exception
             {
             // Try to find the metadata
             List<VirtualFile> files = unit.getMetaDataFiles(name, suffix);
            @@ -156,7 +170,7 @@
            
             VirtualFile file = files.get(0);
            
            - T result = parse(unit, file);
            + T result = parse(unit, file, root);
             init(unit, result, file);
             return result;
             }
            @@ -169,7 +183,7 @@
             * @return the metadata
             * @throws Exception for any error
             */
            - protected abstract T parse(DeploymentUnit unit, VirtualFile file) throws Exception;
            + protected abstract T parse(DeploymentUnit unit, VirtualFile file, T root) throws Exception;
            
             /**
             * Initialise the metadata
            



            • 3. Re: Allowing multiple AbstractParsingDeployer to work with t

              Ok, FYI I'm currently working on reworking the JavaEE parsing.

              I started this so I could get a real idea of what we need
              to create the ManagedObjects, but when I looked
              I got more deeply involved.

              I looked at what EJB3 is doing and it is basically broken
              for the following main reasons (there are others):

              1) It is incomplete and the error handling is rubbish (non-existent)
              2) It is not backward compatible so a user written EJB2 interceptor/plugin
              won't work because BeanMetaData, etc. is a different type.
              3) It is EJB centric, but there has been some work recently to
              copy parts of back into the original model for the injection stuff.

              I'm working on a schema based deployer for JavaEE5 where
              EJB2,3, RAR, WAR, CAR, EAR can share the same metamodel.

              To make this simpler, I've created a layer on top of JBossXB
              that uses annotations to bind the model to the schema.
              I'll describe this is a different JBossXB thread.

              I've also started a refactoring of the current metamodel
              (with a backwards compatibilty layer that basically wraps the new model)
              so we can improve the model.
              I have lots of ideas in this direction, but I been blocked from
              implementing them because of the compatibity consideration.

              One of them, is being able to override anything in ejb-jar.xml
              with the jboss.xml

              Another, which I haven't looked at yet in the current refactoring,
              is to reuse the annotations in the model.
              Which will obviously make it more consistent
              and also integrates better with the metadata repository.

              • 4. Re: Allowing multiple AbstractParsingDeployer to work with t

                 

                "adrian@jboss.org" wrote:
                Ok,


                Actually, this is not OK, because it breaks the idea
                that somebody can pass in an override WebMetaData
                in the predetermined objects and the deployers won't parse
                the web.xml from the deployment.

                • 5. Re: Allowing multiple AbstractParsingDeployer to work with t
                  weston.price

                  If you get a chance could you or Stark have Stephen Hawking call and explain the new deployment stuff to me? I am having a hard time understanding anything your saying at this point (actually for about 8 months now) and I thought he could clear things up for me.

                  Thanks!

                  • 8. Re: Allowing multiple AbstractParsingDeployer to work with t
                    starksm64

                     

                    "adrian@jboss.org" wrote:

                    Actually, this is not OK, because it breaks the idea
                    that somebody can pass in an override WebMetaData
                    in the predetermined objects and the deployers won't parse
                    the web.xml from the deployment.

                    The current AbstractParsingDeployer does not make the distinction as to whether the current deployment type attachment is a predetermined object, so I don't know whether this situation exists. This can be added to prevent uneeded parsing.


                    • 9. Re: Allowing multiple AbstractParsingDeployer to work with t
                      starksm64

                       

                      "adrian@jboss.org" wrote:
                      Ok, FYI I'm currently working on reworking the JavaEE parsing.

                      ...

                      I'm working on a schema based deployer for JavaEE5 where
                      EJB2,3, RAR, WAR, CAR, EAR can share the same metamodel.


                      Where is the metadata model going and how is it relating to the current org.jboss.metadata? I have merged the web tier parsing into population of the root org.jboss.metadata.WebMetaData instance by writing ObjectModelFactory. It should be schema based however.


                      • 10. Re: Allowing multiple AbstractParsingDeployer to work with t
                        starksm64

                         

                        "weston.price@jboss.com" wrote:
                        If you get a chance could you or Stark have Stephen Hawking call and explain the new deployment stuff to me? I am having a hard time understanding anything your saying at this point (actually for about 8 months now) and I thought he could clear things up for me.


                        Start here:
                        http://wiki.jboss.org/wiki/Wiki.jsp?page=JBoss5DeploymentFramework



                        • 11. Re: Allowing multiple AbstractParsingDeployer to work with t

                           

                          "scott.stark@jboss.org" wrote:

                          Where is the metadata model going and how is it relating to the current org.jboss.metadata?


                          Not sure what you are asking. Let me answer both questions :-)

                          1) I'm creating a JavaEE deployer project that does all the
                          standard/comon stuff then there will be EJBDeployer/WebDeployer
                          projects, etc. This is to seperate the deployer from the container
                          so it can a) do "on demand", b) the metadata model is shared where
                          appropriate, c) the container doesn't need to know anything about
                          how the model is created.

                          2) The metadata model will be a shared sanitised and refactored
                          model, e.g. I'm splitting BeanMetaData into security, persistence,
                          transactions, methods, etc
                          The org.jboss.metadata will still exist for read only by old
                          container plugins (e.g. user written interceptors). But it
                          will just be a wrapper/mapper to the real metadata model.

                          e.g.
                          org.jboss.metadata.BeanMetaData
                          
                           /** The delegate */
                           private EJBeanMetaData delegate;
                          
                           /**
                           * Create a new BeanMetaData.
                           *
                           * @param delegate the delegate
                           * @throws IllegalArgumentException for a null delegate
                           */
                           public BeanMetaData(EJBeanMetaData delegate)
                           {
                           if (delegate == null)
                           throw new IllegalArgumentException("Null delegate");
                           this.delegate = delegate;
                           }
                          
                          <snip/>
                          
                           /**
                           * Get the container managed transactions
                           *
                           * @return the container managed transactions
                           */
                           public boolean isContainerManagedTx()
                           {
                           EJBTransactionMetaData result = delegate.getTransactionConfig();
                           if (result == null)
                           return EJBTransactionMetaData.DEFAULT_CONTAINER_MANAGED_TX;
                           return result.isContainerManagedTx();
                           }
                          


                          Of course EJBTransactionMetaData should be an annotation
                          with it really coming from the metadata repository so it can
                          be overridden at different levels, e.g. deployment level
                          transaction defaults.


                          I have merged the web tier parsing into population of the root org.jboss.metadata.WebMetaData instance by writing ObjectModelFactory.

                          I'm using annotations to bind to the schema.
                          See the link I posted to a JBossXB forum post in a comment by itself
                          above.

                          EJB3 has their own factory(ies) as well.


                          It should be schema based however.


                          Correct.

                          • 12. Re: Allowing multiple AbstractParsingDeployer to work with t
                            starksm64

                             

                            "adrian@jboss.org" wrote:
                            "scott.stark@jboss.org" wrote:

                            Where is the metadata model going and how is it relating to the current org.jboss.metadata?


                            Not sure what you are asking. Let me answer both questions :-)
                            ...

                            Just whether the current org.jboss.metadata classes will continue to exist so that I can finish up an initial pass of the web-app 2.4 runtime deployer prototype. I have the metadata part done and now just need to complete the real web app deployer.

                            "adrian@jboss.org" wrote:

                            EJB3 has their own factory(ies) as well.


                            Right, I have merged the ejb3 web tier factories with the legacy XmlLoadable stuff to have a unified org.jboss.metadata based model with the org.jboss.metadata.WebMetaData as the root web app model. I have not updated the ejb3 layers that rely on the duplicate org.jboss.metamodel to use the merged org.jboss.metadata objects. This will need to be done in the context of stuff you are currently working on.


                            • 13. Re: Allowing multiple AbstractParsingDeployer to work with t
                              aloubyansky

                               

                              "scott.stark@jboss.org" wrote:
                              The jbossxb methods taking a SchemaResolver used by SchemaResolverDeployer do not take an existing root(although I don't know why they could not).


                              The reason was that the way to merge two (or more) XML contents into one Java object model wasn't obvious (w/o requiring a user to write the merging code). Of course, we could define some rules to support this.

                              For an example of a non-obvious merging issue, imagine we have ejb-jar.xml and jboss.xml listing a set of beans. How can I get the ejb-jar bean info for a jboss bean info being parsed? We can't rely on the same ordering of bean infos in ejb-jar and jboss.xml (they can be different and some beans maybe missing from jboss.xml or bean infos from ejb-jar could be collected into a java.util.Set and iteration order would be different). This can only be done by ejb-name. In this case, the user would have to provide some merging logic (writting custom element handlers, probably).