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).
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. 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] >
