On Apr 7, 2009, at 1:46 AM, Gianny Damour wrote:
On 07/04/2009, at 4:00 AM, David Jencks wrote:
There are two things that worry me about this.
1. IIUC whenever you include a jar in a configuration all the
configuration's parents get added as parents to the jar's global
classloader, in this code in MultiParentClassLoader2:
protected void addParents(Set<GlobalClassLoader>
globalClassLoaders) {
for (GlobalClassLoader globalClassLoader :
globalClassLoaders) {
for (ClassLoader parent : parents) {
globalClassLoader.addParent(parent);
}
}
}
I don't think this is acceptable. I think that once we have a
GlobalClassloader set up for a jar it needs to be immutable. With
your code which jar a class is loaded from could depend on which
configurations are started when you try to load the class.
I agree and this was one of my concerns; though it can be addressed.
The problem is that the dependencies defined by a given config may
not be complete.
Let's assume:
* config A imports dependency D1, D4;
* config B imports dependency D2 and D3;
* config B is a child of config A; and
* D1 and D3 are declared as maven dependencies for D2.
The current implementation builds a partial tree of
GlobalClassLoaders based on the dependencies defined by a given
config. This means that in the above scenario when config B is
started only GlobalClassLoaders for D2 and D3 are put at the right
place according to their maven dependencies, i.e. D3 is a parent of
D2. D1 is artificially put as a parent of D2 by adding config A's
classloader to D2.
A better implementation would be to add the relevant
GlobalClassLoaders defined by parent configurations, in our example
D1, to the GlobalClassLoaders used by a given config, in our example
D2.
I can fix this problem.
I'm sure I haven't thought this through completely but I really
wonder if adding parents to the global classloaders is necessary.
If we ignore geronimo plugins based on javaee apps for a moment,
geronimo plugins won't have any classes in them, and jars will have
maven dependencies on the appropriate other jars anyway. So I
think that in the normal case adding these parents won't add any
missing classes. Constructing a classloader for a javaee app that
can be used as a parent of some other classloader is a geronimo
specific feature anyway not supported by maven so I think it would
be OK to just have people include such dependencies in the
<baseURL>-additional.xml (or the pom, possibly).
If we drop this add-parents behavior we might need to add
classloading rules to the global classloaders and either specify it
directly or push it down from a plugin config. Again I haven't
thought this through.
I think that classloading rules are only going to be useful to
isolate javaee apps. I think this is going to be OK as classloading
rules were introduced to better isolate javaee apps from their
runtime container.
2. IIUC the <baseURL>-additional.xml only lets you add to the maven
pom. I think we need to be able to delete stuff too.
I can add this functionality.
Assuming that the above is fixed by mid-next week, do you think that
current classloading problems would be resolved? Or do you think
that re-platforming to an OSGi approach will provide a better mileage?
I'm being led into more extensive changes, I hope to have something
working tomorrow or the next day. I think this will be a good and
illuminating step towards osgi and that most likely releasing 2.2 with
this system will be a good idea before attempting more extensive osgi
integration.
thanks
david jencks
Thanks,
Gianny
As a probably easy-to-fix bug I think that we currently decide if
something is a jar or a plugin in MavenDependencyResolver by
whether there is exactly one URL for the artifact. However a
geronimo plugin with classes inside -- say an ejb jar -- could have
exactly one url but not be a jar.
These are just my first impressions, I'll keep looking.
thanks!
david jencks
