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

Reply via email to