You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Christian Schneider <ch...@die-schneider.net> on 2016/07/06 10:44:52 UTC
[Heads up] Design of new major version of CXF DOSGi
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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [Heads up] Design of new major version of CXF DOSGi
Posted by Christian Schneider <ch...@die-schneider.net>.
I was able to configure the server side on the level of pax web and the
client side using the ConduitFeature as an intent.
This way I was able to do a full example using SSL and cert based client
auth.
So while configuring the server side in the pax web config is not very
Remote Service like it is a good work around in my opinion.
Christian
On 21.07.2016 16:58, Christian Schneider wrote:
> Unfortunately this did not work for the server side. The
> TlsServerParameters can not be set using a feature.
> Seems like they are configured in the JettyHTTPServerEngineFactory.
>
> I found that it is possible to configure server side ssl using config
> admin and will test if this helps.
>
> Christian
>
>
> On 21.07.2016 16:32, Sergey Beryozkin wrote:
>> Hi Christian
>> Nice, IMHO this is a nice improvement which will help not only
>> (D)OSGI users,
>> I'll tweak a bit the features to accept JAX-RS clients (they
>> implement InterceptorProvider & ConduitSelectorHolder)
>>
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [Heads up] Design of new major version of CXF DOSGi
Posted by Christian Schneider <ch...@die-schneider.net>.
Unfortunately this did not work for the server side. The
TlsServerParameters can not be set using a feature.
Seems like they are configured in the JettyHTTPServerEngineFactory.
I found that it is possible to configure server side ssl using config
admin and will test if this helps.
Christian
On 21.07.2016 16:32, Sergey Beryozkin wrote:
> Hi Christian
> Nice, IMHO this is a nice improvement which will help not only (D)OSGI
> users,
> I'll tweak a bit the features to accept JAX-RS clients (they implement
> InterceptorProvider & ConduitSelectorHolder)
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [Heads up] Design of new major version of CXF DOSGi
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Christian
Nice, IMHO this is a nice improvement which will help not only (D)OSGI
users,
I'll tweak a bit the features to accept JAX-RS clients (they implement
InterceptorProvider & ConduitSelectorHolder)
SErgey
On 21/07/16 11:47, Christian Schneider wrote:
> One more update on this.
>
> On the mailing list we had a request for configure https with DOSGi.
> I have now created two new features
> (https://issues.apache.org/jira/browse/CXF-6973):
> https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HttpConduitFeature.java
>
> https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HttpDestinationFeature.java
>
>
> These allow to configure http conduits and destinations using features.
> For DOSGi you can create such a Feature and publish it as an OSGi
> service with an intent name
> and require the intent in the service. The feature will then be applied
> and the service will be configured with all settings you do in the
> features.
> For the https clients this should already be enough.
>
> For the https endpoints I found that the jetty transport uses a
> JettyHTTPServerEngineFactory that is retrieved from the bus. I am not
> sure what is the best way to hook into that.
> There already is a way to configure this using config admin. Maybe this
> is enough. I would be happy about any feedback. It would be a little
> difficult to configure this using intents
> as it seems the jetty settings are configured per port and not per
> endpoint. So it does not make much sense to have an intent on the service.
>
> I will create an example that shows https with CXF-DOSGi to prove this
> actually works.
>
> Christian
>
> On 12.07.2016 09:25, Christian Schneider wrote:
>> I have taken some more time to look into possible solutions for
>> customizing CXF services and clients.
>>
>>
>> Current situation (1.x)
>>
>> The 1.x tree provides a way to set these things on a CXF service:
>> inInterceptors, outInterceptors, faultInInterceptors,
>> faultOutInterceptors, features
>> These could be set by providing either the class name or the instance
>> object in a service property.
>> On the JAXRS side there is a way to set providers using Class names
>> and by looking up services with a specific marker property.
>>
>>
>> Issues with the 1.x solution
>>
>> Setting interceptors and providers by instance is very convenient for
>> plain OSGi and blueprint but does not work in DS. It is also not
>> possible to send these instances to discovery to also create the
>> client from these. So I am not sure if this option was spec conformant
>> at all.
>> Another problem is that on the client side you typically need
>> different interceptors. For example if you add something as a header
>> you would use an OutInterceptor on the client and an InInterceptor on
>> the server. So as both client and server must be able to be created
>> from the same set of service properties I think interceptors are not a
>> good choice. A better choice is a feature as the implementation can do
>> different things on the client and server with the same feature
>> definition.*
>> *
>>
>>
>> Possible solution
>>
>> I propose to use intents for all customizations. An intent is an OSGi
>> service of several possible types that is identified by a special
>> property (org.apache.cxf.dosgi.IntentName).
>> A service can specify a list of named intents it requires. The service
>> is then only published when all intents are present as services.
>>
>> In the current code on master it is possible to use intents for
>> Databinding, Binding Config, Feature and Provider.
>> I have also introduced a new interface IntentProvider with one method
>> List<Object> getIntents(). It allows to specify a whole list of
>> intents with one name.
>> This is useful if these intents should always be used together. As
>> IntentProvider is not CXF specific we could even move this interface
>> to the Aries RSA spi bundle.
>>
>> An example for this can be see in this test. It uses the intent "my"
>> with a MessageBodyWriter and a MessageBodyReader. Both service
>> endpoint and client proxy can be created from this
>> intent and allow a full roundtrip for a call with customized
>> serialization:
>> https://github.com/apache/cxf-dosgi/tree/master/provider-rs/src/test/java/org/apache/cxf/dosgi/dsw/handlers/rest/provider
>>
>>
>> Such IntentProvider services are easy to publish using any dependency
>> injection framework and allow to set instances which can even be
>> injected with other services if necessary.
>> So I think this solution should be viable to set all typical needs for
>> SOAP as well as REST.
>>
>> So what do you think? Can we use this to replace all the old config
>> options?
>>
>> Christian
>>
>>
>> On 07.07.2016 11:52, Sergey Beryozkin wrote:
>>> 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
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>
>
Re: [Heads up] Design of new major version of CXF DOSGi
Posted by Christian Schneider <ch...@die-schneider.net>.
One more update on this.
On the mailing list we had a request for configure https with DOSGi.
I have now created two new features
(https://issues.apache.org/jira/browse/CXF-6973):
https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HttpConduitFeature.java
https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HttpDestinationFeature.java
These allow to configure http conduits and destinations using features.
For DOSGi you can create such a Feature and publish it as an OSGi
service with an intent name
and require the intent in the service. The feature will then be applied
and the service will be configured with all settings you do in the features.
For the https clients this should already be enough.
For the https endpoints I found that the jetty transport uses a
JettyHTTPServerEngineFactory that is retrieved from the bus. I am not
sure what is the best way to hook into that.
There already is a way to configure this using config admin. Maybe this
is enough. I would be happy about any feedback. It would be a little
difficult to configure this using intents
as it seems the jetty settings are configured per port and not per
endpoint. So it does not make much sense to have an intent on the service.
I will create an example that shows https with CXF-DOSGi to prove this
actually works.
Christian
On 12.07.2016 09:25, Christian Schneider wrote:
> I have taken some more time to look into possible solutions for
> customizing CXF services and clients.
>
>
> Current situation (1.x)
>
> The 1.x tree provides a way to set these things on a CXF service:
> inInterceptors, outInterceptors, faultInInterceptors,
> faultOutInterceptors, features
> These could be set by providing either the class name or the instance
> object in a service property.
> On the JAXRS side there is a way to set providers using Class names
> and by looking up services with a specific marker property.
>
>
> Issues with the 1.x solution
>
> Setting interceptors and providers by instance is very convenient for
> plain OSGi and blueprint but does not work in DS. It is also not
> possible to send these instances to discovery to also create the
> client from these. So I am not sure if this option was spec conformant
> at all.
> Another problem is that on the client side you typically need
> different interceptors. For example if you add something as a header
> you would use an OutInterceptor on the client and an InInterceptor on
> the server. So as both client and server must be able to be created
> from the same set of service properties I think interceptors are not a
> good choice. A better choice is a feature as the implementation can do
> different things on the client and server with the same feature
> definition.*
> *
>
>
> Possible solution
>
> I propose to use intents for all customizations. An intent is an OSGi
> service of several possible types that is identified by a special
> property (org.apache.cxf.dosgi.IntentName).
> A service can specify a list of named intents it requires. The service
> is then only published when all intents are present as services.
>
> In the current code on master it is possible to use intents for
> Databinding, Binding Config, Feature and Provider.
> I have also introduced a new interface IntentProvider with one method
> List<Object> getIntents(). It allows to specify a whole list of
> intents with one name.
> This is useful if these intents should always be used together. As
> IntentProvider is not CXF specific we could even move this interface
> to the Aries RSA spi bundle.
>
> An example for this can be see in this test. It uses the intent "my"
> with a MessageBodyWriter and a MessageBodyReader. Both service
> endpoint and client proxy can be created from this
> intent and allow a full roundtrip for a call with customized
> serialization:
> https://github.com/apache/cxf-dosgi/tree/master/provider-rs/src/test/java/org/apache/cxf/dosgi/dsw/handlers/rest/provider
>
> Such IntentProvider services are easy to publish using any dependency
> injection framework and allow to set instances which can even be
> injected with other services if necessary.
> So I think this solution should be viable to set all typical needs for
> SOAP as well as REST.
>
> So what do you think? Can we use this to replace all the old config
> options?
>
> Christian
>
>
> On 07.07.2016 11:52, Sergey Beryozkin wrote:
>> 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
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [Heads up] Design of new major version of CXF DOSGi
Posted by Christian Schneider <ch...@die-schneider.net>.
I have taken some more time to look into possible solutions for
customizing CXF services and clients.
Current situation (1.x)
The 1.x tree provides a way to set these things on a CXF service:
inInterceptors, outInterceptors, faultInInterceptors,
faultOutInterceptors, features
These could be set by providing either the class name or the instance
object in a service property.
On the JAXRS side there is a way to set providers using Class names and
by looking up services with a specific marker property.
Issues with the 1.x solution
Setting interceptors and providers by instance is very convenient for
plain OSGi and blueprint but does not work in DS. It is also not
possible to send these instances to discovery to also create the client
from these. So I am not sure if this option was spec conformant at all.
Another problem is that on the client side you typically need different
interceptors. For example if you add something as a header you would use
an OutInterceptor on the client and an InInterceptor on the server. So
as both client and server must be able to be created from the same set
of service properties I think interceptors are not a good choice. A
better choice is a feature as the implementation can do different things
on the client and server with the same feature definition.*
*
Possible solution
I propose to use intents for all customizations. An intent is an OSGi
service of several possible types that is identified by a special
property (org.apache.cxf.dosgi.IntentName).
A service can specify a list of named intents it requires. The service
is then only published when all intents are present as services.
In the current code on master it is possible to use intents for
Databinding, Binding Config, Feature and Provider.
I have also introduced a new interface IntentProvider with one method
List<Object> getIntents(). It allows to specify a whole list of intents
with one name.
This is useful if these intents should always be used together. As
IntentProvider is not CXF specific we could even move this interface to
the Aries RSA spi bundle.
An example for this can be see in this test. It uses the intent "my"
with a MessageBodyWriter and a MessageBodyReader. Both service endpoint
and client proxy can be created from this
intent and allow a full roundtrip for a call with customized serialization:
https://github.com/apache/cxf-dosgi/tree/master/provider-rs/src/test/java/org/apache/cxf/dosgi/dsw/handlers/rest/provider
Such IntentProvider services are easy to publish using any dependency
injection framework and allow to set instances which can even be
injected with other services if necessary.
So I think this solution should be viable to set all typical needs for
SOAP as well as REST.
So what do you think? Can we use this to replace all the old config
options?
Christian
On 07.07.2016 11:52, Sergey Beryozkin wrote:
> 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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [Heads up] Design of new major version of CXF DOSGi
Posted by Sergey Beryozkin <sb...@gmail.com>.
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/
Re: [Heads up] Design of new major version of CXF DOSGi
Posted by Sergey Beryozkin <sb...@gmail.com>.
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/
Re: [Heads up] Design of new major version of CXF DOSGi
Posted by Christian Schneider <ch...@die-schneider.net>.
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
Re: [Heads up] Design of new major version of CXF DOSGi
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sb...@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 <sb...@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/
Re: [Heads up] Design of new major version of CXF DOSGi
Posted by Christian Schneider <ch...@die-schneider.net>.
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 <sb...@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 <sb...@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/
>>>
>>>
>>
>>
>>
>
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
Re: [Heads up] Design of new major version of CXF DOSGi
Posted by Sergey Beryozkin <sb...@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 <sb...@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/
>>
>
>
>
Re: [Heads up] Design of new major version of CXF DOSGi
Posted by Christian Schneider <ch...@die-schneider.net>.
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.
What do you think? Should that work?
Christian
2016-07-06 16:49 GMT+02:00 Sergey Beryozkin <sb...@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/
>
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
Re: [Heads up] Design of new major version of CXF DOSGi
Posted by Sergey Beryozkin <sb...@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/