JaxRS Remote Services using latest Jersey or Apache CXF

[Scott Lewis]

Hi Folks,

There's a new version of the ECF JaxRS Distribution Provider [1].   This 
provider implements OSGi R7 Remote Services [2] via the JaxRS support in 
new Jersey 2.28 or Apache CXF 3.3.


In practice, this means that any JaxRS-annotated service can be exported 
as a spec-compliant Remote Service in Karaf or other environments by 
adding service properties on service registration.   An example of 
running such an example in Karaf is documented here [3] with all example 
source available here [1].


Both Jersey and CXF can be extended and/or configured to support custom 
serialization, security, or other use-case specific distribution needs, 
all within the JaxRS-standardized extension mechanisms.


OSGi R7 Remote Services has asynchronous remote services [4], service 
intents, remote service admin, configurable and extensible service 
discovery, and service dynamics, as well as versioning, proxy 
creation...all integrated-via spec with any frameworks built upon the 
OSGi service registry (DS, etc).


ECF also now has a Bndtools 4.2+ workspace and templates for creating 
and running remote services with Bndtools [5].  These provide the repos 
for the necessary bundles, as well as runnable examples and bndtools 
project templates.


See blog posting [6] for more links.

Thanks,

Scott

[1] https://github.com/ECF/JaxRSProviders

[2] 
https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteservices.html


[3] https://wiki.eclipse.org/Tutorial:_JaxRS_Remote_Services_on_Karaf

[4] 
https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteservices.html#d0e1407


[5] 
https://wiki.eclipse.org/Bndtools_Support_for_Remote_Services_Development


[6] 
http://eclipseecf.blogspot.com/2019/02/restful-osgi-r7-remote-services-with.html

Re: Home and End key bindings in karaf 4.2.3

[Max Spring]

Hi Jean-Baptiste,

I experience a similar problem with Karaf 4.2.3 on Ubuntu 18.04 and Red Hat 6.9.
Trying TERM values "xterm", "xterm-color" and "xterm-color256",
I captured what I see in screen recordings (https://imgur.com/a/5GRrP05).

Regards,
-Max


On 2/25/19 9:11 PM, Jean-Baptiste Onofré wrote:

Hi,

What's your system ? Windows ?

If you are on Unix, can you share your TERM variable value ?

Thanks,
Regards
JB

On 25/02/2019 22:46, bill tsay wrote:

Hi There,

We are using karaf container for years. Currently we plan to migrate our
karaf from 3.0.5 to the latest 4.2.3. We found an issue regarding key
bindings of Home and End in Console. It seems they no longer work as in
the version of 3.0.5. Can anyone help in this matter?

Bill

Re: websocket not working in karaf 422

[Francois Papon]

Hi,

You can take a look at the Karaf examples:

https://github.com/apache/karaf/tree/master/examples/karaf-websocket-example

regards,

François Papon
fpa...@apache.org

Le 26/02/2019 à 18:27, munishgupta.asr a écrit :
> Hi Team 
>
> I upgraded my karaf from 3.x to 4.2.2 and after that one of my bundles where
> websocket is there is not working. 
>
> After some changes able to make the my websocket server up but when tried to
> connect that from client plugin it was not happening. 
>
> In developer tools , network tab the response is showing 500 error. 
>
> Can you please confirm are there any known limitation for websocket
> annotations in karaf 4.x versions? 
>
> I am using below annotations 
> import javax.websocket.ClientEndpoint; 
> import javax.websocket.CloseReason; 
> import javax.websocket.OnClose; 
> import javax.websocket.OnError; 
> import javax.websocket.OnMessage; 
> import javax.websocket.OnOpen; 
> import javax.websocket.Session; 
> import javax.websocket.server.ServerEndpoint; 
>
>
> Please do the needful 
>
> Thanks 
> Munish
>
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Modular graphic interface

[Łukasz Dywicki]

Long long time ago we made an attempt to push concept of modular console
forward: https://github.com/apache/karaf-webconsole. This project is
archived for quite long time as it didn't get beyond Karaf. As you might
expect other communities favored their own tools.

Above is based on wicket, still maintained btw. A glue is pax-wicket
which manages classloaders and extensions to create a fully dynamic
application. There is a bit of magic, however everything happens at Java
level thanks to osgi services and existing Wicket SPIs.

These days most of management tools is based on modern technologies
which communicate via http to retrieve necessary information from
backend. While many of these client oriented technics claim to have
modularization concepts, most of them do not support any dynamism when
it comes to deployment of app. At least I don't know one which does that
out of the box. GWT for example is statically compiled which forces you
to repeat what we did with Wicket, but on client side.
If you aim "modern market" you might need to assemble/generate some kind
of JS resource on the fly which will pull necessary js modules (static
or semi static resources) from deployed bundles.

One of longest surviving projects is felix webconsole which is fairly
basic, however it does support extensibility. Maybe you will be able to
repackage it in a way that it will host your needs.

Kind regards,
Łukasz Dywicki
--
Code-House
http://code-house.org

On 19.02.2019 18:39, Weirig, Alex wrote:
> Hello,
> 
> if you want to stick with Java, you can have a look at the Vaadin Framework.
> 
> Vaadin 8 was/is pure Java. With the newer versions you can also use
> webcomponents.
> 
> You can create modular UIs where even individual parts of the UI can be
> OSGi modules.
> 
> ---
> 
> Mat frëndleche Gréiss, Mit freundlichen Grüßen, Meilleures salutations,
> Kind regards,
> Alex Weirig
> Responsable Technique Ville de Luxembourg Service Enseignement Centre
> Technolink *Tel* +352 4796 - 6127  *Fax* +352 42 88 81
> *Email* alex.wei...@technolink.lu 
> www.vdl.lu  // www.technolink.lu
>  Centre Technolink 2, rue Charles de Tornaco
> L-2623 LUXEMBOURG
> 
> 
> 
> -Original Message-
> *From: *"Jean-Baptiste Onofré" 
> *To: *user@karaf.apache.org
> *Sent: *Tuesday, February 19, 2019 10:26:49 AM
> *Subject: *Re: Modular graphic interface
> 
> Hi,
> 
> I know Yupiik is using Angular (deployed in Karaf) with Karaf backend.
> It's quite module as each part of the whole application is an Angular
> bundle.
> 
> Maybe it's possible to do that same with other frameworks.
> 
> Regards
> JB
> 
> On 19/02/2019 10:23, LuisLo wrote:
>> Hi all.
>>
>> Currently my company has a production system based on karaf. The system is
>> quite dynamic and the client requests new functionalities
> periodically, some
>> of which should not be deployed in all sites.
>> Thanks to Karaf we have elegantly solved, through "features", the part of
>> business logic, so that some deployments contain some services and other
>> deployments contain others.
>> However, the graphical interface is always the same (enabling or disabling
>> unused areas). We use JSF + primeFaces.
>> Is there any way of modulating the war that contains the graphical
>> interface? We have tried to use fragments, but we have not been able (or
>> known) to make a modular application.
>> Note: we prefer a JSF solution, but we accept any other web framework.
>>
>> Thanks for the help.
>>
>>
>>
>> --
>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>>
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
> 
> -- 
> This email was Anti Virus checked by SOPHOS UTM

websocket not working in karaf 422

[munishgupta.asr]

Hi Team 

I upgraded my karaf from 3.x to 4.2.2 and after that one of my bundles where
websocket is there is not working. 

After some changes able to make the my websocket server up but when tried to
connect that from client plugin it was not happening. 

In developer tools , network tab the response is showing 500 error. 

Can you please confirm are there any known limitation for websocket
annotations in karaf 4.x versions? 

I am using below annotations 
import javax.websocket.ClientEndpoint; 
import javax.websocket.CloseReason; 
import javax.websocket.OnClose; 
import javax.websocket.OnError; 
import javax.websocket.OnMessage; 
import javax.websocket.OnOpen; 
import javax.websocket.Session; 
import javax.websocket.server.ServerEndpoint; 


Please do the needful 

Thanks 
Munish




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

Re: KARAF-5742 quick question

[Guillaume Nodet]

Just add the variable definition to

   etc/shell.init.script


Guillaume

Le mar. 26 févr. 2019 à 12:25, Daniel Estermann  a
écrit :

> Thanks for the example, I see know what "em", "ee" and "st" stand for.
> But there was a little misunderstanding. I wanted to have that session
> variable set permanently, not for a single session. How to achieve it?
>
> Am Di., 26. Feb. 2019 um 12:00 Uhr schrieb Guillaume Nodet <
> gno...@apache.org>:
>
>> Fwding to user@k.a.o
>>
>> Le mar. 26 févr. 2019 à 11:03, Daniel Estermann  a
>> écrit :
>>
>>> Hi Guillaume,
>>>
>>> you have fixed the above mentioned issue
>>> ,
>>> but I don't understand yet how to apply it. I want to set the following
>>> colors in my console:
>>>
>>
>>> fatalColor = 31;1
>>> errorColor = 31;1
>>> warnColor = 35;1
>>> infoColor = 36;1
>>> debugColor = 39;1
>>> traceColor = 39;1
>>>
>>> How to set KS_COLORS permanently and what would be the appropriate value
>>> for my desired colors?
>>>
>>
>> The KS_COLORS contains 3 colors which are used to style the exception
>> logged to the console, mainly when the execution of a command  results in
>> an exception. For example, you can see the effect in the following snippet
>>
>> *karaf*@root()> KS_COLORS="em=34:ee=1;33:st=35"
>>
>> em=34:ee=1;33:st=35
>>
>> *karaf*@root()> foo
>>
>> Command not found: *foo*
>>
>> *karaf*@root()> stack-traces-print
>>
>> Printing of stacktraces set to true
>>
>> *karaf*@root()> foo
>>
>>
>> org.apache.felix.gogo.runtime.CommandNotFoundException: Command not
>> found: foo
>>
>> at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:596)
>>
>> at
>> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
>>
>> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415)
>>
>> at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416)
>>
>> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
>>
>> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
>>
>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>
>> at java.lang.Thread.run(Thread.java:748)
>>
>> *karaf*@root()>
>>
>>
>> If you want to configure the logging colors, those are configured in the
>> org.apache.karaf.log configuration with the values you explained, but
>> this is unrelated to KARAF-5742
>>  afaik.
>>
>> Guillaume
>>
>>
>>> Thanks in advance!
>>> Daniel
>>>
>>
>>
>> --
>> 
>> Guillaume Nodet
>>
>>

-- 

Guillaume Nodet

Re: KARAF-5742 quick question

[Daniel Estermann]

Thanks for the example, I see know what "em", "ee" and "st" stand for.
But there was a little misunderstanding. I wanted to have that session
variable set permanently, not for a single session. How to achieve it?

Am Di., 26. Feb. 2019 um 12:00 Uhr schrieb Guillaume Nodet <
gno...@apache.org>:

> Fwding to user@k.a.o
>
> Le mar. 26 févr. 2019 à 11:03, Daniel Estermann  a
> écrit :
>
>> Hi Guillaume,
>>
>> you have fixed the above mentioned issue
>> ,
>> but I don't understand yet how to apply it. I want to set the following
>> colors in my console:
>>
>
>> fatalColor = 31;1
>> errorColor = 31;1
>> warnColor = 35;1
>> infoColor = 36;1
>> debugColor = 39;1
>> traceColor = 39;1
>>
>> How to set KS_COLORS permanently and what would be the appropriate value
>> for my desired colors?
>>
>
> The KS_COLORS contains 3 colors which are used to style the exception
> logged to the console, mainly when the execution of a command  results in
> an exception. For example, you can see the effect in the following snippet
>
> *karaf*@root()> KS_COLORS="em=34:ee=1;33:st=35"
>
> em=34:ee=1;33:st=35
>
> *karaf*@root()> foo
>
> Command not found: *foo*
>
> *karaf*@root()> stack-traces-print
>
> Printing of stacktraces set to true
>
> *karaf*@root()> foo
>
>
> org.apache.felix.gogo.runtime.CommandNotFoundException: Command not found:
> foo
>
> at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:596)
>
> at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
>
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415)
>
> at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416)
>
> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
>
> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
>
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>
> at java.lang.Thread.run(Thread.java:748)
>
> *karaf*@root()>
>
>
> If you want to configure the logging colors, those are configured in the
> org.apache.karaf.log configuration with the values you explained, but
> this is unrelated to KARAF-5742
>  afaik.
>
> Guillaume
>
>
>> Thanks in advance!
>> Daniel
>>
>
>
> --
> 
> Guillaume Nodet
>
>

Re: KARAF-5742 quick question

[Guillaume Nodet]

Fwding to user@k.a.o

Le mar. 26 févr. 2019 à 11:03, Daniel Estermann  a
écrit :

> Hi Guillaume,
>
> you have fixed the above mentioned issue
> ,
> but I don't understand yet how to apply it. I want to set the following
> colors in my console:
>

> fatalColor = 31;1
> errorColor = 31;1
> warnColor = 35;1
> infoColor = 36;1
> debugColor = 39;1
> traceColor = 39;1
>
> How to set KS_COLORS permanently and what would be the appropriate value
> for my desired colors?
>

The KS_COLORS contains 3 colors which are used to style the exception
logged to the console, mainly when the execution of a command  results in
an exception. For example, you can see the effect in the following snippet

*karaf*@root()> KS_COLORS="em=34:ee=1;33:st=35"

em=34:ee=1;33:st=35

*karaf*@root()> foo

Command not found: *foo*

*karaf*@root()> stack-traces-print

Printing of stacktraces set to true

*karaf*@root()> foo


org.apache.felix.gogo.runtime.CommandNotFoundException: Command not found:
foo

at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:596)

at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)

at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415)

at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416)

at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)

at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)

at java.util.concurrent.FutureTask.run(FutureTask.java:266)

at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

at java.lang.Thread.run(Thread.java:748)

*karaf*@root()>


If you want to configure the logging colors, those are configured in the
org.apache.karaf.log configuration with the values you explained, but this
is unrelated to KARAF-5742
 afaik.

Guillaume


> Thanks in advance!
> Daniel
>


-- 

Guillaume Nodet

Re: JAXB 2.2 and 2.3 in Karaf 4.1.5

[Jean-Baptiste Onofré]

If the headers are clean, yes it should work.

Le 26 févr. 2019 à 10:41, à 10:41, Oliver Wulff  a écrit:
>Hi JB
>
>
>Will it also work to deploy JAXB 2.2 and 2.3 in Karaf 4.1.5 when I
>ensure that the import headers are correct?
>
>
>Thanks
>
>Oli
>
>
>Von: Jean-Baptiste Onofré 
>Gesendet: Dienstag, 26. Februar 2019 10:03:14
>An: user@karaf.apache.org
>Betreff: Re: JAXB 2.2 and 2.3 in Karaf 4.1.5
>
>Hi Oliver,
>
>yes you can still install JAXB 2.2 bundle (or via feature).
>
>Regards
>JB
>
>On 26/02/2019 09:59, Oliver Wulff wrote:
>> Hi there
>>
>>
>> Recently I run into an issue with OpenAPI implemenation (Swagger3
>2.0.6)
>> due to a dependency to JAXB 2.3 in Karaf 4.1.5. Some bundles require
>> version 2.2 and Swagger 3 2.0.6 requires JAXB 2.3. This was the error
>> message:
>>
>>
>
>>
>> org.apache.karaf.features.internal.util.MultiException: Error
>restarting
>> bundles:
>> Could not resolve module: party-api-service-wsdl [338]
>>   Bundle was not resolved because of a uses contraint violation.
>>   org.osgi.service.resolver.ResolutionException: Uses constraint
>> violation. Unable to resolve resource party-api-service-wsdl
>> [osgi.identity; osgi.identity="party-api-service-wsdl";
>> type="osgi.bundle"; version:Version="1.0.3.SNAPSHOT"] because it is
>> exposed to package 'javax.xml.bind' from resources
>> org.apache.servicemix.specs.jaxb-api-2.3 [osgi.identity;
>> osgi.identity="org.apache.servicemix.specs.jaxb-api-2.3";
>> type="osgi.bundle"; version:Version="2.3.0.1"] and org.eclipse.osgi
>> [osgi.identity; osgi.identity="org.eclipse.osgi"; type="osgi.bundle";
>> version:Version="3.12.50.v20170928-1321"; singleton:="true"] via two
>> dependency chains.
>>
>
>>
>>
>> I saw that Karaf 4.2.3 supports JAXB 2.3. Is JAXB 2.2 still supported
>or
>> is it not possible to support both JAXB version in one Karaf runtime?
>> IMHO, it should be sufficient to ensure that the import defintion
>> enforces a version number to properly resolve it. But maybe I miss
>> something.
>>
>>
>> Instead of something like this:
>>
>> Import-Package =
>> javax.xml.bind;version="[2.2,3)",
>> javax.xml.bind.annotation;version="[2.2,3)",
>> javax.xml.bind.annotation.adapters;version="[2.2,3)",
>>
>>
>> I should have this:
>>
>> Import-Package =
>> javax.xml.bind;version="[2.2,2.3)",
>> javax.xml.bind.annotation;version="[2.2,2.3)",
>> javax.xml.bind.annotation.adapters;version="[2.2,2.3)",
>>
>> The only solution at the moment is to use Swagger3 2.0.0 (which
>doesn't
>> have the JAXB 2.3 dependency) but I might run into another issue due
>to
>> the lack of bug fixes in Swagger3 2.0.x.
>>
>> Thanks a lot for your feedback
>>
>> Oliver
>>
>> As a recipient of an email from Talend, your contact personal data
>will
>> be on our systems. Please see our contacts privacy notice at Talend,
>> Inc. 
>>
>>
>>
>
>--
>Jean-Baptiste Onofré
>jbono...@apache.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.nanthrax.net=DwID-g=2w5q_42kFG40MI2alLPgJw=MY8HqKKGyKRbsN_hT9rg7mHAgu8X3kX4hI5WsyoHqi0=tXy6S7NX20WRtsa94lub4joq_v7hqPl_8HFV9VuSKHo=NoXtLnQzdbJoWG1JcLOnRrtLAZCKIltq8jDxvsA_4NU=
>Talend - http://www.talend.com

AW: JAXB 2.2 and 2.3 in Karaf 4.1.5

[Oliver Wulff]

Hi JB


Will it also work to deploy JAXB 2.2 and 2.3 in Karaf 4.1.5 when I ensure that 
the import headers are correct?


Thanks

Oli


Von: Jean-Baptiste Onofré 
Gesendet: Dienstag, 26. Februar 2019 10:03:14
An: user@karaf.apache.org
Betreff: Re: JAXB 2.2 and 2.3 in Karaf 4.1.5

Hi Oliver,

yes you can still install JAXB 2.2 bundle (or via feature).

Regards
JB

On 26/02/2019 09:59, Oliver Wulff wrote:
> Hi there
>
>
> Recently I run into an issue with OpenAPI implemenation (Swagger3 2.0.6)
> due to a dependency to JAXB 2.3 in Karaf 4.1.5. Some bundles require
> version 2.2 and Swagger 3 2.0.6 requires JAXB 2.3. This was the error
> message:
>
>

>
> org.apache.karaf.features.internal.util.MultiException: Error restarting
> bundles:
> Could not resolve module: party-api-service-wsdl [338]
>   Bundle was not resolved because of a uses contraint violation.
>   org.osgi.service.resolver.ResolutionException: Uses constraint
> violation. Unable to resolve resource party-api-service-wsdl
> [osgi.identity; osgi.identity="party-api-service-wsdl";
> type="osgi.bundle"; version:Version="1.0.3.SNAPSHOT"] because it is
> exposed to package 'javax.xml.bind' from resources
> org.apache.servicemix.specs.jaxb-api-2.3 [osgi.identity;
> osgi.identity="org.apache.servicemix.specs.jaxb-api-2.3";
> type="osgi.bundle"; version:Version="2.3.0.1"] and org.eclipse.osgi
> [osgi.identity; osgi.identity="org.eclipse.osgi"; type="osgi.bundle";
> version:Version="3.12.50.v20170928-1321"; singleton:="true"] via two
> dependency chains.
>

>
>
> I saw that Karaf 4.2.3 supports JAXB 2.3. Is JAXB 2.2 still supported or
> is it not possible to support both JAXB version in one Karaf runtime?
> IMHO, it should be sufficient to ensure that the import defintion
> enforces a version number to properly resolve it. But maybe I miss
> something.
>
>
> Instead of something like this:
>
> Import-Package =
> javax.xml.bind;version="[2.2,3)",
> javax.xml.bind.annotation;version="[2.2,3)",
> javax.xml.bind.annotation.adapters;version="[2.2,3)",
>
>
> I should have this:
>
> Import-Package =
> javax.xml.bind;version="[2.2,2.3)",
> javax.xml.bind.annotation;version="[2.2,2.3)",
> javax.xml.bind.annotation.adapters;version="[2.2,2.3)",
>
> The only solution at the moment is to use Swagger3 2.0.0 (which doesn't
> have the JAXB 2.3 dependency) but I might run into another issue due to
> the lack of bug fixes in Swagger3 2.0.x.
>
> Thanks a lot for your feedback
>
> Oliver
>
> As a recipient of an email from Talend, your contact personal data will
> be on our systems. Please see our contacts privacy notice at Talend,
> Inc. 
>
>
>

--
Jean-Baptiste Onofré
jbono...@apache.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.nanthrax.net=DwID-g=2w5q_42kFG40MI2alLPgJw=MY8HqKKGyKRbsN_hT9rg7mHAgu8X3kX4hI5WsyoHqi0=tXy6S7NX20WRtsa94lub4joq_v7hqPl_8HFV9VuSKHo=NoXtLnQzdbJoWG1JcLOnRrtLAZCKIltq8jDxvsA_4NU=
Talend - http://www.talend.com

Re: JAXB 2.2 and 2.3 in Karaf 4.1.5

[Jean-Baptiste Onofré]

Hi Oliver,

yes you can still install JAXB 2.2 bundle (or via feature).

Regards
JB

On 26/02/2019 09:59, Oliver Wulff wrote:
> Hi there
> 
> 
> Recently I run into an issue with OpenAPI implemenation (Swagger3 2.0.6)
> due to a dependency to JAXB 2.3 in Karaf 4.1.5. Some bundles require
> version 2.2 and Swagger 3 2.0.6 requires JAXB 2.3. This was the error
> message:
> 
> 

> 
> org.apache.karaf.features.internal.util.MultiException: Error restarting
> bundles:
> Could not resolve module: party-api-service-wsdl [338]
>   Bundle was not resolved because of a uses contraint violation.
>   org.osgi.service.resolver.ResolutionException: Uses constraint
> violation. Unable to resolve resource party-api-service-wsdl
> [osgi.identity; osgi.identity="party-api-service-wsdl";
> type="osgi.bundle"; version:Version="1.0.3.SNAPSHOT"] because it is
> exposed to package 'javax.xml.bind' from resources
> org.apache.servicemix.specs.jaxb-api-2.3 [osgi.identity;
> osgi.identity="org.apache.servicemix.specs.jaxb-api-2.3";
> type="osgi.bundle"; version:Version="2.3.0.1"] and org.eclipse.osgi
> [osgi.identity; osgi.identity="org.eclipse.osgi"; type="osgi.bundle";
> version:Version="3.12.50.v20170928-1321"; singleton:="true"] via two
> dependency chains.
> 

> 
> 
> I saw that Karaf 4.2.3 supports JAXB 2.3. Is JAXB 2.2 still supported or
> is it not possible to support both JAXB version in one Karaf runtime?
> IMHO, it should be sufficient to ensure that the import defintion
> enforces a version number to properly resolve it. But maybe I miss
> something.
> 
> 
> Instead of something like this:
> 
> Import-Package = 
> javax.xml.bind;version="[2.2,3)",
> javax.xml.bind.annotation;version="[2.2,3)",
> javax.xml.bind.annotation.adapters;version="[2.2,3)",
> 
> 
> I should have this:
> 
> Import-Package = 
> javax.xml.bind;version="[2.2,2.3)",
> javax.xml.bind.annotation;version="[2.2,2.3)",
> javax.xml.bind.annotation.adapters;version="[2.2,2.3)",
> 
> The only solution at the moment is to use Swagger3 2.0.0 (which doesn't
> have the JAXB 2.3 dependency) but I might run into another issue due to
> the lack of bug fixes in Swagger3 2.0.x.
> 
> Thanks a lot for your feedback
> 
> Oliver
> 
> As a recipient of an email from Talend, your contact personal data will
> be on our systems. Please see our contacts privacy notice at Talend,
> Inc. 
> 
> 
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

JAXB 2.2 and 2.3 in Karaf 4.1.5

[Oliver Wulff]

Hi there


Recently I run into an issue with OpenAPI implemenation (Swagger3 2.0.6) due to 
a dependency to JAXB 2.3 in Karaf 4.1.5. Some bundles require version 2.2 and 
Swagger 3 2.0.6 requires JAXB 2.3. This was the error message:


>>>

org.apache.karaf.features.internal.util.MultiException: Error restarting 
bundles:
Could not resolve module: party-api-service-wsdl [338]
  Bundle was not resolved because of a uses contraint violation.
  org.osgi.service.resolver.ResolutionException: Uses constraint violation. 
Unable to resolve resource party-api-service-wsdl [osgi.identity; 
osgi.identity="party-api-service-wsdl"; type="osgi.bundle"; 
version:Version="1.0.3.SNAPSHOT"] because it is exposed to package 
'javax.xml.bind' from resources org.apache.servicemix.specs.jaxb-api-2.3 
[osgi.identity; osgi.identity="org.apache.servicemix.specs.jaxb-api-2.3"; 
type="osgi.bundle"; version:Version="2.3.0.1"] and org.eclipse.osgi 
[osgi.identity; osgi.identity="org.eclipse.osgi"; type="osgi.bundle"; 
version:Version="3.12.50.v20170928-1321"; singleton:="true"] via two dependency 
chains.

>>>


I saw that Karaf 4.2.3 supports JAXB 2.3. Is JAXB 2.2 still supported or is it 
not possible to support both JAXB version in one Karaf runtime? IMHO, it should 
be sufficient to ensure that the import defintion enforces a version number to 
properly resolve it. But maybe I miss something.


Instead of something like this:

Import-Package =
javax.xml.bind;version="[2.2,3)",
javax.xml.bind.annotation;version="[2.2,3)",
javax.xml.bind.annotation.adapters;version="[2.2,3)",



I should have this:

Import-Package =
javax.xml.bind;version="[2.2,2.3)",
javax.xml.bind.annotation;version="[2.2,2.3)",
javax.xml.bind.annotation.adapters;version="[2.2,2.3)",

The only solution at the moment is to use Swagger3 2.0.0 (which doesn't have 
the JAXB 2.3 dependency) but I might run into another issue due to the lack of 
bug fixes in Swagger3 2.0.x.


Thanks a lot for your feedback

Oliver

As a recipient of an email from Talend, your contact personal data will be on 
our systems. Please see our contacts privacy notice at Talend, Inc.