On Wed, Mar 11, 2009 at 3:30 PM, David Jencks <david_jen...@yahoo.com> wrote: >> >> Right but that's an important problem which we run into all the time >> in Geronimo (same jar loaded by two different classloaders). And the >> solution to this problem is to create another >> configuration/classloader and make that the parent of the two. This is >> a pretty 'static' solution while osgi offers 'dynamic' solution where >> it figures out at runtime which packages to wire together. So >> Geronimo's and osgi's classloading models might be equivalent ONLY IF >> we support classloader-per-jar model. Hiding classes/packages in a >> classloader is not enough. > > Our classloading system does support classloader-per-jar right now, but we > haven't set up enough classloaders to act that way, and I'm hoping that osgi > will provide the same features with less work.
Right, no argument there. > From a conceptual point of > view I don't see why osgi would be any more or less dynamic than geronimo. > The classes are coming out of some versioned jar and IMNSHO you are > unlikely to want to allow the resolution method to pick anything other than > the version of the jar for you. If you leave out the version in the > dependency geronimo will pick one for you... I'm not sure what the > equivalent osgi configuration would be. The point I was trying to make is that with Geronimo the classloader hierarchy is pretty much created/setup at build time while in osgi if you are using Import-Package is at runtime. Here's an example. Say, we have configuration A that has dependency on configuration B and C. Both B and C have dependency on commons-logging.jar. In Geronimo it would be very likely that you would run into ClassCastExceptions with such configuration. And the only way to fix it, it would be to create a new configuration D that would have the dependency on commons-logging.jar and B and C configurations would have to be updated to have dependency on D. In osgi world, bundle B and C would define a Import-Package on the commons-logging package and the osgi system at runtime would figure out that B and C must be wired to the same bundle that provides the commons-logging library. So classloader-per-jar is important and so is the runtime dependency resolution to make sure that the same library is not loaded from two different classloaders within the hierarchy. <random thoughts> Hmm... I'm not sure what would happen if B and C used Require-Bundle and specify two different bundle names for libraries that provide the commons-logging library. Would we would see ClassCastExceptions (same as in Geronimo right now) or would osgi just pick one of these bundles as the default? Hmm... in Geronimo with artifact substitutions can we substitute jar for car or car for jar? </random thoughts> > Basically it seems to me that osgi has the same problem as geronimo here, > that you have to include some really intrusive metadata in every jar to > specify the classloading behavior. Osgi has merely brainwashed everyone > into thinking that its metadata is desirable since its part of the manifest > whereas geronimo has some weird binary goo that no one is familiar with. > Maven does the same thing, packing the pom into every jar it builds (plus > supplying it alongside in the repository) > > So, everyone has the same problem -- you need a bunch of classloader > metadata associated with the artifacts you want to use -- and pretty much > agrees on the content, although each solution emphasizes different things. > IMO no one has a good solution yet. For instance AFAICT the felix bundle > maven plugin is typically used to effectively convert the maven artifact > dependencies to equivalent package import/export specifications. Yep, I agree. Jarek
