cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eoghan Glynn <eoghan.gl...@iona.com>
Subject Re: [DOSGi] Few questions re current DOSGi implementation (sandbox)
Date Thu, 11 Sep 2008 16:43:05 GMT


Daniel Kulp wrote:
> Eoghan,
> 
> On Thursday 11 September 2008 5:52:20 am Eoghan Glynn wrote:
>>> Next question.
>>> When I expose a service registered under multiple interfaces, what is it
>>> supposed to do in today's codebase?
>>> Will it somehow expose both interfaces over the wire or does it just
>>> pick one?
>> The intention was to support the multi-interface case mapping to a
>> single endpoint by creating a java.lang.reflect.Proxy aggregating the
>> interfaces, and using this proxy as the service class on the
>> ServerBeanFactory.
>>
>> However this introduces some complications around the namespace mapping
>> used the Aegis binding, particularly in ensuring that the namespace used
>> for client-originated payloads match that expected by the server-side.
>>
>> So this approach will require some core CXF changes in order to work,
>> and isn't supported right now.
> 
> Actually, you shouldn't need to refactor any core CXF for this I think.  If 
> you write your own ServiceConfiguration object, there are methods for getting 
> the qnames for the request/response wrappers and such where you can make sure 
> you get the correct namespaces from the correct implementation.   Just 
> register your version before the default versions.


Nice one, thanks for the heads-up. We'll look at using this approach to 
simplify the multi-interface case.

Due to recent changes to the RFC 119 spec, we're not guaranteed that the 
client is made aware of all the interfaces exposed by the OSGi service, 
or even the fact that its a multi-interface service.

So for a service that exposes two interfaces, say foo.bar.I1 and 
sna.fu.I2, would it make sense to think of a server-side 
ServiceConfiguration that's capable of accepting incoming namespaces 
based on /either/ "foo.bar" or "sna.fu" (depending on which interface 
the client has resolved)?

Or would the correct approach be to use a client-side 
ServiceConfiguration to map onto some agreed namespace decoupled from 
both the foo.bar & sna.fu packages?

Cheers,
Eoghan


> Dan
> 
> 
> 
>> For the moment, maybe we should just take the simple approach of mapping
>> each interface onto a /separate/ endpoint.
>>
>> /Eoghan
>>
>>> I'm looking at changing the behaviour of the org.osgi.remote.publish
>>> property with the behaviour in the spec (instead of the value
>>> 'false|true' a list of interfaces or '*' for all published interfaces
>>> should be provided).
>>>
>>> Thanks,
>>>
>>> David
>>>
>>> ----------------------------
>>> IONA Technologies PLC (registered in Ireland)
>>> Registered Number: 171387
>>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>> ----------------------------
>> IONA Technologies PLC (registered in Ireland)
>> Registered Number: 171387
>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
> 
> 
> 

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Mime
View raw message