Hi, thanks for answers and the idea, it sounds really good, I'll go this way definitelly. Right now, I have done that static - hardcoded, in my blueprint.xml:
<camel-cxf:rsServer id="rootServer" address="${server.rest.base}/" serviceClass="com.foo.contextA"/> <camel-cxf:rsServer id="fooServer" address="${server.rest.base}/contextA/" serviceClass="com.foo.contextB"/> <camel-cxf:rsServer id="barServer" address="${server.rest.base}/contextB/" serviceClass="com.foo.contextC" /> But the "dynamic" solution sound quite better and I like it and it's logical, thanks to the nature of a OSGi module. Thanks! On Tue, Jan 15, 2013 at 11:36 AM, Raul Kripalani <r...@evosent.com> wrote: > Hi, > > At last we implemented option 1, to avoid introducing more complexity into > our scenario. > > But yes, the idea is exactly as Sergey mentioned. You'd probably use OSGi > services, where the master resource is exposed under "/" and implements an > OSGi Service Listener to receive callbacks every time a new JAX-RS resource > appears in the OSGi environment. > > Keeping an internal map of available subresources which is queried from a > Subresource Locator would be the way to go in my opinion (off the top of my > head). > > Regards, > > *Raúl Kripalani* > Apache Camel Committer > Enterprise Architect, Program Manager, Open Source Integration specialist > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk> > > On Tue, Jan 15, 2013 at 10:01 AM, Sergey Beryozkin <sberyoz...@gmail.com > >wrote: > > > Hi > > > > On 12/01/13 14:53, Martin Stiborský wrote: > > > >> Hi Raul and Sergey, > >> Guys please, could you explain more for me the "second option" ? > >> I missed the point I guess. > >> > >> I thought the idea around sharing the port was actually to do with > > dynamically attaching new contexts to the base address like > > "localhost:9007", with every new custom bundle introducing a new context > > like "/a". etc. I guess in OSGI one can address this task by having a > > master JAX-RS root resource listening for new bundles and registering > them > > as JAX-RS subresources in the internal map and then removing them once > the > > corresponding bundles have been removed > > > > HTH > > Sergey > > > > > > Thanks! > >> On Jan 11, 2013 3:00 PM, "Sergey Beryozkin"<sberyozkin@gmail.**com< > sberyoz...@gmail.com>> > >> wrote: > >> > >> Hi Raúl > >>> On 11/01/13 13:28, Raul Kripalani wrote: > >>> > >>> Hi Sergey, > >>>> > >>>> Thanks for the quick answer. We were already on our way to implement > the > >>>> second option! > >>>> > >>>> Just a thought off the top of my head... Does it make sense to enhance > >>>> CXF > >>>> or the Jetty CXF Transport so that it's able to figure out this > >>>> situation > >>>> transparently and build the servlet mappings accordingly? > >>>> > >>>> This is possible when CXF Servlet transport is used (with default > >>>> > >>> context /cxf which is configurable and relative endpoint address > values) > >>> but not when every endpoint with an absolute address is powered by > (CXF) > >>> Jetty transport. > >>> Besides, the URI path starting from a given root resource's @Path value > >>> is > >>> not visible to CXF transports given that this @Path value does not > >>> represent the final URI path segment in most cases. > >>> > >>> Cheers, Sergey > >>> > >>> Regards, > >>> > >>>> > >>>> *Raúl Kripalani* > >>>> Apache Camel Committer > >>>> Enterprise Architect, Program Manager, Open Source Integration > >>>> specialist > >>>> http://about.me/raulkripalani | http://www.linkedin.com/in/** > >>>> raulkripalani<http://www.**linkedin.com/in/raulkripalani< > http://www.linkedin.com/in/raulkripalani> > >>>> > > >>>> http://blog.raulkr.net | twitter: @raulvk< > http://twitter.com/****raulvk<http://twitter.com/**raulvk> > >>>> <http://twitter.com/**raulvk <http://twitter.com/raulvk>> > >>>> > >>>>> > >>>>> > >>>> On Fri, Jan 11, 2013 at 1:13 PM, Sergey Beryozkin< > sberyoz...@gmail.com* > >>>> *** > >>>> > >>>>> wrote: > >>>>> > >>>> > >>>> Hi > >>>> > >>>>> > >>>>> On 11/01/13 12:53, Raul Kripalani wrote: > >>>>> > >>>>> Hi all, > >>>>> > >>>>>> > >>>>>> Quick question. > >>>>>> > >>>>>> Has anyone tried to run several CXFRS consumers on different bundles > >>>>>> binding to the same port (e.g. 9007), where each consumer has a > >>>>>> different > >>>>>> root resource stemming from a different path? > >>>>>> > >>>>>> *Bundle A:* > >>>>>> > >>>>>> > >>>>>> <cxf:rsServer id="rsServer" > >>>>>> address="http://0.0.0.0:9007" > >>>>>> serviceClass="com.mycompany.******ResourceA" /> > >>>>>> > >>>>>> *Bundle B:* > >>>>>> > >>>>>> > >>>>>> <cxf:rsServer id="rsServer" > >>>>>> address="http://0.0.0.0:9007" > >>>>>> serviceClass="com.mycompany.******ResourceB" /> > >>>>>> > >>>>>> *ResourceA* annotated with @Path("/resourceA") > >>>>>> *ResourceB* annotated with @Path("/resourceB") > >>>>>> > >>>>>> > >>>>>> It looks like the latest bundle to initialise gets ownership of the > >>>>>> port, > >>>>>> i.e. they become mutually exclusive. > >>>>>> > >>>>>> > >>>>>> will cxf:rsServer work with relative addresses, example, the first > >>>>>> one > >>>>>> > >>>>> with "/resourceA", second - with "/resourceB", and both ResourceA& > >>>>> ResourceB root resources having @Path("/") ? > >>>>> > >>>>> May be another option is to have a single cxf:rsServer listening on " > >>>>> http://0.0.0.0:9007", with it root resource listening on "/" and > >>>>> dynamically managing subresources which in turn can handle > >>>>> "/resourceA", > >>>>> "/resourceB", etc, where every subresource is provided or removed > >>>>> externally via different bundles ? > >>>>> > >>>>> Cheers, Sergey > >>>>> > >>>>> Any ideas on how to make this work? Do you think this question is > >>>>> more > >>>>> on > >>>>> > >>>>> the Camel or CXF side of the fence? > >>>>>> > >>>>>> Thanks! > >>>>>> > >>>>>> *Raúl Kripalani* > >>>>>> > >>>>>> Apache Camel Committer > >>>>>> Enterprise Architect, Program Manager, Open Source Integration > >>>>>> specialist > >>>>>> http://about.me/raulkripalani | http://www.linkedin.com/in/** > >>>>>> raulkripalani<http://www.**lin**kedin.com/in/raulkripalani< > http://linkedin.com/in/raulkripalani> > >>>>>> <htt**p://www.linkedin.com/in/**raulkripalani< > http://www.linkedin.com/in/raulkripalani> > >>>>>> > > >>>>>> > >>>>>>> > >>>>>>> http://blog.raulkr.net | twitter: @raulvk< > http://twitter.com/***** > >>>>>> *raulvk <http://twitter.com/****raulvk>< > http://twitter.com/****raulvk<http://twitter.com/**raulvk> > >>>>>> > > >>>>>> <http://twitter.com/**raulvk<h**ttp://twitter.com/raulvk< > http://twitter.com/raulvk> > >>>>>> >> > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > >>> > >> > > > -- S pozdravem / Best regards Martin Stiborský Jabber: st...@njs.netlab.cz Twitter: http://www.twitter.com/stibi