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
On 07/07/16 06:09, Christian Schneider wrote:
Hi Sergey,
I propose we do a poc for that. Let´s create some customizations for a
jaxrs service in 1.8.0 syntax together and then I can try to do the same on
the 2.0 syntax. If we find gaps I will add the code to 2.0 again of course.
Christian
2016-07-06 21:28 GMT+02:00 Sergey Beryozkin <sberyoz...@gmail.com>:
Hi Christian
On 06/07/16 18:42, Christian Schneider wrote:
I have removed all that code as I hope we have other measures to do this.
One approach are the intents that allow to set interceptors using a
feature.
Another approach might be to use the annoations for features and
interceptors like
@org.apache.cxf.feature.Features (features =
"org.apache.cxf.jaxws.service.AnnotationFeature")
I think together they should provide the same level of configurability.
The problem with all approaches that take class names is the visibility of
these classes. The intent approach allows to offer a feature as a service
so the user bundle with the service using the intent does not need access
to the impl classes of the feature and interceptors.
Most of this code as far as I know deals with instances, not classes.
What do you think? Should that work?
Let me ask you instead, will it work ?
With DOSGI 1.8.0, as far as I recall, one just registers an instance of a
given provider and it works.
What DOSGI RS users would need to do to register an instance of a Jackson
provider for example, start creating some intent like "json" ? I honestly
do not how it will work.
I don't mind with 2.0 the DOSGi users being encouraged to do pure DOSGi
with the intents, but IMHO the JAX-RS provider *instance* registration code
which already works should continue be there rather than remove it and hope
for the best the intents will help :-).
Thanks, Sergey
Christian
2016-07-06 16:49 GMT+02:00 Sergey Beryozkin <sberyoz...@gmail.com>:
Hi Christian
It all looks like a fine way forward, though I do believe there was a
code
before which allowed setting JAX-RS providers/interceptors
This line adds interceptors/features:
https://github.com/apache/cxf-dosgi/blob/cxf-dosgi-ri-1.8.0/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/handlers/JaxRSPojoConfigurationTypeHandler.java#L98
This line should add the providers:
https://github.com/apache/cxf-dosgi/blob/cxf-dosgi-ri-1.8.0/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/handlers/JaxRSPojoConfigurationTypeHandler.java#L106
Have you preserved this code ?
Thanks, Sergey
On 06/07/16 11:44, Christian Schneider wrote:
In the previous days I was working on a new design for CXF DOSGi 2.
I would like to begin with a recap of the state of CXF DOSGi 1.8:
Since the creation of Aries RSA the CXF DOSGi project is not a full OSGi
remote service admin impl anymore. It only provides a
DistributionProvider for CXF that can run
in Aries RSA. The main problem is that there is just one provider that
can do REST and SOAP services. So it always has to carry all
dependencies. In the multi bundle distro these are about 100 bundles.
There are also a lot of configuration properties including older
deprecated properties. The Aegis support in the 1.8 version can not be
used with Java8 as Aegis produces an exception during init.
So the goals for CXF DOSGi 2 were to make it simpler and more light
weight and of course to fully support Java 8.
So this is the new design looks like this:
- cxf-dosgi-common : HttpServiceManager, IntentManager, ProxyFactory and
other small util classes. These are all shared for the providers
- cxf-dosgi-provider-ws: SOAP support. If @Webservice annotation is
present it does JAXWS/JAXB if not it does Simple/Aegis
- cxf-dosgi-provider-rs: REST support. Exposes the service as a default
JAX-RS service. It has not property support for setting providers or
interceptors
- cxf-dosgi-decorator: Allows to expose services using xml. I am not
sure if we still need this as Aries RSA can now expose services using
configs
- cxf-dosgi-repository: Pom that defines all dependencies to OSGi
bundles. This can be used as a OSGi repository in the upcoming bnd and
bndtools
Both providers support intents which can be used to set DataBinding,
Binding Config and Features. I think we might be missing support for
JAXRS @Provider classes but I am not sure.
Apart from this I removed all deprecated config properties and also
slimmed down the other config properties. I hope we still cover most use
cases but I need your feedback.
I created some Readme.md docs in the source code to explain the current
properties.
The multi bundle distro is still there and is not really smaller as it
still relies on the current karaf cxf and pax-web features which are
really big. The karaf features are split into ws and rs. So we do not
need to install everything at runtime.
To show how small a DOSGi deployment can be I created a small example
using bndtools and the repository above and was able to get a SOAP
service exported with a runnable jar that just is about
6 MB. So I hope we can support much smaller deployments of CXF DOSGi in
the future. Unfortunately I can not yet add this example to CXF DOSGi as
it relies on some an experimental pom based repo plugin. As soon as this
support is part of a bnd release I will add an example for this
packaging.
I also hope the new CXF DOSGi can be the default way for karaf boot to
expose and consume REST services.
I would be happy about your feedback on the new design. Before we do a
2.0.0 release nothing is really fixed so please speak up to get your use
cases in.
Christian
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
