felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard S. Hall <he...@ungoverned.org>
Subject Re: Another OBR issue
Date Thu, 08 Feb 2007 22:26:51 GMT

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:heavy@ungoverned.org]
> 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:heavy@ungoverned.org]
>> 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:seh@panix.com]
>>> Sent: Thursday, February 08, 2007 9:51 AM
>>> To: felix-dev@incubator.apache.org
>>> Subject: Re: Another OBR issue
>>>
>>> Rick Litton <Rick.Litton@ktd-kyocera.com> 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
>>
>


Mime
View raw message