geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: Future directions towards better osgi integration
Date Fri, 09 Jul 2010 09:17:52 GMT
For the item 3, especially for the classloader archetecture, I found that it
is difficult to totally depend on the bundle classloader. Also, I am not
sure scan all the jar files in the lib folder is reasonable, even we could
build the import/export packages list, we might also have problems while
reading resources from jar files in the lib folders via classloader (the
same issue with service api in jdk). I am thinking to add a proxy
classloader to separate the web application from the native bundle
classloader.  Aslo, we could hack the classloader in this proxy classloader
to load those classes directly from the bundle hosts the library
jars/ejb/ra, which means the import/export will not be used. In this way,
maybe we could make those java ee applications live more happier in osgi
world.

2010/7/8 David Jencks <david_jencks@yahoo.com>

>
> On Jul 6, 2010, at 4:13 PM, David Jencks wrote:
>
> > 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.
>
> Another point..... currently we use our directed acyclic graph of plugins
> to determine which gbeans are visible to references in a plugin.  This
> mechanism is just not going to be present in the future.  We can think about
> trying to use subsystems or something else, but for now we might be able to
> just make all the gbean refeences global, which will simplify stuff a lot.
>  It may break systems that have multiple possible services satisfying a
> reference, but we'll have to find a way to deal with that anyway.
>
> thanks
> david jencks
>
>
> >
> > thanks
> > david jencks
> >
>
>


-- 
Ivan

Mime
View raw message