You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aries.apache.org by Paul F Fraser <pa...@a2zliving.com> on 2015/10/05 12:07:07 UTC
More on subsystem install failures
All of my declarative services component bundles built using bndtools 3 in eclipse Mars fail to install.
Bundles which do not use DS intall OK.
I have tried adding the
Require-Capability:
osgi.extender;filter:="(&(osgi.extender=osgi.service.component)(version>=1.2.0)(!(version>=2.0.0)))"
to the bnd .bnd file but did not make any difference.
The error, which has been discussed in earlier messages is as follows:-
org.osgi.service.subsystem.SubsystemException: A required content resource could not be found. This
means the resource was either missing or not recognized as a supported resource format due to, for
example, an invalid bundle manifest or blueprint XML file. Turn on debug logging for more
information. The resource was: org.apache.aries.subsystem.core.archive.SubsystemContentRequirement:
namespace=osgi.identity, attributes={},
directives={filter=(&(osgi.identity=co.diderot.staticresources)(type=osgi.bundle)(&(version>=0.0.3)(!(version>=0.0.4))))},
resource=org.apache.aries.subsystem.core.internal.SubsystemResource@dd888a4e
Is there anything about DS that could cause this to occur? There is some mention a few years ago in
bug reports about ds causing problems.
I am fairly confident that I am covering the dependencies in the subsystem manifest.
If there is not a known reason why this might be happening I will try to put together a simple example.
Regards
Paul Fraser
Re: More on subsystem install failures
Posted by John Ross <jw...@gmail.com>.
I don't see how the issue you are encountering is related to DS. The
issue is that you've declared that a subsystem has a content resource
that cannot be found in one of the repositories. Be sure that a bundle
with symbolic name co.diderot.staticresources and version in the range
[0.0.3,0.0.4) is available. You can try packaging the bundle in the
subsystem archive to see if that works.
On Mon, Oct 5, 2015 at 5:07 AM, Paul F Fraser <pa...@a2zliving.com> wrote:
> All of my declarative services component bundles built using bndtools 3 in
> eclipse Mars fail to install.
> Bundles which do not use DS intall OK.
>
> I have tried adding the
> Require-Capability:
> osgi.extender;filter:="(&(osgi.extender=osgi.service.component)(version>=1.2.0)(!(version>=2.0.0)))"
> to the bnd .bnd file but did not make any difference.
>
> The error, which has been discussed in earlier messages is as follows:-
>
> org.osgi.service.subsystem.SubsystemException: A required content resource
> could not be found. This means the resource was either missing or not
> recognized as a supported resource format due to, for example, an invalid
> bundle manifest or blueprint XML file. Turn on debug logging for more
> information. The resource was:
> org.apache.aries.subsystem.core.archive.SubsystemContentRequirement:
> namespace=osgi.identity, attributes={},
> directives={filter=(&(osgi.identity=co.diderot.staticresources)(type=osgi.bundle)(&(version>=0.0.3)(!(version>=0.0.4))))},
> resource=org.apache.aries.subsystem.core.internal.SubsystemResource@dd888a4e
>
> Is there anything about DS that could cause this to occur? There is some
> mention a few years ago in bug reports about ds causing problems.
> I am fairly confident that I am covering the dependencies in the subsystem
> manifest.
>
> If there is not a known reason why this might be happening I will try to put
> together a simple example.
>
> Regards
>
> Paul Fraser
Re: More on subsystem install failures
Posted by John Ross <jw...@gmail.com>.
I know next to nothing about Felix OBR and the index file. However, I
do notice that you are using "version" rather than "bundle-version"
for the co.diderot.staticresources bundle. If this means OBR is
defaulting that bundle to version 0.0.0, that would explain why the
content cannot be found.
On Mon, Oct 5, 2015 at 7:42 AM, Paul F Fraser <pa...@a2zliving.com> wrote:
> Thanks, John & David,
>
> On 5/10/2015 10:58 PM, John Ross wrote:
>>
>> In the meantime, you could try packaging that bundle as part of
>> the subsystem archive, which should lead to the use of other
>> requirement classes that do override toString, for the purposes of
>> identifying the issue.
>>
> I will check this out.
>
> Does this excerpt from the repo index.xml give any clue?
>
> <resource>
> <capability namespace="osgi.identity">
> <attribute name="osgi.identity" value="co.diderot.staticresources"/>
> <attribute name="type" value="osgi.bundle"/>
> <attribute name="version" type="Version" value="0.0.3.201510050448"/>
> </capability>
> <capability namespace="osgi.content">
> <attribute name="osgi.content"
> value="351db26a839939b414c59a2a1bc2aeeeebe1a060ab7c9a69f4a0a7036ed846cd"/>
> <attribute name="url" value="co.diderot.staticresources-0.0.3.jar"/>
> <attribute name="size" type="Long" value="7481"/>
> <attribute name="mime" value="application/vnd.osgi.bundle"/>
> </capability>
> <capability namespace="osgi.wiring.bundle">
> <attribute name="osgi.wiring.bundle"
> value="co.diderot.staticresources"/>
> <attribute name="bundle-version" type="Version"
> value="0.0.3.201510050448"/>
> </capability>
> <capability namespace="osgi.wiring.host">
> <attribute name="osgi.wiring.host"
> value="co.diderot.staticresources"/>
> <attribute name="bundle-version" type="Version"
> value="0.0.3.201510050448"/>
> </capability>
> <capability namespace="osgi.wiring.package">
> <attribute name="osgi.wiring.package"
> value="co.diderot.staticresources"/>
> <attribute name="version" type="Version" value="0.0.1"/>
> <attribute name="bundle-symbolic-name"
> value="co.diderot.staticresources"/>
> <attribute name="bundle-version" type="Version"
> value="0.0.3.201510050448"/>
> <directive name="uses"
> value="javax.servlet.http,org.osgi.framework,org.osgi.service.component,org.osgi.service.http"/>
> </capability>
> <capability namespace="osgi.service">
> <attribute name="objectClass" type="List<String>"
> value="co.diderot.staticresources.StaticResources"/>
> <directive name="uses" value="co.diderot.staticresources"/>
> </capability>
> <requirement namespace="osgi.wiring.package">
> <directive name="filter"
> value="(&(osgi.wiring.package=co.diderot.logging)(version>=0.0.0)(!(version>=1.0.0)))"/>
> </requirement>
> <requirement namespace="osgi.wiring.package">
> <directive name="filter"
> value="(&(osgi.wiring.package=javax.servlet.http)(version>=3.0.0)(!(version>=4.0.0)))"/>
> </requirement>
> <requirement namespace="osgi.wiring.package">
> <directive name="filter"
> value="(&(osgi.wiring.package=org.osgi.framework)(version>=1.8.0)(!(version>=2.0.0)))"/>
> </requirement>
> <requirement namespace="osgi.wiring.package">
> <directive name="filter"
> value="(&(osgi.wiring.package=org.osgi.service.component)(version>=1.2.0)(!(version>=2.0.0)))"/>
> </requirement>
> <requirement namespace="osgi.wiring.package">
> <directive name="filter"
> value="(&(osgi.wiring.package=org.osgi.service.http)(version>=1.2.0)(!(version>=2.0.0)))"/>
> </requirement>
> <requirement namespace="osgi.extender">
> <directive name="filter"
> value="(&(osgi.extender=osgi.service.component)(version>=1.2.0)(!(version>=2.0.0)))"/>
> </requirement>
> <requirement namespace="osgi.ee">
> <directive name="filter"
> value="(&(osgi.ee=JavaSE)(version=1.8))"/>
> </requirement>
> <requirement namespace="osgi.service">
> <directive name="filter"
> value="(objectClass=org.osgi.service.http.HttpService)"/>
> <directive name="effective" value="active"/>
> </requirement>
> <requirement namespace="osgi.extender">
> <directive name="filter"
> value="(&(osgi.extender=osgi.ds)(version>=1.1.0)(!(version>=2.0.0)))"/>
> <directive name="effective" value="active"/>
> </requirement>
> </resource>
>
>
> The felix jetty http bundle covers the javax and http service requirement.
>
> Paul
Re: More on subsystem install failures
Posted by Paul F Fraser <pa...@a2zliving.com>.
Thanks, John & David,
On 5/10/2015 10:58 PM, John Ross wrote:
> In the meantime, you could try packaging that bundle as part of
> the subsystem archive, which should lead to the use of other
> requirement classes that do override toString, for the purposes of
> identifying the issue.
>
I will check this out.
Does this excerpt from the repo index.xml give any clue?
<resource>
<capability namespace="osgi.identity">
<attribute name="osgi.identity" value="co.diderot.staticresources"/>
<attribute name="type" value="osgi.bundle"/>
<attribute name="version" type="Version" value="0.0.3.201510050448"/>
</capability>
<capability namespace="osgi.content">
<attribute name="osgi.content"
value="351db26a839939b414c59a2a1bc2aeeeebe1a060ab7c9a69f4a0a7036ed846cd"/>
<attribute name="url" value="co.diderot.staticresources-0.0.3.jar"/>
<attribute name="size" type="Long" value="7481"/>
<attribute name="mime" value="application/vnd.osgi.bundle"/>
</capability>
<capability namespace="osgi.wiring.bundle">
<attribute name="osgi.wiring.bundle" value="co.diderot.staticresources"/>
<attribute name="bundle-version" type="Version" value="0.0.3.201510050448"/>
</capability>
<capability namespace="osgi.wiring.host">
<attribute name="osgi.wiring.host" value="co.diderot.staticresources"/>
<attribute name="bundle-version" type="Version" value="0.0.3.201510050448"/>
</capability>
<capability namespace="osgi.wiring.package">
<attribute name="osgi.wiring.package" value="co.diderot.staticresources"/>
<attribute name="version" type="Version" value="0.0.1"/>
<attribute name="bundle-symbolic-name" value="co.diderot.staticresources"/>
<attribute name="bundle-version" type="Version" value="0.0.3.201510050448"/>
<directive name="uses"
value="javax.servlet.http,org.osgi.framework,org.osgi.service.component,org.osgi.service.http"/>
</capability>
<capability namespace="osgi.service">
<attribute name="objectClass" type="List<String>"
value="co.diderot.staticresources.StaticResources"/>
<directive name="uses" value="co.diderot.staticresources"/>
</capability>
<requirement namespace="osgi.wiring.package">
<directive name="filter"
value="(&(osgi.wiring.package=co.diderot.logging)(version>=0.0.0)(!(version>=1.0.0)))"/>
</requirement>
<requirement namespace="osgi.wiring.package">
<directive name="filter"
value="(&(osgi.wiring.package=javax.servlet.http)(version>=3.0.0)(!(version>=4.0.0)))"/>
</requirement>
<requirement namespace="osgi.wiring.package">
<directive name="filter"
value="(&(osgi.wiring.package=org.osgi.framework)(version>=1.8.0)(!(version>=2.0.0)))"/>
</requirement>
<requirement namespace="osgi.wiring.package">
<directive name="filter"
value="(&(osgi.wiring.package=org.osgi.service.component)(version>=1.2.0)(!(version>=2.0.0)))"/>
</requirement>
<requirement namespace="osgi.wiring.package">
<directive name="filter"
value="(&(osgi.wiring.package=org.osgi.service.http)(version>=1.2.0)(!(version>=2.0.0)))"/>
</requirement>
<requirement namespace="osgi.extender">
<directive name="filter"
value="(&(osgi.extender=osgi.service.component)(version>=1.2.0)(!(version>=2.0.0)))"/>
</requirement>
<requirement namespace="osgi.ee">
<directive name="filter" value="(&(osgi.ee=JavaSE)(version=1.8))"/>
</requirement>
<requirement namespace="osgi.service">
<directive name="filter" value="(objectClass=org.osgi.service.http.HttpService)"/>
<directive name="effective" value="active"/>
</requirement>
<requirement namespace="osgi.extender">
<directive name="filter"
value="(&(osgi.extender=osgi.ds)(version>=1.1.0)(!(version>=2.0.0)))"/>
<directive name="effective" value="active"/>
</requirement>
</resource>
The felix jetty http bundle covers the javax and http service requirement.
Paul
Re: More on subsystem install failures
Posted by John Ross <jw...@gmail.com>.
The bundle with symbolic name co.diderot.staticresources and version
0.0.3.201510050448 has an unsatisfied requirement that needs to be
identified. Unfortunately,
org.apache.felix.bundlerepository.impl.FelixRequirementAdapter does
not appear to override toString. We can look at updating Aries
Subsystems to print out the requirement details itself rather than
relying on toString. Feel free to open a JIRA if that's important to
you. In the meantime, you could try packaging that bundle as part of
the subsystem archive, which should lead to the use of other
requirement classes that do override toString, for the purposes of
identifying the issue.
[1] https://issues.apache.org/jira/browse/ARIES
On Mon, Oct 5, 2015 at 6:23 AM, Paul F Fraser <pa...@a2zliving.com> wrote:
> On 5/10/2015 9:18 PM, David Bosschaert wrote:
>>
>> Looks like something in the subsystem depends on the bundle:
>> co.diderot.staticresources version 0.0.3
>>
>> Cheers,
>>
>> David
>>
>> On 5 October 2015 at 11:07, Paul F Fraser <pa...@a2zliving.com> wrote:
>>
> Hi David,
>
> After reindexing the repository :( , I got this error
>
> org.osgi.service.subsystem.SubsystemException:
> org.osgi.service.resolver.ResolutionException: Unable to resolve
> co.diderot.staticresources;0.0.3.201510050448;osgi.bundle: missing
> requirement
> org.apache.felix.bundlerepository.impl.FelixRequirementAdapter@93c4d234
>
> Which tells me nothing.
>
> This is all there is in the manifest. The bundle works fine in a bndtools
> run.runbnd setup.
>
> Subsystem-SymbolicName: co.diderot.vaadin.feature
> Subsystem-Version: 1.0.0
> Subsystem-Type: osgi.subsystem.feature
> Subsystem-Content: co.diderot.staticresources;version="[0.0.3,0.0.4)",
> org.apache.felix.http.bundle;version=2.3.2
>
> I will try to re-create the problem with a simple example.
>
> Paul
Re: More on subsystem install failures
Posted by Paul F Fraser <pa...@a2zliving.com>.
On 5/10/2015 9:18 PM, David Bosschaert wrote:
> Looks like something in the subsystem depends on the bundle:
> co.diderot.staticresources version 0.0.3
>
> Cheers,
>
> David
>
> On 5 October 2015 at 11:07, Paul F Fraser <pa...@a2zliving.com> wrote:
>
Hi David,
After reindexing the repository :( , I got this error
org.osgi.service.subsystem.SubsystemException: org.osgi.service.resolver.ResolutionException: Unable
to resolve co.diderot.staticresources;0.0.3.201510050448;osgi.bundle: missing requirement
org.apache.felix.bundlerepository.impl.FelixRequirementAdapter@93c4d234
Which tells me nothing.
This is all there is in the manifest. The bundle works fine in a bndtools run.runbnd setup.
Subsystem-SymbolicName: co.diderot.vaadin.feature
Subsystem-Version: 1.0.0
Subsystem-Type: osgi.subsystem.feature
Subsystem-Content: co.diderot.staticresources;version="[0.0.3,0.0.4)",
org.apache.felix.http.bundle;version=2.3.2
I will try to re-create the problem with a simple example.
Paul
Re: More on subsystem install failures
Posted by David Bosschaert <da...@gmail.com>.
Looks like something in the subsystem depends on the bundle:
co.diderot.staticresources version 0.0.3
Cheers,
David
On 5 October 2015 at 11:07, Paul F Fraser <pa...@a2zliving.com> wrote:
> All of my declarative services component bundles built using bndtools 3 in
> eclipse Mars fail to install.
> Bundles which do not use DS intall OK.
>
> I have tried adding the
> Require-Capability:
> osgi.extender;filter:="(&(osgi.extender=osgi.service.component)(version>=1.2.0)(!(version>=2.0.0)))"
> to the bnd .bnd file but did not make any difference.
>
> The error, which has been discussed in earlier messages is as follows:-
>
> org.osgi.service.subsystem.SubsystemException: A required content resource
> could not be found. This means the resource was either missing or not
> recognized as a supported resource format due to, for example, an invalid
> bundle manifest or blueprint XML file. Turn on debug logging for more
> information. The resource was:
> org.apache.aries.subsystem.core.archive.SubsystemContentRequirement:
> namespace=osgi.identity, attributes={},
> directives={filter=(&(osgi.identity=co.diderot.staticresources)(type=osgi.bundle)(&(version>=0.0.3)(!(version>=0.0.4))))},
> resource=org.apache.aries.subsystem.core.internal.SubsystemResource@dd888a4e
>
> Is there anything about DS that could cause this to occur? There is some
> mention a few years ago in bug reports about ds causing problems.
> I am fairly confident that I am covering the dependencies in the subsystem
> manifest.
>
> If there is not a known reason why this might be happening I will try to put
> together a simple example.
>
> Regards
>
> Paul Fraser