6 Replies Latest reply on Jan 25, 2005 1:49 PM by Adrian Brock

    Classloading

    Adrian Brock Master

      [qoute="scott@jboss.org"]
      I want to revisit our class loading in the new pojo server and at least have a more standard
      parent/child option to address some issues that client are expressing. Is the new server
      to a point of being able to look at this in the context of the new deployers? If not I want to
      work with whoever is working on the deployers to get this moving.

        • 1. Re: Classloading
          Adrian Brock Master

          Dimitris is working on the deployers.

          I'd like to see the classloaders constructed like other beans:

          e.g. in pseudo xml

          <bean name="MyClassLoadingDomain" bean="ClassLoadingDomain">
           <attribute name="Java2ClassLoadingCompliance">false</attribute>
          </bean>
          
          <bean bean="URLClassLoader">
           <reverse-dependency name="MyClassLoadingDomain"
           add="addClassLoader(ClassLoader)"
           remove="removeClassLoader(ClassLoader)"/>
           <constructor>
           <parameters>
           <parameter type="java.net.URL">whatever</parameter>
           </parameters>
           </constructor>
          </bean>
          

          If this is too verbose, it is possible to write a convenience
          mechanism for specific configuration use cases.
          <cldomain name="MyClassLoadingDomain
          java2ClassLoadingCompliance="false"/>
          
          <urlclassloader domain="MyClassLoadingDomain" url="whatever"/>
          

          I've not articulated the idea of "convenience configurations" yet
          (except in passing on one forums post),
          but they basically involve subclassing the bean metadata to
          "hardwire" some of the configuration attributes, providing
          simpler configuration for known use cases.
          They will also be useful for writing deployers where we are mapping
          one metadata model to the jboss microcontainer native model.


          • 3. Re: Classloading
            Dimitris Andreadis Master

            This is related also (look at the 3rd post):

            http://www.jboss.org/index.html?module=bb&op=viewtopic&t=58404

            Basically, I reached a point where I need to create the classloader for a deployment. The existing code creates a UCL for the base node, and adds subdeployment URLs to this.

            This is all JMX related, so at this point I think I'll just create a URLClassLoader there.

            All the related code is under system2/src/main/org/jboss/deployers (jboss-pojo/system).

            In my setup I have jboss running with 2 MainDeployers to test this, but I still need to make some standalone unit tests.

            • 4. Re: Classloading
              Scott Stark Master

              There needs to be a class loader factory to abstract out the details. Just creating a URLClassLoader for every subdeployment will result in overly isolated deployments that will not be able to do call by reference across jars unless the archive is perfectly formed in terms of parent/child relationships. This is never achieved in practise.

              In general I want to move away from URLClassLoader and the deployment packaging defining the classpath as the tight coupling between urls and the class type system really is a huge inflexible pain.

              • 5. Re: Classloading
                Scott Stark Master

                 

                I'd like to see the classloaders constructed like other beans:...


                It might be possible to support this level of configuration, but in general there needs to be an abreviated form that builds the class loader hierarchy based on some associated model (current flat repository model, hiearchical repository model, standard parent child model, ...) since as we know, users having to deal with the type system/ packaging/redeployment/class loader interaction details is not one of the favorite jboss user expierences. I'm expecting that this is what is encapsulated in the "convenience configurations".

                • 6. Re: Classloading
                  Adrian Brock Master

                  Yes, you can give them configuration use cases like "UnifiedClassLoader"
                  or "Java2Delegation" where the model is not exposed (it is hardwired in the use case).

                  But I would still like the full power to write my own classloading use case,
                  e.g. the osgi model

                  <osgi-classloader url="whatever">
                   <imported-packages>....</imported-packages>
                   <exported-packages>....</exported-packages>
                  </osgi-classloader>
                  

                  or something else.