Niclas, You are of course correct, I guess I didn't explain the issue properly. Its really an issue with the bundle plugin works. When this line was present in the bnd file, (I'm guessing because it didn't find the Activator class in the project), the plugin generates an import statement this package. I'd imagine if the class was present in the project, private or otherwise, it would not bother. So to get this component to deploy correctly I need to remove the Activator statement from the bnd file. Sorry for the confusion.
Steve ________________________________________ From: [email protected] [[email protected]] On Behalf Of Niclas Hedhman (JIRA) [[email protected]] Sent: Friday, September 25, 2009 9:09 PM To: [email protected] Subject: [issues] Commented: (PAXWEB-169) Using Pax Web in Karaf, bug fix and features.xml [ http://issues.ops4j.org/browse/PAXWEB-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983#action_12983 ] Niclas Hedhman commented on PAXWEB-169: --------------------------------------- Which bundle was trying to use the .internal package? You explain it was due to a missing Activator, but assume for a second that the private Activator really existed, would that still be a problem? The reason I ask; The OSGi spec was really clear in that Activator can (even should) be private packaged. If Felix+Karaf combination requires it to be in a public package, you will cause a lot of problems in the OSGi world. > Using Pax Web in Karaf, bug fix and features.xml > ------------------------------------------------ > > Key: PAXWEB-169 > URL: http://issues.ops4j.org/browse/PAXWEB-169 > Project: Pax Web > Issue Type: Bug > Components: War Extender > Affects Versions: 0.7.0 > Reporter: Steve Gargan > Assignee: Alin Dreghiciu > Priority: Minor > Fix For: 0.8.0 > > Attachments: patch > > > Hi, > I was having some issues deploying Pax web (both the 0.7.0 and > 0.7.1-SNAPSHOT) versions to karaf (1.1.0-SNAPSHOT), so I took the liberty of > modifying some of the modules to get them to work. I've also created a couple > of features to ease deploying all the Pax web components and some of the > samples. The fixes and features are contained in the attached patch. > To explain the issues I was seeing; First off I was getting an unresolved > constraint problem deploying the spi bundle. It looks for the internal > package 'org.ops4j.pax.web.service.spi.internal' > org.osgi.framework.BundleException: Unresolved constraint in bundle > org.ops4j.pax.web.pax-web-spi [78]: package; > (&(package=org.ops4j.pax.web.service.spi.internal)(version>=0.7.0)) > at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3268) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1596) > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:890) > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:877) > at > org.apache.felix.karaf.shell.osgi.StartBundle.doExecute(StartBundle.java:29) > at > org.apache.felix.karaf.shell.osgi.BundlesCommand.doExecute(BundlesCommand.java:49) > at > org.apache.felix.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:41) > at > org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:34) > at > org.apache.felix.gogo.runtime.shell.CommandProxy.execute(CommandProxy.java:45) > at org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:211) > at > org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.java:146) > at org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:91) > at org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:75) > at > org.apache.felix.gogo.runtime.shell.CommandSessionImpl.execute(CommandSessionImpl.java:71) > at > org.apache.felix.karaf.shell.console.jline.Console.run(Console.java:115) > at java.lang.Thread.run(Thread.java:619) > From what I can tell this is being caused by the inclusion of the Activator > clause in the bnd file, which doesn't seem to exist. > Bundle-Activator:\ > ${bundle.namespace}.internal.Activator > I removed this statement and rebuilt and it then deployed fine. I guess this > activator got ditched at some stage. > The runtime module seemed to be missing import statements for the spi > packages. This caused a class cast exception to be thrown when it tried to > cast the jetty service to > org.ops4j.pax.web.service.spi.ServerControllerFactory. I added them to the > osgi.bnd and it started correctly. > Finally, through my own misunderstanding I deployed a war without an OSGI > manifest and without using the war url protocol. This caused a null pointer > exception generating the webapp context as neither the Webapp-Context or > symbolic name headers were present. I added a quick check for this situation > and veto starting the war bundle unless one or the other is present. > Finally, I put together (shamelessly ripping off the feature generation from > camel) a couple of features.xml files to ease the deployment to Karaf. One > feature contains the combinations of pax web components and the other allows > some of the samples to be easily installed. I copied the war project and set > it up to build with an explicit manifest to test the war extender fix. > To use the features you can enter the following at the karaf console > features:refreshUrl > mvn:org.ops4j.pax.web.platforms/karaf/0.7.1-SNAPSHOT/xml/features > features:refreshUrl > mvn:org.ops4j.pax.web.platforms/samples/0.7.1-SNAPSHOT/xml/features > Hope this helps. Thanks for the great kit! > Steve -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.ops4j.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
