[jira] [Comment Edited] (KARAF-3665) war feature fails when loaded manually (OBR resolution weirdness)

["Simon Kitching (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KARAF-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14494191#comment-14494191 ] 

Simon Kitching edited comment on KARAF-3665 at 4/14/15 3:00 PM:
----------------------------------------------------------------

Problem: in a <feature> definition, some bundles marked with dependency="true" are not being installed even though there is no equivalent bundle currently loaded.

To reproduce:

(a) working case
* install a totally normal servicemix:5.4.0 and start it.
* in console, run "features:list | grep war" and see that the "war" feature has been installed by default
* in console, run "list -s -t 0 | grep xbean" and see that there are some bundles with symname containing "xbean"
* in console, run "exports | grep xbean" and notice that there are some bundles that export org.apache.xbean subpackages

(b) failing case
* stop servicemix
* edit etc/org.apache.karaf.features.cfg and remove all features after "eventadmin", ie no activemq. camel, and particularly no "war" feature
* start karaf with "bin/karaf clean"
* in console, run "features:list | grep war" and see that the "war" feature has NOT been installed by default
* in console, run the "list -s -t 0" and "exports" commands as above, and note that there are no xbean bundles loaded
* in console, run "features:install war" and watch it fail with an unsatisfied dependency on "org.apache.xbean.finder"
* run "list -s -t 0 | grep obr" and then stop the OBR bundle
* run "features:install war" again, and watch it succeed. The "list" and "exports" commands show that xbean bundles have been installed,
  ie it is the OBR service that is preventing the install of these particular bundles for some reason.

The "war" feature depends on "pax-war" which depends on "pax-http" which includes <bundle dependency="true"> .. elements that load the
necessary xbean bundles, including xbean-finder which is needed. However for some reason, the OBR resolver service is suppressing the
loading of this bundle, even though no equivalent bundle exists in the OSGi container - as clearly demonstrated by the resolution failure
that occurs when loading pax-war.

It is strange that the "war" feature works when defined in etc/org.apache.karaf.features.cfg, but not when loaded later..
    
I have turned logging up to DEBUG for all categories, and found nothing useful in the servicemix logfile; it clearly uses maven to look
for and find the xbean bundles at the relevant time (ie finds them under /system), but then the logfiles do not mention the bundles again,
ie they are apparently silently ignored. IMO it would be good for the OBR resolver to LOG when it is ignoring bundles, and why...



was (Author: skitching):
Problem: in a <feature> definition, some bundles marked with dependency="true" are not being installed even though there is no equivalent bundle currently loaded.

To reproduce:
(a) working case
* install a totally normal servicemix:5.4.0 and start it.
* in console, run "features:list | grep war" and see that the "war" feature has been installed by default
* in console, run "list -s -t 0 | grep xbean" and see that there are some bundles with symname containing "xbean"
* in console, run "exports | grep xbean" and notice that there are some bundles that export org.apache.xbean subpackages
(b) failing case
* stop servicemix
* edit etc/org.apache.karaf.features.cfg and remove all features after "eventadmin", ie no activemq. camel, and particularly no "war" feature
* start karaf with "bin/karaf clean"
* in console, run "features:list | grep war" and see that the "war" feature has NOT been installed by default
* in console, run the "list -s -t 0" and "exports" commands as above, and note that there are no xbean bundles loaded
* in console, run "features:install war" and watch it fail with an unsatisfied dependency on "org.apache.xbean.finder"
* run "list -s -t 0 | grep obr" and then stop the OBR bundle
* run "features:install war" again, and watch it succeed. The "list" and "exports" commands show that xbean bundles have been installed,
  ie it is the OBR service that is preventing the install of these particular bundles for some reason.

The "war" feature depends on "pax-war" which depends on "pax-http" which includes <bundle dependency="true"> .. elements that load the
necessary xbean bundles, including xbean-finder which is needed. However for some reason, the OBR resolver service is suppressing the
loading of this bundle, even though no equivalent bundle exists in the OSGi container - as clearly demonstrated by the resolution failure
that occurs when loading pax-war.

It is strange that the "war" feature works when defined in etc/org.apache.karaf.features.cfg, but not when loaded later..
    
I have turned logging up to DEBUG for all categories, and found nothing useful in the servicemix logfile; it clearly uses maven to look
for and find the xbean bundles at the relevant time (ie finds them under /system), but then the logfiles do not mention the bundles again,
ie they are apparently silently ignored. IMO it would be good for the OBR resolver to LOG when it is ignoring bundles, and why...


> war feature fails when loaded manually (OBR resolution weirdness)
> -----------------------------------------------------------------
>
>                 Key: KARAF-3665
>                 URL: https://issues.apache.org/jira/browse/KARAF-3665
>             Project: Karaf
>          Issue Type: Bug
>          Components: karaf-feature
>    Affects Versions: 2.4.1
>            Reporter: Simon Kitching
>
> In servicemix:5.4.0 (including karaf:2.4.1), the "war" feature is by default in etc/org.apache.karaf.features.cfg#featuresBoot and works. However if it is removed from the featuresBoot list, and then later installed from the console a "package resolution" error occurs due to missing org.apache.xbean library - because the OBR resolver mysteriously suppresses installation of it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)