[jira] [Commented] (ARIES-1443) After a restart the capabilities of a subsystem have changed (seem correct) before the restart they seem wrong
[ https://issues.apache.org/jira/browse/ARIES-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15415951#comment-15415951 ] Bas commented on ARIES-1443: ARIES-1444 also describes similar funny stuff. Because of time pressure I didn't retest ARIES-1444 with a newer version of equinox (resolver). But reverting this change won't solve the problem because after a restart the same behavior surfaces again. So then make the behavior consistent and remove the sharing of capabilities also after a restart. This should solve the issues also after a restart. > After a restart the capabilities of a subsystem have changed (seem correct) > before the restart they seem wrong > -- > > Key: ARIES-1443 > URL: https://issues.apache.org/jira/browse/ARIES-1443 > Project: Aries > Issue Type: Bug > Components: Subsystem >Affects Versions: subsystem-2.0.6, subsystem-2.0.8 > Environment: karaf pax-exam >Reporter: Bas >Assignee: John Ross > Labels: test-patch > Fix For: subsystem-2.1.0 > > Attachments: CapabilitiesDifferOnRestart.java.patch, > pax-web-jetty-bundle-4.2.5.jar > > > A feature subsystem should export all capabilities of its constituents and it > does not do that after a fresh install. After a restart of the subsystem core > bundle it will export all the capabilities. > These seems to be a difference in parsing the capabilities of a persisted > subsystem and a new subsystem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1443) After a restart the capabilities of a subsystem have changed (seem correct) before the restart they seem wrong
[ https://issues.apache.org/jira/browse/ARIES-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15415850#comment-15415850 ] John Ross commented on ARIES-1443: -- I'm not sure all of the funny stuff going on in ARIES-1588, ARIES-1590, and ARIES-1591 are entirely due to this change (i.e. exposing feature capabilities at resolution time), but they may be. This defect noted how feature capabilities are not exposed (none except osgi.identity, that is) after installing a feature until you restart the framework. I agree with the premise that the inconsistency is confusing and ideally should not exist. This could mean either features never expose more than the osgi.identity capability or always expose all capabilities. We seem to be in a bit of a bind because either solution causes issues. I'm pretty sure that if we remove the exposure of all capabilities permanently, it will cause some tests to fail, including in the CT. This should be confirmed, however. Always exposing capabilities are associated with the previously mentioned defects. Perhaps the best course of action would be to live with the inconsistency for now, assuming rolling this back would in fact fix those issues. > After a restart the capabilities of a subsystem have changed (seem correct) > before the restart they seem wrong > -- > > Key: ARIES-1443 > URL: https://issues.apache.org/jira/browse/ARIES-1443 > Project: Aries > Issue Type: Bug > Components: Subsystem >Affects Versions: subsystem-2.0.6, subsystem-2.0.8 > Environment: karaf pax-exam >Reporter: Bas >Assignee: John Ross > Labels: test-patch > Fix For: subsystem-2.1.0 > > Attachments: CapabilitiesDifferOnRestart.java.patch, > pax-web-jetty-bundle-4.2.5.jar > > > A feature subsystem should export all capabilities of its constituents and it > does not do that after a fresh install. After a restart of the subsystem core > bundle it will export all the capabilities. > These seems to be a difference in parsing the capabilities of a persisted > subsystem and a new subsystem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1590) Subsystem install fails due to unexpected resolve conflict
[
https://issues.apache.org/jira/browse/ARIES-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15415822#comment-15415822
]
John Ross commented on ARIES-1590:
--
I've been taking a look at this. Not sure what's going on yet. In my
environment, I'm seeing other issues. For example, when I started out using a
Java 7 VM, I was getting a stack overflow from java.util.regex when installing
reproduce-base-subsystem-4.1.2-SNAPSHOT.esa. I then noticed that
reproduce-subsystem-4.1.2-SNAPSHOT.esa was failing to install because it
required Java 8. So I switched to that and am, for now, ignoring the stack
overflow, which does not occur on 8. I don't know what happens with
reproduce-base-subsystem-4.1.2-SNAPSHOT.esa on 8 yet because I have not yet had
the patience to let it run to completion. It apparently takes an eternity to
install. I'll try bringing in the performance improvement from ARIES-1565 and
see what happens.
> Subsystem install fails due to unexpected resolve conflict
> --
>
> Key: ARIES-1590
> URL: https://issues.apache.org/jira/browse/ARIES-1590
> Project: Aries
> Issue Type: Bug
> Components: Subsystem
>Reporter: Tom De Wolf
>Priority: Blocker
> Fix For: subsystem-2.1.0
>
> Attachments: reproduce-base-subsystem-4.1.2-SNAPSHOT.esa,
> reproduce-subsystem-4.1.2-SNAPSHOT.esa
>
>
> When we use the 2.0.9-SNAPSHOT version currently in development we get an
> unexpected resolve conflict:
> {panel}
> DEBUG: Candidate permutation failed due to a conflict between imports; will
> try another if possible. (org.osgi.service.resolver.ResolutionException: Uses
> constraint violation. Unable to resolve resource
> org.apache.servicemix.bundles.spring-core [116.0] because it is exposed to
> package 'org.aspectj.bridge' from resources
> com.reproduce.reproduce-base-subsystem
> [org.apache.aries.subsystem.core.internal.BasicSubsystem: children=0,
> constituents=60, id=3,
> location=file:///Users/tom/Documents/code/aca-common/osgi-subsystem-support/reproduce-base-subsystem/target/reproduce-base-subsystem-4.1.2-SNAPSHOT.esa,
> parents=1, state=INSTALLED,
> symbolicName=com.reproduce.reproduce-base-subsystem,
> type=osgi.subsystem.feature, version=4.1.2.SNAPSHOT] and
> org.apache.servicemix.bundles.aspectj [111.0] via two dependency chains.
> Chain 1:
> org.apache.servicemix.bundles.spring-core [116.0]
> import:
> (&(osgi.wiring.package=org.aspectj.bridge)(version>=1.7.1)(!(version>=2.0.0)))
> |
> export: osgi.wiring.package: org.aspectj.bridge
> com.reproduce.reproduce-base-subsystem
> [org.apache.aries.subsystem.core.internal.BasicSubsystem: children=0,
> constituents=60, id=3,
> location=file:///Users/tom/Documents/code/aca-common/osgi-subsystem-support/reproduce-base-subsystem/target/reproduce-base-subsystem-4.1.2-SNAPSHOT.esa,
> parents=1, state=INSTALLED,
> symbolicName=com.reproduce.reproduce-base-subsystem,
> type=osgi.subsystem.feature, version=4.1.2.SNAPSHOT]
> Chain 2:
> org.apache.servicemix.bundles.spring-core [116.0]
> import:
> (&(osgi.wiring.package=org.aspectj.weaver)(version>=1.7.1)(!(version>=2.0.0)))
> |
> export: osgi.wiring.package=org.aspectj.weaver;
> uses:=org.aspectj.weaver.patterns
> com.reproduce.reproduce-base-subsystem
> [org.apache.aries.subsystem.core.internal.BasicSubsystem: children=0,
> constituents=60, id=3,
> location=file:///Users/tom/Documents/code/aca-common/osgi-subsystem-support/reproduce-base-subsystem/target/reproduce-base-subsystem-4.1.2-SNAPSHOT.esa,
> parents=1, state=INSTALLED,
> symbolicName=com.reproduce.reproduce-base-subsystem,
> type=osgi.subsystem.feature, version=4.1.2.SNAPSHOT]
> import:
> (&(osgi.wiring.package=org.aspectj.weaver.patterns)(&(version>=1.7.1)(!(version>=2.0.0
> |
> export: osgi.wiring.package: org.aspectj.weaver.patterns;
> uses:=org.aspectj.bridge
> export: osgi.wiring.package=org.aspectj.bridge
> org.apache.servicemix.bundles.aspectj [111.0])
> {panel}
> It is unexpected because 1 of the 2 chains points to the actual bundle that
> exports the package and the other of the 2 chains points to the base
> subsystem already installed in the runtime. In fact the bundle is part of
> that subsystem so it should consider both as exactly the same and not
> consider it as 2 chains he cannot resolve.
> Not sure if it is related to ARIES-1588 and the commit mentioned there but
> that commit does affect how already installed subsystems are taken into
> account in the resolve process.
> Note: we are using the felix resolver 1.4.0, verified it has the same problem
> with 1.8.0
> Steps to reproduce:
> 1. start clean felix
> 2. install the attached reproduce-base-subsystem-4.1.2-SNAPSHOT.esa, do not
> start it
> 3. install the attached
[jira] [Comment Edited] (ARIES-1591) Subsystem install fails due to ArrayIndexOutofBoundsException
[
https://issues.apache.org/jira/browse/ARIES-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413033#comment-15413033
]
Tom De Wolf edited comment on ARIES-1591 at 8/10/16 7:17 AM:
-
[~jwr...@us.ibm.com] When I try this setup with felix resolver 1.8 I already
get problems when installing the reproduce-base-subsystem in step 2. These
problems are however different but related to the fragment's host
(pax-web-jetty-bundle). Especially the 2nd permutation failure indicate that it
thinks there are 2 different resources while it is the same bundle
(pax-web-jetty). Probably the arrayindexoutofbounds is now masked by this
problem:
{panel}
DEBUG: Candidate permutation failed due to a conflict between imports; will try
another if possible. (Uses constraint violation. Unable to resolve resource
org.ops4j.pax.web.pax-web-jetty-bundle
[/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract1867503759233108111.zip/pax-web-jetty-bundle-4.2.5.jar]
because it is exposed to package 'org.osgi.service.log' from resources
org.ops4j.pax.logging.pax-logging-api [8.0] and org.apache.felix.gogo.command
[1.0] via two dependency chains.
Chain 1:
org.ops4j.pax.web.pax-web-jetty-bundle
[/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract1867503759233108111.zip/pax-web-jetty-bundle-4.2.5.jar]
import:
(&(osgi.wiring.package=org.osgi.service.log)(&(version>=1.3.0)(!(version>=2.0.0
|
export: osgi.wiring.package: org.osgi.service.log
org.ops4j.pax.logging.pax-logging-api [8.0]
Chain 2:
org.ops4j.pax.web.pax-web-jetty-bundle
[/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract1867503759233108111.zip/pax-web-jetty-bundle-4.2.5.jar]
import:
(&(osgi.wiring.package=org.apache.commons.logging)(&(version>=1.0.0)(!(version>=2.0.0
|
export: osgi.wiring.package=org.apache.commons.logging;
uses:=org.ops4j.pax.logging
org.ops4j.pax.logging.pax-logging-api [8.0]
import:
(&(osgi.wiring.package=org.ops4j.pax.logging)(version>=0.9.5)(!(version>=2.0.0)))
|
export: osgi.wiring.package=org.ops4j.pax.logging;
uses:=org.osgi.service.log
org.ops4j.pax.logging.pax-logging-api [8.0]
import:
(&(osgi.wiring.package=org.osgi.service.log)(version>=1.3.0)(!(version>=2.0.0)))
|
export: osgi.wiring.package: org.osgi.service.log
org.apache.felix.gogo.command [1.0])
DEBUG: Candidate permutation failed due to a conflict between an export and
import; will try another if possible. (Uses constraint violation. Unable to
resolve resource org.ops4j.pax.web.pax-web-jetty-bundle
[/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract1867503759233108111.zip/pax-web-jetty-bundle-4.2.5.jar]
because it exports package 'org.eclipse.jetty.util.log' and is also exposed to
it from resource org.ops4j.pax.web.pax-web-jetty-bundle
[/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract1867503759233108111.zip/pax-web-jetty-bundle-4.2.5.jar]
via the following dependency chain:
org.ops4j.pax.web.pax-web-jetty-bundle
[/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract1867503759233108111.zip/pax-web-jetty-bundle-4.2.5.jar]
import:
(&(osgi.wiring.package=org.eclipse.jetty.server.handler)(&(version>=9.2.0)(!(version>=10.0.0
|
export: osgi.wiring.package: org.eclipse.jetty.server.handler;
uses:=org.eclipse.jetty.util.log
export: osgi.wiring.package=org.eclipse.jetty.util.log
org.ops4j.pax.web.pax-web-jetty-bundle
[/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract1867503759233108111.zip/pax-web-jetty-bundle-4.2.5.jar])
DEBUG: Candidate permutation failed due to a conflict between imports; will try
another if possible. (Uses constraint violation. Unable to resolve resource
org.ops4j.pax.web.pax-web-jetty-bundle
[/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract1867503759233108111.zip/pax-web-jetty-bundle-4.2.5.jar]
because it is exposed to package 'org.osgi.service.log' from resources
org.ops4j.pax.logging.pax-logging-api [8.0] and org.apache.felix.gogo.command
[1.0] via two dependency chains.
Chain 1:
org.ops4j.pax.web.pax-web-jetty-bundle
[/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract1867503759233108111.zip/pax-web-jetty-bundle-4.2.5.jar]
import:
(&(osgi.wiring.package=org.osgi.service.log)(&(version>=1.3.0)(!(version>=2.0.0
|
export: osgi.wiring.package: org.osgi.service.log
org.ops4j.pax.logging.pax-logging-api [8.0]
Chain 2:
org.ops4j.pax.web.pax-web-jetty-bundle
[/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract1867503759233108111.zip/pax-web-jetty-bundle-4.2.5.jar]
import:
(&(osgi.wiring.package=org.apache.commons.logging)(&(version>=1.0.0)(!(version>=2.0.0
|
export: osgi.wiring.package=org.apache.commons.logging;
uses:=org.ops4j.pax.logging
