Hello Stephen, I don't see anything strange in this manifest to be honest. Is it possible to send us this bundle so we can have a look? It probably makes sense to open up a JIRA issue and attach it to that.
Greetings, Marcel On 8 Nov 2010, at 23:29 , Stephen Brady wrote: > Yes...and in this case, the manifest is the first file in the jar. > > > > Manifest-Version: 1.0 > Ant-Version: Apache Ant 1.6.5 > Created-By: 1.5.0_14-b03 (Sun Microsystems Inc.) > Main-Class: org.restlet.Component > Bundle-ManifestVersion: 2 > Bundle-Name: Restlet API > Bundle-SymbolicName: org.restlet > Bundle-Version: 2.0.0.m7 > Bundle-Vendor: Noelios Technologies > Export-Package: org.restlet; uses:="org.restlet.routing, org.restlet. > service, org.restlet.data, org.restlet.representation, org.restlet > .security, org.restlet.util",org.restlet.data; uses:="org.restlet.re > source, org.restlet.representation, org.restlet.util, org.restlet, > org.restlet.service, org.restlet.security",org.restlet.engine; use > s:="org.restlet.engine.log, org.restlet, org.restlet.engine.securit > y, org.restlet.util, org.restlet.routing, org.restlet.service, or > g.restlet.data, org.restlet.engine.converter",org.restlet.engine.app > lication; uses:="org.restlet.routing, org.restlet.service, org.rest > let.data, org.restlet.representation, org.restlet.util, org.restle > t, org.restlet.engine",org.restlet.engine.component; uses:="org.rest > let.routing, org.restlet.resource, org.restlet.representation, org > .restlet, org.restlet.engine",org.restlet.engine.converter; uses:="o > rg.restlet.resource, org.restlet.engine.resource, org.restlet.repre > sentation, org.restlet.engine",org.restlet.engine.http; uses:="org.r > estlet.representation, org.restlet, org.restlet.util, org.restlet. > engine.http.adapter, org.restlet.engine, org.restlet.data",org.rest > let.engine.http.adapter; uses:="org.restlet.data, org.restlet.engine > .http, org.restlet, org.restlet.util",org.restlet.engine.http.conne > ctor; uses:="org.restlet.representation, org.restlet, org.restlet.u > til, org.restlet.engine, javax.net, org.restlet.data",org.restlet. > engine.http.header; uses:="org.restlet.data, org.restlet.representat > ion, org.restlet, org.restlet.util",org.restlet.engine.http.io;uses > :="org.restlet.representation,org.restlet.util",org.restlet.engine.ht > tp.security; uses:="org.restlet.data, org.restlet.engine.http.header > , org.restlet.engine.security, org.restlet.util, org.restlet",org. > restlet.engine.internal;uses:="org.osgi.framework",org.restlet.engine > .io;uses:="org.restlet.data,org.restlet.representation",org.restlet.e > ngine.local; uses:="org.restlet.service, org.restlet.data, org.rest > let.resource, org.restlet.representation, org.restlet, org.restlet > .engine",org.restlet.engine.log;uses:="org.restlet.routing,org.restle > t.service,org.restlet",org.restlet.engine.resource;uses:="org.restlet > .service,org.restlet.data,org.restlet.representation",org.restlet.eng > ine.riap;uses:="org.restlet,org.restlet.engine",org.restlet.engine.se > curity; uses:="org.restlet.data, org.restlet.engine.http.header, or > g.restlet.security, javax.net.ssl, org.restlet.util, org.restlet, > org.restlet.engine",org.restlet.engine.util; uses:="org.restlet.repr > esentation, org.restlet, org.restlet.util, org.xml.sax, org.restl > et.service, org.w3c.dom.ls, org.restlet.data, org.xml.sax.helpers" > ,org.restlet.representation;uses:="org.restlet.data,org.restlet.util" > ,org.restlet.resource; uses:="org.restlet.service, org.restlet.data, > org.restlet.representation, org.restlet.util, org.restlet",org.re > stlet.routing; uses:="org.restlet.data, org.restlet.resource, org.r > estlet.representation, org.restlet.util, org.restlet",org.restlet.s > ecurity; uses:="org.restlet.routing, org.restlet.data, org.restlet. > util, org.restlet",org.restlet.service; uses:="org.restlet.routing, > org.restlet.data, org.restlet.resource, org.restlet.representation > , org.restlet",org.restlet.util; uses:="org.restlet.routing, org.re > stlet.data, org.restlet.representation, org.restlet" > Import-Package: javax.net,javax.net.ssl,javax.xml.parsers,org.osgi.fra > mework > Bundle-RequiredExecutionEnvironment: J2SE-1.5 > Bundle-Activator: org.restlet.engine.internal.Activator > Class-Path: > > Name: org.restlet > Implementation-Title: org.restlet > Implementation-Version: 2.0 Milestone 7 (build 0) > Implementation-Vendor: Noelios Technologies > > > > On Mon, Nov 8, 2010 at 1:08 PM, Angelo van der Sijpt < > [email protected]> wrote: > >> Hi, >> >> On Nov 8, 2010, at 9:57 PM, Stephen Brady wrote: >> >>> To clarify, the specific bundles that I've tested with all have proper >>> symbolic names in the manifest, and still getBundle is encountering null >>> symbolic names. I only referenced the possibility of a given bundle not >>> having a bundle symbolic name as something potentially to catch before >>> getting to getBundle (if this is not already being done). >> >> Hm, that's interesting. Could you post the manifest of one of the offending >> bundles, given that you can pinpoint one?) >> >>> >>> By uncommit, I meant that I take away the distribution that I committed >> in >>> the prior step. In other words, I create a distro which generates >> version >>> 1. I "save" it from the Web interface, which prompts the failed Gateway >>> deployment that I referenced. I unlink that distro from the Gateway >> target >>> and save that one, which prompts a increment to the version counter to 2. >>> Version 2 properly "deploys" (even though it contains no bundles) on the >>> Gateway--no error on the Gateway side is flagged. Hope that makes sense. >> >> Okay, just to be sure. >> >> Angelo >> >>> >>> >>> On Mon, Nov 8, 2010 at 12:49 PM, Karl Pauls <[email protected]> wrote: >>> >>>> R3 doesn't require a symbolic-name. It was added in R4. >>>> >>>> regards, >>>> >>>> Karl >>>> >>>> On Mon, Nov 8, 2010 at 9:45 PM, Angelo van der Sijpt >>>> <[email protected]> wrote: >>>>> Okay, good to hear you got it to work. The symbolic name is a required >>>> property for R4 bundles, I'm not sure for R3. Was it your intention to >>>> deploy an R3 bundle? >>>>> >>>>> In the Deployment Admin specification (compendium 4.2, 114.3.4.7), we >>>> find >>>>> "If the bundle resource has no Bundle-SymbolicName header, the given >>>> symbolic name must be used to calculate the location of the bundle." >>>>> So, I agree that this is a bug in deployment admin. Can you file a bug >>>> with Deployment Admin in the Felix project? >>>>> >>>>> I don't understand what you mean by 'uncommit' a distribution; do you >>>> mean removing _all_ bundles from the gateway? >>>>> >>>>> Angelo >>>>> >>>>> >>>>> On Nov 8, 2010, at 9:06 PM, Stephen Brady wrote: >>>>> >>>>>> I've figured out an immediate fix and maybe revealed a bug (don't know >>>>>> enough about ACE to call it a bug). It seems it's failing at line 115 >>>> at >>>>>> org.apache.felix.deploymentadmin.abstractdeploymentpackage.getBundle >>>>>> because it's not gracefully handling null symbolic names. I've >> filtered >>>> out >>>>>> the nulls, which at least allowed me to get ACE working. I don't know >>>>>> Felix-ACE internals well enough to understand whether this fix is >>>>>> sustainable/reliable. For example, not sure what happens if a given >>>> bundle >>>>>> added to the repository has an improper manifest with no symbolic >> name. >>>>>> Perhaps someone can root cause what's going on here? Does getBundle >>>> need >>>>>> to handle these nulls more gracefully or should it not be getting any >>>> nulls >>>>>> to begin with further upstream? >>>>>> >>>>>> Angelo, to answer your questions. What you see with the first six >>>>>> deployments in that readout is just earlier attempts to push different >>>>>> distributions. When I would try and commit a new distribution, the >>>> Gateway >>>>>> would fail to pull down the associated bundles (the stack trace I sent >>>>>> earlier). I would then "uncommit" that distribution, upping the >> version >>>>>> number again, and the Gateway would then readout OK since no bundles >>>> needed >>>>>> to be pulled down. >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Nov 5, 2010 at 7:28 AM, Angelo van der Sijpt < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Stephen, >>>>>>> >>>>>>> Without knowing what exactly runs in your framework, it's a bit hard >> to >>>>>>> know what exactly is happening. Still, it should be very well >> possible >>>> to >>>>>>> use your own framework, and drop the right bundles and configuration >>>> into >>>>>>> it. >>>>>>> >>>>>>> Could you give a little more info on what you're doing? For instance, >>>> how >>>>>>> were you possible to make the first six deployments? Have you >> included >>>>>>> specific new bundles in your latest deployment? >>>>>>> >>>>>>> Angelo >>>>>>> >>>>>>> >>>>>>> On Nov 4, 2010, at 11:02 PM, Stephen Brady wrote: >>>>>>> >>>>>>>> I get the following stack trace on the Gateway after committing a >>>> change >>>>>>> on >>>>>>>> the Server webui. >>>>>>>> >>>>>>>> Stepping back, I'm trying to deploy the Gateway bundles in my own >>>> Felix >>>>>>>> 2.0.5-based osgi framework (which is closely modeled off of >> Intalio's >>>>>>> Jetty >>>>>>>> embedded in Felix distro). I've had no problems running the ACE >>>> gateway >>>>>>>> going the pax route. However, I'm not terribly familiar with pax, >> so >>>> I'm >>>>>>>> not 100% clear what kind of setup/config it's doing. But as far as >> I >>>> can >>>>>>>> tell, I've made the appropriate configuration additions/changes in >> my >>>>>>> osgi >>>>>>>> framework to handle the ACE gateway so I'm at a loss now. >>>>>>>> >>>>>>>> Thanks for the help! This is a great project. >>>>>>>> >>>>>>>> >>>>>>>> [Info ] [ ] Highest remote: 7.0.0 / Highest local: 6.0.0 >>>>>>>> [Info ] [ ] Installing version: 7.0.0 >>>>>>>> [Error] [ ] Error installing update >>>>>>>> java.lang.NullPointerException >>>>>>>> at >>>>>>>> >>>>>>> >>>> >> org.apache.felix.deploymentadmin.AbstractDeploymentPackage.getBundle(AbstractDeploymentPackage.java:115) >>>>>>>> at >>>>>>>> >>>>>>> >>>> >> org.apache.felix.deploymentadmin.spi.UpdateCommand.execute(UpdateCommand.java:70) >>>>>>>> at >>>>>>>> >>>>>>> >>>> >> org.apache.felix.deploymentadmin.spi.DeploymentSessionImpl.call(DeploymentSessionImpl.java:74) >>>>>>>> at >>>>>>>> >>>>>>> >>>> >> org.apache.felix.deploymentadmin.DeploymentAdminImpl.installDeploymentPackage(DeploymentAdminImpl.java:215) >>>>>>>> at >>>>>>>> >>>>>>> >>>> >> org.apache.ace.deployment.deploymentadmin.DeploymentAdminDeployer.install(DeploymentAdminDeployer.java:51) >>>>>>>> at >>>>>>>> >>>>>>> >>>> >> org.apache.ace.deployment.task.DeploymentTaskBase.installVersion(DeploymentTaskBase.java:75) >>>>>>>> at >>>>>>>> >>>>>>> >>>> >> org.apache.ace.deployment.task.DeploymentUpdateTask.run(DeploymentUpdateTask.java:57) >>>>>>>> at org.apache.ace.scheduler.Executer.run(Executer.java:92) >>>>>>>> at java.util.TimerThread.mainLoop(Unknown Source) >>>>>>>> at java.util.TimerThread.run(Unknown Source) >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Karl Pauls >>>> [email protected] >>>> >> >>
