ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Pauls <karlpa...@gmail.com>
Subject Re: Gateway error when updating
Date Mon, 08 Nov 2010 20:49:05 GMT
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
<angelo.vandersijpt@luminis.eu> 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 <
>> angelo.vandersijpt@luminis.eu> 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
karlpauls@gmail.com

Mime
View raw message