[
https://issues.apache.org/jira/browse/ARIES-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15925747#comment-15925747
]
Tom De Wolf edited comment on ARIES-1590 at 3/15/17 8:38 AM:
-------------------------------------------------------------
Hi [~sbratton], thanks for taking a look. Apparently everyone has a different
effect (see also comment from [[email protected]]) that is even influences by
the jdk version you have. The posted debug is only 1 example of the regression
that results in subsystems not getting installed/resolved at all. Maybe in some
cases and when you wait 50 minutes it could have a chance to pass through but
we see it getting out of memory completely sometimes too. So it looks to us
that the changes that I partly reverted in my pull request start to get too
much regression and failures. In the previous version of that code there was
even a comment/todo stating that too much regression occurs when we also
consider constituent capabilities as capabilities of the subsystem (see pull
request).
Extra argument is that the pull request fixes 3 jira issues at once:
ARIES-1590, ARIES-1588 and ARIES-1591.
Therefore, I propose to accept the pull request so that a new release of aries
can be made and then maybe start a new issue to look into the problem more
closely? Is that a workable plan? It would deblock us not being able to use the
other changes done in the latest snapshot and after that we can go deeper into
the problem.
was (Author: tom.dewolf):
Hi [~sbratton], thanks for taking a look. Apparently everyone has a different
effect (see also comment from [[email protected]]) that is even influences by
the jdk version you have. The posted debug is only 1 example of the regression
that results in subsystems not getting installed/resolved at all. Maybe in some
cases and when you wait 50 minutes it could have a chance to pass through but
we see it getting out of memory completely sometimes too. So it looks to us
that the changes that I partly reverted in my pull request start to get too
much regression and failures. In the previous version of that code there was
even a comment/todo stating that too much regression occurs when we also
consider constituent capabilities as capabilities of the subsystem (see pull
request).
Therefore, I propose to accept the pull request so that a new release of aries
can be made and then maybe start a new issue to look into the problem more
closely? Is that a workable plan? It would deblock us not being able to use the
other changes done in the latest snapshot and after that we can go deeper into
the problem.
> 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 reproduce-subsystem-4.1.2-SNAPSHOT.esa
> Step 3 will start failing in DEBUG logging with chain errors like above. It
> will try a number of permutations but it will not get out of it.
> Note: which bundles and packages are shown in the example log above are less
> important as we have multiple such kind of errors for which only the package
> and bundles differ.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
