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 <[email protected]>: > 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 <[email protected]>: >> >> 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>
