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