8 Replies Latest reply on Jan 31, 2005 10:56 AM by Adrian Brock

    Convenience or use case configurations

    Adrian Brock Master

      I'd better outline the idea of "convenience" or use case configurations.

      The problem:
      Although the jboss microcontainer metadata is very flexible and basically
      will allow you configure anything you like that could be done through
      java programming and much more, it is very verbose.
      In many use cases, a lot of the configuration remains the same with only
      a few parameters changing.

        • 1. Re: Convenience or use case configurations
          Adrian Brock Master

          Let's take the example of constructing a classloader since that was brought up
          by Scott.

          In plain bean metadata this looks something like the following:

          <bean bean="java.net.URLClassLoader">
           <constructor>
           <parameters>
           <parameter type="java.net.URL">someURL</parameter>
           </parameters>
           </constructor>
          </bean>
          


          which will become pretty tedious for more complicated constructs.

          • 2. Re: Convenience or use case configurations
            Adrian Brock Master

            Solution:
            The microcontainer accepts the notion of a deployment,
            this is a collection of beans:

            public interface KernelDeployment
            {
             /**
             * Get the beans in the deployment
             *
             * @return List<BeanMetaData>
             */
             List getBeans();
            
            


            This can be used to "generate" the bean metadata from a few parameters.

            In the example above it would be something like:
            public class URLClassLoaderDeployment extends AbstractDeployment
            {
             /** with getters and setters */
             private URL url;
            
             public List getBeans()
             {
             // Generate the bean metadata here
             }
            }
            


            So the xml might look something like:
            <urlclassloader url="whatever"/>
            



            • 3. Re: Convenience or use case configurations
              Adrian Brock Master

              You will also note that multiple beans can be constructed
              so you could use the same technique to simplify more complex
              (multi-bean) deployments:

              <proxy-container>
               <interceptors>...</interceptors>
               <target>...</target>
              </proxy-container>
              


              I see this as more important for the deployers where we should be able to
              parse the more complex j2ee deployment descriptors and turn them into
              a
              List getBeans()
              and let the kernel takeover to resolve dependencies,
              construct containers and do all the other goodness in the correct order.

              • 4. Re: Convenience or use case configurations
                Dimitris Andreadis Master

                So, we should have each deployer defining its own AbstractKernelDeployment subclass that programmatically generates the full deployment metadata from a simplified "description".

                I'm not sure if I understand the last part. Do you mean for example, how to use many of those AbstractKernelDeployment subclasses in order to produce deployment metadata from a combined larger xml definition, that may contain information for different deployers?

                • 5. Re: Convenience or use case configurations
                  Adrian Brock Master

                  That is one way to implement it.

                  It does have the advantage the deployers become simple and it would be easier
                  for other deployers to pluck out the parts they want to work on.

                  e.g. A hypothetical deployer that wants to post process all EJB containers
                  can do it more easily if it is looking for "metadata instanceof EJBDeployment" rather than a
                  BeanMetaData with an open ended set of possibities like
                  bean="StatelessContainer" or bean="CMPContainer"

                  I don't understsand your second question.

                  • 6. Re: Convenience or use case configurations
                    Adrian Brock Master

                    The downside is that (in the hypothetical example) you can only override config
                    exposed by EJBDeployment whereas the plain BeanMetaData configs expose
                    everything for configuration.

                    But this could be worked around by allowing an "advanced config option"
                    List beans = EJBDeployment.getBeans();
                    //process beans to add config;
                    EJBDeployment.setBeans(beans);

                    Although that is probably too simplistic to scale across multiple separation of concerns
                    and would be brittle to internal changes within the EJB metadata model.

                    • 7. Re: Convenience or use case configurations
                      Scott Stark Master

                      Clarify what you mean by the "advanced config option" here please:

                      But this could be worked around by allowing an "advanced config option"
                      List beans = EJBDeployment.getBeans();
                      //process beans to add config;
                      EJBDeployment.setBeans(beans);
                      


                      This convenience config topic is too wide open to grok effectively because its mixing several different layers. Its a variation of the *-ds.xml vs the underlying jboss-service.xml mbeans for the datasource layer, and as such its really intersecting with the admin ui layer. Turing around and discussing how this impacts the type interfaces showing up at the object based kernel metamodel is making a huge leap without any usecases to justify it.

                      Due to the historical tight coupling of xml configuration views with xml parsing showing up in the codebase, I want to be clear that when we discuss configuration using xml fragments that this implies the existence of a jbossxb layer which is handling the actual xml to object transformation. As such, a convience configuration further impiles another layer on top of the jbossxb layer. The layer could just be an xml transformation to the full schema, or it could be another namespace that maps to jbossxb factories that extend the full schema factories.


                      • 8. Re: Convenience or use case configurations
                        Adrian Brock Master

                        I was thinking out load about the advanced configuration.

                        Let me be clear that when I post xml fragments, I am not thinking that these
                        should be just xml. In fact, the use of xslt is not what I want.

                        Everything that is xml should be directly backed by a javabean (the xml parser
                        just does a direct translation).

                        The pseudo xml representation I am using in these posts is just easier to get the ideas
                        across than posting javabean code.

                        The idea is the same as the -ds.xml but it is done in code not xslt.