Hi Adriy,
if I understand correctly then we would still need to set the property
in order for it to work properly, right?
What I was suggesting was changing this default behavior, because it
seems to me that it is not usable as it is having all the buses share
the same HTTPTransportFactory. Is there a use case behind this default
behavior so I take in into account?
Bests.
Carlos.
El 5/5/21 a las 3:24, Andriy Redko escribió:
Hi Carlos,
Thanks a lot for troubleshooting. I just quickly went through the history and
it seems like the PrototypeServiceFactory
came out as part of OSGi Core 6 release but the original implementation
predates that. So this fact apparently explains the implementation
choice. I think we could provide the prototypes as well, fe controlled by the
property, since changing the default may have an
impact on existing deployments. What do you think? @Freeman may be you have
some insights?
Thanks!
Best Regards,
Andriy Redko
CSA> Hi again,
CSA> I have been debugging further and I believe I know where the problem is:
CSA> HttpTransportActivator.java:66 registers a HTTPTransportFactory singleton
which has a singleton DestinationRegistryImpl as well. This HTTPTransportFactory
singleton is then shared across all the buses. This causes that, when something is
registered on one of the buses on one path, can not be registered in other bus on
the same path even though the buses are used by different servlets that are
deployed on different context.
CSA> This is the reason why setting
org.apache.cxf.osgi.http.transport.disable=true makes it work, because the
singleton HTTPTransportFactory is not registered and each bus gets an instance of
its own.
CSA> It looks to me that sharing a singleton HTTPTransportFactory is wrong. Is
there a reason for it? Should we change it to register a PrototypeServiceFactory?
CSA> Carlos.
CSA> El 22/4/21 a las 2:08, Andriy Redko escribió:
Hi Carlos,
I can surely check the Aries Whiteboard tests if you share some pointers with
me, which
tests etc (sorry, I am not a seasoned Aries Whiteboard user). I believe we
don't have Aries
Whiteboard tests anywhere in CXF. In any case, if you curious where the Karaf /
Felix
integration tests are in CXF, please check out [1], [2], they might give you
some hints
meantime.
[1] https://github.com/apache/cxf/tree/master/osgi/itests
[2] https://github.com/apache/cxf/tree/master/osgi/itests-felix
Best Regards,
Andriy Redko
CSA> Hi Andriy,
CSA> it fails consistently in the aries whiteboard tests but I will try to
reproduce the error in the CXF tests... I will have a look but if you have any
advice on where to test it I will really appreciate it.
CSA> Bests.
CSA> Carlos.
CSA> El 19/4/21 a las 4:37, Andriy Redko escribió:
Hi Carlos,
It sounds a bit surprising that you need to add
"org.apache.cxf.osgi.http.transport.disable=true"
if you don't bundle CXF anymore. It would be good to understand what is going
on, may be there
are some steps you could share to reproduce the problem? Thank you.
Best Regards,
Andriy Redko
CSA> Hi all,
CSA> I am crossposting a message that I left on the slack channel:
CSA> we are about to release a new version of the aries jaxrs whiteboard that
does not bundle CXF.
CSA> However, for it to work, we need to set
"org.apache.cxf.osgi.http.transport.disable=true", otherwise it seems like some
things are shared across different buses preventing the JAX-RS whiteboard from working
correctly. We are going to create a release with this limitation, but we would love to have
your advice in how the whiteboard should collaborate gracefully with the regular CXF OSGi
integration, if at all possible.
CSA> Thx in advance!
CSA> Carlos.
