Classloading

[adrian.brock]

[qoute="[e-mail]"]
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.

[adrian.brock]

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.

[adrian.brock]

This task is related:
http://jira.jboss.com/jira/browse/JBMICROCONT-7

[dimitris]

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.

[starksm64]

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.

[starksm64]

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".

[adrian.brock]

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.