cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: Troubles with multiple JAX-RS applications in one web.xml
Date Wed, 23 Apr 2014 13:06:52 GMT
Hi Petr
On 23/04/14 13:21, Dolezal, Petr wrote:
> Hi Sergey.
>> The question though remains, given that you use web.xml, no Spring & Blueprint,
>> meaning that in case of a single web.xml you have two CXFNonSpringJaxrsServlet
>> instances created, how both of those instances end up sharing the bus (lets say
>> the same endpoint registry in the context of this discussion).
> We have a Blueprint extender deployed in the OSGi container, namely Apache Aries. I forgot
to mention it - anyway, I think it is not possible to run CXF in OSGi without Blueprint (or
it is troublesame at least, so we rather quickly deployed Aries).
>> CXFNonSpringJaxrsServlet delegates to a default CXFNonSpringServlet constructor
>> and afterwards a new bus created in loadBus().
>> Note, CXFNonSpringServlet has a setBus() method, and bus itself is 'protected'
>> and it appears to me somehow you have the shared bus injected via those setters.
>> I don't understand how it is possible :-) so if you could check out the source
>> and put a breakpoint in CXFNonSpringServlet then we'd trace where the shared
>> bus is coming from...
> No, no - we didn't touch it at all. No modification, no direct touch with CXF classes,
our code does not depend on CXF at all, it depends only on Olingo (and more or less indirectly
on JAX-RS API). The cause must lie in the bus sharing... and here you would know the details
far better. I think that the most important information is the environment: OSGi (Equinox)
+ Blueprint extender (Aries) + JAX-RS application (inherited from Olingo).
> I hope this would clear all the confusion.
Right, you are likely seeing the side-effects:

So far I haven't found how this can be solved

Thanks, Sergey

> Petr

View raw message