Hi
On 03/05/13 10:53, Julio Carlos Barrera Juez wrote:
Well, it is not possible to register more than one service using DOSGi
using the same "org.apache.cxf.rs.httpservice.context". I updated CXF to
2.7.4 and DOSGi to 1.4.0 and now I'm using
"org.apache.cxf.rs.httpservice.context"
property with full relative address and "org.apache.cxf.rs.address" "/" in
all my services. With this configuration, all the endpoint are correctly
deployed and are accessible, including WADLs.

Thank you for your assistance, Sergey!!

Thanks for all your experiments, glad it works, though I have to admit I'm not exactly sure why it works :-). It appears to be we have a case where a single HTTP context effectively works with a single 'virtual' JAX-RS endpoint, where all the bundles contribute individual root services...

I'll experiment with all of it later when we get to doing DOSGi 1.5 release

Sergey


On 2 May 2013 13:22, Julio Carlos Barrera Juez<
juliocarlos.barr...@i2cat.net>  wrote:

Is there any way to publish my REST API not using
"org.apache.cxf.rs.httpservice.context" property and using different
"org.apache.cxf.rs.address" relative paths property with DOSGi? When I used
absolute paths it worked, now I need to use HTTP service and it is
a nightmare achieving same goal.



On 2 May 2013 12:11, Julio Carlos Barrera Juez<
juliocarlos.barr...@i2cat.net>  wrote:

As I mentioned a few times, if I register two services with the same
"org.apache.cxf.rs.httpservice.context" property with value like "/myApp" I
get an error:

Exception in thread "pool-12-thread-4"
org.osgi.framework.ServiceException: CXF DOSGi: problem registering CXF
HTTP Servlet
  at
org.apache.cxf.dosgi.dsw.handlers.HttpServiceConfigurationTypeHandler.registerServletAndGetBus(HttpServiceConfigurationTypeHandler.java:200)
at
org.apache.cxf.dosgi.dsw.handlers.JaxRSHttpServiceConfigurationTypeHandler.createServer(JaxRSHttpServiceConfigurationTypeHandler.java:55)
  at
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportService(RemoteServiceAdminCore.java:247)
at
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:72)
  at
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:67)
at java.security.AccessController.doPrivileged(Native Method)
  at
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:66)
at
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:38)
  at
org.apache.cxf.dosgi.topologymanager.TopologyManager$2.run(TopologyManager.java:267)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
  at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.osgi.service.http.NamespaceException: alias is already in
use in this or another context
at
org.ops4j.pax.web.service.spi.model.ServerModel.addServletModel(ServerModel.java:120)
  at
org.ops4j.pax.web.service.internal.HttpServiceStarted.registerServlet(HttpServiceStarted.java:139)
at
org.ops4j.pax.web.service.internal.HttpServiceProxy.registerServlet(HttpServiceProxy.java:56)
  at
org.apache.cxf.dosgi.dsw.handlers.HttpServiceConfigurationTypeHandler.registerServletAndGetBus(HttpServiceConfigurationTypeHandler.java:194)
... 11 more

Moreover, the endpoint registered loses his portion of path corresponding
to "org.apache.cxf.rs.address" property. It means that my desired URL
"/myApp/serviceA/methodY" is transformed to "/myApp/methodY".

And the mixing of services is produced anyway, if I look for serviceA
WADL ("myApp/serviceA?_wadl") I get exactly the same as if I look for
serviceB WADL ("myApp/serviceB?_wadl"). Same addresses referring to
serviceB in both cases.


On 2 May 2013 11:57, Sergey Beryozkin<sberyoz...@gmail.com>  wrote:

On 02/05/13 10:52, Julio Carlos Barrera Juez wrote:

What fix? Is there any bug in version 1.3? I am going to try changing
the
version, but what now? Do need I to use both properties? How to achieve
having an URL like "/myApp/serviceX/methodY"


yes, ex, "/myApp" for the the context property and "/serviceX/methodY"
for the rs.address property will give you that combined relative path

Sergey




On 2 May 2013 11:39, Sergey Beryozkin<sberyoz...@gmail.com**>   wrote:

  On 02/05/13 10:34, Julio Carlos Barrera Juez wrote:

  I am using DOSGI 1.3 with bundles cxf-dosgi-ri-discovery-local and
cxf-dosgi-ri-dsw-cxf. And CXF 2.4.3. It is difficult to choose a
different
version, because we use a concrete Servicemix version (4.4.1), quite
old,
we know :-( .


The fix I was referring to (and which I hope but can not guarantee at
the
moment will help in your case) is in DOSGi 1.4. Can you experiment with
DOSGi 1.4 multibundle distro ?

Sergey



On 2 May 2013 11:28, Sergey Beryozkin<sberyoz...@gmail.com****>
wrote:

   What DOSGi version do you use ?

Sergey

On 02/05/13 10:22, Julio Carlos Barrera Juez wrote:

   As I wrote in my first e-mail, If we use the same value for "

org.apache.cxf.rs.********httpservice.context" in each bundle, we
get

errors

noticing it. And if we use different values in "org.apache.cxf.rs.**

httpservice.context" property and "org.apache.cxf.rs.address" there
is a
mix in the WADLs and in the WS registrations. Each WADL point to the
last
registered service. We have tried all the combinations of values of
both
properties and none of them give us a good result ;-((


On 2 May 2013 11:01, Sergey Beryozkin<sberyoz...@gmail.com******>
wrote:

    Hi


On 02/05/13 09:10, Julio Carlos Barrera Juez wrote:

    Additionally, we cannot provide good javax.ws.rs.Path
annotations

  because
our OSGi service interfaces are used to generate different
services dynamically. for instance, given this interface:

@Path("/")
public interface DynamicService {

       @Path("/methodA")
       public Object methodA();

}

Different services are registered using the same interface, then
different "org.apache.cxf.rs.address"
properties are generated to differentiate each service like
"/serviceA"
and
"/serviceB". Both services have same interface, but different
instances.


    What I know is possible with DOSGi CXF 1.4 is to use both

  "org.apache.cxf.rs.********httpservice.context" and


"org.apache.cxf.rs.address"

properties, both being relative, example, see

http://svn.apache.org/repos/********asf/cxf/dosgi/tags/cxf-****
dosgi-****<http://svn.apache.org/repos/******asf/cxf/dosgi/tags/cxf-**dosgi-****>
<http://svn.apache.**org/repos/****asf/cxf/dosgi/**
tags/cxf-dosgi-****<http://svn.apache.org/repos/****asf/cxf/dosgi/tags/cxf-dosgi-****>

<http://svn.apache.**org/**repos/**asf/cxf/dosgi/**tags/**
cxf-dosgi-**<http://svn.**apache.org/repos/**asf/cxf/**
dosgi/tags/cxf-dosgi-**<http://svn.apache.org/repos/**asf/cxf/dosgi/tags/cxf-dosgi-**>



  ri-1.4.0/samples/greeter_rest/********impl2/src/main/java/org/**
**
apache/cxf/dosgi/samples/********greeter/impl2/rest/Activator.**
***
***java<
http://svn.apache.org/**repos/****asf/cxf/dosgi/tags/cxf-**<http://svn.apache.org/**repos/**asf/cxf/dosgi/tags/cxf-**>
<ht**tp://svn.apache.org/**repos/**asf/cxf/dosgi/tags/cxf-**<http://svn.apache.org/**repos/asf/cxf/dosgi/tags/cxf-**>

dosgi-ri-1.4.0/samples/******greeter_rest/impl2/src/main/**
java/org/apache/cxf/dosgi/******samples/greeter/impl2/rest/******
Activator.java<http://svn.**ap**ache.org/repos/asf/cxf/**<http://apache.org/repos/asf/cxf/**>
dosgi/tags/cxf-dosgi-ri-1.4.0/****samples/greeter_rest/impl2/****
src/main/java/org/apache/cxf/****dosgi/samples/greeter/impl2/****
rest/Activator.java<http://**svn.apache.org/repos/asf/cxf/**
dosgi/tags/cxf-dosgi-ri-1.4.0/**samples/greeter_rest/impl2/**
src/main/java/org/apache/cxf/**dosgi/samples/greeter/impl2/**
rest/Activator.java<http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.4.0/samples/greeter_rest/impl2/src/main/java/org/apache/cxf/dosgi/samples/greeter/impl2/rest/Activator.java>






  So you should be able to set "org.apache.cxf.rs.******

httpservice.context"

to

say "/rest" for all the bundles and "/a", "/b", etc for
"org.apache.cxf.rs.address" for the individual bundles.
Give that a try please.

One other thing is that you can avoid annotating interfaces with
JAX-RS
annotations and use the external user models, the greeter_rest demo
shows
that too. The only limitation there is that a user model is
static, one
can
not 'attach' them dynamically, may be we should support that...

Sergey



    On 2 May 2013 09:24, Julio Carlos Barrera Juez<

  juliocarlos.barr...@i2cat.net>      wrote:

     Hi!


  We have a ServiceMix app with multiple bundles. We want to
export our
OSGi
service interfaces using DOSGi. We annotate our service
interfaces
with javax.ws.rs.Path, javax.ws.rs.GET,
javax.ws.rs.POST, javax.ws.rs.Consumes and javax.ws.rs.Produces.
Then
we
register our OSGi services using Apache Aries Blueprint or Java
code
adding different CXF properties.

At the beginning we used "org.apache.cxf.rs.address" property
with
absolute URLs, using Jetty standalone instance. But now we want
to
use
relative address to use HTTP service. If we don't
specify "org.apache.cxf.rs.********httpservice.context"
property, our


service

seems
to be not registered at all. I we specify this property with same
value
for
all services there are some errors when registering services
("alias
in
use
or another context..."). If we specify different values for each
registration there are no errors, but there are a mix of methods
in
each
service (looking at WADL).

How we must set both properties to achieve having different
services
registered with relative paths?




    --

Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com




  --
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com







--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Reply via email to