Re: Whence the geronimo kernel?
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(SetGlobalClassLoader
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
Re: Whence the geronimo kernel?
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(SetGlobalClassLoader
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
Re: Whence the geronimo kernel?
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(SetGlobalClassLoader
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
Re: Whence the geronimo kernel?
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(SetGlobalClassLoader
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?
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
Re: Whence the geronimo kernel?
Hi Gianny,
On Mar 17, 2009, at 4:24 AM, Gianny Damour wrote:
On 13/03/2009, at 6:44 PM, David Jencks wrote:
On Mar 12, 2009, at 10:02 AM, David Jencks wrote:
On Mar 12, 2009, at 3:25 AM, Gianny Damour wrote:
On 12/03/2009, at 4:29 AM, David Jencks wrote:
I think I probably have the most experience with classloading
problems in geronimo and the only real problem that arises is
loading a jar in two different classloaders. This can be
solved by a classloader-per-jar model which offers no
theoretical problems to set up in geronimo but practically would
take a lot of work (and maven projects to build a plugin per
jar). So I think we'll have to see what kind of problems we get
with trying to actually use OSGI.
Hi,
Thinking more about this, I believe we can expedite the
implementation of a classloader-per-jar model. Under the hood of
a MultiParentClassLoader we can replace the current
implementation of find class and resources contracts by an
implementation which delegates to a bunch of URLClassLoaders (one
per jar). These bunch of URLClassLoaders are global classloaders,
i.e. shared across all the configs/MultiParentClassLoaders. The
core challenge is to create them in a hierarchy respecting the
maven dependency declarations. So, we could install the pom of
the dependencies in the repo and lazily parse them when
MultiParentClassLoader are created to build this global and share
tree of URLClassLoaders.
IMO the danger here is that the maven pom may not exist or may be
wrong. OSGI has the same problem in that the vast majority of
released jars don't have osgi manifests. I think I saw a rumor
that spring spent a lot of effort osgi-ifying a lot of commonly
used jars to try to solve this problem.
I also don't know if there are situations in which a small number
of closely related jars need to be loaded in a single classloader,
perhaps because one of the jars is optional but if present the
main jar needs access to its classes. I think there was an osgi
feature that looked sort of like this.
I just started to work on it and I will post back my findings (i
should be able to complete this over the week-end). Even if we
switch to an OSGi kernel, part of this work may hopefully still
be useful.
Unless you are pretty sure we won't have the kind of problems with
bad community metadata suggested above it might be a good idea to
do this in a sandbox branch?
Thinking about this more I really expect the code will be easy
compared to straightening out the dependencies :-(
As a concrete example, the JACC spec needs the servlet and ejb
specs but in our maven poms we've excluded them as dependencies so
as to make it easier to upgrade the jars independently. While
(especially with maven 3) we can probably put in the dependencies
with version ranges, they aren't there now. Getting the server to
work again may be time consuming. I really hope I'm wrong :-D
Hi David,
I just created a patch
http://issues.apache.org/jira/browse/GERONIMO-4590
which provides a preview of the code changes necessary to move to a
one classloader per jar model. It is not yet good enough to create a
branch as only 22 configurations out of the 27 of the jetty-jee5
assemblies can successfully start (failing config is certainly a
maven dependency problem).
The design is rather simple:
1. when a configuraton classloader is created, configuration
dependencies and classPath entries are used to generate a bunch of
GlobalClassLoaders - one per dependency or one for all the classPath
entries.
2. this set of GlobalClassLoaders are put in a hierarchy according
to maven dependency declarations (note that dependency version
declarations are not honored even if present). Maven dependency
declarations can be augmented by dropping an XML file with maven
like dependencies declarations.
3. the classloaders of the parent configuration of the configuration
being created are added to this set of GlobalClassLoaders.
4. this set of GlobalClassLoaders is used under the hood of the
configuration's MultiParentClassLoader to implement find class and
resources contracts.
Four maven dependency declarations had to be supplemented to start
22 configurations. Assuming the same ratio, about 14 dependency
declarations may have to be supplemented to start the jetty-jee5
assembly. This is not too involving.
Could you please have a cursory review of this preview patch and let
me know your thoughts?
I finally got some more time to look at this -- thanks for applying it
to my sandbox framework branch.
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(SetGlobalClassLoader
globalClassLoaders) {
for
Re: Whence the geronimo kernel?
Hi Rex, I'm not Lin, but I thought I'd just add a few thoughts/comments. Split packages are sometimes forced upon us. For example, the transactions APIs are partially provided by the JDK. This might be a case for using Require-Bundle, but then there are also other techniques to avoid resolving to these partial packages, like using mandatory attributes (i.e. provide a complete package exported with a mandatory attribute and then express your dependency on that). Other cases where Require-Bundle can cause problems is when there are multiple importers/exporters for the same packages. This can occur for example with spec APIs which are sometimes provided separately and sometimes packaged with an implementation. The best solution here is to design for substitutability. Exporters of the package should also import the package so they all resolve to the same provider (I believe substitutability is the default that the BND tool will generate). Doing so helps avoid class cast exceptions because the bundles will all use the same classloader to provide the classes, irrespective of the order in which they were installed. Require-Bundle, however would not allow this behavior because we would only express the requirement on the bundle which happens to provide the packages. We cannot therefore be flexible in the choice of provider of the packages. I just wanted to provide an analogy for Require-Bundle. I liken it to a toolbox (bundle) which contains some tools (packages). If I have a job I need to do, I know which tools I need so I pick up my toolbox and take it to the place where I need to do the job. I've lost track of the number of times I've done that and found one of my tools is missing. OK, so I should be more careful with my tools, but sometimes the things we depend on aren't provided by us. If they get refactored, it's more difficult to track down the issues when they're hidden behind an opaque Require-Bundle. A comment regarding Eclipse, when you're working in an extension-point/extension world, the person providing the extension point is in control (dictates what the service should look like). In this scenario there is only likely to be one provider of the thing you depend upon and therefore the problem is much more constrained. In a services world it is much more egalitarian and you have to start catering for multiple providers and refactoring. It might be worth taking a look at what Apache Tuscany has done in this area. They are in the process of bundlizing their runtime consisting of something like 80 Tuscany provided bundles and 160 third-party dependencies. Luciano Resende presented on some of the early work at ApacheCon US last year (see http://tinyurl.com/c6rm5z ) I hope this helps. Regards, Graham. 2009/3/18 Rex Wang rwo...@gmail.com: Thanks Lin, I know the Issues with reqriring bundle(3.13.3 of spec 4.1), and the main opposite point from the blog I think is just because of the refactor. I just want to make clear that, is there any situation we might meet the split packages or refactor a bundle frequently? At least, my eclipse 3.4's plugins always prefer to use require-bundle and seems no problem with that.. I am not saying that I am a funs of require-bundle, but I really hope the MF and geronimo-plugin.xml(for a single bundle) not have a relationship like the JEE app's deployment descriptor and geronimo deployment plan... Rex. 2009/3/17 Lin Sun linsun@gmail.com Rex, If you follow the discussion closely, I think David was just saying that he prefers to stay away from Require-Bundle for now, as the OSGi specification doesn't recommend people to use it, along with the probs people mentioned about it in the link I posted earlier. I also found these links interesting - http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html http://ekkes-corner.blogspot.com/2008/06/catch-22-logging-with-osgi-frameworks.html David, Some comments regarding #2, its essential to know what jars/bundles/plugins/modules are actually in your running system. I think OSGi framework provides the ability to display the currently running bundles, so there should be APIs to get that. For example, you type ss in equinox console to get the list of installed bundles: osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.2.R34x_v20080826-1230 14 ACTIVE org.osgi.impl.service.log_1.3.2.200902181055 17 RESOLVED org.osgi.impl.service.http_4.2.0.200902181209 18 INSTALLED org.osgi.test.cases.http_4.2.0.200902181210 OSGi framework also uses resolver to resolve bundles. For example, if I want to install Bundle A to the framework, and Bundle imports package AA, then when I install the bundle A, the OSGi framework uses the resolver to find out if there is any bundle that exports package AA. If so, bundle A will be marked as RESOLVED. Otherwise, Bundle A will be marked as INSTALLED. If you
Re: Whence the geronimo kernel?
Guillaume Nodet wrote: For those that are not aware of ServiceMix Kernel (I know David is), i'd like to point them to it. Feel free to download it and give it a try. It's based on felix, gshell and a few other bundles. We're using it to deploy our JBI container in ServiceMix 4 (including the geronimo transaction manager, activemq, jetty, but those are not included in the kernel). See http://servicemix.apache.org/kernel/index.html To add to this discussion, we are deploying stuff on servicemix using features, which is imho the metdata related to (2). A feature is mostly a list of OSGi bundles with some dependencies on other features and some optional configuration. We are almost using Import-Packages exclusively, using spring-dm to configure most of our services ... There are other features of the OSGi framework that we might want to mix into discussion: 1) The config-admin service. This is an OSGi-managed persistent configuration service. The blueprint service spec includes interactions with the cm service to allow configuration properties to be injected into created components. This is a bit like what happens with the geronimo config substitutions today. 2) Lazy activation. Lazy activation allows a bundle to be started, but sit in an idle state. On the first classload operation, the bundle will go through the complete activation process. The Blueprint service add additional support that allows services exported by the bundle to be registered as available, but the service does not get created until the first service request. This could allow some interesting delay provisioning of subsystems to be implemented. Rick 2009/3/17 Lin Sun linsun@gmail.com mailto:linsun@gmail.com Rex, If you follow the discussion closely, I think David was just saying that he prefers to stay away from Require-Bundle for now, as the OSGi specification doesn't recommend people to use it, along with the probs people mentioned about it in the link I posted earlier. I also found these links interesting - http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html http://ekkes-corner.blogspot.com/2008/06/catch-22-logging-with-osgi-frameworks.html David, Some comments regarding #2, its essential to know what jars/bundles/plugins/modules are actually in your running system. I think OSGi framework provides the ability to display the currently running bundles, so there should be APIs to get that. For example, you type ss in equinox console to get the list of installed bundles: osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.2.R34x_v20080826-1230 14 ACTIVE org.osgi.impl.service.log_1.3.2.200902181055 17 RESOLVEDorg.osgi.impl.service.http_4.2.0.200902181209 18 INSTALLED org.osgi.test.cases.http_4.2.0.200902181210 OSGi framework also uses resolver to resolve bundles. For example, if I want to install Bundle A to the framework, and Bundle imports package AA, then when I install the bundle A, the OSGi framework uses the resolver to find out if there is any bundle that exports package AA. If so, bundle A will be marked as RESOLVED. Otherwise, Bundle A will be marked as INSTALLED. If you search resolver in the OSGi core spec, you'll see a couple of places that mention it. I recently took a look at the new OSGi bundle repository spec (RFC 112). It talks about the concept of Resolver and the interface Resolver It talks about scenarios where a user wants to install a bundle (that uses Import-Package), the server should be able to pull all its dependencies from the bundle repository (or repositories) on the fly using the resolver. This seems something we would need for geronimo. Lin On Tue, Mar 17, 2009 at 12:52 AM, Rex Wang rwo...@gmail.com mailto:rwo...@gmail.com wrote: At the moment I'm inclined to think that require-bundle is not a workable solution for (2) and so we might as well use import-package plus an osgi runtime that uses and requires explicit external dependency information such as provided by maven or geronimo-plugin.xml to choose what bundle to resolve to. From my point of view, I am not quite like this mix version, because we must maintain the related information in two different places, that will absolutely increase geronimo's complexity and some sorts of confusing on the dependency settings, not only to the developers but also the users. I think one of the purpose that we adopt OSGi is to make our server infrastructure standardize to the OSGi specification, but not to create a new application model. Because this may lead to a non osgi compatiable bundle, IIUC, any bundle that wanna be used in geronimo must
Re: Whence the geronimo kernel?
On 13/03/2009, at 6:44 PM, David Jencks wrote: On Mar 12, 2009, at 10:02 AM, David Jencks wrote: On Mar 12, 2009, at 3:25 AM, Gianny Damour wrote: On 12/03/2009, at 4:29 AM, David Jencks wrote: I think I probably have the most experience with classloading problems in geronimo and the only real problem that arises is loading a jar in two different classloaders. This can be solved by a classloader-per-jar model which offers no theoretical problems to set up in geronimo but practically would take a lot of work (and maven projects to build a plugin per jar). So I think we'll have to see what kind of problems we get with trying to actually use OSGI. Hi, Thinking more about this, I believe we can expedite the implementation of a classloader-per-jar model. Under the hood of a MultiParentClassLoader we can replace the current implementation of find class and resources contracts by an implementation which delegates to a bunch of URLClassLoaders (one per jar). These bunch of URLClassLoaders are global classloaders, i.e. shared across all the configs/MultiParentClassLoaders. The core challenge is to create them in a hierarchy respecting the maven dependency declarations. So, we could install the pom of the dependencies in the repo and lazily parse them when MultiParentClassLoader are created to build this global and share tree of URLClassLoaders. IMO the danger here is that the maven pom may not exist or may be wrong. OSGI has the same problem in that the vast majority of released jars don't have osgi manifests. I think I saw a rumor that spring spent a lot of effort osgi-ifying a lot of commonly used jars to try to solve this problem. I also don't know if there are situations in which a small number of closely related jars need to be loaded in a single classloader, perhaps because one of the jars is optional but if present the main jar needs access to its classes. I think there was an osgi feature that looked sort of like this. I just started to work on it and I will post back my findings (i should be able to complete this over the week-end). Even if we switch to an OSGi kernel, part of this work may hopefully still be useful. Unless you are pretty sure we won't have the kind of problems with bad community metadata suggested above it might be a good idea to do this in a sandbox branch? Thinking about this more I really expect the code will be easy compared to straightening out the dependencies :-( As a concrete example, the JACC spec needs the servlet and ejb specs but in our maven poms we've excluded them as dependencies so as to make it easier to upgrade the jars independently. While (especially with maven 3) we can probably put in the dependencies with version ranges, they aren't there now. Getting the server to work again may be time consuming. I really hope I'm wrong :-D Hi David, I just created a patch http://issues.apache.org/jira/browse/GERONIMO-4590 which provides a preview of the code changes necessary to move to a one classloader per jar model. It is not yet good enough to create a branch as only 22 configurations out of the 27 of the jetty-jee5 assemblies can successfully start (failing config is certainly a maven dependency problem). The design is rather simple: 1. when a configuraton classloader is created, configuration dependencies and classPath entries are used to generate a bunch of GlobalClassLoaders - one per dependency or one for all the classPath entries. 2. this set of GlobalClassLoaders are put in a hierarchy according to maven dependency declarations (note that dependency version declarations are not honored even if present). Maven dependency declarations can be augmented by dropping an XML file with maven like dependencies declarations. 3. the classloaders of the parent configuration of the configuration being created are added to this set of GlobalClassLoaders. 4. this set of GlobalClassLoaders is used under the hood of the configuration's MultiParentClassLoader to implement find class and resources contracts. Four maven dependency declarations had to be supplemented to start 22 configurations. Assuming the same ratio, about 14 dependency declarations may have to be supplemented to start the jetty-jee5 assembly. This is not too involving. Could you please have a cursory review of this preview patch and let me know your thoughts? Thanks, Gianny thanks david jencks thanks david jencks Thanks, Gianny One thing I'd really like actual user data on is how people actually specify osgi classloading info in real life. I'm very aware that in theory you are supposed to specify the package imports and exports for your bundle but I've been told that in real life everyone with a serious osgi project actually specifies the jar dependencies they want using require-bundle. thanks david jencks Thanks, Gianny On
Re: Whence the geronimo kernel?
Rex, If you follow the discussion closely, I think David was just saying that he prefers to stay away from Require-Bundle for now, as the OSGi specification doesn't recommend people to use it, along with the probs people mentioned about it in the link I posted earlier. I also found these links interesting - http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html http://ekkes-corner.blogspot.com/2008/06/catch-22-logging-with-osgi-frameworks.html David, Some comments regarding #2, its essential to know what jars/bundles/plugins/modules are actually in your running system. I think OSGi framework provides the ability to display the currently running bundles, so there should be APIs to get that. For example, you type ss in equinox console to get the list of installed bundles: osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.2.R34x_v20080826-1230 14 ACTIVE org.osgi.impl.service.log_1.3.2.200902181055 17 RESOLVEDorg.osgi.impl.service.http_4.2.0.200902181209 18 INSTALLED org.osgi.test.cases.http_4.2.0.200902181210 OSGi framework also uses resolver to resolve bundles. For example, if I want to install Bundle A to the framework, and Bundle imports package AA, then when I install the bundle A, the OSGi framework uses the resolver to find out if there is any bundle that exports package AA. If so, bundle A will be marked as RESOLVED. Otherwise, Bundle A will be marked as INSTALLED. If you search resolver in the OSGi core spec, you'll see a couple of places that mention it. I recently took a look at the new OSGi bundle repository spec (RFC 112). It talks about the concept of Resolver and the interface Resolver It talks about scenarios where a user wants to install a bundle (that uses Import-Package), the server should be able to pull all its dependencies from the bundle repository (or repositories) on the fly using the resolver. This seems something we would need for geronimo. Lin On Tue, Mar 17, 2009 at 12:52 AM, Rex Wang rwo...@gmail.com wrote: At the moment I'm inclined to think that require-bundle is not a workable solution for (2) and so we might as well use import-package plus an osgi runtime that uses and requires explicit external dependency information such as provided by maven or geronimo-plugin.xml to choose what bundle to resolve to. From my point of view, I am not quite like this mix version, because we must maintain the related information in two different places, that will absolutely increase geronimo's complexity and some sorts of confusing on the dependency settings, not only to the developers but also the users. I think one of the purpose that we adopt OSGi is to make our server infrastructure standardize to the OSGi specification, but not to create a new application model. Because this may lead to a non osgi compatiable bundle, IIUC, any bundle that wanna be used in geronimo must re-write to provide the additional mvn-style information. Why do you think the require-bundle is not a workable solution for (2) ? Rex. 2009/3/14 David Jencks david_jen...@yahoo.com On Mar 13, 2009, at 9:43 AM, Rick McGuire wrote: David Jencks wrote: I read the blog entry and discussion. The entire discussion is predicated on the idea that osgi is close to ideal as-is and we have no need to consider any other point of view. If you step back a bit I see two things clearly acknowledged by everyone: 1. its useful to be able to know what classes are needed to make a jar/bundle/plugin/module work and which classes are expected to be used elsewhere 2. its essential to know what jars/bundles/plugins/modules are actually in your running system In osgi-land, import-package and export-package supply (1), and require-bundle sort of helps with (2) but AFAICT right now doesn't support artifact aliasing In maven-land, the pom dependency tracking provides a pretty good solution for (2), including some support for overriding requirements through exclusions, but it's single-classloader model doesn't translate directly into an app server or osgi runtime In geronimo trunk we emphasize (2) and can actually assemble working servers using it, and have support for (1) (although its mostly backwards from osgi specifications) I'd say that in my (limited) experience osgi zealots typically think that (1) is essential and brush (2) under the carpet by working in constrained environments such as their eclipse workspace. I'd say that our experience with geronimo is that (1) is rarely needed if you have a working (2) (look at how many hidden-classes and non-overriable classes filters are in our poms -- none for the use of geronimo, and a few to make deploying applications that include the same jars as us work) The geronimo/maven approach to (2) is to include the dependency information with the artifact. I'm not sure what approach(es) osgi is considering -- OBR appears to
Re: Whence the geronimo kernel?
For those that are not aware of ServiceMix Kernel (I know David is), i'd like to point them to it. Feel free to download it and give it a try. It's based on felix, gshell and a few other bundles. We're using it to deploy our JBI container in ServiceMix 4 (including the geronimo transaction manager, activemq, jetty, but those are not included in the kernel). See http://servicemix.apache.org/kernel/index.html To add to this discussion, we are deploying stuff on servicemix using features, which is imho the metdata related to (2). A feature is mostly a list of OSGi bundles with some dependencies on other features and some optional configuration. We are almost using Import-Packages exclusively, using spring-dm to configure most of our services ... 2009/3/17 Lin Sun linsun@gmail.com Rex, If you follow the discussion closely, I think David was just saying that he prefers to stay away from Require-Bundle for now, as the OSGi specification doesn't recommend people to use it, along with the probs people mentioned about it in the link I posted earlier. I also found these links interesting - http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html http://ekkes-corner.blogspot.com/2008/06/catch-22-logging-with-osgi-frameworks.html David, Some comments regarding #2, its essential to know what jars/bundles/plugins/modules are actually in your running system. I think OSGi framework provides the ability to display the currently running bundles, so there should be APIs to get that. For example, you type ss in equinox console to get the list of installed bundles: osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.2.R34x_v20080826-1230 14 ACTIVE org.osgi.impl.service.log_1.3.2.200902181055 17 RESOLVEDorg.osgi.impl.service.http_4.2.0.200902181209 18 INSTALLED org.osgi.test.cases.http_4.2.0.200902181210 OSGi framework also uses resolver to resolve bundles. For example, if I want to install Bundle A to the framework, and Bundle imports package AA, then when I install the bundle A, the OSGi framework uses the resolver to find out if there is any bundle that exports package AA. If so, bundle A will be marked as RESOLVED. Otherwise, Bundle A will be marked as INSTALLED. If you search resolver in the OSGi core spec, you'll see a couple of places that mention it. I recently took a look at the new OSGi bundle repository spec (RFC 112). It talks about the concept of Resolver and the interface Resolver It talks about scenarios where a user wants to install a bundle (that uses Import-Package), the server should be able to pull all its dependencies from the bundle repository (or repositories) on the fly using the resolver. This seems something we would need for geronimo. Lin On Tue, Mar 17, 2009 at 12:52 AM, Rex Wang rwo...@gmail.com wrote: At the moment I'm inclined to think that require-bundle is not a workable solution for (2) and so we might as well use import-package plus an osgi runtime that uses and requires explicit external dependency information such as provided by maven or geronimo-plugin.xml to choose what bundle to resolve to. From my point of view, I am not quite like this mix version, because we must maintain the related information in two different places, that will absolutely increase geronimo's complexity and some sorts of confusing on the dependency settings, not only to the developers but also the users. I think one of the purpose that we adopt OSGi is to make our server infrastructure standardize to the OSGi specification, but not to create a new application model. Because this may lead to a non osgi compatiable bundle, IIUC, any bundle that wanna be used in geronimo must re-write to provide the additional mvn-style information. Why do you think the require-bundle is not a workable solution for (2) ? Rex. 2009/3/14 David Jencks david_jen...@yahoo.com On Mar 13, 2009, at 9:43 AM, Rick McGuire wrote: David Jencks wrote: I read the blog entry and discussion. The entire discussion is predicated on the idea that osgi is close to ideal as-is and we have no need to consider any other point of view. If you step back a bit I see two things clearly acknowledged by everyone: 1. its useful to be able to know what classes are needed to make a jar/bundle/plugin/module work and which classes are expected to be used elsewhere 2. its essential to know what jars/bundles/plugins/modules are actually in your running system In osgi-land, import-package and export-package supply (1), and require-bundle sort of helps with (2) but AFAICT right now doesn't support artifact aliasing In maven-land, the pom dependency tracking provides a pretty good solution for (2), including some support for overriding requirements through exclusions, but it's single-classloader model doesn't
Re: Whence the geronimo kernel?
Thanks Lin, I know the Issues with reqriring bundle(3.13.3 of spec 4.1), and the main opposite point from the blog I think is just because of the refactor. I just want to make clear that, is there any situation we might meet the split packages or refactor a bundle frequently? At least, my eclipse 3.4's plugins always prefer to use require-bundle and seems no problem with that.. I am not saying that I am a funs of require-bundle, but I really hope the MF and geronimo-plugin.xml(for a single bundle) not have a relationship like the JEE app's deployment descriptor and geronimo deployment plan... Rex. 2009/3/17 Lin Sun linsun@gmail.com Rex, If you follow the discussion closely, I think David was just saying that he prefers to stay away from Require-Bundle for now, as the OSGi specification doesn't recommend people to use it, along with the probs people mentioned about it in the link I posted earlier. I also found these links interesting - http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html http://ekkes-corner.blogspot.com/2008/06/catch-22-logging-with-osgi-frameworks.html David, Some comments regarding #2, its essential to know what jars/bundles/plugins/modules are actually in your running system. I think OSGi framework provides the ability to display the currently running bundles, so there should be APIs to get that. For example, you type ss in equinox console to get the list of installed bundles: osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.2.R34x_v20080826-1230 14 ACTIVE org.osgi.impl.service.log_1.3.2.200902181055 17 RESOLVEDorg.osgi.impl.service.http_4.2.0.200902181209 18 INSTALLED org.osgi.test.cases.http_4.2.0.200902181210 OSGi framework also uses resolver to resolve bundles. For example, if I want to install Bundle A to the framework, and Bundle imports package AA, then when I install the bundle A, the OSGi framework uses the resolver to find out if there is any bundle that exports package AA. If so, bundle A will be marked as RESOLVED. Otherwise, Bundle A will be marked as INSTALLED. If you search resolver in the OSGi core spec, you'll see a couple of places that mention it. I recently took a look at the new OSGi bundle repository spec (RFC 112). It talks about the concept of Resolver and the interface Resolver It talks about scenarios where a user wants to install a bundle (that uses Import-Package), the server should be able to pull all its dependencies from the bundle repository (or repositories) on the fly using the resolver. This seems something we would need for geronimo. Lin On Tue, Mar 17, 2009 at 12:52 AM, Rex Wang rwo...@gmail.com wrote: At the moment I'm inclined to think that require-bundle is not a workable solution for (2) and so we might as well use import-package plus an osgi runtime that uses and requires explicit external dependency information such as provided by maven or geronimo-plugin.xml to choose what bundle to resolve to. From my point of view, I am not quite like this mix version, because we must maintain the related information in two different places, that will absolutely increase geronimo's complexity and some sorts of confusing on the dependency settings, not only to the developers but also the users. I think one of the purpose that we adopt OSGi is to make our server infrastructure standardize to the OSGi specification, but not to create a new application model. Because this may lead to a non osgi compatiable bundle, IIUC, any bundle that wanna be used in geronimo must re-write to provide the additional mvn-style information. Why do you think the require-bundle is not a workable solution for (2) ? Rex. 2009/3/14 David Jencks david_jen...@yahoo.com On Mar 13, 2009, at 9:43 AM, Rick McGuire wrote: David Jencks wrote: I read the blog entry and discussion. The entire discussion is predicated on the idea that osgi is close to ideal as-is and we have no need to consider any other point of view. If you step back a bit I see two things clearly acknowledged by everyone: 1. its useful to be able to know what classes are needed to make a jar/bundle/plugin/module work and which classes are expected to be used elsewhere 2. its essential to know what jars/bundles/plugins/modules are actually in your running system In osgi-land, import-package and export-package supply (1), and require-bundle sort of helps with (2) but AFAICT right now doesn't support artifact aliasing In maven-land, the pom dependency tracking provides a pretty good solution for (2), including some support for overriding requirements through exclusions, but it's single-classloader model doesn't translate directly into an app server or osgi runtime In geronimo trunk we emphasize (2) and can actually assemble working servers using it, and
Re: Whence the geronimo kernel?
At the moment I'm inclined to think that require-bundle is not a workable solution for (2) and so we might as well use import-package plus an osgi runtime that uses and requires explicit external dependency information such as provided by maven or geronimo-plugin.xml to choose what bundle to resolve to. From my point of view, I am not quite like this mix version, because we must maintain the related information in two different places, that will absolutely increase geronimo's complexity and some sorts of confusing on the dependency settings, not only to the developers but also the users. I think one of the purpose that we adopt OSGi is to make our server infrastructure standardize to the OSGi specification, but not to create a new application model. Because this may lead to a non osgi compatiable bundle, IIUC, any bundle that wanna be used in geronimo must re-write to provide the additional mvn-style information. Why do you think the require-bundle is not a workable solution for (2) ? Rex. 2009/3/14 David Jencks david_jen...@yahoo.com On Mar 13, 2009, at 9:43 AM, Rick McGuire wrote: David Jencks wrote: I read the blog entry and discussion. The entire discussion is predicated on the idea that osgi is close to ideal as-is and we have no need to consider any other point of view. If you step back a bit I see two things clearly acknowledged by everyone: 1. its useful to be able to know what classes are needed to make a jar/bundle/plugin/module work and which classes are expected to be used elsewhere 2. its essential to know what jars/bundles/plugins/modules are actually in your running system In osgi-land, import-package and export-package supply (1), and require-bundle sort of helps with (2) but AFAICT right now doesn't support artifact aliasing In maven-land, the pom dependency tracking provides a pretty good solution for (2), including some support for overriding requirements through exclusions, but it's single-classloader model doesn't translate directly into an app server or osgi runtime In geronimo trunk we emphasize (2) and can actually assemble working servers using it, and have support for (1) (although its mostly backwards from osgi specifications) I'd say that in my (limited) experience osgi zealots typically think that (1) is essential and brush (2) under the carpet by working in constrained environments such as their eclipse workspace. I'd say that our experience with geronimo is that (1) is rarely needed if you have a working (2) (look at how many hidden-classes and non-overriable classes filters are in our poms -- none for the use of geronimo, and a few to make deploying applications that include the same jars as us work) The geronimo/maven approach to (2) is to include the dependency information with the artifact. I'm not sure what approach(es) osgi is considering -- OBR appears to not consider bundling dependency info with the artifact but to have a completely external specification. I don't know about p2 but since jason vanZyl seems to be looking at it I'd guess it is more maven friendly. If you don't bundle (2) with the artifacts then you need some kind of import-package to artifact map or resolution system. We sort of have some vestiges of this today: when you deploy a web app as a geronimo plugin (or export it from a server where it was deployed) it has picked up dependencies on jetty or tomcat based on which deployer you specified in the plugin project pom or which kind of server you deployed on. Another example is that the car-maven-plugin filters the view of the local maven repo so only the versions specified in the pom are visible to the geronimo server we run off the repo -- this allows you to build plugins for a 2.1.3 server even if you have 2.2-SNAPSHOT artifacts locally and some of the dependencies don't specify the version required. I don't know where the best balance for geronimo lies here. I certainly think claiming all we need is import-package is shortchanging most of our experience in producing geronimo as a working server. But on the other hand, I'd hate to have not using just Import-package as the starting point. Given how much it is assumed in the OSGi world, it would be best to assume its use and only step outside of that box once we've found the intractable problem that requires it. Starting outside of those limits means we're abandoning the things OSGi does straight off because their may be some places where the exception mechanisms are required. Aren't you exhibiting exactly the same attitude as the blog posters in saying the (2) is not really a problem we need to consider? Whereas all our work in getting geronimo to actually work has been focussed on solving (2). If we ditch our working system for (2) we won't have a server perhaps ever. In terms of assembling a server, without (2) the space of possible bundles to resolve to is the entire maven central repo. ( I
Re: Whence the geronimo kernel?
On Mar 12, 2009, at 10:02 AM, David Jencks wrote: On Mar 12, 2009, at 3:25 AM, Gianny Damour wrote: On 12/03/2009, at 4:29 AM, David Jencks wrote: On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote: Hi, So let's agree to disagree for now. This may be related to my personal way of comparing stuff which is pretty much limited to: 1. understand what the requirements are. 2. understand how the technologies support these requirements. I do not need all the bells and whistles that a technology offers to fulfill the requirements. Moreover comparing stuff based on technology differentiators not clearly linked to the requirements is pointless. 3. assess best way forward based on above scoring. Key steps are 1 and 2 where stuff offering all the bells and whistles may well be scored as good as other stuff (I clearly do not support over-bloated stuff...). Obviously, I am keen to be proven wrong and adjust accordingly. So far, I am still saying that the main challenge is to properly tune export/import of dependency declarations. For me, the technology is not the core issue and switching is not going to resolve problems. I agree. I doubt Guillaume has seen your additions to classloading in trunk which allow you to not export packages from a classloader. I haven't tried to prove it mathematically but I think that with this feature the classloading models for geronimo and osgi are equivalent in that you can express the same ability to access classes with either of them. Of course, the notation you use to express this and the specific information included in the configuration is different. I think I probably have the most experience with classloading problems in geronimo and the only real problem that arises is loading a jar in two different classloaders. This can be solved by a classloader-per-jar model which offers no theoretical problems to set up in geronimo but practically would take a lot of work (and maven projects to build a plugin per jar). So I think we'll have to see what kind of problems we get with trying to actually use OSGI. Hi, Thinking more about this, I believe we can expedite the implementation of a classloader-per-jar model. Under the hood of a MultiParentClassLoader we can replace the current implementation of find class and resources contracts by an implementation which delegates to a bunch of URLClassLoaders (one per jar). These bunch of URLClassLoaders are global classloaders, i.e. shared across all the configs/MultiParentClassLoaders. The core challenge is to create them in a hierarchy respecting the maven dependency declarations. So, we could install the pom of the dependencies in the repo and lazily parse them when MultiParentClassLoader are created to build this global and share tree of URLClassLoaders. IMO the danger here is that the maven pom may not exist or may be wrong. OSGI has the same problem in that the vast majority of released jars don't have osgi manifests. I think I saw a rumor that spring spent a lot of effort osgi-ifying a lot of commonly used jars to try to solve this problem. I also don't know if there are situations in which a small number of closely related jars need to be loaded in a single classloader, perhaps because one of the jars is optional but if present the main jar needs access to its classes. I think there was an osgi feature that looked sort of like this. I just started to work on it and I will post back my findings (i should be able to complete this over the week-end). Even if we switch to an OSGi kernel, part of this work may hopefully still be useful. Unless you are pretty sure we won't have the kind of problems with bad community metadata suggested above it might be a good idea to do this in a sandbox branch? Thinking about this more I really expect the code will be easy compared to straightening out the dependencies :-( As a concrete example, the JACC spec needs the servlet and ejb specs but in our maven poms we've excluded them as dependencies so as to make it easier to upgrade the jars independently. While (especially with maven 3) we can probably put in the dependencies with version ranges, they aren't there now. Getting the server to work again may be time consuming. I really hope I'm wrong :-D thanks david jencks thanks david jencks Thanks, Gianny One thing I'd really like actual user data on is how people actually specify osgi classloading info in real life. I'm very aware that in theory you are supposed to specify the package imports and exports for your bundle but I've been told that in real life everyone with a serious osgi project actually specifies the jar dependencies they want using require-bundle. thanks david jencks Thanks, Gianny On 11/03/2009, at 7:11 PM, Guillaume Nodet wrote: On Wed, Mar 11, 2009 at 08:57, Gianny Damour gianny.dam...@optusnet.com.au
Re: Whence the geronimo kernel?
I think I was not too clear below. I didn't mean to say that I am in favor of Require-Bundle because it is a lot harder to come up with the right Import-Package lists. What I meant was that the reason why a lot of people are using Require-Bundle like David mentioned in his early notes is probably because it is a lot easier to use. I personally had to spend quite some time to figure out the prob I mentioned earlier - I was developing a bundle that needs to import the javax.transaction package from the transaction in OSGi bundle, but two bundles have it (the basic OSGi J2SE and the transaction in OSGi bundle).I was able to resolve this using Import-Package with the specific version of javax.transaction package that I need. I just tried to switch to use Require-Bundle, that is to have my bundle to depend on the transaction in OSGi bundle as it contains the right version of the javax.transaction package I need, but my bundle is broken completely due to CDNFE. I don't think the Require-Bundle offers the fine grain control that I needed for my bundle and I am sure Geronimo would have a lot more complicated bundles than what I was developing. BTW, there's a good discussion here: http://thhal.blogspot.com/2008/02/dependencies-and-package-imports.html - in particular in the first comment from Neil Bartlett and the limitations of Require-Bundle documented in the OSGi v 4.1 core spec (section 3.13.3). Lin On Thu, Mar 12, 2009 at 11:40 PM, Lin Sun linsun@gmail.com wrote: Not sure about Require-Bundle. I personally has never used it and I never see it is being used in the OSGi repo. Require-Bundle may not offer the level of control that the Import-Package provides but it is probably a lot harder to come up with the right Import-Package lists. I think this scenario should work just fine if using Import-Package.
Re: Whence the geronimo kernel?
I read the blog entry and discussion. The entire discussion is predicated on the idea that osgi is close to ideal as-is and we have no need to consider any other point of view. If you step back a bit I see two things clearly acknowledged by everyone: 1. its useful to be able to know what classes are needed to make a jar/ bundle/plugin/module work and which classes are expected to be used elsewhere 2. its essential to know what jars/bundles/plugins/modules are actually in your running system In osgi-land, import-package and export-package supply (1), and require-bundle sort of helps with (2) but AFAICT right now doesn't support artifact aliasing In maven-land, the pom dependency tracking provides a pretty good solution for (2), including some support for overriding requirements through exclusions, but it's single-classloader model doesn't translate directly into an app server or osgi runtime In geronimo trunk we emphasize (2) and can actually assemble working servers using it, and have support for (1) (although its mostly backwards from osgi specifications) I'd say that in my (limited) experience osgi zealots typically think that (1) is essential and brush (2) under the carpet by working in constrained environments such as their eclipse workspace. I'd say that our experience with geronimo is that (1) is rarely needed if you have a working (2) (look at how many hidden-classes and non-overriable classes filters are in our poms -- none for the use of geronimo, and a few to make deploying applications that include the same jars as us work) The geronimo/maven approach to (2) is to include the dependency information with the artifact. I'm not sure what approach(es) osgi is considering -- OBR appears to not consider bundling dependency info with the artifact but to have a completely external specification. I don't know about p2 but since jason vanZyl seems to be looking at it I'd guess it is more maven friendly. If you don't bundle (2) with the artifacts then you need some kind of import-package to artifact map or resolution system. We sort of have some vestiges of this today: when you deploy a web app as a geronimo plugin (or export it from a server where it was deployed) it has picked up dependencies on jetty or tomcat based on which deployer you specified in the plugin project pom or which kind of server you deployed on. Another example is that the car-maven-plugin filters the view of the local maven repo so only the versions specified in the pom are visible to the geronimo server we run off the repo -- this allows you to build plugins for a 2.1.3 server even if you have 2.2-SNAPSHOT artifacts locally and some of the dependencies don't specify the version required. I don't know where the best balance for geronimo lies here. I certainly think claiming all we need is import-package is shortchanging most of our experience in producing geronimo as a working server. thanks david jencks On Mar 13, 2009, at 7:10 AM, Lin Sun wrote: I think I was not too clear below. I didn't mean to say that I am in favor of Require-Bundle because it is a lot harder to come up with the right Import-Package lists. What I meant was that the reason why a lot of people are using Require-Bundle like David mentioned in his early notes is probably because it is a lot easier to use. I personally had to spend quite some time to figure out the prob I mentioned earlier - I was developing a bundle that needs to import the javax.transaction package from the transaction in OSGi bundle, but two bundles have it (the basic OSGi J2SE and the transaction in OSGi bundle).I was able to resolve this using Import-Package with the specific version of javax.transaction package that I need. I just tried to switch to use Require-Bundle, that is to have my bundle to depend on the transaction in OSGi bundle as it contains the right version of the javax.transaction package I need, but my bundle is broken completely due to CDNFE. I don't think the Require-Bundle offers the fine grain control that I needed for my bundle and I am sure Geronimo would have a lot more complicated bundles than what I was developing. BTW, there's a good discussion here: http://thhal.blogspot.com/2008/02/dependencies-and-package- imports.html - in particular in the first comment from Neil Bartlett and the limitations of Require-Bundle documented in the OSGi v 4.1 core spec (section 3.13.3). Lin On Thu, Mar 12, 2009 at 11:40 PM, Lin Sun linsun@gmail.com wrote: Not sure about Require-Bundle. I personally has never used it and I never see it is being used in the OSGi repo. Require-Bundle may not offer the level of control that the Import-Package provides but it is probably a lot harder to come up with the right Import-Package lists. I think this scenario should work just fine if using Import-Package.
Re: Whence the geronimo kernel?
I certainly think claiming all we need is import-package is shortchanging most of our experience in producing geronimo as a working server. +1000 -- dims On Fri, Mar 13, 2009 at 12:27 PM, David Jencks david_jen...@yahoo.com wrote: I read the blog entry and discussion. The entire discussion is predicated on the idea that osgi is close to ideal as-is and we have no need to consider any other point of view. If you step back a bit I see two things clearly acknowledged by everyone: 1. its useful to be able to know what classes are needed to make a jar/bundle/plugin/module work and which classes are expected to be used elsewhere 2. its essential to know what jars/bundles/plugins/modules are actually in your running system In osgi-land, import-package and export-package supply (1), and require-bundle sort of helps with (2) but AFAICT right now doesn't support artifact aliasing In maven-land, the pom dependency tracking provides a pretty good solution for (2), including some support for overriding requirements through exclusions, but it's single-classloader model doesn't translate directly into an app server or osgi runtime In geronimo trunk we emphasize (2) and can actually assemble working servers using it, and have support for (1) (although its mostly backwards from osgi specifications) I'd say that in my (limited) experience osgi zealots typically think that (1) is essential and brush (2) under the carpet by working in constrained environments such as their eclipse workspace. I'd say that our experience with geronimo is that (1) is rarely needed if you have a working (2) (look at how many hidden-classes and non-overriable classes filters are in our poms -- none for the use of geronimo, and a few to make deploying applications that include the same jars as us work) The geronimo/maven approach to (2) is to include the dependency information with the artifact. I'm not sure what approach(es) osgi is considering -- OBR appears to not consider bundling dependency info with the artifact but to have a completely external specification. I don't know about p2 but since jason vanZyl seems to be looking at it I'd guess it is more maven friendly. If you don't bundle (2) with the artifacts then you need some kind of import-package to artifact map or resolution system. We sort of have some vestiges of this today: when you deploy a web app as a geronimo plugin (or export it from a server where it was deployed) it has picked up dependencies on jetty or tomcat based on which deployer you specified in the plugin project pom or which kind of server you deployed on. Another example is that the car-maven-plugin filters the view of the local maven repo so only the versions specified in the pom are visible to the geronimo server we run off the repo -- this allows you to build plugins for a 2.1.3 server even if you have 2.2-SNAPSHOT artifacts locally and some of the dependencies don't specify the version required. I don't know where the best balance for geronimo lies here. I certainly think claiming all we need is import-package is shortchanging most of our experience in producing geronimo as a working server. thanks david jencks On Mar 13, 2009, at 7:10 AM, Lin Sun wrote: I think I was not too clear below. I didn't mean to say that I am in favor of Require-Bundle because it is a lot harder to come up with the right Import-Package lists. What I meant was that the reason why a lot of people are using Require-Bundle like David mentioned in his early notes is probably because it is a lot easier to use. I personally had to spend quite some time to figure out the prob I mentioned earlier - I was developing a bundle that needs to import the javax.transaction package from the transaction in OSGi bundle, but two bundles have it (the basic OSGi J2SE and the transaction in OSGi bundle). I was able to resolve this using Import-Package with the specific version of javax.transaction package that I need. I just tried to switch to use Require-Bundle, that is to have my bundle to depend on the transaction in OSGi bundle as it contains the right version of the javax.transaction package I need, but my bundle is broken completely due to CDNFE. I don't think the Require-Bundle offers the fine grain control that I needed for my bundle and I am sure Geronimo would have a lot more complicated bundles than what I was developing. BTW, there's a good discussion here: http://thhal.blogspot.com/2008/02/dependencies-and-package-imports.html - in particular in the first comment from Neil Bartlett and the limitations of Require-Bundle documented in the OSGi v 4.1 core spec (section 3.13.3). Lin On Thu, Mar 12, 2009 at 11:40 PM, Lin Sun linsun@gmail.com wrote: Not sure about Require-Bundle. I personally has never used it and I never see it is being used in the OSGi repo. Require-Bundle may not offer the level of control that the Import-Package
Re: Whence the geronimo kernel?
David Jencks wrote: I read the blog entry and discussion. The entire discussion is predicated on the idea that osgi is close to ideal as-is and we have no need to consider any other point of view. If you step back a bit I see two things clearly acknowledged by everyone: 1. its useful to be able to know what classes are needed to make a jar/bundle/plugin/module work and which classes are expected to be used elsewhere 2. its essential to know what jars/bundles/plugins/modules are actually in your running system In osgi-land, import-package and export-package supply (1), and require-bundle sort of helps with (2) but AFAICT right now doesn't support artifact aliasing In maven-land, the pom dependency tracking provides a pretty good solution for (2), including some support for overriding requirements through exclusions, but it's single-classloader model doesn't translate directly into an app server or osgi runtime In geronimo trunk we emphasize (2) and can actually assemble working servers using it, and have support for (1) (although its mostly backwards from osgi specifications) I'd say that in my (limited) experience osgi zealots typically think that (1) is essential and brush (2) under the carpet by working in constrained environments such as their eclipse workspace. I'd say that our experience with geronimo is that (1) is rarely needed if you have a working (2) (look at how many hidden-classes and non-overriable classes filters are in our poms -- none for the use of geronimo, and a few to make deploying applications that include the same jars as us work) The geronimo/maven approach to (2) is to include the dependency information with the artifact. I'm not sure what approach(es) osgi is considering -- OBR appears to not consider bundling dependency info with the artifact but to have a completely external specification. I don't know about p2 but since jason vanZyl seems to be looking at it I'd guess it is more maven friendly. If you don't bundle (2) with the artifacts then you need some kind of import-package to artifact map or resolution system. We sort of have some vestiges of this today: when you deploy a web app as a geronimo plugin (or export it from a server where it was deployed) it has picked up dependencies on jetty or tomcat based on which deployer you specified in the plugin project pom or which kind of server you deployed on. Another example is that the car-maven-plugin filters the view of the local maven repo so only the versions specified in the pom are visible to the geronimo server we run off the repo -- this allows you to build plugins for a 2.1.3 server even if you have 2.2-SNAPSHOT artifacts locally and some of the dependencies don't specify the version required. I don't know where the best balance for geronimo lies here. I certainly think claiming all we need is import-package is shortchanging most of our experience in producing geronimo as a working server. But on the other hand, I'd hate to have not using just Import-package as the starting point. Given how much it is assumed in the OSGi world, it would be best to assume its use and only step outside of that box once we've found the intractable problem that requires it. Starting outside of those limits means we're abandoning the things OSGi does straight off because their may be some places where the exception mechanisms are required. Rick thanks david jencks On Mar 13, 2009, at 7:10 AM, Lin Sun wrote: I think I was not too clear below. I didn't mean to say that I am in favor of Require-Bundle because it is a lot harder to come up with the right Import-Package lists. What I meant was that the reason why a lot of people are using Require-Bundle like David mentioned in his early notes is probably because it is a lot easier to use. I personally had to spend quite some time to figure out the prob I mentioned earlier - I was developing a bundle that needs to import the javax.transaction package from the transaction in OSGi bundle, but two bundles have it (the basic OSGi J2SE and the transaction in OSGi bundle).I was able to resolve this using Import-Package with the specific version of javax.transaction package that I need. I just tried to switch to use Require-Bundle, that is to have my bundle to depend on the transaction in OSGi bundle as it contains the right version of the javax.transaction package I need, but my bundle is broken completely due to CDNFE. I don't think the Require-Bundle offers the fine grain control that I needed for my bundle and I am sure Geronimo would have a lot more complicated bundles than what I was developing. BTW, there's a good discussion here: http://thhal.blogspot.com/2008/02/dependencies-and-package-imports.html - in particular in the first comment from Neil Bartlett and the limitations of Require-Bundle documented in the OSGi v 4.1 core spec (section 3.13.3). Lin On Thu, Mar 12, 2009 at 11:40 PM, Lin Sun
Re: Whence the geronimo kernel?
On Mar 13, 2009, at 9:43 AM, Rick McGuire wrote: David Jencks wrote: I read the blog entry and discussion. The entire discussion is predicated on the idea that osgi is close to ideal as-is and we have no need to consider any other point of view. If you step back a bit I see two things clearly acknowledged by everyone: 1. its useful to be able to know what classes are needed to make a jar/bundle/plugin/module work and which classes are expected to be used elsewhere 2. its essential to know what jars/bundles/plugins/modules are actually in your running system In osgi-land, import-package and export-package supply (1), and require-bundle sort of helps with (2) but AFAICT right now doesn't support artifact aliasing In maven-land, the pom dependency tracking provides a pretty good solution for (2), including some support for overriding requirements through exclusions, but it's single-classloader model doesn't translate directly into an app server or osgi runtime In geronimo trunk we emphasize (2) and can actually assemble working servers using it, and have support for (1) (although its mostly backwards from osgi specifications) I'd say that in my (limited) experience osgi zealots typically think that (1) is essential and brush (2) under the carpet by working in constrained environments such as their eclipse workspace. I'd say that our experience with geronimo is that (1) is rarely needed if you have a working (2) (look at how many hidden- classes and non-overriable classes filters are in our poms -- none for the use of geronimo, and a few to make deploying applications that include the same jars as us work) The geronimo/maven approach to (2) is to include the dependency information with the artifact. I'm not sure what approach(es) osgi is considering -- OBR appears to not consider bundling dependency info with the artifact but to have a completely external specification. I don't know about p2 but since jason vanZyl seems to be looking at it I'd guess it is more maven friendly. If you don't bundle (2) with the artifacts then you need some kind of import-package to artifact map or resolution system. We sort of have some vestiges of this today: when you deploy a web app as a geronimo plugin (or export it from a server where it was deployed) it has picked up dependencies on jetty or tomcat based on which deployer you specified in the plugin project pom or which kind of server you deployed on. Another example is that the car-maven- plugin filters the view of the local maven repo so only the versions specified in the pom are visible to the geronimo server we run off the repo -- this allows you to build plugins for a 2.1.3 server even if you have 2.2-SNAPSHOT artifacts locally and some of the dependencies don't specify the version required. I don't know where the best balance for geronimo lies here. I certainly think claiming all we need is import-package is shortchanging most of our experience in producing geronimo as a working server. But on the other hand, I'd hate to have not using just Import- package as the starting point. Given how much it is assumed in the OSGi world, it would be best to assume its use and only step outside of that box once we've found the intractable problem that requires it. Starting outside of those limits means we're abandoning the things OSGi does straight off because their may be some places where the exception mechanisms are required. Aren't you exhibiting exactly the same attitude as the blog posters in saying the (2) is not really a problem we need to consider? Whereas all our work in getting geronimo to actually work has been focussed on solving (2). If we ditch our working system for (2) we won't have a server perhaps ever. In terms of assembling a server, without (2) the space of possible bundles to resolve to is the entire maven central repo. ( I anticipate that any working server is going to be able to convert plain jars to bundles on the fly. If not, no one who is not osgi-obsessed will be willing to use it) At the moment I'm inclined to think that require-bundle is not a workable solution for (2) and so we might as well use import-package plus an osgi runtime that uses and requires explicit external dependency information such as provided by maven or geronimo- plugin.xml to choose what bundle to resolve to. However until we get something working we won't know much about whether this or any proposal is a good or workable choice. I'm still waiting for news of a working osgi system that is comparable in scale to eclipse that primarily uses import-package. thanks david jencks Rick thanks david jencks On Mar 13, 2009, at 7:10 AM, Lin Sun wrote: I think I was not too clear below. I didn't mean to say that I am in favor of Require-Bundle because it is a lot harder to come up with the right Import-Package
Re: Whence the geronimo kernel?
On Mar 11, 2009, at 10:55 PM, Jason Dillon wrote: On Mar 12, 2009, at 1:26 AM, David Jencks wrote: I believe that xbean-spring is still unnecessary noisy when compared to something like the Spring Bean Builder (http://www.grails.org/Spring+Bean+Builder ). That looks nice, but is there any syntax validation possible? I'm pretty much unwilling to use groovy for anything at this point due to my bad experiences with lack of pre-runtime syntax validation and unclear error messages writing some simple gshell commands. xml is really horrible but most editors do support validation against a schema. On the other hand, I think we could come up with something even shorter, clearer, and to the point, with syntax validation, using scala. Why Scala? My knowledge of scala is limited to reading the scala book and not trying any code, but I got the impression you could do at least as powerful things in the way of builders as with groovy, plus have compile time type checking. As with groovy it's compatible with java code and compiles to java bytecode. thanks david jencks --jason
Re: Whence the geronimo kernel?
On 12/03/2009, at 4:29 AM, David Jencks wrote: On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote: Hi, So let's agree to disagree for now. This may be related to my personal way of comparing stuff which is pretty much limited to: 1. understand what the requirements are. 2. understand how the technologies support these requirements. I do not need all the bells and whistles that a technology offers to fulfill the requirements. Moreover comparing stuff based on technology differentiators not clearly linked to the requirements is pointless. 3. assess best way forward based on above scoring. Key steps are 1 and 2 where stuff offering all the bells and whistles may well be scored as good as other stuff (I clearly do not support over-bloated stuff...). Obviously, I am keen to be proven wrong and adjust accordingly. So far, I am still saying that the main challenge is to properly tune export/import of dependency declarations. For me, the technology is not the core issue and switching is not going to resolve problems. I agree. I doubt Guillaume has seen your additions to classloading in trunk which allow you to not export packages from a classloader. I haven't tried to prove it mathematically but I think that with this feature the classloading models for geronimo and osgi are equivalent in that you can express the same ability to access classes with either of them. Of course, the notation you use to express this and the specific information included in the configuration is different. I think I probably have the most experience with classloading problems in geronimo and the only real problem that arises is loading a jar in two different classloaders. This can be solved by a classloader-per-jar model which offers no theoretical problems to set up in geronimo but practically would take a lot of work (and maven projects to build a plugin per jar). So I think we'll have to see what kind of problems we get with trying to actually use OSGI. Hi, Thinking more about this, I believe we can expedite the implementation of a classloader-per-jar model. Under the hood of a MultiParentClassLoader we can replace the current implementation of find class and resources contracts by an implementation which delegates to a bunch of URLClassLoaders (one per jar). These bunch of URLClassLoaders are global classloaders, i.e. shared across all the configs/MultiParentClassLoaders. The core challenge is to create them in a hierarchy respecting the maven dependency declarations. So, we could install the pom of the dependencies in the repo and lazily parse them when MultiParentClassLoader are created to build this global and share tree of URLClassLoaders. I just started to work on it and I will post back my findings (i should be able to complete this over the week-end). Even if we switch to an OSGi kernel, part of this work may hopefully still be useful. Thanks, Gianny One thing I'd really like actual user data on is how people actually specify osgi classloading info in real life. I'm very aware that in theory you are supposed to specify the package imports and exports for your bundle but I've been told that in real life everyone with a serious osgi project actually specifies the jar dependencies they want using require-bundle. thanks david jencks Thanks, Gianny On 11/03/2009, at 7:11 PM, Guillaume Nodet wrote: On Wed, Mar 11, 2009 at 08:57, Gianny Damour gianny.dam...@optusnet.com.au wrote: Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/import dependency declarations. I have to disagree with that. The CLing mechanism is very different in Geronimo (from what I recall) and OSGi. Geronimo uses a multi-parent classloader style with some nice features to be able to hide / never override + parent or self-first delegation. OSGi CLind is very different: the first one is that you don't really have parent classloaders: the classloader for a given OSGi bundle is calculated wrt to the constraints expressed in the OSGi manifest using imported packages or required bundles. Let's take an example: bundle A needs api packages from bundles B and C implementation classes from bundle B and C needs something from bundle D but with different versions OSGi will be able to handle that because of non tree-like CLind mechanism: if bundle A is wired to bundle B, it does not have to see all the requirements from bundle B, and same for C. Therefore, bundle A can be wired to both B and C without problems because it will not see bundle D at all (so there's no
Re: Whence the geronimo kernel?
On 12/03/2009, at 5:26 AM, David Jencks wrote: On Mar 11, 2009, at 12:57 AM, Gianny Damour wrote: Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/import dependency declarations. The JAXB approach to turn xml plans to a bunch of objects is certainly interesting. I believe it is still a technology limiting decision whereby a lot of custom code will have to be implemented to support various style (factory methods or beans et cetera) of configurations. I have been bouncing around this idea a while back and here it is again. Why do we want to define a XML language to create a bunch of objects when scripting can do that for us? I believe that xbean-spring is still unnecessary noisy when compared to something like the Spring Bean Builder (http:// www.grails.org/Spring+Bean+Builder). That looks nice, but is there any syntax validation possible? I'm pretty much unwilling to use groovy for anything at this point due to my bad experiences with lack of pre-runtime syntax validation and unclear error messages writing some simple gshell commands. xml is really horrible but most editors do support validation against a schema. This is the weakness but also the power of the approach whereby users can mix arbitrary code and declarations. Syntax validation is pretty much addressed by IDEs; however, only testing the script will prove that it does what it is supposed to do. I do understand your reticence thought and I will not insist. On the other hand, I think we could come up with something even shorter, clearer, and to the point, with syntax validation, using scala. This is an interesting idea. I am keen to see something more streamlined and efficient than yet another XML approach to configure a bunch of services in the kernel! Thanks, Gianny thanks david jencks If there is an interest in a scripting approach, then I can investigate further. Thoughts? Thanks, Gianny On 11/03/2009, at 6:54 AM, David Jencks wrote: So as mentioned below I'm starting to look into the osgi classloading bit, sort of from the bottom. Another approach to many of these issues is perhaps from the top, from the point of view of going from a presumably xml plan to a bunch of objects. I've long thought that it must be possible to leverage jaxb to do most of the heavy lifting here. In particular sxc is some code we can presumably actually extend to do stuff like constructor dependency injection. So another avenue that could perhaps be approached in parallel would be to investigate sxc, jaxb, xbean- spring, xbean-reflect, the blueprint service schema, and jsr299 requirements and see what we can come up with. For instance, it might be possible to have a large part of the blueprint service functionality in jaxb-enabled objects that jaxb instantiates from the xml. The init method could deal with feeding the metadata into the blueprint service core. Maybe we can get sxc to use xbean-reflect to create the objects. So far this is more or less wild speculation in my head... but I think it would be a lot of fun to investigate. thanks david jencks On Mar 4, 2009, at 4:56 PM, David Jencks wrote: Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two plugins. NoClassDefFound errors from an optional jar in a child classloader are also really annoying. Really good things about geronimo I haven't seen elsewhere (at least in one place): - gbean dependencies work across plugins. Dependencies are a unified system, not per-plugin. - gbean dependencies are resolved in the ancestors of a plugin, not server wide. This means that you can't make a partially specified dependency ambiguous by deploying additional plugins. I consider this an extremely important feature for predictability. - plugin dependencies allow assembly of a server from the explicit dependencies which are normally the same as the maven dependencies.
Re: Whence the geronimo kernel?
Hi Gianny, As a keen observer of the Geronimo dev List , I would like to ask question on this subject. Gianny, do you want to say that there is an UniversalClassLoader for all the server instance that contains the other class loaders. IOW, try to change hierarchical class loaders with the flat class loader repository? Do you mean that if jar is already loaded by the any class loader that is registered in the UniversalClassLoader, it will always load the same jar? Thanks; Gurkan From: Gianny Damour gianny.dam...@optusnet.com.au To: dev@geronimo.apache.org Sent: Thursday, March 12, 2009 12:25:34 PM Subject: Re: Whence the geronimo kernel? On 12/03/2009, at 4:29 AM, David Jencks wrote: On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote: Hi, So let's agree to disagree for now. This may be related to my personal way of comparing stuff which is pretty much limited to: 1. understand what the requirements are. 2. understand how the technologies support these requirements. I do not need all the bells and whistles that a technology offers to fulfill the requirements. Moreover comparing stuff based on technology differentiators not clearly linked to the requirements is pointless. 3. assess best way forward based on above scoring. Key steps are 1 and 2 where stuff offering all the bells and whistles may well be scored as good as other stuff (I clearly do not support over-bloated stuff...). Obviously, I am keen to be proven wrong and adjust accordingly. So far, I am still saying that the main challenge is to properly tune export/import of dependency declarations. For me, the technology is not the core issue and switching is not going to resolve problems. I agree. I doubt Guillaume has seen your additions to classloading in trunk which allow you to not export packages from a classloader. I haven't tried to prove it mathematically but I think that with this feature the classloading models for geronimo and osgi are equivalent in that you can express the same ability to access classes with either of them. Of course, the notation you use to express this and the specific information included in the configuration is different. I think I probably have the most experience with classloading problems in geronimo and the only real problem that arises is loading a jar in two different classloaders. This can be solved by a classloader-per-jar model which offers no theoretical problems to set up in geronimo but practically would take a lot of work (and maven projects to build a plugin per jar). So I think we'll have to see what kind of problems we get with trying to actually use OSGI. Hi, Thinking more about this, I believe we can expedite the implementation of a classloader-per-jar model. Under the hood of a MultiParentClassLoader we can replace the current implementation of find class and resources contracts by an implementation which delegates to a bunch of URLClassLoaders (one per jar). These bunch of URLClassLoaders are global classloaders, i.e. shared across all the configs/MultiParentClassLoaders. The core challenge is to create them in a hierarchy respecting the maven dependency declarations. So, we could install the pom of the dependencies in the repo and lazily parse them when MultiParentClassLoader are created to build this global and share tree of URLClassLoaders. I just started to work on it and I will post back my findings (i should be able to complete this over the week-end). Even if we switch to an OSGi kernel, part of this work may hopefully still be useful. Thanks, Gianny One thing I'd really like actual user data on is how people actually specify osgi classloading info in real life. I'm very aware that in theory you are supposed to specify the package imports and exports for your bundle but I've been told that in real life everyone with a serious osgi project actually specifies the jar dependencies they want using require-bundle. thanks david jencks Thanks, Gianny On 11/03/2009, at 7:11 PM, Guillaume Nodet wrote: On Wed, Mar 11, 2009 at 08:57, Gianny Damour gianny.dam...@optusnet.com.au wrote: Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/import dependency declarations. I have to disagree with that. The CLing mechanism is very different in Geronimo (from what I recall) and OSGi. Geronimo uses a multi-parent classloader style with some nice features to be able to hide / never override + parent or self-first delegation. OSGi CLind is very different: the first one
Re: Whence the geronimo kernel?
On Mar 12, 2009, at 3:25 AM, Gianny Damour wrote: On 12/03/2009, at 4:29 AM, David Jencks wrote: On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote: Hi, So let's agree to disagree for now. This may be related to my personal way of comparing stuff which is pretty much limited to: 1. understand what the requirements are. 2. understand how the technologies support these requirements. I do not need all the bells and whistles that a technology offers to fulfill the requirements. Moreover comparing stuff based on technology differentiators not clearly linked to the requirements is pointless. 3. assess best way forward based on above scoring. Key steps are 1 and 2 where stuff offering all the bells and whistles may well be scored as good as other stuff (I clearly do not support over-bloated stuff...). Obviously, I am keen to be proven wrong and adjust accordingly. So far, I am still saying that the main challenge is to properly tune export/import of dependency declarations. For me, the technology is not the core issue and switching is not going to resolve problems. I agree. I doubt Guillaume has seen your additions to classloading in trunk which allow you to not export packages from a classloader. I haven't tried to prove it mathematically but I think that with this feature the classloading models for geronimo and osgi are equivalent in that you can express the same ability to access classes with either of them. Of course, the notation you use to express this and the specific information included in the configuration is different. I think I probably have the most experience with classloading problems in geronimo and the only real problem that arises is loading a jar in two different classloaders. This can be solved by a classloader-per-jar model which offers no theoretical problems to set up in geronimo but practically would take a lot of work (and maven projects to build a plugin per jar). So I think we'll have to see what kind of problems we get with trying to actually use OSGI. Hi, Thinking more about this, I believe we can expedite the implementation of a classloader-per-jar model. Under the hood of a MultiParentClassLoader we can replace the current implementation of find class and resources contracts by an implementation which delegates to a bunch of URLClassLoaders (one per jar). These bunch of URLClassLoaders are global classloaders, i.e. shared across all the configs/MultiParentClassLoaders. The core challenge is to create them in a hierarchy respecting the maven dependency declarations. So, we could install the pom of the dependencies in the repo and lazily parse them when MultiParentClassLoader are created to build this global and share tree of URLClassLoaders. IMO the danger here is that the maven pom may not exist or may be wrong. OSGI has the same problem in that the vast majority of released jars don't have osgi manifests. I think I saw a rumor that spring spent a lot of effort osgi-ifying a lot of commonly used jars to try to solve this problem. I also don't know if there are situations in which a small number of closely related jars need to be loaded in a single classloader, perhaps because one of the jars is optional but if present the main jar needs access to its classes. I think there was an osgi feature that looked sort of like this. I just started to work on it and I will post back my findings (i should be able to complete this over the week-end). Even if we switch to an OSGi kernel, part of this work may hopefully still be useful. Unless you are pretty sure we won't have the kind of problems with bad community metadata suggested above it might be a good idea to do this in a sandbox branch? thanks david jencks Thanks, Gianny One thing I'd really like actual user data on is how people actually specify osgi classloading info in real life. I'm very aware that in theory you are supposed to specify the package imports and exports for your bundle but I've been told that in real life everyone with a serious osgi project actually specifies the jar dependencies they want using require-bundle. thanks david jencks Thanks, Gianny On 11/03/2009, at 7:11 PM, Guillaume Nodet wrote: On Wed, Mar 11, 2009 at 08:57, Gianny Damour gianny.dam...@optusnet.com.au wrote: Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/import dependency declarations. I have to disagree with that. The CLing mechanism is very different in Geronimo (from what I recall) and OSGi. Geronimo uses a
Re: Whence the geronimo kernel?
See comments below. Lin On Thu, Mar 12, 2009 at 1:51 AM, Jarek Gawor jga...@gmail.com wrote: 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. Here is my understanding on this scenario. First, you don't really need to develop a bundle for commons-logging package(s). Bundle B and C can just have the commons-logging packages on their Import-Package attribute, with the specific versions they need, for example: Import-Package = \ org.apache.commons...;version=1.1, \ * When bundle A have Bundle B and C's APIs listed on Bundle A's Import-Package attribute, it won't see the commons-logging package at all. It would only see the package if Bundle B/C exports the commons-logging package on its Export-Package attribute, and Bundle A has commons-logging package explicitly on its Import-Package attribute. 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? Not sure about Require-Bundle. I personally has never used it and I never see it is being used in the OSGi repo. Require-Bundle may not offer the level of control that the Import-Package provides but it is probably a lot harder to come up with the right Import-Package lists. I think this scenario should work just fine if using Import-Package.
Re: Whence the geronimo kernel?
I think this is a valid concern. My understanding is that the OSGi community is working hard on this as they are working on specifications for a Web Container in OSGi with requirements like Java EE compliant web container in OSGi. They are also working on specifications for JNDI in OSGi, transaction in OSGi, JPA in OSGi, etc. Lin Also, OSGi does not really play nicely with the usual JEE way to discover implementations through the MANIFEST/services entries. That's kinda what we've tried to solve in servicemix specs, though I'm not sure if that really applies everywhere because I would imagine the classloaders for EARs are not really OSGi classloaders ...
Re: Whence the geronimo kernel?
Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/ import dependency declarations. The JAXB approach to turn xml plans to a bunch of objects is certainly interesting. I believe it is still a technology limiting decision whereby a lot of custom code will have to be implemented to support various style (factory methods or beans et cetera) of configurations. I have been bouncing around this idea a while back and here it is again. Why do we want to define a XML language to create a bunch of objects when scripting can do that for us? I believe that xbean-spring is still unnecessary noisy when compared to something like the Spring Bean Builder (http://www.grails.org/ Spring+Bean+Builder). If there is an interest in a scripting approach, then I can investigate further. Thoughts? Thanks, Gianny On 11/03/2009, at 6:54 AM, David Jencks wrote: So as mentioned below I'm starting to look into the osgi classloading bit, sort of from the bottom. Another approach to many of these issues is perhaps from the top, from the point of view of going from a presumably xml plan to a bunch of objects. I've long thought that it must be possible to leverage jaxb to do most of the heavy lifting here. In particular sxc is some code we can presumably actually extend to do stuff like constructor dependency injection. So another avenue that could perhaps be approached in parallel would be to investigate sxc, jaxb, xbean- spring, xbean-reflect, the blueprint service schema, and jsr299 requirements and see what we can come up with. For instance, it might be possible to have a large part of the blueprint service functionality in jaxb-enabled objects that jaxb instantiates from the xml. The init method could deal with feeding the metadata into the blueprint service core. Maybe we can get sxc to use xbean-reflect to create the objects. So far this is more or less wild speculation in my head... but I think it would be a lot of fun to investigate. thanks david jencks On Mar 4, 2009, at 4:56 PM, David Jencks wrote: Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two plugins. NoClassDefFound errors from an optional jar in a child classloader are also really annoying. Really good things about geronimo I haven't seen elsewhere (at least in one place): - gbean dependencies work across plugins. Dependencies are a unified system, not per-plugin. - gbean dependencies are resolved in the ancestors of a plugin, not server wide. This means that you can't make a partially specified dependency ambiguous by deploying additional plugins. I consider this an extremely important feature for predictability. - plugin dependencies allow assembly of a server from the explicit dependencies which are normally the same as the maven dependencies. Other projects and specs that have stuff we should look into: maven. Maven has a lot better infrastructure for dealing with dependency resolution from partial transitive dependency specification than we do. We should look into using more of their infrastructure. osgi. osgi has a lot of similarities to geronimo. The osgi classloading model is getting a lot of people excited. The import- bundle idea is pretty much the same as our classloader model where every jar is a plugin. I don't know if people are really using the allegedly recommended method of specifying imports and exports and letting the osgi runtime figure out where they come from; this seems worth investigating to me. Also, we get periodic inquiries about when we are going to support osgi and the was ce folks get even more. osgi blueprint service (rfc 124) This appears to be a simple wiring framework for a single plugin. IIUC it uses the osgi service registry for component dependencies between bundles. xbean-spring. I'd be reluctant to try to implement a blueprint service that didn't provide the xbean-spring capabilities really well
Re: Whence the geronimo kernel?
On Wed, Mar 11, 2009 at 08:57, Gianny Damour gianny.dam...@optusnet.com.auwrote: Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/import dependency declarations. I have to disagree with that. The CLing mechanism is very different in Geronimo (from what I recall) and OSGi. Geronimo uses a multi-parent classloader style with some nice features to be able to hide / never override + parent or self-first delegation. OSGi CLind is very different: the first one is that you don't really have parent classloaders: the classloader for a given OSGi bundle is calculated wrt to the constraints expressed in the OSGi manifest using imported packages or required bundles. Let's take an example: bundle A needs api packages from bundles B and C implementation classes from bundle B and C needs something from bundle D but with different versions OSGi will be able to handle that because of non tree-like CLind mechanism: if bundle A is wired to bundle B, it does not have to see all the requirements from bundle B, and same for C. Therefore, bundle A can be wired to both B and C without problems because it will not see bundle D at all (so there's no conflicts between the two versions of bundle D). OSGi has a much more powerful CLing mechanism where you can express lots of different constraints. The drawback is that establishing the classloader can take a bit of time, so going to OSGi most certainly leads to a big slowdown at startup while creating the classloaders. Also, OSGi does not really play nicely with the usual JEE way to discover implementations through the MANIFEST/services entries. That's kinda what we've tried to solve in servicemix specs, though I'm not sure if that really applies everywhere because I would imagine the classloaders for EARs are not really OSGi classloaders ... I certainly don't want to say OSGi is not the way to go, just want to make the point that there are benefits but also drawbacks. The JAXB approach to turn xml plans to a bunch of objects is certainly interesting. I believe it is still a technology limiting decision whereby a lot of custom code will have to be implemented to support various style (factory methods or beans et cetera) of configurations. I have been bouncing around this idea a while back and here it is again. Why do we want to define a XML language to create a bunch of objects when scripting can do that for us? I believe that xbean-spring is still unnecessary noisy when compared to something like the Spring Bean Builder (http://www.grails.org/ Spring+Bean+Builder). If there is an interest in a scripting approach, then I can investigate further. Thoughts? Thanks, Gianny On 11/03/2009, at 6:54 AM, David Jencks wrote: So as mentioned below I'm starting to look into the osgi classloading bit, sort of from the bottom. Another approach to many of these issues is perhaps from the top, from the point of view of going from a presumably xml plan to a bunch of objects. I've long thought that it must be possible to leverage jaxb to do most of the heavy lifting here. In particular sxc is some code we can presumably actually extend to do stuff like constructor dependency injection. So another avenue that could perhaps be approached in parallel would be to investigate sxc, jaxb, xbean-spring, xbean-reflect, the blueprint service schema, and jsr299 requirements and see what we can come up with. For instance, it might be possible to have a large part of the blueprint service functionality in jaxb-enabled objects that jaxb instantiates from the xml. The init method could deal with feeding the metadata into the blueprint service core. Maybe we can get sxc to use xbean-reflect to create the objects. So far this is more or less wild speculation in my head... but I think it would be a lot of fun to investigate. thanks david jencks On Mar 4, 2009, at 4:56 PM, David Jencks wrote: Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two
Re: Whence the geronimo kernel?
Hi, So let's agree to disagree for now. This may be related to my personal way of comparing stuff which is pretty much limited to: 1. understand what the requirements are. 2. understand how the technologies support these requirements. I do not need all the bells and whistles that a technology offers to fulfill the requirements. Moreover comparing stuff based on technology differentiators not clearly linked to the requirements is pointless. 3. assess best way forward based on above scoring. Key steps are 1 and 2 where stuff offering all the bells and whistles may well be scored as good as other stuff (I clearly do not support over-bloated stuff...). Obviously, I am keen to be proven wrong and adjust accordingly. So far, I am still saying that the main challenge is to properly tune export/import of dependency declarations. For me, the technology is not the core issue and switching is not going to resolve problems. Thanks, Gianny On 11/03/2009, at 7:11 PM, Guillaume Nodet wrote: On Wed, Mar 11, 2009 at 08:57, Gianny Damour gianny.dam...@optusnet.com.au wrote: Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/import dependency declarations. I have to disagree with that. The CLing mechanism is very different in Geronimo (from what I recall) and OSGi. Geronimo uses a multi-parent classloader style with some nice features to be able to hide / never override + parent or self-first delegation. OSGi CLind is very different: the first one is that you don't really have parent classloaders: the classloader for a given OSGi bundle is calculated wrt to the constraints expressed in the OSGi manifest using imported packages or required bundles. Let's take an example: bundle A needs api packages from bundles B and C implementation classes from bundle B and C needs something from bundle D but with different versions OSGi will be able to handle that because of non tree-like CLind mechanism: if bundle A is wired to bundle B, it does not have to see all the requirements from bundle B, and same for C. Therefore, bundle A can be wired to both B and C without problems because it will not see bundle D at all (so there's no conflicts between the two versions of bundle D). OSGi has a much more powerful CLing mechanism where you can express lots of different constraints. The drawback is that establishing the classloader can take a bit of time, so going to OSGi most certainly leads to a big slowdown at startup while creating the classloaders. Also, OSGi does not really play nicely with the usual JEE way to discover implementations through the MANIFEST/services entries. That's kinda what we've tried to solve in servicemix specs, though I'm not sure if that really applies everywhere because I would imagine the classloaders for EARs are not really OSGi classloaders ... I certainly don't want to say OSGi is not the way to go, just want to make the point that there are benefits but also drawbacks. The JAXB approach to turn xml plans to a bunch of objects is certainly interesting. I believe it is still a technology limiting decision whereby a lot of custom code will have to be implemented to support various style (factory methods or beans et cetera) of configurations. I have been bouncing around this idea a while back and here it is again. Why do we want to define a XML language to create a bunch of objects when scripting can do that for us? I believe that xbean-spring is still unnecessary noisy when compared to something like the Spring Bean Builder (http:// www.grails.org/Spring+Bean+Builder). If there is an interest in a scripting approach, then I can investigate further. Thoughts? Thanks, Gianny On 11/03/2009, at 6:54 AM, David Jencks wrote: So as mentioned below I'm starting to look into the osgi classloading bit, sort of from the bottom. Another approach to many of these issues is perhaps from the top, from the point of view of going from a presumably xml plan to a bunch of objects. I've long thought that it must be possible to leverage jaxb to do most of the heavy lifting here. In particular sxc is some code we can presumably actually extend to do stuff like constructor dependency injection. So another avenue that could perhaps be approached in parallel would be to investigate sxc, jaxb, xbean- spring, xbean-reflect, the blueprint service schema, and jsr299 requirements and see what we can come up with. For instance, it might be possible to have a large part of the blueprint service functionality in jaxb-enabled objects that
Re: Whence the geronimo kernel?
Guillaume Nodet wrote: On Wed, Mar 11, 2009 at 08:57, Gianny Damour gianny.dam...@optusnet.com.au mailto:gianny.dam...@optusnet.com.au wrote: Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/import dependency declarations. I have to disagree with that. The CLing mechanism is very different in Geronimo (from what I recall) and OSGi. Geronimo uses a multi-parent classloader style with some nice features to be able to hide / never override + parent or self-first delegation. OSGi CLind is very different: the first one is that you don't really have parent classloaders: the classloader for a given OSGi bundle is calculated wrt to the constraints expressed in the OSGi manifest using imported packages or required bundles. Let's take an example: bundle A needs api packages from bundles B and C implementation classes from bundle B and C needs something from bundle D but with different versions OSGi will be able to handle that because of non tree-like CLind mechanism: if bundle A is wired to bundle B, it does not have to see all the requirements from bundle B, and same for C. Therefore, bundle A can be wired to both B and C without problems because it will not see bundle D at all (so there's no conflicts between the two versions of bundle D). I have to agree with Guillaume on this. A lot of the difficulties that people run into with trying to configure the classloading options on Geronimo can become non-issues under the OSGi model. Those sorts of problems are handled automatically by the OSGi framework. On the downside, a lot more work needs to go into specifying the package dependencies. This can make bundlizing a jar an interesting exercise the first time. OSGi has a much more powerful CLing mechanism where you can express lots of different constraints. The drawback is that establishing the classloader can take a bit of time, so going to OSGi most certainly leads to a big slowdown at startup while creating the classloaders. Also, OSGi does not really play nicely with the usual JEE way to discover implementations through the MANIFEST/services entries. That's kinda what we've tried to solve in servicemix specs, though I'm not sure if that really applies everywhere because I would imagine the classloaders for EARs are not really OSGi classloaders ... OSGi is definitely moving in that direction. There are a number of RFCs in the works for how that sort of autodiscovery should behave running on an OSGi framework. The new blueprint service will provide a native application assembly model, and other RFCs cover discovering/running different types of JEE application types. I certainly don't want to say OSGi is not the way to go, just want to make the point that there are benefits but also drawbacks. The JAXB approach to turn xml plans to a bunch of objects is certainly interesting. I believe it is still a technology limiting decision whereby a lot of custom code will have to be implemented to support various style (factory methods or beans et cetera) of configurations. I have been bouncing around this idea a while back and here it is again. Why do we want to define a XML language to create a bunch of objects when scripting can do that for us? I believe that xbean-spring is still unnecessary noisy when compared to something like the Spring Bean Builder (http://www.grails.org/Spring+Bean+Builder). If there is an interest in a scripting approach, then I can investigate further. Thoughts? Thanks, Gianny On 11/03/2009, at 6:54 AM, David Jencks wrote: So as mentioned below I'm starting to look into the osgi classloading bit, sort of from the bottom. Another approach to many of these issues is perhaps from the top, from the point of view of going from a presumably xml plan to a bunch of objects. I've long thought that it must be possible to leverage jaxb to do most of the heavy lifting here. In particular sxc is some code we can presumably actually extend to do stuff like constructor dependency injection. So another avenue that could perhaps be approached in parallel would be to investigate sxc, jaxb, xbean-spring, xbean-reflect, the blueprint service schema, and jsr299 requirements and see what we can come up with. For instance, it might be possible to have a large part of the blueprint service functionality in jaxb-enabled objects that jaxb instantiates from the xml. The init
Re: Whence the geronimo kernel?
David Jencks wrote: So as mentioned below I'm starting to look into the osgi classloading bit, sort of from the bottom. Another approach to many of these issues is perhaps from the top, from the point of view of going from a presumably xml plan to a bunch of objects. I've long thought that it must be possible to leverage jaxb to do most of the heavy lifting here. In particular sxc is some code we can presumably actually extend to do stuff like constructor dependency injection. So another avenue that could perhaps be approached in parallel would be to investigate sxc, jaxb, xbean-spring, xbean-reflect, the blueprint service schema, and jsr299 requirements and see what we can come up with. For instance, it might be possible to have a large part of the blueprint service functionality in jaxb-enabled objects that jaxb instantiates from the xml. The init method could deal with feeding the metadata into the blueprint service core. Maybe we can get sxc to use xbean-reflect to create the objects. Don't fall into the trap of thinking of the blueprint service as just a bean assembler. There's a lot more going on in the runtime beyond just creating class instances and injecting dependencies. There are different sorts of lifecyle considerations (lazy-init, prototype scope), as well as all of the work that goes into supporting the dynamics of the OSGi service registry. So far this is more or less wild speculation in my head... but I think it would be a lot of fun to investigate. I thnk it will be too! thanks david jencks On Mar 4, 2009, at 4:56 PM, David Jencks wrote: Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two plugins. NoClassDefFound errors from an optional jar in a child classloader are also really annoying. Really good things about geronimo I haven't seen elsewhere (at least in one place): - gbean dependencies work across plugins. Dependencies are a unified system, not per-plugin. - gbean dependencies are resolved in the ancestors of a plugin, not server wide. This means that you can't make a partially specified dependency ambiguous by deploying additional plugins. I consider this an extremely important feature for predictability. - plugin dependencies allow assembly of a server from the explicit dependencies which are normally the same as the maven dependencies. Other projects and specs that have stuff we should look into: maven. Maven has a lot better infrastructure for dealing with dependency resolution from partial transitive dependency specification than we do. We should look into using more of their infrastructure. osgi. osgi has a lot of similarities to geronimo. The osgi classloading model is getting a lot of people excited. The import-bundle idea is pretty much the same as our classloader model where every jar is a plugin. I don't know if people are really using the allegedly recommended method of specifying imports and exports and letting the osgi runtime figure out where they come from; this seems worth investigating to me. Also, we get periodic inquiries about when we are going to support osgi and the was ce folks get even more. osgi blueprint service (rfc 124) This appears to be a simple wiring framework for a single plugin. IIUC it uses the osgi service registry for component dependencies between bundles. xbean-spring. I'd be reluctant to try to implement a blueprint service that didn't provide the xbean-spring capabilities really well ee6 dependency injection. EE6 is going to have a pretty sophisticated dependency injection service which we'll need to support anyway. We should try to figure out how much of the core we can assemble using it. Other great stuff we have: xbean-reflect, xbean-finder, xbean-spring These ideas have been floating around in my head for a long time and I've chatted with various people about them occasionally. While more discussion is certainly needed on everything here I need to do some implementation to understand much more. So, what I'm planning to do: Dave's crazy work plan... - Try to use the osgi classloader. I think this involves putting the classloader creation in Configuration into a service. Configurations will turn into osgi bundles. I'll put the Kernel in the osgi ServiceRegistry so the Configuration bundle
Re: Whence the geronimo kernel?
On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote: Hi, So let's agree to disagree for now. This may be related to my personal way of comparing stuff which is pretty much limited to: 1. understand what the requirements are. 2. understand how the technologies support these requirements. I do not need all the bells and whistles that a technology offers to fulfill the requirements. Moreover comparing stuff based on technology differentiators not clearly linked to the requirements is pointless. 3. assess best way forward based on above scoring. Key steps are 1 and 2 where stuff offering all the bells and whistles may well be scored as good as other stuff (I clearly do not support over-bloated stuff...). Obviously, I am keen to be proven wrong and adjust accordingly. So far, I am still saying that the main challenge is to properly tune export/import of dependency declarations. For me, the technology is not the core issue and switching is not going to resolve problems. I agree. I doubt Guillaume has seen your additions to classloading in trunk which allow you to not export packages from a classloader. I haven't tried to prove it mathematically but I think that with this feature the classloading models for geronimo and osgi are equivalent in that you can express the same ability to access classes with either of them. Of course, the notation you use to express this and the specific information included in the configuration is different. I think I probably have the most experience with classloading problems in geronimo and the only real problem that arises is loading a jar in two different classloaders. This can be solved by a classloader-per- jar model which offers no theoretical problems to set up in geronimo but practically would take a lot of work (and maven projects to build a plugin per jar). So I think we'll have to see what kind of problems we get with trying to actually use OSGI. One thing I'd really like actual user data on is how people actually specify osgi classloading info in real life. I'm very aware that in theory you are supposed to specify the package imports and exports for your bundle but I've been told that in real life everyone with a serious osgi project actually specifies the jar dependencies they want using require-bundle. thanks david jencks Thanks, Gianny On 11/03/2009, at 7:11 PM, Guillaume Nodet wrote: On Wed, Mar 11, 2009 at 08:57, Gianny Damour gianny.dam...@optusnet.com.au wrote: Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/import dependency declarations. I have to disagree with that. The CLing mechanism is very different in Geronimo (from what I recall) and OSGi. Geronimo uses a multi-parent classloader style with some nice features to be able to hide / never override + parent or self-first delegation. OSGi CLind is very different: the first one is that you don't really have parent classloaders: the classloader for a given OSGi bundle is calculated wrt to the constraints expressed in the OSGi manifest using imported packages or required bundles. Let's take an example: bundle A needs api packages from bundles B and C implementation classes from bundle B and C needs something from bundle D but with different versions OSGi will be able to handle that because of non tree-like CLind mechanism: if bundle A is wired to bundle B, it does not have to see all the requirements from bundle B, and same for C. Therefore, bundle A can be wired to both B and C without problems because it will not see bundle D at all (so there's no conflicts between the two versions of bundle D). OSGi has a much more powerful CLing mechanism where you can express lots of different constraints. The drawback is that establishing the classloader can take a bit of time, so going to OSGi most certainly leads to a big slowdown at startup while creating the classloaders. Also, OSGi does not really play nicely with the usual JEE way to discover implementations through the MANIFEST/services entries. That's kinda what we've tried to solve in servicemix specs, though I'm not sure if that really applies everywhere because I would imagine the classloaders for EARs are not really OSGi classloaders ... I certainly don't want to say OSGi is not the way to go, just want to make the point that there are benefits but also drawbacks. The JAXB approach to turn xml plans to a bunch of objects is certainly interesting. I believe it is still a technology limiting decision whereby a lot of custom code will have to be
Re: Whence the geronimo kernel?
On Wed, Mar 11, 2009 at 1:29 PM, David Jencks david_jen...@yahoo.com wrote: On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote: Hi, So let's agree to disagree for now. This may be related to my personal way of comparing stuff which is pretty much limited to: 1. understand what the requirements are. 2. understand how the technologies support these requirements. I do not need all the bells and whistles that a technology offers to fulfill the requirements. Moreover comparing stuff based on technology differentiators not clearly linked to the requirements is pointless. 3. assess best way forward based on above scoring. Key steps are 1 and 2 where stuff offering all the bells and whistles may well be scored as good as other stuff (I clearly do not support over-bloated stuff...). Obviously, I am keen to be proven wrong and adjust accordingly. So far, I am still saying that the main challenge is to properly tune export/import of dependency declarations. For me, the technology is not the core issue and switching is not going to resolve problems. I agree. I doubt Guillaume has seen your additions to classloading in trunk which allow you to not export packages from a classloader. I haven't tried to prove it mathematically but I think that with this feature the classloading models for geronimo and osgi are equivalent in that you can express the same ability to access classes with either of them. Of course, the notation you use to express this and the specific information included in the configuration is different. I think I probably have the most experience with classloading problems in geronimo and the only real problem that arises is loading a jar in two different classloaders. This can be solved by a classloader-per-jar model which offers no theoretical problems to set up in geronimo but practically would take a lot of work (and maven projects to build a plugin per jar). So I think we'll have to see what kind of problems we get with trying to actually use OSGI. 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. Jarek
Re: Whence the geronimo kernel?
On Mar 11, 2009, at 11:27 AM, Jarek Gawor wrote: On Wed, Mar 11, 2009 at 1:29 PM, David Jencks david_jen...@yahoo.com wrote: On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote: Hi, So let's agree to disagree for now. This may be related to my personal way of comparing stuff which is pretty much limited to: 1. understand what the requirements are. 2. understand how the technologies support these requirements. I do not need all the bells and whistles that a technology offers to fulfill the requirements. Moreover comparing stuff based on technology differentiators not clearly linked to the requirements is pointless. 3. assess best way forward based on above scoring. Key steps are 1 and 2 where stuff offering all the bells and whistles may well be scored as good as other stuff (I clearly do not support over-bloated stuff...). Obviously, I am keen to be proven wrong and adjust accordingly. So far, I am still saying that the main challenge is to properly tune export/ import of dependency declarations. For me, the technology is not the core issue and switching is not going to resolve problems. I agree. I doubt Guillaume has seen your additions to classloading in trunk which allow you to not export packages from a classloader. I haven't tried to prove it mathematically but I think that with this feature the classloading models for geronimo and osgi are equivalent in that you can express the same ability to access classes with either of them. Of course, the notation you use to express this and the specific information included in the configuration is different. I think I probably have the most experience with classloading problems in geronimo and the only real problem that arises is loading a jar in two different classloaders. This can be solved by a classloader-per- jar model which offers no theoretical problems to set up in geronimo but practically would take a lot of work (and maven projects to build a plugin per jar). So I think we'll have to see what kind of problems we get with trying to actually use OSGI. 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. 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. 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. rant coherency=questionable To me it seems like there are two opposing forces at work here. On the one hand you want your code to be able to run in a variety of environments. On the other hand you want to be able to know and specify stuff about the environment. The environment basically boils down to a graph of a bunch of jars. (with osgi, the classes you specifiy in import/export requirements are in fact coming from some jar, somewhere). So how are you going to specify that graph? How are you going to make it flexible? What's the boundary between your app and the outside world? Maven and geronimo deal with this by having your app specify the jars it wants and by allowing some way to substitute jars (artifact-aliases
Re: Whence the geronimo kernel?
On Wed, Mar 11, 2009 at 20:30, David Jencks david_jen...@yahoo.com wrote: On Mar 11, 2009, at 11:27 AM, Jarek Gawor wrote: On Wed, Mar 11, 2009 at 1:29 PM, David Jencks david_jen...@yahoo.com wrote: On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote: Hi, So let's agree to disagree for now. This may be related to my personal way of comparing stuff which is pretty much limited to: 1. understand what the requirements are. 2. understand how the technologies support these requirements. I do not need all the bells and whistles that a technology offers to fulfill the requirements. Moreover comparing stuff based on technology differentiators not clearly linked to the requirements is pointless. 3. assess best way forward based on above scoring. Key steps are 1 and 2 where stuff offering all the bells and whistles may well be scored as good as other stuff (I clearly do not support over-bloated stuff...). Obviously, I am keen to be proven wrong and adjust accordingly. So far, I am still saying that the main challenge is to properly tune export/import of dependency declarations. For me, the technology is not the core issue and switching is not going to resolve problems. I agree. I doubt Guillaume has seen your additions to classloading in trunk which allow you to not export packages from a classloader. I haven't tried to prove it mathematically but I think that with this feature the classloading models for geronimo and osgi are equivalent in that you can express the same ability to access classes with either of them. Of course, the notation you use to express this and the specific information included in the configuration is different. I think I probably have the most experience with classloading problems in geronimo and the only real problem that arises is loading a jar in two different classloaders. This can be solved by a classloader-per-jar model which offers no theoretical problems to set up in geronimo but practically would take a lot of work (and maven projects to build a plugin per jar). So I think we'll have to see what kind of problems we get with trying to actually use OSGI. 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. 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. 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. FWIW, the bundle plugin does not really use maven dependencies. What happens is that the code that goes inside the osgi bundle is introspected to find all the list of all packages that are needed. This list is then converted into the OSGi manifest import along with any additional constraints or modification of those default constrainst. At some point (not sure if this has been done yet), maven optional dependencies should be used to specify optional package imports, but even if you miss a dependency or add some that are not really needed, it won't really affect the osgi metadata generated. rant coherency=questionable To me it seems like there are two opposing forces at work
Re: Whence the geronimo kernel?
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
Re: Whence the geronimo kernel?
On Mar 12, 2009, at 1:26 AM, David Jencks wrote: I believe that xbean-spring is still unnecessary noisy when compared to something like the Spring Bean Builder (http://www.grails.org/Spring+Bean+Builder ). That looks nice, but is there any syntax validation possible? I'm pretty much unwilling to use groovy for anything at this point due to my bad experiences with lack of pre-runtime syntax validation and unclear error messages writing some simple gshell commands. xml is really horrible but most editors do support validation against a schema. On the other hand, I think we could come up with something even shorter, clearer, and to the point, with syntax validation, using scala. Why Scala? --jason
Re: Whence the geronimo kernel?
Absolutely correct, our goal is to build a JEE server, but not a new osgi implementation. So the problem is if we need a OSGi way instead of the current gbean way. I totally support to transfer our core to the osgi based, like what eclipse did in its 3.0 M5. Ideally, also hope all the plugins could be modified as a osgi bundle. Like what we have, JEE application is not our plugins, but we can convert them to plugins, that means we also can convert them to osgi bundles. So the only thing is we need a mechanism to map our maven-style dependencies in the deployment plan to osgi-style dependencies. Rex. 2009/3/6 Juergen Weber webe...@gmail.com I as user see Geronimo not as GBeans nor as OSGI server, I see it as JEE server. So my requirements are to have a server - that runs standard JEE applications - without changes necessary - on an Apache licensed server Therefore the change to OSGI should be transparent to users, I wouldn't want to have to specify OSGI dependencies for JEE applications. If there is OSGI below, fine. If I can use it, fine. But it should not be necessary for standard JEE apps. Thanks, Juergen -- View this message in context: http://www.nabble.com/Whence-the-geronimo-kernel--tp22343125s134p22372881.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: Whence the geronimo kernel?
So as mentioned below I'm starting to look into the osgi classloading bit, sort of from the bottom. Another approach to many of these issues is perhaps from the top, from the point of view of going from a presumably xml plan to a bunch of objects. I've long thought that it must be possible to leverage jaxb to do most of the heavy lifting here. In particular sxc is some code we can presumably actually extend to do stuff like constructor dependency injection. So another avenue that could perhaps be approached in parallel would be to investigate sxc, jaxb, xbean-spring, xbean- reflect, the blueprint service schema, and jsr299 requirements and see what we can come up with. For instance, it might be possible to have a large part of the blueprint service functionality in jaxb-enabled objects that jaxb instantiates from the xml. The init method could deal with feeding the metadata into the blueprint service core. Maybe we can get sxc to use xbean-reflect to create the objects. So far this is more or less wild speculation in my head... but I think it would be a lot of fun to investigate. thanks david jencks On Mar 4, 2009, at 4:56 PM, David Jencks wrote: Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two plugins. NoClassDefFound errors from an optional jar in a child classloader are also really annoying. Really good things about geronimo I haven't seen elsewhere (at least in one place): - gbean dependencies work across plugins. Dependencies are a unified system, not per-plugin. - gbean dependencies are resolved in the ancestors of a plugin, not server wide. This means that you can't make a partially specified dependency ambiguous by deploying additional plugins. I consider this an extremely important feature for predictability. - plugin dependencies allow assembly of a server from the explicit dependencies which are normally the same as the maven dependencies. Other projects and specs that have stuff we should look into: maven. Maven has a lot better infrastructure for dealing with dependency resolution from partial transitive dependency specification than we do. We should look into using more of their infrastructure. osgi. osgi has a lot of similarities to geronimo. The osgi classloading model is getting a lot of people excited. The import- bundle idea is pretty much the same as our classloader model where every jar is a plugin. I don't know if people are really using the allegedly recommended method of specifying imports and exports and letting the osgi runtime figure out where they come from; this seems worth investigating to me. Also, we get periodic inquiries about when we are going to support osgi and the was ce folks get even more. osgi blueprint service (rfc 124) This appears to be a simple wiring framework for a single plugin. IIUC it uses the osgi service registry for component dependencies between bundles. xbean-spring. I'd be reluctant to try to implement a blueprint service that didn't provide the xbean-spring capabilities really well ee6 dependency injection. EE6 is going to have a pretty sophisticated dependency injection service which we'll need to support anyway. We should try to figure out how much of the core we can assemble using it. Other great stuff we have: xbean-reflect, xbean-finder, xbean-spring These ideas have been floating around in my head for a long time and I've chatted with various people about them occasionally. While more discussion is certainly needed on everything here I need to do some implementation to understand much more. So, what I'm planning to do: Dave's crazy work plan... - Try to use the osgi classloader. I think this involves putting the classloader creation in Configuration into a service. Configurations will turn into osgi bundles. I'll put the Kernel in the osgi ServiceRegistry so the Configuration bundle activator should be able to use it to resolve cross-plugin dependencies. - try to figure out how maven dependency resolution fits into osgi. - see if eclipse p2 is relevant for provisioning geronimo repositories at this point I think geronimo would be running on osgi, still using gbeans. - look into relaxing the gbean framework so it is more plugin-at-a- time rather
Re: Whence the geronimo kernel?
I as user see Geronimo not as GBeans nor as OSGI server, I see it as JEE server. So my requirements are to have a server - that runs standard JEE applications - without changes necessary - on an Apache licensed server Therefore the change to OSGI should be transparent to users, I wouldn't want to have to specify OSGI dependencies for JEE applications. If there is OSGI below, fine. If I can use it, fine. But it should not be necessary for standard JEE apps. Thanks, Juergen -- View this message in context: http://www.nabble.com/Whence-the-geronimo-kernel--tp22343125s134p22372881.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: Whence the geronimo kernel?
I think this is a fair requirement from.I also think the OSGi community is aware of this requirement. For example, the web container in OSGi spec that I am following, it requires the web container in OSGi to support deployment of traditional war file as well as the OSGi bundle war file. Lin On Fri, Mar 6, 2009 at 8:52 AM, Juergen Weber webe...@gmail.com wrote: Therefore the change to OSGI should be transparent to users, I wouldn't want to have to specify OSGI dependencies for JEE applications. If there is OSGI below, fine. If I can use it, fine. But it should not be necessary for standard JEE apps. Thanks, Juergen -- View this message in context: http://www.nabble.com/Whence-the-geronimo-kernel--tp22343125s134p22372881.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: Whence the geronimo kernel?
On Mar 6, 2009, at 8:52 AM, Juergen Weber wrote: I as user see Geronimo not as GBeans nor as OSGI server, I see it as JEE server. So my requirements are to have a server - that runs standard JEE applications - without changes necessary - on an Apache licensed server Therefore the change to OSGI should be transparent to users, I wouldn't want to have to specify OSGI dependencies for JEE applications. If there is OSGI below, fine. If I can use it, fine. But it should not be necessary for standard JEE apps. Absolutely agree. To the point that I might not have thought to bother stating it -- so I'm glad you did... ;-) I would expect that OSGi features would become available to JEE users, but they'd not be forced or even expected to use them. --kevan
Re: Whence the geronimo kernel?
We've spoken about this, in the past. I'm certainly in favor of exploring this... On Mar 4, 2009, at 7:56 PM, David Jencks wrote: Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. Agreed. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two plugins. NoClassDefFound errors from an optional jar in a child classloader are also really annoying. Classloaders certainly can be hard. In some ways, however, I think we'll be trading one set of problems for another. Hopefully, the net sum is in our benefit... Really good things about geronimo I haven't seen elsewhere (at least in one place): - gbean dependencies work across plugins. Dependencies are a unified system, not per-plugin. - gbean dependencies are resolved in the ancestors of a plugin, not server wide. This means that you can't make a partially specified dependency ambiguous by deploying additional plugins. I consider this an extremely important feature for predictability. - plugin dependencies allow assembly of a server from the explicit dependencies which are normally the same as the maven dependencies. Agreed. Other projects and specs that have stuff we should look into: maven. Maven has a lot better infrastructure for dealing with dependency resolution from partial transitive dependency specification than we do. We should look into using more of their infrastructure. osgi. osgi has a lot of similarities to geronimo. The osgi classloading model is getting a lot of people excited. The import- bundle idea is pretty much the same as our classloader model where every jar is a plugin. I don't know if people are really using the allegedly recommended method of specifying imports and exports and letting the osgi runtime figure out where they come from; this seems worth investigating to me. Also, we get periodic inquiries about when we are going to support osgi and the was ce folks get even more. Right. So, this is a pretty strong motivation, IMO. Users are looking for an OSGi standards-based mechanism for installing services/ applications, without having to learn/conform to Geronimo techniques. osgi blueprint service (rfc 124) This appears to be a simple wiring framework for a single plugin. IIUC it uses the osgi service registry for component dependencies between bundles. xbean-spring. I'd be reluctant to try to implement a blueprint service that didn't provide the xbean-spring capabilities really well ee6 dependency injection. EE6 is going to have a pretty sophisticated dependency injection service which we'll need to support anyway. We should try to figure out how much of the core we can assemble using it. Other great stuff we have: xbean-reflect, xbean-finder, xbean-spring Agreed. These ideas have been floating around in my head for a long time and I've chatted with various people about them occasionally. While more discussion is certainly needed on everything here I need to do some implementation to understand much more. So, what I'm planning to do: Dave's crazy work plan... - Try to use the osgi classloader. I think this involves putting the classloader creation in Configuration into a service. Configurations will turn into osgi bundles. I'll put the Kernel in the osgi ServiceRegistry so the Configuration bundle activator should be able to use it to resolve cross-plugin dependencies. - try to figure out how maven dependency resolution fits into osgi. - see if eclipse p2 is relevant for provisioning geronimo repositories at this point I think geronimo would be running on osgi, still using gbeans. - look into relaxing the gbean framework so it is more plugin-at-a- time rather than gbean-at-a-time - see how that differs from the blueprint service, ee DI, and xbean- spring. Try to support all of these at once. Thoughts? Counter proposals? Anyone interested? Sounds like a good start. I think there'll be a lot of learning/ discovery that will be taking place. So, prolly not much point in over- refining, now. Definitely interested. However, likely to be somewhat time- constrained. Will do what I can... --kevan
Re: Whence the geronimo kernel?
The one difficulty I see in moving from the current Geronimo classloading model to the OSGi model is dealing with the change in granularity. In the current model, the granularity is at the jar level and using the one-classloader-per-jar model, you get all of the classes contained in the jar. This is generally the source of the various class loading conflict we see with Geronimo. Different jars might contain their own versions of classes, creating the conflict. With the OSGi model, each bundle explicitly specifies its classloading dependencies in the form of package imports and also specifies which classes it makes available for others to use as package exports. Any packages not specified as exports are private to the bundle scope and are only directly visible to the bundle itself. The bnd tools created by Peter Kriens is a good step toward converting jars into bundles. It examines all of the class files contained in a jar and figures out which files need to be imported from other source and constructs the appropriate headers. This works ok if the bundle doesn't need to export any packages. If exports are required, then additional information about the jar is required. There are a couple of additional downsides to the static analysys: 1) This type of analysis can detect which packages are required, but doesn't tell you anything about which versions of the packages are needed. This can probably be sorted out by coupling the analysis information with information from the maven-style dependencies. That is, your jar requires package org.apache.foo.bar and you specify you have a dependency on org.apache.foo-1.3.2 which happens to export org.apache.foo.bar package, so your bundle import dependency for org.apache.foo.bar is set to the 1.3.2 version level. 2) It's not very good at determining dynamic classloading dependencies. This also requires some additional metadata to indicate certain packages are going to be required by the application. Rick David Jencks wrote: Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two plugins. NoClassDefFound errors from an optional jar in a child classloader are also really annoying. Really good things about geronimo I haven't seen elsewhere (at least in one place): - gbean dependencies work across plugins. Dependencies are a unified system, not per-plugin. - gbean dependencies are resolved in the ancestors of a plugin, not server wide. This means that you can't make a partially specified dependency ambiguous by deploying additional plugins. I consider this an extremely important feature for predictability. - plugin dependencies allow assembly of a server from the explicit dependencies which are normally the same as the maven dependencies. Other projects and specs that have stuff we should look into: maven. Maven has a lot better infrastructure for dealing with dependency resolution from partial transitive dependency specification than we do. We should look into using more of their infrastructure. osgi. osgi has a lot of similarities to geronimo. The osgi classloading model is getting a lot of people excited. The import-bundle idea is pretty much the same as our classloader model where every jar is a plugin. I don't know if people are really using the allegedly recommended method of specifying imports and exports and letting the osgi runtime figure out where they come from; this seems worth investigating to me. Also, we get periodic inquiries about when we are going to support osgi and the was ce folks get even more. osgi blueprint service (rfc 124) This appears to be a simple wiring framework for a single plugin. IIUC it uses the osgi service registry for component dependencies between bundles. xbean-spring. I'd be reluctant to try to implement a blueprint service that didn't provide the xbean-spring capabilities really well ee6 dependency injection. EE6 is going to have a pretty sophisticated dependency injection service which we'll need to support anyway. We should try to figure out how much of the core we can assemble using it. Other great stuff we have: xbean-reflect, xbean-finder, xbean-spring These ideas have been floating around in my head for a long time and I've chatted with various people about them occasionally. While more
Re: Whence the geronimo kernel?
Agree that it is time to start looking at OSGi and thanks for kicking this off! -Donald David Jencks wrote: Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two plugins. NoClassDefFound errors from an optional jar in a child classloader are also really annoying. Really good things about geronimo I haven't seen elsewhere (at least in one place): - gbean dependencies work across plugins. Dependencies are a unified system, not per-plugin. - gbean dependencies are resolved in the ancestors of a plugin, not server wide. This means that you can't make a partially specified dependency ambiguous by deploying additional plugins. I consider this an extremely important feature for predictability. - plugin dependencies allow assembly of a server from the explicit dependencies which are normally the same as the maven dependencies. Other projects and specs that have stuff we should look into: maven. Maven has a lot better infrastructure for dealing with dependency resolution from partial transitive dependency specification than we do. We should look into using more of their infrastructure. osgi. osgi has a lot of similarities to geronimo. The osgi classloading model is getting a lot of people excited. The import-bundle idea is pretty much the same as our classloader model where every jar is a plugin. I don't know if people are really using the allegedly recommended method of specifying imports and exports and letting the osgi runtime figure out where they come from; this seems worth investigating to me. Also, we get periodic inquiries about when we are going to support osgi and the was ce folks get even more. osgi blueprint service (rfc 124) This appears to be a simple wiring framework for a single plugin. IIUC it uses the osgi service registry for component dependencies between bundles. xbean-spring. I'd be reluctant to try to implement a blueprint service that didn't provide the xbean-spring capabilities really well ee6 dependency injection. EE6 is going to have a pretty sophisticated dependency injection service which we'll need to support anyway. We should try to figure out how much of the core we can assemble using it. Other great stuff we have: xbean-reflect, xbean-finder, xbean-spring These ideas have been floating around in my head for a long time and I've chatted with various people about them occasionally. While more discussion is certainly needed on everything here I need to do some implementation to understand much more. So, what I'm planning to do: Dave's crazy work plan... - Try to use the osgi classloader. I think this involves putting the classloader creation in Configuration into a service. Configurations will turn into osgi bundles. I'll put the Kernel in the osgi ServiceRegistry so the Configuration bundle activator should be able to use it to resolve cross-plugin dependencies. - try to figure out how maven dependency resolution fits into osgi. - see if eclipse p2 is relevant for provisioning geronimo repositories at this point I think geronimo would be running on osgi, still using gbeans. - look into relaxing the gbean framework so it is more plugin-at-a-time rather than gbean-at-a-time - see how that differs from the blueprint service, ee DI, and xbean-spring. Try to support all of these at once. Thoughts? Counter proposals? Anyone interested? many thanks david jencks
Re: Whence the geronimo kernel?
Hi David, I think this is a good move and worthy investigation! I have some comments below. On Wed, Mar 4, 2009 at 7:56 PM, David Jencks david_jen...@yahoo.com wrote: Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two plugins. NoClassDefFound errors from an optional jar in a child classloader are also really annoying. Really good things about geronimo I haven't seen elsewhere (at least in one place): - gbean dependencies work across plugins. Dependencies are a unified system, not per-plugin. - gbean dependencies are resolved in the ancestors of a plugin, not server wide. This means that you can't make a partially specified dependency ambiguous by deploying additional plugins. I consider this an extremely important feature for predictability. - plugin dependencies allow assembly of a server from the explicit dependencies which are normally the same as the maven dependencies. Other projects and specs that have stuff we should look into: maven. Maven has a lot better infrastructure for dealing with dependency resolution from partial transitive dependency specification than we do. We should look into using more of their infrastructure. osgi. osgi has a lot of similarities to geronimo. The osgi classloading model is getting a lot of people excited. The import-bundle idea is pretty much the same as our classloader model where every jar is a plugin. I don't know if people are really using the allegedly recommended method of specifying imports and exports and letting the osgi runtime figure out where they come from; this seems worth investigating to me. Also, we get periodic inquiries about when we are going to support osgi and the was ce folks get even more. I have used the Import-Package function. The bundle I was trying to build can get javax.transaction pacakge from the J2SE or the geronimo's jta spec jar, so I had to specify the exact version of the javax.transaction package in the Import-Package attribute and let the bnd tool figure out the rest. This works well for me. The bnd tool cannot auto-discover this so this have to be done manually AFAIK. osgi blueprint service (rfc 124) This appears to be a simple wiring framework for a single plugin. IIUC it uses the osgi service registry for component dependencies between bundles. xbean-spring. I'd be reluctant to try to implement a blueprint service that didn't provide the xbean-spring capabilities really well ee6 dependency injection. EE6 is going to have a pretty sophisticated dependency injection service which we'll need to support anyway. We should try to figure out how much of the core we can assemble using it. Other great stuff we have: xbean-reflect, xbean-finder, xbean-spring These ideas have been floating around in my head for a long time and I've chatted with various people about them occasionally. While more discussion is certainly needed on everything here I need to do some implementation to understand much more. So, what I'm planning to do: Dave's crazy work plan... - Try to use the osgi classloader. I think this involves putting the classloader creation in Configuration into a service. Configurations will turn into osgi bundles. I'll put the Kernel in the osgi ServiceRegistry so the Configuration bundle activator should be able to use it to resolve cross-plugin dependencies. - try to figure out how maven dependency resolution fits into osgi. - see if eclipse p2 is relevant for provisioning geronimo repositories Osgi is building a bundle repository RFC (think it is rfc 112). I haven't looked into detail so not sure if it is related to maven at all, but you may want to check it out. at this point I think geronimo would be running on osgi, still using gbeans. Are you envisioning all the geronimo plugins converted to OSGi bundles to run in the OSGi based kernel? - look into relaxing the gbean framework so it is more plugin-at-a-time rather than gbean-at-a-time - see how that differs from the blueprint service, ee DI, and xbean-spring. Try to support all of these at once. Thoughts? Counter proposals? Anyone interested? many thanks david jencks
Whence the geronimo kernel?
Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two plugins. NoClassDefFound errors from an optional jar in a child classloader are also really annoying. Really good things about geronimo I haven't seen elsewhere (at least in one place): - gbean dependencies work across plugins. Dependencies are a unified system, not per-plugin. - gbean dependencies are resolved in the ancestors of a plugin, not server wide. This means that you can't make a partially specified dependency ambiguous by deploying additional plugins. I consider this an extremely important feature for predictability. - plugin dependencies allow assembly of a server from the explicit dependencies which are normally the same as the maven dependencies. Other projects and specs that have stuff we should look into: maven. Maven has a lot better infrastructure for dealing with dependency resolution from partial transitive dependency specification than we do. We should look into using more of their infrastructure. osgi. osgi has a lot of similarities to geronimo. The osgi classloading model is getting a lot of people excited. The import- bundle idea is pretty much the same as our classloader model where every jar is a plugin. I don't know if people are really using the allegedly recommended method of specifying imports and exports and letting the osgi runtime figure out where they come from; this seems worth investigating to me. Also, we get periodic inquiries about when we are going to support osgi and the was ce folks get even more. osgi blueprint service (rfc 124) This appears to be a simple wiring framework for a single plugin. IIUC it uses the osgi service registry for component dependencies between bundles. xbean-spring. I'd be reluctant to try to implement a blueprint service that didn't provide the xbean-spring capabilities really well ee6 dependency injection. EE6 is going to have a pretty sophisticated dependency injection service which we'll need to support anyway. We should try to figure out how much of the core we can assemble using it. Other great stuff we have: xbean-reflect, xbean-finder, xbean-spring These ideas have been floating around in my head for a long time and I've chatted with various people about them occasionally. While more discussion is certainly needed on everything here I need to do some implementation to understand much more. So, what I'm planning to do: Dave's crazy work plan... - Try to use the osgi classloader. I think this involves putting the classloader creation in Configuration into a service. Configurations will turn into osgi bundles. I'll put the Kernel in the osgi ServiceRegistry so the Configuration bundle activator should be able to use it to resolve cross-plugin dependencies. - try to figure out how maven dependency resolution fits into osgi. - see if eclipse p2 is relevant for provisioning geronimo repositories at this point I think geronimo would be running on osgi, still using gbeans. - look into relaxing the gbean framework so it is more plugin-at-a- time rather than gbean-at-a-time - see how that differs from the blueprint service, ee DI, and xbean- spring. Try to support all of these at once. Thoughts? Counter proposals? Anyone interested? many thanks david jencks
Re: Whence the geronimo kernel?
It is a good idea. I encounter some similar issues about the multiparent classloader. From the pom.xml, currently, it is hard to know which jar is in the classpath. The dependies between the configurations are also too complex, I notice that the restart/reload codes in the configurationManager is very very ... Maybe we could replace all the codes in the configurationManager, and just delegate it to the OSGI module/lifecycle layer. Thanks ! 2009/3/5 David Jencks david_jen...@yahoo.com Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two plugins. NoClassDefFound errors from an optional jar in a child classloader are also really annoying. Really good things about geronimo I haven't seen elsewhere (at least in one place): - gbean dependencies work across plugins. Dependencies are a unified system, not per-plugin. - gbean dependencies are resolved in the ancestors of a plugin, not server wide. This means that you can't make a partially specified dependency ambiguous by deploying additional plugins. I consider this an extremely important feature for predictability. - plugin dependencies allow assembly of a server from the explicit dependencies which are normally the same as the maven dependencies. Other projects and specs that have stuff we should look into: maven. Maven has a lot better infrastructure for dealing with dependency resolution from partial transitive dependency specification than we do. We should look into using more of their infrastructure. osgi. osgi has a lot of similarities to geronimo. The osgi classloading model is getting a lot of people excited. The import-bundle idea is pretty much the same as our classloader model where every jar is a plugin. I don't know if people are really using the allegedly recommended method of specifying imports and exports and letting the osgi runtime figure out where they come from; this seems worth investigating to me. Also, we get periodic inquiries about when we are going to support osgi and the was ce folks get even more. osgi blueprint service (rfc 124) This appears to be a simple wiring framework for a single plugin. IIUC it uses the osgi service registry for component dependencies between bundles. xbean-spring. I'd be reluctant to try to implement a blueprint service that didn't provide the xbean-spring capabilities really well ee6 dependency injection. EE6 is going to have a pretty sophisticated dependency injection service which we'll need to support anyway. We should try to figure out how much of the core we can assemble using it. Other great stuff we have: xbean-reflect, xbean-finder, xbean-spring These ideas have been floating around in my head for a long time and I've chatted with various people about them occasionally. While more discussion is certainly needed on everything here I need to do some implementation to understand much more. So, what I'm planning to do: Dave's crazy work plan... - Try to use the osgi classloader. I think this involves putting the classloader creation in Configuration into a service. Configurations will turn into osgi bundles. I'll put the Kernel in the osgi ServiceRegistry so the Configuration bundle activator should be able to use it to resolve cross-plugin dependencies. - try to figure out how maven dependency resolution fits into osgi. - see if eclipse p2 is relevant for provisioning geronimo repositories at this point I think geronimo would be running on osgi, still using gbeans. - look into relaxing the gbean framework so it is more plugin-at-a-time rather than gbean-at-a-time - see how that differs from the blueprint service, ee DI, and xbean-spring. Try to support all of these at once. Thoughts? Counter proposals? Anyone interested? many thanks david jencks -- Ivan
Re: Whence the geronimo kernel?
This is defintely a good move! How will that affect the programming model around Geronimo? Obviously some users are not happy with the complexity of the deployment plan [1]. -Jack [1] http://www.nabble.com/your-current-Geronimo-evaluation-td22329850s134.html 2009/3/5 Ivan xhh...@gmail.com It is a good idea. I encounter some similar issues about the multiparent classloader. From the pom.xml, currently, it is hard to know which jar is in the classpath. The dependies between the configurations are also too complex, I notice that the restart/reload codes in the configurationManager is very very ... Maybe we could replace all the codes in the configurationManager, and just delegate it to the OSGI module/lifecycle layer. Thanks ! 2009/3/5 David Jencks david_jen...@yahoo.com Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two plugins. NoClassDefFound errors from an optional jar in a child classloader are also really annoying. Really good things about geronimo I haven't seen elsewhere (at least in one place): - gbean dependencies work across plugins. Dependencies are a unified system, not per-plugin. - gbean dependencies are resolved in the ancestors of a plugin, not server wide. This means that you can't make a partially specified dependency ambiguous by deploying additional plugins. I consider this an extremely important feature for predictability. - plugin dependencies allow assembly of a server from the explicit dependencies which are normally the same as the maven dependencies. Other projects and specs that have stuff we should look into: maven. Maven has a lot better infrastructure for dealing with dependency resolution from partial transitive dependency specification than we do. We should look into using more of their infrastructure. osgi. osgi has a lot of similarities to geronimo. The osgi classloading model is getting a lot of people excited. The import-bundle idea is pretty much the same as our classloader model where every jar is a plugin. I don't know if people are really using the allegedly recommended method of specifying imports and exports and letting the osgi runtime figure out where they come from; this seems worth investigating to me. Also, we get periodic inquiries about when we are going to support osgi and the was ce folks get even more. osgi blueprint service (rfc 124) This appears to be a simple wiring framework for a single plugin. IIUC it uses the osgi service registry for component dependencies between bundles. xbean-spring. I'd be reluctant to try to implement a blueprint service that didn't provide the xbean-spring capabilities really well ee6 dependency injection. EE6 is going to have a pretty sophisticated dependency injection service which we'll need to support anyway. We should try to figure out how much of the core we can assemble using it. Other great stuff we have: xbean-reflect, xbean-finder, xbean-spring These ideas have been floating around in my head for a long time and I've chatted with various people about them occasionally. While more discussion is certainly needed on everything here I need to do some implementation to understand much more. So, what I'm planning to do: Dave's crazy work plan... - Try to use the osgi classloader. I think this involves putting the classloader creation in Configuration into a service. Configurations will turn into osgi bundles. I'll put the Kernel in the osgi ServiceRegistry so the Configuration bundle activator should be able to use it to resolve cross-plugin dependencies. - try to figure out how maven dependency resolution fits into osgi. - see if eclipse p2 is relevant for provisioning geronimo repositories at this point I think geronimo would be running on osgi, still using gbeans. - look into relaxing the gbean framework so it is more plugin-at-a-time rather than gbean-at-a-time - see how that differs from the blueprint service, ee DI, and xbean-spring. Try to support all of these at once. Thoughts? Counter proposals? Anyone interested? many thanks david jencks -- Ivan
