Bugzilla – Full Text Bug Listing
| Summary: | Bundles that use OSGi DS should declare an optional dependency to org.eclipse.equinox.ds | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Kai Toedter <kai.toedter> |
| Component: | E4 | Assignee: | Project Inbox <e4.runtime-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | john.arthorne, tjwatson |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
As others have said on the e4 mailing list, it isn't correct to add a dependency on org.eclipse.equinox.ds. The equinox ds bundle provides no API, and it is just one possible implementation of the service. In fact, it should be possible to use e4 with some completely different injection system if desired - most of the e4 code itself just requires a service and it doesn't care who provides it. The IEclipseContext abstraction is intended to separate the service consumer from the provider so that service consumers don't need to know anything about the service provider framework. A client could add a new parent context with a different ILookupStrategy that obtains services from some other mechanism. Having said that, it is definitely a problem and we hit the same issue in the 3.x stream which also uses DS. Currently we add DS as a dependency at the feature level to keep the bundle dependencies clean, but I remember Tom talking about a more generic mechanism that would allow a bundle to declare "I need a service injection provider", without specifying any one in particular. That would allow p2 or the OSGi resolver to find DS or some equivalent automatically. Also, to be a good service citizen E4CommandProcessor should really be checking for a null service before trying to reference it. That way it could at least provide better logging (the error could say that it failed because a required service was not available). OK, I just wanted to make sure that everyone is aware of the current situation. (In reply to comment #1) > Having said that, it is definitely a problem and we hit the same issue in the > 3.x stream which also uses DS. Currently we add DS as a dependency at the > feature level to keep the bundle dependencies clean, but I remember Tom talking > about a more generic mechanism that would allow a bundle to declare "I need a > service injection provider", without specifying any one in particular. That > would allow p2 or the OSGi resolver to find DS or some equivalent > automatically. > In Equinox we have generic capability/requirement headers that can be used to declare a capability that other bundles can depend on in order to resolve. See Eclipse-GenericCapability and Eclipse-GenericRequire headers at http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/misc/bundle_manifest.html We could consider adding a capability header to DS to declare a DS runtime capability that other bundles can require. This would prevent such bundles that require a DS runtime to fail to resolve if a bundle was not installed that provided the DS runtime capability. There are a few downsides to this approach currently. - p2 does not recognize these headers currently and will not cause the DS bundle to be installed if another bundle requires a DS runtime capability with the Eclipse-GenericRequire header. - In the next OSGi release we will like standardize something very similar to the Equinox-Generic* headers. Perhaps we should evaluate the proposal for the OSGi specification to see if it meets our needs. Either way we would need p2 to understand the concept of generic capabilities and requirements declared in bundles. |
OSGi DS (Declarative Services) are used as the base for the e4 service implementation. But since there is no dependency defined, launching e4 based RCP apps often result in NPEs, like !ENTRY org.eclipse.osgi 4 0 2010-07-02 13:34:51.014 !MESSAGE Application error !STACK 1 java.lang.NullPointerException at org.eclipse.e4.ui.internal.workbench.E4CommandProcessor.processCommands(E4CommandProcessor.java:52) ...