cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: [Heads up] Design of new major version of CXF DOSGi
Date Thu, 07 Jul 2016 09:52:55 GMT
I'm not seeing this code in a WS provider either:

so it is not possible to add extra CXF interceptors for JAX-WS users 
too. The use-cases for adding them to JAX-WS endpoints would be the same 
as for JAX-RS.


is kept across the providers.

Look, it is not really a big deal for me :-). But if one has a DS or 
Blueprint context it is handy to add CXF logging features or something 
else OOB by simply registering a bean in the context.

I'd still prefer to keep that code for now at least, then do the intent 
POCs, and only then decide if the code can be removed or not.

Cheers, Sergey

On 07/07/16 10:37, Sergey Beryozkin wrote:
> Hi Christian
> As I said in my previous email I'd like to keep the code which works for
> whoever uses DOSGI JAX-RS operational so lets start from it - this code
> should stay, why would you remove it if you don't quite understand what
> it is used for :-) ?
> We do not need to go via a white-board discussion of various JAX-RS use
> cases for this code to stay and to be honest I don't have much time for
> it at the moment.
> The providers which JAX-RS users would typically register are JAX-RS
> MessageBodyWriter/Reader and it is about supporting the conversion of
> beans to JSON/XML, these are data bindings in a CXF JAX-WS speak. We do
> not need use-cases to justify having an option of registering these data
> bindings as properties.
> Forcing the users to start registering intent OSGI services in order to
> register a Jackson provider is a step backward if they can set a bean in
> the OSGI context and be done with it. Again, I'm not against the
> intents, all I'd like is to have the existing option operational. This
> option is not anti-DOSGI.
> Thanks, Sergey
> On 07/07/16 10:22, Christian Schneider wrote:
>> Hi Sergey,
>> the problem is that we can not easily remove options after the major
>> release as minor releases then should be compatible.
>> So I would like to get rid of as many options as possible. On the other
>> hand we need all important use cases to still work.
>> The big problem for me is that I do not know enough about the JAX-RS use
>> cases. So I would like to first set up some cases to see what we need to
>> get working and then look into the possible soluitions. The current
>> tests and examples still work with all those features removed. So I
>> think our tests
>> and examples do not reflect the typical use cases.
>> I have no big pressure to release DOSGi 2 very soon. So I can guarantee
>> you that I will not push for a release until we have a solution you are
>> fine with.
>> That might very well be putting back in all the options but I want to
>> make sure these are really the best solution. So I would like to take
>> the chance to learn from
>> you what typical JAX-RS services need.
>> So I propose we talk on skype to discuss the use cases and then sketch
>> some examples. These will then be the barrier the new impl must pass.
>> Christian
>> On 07.07.2016 11:10, Sergey Beryozkin wrote:
>>> Hi Christian
>>> Having a POC is a good idea and given it let me suggest a slightly
>>> different path.
>>> I'd like to keep the code which is working for JAX-RS users mostly
>>> intact - if there's some code there which tries to load classes from
>>> their String names then I agree we can let it go but the code which
>>> deals with the already instantiated JAX-RS providers without depending
>>> on some wildcard imports in the DOSGI impl IMHO needs to stay.
>>> I do not know if anyone still uses DOSGi JAX-RS but I 100% sure I
>>> worked with some of them specifically on the issue of supporting
>>> injected providers and properties.
>>> Having an intent alternative is interesting and here a POC will help
>>> us understand how it can be done in a pure DOSGi way. Even if it works
>>> well I'd still favor keeping the existing JAX-RS option while we can
>>> start encouraging users to migrate to the Intents way.
>>> However, the goal of this re-design is not to make the JAX-RS part
>>> more DOSGI-y :-). It is about making a clean split of the monolitic
>>> CXF DOSGi which I fully support.
>>> Let it be done first and then we can try and go for a POC - it won't
>>> have to be done for JAX-RS only, we can try and see how it works for
>>> JAX-WS, example, having a 'BeanValidation' intent or 'Logging' intent,
>>> etc.
>>> Sounds reasonable ?
>>> Cheers, Sergey

Sergey Beryozkin

Talend Community Coders

View raw message