ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <marcel.offerm...@luminis.nl>
Subject Re: Gateway error when updating
Date Tue, 09 Nov 2010 09:32:19 GMT
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 <karlpauls@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
>>>> <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