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.

Petr

Reply via email to