geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacek Laskowski" <>
Subject Re: [long] OSGi overview (was Re: Geronimo/Equinox integration status?)
Date Fri, 07 Jul 2006 20:22:34 GMT
Hi Toby,

Thanks for the gentle introduction to OSGi. It's the shortest yet very
informative description of OSGi I could read and really enjoyed it.
Much appreciated.

Would you point out another short introductory material about it or
just suggest I'll simply take a look at the spec to get the gist of


On 7/7/06, toby cabot <> wrote:
> Jacek,
> Thanks for the info.
> On Wed, Jul 05, 2006 at 10:06:46PM +0200, Jacek Laskowski wrote:
> > On 7/5/06, toby cabot <> wrote:
> > >What's the status of the Geronimo/Equinox (OSGi server) integration?
> >
> > Dunno, but great you've asked as it was one of the questions during
> > the Apache Geronimo panel at TSSJS in Barcelona, which James S.
> > answered positively, i.e. there's a fit for it in Geronimo and it
> > should or will be soon available. I think Dain mentioned it a couple
> > of times (it was something about classloading architecture or alike).
> That's great to hear.  I'd be willing to help out.
> > I wonder how it's different from what we've got now? How does it
> > compare to XBean if at all? A short introduction would be of help.
> I'm far from an OSGi expert, but let me take a swing.  Either I'll be
> correct or someone will correct me, and either way we'll learn
> something.  OSGi [1] is both an organization and a specification.  The
> spec [2], currently at release 4 and weighing in at >260 pages,
> describes what they call a "service platform" [3] which really amounts
> to an application server.  It's somewhat analogous to GBeans in that
> it specifies the interface between application components and the
> server that runs them.  It's much smaller and less featureful than
> J2EE, having been originally intended (and still used often) for
> embedded systems.  The spec has been around for quite some time but
> seems to be gaining a lot more mindshare recently.  Probably a big
> part of that is due to the Eclipse project using OSGi technology
> inside their IDE.
> The basic OSGi software package is called a "bundle".  A bundle is
> basically a jar file + metadata.  The metadata indicates which
> "services" a bundle exports and which it depends on; this allows a
> server to do automatic dependency resolution, so if you ask it to
> download a particular bundle from a remote bundle server it can first
> download and start all of the dependencies automatically.  There's
> also a JNDI-ish "registry" within an OSGi server that allows bundles
> to find services and bind to them at run-time.
> So I guess you can say that a bundle is somewhere between a GBean and
> a Configuration, but closer a GBean plus some additional packaging.
> Within Eclipse, the things that Eclipse calls "plugins" are basically
> OSGi bundles with some additional Eclipse metadata.
> From my admittedly naive perspective, I don't see huge differences
> between bundles and GBeans, but I wouldn't be surprised if they were
> there.  So far I've seen two integration approaches mentioned -
> OSGi-centric and Geronimo-centric.  The OSGi-centric approach [4]
> involves taking the various Geronimo services, repackaging them as
> bundles, and running them in an OSGi server.  The Geronimo-centric
> approach [5] involves building a GBean wrapper around bundles and
> services, so the GBean server can manage them.  In either case I think
> that having the ability to run J2EE apps *and* OSGi bundles is very
> powerful.
> My interest in OSGi technology stems from the fact that my employer
> uses Geronimo currently but is planning to also support OSGi, so my
> best-case scenario is a nice integration between the two technologies.
> Thanks,
> Toby
> [1]
> [2] Specs are "by-request" at
> [3]
> [4]
> [5]

Jacek Laskowski

View raw message