aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom De Wolf (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (ARIES-1590) Subsystem install fails due to unexpected resolve conflict
Date Wed, 15 Mar 2017 08:38:41 GMT

    [ 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 [~jwross@us.ibm.com]) 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 [~jwross@us.ibm.com]) 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)

Mime
View raw message