Mailing-List: contact ace-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ace-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <AANLkTik741A2Xse0S1o2TpCL1_Mx2RA4BqO-R0rs=E8f@mail.gmail.com>
References: <AANLkTinSBq=KmJ++JEPwqPhZZjAzkS81iW5DBG5Ted3h@mail.gmail.com>
 <0AE91550-9F80-4DDD-A627-8690AD48A47B@luminis.eu>
 <AANLkTikQmM7bKS00dNkMAAniOxBv5PoUgOGuL4KnkomU@mail.gmail.com>
 <9C8F4F13-B3E0-4CDA-B485-F605975530DF@luminis.eu>
 <AANLkTik741A2Xse0S1o2TpCL1_Mx2RA4BqO-R0rs=E8f@mail.gmail.com>
From: Stephen Brady <stephen@bitlev.com>
Date: Mon, 8 Nov 2010 12:57:00 -0800
Message-ID: <AANLkTin=RCx7M8W2oeEKXh5sTR+WbSyQdkMNAgMryhVi@mail.gmail.com>
Subject: Re: Gateway error when updating
To: ace-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=001636285138c82161049490dea4

--001636285138c82161049490dea4
Content-Type: text/plain; charset=ISO-8859-1

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

--001636285138c82161049490dea4--