Community
Participate
Working Groups
Build ID: 3.3.0.v20070208 I have a bundle that creates a JFrame, but does not have javax.swing in its Import-Package. The bundle can be installed by; osgi> install http://www.ops4j.org/~niclas/equinox-test-1.0.0-SNAPSHOT.jar Various ways to start a "strict" Equinox instance has been tried; java -Dosgi.java.profile.bootdelegation=none \ -jar $EQ/plugins/org.eclipse.osgi_3.3.0.v20070208.jar \ -clean \ -console java -Dosgi.java.profile.bootdelegation=ignore \ -Dorg.osgi.framework.bootdelegation="" \ -jar $EQ/plugins/org.eclipse.osgi_3.3.0.v20070208.jar \ -clean \ -console which according to the documentation at http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/runtime-options.html should disable automatic delegation to the parent classloader. So, the testcase is; 1. Start Equinox. 2. install the bundle from http://www.ops4j.org/~niclas/equinox-test-1.0.0-SNAPSHOT.jar 3. Start the bundle. 4. If the bundle gets started, there is a problem. More information: The Manifest looks like; Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: niclas Build-Jdk: 1.5.0_06 Extension-Name: equinox-test Specification-Title: Bundle to test R4 specification ambiguities. Specification-Vendor: OPS4J - Open Participation Software for Java Implementation-Vendor: OPS4J - Open Participation Software for Java Implementation-Title: equinox-test Implementation-Version: 1.0.0-SNAPSHOT Bundle-Copyright: Copyright 2006OPS4J - Open Participation Software fo r Java Bundle-ClassPath: . Bundle-Version: 1.0.0 Bundle-Source: https://scm.ops4j.org/repos/ops4j/branches/pax/wicket2/ equinox-test Bundle-Vendor: OPS4J Bundle-ManifestVersion: 2 Bundle-ContactAddress: http://www.ops4j.org/ Bundle-Date: 2007-Mar-20 15:01 MYT Bundle-DocURL: http://www.ops4j.org/projects/pax/wicket/equinox-test Import-Package: org.osgi.framework Bundle-Name: Testing Equinox behavior Bundle-Description: Bundle to test R4 specification ambiguities. Bundle-SymbolicName: org.ops4j.test.bundle Bundle-Localization: plugin Bundle-Activator: org.ops4j.test.bundle.Activator The source is nothing more than; public void start( BundleContext bc ) throws Exception { new JFrame("Title").setVisible( true ); }
Created attachment 61497 [details] The test bundle The file that is available on the server, is attached for archiving purposes.
Try -Dosgi.compatibility.bootdelegation=false. Also see bug 162231#c7
(In reply to comment #2) > Try -Dosgi.compatibility.bootdelegation=false. > > Also see bug 162231#c7 > The default value of this flag needs to be false for simple use of the equinox framework (e.g. java -jar). When the equinox framework is used by eclipse, then the value can be set to true. The can be done via an explicit set in config.ini, for example, or implicitly by the launcher or the act of processing a config.ini. It is important that the simple use of equinox as an OSGi framework follow the OSGi specification as closely as possible.
In the light of the discussion that took place on the osgi-dev mailing list, I wonder if the equinox implementation should not have a command line option whose goal is to set all the options like for the RI. This way people don't have to download the same implementation from a different place. Would that work with you? In addition to that, we could see if it makes sense to have this option be the default one when starting equinox directly from the jar (e.g java -jar org.eclipse.osgi.jar). And another important aspect of the problem is tooling, where this option could be turned on if a bundle contained in the launch configuration contains a bundle created with the "standard" option (see first page of the new plugin wizard). This could also be used in the
(In reply to comment #4) > In the light of the discussion that took place on the osgi-dev mailing list, I > wonder if the equinox implementation should not have a command line option > whose goal is to set all the options like for the RI. This way people don't > have to download the same implementation from a different place. > Would that work with you? Well not really. The default (for the simple case: java -jar) should not require anyone to remember some special option. The question could be flipped to say: Would it work for Eclipse to have some option that sets the mode to "permissive"? :-) > > In addition to that, we could see if it makes sense to have this option be the > default one when starting equinox directly from the jar (e.g java -jar > org.eclipse.osgi.jar). This is what is needed. java -jar should be strict. > And another important aspect of the problem is tooling, where this option could > be turned on if a bundle contained in the launch configuration contains a > bundle created with the "standard" option (see first page of the new plugin > wizard). > > This could also be used in the >
I agree that we should have a strict mode flag or some such - note that this might be hard to define as there are different levels of strictnes. For example should all Equinox extensions be disabled in strict mode? buddies? x-internal ,... This may cause grief for some people - I am not keen triggering the mode of of the launch path (unless there is a new / explicit "strict" launch path). There are many usecases here people expecting "Eclipse" behaviour run using java -jar. We cannot change that behaviour. - personally I suggest that the RI come from OSGi and it be configured appropriately. We can provide the code and the means to do the configuration. To be clear, it is highly desirable that people conform to the spec but give the rate of evolution of things and the adoption of the technology, it is not likely to be practical.
I will investigate adding a "simple" option to configure Equinox to be a standard/strict OSGi Framework implementation. For now I will call this option osgi.mode=standard Here is the list of things I can think of to enable/disable when this mode is set. - Strict boot/parent delegation By default Equinox has a policy to delegate to boot as a last resort after searching all constraints (import-package, require-bundle, self, fragments) - Strict behavior WRT activating bundles with lazy activation policies. In Equinox, by default bundles with the lazy activation policy are allowed to activate when a trigger class is loaded without requiring the bundles be started with the Bundle.start(START_ACTIVATION_POLICY) method. - Strict verification of Execution Environment In Equinox, by default if a bundle is installed into a platform without a matching Execution Environment then the bundle is allowed to be installed but it is not allowed to resolve. The OSGi specification mandates that the bundle fails to install. - Disable plugin convertion Ever since 3.0 Equinox has been able to convert old-style eclipse plugins with no bundle manifest into OSGi bundles. - Disable buddy classloading This is the support for the Eclipse-BuddyPolicy headers etc. - Disable Context Finder Equinox sets the context classloader to a Context Finder that essentially converts all usage of the default context classloader to Class.forName calls Questionable settings that will not be enabled by the osgi.mode=standard - Enable bundle signing support Equinox by default does not verify signed bundle certificates or verify code content at load time. Not sure we should enable that be default since it is an optional part of the spec. - Enable the framework security manager Equinox by default does not set the framework security manager. This is needed to support the optional PermissionAdmin and ConditionalPermissionAdmin services. Others that people can think of?
Jeff McAffer, BJ Hargrave and Myself have come up with the following plan. - Equinox's default behavior when using java -jar org.eclipse.osgi.jar will be to *not* delegate to boot classloader by default. It is assumed that most customers that use equinox in this way are investigating OSGi and are expecting a standard behaving OSGi Framework. - For typical Eclipse scenarios which use the eclipse.exe and org.eclipse.equinox.launcher jar will still have the boot delegation compatibility option enabled by default (see bug 162231) - For the post 3.3 release (e.g. 3.4, 4.0) we will investigate disabling the boot delegation compatibility flag for the Eclipse scenarios as well. Our main goal is to converge the Eclipse and OSGi communities as much as possible. - A separate bug 179356 has been opened to investigate a more general option to disable all Equinox extras. This does not seem as important because bundle developers must make explicit decisions to use these extra Equinox "containerisms". But the boot delegation compatibility dependence is much more implicit and hard to debug when things go wrong on other frameworks.
I will release the new defaults for running with java -jar org.eclipse.osgi.jar
The bootdelegation compatibility option will be set to false by default: osgi.compatibility.bootdelegation = false This option will be false by default when using java -jar org.eclipse.osgi.jar or when using the old org.eclipse.osgi.framework.launcher.Launcher class which the OSGi TCK uses. Fix is in HEAD for M7.
Can you publicize this on equinox-dev so that people picking up the latest stuff are not surprised? We likely need some buildnotes or other information available.
