I'm not seeing this code in a WS provider either:
https://github.com/apache/cxf-dosgi/blob/cxf-dosgi-ri-1.8.0/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/handlers/AbstractPojoConfigurationTypeHandler.java#L186
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.
Only
https://github.com/apache/cxf-dosgi/blob/cxf-dosgi-ri-1.8.0/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/handlers/AbstractPojoConfigurationTypeHandler.java#L235
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
http://coders.talend.com/
