Re: [DOSGi] Few questions re current DOSGi implementation (sandbox)
David Bosschaert wrote: Hi all, I'm trying to get rid of the exception that shows up when you distribute a service in a bundle that doesn't provide an intent-map.xml file. Currently this seems to work well, but an exception comes up on the screen. If a user doesn't provide this map, simply the default distribution settings (intents) should be used. Would simply using a new IntentMap() be enough? or should I try to get a default IntentMap from somewhere else? The idea was to merge the calling-bundle-specific IntentMap with the master map from the DSW bundle, so that the calling bundle could override some intent->policy mappings, or add some new ones. So if the client bundle doesn't require any such overrides, simply creating an empty IntentMap as you propose is fine. 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. 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
Re: [DOSGi] Few questions re current DOSGi implementation (sandbox)
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. 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 -- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: [DOSGi] Few questions re current DOSGi implementation (sandbox)
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
[ZenSolutions:44413] Please add me********** in your distributions***************
Hi Partners, This is VENKY from OPENBOXSOLUTIONS, INC. I have wonderful requirements and excellent consultants with me. so please add me in your distributions. [EMAIL PROTECTED] Yahoo IM: venkysmart4u Thanks & Regards Venky Sr.Technical recruiter, Openboxsolutions Inc, 2890 Carpenter Road, Suite# 2000 Ann Arbor, MI 48108 Phone: 734-418-2582 Fax: 734-975-9380 [EMAIL PROTECTED] *www.openboxsolutions.com* --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Corp_Corp_Resumes" group. To post to this group, send email to Corp_Corp@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Corp_Corp?hl=en -~--~~~~--~~--~--~---
