You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Felix Meschberger <fm...@gmail.com> on 2007/08/02 10:56:34 UTC

RE: Issue with Apache Felix Declarative Service

Hi Dev,

> Thanks a lot for your explanation, I was a little confused as to how OSGi
> resolves import packages if the package has been exported by two different
> bundles.

Well, this is layed out in the spec in chapter 3.7, Resolving Process,
which states that the package version is considered as well as
attributes of the export.

In case of multiple possible choices for an export, the following list
defines the preferences in order of decreasing priority (quoting the
Rev. 4.0 spec):

* A resolved exporter is preferred over an unresolved exporter.
* An exporter with a higher version is preferred over an exporter with a
lower version.
* An exporter with a lower bundle ID is preferred over an exporter with
a higher ID.


> As for my problem, we found that we hadn't imported ComponentContext package
> in the manifest file. By the way, I am curious to ask, what kind of
> debugging strategy can be adopted for OSGi? Because at times the bundles
> don't get deployed, but doesn't provide more information as to the reason
> why? Though it shows that there was an Error Event generated while starting
> the bundle.

First of all: have a Log Service implementation and use logging. While
the Felix Framework uses an internal logger, having a Log Service handy
is always a good thing as many of the Compendium Services use a Log
Service to log issues.

Second, more hard core of course, you might want to connect your
favourite Java IDE/Debugger to the running instance to track the code
path. If you encounter issues, using the debugger, which you think would
be worth better logging, you might want to file a JIRA issue.

Regards
Felix