On 3/19/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi, > > I've done some experiments now and this leads me to another > question: In my sample a component A calls a component B > which in turn uses the ComponentContext to get a CallableReference > to start a conversation with a component C. This works with > implementation.java. > > Then I switched A and B to implementation.osgi and have them > registered using OSGi Declarative Services. Now it does not > work anymore, because B does not have a ComponentContext > injected, while A does have one. Then I switched back A > to implementation.java and now B has a correct ComponentContext > again. > > So the summary is: If an implementation.osgi component is > called by another implementation.osgi it does not have its > ComponentContext set, while it has it have set if called > from an implementation.java component (or from outside the > domain). Which one is wrong - or is it me who's wrong trying this? > Mayne an implementation.osgi component should not use a > ComponentContext at all? I would unterstand that, too, but the > current behaviour is different.
You should be able to use ComponentContext in an implementation.osgicomponent, regardless of where it is called from. Having said that, Tuscany cannot enforce wiring of OSGi services and references, so it is always possible for OSGi implementations to bypass Tuscany proxies and hence obtain a service which doesn't have the ComponentContext set. There are other SCA features like scoping as well which rely on implementation.osgi components picking up the Tuscany proxy service rather than the original OSGi service. In your example, B will have a ComponentContext set only if B was invoked through a Tuscany proxy. If A is an implementation.java component, this is always true. If A is an implementation.osgi component, a proxy service with the highest possible ranking is installed into the OSGi service registry, and the original OSGi service registered by B is also in the service registry. Without any additional filters, it is left to OSGi to choose between the two. There is an additional property on the proxy that you can filter on to guarantee that the proxy is selected. Tuscany proxies have a property "component.service.name" which is set to SCAComponentName/SCAServiceName. The wiring examples in itest/osgi-implementation use these (eg. itest/osgi-implementation/src/main/resources/osgi/wiring/ds/Retailer1.xml). There is still an outstanding issue with CallableReference when running inside OSGi. The interface referred to by the CallableReference is currently resolved using the thread context classloader, and hence will work with OSGi only if it can be resolved using TCCL. Cheers, > Juergen. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thank you... Regards, Rajini
