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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

***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
Reply | Threaded
Open this post in threaded view
|

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

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
Reply | Threaded
Open this post in threaded view
|

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

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


Reply | Threaded
Open this post in threaded view
|

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

tvogel
In reply to this post by jbonofre
JB,
  A short example would be greatly appreciated!  
Timothy




--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Reply | Threaded
Open this post in threaded view
|

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

jbonofre
In reply to this post by Steinar Bang
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
Reply | Threaded
Open this post in threaded view
|

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

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)



Reply | Threaded
Open this post in threaded view
|

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

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