You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2006/12/01 15:26:07 UTC
Re: Programmatic/non-shell-based interface to OBR
Steven E. Harris wrote:
> As I mentioned, I finished hoisting LocalResourceImpl into my code
> just for the sake of mapping a Bundle to a Resource. I then had to
> edit bundlerepository/pom.xml to export the would-be private
> org.apache.felix.bundlerepository package from the bundlerepository
> bundle.
>
> After all that, I can declare
>
> SUCCESS!
>
Well, that is good news.
> Once the first bundle is installed, I created a LocalResourceImpl
> instance around it. Of course, I'd rather call on some mapping
> function like you suggested to get a Resource from this Bundle. Using
> a ServiceTracker¹, I got ahold of the RepositoryAdmin service, added
> my local repository.xml file, and asked for a Resolver instance.
>
> Next I added my Bundle-based Resource to the Resolver, told it to
> resolve() and, upon success, told it to deploy(). It looks like it
> figures out not to install the original Bundle again, but obviously
> even that is extra work: It would be nice if there was some way to add
> /requirements/ to a Resolver rather than Resources themselves (as in
> this case, I don't want the added Resource to be deployed, as it's
> already installed), but perhaps that's what
> RepositoryAdmin.discoverResources() is for.
>
I am not sure why you want to add requirements or see adding a Resource
to the resolver as extra work. Assuming we had the static method in
question, the solution to your situation would be a process like:
1. Resource localRes = OBR.bundleToResource(bundle);
2. Resolver resolver = repoAdmin.getResolver();
3. resolver.add(localRes);
4. resolver.resolver();
5. resolver.deploy();
This seems pretty simple. How would accessing the requirements make this
any better or simpler?
Or are you worried about making the OBR resolver code simpler? In that
case it doesn't matter because OBR has to deal with the case that some
things might be locally installed no matter what.
> Based on the success here, this process can be made to work, but it's
> a matter of finding the right place to expose this Bundle->Resource
> mapping. Again, I'd prefer that such a mapping be available as part of
> the OSGi OBR API, but for now I'd settle for a
> Felix-specific-but-publicly-exposed solution as well.
>
Ok, thanks for looking into this, when I get the time I will look into
it. I created a JIRA issue to keep track of it.
> Footnotes:
> ¹ Pulling in the org.osgi.compendium bundle has an unfortunate
> dependency on the javax.servlet.http package, though I couldn't
> trace it back to the org.osgi.compendium/pom.xml file.
>
I think this is due to the fact that compendium contains HTTP Service,
which has a dependency on servlet. If you want to avoid that, then you
can create your own tracker JAR that only contains the tracker...this
would be really, really easy to do with the new maven-bundle-plugin.
-> richard
Re: OBR Resource from a Bundle
Posted by "Steven E. Harris" <se...@panix.com>.
"Steven E. Harris" <se...@panix.com> writes:
> Is there some way short of writing another such class to get from a
> Dictionary to a Map?
Oh, maybe copy-construct a new java.util.Hashtable, providing the Map
to the constructor, and taking advantage of Hashtable implementing the
Dictionary interface. Unfortunately, we'd have to copy all the
mappings, rather than just providing an adapted view of them.
--
Steven E. Harris
Re: OBR Resource from a Bundle
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Steven E. Harris wrote:
> "Richard S. Hall" <he...@ungoverned.org> writes:
>
>
>> In truth, we could avoid passing this into the constructor and pass it
>> into the getLibraries() instead, then you wouldn't need it at all,
>> since you don't need to call this method for converting a bundle to a
>> resource.
>>
>
> I just made that change, and only had to correct one constructor call
> and one method call elsewhere.
>
>
>> Admittedly, ManifestParser is still a little bit rough around the
>> edges for this purpose, but it definitely has the basics. It currently
>> has the ability to:
>>
>> * Convert bundle symbolic name and package export to capabilities.
>> * Convert require-bundle and package import to requirements.
>>
>
> That's probably all I need here.
>
> On to the next small problem: ManifestParser wants a java.util.Map as
> its "header map". Bundle.getHeaders() returns a
> java.util.Dictionary. I see that there's a MapToDictionary class in
> Felix already. Is there some way short of writing another such class
> to get from a Dictionary to a Map?
>
> Funny, I see that BundleInfo.getCurrentLocalizedHeader(String) returns
> a Map, which is converted to a Dictionary by Bundle.getHeaders().
>
Yep. We generally only use Map/List, but the OSGi R1 spec stuck us with
Dictionary...perhaps we could make MapToDictionary also implement Map?
-> richard
Re: OBR Resource from a Bundle
Posted by "Steven E. Harris" <se...@panix.com>.
"Richard S. Hall" <he...@ungoverned.org> writes:
> In truth, we could avoid passing this into the constructor and pass it
> into the getLibraries() instead, then you wouldn't need it at all,
> since you don't need to call this method for converting a bundle to a
> resource.
I just made that change, and only had to correct one constructor call
and one method call elsewhere.
> Admittedly, ManifestParser is still a little bit rough around the
> edges for this purpose, but it definitely has the basics. It currently
> has the ability to:
>
> * Convert bundle symbolic name and package export to capabilities.
> * Convert require-bundle and package import to requirements.
That's probably all I need here.
On to the next small problem: ManifestParser wants a java.util.Map as
its "header map". Bundle.getHeaders() returns a
java.util.Dictionary. I see that there's a MapToDictionary class in
Felix already. Is there some way short of writing another such class
to get from a Dictionary to a Map?
Funny, I see that BundleInfo.getCurrentLocalizedHeader(String) returns
a Map, which is converted to a Dictionary by Bundle.getHeaders().
--
Steven E. Harris
Re: OBR Resource from a Bundle
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Steven E. Harris wrote:
> "Richard S. Hall" <he...@ungoverned.org> writes:
>
> Thanks for the suggestions so far.
>
>
>> I think I slightly modified the original OBR interfaces, though, but
>> we can probably deal with that by extending the original interface
>> definitions.
>>
>
> This looks easy to achieve.
>
>
>> Regardless, this means that it may now be possible to use
>> ManifestParser to convert manifests to capabilities/
>> requirements...or at least it will be in the future. So, we have an
>> option now of using the existing OBR approach or adopting the
>> ManifestParser if it will be sufficient (or moving in that direction
>> later if need be).
>>
>
> I started looking into using ManifestParser. A problem arises with the
> ManifestParser constructor. First, I need to get ahold of a
> PropertyResolver instance. The Felix class exposes one with
> getConfig(), but I can't get back "out" to Felix from within one of my
> bundles.
>
> The logger and headerMap parameters are easy enough to provide. If I
> knew how to get a PropertyResolver from within a bundle, I could start
> experimenting with using ManifestParser to write the Bundle->Resource
> conversion function.
>
You don't need to get the PropertyResolver that Felix uses, you can
create your own instance...it is essentially a map. The only thing that
it is used for is to determine that matching set of libraries from the
available libraries. It essentially examines osname and processor to
determine which of the available native code libraries are appropriate
for the current platform.
In truth, we could avoid passing this into the constructor and pass it
into the getLibraries() instead, then you wouldn't need it at all, since
you don't need to call this method for converting a bundle to a
resource. In this case, ManifestParser is also helping out with some
runtime issues. We might find that some of this stuff has to be cleaned
up to some degree.
Admittedly, ManifestParser is still a little bit rough around the edges
for this purpose, but it definitely has the basics. It currently has the
ability to:
* Convert bundle symbolic name and package export to capabilities.
* Convert require-bundle and package import to requirements.
At a minimum, it still needs a mechanism to convert native code headers
to requirements.
-> richard
Re: OBR Resource from a Bundle
Posted by "Steven E. Harris" <se...@panix.com>.
"Richard S. Hall" <he...@ungoverned.org> writes:
Thanks for the suggestions so far.
> I think I slightly modified the original OBR interfaces, though, but
> we can probably deal with that by extending the original interface
> definitions.
This looks easy to achieve.
> Regardless, this means that it may now be possible to use
> ManifestParser to convert manifests to capabilities/
> requirements...or at least it will be in the future. So, we have an
> option now of using the existing OBR approach or adopting the
> ManifestParser if it will be sufficient (or moving in that direction
> later if need be).
I started looking into using ManifestParser. A problem arises with the
ManifestParser constructor. First, I need to get ahold of a
PropertyResolver instance. The Felix class exposes one with
getConfig(), but I can't get back "out" to Felix from within one of my
bundles.
The logger and headerMap parameters are easy enough to provide. If I
knew how to get a PropertyResolver from within a bundle, I could start
experimenting with using ManifestParser to write the Bundle->Resource
conversion function.
--
Steven E. Harris
RE: Another OBR issue
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
Ok will do as suggested. Thanks again!
Rick Litton
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
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: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 <Ri...@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
>>>
>>
>
RE: Another OBR issue
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
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:heavy@ungoverned.org]
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:heavy@ungoverned.org]
> 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: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 <Ri...@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
>>>>>
>
>
Re: Another OBR issue
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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:heavy@ungoverned.org]
> 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: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 <Ri...@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
>>>>>
>
>
RE: Another OBR issue
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
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:heavy@ungoverned.org]
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: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 <Ri...@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
>>>
>>
>
Re: Another OBR issue
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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 <Ri...@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
>>>
>>
>
RE: Another OBR issue
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
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.
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 <Ri...@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
>>
>
Re: Another OBR issue
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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 <Ri...@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
>>
>
RE: Another OBR issue
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
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.
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 <Ri...@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
>
Re: Another OBR issue
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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 <Ri...@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
>
RE: Another OBR issue
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
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:
-> 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 <Ri...@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
Re: Another OBR issue
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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 <Ri...@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
RE: Another OBR issue
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
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.
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 <Ri...@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
Re: Another OBR issue
Posted by "Steven E. Harris" <se...@panix.com>.
Rick Litton <Ri...@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
Another OBR issue
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
Richard,
I'm also currently investigating OBR and encountered a problem when I
try to deploy a bundle:
ShellTui: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.bundlerepository.ResourceImpl.hashCode(ResourceImpl.jav
a:79)
at java.util.HashMap.hash(HashMap.java:261)
at java.util.HashMap.put(HashMap.java:379)
at java.util.HashSet.add(HashSet.java:192)
at
org.apache.felix.bundlerepository.ResolverImpl.resolve(ResolverImpl.java
:219)
at
org.apache.felix.bundlerepository.ResolverImpl.resolve(ResolverImpl.java
:134)
at
org.apache.felix.bundlerepository.ObrCommandImpl._deploy(ObrCommandImpl.
java:322)
at
org.apache.felix.bundlerepository.ObrCommandImpl.deploy(ObrCommandImpl.j
ava:296)
at
org.apache.felix.bundlerepository.ObrCommandImpl.execute(ObrCommandImpl.
java:110)
at
org.apache.felix.shell.impl.Activator$ExecutePrivileged.run(Activator.ja
va:354)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.felix.shell.impl.Activator$ShellServiceImpl.executeCommand(Ac
tivator.java:253)
at
org.apache.felix.shell.tui.Activator$ShellTuiRunnable.run(Activator.java
:167)
at java.lang.Thread.run(Thread.java:534)
Would this indicate a missing dependency? If this is the case, then
perhaps OBR could be enhanced with a better error handling mechanism.
Thanks.
Rick Litton
Re: OBR Resource from a Bundle
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Steven E. Harris wrote:
> "Richard S. Hall" <he...@ungoverned.org> writes:
>
>
>> On the other hand, if you can wait a couple of weeks, then maybe I
>> can clear enough off of my plate to help in the process.
>>
>
> Yes, I can wait, as I decided yesterday to try pursuing the alternate
> path of using a filter to "discover" the target bundle rather than
> trying to work with a Bundle instance already in hand.
>
> Instead of assuming that I have an installed bundle that I'm trying to
> make resolvable by having OBR install its dependencies, I'm assuming I
> have nothing installed and am trying to fetch that target bundle from
> a repository, given its symbolic name. So far this works just as well,
> modulo the start-up discrepancy being discussed in a parallel thread.
>
Cool. I am glad you have at least found a suitable solution for the time
being.
> I see. I'll follow along and help where possible.
Great. Thanks.
-> richard
Re: OBR Resource from a Bundle
Posted by "Steven E. Harris" <se...@panix.com>.
"Richard S. Hall" <he...@ungoverned.org> writes:
> On the other hand, if you can wait a couple of weeks, then maybe I
> can clear enough off of my plate to help in the process.
Yes, I can wait, as I decided yesterday to try pursuing the alternate
path of using a filter to "discover" the target bundle rather than
trying to work with a Bundle instance already in hand.
Instead of assuming that I have an installed bundle that I'm trying to
make resolvable by having OBR install its dependencies, I'm assuming I
have nothing installed and am trying to fetch that target bundle from
a repository, given its symbolic name. So far this works just as well,
modulo the start-up discrepancy being discussed in a parallel thread.
> The main issue here is that we still have a bit of unsettled stuff
> from the transition to using capabilities/requirements in Felix, so
> the main priority in refactoring the code is dealing with those set
> of changes first.
I see. I'll follow along and help where possible.
--
Steven E. Harris
Re: OBR Resource from a Bundle
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Steven,
You raise some good issues...
Unfortunately, I don't have a lot of extra time to investigate this
right now.
If you really need to make progress right now, perhaps the simpler
approach for the time being is just copying ManifestParser into the OBR
subproject and modifying it to use the interfaces defined in OBR, which
should be pretty straightforward.
Then at a later time, we can figure out how to go about combining the
OBR interfaces with the corresponding interfaces in Felix as well as
refactoring the pieces to get it to fit together and eliminate the code
duplication.
On the other hand, if you can wait a couple of weeks, then maybe I can
clear enough off of my plate to help in the process.
The main issue here is that we still have a bit of unsettled stuff from
the transition to using capabilities/requirements in Felix, so the main
priority in refactoring the code is dealing with those set of changes first.
-> richard
Steven E. Harris wrote:
> "Richard S. Hall" <he...@ungoverned.org> writes:
>
>
>> but I would think the way to do it would be to have the OBR bundle
>> export org.apache.felix.bundlerepository.util (perhaps we should
>> also change the OBR package to be org.apache.felix.obr while we are
>> at it), which contained the class that you needed.
>>
>
> Looking closer at this approach, would it harm anything to make the
> constructors for
>
> LocalRepositoryImpl.LocalResourceImpl
>
> have access modifier public instead of package-private?
>
> At present, the only thing that constructs a LocalResourceImpl is
> LocalRepositoryImpl itself. However, if we place the requested
> Bundle->Resource conversion function in a different package
> Bundle->(org.apache.felix.bundlerepository.util), it won't
> be able to call on the LocalRepositoryImpl constructor.
>
>
Re: OBR Resource from a Bundle
Posted by "Steven E. Harris" <se...@panix.com>.
"Richard S. Hall" <he...@ungoverned.org> writes:
> but I would think the way to do it would be to have the OBR bundle
> export org.apache.felix.bundlerepository.util (perhaps we should
> also change the OBR package to be org.apache.felix.obr while we are
> at it), which contained the class that you needed.
Looking closer at this approach, would it harm anything to make the
constructors for
LocalRepositoryImpl.LocalResourceImpl
have access modifier public instead of package-private?
At present, the only thing that constructs a LocalResourceImpl is
LocalRepositoryImpl itself. However, if we place the requested
Bundle->Resource conversion function in a different package
Bundle->(org.apache.felix.bundlerepository.util), it won't
be able to call on the LocalRepositoryImpl constructor.
--
Steven E. Harris
Re: OBR Resource from a Bundle
Posted by "Steven E. Harris" <se...@panix.com>.
"Steven E. Harris" <se...@panix.com> writes:
> I can't just make the org.apache.felix.moduleloader.ICapability
> extend the org.osgi.service.obr.Capability interface
Similarly, org.apache.felix.moduleloader.IRequirement has a method
String getNamespace();
that is not part of org.osgi.service.obr.Requirement, but Requirement
has two methods not part of IRequirement:
String getName();
boolean isExtend();
--
Steven E. Harris
Re: OBR Resource from a Bundle
Posted by "Steven E. Harris" <se...@panix.com>.
"Richard S. Hall" <he...@ungoverned.org> writes:
> As far as pulling the needed bits out and putting them into an OBR
> bundle, that doesn't seem like it should be an issue since maven-
> bundle-plugin can let us pull out specifically what we need and put
> it in the bundle, I would imagine.
I'm not sure if this is what you're referring to here, but I realized
that I can't just make the org.apache.felix.moduleloader.ICapability
extend the org.osgi.service.obr.Capability interface because the OBR
classes are not part of the framework Maven artifact, nor are they a
dependency. We'd have to pull the OBR interfaces out to a separate
artifact, if not bundle, that the framework artifact could rely upon
as part of its compile-time class path. I'm not sure how to do that
from the sidelines.
Perhaps it could work like the interface-only OSGi bundles, such as
org.osgi.core.
--
Steven E. Harris
Re: OBR Resource from a Bundle (was: Programmatic/non-shell-based interface to OBR)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On Feb 6, 2007, at 7:18 PM, Steven E. Harris wrote:
> "Richard S. Hall" <he...@ungoverned.org> writes:
>
>> After talking with Peter Kriens a bit about it, I think when I get
>> the time to work on it, I will just create a OBR-impl-specific
>> package to export.
>
> I'm raising this thread again, in reference to JIRA issue FELIX-178:
>
> http://issues.apache.org/jira/browse/FELIX-178
>
> As more team members join my project, I'm looking to solidify how I'm
> going to move forward with the conversion from a Bundle to an OBR
> Resource.
>
> I have a cobbled-together copy of LocalResourceImpl with a public
> constructor that takes a Bundle as an argument, mostly copied from the
> Felix class LocalRepositoryImpl.LocalResourceImpl. However, it
> requires me to fiddle with the bundlerepository POM's Export-Package
> and Private-Package directives, forcing us all to use in-house builds
> of the Felix bundle.
>
>> The OBR spec is essentially OSGi independent, so it seems to make
>> sense to keep it that way. Even though they will be exposed as
>> OBR-impl packages, you can still use those on other frameworks with
>> other OBR implementations, so it seems reasonable...and with the new
>> bundle plugin, you can easily just extract that package and include
>> it in your own bundle if you want, to make it completely independent
>> of Felix' OBR impl.
>
> I experimented with this today, and found that I also have to drag in
> the kxml2 stuff, or start tailoring my own bundle's dependencies to
> match what would have been bundlerepository's dependencies.
>
> I'd rather put my effort toward actually implementing this capability
> in Felix so that I could contribute the changes and get them rolled
> into the official source tree.
>
> My problem is figuring out where to put the new package and class. We
> need a class because we're talking about what should be a static
> method. It should take a Bundle as an argument and return a
> Resource. The function signature could use all OBR types; nothing
> Felix-specific need be mentioned.
>
> However, the implementation would probably reuse the guts of
> LocalRepositoryImpl.LocalResourceImpl, provided these parsing and
> conversion functions haven't moved into Felix proper with the recent
> filter development.
>
> Again, I'm willing to do the typing and testing, but I need some
> aesthetic direction from those here with the organizational
> vision. Should this new class live under something like
> org.osgi.service.obr.util? Or maybe under something like
> org.apache.felix.bundlerepository.obrext?
>
> We could wander into circular dependencies, too. The interface depends
> upon OBR, but the implementation depends upon the guts of the Felix
> bundlerepository stuff, which in turn depends upon OBR. That makes me
> think that this conversion function belongs with the Felix code, but
> none of those packages are exported at the moment.¹
>
> Your thoughts would be most appreciated.
I would have to look more closely at the code (right now I am away
from my computer), but I would think the way to do it would be to
have the OBR bundle export org.apache.felix.bundlerepository.util
(perhaps we should also change the OBR package to be
org.apache.felix.obr while we are at it), which contained the class
that you needed. If necessary we could move around other pieces of
the OBR impl into that package as well.
The main change I see from the previous thread is now the framework
is actually using capabilities/requirements internally too. I think I
slightly modified the original OBR interfaces, though, but we can
probably deal with that by extending the original interface
definitions. Regardless, this means that it may now be possible to
use ManifestParser to convert manifests to capabilities/
requirements...or at least it will be in the future. So, we have an
option now of using the existing OBR approach or adopting the
ManifestParser if it will be sufficient (or moving in that direction
later if need be).
As far as pulling the needed bits out and putting them into an OBR
bundle, that doesn't seem like it should be an issue since maven-
bundle-plugin can let us pull out specifically what we need and put
it in the bundle, I would imagine.
The only other issue, might be refactoring some of the names of the
classes, since R4Directive, etc. aren't really great names since they
weren't intended to be exposed.
-> richard
OBR Resource from a Bundle (was: Programmatic/non-shell-based interface to OBR)
Posted by "Steven E. Harris" <se...@panix.com>.
"Richard S. Hall" <he...@ungoverned.org> writes:
> After talking with Peter Kriens a bit about it, I think when I get
> the time to work on it, I will just create a OBR-impl-specific
> package to export.
I'm raising this thread again, in reference to JIRA issue FELIX-178:
http://issues.apache.org/jira/browse/FELIX-178
As more team members join my project, I'm looking to solidify how I'm
going to move forward with the conversion from a Bundle to an OBR
Resource.
I have a cobbled-together copy of LocalResourceImpl with a public
constructor that takes a Bundle as an argument, mostly copied from the
Felix class LocalRepositoryImpl.LocalResourceImpl. However, it
requires me to fiddle with the bundlerepository POM's Export-Package
and Private-Package directives, forcing us all to use in-house builds
of the Felix bundle.
> The OBR spec is essentially OSGi independent, so it seems to make
> sense to keep it that way. Even though they will be exposed as
> OBR-impl packages, you can still use those on other frameworks with
> other OBR implementations, so it seems reasonable...and with the new
> bundle plugin, you can easily just extract that package and include
> it in your own bundle if you want, to make it completely independent
> of Felix' OBR impl.
I experimented with this today, and found that I also have to drag in
the kxml2 stuff, or start tailoring my own bundle's dependencies to
match what would have been bundlerepository's dependencies.
I'd rather put my effort toward actually implementing this capability
in Felix so that I could contribute the changes and get them rolled
into the official source tree.
My problem is figuring out where to put the new package and class. We
need a class because we're talking about what should be a static
method. It should take a Bundle as an argument and return a
Resource. The function signature could use all OBR types; nothing
Felix-specific need be mentioned.
However, the implementation would probably reuse the guts of
LocalRepositoryImpl.LocalResourceImpl, provided these parsing and
conversion functions haven't moved into Felix proper with the recent
filter development.
Again, I'm willing to do the typing and testing, but I need some
aesthetic direction from those here with the organizational
vision. Should this new class live under something like
org.osgi.service.obr.util? Or maybe under something like
org.apache.felix.bundlerepository.obrext?
We could wander into circular dependencies, too. The interface depends
upon OBR, but the implementation depends upon the guts of the Felix
bundlerepository stuff, which in turn depends upon OBR. That makes me
think that this conversion function belongs with the Felix code, but
none of those packages are exported at the moment.¹
Your thoughts would be most appreciated.
Footnotes:
¹ http://mail-archives.apache.org/mod_mbox/incubator-felix-dev/200611.mbox/%3c456F37A8.8060909@ungoverned.org%3e
--
Steven E. Harris
Re: Programmatic/non-shell-based interface to OBR
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Steven E. Harris wrote:
> "Richard S. Hall" <he...@ungoverned.org> writes:
>
>
>> I am not sure why you want to add requirements or see adding a
>> Resource to the resolver as extra work.
>>
>
> I meant it's extra work for the resolver, as adding a Resource to the
> Resolver tells it that we need to go find the given Resource, even
> though we know it's already installed.
>
Ok, now I understand what you are saying, but as I said, it really isn't
extra work since the OBR code has to be able to deal with resources
being locally installed anyway. That is why OBR has the LocalRepository
and LocalResource in the first place, because it has to be able to treat
locally installed stuff as resources and the deploy() algorithm has to
deal with the fact that things that it might want to deploy could
already be installed (either the correct or incorrect version).
> Please let me know if I can help. As I'm new to Felix, I don't yet
> feel qualified to decide /where/ this capability should be
> implemented. However, I could probably help implement it.
>
After talking with Peter Kriens a bit about it, I think when I get the
time to work on it, I will just create a OBR-impl-specific package to
export. The OBR spec is essentially OSGi independent, so it seems to
make sense to keep it that way. Even though they will be exposed as
OBR-impl packages, you can still use those on other frameworks with
other OBR implementations, so it seems reasonable...and with the new
bundle plugin, you can easily just extract that package and include it
in your own bundle if you want, to make it completely independent of
Felix' OBR impl.
Thanks.
-> richard
Re: Programmatic/non-shell-based interface to OBR
Posted by "Steven E. Harris" <se...@panix.com>.
"Richard S. Hall" <he...@ungoverned.org> writes:
> I am not sure why you want to add requirements or see adding a
> Resource to the resolver as extra work.
I meant it's extra work for the resolver, as adding a Resource to the
Resolver tells it that we need to go find the given Resource, even
though we know it's already installed.
> Assuming we had the static method in question, the solution to your
> situation would be a process like:
>
> 1. Resource localRes = OBR.bundleToResource(bundle);
> 2. Resolver resolver = repoAdmin.getResolver();
> 3. resolver.add(localRes);
> 4. resolver.resolver();
> 5. resolver.deploy();
>
> This seems pretty simple. How would accessing the requirements make
> this any better or simpler?
It wouldn't make it easier for the user, but it might make it easier
for the OBR code. By analogy, if I buy a kit to make cookies, go home,
and open the kit and discover that it calls for butter and sugar, I
might send someone out to the grocery store with the shopping list:
o butter
o sugar
I don't send the person to the store with a shopping list like:
o cookie kit
o butter
o sugar
(but call me first to see if I have any of these things)
or even:
o cookie kit
(everything required by cookie kit)
(but call me first to see if I have any of these things)
because I already have the first item. I don't want my shopper going
and looking for the cookie kit, or even calling me about it; it's
known to be a settled item from the start.
The difference between the two shopping lists maps to the difference
between RepositoryAdmin.discoverResources() and Resolver.add(). The
former deals only with requirements, while the second deals with
specific Resources and, as a side effect, with their transitive
requirements.
> Or are you worried about making the OBR resolver code simpler?
If not making the code simpler, asking it to do less on my behalf.
> In that case it doesn't matter because OBR has to deal with the case
> that some things might be locally installed no matter what.
I see.
> Ok, thanks for looking into this, when I get the time I will look into
> it.
Please let me know if I can help. As I'm new to Felix, I don't yet
feel qualified to decide /where/ this capability should be
implemented. However, I could probably help implement it.
> I created a JIRA issue to keep track of it.
Thanks.¹
Footnotes:
¹ https://issues.apache.org/jira/browse/FELIX-178
--
Steven E. Harris
Re[2]: Creating bundles using subsets of other bundles' code
Posted by Peter Kriens <Pe...@aQute.biz>.
>> in my pom.xml file, I see that all of the org.osgi.util.tracker
>> package gets copied into my bundle.² But what if this package makes
>> use of other packages for implementation that would normally be
>> specified in a Private-Package declaration? Will the Bundle Plugin
>> know to include these in my bundle?
After creating the content of the JAR, bnd will calculate all the
referred classes from this content. It will then remove any private
packages and will then create an import statement for the remainder.
So you will -not- get any automatic includes of imports. However, if
you find that you have an unwanted imported, just add it to your
Private-Package list.
Kind regards,
Peter Kriens
RSH> Steven E. Harris wrote:
>> "Steven E. Harris" <se...@panix.com> writes:
>>
>>
>>> Would this mean creating a Maven project in my own source tree and
>>> pointing it at the tracker code, requesting the appropriate packages
>>> for export?
>>>
>>
>> I figured it out. It's explained in the "Real-World Example" section
>> of the "Bundle Plugin for Maven" documentation.¹ What's not obvious is
>> whether the plugin automatically includes any dependencies of the
>> exported "borrowed" package. That is, when I write
>>
>> <Export-Package>org.osgi.util.tracker[,...]</Export-Package>
>>
>> in my pom.xml file, I see that all of the org.osgi.util.tracker
>> package gets copied into my bundle.² But what if this package makes
>> use of other packages for implementation that would normally be
>> specified in a Private-Package declaration? Will the Bundle Plugin
>> know to include these in my bundle?
>>
RSH> Good question, I don't know how BND handles that, but I am sure Peter
RSH> knows... :-)
>> I must say this whole approach of borrowing parts of other bundles
>> makes me uneasy. Isn't it possible that these individual class files
>> may rely on other resources being present in the bundle? Is a package
>> name really sufficient to capture the cohesive set of resources?
>>
RSH> That is why you have testing, etc. It doesn't make sense that you would
RSH> do this and just release it without any understanding of what the
RSH> requirements and constraints are for the packages you are borrowing.
RSH> Since the stuff we are talking about here is open source, you can easily
RSH> look at see what you should be getting or ask the community around the
RSH> project what is necessary.
RSH> The plugin enables this type of approach, but it doesn't require it
RSH> anyway. So, you are still free to use the same old method. However, for
RSH> me it doesn't make sense, for example, to have a dependency on the
RSH> entire OSGi compendium for our simple Log Service bundle, since we can
RSH> easily include the log package in the bundle itself. The plugin makes
RSH> this approach easy and doesn't require that I re-package the log package
RSH> separately or copy the source files into the Log Service project.
RSH> So, follow whichever approach that makes you feel comfortable.
->> richard
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Creating bundles using subsets of other bundles' code
Posted by "Steven E. Harris" <se...@panix.com>.
"Richard S. Hall" <he...@ungoverned.org> writes:
> The plugin enables this type of approach, but it doesn't require it
> anyway.
[...]
> The plugin makes this approach easy and doesn't require that I
> re-package the log package separately or copy the source files into
> the Log Service project.
True, and it's impressive. I'm raising these issues mostly because I'm
still in search of understanding the best (or at least recommended)
ways to tie these bundles together.
--
Steven E. Harris
Re: Creating bundles using subsets of other bundles' code
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Steven E. Harris wrote:
> "Steven E. Harris" <se...@panix.com> writes:
>
>
>> Would this mean creating a Maven project in my own source tree and
>> pointing it at the tracker code, requesting the appropriate packages
>> for export?
>>
>
> I figured it out. It's explained in the "Real-World Example" section
> of the "Bundle Plugin for Maven" documentation.¹ What's not obvious is
> whether the plugin automatically includes any dependencies of the
> exported "borrowed" package. That is, when I write
>
> <Export-Package>org.osgi.util.tracker[,...]</Export-Package>
>
> in my pom.xml file, I see that all of the org.osgi.util.tracker
> package gets copied into my bundle.² But what if this package makes
> use of other packages for implementation that would normally be
> specified in a Private-Package declaration? Will the Bundle Plugin
> know to include these in my bundle?
>
Good question, I don't know how BND handles that, but I am sure Peter
knows... :-)
> I must say this whole approach of borrowing parts of other bundles
> makes me uneasy. Isn't it possible that these individual class files
> may rely on other resources being present in the bundle? Is a package
> name really sufficient to capture the cohesive set of resources?
>
That is why you have testing, etc. It doesn't make sense that you would
do this and just release it without any understanding of what the
requirements and constraints are for the packages you are borrowing.
Since the stuff we are talking about here is open source, you can easily
look at see what you should be getting or ask the community around the
project what is necessary.
The plugin enables this type of approach, but it doesn't require it
anyway. So, you are still free to use the same old method. However, for
me it doesn't make sense, for example, to have a dependency on the
entire OSGi compendium for our simple Log Service bundle, since we can
easily include the log package in the bundle itself. The plugin makes
this approach easy and doesn't require that I re-package the log package
separately or copy the source files into the Log Service project.
So, follow whichever approach that makes you feel comfortable.
-> richard
Re: Creating bundles using subsets of other bundles' code
Posted by "Steven E. Harris" <se...@panix.com>.
"Steven E. Harris" <se...@panix.com> writes:
> Would this mean creating a Maven project in my own source tree and
> pointing it at the tracker code, requesting the appropriate packages
> for export?
I figured it out. It's explained in the "Real-World Example" section
of the "Bundle Plugin for Maven" documentation.¹ What's not obvious is
whether the plugin automatically includes any dependencies of the
exported "borrowed" package. That is, when I write
<Export-Package>org.osgi.util.tracker[,...]</Export-Package>
in my pom.xml file, I see that all of the org.osgi.util.tracker
package gets copied into my bundle.² But what if this package makes
use of other packages for implementation that would normally be
specified in a Private-Package declaration? Will the Bundle Plugin
know to include these in my bundle?
I must say this whole approach of borrowing parts of other bundles
makes me uneasy. Isn't it possible that these individual class files
may rely on other resources being present in the bundle? Is a package
name really sufficient to capture the cohesive set of resources?
Footnotes:
¹ http://cwiki.apache.org/FELIX/bundle-plugin-for-maven-bnd.html
² That is, so long as the dependency on the org.osgi.compendium
artifact does not have "provided" scope.
--
Steven E. Harris
Creating bundles using subsets of other bundles' code (was: Programmatic/non-shell-based interface to OBR)
Posted by "Steven E. Harris" <se...@panix.com>.
"Richard S. Hall" <he...@ungoverned.org> writes:
> I think this is due to the fact that compendium contains HTTP Service,
> which has a dependency on servlet. If you want to avoid that, then you
> can create your own tracker JAR that only contains the tracker...this
> would be really, really easy to do with the new maven-bundle-plugin.
Some hints would be welcome. Would this mean creating a Maven project
in my own source tree and pointing it at the tracker code, requesting
the appropriate packages for export? I'm not sure how to do this.
--
Steven E. Harris
Re: Programmatic/non-shell-based interface to OBR
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Steven E. Harris wrote:
> "Richard S. Hall" <he...@ungoverned.org> writes:
>
>
>> I think this is due to the fact that compendium contains HTTP
>> Service, which has a dependency on servlet.
>>
>
> That's unfortunate, as there's a lot of stuff in the compendium that
> could be useful in a standalone or client application that would have
> nothing to do with Servlets. I'd rather not be forced to deploy unused
> dependencies.
>
Which is precisely why I am fond of the new plugins ability to grab a
package for me. :-)
-> richard
> Would it be possible for the dependency on the javax.servlet package
> to be dynamic (DynamicImport-Package)? At present the
> org.osgi.compendium's bundle has a DynamicImport-Package value of "*".
>
>
Re: Programmatic/non-shell-based interface to OBR
Posted by "Steven E. Harris" <se...@panix.com>.
"Richard S. Hall" <he...@ungoverned.org> writes:
> I think this is due to the fact that compendium contains HTTP
> Service, which has a dependency on servlet.
That's unfortunate, as there's a lot of stuff in the compendium that
could be useful in a standalone or client application that would have
nothing to do with Servlets. I'd rather not be forced to deploy unused
dependencies.
Would it be possible for the dependency on the javax.servlet package
to be dynamic (DynamicImport-Package)? At present the
org.osgi.compendium's bundle has a DynamicImport-Package value of "*".
--
Steven E. Harris