geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: Future directions towards better osgi integration
Date Wed, 07 Jul 2010 07:20:13 GMT
1, 2 and 3 sounds pretty good. Have not enough knowledge to judge 4 and 5.

LieGrue,
strub

--- On Tue, 7/6/10, David Jencks <david_jencks@yahoo.com> wrote:

> From: David Jencks <david_jencks@yahoo.com>
> Subject: Future directions towards better osgi integration
> To: "Geronimo Dev List (JIRA)" <dev@geronimo.apache.org>
> Date: Tuesday, July 6, 2010, 11:13 PM
> What we have now in trunk more or
> less works OK but does not really take good advantage of
> many osgi standard features, instead often duplicating some
> functionality with stuff ported from earlier geronimo
> versions.  Here are a few ideas on how we might be more
> osgi friendly.
> 
> 
> 1. use osgi jndi to back up our java: jndi namespace. 
> Right now we're constructing our own references that poke
> around in the geronimo kernel gbean registry to find the
> target.  This is very similar to what the osgi:
> namespace does in the osgi service registry.  I think
> we can bind jndi links to the osgi jndi name and get into
> the service registry that way.  We're already binding
> connection factories in the service registry, we can do
> admin objects and ejbs pretty easily too.  I'm
> experimenting with this in connector.
> 
> 2. Use karaf features instead of our plugin dependency
> management.  Currently these are very similar, our
> addition is to unpack stuff from bundles on installation if
> requested.  We can do this independently of the
> features functionality, and we can talk to karaf about
> whether this unpack idea would be good there.
> 
> 3. Build ee artifacts into eba's.  Although it isn't
> really counter-spec to through everything except app clients
> in an ear into one bundle/classloader, it doesn't seem
> ideal.  I think one bundle per module (and possibly one
> additional bundle per @DataSource annotation) will be more
> flexible.  BTW we have a problem currently in getting
> the app and global jndi contexts onto the app client. 
> If we deploy each rar and datasource into a separate bundle
> we can just start these on the app client too so the jndi
> stuff will be avaliable.
> 
> 4. Replace gbeans with some combination of blueprint,
> blueprint namespace handlers, and whatever else is
> needed.  The plugins that use plain gbeans can be
> converted to blueprint pretty easily.  Our use of
> gbeans to wrap EE application components is less
> straightforward.  We may be able to generate fairly
> simple blueprint plans in a special namespace that will give
> access to the appropriate bundles containing the container
> classes.  This will take some investigation.  I
> wonder if processing the xml into a neutral data tree like
> the openejb info tree would be a useful approach.
> 
> I've worried that (4) will take months and break everything
> from when it starts to when it's complete.  However I
> am now starting to think that if we do 1-3 first there's a
> small chance that (4) can be done plugin-by-plugin without
> completely breaking the server.
> 
> 5. Figure out how to support jsr-77 (ee management) without
> gbeans.  One of the basic functions of gbeans was to
> support jsr-77 directly.  Without them we'll have to
> figure out what mbeans to register and how to do it. 
> Since the jsr-77 mbean structure is often totally nuts, this
> will probably simplify the working code a bit, but will add
> another layer of goo.  On the other hand we can
> presumably make it optional.
> 
> thanks
> david jencks
> 
> 


      

Mime
View raw message