date:20160704

Re: Karaf 4.0.5 - Jetty features different versions: pax-jetty and jetty

2016-07-04 Thread Allan C.

Noted. Thanks.

Regards,
Allan C.

On Tue, Jul 5, 2016 at 3:40 AM, Jean-Baptiste Onofré 
wrote:

> Thanks Allan,
>
> jetty is an alias feature on top of pax-jetty (for backward compatibility).
>
> Definitely, we upgraded in pax-web, but forgot to update the jetty alias
> feature.
>
> Let me create a Jira to fix that.
>
> Thanks !
> Regards
> JB
>
> On 07/04/2016 10:20 AM, Allan C. wrote:
>
>> I am playing around with 4.0.5 and I noticed that the versions for the
>> jetty and pax-jetty are different. In Fuse 6.2.1 (I think it is based on
>> Karaf 2.4.0), the versions are the same.
>>
>> JBossFuse:karaf@root> features:list | grep jetty
>> [installed  ] [*8.1.17.v20150415* ] jetty
>>karaf-2.4.0.redhat-621084
>>  Provide Jetty engine support
>> [installed  ] [2.15.1.redhat-621084 ] camel-jetty
>>  camel-2.15.1.redhat-621084
>>
>> [uninstalled] [2.15.1.redhat-621084 ] camel-jetty9
>> camel-2.15.1.redhat-621084
>>
>> [installed  ] [*8.1.17.v20150415* ] pax-jetty
>>org.ops4j.pax.web-3.2.5
>>  Provide Jetty engine support
>> [installed  ] [3.0.4.redhat-621084  ] cxf-http-jetty
>> cxf-3.0.4.redhat-621084
>>
>> Karaf 4.0.5:
>>
>> karaf@root(feature)> list | grep jetty
>> jetty   | *9.2.10.v20150310* |
>>   | Started | standard-4.0.5  |
>> jetty   | 8.1.14.v20131031 |  |
>> Uninstalled | standard-4.0.5  |
>> cxf-http-jetty  | 3.1.5|  |
>> Started | cxf-3.1.5   |
>> pax-jetty   | *9.2.15.v20160210* |
>>   | Started | org.ops4j.pax.web-4.2.6 | Provide Jetty engine
>> support
>> pax-jetty-spdy  | 4.2.6|  |
>> Uninstalled | org.ops4j.pax.web-4.2.6 | Optional additional feature
>> to run Jetty with SPDY
>> pax-http-jetty  | 4.2.6|  |
>> Started | org.ops4j.pax.web-4.2.6 |
>> camel-jetty | 2.16.3   |  |
>> Uninstalled | camel-2.16.3|
>> camel-jetty9| 2.16.3   |  |
>> Started | camel-2.16.3|
>> karaf@root(feature)>
>>
>> Would it be a concern?
>>
>> Regards,
>> Allan C.
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Karaf 4.0.5: Second bundle auto restart indefnitely

2016-07-04 Thread Allan C.

I encountered this issue when I was installing some of my bundles. I've
narrowed it down to I think what is the cause of the issue.

For instance, bundle A and B contains the following:



When first bundle is installed, it works fine. But when second bundle is
installed, it will restart indefinitely. As a workaround, my bundles are
now referring to different config files.

Could someone test if it happens to you too? Thanks.

Regards,
Allan C.

Re: Karaf 4.0.5 - Jetty features different versions: pax-jetty and jetty

2016-07-04 Thread Jean-Baptiste Onofré


Thanks Allan,

jetty is an alias feature on top of pax-jetty (for backward compatibility).

Definitely, we upgraded in pax-web, but forgot to update the jetty alias 
feature.


Let me create a Jira to fix that.

Thanks !
Regards
JB

On 07/04/2016 10:20 AM, Allan C. wrote:

I am playing around with 4.0.5 and I noticed that the versions for the
jetty and pax-jetty are different. In Fuse 6.2.1 (I think it is based on
Karaf 2.4.0), the versions are the same.

JBossFuse:karaf@root> features:list | grep jetty
[installed  ] [*8.1.17.v20150415* ] jetty
   karaf-2.4.0.redhat-621084
 Provide Jetty engine support
[installed  ] [2.15.1.redhat-621084 ] camel-jetty
 camel-2.15.1.redhat-621084

[uninstalled] [2.15.1.redhat-621084 ] camel-jetty9
camel-2.15.1.redhat-621084

[installed  ] [*8.1.17.v20150415* ] pax-jetty
   org.ops4j.pax.web-3.2.5
 Provide Jetty engine support
[installed  ] [3.0.4.redhat-621084  ] cxf-http-jetty
cxf-3.0.4.redhat-621084

Karaf 4.0.5:

karaf@root(feature)> list | grep jetty
jetty   | *9.2.10.v20150310* |
  | Started | standard-4.0.5  |
jetty   | 8.1.14.v20131031 |  |
Uninstalled | standard-4.0.5  |
cxf-http-jetty  | 3.1.5|  |
Started | cxf-3.1.5   |
pax-jetty   | *9.2.15.v20160210* |
  | Started | org.ops4j.pax.web-4.2.6 | Provide Jetty engine support
pax-jetty-spdy  | 4.2.6|  |
Uninstalled | org.ops4j.pax.web-4.2.6 | Optional additional feature
to run Jetty with SPDY
pax-http-jetty  | 4.2.6|  |
Started | org.ops4j.pax.web-4.2.6 |
camel-jetty | 2.16.3   |  |
Uninstalled | camel-2.16.3|
camel-jetty9| 2.16.3   |  |
Started | camel-2.16.3|
karaf@root(feature)>

Would it be a concern?

Regards,
Allan C.


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

Re: Log4j NTEventLogAppender in Karaf 4.0.5

2016-07-04 Thread Bengt Rodehav

Another theory: Looking at the stack trace this seems to be triggered by a
configuration update. Could the problem be that Pax-logging is trying to
load the DLL again and failing since it is already loaded? Perhaps the
initial load works but subsequent configuration updates does not?

I tried to verify this...

After successful start of Karaf (after step 9 in my previous post), I edit
org.ops4j.pas.logging.cfg (by changing the root logger between INFO and
DEBUG). This causes no error.

But after having installed feature pax-jetty (after step 10 in my previous
post), every change in org.ops4j.pas.logging.cfg causes the same error to
appear (the stack trace included in my previous post).

It's as if installing the pax-jetty feature takes gives control of
org.ops4j.pas.logging.cfg to someone who cannot load the DLL. I have no
idea how this could happen.

Anyone else has an idea?

/Bengt







/Bengt

2016-07-04 15:51 GMT+02:00 Bengt Rodehav :

> A theory: Could one of the bundles installed by feature pax-jetty be using
> log4j 2.x directly without using Pax-logging? If so, would it too try to
> read the log4j configuration file? I guess it would fail to load the DLL
> since it is probably not compatible with log4j 2.x.
>
> Could this happen? If so, how can I find out which bundle?
>
> /Bengt
>
> 2016-07-04 15:15 GMT+02:00 Bengt Rodehav :
>
>> Back to the Karaf mailing list
>>
>> I can actually get this problem on a standard vanilla Karaf 4.0.5. It
>> seems to be triggered when installing the feature pax-jetty.
>>
>> *1. Install standard Karaf 4.0.5*
>>
>> *2. Replace org.ops4j.pax.logging.cfg with the following:*
>>
>> log4j.rootLogger=INFO, stdout
>>
>> # CONSOLE appender
>> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
>> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
>> log4j.appender.stdout.layout.ConversionPattern=%d{ISO8601} | %-5.5p |
>> %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n
>> log4j.appender.stdout.threshold=ERROR
>>
>> # Windows event log
>> log4j.appender.nteventlog=org.apache.log4j.nt.NTEventLogAppender
>> log4j.appender.nteventlog.source=Test source
>> log4j.appender.nteventlog.layout=org.apache.log4j.PatternLayout
>> log4j.appender.nteventlog.layout.ConversionPattern=Time:
>> %d{ISO8601}%n%nSeverity: %p%n%nThread: %t%n%n%m%n
>> log4j.appender.nteventlog.threshold=DEBUG
>>
>> *3. Start Karaf: "bin\karaf clean"*
>>
>> This should work.
>>
>> *4. Exit Karaf*
>>
>> *5. Change the root looger line to:*
>>
>> log4j.rootLogger=INFO, stdout, nteventlog
>>
>> *6. Start Karaf again*
>>
>> I get the following error:
>>
>> 2016-07-04 15:05:39,534 | ERROR | s4j.pax.logging) | configadmin
>>  | ?? | [org.osgi.service.log.LogService,
>> org.knopflerfish.service.log.LogService,
>> org.ops4j.pax.logging.PaxLoggingService,
>> org.osgi.service.cm.ManagedService, id=12,
>> bundle=6/mvn:org.ops4j.pax.logging/pax-logging-service/1.8.5]: Unexpected
>> problem updating configuration org.ops4j.pax.logging
>> java.lang.UnsatisfiedLinkError: no NTEventLogAppender in java.library.path
>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)
>> at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>> at java.lang.System.loadLibrary(System.java:1122)
>> at
>> org.apache.log4j.nt.NTEventLogAppender.(NTEventLogAppender.java:179)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>> Method)
>> at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>> at java.lang.Class.newInstance(Class.java:442)
>> at
>> org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:336)
>> at
>> org.apache.log4j.helpers.OptionConverter.instantiateByKey(OptionConverter.java:123)
>> at
>> org.apache.log4j.PaxLoggingConfigurator.parseAppender(PaxLoggingConfigurator.java:97)
>> at
>> org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:735)
>> at
>> org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:615)
>> at
>> org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:502)
>> at
>> org.apache.log4j.PaxLoggingConfigurator.doConfigure(PaxLoggingConfigurator.java:72)
>> at
>> org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl.updated(PaxLoggingServiceImpl.java:214)
>> at
>> org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl$1ManagedPaxLoggingService.updated(PaxLoggingServiceImpl.java:362)
>> at
>> org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)
>> at
>>

Re: Log4j NTEventLogAppender in Karaf 4.0.5

2016-07-04 Thread Bengt Rodehav

A theory: Could one of the bundles installed by feature pax-jetty be using
log4j 2.x directly without using Pax-logging? If so, would it too try to
read the log4j configuration file? I guess it would fail to load the DLL
since it is probably not compatible with log4j 2.x.

Could this happen? If so, how can I find out which bundle?

/Bengt

2016-07-04 15:15 GMT+02:00 Bengt Rodehav :

> Back to the Karaf mailing list
>
> I can actually get this problem on a standard vanilla Karaf 4.0.5. It
> seems to be triggered when installing the feature pax-jetty.
>
> *1. Install standard Karaf 4.0.5*
>
> *2. Replace org.ops4j.pax.logging.cfg with the following:*
>
> log4j.rootLogger=INFO, stdout
>
> # CONSOLE appender
> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
> log4j.appender.stdout.layout.ConversionPattern=%d{ISO8601} | %-5.5p |
> %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n
> log4j.appender.stdout.threshold=ERROR
>
> # Windows event log
> log4j.appender.nteventlog=org.apache.log4j.nt.NTEventLogAppender
> log4j.appender.nteventlog.source=Test source
> log4j.appender.nteventlog.layout=org.apache.log4j.PatternLayout
> log4j.appender.nteventlog.layout.ConversionPattern=Time:
> %d{ISO8601}%n%nSeverity: %p%n%nThread: %t%n%n%m%n
> log4j.appender.nteventlog.threshold=DEBUG
>
> *3. Start Karaf: "bin\karaf clean"*
>
> This should work.
>
> *4. Exit Karaf*
>
> *5. Change the root looger line to:*
>
> log4j.rootLogger=INFO, stdout, nteventlog
>
> *6. Start Karaf again*
>
> I get the following error:
>
> 2016-07-04 15:05:39,534 | ERROR | s4j.pax.logging) | configadmin
>| ?? | [org.osgi.service.log.LogService,
> org.knopflerfish.service.log.LogService,
> org.ops4j.pax.logging.PaxLoggingService,
> org.osgi.service.cm.ManagedService, id=12,
> bundle=6/mvn:org.ops4j.pax.logging/pax-logging-service/1.8.5]: Unexpected
> problem updating configuration org.ops4j.pax.logging
> java.lang.UnsatisfiedLinkError: no NTEventLogAppender in java.library.path
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)
> at java.lang.Runtime.loadLibrary0(Runtime.java:870)
> at java.lang.System.loadLibrary(System.java:1122)
> at
> org.apache.log4j.nt.NTEventLogAppender.(NTEventLogAppender.java:179)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at
> org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:336)
> at
> org.apache.log4j.helpers.OptionConverter.instantiateByKey(OptionConverter.java:123)
> at
> org.apache.log4j.PaxLoggingConfigurator.parseAppender(PaxLoggingConfigurator.java:97)
> at
> org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:735)
> at
> org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:615)
> at
> org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:502)
> at
> org.apache.log4j.PaxLoggingConfigurator.doConfigure(PaxLoggingConfigurator.java:72)
> at
> org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl.updated(PaxLoggingServiceImpl.java:214)
> at
> org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl$1ManagedPaxLoggingService.updated(PaxLoggingServiceImpl.java:362)
> at
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)
> at
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)
> at
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)
> at
> org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1753)
> at
> org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)
> at java.lang.Thread.run(Thread.java:745)
>
> This makes sense since I haven't provided the DLL yet.
>
> *7. Exit Karaf*
>
> *8. Put the file NTEventLogAppender.amd64.dll in KARAF_HOME/lib (I attach
> the file for 64 bit Windows)*
>
> *9. Start Karaf again*
>
> This works - no error messages. I take this as "proof" that the DLL has
> been successfully loaded.
>
> *10. Install pax-jetty:*
>
> feature:install pax-jetty
>
> I now get the following error:
>
> 2016-07-04 15:11:17,854 | ERROR | 4j.pax.logging]) | configadmin
>| ?? | [org.osgi.service.log.LogService,
>

Re: bundles starting automatically

2016-07-04 Thread Laci Gaspar


hm, I'm not quite getting this.

when I enter feature:install -v -t bundle1
then I get the following output:


2016-07-04 12:36:50,137 | INFO  | ool-791-thread-1 | 
FeaturesServiceImpl  | 9 - org.apache.karaf.features.core - 
4.0.5 |   Bundles to refresh:

  Bundles to refresh:
2016-07-04 12:36:50,138 | INFO  | ool-791-thread-1 | 
FeaturesServiceImpl  | 9 - org.apache.karaf.features.core - 
4.0.5 | bundle2/3.1.0.SNAPSHOT (Should be wired to: 
bundle3/3.1.0.SNAPSHOT (through [bundle2/3.1.0.SNAPSHOT] 
osgi.wiring.package; 
filter:="(&(osgi.wiring.package=a.b.service)(version>=3.1.0.SNAPSHOT)(version<=3.1.0.SNAPSHOT))"))
bundle2/3.1.0.SNAPSHOT (Should be wired to: bundle3/3.1.0.SNAPSHOT 
(through [bundle2/3.1.0.SNAPSHOT] osgi.wiring.package; 
filter:="(&(osgi.wiring.package=a.b.service)(version>=3.1.0.SNAPSHOT)(version<=3.1.0.SNAPSHOT))"))

... info about 3 more bundles will be refreshed

1. I don't understand what '... should be wired to ... through .. means
2. the stopped bundle that is started up by the resolver is not listed 
in the info which is given by feature:install -v -t. The only connection 
I see, is, that that bundle  is dependend on a bundle which has the same

   groupId as the one listed above (a.b.service)
  ... that sounds a bit complicated. I try again: The stopped bundle X 
is dependent on a.b.service. That is the only connection that I see to 
the info above.


Any ideas?
Thanks
Laci





Am 30.06.2016 um 17:36 schrieb Jean-Baptiste Onofré:

Hi Laci,

yes, the feature resolver can deal with the bundle startup now.

Take a look in etc/org.apache.karaf.features.cfg, you have a property 
to control the resolver behavior.


Generally speaking, the resolver does it for a reason (maybe a 
refresh), so, I would check what it does using -v -t options on 
feature:install.


Regards
JB

On 06/30/2016 03:42 PM, Laci Gaspar wrote:

Hi

we have several bundles (features) installed in karaf 4.0.5.
I noticed that if I stop some of them and after that install a new
feature, the stopped bundles
start automatically.
If I remember correctly this didn't happen in karaf 2.x.

Is it possible to configure the features so that they won't start up
when stopped
with the client?

Thanks.
Regards
Laci

Re: bundles starting automatically

2016-07-04 Thread Laci Gaspar


hm, I'm not quite getting this.

when I enter feature:install -v -t bundle1
then I get the following output:


2016-07-04 12:36:50,137 | INFO  | ool-791-thread-1 | 
FeaturesServiceImpl  | 9 - org.apache.karaf.features.core - 
4.0.5 |   Bundles to refresh:

  Bundles to refresh:
2016-07-04 12:36:50,138 | INFO  | ool-791-thread-1 | 
FeaturesServiceImpl  | 9 - org.apache.karaf.features.core - 
4.0.5 | bundle2/3.1.0.SNAPSHOT (Should be wired to: 
bundle3/3.1.0.SNAPSHOT (through [bundle2/3.1.0.SNAPSHOT] 
osgi.wiring.package; 
filter:="(&(osgi.wiring.package=a.b.service)(version>=3.1.0.SNAPSHOT)(version<=3.1.0.SNAPSHOT))"))
bundle2/3.1.0.SNAPSHOT (Should be wired to: bundle3/3.1.0.SNAPSHOT 
(through [bundle2/3.1.0.SNAPSHOT] osgi.wiring.package; 
filter:="(&(osgi.wiring.package=a.b.service)(version>=3.1.0.SNAPSHOT)(version<=3.1.0.SNAPSHOT))"))

... info about 3 more bundles will be refreshed

1. I don't understand what '... should be wired to ... through .. means
2. the stopped bundle that is started up by the resolver is not listed 
in the info which is given by feature:install -v -t. The only connection 
I see, is, that that bundle  is dependend on a bundle which has the same

   groupId as the one listed above (a.b.service)
  ... that sounds a bit complicated. I try again: The stopped bundle X 
is dependent on a.b.service. That is the only connection that I see to 
the info above.


Any ideas?
Thanks
Laci





Am 30.06.2016 um 17:36 schrieb Jean-Baptiste Onofré:

Hi Laci,

yes, the feature resolver can deal with the bundle startup now.

Take a look in etc/org.apache.karaf.features.cfg, you have a property 
to control the resolver behavior.


Generally speaking, the resolver does it for a reason (maybe a 
refresh), so, I would check what it does using -v -t options on 
feature:install.


Regards
JB

On 06/30/2016 03:42 PM, Laci Gaspar wrote:

Hi

we have several bundles (features) installed in karaf 4.0.5.
I noticed that if I stop some of them and after that install a new
feature, the stopped bundles
start automatically.
If I remember correctly this didn't happen in karaf 2.x.

Is it possible to configure the features so that they won't start up
when stopped
with the client?

Thanks.
Regards
Laci

Karaf 4.0.5 - Jetty features different versions: pax-jetty and jetty

2016-07-04 Thread Allan C.

I am playing around with 4.0.5 and I noticed that the versions for the
jetty and pax-jetty are different. In Fuse 6.2.1 (I think it is based on
Karaf 2.4.0), the versions are the same.

JBossFuse:karaf@root> features:list | grep jetty
[installed  ] [*8.1.17.v20150415* ] jetty
  karaf-2.4.0.redhat-621084
Provide Jetty engine support
[installed  ] [2.15.1.redhat-621084 ] camel-jetty
camel-2.15.1.redhat-621084

[uninstalled] [2.15.1.redhat-621084 ] camel-jetty9
 camel-2.15.1.redhat-621084

[installed  ] [*8.1.17.v20150415* ] pax-jetty
  org.ops4j.pax.web-3.2.5
Provide Jetty engine support
[installed  ] [3.0.4.redhat-621084  ] cxf-http-jetty
 cxf-3.0.4.redhat-621084

Karaf 4.0.5:

karaf@root(feature)> list | grep jetty
jetty   | *9.2.10.v20150310* |  |
Started | standard-4.0.5  |
jetty   | 8.1.14.v20131031 |  |
Uninstalled | standard-4.0.5  |
cxf-http-jetty  | 3.1.5|  |
Started | cxf-3.1.5   |
pax-jetty   | *9.2.15.v20160210* |  |
Started | org.ops4j.pax.web-4.2.6 | Provide Jetty engine support
pax-jetty-spdy  | 4.2.6|  |
Uninstalled | org.ops4j.pax.web-4.2.6 | Optional additional feature to
run Jetty with SPDY
pax-http-jetty  | 4.2.6|  |
Started | org.ops4j.pax.web-4.2.6 |
camel-jetty | 2.16.3   |  |
Uninstalled | camel-2.16.3|
camel-jetty9| 2.16.3   |  |
Started | camel-2.16.3|
karaf@root(feature)>

Would it be a concern?

Regards,
Allan C.

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-07-04 Thread Michael Täschner

Hi,

I think OSGi enroute also provides a small rest implementation, I haven't
looked in detail though:
- http://enroute.osgi.org/services/osgi.enroute.rest.api.html

Cheers,
Michael

2016-07-03 3:25 GMT+02:00 David Leangen :

>
> Very rudimentary, but I list the 5 implementations suggested so far along
> with their “dependencies”. I don’t know if it is the entire list (i.e.
> includes transitive dependencies as well) and if there are optional ones or
> not.
>
> It’s a start.
>
>
> 1. Amdatu Web:
> com.fasterxml.jackson.core.jackson-annotations-2.7.2.jar
> com.fasterxml.jackson.core.jackson-core-2.7.2.jar
> com.fasterxml.jackson.core.jackson-databind-2.7.2.jar
> com.fasterxml.jackson.jaxrs.jackson-jaxrs-base-2.7.2.jar
> com.fasterxml.jackson.jaxrs.jackson-jaxrs-json-provider-2.7.2.jar
> org.amdatu.web.rest.jaxrs-1.0.9.jar
> org.amdatu.web.rest.wink-2.0.3.jar
> org.apache.felix.dependencymanager-4.3.0.jar
> org.apache.felix.dependencymanager.shell-4.0.4.jar (optional)
>
> 2. CFX
> feature "cxf-specs":
> mvn:org.apache.geronimo.specs/geronimo-osgi-registry/1.1
> start-level=9
>
> mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.activation-api-1.1/2.6.0
> start-level=10
> mvn:javax.annotation/javax.annotation-api/1.2
> start-level=10
>
> mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.stax-api-1.0/2.6.0
> start-level=10
>
> mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jaxb-api-2.2/2.6.0
> start-level=10
>
> mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jaxws-api-2.2/2.6.0
> start-level=10
>
> mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.saaj-api-1.3/2.6.0
> start-level=10
>
> mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jsr339-api-2.0.1/2.6.0
> start-level=10
> mvn:javax.mail/mail/1.4.4 start-level=10
> mvn:org.codehaus.woodstox/stax2-api/3.1.4 start-level=20
> mvn:org.codehaus.woodstox/woodstox-core-asl/4.4.1
> start-level=20
>
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jaxb-impl/2.2.11_1
> start-level=20
>
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jaxb-xjc/2.2.11_1
> start-level=20
> feature "cxf-core":
> mvn:org.apache.ws.xmlschema/xmlschema-core/2.2.1
> start-level=30
>
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.xmlresolver/1.2_5
> start-level=25
>
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.fastinfoset/1.2.13_1
> start-level=30
> mvn:org.apache.cxf/cxf-core/3.1.6 start-level=40
> mvn:org.apache.cxf/cxf-rt-management/3.1.6 start-level=40
> feature "cxf-http":
> mvn:org.apache.cxf/cxf-rt-transports-http/3.1.6
> start-level=40
> feature "cxf-jaxrs":
> mvn:org.codehaus.jettison/jettison/1.3.7 start-level=30
> mvn:org.apache.cxf/cxf-rt-rs-extension-providers/3.1.6
> start-level=40
> mvn:org.apache.cxf/cxf-rt-rs-extension-search/3.1.6
> start-level=40
> mvn:org.apache.cxf/cxf-rt-rs-service-description/3.1.6
> start-level=40
> mvn:org.apache.cxf/cxf-rt-frontend-jaxrs/3.1.6
> start-level=40
> mvn:org.apache.cxf/cxf-rt-rs-client/3.1.6 start-level=40
>
> 3. RESTeasy
> ???
>
> 4. Restlet
> ???
>
> 5. Jersey (from:
> https://jersey.java.net/project-info/2.23.1/jersey/project/osgi-helloworld-webapp/war-bundle/dependencies.html
> )
>
> org.glassfish.jersey.examples.osgi-helloworld-webapp:war-bundle:war:2.23.1
>
> org.glassfish.jersey.containers:jersey-container-servlet-core:jar:2.23.1
> (provided)
> org.glassfish.hk2.external:javax.inject:jar:2.4.0-b34 (provided)
> org.glassfish.jersey.core:jersey-common:jar:2.23.1 (provided)
> javax.annotation:javax.annotation-api:jar:1.2 (provided)
> org.glassfish.jersey.bundles.repackaged:jersey-guava:jar:2.23.1
> (provided)
> org.glassfish.hk2:hk2-api:jar:2.4.0-b34 (provided)
> org.glassfish.hk2:hk2-utils:jar:2.4.0-b34 (provided)
> org.glassfish.hk2.external:aopalliance-repackaged:jar:2.4.0-b34
> (provided)
> org.glassfish.hk2:hk2-locator:jar:2.4.0-b34 (provided)
> org.javassist:javassist:jar:3.18.1-GA (provided)
> org.glassfish.hk2:osgi-resource-locator:jar:1.0.1 (provided)
> org.glassfish.jersey.core:jersey-server:jar:2.23.1 (provided)
> org.glassfish.jersey.core:jersey-client:jar:2.23.1 (provided)
> org.glassfish.jersey.media:jersey-media-jaxb:jar:2.23.1 (provided)
> javax.validation:validation-api:jar:1.1.0.Final (provided)
>
> org.glassfish.jersey.examples.osgi-helloworld-webapp:lib-bundle:jar:2.23.1
> (compile)
>
> org.glassfish.jersey.examples.osgi-helloworld-webapp:additional-bundle:jar:2.23.1
> (compile)
>
>

Re: Karaf 4.0.5 - Jetty features different versions: pax-jetty and jetty

Karaf 4.0.5: Second bundle auto restart indefnitely

Re: Karaf 4.0.5 - Jetty features different versions: pax-jetty and jetty

Re: Log4j NTEventLogAppender in Karaf 4.0.5

Re: Log4j NTEventLogAppender in Karaf 4.0.5

Re: bundles starting automatically

Re: bundles starting automatically

Karaf 4.0.5 - Jetty features different versions: pax-jetty and jetty

Re: JAX-RS Annotations and Apache Karaf 4.0.5

9 matches

Site Navigation

Mail list logo

Footer information