11 Replies Latest reply on Dec 24, 2001 2:09 PM by David Jencks

    Unified Deployer

    marc fleury Master

      That is the grand unification theory,

      in fact don't even bother, i am on it, I don't want to share.

      marcf

        • 1. Re: Unified Deployer
          Adrian Brock Master

          Hi Marc,

          Is this David Jenck's

          *.xml -> jboss-deployment.xml(?) -> deployed

          Or something else?

          Regards,
          Adrian

          • 2. Re: Unified Deployer
            marc fleury Master

            No that is something else.

            What I am talking about is at the ServiceDeployment level and the ClassLoader structure.

            Like I said I keep it for myself.

            • 3. Re: Unified Deployer
              Adrian Brock Master

              Hi,

              Would you mind if I had a go at implementing David's
              idea?

              I'm not that familiar with all the DTDs, but his
              idea sounds very powerful!

              I see it working a bit like docbook???

              With entries mapping to
              Interceptors, ENC entries, registrations with other
              services (e.g. servlets with web integration or
              CMP with data sources)
              etc., etc.

              There will be default configuration provided by each
              "deployer". This is no longer any code, it is just some stylesheets. Of course the stylesheet will define
              the classes doing the real deployment/registration.

              Each deployment can override any entry in the default configuration.

              It doesn't sound easy does it? Perhaps I don't know
              enough about all requirements to do this properly??

              This seems the way to go though. Think about .net.
              Just write a default stylesheet and a .net archive can
              be deployed running over rmi/iiop/soap/etc

              Regards,
              Adrian

              • 4. Re: Unified Deployer
                David Jencks Master

                Marc, are you mostly concerned with working out the classloader stuff? If so maybe we could cooperate so the only thing that needs deplloying is mbeans in *-service.xml files.


                As I see it there are 2 parts:
                1. Writing the transformational grammar (xslt) to convert "spec-like" dds (spec compliant ejb-jar.xml, jboss.xml, jbosscmp.xml) to a *-service.xml file with an mbean configuration for each object (application if necessary, ejb-module, each ejb, possibly some for relationships, I haven't thought that far). This is fairly easy if you know a little xslt -- I combined ejb-jar.xml and jbosscmp.xml with a fairly simple script. I also envision explicitly setting the defaults everywhere they will be used. (also not very hard).


                2. Moving the logic from what are now e.g. ejb deployers (ContainerFactory) into the ejb-mbeans (now Container). This will include a dramatic simplification of the xml parsing code, since there are now no defaults and no need to add more data later, due to the combining of xml dds in the transformation phase.

                2.5 We ought to be able to avoid writing the xml parsing code ourselves by using either jaxb or castor-xml to generate classes and mapping code from an xml dtd or schema. I've done some experiments with jaxb that look promising but I don't know to what extent it will work, nor do I understand the license issues. Could we use Castor for this?

                If you want a copy of my xslt scripts or the jaxb stuff let me know, I will send it. I'll try to put together a more specific simple example tomorrow of the transformations.

                • 5. Re: Unified Deployer
                  marc fleury Master

                  > Marc, are you mostly concerned with working out the
                  > classloader stuff?

                  I am concerned with integrating the classloaders and tracking the dependencies in the classes-> URL. That harps back to the deployers.

                  The one thing where I see this leaving are the Deployment info, or ServiceDeploymentInfo we have now. I still am fuzzy on the granularity on the "MBeanClassLoader" at this point, per app? per bean? per EJB? per MBean.. I will sort this out.

                  It seems this work is somewhat independent of your which is really the unification of the deployment descriptors, I will work on CL and possibly SDI to unify them across deployers. First CL.

                  > If so maybe we could cooperate so
                  > the only thing that needs deplloying is mbeans in
                  > *-service.xml files.
                  >
                  >
                  > As I see it there are 2 parts:
                  > 1. Writing the transformational grammar (xslt) to
                  > convert "spec-like" dds (spec compliant ejb-jar.xml,
                  > jboss.xml, jbosscmp.xml) to a *-service.xml file with
                  > an mbean configuration for each object (application
                  > if necessary, ejb-module, each ejb, possibly some for
                  > relationships, I haven't thought that far). This is
                  > fairly easy if you know a little xslt -- I combined
                  > ejb-jar.xml and jbosscmp.xml with a fairly simple
                  > script. I also envision explicitly setting the
                  > defaults everywhere they will be used. (also not very
                  > hard).
                  >

                  Ok the capacity to use default in the transformation would indeed be useful if it simplifies the parsing code in the respective containers.

                  > 2. Moving the logic from what are now e.g. ejb
                  > deployers (ContainerFactory) into the ejb-mbeans (now
                  > Container). This will include a dramatic
                  > simplification of the xml parsing code, since there
                  > are now no defaults and no need to add more data
                  > later, due to the combining of xml dds in the

                  ok

                  > transformation phase.
                  >
                  > 2.5 We ought to be able to avoid writing the xml
                  > parsing code ourselves by using either jaxb or
                  > castor-xml to generate classes and mapping code from
                  > an xml dtd or schema. I've done some experiments
                  > with jaxb that look promising but I don't know to
                  > what extent it will work, nor do I understand the
                  > license issues. Could we use Castor for this?

                  Send me a link to the license.

                  > If you want a copy of my xslt scripts or the jaxb
                  > stuff let me know, I will send it. I'll try to put
                  > together a more specific simple example tomorrow of
                  > the transformations.


                  marcf

                  • 6. Re: Unified Deployer
                    David Jencks Master

                    > > Marc, are you mostly concerned with working out
                    > the
                    > > classloader stuff?
                    >
                    > I am concerned with integrating the classloaders and
                    > tracking the dependencies in the classes-> URL. That
                    > harps back to the deployers.
                    >
                    > The one thing where I see this leaving are the
                    > Deployment info, or ServiceDeploymentInfo we have
                    > now. I still am fuzzy on the granularity on the
                    > "MBeanClassLoader" at this point, per app? per bean?
                    > per EJB? per MBean.. I will sort this out.

                    At this point I think sdi <--> jboss's URLClassLoader, maybe they can even be the same class. I think MBeanClassLoader <--> class of mbean rather than mbean instance. MbeanClassLoader <--> mbean instance is ok, but may have more classes and notification than necessary.
                    >
                    > It seems this work is somewhat independent of your
                    > which is really the unification of the deployment
                    > descriptors, I will work on CL and possibly SDI to
                    > unify them across deployers. First CL.
                    >

                    I think we can work in parallel and assemble the pieces later.
                    > > If so maybe we could cooperate so
                    > > the only thing that needs deplloying is mbeans in
                    > > *-service.xml files.


                    > > 2.5 We ought to be able to avoid writing the xml
                    > > parsing code ourselves by using either jaxb or
                    > > castor-xml to generate classes and mapping code
                    > from
                    > > an xml dtd or schema. I've done some experiments
                    > > with jaxb that look promising but I don't know to
                    > > what extent it will work, nor do I understand the
                    > > license issues. Could we use Castor for this?
                    >
                    > Send me a link to the license.

                    I've anly found the jaxb license on the way to the download from

                    http://developer.java.sun.com/developer/earlyAccess/xml/jaxb/

                    How about Castor

                    http://castor.exolab.org/license.html

                    thanks
                    david

                    • 8. Re: Unified Deployer
                      Scott Sanders Newbie

                      I would be willing to help with parts of this. I have quite a bit of experience with XSLT, and also xml 2 java mapping. Shouldn't be hard at all. Let me know if you want some help. Would Digester (from jakarta-commons) be useful in the xml->java realm?

                      Scott Sanders

                      • 9. Re: Unified Deployer
                        David Jencks Master

                        xml <--> java. I looked at digester for a minute, so far it looks like less of what I think we need than Castor or JAXB. I think the ability to generate (base) (metadata) classes from a schema or dtd will end up being very useful in providing compile time checking of schema/dtd to metadata class consistency.

                        I think the hardest part of this will be figuring out what we want;-)

                        So, here is my promised example. This is a hypothetical xml document (to be) generated through xslt from ejb-jar.xml, jbosscmp-jdbc.xml, and jboss.xml. The current dd's can remain as they are today, just what is actually deployed is different.


                        <?xml version="1.0" encoding="UTF-8"?>



                        <depends optional-attribute-name="virtualhost">HOSTS:name=sample
                        <depends optional-attribute-name="securitydomain">DOMAINS:name=ReallySecure



                        <depends optional-attribute-name="application">J2EE-Deployments:name=smallexample,type=application,id=1



                        <depends optional-attribute-name="ejb-module">J2EE-Deployments:name=smallexample,type=ejb-module,id=2
                        <depends optional-attribute-name="interceptor-chain">J2EE-Deployments:name=myinterceptorchain,type=interceptorchain


                        User
                        <ejb-name>UserEJB</ejb-name>
                        org.jboss.docs.cmp2.commerce.UserHome
                        org.jboss.docs.cmp2.commerce.User
                        <local-home>org.jboss.docs.cmp2.commerce.UserLocalHome</local-home>
                        org.jboss.docs.cmp2.commerce.UserLocal
                        <ejb-class>org.jboss.docs.cmp2.commerce.UserBean</ejb-class>
                        <persistence-type>Container</persistence-type>
                        <prim-key-class>java.lang.String</prim-key-class>
                        False
                        <cmp-version>2.x</cmp-version>
                        <abstract-schema-name>user</abstract-schema-name>
                        <cmp-field>
                        <field-name>userId</field-name>
                        <column-name>USER_ID</column-name>
                        <jdbc-type>INTEGER</jdbc-type>
                        <sql-type>INTEGER</sql-type>
                        </cmp-field>
                        <cmp-field>
                        <field-name>userName</field-name>
                        <column-name>USER_NAME</column-name>
                        <jdbc-type>VARCHAR</jdbc-type>
                        <sql-type>VARCHAR(255)</sql-type>
                        </cmp-field>
                        <cmp-field>
                        <field-name>email</field-name>
                        <column-name>EMAIL</column-name>
                        <jdbc-type>VARCHAR</jdbc-type>
                        <sql-type>VARCHAR(255)</sql-type>
                        </cmp-field>
                        <cmp-field>
                        <field-name>sendSpam</field-name>
                        <column-name>SEND_SPAM</column-name>
                        <jdbc-type>CHAR</jdbc-type>
                        <sql-type>CHAR(255)</sql-type>
                        </cmp-field>
                        <primkey-field>userId</primkey-field>


                        Find the user with the specified name.

                        <query-method>
                        <method-name>findByUserName</method-name>
                        <method-params>
                        <method-param>java.lang.String</method-param>
                        </method-params>
                        </query-method>
                        <ejb-ql>
                        select object(U)
                        from user u
                        where U.userName = ?1
                        </ejb-ql>



                        Find all users

                        <query-method>
                        <method-name>findAll</method-name>
                        <method-params/>
                        </query-method>
                        <ejb-ql>
                        SELECT OBJECT(u)
                        FROM user U
                        </ejb-ql>



                        This is just a place holder. Overriden with declared-sql

                        <query-method>
                        <method-name>ejbSelectUserIds</method-name>
                        <method-params/>
                        </query-method>
                        <ejb-ql>
                        SELECT OBJECT(u)
                        FROM user u
                        </ejb-ql>
                        <declared-sql>


                        <ejb-name>UserEJB</ejb-name>
                        <field-name>userId</field-name>

                        USER_ID
                        </declared-sql>

                        java:/DefaultDS
                        <store-name>USER</store-name>
                        <eager-load>
                        <field-name>userName</field-name>
                        </eager-load>
                        <lazy-load-groups>
                        <lazy-load-group>
                        email options
                        <field-name>email</field-name>
                        <field-name>sendSpam</field-name>
                        </lazy-load-group>
                        </lazy-load-groups>
                        <create-table>true</create-table>
                        <remove-table>true</remove-table>
                        <read-only>false</read-only>
                        <time-out>300</time-out>
                        <select-for-update>false</select-for-update>
                        <pk-constraint>true</pk-constraint>
                        <container-transaction>

                        <method-name>*</method-name>
                        <!--the method names should really be expanded to a complete list -->

                        <trans-attribute>Required</trans-attribute>
                        </container-transaction>





                        <depends-list optional-attribute-name="interceptorlist">
                        <depends-list-element>J2EE-Deployments:name=LogInterceptor</depends-list-element>
                        <depends-list-element>J2EE-Deployments:name=SecurityInterceptor</depends-list-element>
                        <depends-list-element>J2EE-Deployments:name=TxInterceptorCMT</depends-list-element>
                        J2EE-Deployments:name=MetricsInterceptor</depends-list-element>
                        <depends-list-element>J2EE-Deployments:name=EntityLockInterceptor</depends-list-element>
                        <depends-list-element>J2EE-Deployments:name=EntityInstanceInterceptor</depends-list-element>
                        <depends-list-element>J2EE-Deployments:name=EntitySynchronizationInterceptor</depends-list-element>
                        <depends-list-element>J2EE-Deployments:name=cmp.jdbc.JDBCRelationInterceptor</depends-list-element>
                        <depends-list-element>J2EE-Deployments:name=cmp.jdbc.JDBCReadAheadInterceptor</depends-list-element>
                        </depends-list>



                        <!--mbeans for interceptors ommitted-->


                        • 10. Re: Unified Deployer
                          Scott Sanders Newbie

                          > xml <--> java. I looked at digester for a minute, so
                          > far it looks like less of what I think we need than
                          > Castor or JAXB. I think the ability to generate
                          > (base) (metadata) classes from a schema or dtd will
                          > end up being very useful in providing compile time
                          > checking of schema/dtd to metadata class
                          > consistency.

                          Digester cannot currently do 2way, only xml -> java, so Castor or jaxb will be a better fit if that is needed.

                          >
                          > I think the hardest part of this will be figuring out
                          > what we want;-)
                          >
                          > So, here is my promised example. This is a
                          > hypothetical xml document (to be) generated through
                          > xslt from ejb-jar.xml, jbosscmp-jdbc.xml, and
                          > jboss.xml. The current dd's can remain as they are
                          > today, just what is actually deployed is different.
                          >
                          >

                          So, from this example, you actually want to generate a class (and an instance of that class) for this, or just an instance of some common metadata type class?

                          Scott

                          • 11. Re: Unified Deployer
                            David Jencks Master

                            Lets see if I can be clearer.

                            The xml in my example is to be generated from the current dd's using xslt.

                            The code for the mbeans mentioned in the xml is written by hand.

                            We write the schema/dtd + other config info describing the structure of the xml element in the ejb mbean, and use JAXB or Castor to generate base metadata classes from it. This code generation is done as part of the jboss build.

                            The actual metadata classes we use are subclasses of the generated classes. With a lot of luck, these can actually be the classes that for instance implement the cmp 2 behavior: without that luck, they will replace the current metadata classes and be used by the e.g. cmp 2 classes.

                            By subclassing the generated classes, we get a compile time check on the correspondence between the xml structure and the classes representing it.

                            At runtime, the ejb mbean will take its xml-config attribute value and during "create" will unmarshal it into the metadata classes using JAXB or Castor.

                            There are several ideas here, and they don't all have to happen at once.

                            Transforming dd's into mbean configuration is one step, and the xml can still be read by something like what we have now or the more reflection-driven technique used in RARMetaData. In this case all classes are written by hand.

                            Generating classes with JAXB or Castor and using those unmarshalling frameworks is another step that would provide additional compile time checks and I think considerably reduce the amount of code we have to write.

                            So far I've worked a bit with JAXB which appears to be pretty easy to use, however apparently we can't use it in a release right now. Castor looks like it may be a little harder to set up, but does have the advantage of availability.

                            So far I've mostly been playing around, but I'd be happy to send my experiments to anyone interested.