tags:

views:

159

answers:

1

I'm currently testing out osgi (Spring DM) on a new application. The application needs to be able to listen to file system events. Today I've solved this with a simple time based poller, but when Java 7 is released I probably want to replace that with a NIO2 based implementation.

So far I'm looking at three bundles, two for the file service implementations and one for the business logic consuming one of the services. The two implementations should implement the same interface so my question is, where to place that interface? Placing the interface in the bundle containing the implementation would cause the service to depend on one of its consumers.

What would be the best and most osgi-like way to structure this? So far my best bet is to create a new "api" bundle defining the common interfaces for the implementations.

+4  A: 

Separete api-bundle is probably the best choise. It allows you to replace bundle implentation later. Also with separate api-bundle you are able to hot-replace your current bundle with out the need for consumer to restart as well.

Classes (and interfaces) are recognized by their name and class loader. So if you place the service-interface in the same bundle as the implementation you lose the ability to hot-replace running bundle. Even though the interface has the same name, and it is identical in every sense newly deployed bundle has a different class loader => consumer considers the newly deployed bundles interface as a new class, and its dependencies are no longer met.

Ahe
In addition you should make use of bundle-versions. This way you can even have different versions of the same API bundle and even the same service deployed in one framework.
akr
While you can do that with OSGi, if you have different versions of the same API, this will split your application into regions that use each version, and they will probably not be able to cooperate very well, because the will have incompatible classloaders. For example by default OSGi will not make services that implement a different version of the API visible.
Thilo
That is correct. I just wanted to point out that it is actually important to use the versioning here in case, for example, only one bundle (implementation or API) is updated. Otherwise you might end up in a mess because you don't see that the API, the implementation bundle and the using bundle don't match.Could you explain what you mean with "incompatible classloaders"?
akr