You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Carlos Sierra Andrés <cs...@apache.org> on 2021/04/13 14:36:09 UTC
Aries JAX-RS Whiteboard and CXF OSGi integration interaction
Hi all,
I am crossposting a message that I left on the slack channel:
we are about to release a new version of the aries jaxrs whiteboard that
does not bundle CXF.
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.
Thx in advance!
Carlos.
Re: Aries JAX-RS Whiteboard and CXF OSGi integration interaction
Posted by Andriy Redko <dr...@gmail.com>.
Hi Carlos,
If there is no impact on majority of the users, I have no objections flipping the defaults. In this case the property
could be set only to fallback to singleton behaviour if the need arises. In any case, I think we should explore the
PrototypeServiceFactory as you suggested, would you mind please to create an issue for CFX there [1]?
[1] https://issues.apache.org/jira/projects/CXF/issues/
Thank you!
Best Regards,
Andriy Redko
CSA> Hi Adriy,
CSA> if I understand correctly then we would still need to set the property in order for it to work properly, right?
CSA> 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?
CSA> Bests.
CSA> Carlos.
CSA> 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.
Re: Aries JAX-RS Whiteboard and CXF OSGi integration interaction
Posted by Carlos Sierra Andrés <cs...@apache.org>.
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.
Re: Aries JAX-RS Whiteboard and CXF OSGi integration interaction
Posted by Andriy Redko <dr...@gmail.com>.
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.
Re: Aries JAX-RS Whiteboard and CXF OSGi integration interaction
Posted by Carlos Sierra Andrés <cs...@apache.org>.
Hi again,
I have been debugging further and I believe I know where the problem is:
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.
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.
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?
Carlos.
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.
Re: Aries JAX-RS Whiteboard and CXF OSGi integration interaction
Posted by Andriy Redko <dr...@gmail.com>.
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.
Re: Aries JAX-RS Whiteboard and CXF OSGi integration interaction
Posted by Carlos Sierra Andrés <cs...@apache.org>.
Hi Andriy,
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.
Bests.
Carlos.
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.
>
Re: Aries JAX-RS Whiteboard and CXF OSGi integration interaction
Posted by Andriy Redko <dr...@gmail.com>.
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.