16

I have a class with dependencies which I want to hot deploy without restarting the dependencies. The class has an interface but there's only one concrete implementation.

Initially I created a single bundle with exported the interface and registered the implementation using activator and implementation classes which were not exported. However, if I update the bundle, bundles which use the registered service get restarted after the update when PackageAdmin#refreshPackages is called (this is automatic when using fileinstall).

I have fixed this by creating a separate api bundle.

Is this the best way to achieve this?

Would you ever have a bundle which exports its api and includes the implementation in the same bundle. As far as I can see any give bundle would either export all its classes or no classes. What am I missing?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Thomas Rynne
  • 397
  • 2
  • 10

3 Answers3

20

It is definitely a best practice to separate API bundles from their implementations in OSGi. If you do this, then any bundle that uses the API only needs to import classes from the API bundle, which can allow you to change implementations at runtime without restarting your dependent bundles.

Ideally your implementation bundle would implement the interface and export implementation as a service on the API provided interface. This allows the client bundles to utilize the service without referencing the implementation bundle.

Ryan Gross
  • 6,423
  • 2
  • 32
  • 44
  • 9
    I agree 100% with this answer, but I'd like make it a bit more explicit. In an ideal OSGi world, there are just 2 kinds of bundles. One contains *pure API* (i.e. just interfaces and exceptions) and these packages are exported. The other kind of bundle is the implementation bundle and it exports *nothing*, using services to interact with other bundles. Note that it is quite acceptable in many cases to merge multiple APIs into one bundle. – Neil Bartlett Jun 27 '11 at 23:49
10

In Apache Sling we do both: major APIs are in their own bundles, but for smaller things like extensions or optional components we often provide the default implementation in the same bundle as the API.

In the latter case, you can still allow for those default services to be replaceable, for example using service ranking values when you want to override them.

A bundle does not have to export all its classes, our bundles which include default services export just the API packages (and the default implementations are in different packages, obviously).

Bertrand Delacretaz
  • 6,100
  • 19
  • 24
0

Unless there is a hard requirement to be able to replace implementation at runtime, without restarting client bundles, I would personally advocate keeping the explicit dependency link between API and implementation (either by including impl classes in the API bundle, or by having the API bundle import implementation packages from the impl. bundle).

The pb with the patterns suggested above is that they break the dependency chain. The benefits of dependency management go far beyond simple API compatibility, they also include ensuring predictable, consistent runtime behavior, as well as compatibility with the deployment ecosystem, and all of those require managing the implementation dependencies.

franck102
  • 221
  • 4
  • 14