Whence the geronimo kernel?

[djencks]

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 Xu]

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_jencks@...>

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

[Jack Cai]

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 <xhhsld@...>

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_jencks@...>

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

[kevan]

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

[Rick McGuire]

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
> 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
>
>

[Donald Woods-2]

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
>
>

[Lin Sun-2]

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_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.

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
>
>

[Juergen Weber]

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

[Lin Sun-2]

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 <weberjn@...> 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.
>
>

[kevan]

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

[Rex Wang-2]

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 <weberjn@...>

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.

[djencks]

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 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
>

[Gianny Damour-2]

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
>> 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
>>
>

[gnodet]

On Wed, Mar 11, 2009 at 08:57, Gianny Damour <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.

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 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

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

[Gianny Damour-2]

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.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.
>
> 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 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
>
>
>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>

[Rick McGuire]

Guillaume Nodet wrote:

>
>
> On Wed, Mar 11, 2009 at 08:57, Gianny Damour
> <gianny.damour@... <mailto: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.
>
>
> 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" 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 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
>
>
>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>

[Rick McGuire]

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 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
>>
>
>

[djencks]

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.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.
>>
>> 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 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
>>
>>
>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>>
>

[djencks]

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.

On the other hand, I think we could come up with something even  
shorter, clearer, and to the point, with syntax validation, using scala.

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.
>>>
>>> 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
>>>
>>
>

[Jarek Gawor-2]

On Wed, Mar 11, 2009 at 1:29 PM, David Jencks <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.

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