Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:From:Content-Type:Content-Transfer-Encoding:Subject:Date:Message-Id:To:Mime-Version:X-Mailer;
  b=jPxzTAXWhNPhh/vu4mfx9XmYwciOtJJQOiqUDli+raQxhA3tXvHijIkRz6Mn/eJ+t+v76YWTpuGMxc1kFAku6Gr5dD2SaHmVgV0GnCaLwfG/egISS6gLPqOju+Iqj6V8lHrlqnZgLLdf1wOrlZ3HCF82xoKt/Ci9DhSmWZ6Wnyo=
  ;
From: David Jencks <david_jencks@yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: Future directions towards better osgi integration
Date: Tue, 6 Jul 2010 16:13:55 -0700
Message-Id: <6DEAC043-60E5-4760-BAD9-7EC237188CE5@yahoo.com>
To: "Geronimo Dev List \(JIRA\)" <dev@geronimo.apache.org>
Mime-Version: 1.0 (Apple Message framework v1081)

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