geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Whence the geronimo kernel?
Date Tue, 17 Mar 2009 14:55:57 GMT
For those that are not aware of ServiceMix Kernel (I know David is), i'd
like to point them to it.  Feel free to download it and give it a try.  It's
based on felix, gshell and a few other bundles. We're using it to deploy our
JBI container in ServiceMix 4 (including the geronimo transaction manager,
activemq, jetty, but those are not included in the kernel).
See http://servicemix.apache.org/kernel/index.html

To add to this discussion, we are deploying stuff on servicemix using
"features", which is imho the metdata related to (2).
A feature is mostly a list of OSGi bundles with some dependencies on other
features and some optional configuration.
We are almost using Import-Packages exclusively, using spring-dm to
configure most of our services ...

2009/3/17 Lin Sun <linsun.unc@gmail.com>

> Rex,
>
> If you follow the discussion closely, I think David was just saying
> that he prefers to stay away from Require-Bundle for now, as the OSGi
> specification doesn't recommend people to use it, along with the probs
> people mentioned about it in the link I posted earlier.
>
> I also found these links interesting -
>
> http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html
>
>
> http://ekkes-corner.blogspot.com/2008/06/catch-22-logging-with-osgi-frameworks.html
>
> David,
>
> Some comments regarding #2, its essential to know what
> jars/bundles/plugins/modules are actually in your running system.
>
> I think OSGi framework provides the ability to display the currently
> running bundles, so there should be APIs to get that.  For example,
> you type "ss" in equinox console to get the list of installed bundles:
>
> osgi> ss
>
> Framework is launched.
>
> id      State       Bundle
> 0       ACTIVE      org.eclipse.osgi_3.4.2.R34x_v20080826-1230
> 14      ACTIVE      org.osgi.impl.service.log_1.3.2.200902181055
> 17      RESOLVED    org.osgi.impl.service.http_4.2.0.200902181209
> 18      INSTALLED   org.osgi.test.cases.http_4.2.0.200902181210
>
> OSGi framework also uses resolver to resolve bundles.   For example,
> if I want to install Bundle A to the framework, and Bundle imports
> package AA, then when I install the bundle A, the OSGi framework uses
> the resolver to find out if there is any bundle that exports package
> AA.  If so, bundle A will be marked as RESOLVED.  Otherwise, Bundle A
> will be marked as INSTALLED.  If you search "resolver" in the OSGi
> core spec, you'll see a couple of places that mention it.
>
> I recently took a look at the new OSGi bundle repository spec (RFC
> 112).  It talks about the concept of Resolver and the interface
> Resolver   It talks about scenarios where a user wants to install a
> bundle (that uses Import-Package), the server should be able to pull
> all its dependencies from the bundle repository (or repositories) on
> the fly using the resolver.   This seems something we would need for
> geronimo.
>
> Lin
>
>
>
>
>
>
> On Tue, Mar 17, 2009 at 12:52 AM, Rex Wang <rwonly@gmail.com> wrote:
> > "At the moment I'm inclined to think that require-bundle is not a
> workable
> > solution for (2) and so we might as well use import-package plus an osgi
> > runtime that uses and requires explicit external dependency information
> such
> > as provided by maven or geronimo-plugin.xml to choose what bundle to
> resolve
> > to. "
> >
> > From my point of view, I am not quite like this "mix" version, because we
> > must maintain the related information in two different places, that will
> > absolutely increase geronimo's complexity and some sorts of confusing on
> the
> > dependency settings, not only to the developers but also the users. I
> think
> > one of the purpose that we adopt OSGi is to make our server
> infrastructure
> > "standardize" to the OSGi specification, but not to create a new
> application
> > model.  Because this may lead to a non osgi compatiable bundle, IIUC, any
> > bundle that wanna be used in geronimo must re-write to provide the
> > additional mvn-style information.
> >
> > Why do you think the require-bundle is not a workable solution for (2) ?
> >
> >
> > Rex.
> >
> >
> >
> > 2009/3/14 David Jencks <david_jencks@yahoo.com>
> >>
> >> On Mar 13, 2009, at 9:43 AM, Rick McGuire wrote:
> >>
> >>> David Jencks wrote:
> >>>>
> >>>> I read the blog entry and discussion.  The entire discussion is
> >>>> predicated on the idea that osgi is close to ideal as-is and we have
> no need
> >>>> to consider any other point of view.  If you step back a bit I see two
> >>>> things clearly acknowledged by everyone:
> >>>>
> >>>> 1. its useful to be able to know what classes are needed to make a
> >>>> jar/bundle/plugin/module work and which classes are expected to be
> used
> >>>> elsewhere
> >>>> 2. its essential to know what jars/bundles/plugins/modules are
> actually
> >>>> in your running system
> >>>>
> >>>> In osgi-land, import-package and export-package supply (1), and
> >>>> require-bundle sort of helps with (2) but AFAICT right now doesn't
> support
> >>>> "artifact aliasing"
> >>>> In maven-land, the pom dependency tracking provides a pretty good
> >>>> solution for (2), including some support for overriding "requirements"
> >>>> through exclusions, but it's single-classloader model doesn't
> translate
> >>>> directly into an app server or osgi runtime
> >>>> In geronimo trunk we emphasize (2) and can actually assemble working
> >>>> servers using it, and have support for (1) (although its mostly
> backwards
> >>>> from osgi specifications)
> >>>>
> >>>> I'd say that in my (limited) experience osgi zealots typically think
> >>>> that (1) is essential and brush (2) under the carpet by working in
> >>>> constrained environments such as their eclipse workspace.  I'd say
> that our
> >>>> experience with geronimo is that (1) is rarely needed if you have a
> working
> >>>> (2) (look at how many hidden-classes and non-overriable classes
> filters are
> >>>> in our poms -- none for the use of geronimo, and a few to make
> deploying
> >>>> applications that include the same jars as us work)
> >>>>
> >>>> The geronimo/maven approach to (2) is to include the dependency
> >>>> information with the artifact.  I'm not sure what approach(es) osgi
is
> >>>> considering -- OBR appears to not consider bundling dependency info
> with the
> >>>> artifact but to have a completely external specification.  I don't
> know
> >>>> about p2.... but since jason vanZyl seems to be looking at it I'd
> guess it
> >>>> is more maven friendly.
> >>>>
> >>>> If you don't bundle (2) with the artifacts then you need some kind of
> >>>> import-package to artifact map or resolution system.  We sort of have
> some
> >>>> vestiges of this today: when you deploy a web app as a geronimo plugin
> (or
> >>>> export it from a server where it was deployed) it has picked up
> dependencies
> >>>> on jetty or tomcat based on which deployer you specified in the plugin
> >>>> project pom or which kind of server you deployed on.  Another example
> is
> >>>> that the car-maven-plugin filters the view of the local maven repo so
> only
> >>>> the versions specified in the pom are visible to the geronimo server
> we run
> >>>> off the repo -- this allows you to build plugins for a 2.1.3 server
> even if
> >>>> you have 2.2-SNAPSHOT artifacts locally and some of the dependencies
> don't
> >>>> specify the version required.
> >>>>
> >>>> I don't know where the best balance for geronimo lies here.  I
> certainly
> >>>> think claiming all we need is import-package is shortchanging most of
> our
> >>>> experience in producing geronimo as a working server.
> >>>
> >>> But on the other hand, I'd hate to have not using just Import-package
> as
> >>> the starting point.  Given how much it is assumed in the OSGi world, it
> >>> would be best to assume its use and only step outside of that box once
> we've
> >>> found the intractable problem that requires it.  Starting outside of
> those
> >>> limits means we're abandoning the things OSGi does straight off because
> >>> their may be some places where the exception mechanisms are required.
> >>
> >> Aren't you exhibiting exactly the same attitude as the blog posters in
> >> saying the (2) is not really a problem we need to consider?  Whereas all
> our
> >> work in getting geronimo to actually work has been focussed on solving
> (2).
> >>  If we ditch our working system for (2) we won't have a server....
> perhaps
> >> ever.  In terms of assembling a server, without (2) the space of
> possible
> >> bundles to resolve to is the entire maven central repo. ( I anticipate
> that
> >> any working server is going to be able to convert plain jars to bundles
> on
> >> the fly.  If not, no one who is not osgi-obsessed will be willing to use
> it)
> >>
> >> At the moment I'm inclined to think that require-bundle is not a
> workable
> >> solution for (2) and so we might as well use import-package plus an osgi
> >> runtime that uses and requires explicit external dependency information
> such
> >> as provided by maven or geronimo-plugin.xml to choose what bundle to
> resolve
> >> to.  However until we get something working we won't know much about
> whether
> >> this or any proposal is a good or workable choice.
> >>
> >> I'm still waiting for news of a working osgi system that is comparable
> in
> >> scale to eclipse that primarily uses import-package.
> >>
> >> thanks
> >> david jencks
> >>
> >>>
> >>>
> >>> Rick
> >>>>
> >>>> thanks
> >>>> david jencks
> >>>>
> >>>> On Mar 13, 2009, at 7:10 AM, Lin Sun wrote:
> >>>>
> >>>>> I think I was not too clear below.  I didn't mean to say that I
am in
> >>>>> favor of Require-Bundle because it is a lot harder to come up with
> the
> >>>>> right Import-Package lists.  What I meant was that the reason why
a
> >>>>> lot of people are using Require-Bundle like David mentioned in his
> >>>>> early notes is probably because it is a lot easier to use.
> >>>>>
> >>>>> I personally had to spend quite some time to figure out the prob
I
> >>>>> mentioned earlier  - I was developing a bundle that needs to import
> >>>>> the javax.transaction package from the transaction in OSGi bundle,
> but
> >>>>> two bundles have it (the basic OSGi J2SE and the transaction in
OSGi
> >>>>> bundle).    I was able to resolve this using Import-Package with
the
> >>>>> specific version of javax.transaction package that I need.  I just
> >>>>> tried to switch to use Require-Bundle, that is to have my bundle
to
> >>>>> depend on the transaction in OSGi bundle as it contains the right
> >>>>> version of the javax.transaction package I need, but my bundle is
> >>>>> broken completely due to CDNFE.   I don't think the Require-Bundle
> >>>>> offers the fine grain control that I needed for my bundle and I
am
> >>>>> sure Geronimo would have a lot more complicated bundles than what
I
> >>>>> was developing.
> >>>>>
> >>>>> BTW, there's a good discussion here:
> >>>>>
> http://thhal.blogspot.com/2008/02/dependencies-and-package-imports.html
> >>>>>
> >>>>> - in particular in the first comment from Neil Bartlett and the
> >>>>> limitations of Require-Bundle documented in the OSGi v 4.1 core
spec
> >>>>> (section 3.13.3).
> >>>>>
> >>>>> Lin
> >>>>>
> >>>>>
> >>>>> On Thu, Mar 12, 2009 at 11:40 PM, Lin Sun <linsun.unc@gmail.com>
> wrote:
> >>>>>
> >>>>>> Not sure about Require-Bundle.  I personally has never used
it and I
> >>>>>> never see it is being used in the OSGi repo.  Require-Bundle
may not
> >>>>>> offer the level of control that the Import-Package provides
but it
> is
> >>>>>> probably a lot harder to come up with the right Import-Package
> lists.
> >>>>>> I think this scenario should work just fine if using Import-Package.
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
> >
> >
>



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

Mime
View raw message