Community
Participate
Working Groups
Build Identifier: 20100520-1308 The NPE error is not really explicit. At least, tells that the service is missing would be better. In fact, in 3.5, the service was launched in the start of the Activator. In 3.6, it uses the Declaration Service so the plugin org.eclipse.equinox.ds is required. I think that a lot of migration will encountered this error. Thats why it will be great to fix it for 3.6. Reproducible: Always Steps to Reproduce: 1. launch an RCP application without org.eclipse.equinox.ds (ie when you are migrationg from 3.5, you will not have it) 2. 3.
Could you add/complete the "steps"? As well, isn't the workaround to include org.eclipse.equinox.ds?
(In reply to comment #1) > Could you add/complete the "steps"? I don't know exactly what actions called this method of AbstractBundleContainer but building a plugin project might do this > As well, isn't the workaround to include > org.eclipse.equinox.ds? Yes it is :) but a lot people might be confronted with this issue and it will be better if it is explicit that they required org.eclipse.equinox.ds (to have FrameWorkAdmin service)
(In reply to comment #0) > Steps to Reproduce: > 1. launch an RCP application without org.eclipse.equinox.ds (ie when you are > migrationg from 3.5, you will not have it) I'm just wondering how 'critical' this. I'm not sure many RCP applications include PDE. As well, I'm not sure that PDE should be requiring DS, since PDE does not know how the FrameWorkAdmin service is provided. PDE just retrieves the service from OSGi... the fact that DS is used is an implementation detail of the service.
(In reply to comment #3) > (In reply to comment #0) > > Steps to Reproduce: > > 1. launch an RCP application without org.eclipse.equinox.ds (ie when you are > > migrationg from 3.5, you will not have it) > > I'm just wondering how 'critical' this. I'm not sure many RCP applications > include PDE. As well, I'm not sure that PDE should be requiring DS, since PDE > does not know how the FrameWorkAdmin service is provided. PDE just retrieves > the service from OSGi... the fact that DS is used is an implementation detail > of the service. I thought it is critical in the way that if the service doesn't exist, some features of PDE doesn't work and the only hint is a NPE. And yes, perhaps not so many RCP application will be affected. I didn't think that it is PDE.
(In reply to comment #3) > I'm just wondering how 'critical' this. I'm not sure many RCP applications > include PDE. As well, I'm not sure that PDE should be requiring DS, since PDE > does not know how the FrameWorkAdmin service is provided. PDE just retrieves > the service from OSGi... the fact that DS is used is an implementation detail > of the service. Yes. No bundle should have a direct dependency on org.eclipse.equinox.ds since it doesn't provide any API. Especially here, it is another bundle that is using ds to publish its service, and the PDE code is just consuming the service in the traditional OSGi manner.
Reducing severity. It's not critical in the sense that the Eclipse SDK is broken - it's a configration error (that is potentially difficult to diagnose) in the RCP app. PDE should improve handling of the missing service - i.e. log a message if it cannot be found.
The only thing PDE will fix here is the NPE. We use the framework admin service all over in PDE code, but we do not care who provides the service (or whether it is a DS). Reducing severity to normal. Marking for 3.7. We can consider putting this into 3.6.1.
*** Bug 315177 has been marked as a duplicate of this bug. ***
Perhaps we can follow the same way than in e4: https://bugs.eclipse.org/bugs/show_bug.cgi?id=318821 ie display a warning in launch configuration.
Added the NPE guards to HEAD. See AbstractBundleContainer.java If the service is not available, we will just skip trying to load the vm arguments from the running application.
