[jira] [Commented] (ARIES-1368) BundleResource is not able to compute capabilities for fragments
[ https://issues.apache.org/jira/browse/ARIES-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14681340#comment-14681340 ] Tom De Wolf commented on ARIES-1368: John, is it not possible to have the testsupport release 2.0.0? It is rather urgent for our customer to be able to adopt subsystems. Otherwise we might have to drop aries subsystems completely which I would not prefer. BundleResource is not able to compute capabilities for fragments Key: ARIES-1368 URL: https://issues.apache.org/jira/browse/ARIES-1368 Project: Aries Issue Type: Bug Components: Subsystem Affects Versions: subsystem-core-1.0.0, subsystem-core-1.1.0, subsystem-core-1.2.0, subsystem-2.0.2, subsystem-2.0.1 Reporter: Wouter Bancken Assignee: John Ross Attachments: OsgiIdentityCapability.OsgiIdentityCapability(Resource,BundleManifest)-CallHierarchy.jpg, test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa The computeOsgiIdentityCapability method of the BundleResource is not able to compute capabilities for fragments (only for bundles). This is caused by the fact that the BundleResource is hardcoded to always assume a type of osgi.bundle without inspecting the manifest. Link to mailinglist thread: http://mail-archives.apache.org/mod_mbox/aries-user/201508.mbox/%3CCAL5nZgTOVhdAPYYFOmuV%3DPquAz1a4n_D1Rd3RBrTfu2znCSjKA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1368) BundleResource is not able to compute capabilities for fragments
[ https://issues.apache.org/jira/browse/ARIES-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662913#comment-14662913 ] Tom De Wolf commented on ARIES-1368: John, there is indeed no reason we could not upgrade to the latest release. I've updated our code base and aside from the reported problems we can use it. So getting this fixed and in an 2.0.3 release including maybe some extra bugfixes and upgrade to aries util 1.1.1 would be great. The latter also solve an issue we have when using subsystems. BundleResource is not able to compute capabilities for fragments Key: ARIES-1368 URL: https://issues.apache.org/jira/browse/ARIES-1368 Project: Aries Issue Type: Bug Components: Subsystem Affects Versions: subsystem-core-1.2.0 Reporter: Wouter Bancken Attachments: OsgiIdentityCapability.OsgiIdentityCapability(Resource,BundleManifest)-CallHierarchy.jpg, test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa The computeOsgiIdentityCapability method of the BundleResource is not able to compute capabilities for fragments (only for bundles). This is caused by the fact that the BundleResource is hardcoded to always assume a type of osgi.bundle without inspecting the manifest. Link to mailinglist thread: http://mail-archives.apache.org/mod_mbox/aries-user/201508.mbox/%3CCAL5nZgTOVhdAPYYFOmuV%3DPquAz1a4n_D1Rd3RBrTfu2znCSjKA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1368) BundleResource is not able to compute capabilities for fragments
[ https://issues.apache.org/jira/browse/ARIES-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661899#comment-14661899 ] Tom De Wolf commented on ARIES-1368: John, the problem manifests itself when you use the maven esa plugin and generate an esa in which the fragment is included. Installing such a subsystem does not work as it does not recognize the fragment as fragment. BundleResource is not able to compute capabilities for fragments Key: ARIES-1368 URL: https://issues.apache.org/jira/browse/ARIES-1368 Project: Aries Issue Type: Bug Components: Subsystem Affects Versions: subsystem-core-1.2.0 Reporter: Wouter Bancken Attachments: OsgiIdentityCapability.OsgiIdentityCapability(Resource,BundleManifest)-CallHierarchy.jpg The computeOsgiIdentityCapability method of the BundleResource is not able to compute capabilities for fragments (only for bundles). This is caused by the fact that the BundleResource is hardcoded to always assume a type of osgi.bundle without inspecting the manifest. Link to mailinglist thread: http://mail-archives.apache.org/mod_mbox/aries-user/201508.mbox/%3CCAL5nZgTOVhdAPYYFOmuV%3DPquAz1a4n_D1Rd3RBrTfu2znCSjKA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1368) BundleResource is not able to compute capabilities for fragments
[
https://issues.apache.org/jira/browse/ARIES-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom De Wolf updated ARIES-1368:
---
Attachment: test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa
It is the Aries ESA plugin at
http://aries.apache.org/modules/esamavenpluginproject.html
https://github.com/apache/aries/tree/trunk/esa-maven-plugin
Installing the attached subsystem including a fragment with the install gogo
command results in the stacktrace below. Thus the included fragment is not
found. The gogo commands are the ones included in the aries code base at:
https://github.com/apache/aries/tree/trunk/subsystem/subsystem-gogo-command
Cause: OsgiIdentityCapability identifies all bundles as osgi.bundle via the
osgi.identity capability, it should check for fragments and use osgi.fragment.
{code}
install
file:/Users/tom/Downloads/test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa
...
Caused by: org.osgi.service.subsystem.SubsystemException: A required content
resource could not be found. This means the resource was either missing or not
recognized as a supported resource format due to, for example, an invalid
bundle manifest or blueprint XML file. Turn on debug logging for more
information. The resource was:
org.apache.aries.subsystem.core.archive.SubsystemContentRequirement:
namespace=osgi.identity, attributes={},
directives={filter=((osgi.identity=be.aca.test-service-fragment)(type=osgi.fragment)((version=1.0.1.SNAPSHOT)(version=1.0.1.SNAPSHOT)))},
resource=org.apache.aries.subsystem.core.internal.SubsystemResource@9780e9f1
at
org.apache.aries.subsystem.core.internal.SubsystemResource.computeContentResources(SubsystemResource.java:384)
at
org.apache.aries.subsystem.core.internal.SubsystemResource.computeContentResources(SubsystemResource.java:360)
at
org.apache.aries.subsystem.core.internal.SubsystemResource.init(SubsystemResource.java:99)
at
org.apache.aries.subsystem.core.internal.SubsystemResource.init(SubsystemResource.java:92)
at
org.apache.aries.subsystem.core.internal.InstallAction.createSubsystemResource(InstallAction.java:134)
at
org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:55)
at
org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:33)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:621)
at
org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:259)
at
org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:63)
... 30 more
g!
{code}
BundleResource is not able to compute capabilities for fragments
Key: ARIES-1368
URL: https://issues.apache.org/jira/browse/ARIES-1368
Project: Aries
Issue Type: Bug
Components: Subsystem
Affects Versions: subsystem-core-1.2.0
Reporter: Wouter Bancken
Attachments:
OsgiIdentityCapability.OsgiIdentityCapability(Resource,BundleManifest)-CallHierarchy.jpg,
test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa
The computeOsgiIdentityCapability method of the BundleResource is not able to
compute capabilities for fragments (only for bundles).
This is caused by the fact that the BundleResource is hardcoded to always
assume a type of osgi.bundle without inspecting the manifest.
Link to mailinglist thread:
http://mail-archives.apache.org/mod_mbox/aries-user/201508.mbox/%3CCAL5nZgTOVhdAPYYFOmuV%3DPquAz1a4n_D1Rd3RBrTfu2znCSjKA%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1368) BundleResource is not able to compute capabilities for fragments
[ https://issues.apache.org/jira/browse/ARIES-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662230#comment-14662230 ] Tom De Wolf commented on ARIES-1368: Ok, thank you for explaining this. When can we expect to have the fix for this integrated in a new version of the subsystems library? The workaround would imply manually writing out subsystem manifests and no longer generate them using the maven plugin which we would like to keep. BundleResource is not able to compute capabilities for fragments Key: ARIES-1368 URL: https://issues.apache.org/jira/browse/ARIES-1368 Project: Aries Issue Type: Bug Components: Subsystem Affects Versions: subsystem-core-1.2.0 Reporter: Wouter Bancken Attachments: OsgiIdentityCapability.OsgiIdentityCapability(Resource,BundleManifest)-CallHierarchy.jpg, test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa The computeOsgiIdentityCapability method of the BundleResource is not able to compute capabilities for fragments (only for bundles). This is caused by the fact that the BundleResource is hardcoded to always assume a type of osgi.bundle without inspecting the manifest. Link to mailinglist thread: http://mail-archives.apache.org/mod_mbox/aries-user/201508.mbox/%3CCAL5nZgTOVhdAPYYFOmuV%3DPquAz1a4n_D1Rd3RBrTfu2znCSjKA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1368) Fragment resources receive the osgi.identity capability type of osgi.bundle but should receive osgi.fragment. Also, osgi.wiring.host capabilities and requirements are n
[ https://issues.apache.org/jira/browse/ARIES-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14698238#comment-14698238 ] Tom De Wolf commented on ARIES-1368: John, In your commit at https://github.com/apache/aries/commit/8ad6b99df1fd22d8d89aae9d53975dd634215e74#diff-71f7b1ba9fdbe73d19d4343685d7acad I put a comment on a line which seems strange. As a fragment host requirement has to match with a bundle with identity equal to the host specified in the fragment's manifest I find it strange that a bundleResource has a fragmentHostCapability given when it itself has the Fragment-Host manifest header? A host does not have any header making it a fragment host. Only the fragment itself has a Fragment-Host header. Or am I missing something? Is it not more logical that a fragment host requirement matches to an osgi.identity capability of a bundle matching the name of the fragment host required? Fragment resources receive the osgi.identity capability type of osgi.bundle but should receive osgi.fragment. Also, osgi.wiring.host capabilities and requirements are not computed for bundle or fragment resources. - Key: ARIES-1368 URL: https://issues.apache.org/jira/browse/ARIES-1368 Project: Aries Issue Type: Bug Components: Subsystem Affects Versions: subsystem-core-1.0.0, subsystem-core-1.1.0, subsystem-core-1.2.0, subsystem-2.0.1, subsystem-2.0.2 Reporter: Wouter Bancken Assignee: John Ross Attachments: OsgiIdentityCapability.OsgiIdentityCapability(Resource,BundleManifest)-CallHierarchy.jpg, org.apache.aries.subsystem.core.patch, org.apache.aries.subsystem.itests.patch, test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa The computeOsgiIdentityCapability method of the BundleResource is not able to compute capabilities for fragments (only for bundles). This is caused by the fact that the BundleResource is hardcoded to always assume a type of osgi.bundle without inspecting the manifest. Link to mailinglist thread: http://mail-archives.apache.org/mod_mbox/aries-user/201508.mbox/%3CCAL5nZgTOVhdAPYYFOmuV%3DPquAz1a4n_D1Rd3RBrTfu2znCSjKA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (ARIES-1368) Fragment resources receive the osgi.identity capability type of osgi.bundle but should receive osgi.fragment. Also, osgi.wiring.host capabilities and requir
[ https://issues.apache.org/jira/browse/ARIES-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom De Wolf updated ARIES-1368: --- Comment: was deleted (was: John, In your commit at https://github.com/apache/aries/commit/8ad6b99df1fd22d8d89aae9d53975dd634215e74#diff-71f7b1ba9fdbe73d19d4343685d7acad I put a comment on a line which seems strange. As a fragment host requirement has to match with a bundle with identity equal to the host specified in the fragment's manifest I find it strange that a bundleResource has a fragmentHostCapability given when it itself has the Fragment-Host manifest header? A host does not have any header making it a fragment host. Only the fragment itself has a Fragment-Host header. Or am I missing something? Is it not more logical that a fragment host requirement matches to an osgi.identity capability of a bundle matching the name of the fragment host required?) Fragment resources receive the osgi.identity capability type of osgi.bundle but should receive osgi.fragment. Also, osgi.wiring.host capabilities and requirements are not computed for bundle or fragment resources. - Key: ARIES-1368 URL: https://issues.apache.org/jira/browse/ARIES-1368 Project: Aries Issue Type: Bug Components: Subsystem Affects Versions: subsystem-core-1.0.0, subsystem-core-1.1.0, subsystem-core-1.2.0, subsystem-2.0.1, subsystem-2.0.2 Reporter: Wouter Bancken Assignee: John Ross Attachments: OsgiIdentityCapability.OsgiIdentityCapability(Resource,BundleManifest)-CallHierarchy.jpg, org.apache.aries.subsystem.core.patch, org.apache.aries.subsystem.itests.patch, test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa The computeOsgiIdentityCapability method of the BundleResource is not able to compute capabilities for fragments (only for bundles). This is caused by the fact that the BundleResource is hardcoded to always assume a type of osgi.bundle without inspecting the manifest. Link to mailinglist thread: http://mail-archives.apache.org/mod_mbox/aries-user/201508.mbox/%3CCAL5nZgTOVhdAPYYFOmuV%3DPquAz1a4n_D1Rd3RBrTfu2znCSjKA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1453) Fragment-Host requirements with version range do not match with FragmentHostCapability
[
https://issues.apache.org/jira/browse/ARIES-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006922#comment-15006922
]
Tom De Wolf commented on ARIES-1453:
[~jwr...@us.ibm.com] is this synced to github or how does this work?
> Fragment-Host requirements with version range do not match with
> FragmentHostCapability
> --
>
> Key: ARIES-1453
> URL: https://issues.apache.org/jira/browse/ARIES-1453
> Project: Aries
> Issue Type: Bug
> Components: Subsystem
>Affects Versions: subsystem-2.0.6
>Reporter: Tom De Wolf
>Assignee: John Ross
>Priority: Blocker
> Fix For: subsystem-2.0.8
>
>
> According to http://wiki.osgi.org/wiki/Fragment-Host we can specify
> Fragment-host headers using version ranges. When we do that the requirement
> no longer matches on the capabilities in the aries subsystem implementation.
> It results in the errors below.
> Reason for this is that the FragmentHostCapability only uses 'string'
> attributes which results in versions "9.6.1" and "10.0.0" being compared as
> if "10.0.0" is earlier than "9.6.1". A bundle host with version 9.6.1
> therefore does not match the version range [9.6.0, 10.0.0). It should not do
> string comparison but have a real 'Version' instance to compare with.
> {code}
> Error installing subsystem: org.osgi.service.subsystem.SubsystemException:
> org.osgi.service.resolver.ResolutionException: Unable to resolve
> /var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar:
> missing requirement
> org.apache.aries.subsystem.core.archive.FragmentHostRequirement:
> namespace=osgi.wiring.host, attributes={},
> directives={filter=(&(osgi.wiring.host=be.aca.ui-framework)(&(bundle-version>=9.3.0)(!(bundle-version>=10.0.0},
>
> resource=/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar
> g! at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
> at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
> at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
> at
> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:92)
> at org.apache.felix.gogo.shell.Activator.run(Activator.java:75)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.osgi.service.subsystem.SubsystemException:
> org.osgi.service.resolver.ResolutionException: Unable to resolve
> /var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar:
> missing requirement
> org.apache.aries.subsystem.core.archive.FragmentHostRequirement:
> namespace=osgi.wiring.host, attributes={},
> directives={filter=(&(osgi.wiring.host=be.aca.ui-framework)(&(bundle-version>=9.3.0)(!(bundle-version>=10.0.0},
>
> resource=/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar
> at
> org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:395)
> at
> org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:356)
> at
> org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:98)
> at
> org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:90)
> at
> org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:54)
> at
> org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:30)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:646)
> at
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:690)
> at
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:278)
> at
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:65)
> at
> be.aca.subsystem.internal.DefaultSubsystemService.installFromRepo(DefaultSubsystemService.java:86)
> at
> be.aca.subsystem.internal.DefaultSubsystemService.install(DefaultSubsystemService.java:47)
> ... 30 more
> Caused by: org.osgi.service.resolver.ResolutionException: Unable to resolve
> /var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar:
> missing requirement
> org.apache.aries.subsystem.core.archive.FragmentHostRequirement:
> namespace=osgi.wiring.host, attributes={},
>
[jira] [Created] (ARIES-1453) Fragment-Host requirements with version range do not match with FragmentHostCapability
Tom De Wolf created ARIES-1453:
--
Summary: Fragment-Host requirements with version range do not
match with FragmentHostCapability
Key: ARIES-1453
URL: https://issues.apache.org/jira/browse/ARIES-1453
Project: Aries
Issue Type: Bug
Components: Subsystem
Affects Versions: subsystem-2.0.6
Reporter: Tom De Wolf
Priority: Blocker
Fix For: subsystem-2.0.8
According to http://wiki.osgi.org/wiki/Fragment-Host we can specify
Fragment-host headers using version ranges. When we do that the requirement no
longer matches on the capabilities in the aries subsystem implementation. It
results in the errors below.
Reason for this is that the FragmentHostCapability only uses 'string'
attributes which results in versions "9.6.1" and "10.0.0" being compared as if
"10.0.0" is earlier than "9.6.1". A bundle host with version 9.6.1 therefore
does not match the version range [9.6.0, 10.0.0). It should not do string
comparison but have a real 'Version' instance to compare with.
{code}
Error installing subsystem: org.osgi.service.subsystem.SubsystemException:
org.osgi.service.resolver.ResolutionException: Unable to resolve
/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar:
missing requirement
org.apache.aries.subsystem.core.archive.FragmentHostRequirement:
namespace=osgi.wiring.host, attributes={},
directives={filter=(&(osgi.wiring.host=be.aca.ui-framework)(&(bundle-version>=9.3.0)(!(bundle-version>=10.0.0},
resource=/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar
g! at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
at
org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:92)
at org.apache.felix.gogo.shell.Activator.run(Activator.java:75)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.osgi.service.subsystem.SubsystemException:
org.osgi.service.resolver.ResolutionException: Unable to resolve
/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar:
missing requirement
org.apache.aries.subsystem.core.archive.FragmentHostRequirement:
namespace=osgi.wiring.host, attributes={},
directives={filter=(&(osgi.wiring.host=be.aca.ui-framework)(&(bundle-version>=9.3.0)(!(bundle-version>=10.0.0},
resource=/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar
at
org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:395)
at
org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:356)
at
org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:98)
at
org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:90)
at
org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:54)
at
org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:30)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:646)
at
org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:690)
at
org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:278)
at
org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:65)
at
be.aca.subsystem.internal.DefaultSubsystemService.installFromRepo(DefaultSubsystemService.java:86)
at
be.aca.subsystem.internal.DefaultSubsystemService.install(DefaultSubsystemService.java:47)
... 30 more
Caused by: org.osgi.service.resolver.ResolutionException: Unable to resolve
/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar:
missing requirement
org.apache.aries.subsystem.core.archive.FragmentHostRequirement:
namespace=osgi.wiring.host, attributes={},
directives={filter=(&(osgi.wiring.host=be.aca.ui-framework)(&(bundle-version>=9.3.0)(!(bundle-version>=10.0.0},
resource=/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar
at org.apache.felix.resolver.Candidates.populateResource(Candidates.java:285)
at org.apache.felix.resolver.Candidates.populate(Candidates.java:153)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:148)
at
[jira] [Commented] (ARIES-1453) Fragment-Host requirements with version range do not match with FragmentHostCapability
[
https://issues.apache.org/jira/browse/ARIES-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006026#comment-15006026
]
Tom De Wolf commented on ARIES-1453:
Pull request that solves this: https://github.com/apache/aries/pull/30
As this blocks our usage of our current subsystem setup, could a 2.0.7 or 2.0.8
release be planned in the next few days?
> Fragment-Host requirements with version range do not match with
> FragmentHostCapability
> --
>
> Key: ARIES-1453
> URL: https://issues.apache.org/jira/browse/ARIES-1453
> Project: Aries
> Issue Type: Bug
> Components: Subsystem
>Affects Versions: subsystem-2.0.6
>Reporter: Tom De Wolf
>Priority: Blocker
> Fix For: subsystem-2.0.8
>
>
> According to http://wiki.osgi.org/wiki/Fragment-Host we can specify
> Fragment-host headers using version ranges. When we do that the requirement
> no longer matches on the capabilities in the aries subsystem implementation.
> It results in the errors below.
> Reason for this is that the FragmentHostCapability only uses 'string'
> attributes which results in versions "9.6.1" and "10.0.0" being compared as
> if "10.0.0" is earlier than "9.6.1". A bundle host with version 9.6.1
> therefore does not match the version range [9.6.0, 10.0.0). It should not do
> string comparison but have a real 'Version' instance to compare with.
> {code}
> Error installing subsystem: org.osgi.service.subsystem.SubsystemException:
> org.osgi.service.resolver.ResolutionException: Unable to resolve
> /var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar:
> missing requirement
> org.apache.aries.subsystem.core.archive.FragmentHostRequirement:
> namespace=osgi.wiring.host, attributes={},
> directives={filter=(&(osgi.wiring.host=be.aca.ui-framework)(&(bundle-version>=9.3.0)(!(bundle-version>=10.0.0},
>
> resource=/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar
> g! at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
> at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
> at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
> at
> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:92)
> at org.apache.felix.gogo.shell.Activator.run(Activator.java:75)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.osgi.service.subsystem.SubsystemException:
> org.osgi.service.resolver.ResolutionException: Unable to resolve
> /var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar:
> missing requirement
> org.apache.aries.subsystem.core.archive.FragmentHostRequirement:
> namespace=osgi.wiring.host, attributes={},
> directives={filter=(&(osgi.wiring.host=be.aca.ui-framework)(&(bundle-version>=9.3.0)(!(bundle-version>=10.0.0},
>
> resource=/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar
> at
> org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:395)
> at
> org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:356)
> at
> org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:98)
> at
> org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:90)
> at
> org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:54)
> at
> org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:30)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:646)
> at
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:690)
> at
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:278)
> at
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:65)
> at
> be.aca.subsystem.internal.DefaultSubsystemService.installFromRepo(DefaultSubsystemService.java:86)
> at
> be.aca.subsystem.internal.DefaultSubsystemService.install(DefaultSubsystemService.java:47)
> ... 30 more
> Caused by: org.osgi.service.resolver.ResolutionException: Unable to resolve
> /var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar:
> missing requirement
> org.apache.aries.subsystem.core.archive.FragmentHostRequirement:
>
[jira] [Comment Edited] (ARIES-1453) Fragment-Host requirements with version range do not match with FragmentHostCapability
[
https://issues.apache.org/jira/browse/ARIES-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006026#comment-15006026
]
Tom De Wolf edited comment on ARIES-1453 at 11/15/15 9:03 PM:
--
Pull request that solves this: https://github.com/apache/aries/pull/30
[~jwr...@us.ibm.com] As this blocks our usage of our current subsystem setup,
could a 2.0.7 or 2.0.8 release be planned in the next few days?
was (Author: tom.dewolf):
Pull request that solves this: https://github.com/apache/aries/pull/30
As this blocks our usage of our current subsystem setup, could a 2.0.7 or 2.0.8
release be planned in the next few days?
> Fragment-Host requirements with version range do not match with
> FragmentHostCapability
> --
>
> Key: ARIES-1453
> URL: https://issues.apache.org/jira/browse/ARIES-1453
> Project: Aries
> Issue Type: Bug
> Components: Subsystem
>Affects Versions: subsystem-2.0.6
>Reporter: Tom De Wolf
>Priority: Blocker
> Fix For: subsystem-2.0.8
>
>
> According to http://wiki.osgi.org/wiki/Fragment-Host we can specify
> Fragment-host headers using version ranges. When we do that the requirement
> no longer matches on the capabilities in the aries subsystem implementation.
> It results in the errors below.
> Reason for this is that the FragmentHostCapability only uses 'string'
> attributes which results in versions "9.6.1" and "10.0.0" being compared as
> if "10.0.0" is earlier than "9.6.1". A bundle host with version 9.6.1
> therefore does not match the version range [9.6.0, 10.0.0). It should not do
> string comparison but have a real 'Version' instance to compare with.
> {code}
> Error installing subsystem: org.osgi.service.subsystem.SubsystemException:
> org.osgi.service.resolver.ResolutionException: Unable to resolve
> /var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar:
> missing requirement
> org.apache.aries.subsystem.core.archive.FragmentHostRequirement:
> namespace=osgi.wiring.host, attributes={},
> directives={filter=(&(osgi.wiring.host=be.aca.ui-framework)(&(bundle-version>=9.3.0)(!(bundle-version>=10.0.0},
>
> resource=/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar
> g! at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
> at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
> at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
> at
> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:92)
> at org.apache.felix.gogo.shell.Activator.run(Activator.java:75)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.osgi.service.subsystem.SubsystemException:
> org.osgi.service.resolver.ResolutionException: Unable to resolve
> /var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar:
> missing requirement
> org.apache.aries.subsystem.core.archive.FragmentHostRequirement:
> namespace=osgi.wiring.host, attributes={},
> directives={filter=(&(osgi.wiring.host=be.aca.ui-framework)(&(bundle-version>=9.3.0)(!(bundle-version>=10.0.0},
>
> resource=/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8702582580344751163.zip/ui-main-13.3.1.jar
> at
> org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:395)
> at
> org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:356)
> at
> org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:98)
> at
> org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:90)
> at
> org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:54)
> at
> org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:30)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:646)
> at
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:690)
> at
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:278)
> at
> org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:65)
> at
> be.aca.subsystem.internal.DefaultSubsystemService.installFromRepo(DefaultSubsystemService.java:86)
> at
> be.aca.subsystem.internal.DefaultSubsystemService.install(DefaultSubsystemService.java:47)
> ... 30 more
> Caused by:
[jira] [Commented] (ARIES-1377) Subsystems 2.0.4 Release
[ https://issues.apache.org/jira/browse/ARIES-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951713#comment-14951713 ] Tom De Wolf commented on ARIES-1377: Thanks [~jwr...@us.ibm.com] for getting this release packed with improvements and released so efficiently. Really helps in using aries subsystems. > Subsystems 2.0.4 Release > > > Key: ARIES-1377 > URL: https://issues.apache.org/jira/browse/ARIES-1377 > Project: Aries > Issue Type: Task > Components: Subsystem >Reporter: John Ross >Assignee: John Ross > Fix For: subsystem-2.0.4, subsystem-obr-1.0.4 > > Attachments: TEST-org.osgi.test.cases.subsystem-6.0.0.html, > TEST-org.osgi.test.cases.subsystem.secure-6.0.0.html > > > This will track the 2.0.4 release of the following subsystems modules. > subsystem-core > previous release 2.0.2 > svn diff -r 1688374 > > http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem.core-2.0.2/ > ARIES-1348: subsystems that are dependencies are not auto started > ARIES-1368: Fragment resources receive the osgi.identity capability > type of osgi.bundle but should receive osgi.fragment. Also, osgi.wiring.host > capabilities and requirements are not computed for bundle or fragment > resources. > ARIES-1371: Move subsystems to Aries Util 1.1.1 > ARIES-1381: java.lang.ClassCastException: > org.apache.aries.subsystem.core.archive.GenericDirective cannot be cast to > org.apache.aries.subsystem.core.archive.VersionRangeAttribute > ARIES-1352: Do not overwrite existing configuration when installing a > subsystem > ARIES-1388: Compute requirement filters only once. > ARIES-1356: getInstance method on the core Activator shows up on > jvisualvm sampling during performance analysis > ARIES-1359: Performance improvement on the findProviders method in > the SystemRepository class > ARIES-1389: Compute service requirements and capabilities once in > BundleRevisionResource. > ARIES-1390: BasicCapability should take advantage of the effective > immutability of capabilities. > ARIES-1392: Provide a more efficient implementation of a system > repository. > ARIES-1394: Provide more efficient implementations of the local and > content repositories. > ARIES-1396: Use capability set when calculating subsystem > dependencies. > ARIES-1397: Use capability set with preferred provider repository. > ARIES-1399: Trunk fails OSGi R6 CT > ARIES-1387: Make equals and hashCode comparisons within the header, > clause, and parameter hierarchies based on equivalency rather than string > equals. > ARIES-1084: Subsystem : Failure on restart after framework crash > ARIES-1408: The RequireCapabilityHeader currently only supports > requirements defined by the Aries implementation > ARIES-1404: Restart of the osgi container does not restart subsystem > core because of an error related to missing resource > org.apache.aries.subsystem.resource.synthesized > ARIES-1416: BundleException "bundle is already installed" when the > Preferred-Provider subsystem header points to a bundle. > ARIES-1357: BasicSubsystem can be used by the subsystem install > process a factor 6 times faster > ARIES-1419: Provide-Capability header parser does not support typed > attributes. > ARIES-1235: Installation of a Subsystem containing Subsystems > extremely slow > ARIES-1328: Application subsystem does not import service capabilities > ARIES-1421: SimpleFilter attribute extraction can not handle version > ranges > ARIES-1419: Provide-Capability header parser does not support typed > attributes. > ARIES-1423: IllegalArgumentException when GenericHeader has no clauses > subsystem-api > previous release 2.0.2 > svn diff -r 1688370 > > http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem.api-2.0.2/ > ARIES-1371: Move subsystems to Aries Util 1.1.1 > subsystem-bundle > previous release 2.0.2 > svn diff -r 1688378 > > http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem-2.0.2/ > ARIES-1371: Move subsystems to Aries Util 1.1.1 > subsystem-obr > previous release 1.0.1 > svn diff -r 1668058 > > http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.subsystem.obr-1.0.1/ > ARIES-1410: The FelixResourceAdapter does not return all capabilities > when given a null namespace. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1458) Subsystems 2.0.8 Release
[ https://issues.apache.org/jira/browse/ARIES-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15033265#comment-15033265 ] Tom De Wolf commented on ARIES-1458: [~jwr...@us.ibm.com] any update on the availability of this release on maven central? > Subsystems 2.0.8 Release > > > Key: ARIES-1458 > URL: https://issues.apache.org/jira/browse/ARIES-1458 > Project: Aries > Issue Type: Task > Components: Subsystem >Affects Versions: subsystem-2.0.6 >Reporter: John Ross >Assignee: John Ross > Fix For: subsystem-2.0.8 > > > This will track the 2.0.8 release of Subsystems. > subsystem-core > previous release 2.0.6 > svn diff -r 1711061 > http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem.core-2.0.6/ > ARIES-1451 BundleResourceInstaller.installBundle() throws > IllegalAccessException > ARIES-1453 Fragment-Host requirements with version range do not match with > FragmentHostCapability > subsystem-api > previous release 2.0.6 > svn diff -r 1711055 > http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem.api-2.0.6/ > No changes > subsystem-bundle > previous release 2.0.6 > svn diff -r 1711065 > http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem-2.0.6/ > No changes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1565) Performance Improvement: unpack subsystem artifacts to tmp folder to avoid directly reading from zip archive
[ https://issues.apache.org/jira/browse/ARIES-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324325#comment-15324325 ] Tom De Wolf commented on ARIES-1565: [~jwr...@us.ibm.com] any chance that you could have a look to see if this can be included in a new subsystems release soon? would help our development teams enormously > Performance Improvement: unpack subsystem artifacts to tmp folder to avoid > directly reading from zip archive > > > Key: ARIES-1565 > URL: https://issues.apache.org/jira/browse/ARIES-1565 > Project: Aries > Issue Type: Improvement > Components: Subsystem, Util >Affects Versions: subsystem-2.0.8, util-1.1.2 >Reporter: Wouter Bancken > > h4. Description > Aries copies ESA archives to a temporary zip file during the installation > phase. Afterwards, bundles are read directly from this temporary zip which > has a large impact on the startup performance of Aries applications. By > unpacking the esa artifact into the temporary folder it is unpacked only > once. Subsequent reads for the bundles (jars) can be read directly from the > folder. > h4. Mailinglist > http://mail-archives.apache.org/mod_mbox/aries-user/201606.mbox/%3CCAL5nZgTq5FxDvURJbzcEZ9YHx6vTs3HAOuFYDYA3ec9OZbmwjA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1564) Performance improvement: sorting bundles by start-level is done eagerly
[ https://issues.apache.org/jira/browse/ARIES-1564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324320#comment-15324320 ] Tom De Wolf commented on ARIES-1564: [~jwr...@us.ibm.com] any chance that you could have a look to see if this can be included in a new subsystems release soon? would help our development teams enormously > Performance improvement: sorting bundles by start-level is done eagerly > --- > > Key: ARIES-1564 > URL: https://issues.apache.org/jira/browse/ARIES-1564 > Project: Aries > Issue Type: Improvement > Components: Subsystem >Affects Versions: subsystem-2.0.8 >Reporter: Wouter Bancken > > h4. Description > During sorting in the StartAction class, the SubsystemContentHeader is parsed > every time the start order of a bundle is needed. By eagerly parsing the > header and storing the start value for every bundle, an improved startup time > can be achieved. > h4. Mailinglist > http://mail-archives.apache.org/mod_mbox/aries-user/201606.mbox/%3CCAL5nZgRQcvFqz8g1c7mKJ3C_UoRmRox10%2BOM2uEjRbCkTYodDQ%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1491) Fragment-host bundle is refreshed when a new fragment is installed
[ https://issues.apache.org/jira/browse/ARIES-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15142657#comment-15142657 ] Tom De Wolf commented on ARIES-1491: [~jwr...@us.ibm.com] any idea if this improvement could be planned with option/solution (3)? > Fragment-host bundle is refreshed when a new fragment is installed > -- > > Key: ARIES-1491 > URL: https://issues.apache.org/jira/browse/ARIES-1491 > Project: Aries > Issue Type: Improvement > Components: Subsystem >Affects Versions: subsystem-2.0.8 >Reporter: Wouter Bancken > > The Felix framework will not allow fragments to attach to an already resolved > host. This results in resolution errors when a new fragment bundle appears in > a new subsystem while the fragment-host is in an already started subsystem. > These resolution errors can be resolved by refreshing > (FrameworkWiring.refreshBundles) the resolved fragment-host bundle after > installing the fragment. > Aries could do this automatically when it encounters a fragment-host > requirement when resolving a subsystem. > Related mailinglist discussion: > http://mail-archives.apache.org/mod_mbox/aries-user/201602.mbox/browser -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1491) Fragment-host bundle is refreshed when a new fragment is installed
[ https://issues.apache.org/jira/browse/ARIES-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15130366#comment-15130366 ] Tom De Wolf commented on ARIES-1491: Looks like option (3) is the best option as in general normal bundles do not need such a refresh cross-subsystem. OSGi fragments-host is part of the OSGi spec so have fragment specific support cross-subsystems seems logical to implement. The current aries subsystem implementation already has specific fragment support for other reasons. > Fragment-host bundle is refreshed when a new fragment is installed > -- > > Key: ARIES-1491 > URL: https://issues.apache.org/jira/browse/ARIES-1491 > Project: Aries > Issue Type: Improvement > Components: Subsystem >Affects Versions: subsystem-2.0.8 >Reporter: Wouter Bancken > > The Felix framework will not allow fragments to attach to an already resolved > host. This results in resolution errors when a new fragment bundle appears in > a new subsystem while the fragment-host is in an already started subsystem. > These resolution errors can be resolved by refreshing > (FrameworkWiring.refreshBundles) the resolved fragment-host bundle after > installing the fragment. > Aries could do this automatically when it encounters a fragment-host > requirement when resolving a subsystem. > Related mailinglist discussion: > http://mail-archives.apache.org/mod_mbox/aries-user/201602.mbox/browser -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1490) The esa maven plugin provides more flexibility when creating the subsystem manifest
[ https://issues.apache.org/jira/browse/ARIES-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15158534#comment-15158534 ] Tom De Wolf commented on ARIES-1490: Yes, your understanding is correct. We do not want to list all dependencies individually and thus rely on the fact that the esa plugin uses the maven dependency tree to include the transitive dependencies. However, for us they are actual content of the esa subsystem so we would like to mark them as such by including them in the Subsystem-Content header without having to list them again. To structure a big project we also like to use external pom.xml files including a list of dependencies and having the esa plugin able to cope with that would easy the use of the plugin for bigger projects too. Also being able to influence the start order is sometimes needed. It is very confusing that the content specified in the header is out of sync with the content that is actually in the esa. Why make the difference? What would be wrong to at least add all bundles included in the esa archive also to the manifest Subsystem-Content header? Sounds more consistent. > The esa maven plugin provides more flexibility when creating the subsystem > manifest > --- > > Key: ARIES-1490 > URL: https://issues.apache.org/jira/browse/ARIES-1490 > Project: Aries > Issue Type: New Feature > Components: ESA Maven Plugin >Affects Versions: esa-maven-plugin-1.0.0 >Reporter: Wouter Bancken > > When determining which dependencies are included in the archive, the ESA > maven plugin provides different possibilities as to which dependencies are > included (transitive dependencies vs only direct dependencies). > When generating the subsystem manifest, the plugin always decides to only > list the direct dependencies and therefore it does not include the transitive > dependencies as part of the subsystem content even though they are present in > the archive. > Additionally, the type of the dependencies (e.g. 'pom') is not taken into > account. This makes it impossible to extract a sequence of related > dependencies into a separate pom file to improve the overall readability. The > readability would improve greatly if a related set of dependencies could be > imported from another pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1490) The esa maven plugin provides more flexibility when creating the subsystem manifest
[ https://issues.apache.org/jira/browse/ARIES-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15158555#comment-15158555 ] Tom De Wolf commented on ARIES-1490: Also, when we use the maven dependency tree to include an extender bundle (e.g. blueprint extender) then there is no bundle having a direct Import-Package requirement on that bundle and it will not even get installed while we do want it there. For those bundles we now only have the option to list them separately. So an option 'includeDependenciesInSubsystemContentHeader' would be nice. > The esa maven plugin provides more flexibility when creating the subsystem > manifest > --- > > Key: ARIES-1490 > URL: https://issues.apache.org/jira/browse/ARIES-1490 > Project: Aries > Issue Type: New Feature > Components: ESA Maven Plugin >Affects Versions: esa-maven-plugin-1.0.0 >Reporter: Wouter Bancken > > When determining which dependencies are included in the archive, the ESA > maven plugin provides different possibilities as to which dependencies are > included (transitive dependencies vs only direct dependencies). > When generating the subsystem manifest, the plugin always decides to only > list the direct dependencies and therefore it does not include the transitive > dependencies as part of the subsystem content even though they are present in > the archive. > Additionally, the type of the dependencies (e.g. 'pom') is not taken into > account. This makes it impossible to extract a sequence of related > dependencies into a separate pom file to improve the overall readability. The > readability would improve greatly if a related set of dependencies could be > imported from another pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1490) The esa maven plugin provides more flexibility when creating the subsystem manifest
[ https://issues.apache.org/jira/browse/ARIES-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15156992#comment-15156992 ] Tom De Wolf commented on ARIES-1490: If we do not specify the Subsystem-Content header then we have no way to influence the start order of those bundles and the esa-maven-plugin enables this by taking the order of maven dependencies into account to generate start orders. So it would be better to have a possibility to choose if the content packaged should be completely listed in the header also, no? > The esa maven plugin provides more flexibility when creating the subsystem > manifest > --- > > Key: ARIES-1490 > URL: https://issues.apache.org/jira/browse/ARIES-1490 > Project: Aries > Issue Type: New Feature > Components: ESA Maven Plugin >Affects Versions: esa-maven-plugin-1.0.0 >Reporter: Wouter Bancken > > When determining which dependencies are included in the archive, the ESA > maven plugin provides different possibilities as to which dependencies are > included (transitive dependencies vs only direct dependencies). > When generating the subsystem manifest, the plugin always decides to only > list the direct dependencies and therefore it does not include the transitive > dependencies as part of the subsystem content even though they are present in > the archive. > Additionally, the type of the dependencies (e.g. 'pom') is not taken into > account. This makes it impossible to extract a sequence of related > dependencies into a separate pom file to improve the overall readability. The > readability would improve greatly if a related set of dependencies could be > imported from another pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1490) The esa maven plugin provides more flexibility when creating the subsystem manifest
[ https://issues.apache.org/jira/browse/ARIES-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15156180#comment-15156180 ] Tom De Wolf commented on ARIES-1490: [~jwr...@us.ibm.com] [~bosschaert] any chance this is getting resolved? It even seems to be a bug in the esa-maven-plugin as that plugin provides an option to include transitive dependencies as jars within the esa file BUT it does not list those transitive dependencies in the SUBSYSTEM.MF manifest as content of the esa. So a mismatch between what is put in the esa archive and what is listed in the manifest as content which is incorrect. > The esa maven plugin provides more flexibility when creating the subsystem > manifest > --- > > Key: ARIES-1490 > URL: https://issues.apache.org/jira/browse/ARIES-1490 > Project: Aries > Issue Type: New Feature > Components: ESA Maven Plugin >Affects Versions: esa-maven-plugin-1.0.0 >Reporter: Wouter Bancken > > When determining which dependencies are included in the archive, the ESA > maven plugin provides different possibilities as to which dependencies are > included (transitive dependencies vs only direct dependencies). > When generating the subsystem manifest, the plugin always decides to only > list the direct dependencies and therefore it does not include the transitive > dependencies as part of the subsystem content even though they are present in > the archive. > Additionally, the type of the dependencies (e.g. 'pom') is not taken into > account. This makes it impossible to extract a sequence of related > dependencies into a separate pom file to improve the overall readability. The > readability would improve greatly if a related set of dependencies could be > imported from another pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1588) Installation of subsystems fails due to incorrectly detected export packages
[
https://issues.apache.org/jira/browse/ARIES-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407619#comment-15407619
]
Tom De Wolf commented on ARIES-1588:
[~jwr...@us.ibm.com] any idea when a fix for this can be made or a roll-back of
the specific commit so that the next version of aries does not pose problems?
> Installation of subsystems fails due to incorrectly detected export packages
>
>
> 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.4#6332)
[jira] [Commented] (ARIES-1565) Performance Improvement: unpack subsystem artifacts to tmp folder to avoid directly reading from zip archive
[ https://issues.apache.org/jira/browse/ARIES-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407616#comment-15407616 ] Tom De Wolf commented on ARIES-1565: [~jwr...@us.ibm.com] any idea when this can be integrated? > Performance Improvement: unpack subsystem artifacts to tmp folder to avoid > directly reading from zip archive > > > Key: ARIES-1565 > URL: https://issues.apache.org/jira/browse/ARIES-1565 > Project: Aries > Issue Type: Improvement > Components: Subsystem, Util >Affects Versions: subsystem-2.0.8, util-1.1.2 >Reporter: Wouter Bancken > Attachments: 1565.patch, Call_Tree_2_0_8.html, > Call_Tree_John_Ross.html, Call_Tree_Wouter_Bancken.html, > aries1565-profile.png, test-service-subsystem-4.0.2-SNAPSHOT.esa > > > h4. Description > Aries copies ESA archives to a temporary zip file during the installation > phase. Afterwards, bundles are read directly from this temporary zip which > has a large impact on the startup performance of Aries applications. By > unpacking the esa artifact into the temporary folder it is unpacked only > once. Subsequent reads for the bundles (jars) can be read directly from the > folder. > h4. Pull request > https://github.com/apache/aries/compare/subsystem-2.0.x...WouterBanckenACA:io_performance_optimalisation?expand=1 > h4. Mailinglist > http://mail-archives.apache.org/mod_mbox/aries-user/201606.mbox/%3CCAL5nZgTq5FxDvURJbzcEZ9YHx6vTs3HAOuFYDYA3ec9OZbmwjA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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
[jira] [Updated] (ARIES-1591) Subsystem install fails due to ArrayIndexOutofBoundsException
[
https://issues.apache.org/jira/browse/ARIES-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom De Wolf updated ARIES-1591:
---
Description:
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
was:
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.
> Subsystem install fails due to ArrayIndexOutofBoundsException
>
[jira] [Commented] (ARIES-1588) Installation of subsystems fails due to uses constraint violation after exposing feature capabilities.
[
https://issues.apache.org/jira/browse/ARIES-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15412117#comment-15412117
]
Tom De Wolf commented on ARIES-1588:
[~jwr...@us.ibm.com] tried to compose subsystems for this specific issue and
encountered possibly related problems, equally blocking the 2.1.0 release with
the perf improvements. Can you have a look?
> 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.4#6332)
[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/9/16 6:41 AM:
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 and 3rd permutation failure indicate that it thinks there are 2
different resources while it is the same bundle. 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
org.ops4j.pax.logging.pax-logging-api [8.0]
[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/9/16 6:41 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 and 3rd permutation failure indicate
that it thinks there are 2 different resources while it is the same bundle.
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
[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/9/16 6:40 AM:
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 and 3rd permutation failure indicate that it thinks there are 2
different resources while it is the same bundle:
{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
org.ops4j.pax.logging.pax-logging-api [8.0]
import:
[jira] [Commented] (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 commented on ARIES-1591:
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):
{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
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:
[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=15413028#comment-15413028
]
Tom De Wolf commented on ARIES-1590:
[~jwr...@us.ibm.com] using 1.8 of the felix resolver results in the same 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
> 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.4#6332)
[jira] [Updated] (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:all-tabpanel
]
Tom De Wolf updated ARIES-1590:
---
Description:
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.
was:
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:
[jira] [Created] (ARIES-1590) Subsystem install fails due to unexpected resolve conflict
Tom De Wolf created ARIES-1590:
--
Summary: 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
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 com.reproduce.reproduce-bundle
[/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8165788265469364064.zip/reproduce-bundle-4.1.2-SNAPSHOT.jar]
because it is exposed to package 'org.springframework.beans' from resources
com.reproduce.reproduce-base-subsystem
[org.apache.aries.subsystem.core.internal.BasicSubsystem: children=0,
constituents=70, id=1,
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.spring-beans [73.0] via two dependency chains.
Chain 1:
com.reproduce.reproduce-bundle
[/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8165788265469364064.zip/reproduce-bundle-4.1.2-SNAPSHOT.jar]
import: (&(osgi.wiring.package=org.springframework.beans)(version>=0.0.0))
|
export: osgi.wiring.package: org.springframework.beans
com.reproduce.reproduce-base-subsystem
[org.apache.aries.subsystem.core.internal.BasicSubsystem: children=0,
constituents=70, id=1,
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:
com.reproduce.reproduce-bundle
[/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8165788265469364064.zip/reproduce-bundle-4.1.2-SNAPSHOT.jar]
import:
(&(osgi.wiring.package=org.springframework.beans.factory.annotation)(version>=0.0.0))
|
export: osgi.wiring.package: org.springframework.beans.factory.annotation;
uses:=org.springframework.beans
export: osgi.wiring.package=org.springframework.beans
org.apache.servicemix.bundles.spring-beans [73.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
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (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:all-tabpanel
]
Tom De Wolf updated ARIES-1590:
---
Description:
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
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.
was:
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 com.reproduce.reproduce-bundle
[/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8165788265469364064.zip/reproduce-bundle-4.1.2-SNAPSHOT.jar]
because it is exposed to package 'org.springframework.beans' from resources
com.reproduce.reproduce-base-subsystem
[org.apache.aries.subsystem.core.internal.BasicSubsystem: children=0,
constituents=70, id=1,
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.spring-beans [73.0] via two dependency chains.
Chain 1:
com.reproduce.reproduce-bundle
[jira] [Updated] (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:all-tabpanel
]
Tom De Wolf updated ARIES-1590:
---
Attachment: reproduce-base-subsystem-4.1.2-SNAPSHOT.esa
> 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
> 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.4#6332)
[jira] [Commented] (ARIES-1588) Installation of subsystems fails due to uses constraint violation after exposing feature capabilities.
[
https://issues.apache.org/jira/browse/ARIES-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15411829#comment-15411829
]
Tom De Wolf commented on ARIES-1588:
ARIES-1590 might be related, I came across it trying to compose a set of
subsystems which can reproduce this issue (have to clean them out as I cannot
share all company bundles).
The problem in ARIES-1590 also seems to linked to the commit mentioned in the
description of this issue.
> 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.4#6332)
[jira] [Updated] (ARIES-1591) Subsystem install fails due to ArrayIndexOutofBoundsException
[
https://issues.apache.org/jira/browse/ARIES-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom De Wolf updated ARIES-1591:
---
Description:
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.
was:
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
[jira] [Updated] (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:all-tabpanel
]
Tom De Wolf updated ARIES-1590:
---
Attachment: reproduce-subsystem-4.1.2-SNAPSHOT.esa
> 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-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
> com.reproduce.reproduce-bundle
> [/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8165788265469364064.zip/reproduce-bundle-4.1.2-SNAPSHOT.jar]
> because it is exposed to package 'org.springframework.beans' from resources
> com.reproduce.reproduce-base-subsystem
> [org.apache.aries.subsystem.core.internal.BasicSubsystem: children=0,
> constituents=70, id=1,
> 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.spring-beans [73.0] via two dependency chains.
> Chain 1:
> com.reproduce.reproduce-bundle
> [/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8165788265469364064.zip/reproduce-bundle-4.1.2-SNAPSHOT.jar]
> import: (&(osgi.wiring.package=org.springframework.beans)(version>=0.0.0))
> |
> export: osgi.wiring.package: org.springframework.beans
> com.reproduce.reproduce-base-subsystem
> [org.apache.aries.subsystem.core.internal.BasicSubsystem: children=0,
> constituents=70, id=1,
> 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:
> com.reproduce.reproduce-bundle
> [/var/folders/9b/nqy6w5xs6gz1m1q4g6gpfr_cgn/T/inputStreamExtract8165788265469364064.zip/reproduce-bundle-4.1.2-SNAPSHOT.jar]
> import:
> (&(osgi.wiring.package=org.springframework.beans.factory.annotation)(version>=0.0.0))
> |
> export: osgi.wiring.package:
> org.springframework.beans.factory.annotation; uses:=org.springframework.beans
> export: osgi.wiring.package=org.springframework.beans
> org.apache.servicemix.bundles.spring-beans [73.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
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARIES-1591) Subsystem install fails due to ArrayIndexOutofBoundsException
Tom De Wolf created ARIES-1591:
--
Summary: 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
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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1591) Subsystem install fails due to ArrayIndexOutofBoundsException
[
https://issues.apache.org/jira/browse/ARIES-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom De Wolf updated ARIES-1591:
---
Attachment: reproduce-subsystem-4.1.2-SNAPSHOT.esa
reproduce-base-subsystem-4.1.2-SNAPSHOT.esa
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1565) Performance Improvement: unpack subsystem artifacts to tmp folder to avoid directly reading from zip archive
[ https://issues.apache.org/jira/browse/ARIES-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15465408#comment-15465408 ] Tom De Wolf commented on ARIES-1565: [~jwr...@us.ibm.com] the changes are done in the pull request. Thx to [~Wouter Bancken]. Can you integrate the pull request into the Aries subsystems and aries util code base? > Performance Improvement: unpack subsystem artifacts to tmp folder to avoid > directly reading from zip archive > > > Key: ARIES-1565 > URL: https://issues.apache.org/jira/browse/ARIES-1565 > Project: Aries > Issue Type: Improvement > Components: Subsystem, Util >Affects Versions: subsystem-2.0.8, util-1.1.2 >Reporter: Wouter Bancken > Attachments: 1565.patch, Call_Tree_2_0_8.html, > Call_Tree_John_Ross.html, Call_Tree_Wouter_Bancken.html, > aries1565-profile.png, test-service-subsystem-4.0.2-SNAPSHOT.esa > > > h4. Description > Aries copies ESA archives to a temporary zip file during the installation > phase. Afterwards, bundles are read directly from this temporary zip which > has a large impact on the startup performance of Aries applications. By > unpacking the esa artifact into the temporary folder it is unpacked only > once. Subsequent reads for the bundles (jars) can be read directly from the > folder. > h4. Pull request > https://github.com/apache/aries/compare/subsystem-2.0.x...WouterBanckenACA:io_performance_optimalisation?expand=1 > h4. Mailinglist > http://mail-archives.apache.org/mod_mbox/aries-user/201606.mbox/%3CCAL5nZgTq5FxDvURJbzcEZ9YHx6vTs3HAOuFYDYA3ec9OZbmwjA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1612) Zip input stream relies on default (non buffered) InputStream read
[ https://issues.apache.org/jira/browse/ARIES-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509254#comment-15509254 ] Tom De Wolf commented on ARIES-1612: [~jwr...@us.ibm.com] are you also able to create a new aries util release? or point us to the person who can? > Zip input stream relies on default (non buffered) InputStream read > -- > > Key: ARIES-1612 > URL: https://issues.apache.org/jira/browse/ARIES-1612 > Project: Aries > Issue Type: Bug > Components: Util >Affects Versions: util-1.1.1 >Reporter: Paul Thevenot >Assignee: Thomas Watson > Fix For: util-1.1.2 > > > We have performances issues on application startup. It takes a while to > install all the bundles of a subsystem. After a quick look with JProfiler, we > saw that the SpecialZipInputStream.read() was invoked 44 millions times > during startup. > We're using the Felix framework and the BundleCache.copyStreamToFile calls > the method read(byte[] b) from the InputStream. Unfortunately, the method > read(byte[] b) and read(byte[] b, int off, int len) are not overriden by the > SpecialZipInputStream (thus we don't buffer the read). > Completing the decoration in the SpecialZipInputStream solved this problem > and divided the startup time by two. > I've made the pull request with the requested change > https://github.com/apache/aries/pull/55 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1588) Installation of subsystems fails due to uses constraint violation after exposing feature capabilities.
[
https://issues.apache.org/jira/browse/ARIES-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15930125#comment-15930125
]
Tom De Wolf commented on ARIES-1588:
[~sbratton] tested the new snapshot/trunk version against our setup to
reproduce ARIES-1588 and I can confirm it is solved. I will resolve the issue.
> 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] [Resolved] (ARIES-1591) Subsystem install fails due to ArrayIndexOutofBoundsException
[
https://issues.apache.org/jira/browse/ARIES-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom De Wolf resolved ARIES-1591.
Resolution: Fixed
> 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-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=15930109#comment-15930109
]
Tom De Wolf commented on ARIES-1590:
[~sbratton] tested the new snapshot/trunk version against our setup to
reproduce ARIES-1590 and I can confirm it is solved. I will resolve the issue.
> 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)
[jira] [Resolved] (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:all-tabpanel
]
Tom De Wolf resolved ARIES-1590.
Resolution: Fixed
> 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)
[jira] [Commented] (ARIES-1547) Subsystem 2.1.0 Release
[ https://issues.apache.org/jira/browse/ARIES-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15930136#comment-15930136 ] Tom De Wolf commented on ARIES-1547: [~sbratton] [~jwr...@us.ibm.com] [~tjwatson] [~bosschaert] as we now have a working aries 2.1.0 on trunk which has a number of improvements/fixes which we need in our projects, can we consider to pull issue ARIES-1443 out of the release so that it can be looked into in detail without a rush? All the other issues are resolved so we would appreciate if the release procedure for aries subystems 2.1.0 can be started. > Subsystem 2.1.0 Release > --- > > Key: ARIES-1547 > URL: https://issues.apache.org/jira/browse/ARIES-1547 > Project: Aries > Issue Type: Task > Components: Subsystem >Reporter: John Ross >Assignee: John Ross > Fix For: subsystem-2.1.0 > > > It may be a good idea to start thinking about another Subsystem release. A > number of defects have been addressed (see the attached links). The minor > version bump is due to the new functionality introduced in ARIES-1383. > It would be nice to get ARIES-1493 in as well, but I don't know when I'll > have time to do it. > One potential blocker is ARIES-1491, but I am unable to commit to > implementing this for the foreseeable future. > subsystem-core 2.1.0 > previous release 2.0.8 > svn diff -r 1715820 > http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem.core-2.0.8/ > subsystem-api 2.1.0 > previous release 2.0.8 > svn diff -r 1715811 > http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem.api-2.0.8/ > subsystem-bundle 2.1.0 > previous release 2.0.8 > svn diff -r 1715829 > http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem-2.0.8/ > subsystem-obr 1.0.6 > previous release 1.0.4 > svn diff -r 1745514 > http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.subsystem.obr-1.0.4/ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARIES-1666) Sharing policy is importing from requirements not included as part of the subsystem
[ https://issues.apache.org/jira/browse/ARIES-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15930140#comment-15930140 ] Tom De Wolf commented on ARIES-1666: [~tjwatson] also 'resolved'? part of subsystem 2.1.0? > Sharing policy is importing from requirements not included as part of the > subsystem > --- > > Key: ARIES-1666 > URL: https://issues.apache.org/jira/browse/ARIES-1666 > Project: Aries > Issue Type: Bug > Components: Subsystem >Reporter: Thomas Watson > > When resolving a subsystem the implementation uses the Resolver service to > determine the subsystem's dependencies. For application type subsystems this > causes the sharing policy to be computed according to the wires returned by > the resolver. > The subsystems implementation is doing a 'full' resolve to do this. This > includes re-resolving bundles already resolved in the system repository as > part of the subsystem resolution or installation process. As a result the > resolution map used to calculate the import sharing policy contains wires for > many resources that are not considered as part of the subsystem content. But > the import policy is updated with the requirements for all wires which do not > get wired to a provider contained in the subsystem. > This results in a explosion of filters in the equinox region edge which > connects the subsystem region to its parent region. This is bad for several > reasons. 1) may give access to things that the subsystem should not have > access to 2) will slowdown performance when the list of filters gets large. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (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=15930122#comment-15930122
]
Tom De Wolf commented on ARIES-1591:
[~sbratton] tested the new snapshot/trunk version against our setup to
reproduce ARIES-1591 and I can confirm it is solved. I will resolve the issue.
> 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-1667) findCandidates for already resolved resources is slow
[ https://issues.apache.org/jira/browse/ARIES-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15930138#comment-15930138 ] Tom De Wolf commented on ARIES-1667: [~tjwatson] this one seems resolved? committed on trunk. Maybe add it to the 'subsystem 2.1.0' release issue and put it in 'resolved' too? > findCandidates for already resolved resources is slow > - > > Key: ARIES-1667 > URL: https://issues.apache.org/jira/browse/ARIES-1667 > Project: Aries > Issue Type: Bug > Components: Subsystem >Reporter: Thomas Watson > > org.apache.aries.subsystem.core.internal.ResolveContext.processWire(Wire, > Requirement, List) > The processWire method for ResolveContext is used when doing off-line > resolution of a subsystem for resources that are already resolved in the host > framework (or the system repository). The problem is the way the candidates > are discovered with the existing wirings. The existing code will iterate > over every wire looking for a capability that matches the given requirement. > This is a lot of work because it requires filter matching against every > capability the resolved resource is wired to. > I see no reason the filter matching is required here. We have the resources > requirement and the resources wiring wire which uses the requirement. All we > need to do is find the wires that use the requirement. The capabilities > attached to these wires have to match. Checking for requirement equality > should be faster that checking every capability wired to for a match. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[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=15926814#comment-15926814
]
Tom De Wolf commented on ARIES-1590:
Sounds logical. I think the working theory is correct. As I understood
ARIES-1443 was not directly linked to a failure problem.
Concerning understanding the problem, indeed the resolver is being exposed from
duplicate capabilities but it does not consider them duplicates because they
are not 'equal', reason: their 'resource' is not equal (bundle vs
basicsubystem).
Thanks for considering the pull request and reopening ARIES-1443 for later. If
I can help with something to get it in a new release (testing, ...), just let
me know.
> 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
[jira] [Commented] (ARIES-1547) Subsystem 2.1.0 Release
[ https://issues.apache.org/jira/browse/ARIES-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978802#comment-15978802 ] Tom De Wolf commented on ARIES-1547: [~sbratton] [~jwr...@us.ibm.com] [~tjwatson] [~bosschaert] see my earlier comment. We would like to have a 2.1.0 release so we can go forward with some improvement tracks on our projects. Can one of u facilitate this and get the release out? Thx. > Subsystem 2.1.0 Release > --- > > Key: ARIES-1547 > URL: https://issues.apache.org/jira/browse/ARIES-1547 > Project: Aries > Issue Type: Task > Components: Subsystem >Reporter: John Ross >Assignee: John Ross > Fix For: subsystem-2.1.0 > > > It may be a good idea to start thinking about another Subsystem release. A > number of defects have been addressed (see the attached links). The minor > version bump is due to the new functionality introduced in ARIES-1383. > It would be nice to get ARIES-1493 in as well, but I don't know when I'll > have time to do it. > One potential blocker is ARIES-1491, but I am unable to commit to > implementing this for the foreseeable future. > subsystem-core 2.1.0 > previous release 2.0.8 > svn diff -r 1715820 > http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem.core-2.0.8/ > subsystem-api 2.1.0 > previous release 2.0.8 > svn diff -r 1715811 > http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem.api-2.0.8/ > subsystem-bundle 2.1.0 > previous release 2.0.8 > svn diff -r 1715829 > http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem-2.0.8/ > subsystem-obr 1.0.6 > previous release 1.0.4 > svn diff -r 1745514 > http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.subsystem.obr-1.0.4/ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARIES-1588) Installation of subsystems fails due to uses constraint violation after exposing feature capabilities.
[
https://issues.apache.org/jira/browse/ARIES-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15903374#comment-15903374
]
Tom De Wolf commented on ARIES-1588:
[~tjwatson] pull request https://github.com/apache/aries/pull/70 fixes this
issue
> 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
[
https://issues.apache.org/jira/browse/ARIES-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15903376#comment-15903376
]
Tom De Wolf commented on ARIES-1590:
[~tjwatson] pull request https://github.com/apache/aries/pull/70 fixes this
issue
> 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)
[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=15903372#comment-15903372
]
Tom De Wolf edited comment on ARIES-1591 at 3/9/17 4:54 PM:
[~tjwatson] pull request https://github.com/apache/aries/pull/70 fixes this
issue
was (Author: tom.dewolf):
pull request https://github.com/apache/aries/pull/70 fixes this issue
> 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-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=15903152#comment-15903152
]
Tom De Wolf commented on ARIES-1590:
[~tjwatson] I've tested it again with felix resolver 1.12.0 and it still has
the same problem. Please consider reverting ARIES-1443, specifically commit
4c0437de06f34321909a6132a7f2be163b2f6d5 as that is the cause that breaks aries
subsystems.
> 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)
[jira] [Commented] (ARIES-1588) Installation of subsystems fails due to uses constraint violation after exposing feature capabilities.
[
https://issues.apache.org/jira/browse/ARIES-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15903151#comment-15903151
]
Tom De Wolf commented on ARIES-1588:
[~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-1564) Performance improvement: sorting bundles by start-level is done eagerly
[ https://issues.apache.org/jira/browse/ARIES-1564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15903173#comment-15903173 ] Tom De Wolf commented on ARIES-1564: [~Wouter Bancken] correct me if I'm wrong, but a number of other perf improvements makes this issue obsolete? > Performance improvement: sorting bundles by start-level is done eagerly > --- > > Key: ARIES-1564 > URL: https://issues.apache.org/jira/browse/ARIES-1564 > Project: Aries > Issue Type: Improvement > Components: Subsystem >Affects Versions: subsystem-2.0.8 >Reporter: Wouter Bancken > > h4. Description > During sorting in the StartAction class, the SubsystemContentHeader is parsed > every time the start order of a bundle is needed. By eagerly parsing the > header and storing the start value for every bundle, an improved startup time > can be achieved. > h4. Pull request > https://github.com/apache/aries/compare/subsystem-2.0.x...WouterBanckenACA:sorting_performance_optimalisation > h4. Mailinglist > http://mail-archives.apache.org/mod_mbox/aries-user/201606.mbox/%3CCAL5nZgRQcvFqz8g1c7mKJ3C_UoRmRox10%2BOM2uEjRbCkTYodDQ%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (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=15903167#comment-15903167
]
Tom De Wolf commented on ARIES-1591:
[~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-1490) The esa maven plugin provides more flexibility when creating the subsystem manifest
[ https://issues.apache.org/jira/browse/ARIES-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15892554#comment-15892554 ] Tom De Wolf commented on ARIES-1490: [~bosschaert] thank you for taking care of it so soon. We'll take a look at the other pull request that now needs some adaptations. When that is done, we will notify you again. Thanks! > The esa maven plugin provides more flexibility when creating the subsystem > manifest > --- > > Key: ARIES-1490 > URL: https://issues.apache.org/jira/browse/ARIES-1490 > Project: Aries > Issue Type: New Feature > Components: ESA Maven Plugin >Affects Versions: esa-maven-plugin-1.0.0 >Reporter: Wouter Bancken >Assignee: David Bosschaert > Fix For: esa-maven-plugin-1.0.0 > > > When determining which dependencies are included in the archive, the ESA > maven plugin provides different possibilities as to which dependencies are > included (transitive dependencies vs only direct dependencies). > When generating the subsystem manifest, the plugin always decides to only > list the direct dependencies and therefore it does not include the transitive > dependencies as part of the subsystem content even though they are present in > the archive. > Additionally, the type of the dependencies (e.g. 'pom') is not taken into > account. This makes it impossible to extract a sequence of related > dependencies into a separate pom file to improve the overall readability. The > readability would improve greatly if a related set of dependencies could be > imported from another pom. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARIES-1588) Installation of subsystems fails due to uses constraint violation after exposing feature capabilities.
[
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-1591) Subsystem install fails due to ArrayIndexOutofBoundsException
[
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
[
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)
[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=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-1588) Installation of subsystems fails due to uses constraint violation after exposing feature capabilities.
[
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-1490) The esa maven plugin provides more flexibility when creating the subsystem manifest
[ https://issues.apache.org/jira/browse/ARIES-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15892389#comment-15892389 ] Tom De Wolf commented on ARIES-1490: [~bosschaert] are you still processing pull requests for the esa-maven-plugin? if not, who should I contact to get the pull request for this issue merged and released? > The esa maven plugin provides more flexibility when creating the subsystem > manifest > --- > > Key: ARIES-1490 > URL: https://issues.apache.org/jira/browse/ARIES-1490 > Project: Aries > Issue Type: New Feature > Components: ESA Maven Plugin >Affects Versions: esa-maven-plugin-1.0.0 >Reporter: Wouter Bancken > > When determining which dependencies are included in the archive, the ESA > maven plugin provides different possibilities as to which dependencies are > included (transitive dependencies vs only direct dependencies). > When generating the subsystem manifest, the plugin always decides to only > list the direct dependencies and therefore it does not include the transitive > dependencies as part of the subsystem content even though they are present in > the archive. > Additionally, the type of the dependencies (e.g. 'pom') is not taken into > account. This makes it impossible to extract a sequence of related > dependencies into a separate pom file to improve the overall readability. The > readability would improve greatly if a related set of dependencies could be > imported from another pom. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
