Sharing Packages and Services between PARs

I'd like to set up a new project using DM Server. I've done some simple stuff and it looks very cool. Now I have a slightly more complicated setup that's stumping me.

In this app, I'm doing a main webapp PAR that can use dynamically loaded services. The PAR has two bundles: one that defines the Service interface, and one that has the actual web app, including a controller and the list of services.

The services themselves might be simple bundles, for simple services, or they might be other PARs, for services that need to do complex database work.

However, I'm running in to two problems. First, the Service interface is not being exported from the PAR. This prevents the various service bundles from loading.

If I copy the common bundle that defines Service into the pickup dir, the service bundles start, but the actual services still aren't visible in the web PAR.

Is there an easy way around this? This is just a mockup, the real application will have about 5 bundles in the web PAR and around a dozen services. It will be much more convenient to manage these as PARs than as plain bundles, and will lose a lot of what I'm hoping to gain from using DM Server.

I can make my test code available if needed.

Thanks!

If I've understood your modified setup correctly, I'm surprised it doesn't work.

A PAR provides a scope around the packages and services exported by the bundles inside the PAR. This scope prevents the packages and services exported by the bundles inside the PAR from being (easily) accessed from outside the PAR. However, all packages and services exported by bundles outside the PAR should be available to bundles inside the PAR (unless they are "shadowed" by exports inside the PAR).

So by moving the Service interface bundle outside the PAR, bundles inside the PAR and Service implementation(s) outside the PAR should be able to share the same Service interface. Also, by having services exported by Service implementations outside the PAR, the bundles in the PAR should be able to see those services, which appears not to be happening in your case.

Please check that "shadowing" is not the problem. This would be the case if at least one bundle *inside* the PAR exported a service consisting of a Service implementation. In that case, the bundles inside the PAR would be unable to see any Service services from outside the PAR because scoping prefers services inside the PAR when shadowing occurs.

If you have a service outside the PAR which is not shadowed inside the PAR and is not visible to bundles inside the PAR, please would you raise an issue and attach as small an example of code as possible which reproduces the behaviour on dm Server 1.0.2.RELEASE or 2.0.0.M1. (If you are using an older version, you should upgrade first in case the problem has already been fixed.)

Okay, I see my mistake. I had the service interface bundle loaded separately, and inside the webapp PAR. Clearly this was causing the problems with shadowing. Removing that, I can get the service PAR and web PAR to start, and the web par sees the exported services.

I'm a little worried about having to separate the interface bundle from the main PAR, but I suppose I can refactor out any other dependencies to clean it up and keep the number of deployables down.

Thanks for the help!

I'm glad that helped.

If you want to reduce the number of bundles in your system, you *might* want to experiment with an old OSGi R3 style trick, although we haven't tested it much with dm Server, so it might be a voyage of discovery...

If you import *and* export the Service package from each of the Service implementing bundles (and include the Service class in all of those bundles), then the OSGi resolver should keep one of the exports and discard the rest so that the Service implementing bundles and the PAR all share the same Service package. The (arguable) beauty of this is that each Service implementing bundle is self-contained and comes with its own exported interface package, so you don't need a separate bundle just to export the interface package.

On the other hand, if you don't like the sound of including the Service interface in multiple bundles, stay as you as. ;-)