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
