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: JAX-RS Annotations and Apache Karaf 4.0.5

2016-07-02 Thread 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) 

org.glassfish.jersey.examples.osgi-helloworld-webapp:alternate-version-bundle:jar:2.23.1
 (compile) 
javax.ws.rs:javax.ws.rs-api:jar:2.0.1 (provided) 
javax.servlet:servlet-api:jar:2.5 (provided)

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-07-02 Thread James Carman 
There's Jersey, the reference implementation

On Sat, Jul 2, 2016 at 8:00 PM  wrote:

> >
> > Very interesting. Thank you for this.
> >
> >> [1] https://wiki.eclipse.org/Distribution_Providers
> >> [2] https://wiki.eclipse.org/EIG:Remote_Services_Admin
> >> [3]
> >>
> https://wiki.eclipse.org/Tutorial:_Exposing_a_Jax_REST_service_as_an_OSGi_Remote_Service
> >> [4] https://github.com/ECF/JaxRSProviders
> >> [5] https://www.eclipse.org/ecf/
> >
> >
> > Question: is there a more light-weight JAX-RS implementation out there?
>
> The only other jaxrs impls that I know about are resteasy and restlet.
> Might be new/others of course.
>
>
>
>

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-07-02 Thread Scott Lewis 

On 7/2/2016 9:07 AM, David Daniel wrote:
The problem with the single bundle approach is extension points.  How 
do you handle letting people handle filters so they can customize 
authorization, or CORS settings? How do you let them have a custom way 
to inject session so that they can do something like have a shared 
session across services?  Serialization is a huge one.  OSGI seems to 
be going to the DTO objects but they are very limiting in my opinion 
and I personally like that different options allow for me to have 
different providers for gson, jackson, minimal json ...  A big one for 
me is also threading.  If each request gets it's own thread then what 
happens with long running processes that hit a database.  I love the 
ease of rest and agree that J2E has a lot of standards but as projects 
grow I find myself having to customize many different aspects of how 
it works and like to have a framework that implements the standards.


This is a very nice explanation for why ECF's implementation of RS/RSA 
allows pluggable distribution providers, and the easy creation of one's 
own distribution provider (able to customize auth, session handling, 
serialization, pass-by-ref or pass-by-value, threading/asynchronous, 
wire protocol, client/server vs topic/group impl, service discovery, 
reliability requirements, and others [1-2].  Any/all of these providers 
automatically implement/compliant with the OSGI RS/RSA specs, which 
allows services built upon the specs to easily move between distribution 
providers if requirements change...without having to rewrite service 
impl or consumer code.


I currently use https://github.com/hstaudacher/osgi-jax-rs-connector 
like mentioned earlier but I am starting to do more with vertx and 
unfortunately finding myself moving away from the standards.  The 
standards and especially JEE seem to be falling behind technology.  
OSGI has a jaxrs standard in the works 
https://github.com/osgi/design/blob/master/rfps/rfp-0173-JAX-RS-Services.pdf 
I would love to see a minimal implementation of it that is really 
extensible but I think there are tradeoffs that need to be made and 
having lots of options allows the user to choose which ones they find 
acceptable.


Yes, indeed.

Scott

[1] 
https://wiki.eclipse.org/Tutorial:_Creating_Custom_Distribution_Providers
[2] 
http://eclipseecf.blogspot.com/2016/04/remote-services-over-unreliable-networks.html





On Sat, Jul 2, 2016 at 11:41 AM, David Leangen > wrote:



IMO, this is too fine grained. If I want to install “REST”, there
should ideally be a single bundle.

Of course, I can imagine that there are people who want/need to
work at that level of granularity. They should have that option,
but if I only want “REST”, then this really complicates my system.
:-(  If every feature worked that way, I could imagine pulling in
many hundreds of bundles very quickly. Even the "simplest” system
would no longer be simple at the component level.

Has anybody considered shipping all this packaged as a single
bundle? (And has anybody questioned if all those dependencies are
*really* necessary?)

Just askin'. :-)


Cheers,
=David




On Jul 2, 2016, at 9:58 PM, Christian Schneider
> wrote:

I am also not sure if we really still need all the spec overrides
in Java 7 and 8. Maybe we can slim that down a bit.

I am just working on CXF-DOSGi and the multibundle distro
contains almost 100 deps. A lot of these come from pax-web which
includes a lot of stuff I do not really need but it is installed
by the lkaraf http feature.

Christian


2016-07-02 13:53 GMT+02:00 James Carman
>:



On Sat, Jul 2, 2016 at 4:13 AM David Leangen
> wrote:



Question: is there a more light-weight JAX-RS
implementation out there? I am not happy about how
bloated CFX seems to be. I don’t like having to pull in
that long list of dependencies. For something as “simple”
as REST, it sure complicates my system. Bleh.


This is the list of dependencies for the "cxf-jaxrs" feature
version 3.1.6 in Karaf:

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

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-07-02 Thread David Daniel 
The problem with the single bundle approach is extension points.  How do
you handle letting people handle filters so they can customize
authorization, or CORS settings?  How do you let them have a custom way to
inject session so that they can do something like have a shared session
across services?  Serialization is a huge one.  OSGI seems to be going to
the DTO objects but they are very limiting in my opinion and I personally
like that different options allow for me to have different providers for
gson, jackson, minimal json ...  A big one for me is also threading.  If
each request gets it's own thread then what happens with long running
processes that hit a database.  I love the ease of rest and agree that J2E
has a lot of standards but as projects grow I find myself having to
customize many different aspects of how it works and like to have a
framework that implements the standards.  I currently use
https://github.com/hstaudacher/osgi-jax-rs-connector like mentioned earlier
but I am starting to do more with vertx and unfortunately finding myself
moving away from the standards.  The standards and especially JEE seem to
be falling behind technology.  OSGI has a jaxrs standard in the works
https://github.com/osgi/design/blob/master/rfps/rfp-0173-JAX-RS-Services.pdf
I would love to see a minimal implementation of it that is really
extensible but I think there are tradeoffs that need to be made and having
lots of options allows the user to choose which ones they find acceptable.

On Sat, Jul 2, 2016 at 11:41 AM, David Leangen  wrote:

>
> IMO, this is too fine grained. If I want to install “REST”, there should
> ideally be a single bundle.
>
> Of course, I can imagine that there are people who want/need to work at
> that level of granularity. They should have that option, but if I only want
> “REST”, then this really complicates my system. :-(  If every feature
> worked that way, I could imagine pulling in many hundreds of bundles very
> quickly. Even the "simplest” system would no longer be simple at the
> component level.
>
> Has anybody considered shipping all this packaged as a single bundle? (And
> has anybody questioned if all those dependencies are *really* necessary?)
>
> Just askin'. :-)
>
>
> Cheers,
> =David
>
>
>
> On Jul 2, 2016, at 9:58 PM, Christian Schneider 
> wrote:
>
> I am also not sure if we really still need all the spec overrides in Java
> 7 and 8. Maybe we can slim that down a bit.
>
> I am just working on CXF-DOSGi and the multibundle distro contains almost
> 100 deps. A lot of these come from pax-web which includes a lot of stuff I
> do not really need but it is installed by the lkaraf http feature.
>
> Christian
>
>
> 2016-07-02 13:53 GMT+02:00 James Carman :
>
>>
>>
>> On Sat, Jul 2, 2016 at 4:13 AM David Leangen  wrote:
>>
>>>
>>>
>>> Question: is there a more light-weight JAX-RS implementation out there?
>>> I am not happy about how bloated CFX seems to be. I don’t like having to
>>> pull in that long list of dependencies. For something as “simple” as REST,
>>> it sure complicates my system. Bleh.
>>>
>>>
>> This is the list of dependencies for the "cxf-jaxrs" feature version
>> 3.1.6 in Karaf:
>>
>> 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":
>>
>>

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-07-02 Thread David Leangen 

IMO, this is too fine grained. If I want to install “REST”, there should 
ideally be a single bundle.

Of course, I can imagine that there are people who want/need to work at that 
level of granularity. They should have that option, but if I only want “REST”, 
then this really complicates my system. :-(  If every feature worked that way, 
I could imagine pulling in many hundreds of bundles very quickly. Even the 
"simplest” system would no longer be simple at the component level.

Has anybody considered shipping all this packaged as a single bundle? (And has 
anybody questioned if all those dependencies are *really* necessary?)

Just askin'. :-)


Cheers,
=David



> On Jul 2, 2016, at 9:58 PM, Christian Schneider  
> wrote:
> 
> I am also not sure if we really still need all the spec overrides in Java 7 
> and 8. Maybe we can slim that down a bit.
> 
> I am just working on CXF-DOSGi and the multibundle distro contains almost 100 
> deps. A lot of these come from pax-web which includes a lot of stuff I do not 
> really need but it is installed by the lkaraf http feature.
> 
> Christian
> 
> 
> 2016-07-02 13:53 GMT+02:00 James Carman  >:
> 
> 
> On Sat, Jul 2, 2016 at 4:13 AM David Leangen  > wrote:
> 
> 
> Question: is there a more light-weight JAX-RS implementation out there? I am 
> not happy about how bloated CFX seems to be. I don’t like having to pull in 
> that long list of dependencies. For something as “simple” as REST, it sure 
> complicates my system. Bleh.
> 
> 
> This is the list of dependencies for the "cxf-jaxrs" feature version 3.1.6 in 
> Karaf:
> 
> 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
> 
> Most of that is the "spec" stuff.  I wouldn't really consider that too 
> bloated.  It's extremely easy to install using Karaf features:
> 
> feature:repo-add cxf 3.1.6
> feature:install cxf-jaxrs
> 
> 
> 
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de 
> 
> 
> Open Source Architect
> http://www.talend.com 
>

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-07-02 Thread Christian Schneider 
I am also not sure if we really still need all the spec overrides in Java 7
and 8. Maybe we can slim that down a bit.

I am just working on CXF-DOSGi and the multibundle distro contains almost
100 deps. A lot of these come from pax-web which includes a lot of stuff I
do not really need but it is installed by the lkaraf http feature.

Christian


2016-07-02 13:53 GMT+02:00 James Carman :

>
>
> On Sat, Jul 2, 2016 at 4:13 AM David Leangen  wrote:
>
>>
>>
>> Question: is there a more light-weight JAX-RS implementation out there? I
>> am not happy about how bloated CFX seems to be. I don’t like having to pull
>> in that long list of dependencies. For something as “simple” as REST, it
>> sure complicates my system. Bleh.
>>
>>
> This is the list of dependencies for the "cxf-jaxrs" feature version 3.1.6
> in Karaf:
>
> 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
>
> Most of that is the "spec" stuff.  I wouldn't really consider that too
> bloated.  It's extremely easy to install using Karaf features:
>
> feature:repo-add cxf 3.1.6
> feature:install cxf-jaxrs
>
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Open Source Architect
http://www.talend.com

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-07-02 Thread James Carman 
On Sat, Jul 2, 2016 at 4:13 AM David Leangen  wrote:

>
>
> Question: is there a more light-weight JAX-RS implementation out there? I
> am not happy about how bloated CFX seems to be. I don’t like having to pull
> in that long list of dependencies. For something as “simple” as REST, it
> sure complicates my system. Bleh.
>
>
This is the list of dependencies for the "cxf-jaxrs" feature version 3.1.6
in Karaf:

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

Most of that is the "spec" stuff.  I wouldn't really consider that too
bloated.  It's extremely easy to install using Karaf features:

feature:repo-add cxf 3.1.6
feature:install cxf-jaxrs

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-07-02 Thread Christian Schneider 
The Amdatu JAXRS support sounds interesting for light weight deploys.
Should we create a Karaf feature for it?

Christian

2016-07-02 11:22 GMT+02:00 Bram Pouwelse :

> You could have a look at Amdatu Web [1], that has a JAX-RS implementation
> that doesn't have a long list of dependencies. The dependencies on the
> website state that the Felix Http service and whiteboard are required but
> just tested this with the http-whiteboard feature provided by Karaf and
> this works as well.
>
> Added the full list of bundles I've deployed to get this working below.
>
> Cheers,
> Bram
>
> List of bundles:
> 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)
>
>
> 1: http://amdatu.org/components/web.html
>
> On Sat, Jul 2, 2016 at 10:13 AM David Leangen  wrote:
>
>>
>> Very interesting. Thank you for this.
>>
>> > [1] https://wiki.eclipse.org/Distribution_Providers
>> > [2] https://wiki.eclipse.org/EIG:Remote_Services_Admin
>> > [3]
>> https://wiki.eclipse.org/Tutorial:_Exposing_a_Jax_REST_service_as_an_OSGi_Remote_Service
>> > [4] https://github.com/ECF/JaxRSProviders
>> > [5] https://www.eclipse.org/ecf/
>>
>>
>> Question: is there a more light-weight JAX-RS implementation out there? I
>> am not happy about how bloated CFX seems to be. I don’t like having to pull
>> in that long list of dependencies. For something as “simple” as REST, it
>> sure complicates my system. Bleh.
>>
>> There must be a simpler way...
>>
>>
>> Cheers,
>> =David
>>
>>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Open Source Architect
http://www.talend.com

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-07-02 Thread Bram Pouwelse 
You could have a look at Amdatu Web [1], that has a JAX-RS implementation
that doesn't have a long list of dependencies. The dependencies on the
website state that the Felix Http service and whiteboard are required but
just tested this with the http-whiteboard feature provided by Karaf and
this works as well.

Added the full list of bundles I've deployed to get this working below.

Cheers,
Bram

List of bundles:
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)


1: http://amdatu.org/components/web.html

On Sat, Jul 2, 2016 at 10:13 AM David Leangen  wrote:

>
> Very interesting. Thank you for this.
>
> > [1] https://wiki.eclipse.org/Distribution_Providers
> > [2] https://wiki.eclipse.org/EIG:Remote_Services_Admin
> > [3]
> https://wiki.eclipse.org/Tutorial:_Exposing_a_Jax_REST_service_as_an_OSGi_Remote_Service
> > [4] https://github.com/ECF/JaxRSProviders
> > [5] https://www.eclipse.org/ecf/
>
>
> Question: is there a more light-weight JAX-RS implementation out there? I
> am not happy about how bloated CFX seems to be. I don’t like having to pull
> in that long list of dependencies. For something as “simple” as REST, it
> sure complicates my system. Bleh.
>
> There must be a simpler way...
>
>
> Cheers,
> =David
>
>

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-07-02 Thread David Leangen 

Very interesting. Thank you for this.

> [1] https://wiki.eclipse.org/Distribution_Providers
> [2] https://wiki.eclipse.org/EIG:Remote_Services_Admin
> [3] 
> https://wiki.eclipse.org/Tutorial:_Exposing_a_Jax_REST_service_as_an_OSGi_Remote_Service
> [4] https://github.com/ECF/JaxRSProviders
> [5] https://www.eclipse.org/ecf/


Question: is there a more light-weight JAX-RS implementation out there? I am 
not happy about how bloated CFX seems to be. I don’t like having to pull in 
that long list of dependencies. For something as “simple” as REST, it sure 
complicates my system. Bleh.

There must be a simpler way...


Cheers,
=David

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-07-01 Thread Scott Lewis 

On 7/1/2016 10:15 AM, Benson Margulies wrote:

I have a ton of working JAX-RS in 4.0.4 with CXF 3.1.x. I didn't see
the start of this thread. What's the problem?


There's no problem.   I was simply pointing out to Markus that ECF has a 
Jax-RS-based distribution provider among many others [1], all of which 
implement the most recent OSGi Remote Service and Remote Service Admin 
specifications.   I understand that many are not familiar with these 
specifications and am trying to make that more commonly know.   These 
are OSGi standards for doing remote OSGi services and do ease some of 
the development pain of doing remote OSGi services, particularly as a 
way to avoid transport/impl lock-in.   We also have a tutorial [3] 
describing the use of Jax-RS along with remote services.


Our Jax-RS distribution provider [4] can/does use CXF.  Having the 
ability to select providers (or create one's own) can be beneficial 
since...among other advantages...people would like to have their OSGi 
services inter-operate with existing deployed services, while being able 
to add and use OSGi remote services for OSGi runtimes like Karaf.


Markus:  WRT SmartHome, it might be useful for you/your project to look 
at ECF [5], since it's an EF mature project, is a fully compliant impl 
of RS/RSA specs, and also supports several of the IoT protocols (e.g. 
MQTT, etc).


Scott

[1] https://wiki.eclipse.org/Distribution_Providers
[2] https://wiki.eclipse.org/EIG:Remote_Services_Admin
[3] 
https://wiki.eclipse.org/Tutorial:_Exposing_a_Jax_REST_service_as_an_OSGi_Remote_Service

[4] https://github.com/ECF/JaxRSProviders
[5] https://www.eclipse.org/ecf/





On Fri, Jul 1, 2016 at 1:12 PM, Markus Rathgeb  wrote:

Hi Scott,

my knowledge about ECF, CXF, JAX-RS is very very small.
In the past I need to get the OSGi JAX-RS of hstaudacher working in
Karaf (at least to support Karaf Features for the Eclipse SmartHome
project and openHAB etc.). The projects already exist and already use
JAX-RS.
I started using the stuff hstaudacher provides, but I was not happy as
I realized that he creates bundles that are just a collection of a lot
of other bundles.

I don't know the pro and cons of the different projects and ATM its
nothing I need to care.
The only thing I want to state is if Artur needs to use JAX-RS, he can
have a look at the Karaf feature and the work I have already done.

And last but not least, I assume that the hstaudacher does not really
work on JAX-RS anymore.

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-07-01 Thread Markus Rathgeb 
Hi Benson,
the whole message list could be found here:
http://karaf.922171.n3.nabble.com/JAX-RS-Annotations-and-Apache-Karaf-4-0-5-td4047001.html#a4047014

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-07-01 Thread Benson Margulies 
I have a ton of working JAX-RS in 4.0.4 with CXF 3.1.x. I didn't see
the start of this thread. What's the problem?


On Fri, Jul 1, 2016 at 1:12 PM, Markus Rathgeb  wrote:
> Hi Scott,
>
> my knowledge about ECF, CXF, JAX-RS is very very small.
> In the past I need to get the OSGi JAX-RS of hstaudacher working in
> Karaf (at least to support Karaf Features for the Eclipse SmartHome
> project and openHAB etc.). The projects already exist and already use
> JAX-RS.
> I started using the stuff hstaudacher provides, but I was not happy as
> I realized that he creates bundles that are just a collection of a lot
> of other bundles.
>
> I don't know the pro and cons of the different projects and ATM its
> nothing I need to care.
> The only thing I want to state is if Artur needs to use JAX-RS, he can
> have a look at the Karaf feature and the work I have already done.
>
> And last but not least, I assume that the hstaudacher does not really
> work on JAX-RS anymore.

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-07-01 Thread Markus Rathgeb 
Hi Scott,

my knowledge about ECF, CXF, JAX-RS is very very small.
In the past I need to get the OSGi JAX-RS of hstaudacher working in
Karaf (at least to support Karaf Features for the Eclipse SmartHome
project and openHAB etc.). The projects already exist and already use
JAX-RS.
I started using the stuff hstaudacher provides, but I was not happy as
I realized that he creates bundles that are just a collection of a lot
of other bundles.

I don't know the pro and cons of the different projects and ATM its
nothing I need to care.
The only thing I want to state is if Artur needs to use JAX-RS, he can
have a look at the Karaf feature and the work I have already done.

And last but not least, I assume that the hstaudacher does not really
work on JAX-RS anymore.

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-07-01 Thread Scott Lewis 

Hi Markus,

My point was that ECF's implementation of Jax-RS is small, modular, and 
compliant with the RS/RSA specs.   AFAIK the OSGi JAX-RS Connector 
project is not.


Scott

On 7/1/2016 1:17 AM, Markus Rathgeb wrote:

The Karaf Features provided by Holger Staudacher are using bundles
that package a lot of other bundles in a single one.
If you don't want to have such very big bundles in your runtime and
prefer using the separate bundles (to be reused by other ones, etc.)
you can have a look at the Features I created for another project:

https://github.com/eclipse/smarthome/blob/master/features/karaf-tp/src/main/feature/feature.xml#L39

At least if you have a look at the jersey-min feature, you see that
the one bundle of "OSGi JAX-RS Connector / GitHub" consists of a lot
of other bundles (and more, I dopped the duplcates).

The jersey-min one is available here, too:
https://dl.bintray.com/maggu2810/maven/de/maggu2810/kat/features/jersey-min/1.5/:jersey-min-1.5-features.xml

2016-06-30 17:32 GMT+02:00 Scott Lewis :

Also to consider:  ECF provides an impl of the OSGi R6 Remote Service/Remote
Service Admin specifications [1] with pluggable distribution providers [2].

Our Jax-RS provider [3] uses/is based upon CXF (or Jersey).

Scott

[1] https://wiki.eclipse.org/Eclipse_Communication_Framework_Project
[2] https://wiki.eclipse.org/Distribution_Providers
[3] https://github.com/ECF/JaxRSProviders


On 6/30/2016 6:12 AM, James Carman wrote:

Consider using CXF. Very well tested.
On Thu, Jun 30, 2016 at 8:46 AM Artur Lojewski  wrote:

OK,

thanks both of you for your response! I forgot to mention that I am using
the 'OSGi JAX-RS Connector' v5.3.1 from EclipseSource.

So one can use the config admin to set the 'root' path as follows:

/config:property-set -p com.eclipsesource.jaxrs.connector root /foo/

This works for root paths like '/abc', '/ab' and '/a' - but not '/' alone!
When I use '/' as root path value I cannot call http://localhost/abd/def.
This seems to be a bug in the implementation.

Moreover, configuring the 2nd config admin parameter 'publishDelay'
results
in a ClassCastException...

So I guess I have to contact Holger Staudacher (OSGi JAX-RS Connector /
GitHub).

Thanks for your help!



--
View this message in context:
http://karaf.922171.n3.nabble.com/JAX-RS-Annotations-and-Apache-Karaf-4-0-5-tp4047001p4047014.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-07-01 Thread Markus Rathgeb 
The Karaf Features provided by Holger Staudacher are using bundles
that package a lot of other bundles in a single one.
If you don't want to have such very big bundles in your runtime and
prefer using the separate bundles (to be reused by other ones, etc.)
you can have a look at the Features I created for another project:

https://github.com/eclipse/smarthome/blob/master/features/karaf-tp/src/main/feature/feature.xml#L39

At least if you have a look at the jersey-min feature, you see that
the one bundle of "OSGi JAX-RS Connector / GitHub" consists of a lot
of other bundles (and more, I dopped the duplcates).

The jersey-min one is available here, too:
https://dl.bintray.com/maggu2810/maven/de/maggu2810/kat/features/jersey-min/1.5/:jersey-min-1.5-features.xml

2016-06-30 17:32 GMT+02:00 Scott Lewis :
> Also to consider:  ECF provides an impl of the OSGi R6 Remote Service/Remote
> Service Admin specifications [1] with pluggable distribution providers [2].
>
> Our Jax-RS provider [3] uses/is based upon CXF (or Jersey).
>
> Scott
>
> [1] https://wiki.eclipse.org/Eclipse_Communication_Framework_Project
> [2] https://wiki.eclipse.org/Distribution_Providers
> [3] https://github.com/ECF/JaxRSProviders
>
>
> On 6/30/2016 6:12 AM, James Carman wrote:
>
> Consider using CXF. Very well tested.
> On Thu, Jun 30, 2016 at 8:46 AM Artur Lojewski  wrote:
>>
>> OK,
>>
>> thanks both of you for your response! I forgot to mention that I am using
>> the 'OSGi JAX-RS Connector' v5.3.1 from EclipseSource.
>>
>> So one can use the config admin to set the 'root' path as follows:
>>
>> /config:property-set -p com.eclipsesource.jaxrs.connector root /foo/
>>
>> This works for root paths like '/abc', '/ab' and '/a' - but not '/' alone!
>> When I use '/' as root path value I cannot call http://localhost/abd/def.
>> This seems to be a bug in the implementation.
>>
>> Moreover, configuring the 2nd config admin parameter 'publishDelay'
>> results
>> in a ClassCastException...
>>
>> So I guess I have to contact Holger Staudacher (OSGi JAX-RS Connector /
>> GitHub).
>>
>> Thanks for your help!
>>
>>
>>
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/JAX-RS-Annotations-and-Apache-Karaf-4-0-5-tp4047001p4047014.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>
>

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-06-30 Thread Scott Lewis 
Also to consider:  ECF provides an impl of the OSGi R6 Remote 
Service/Remote Service Admin specifications [1] with pluggable 
distribution providers [2].


Our Jax-RS provider [3] uses/is based upon CXF (or Jersey).

Scott

[1] https://wiki.eclipse.org/Eclipse_Communication_Framework_Project
[2] https://wiki.eclipse.org/Distribution_Providers
[3] https://github.com/ECF/JaxRSProviders

On 6/30/2016 6:12 AM, James Carman wrote:

Consider using CXF. Very well tested.
On Thu, Jun 30, 2016 at 8:46 AM Artur Lojewski > wrote:


OK,

thanks both of you for your response! I forgot to mention that I
am using
the 'OSGi JAX-RS Connector' v5.3.1 from EclipseSource.

So one can use the config admin to set the 'root' path as follows:

/config:property-set -p com.eclipsesource.jaxrs.connector root /foo/

This works for root paths like '/abc', '/ab' and '/a' - but not
'/' alone!
When I use '/' as root path value I cannot call
http://localhost/abd/def.
This seems to be a bug in the implementation.

Moreover, configuring the 2nd config admin parameter
'publishDelay' results
in a ClassCastException...

So I guess I have to contact Holger Staudacher (OSGi JAX-RS
Connector /
GitHub).

Thanks for your help!



--
View this message in context:

http://karaf.922171.n3.nabble.com/JAX-RS-Annotations-and-Apache-Karaf-4-0-5-tp4047001p4047014.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-06-30 Thread James Carman 
Consider using CXF. Very well tested.
On Thu, Jun 30, 2016 at 8:46 AM Artur Lojewski  wrote:

> OK,
>
> thanks both of you for your response! I forgot to mention that I am using
> the 'OSGi JAX-RS Connector' v5.3.1 from EclipseSource.
>
> So one can use the config admin to set the 'root' path as follows:
>
> /config:property-set -p com.eclipsesource.jaxrs.connector root /foo/
>
> This works for root paths like '/abc', '/ab' and '/a' - but not '/' alone!
> When I use '/' as root path value I cannot call http://localhost/abd/def.
> This seems to be a bug in the implementation.
>
> Moreover, configuring the 2nd config admin parameter 'publishDelay' results
> in a ClassCastException...
>
> So I guess I have to contact Holger Staudacher (OSGi JAX-RS Connector /
> GitHub).
>
> Thanks for your help!
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/JAX-RS-Annotations-and-Apache-Karaf-4-0-5-tp4047001p4047014.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-06-30 Thread Artur Lojewski 
OK,

thanks both of you for your response! I forgot to mention that I am using
the 'OSGi JAX-RS Connector' v5.3.1 from EclipseSource.

So one can use the config admin to set the 'root' path as follows:

/config:property-set -p com.eclipsesource.jaxrs.connector root /foo/

This works for root paths like '/abc', '/ab' and '/a' - but not '/' alone!
When I use '/' as root path value I cannot call http://localhost/abd/def.
This seems to be a bug in the implementation.

Moreover, configuring the 2nd config admin parameter 'publishDelay' results
in a ClassCastException...

So I guess I have to contact Holger Staudacher (OSGi JAX-RS Connector /
GitHub).

Thanks for your help!



--
View this message in context: 
http://karaf.922171.n3.nabble.com/JAX-RS-Annotations-and-Apache-Karaf-4-0-5-tp4047001p4047014.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-06-30 Thread Jean-Baptiste Onofré 

Hi Artur,

/services is the CXF context.

To change it, you have to change the CXF config in 
etc/org.apache.cxf.osgi.cfg:


org.apache.cxf.servlet.context=/services

Regards
JB

On 06/30/2016 07:28 AM, Artur Lojewski wrote:

Hi,

I am implementing a REST service with Apache Karaf 4.0.5 with JAX-RS
annotations only, i.e. no web.xml. My implementation  uses the
@ApplicationPath("/abc") and @Path("/def") annotations.

When I deploy my bundle into Karaf I can successfully access the service via

http://localhost/services/abc/def

However, I want

http://localhost/abc/def

It seems like my implementation missed something. I assumed that
@ApplicationPag("abc") should be sufficient, but it does not.

Can anybody give me a hint how this can be fixed?


Best Regards,

Artur





--
View this message in context: 
http://karaf.922171.n3.nabble.com/JAX-RS-Annotations-and-Apache-Karaf-4-0-5-tp4047001.html
Sent from the Karaf - User mailing list archive at Nabble.com.



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

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-06-29 Thread Allan C. 
Have you tried configuring your jaxrs server address to "/"?

Something like this:

http://0.0.0.0:8080/;>


Regards,
Allan C.

On Thu, Jun 30, 2016 at 1:28 PM, Artur Lojewski  wrote:

> Hi,
>
> I am implementing a REST service with Apache Karaf 4.0.5 with JAX-RS
> annotations only, i.e. no web.xml. My implementation  uses the
> @ApplicationPath("/abc") and @Path("/def") annotations.
>
> When I deploy my bundle into Karaf I can successfully access the service
> via
>
> http://localhost/services/abc/def
>
> However, I want
>
> http://localhost/abc/def
>
> It seems like my implementation missed something. I assumed that
> @ApplicationPag("abc") should be sufficient, but it does not.
>
> Can anybody give me a hint how this can be fixed?
>
>
> Best Regards,
>
> Artur
>
>
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/JAX-RS-Annotations-and-Apache-Karaf-4-0-5-tp4047001.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>