Hi Neil,
On 2/20/2011 6:10 PM, Neil Bartlett wrote:
Taking a step back because I'm getting confused... it seems the
problem might be as follows.
You (an RSA bundle) want to proxy the org.foo.IFoo, so you need
register your service factory against the interface name
"org.foo.IFoo". You can't register it using your RSA bundle's own
BundleContext because your RSA bundle doesn't import the "org.foo"
package, so the framework will see that it is not compatible with the
client bundle. As per BJ's checklist for compatibility:
"Are the client bundle and the registering bundle (note that in both
cases it the bundle context used which established the bundle) wired
to the same service type?"
I.e, the registering bundle (or rather the bundle whose BundleContext
is used to register the service factory) must be *wired* to the
service package using Import-Package, which is obviously not true for
the RSA bundle. And you can't register using the client's context
because the client may not exist yet.
Right.
It seems you have three options:
So just to make sure I understand: is it not possible for the topology
manager bundle to register the proxy ServiceFactory (with or without the
service type Class actually loaded)...and have the consistency check
succeed?
1) Use the BC of the API bundle itself, i.e. the bundle that exports
package "org.foo". This should work because it will be compatible with
any client bundle that imports the package, but it may be confusing
for users since the service registration will appear to be coming from
the API bundle.
I agree that this seems confusing (proxy ServiceFactory registration
from the api bundle itself). Although at face value it seems like the
most direct way to handle things.
2) Use Service Hooks to detect when a client bundle goes looking for
the service, and dynamically register the proxy using the client's own
BundleContext. Again possibly confusing because the client will seem
to be getting the service from itself!
This seems like a lot of complexity...and I agree confusing that the
client seems to be getting the service from itself.
3) Use the BundleContext of a bundle created on the fly that imports
package "org.foo".
I hope BJ can confirm that my reasoning is sound. Assuming it is then
I would proceed by testing option (1) to ensure it gets rid of the
service compatibility problems, then implementing (3) since this
appears to be the proper way.
My great concern, if this is indeed the Right Way, is that it is much
too hard to implement an RSA bundle! Any bundle that wants to provide
a new remoting transport is expected to act as an RSA, so ideally it
should not require the same level of sophistication as implementing a
Topology Manager.
Yeah, I agree. If 3 really is the Right (or Only) Way, it does seem to
me to be a lot of effort/sophistication, etc.
If I'm understanding things, though...ECF's transport-independent remote
service API makes possible the creation of a single RSA that can use
multiple remoting transports.
Thanks,
Scott
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
