On Feb 8, 2007, at 5:13 PM, Rick Litton wrote:
Richard S. Hall wrote:
Are you saying that your bundle's manifest does not contain a symbolic
name and the one shown below is given by default?
Yes, that's correct. Here is a portion of the manifest:
Bundle-Name: Framework Data Source
Bundle-Description: Data Source Layer.
Bundle-Version: 1.1
Bundle-Activator: com....framework.ds.Activator
Bundle-ClassPath: .
Export-Package: ...
Import-Package: ...
I was just hoping that the exception from OBR will be able describe
what
dependency failed to resolve so that the appropriate action can be
taken. I will also try to insert some code to make this happen as
well.
What is the scenario that is happening when you do see the exception?
It possible, as Steven suggested, that this could be related to whether
the metadata is coming from XML or the manifest. For example, if you
have a bundle installed locally without a bundle symbolic name, then
when this is converted into a resource, it won't have a symbolic name,
which could cause the NPE.
How did you generate the XML? Did you use bindex? Maybe it
automatically adds the symbolic name.
Just some thoughts.
-> richard
Thanks in advance.
Rick Litton
-----Original Message-----
From: Richard S. Hall [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 08, 2007 2:04 PM
To: felix-dev@incubator.apache.org
Subject: Re: Another OBR issue
On Feb 8, 2007, at 3:09 PM, Rick Litton wrote:
Richard S. Hall wrote:
I don't think so. OBR requires a bundle symbolic name, because this
plus version is a unique identifier.
Hmmm. I wonder how this worked:
Are you saying that your bundle's manifest does not contain a symbolic
name and the one shown below is given by default?
I don't recall doing it that way, but anything is possible...it has
been a long time since I worked on OBR. The last time I saw this bug,
though, I am fairly certain it was because there was no symbolic name.
I will try to take a closer look at it and see if I can see what is
going on.
-> richard
-> obr info "Framework Data Source"
---------------------
Framework Data Source
---------------------
description: Data Source Layer.
documentation: file:../temp/repository.xml
id: 1
license: file:../temp/repository.xml
presentationname: Framework Data Source
size: 7783
source: file:../temp/repository.xml
symbolicname: Framework Data Source
url: file:../temp/Build/bundles/fwk-ds.jar
version: 1.1.0
...
-> obr deploy "Framework Data Source"
Target resource(s):
-------------------
Framework Data Source (1.1.0)
Deploying...done.
Rick Litton
-----Original Message-----
From: Richard S. Hall [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 08, 2007 12:02 PM
To: felix-dev@incubator.apache.org
Subject: Re: Another OBR issue
On Feb 8, 2007, at 1:18 PM, Rick Litton wrote:
Steven wrote:
It looks like either the symbolic name or the version are nil. I
haven't been able to track down all the ways this could be so.
Looking at the output from obr info, the repository.xml generated by
bindex shows that the Bundle-Name has been used as a substitute
when the
Bundle-SymbolicName descriptor is missing from the manifest. Hence
my
guess is that the obr deploy command fails with an NPE only when
dependencies are not satisfied.
I don't think so. OBR requires a bundle symbolic name, because this
plus version is a unique identifier.
-> richard
Rick Litton
-----Original Message-----
From: Steven E. Harris [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 08, 2007 9:51 AM
To: felix-dev@incubator.apache.org
Subject: Re: Another OBR issue
Rick Litton <[EMAIL PROTECTED]> writes:
java.lang.NullPointerException
at
org.apache.felix.bundlerepository.ResourceImpl.hashCode
(ResourceImpl.jav
a:79)
,----[ ResourceImpl.hashCode source ]
| public int hashCode()
| {
| return getSymbolicName().hashCode() ^ getVersion().hashCode();
| }
`----
It looks like either the symbolic name or the version are nil. I
haven't been able to track down all the ways this could be so. Do you
know if the ResourceImpl here is a LocalResourceImpl, or one created
by RepositoryImpl's parsing of an XML file?
--
Steven E. Harris
