On Mar 24, 2010, at 5:30 PM, David Jencks wrote: > > While I always thought shared lib was a bad idea, at least pre-osgi the > concept of a classloader that you could just toss things in made sense. I > don't think it makes any sense in osgi. There is no dynamic-export header so > whatever implementation you came up with would have to know exactly what > packages to export... making the idea of adding more stuff to it useless. If > you just make sure your jar is bundleized so the packages you want to use are > exported, and install the bundle in the osgi framework, the osgi wiring > mechanism will take care of making it available to your app, in a simpler, > uniform way that is much more flexible than shared lib was. > > In other words, plain vanilla osgi all by itself does what shared lib was for > much much better. The only inconvenience is that you have to make your > libraries into bundles somehow. We can certainly talk about how to help > people do that, but that will be generally useful and/or impossible to do > well.
Understood. And I'm not claiming that we'd end up with the same runtime efficiencies of a common shared lib ClassLoader, in previous versions of Geronimo. However, we're processing WARs and EARs with packaged jar files. And we'd better be pretty good at that. And we're certainly not going to require users to convert these jars into bundles. So, is extending this capability to a sharedlib dirctory (outside of the archive) such a big stretch? It might not be as runtime efficient as it could be, but a class of users might well appreciate its simplicity. We also want to be making it easy for users to bundleize jars and incorporate them into Geronimo. However, I'm not convinced that users should always be required to bundlize their jars... --kevan
