Bugzilla – Full Text Bug Listing
| Summary: | [DS] NullPointerException when activating a bundle with a service component (only if framework is launched in a tomcat) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Benedikt Arnold <benedikt.arnold> | ||||||
| Component: | Incubator | Assignee: | Pavlin Dobrev <Pavlin.Dobrev> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P3 | CC: | s.boshev, simon_kaegi | ||||||
| Version: | 3.3 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
It's hard to know for certain if this is the problem however uur implementation of DS should not be using System.getProperty. It should instead, be using bundleContext.getProperty. When launching under an app server (like Tomcat) the FrameworkProperties implementation are private to the framework and are not backed by System Properties. Created attachment 82331 [details]
patch to use BundleContext.getProperty
I think Simon is correct. Are you embedding Equinox into your own application? If Eclipse is launched stand-alone (typical launch using eclipse.exe) then the framework will use the global System properties to store the org.osgi.* property values. But if you are embedding Equinox and you set osgi.framework.useSystemProperties=false then Equinox will use a "instance specific" Properties object for storing the org.osgi.* and other instance configuration properties. These will not be reflected in the global system properties.
A quick search of the bundles from prosyst show quite a few calls to System.getProperty methods. If possible you should try to use BundleContext.getProperty to ensure you are getting the property from the instance of Equinox. This patch does this for the properties causing the issue in this bug.
Hi! Thanks for the hint not to use System.getProperty. It solved another problem in one of my own bundles, too :-) I tried Thomas path and it works for me. Thanks a lot! Cheers, Ben (In reply to comment #2) > A quick search of the bundles from prosyst show quite a few calls to > System.getProperty methods. If possible you should try to use > BundleContext.getProperty to ensure you are getting the property from the > instance of Equinox. This patch does this for the properties causing the issue > in this bug. I think we must also fix occurrences of Boolean.getBoolean() and Integer.getInteger() as well. These methods are using internally System.getProperty() Shall we open new bugs for each bundle that needs these fixes or when we fix all of the bundles we should mark this bug as fixed? I fixed the way of getting of the system properties that caused this bug. I fixed as well all other calls to System.getProperty(), Boolean.getBoolean() and Integer.getInteger() in DS bundle. Fixed also in DS, IO, IP and Util |
Created attachment 82319 [details] workaround for the bug Build ID: I20070625-1500 This bug report is for the bundle org.eclipse.equinox.ds from the equinox-incubator. If I run equinox in a tomcat there is a NullPointerException when activating the org.eclipse.equinox.ds bundle or a bundle which provides a service component. The stack trace is as the following: java.lang.NullPointerException at org.eclipse.equinox.ds.SCRManager.startedBundle(SCRManager.java:474) at org.eclipse.equinox.ds.SCRManager.startIt(SCRManager.java:114) at org.eclipse.equinox.ds.Activator.initSCR(Activator.java:113) at org.eclipse.equinox.ds.Activator.start(Activator.java:168) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java :145) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:291) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:276) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:218) at java.lang.Thread.run(Unknown Source) After debuging a while I found out that SCRManager.java tries to read the property "org.osgi.framework.vendor" in Line 91. If I type on the osgi console "getprop org.osgi.framework.vendor" the value is "Eclipse" but in SCRManager the value is "ProSyst". The value is provided as the default in the System.getProperty call. After changing the default to "Eclipse" everything works fine. I will provide a patch, but I think thats only a workaround. Why is the property value incorrect in SCRManager:91 but correct if I type getprop org.osgi.framewok.vendor in the osgi console?