camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raul Kripalani <r...@evosent.com>
Subject Re: CXFRS: Share port number across bundles
Date Tue, 15 Jan 2013 10:36:38 GMT
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 <sberyozkin@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<sberyozkin@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<sberyozkin@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>
>>>>>> >>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message