commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [all] OSGI - POOL-160
Date Thu, 25 Feb 2010 14:49:35 GMT
I just had a lively chat with Peter who kinda agreed that
substitutability issue is mostly important for APIs.

Please have a look at the Felix FAQ entry:
  http://felix.apache.org/site/apache-felix-osgi-faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F
I haven't written it, so I can't be blame for that one.
The last paragraph says:
    "The main time you want to export only, is if your bundle is
purely a library bundle, then its packages will only be used if they
are needed."

In all cases, the current imports *are* wrong and need to be fixed,
because the way they are written will fail if there is any
incompatible change ever introduced (whatever the version).  And I
don't think we should guarantee that, especially across major
versions.

Anyway, the problem is the following.
You install commons-pool 1.5 in the osgi framework.
Then you install commons-pool 1.4 later.
What you end up with is:

karaf@root> osgi:list -l | grep commons-pool
[ 100] [Active     ] [            ] [       ] [   60]
mvn:commons-pool/commons-pool/1.5.4
[ 124] [Active     ] [            ] [       ] [   60]
mvn:commons-pool/commons-pool/1.4
karaf@root> packages:exports 100
Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
Commons Pool (100): org.apache.commons.pool; version=1.5.4
karaf@root> packages:exports 124
Apache Commons Pool Bundle (124): No active exported packages.
karaf@root> packages:imports 124
Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
Commons Pool (100): org.apache.commons.pool; version=1.5.4
karaf@root> osgi:start 170
Error executing command: Unresolved constraint in bundle
org.apache.activemq.activemq-pool [129]: package;
(&(package=org.apache.commons.pool.impl)(version>=1.4.0)(!(version>=1.5.0)))


On Thu, Feb 25, 2010 at 14:26, Jörg Schaible <joerg.schaible@gmx.de> wrote:
> Hi Guillaume,
>
> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 14:13:
>
>> I'm not a committer on commons, but I've diagnosed the issue we had in
>> ServiceMix with the commons-pool bundles.
>> I can confirm that the patch is the right way to go.   If a bundle
>> acting as a library imports its own exported packages, you're bound to
>> a lot of problems.
>
> Well, this has come up before and was an explicit recommendation by the
> experts:
>
> Peter Kriens: "Bnd automatically imports all exports to allow
> substitutability. If you do not do this, you create all kinds of standalone
> class spaces and things will not work together. It is generally bad practice
> to only export a package."
>
> http://commons.markmail.org/message/lgmj7srrxhld42tp
>
>> This problem applies to all releases of commons-pool and maybe to
>> other commons-xxx components.
>> I need to try if, but a better way might be to change the
>> commons-parent pom with something like:
>>
>>     <commons.osgi.export>org.apache.commons.*;version=${pom.version};-
> noimport</commons.osgi.export>
>>
>> This should work the same (i.e. not import our own exports), but be
>> applicable to all modules.
>
> I'd rather not chage this unless proven by the experts again...
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>



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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message