On Apr 8, 2009, at 6:09 AM, Gianny Damour wrote:
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.
At this point I regard the configuration model as a bit orthogonal to
the classloader model. I think that getting the one-cl-per-jar to
work is a really good idea. For the configuration model I'm not sure
if it makes more sense to extend ours or implement the osgi blueprint
service.
Anyway I took the approach of generating classloader metadata from
poms and including it in the geronimo-plugin.xml for plugins. I got
the framework server to start with this and just checked in the result
in my sandbox. I expect to look at the rest of the server next....
I'm sure there are lots of bugs left.
I've been wondering how we'll assemble servers if we are using osgi.
AFAICT osgi doesn't really try to address the question of deciding
which allegedly equivalent implementations of particular classes
should actually get used, something that maven spends much of its
efforts on. I think that as a first step we should continue
generating and using the geronimo-plugin.xml metadata even though in
an osgi environment it will be much less directly related to the
geronimo classloading structure.
thanks
david jencks
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
