[jira] [Updated] (ARIES-2058) Aries 1.16.0 RSA fails OSGi RemoteServiceAdmin TCK test

[A. J. David Bosschaert (Jira)]

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

A. J. David Bosschaert updated ARIES-2058:
--
Attachment: aries.log

> Aries 1.16.0 RSA fails OSGi RemoteServiceAdmin TCK test
> ---
>
> Key: ARIES-2058
> URL: https://issues.apache.org/jira/browse/ARIES-2058
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.16.0
>Reporter: A. J. David Bosschaert
>Priority: Major
> Attachments: aries.log
>
>
> When running the OSGi RSA TCK 13 of the 39 tests fail:
> {code:java}
> Test run finished after 458266 ms
> [11 containers found  ]
> [ 0 containers skipped]
> [11 containers started]
> [ 0 containers aborted]
> [11 containers successful ]
> [ 0 containers failed ]
> [39 tests found   ]
> [ 0 tests skipped ]
> [39 tests started ]
> [ 0 tests aborted ]
> [26 tests successful  ]
> [13 tests failed  ]
> # test ran
> # queue []
>  
> > Task :org.osgi.test.cases.remoteserviceadmin:testOSGi FAILED {code}
> To reproduce make the following change in https://github.com/osgi/osgi:
> {code}
> $ git diff
> diff --git a/cnf/ext/central.mvn b/cnf/ext/central.mvn
> index 2a8e2f44b2..e43331adac 100644
> --- a/cnf/ext/central.mvn
> +++ b/cnf/ext/central.mvn
> @@ -89,12 +89,12 @@ 
> org.apache.aries.jpa:org.apache.aries.jpa.eclipselink.adapter:2.4.0
>  org.apache.aries.spec:org.apache.aries.javax.jax.rs-api:1.0.4
>  org.apache.aries.spifly:org.apache.aries.spifly.dynamic.bundle:1.0.8
>  
> org.apache.aries.spifly:org.apache.aries.spifly.dynamic.framework.extension:1.3.3
> -org.apache.aries.rsa:org.apache.aries.rsa.core:1.13.0
> -org.apache.aries.rsa:org.apache.aries.rsa.spi:1.13.0
> -org.apache.aries.rsa:org.apache.aries.rsa.topology-manager:1.13.0
> -org.apache.aries.rsa.discovery:org.apache.aries.rsa.discovery.local:1.13.0
> -org.apache.aries.rsa.discovery:org.apache.aries.rsa.discovery.zookeeper:1.13.0
> -org.apache.aries.rsa.provider:org.apache.aries.rsa.provider.tcp:1.13.0
> +org.apache.aries.rsa:org.apache.aries.rsa.core:1.16.0
> +org.apache.aries.rsa:org.apache.aries.rsa.spi:1.16.0
> +org.apache.aries.rsa:org.apache.aries.rsa.topology-manager:1.16.0
> +org.apache.aries.rsa.discovery:org.apache.aries.rsa.discovery.local:1.16.0
> +org.apache.aries.rsa.discovery:org.apache.aries.rsa.discovery.zookeeper:1.16.0
> +org.apache.aries.rsa.provider:org.apache.aries.rsa.provider.tcp:1.16.0
>  org.apache.felix:org.apache.felix.configadmin:1.9.22
>  org.apache.felix:org.apache.felix.configurator:1.0.8
> {code}
> Then run in the {{org.osgi.test.cases.remoteserviceadmin}} directory:
> {code}
> $ ../gradlew check
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (ARIES-2058) Aries 1.16.0 RSA fails OSGi RemoteServiceAdmin TCK test

[A. J. David Bosschaert (Jira)]

A. J. David Bosschaert created ARIES-2058:
-

 Summary: Aries 1.16.0 RSA fails OSGi RemoteServiceAdmin TCK test
 Key: ARIES-2058
 URL: https://issues.apache.org/jira/browse/ARIES-2058
 Project: Aries
  Issue Type: Bug
  Components: Remote Service Admin
Affects Versions: rsa-1.16.0
Reporter: A. J. David Bosschaert


When running the OSGi RSA TCK 13 of the 39 tests fail:

{code:java}
Test run finished after 458266 ms
[11 containers found  ]
[ 0 containers skipped]
[11 containers started]
[ 0 containers aborted]
[11 containers successful ]
[ 0 containers failed ]
[39 tests found   ]
[ 0 tests skipped ]
[39 tests started ]
[ 0 tests aborted ]
[26 tests successful  ]
[13 tests failed  ]
# test ran
# queue []
 
> Task :org.osgi.test.cases.remoteserviceadmin:testOSGi FAILED {code}

To reproduce make the following change in https://github.com/osgi/osgi:

{code}
$ git diff
diff --git a/cnf/ext/central.mvn b/cnf/ext/central.mvn
index 2a8e2f44b2..e43331adac 100644
--- a/cnf/ext/central.mvn
+++ b/cnf/ext/central.mvn
@@ -89,12 +89,12 @@ 
org.apache.aries.jpa:org.apache.aries.jpa.eclipselink.adapter:2.4.0
 org.apache.aries.spec:org.apache.aries.javax.jax.rs-api:1.0.4
 org.apache.aries.spifly:org.apache.aries.spifly.dynamic.bundle:1.0.8
 
org.apache.aries.spifly:org.apache.aries.spifly.dynamic.framework.extension:1.3.3
-org.apache.aries.rsa:org.apache.aries.rsa.core:1.13.0
-org.apache.aries.rsa:org.apache.aries.rsa.spi:1.13.0
-org.apache.aries.rsa:org.apache.aries.rsa.topology-manager:1.13.0
-org.apache.aries.rsa.discovery:org.apache.aries.rsa.discovery.local:1.13.0
-org.apache.aries.rsa.discovery:org.apache.aries.rsa.discovery.zookeeper:1.13.0
-org.apache.aries.rsa.provider:org.apache.aries.rsa.provider.tcp:1.13.0
+org.apache.aries.rsa:org.apache.aries.rsa.core:1.16.0
+org.apache.aries.rsa:org.apache.aries.rsa.spi:1.16.0
+org.apache.aries.rsa:org.apache.aries.rsa.topology-manager:1.16.0
+org.apache.aries.rsa.discovery:org.apache.aries.rsa.discovery.local:1.16.0
+org.apache.aries.rsa.discovery:org.apache.aries.rsa.discovery.zookeeper:1.16.0
+org.apache.aries.rsa.provider:org.apache.aries.rsa.provider.tcp:1.16.0

 org.apache.felix:org.apache.felix.configadmin:1.9.22
 org.apache.felix:org.apache.felix.configurator:1.0.8
{code}

Then run in the {{org.osgi.test.cases.remoteserviceadmin}} directory:

{code}
$ ../gradlew check
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (ARIES-1814) Solve the start order limitations with SPI Fly

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1814:
-

Thanks for offering to help out with this issue [~rotty3000]!

> Solve the start order limitations with SPI Fly
> --
>
> Key: ARIES-1814
> URL: https://issues.apache.org/jira/browse/ARIES-1814
> Project: Aries
>  Issue Type: Improvement
>  Components: SPI Fly
>Reporter: Raymond Augé
>Assignee: Raymond Augé
>Priority: Major
>
> A couple of aspects to try:
> - create a new SPI Fly artifact which is a framework fragment
> - likely needs to embed ASM and Aries Util
> -- maybe use the bnd instruction {{-conditionalpackage}} (which in 
> maven-bundle-plugin becomes {{<_conditionalpackage>}}, same syntax as 
> Import-Package



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (ARIES-1814) Solve the start order limitations with SPI Fly

[David Bosschaert (JIRA)]

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

David Bosschaert reassigned ARIES-1814:
---

Assignee: Raymond Augé  (was: David Bosschaert)

> Solve the start order limitations with SPI Fly
> --
>
> Key: ARIES-1814
> URL: https://issues.apache.org/jira/browse/ARIES-1814
> Project: Aries
>  Issue Type: Improvement
>  Components: SPI Fly
>Reporter: Raymond Augé
>Assignee: Raymond Augé
>Priority: Major
>
> A couple of aspects to try:
> - create a new SPI Fly artifact which is a framework fragment
> - likely needs to embed ASM and Aries Util
> -- maybe use the bnd instruction {{-conditionalpackage}} (which in 
> maven-bundle-plugin becomes {{<_conditionalpackage>}}, same syntax as 
> Import-Package



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (ARIES-1814) Solve the start order limitations with SPI Fly

[David Bosschaert (JIRA)]

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

David Bosschaert reassigned ARIES-1814:
---

Assignee: David Bosschaert

> Solve the start order limitations with SPI Fly
> --
>
> Key: ARIES-1814
> URL: https://issues.apache.org/jira/browse/ARIES-1814
> Project: Aries
>  Issue Type: Improvement
>  Components: SPI Fly
>Reporter: Raymond Augé
>Assignee: David Bosschaert
>Priority: Major
>
> A couple of aspects to try:
> - create a new SPI Fly artifact which is a framework fragment
> - likely needs to embed ASM and Aries Util
> -- maybe use the bnd instruction {{-conditionalpackage}} (which in 
> maven-bundle-plugin becomes {{<_conditionalpackage>}}, same syntax as 
> Import-Package



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ARIES-1801) SPI Fly does not work with a dynamic class object

[David Bosschaert (JIRA)]

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

David Bosschaert resolved ARIES-1801.
-
Resolution: Fixed

> SPI Fly does not work with a dynamic class object
> -
>
> Key: ARIES-1801
> URL: https://issues.apache.org/jira/browse/ARIES-1801
> Project: Aries
>  Issue Type: Bug
>Affects Versions: spifly-1.0.10
>Reporter: Björn Kautler
>Assignee: David Bosschaert
>Priority: Major
> Fix For: spifly-1.0.12
>
>
> SLF4J changes in version 1.8 how implementations are looked up to 
> {{java.util.ServiceLoader}}.
> In our codebase we dynamically search for an SLF4J implementation and use a 
> default logger if none is found.
> To adapt to the new mechanism but remain compatible with SLF4J 1.7 I added to 
> our codebase
> {code:java}
> try {
> // post-1.8 mechanism
> Class slf4jServiceProviderClass = 
> Class.forName("org.slf4j.spi.SLF4JServiceProvider");
> if (ServiceLoader.load(slf4jServiceProviderClass).iterator().hasNext()) {
> noLogger.set(false);
> return true;
> }
> } catch (ClassNotFoundException e) {
> // ignore
> }
> {code}
> If I now use the {{org.apache.aries.spifly.dynamic.bundle}} 1.0.10, I get an 
> exception as SPI Fly seemingly only supports class constants. While 
> traversing the ASM tree it remembers the last class constant seen and uses 
> that to transform the {{load}} call.
> Here the exception I get:
> {code:java}
> java.lang.ClassFormatError: Weaving hook failed.
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2479)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2152)
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1607)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at 
> org.javacord.core.util.logging.ExceptionLoggerDelegateImpl.(ExceptionLoggerDelegateImpl.java:20)
>   at 
> org.javacord.core.util.DelegateFactoryDelegateImpl.createExceptionLoggerDelegate(DelegateFactoryDelegateImpl.java:180)
>   at 
> org.javacord.api.util.internal.DelegateFactory.(DelegateFactory.java:74)
>   at org.javacord.api.DiscordApiBuilder.(DiscordApiBuilder.java:20)
>   at net.kautler.test.osgi.OsgiTest.start(OsgiTest.java:17)
>   at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
>   at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
>   at org.apache.felix.framework.Felix.startBundle(Felix.java:2146)
>   at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373)
>   at 
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: value null
>   at org.objectweb.asm.ClassWriter.newConstItem(ClassWriter.java:1057)
>   at org.objectweb.asm.MethodWriter.visitLdcInsn(MethodWriter.java:1126)
>   at 
> org.apache.aries.spifly.weaver.TCCLSetterVisitor$TCCLSetterMethodVisitor.visitMethodInsn(TCCLSetterVisitor.java:194)
>   at org.objectweb.asm.ClassReader.readCode(ClassReader.java:1416)
>   at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1017)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:693)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:506)
>   at 
> org.apache.aries.spifly.dynamic.ClientWeavingHook.weave(ClientWeavingHook.java:61)
>   at 
> org.apache.felix.framework.util.SecureAction.invokeWeavingHook(SecureAction.java:1203)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2465)
>   ... 16 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1801) SPI Fly does not work with a dynamic class object

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1801:
-

[~vampire] FYI the release thread has started. Feel free to vote :) 
http://mail-archives.apache.org/mod_mbox/aries-dev/201806.mbox/%3CCAMit8Soa_g5wQXL6zHx0DESyY%2BC4pJannmanLe79Nc_LxHZ7FA%40mail.gmail.com%3E

> SPI Fly does not work with a dynamic class object
> -
>
> Key: ARIES-1801
> URL: https://issues.apache.org/jira/browse/ARIES-1801
> Project: Aries
>  Issue Type: Bug
>Affects Versions: spifly-1.0.10
>Reporter: Björn Kautler
>Assignee: David Bosschaert
>Priority: Major
> Fix For: spifly-1.0.12
>
>
> SLF4J changes in version 1.8 how implementations are looked up to 
> {{java.util.ServiceLoader}}.
> In our codebase we dynamically search for an SLF4J implementation and use a 
> default logger if none is found.
> To adapt to the new mechanism but remain compatible with SLF4J 1.7 I added to 
> our codebase
> {code:java}
> try {
> // post-1.8 mechanism
> Class slf4jServiceProviderClass = 
> Class.forName("org.slf4j.spi.SLF4JServiceProvider");
> if (ServiceLoader.load(slf4jServiceProviderClass).iterator().hasNext()) {
> noLogger.set(false);
> return true;
> }
> } catch (ClassNotFoundException e) {
> // ignore
> }
> {code}
> If I now use the {{org.apache.aries.spifly.dynamic.bundle}} 1.0.10, I get an 
> exception as SPI Fly seemingly only supports class constants. While 
> traversing the ASM tree it remembers the last class constant seen and uses 
> that to transform the {{load}} call.
> Here the exception I get:
> {code:java}
> java.lang.ClassFormatError: Weaving hook failed.
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2479)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2152)
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1607)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at 
> org.javacord.core.util.logging.ExceptionLoggerDelegateImpl.(ExceptionLoggerDelegateImpl.java:20)
>   at 
> org.javacord.core.util.DelegateFactoryDelegateImpl.createExceptionLoggerDelegate(DelegateFactoryDelegateImpl.java:180)
>   at 
> org.javacord.api.util.internal.DelegateFactory.(DelegateFactory.java:74)
>   at org.javacord.api.DiscordApiBuilder.(DiscordApiBuilder.java:20)
>   at net.kautler.test.osgi.OsgiTest.start(OsgiTest.java:17)
>   at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
>   at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
>   at org.apache.felix.framework.Felix.startBundle(Felix.java:2146)
>   at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373)
>   at 
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: value null
>   at org.objectweb.asm.ClassWriter.newConstItem(ClassWriter.java:1057)
>   at org.objectweb.asm.MethodWriter.visitLdcInsn(MethodWriter.java:1126)
>   at 
> org.apache.aries.spifly.weaver.TCCLSetterVisitor$TCCLSetterMethodVisitor.visitMethodInsn(TCCLSetterVisitor.java:194)
>   at org.objectweb.asm.ClassReader.readCode(ClassReader.java:1416)
>   at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1017)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:693)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:506)
>   at 
> org.apache.aries.spifly.dynamic.ClientWeavingHook.weave(ClientWeavingHook.java:61)
>   at 
> org.apache.felix.framework.util.SecureAction.invokeWeavingHook(SecureAction.java:1203)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2465)
>   ... 16 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1801) SPI Fly does not work with a dynamic class object

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1801:
-

[~vampire] I'll prepare a release soon.

> SPI Fly does not work with a dynamic class object
> -
>
> Key: ARIES-1801
> URL: https://issues.apache.org/jira/browse/ARIES-1801
> Project: Aries
>  Issue Type: Bug
>Affects Versions: spifly-1.0.10
>Reporter: Björn Kautler
>Assignee: David Bosschaert
>Priority: Major
> Fix For: spifly-1.0.12
>
>
> SLF4J changes in version 1.8 how implementations are looked up to 
> {{java.util.ServiceLoader}}.
> In our codebase we dynamically search for an SLF4J implementation and use a 
> default logger if none is found.
> To adapt to the new mechanism but remain compatible with SLF4J 1.7 I added to 
> our codebase
> {code:java}
> try {
> // post-1.8 mechanism
> Class slf4jServiceProviderClass = 
> Class.forName("org.slf4j.spi.SLF4JServiceProvider");
> if (ServiceLoader.load(slf4jServiceProviderClass).iterator().hasNext()) {
> noLogger.set(false);
> return true;
> }
> } catch (ClassNotFoundException e) {
> // ignore
> }
> {code}
> If I now use the {{org.apache.aries.spifly.dynamic.bundle}} 1.0.10, I get an 
> exception as SPI Fly seemingly only supports class constants. While 
> traversing the ASM tree it remembers the last class constant seen and uses 
> that to transform the {{load}} call.
> Here the exception I get:
> {code:java}
> java.lang.ClassFormatError: Weaving hook failed.
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2479)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2152)
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1607)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at 
> org.javacord.core.util.logging.ExceptionLoggerDelegateImpl.(ExceptionLoggerDelegateImpl.java:20)
>   at 
> org.javacord.core.util.DelegateFactoryDelegateImpl.createExceptionLoggerDelegate(DelegateFactoryDelegateImpl.java:180)
>   at 
> org.javacord.api.util.internal.DelegateFactory.(DelegateFactory.java:74)
>   at org.javacord.api.DiscordApiBuilder.(DiscordApiBuilder.java:20)
>   at net.kautler.test.osgi.OsgiTest.start(OsgiTest.java:17)
>   at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
>   at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
>   at org.apache.felix.framework.Felix.startBundle(Felix.java:2146)
>   at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373)
>   at 
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: value null
>   at org.objectweb.asm.ClassWriter.newConstItem(ClassWriter.java:1057)
>   at org.objectweb.asm.MethodWriter.visitLdcInsn(MethodWriter.java:1126)
>   at 
> org.apache.aries.spifly.weaver.TCCLSetterVisitor$TCCLSetterMethodVisitor.visitMethodInsn(TCCLSetterVisitor.java:194)
>   at org.objectweb.asm.ClassReader.readCode(ClassReader.java:1416)
>   at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1017)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:693)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:506)
>   at 
> org.apache.aries.spifly.dynamic.ClientWeavingHook.weave(ClientWeavingHook.java:61)
>   at 
> org.apache.felix.framework.util.SecureAction.invokeWeavingHook(SecureAction.java:1203)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2465)
>   ... 16 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARIES-1801) SPI Fly does not work with a dynamic class object

[David Bosschaert (JIRA)]

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

David Bosschaert updated ARIES-1801:

Affects Version/s: (was: 1.0)
   spifly-1.0.10

> SPI Fly does not work with a dynamic class object
> -
>
> Key: ARIES-1801
> URL: https://issues.apache.org/jira/browse/ARIES-1801
> Project: Aries
>  Issue Type: Bug
>Affects Versions: spifly-1.0.10
>Reporter: Björn Kautler
>Assignee: David Bosschaert
>Priority: Major
> Fix For: spifly-1.0.12
>
>
> SLF4J changes in version 1.8 how implementations are looked up to 
> {{java.util.ServiceLoader}}.
> In our codebase we dynamically search for an SLF4J implementation and use a 
> default logger if none is found.
> To adapt to the new mechanism but remain compatible with SLF4J 1.7 I added to 
> our codebase
> {code:java}
> try {
> // post-1.8 mechanism
> Class slf4jServiceProviderClass = 
> Class.forName("org.slf4j.spi.SLF4JServiceProvider");
> if (ServiceLoader.load(slf4jServiceProviderClass).iterator().hasNext()) {
> noLogger.set(false);
> return true;
> }
> } catch (ClassNotFoundException e) {
> // ignore
> }
> {code}
> If I now use the {{org.apache.aries.spifly.dynamic.bundle}} 1.0.10, I get an 
> exception as SPI Fly seemingly only supports class constants. While 
> traversing the ASM tree it remembers the last class constant seen and uses 
> that to transform the {{load}} call.
> Here the exception I get:
> {code:java}
> java.lang.ClassFormatError: Weaving hook failed.
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2479)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2152)
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1607)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at 
> org.javacord.core.util.logging.ExceptionLoggerDelegateImpl.(ExceptionLoggerDelegateImpl.java:20)
>   at 
> org.javacord.core.util.DelegateFactoryDelegateImpl.createExceptionLoggerDelegate(DelegateFactoryDelegateImpl.java:180)
>   at 
> org.javacord.api.util.internal.DelegateFactory.(DelegateFactory.java:74)
>   at org.javacord.api.DiscordApiBuilder.(DiscordApiBuilder.java:20)
>   at net.kautler.test.osgi.OsgiTest.start(OsgiTest.java:17)
>   at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
>   at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
>   at org.apache.felix.framework.Felix.startBundle(Felix.java:2146)
>   at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373)
>   at 
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: value null
>   at org.objectweb.asm.ClassWriter.newConstItem(ClassWriter.java:1057)
>   at org.objectweb.asm.MethodWriter.visitLdcInsn(MethodWriter.java:1126)
>   at 
> org.apache.aries.spifly.weaver.TCCLSetterVisitor$TCCLSetterMethodVisitor.visitMethodInsn(TCCLSetterVisitor.java:194)
>   at org.objectweb.asm.ClassReader.readCode(ClassReader.java:1416)
>   at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1017)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:693)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:506)
>   at 
> org.apache.aries.spifly.dynamic.ClientWeavingHook.weave(ClientWeavingHook.java:61)
>   at 
> org.apache.felix.framework.util.SecureAction.invokeWeavingHook(SecureAction.java:1203)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2465)
>   ... 16 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARIES-1801) SPI Fly does not work with a dynamic class object

[David Bosschaert (JIRA)]

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

David Bosschaert updated ARIES-1801:

Fix Version/s: spifly-1.0.12

> SPI Fly does not work with a dynamic class object
> -
>
> Key: ARIES-1801
> URL: https://issues.apache.org/jira/browse/ARIES-1801
> Project: Aries
>  Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Björn Kautler
>Assignee: David Bosschaert
>Priority: Major
> Fix For: spifly-1.0.12
>
>
> SLF4J changes in version 1.8 how implementations are looked up to 
> {{java.util.ServiceLoader}}.
> In our codebase we dynamically search for an SLF4J implementation and use a 
> default logger if none is found.
> To adapt to the new mechanism but remain compatible with SLF4J 1.7 I added to 
> our codebase
> {code:java}
> try {
> // post-1.8 mechanism
> Class slf4jServiceProviderClass = 
> Class.forName("org.slf4j.spi.SLF4JServiceProvider");
> if (ServiceLoader.load(slf4jServiceProviderClass).iterator().hasNext()) {
> noLogger.set(false);
> return true;
> }
> } catch (ClassNotFoundException e) {
> // ignore
> }
> {code}
> If I now use the {{org.apache.aries.spifly.dynamic.bundle}} 1.0.10, I get an 
> exception as SPI Fly seemingly only supports class constants. While 
> traversing the ASM tree it remembers the last class constant seen and uses 
> that to transform the {{load}} call.
> Here the exception I get:
> {code:java}
> java.lang.ClassFormatError: Weaving hook failed.
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2479)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2152)
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1607)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at 
> org.javacord.core.util.logging.ExceptionLoggerDelegateImpl.(ExceptionLoggerDelegateImpl.java:20)
>   at 
> org.javacord.core.util.DelegateFactoryDelegateImpl.createExceptionLoggerDelegate(DelegateFactoryDelegateImpl.java:180)
>   at 
> org.javacord.api.util.internal.DelegateFactory.(DelegateFactory.java:74)
>   at org.javacord.api.DiscordApiBuilder.(DiscordApiBuilder.java:20)
>   at net.kautler.test.osgi.OsgiTest.start(OsgiTest.java:17)
>   at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
>   at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
>   at org.apache.felix.framework.Felix.startBundle(Felix.java:2146)
>   at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373)
>   at 
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: value null
>   at org.objectweb.asm.ClassWriter.newConstItem(ClassWriter.java:1057)
>   at org.objectweb.asm.MethodWriter.visitLdcInsn(MethodWriter.java:1126)
>   at 
> org.apache.aries.spifly.weaver.TCCLSetterVisitor$TCCLSetterMethodVisitor.visitMethodInsn(TCCLSetterVisitor.java:194)
>   at org.objectweb.asm.ClassReader.readCode(ClassReader.java:1416)
>   at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1017)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:693)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:506)
>   at 
> org.apache.aries.spifly.dynamic.ClientWeavingHook.weave(ClientWeavingHook.java:61)
>   at 
> org.apache.felix.framework.util.SecureAction.invokeWeavingHook(SecureAction.java:1203)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2465)
>   ... 16 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (ARIES-1801) SPI Fly does not work with a dynamic class object

[David Bosschaert (JIRA)]

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

David Bosschaert reassigned ARIES-1801:
---

Assignee: David Bosschaert

> SPI Fly does not work with a dynamic class object
> -
>
> Key: ARIES-1801
> URL: https://issues.apache.org/jira/browse/ARIES-1801
> Project: Aries
>  Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Björn Kautler
>Assignee: David Bosschaert
>Priority: Major
> Fix For: spifly-1.0.12
>
>
> SLF4J changes in version 1.8 how implementations are looked up to 
> {{java.util.ServiceLoader}}.
> In our codebase we dynamically search for an SLF4J implementation and use a 
> default logger if none is found.
> To adapt to the new mechanism but remain compatible with SLF4J 1.7 I added to 
> our codebase
> {code:java}
> try {
> // post-1.8 mechanism
> Class slf4jServiceProviderClass = 
> Class.forName("org.slf4j.spi.SLF4JServiceProvider");
> if (ServiceLoader.load(slf4jServiceProviderClass).iterator().hasNext()) {
> noLogger.set(false);
> return true;
> }
> } catch (ClassNotFoundException e) {
> // ignore
> }
> {code}
> If I now use the {{org.apache.aries.spifly.dynamic.bundle}} 1.0.10, I get an 
> exception as SPI Fly seemingly only supports class constants. While 
> traversing the ASM tree it remembers the last class constant seen and uses 
> that to transform the {{load}} call.
> Here the exception I get:
> {code:java}
> java.lang.ClassFormatError: Weaving hook failed.
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2479)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2152)
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1607)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at 
> org.javacord.core.util.logging.ExceptionLoggerDelegateImpl.(ExceptionLoggerDelegateImpl.java:20)
>   at 
> org.javacord.core.util.DelegateFactoryDelegateImpl.createExceptionLoggerDelegate(DelegateFactoryDelegateImpl.java:180)
>   at 
> org.javacord.api.util.internal.DelegateFactory.(DelegateFactory.java:74)
>   at org.javacord.api.DiscordApiBuilder.(DiscordApiBuilder.java:20)
>   at net.kautler.test.osgi.OsgiTest.start(OsgiTest.java:17)
>   at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
>   at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
>   at org.apache.felix.framework.Felix.startBundle(Felix.java:2146)
>   at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373)
>   at 
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: value null
>   at org.objectweb.asm.ClassWriter.newConstItem(ClassWriter.java:1057)
>   at org.objectweb.asm.MethodWriter.visitLdcInsn(MethodWriter.java:1126)
>   at 
> org.apache.aries.spifly.weaver.TCCLSetterVisitor$TCCLSetterMethodVisitor.visitMethodInsn(TCCLSetterVisitor.java:194)
>   at org.objectweb.asm.ClassReader.readCode(ClassReader.java:1416)
>   at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1017)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:693)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:506)
>   at 
> org.apache.aries.spifly.dynamic.ClientWeavingHook.weave(ClientWeavingHook.java:61)
>   at 
> org.apache.felix.framework.util.SecureAction.invokeWeavingHook(SecureAction.java:1203)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2465)
>   ... 16 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1801) SPI Fly does not work with a dynamic class object

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1801:
-

I added a commit with an additional test:
https://svn.apache.org/viewvc?view=revision=1832236

I *think* that the test should be exactly what you're describing in this issue, 
but the test passes so it's probably missing something. 
[~vampire] would you be able to add/modify a test in the codebase which exposes 
the problem?

> SPI Fly does not work with a dynamic class object
> -
>
> Key: ARIES-1801
> URL: https://issues.apache.org/jira/browse/ARIES-1801
> Project: Aries
>  Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Björn Kautler
>Priority: Major
>
> SLF4J changes in version 1.8 how implementations are looked up to 
> {{java.util.ServiceLoader}}.
> In our codebase we dynamically search for an SLF4J implementation and use a 
> default logger if none is found.
> To adapt to the new mechanism but remain compatible with SLF4J 1.7 I added to 
> our codebase
> {code:java}
> try {
> // post-1.8 mechanism
> Class slf4jServiceProviderClass = 
> Class.forName("org.slf4j.spi.SLF4JServiceProvider");
> if (ServiceLoader.load(slf4jServiceProviderClass).iterator().hasNext()) {
> noLogger.set(false);
> return true;
> }
> } catch (ClassNotFoundException e) {
> // ignore
> }
> {code}
> If I now use the {{org.apache.aries.spifly.dynamic.bundle}} 1.0.10, I get an 
> exception as SPI Fly seemingly only supports class constants. While 
> traversing the ASM tree it remembers the last class constant seen and uses 
> that to transform the {{load}} call.
> Here the exception I get:
> {code:java}
> java.lang.ClassFormatError: Weaving hook failed.
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2479)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2152)
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1607)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at 
> org.javacord.core.util.logging.ExceptionLoggerDelegateImpl.(ExceptionLoggerDelegateImpl.java:20)
>   at 
> org.javacord.core.util.DelegateFactoryDelegateImpl.createExceptionLoggerDelegate(DelegateFactoryDelegateImpl.java:180)
>   at 
> org.javacord.api.util.internal.DelegateFactory.(DelegateFactory.java:74)
>   at org.javacord.api.DiscordApiBuilder.(DiscordApiBuilder.java:20)
>   at net.kautler.test.osgi.OsgiTest.start(OsgiTest.java:17)
>   at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
>   at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
>   at org.apache.felix.framework.Felix.startBundle(Felix.java:2146)
>   at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373)
>   at 
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: value null
>   at org.objectweb.asm.ClassWriter.newConstItem(ClassWriter.java:1057)
>   at org.objectweb.asm.MethodWriter.visitLdcInsn(MethodWriter.java:1126)
>   at 
> org.apache.aries.spifly.weaver.TCCLSetterVisitor$TCCLSetterMethodVisitor.visitMethodInsn(TCCLSetterVisitor.java:194)
>   at org.objectweb.asm.ClassReader.readCode(ClassReader.java:1416)
>   at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1017)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:693)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:506)
>   at 
> org.apache.aries.spifly.dynamic.ClientWeavingHook.weave(ClientWeavingHook.java:61)
>   at 
> org.apache.felix.framework.util.SecureAction.invokeWeavingHook(SecureAction.java:1203)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2465)
>   ... 16 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1801) SPI Fly does not work with a dynamic class object

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1801:
-

Hmm, but when I run the test with the two lines you quoted commented out, the 
test still passes. Or am I missing something?

> SPI Fly does not work with a dynamic class object
> -
>
> Key: ARIES-1801
> URL: https://issues.apache.org/jira/browse/ARIES-1801
> Project: Aries
>  Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Björn Kautler
>Priority: Major
>
> SLF4J changes in version 1.8 how implementations are looked up to 
> {{java.util.ServiceLoader}}.
> In our codebase we dynamically search for an SLF4J implementation and use a 
> default logger if none is found.
> To adapt to the new mechanism but remain compatible with SLF4J 1.7 I added to 
> our codebase
> {code:java}
> try {
> // post-1.8 mechanism
> Class slf4jServiceProviderClass = 
> Class.forName("org.slf4j.spi.SLF4JServiceProvider");
> if (ServiceLoader.load(slf4jServiceProviderClass).iterator().hasNext()) {
> noLogger.set(false);
> return true;
> }
> } catch (ClassNotFoundException e) {
> // ignore
> }
> {code}
> If I now use the {{org.apache.aries.spifly.dynamic.bundle}} 1.0.10, I get an 
> exception as SPI Fly seemingly only supports class constants. While 
> traversing the ASM tree it remembers the last class constant seen and uses 
> that to transform the {{load}} call.
> Here the exception I get:
> {code:java}
> java.lang.ClassFormatError: Weaving hook failed.
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2479)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2152)
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1607)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at 
> org.javacord.core.util.logging.ExceptionLoggerDelegateImpl.(ExceptionLoggerDelegateImpl.java:20)
>   at 
> org.javacord.core.util.DelegateFactoryDelegateImpl.createExceptionLoggerDelegate(DelegateFactoryDelegateImpl.java:180)
>   at 
> org.javacord.api.util.internal.DelegateFactory.(DelegateFactory.java:74)
>   at org.javacord.api.DiscordApiBuilder.(DiscordApiBuilder.java:20)
>   at net.kautler.test.osgi.OsgiTest.start(OsgiTest.java:17)
>   at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
>   at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
>   at org.apache.felix.framework.Felix.startBundle(Felix.java:2146)
>   at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373)
>   at 
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: value null
>   at org.objectweb.asm.ClassWriter.newConstItem(ClassWriter.java:1057)
>   at org.objectweb.asm.MethodWriter.visitLdcInsn(MethodWriter.java:1126)
>   at 
> org.apache.aries.spifly.weaver.TCCLSetterVisitor$TCCLSetterMethodVisitor.visitMethodInsn(TCCLSetterVisitor.java:194)
>   at org.objectweb.asm.ClassReader.readCode(ClassReader.java:1416)
>   at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1017)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:693)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:506)
>   at 
> org.apache.aries.spifly.dynamic.ClientWeavingHook.weave(ClientWeavingHook.java:61)
>   at 
> org.apache.felix.framework.util.SecureAction.invokeWeavingHook(SecureAction.java:1203)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2465)
>   ... 16 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-619) Fix SPI-FLY and SUBSYSTEM tio use release by bundle scheme

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-619:


This is a very old issue and I'm not sure it's still relevant. [~zoe] 
[~hughesj] do you think we still need this, or can the issue be closed?

> Fix SPI-FLY and SUBSYSTEM tio use release by bundle scheme
> --
>
> Key: ARIES-619
> URL: https://issues.apache.org/jira/browse/ARIES-619
> Project: Aries
>  Issue Type: Bug
>Reporter: zoe slattery
>Assignee: Jeremy Hughes
>Priority: Major
>
> In summary:
> Split parent and reactor poms (Reactor just contains a list of modules, no 
> SCM element)
> Add packageinfo files for package export versions
> Make each bundle pom depend on the 0.4 released parent (if possible)
> Switch depenedencies to point at released versions (where possible)
> Add an SCM element to each modules pom.
> Fix build warnings caused by default settings for maven-bundle-plugin



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1470) java.util.ServiceConfigurationError

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1470:
-

[~setya] Is this issue still relevant, or can we close it?

> java.util.ServiceConfigurationError
> ---
>
> Key: ARIES-1470
> URL: https://issues.apache.org/jira/browse/ARIES-1470
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.6
> Environment: Eclipse Virgo Jetty Server 3.6.4, Spring Framework 3.2.5
>Reporter: Setya
>Priority: Major
>
> Deploying application that relies on 3rd party framework that's using 
> ServiceLoader into Eclipse Virgo intermittenly causes the following exception 
> to be thrown:
> Caused by: java.util.ServiceConfigurationError: 
> org.axonframework.serializer.ContentTypeConverter: Provider 
> org.axonframework.serializer.converters.ByteArrayToInputStreamConverter not a 
> subtype
>   at java.util.ServiceLoader.fail(ServiceLoader.java:231)
>   at java.util.ServiceLoader.access$300(ServiceLoader.java:181)
>   at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369)
>   at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
>   at 
> org.axonframework.serializer.ChainingConverterFactory.(ChainingConverterFactory.java:51)
>   at 
> org.axonframework.serializer.AbstractXStreamSerializer.(AbstractXStreamSerializer.java:106)
>   at 
> org.axonframework.serializer.AbstractXStreamSerializer.(AbstractXStreamSerializer.java:81)
>   at 
> org.axonframework.serializer.AbstractXStreamSerializer.(AbstractXStreamSerializer.java:70)
>   at 
> org.axonframework.serializer.xml.XStreamSerializer.(XStreamSerializer.java:53)
>   at 
> org.axonframework.contextsupport.spring.FileSystemEventStoreBeanDefinitionParser.doParse(FileSystemEventStoreBeanDefinitionParser.java:76)
>   at 
> org.springframework.beans.factory.xml.AbstractSingleBeanDefinitionParser.parseInternal(AbstractSingleBeanDefinitionParser.java:85)
>   at 
> org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59)
>   at 
> org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
>   at 
> org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1438)
>   at 
> org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1428)
>   at 
> org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:195)
>   at 
> org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.doRegisterBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:139)
>   at 
> org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:108)
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
>   ... 21 common frames omitted
> Have tried to weave static bundle using SPI Fly, but the problem persists.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (ARIES-938) Proposal: SPI Catch (plug-in discovery for both plain Java >=5 and OSGi)

[David Bosschaert (JIRA)]

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

David Bosschaert closed ARIES-938.
--
Resolution: Won't Do

> Proposal: SPI Catch (plug-in discovery for both plain Java >=5 and OSGi)
> 
>
> Key: ARIES-938
> URL: https://issues.apache.org/jira/browse/ARIES-938
> Project: Aries
>  Issue Type: New Feature
>Reporter: Jeremias Maerki
>Priority: Major
> Attachments: spi-catch.zip
>
>
> As discussed in http://aries.markmail.org/thread/i2vgjryf5caitqmy I propose a 
> new component for Apache Aries, code-named "SPI Catch", as a complement to 
> SPI Fly.
> SPI Catch provides an abstraction to plug-in discovery that for libraries 
> that make use of the JAR service provider mechanism (through 
> META-INF/services) to discover plug-ins. It shields the client from OSGi 
> specifics but all the same offering the dynamics provided through the OSGi 
> service registry. It is an deal counter-part to Apache Aries SPI Fly which is 
> used to publish SPI providers as OSGi services. And finally, another focus is 
> on preserving the runnability totally outside of OSGi.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1801) SPI Fly does not work with a dynamic class object

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1801:
-

Interestingly enough, there seems to be a test for this use case:

The method testClientSpecifyingDifferentMethodsLimitedToDifferentProviders() in 
https://svn.apache.org/repos/asf/aries/trunk/spi-fly/spi-fly-dynamic-bundle/src/test/java/org/apache/aries/spifly/dynamic/ClientWeavingHookTest.java
internally exercises the testService() method in 
https://svn.apache.org/repos/asf/aries/trunk/spi-fly/spi-fly-dynamic-bundle/src/test/java/org/apache/aries/spifly/dynamic/TestClient.java
 which passes a Class object which is a parameter to the method to 
ServiceLoader.load()

So I guess the question is: how is the use-case filed in this issue different?

> SPI Fly does not work with a dynamic class object
> -
>
> Key: ARIES-1801
> URL: https://issues.apache.org/jira/browse/ARIES-1801
> Project: Aries
>  Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Björn Kautler
>Priority: Major
>
> SLF4J changes in version 1.8 how implementations are looked up to 
> {{java.util.ServiceLoader}}.
> In our codebase we dynamically search for an SLF4J implementation and use a 
> default logger if none is found.
> To adapt to the new mechanism but remain compatible with SLF4J 1.7 I added to 
> our codebase
> {code:java}
> try {
> // post-1.8 mechanism
> Class slf4jServiceProviderClass = 
> Class.forName("org.slf4j.spi.SLF4JServiceProvider");
> if (ServiceLoader.load(slf4jServiceProviderClass).iterator().hasNext()) {
> noLogger.set(false);
> return true;
> }
> } catch (ClassNotFoundException e) {
> // ignore
> }
> {code}
> If I now use the {{org.apache.aries.spifly.dynamic.bundle}} 1.0.10, I get an 
> exception as SPI Fly seemingly only supports class constants. While 
> traversing the ASM tree it remembers the last class constant seen and uses 
> that to transform the {{load}} call.
> Here the exception I get:
> {code:java}
> java.lang.ClassFormatError: Weaving hook failed.
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2479)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2152)
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1607)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at 
> org.javacord.core.util.logging.ExceptionLoggerDelegateImpl.(ExceptionLoggerDelegateImpl.java:20)
>   at 
> org.javacord.core.util.DelegateFactoryDelegateImpl.createExceptionLoggerDelegate(DelegateFactoryDelegateImpl.java:180)
>   at 
> org.javacord.api.util.internal.DelegateFactory.(DelegateFactory.java:74)
>   at org.javacord.api.DiscordApiBuilder.(DiscordApiBuilder.java:20)
>   at net.kautler.test.osgi.OsgiTest.start(OsgiTest.java:17)
>   at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
>   at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
>   at org.apache.felix.framework.Felix.startBundle(Felix.java:2146)
>   at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373)
>   at 
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: value null
>   at org.objectweb.asm.ClassWriter.newConstItem(ClassWriter.java:1057)
>   at org.objectweb.asm.MethodWriter.visitLdcInsn(MethodWriter.java:1126)
>   at 
> org.apache.aries.spifly.weaver.TCCLSetterVisitor$TCCLSetterMethodVisitor.visitMethodInsn(TCCLSetterVisitor.java:194)
>   at org.objectweb.asm.ClassReader.readCode(ClassReader.java:1416)
>   at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1017)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:693)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:506)
>   at 
> org.apache.aries.spifly.dynamic.ClientWeavingHook.weave(ClientWeavingHook.java:61)
>   at 
> org.apache.felix.framework.util.SecureAction.invokeWeavingHook(SecureAction.java:1203)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2465)
>   ... 16 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ARIES-1766) Configure log severity for Whiteboard JMX registration exceptions

[David Bosschaert (JIRA)]

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

David Bosschaert resolved ARIES-1766.
-
Resolution: Fixed

Fixed with 
https://github.com/apache/aries/commit/e31a947fee0843ce8f09d01d9139ee837db77681

> Configure log severity for Whiteboard JMX registration exceptions
> -
>
> Key: ARIES-1766
> URL: https://issues.apache.org/jira/browse/ARIES-1766
> Project: Aries
>  Issue Type: Bug
>  Components: JMX
>Affects Versions: jmx-1.1.5
>Reporter: David Bosschaert
>Assignee: David Bosschaert
>Priority: Major
> Fix For: jmx-whiteboard-1.2.0
>
>
> When Aries JMX Whiteboard registers MBeans (in 
> {{org.apache.aries.jmx.whiteboard.MBeanHolder}}) a number of exceptions, 
> including {{InstanceAlreadyExistsException}} are caught and logged at 
> {{error}} level. 
> Depending on the context these messages may not really be errors, but rather 
> warnings. It would be good to be able to configure Aries JMX wrt to how these 
> exceptions are logged, allowing certain ones to appear as warnings in the log 
> instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARIES-1321) NPE when calling ServiceLoader.load with a variable

[David Bosschaert (JIRA)]

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

David Bosschaert updated ARIES-1321:

Fix Version/s: spifly-1.0.12

> NPE when calling ServiceLoader.load with a variable
> ---
>
> Key: ARIES-1321
> URL: https://issues.apache.org/jira/browse/ARIES-1321
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.2
>Reporter: Olivier NOUGUIER
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: spifly-1.0.12
>
> Attachments: ARIES-1321.diff
>
>
> When ServiceLoader is called with a variable (aka not a constant):
> aMethod(Class type ){
>   ServiceLoader.load(type).
> }
> Then the weaver result in a NPE in TCCLMethodVisitor because lastLDCType is 
> null.
> Patch provided.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (ARIES-1752) Upgrade to ASM 6.0

[David Bosschaert (JIRA)]

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

David Bosschaert resolved ARIES-1752.
-
Resolution: Fixed

> Upgrade to ASM 6.0
> --
>
> Key: ARIES-1752
> URL: https://issues.apache.org/jira/browse/ARIES-1752
> Project: Aries
>  Issue Type: Dependency upgrade
>  Components: SPI Fly
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
> Fix For: spifly-1.0.10
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ARIES-1321) NPE when calling ServiceLoader.load with a variable

[David Bosschaert (JIRA)]

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

David Bosschaert updated ARIES-1321:

Fix Version/s: (was: spifly-1.0.10)

> NPE when calling ServiceLoader.load with a variable
> ---
>
> Key: ARIES-1321
> URL: https://issues.apache.org/jira/browse/ARIES-1321
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.2
>Reporter: Olivier NOUGUIER
>Assignee: David Bosschaert
>Priority: Critical
> Attachments: ARIES-1321.diff
>
>
> When ServiceLoader is called with a variable (aka not a constant):
> aMethod(Class type ){
>   ServiceLoader.load(type).
> }
> Then the weaver result in a NPE in TCCLMethodVisitor because lastLDCType is 
> null.
> Patch provided.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (ARIES-1321) NPE when calling ServiceLoader.load with a variable

[David Bosschaert (JIRA)]

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

David Bosschaert resolved ARIES-1321.
-
   Resolution: Fixed
Fix Version/s: spifly-1.0.10

> NPE when calling ServiceLoader.load with a variable
> ---
>
> Key: ARIES-1321
> URL: https://issues.apache.org/jira/browse/ARIES-1321
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.2
>Reporter: Olivier NOUGUIER
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: spifly-1.0.10
>
> Attachments: ARIES-1321.diff
>
>
> When ServiceLoader is called with a variable (aka not a constant):
> aMethod(Class type ){
>   ServiceLoader.load(type).
> }
> Then the weaver result in a NPE in TCCLMethodVisitor because lastLDCType is 
> null.
> Patch provided.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (ARIES-1321) NPE when calling ServiceLoader.load with a variable

[David Bosschaert (JIRA)]

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

David Bosschaert reassigned ARIES-1321:
---

Assignee: David Bosschaert

> NPE when calling ServiceLoader.load with a variable
> ---
>
> Key: ARIES-1321
> URL: https://issues.apache.org/jira/browse/ARIES-1321
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.2
>Reporter: Olivier NOUGUIER
>Assignee: David Bosschaert
>Priority: Critical
> Attachments: ARIES-1321.diff
>
>
> When ServiceLoader is called with a variable (aka not a constant):
> aMethod(Class type ){
>   ServiceLoader.load(type).
> }
> Then the weaver result in a NPE in TCCLMethodVisitor because lastLDCType is 
> null.
> Patch provided.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ARIES-1766) Configure log severity for Whiteboard JMX registration exceptions

[David Bosschaert (JIRA)]

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

David Bosschaert updated ARIES-1766:

Fix Version/s: jmx-whiteboard-1.2.0

> Configure log severity for Whiteboard JMX registration exceptions
> -
>
> Key: ARIES-1766
> URL: https://issues.apache.org/jira/browse/ARIES-1766
> Project: Aries
>  Issue Type: Bug
>  Components: JMX
>Affects Versions: jmx-1.1.5
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: jmx-whiteboard-1.2.0
>
>
> When Aries JMX Whiteboard registers MBeans (in 
> {{org.apache.aries.jmx.whiteboard.MBeanHolder}}) a number of exceptions, 
> including {{InstanceAlreadyExistsException}} are caught and logged at 
> {{error}} level. 
> Depending on the context these messages may not really be errors, but rather 
> warnings. It would be good to be able to configure Aries JMX wrt to how these 
> exceptions are logged, allowing certain ones to appear as warnings in the log 
> instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ARIES-1630) jmx core fails if configadmin is not present

[David Bosschaert (JIRA)]

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

David Bosschaert updated ARIES-1630:

Fix Version/s: jmx-whiteboard-1.2.0

> jmx core fails if configadmin is not present
> 
>
> Key: ARIES-1630
> URL: https://issues.apache.org/jira/browse/ARIES-1630
> Project: Aries
>  Issue Type: Bug
>  Components: JMX
>Affects Versions: jmx-core-1.1.7
>Reporter: Christian Schneider
>Assignee: Christian Schneider
> Fix For: jmx-core-1.1.8, jmx-whiteboard-1.2.0
>
>
> JMX core claims it has an optional dependency to config admin. In the 
> Activator though it directly accesses StateConfig which depends on config 
> admin. 
> So the fix is to make config admin spec mandatory.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ARIES-1707) The BlueprintMetadata.getBlueprintContainer throws inconsistent exceptions

[David Bosschaert (JIRA)]

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

David Bosschaert updated ARIES-1707:

Fix Version/s: (was: jmx-1.2.0)
   jmx-blueprint-core-1.2.0
   jmx-blueprint-api-1.2.0

> The BlueprintMetadata.getBlueprintContainer throws inconsistent exceptions
> --
>
> Key: ARIES-1707
> URL: https://issues.apache.org/jira/browse/ARIES-1707
> Project: Aries
>  Issue Type: Bug
>  Components: JMX
>Reporter: Hao Zhong
>Assignee: Guillaume Nodet
> Fix For: jmx-blueprint-api-1.2.0, jmx-blueprint-core-1.2.0
>
> Attachments: aries.patch
>
>
> The BlueprintMetadata_getBlueprintContainer method throws 
> IllegalArgumentException as follow:
> {code:title=BlueprintMetadata.java|borderStyle=solid}
>  if (serviceReferences == null || serviceReferences.length <1) {
> throw new IllegalArgumentException("Invalid BlueprintContainer 
> service id: " + containerServiceId);
> }
> {code}
> However, the FrameworkUtils_resolveService method throws IOException for the 
> same condition:
> {code:title=FrameworkUtils.java|borderStyle=solid}
> if (references == null || references.length < 1) {
> throw new IOException("Service with id [" + serviceId + "] 
> not found");
> } else {
> result = references[0];
> }
> {code}
> This is confusing. Indeed, I notice that the buggy code of ARIES-333 throws 
> IllegalArgumentException, but the fixed code throws IOException.
> The current BlueprintMetadata.java shall be modified to eliminate the 
> confusing.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARIES-1766) Configure log severity for Whiteboard JMX registration exceptions

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1766:
-

I implemented a fix in: 
https://svn.apache.org/viewvc?view=revision=1818103

This fix uses an extra service registration property {{warning.exceptions}}. 
Set the exception class names on that service registration property that are 
considered warnings to get them logged as warning.

> Configure log severity for Whiteboard JMX registration exceptions
> -
>
> Key: ARIES-1766
> URL: https://issues.apache.org/jira/browse/ARIES-1766
> Project: Aries
>  Issue Type: Bug
>  Components: JMX
>Affects Versions: jmx-1.1.5
>Reporter: David Bosschaert
>Assignee: David Bosschaert
>
> When Aries JMX Whiteboard registers MBeans (in 
> {{org.apache.aries.jmx.whiteboard.MBeanHolder}}) a number of exceptions, 
> including {{InstanceAlreadyExistsException}} are caught and logged at 
> {{error}} level. 
> Depending on the context these messages may not really be errors, but rather 
> warnings. It would be good to be able to configure Aries JMX wrt to how these 
> exceptions are logged, allowing certain ones to appear as warnings in the log 
> instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (ARIES-1766) Configure log severity for Whiteboard JMX registration exceptions

[David Bosschaert (JIRA)]

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

David Bosschaert reassigned ARIES-1766:
---

Assignee: David Bosschaert

> Configure log severity for Whiteboard JMX registration exceptions
> -
>
> Key: ARIES-1766
> URL: https://issues.apache.org/jira/browse/ARIES-1766
> Project: Aries
>  Issue Type: Bug
>  Components: JMX
>Affects Versions: jmx-1.1.5
>Reporter: David Bosschaert
>Assignee: David Bosschaert
>
> When Aries JMX Whiteboard registers MBeans (in 
> {{org.apache.aries.jmx.whiteboard.MBeanHolder}}) a number of exceptions, 
> including {{InstanceAlreadyExistsException}} are caught and logged at 
> {{error}} level. 
> Depending on the context these messages may not really be errors, but rather 
> warnings. It would be good to be able to configure Aries JMX wrt to how these 
> exceptions are logged, allowing certain ones to appear as warnings in the log 
> instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (ARIES-1766) Configure log severity for Whiteboard JMX registration exceptions

[David Bosschaert (JIRA)]

David Bosschaert created ARIES-1766:
---

 Summary: Configure log severity for Whiteboard JMX registration 
exceptions
 Key: ARIES-1766
 URL: https://issues.apache.org/jira/browse/ARIES-1766
 Project: Aries
  Issue Type: Bug
  Components: JMX
Affects Versions: jmx-1.1.5
Reporter: David Bosschaert


When Aries JMX Whiteboard registers MBeans (in 
{{org.apache.aries.jmx.whiteboard.MBeanHolder}}) a number of exceptions, 
including {{InstanceAlreadyExistsException}} are caught and logged at {{error}} 
level. 

Depending on the context these messages may not really be errors, but rather 
warnings. It would be good to be able to configure Aries JMX wrt to how these 
exceptions are logged, allowing certain ones to appear as warnings in the log 
instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARIES-1746) SPIFly support for InitialContextFactory

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1746:
-

[~Thusitha] do you think you have time to contribute such a separate bundle as 
mentioned in my previous comment to SPI-Fly?

> SPIFly support for InitialContextFactory
> 
>
> Key: ARIES-1746
> URL: https://issues.apache.org/jira/browse/ARIES-1746
> Project: Aries
>  Issue Type: Improvement
>  Components: SPI Fly
>Reporter: Thusitha Thilina Dayaratne
>
> I'm trying to use Aries SPYFly with one of our projects. According to the 
> OSGi spec when we register an InitialContextFactory, we need to register that 
> for both implementation and InitialContextFactory classes.
> IMHO it would be great if we can support that with SPY-Fly



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (ARIES-1746) SPIFly support for InitialContextFactory

[David Bosschaert (JIRA)]

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

David Bosschaert reassigned ARIES-1746:
---

Assignee: (was: David Bosschaert)

> SPIFly support for InitialContextFactory
> 
>
> Key: ARIES-1746
> URL: https://issues.apache.org/jira/browse/ARIES-1746
> Project: Aries
>  Issue Type: Improvement
>  Components: SPI Fly
>Reporter: Thusitha Thilina Dayaratne
>
> I'm trying to use Aries SPYFly with one of our projects. According to the 
> OSGi spec when we register an InitialContextFactory, we need to register that 
> for both implementation and InitialContextFactory classes.
> IMHO it would be great if we can support that with SPY-Fly



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARIES-1746) SPIFly support for InitialContextFactory

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1746:
-

Hi [~Thusitha], I agree that it could be a feature that could benefit others, 
but it would be specific to using SPI-Fly in combination with JNDI. What we 
*could* do is create a separate module in the SPI-Fly codebase for the 
SPI-Fly/JNDI integration, where we could put such code for others to reuse.

It would still be a separate bundle though, I think it should not be mixed in 
with the core SPI-Fly component.

Feel free to contribute such a bundle, if you have the time to this :)

> SPIFly support for InitialContextFactory
> 
>
> Key: ARIES-1746
> URL: https://issues.apache.org/jira/browse/ARIES-1746
> Project: Aries
>  Issue Type: Improvement
>  Components: SPI Fly
>Reporter: Thusitha Thilina Dayaratne
>Assignee: David Bosschaert
>
> I'm trying to use Aries SPYFly with one of our projects. According to the 
> OSGi spec when we register an InitialContextFactory, we need to register that 
> for both implementation and InitialContextFactory classes.
> IMHO it would be great if we can support that with SPY-Fly



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (ARIES-1746) SPIFly support for InitialContextFactory

[David Bosschaert (JIRA)]

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

David Bosschaert reassigned ARIES-1746:
---

Assignee: David Bosschaert

> SPIFly support for InitialContextFactory
> 
>
> Key: ARIES-1746
> URL: https://issues.apache.org/jira/browse/ARIES-1746
> Project: Aries
>  Issue Type: Improvement
>  Components: SPI Fly
>Reporter: Thusitha Thilina Dayaratne
>Assignee: David Bosschaert
>
> I'm trying to use Aries SPYFly with one of our projects. According to the 
> OSGi spec when we register an InitialContextFactory, we need to register that 
> for both implementation and InitialContextFactory classes.
> IMHO it would be great if we can support that with SPY-Fly



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARIES-1746) SPIFly support for InitialContextFactory

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1746:
-

That change is very specific to the javax.naming.spi.InitialContextFactory and 
does not belong in SPI-Fly IMHO.

A more generic way to do this would be to get your own bundle to do this. 
Basically you have a service tracker or something like this listen for the 
service that is registered by SPI-Fly. The you can register the same service 
object in your own code under the {{javax.naming.spi.InitialContextFactory}} 
interface.

Something like this:

{code}
List handled = new 
CopyOnWriteArrayList<>();

public void start() {
BundleContext context = null;
ServiceTracker tracker = 
new ServiceTracker(context, 
InitialContextFactory.class, null) {
@Override
public InitialContextFactory 
addingService(ServiceReference reference) {
InitialContextFactory svc = super.addingService(reference);
if (!handled.contains(reference)) { // only process services 
once
handled.add(reference);

String implClass = svc.getClass().getName();
String[] objClass = (String[]) 
reference.getProperty("objectClass");
List newObjClasses = Arrays.asList(objClass);
newObjClasses.add(implClass);

context.registerService(newObjClasses.toArray(new String [] 
{}), svc, reference.getProperties());
}
return svc;
}
};
tracker.open();
}
{code}

Hope this works for you?

> SPIFly support for InitialContextFactory
> 
>
> Key: ARIES-1746
> URL: https://issues.apache.org/jira/browse/ARIES-1746
> Project: Aries
>  Issue Type: Improvement
>  Components: SPI Fly
>Reporter: Thusitha Thilina Dayaratne
>
> I'm trying to use Aries SPYFly with one of our projects. According to the 
> OSGi spec when we register an InitialContextFactory, we need to register that 
> for both implementation and InitialContextFactory classes.
> IMHO it would be great if we can support that with SPY-Fly



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ARIES-1443) After a restart the capabilities of a subsystem have changed (seem correct) before the restart they seem wrong

[David Bosschaert (JIRA)]

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

David Bosschaert updated ARIES-1443:

Fix Version/s: (was: subsystem-2.0.10)
   subsystem-2.0.12

> After a restart the capabilities of a subsystem have changed (seem correct) 
> before the restart they seem wrong
> --
>
> Key: ARIES-1443
> URL: https://issues.apache.org/jira/browse/ARIES-1443
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.6, subsystem-2.0.8
> Environment: karaf pax-exam
>Reporter: Bas
>  Labels: test-patch
> Fix For: subsystem-2.0.12
>
> Attachments: CapabilitiesDifferOnRestart.java.patch, 
> pax-web-jetty-bundle-4.2.5.jar
>
>
> A feature subsystem should export all capabilities of its constituents and it 
> does not do that after a fresh install. After a restart of the subsystem core 
> bundle it will export all the capabilities. 
> These seems to be a difference in parsing the capabilities of a persisted 
> subsystem and a new subsystem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (ARIES-1443) After a restart the capabilities of a subsystem have changed (seem correct) before the restart they seem wrong

[David Bosschaert (JIRA)]

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

David Bosschaert reassigned ARIES-1443:
---

Assignee: (was: John Ross)

> After a restart the capabilities of a subsystem have changed (seem correct) 
> before the restart they seem wrong
> --
>
> Key: ARIES-1443
> URL: https://issues.apache.org/jira/browse/ARIES-1443
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.6, subsystem-2.0.8
> Environment: karaf pax-exam
>Reporter: Bas
>  Labels: test-patch
> Fix For: subsystem-2.0.10
>
> Attachments: CapabilitiesDifferOnRestart.java.patch, 
> pax-web-jetty-bundle-4.2.5.jar
>
>
> A feature subsystem should export all capabilities of its constituents and it 
> does not do that after a fresh install. After a restart of the subsystem core 
> bundle it will export all the capabilities. 
> These seems to be a difference in parsing the capabilities of a persisted 
> subsystem and a new subsystem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (ARIES-1547) Subsystem 2.0.10 Release

[David Bosschaert (JIRA)]

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

David Bosschaert reassigned ARIES-1547:
---

Assignee: David Bosschaert  (was: John Ross)

> Subsystem 2.0.10 Release
> 
>
> Key: ARIES-1547
> URL: https://issues.apache.org/jira/browse/ARIES-1547
> Project: Aries
>  Issue Type: Task
>  Components: Subsystem
>Reporter: John Ross
>Assignee: David Bosschaert
> Fix For: subsystem-2.0.10
>
>
> 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.4.14#64029)

[jira] [Updated] (ARIES-1547) Subsystem 2.0.10 Release

[David Bosschaert (JIRA)]

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

David Bosschaert updated ARIES-1547:

Summary: Subsystem 2.0.10 Release  (was: Subsystem 2.1.0 Release)

> Subsystem 2.0.10 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.0.10
>
>
> 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.4.14#64029)

[jira] [Created] (ARIES-1718) Please create a Project Space for the Apache Aries

[David Bosschaert (JIRA)]

David Bosschaert created ARIES-1718:
---

 Summary: Please create a Project Space for the Apache Aries
 Key: ARIES-1718
 URL: https://issues.apache.org/jira/browse/ARIES-1718
 Project: Aries
  Issue Type: New Confluence Wiki
Reporter: David Bosschaert






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

[jira] [Updated] (ARIES-1650) Maven plugin no longer includes non-bundle artifacts

[David Bosschaert (JIRA)]

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

David Bosschaert updated ARIES-1650:

Fix Version/s: (was: esa-maven-plugin-1.0.0)
   esa-maven-plugin-1.0.2

> Maven plugin no longer includes non-bundle artifacts
> 
>
> Key: ARIES-1650
> URL: https://issues.apache.org/jira/browse/ARIES-1650
> Project: Aries
>  Issue Type: Improvement
>  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.2
>
>
> The ESA Maven plugin currently includes artifacts in the ESA Archive 
> regardless of whether these artifacts are OSGi bundles. Non-bundle artifacts 
> included in the ESA Archive cause issues while installing the subsystem. 
> The ESA Maven Plugin should be adapted to either log warnings or fail when 
> trying to include a non-bundle artifact in the archive. Detecting whether an 
> artifact is a bundle can be done by checking if the Bundle-SymbolicName 
> header is present in the manifest.
> Example error when trying to install an archive containing a non-bundle 
> artifact:
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.aries.subsystem.core.archive.FragmentHostCapability.initializeAttributes(FragmentHostCapability.java:38)
>   at 
> org.apache.aries.subsystem.core.archive.FragmentHostCapability.(FragmentHostCapability.java:67)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.computeOsgiWiringHostCapability(BundleResource.java:191)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.computeRequirementsOtherThanService(BundleResource.java:245)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.computeRequirementsAndCapabilities(BundleResource.java:216)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.(BundleResource.java:74)
>   at 
> org.apache.aries.subsystem.core.internal.RawSubsystemResource.addResource(RawSubsystemResource.java:444)
>   at 
> org.apache.aries.subsystem.core.internal.RawSubsystemResource.computeResources(RawSubsystemResource.java:429)
>   at 
> org.apache.aries.subsystem.core.internal.RawSubsystemResource.(RawSubsystemResource.java:131)
>   at 
> org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:90)
>   at 
> org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:54)
>   ... 37 more



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

[jira] [Resolved] (ARIES-1650) Maven plugin no longer includes non-bundle artifacts

[David Bosschaert (JIRA)]

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

David Bosschaert resolved ARIES-1650.
-
   Resolution: Fixed
Fix Version/s: esa-maven-plugin-1.0.0

> Maven plugin no longer includes non-bundle artifacts
> 
>
> Key: ARIES-1650
> URL: https://issues.apache.org/jira/browse/ARIES-1650
> Project: Aries
>  Issue Type: Improvement
>  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
>
>
> The ESA Maven plugin currently includes artifacts in the ESA Archive 
> regardless of whether these artifacts are OSGi bundles. Non-bundle artifacts 
> included in the ESA Archive cause issues while installing the subsystem. 
> The ESA Maven Plugin should be adapted to either log warnings or fail when 
> trying to include a non-bundle artifact in the archive. Detecting whether an 
> artifact is a bundle can be done by checking if the Bundle-SymbolicName 
> header is present in the manifest.
> Example error when trying to install an archive containing a non-bundle 
> artifact:
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.aries.subsystem.core.archive.FragmentHostCapability.initializeAttributes(FragmentHostCapability.java:38)
>   at 
> org.apache.aries.subsystem.core.archive.FragmentHostCapability.(FragmentHostCapability.java:67)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.computeOsgiWiringHostCapability(BundleResource.java:191)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.computeRequirementsOtherThanService(BundleResource.java:245)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.computeRequirementsAndCapabilities(BundleResource.java:216)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.(BundleResource.java:74)
>   at 
> org.apache.aries.subsystem.core.internal.RawSubsystemResource.addResource(RawSubsystemResource.java:444)
>   at 
> org.apache.aries.subsystem.core.internal.RawSubsystemResource.computeResources(RawSubsystemResource.java:429)
>   at 
> org.apache.aries.subsystem.core.internal.RawSubsystemResource.(RawSubsystemResource.java:131)
>   at 
> org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:90)
>   at 
> org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:54)
>   ... 37 more



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

[jira] [Commented] (ARIES-1650) Maven plugin no longer includes non-bundle artifacts

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1650:
-

Many thanks for the fix! It's committed in 
https://svn.apache.org/viewvc?view=revision=1785640

> Maven plugin no longer includes non-bundle artifacts
> 
>
> Key: ARIES-1650
> URL: https://issues.apache.org/jira/browse/ARIES-1650
> Project: Aries
>  Issue Type: Improvement
>  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
>
>
> The ESA Maven plugin currently includes artifacts in the ESA Archive 
> regardless of whether these artifacts are OSGi bundles. Non-bundle artifacts 
> included in the ESA Archive cause issues while installing the subsystem. 
> The ESA Maven Plugin should be adapted to either log warnings or fail when 
> trying to include a non-bundle artifact in the archive. Detecting whether an 
> artifact is a bundle can be done by checking if the Bundle-SymbolicName 
> header is present in the manifest.
> Example error when trying to install an archive containing a non-bundle 
> artifact:
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.aries.subsystem.core.archive.FragmentHostCapability.initializeAttributes(FragmentHostCapability.java:38)
>   at 
> org.apache.aries.subsystem.core.archive.FragmentHostCapability.(FragmentHostCapability.java:67)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.computeOsgiWiringHostCapability(BundleResource.java:191)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.computeRequirementsOtherThanService(BundleResource.java:245)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.computeRequirementsAndCapabilities(BundleResource.java:216)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.(BundleResource.java:74)
>   at 
> org.apache.aries.subsystem.core.internal.RawSubsystemResource.addResource(RawSubsystemResource.java:444)
>   at 
> org.apache.aries.subsystem.core.internal.RawSubsystemResource.computeResources(RawSubsystemResource.java:429)
>   at 
> org.apache.aries.subsystem.core.internal.RawSubsystemResource.(RawSubsystemResource.java:131)
>   at 
> org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:90)
>   at 
> org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:54)
>   ... 37 more



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

[jira] [Assigned] (ARIES-1650) Maven plugin no longer includes non-bundle artifacts

[David Bosschaert (JIRA)]

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

David Bosschaert reassigned ARIES-1650:
---

Assignee: David Bosschaert

> Maven plugin no longer includes non-bundle artifacts
> 
>
> Key: ARIES-1650
> URL: https://issues.apache.org/jira/browse/ARIES-1650
> Project: Aries
>  Issue Type: Improvement
>  Components: ESA Maven Plugin
>Affects Versions: esa-maven-plugin-1.0.0
>Reporter: Wouter Bancken
>Assignee: David Bosschaert
>
> The ESA Maven plugin currently includes artifacts in the ESA Archive 
> regardless of whether these artifacts are OSGi bundles. Non-bundle artifacts 
> included in the ESA Archive cause issues while installing the subsystem. 
> The ESA Maven Plugin should be adapted to either log warnings or fail when 
> trying to include a non-bundle artifact in the archive. Detecting whether an 
> artifact is a bundle can be done by checking if the Bundle-SymbolicName 
> header is present in the manifest.
> Example error when trying to install an archive containing a non-bundle 
> artifact:
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.aries.subsystem.core.archive.FragmentHostCapability.initializeAttributes(FragmentHostCapability.java:38)
>   at 
> org.apache.aries.subsystem.core.archive.FragmentHostCapability.(FragmentHostCapability.java:67)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.computeOsgiWiringHostCapability(BundleResource.java:191)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.computeRequirementsOtherThanService(BundleResource.java:245)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.computeRequirementsAndCapabilities(BundleResource.java:216)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.(BundleResource.java:74)
>   at 
> org.apache.aries.subsystem.core.internal.RawSubsystemResource.addResource(RawSubsystemResource.java:444)
>   at 
> org.apache.aries.subsystem.core.internal.RawSubsystemResource.computeResources(RawSubsystemResource.java:429)
>   at 
> org.apache.aries.subsystem.core.internal.RawSubsystemResource.(RawSubsystemResource.java:131)
>   at 
> org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:90)
>   at 
> org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:54)
>   ... 37 more



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

[jira] [Resolved] (ARIES-1490) The esa maven plugin provides more flexibility when creating the subsystem manifest

[David Bosschaert (JIRA)]

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

David Bosschaert resolved ARIES-1490.
-
   Resolution: Fixed
Fix Version/s: esa-maven-plugin-1.0.0

Many thanks for the patch, [~tom.dewolf]! It's applied in 
https://svn.apache.org/viewvc?view=revision=1785159

> 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] [Updated] (ARIES-1697) Create CDI component in ARIES JIRA project

[David Bosschaert (JIRA)]

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

David Bosschaert updated ARIES-1697:

Component/s: CDI

> Create CDI component in ARIES JIRA project
> --
>
> Key: ARIES-1697
> URL: https://issues.apache.org/jira/browse/ARIES-1697
> Project: Aries
>  Issue Type: Request
>  Components: CDI
>Reporter: Raymond Augé
>Assignee: David Bosschaert
>
> I'd like to request someone with JIRA powers to create a CDI component in the 
> ARIES project.



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

[jira] [Resolved] (ARIES-1697) Create CDI component in ARIES JIRA project

[David Bosschaert (JIRA)]

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

David Bosschaert resolved ARIES-1697.
-
Resolution: Fixed

Done :)

> Create CDI component in ARIES JIRA project
> --
>
> Key: ARIES-1697
> URL: https://issues.apache.org/jira/browse/ARIES-1697
> Project: Aries
>  Issue Type: Request
>  Components: CDI
>Reporter: Raymond Augé
>Assignee: David Bosschaert
>
> I'd like to request someone with JIRA powers to create a CDI component in the 
> ARIES project.



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

[jira] [Assigned] (ARIES-1697) Create CDI component in ARIES JIRA project

[David Bosschaert (JIRA)]

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

David Bosschaert reassigned ARIES-1697:
---

Assignee: David Bosschaert

> Create CDI component in ARIES JIRA project
> --
>
> Key: ARIES-1697
> URL: https://issues.apache.org/jira/browse/ARIES-1697
> Project: Aries
>  Issue Type: Request
>Reporter: Raymond Augé
>Assignee: David Bosschaert
>
> I'd like to request someone with JIRA powers to create a CDI component in the 
> ARIES project.



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

[jira] [Resolved] (ARIES-1665) Initial contribution of implementation of OSGi RFC-193

[David Bosschaert (JIRA)]

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

David Bosschaert resolved ARIES-1665.
-
Resolution: Fixed

Committed in the following commits with many thanks!

https://svn.apache.org/viewvc?view=revision=1780123
https://svn.apache.org/viewvc?view=revision=1780127

> Initial contribution of implementation of OSGi RFC-193
> --
>
> Key: ARIES-1665
> URL: https://issues.apache.org/jira/browse/ARIES-1665
> Project: Aries
>  Issue Type: New Feature
>Reporter: Raymond Augé
>Assignee: David Bosschaert
>
> This contribution will begin to implement *RFC-193 CDI Integration*
> https://github.com/osgi/design/blob/master/rfcs/rfc0193/rfc-0193-CDI-Integration.pdf



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1665) Initial contribution of implementation of OSGi RFC-193

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1665:
-

Hi [~gnt] would it help if the OSGi API was split in a separate commit?

> Initial contribution of implementation of OSGi RFC-193
> --
>
> Key: ARIES-1665
> URL: https://issues.apache.org/jira/browse/ARIES-1665
> Project: Aries
>  Issue Type: New Feature
>Reporter: Raymond Augé
>Assignee: David Bosschaert
>
> This contribution will begin to implement *RFC-193 CDI Integration*
> https://github.com/osgi/design/blob/master/rfcs/rfc0193/rfc-0193-CDI-Integration.pdf



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1665) Initial contribution of implementation of OSGi RFC-193

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1665:
-

I looked through the code and this is great. Many thanks [~rotty3000]! 

I'd like to commit this to /cdi in Aries SVN. Anyone any issues?

> Initial contribution of implementation of OSGi RFC-193
> --
>
> Key: ARIES-1665
> URL: https://issues.apache.org/jira/browse/ARIES-1665
> Project: Aries
>  Issue Type: New Feature
>Reporter: Raymond Augé
>Assignee: David Bosschaert
>
> This contribution will begin to implement *RFC-193 CDI Integration*
> https://github.com/osgi/design/blob/master/rfcs/rfc0193/rfc-0193-CDI-Integration.pdf



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (ARIES-1665) Initial contribution of implementation of OSGi RFC-193

[David Bosschaert (JIRA)]

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

David Bosschaert reassigned ARIES-1665:
---

Assignee: David Bosschaert

> Initial contribution of implementation of OSGi RFC-193
> --
>
> Key: ARIES-1665
> URL: https://issues.apache.org/jira/browse/ARIES-1665
> Project: Aries
>  Issue Type: New Feature
>Reporter: Raymond Augé
>Assignee: David Bosschaert
>
> This contribution will begin to implement *RFC-193 CDI Integration*
> https://github.com/osgi/design/blob/master/rfcs/rfc0193/rfc-0193-CDI-Integration.pdf



--
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

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1565:
-

I would not be in favour of adding a dependency to Google Guava for Aries 
Subsystems. This can cause issues if people use Guava in their own subsystems 
and they want a different version than the one used by Aries Subsystems. For 
the same reason I would not use Apache Commons just for a createTempFile() API. 
It should be easy to create this ourselves or why not switch to Java 7 which 
has Files.createTempDirectory().

> 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] [Resolved] (ARIES-1459) Installing subsystem with large number of constituents takes forever or gives out of memory

[David Bosschaert (JIRA)]

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

David Bosschaert resolved ARIES-1459.
-
Resolution: Fixed

I did not have time yet to try it with the latest resolver, but I'm closing 
this as fixed, as I assume that upgrading to the newer resolver will help as 
indicated. If I see it again I'll reopen.

> Installing subsystem with large number of constituents takes forever or gives 
> out of memory
> ---
>
> Key: ARIES-1459
> URL: https://issues.apache.org/jira/browse/ARIES-1459
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.6
>Reporter: David Bosschaert
>
> Installing a large subsystem that contains a lot of bundles can cause the 
> resolution phase to run for hours and sometimes causes out of memory, even 
> with a feature subsystem.
> I think this is caused by the fact that all the bundles inside the subsystem 
> are attempted to be resolved in one shot. When you have 200+ bundles that 
> gives an enormous resolution problem space.
> In a plain OSGi framework such a scenario can be helped by installing bundles 
> in stages, making life easier for the resolver. 
> Maybe subsystems can support this too. We could use the 'start-order' 
> directive on the Subsystem-Content header to guide resolution and only 
> resolve bundles on the current start-order as we progress through those.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1493) Investigate making the org.osgi.service.cm dependency optional rather than mandatory.

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1493:
-

No big issue, but the ConfigAdminContentHandler depends on it. This one is 
created and registered as a service in the main Activator. So we need to 
probably change the activator a little bit so that it does not register this 
service and does not cause any exceptions if the ConfigAdmin package is not 
available.

> Investigate making the org.osgi.service.cm dependency optional rather than 
> mandatory.
> -
>
> Key: ARIES-1493
> URL: https://issues.apache.org/jira/browse/ARIES-1493
> Project: Aries
>  Issue Type: Improvement
>  Components: Subsystem
>Affects Versions: subsystem-2.0.8
>Reporter: John Ross
>Priority: Minor
>
> The subsystem core bundle currently has a mandatory dependency on package 
> org.osgi.service.cm. I believe this was added as part of ARIES-1252. We 
> should make this optional if possible.
> David, do you see any issues with making this dependency optional?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1493) Investigate making the org.osgi.service.cm dependency optional rather than mandatory.

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1493:
-

Or... as friend suggested:

bq. Register as a ServiceFactory with the service name as a String (instead of 
XYZ.class.name()). Then the service is registered and once the API becomes 
available and the service is requested the ServiceFactory returns the actual 
instance. The cm package has to be DynamicImport-Package-ed for this to work.


> Investigate making the org.osgi.service.cm dependency optional rather than 
> mandatory.
> -
>
> Key: ARIES-1493
> URL: https://issues.apache.org/jira/browse/ARIES-1493
> Project: Aries
>  Issue Type: Improvement
>  Components: Subsystem
>Affects Versions: subsystem-2.0.8
>Reporter: John Ross
>Priority: Minor
>
> The subsystem core bundle currently has a mandatory dependency on package 
> org.osgi.service.cm. I believe this was added as part of ARIES-1252. We 
> should make this optional if possible.
> David, do you see any issues with making this dependency optional?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1470) java.util.ServiceConfigurationError

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1470:
-

Hi Setya,

So the odd one out here is this one:

bq. org.axonframework.serializer.ContentTypeConverter from 
file:/usr/apps/virgo-jetty-server-3.6.4.RELEASE/work/deployer/s/axonframework.plan-2.4/5/0/axon-core-2.4.jar/

all the other ones are loaded from .../repository/usr/axon-core-2.4.jar. So it 
would be interesting to know why the code loads that class from that odd 
location. Maybe it's using the ThreadContextClassLoader (TCCL) to load it, 
which would explain the 'random' behaviour as the TCCL could be set to 
anything, but this is just a hunch.

*If* it's the TCCL and you have access to the code yourself, then you can set 
the TCCL to the appropriate bundle classloader (just take a class loaded by the 
bundle and call {{clz.getClass().getClassLoader()}} on it to get a bundle 
classloader). 
If you don't have access to the code and it's the TCCL then you can use SPI-Fly 
to weave in TCCL setter calls...

> java.util.ServiceConfigurationError
> ---
>
> Key: ARIES-1470
> URL: https://issues.apache.org/jira/browse/ARIES-1470
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.6
> Environment: Eclipse Virgo Jetty Server 3.6.4, Spring Framework 3.2.5
>Reporter: Setya
>
> Deploying application that relies on 3rd party framework that's using 
> ServiceLoader into Eclipse Virgo intermittenly causes the following exception 
> to be thrown:
> Caused by: java.util.ServiceConfigurationError: 
> org.axonframework.serializer.ContentTypeConverter: Provider 
> org.axonframework.serializer.converters.ByteArrayToInputStreamConverter not a 
> subtype
>   at java.util.ServiceLoader.fail(ServiceLoader.java:231)
>   at java.util.ServiceLoader.access$300(ServiceLoader.java:181)
>   at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369)
>   at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
>   at 
> org.axonframework.serializer.ChainingConverterFactory.(ChainingConverterFactory.java:51)
>   at 
> org.axonframework.serializer.AbstractXStreamSerializer.(AbstractXStreamSerializer.java:106)
>   at 
> org.axonframework.serializer.AbstractXStreamSerializer.(AbstractXStreamSerializer.java:81)
>   at 
> org.axonframework.serializer.AbstractXStreamSerializer.(AbstractXStreamSerializer.java:70)
>   at 
> org.axonframework.serializer.xml.XStreamSerializer.(XStreamSerializer.java:53)
>   at 
> org.axonframework.contextsupport.spring.FileSystemEventStoreBeanDefinitionParser.doParse(FileSystemEventStoreBeanDefinitionParser.java:76)
>   at 
> org.springframework.beans.factory.xml.AbstractSingleBeanDefinitionParser.parseInternal(AbstractSingleBeanDefinitionParser.java:85)
>   at 
> org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59)
>   at 
> org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
>   at 
> org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1438)
>   at 
> org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1428)
>   at 
> org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:195)
>   at 
> org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.doRegisterBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:139)
>   at 
> org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:108)
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
>   ... 21 common frames omitted
> Have tried to weave static bundle using SPI Fly, but the problem persists.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1470) java.util.ServiceConfigurationError

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1470:
-

Hi [~setya], it could be possible that the TCCL (ThreadContextClassloader) has 
visibility of some of these classes too. ServiceLoader.load() uses the TCCL by 
default so it might pick up these classes from elsewhere via the TCCL. 

What I would do is debug the code a bit and see what classloader is associated 
with these classes. 

Then you should be able to use SPI-Fly to set the TCCL to the bundle 
classloader that you want to use here.

> java.util.ServiceConfigurationError
> ---
>
> Key: ARIES-1470
> URL: https://issues.apache.org/jira/browse/ARIES-1470
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.6
> Environment: Eclipse Virgo Jetty Server 3.6.4, Spring Framework 3.2.5
>Reporter: Setya
>
> Deploying application that relies on 3rd party framework that's using 
> ServiceLoader into Eclipse Virgo intermittenly causes the following exception 
> to be thrown:
> Caused by: java.util.ServiceConfigurationError: 
> org.axonframework.serializer.ContentTypeConverter: Provider 
> org.axonframework.serializer.converters.ByteArrayToInputStreamConverter not a 
> subtype
>   at java.util.ServiceLoader.fail(ServiceLoader.java:231)
>   at java.util.ServiceLoader.access$300(ServiceLoader.java:181)
>   at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369)
>   at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
>   at 
> org.axonframework.serializer.ChainingConverterFactory.(ChainingConverterFactory.java:51)
>   at 
> org.axonframework.serializer.AbstractXStreamSerializer.(AbstractXStreamSerializer.java:106)
>   at 
> org.axonframework.serializer.AbstractXStreamSerializer.(AbstractXStreamSerializer.java:81)
>   at 
> org.axonframework.serializer.AbstractXStreamSerializer.(AbstractXStreamSerializer.java:70)
>   at 
> org.axonframework.serializer.xml.XStreamSerializer.(XStreamSerializer.java:53)
>   at 
> org.axonframework.contextsupport.spring.FileSystemEventStoreBeanDefinitionParser.doParse(FileSystemEventStoreBeanDefinitionParser.java:76)
>   at 
> org.springframework.beans.factory.xml.AbstractSingleBeanDefinitionParser.parseInternal(AbstractSingleBeanDefinitionParser.java:85)
>   at 
> org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59)
>   at 
> org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
>   at 
> org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1438)
>   at 
> org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1428)
>   at 
> org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:195)
>   at 
> org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.doRegisterBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:139)
>   at 
> org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:108)
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
>   ... 21 common frames omitted
> Have tried to weave static bundle using SPI Fly, but the problem persists.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1461) Support SPI-Consumer/Provider headers for fragment bundles

[David Bosschaert (JIRA)]

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

David Bosschaert updated ARIES-1461:

Summary: Support SPI-Consumer/Provider headers for fragment bundles  (was: 
Adding SPI-Consumer headers for fragment bundles)

> Support SPI-Consumer/Provider headers for fragment bundles
> --
>
> Key: ARIES-1461
> URL: https://issues.apache.org/jira/browse/ARIES-1461
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.4
> Environment: ubuntu 14.04 with JDK 1.8.0_20
>Reporter: Aruna Karunarathna
>Assignee: David Bosschaert
> Fix For: spifly-1.0.8
>
>
> I have a host bundle and I can't modify the content of the host bundle, So I 
> created a fragment bundle and add the following header,
> javax.ws.rs.ext.RuntimeDelegate#findDelegate
> After adding this header to the fragment bundle and using it, the service is 
> not working accordingly, Is this a limitation of SPI-Fly?..
> Please note that if I edit and add the above header to the host bundle, it 
> works accordingly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1470) java.util.ServiceConfigurationError

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1470:
-

Hi [~setya], that error is thrown if the service implementation loaded fails 
the following check
{code}service.isAssignableFrom(c)){code}

After looking at the axon code I think ServiceLoader is invoked like this:
{code}ServiceLoader.load(ContentTypeConverter.class);{code}
So the loaded class 
{{org.axonframework.serializer.converters.ByteArrayToInputStreamConverter}} 
cannot be assigned to ContentTypeConverter which suggests to me that the 
classloader that loaded {{ByteArrayToInputStreamConverter}} loads 
{{ContentTypeConverter}} from a different classloader...

What I would ensure first is that {{ByteArrayToInputStreamConverter}} loads the 
{{ContentTypeConverter}} using the same classloader as the code calling 
ServiceLoader.load(). If this means changing to a different TCCL then SPI-Fly 
should be able to help...

> java.util.ServiceConfigurationError
> ---
>
> Key: ARIES-1470
> URL: https://issues.apache.org/jira/browse/ARIES-1470
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.6
> Environment: Eclipse Virgo Jetty Server 3.6.4, Spring Framework 3.2.5
>Reporter: Setya
>
> Deploying application that relies on 3rd party framework that's using 
> ServiceLoader into Eclipse Virgo intermittenly causes the following exception 
> to be thrown:
> Caused by: java.util.ServiceConfigurationError: 
> org.axonframework.serializer.ContentTypeConverter: Provider 
> org.axonframework.serializer.converters.ByteArrayToInputStreamConverter not a 
> subtype
>   at java.util.ServiceLoader.fail(ServiceLoader.java:231)
>   at java.util.ServiceLoader.access$300(ServiceLoader.java:181)
>   at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369)
>   at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
>   at 
> org.axonframework.serializer.ChainingConverterFactory.(ChainingConverterFactory.java:51)
>   at 
> org.axonframework.serializer.AbstractXStreamSerializer.(AbstractXStreamSerializer.java:106)
>   at 
> org.axonframework.serializer.AbstractXStreamSerializer.(AbstractXStreamSerializer.java:81)
>   at 
> org.axonframework.serializer.AbstractXStreamSerializer.(AbstractXStreamSerializer.java:70)
>   at 
> org.axonframework.serializer.xml.XStreamSerializer.(XStreamSerializer.java:53)
>   at 
> org.axonframework.contextsupport.spring.FileSystemEventStoreBeanDefinitionParser.doParse(FileSystemEventStoreBeanDefinitionParser.java:76)
>   at 
> org.springframework.beans.factory.xml.AbstractSingleBeanDefinitionParser.parseInternal(AbstractSingleBeanDefinitionParser.java:85)
>   at 
> org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59)
>   at 
> org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
>   at 
> org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1438)
>   at 
> org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1428)
>   at 
> org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:195)
>   at 
> org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.doRegisterBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:139)
>   at 
> org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:108)
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
>   at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
>   ... 21 common frames omitted
> Have tried to weave static bundle using SPI Fly, but the problem persists.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ARIES-1461) Adding SPI-Consumer headers for fragment bundles

[David Bosschaert (JIRA)]

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

David Bosschaert resolved ARIES-1461.
-
Resolution: Fixed

With commit svn.apache.org/viewvc?view=revision=1718163 this issue is 
now resolved.

> Adding SPI-Consumer headers for fragment bundles
> 
>
> Key: ARIES-1461
> URL: https://issues.apache.org/jira/browse/ARIES-1461
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.4
> Environment: ubuntu 14.04 with JDK 1.8.0_20
>Reporter: Aruna Karunarathna
>Assignee: David Bosschaert
> Fix For: spifly-1.0.8
>
>
> I have a host bundle and I can't modify the content of the host bundle, So I 
> created a fragment bundle and add the following header,
> javax.ws.rs.ext.RuntimeDelegate#findDelegate
> After adding this header to the fragment bundle and using it, the service is 
> not working accordingly, Is this a limitation of SPI-Fly?..
> Please note that if I edit and add the above header to the host bundle, it 
> works accordingly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ARIES-1465) Stopping the Subsystem-Core bundle does not remove synthesized bundles

[David Bosschaert (JIRA)]

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

David Bosschaert resolved ARIES-1465.
-
Resolution: Invalid

> Stopping the Subsystem-Core bundle does not remove synthesized bundles
> --
>
> Key: ARIES-1465
> URL: https://issues.apache.org/jira/browse/ARIES-1465
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.8
>Reporter: David Bosschaert
>
> The Aries Subsystems implementation generates synthesized bundles, such as:
> {code}org.osgi.service.subsystem.region.context.0{code}
> However, when the Aries Subsystem implementation is stopped/uninstalled these 
> generated bundles should disappear. This is currently not happening.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1465) Stopping the Subsystem-Core bundle does not remove synthesized bundles

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1465:
-

Thanks for the clarification, [~tjwatson]!

On the following:
bq. The issue is that a bundle cannot detect that it is being uninstalled so 
there is no way for the impl to tell it is being uninstalled. It would require 
a separate 'helper' bundle to be installed that listens for when the 
subsystem's impl is uninstalled.

The subsystem implementation *could* potentially do this when it's being 
stopped (simply from the BundleActivator.stop() method). However as I see that 
the spec does not require this I think there is nothing to be done here.

> Stopping the Subsystem-Core bundle does not remove synthesized bundles
> --
>
> Key: ARIES-1465
> URL: https://issues.apache.org/jira/browse/ARIES-1465
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.8
>Reporter: David Bosschaert
>
> The Aries Subsystems implementation generates synthesized bundles, such as:
> {code}org.osgi.service.subsystem.region.context.0{code}
> However, when the Aries Subsystem implementation is stopped/uninstalled these 
> generated bundles should disappear. This is currently not happening.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ARIES-1465) Stopping the Subsystem-Core bundle does not remove synthesized bundles

[David Bosschaert (JIRA)]

David Bosschaert created ARIES-1465:
---

 Summary: Stopping the Subsystem-Core bundle does not remove 
synthesized bundles
 Key: ARIES-1465
 URL: https://issues.apache.org/jira/browse/ARIES-1465
 Project: Aries
  Issue Type: Bug
  Components: Subsystem
Affects Versions: subsystem-2.0.8
Reporter: David Bosschaert


The Aries Subsystems implementation generates synthesized bundles, such as:
{code}org.osgi.service.subsystem.region.context.0{code}

However, when the Aries Subsystem implementation is stopped/uninstalled these 
generated bundles should disappear. This is currently not happening.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1461) Adding SPI-Consumer headers for fragment bundles

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1461:
-

Hi [~arunasujith], 

Thanks for validating the fix! I would like to write some unit tests for it 
later this week and then do a release sometime soon after.

> Adding SPI-Consumer headers for fragment bundles
> 
>
> Key: ARIES-1461
> URL: https://issues.apache.org/jira/browse/ARIES-1461
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.4
> Environment: ubuntu 14.04 with JDK 1.8.0_20
>Reporter: Aruna Karunarathna
>Assignee: David Bosschaert
>
> I have a host bundle and I can't modify the content of the host bundle, So I 
> created a fragment bundle and add the following header,
> javax.ws.rs.ext.RuntimeDelegate#findDelegate
> After adding this header to the fragment bundle and using it, the service is 
> not working accordingly, Is this a limitation of SPI-Fly?..
> Please note that if I edit and add the above header to the host bundle, it 
> works accordingly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1461) Adding SPI-Consumer headers for fragment bundles

[David Bosschaert (JIRA)]

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

David Bosschaert updated ARIES-1461:

Fix Version/s: spifly-1.0.8

> Adding SPI-Consumer headers for fragment bundles
> 
>
> Key: ARIES-1461
> URL: https://issues.apache.org/jira/browse/ARIES-1461
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.4
> Environment: ubuntu 14.04 with JDK 1.8.0_20
>Reporter: Aruna Karunarathna
>Assignee: David Bosschaert
> Fix For: spifly-1.0.8
>
>
> I have a host bundle and I can't modify the content of the host bundle, So I 
> created a fragment bundle and add the following header,
> javax.ws.rs.ext.RuntimeDelegate#findDelegate
> After adding this header to the fragment bundle and using it, the service is 
> not working accordingly, Is this a limitation of SPI-Fly?..
> Please note that if I edit and add the above header to the host bundle, it 
> works accordingly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1461) Adding SPI-Consumer headers for fragment bundles

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1461:
-

Hi [~arunasujith], I have made an implementation of this in the following 
commit: http://svn.apache.org/viewvc?view=revision=1717300

It supports adding any of the relevant headers, either SPI Fly specific ones or 
the Require-Capability/Provide-Capability ones, to be provided to bundles via 
fragments. I also added some new examples that exercise this:

spi-fly-example-provider3-bundle - a provider bundle without any SPI Fly headers
spi-fly-example-provider3-fragment - a fragment to add the SPI Fly headers to 
spi-fly-example-provider3-bundle
spi-fly-example-client3-bundle - a consumer bundle without any SPI Fly headers
spi-fly-example-client3-fragment - a fragment to add the SPI Fly headers to 
spi-fly-example-client3-bundle

Could you please check that this addresses the issue for you?

> Adding SPI-Consumer headers for fragment bundles
> 
>
> Key: ARIES-1461
> URL: https://issues.apache.org/jira/browse/ARIES-1461
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.4
> Environment: ubuntu 14.04 with JDK 1.8.0_20
>Reporter: Aruna Karunarathna
>Assignee: David Bosschaert
>
> I have a host bundle and I can't modify the content of the host bundle, So I 
> created a fragment bundle and add the following header,
> javax.ws.rs.ext.RuntimeDelegate#findDelegate
> After adding this header to the fragment bundle and using it, the service is 
> not working accordingly, Is this a limitation of SPI-Fly?..
> Please note that if I edit and add the above header to the host bundle, it 
> works accordingly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (ARIES-1437) Use ASM5 Opcodes instead of the ASM4 and implement ASM 5 visitor api.

[David Bosschaert (JIRA)]

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

David Bosschaert closed ARIES-1437.
---

Thanks for confirming, [~rogilles] - closing the issue.

> Use ASM5 Opcodes instead of the ASM4 and implement ASM 5 visitor api.
> -
>
> Key: ARIES-1437
> URL: https://issues.apache.org/jira/browse/ARIES-1437
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.2
>Reporter: Romain Gilles
>Assignee: David Bosschaert
> Fix For: spifly-1.0.6
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> If weaving code use Java 8 specific language features you will end-up with 
> this kind of exception:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: INVOKESPECIAL/STATIC on 
> interfaces require ASM 5
> at org.objectweb.asm.MethodVisitor.visitMethodInsn(Unknown Source)
> at org.objectweb.asm.ClassReader.a(Unknown Source)
> at org.objectweb.asm.ClassReader.b(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at 
> org.apache.aries.spifly.dynamic.ClientWeavingHook.weave(ClientWeavingHook.java:61)
> {code}
> I provide a pull request in order to solve it:
> [https://github.com/apache/aries/pull/29]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1459) Installing subsystem with large number of constituents takes forever or gives out of memory

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1459:
-

[~gnt] sounds like a good idea to me!

> Installing subsystem with large number of constituents takes forever or gives 
> out of memory
> ---
>
> Key: ARIES-1459
> URL: https://issues.apache.org/jira/browse/ARIES-1459
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.6
>Reporter: David Bosschaert
>
> Installing a large subsystem that contains a lot of bundles can cause the 
> resolution phase to run for hours and sometimes causes out of memory, even 
> with a feature subsystem.
> I think this is caused by the fact that all the bundles inside the subsystem 
> are attempted to be resolved in one shot. When you have 200+ bundles that 
> gives an enormous resolution problem space.
> In a plain OSGi framework such a scenario can be helped by installing bundles 
> in stages, making life easier for the resolver. 
> Maybe subsystems can support this too. We could use the 'start-order' 
> directive on the Subsystem-Content header to guide resolution and only 
> resolve bundles on the current start-order as we progress through those.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1459) Installing subsystem with large number of constituents takes forever or gives out of memory

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1459:
-

We could consider making this configurable...

> Installing subsystem with large number of constituents takes forever or gives 
> out of memory
> ---
>
> Key: ARIES-1459
> URL: https://issues.apache.org/jira/browse/ARIES-1459
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.6
>Reporter: David Bosschaert
>
> Installing a large subsystem that contains a lot of bundles can cause the 
> resolution phase to run for hours and sometimes causes out of memory, even 
> with a feature subsystem.
> I think this is caused by the fact that all the bundles inside the subsystem 
> are attempted to be resolved in one shot. When you have 200+ bundles that 
> gives an enormous resolution problem space.
> In a plain OSGi framework such a scenario can be helped by installing bundles 
> in stages, making life easier for the resolver. 
> Maybe subsystems can support this too. We could use the 'start-order' 
> directive on the Subsystem-Content header to guide resolution and only 
> resolve bundles on the current start-order as we progress through those.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (ARIES-1461) Adding SPI-Consumer headers for fragment bundles

[David Bosschaert (JIRA)]

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

David Bosschaert reassigned ARIES-1461:
---

Assignee: David Bosschaert

> Adding SPI-Consumer headers for fragment bundles
> 
>
> Key: ARIES-1461
> URL: https://issues.apache.org/jira/browse/ARIES-1461
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.4
> Environment: ubuntu 14.04 with JDK 1.8.0_20
>Reporter: Aruna Karunarathna
>Assignee: David Bosschaert
>
> I have a host bundle and I can't modify the content of the host bundle, So I 
> created a fragment bundle and add the following header,
> javax.ws.rs.ext.RuntimeDelegate#findDelegate
> After adding this header to the fragment bundle and using it, the service is 
> not working accordingly, Is this a limitation of SPI-Fly?..
> Please note that if I edit and add the above header to the host bundle, it 
> works accordingly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ARIES-1459) Installing subsystem with large number of constituents takes forever or gives out of memory

[David Bosschaert (JIRA)]

David Bosschaert created ARIES-1459:
---

 Summary: Installing subsystem with large number of constituents 
takes forever or gives out of memory
 Key: ARIES-1459
 URL: https://issues.apache.org/jira/browse/ARIES-1459
 Project: Aries
  Issue Type: Bug
  Components: Subsystem
Affects Versions: subsystem-2.0.6
Reporter: David Bosschaert


Installing a large subsystem that contains a lot of bundles can cause the 
resolution phase to run for hours and sometimes causes out of memory.

I think this is cause by the fact that all the bundles inside the subsystem are 
attempted to be resolved in one shot. When you have 200+ bundles that gives an 
enormous resolution problem space.

In a plain OSGi framework such a scenario can be helped by installing bundles 
in stages, making life easier for the resolver. 

Maybe subsystems can support this too. We could use the 'start-order' directive 
on the Subsystem-Content header to guide resolution and only resolve bundles on 
the current start-order as we progress through those.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1459) Installing subsystem with large number of constituents takes forever or gives out of memory

[David Bosschaert (JIRA)]

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

David Bosschaert updated ARIES-1459:

Description: 
Installing a large subsystem that contains a lot of bundles can cause the 
resolution phase to run for hours and sometimes causes out of memory, even with 
a feature subsystem.

I think this is caused by the fact that all the bundles inside the subsystem 
are attempted to be resolved in one shot. When you have 200+ bundles that gives 
an enormous resolution problem space.

In a plain OSGi framework such a scenario can be helped by installing bundles 
in stages, making life easier for the resolver. 

Maybe subsystems can support this too. We could use the 'start-order' directive 
on the Subsystem-Content header to guide resolution and only resolve bundles on 
the current start-order as we progress through those.

  was:
Installing a large subsystem that contains a lot of bundles can cause the 
resolution phase to run for hours and sometimes causes out of memory.

I think this is cause by the fact that all the bundles inside the subsystem are 
attempted to be resolved in one shot. When you have 200+ bundles that gives an 
enormous resolution problem space.

In a plain OSGi framework such a scenario can be helped by installing bundles 
in stages, making life easier for the resolver. 

Maybe subsystems can support this too. We could use the 'start-order' directive 
on the Subsystem-Content header to guide resolution and only resolve bundles on 
the current start-order as we progress through those.


> Installing subsystem with large number of constituents takes forever or gives 
> out of memory
> ---
>
> Key: ARIES-1459
> URL: https://issues.apache.org/jira/browse/ARIES-1459
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.6
>Reporter: David Bosschaert
>
> Installing a large subsystem that contains a lot of bundles can cause the 
> resolution phase to run for hours and sometimes causes out of memory, even 
> with a feature subsystem.
> I think this is caused by the fact that all the bundles inside the subsystem 
> are attempted to be resolved in one shot. When you have 200+ bundles that 
> gives an enormous resolution problem space.
> In a plain OSGi framework such a scenario can be helped by installing bundles 
> in stages, making life easier for the resolver. 
> Maybe subsystems can support this too. We could use the 'start-order' 
> directive on the Subsystem-Content header to guide resolution and only 
> resolve bundles on the current start-order as we progress through those.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1452) Subsystem throws exception when bundle imports osgi framework

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1452:
-

Thanks for the testcase [~royteeuwen], the interesting thing here is that the 
behaviour is different when the bundle is used inside a subsystem than outside 
of a subsystem, where I can't really see a reason why... 

[~jwr...@us.ibm.com], would you have an idea why this could be?

> Subsystem throws exception when bundle imports osgi framework
> -
>
> Key: ARIES-1452
> URL: https://issues.apache.org/jira/browse/ARIES-1452
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
> Environment: Mac OS X
> Apache Felix (inside Apache Sling 9-SNAPSHOT)
>Reporter: Roy Teeuwen
> Attachments: testcase.zip
>
>
> When building an OSGi subsystem feature, I created two bundles, an api and a 
> core. The core has following embedded dependency:
> 
>com.squeakysand.osgi
>squeakysand-osgi
>0.4.0
> 
> Using  previous dependency in the core, it creates the Import-Package 
> org.osgi.framework;version="[1.5,2)” when using maven-bundle-plugin version 
> 3.0.1.
> Starting up this subsystem through the webconsole subsystem plugin of Apache 
> Felix, following error is thrown:
> 13.11.2015 22:01:23.849 *ERROR* [Thread-95] 
> org.apache.sling.extensions.threaddump.internal.Activator Uncaught exception 
> in Thread Thread[Thread-95,5,main]
> org.osgi.service.subsystem.SubsystemException: 
> org.osgi.service.resolver.ResolutionException: Uses constraint violation. 
> Unable to resolve resource idoneus.mdm-parser-core 
> [/var/folders/h1/k9tr352j615f8jrrzh5yr5b8gn/T/inputStreamExtract734624941409606295.zip/mdm-parser-core-1.0.0-SNAPSHOT.jar]
>  because it is exposed to package 'org.osgi.framework' from resources 
> org.apache.felix.framework [org.apache.felix.framework [0](R 0)] and 
> org.apache.felix.framework [org.apache.felix.framework [0](R 0)] via two 
> dependency chains.
> Chain 1:
>   idoneus.mdm-parser-core 
> [/var/folders/h1/k9tr352j615f8jrrzh5yr5b8gn/T/inputStreamExtract734624941409606295.zip/mdm-parser-core-1.0.0-SNAPSHOT.jar]
> import: 
> (&(osgi.wiring.package=org.osgi.framework)(&(version>=1.5.0)(!(version>=2.0.0
>  |
> export: osgi.wiring.package: org.osgi.framework
>   org.apache.felix.framework [org.apache.felix.framework [0](R 0)]
> Chain 2:
>   idoneus.mdm-parser-core 
> [/var/folders/h1/k9tr352j615f8jrrzh5yr5b8gn/T/inputStreamExtract734624941409606295.zip/mdm-parser-core-1.0.0-SNAPSHOT.jar]
> import: 
> (&(osgi.wiring.package=org.apache.sling.event.jobs.consumer)(&(version>=1.2.0)(!(version>=2.0.0
>  |
> export: osgi.wiring.package=org.apache.sling.event.jobs.consumer; 
> uses:=org.osgi.service.event
>   org.apache.sling.event [org.apache.sling.event [103](R 103.0)]
> import: 
> (&(osgi.wiring.package=org.osgi.service.event)(version>=1.2.0)(!(version>=2.0.0)))
>  |
> export: osgi.wiring.package=org.osgi.service.event; 
> uses:=org.osgi.framework
>   org.apache.felix.eventadmin [org.apache.felix.eventadmin [9](R 9.0)]
> import: 
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.3.0)(!(version>=2.0.0)))
>  |
> export: osgi.wiring.package: org.osgi.framework
>   org.apache.felix.framework [org.apache.felix.framework [0](R 0)]
>   at 
> org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:395)
> This does not happen when I install the api and core as seperate bundles in 
> the OSGi container



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1437) Use ASM5 Opcodes instead of the ASM4 and implement ASM 5 visitor api.

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1437:
-

Actually, I just kicked off the release process: 
http://aries.15396.n3.nabble.com/VOTE-Release-SPI-Fly-1-0-6-td4031882.html

> Use ASM5 Opcodes instead of the ASM4 and implement ASM 5 visitor api.
> -
>
> Key: ARIES-1437
> URL: https://issues.apache.org/jira/browse/ARIES-1437
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.2
>Reporter: Romain Gilles
>Assignee: David Bosschaert
> Fix For: spifly-1.0.6
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> If weaving code use Java 8 specific language features you will end-up with 
> this kind of exception:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: INVOKESPECIAL/STATIC on 
> interfaces require ASM 5
> at org.objectweb.asm.MethodVisitor.visitMethodInsn(Unknown Source)
> at org.objectweb.asm.ClassReader.a(Unknown Source)
> at org.objectweb.asm.ClassReader.b(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at 
> org.apache.aries.spifly.dynamic.ClientWeavingHook.weave(ClientWeavingHook.java:61)
> {code}
> I provide a pull request in order to solve it:
> [https://github.com/apache/aries/pull/29]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1437) Use ASM5 Opcodes instead of the ASM4 and implement ASM 5 visitor api.

[David Bosschaert (JIRA)]

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

David Bosschaert updated ARIES-1437:

Fix Version/s: spifly-1.0.6

> Use ASM5 Opcodes instead of the ASM4 and implement ASM 5 visitor api.
> -
>
> Key: ARIES-1437
> URL: https://issues.apache.org/jira/browse/ARIES-1437
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.2
>Reporter: Romain Gilles
>Assignee: David Bosschaert
> Fix For: spifly-1.0.6
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> If weaving code use Java 8 specific language features you will end-up with 
> this kind of exception:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: INVOKESPECIAL/STATIC on 
> interfaces require ASM 5
> at org.objectweb.asm.MethodVisitor.visitMethodInsn(Unknown Source)
> at org.objectweb.asm.ClassReader.a(Unknown Source)
> at org.objectweb.asm.ClassReader.b(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at 
> org.apache.aries.spifly.dynamic.ClientWeavingHook.weave(ClientWeavingHook.java:61)
> {code}
> I provide a pull request in order to solve it:
> [https://github.com/apache/aries/pull/29]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ARIES-1440) OSGi Subsystems CT testGetDeploymentHeaders() failure 'Wrong Import-Package header'

[David Bosschaert (JIRA)]

David Bosschaert created ARIES-1440:
---

 Summary: OSGi Subsystems CT testGetDeploymentHeaders() failure 
'Wrong Import-Package header'
 Key: ARIES-1440
 URL: https://issues.apache.org/jira/browse/ARIES-1440
 Project: Aries
  Issue Type: Bug
  Components: Subsystem
Affects Versions: subsystem-2.0.4
Reporter: David Bosschaert
 Fix For: subsystem-2.0.6


{code}  


  {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (ARIES-1437) Use ASM5 Opcodes instead of the ASM4 and implement ASM 5 visitor api.

[David Bosschaert (JIRA)]

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

David Bosschaert edited comment on ARIES-1437 at 10/27/15 11:22 AM:


I've applied the patch here: 
http://svn.apache.org/viewvc?view=revision=1710765

Many thanks for your contribution, Romain!


was (Author: bosschaert):
I've applied the patch here: 
svn.apache.org/viewvc?view=revision=1710765

Many thanks for your contribution, Romain!

> Use ASM5 Opcodes instead of the ASM4 and implement ASM 5 visitor api.
> -
>
> Key: ARIES-1437
> URL: https://issues.apache.org/jira/browse/ARIES-1437
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.2
>Reporter: Romain Gilles
>Assignee: David Bosschaert
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> If weaving code use Java 8 specific language features you will end-up with 
> this kind of exception:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: INVOKESPECIAL/STATIC on 
> interfaces require ASM 5
> at org.objectweb.asm.MethodVisitor.visitMethodInsn(Unknown Source)
> at org.objectweb.asm.ClassReader.a(Unknown Source)
> at org.objectweb.asm.ClassReader.b(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at 
> org.apache.aries.spifly.dynamic.ClientWeavingHook.weave(ClientWeavingHook.java:61)
> {code}
> I provide a pull request in order to solve it:
> [https://github.com/apache/aries/pull/29]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ARIES-1437) Use ASM5 Opcodes instead of the ASM4 and implement ASM 5 visitor api.

[David Bosschaert (JIRA)]

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

David Bosschaert resolved ARIES-1437.
-
Resolution: Fixed

I've applied the patch here: 
svn.apache.org/viewvc?view=revision=1710765

Many thanks for your contribution, Romain!

> Use ASM5 Opcodes instead of the ASM4 and implement ASM 5 visitor api.
> -
>
> Key: ARIES-1437
> URL: https://issues.apache.org/jira/browse/ARIES-1437
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.2
>Reporter: Romain Gilles
>Assignee: David Bosschaert
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> If weaving code use Java 8 specific language features you will end-up with 
> this kind of exception:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: INVOKESPECIAL/STATIC on 
> interfaces require ASM 5
> at org.objectweb.asm.MethodVisitor.visitMethodInsn(Unknown Source)
> at org.objectweb.asm.ClassReader.a(Unknown Source)
> at org.objectweb.asm.ClassReader.b(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at 
> org.apache.aries.spifly.dynamic.ClientWeavingHook.weave(ClientWeavingHook.java:61)
> {code}
> I provide a pull request in order to solve it:
> [https://github.com/apache/aries/pull/29]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ARIES-1439) Aries ResolveContext.insertHostedCapability() calls unsupported add() method on capabilies

[David Bosschaert (JIRA)]

David Bosschaert created ARIES-1439:
---

 Summary: Aries ResolveContext.insertHostedCapability() calls 
unsupported add() method on capabilies
 Key: ARIES-1439
 URL: https://issues.apache.org/jira/browse/ARIES-1439
 Project: Aries
  Issue Type: Bug
  Components: Subsystem
Affects Versions: subsystem-core-2.0.4
Reporter: David Bosschaert
Assignee: David Bosschaert
 Fix For: subsystem-2.0.6


The method 
{code}org.apache.aries.subsystem.core.internal.ResolveContext.insertHostedCapability(List
 capabilities, HostedCapability hostedCapability){code}
calls {{capabilities.add(hostedCapability)}}.

However the key reason for this callback is to insert this capability at the 
correct position in the capabilities list. The Felix implementation of the List 
provided insist on a call to {{add(idx, capability)}} which seems to make sense 
in this context. 

Currently this call causes the following exception:

{code}java.lang.UnsupportedOperationException: null
at 
org.apache.felix.resolver.util.CopyOnWriteList.add(CopyOnWriteList.java:135)
at 
org.apache.aries.subsystem.core.internal.ResolveContext.insertHostedCapability(ResolveContext.java:101)
at org.apache.felix.resolver.Candidates.prepare(Candidates.java:934)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:232)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:158)
at 
org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:372){code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ARIES-1439) Aries ResolveContext.insertHostedCapability() calls unsupported add() method on capabilies

[David Bosschaert (JIRA)]

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

David Bosschaert resolved ARIES-1439.
-
Resolution: Fixed

Fixed in http://svn.apache.org/viewvc?view=revision=1710841

> Aries ResolveContext.insertHostedCapability() calls unsupported add() method 
> on capabilies
> --
>
> Key: ARIES-1439
> URL: https://issues.apache.org/jira/browse/ARIES-1439
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-core-2.0.4
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: subsystem-2.0.6
>
>
> The method 
> {code}org.apache.aries.subsystem.core.internal.ResolveContext.insertHostedCapability(List
>  capabilities, HostedCapability hostedCapability){code}
> calls {{capabilities.add(hostedCapability)}}.
> However the key reason for this callback is to insert this capability at the 
> correct position in the capabilities list. The Felix implementation of the 
> List provided insist on a call to {{add(idx, capability)}} which seems to 
> make sense in this context. 
> Currently this call causes the following exception:
> {code}java.lang.UnsupportedOperationException: null
>   at 
> org.apache.felix.resolver.util.CopyOnWriteList.add(CopyOnWriteList.java:135)
>   at 
> org.apache.aries.subsystem.core.internal.ResolveContext.insertHostedCapability(ResolveContext.java:101)
>   at org.apache.felix.resolver.Candidates.prepare(Candidates.java:934)
>   at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:232)
>   at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:158)
>   at 
> org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:372){code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1437) Use ASM5 Opcodes instead of the ASM4 and implement ASM 5 visitor api.

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1437:
-

[~rogilles] would you have a few simple steps to reproduce the problem? 

I'll look into applying your patch...

> Use ASM5 Opcodes instead of the ASM4 and implement ASM 5 visitor api.
> -
>
> Key: ARIES-1437
> URL: https://issues.apache.org/jira/browse/ARIES-1437
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.2
>Reporter: Romain Gilles
>Assignee: David Bosschaert
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> If weaving code use Java 8 specific language features you will end-up with 
> this kind of exception:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: INVOKESPECIAL/STATIC on 
> interfaces require ASM 5
> at org.objectweb.asm.MethodVisitor.visitMethodInsn(Unknown Source)
> at org.objectweb.asm.ClassReader.a(Unknown Source)
> at org.objectweb.asm.ClassReader.b(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at 
> org.apache.aries.spifly.dynamic.ClientWeavingHook.weave(ClientWeavingHook.java:61)
> {code}
> I provide a pull request in order to solve it:
> [https://github.com/apache/aries/pull/29]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (ARIES-1437) Use ASM5 Opcodes instead of the ASM4 and implement ASM 5 visitor api.

[David Bosschaert (JIRA)]

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

David Bosschaert reassigned ARIES-1437:
---

Assignee: David Bosschaert

> Use ASM5 Opcodes instead of the ASM4 and implement ASM 5 visitor api.
> -
>
> Key: ARIES-1437
> URL: https://issues.apache.org/jira/browse/ARIES-1437
> Project: Aries
>  Issue Type: Bug
>  Components: SPI Fly
>Affects Versions: spifly-1.0.2
>Reporter: Romain Gilles
>Assignee: David Bosschaert
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> If weaving code use Java 8 specific language features you will end-up with 
> this kind of exception:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: INVOKESPECIAL/STATIC on 
> interfaces require ASM 5
> at org.objectweb.asm.MethodVisitor.visitMethodInsn(Unknown Source)
> at org.objectweb.asm.ClassReader.a(Unknown Source)
> at org.objectweb.asm.ClassReader.b(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at 
> org.apache.aries.spifly.dynamic.ClientWeavingHook.weave(ClientWeavingHook.java:61)
> {code}
> I provide a pull request in order to solve it:
> [https://github.com/apache/aries/pull/29]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-953) SPIFly: SPI-Consumer breaks when method has multiple parameters

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-953:


The 1.0.4 release just completed. See here: 
https://repository.apache.org/content/repositories/releases/org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle/1.0.4/

> SPIFly: SPI-Consumer breaks when method has multiple parameters
> ---
>
> Key: ARIES-953
> URL: https://issues.apache.org/jira/browse/ARIES-953
> Project: Aries
>  Issue Type: Bug
>Affects Versions: 1.0
> Environment: o.a.a.spifly.dynamic.bundle-1.0.0-20121027.033140-20
> Eclipse 4.2
>Reporter: Kevin Milburn
>Assignee: David Bosschaert
> Fix For: spifly-1.0.4
>
> Attachments: HeaderParser.java.patch, HeaderParser.patch
>
>
> If a method used on the SPI-Consumer header contains multiple parameters, an 
> erroneous exception is generated.
> e.g.  
>  SPI-Consumer: o.a.x.u.Service#providers(java.lang.Class,boolean)
> generates 
>  Must at least specify class name and method name: boolean
> While the ConsumerHeaderProcessor.java has code to deal with multiple 
> parameters, the call to HeaderParser.parseHeader breaks the string 
> incorrectly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-953) SPIFly: SPI-Consumer breaks when method has multiple parameters

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-953:


I can kick off a release today. There was another issue fixed as well, so I 
think a release makes sense.

> SPIFly: SPI-Consumer breaks when method has multiple parameters
> ---
>
> Key: ARIES-953
> URL: https://issues.apache.org/jira/browse/ARIES-953
> Project: Aries
>  Issue Type: Bug
>Affects Versions: 1.0
> Environment: o.a.a.spifly.dynamic.bundle-1.0.0-20121027.033140-20
> Eclipse 4.2
>Reporter: Kevin Milburn
>Assignee: David Bosschaert
> Fix For: spifly-1.0.2
>
> Attachments: HeaderParser.java.patch, HeaderParser.patch
>
>
> If a method used on the SPI-Consumer header contains multiple parameters, an 
> erroneous exception is generated.
> e.g.  
>  SPI-Consumer: o.a.x.u.Service#providers(java.lang.Class,boolean)
> generates 
>  Must at least specify class name and method name: boolean
> While the ConsumerHeaderProcessor.java has code to deal with multiple 
> parameters, the call to HeaderParser.parseHeader breaks the string 
> incorrectly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-953) SPIFly: SPI-Consumer breaks when method has multiple parameters

[David Bosschaert (JIRA)]

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

David Bosschaert updated ARIES-953:
---
Fix Version/s: (was: spifly-1.0.2)
   spifly-1.0.4

> SPIFly: SPI-Consumer breaks when method has multiple parameters
> ---
>
> Key: ARIES-953
> URL: https://issues.apache.org/jira/browse/ARIES-953
> Project: Aries
>  Issue Type: Bug
>Affects Versions: 1.0
> Environment: o.a.a.spifly.dynamic.bundle-1.0.0-20121027.033140-20
> Eclipse 4.2
>Reporter: Kevin Milburn
>Assignee: David Bosschaert
> Fix For: spifly-1.0.4
>
> Attachments: HeaderParser.java.patch, HeaderParser.patch
>
>
> If a method used on the SPI-Consumer header contains multiple parameters, an 
> erroneous exception is generated.
> e.g.  
>  SPI-Consumer: o.a.x.u.Service#providers(java.lang.Class,boolean)
> generates 
>  Must at least specify class name and method name: boolean
> While the ConsumerHeaderProcessor.java has code to deal with multiple 
> parameters, the call to HeaderParser.parseHeader breaks the string 
> incorrectly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-953) SPIFly: SPI-Consumer breaks when method has multiple parameters

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-953:


Turned out that 1.0.2 was already released, so this goes into 1.0.4. The 
release vote has just been sent.

> SPIFly: SPI-Consumer breaks when method has multiple parameters
> ---
>
> Key: ARIES-953
> URL: https://issues.apache.org/jira/browse/ARIES-953
> Project: Aries
>  Issue Type: Bug
>Affects Versions: 1.0
> Environment: o.a.a.spifly.dynamic.bundle-1.0.0-20121027.033140-20
> Eclipse 4.2
>Reporter: Kevin Milburn
>Assignee: David Bosschaert
> Fix For: spifly-1.0.4
>
> Attachments: HeaderParser.java.patch, HeaderParser.patch
>
>
> If a method used on the SPI-Consumer header contains multiple parameters, an 
> erroneous exception is generated.
> e.g.  
>  SPI-Consumer: o.a.x.u.Service#providers(java.lang.Class,boolean)
> generates 
>  Must at least specify class name and method name: boolean
> While the ConsumerHeaderProcessor.java has code to deal with multiple 
> parameters, the call to HeaderParser.parseHeader breaks the string 
> incorrectly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ARIES-953) SPIFly: SPI-Consumer breaks when method has multiple parameters

[David Bosschaert (JIRA)]

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

David Bosschaert resolved ARIES-953.

Resolution: Fixed

Patch applied in http://svn.apache.org/viewvc?view=revision=1708295

Many thanks to [~kpmilburn] and [~acourouppe]!

> SPIFly: SPI-Consumer breaks when method has multiple parameters
> ---
>
> Key: ARIES-953
> URL: https://issues.apache.org/jira/browse/ARIES-953
> Project: Aries
>  Issue Type: Bug
>Affects Versions: 1.0
> Environment: o.a.a.spifly.dynamic.bundle-1.0.0-20121027.033140-20
> Eclipse 4.2
>Reporter: Kevin Milburn
>Assignee: David Bosschaert
> Fix For: spifly-1.0.2
>
> Attachments: HeaderParser.java.patch, HeaderParser.patch
>
>
> If a method used on the SPI-Consumer header contains multiple parameters, an 
> erroneous exception is generated.
> e.g.  
>  SPI-Consumer: o.a.x.u.Service#providers(java.lang.Class,boolean)
> generates 
>  Must at least specify class name and method name: boolean
> While the ConsumerHeaderProcessor.java has code to deal with multiple 
> parameters, the call to HeaderParser.parseHeader breaks the string 
> incorrectly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-953) SPIFly: SPI-Consumer breaks when method has multiple parameters

[David Bosschaert (JIRA)]

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

David Bosschaert updated ARIES-953:
---
Fix Version/s: spifly-1.0.2

> SPIFly: SPI-Consumer breaks when method has multiple parameters
> ---
>
> Key: ARIES-953
> URL: https://issues.apache.org/jira/browse/ARIES-953
> Project: Aries
>  Issue Type: Bug
>Affects Versions: 1.0
> Environment: o.a.a.spifly.dynamic.bundle-1.0.0-20121027.033140-20
> Eclipse 4.2
>Reporter: Kevin Milburn
>Assignee: David Bosschaert
> Fix For: spifly-1.0.2
>
> Attachments: HeaderParser.java.patch, HeaderParser.patch
>
>
> If a method used on the SPI-Consumer header contains multiple parameters, an 
> erroneous exception is generated.
> e.g.  
>  SPI-Consumer: o.a.x.u.Service#providers(java.lang.Class,boolean)
> generates 
>  Must at least specify class name and method name: boolean
> While the ConsumerHeaderProcessor.java has code to deal with multiple 
> parameters, the call to HeaderParser.parseHeader breaks the string 
> incorrectly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-953) SPIFly: SPI-Consumer breaks when method has multiple parameters

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-953:


Sorry for the long time it took me to look at this patch. I am just looking at 
it and I'm not sure I fully understand the changed regular expression with its 
escapes and modifier.

Would it be possible to also provide a unit test that actually exercises this 
code and shows what situations it is for? 

> SPIFly: SPI-Consumer breaks when method has multiple parameters
> ---
>
> Key: ARIES-953
> URL: https://issues.apache.org/jira/browse/ARIES-953
> Project: Aries
>  Issue Type: Bug
>Affects Versions: 1.0
> Environment: o.a.a.spifly.dynamic.bundle-1.0.0-20121027.033140-20
> Eclipse 4.2
>Reporter: Kevin Milburn
>Assignee: David Bosschaert
> Attachments: HeaderParser.java.patch
>
>
> If a method used on the SPI-Consumer header contains multiple parameters, an 
> erroneous exception is generated.
> e.g.  
>  SPI-Consumer: o.a.x.u.Service#providers(java.lang.Class,boolean)
> generates 
>  Must at least specify class name and method name: boolean
> While the ConsumerHeaderProcessor.java has code to deal with multiple 
> parameters, the call to HeaderParser.parseHeader breaks the string 
> incorrectly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1398) Aries Subsystem implementation is start-order dependent

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1398:
-

I've reopened this issue now that the conclusion in FELIX-5049 is that this is 
not a problem with the framework. 

The Aries Subsystem implementation could be amended to include 
Require-Capability on the osgi.service capabilities for those services without 
which it does not function - that should resolve this issue too. Is this 
something to consider? These would have to be resolve-time requirements for 
those mandatory services...

> Aries Subsystem implementation is start-order dependent
> ---
>
> Key: ARIES-1398
> URL: https://issues.apache.org/jira/browse/ARIES-1398
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.2
>Reporter: David Bosschaert
> Attachments: nowork.txt, services.txt, works.txt
>
>
> From an email thread by Paul F Frazer: 
> https://mail-archives.apache.org/mod_mbox/aries-user/201509.mbox/browser
> When the Aries Subsystem implementation is started in a certain order the 
> synthesized {{org.osgi.service.subsystem.region.context.0}} bundle is not 
> created.
> While the original bug was reported on the Raspberry Pi, this can also be 
> reproduced on an ordinary laptop. For example by starting the bundles in the 
> following order:
> {code}START LEVEL 1
>ID|State  |Level|Name
> 0|Active |0|System Bundle (5.2.0)
> 1|Active |1|Apache Felix Bundle Repository (2.0.4)
> 2|Active |1|Apache Felix Gogo Command (0.14.0)
> 3|Active |1|Apache Felix Gogo Runtime (0.16.2)
> 4|Active |1|Apache Felix Gogo Shell (0.10.0)
> 5|Active |1|Apache Felix Configuration Admin Service (1.8.6)
> 6|Active |1|Apache Felix Coordinator Service (1.0.0)
> 7|Active |1|osgi.cmpn (5.0.0.201305092017)
> 8|Active |1|slf4j-api (1.7.12)
> 9|Active |1|Region Digraph (1.1.0.v20120522-1841)
>10|Active |1|Apache Aries Subsystem Core (2.0.2)
>11|Resolved   |1|slf4j-simple (1.7.12)
>12|Active |1|Apache Aries Util (1.1.1)
>13|Active |1|Apache Aries Subsystem API (2.0.2)
> {code}
> As you can see the synthesized bundle does not appear.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1398) Aries Subsystem implementation is start-order dependent

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1398:
-

> Is that the case here?

Yes, except that it's the following:
{{osgi.service; objectClass:List=org.osgi.service.resolver.Resolver; 
uses:=org.osgi.service.resolver}} (use of the {{osgi.service}} attribute is not 
correct in your example)

This has been added to the Felix framework current trunk. See FELIX-5064.

> I'm not sure we want a solution that would always wire subsystems to the 
> framework resolver. Folks may wish to use another.

I don't think this statement does that. It wires to providers of the service, 
which may be the framework but if other bundles provide the service and are in 
the same class-space they would be used too. Effectively this only says that a 
service must be provided, but doesn't state where it comes from.

> Aries Subsystem implementation is start-order dependent
> ---
>
> Key: ARIES-1398
> URL: https://issues.apache.org/jira/browse/ARIES-1398
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.2
>Reporter: David Bosschaert
> Attachments: nowork.txt, services.txt, works.txt
>
>
> From an email thread by Paul F Frazer: 
> https://mail-archives.apache.org/mod_mbox/aries-user/201509.mbox/browser
> When the Aries Subsystem implementation is started in a certain order the 
> synthesized {{org.osgi.service.subsystem.region.context.0}} bundle is not 
> created.
> While the original bug was reported on the Raspberry Pi, this can also be 
> reproduced on an ordinary laptop. For example by starting the bundles in the 
> following order:
> {code}START LEVEL 1
>ID|State  |Level|Name
> 0|Active |0|System Bundle (5.2.0)
> 1|Active |1|Apache Felix Bundle Repository (2.0.4)
> 2|Active |1|Apache Felix Gogo Command (0.14.0)
> 3|Active |1|Apache Felix Gogo Runtime (0.16.2)
> 4|Active |1|Apache Felix Gogo Shell (0.10.0)
> 5|Active |1|Apache Felix Configuration Admin Service (1.8.6)
> 6|Active |1|Apache Felix Coordinator Service (1.0.0)
> 7|Active |1|osgi.cmpn (5.0.0.201305092017)
> 8|Active |1|slf4j-api (1.7.12)
> 9|Active |1|Region Digraph (1.1.0.v20120522-1841)
>10|Active |1|Apache Aries Subsystem Core (2.0.2)
>11|Resolved   |1|slf4j-simple (1.7.12)
>12|Active |1|Apache Aries Util (1.1.1)
>13|Active |1|Apache Aries Subsystem API (2.0.2)
> {code}
> As you can see the synthesized bundle does not appear.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1398) Aries Subsystem implementation is start-order dependent

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1398:
-

Hi [~tjwatson],

> Are you suggesting we must have a mandatory, resolve type requirement for all 
> services that are required for some bundle to be functional? 

Well, yes, I think there is value in this. We expect bundles that resolve to be 
functional. We have been introducing capabilities in Enterprise R6 to this 
effect, such as {{osgi.extender}} and {{osgi.implementation}}. The same holds 
for {{osgi.service}} capabilities. If a bundle only functions with a certain 
service being present, this I think this would be a useful 
{{osgi.service;effective:=resolve}} type requirement. 
Not all osgi.cmpn specifications define the osgi.service capability just yet, 
but most do and others are being updated for R7.

> Are you only suggesting that for this special case with the resolver package? 
> If so, why? 

No the resolver is not special, I think it should be done for all OSGi-spec 
based services that are required. 

> Surely other packages out of osgi.cmpn could cause similar issues with 
> implementations of other services.

True, and that's why I think we should do this across the board for OSGi 
spec-defined services. 


Hi [~jwr...@us.ibm.com], 

> If we go that route, the requirement should be optional

That doesn't work. Optional requirements are not enforced, the framework can do 
whatever it wants with them, so they don't help in such a situation.

> Having said that, I still want to emphasize that the only motivating use case 
> for this that I'm aware of is to allow people to install the R5 CMPN bundle 
> into the runtime.

Unfortunately there are quite a lot of these deployed at runtime.

> Aries Subsystem implementation is start-order dependent
> ---
>
> Key: ARIES-1398
> URL: https://issues.apache.org/jira/browse/ARIES-1398
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.2
>Reporter: David Bosschaert
> Attachments: nowork.txt, services.txt, works.txt
>
>
> From an email thread by Paul F Frazer: 
> https://mail-archives.apache.org/mod_mbox/aries-user/201509.mbox/browser
> When the Aries Subsystem implementation is started in a certain order the 
> synthesized {{org.osgi.service.subsystem.region.context.0}} bundle is not 
> created.
> While the original bug was reported on the Raspberry Pi, this can also be 
> reproduced on an ordinary laptop. For example by starting the bundles in the 
> following order:
> {code}START LEVEL 1
>ID|State  |Level|Name
> 0|Active |0|System Bundle (5.2.0)
> 1|Active |1|Apache Felix Bundle Repository (2.0.4)
> 2|Active |1|Apache Felix Gogo Command (0.14.0)
> 3|Active |1|Apache Felix Gogo Runtime (0.16.2)
> 4|Active |1|Apache Felix Gogo Shell (0.10.0)
> 5|Active |1|Apache Felix Configuration Admin Service (1.8.6)
> 6|Active |1|Apache Felix Coordinator Service (1.0.0)
> 7|Active |1|osgi.cmpn (5.0.0.201305092017)
> 8|Active |1|slf4j-api (1.7.12)
> 9|Active |1|Region Digraph (1.1.0.v20120522-1841)
>10|Active |1|Apache Aries Subsystem Core (2.0.2)
>11|Resolved   |1|slf4j-simple (1.7.12)
>12|Active |1|Apache Aries Util (1.1.1)
>13|Active |1|Apache Aries Subsystem API (2.0.2)
> {code}
> As you can see the synthesized bundle does not appear.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1398) Aries Subsystem implementation is start-order dependent

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1398:
-

Hi [~jwr...@us.ibm.com], you can see in FELIX-5049 that the framework behaviour 
is actually correct because the framework exports the resolver package in 
version 1.0.0 whereas the cmpn bundle exports it in 1.0.1. I guess the real 
solution is to not use the cmpn bundle as it is really not aimed at runtime 
use. We could potentially discuss whether the Subsystems implementation should 
look for Resolver services that are in a different class-space (via 
getAllServices()) and use them through reflection. Normally service consumers 
don't do this, but it might be something to consider...

> Aries Subsystem implementation is start-order dependent
> ---
>
> Key: ARIES-1398
> URL: https://issues.apache.org/jira/browse/ARIES-1398
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.2
>Reporter: David Bosschaert
> Attachments: nowork.txt, services.txt, works.txt
>
>
> From an email thread by Paul F Frazer: 
> https://mail-archives.apache.org/mod_mbox/aries-user/201509.mbox/browser
> When the Aries Subsystem implementation is started in a certain order the 
> synthesized {{org.osgi.service.subsystem.region.context.0}} bundle is not 
> created.
> While the original bug was reported on the Raspberry Pi, this can also be 
> reproduced on an ordinary laptop. For example by starting the bundles in the 
> following order:
> {code}START LEVEL 1
>ID|State  |Level|Name
> 0|Active |0|System Bundle (5.2.0)
> 1|Active |1|Apache Felix Bundle Repository (2.0.4)
> 2|Active |1|Apache Felix Gogo Command (0.14.0)
> 3|Active |1|Apache Felix Gogo Runtime (0.16.2)
> 4|Active |1|Apache Felix Gogo Shell (0.10.0)
> 5|Active |1|Apache Felix Configuration Admin Service (1.8.6)
> 6|Active |1|Apache Felix Coordinator Service (1.0.0)
> 7|Active |1|osgi.cmpn (5.0.0.201305092017)
> 8|Active |1|slf4j-api (1.7.12)
> 9|Active |1|Region Digraph (1.1.0.v20120522-1841)
>10|Active |1|Apache Aries Subsystem Core (2.0.2)
>11|Resolved   |1|slf4j-simple (1.7.12)
>12|Active |1|Apache Aries Util (1.1.1)
>13|Active |1|Apache Aries Subsystem API (2.0.2)
> {code}
> As you can see the synthesized bundle does not appear.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-953) SPIFly: SPI-Consumer breaks when method has multiple parameters

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-953:


Hi [~acourouppe], this seems to have slipped my attention at the time. I'll 
have a look at the patch soon.

> SPIFly: SPI-Consumer breaks when method has multiple parameters
> ---
>
> Key: ARIES-953
> URL: https://issues.apache.org/jira/browse/ARIES-953
> Project: Aries
>  Issue Type: Bug
>Affects Versions: 1.0
> Environment: o.a.a.spifly.dynamic.bundle-1.0.0-20121027.033140-20
> Eclipse 4.2
>Reporter: Kevin Milburn
>Assignee: David Bosschaert
> Attachments: HeaderParser.java.patch
>
>
> If a method used on the SPI-Consumer header contains multiple parameters, an 
> erroneous exception is generated.
> e.g.  
>  SPI-Consumer: o.a.x.u.Service#providers(java.lang.Class,boolean)
> generates 
>  Must at least specify class name and method name: boolean
> While the ConsumerHeaderProcessor.java has code to deal with multiple 
> parameters, the call to HeaderParser.parseHeader breaks the string 
> incorrectly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (ARIES-953) SPIFly: SPI-Consumer breaks when method has multiple parameters

[David Bosschaert (JIRA)]

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

David Bosschaert reassigned ARIES-953:
--

Assignee: David Bosschaert

> SPIFly: SPI-Consumer breaks when method has multiple parameters
> ---
>
> Key: ARIES-953
> URL: https://issues.apache.org/jira/browse/ARIES-953
> Project: Aries
>  Issue Type: Bug
>Affects Versions: 1.0
> Environment: o.a.a.spifly.dynamic.bundle-1.0.0-20121027.033140-20
> Eclipse 4.2
>Reporter: Kevin Milburn
>Assignee: David Bosschaert
> Attachments: HeaderParser.java.patch
>
>
> If a method used on the SPI-Consumer header contains multiple parameters, an 
> erroneous exception is generated.
> e.g.  
>  SPI-Consumer: o.a.x.u.Service#providers(java.lang.Class,boolean)
> generates 
>  Must at least specify class name and method name: boolean
> While the ConsumerHeaderProcessor.java has code to deal with multiple 
> parameters, the call to HeaderParser.parseHeader breaks the string 
> incorrectly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1398) Aries Subsystem implementation is start-order dependent

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1398:
-

Hi [~jwr...@us.ibm.com],

Re 1) yes I've already created FELIX-5049 for this.
Re 2) this is not possible since the osgi.cmpn R5 bundle has already been 
released and cannot be changed, however the R6 enterprise and compendium 
bundles which were released earlier this year are indeed non-resolvable at 
runtime.

> Aries Subsystem implementation is start-order dependent
> ---
>
> Key: ARIES-1398
> URL: https://issues.apache.org/jira/browse/ARIES-1398
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.2
>Reporter: David Bosschaert
> Attachments: nowork.txt, services.txt, works.txt
>
>
> From an email thread by Paul F Frazer: 
> https://mail-archives.apache.org/mod_mbox/aries-user/201509.mbox/browser
> When the Aries Subsystem implementation is started in a certain order the 
> synthesized {{org.osgi.service.subsystem.region.context.0}} bundle is not 
> created.
> While the original bug was reported on the Raspberry Pi, this can also be 
> reproduced on an ordinary laptop. For example by starting the bundles in the 
> following order:
> {code}START LEVEL 1
>ID|State  |Level|Name
> 0|Active |0|System Bundle (5.2.0)
> 1|Active |1|Apache Felix Bundle Repository (2.0.4)
> 2|Active |1|Apache Felix Gogo Command (0.14.0)
> 3|Active |1|Apache Felix Gogo Runtime (0.16.2)
> 4|Active |1|Apache Felix Gogo Shell (0.10.0)
> 5|Active |1|Apache Felix Configuration Admin Service (1.8.6)
> 6|Active |1|Apache Felix Coordinator Service (1.0.0)
> 7|Active |1|osgi.cmpn (5.0.0.201305092017)
> 8|Active |1|slf4j-api (1.7.12)
> 9|Active |1|Region Digraph (1.1.0.v20120522-1841)
>10|Active |1|Apache Aries Subsystem Core (2.0.2)
>11|Resolved   |1|slf4j-simple (1.7.12)
>12|Active |1|Apache Aries Util (1.1.1)
>13|Active |1|Apache Aries Subsystem API (2.0.2)
> {code}
> As you can see the synthesized bundle does not appear.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (ARIES-1328) Application subsystem does not import services

[David Bosschaert (JIRA)]

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

David Bosschaert reassigned ARIES-1328:
---

Assignee: David Bosschaert

> Application subsystem does not import services
> --
>
> Key: ARIES-1328
> URL: https://issues.apache.org/jira/browse/ARIES-1328
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-core-1.2.0
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Attachments: api-bundle-1.0.0-SNAPSHOT.jar, 
> application-subsystem-nosvc-1.0.0-SNAPSHOT.esa, 
> application-subsystem-nosvc-rc.esa, application-subsystem-nosvc-ubrc.esa, 
> svc-bundle2-1.0.0-SNAPSHOT.jar, use-bundle-1.0.0-SNAPSHOT.jar
>
>
> I have an application Subsystem that has a bundle that looks for a service 
> via a service tracker.
> This service and its API is provided by pre-existing bundles (api-bundle, 
> svc-bundle2) in the parent subsystem. 
> The OSGi enterprise R5 spec states in 134.16.1 (Application Subsystems):
> "Any required capabilities that are not satisfied by the application's 
> constituents are automatically shared in (imported) from the parent 
> Subsystem."
> However when I install and start the application subsystem 
> (application-subsystem-nosvc), it does not find the services provided in the 
> parent.
> I'm attaching the bundles and subsystem to reproduce. The full source code 
> can be found here: https://github.com/coderthoughts/subsystem-examples



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1328) Application subsystem does not import services

[David Bosschaert (JIRA)]

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

David Bosschaert commented on ARIES-1328:
-

Assigned to myself to remind me to check whether its fixed or not.

> Application subsystem does not import services
> --
>
> Key: ARIES-1328
> URL: https://issues.apache.org/jira/browse/ARIES-1328
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-core-1.2.0
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Attachments: api-bundle-1.0.0-SNAPSHOT.jar, 
> application-subsystem-nosvc-1.0.0-SNAPSHOT.esa, 
> application-subsystem-nosvc-rc.esa, application-subsystem-nosvc-ubrc.esa, 
> svc-bundle2-1.0.0-SNAPSHOT.jar, use-bundle-1.0.0-SNAPSHOT.jar
>
>
> I have an application Subsystem that has a bundle that looks for a service 
> via a service tracker.
> This service and its API is provided by pre-existing bundles (api-bundle, 
> svc-bundle2) in the parent subsystem. 
> The OSGi enterprise R5 spec states in 134.16.1 (Application Subsystems):
> "Any required capabilities that are not satisfied by the application's 
> constituents are automatically shared in (imported) from the parent 
> Subsystem."
> However when I install and start the application subsystem 
> (application-subsystem-nosvc), it does not find the services provided in the 
> parent.
> I'm attaching the bundles and subsystem to reproduce. The full source code 
> can be found here: https://github.com/coderthoughts/subsystem-examples



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ARIES-1398) Aries Subsystem implementation is start-order dependent

[David Bosschaert (JIRA)]

David Bosschaert created ARIES-1398:
---

 Summary: Aries Subsystem implementation is start-order dependent
 Key: ARIES-1398
 URL: https://issues.apache.org/jira/browse/ARIES-1398
 Project: Aries
  Issue Type: Bug
  Components: Subsystem
Affects Versions: subsystem-2.0.2
Reporter: David Bosschaert
 Attachments: nowork.txt, works.txt

>From an email thread by Paul F Frazer: 
>https://mail-archives.apache.org/mod_mbox/aries-user/201509.mbox/browser

When the Aries Subsystem implementation is started in a certain order the 
synthesized {{org.osgi.service.subsystem.region.context.0}} bundle is not 
created.

While the original bug was reported on the Raspberry Pi, this can also be 
reproduced on an ordinary laptop. For example by starting the bundles in the 
following order:

{code}START LEVEL 1
   ID|State  |Level|Name
0|Active |0|System Bundle (5.2.0)
1|Active |1|Apache Felix Bundle Repository (2.0.4)
2|Active |1|Apache Felix Gogo Command (0.14.0)
3|Active |1|Apache Felix Gogo Runtime (0.16.2)
4|Active |1|Apache Felix Gogo Shell (0.10.0)
5|Active |1|Apache Felix Configuration Admin Service (1.8.6)
6|Active |1|Apache Felix Coordinator Service (1.0.0)
7|Active |1|osgi.cmpn (5.0.0.201305092017)
8|Active |1|slf4j-api (1.7.12)
9|Active |1|Region Digraph (1.1.0.v20120522-1841)
   11|Resolved   |1|slf4j-simple (1.7.12)
   12|Active |1|Apache Aries Util (1.1.1)
   13|Active |1|Apache Aries Subsystem API (2.0.2)
   14|Active |1|Apache Aries Subsystem Core (2.0.2)
{code}
As you can see the synthesized bundle does not appear.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1398) Aries Subsystem implementation is start-order dependent

[David Bosschaert (JIRA)]

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

David Bosschaert updated ARIES-1398:

Attachment: works.txt
nowork.txt

The attached txt files are provided by Paul to show working and non-working 
scenarios.

> Aries Subsystem implementation is start-order dependent
> ---
>
> Key: ARIES-1398
> URL: https://issues.apache.org/jira/browse/ARIES-1398
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.2
>Reporter: David Bosschaert
> Attachments: nowork.txt, works.txt
>
>
> From an email thread by Paul F Frazer: 
> https://mail-archives.apache.org/mod_mbox/aries-user/201509.mbox/browser
> When the Aries Subsystem implementation is started in a certain order the 
> synthesized {{org.osgi.service.subsystem.region.context.0}} bundle is not 
> created.
> While the original bug was reported on the Raspberry Pi, this can also be 
> reproduced on an ordinary laptop. For example by starting the bundles in the 
> following order:
> {code}START LEVEL 1
>ID|State  |Level|Name
> 0|Active |0|System Bundle (5.2.0)
> 1|Active |1|Apache Felix Bundle Repository (2.0.4)
> 2|Active |1|Apache Felix Gogo Command (0.14.0)
> 3|Active |1|Apache Felix Gogo Runtime (0.16.2)
> 4|Active |1|Apache Felix Gogo Shell (0.10.0)
> 5|Active |1|Apache Felix Configuration Admin Service (1.8.6)
> 6|Active |1|Apache Felix Coordinator Service (1.0.0)
> 7|Active |1|osgi.cmpn (5.0.0.201305092017)
> 8|Active |1|slf4j-api (1.7.12)
> 9|Active |1|Region Digraph (1.1.0.v20120522-1841)
>11|Resolved   |1|slf4j-simple (1.7.12)
>12|Active |1|Apache Aries Util (1.1.1)
>13|Active |1|Apache Aries Subsystem API (2.0.2)
>14|Active |1|Apache Aries Subsystem Core (2.0.2)
> {code}
> As you can see the synthesized bundle does not appear.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)