[
https://issues.apache.org/jira/browse/KARAF-7779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787204#comment-17787204
]
ASF subversion and git services commented on KARAF-7779:
--------------------------------------------------------
Commit c0d6cbd3f158e96ba77382c0f307353052bcb50c in karaf's branch
refs/heads/karaf-4.4.x from JB Onofré
[ https://gitbox.apache.org/repos/asf?p=karaf.git;h=c0d6cbd3f1 ]
Merge pull request #1790 from grgrzybek/KARAF-7779
[KARAF-7779] Fix deployment scenario where feature has a fragment for…
> Problem installing feature with fragment bundle for existing host bundle
> ------------------------------------------------------------------------
>
> Key: KARAF-7779
> URL: https://issues.apache.org/jira/browse/KARAF-7779
> Project: Karaf
> Issue Type: Bug
> Components: karaf
> Affects Versions: 4.4.4
> Reporter: Grzegorz Grzybek
> Assignee: Grzegorz Grzybek
> Priority: Major
> Fix For: 4.5.0, 4.4.5, 4.3.11
>
>
> In my custom Karaf distro with custom KAR which uses Pax Web and fragment
> bundles (for javax-el-api), I had this problem:
> {noformat}
> java.lang.IllegalStateException: Resource has no uri
> at
> org.apache.karaf.features.internal.service.Deployer.getBundleInputStream(Deployer.java:1631)
> at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:904)
> ...
> {noformat}
> After quite complex investigation I was able to prepare a Karaf test case and
> the problem can be described like this:
> * we install a feature which contains fragment bundle which can be attached
> to already existing bundle
> * Karaf resolver/deployer treats already installed bundles as BundleRevisions
> (without {{osgi.content}} namespaced capabilities. {{url}} is part of Bundle
> capabilities only
> * during resolver procedure, I had this:
> {noformat}
> {org.apache.felix.framework.BundleRevisionImpl@7703}
> "org.apache.servicemix.specs.javax-el-api-3.0.0 [39](R 39.0)" ->
> {java.util.ArrayList@11407} size = 3
> key: org.apache.felix.framework.BundleRevisionImpl =
> {org.apache.felix.framework.BundleRevisionImpl@7703}
> "org.apache.servicemix.specs.javax-el-api-3.0.0 [39](R 39.0)"
> value: java.util.ArrayList = {java.util.ArrayList@11407} size = 3
> 0 = {org.apache.felix.resolver.WireImpl@11791}
> "[org.apache.servicemix.specs.javax-el-api-3.0.0 [39](R 39.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.6.0)(!(version>=2.0.0)))
> -> [org.apache.felix.framework [0](R 0)]"
> 1 = {org.apache.felix.resolver.WireImpl@11792}
> "[org.apache.servicemix.specs.javax-el-api-3.0.0 [39](R 39.0)] osgi.ee;
> (&(osgi.ee=JavaSE)(version=1.7)) -> [org.apache.felix.framework [0](R 0)]"
> 2 = {org.apache.felix.resolver.WireImpl@9972}
> "[org.jboss.fuse.modules.fuse-el2-compatibility/7.12.1.fuse-7_12_1-00009-redhat-00001]
> osgi.identity; osgi.identity="root#pax-web-jsp-8.0.23";
> type=karaf.subsystem; version="[0,0.0.0]"; resolution:=mandatory ->
> [root#pax-web-jsp-8.0.23]"
> {noformat}
> which means that the fragment added a wire to the host bundle. The wire ties
> the BundleRevision resource to feature's subsystem, effectively marking
> already existing BundleRevision as a resource to install.
> The problem is that there's no {{osgi.content; url=xxx}} capability inside
> existing BundleRevision.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
