On 08/04/2009, at 5:10 PM, David Jencks wrote:
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.
Based on this fact, it appears to me as useless to continue further
down the road I explored.
I do still believe that simplifying the configuration model is more
important than OSGi integration. Making IoC simpler (e.g. no need to
declare or annotate injected attributes or references), more flexible
(e.g. use of service factory) and to the point (i.e. less verbose) is
hopefully part of the extensive changes. Re-using Apache Felix iPOJO
would be good.
Thanks,
Gianny
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
