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]
