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:37:30 GMT
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