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
