I am fairly certain the spec says if the requester does not have a wire
to the package, then it should receive the service reference. In this
case the framework assumes the caller is using reflection to access the
service object. Here are the comments in
ServiceReferenceImpl.isAssignableTo():
// There are three situations that may occur here:
// 1. The requester does not have a wire for the package.
// 2. The provider does not have a wire for the package.
// 3. Both have a wire for the package.
// For case 1, we do not filter the service reference since we
// assume that the bundle is using reflection or that it won't
// use that class at all since it does not import it. For
// case 2, we have to try to load the class from the class
// loader of the service object and then compare the class
// loaders to determine if we should filter the service
// refernce. In case 3, we simply compare the exporting
// modules from the package wiring to determine if we need
// to filter the service reference.
If you have a simple example where this is not working, create a JIRA
issue for it and attach the example.
-> richard
On 3/20/09 6:33 PM, Guillaume Nodet wrote:
Another problem i've hit is that if C does not even import foo and the
service exported by A as one of its exposed interface from the foo
package, C won't be able to use the service. This can be problematic
because C may be able to use some of the interfaces exposed by that
service. I'm not sure what the spec says about such scenario. If
this is not mandatory, I think the behavior could be changed in such a
case. The getServiceReference() should exclude service which have an
incompatible class between bundles A and C, but not exclude services
which have classes not known to C imho.
This can easily be used when using spring-dm and the export-all
attribute which exports all the classes and interfaces (leading to the
service being usually unusable, unless you see the implemenation class
itself).
On Fri, Mar 20, 2009 at 23:24, Karl Pauls<[email protected]> wrote:
Well, a call to the BundleContext.getServiceReference(s) method is
going to filter based on whether you can see the version of the
interface of the service or not. In certain scenarios, you couldn't
use the service because you see a different version of the interface
then the service actually implements (so you would get a classcast
exception). Therefor, these services are filtered away. In case you
still want to see them (for example because you are going to use
reflection) you can use the getAllServiceReferences method.
Why is that happening? Well, there are a couple of scenarios but a
simple one is:
A imports foo from B
C imports foo from D
now if A exports a service with an interface out of foo then C can not
use that service because it gets foo from a different provider. That
is why bundles should generally import what they export.
In your case, try to use getAllServiceReferences and see whether that
helps. Then you can check where your bundle wiring goes wrong.
Hope that helps.
regards,
Karl
On Fri, Mar 20, 2009 at 10:50 PM, Patrick Forhan<[email protected]> wrote:
This is a generic OSGi service question, I think. We use a mix of
Spring-DM and Felix-SCR for services, but have never had an issue like
this.
Are there any circumstances where a service won't be found by someone
looking for it? My impression is that services are referenced by a
string version of their class name, so there shouldn't be class
loading differences, right?
Basically, we have this structure:
bundle mvc.framework
IView
ICommand
... and a couple of services looking for instances of those interfaces.
bundle authentication.ui
AuthenticationView implements IView
AuthenticationCommand implements ICommand
For some reason, AuthenticationCommand gets found by the service
looking for ICommand interfaces, but AuthenticationView does not.
When I do a "services" on authentication on the felix cmd line, both
are showing properly. But when I do a "services -u" on mvc.framework,
only AuthenticationCommand shows up.
This feels like some filtering is in place, but we've stripped all of
that out. This code is only 2 days different from a working version
of our spring-dm context files, and we can't see what's going on.
Pat.
--
Defy mediocrity.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Karl Pauls
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
