[jira] [Commented] (ARIES-1588) Installation of subsystems fails due to uses constraint violation after exposing feature capabilities.

2017-03-14 Thread Tom De Wolf (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARIES-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924176#comment-15924176
 ] 

Tom De Wolf commented on ARIES-1588:


[~tjwatson] [~jwr...@us.ibm.com] using pull request 
https://github.com/apache/aries/pull/70 I kept the fix for ARIES-1442 and even 
fixed the case for the FragmentHost capability which a subsystem should also 
not impersonate. Additionally, at installation time it should not expose the 
capabilities of its contituents because it will conflict with the 
LocalRepository in which the resolver then also finds a resource capable of 
doing the same resulting in these resolve chain conflicts. 

Can someone have a look at the pull request? thx

Then we can release 2.1.0 and get all the work being done out there.

> Installation of subsystems fails due to uses constraint violation after 
> exposing feature capabilities.
> --
>
> Key: ARIES-1588
> URL: https://issues.apache.org/jira/browse/ARIES-1588
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.1.0
>Reporter: Wouter Bancken
> Fix For: subsystem-2.1.0
>
> Attachments: pax-web-jetty-bundle-4.2.5.jar
>
>
> h4. Setup
> Two feature subsystems
> 1. Feature subsystem with fragment-hosts and fragments
> 2. Feature subsystem with other bundles
> Installation of the second subsystem fails
> h4. Issue
> Installation of the second subsystem fails with the message 
> {quote}
> gogo: SubsystemException: org.osgi.service.resolver.ResolutionException: Uses 
> constraint violation. Unable to resolve resource 
> org.ops4j.pax.web.pax-web-jetty-bundle [124.0] because it exports package 
> 'org.apache.xbean.finder.archive' and is also exposed to it from resource 
> org.apache.xbean.finder [98.0] via the following dependency chain:
> org.ops4j.pax.web.pax-web-jetty-bundle [124.0]
> import: (osgi.wiring.package=org.apache.xbean.finder)
> export: osgi.wiring.package: org.apache.xbean.finder; 
> uses:=org.apache.xbean.finder.archive
> export: osgi.wiring.package=org.apache.xbean.finder.archive
> org.apache.xbean.finder [98.0]
> {quote}
> Before failing a lot of similar messages are logged with the message "DEBUG: 
> Candidate permutation failed due to a conflict between an export and import; 
> will try another if possible."
> This is especially weird since pax-web-jetty-bundle does not expose the 
> org.apache.xbean.finder.archive package (see attached Jar). Both 
> pax-web-jetty-bundle and org.apache.xbean.finder are only present in the 
> first subsystem.
> In our setup pax-web-jetty-bundle is a fragment-host for a fragment which is 
> in the same (first) subsystem. Similar DEBUG statements are printed for other 
> fragment-hosts in the first subsystem.
> The issue occurs since commit 4c0437de06f34321909a6132a7f2be163b2f6d5 
> (ARIES-1443). In earlier versions, we had no issues for these subsystems. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (ARIES-1588) Installation of subsystems fails due to uses constraint violation after exposing feature capabilities.

2017-03-14 Thread Tom De Wolf (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARIES-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15903151#comment-15903151
 ] 

Tom De Wolf edited comment on ARIES-1588 at 3/14/17 1:24 PM:
-

[~tjwatson] same problem with felix resolver 1.12.0 and subsystems 
2.0.9-SNAPSHOT (latest snapshot). 


was (Author: tom.dewolf):
[~tjwatson] same problem with felix resolver 1.12.0 and subsystems 
2.0.9-SNAPSHOT (latest snapshot). Please consider reverting ARIES-1443, 
specifically commit 4c0437de06f34321909a6132a7f2be163b2f6d5 as that is the 
cause that breaks aries subsystems. 

> Installation of subsystems fails due to uses constraint violation after 
> exposing feature capabilities.
> --
>
> Key: ARIES-1588
> URL: https://issues.apache.org/jira/browse/ARIES-1588
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.1.0
>Reporter: Wouter Bancken
> Fix For: subsystem-2.1.0
>
> Attachments: pax-web-jetty-bundle-4.2.5.jar
>
>
> h4. Setup
> Two feature subsystems
> 1. Feature subsystem with fragment-hosts and fragments
> 2. Feature subsystem with other bundles
> Installation of the second subsystem fails
> h4. Issue
> Installation of the second subsystem fails with the message 
> {quote}
> gogo: SubsystemException: org.osgi.service.resolver.ResolutionException: Uses 
> constraint violation. Unable to resolve resource 
> org.ops4j.pax.web.pax-web-jetty-bundle [124.0] because it exports package 
> 'org.apache.xbean.finder.archive' and is also exposed to it from resource 
> org.apache.xbean.finder [98.0] via the following dependency chain:
> org.ops4j.pax.web.pax-web-jetty-bundle [124.0]
> import: (osgi.wiring.package=org.apache.xbean.finder)
> export: osgi.wiring.package: org.apache.xbean.finder; 
> uses:=org.apache.xbean.finder.archive
> export: osgi.wiring.package=org.apache.xbean.finder.archive
> org.apache.xbean.finder [98.0]
> {quote}
> Before failing a lot of similar messages are logged with the message "DEBUG: 
> Candidate permutation failed due to a conflict between an export and import; 
> will try another if possible."
> This is especially weird since pax-web-jetty-bundle does not expose the 
> org.apache.xbean.finder.archive package (see attached Jar). Both 
> pax-web-jetty-bundle and org.apache.xbean.finder are only present in the 
> first subsystem.
> In our setup pax-web-jetty-bundle is a fragment-host for a fragment which is 
> in the same (first) subsystem. Similar DEBUG statements are printed for other 
> fragment-hosts in the first subsystem.
> The issue occurs since commit 4c0437de06f34321909a6132a7f2be163b2f6d5 
> (ARIES-1443). In earlier versions, we had no issues for these subsystems. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARIES-1590) Subsystem install fails due to unexpected resolve conflict

2017-03-14 Thread Tom De Wolf (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARIES-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924170#comment-15924170
 ] 

Tom De Wolf commented on ARIES-1590:


[~tjwatson] [~jwr...@us.ibm.com] using pull request 
https://github.com/apache/aries/pull/70 I kept the fix for ARIES-1442 and even 
fixed the case for the FragmentHost capability which a subsystem should also 
not impersonate. Additionally, at installation time it should not expose the 
capabilities of its contituents because it will conflict with the 
LocalRepository in which the resolver then also finds a resource capable of 
doing the same resulting in these resolve chain conflicts. 

Can someone have a look at the pull request? thx

Then we can release 2.1.0 and get all the work being done out there.

> 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

[jira] [Comment Edited] (ARIES-1591) Subsystem install fails due to ArrayIndexOutofBoundsException

2017-03-14 Thread Tom De Wolf (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARIES-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15903167#comment-15903167
 ] 

Tom De Wolf edited comment on ARIES-1591 at 3/14/17 1:21 PM:
-

[~tjwatson] same problem with felix resolver 1.12.0 and subsystems 
2.0.9-SNAPSHOT (latest snapshot).


was (Author: tom.dewolf):
[~tjwatson] same problem with felix resolver 1.12.0 and subsystems 
2.0.9-SNAPSHOT (latest snapshot). Please consider reverting ARIES-1443, 
specifically commit 4c0437de06f34321909a6132a7f2be163b2f6d5 as that is the 
cause that breaks aries subsystems.

> Subsystem install fails due to ArrayIndexOutofBoundsException
> -
>
> Key: ARIES-1591
> URL: https://issues.apache.org/jira/browse/ARIES-1591
> 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 
> ArrayIndexOutOfBoundsException as soon as our base subsystem contains a 
> fragment bundle:
> {panel}
> Caused by: org.osgi.service.subsystem.SubsystemException: 
> java.lang.ArrayIndexOutOfBoundsException: -1
>   at 
> org.apache.aries.subsystem.core.internal.Utils.handleTrowable(Utils.java:117)
>   at 
> org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:398)
>   at 
> org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:363)
>   at 
> org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:101)
>   at 
> org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:91)
>   at 
> org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:60)
>   at 
> org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:27)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:738)
>   at 
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:791)
>   at 
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:365)
>   at 
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:70)
>   ... 30 more
> Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
>   at 
> org.apache.felix.resolver.util.CopyOnWriteList.set(CopyOnWriteList.java:53)
>   at org.apache.felix.resolver.Candidates.prepare(Candidates.java:1052)
>   at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:173)
>   at 
> org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:393)
>   ... 41 more
> {panel}
> Attached are 2 subsystems that allow to reproduce it. Note that the ONLY 
> difference between these subsystem esa's and the onces attached at ARIES-1590 
> is the fragment bundle osgi-pax-web-jetty-config.
> So the problem might be related to the same commit, but another effect.
> Note: we are using the felix resolver 1.4.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 fails with the above exception.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARIES-1591) Subsystem install fails due to ArrayIndexOutofBoundsException

2017-03-14 Thread Tom De Wolf (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARIES-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924162#comment-15924162
 ] 

Tom De Wolf commented on ARIES-1591:


[~tjwatson] [~jwr...@us.ibm.com] using pull request 
https://github.com/apache/aries/pull/70 I kept the fix for ARIES-1442 and even 
fixed the case for the FragmentHost capability which a subsystem should also 
not impersonate. Can someone have a look at the pull request? thx

> Subsystem install fails due to ArrayIndexOutofBoundsException
> -
>
> Key: ARIES-1591
> URL: https://issues.apache.org/jira/browse/ARIES-1591
> 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 
> ArrayIndexOutOfBoundsException as soon as our base subsystem contains a 
> fragment bundle:
> {panel}
> Caused by: org.osgi.service.subsystem.SubsystemException: 
> java.lang.ArrayIndexOutOfBoundsException: -1
>   at 
> org.apache.aries.subsystem.core.internal.Utils.handleTrowable(Utils.java:117)
>   at 
> org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:398)
>   at 
> org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:363)
>   at 
> org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:101)
>   at 
> org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:91)
>   at 
> org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:60)
>   at 
> org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:27)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:738)
>   at 
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:791)
>   at 
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:365)
>   at 
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:70)
>   ... 30 more
> Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
>   at 
> org.apache.felix.resolver.util.CopyOnWriteList.set(CopyOnWriteList.java:53)
>   at org.apache.felix.resolver.Candidates.prepare(Candidates.java:1052)
>   at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:173)
>   at 
> org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:393)
>   ... 41 more
> {panel}
> Attached are 2 subsystems that allow to reproduce it. Note that the ONLY 
> difference between these subsystem esa's and the onces attached at ARIES-1590 
> is the fragment bundle osgi-pax-web-jetty-config.
> So the problem might be related to the same commit, but another effect.
> Note: we are using the felix resolver 1.4.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 fails with the above exception.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] aries pull request #71: Fix typo

2017-03-14 Thread VEINHORN 
GitHub user VEINHORN opened a pull request:

https://github.com/apache/aries/pull/71

Fix typo



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/VEINHORN/aries patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/aries/pull/71.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #71


commit 5e5ba694600bb85cb726a328d5606d13604b2bf4
Author: Boris Korogvich 
Date:   2017-03-14T10:55:25Z

fix typo




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (ARIES-1674) Multiple inharitance levels with generics cause ClassCastException when JPA is enabled

2017-03-14 Thread Christian Schneider (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ARIES-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schneider resolved ARIES-1674.

Resolution: Won't Fix

Until someone comes up with a way to fix this I would like to treat this as a 
known limitation.

> Multiple inharitance levels with generics cause ClassCastException when JPA 
> is enabled
> --
>
> Key: ARIES-1674
> URL: https://issues.apache.org/jira/browse/ARIES-1674
> Project: Aries
>  Issue Type: Bug
>  Components: JPA
>Affects Versions: jpa-2.5.0
> Environment: Win 7 x64, JDK 1.8.0_73, Karaf 4.0.4
>Reporter: Felix Wassmer
>Assignee: Christian Schneider
>
> I'm using inheritance with generics over multiple levels.
> Injecting properties to those beans works fine, but on access of a property 
> of the lowest class, there is a ClassCastException thrown.
> I could narrow it down to enabling JPA in the blueprint causing the issue:
> When disabling JPA, the proper bean class is resolved,
> enabled the type resolving stopped at the parent abstract class of the 
> expected class, thus throwing a ClassCastException.
> Example project to reproduce this issue:
> https://github.com/fwassmer/inheritance



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (ARIES-1658) Require OSGi 4.3 and slf4j

2017-03-14 Thread Christian Schneider (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ARIES-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schneider resolved ARIES-1658.

Resolution: Fixed

> Require OSGi 4.3 and slf4j
> --
>
> Key: ARIES-1658
> URL: https://issues.apache.org/jira/browse/ARIES-1658
> Project: Aries
>  Issue Type: Improvement
>  Components: Proxy
>Affects Versions: proxy-impl-1.0.6
>Reporter: Christian Schneider
>Assignee: Christian Schneider
> Fix For: proxy-impl-1.0.7
>
>
> Until now aries proxy depdended only on OSGi 4.2 and also slf4j was marked as 
> optional.
> I think we can now assume OSGi 4.3 is present so we can safely use weaving 
> hook and wiring.
> I also noticed that slf4j is used quite a lot. So I don think it is really 
> optional.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (ARIES-1659) Only produce the combined bundle

2017-03-14 Thread Christian Schneider (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ARIES-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schneider resolved ARIES-1659.

Resolution: Fixed

> Only produce the combined bundle
> 
>
> Key: ARIES-1659
> URL: https://issues.apache.org/jira/browse/ARIES-1659
> Project: Aries
>  Issue Type: Improvement
>  Components: Proxy
>Affects Versions: proxy-impl-1.0.6
>Reporter: Christian Schneider
>Assignee: Christian Schneider
> Fix For: proxy-impl-1.0.7
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)