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. ;) 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. 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 >>> >> >
