cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: [Heads up] Design of new major version of CXF DOSGi
Date Thu, 07 Jul 2016 09:22:11 GMT
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.


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

Christian Schneider

Open Source Architect

View raw message