***UNCHECKED*** Sample project - multiple versions of a set of bundles

[tvogel]

I am coming back to a project for a client after a 3+ year hiatus.  As I
remember the karaf specific challenges, I was unable to get multiple
versions of a set of bundles running in the same Karaf runtime (4.0.6).  We
ran out of time / funding and simply spun up a new server / instance.  The
Java RCP client application has a different configuration depending on which
version of the services are required.

One of the things I would like to fix, in addition to the enhancements the
client requested, is to get to a single server for all versions.

Is there a sample project that shows how to run two different versions of a
set of 3 bundles in the same Karaf runtime?  It could be as simple as a
"hello world" spread across 3 bundles.

Thanks in advance,
Timothy Vogel



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

[jbonofre]

Hi Timothy,

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.

Regards
JB

On 02/11/2019 02:18, tvogel wrote:

> I am coming back to a project for a client after a 3+ year hiatus.  As I
> remember the karaf specific challenges, I was unable to get multiple
> versions of a set of bundles running in the same Karaf runtime (4.0.6).  We
> ran out of time / funding and simply spun up a new server / instance.  The
> Java RCP client application has a different configuration depending on which
> version of the services are required.
>
> One of the things I would like to fix, in addition to the enhancements the
> client requested, is to get to a single server for all versions.
>
> Is there a sample project that shows how to run two different versions of a
> set of 3 bundles in the same Karaf runtime?  It could be as simple as a
> "hello world" spread across 3 bundles.
>
> Thanks in advance,
> Timothy Vogel
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>

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

[Steinar Bang]

>>>>> Jean-Baptiste Onofré <[hidden email]>:

> 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

[tvogel]

JB,
  A short example would be greatly appreciated!  
Timothy




--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

[jbonofre]

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é <[hidden email]>:
>
>> 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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

[Steinar Bang]

>>>>> Jean-Baptiste Onofré <[hidden email]>:

> 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).

(Yes, but in my case several bundles of javax.inject already existed, so
I just had to stop the non-bundled version from being pulled in as a
transitive dependency and wrapped.  It was actually one of the jersey
bundles that pulled it in)

[jbonofre]

Understood ;)

Another possible workaround is just to embed in your bundle using
private-package in that case.

Regards
JB

On 02/11/2019 16:14, Steinar Bang wrote:

>>>>>> Jean-Baptiste Onofré <[hidden email]>:
>
>> 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).
>
> (Yes, but in my case several bundles of javax.inject already existed, so
> I just had to stop the non-bundled version from being pulled in as a
> transitive dependency and wrapped.  It was actually one of the jersey
> bundles that pulled it in)
>
>
>

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