I recently came accross a problem that I am not sure what a good solution would be. In Riena we fiddle a lot around with
OSGI services rather than using extensions.
The scenario is like this:
Bundle A defines a interface
Bundle B has a class that implements that interface and registers this implementation as OSGi service. This is done in
the start method of the Activator of that bundle
Bundle C tries to find any registered service for the interface in A.
Now obviously C has (intentionally) no dependency to B. Our observation is that Bundle B stays as <<LAZY>> or
as RESOLVED, since no one accesses any class in there. Accessing a class could start that bundle if I had the right
property in my MANIFEST.MF but hence no class is accessed it does not start.
In the past we tried to use our own config.ini (rather then the generated one) and put Bundle B on a lower level which
sometimes had the desired effect. We also tried to start our application with the type OSGI Framework rather than
Eclipse application. There you can also in the UI of the IDE specify start levels.
However at the end of the day we also like Riena to work in launch configurations of type Eclipse applications or Junit
Plugin tests where we can't modify startlevels. If we are not missing a very obvious point it seems a little odd.
The last step we took, which worked quit well but is not a standard was to add a new property to the MANIFEST.MF. We
called that one "Riena-Forcestart" and if set to true, the Activator in the Riena core bundle (which is always started)
calls the Bundles start method that has this attribute. This way any bundle (that you can modify) can be forced to start.
Anyone else out there with a better solution ? Please tell us !!
Benedikt Arnold schrieb:
> Hi Christian!
> You should use declarative services. That will solve all your issues.
I did use Declarative Services in the past.
However my observation is that DS
- is currently not part of Equinox but only in the Incubator area. (not sure but I think that is still true)
- lacks any editor for the XML descriptive files (which makes it hard to use)
- is pretty hard to debug (since incorrect XML files will most of the times, do nothing without error message)
For that reason I think its easier to tell people to use OSGi Services using the API. No question is DS
the way to go.
sorry for answering so late. I started a new job last week and settled to
> I did use Declarative Services in the past.
> However my observation is that DS
> - is currently not part of Equinox but only in the Incubator area. (not sure
but I think that is still true)
> - lacks any editor for the XML descriptive files (which makes it hard to use)
> - is pretty hard to debug (since incorrect XML files will most of the times,
do nothing without error message)
Full ack. It is only in the incubator but I had no problem using this
implementation. There is an xsd for the xml descriptive files so code
completion should be no problem.
Missing error messages are a big problem. I spend a lot of hours with it
> For that reason I think its easier to tell people to use OSGi Services using
the API. No question is DS
> the way to go.
> Are you currently using DS a lot ?
I made heavy use of ds in my diploma thesis but I am currently
experimenting with spring dynamic modules an I think thats the way to go