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