You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ace.apache.org by Stephen Brady <st...@bitlev.com> on 2010/11/05 04:02:36 UTC
Gateway error when updating
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)
Re: Gateway error when updating
Posted by Marcel Offermans <ma...@luminis.nl>.
On 8 Nov 2010, at 22:08 , Angelo van der Sijpt wrote:
> 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?)
I have not looked at the problem in detail, but could this be a case where the bundle's manifest is not the first thing in the jar file, causing the call to getBundle() to ultimately fail? I guess having such an offending bundle would reveal that.
Greetings, Marcel
Re: Gateway error when updating
Posted by Marcel Offermans <ma...@luminis.nl>.
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 <
> angelo.vandersijpt@luminis.eu> 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 <ka...@gmail.com> 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
>>>> <an...@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
>>>>
>>
>>
Re: Gateway error when updating
Posted by Stephen Brady <st...@bitlev.com>.
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 <
angelo.vandersijpt@luminis.eu> 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 <ka...@gmail.com> 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
> >> <an...@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
> >>
>
>
Re: Gateway error when updating
Posted by Angelo van der Sijpt <an...@luminis.eu>.
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 <ka...@gmail.com> 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
>> <an...@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
>>
Re: Gateway error when updating
Posted by Stephen Brady <st...@bitlev.com>.
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 <ka...@gmail.com> 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
> <an...@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
>
Re: Gateway error when updating
Posted by Karl Pauls <ka...@gmail.com>.
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
<an...@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
Re: Gateway error when updating
Posted by Angelo van der Sijpt <an...@luminis.eu>.
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)
>>
>>
Re: Gateway error when updating
Posted by Stephen Brady <st...@bitlev.com>.
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)
>
>
Re: Gateway error when updating
Posted by Angelo van der Sijpt <an...@luminis.eu>.
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)