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:47:48 GMT

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:heavy@ungoverned.org]
> 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: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