Rick Litton wrote:
Richard S. Hall wrote:
Make sure that all of your locally installed bundles
have symbolic names.
Yes it now works! The only "gotcha" I noticed was that modifying the
version number of a package (Export-Package header) would not be
reflected in the bundle by simply using the "obr deploy" command. I had
to uninstall/install the bundle instead. Otherwise, the OBR commands I
tested executed as advertised. ;)
If I understand, you are saying that you updated the version of an
exported package, but not the version of bundle itself. If so, you are
correct, OBR would not recognize that as a change. It only looks at
symbolic name + bundle version as a unique identifier, so if it finds
it, it thinks it is done.
I also noticed that the Bundle-SymbolicName header is mandatory per the
R4 specs. I'm now wondering why this was not caught earlier in the
bundle lifecycle. And since bindex used the bundle name as the symbolic
name, I assumed that the bundle manifest was entirely valid. Thanks to
you and Steven for helping sort this out.
Well, R3 bundles are still allowed to not have a symbolic name...if you
try to install an R4 bundle without one, you should get an install error.
-> richard
Rick Litton
-----Original Message-----
From: Richard S. Hall [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 08, 2007 2:48 PM
To: felix-dev@incubator.apache.org
Subject: Re: Another OBR issue
On Feb 8, 2007, at 5:41 PM, Rick Litton wrote:
Richard S. Hall wrote:
How did you generate the XML? Did you use bindex? Maybe it
automatically adds the symbolic name.
Yes, that's also right. The bindex tool generated the repository.xml
and added the missing info, as shown in this xml fragment:
<capability name='bundle'>
<p n='manifestversion' v='1'/>
<p n='presentationname' v='Framework Data Source'/>
<p n='symbolicname' v='Framework Data Source'/>
<p n='version' t='version' v='1.1.0'/>
</capability>
Unfortunately, what is happening is the bundle that is failing with
the
NPE is also described in the same way:
<capability name='bundle'>
<p n='manifestversion' v='1'/>
<p n='presentationname' v='Framework Plugin'/>
<p n='symbolicname' v='Framework Plugin'/>
<p n='version' t='version' v='1.1.1'/>
</capability>
What I can determine by reading through the repository.xml is that a
couple of "requires" for the second bundle were either missing or
deprecated. However, I'm not certain if this is the source of the
problem. Also, could you confirm if packages referenced from the
classpath through the system bundle are "safely" visible to OBR and
resolved successfully? These packages would of course appear in a
"require" tag as well yet they are not exported by any bundle.
OBR converts every locally installed bundle into a Resource, including
the system bundle. Make sure that all of your locally installed bundles
have symbolic names. If they do, then we will have to track it
down...perhaps you can send me a URL to your repo and the steps to
reproduce the exception (or some sort of tar ball off line).
-> richard
Rick Litton
-----Original Message-----
From: Richard S. Hall [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 08, 2007 2:27 PM
To: felix-dev@incubator.apache.org
Subject: Re: Another OBR issue
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
