Configurations & Class loading

[Gianny Damour <gi...@optusnet.com.au>]

Hi,

I have just added a new attribute and two new elements to each type of 
configurations, which give us more control on class loading:
* the inverseClassloading attribute can be used to inverse the standard 
class loading delegation model. This means that class loading requests 
are first delegated to this configuration and then to its parents;
* the hidden-classes elements can be used to define classes, which 
should be hidden from the configuration.
For instance:
    <hidden-classes>
        <filter>org.apache.commons.logging</filter>
    </hidden-classes>
hides commons-logging from a configuration.
* the non-overridable-classes elements can be used to define classes, 
which should not be redefined by a configuration reversing the 
delegation model. A configuration inherits the non-overridable filters 
of its parents.

I think that this is the short term solution that Dain was talking about 
to prevent problems while running applications using some Geronimo 
dependencies.

Also, it seems that the cl architecture does not support this scenario: 
an EAR defines an EJB and RAR modules; the EJB module defines and uses 
class A v1; the RAR module defines and uses class A v2. As A v1 and A v2 
are added to the same configuration, the first version being added hides 
the over one. As this type of modules are rather weird, it may not be so 
important to support them at this stage.

Thanks,
Gianny