Bugzilla – Full Text Bug Listing
| Summary: | CNFE: unable to start org.eclipse.jetty.osgi.boot_7.1.3.v20100526.jar | ||
|---|---|---|---|
| Product: | [RT] Jetty | Reporter: | Dmytro Pishchukhin <dmytro.pishchukhin> |
| Component: | osgi | Assignee: | Hugues Malphettes <hmalphettes> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | P3 | CC: | jetty-inbox, mgorovoy |
| Version: | 7.1.3 | ||
| Target Milestone: | 7.1.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Attachments: | |||
Hugues, I presume this needs to be done in time to be included into 7.1.4... Thanks for reporting this Dmytro. In theory org.xml.sax is provided by the profile J2SE5 which is required by this bundle. With equinox it works fine without declaring this extra import. I removed this import on purpose: declaring it explicitly is prone to create some conflicts with other bundles later on. For example, bundleA declares that it imports org.xml.sax;version="1.0" and jetty would import org.xml.sax suddenly OSGi will tell you that it can't load bundleA and jetty in the same classspace. This is why I removed all imports of jdk packages. Can you describe the setup you are using to produce this error? Created attachment 171132 [details]
Maven POM file to test Jetty CNFE
Created attachment 171133 [details]
Platform definition that is used by Pax Runner Maven plugin to start OSGi framework
Hello Hugues. Actually, it does not work with Equinox for me :) Steps to reproduce: 0. create temp folder and download 2 attached files. Install Maven if you need. 1. have a look at platform-definition.xml to get the list of bundles. Copy all those bundles to the temp folder. 2. run Maven command: mvn -f pom-jetty-test.xml -P test 3. you'll see error (or try to start jetty-osgi-boot-7.1.3.v20100526.jar bundle manually) if you have any questions, feel free to contact me. Regards, Dmytro (In reply to comment #4) > Created an attachment (id=171133) [details] > Platform definition that is used by Pax Runner Maven plugin to start OSGi > framework Thanks Dmytro. Could attach the complete project so I can just unzip it and try it? I tried putting the 2 files together, renaming the pom-jetty-test.xml to pom.xml then calling mvn compile and mvn package but nothing much happened. Am I missing something? On a different note: I suspect that you need to specify the execution environment: http://paxrunner.ops4j.org/space/Execution+environment -ee=J2SE-1.5 or more recent. I have not used paxrunner and I am very interested in a sample test project. Thanks. (In reply to comment #6) ... err just reading your comment now: I guess the full attachment is too big for bugzilla. You are welcome to email it to my personal address. org.xml.sax package is provided by system bundle osgi> packages org.xml.sax org.xml.sax; version="0.0.0"<org.eclipse.osgi_3.5.2.R35x_v20100126 [0]> org.eclipse.equinox.registry_3.4.100.v20090520-1800 [3] imports org.eclipse.jetty.xml_7.1.3.v20100526 [13] imports if bootDelegation is configured to provide org.xml.sax package I got NPE during bundle start (something new) that is related to jetty configuration (In reply to comment #8) > org.xml.sax package is provided by system bundle > > osgi> packages org.xml.sax > org.xml.sax; version="0.0.0"<org.eclipse.osgi_3.5.2.R35x_v20100126 [0]> > org.eclipse.equinox.registry_3.4.100.v20090520-1800 [3] imports > org.eclipse.jetty.xml_7.1.3.v20100526 [13] imports > I don't mind adding a Require-Bundle: system.bundle I am curious if you tried the -ee=J2SE-1.5 parameter. > if bootDelegation is configured to provide org.xml.sax package I got NPE during > bundle start (something new) that is related to jetty configuration It is probably because it does not find the configuration file. Unfortunately at this point jetty-osgi is limited to: - start a single instance of the jetty server - that instance is configured via a jetty.xml file found as ${jetty.home}/etc/jetty.xml. I have spent a lot less time actually working on jetty-osgi itself than on packaging it this year. I'll attach a jettyhome folder that will work. I can look for the bug about this limitation. I tried this parameter -ee=J2SE-1.5 and it did not help. as you can see org.xml.sax;version="0.0.0" is provided by system bundle. you dont need to add Require-Bundle: system bundle (OSGi antipatern), just add import of the package. What tool do you use to generate bundle manifest? (Bnd?) Created attachment 171141 [details] sample configuration files currently expected by jetty-osgi There are 2 solutions to the issue: 1- The org.eclipse.jetty.osgi.boot should be installed unzipped. It contains the configuration files. Really not ideal but at least it works. I am not sure how to get paxrunner to do that though. 2- Setup the system property jetty.home and make it point to the jettyhome folder attached here. I am not sure how to pass a system property to paxrunner so I did not try that. Regarding the original issue: I can add Require-Bundle: system.bundle to jetty.osgi's Manifest. I suspect that the execution profile is not passed correctly though. https://scm.ops4j.org/repos/ops4j/projects/pax/runner/pax-runner-platform/src/main/resources/META-INF/platform/ee/J2SE-1.5.profile Does declare the org.xml.sax package. (In reply to comment #10) > I tried this parameter -ee=J2SE-1.5 and it did not help. > > as you can see org.xml.sax;version="0.0.0" is provided by system bundle. you > dont need to add Require-Bundle: system bundle (OSGi antipatern), just add > import of the package. > > What tool do you use to generate bundle manifest? (Bnd?) The manifest is manually generated. That is the best practice at eclipse. I have issues importing org.xml.sax as explained comment #2: If a different plugin imports org.xml.sax and specifies the version number for the import it will refuse to depend on any jetty bundles because it will be identified as a conflict. (In reply to comment #11) > Created an attachment (id=171141) [details] > sample configuration files currently expected by jetty-osgi > > There are 2 solutions to the issue: > 1- The org.eclipse.jetty.osgi.boot should be installed unzipped. It contains > the configuration files. Really not ideal but at least it works. > I am not sure how to get paxrunner to do that though. > 2- Setup the system property jetty.home and make it point to the jettyhome > folder attached here. > I am not sure how to pass a system property to paxrunner so I did not try that. > 1. installation of bundle as unzipped is out of OSGi spec 2. this is the way to set system property via PaxRunner <param><![CDATA[ --vmOptions=-Dorg.osgi.service.http.port.secure=443 ]]></param> Can Jetty read configuration from URL or file that is embedded into Jar file (not from folder)? > Regarding the original issue: I can add Require-Bundle: system.bundle to > jetty.osgi's Manifest. > I suspect that the execution profile is not passed correctly though. > https://scm.ops4j.org/repos/ops4j/projects/pax/runner/pax-runner-platform/src/main/resources/META-INF/platform/ee/J2SE-1.5.profile > Does declare the org.xml.sax package. this *.profile file contains the list of packages that should be provided by system bundle. But the package could be exported by another bundle. In this case creation of hard link to system bundle is not good idea. (In reply to comment #12) > (In reply to comment #10) > > I tried this parameter -ee=J2SE-1.5 and it did not help. > > > > as you can see org.xml.sax;version="0.0.0" is provided by system bundle. you > > dont need to add Require-Bundle: system bundle (OSGi antipatern), just add > > import of the package. > > > > What tool do you use to generate bundle manifest? (Bnd?) > The manifest is manually generated. That is the best practice at eclipse. > > I have issues importing org.xml.sax as explained comment #2: > If a different plugin imports org.xml.sax and specifies the version number for > the import it will refuse to depend on any jetty bundles because it will be > identified as a conflict. system bundle exports system packages with version "0.0.0". you can import the package with version interval, e.g. "[0.0.0,1.0]" (In reply to comment #13) Ok adding <param>--vmOption=-Djetty.home=jettyhome</param> and it works. (In reply to comment #14) > > the import it will refuse to depend on any jetty bundles because it will be > > identified as a conflict. > > system bundle exports system packages with version "0.0.0". you can import the > package with version interval, e.g. "[0.0.0,1.0]" Yes I agree. It is the same issue than with the Import-Package: org.xml.sax When you don't specify a version you are in fact specifying the version "0.0.0" That version does not mean "any". It means "the one found in the JDK or any". I don't know in advance what versions another bundle would be exporting its org.xml.sax and importing all the packages provided by the execution profile with a range such as [0.0.0,1.0.0]. For example, javax.xml bundle package at eclipse orbit exports org.sax.xml under the version "2.0.2" Given that jetty7 depends on jdk5, we might as well avoid all those problems by not explicitly mentionning that import. I use and test this bundle a lot and until now it is all working fine. I used to test this with felix back in October and that worked as well at the time. I would like to understand why we would need to explicitly import this package now. (In reply to comment #15) > (In reply to comment #13) > Ok adding > <param>--vmOption=-Djetty.home=jettyhome</param> > and it works. > > (In reply to comment #14) > > > the import it will refuse to depend on any jetty bundles because it will be > > > identified as a conflict. > > > > system bundle exports system packages with version "0.0.0". you can import the > > package with version interval, e.g. "[0.0.0,1.0]" > > Yes I agree. It is the same issue than with the Import-Package: org.xml.sax > When you don't specify a version you are in fact specifying the version "0.0.0" > That version does not mean "any". It means "the one found in the JDK or any". > I don't know in advance what versions another bundle would be exporting its > org.xml.sax and importing all the packages provided by the execution profile > with a range such as [0.0.0,1.0.0]. > > For example, javax.xml bundle package at eclipse orbit exports org.sax.xml > under the version "2.0.2" > > Given that jetty7 depends on jdk5, we might as well avoid all those problems by > not explicitly mentionning that import. > I use and test this bundle a lot and until now it is all working fine. > I used to test this with felix back in October and that worked as well at the > time. > > I would like to understand why we would need to explicitly import this package > now. have a look at org.eclipse.jetty.xml_7.1.3.v20100526. it imports the package w/o version and it is resolved correctly. probably you have to import the package the same way. Could you try? (In reply to comment #16) > > > > I would like to understand why we would need to explicitly import this package > > now. > > have a look at org.eclipse.jetty.xml_7.1.3.v20100526. it imports the package > w/o version and it is resolved correctly. > > probably you have to import the package the same way. > > Could you try? Ok if it is there then it is not causing the issue I am describing to my own projects. I'll add it as it is unlikely to cause regressions. Still a mystery why the execution profile is not sufficient when paxrunner setups equinox. Committed with revision 1925. Will be in 7.1.4 Let us know how paxrunner goes Dmytro! |
class org.eclipse.jetty.osgi.boot.internal.webapp.WebappRegistrationHelper imports org.xml.sax.* classes that are not included into MANIFEST.MF Import-Package. org.osgi.framework.BundleException: Exception in org.eclipse.jetty.osgi.boot.JettyBootstrapActivator.start() of bundle org.eclipse.jetty.osgi.boot. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:806) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:352) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:280) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:272) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:253) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:155) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:303) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:288) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:224) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.NoClassDefFoundError: org/xml/sax/SAXException at org.eclipse.jetty.osgi.boot.internal.webapp.JettyContextHandlerServiceTracker.<init>(JettyContextHandlerServiceTracker.java:74) at org.eclipse.jetty.osgi.boot.JettyBootstrapActivator.start(JettyBootstrapActivator.java:92) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774) ... 14 more Caused by: java.lang.ClassNotFoundException: org.xml.sax.SAXException at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:494) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:398) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) ... 19 more