geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Charters <gchart...@googlemail.com>
Subject Re: Whence the geronimo kernel?
Date Wed, 18 Mar 2009 09:17:55 GMT
Hi Rex, I'm not Lin, but I thought I'd just add a few thoughts/comments.

Split packages are sometimes forced upon us.  For example, the
transactions APIs are partially provided by the JDK.  This might be a
case for using Require-Bundle, but then there are also other
techniques to avoid resolving to these partial packages, like using
mandatory attributes (i.e. provide a complete package exported with a
mandatory attribute and then express your dependency on that).

Other cases where Require-Bundle can cause problems is when there are
multiple importers/exporters for the same packages.  This can occur
for example with spec APIs which are sometimes provided separately and
sometimes packaged with an implementation.  The best solution here is
to design for substitutability.  Exporters of the package should also
import the package so they all resolve to the same provider (I believe
substitutability is the default that the BND tool will generate).
Doing so helps avoid class cast exceptions because the bundles will
all use the same classloader to provide the classes, irrespective of
the order in which they were installed.  Require-Bundle, however would
not allow this behavior because we would only express the requirement
on the bundle which happens to provide the packages.  We cannot
therefore be flexible in the choice of provider of the packages.

I just wanted to provide an analogy for Require-Bundle.  I liken it to
a toolbox (bundle) which contains some tools (packages).  If I have a
job I need to do, I know which tools I need so I pick up my toolbox
and take it to the place where I need to do the job.  I've lost track
of the number of times I've done that and found one of my tools is
missing.  OK, so I should be more careful with my tools, but sometimes
the things we depend on aren't provided by us.  If they get
refactored, it's more difficult to track down the issues when they're
hidden behind an opaque Require-Bundle.

A comment regarding Eclipse, when you're working in an
extension-point/extension world, the person providing the extension
point is in control (dictates what the service should look like).  In
this scenario there is only likely to be one provider of the thing you
depend upon and therefore the problem is much more constrained.  In a
services world it is much more egalitarian and you have to start
catering for multiple providers and refactoring.

It might be worth taking a look at what Apache Tuscany has done in
this area.  They are in the process of bundlizing their runtime
consisting of something like 80 Tuscany provided bundles and 160
third-party dependencies.  Luciano Resende presented on some of the
early work at ApacheCon US last year (see http://tinyurl.com/c6rm5z )

I hope this helps.

Regards, Graham.

2009/3/18 Rex Wang <rwonly@gmail.com>:
> Thanks Lin,
> I know the Issues with reqriring bundle(3.13.3 of spec 4.1), and the main
> opposite point from the blog I think is just because of the "refactor".
> I just want to make clear that, is there any situation we might meet the
> split packages or refactor a bundle frequently?
> At least, my eclipse 3.4's plugins always prefer to use "require-bundle" and
> seems no problem with that..
> I am not saying that I am a funs of require-bundle, but I really hope the MF
> and geronimo-plugin.xml(for a single bundle) not have a relationship like
> the JEE app's deployment descriptor and geronimo deployment plan...
>
> Rex.
>
> 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.
>> >>>>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >
>> >
>
>

Mime
View raw message