Richard S. Hall wrote: > 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.
Oops, missed that one too! I guess we are encountering all these "bundle 101" issues as we are just beginning to get comfortable with R4. Thanks for the reminder. Rick Litton -----Original Message----- From: Richard S. Hall [mailto:[EMAIL PROTECTED] Sent: Friday, February 09, 2007 11:10 AM To: felix-dev@incubator.apache.org Subject: Re: Another OBR issue 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 >>>>> > >
