It's not so painful if you use either the wrap protocol (you can specify
the OSGi headers on the URL) or create a clean bundle (for instance,
like we do at ServiceMix Bundles).

I think it makes sense to show wrap in the "multi-version" example (with
clean wrap URL directly in features XML).

Regards
JB

On 02/11/2019 08:51, Steinar Bang wrote:
>>>>>> Jean-Baptiste Onofré <[email protected]>:
> 
>> Of course it depends a lot of the bundles and the code you are doing,
>> but from a Karaf perspective you can deploy same bundle with different
>> versions in a single instance without problem (as soon as the headers
>> are good enough).
> 
>> I can add an example in Karaf distribution to show this if you want.
> 
> One thing that has bitten me, is wrap'ing of non-bundle jars.  I.e. in
> particular one none-bundle: javax.inject.
> 
> If I get an wrap'ed javax.inject, the resulting bundle gets version 0
> and this seems to take precedence over actually versioned bundles...?
> 
> The place where it bit me was jersey's HK2's scanning for resources,
> where it didn't find the @Inject annotations on resources (HK2 has its
> own bundled version of javax.inject.
> 
> The fix for me was to examine all transitive dependencies in
> "mvn dependency:tree" for javax.inject and exclude it everywhere I
> found it so that I didn't get any features trying to load it as a
> wrap'ed jar.
> 
> Properly versioned javax.connect bundles hasn't created any problems for
> me.
> 
> E.g. the feature for the PostgreSQL JDBC driver relies on the built-in
> karaf feature transaction-api, which pulls in
>   48 │ Active │  80 │ 1.0.0.2 │ Apache ServiceMix :: Bundles :: javax.inject
> and this doesn't create any problems for
>  136 │ Active │  80 │ 2.28.0             │ jersey-inject-hk2
> 
> 

-- 
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply via email to