Import-Package not satisfied unless exporter and importer are in a PAR

Hello,
I have a strange problem here...
As the title suggests, if I have a bundle A exporting a package P, and another Bundle B importing this same package P, then, when starting s2AP, a nasty exception blows on my face :

com.springsource.platform.osgi.framework.UnableToS atisfyBundleDependenciesException: Unable to satisfy dependencies of bundle 'djo.cc.dt' at version '1.0.0': Cannot resolve: djo.cc.dt
Unsatisfied leaf constraints:
Bundle: djo.cc.dt_1.0.0 - Import-Package: djo.cc.foundation; version="0.0.0"
Did you mean: 'javax.activation'?

If I place the bundles A and B in a PAR, and deploy this PAR in S2AP, no problem at all.

Hell, this worked perfectly before (not grouping the exporter and the importer in the same par) ...

Anyway, here are some excerpts from my code:
-bundle A:
-manifest:

Manifest-Version: 1.0
Bundle-Version: 1.0.0
Bundle-Name: Foundation Bundle
Bundle-SymbolicName: djo.cc.foundation
Export-Package: djo.cc.foundation

- Bundle B:
- manifest:

Manifest-Version: 1.0
Bundle-Version: 1.0.0
Bundle-Name: Euro Bundle
Bundle-SymbolicName: djo.cc.euro
Import-Package: djo.cc.foundation

So, what I'm I doing wrong ?

Thanks :)

Hi

A bit more information will help us dig into this.

How are you getting bundles A and B into the Platform? If you are dropping them in the pickup directory for instance, then there is no guarantee that they will be processed in the "right" order and the above resolution failures could happen as often as not (or more often, depending on the precise filesystem behaviour). (You talk about "when starting S2AP", but the Platform doesn't gratuitously resolve bundles on restart unless they are needed by the Platform or by a previously deployed application, so presumably you have deployed these bundles somehow and haven't just put them in the repository.)

>this worked perfectly before (not grouping the exporter and the importer in the same par)

Please could you say on what level of code this worked. In the first beta drop? On Equinox before the Platform was shipped? I'm guessing you are just seeing variability in the behaviour of the filesystem and the Platform's Deployer.

>So, what I'm I doing wrong ?

I can't see anything wrong in the manifests, except that they don't set:

Bundle-ManifestVersion: 2

and so they will be treated as OSGi R3 bundles and Bundle-SymbolicName will be ignored by other OSGi containers (although it turns out the Platform will upgrade the manifests to R4 if you deploy the bundles into the Platform and the Bundle-SymbolicName will be honoured).

Glyn

Hi

>A bit more information will help us dig into this.
my bad

>How are you getting bundles A and B into the Platform?
Using the eclipse tooling: Right click on the S2AP Server, Add and Remove Projects, and the I select the bundles A and B.

> If you are dropping them in the pickup directory for instance, then there is no guarantee that they >will be processed in the "right" order and the above resolution failures could happen as often as not >(or more often, depending on the precise filesystem behaviour).

Isn't this behavior kind of weird and error prone ?


>Please could you say on what level of code this worked. In the first beta drop? On Equinox before >the Platform was shipped? I'm guessing you are just seeing variability in the behaviour of the >filesystem and the Platform's Deployer.

I was talking about a similar situation, i.e. deploying some bundle projects created with STS on eclipse.

Actually, when retrying with these bundles (which previously worked), I can see that they no longer work as before, and I am getting the same exception :"UnableToSatisfyBundleDependenciesException" ...
I guess that that worked on the first S2AP beta and stopped working in the second one :(
>So, what I'm I doing wrong ?

>I can't see anything wrong in the manifests, except that they don't set:

>Bundle-ManifestVersion: 2

>and so they will be treated as OSGi R3 bundles and Bundle-SymbolicName will be ignored by other >OSGi containers (although it turns out the Platform will upgrade the manifests to R4 if you deploy >the bundles into the Platform and the Bundle-SymbolicName will be honoured).

Well, it is the "New bundle Project" Wizard who generates the manifest and the version header.
Should I raise a JIRA issue about this (generating an R4 manifest instead of an R3) ?

Thanks for the reply :)
Jawher

Hi Jawher

I've asked our tooling guru to comment.

As for:

>Isn't this behavior kind of weird and error prone ?

I would say "no". ;-) There's a full discussion in https://issuetracker.springsource.com/browse/PLATFORM-7

Regards,
Glyn

Hi Glyn

>I've asked our tooling guru to comment.
Thanks a lot :)
But I think that under the current design choices of S2AP, this is no longer a bug ... it's simply a matter of the deployment order. More on this later.

>As for:

>>Isn't this behavior kind of weird and error prone ?

>I would say "no". ;-) There's a full discussion in https://issuetracker.springsource.com/browse/PLATFORM-7

Okey, thanks for the link.
Yet, I have to state that I totally and strongly disagree with this approach and I consider this to be a regression compared to the vanilla OSGi containers.

I'm not in a position to be able to judge on technical issues that may have forcer the S2AP team to choose this path, so please correct if this is the case.
But, IMHO, this simply breaks the beauty of OSGi.
Here is an example:
As a sample application, I'm trying to put in place a currencyConverter.
My design is to divide this in a 2+ bundles:
- djo.cc.foundation: where I define a CurrencyConverter interface (which uses euro as etalon).
- djo.cc.web : where I create a web front end for the application
--and now the optionnal parts:
- djo.cc.euro: a concrete implementation of currencyConverter (identity).
-djo.cc.dollar: a concrete implementation of currencyConverter (identity).
-etc.

in the web front end, and using Spring DM, I retrieve the complete list of ICurrencyConverter implementations.
I'm planning to provide a form with 1 textefield, a dropdown to specify the current currency (filled useing the list of converters), and a second dropdown (same elements as the previous) to specify the target currency.

In a perfect world, I would simply deploy the foundation and the web bundles in S2AP, and adding some fancy currency would require me juste to deploy another bundle (like djo.cc.euro), and hit F5 in my web front-end to start using it.

Yet, and because the S2AP tries to install and resolve bundle dependencies in a single bundle base, this kind of scenarios is not possible.

The solution you guys pointed out (put some bundles in the usr repository), IMHO, applies only to third party libraries (log4j, etc.) but not to my own bundles.

What do you think about this case (and, I'm sure about it, zillions of similar cases) ?

Regards,
Jawher

Hi Jawher

We certainly want to support use cases like the example above. We've been discussing how we can best satisfy these requirements, but the current release has been focussed on deploying WARs, PARs, and stand-alone bundles.

There are two approaches we'll want to explore for future releases.

The first is to separate out install and start in some way so that groups of bundles with interdependencies can be installed in any order and then started. This is the kind of thing you would do with the Equinox or Felix consoles, for instance.

The second is to look into adding modules into running PAR files. In the example above, this would enable adding a new currency module to an existing PAR.

To be clear, the approach we are resisting is somehow trying to retain the current deployment semantics of install+start and having to monitor the pickup directory for the arrival of related groups of bundles and then sort them into dependency order for deployment. I'm sure you can see how this would be unreliable: 'late arrival' of group members; cyclic dependencies; etc.

Meanwhile, you have the option of exercising extreme care in the use of the pickup directory - not something we'd recommend - or of using a PAR file to group your bundles and then redeploying the PAR file when you add a new bundle.

Regards,
Glyn

Hello Glyn,
Thanks as always for the quick and clear response.

Sorry if my tone in the previous message was a bit 'excessive' :-)

>The first is to separate out install and start in some way so that groups of bundles with interdependencies can be installed in any order and then started. This is the kind of thing you would do with the Equinox or Felix consoles, for instance.

Yep, basically, this is the idea :-)


>The second is to look into adding modules into running PAR files. In the example above, this would enable adding a new currency module to an existing PAR.

Hum ... interesting idea, but doesn't sound easily feasible nor that clean ...
In fact, if you want my opinion on this, I think that the PAR approach is not very flexible nor extensible ... and it reminds me of something called 'war files' :-D
But yes, I'm perfectly aware that there are many use cases where PAR files are applicable or even best-fit.

>To be clear, the approach we are resisting is somehow trying to retain the current deployment semantics of install+start and having to monitor the pickup directory for the arrival of related groups of bundles and then sort them into dependency order for deployment. I'm sure you can see how this would be unreliable: 'late arrival' of group members; cyclic dependencies; etc.

Hum ... agreed.
Or maybe something like the eclipse way of doing it ? a bundle found in the pickup dir gets installed, but not started, unless requested to do so, i.e. use lazy-loading.
Basically, the 'requested to do so' may be one of those cases:
- For a web bundle, it's context path get's requested.
- For any type of bundle, another bundle imports one of the packages they export.

This implies that the install step must lookup into the bundle meta-data for some info.

I know, I know, this is too kind of abstract and superficial ...

I'm really astounded that this use-case, which IMHO is a sort of 'The Best Of' the OSGi developpement model is not feasible with the current version of S2AP.

Anyway, I guess that it is too late for this version, and in the mean time, would somebody please provide a time-frame for the next major release of S2AP ? weeks ? months ?

Best Regards,
Jawher

After reading Wilkinson's blog post:
http://blog.springsource.com/main/2008/05/09/working-with-springsource-application-platforms-provisioning-repository/

Where the dependency resolution mechanism used by S2AP is described:

1. A bundle which imports org.apache.commons.dbcp is installed by the Platform into Equinox.
2. The Platform asks Equinox for the bundle's unsatisfied dependencies and is told that the import of org.apache.commons.dbcp cannot be satisfied.
3. The Platform searches its index of the provisioning repository for a bundle which exports org.apache.commons.dbcp
4. The Platform installs the bundle which exports org.apache.commons.dbcp into Equinox
5. Having satisfied the original bundle's dependencies the Platform successfully starts the original bundle.


I think that a workaround for the problem I descibe may be plugged in the third step or even between the fourth and fifth steps.

=> Search also the pickup folder for for a bundle which exports org.apache.commons.dbcp

well, not only the pickup folder, maybe also bundles in the stage folder that were not installed yet ?

Hi,

from a tooling perspective I thing we need to find a way to specify the deployment order of the stand-alone bundles for deployment within the tools. Before we go ahead adding such a feature we need to be sure that having this is desired from the platform's point of view.

> Well, it is the "New bundle Project" Wizard who generates the manifest and the version header.
> Should I raise a JIRA issue about this (generating an R4 manifest instead of an R3) ?

Oh yes, please raise a JIRA against the TOOLS component.

Christian

Hello christian :-)
>from a tooling perspective I thing we need to find a way to specify the deployment order of the stand-alone bundles for deployment within the tools. Before we go ahead adding such a feature we need to be sure that having this is desired from the platform's point of view.

That solves only half the problem I'm afraid, i.e. only during development phase.

Imagine instead that you want to extend an already deployed product ... the best theoritical way would be to tell the client to drop a file (bundle jar) in the pickup folder, end of story ...
therwise, you would have to repackage the whole PAR and redeploy it again.

JIRA issue created:
https://issuetracker.springsource.com/browse/PLATFORM-41

Mucho Gracias