tags:

views:

79

answers:

1

Hi, i'm fairly new to osgi and am trying to get a functional proof of concept together.

The setup is that my common api is created in a bundle creatively named common-api.jar with no bundle activator, but it exports all it's interfaces. the one of interest in this situation is DatabaseService.java.

I then have a Second bundle called systemx-database-service. That implements the database service interface. this works fine as in the activator of the implementation bundle i test the connection to the database and select some arbitraty values. I also register the service i want to be available to the other bundle's like so:

   context.registerService(DatabaseService.class.getName(), new SystemDatabaseServiceImpl(context), new Properties());

The basic idea being when you look for a service reference for a Database service you'll get back the SystemDatabaseService implementation.

When i do a inspect service the output it this:

-> inspect s c 69
System Database Service (69) provides services:
----------------------------------------------
objectClass = za.co.xxx.xxx.common.api.DatabaseService
service.id = 39

which would lead me to believe that if i do this in a test bundle:

context.getService(context.getServiceReference(DatabaseService.class));

i should get back an instance of DatabaseService.class, but alas no such luck. it simply seems like it cannot find the service. stick with me here my story gets stranger.

figuring there is no where to go but up i wrote this monstrosity:

 for (Bundle bundle : bundles) {
        if (bundle.getSymbolicName().equals("za.co.xxx.xxx.database-service")) {
            ServiceReference[] registeredServices = bundle.getRegisteredServices();
            for (ServiceReference ref : registeredServices) {
                DatabaseService service = (DatabaseService) context.getService(ref);
               // use service here. 
               }
            }
        }
    }

now i can actually see the service reference, but i get this error

java.lang.ClassCastException: za.co.xxx.xxx.database.service.impl.SystemDatabaseServiceImpl cannot be cast to za.co.xxx.xx.common.api.DatabaseService

which is crazy since the implementation clearly implements the interface!

Any help would be appreciated. Please keep in mind i'm very new at the osgi way of thinking so my whole approach here might be flawed.

oh. if anyone wants the manifests i can post them. and i'm using the maven-bnd-plugin to build and executing on felix.

thanks

Nico

+2  A: 

The test bundle must resolve to the same import of the DatabaseService interface as the SystemDatabaseServiceImpl. If this does not occur, then getServiceReference documents that it will return null even if a service is found. By locating the bundle manually and attempting to locate the service and cast, you're showing why getServiceReference behaves in this way: if it returned arbitrary services, Java casts would fail.

I would recommend printing DatabaseService.class.getClassLoader() in both the impl bundle and test bundle to prove if they're the same bundle. If they're not, then you need to adjust your OSGi MANIFEST.MF metadata to ensure that they have a consistent view of the interface class.

For example, is the DatabaseService interface included in both the test and impl bundles? If yes, you need to move that interface to either the impl bundle (and Export-Package) or to a third interface bundle and Export-Package. Then, adjust the other bundles to Import-Package.

bkail
Getting "class A cannot be cast to class A" is a classic Java issue when multiple class loaders are involved and OSGi has a classloader per bundle.
hbunny
spot on bkail. when i ran a sysout on the class loaders i got[ 69.0 = classloader for target service74.0 = classloader for this class].the common-api is in a separate bundle. does that mean that i need to exclude it from the jars that i'm creating for the implementation and test bundles?
Nico
thanks. excluded the common api from everything and BAM. works like a charm
Nico