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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
