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.

Reply via email to