cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [Discuss] Provider API for DOSGi and move core of CXF-DOSGi to Aries
Date Mon, 29 Feb 2016 12:09:56 GMT
Hi Sergey,

just saw that my paste was incomplete.
The createServer method already contains a map and the createProxy 
method contains the EndpointDescription which also has a map inside.
So I think we should already be able to push additional data through the 
Maps.
Sorry for the error.

Btw. One thing I hope to be able to remove is the dswContext. I think it 
should be internal to the provider.

Christian

https://github.com/apache/cxf-dosgi/blob/master/dsw/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/api/ConfigurationTypeHandler.java

public interface ConfigurationTypeHandler {
      ExportResult createServer(ServiceReference<?> serviceReference,
                          BundleContext dswContext,
                          BundleContext callingContext,
                          Map<String, Object> sd,
                          Class<?> iClass,
                          Object serviceBean);

      Object createProxy(ServiceReference<?> serviceReference,
                         BundleContext dswContext,
                         BundleContext callingContext,
                         Class<?> iClass,
EndpointDescription endpoint) throws IntentUnsatisfiedException;
}

EndpointDescription endpoint) throws IntentUnsatisfiedException;

On 29.02.2016 12:01, Sergey Beryozkin wrote:
> Hi Christian
>
> I think it is a good idea to make some of CXF-DSW code re-usable.
> It may help to give more 'energy' to CXF DOSGI itself (as well to 
> DOSGi in general), and also indeed make for yet another connection 
> between CXF and Aries.
>
> As far as ConfigurationTypeHandler is concerned, what happens if in 
> some future one extra parameter needs to be passed along. If it were 
> in CXF DSW then it would be only a quick internal update. Might be 
> worth adding an extra parameter such as Map<String, Object>, so that 
> the extra objects can be passed if needed without breaking the 
> implementations. May be that interface will never change :-) or may be 
> a better idea can be realized...
>
> Cheers, Sergey

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com


Mime
View raw message