Re: [VOTE] Release Felix maven-bundle-plugin version 2.5.0 (second attempt)
+1 (non-binding) I did a test with latest fabric8 and all went well after little modification: We had this default: Private-Package!*/Private-Package But it seems that it resulted in empty JARs - the above setting overrode Export-Packageio.fabric8.xxx*/Export-Package Shouldn't we use Export-Package with higher priority? After changing this to: Private-Package / all went fine. regards Grzegorz Grzybek 2014-06-23 20:52 GMT+02:00 Jean-Baptiste Onofré j...@nanthrax.net: +1 (non binding) Regards JB On 06/23/2014 04:05 PM, Stuart McCulloch wrote: Hi, I’ve fixed the issue reported in http://www.mail-archive.com/ us...@felix.apache.org/msg15423.html and have restaged the 2.5.0 release... We solved 7 issues in this release, the major ones being the bndlib 2.3.0 upgrade to support Java 8 bytecode and a new baselining feature: https://issues.apache.org/jira/secure/ReleaseNote.jspa? version=12324606styleName=HtmlprojectId=12310100 There are still several outstanding issues which people can contribute towards fixing :) https://issues.apache.org/jira/issues/?jql=component+% 3D+%22Maven+Bundle+Plugin%22+AND+project+%3D+FELIX+AND+ resolution+%3D+Unresolved+ORDER+BY+priority+DESC Release source tag: https://svn.apache.org/repos/asf/felix/releases/maven- bundle-plugin-2.5.0/ Staging repository: https://repository.apache.org/content/repositories/ orgapachefelix-1024/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_ release.sh Usage: sh check_staged_release.sh 1024 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. — Cheers, Stuart -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: [VOTE] Release Felix maven-bundle-plugin version 2.5.0 (second attempt)
On 24 Jun 2014, at 09:54, Grzegorz Grzybek gr.grzy...@gmail.com wrote: +1 (non-binding) I did a test with latest fabric8 and all went well after little modification: We had this default: Private-Package!*/Private-Package But it seems that it resulted in empty JARs - the above setting overrode Export-Packageio.fabric8.xxx*/Export-Package Shouldn't we use Export-Package with higher priority? AFAICT nothing has changed in the bundleplugin wrt. Private-Package (compared to bundleplugin 2.4.0), but it could be a consequence of the upgrade to bnd 2.3.0 After changing this to: Private-Package / all went fine. regards Grzegorz Grzybek 2014-06-23 20:52 GMT+02:00 Jean-Baptiste Onofré j...@nanthrax.net: +1 (non binding) Regards JB On 06/23/2014 04:05 PM, Stuart McCulloch wrote: Hi, I’ve fixed the issue reported in http://www.mail-archive.com/ us...@felix.apache.org/msg15423.html and have restaged the 2.5.0 release... We solved 7 issues in this release, the major ones being the bndlib 2.3.0 upgrade to support Java 8 bytecode and a new baselining feature: https://issues.apache.org/jira/secure/ReleaseNote.jspa? version=12324606styleName=HtmlprojectId=12310100 There are still several outstanding issues which people can contribute towards fixing :) https://issues.apache.org/jira/issues/?jql=component+% 3D+%22Maven+Bundle+Plugin%22+AND+project+%3D+FELIX+AND+ resolution+%3D+Unresolved+ORDER+BY+priority+DESC Release source tag: https://svn.apache.org/repos/asf/felix/releases/maven- bundle-plugin-2.5.0/ Staging repository: https://repository.apache.org/content/repositories/ orgapachefelix-1024/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_ release.sh Usage: sh check_staged_release.sh 1024 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. — Cheers, Stuart -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
[jira] [Updated] (FELIX-4523) Deadlock in URLHandlers when Felix.init and Felix.stop are called concurrently
[
https://issues.apache.org/jira/browse/FELIX-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-4523:
--
Attachment: urlhandlers.patch
Deadlock in URLHandlers when Felix.init and Felix.stop are called concurrently
--
Key: FELIX-4523
URL: https://issues.apache.org/jira/browse/FELIX-4523
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-4.2.1
Environment: linux, junittests
Reporter: Benjamin Rogge
Assignee: Karl Pauls
Attachments: urlhandlers.patch
From time to time we are experiencing a deadlock in the URLHandlers Class in
Apache Felix. We are using Felix as an embedded OSGi Container and
instantiate the Felix Framework via ServiceLoader and Framework Factory
ourselves. The situation is as follows: When Felix.stop and Felix.init are
called by different threads, eventually
URLHandlers.unregisterFrameworkListsForContextSearch and
URLHandlers.registerFrameworkInstance are called by the threads. There are
two locks: m_frameworks and the Class Object of URL (URL.class).
registerFrameworkInstance tries to aquire m_frameworks first and via the
constructor of URLHanders URL.class after that.
unregisterFrameworkListsForContextSearch tries to aquire URL.class first and
m_frameworks after that. This is a classic deadlock situation. The situation
arises in unittests where we frequently start and stop the felix framework.
Stacktracke log:
{code}
Found one Java-level deadlock:
=
FelixShutdown:
waiting to lock monitor 0x00ff7710 (object 0x0007ff33e7f0, a
java.util.ArrayList),
which is held by main
main:
waiting to lock monitor 0x022c4a08 (object 0x000783b06b18, a
java.lang.Class),
which is held by FelixShutdown
Java stack information for the threads listed above:
===
FelixShutdown:
at
org.apache.felix.framework.URLHandlers.unregisterFrameworkListsForContextSearch(URLHandlers.java:315)
- waiting to lock 0x0007ff33e7f0 (a java.util.ArrayList)
- locked 0x0007ff33e840 (a java.util.HashMap)
- locked 0x000783b06b18 (a java.lang.Class for java.net.URL)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.felix.framework.util.SecureAction.invoke(SecureAction.java:840)
at
org.apache.felix.framework.URLHandlers.unregisterFrameworkInstance(URLHandlers.java:635)
at
org.apache.felix.framework.URLHandlersActivator.stop(URLHandlersActivator.java:76)
at
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667)
at
org.apache.felix.framework.Felix$SystemBundleActivator.stop(Felix.java:4715)
at
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2530)
at org.apache.felix.framework.Felix$2.run(Felix.java:959)
at java.lang.Thread.run(Thread.java:724)
main:
at org.apache.felix.framework.URLHandlers.init(URLHandlers.java:150)
- waiting to lock 0x000783b06b18 (a java.lang.Class for
java.net.URL)
at
org.apache.felix.framework.URLHandlers.registerFrameworkInstance(URLHandlers.java:600)
- locked 0x0007ff33e7f0 (a java.util.ArrayList)
at
org.apache.felix.framework.URLHandlersActivator.start(URLHandlersActivator.java:71)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
at
org.apache.felix.framework.Felix$SystemBundleActivator.start(Felix.java:4634)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
at org.apache.felix.framework.Felix.init(Felix.java:783)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (FELIX-4523) Deadlock in URLHandlers when Felix.init and Felix.stop are called concurrently
[
https://issues.apache.org/jira/browse/FELIX-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14041961#comment-14041961
]
Karl Pauls commented on FELIX-4523:
---
Can you try the attached patch (against the current trunk) and see whether that
fixes your issue? That would be great...
Deadlock in URLHandlers when Felix.init and Felix.stop are called concurrently
--
Key: FELIX-4523
URL: https://issues.apache.org/jira/browse/FELIX-4523
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-4.2.1
Environment: linux, junittests
Reporter: Benjamin Rogge
Assignee: Karl Pauls
Attachments: urlhandlers.patch
From time to time we are experiencing a deadlock in the URLHandlers Class in
Apache Felix. We are using Felix as an embedded OSGi Container and
instantiate the Felix Framework via ServiceLoader and Framework Factory
ourselves. The situation is as follows: When Felix.stop and Felix.init are
called by different threads, eventually
URLHandlers.unregisterFrameworkListsForContextSearch and
URLHandlers.registerFrameworkInstance are called by the threads. There are
two locks: m_frameworks and the Class Object of URL (URL.class).
registerFrameworkInstance tries to aquire m_frameworks first and via the
constructor of URLHanders URL.class after that.
unregisterFrameworkListsForContextSearch tries to aquire URL.class first and
m_frameworks after that. This is a classic deadlock situation. The situation
arises in unittests where we frequently start and stop the felix framework.
Stacktracke log:
{code}
Found one Java-level deadlock:
=
FelixShutdown:
waiting to lock monitor 0x00ff7710 (object 0x0007ff33e7f0, a
java.util.ArrayList),
which is held by main
main:
waiting to lock monitor 0x022c4a08 (object 0x000783b06b18, a
java.lang.Class),
which is held by FelixShutdown
Java stack information for the threads listed above:
===
FelixShutdown:
at
org.apache.felix.framework.URLHandlers.unregisterFrameworkListsForContextSearch(URLHandlers.java:315)
- waiting to lock 0x0007ff33e7f0 (a java.util.ArrayList)
- locked 0x0007ff33e840 (a java.util.HashMap)
- locked 0x000783b06b18 (a java.lang.Class for java.net.URL)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.felix.framework.util.SecureAction.invoke(SecureAction.java:840)
at
org.apache.felix.framework.URLHandlers.unregisterFrameworkInstance(URLHandlers.java:635)
at
org.apache.felix.framework.URLHandlersActivator.stop(URLHandlersActivator.java:76)
at
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667)
at
org.apache.felix.framework.Felix$SystemBundleActivator.stop(Felix.java:4715)
at
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2530)
at org.apache.felix.framework.Felix$2.run(Felix.java:959)
at java.lang.Thread.run(Thread.java:724)
main:
at org.apache.felix.framework.URLHandlers.init(URLHandlers.java:150)
- waiting to lock 0x000783b06b18 (a java.lang.Class for
java.net.URL)
at
org.apache.felix.framework.URLHandlers.registerFrameworkInstance(URLHandlers.java:600)
- locked 0x0007ff33e7f0 (a java.util.ArrayList)
at
org.apache.felix.framework.URLHandlersActivator.start(URLHandlersActivator.java:71)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
at
org.apache.felix.framework.Felix$SystemBundleActivator.start(Felix.java:4634)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
at org.apache.felix.framework.Felix.init(Felix.java:783)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[RESULT] [VOTE] Release Apache Felix Gogo Runtime 0.12.1
Closing this vote with 3 binding +1s and 3 non binding +1s. Cheers, Guillaume Nodet 2014-06-14 11:09 GMT+02:00 Guillaume Nodet gno...@apache.org: I'm calling a vote on Felix Gogo Runtime 0.12.1. Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-1020/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1020 /tmp/felix-staging Changes: ** Bug * [FELIX-4533] - Gogo runtime does not advertise published services Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Cheers, Guillaume
[jira] [Commented] (FELIX-4523) Deadlock in URLHandlers when Felix.init and Felix.stop are called concurrently
[
https://issues.apache.org/jira/browse/FELIX-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042032#comment-14042032
]
Benjamin Rogge commented on FELIX-4523:
---
@[~karlpauls]: Thank you very much. It might take me a couple of days (to find
time to do it), but I'm on it.
Deadlock in URLHandlers when Felix.init and Felix.stop are called concurrently
--
Key: FELIX-4523
URL: https://issues.apache.org/jira/browse/FELIX-4523
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-4.2.1
Environment: linux, junittests
Reporter: Benjamin Rogge
Assignee: Karl Pauls
Attachments: urlhandlers.patch
From time to time we are experiencing a deadlock in the URLHandlers Class in
Apache Felix. We are using Felix as an embedded OSGi Container and
instantiate the Felix Framework via ServiceLoader and Framework Factory
ourselves. The situation is as follows: When Felix.stop and Felix.init are
called by different threads, eventually
URLHandlers.unregisterFrameworkListsForContextSearch and
URLHandlers.registerFrameworkInstance are called by the threads. There are
two locks: m_frameworks and the Class Object of URL (URL.class).
registerFrameworkInstance tries to aquire m_frameworks first and via the
constructor of URLHanders URL.class after that.
unregisterFrameworkListsForContextSearch tries to aquire URL.class first and
m_frameworks after that. This is a classic deadlock situation. The situation
arises in unittests where we frequently start and stop the felix framework.
Stacktracke log:
{code}
Found one Java-level deadlock:
=
FelixShutdown:
waiting to lock monitor 0x00ff7710 (object 0x0007ff33e7f0, a
java.util.ArrayList),
which is held by main
main:
waiting to lock monitor 0x022c4a08 (object 0x000783b06b18, a
java.lang.Class),
which is held by FelixShutdown
Java stack information for the threads listed above:
===
FelixShutdown:
at
org.apache.felix.framework.URLHandlers.unregisterFrameworkListsForContextSearch(URLHandlers.java:315)
- waiting to lock 0x0007ff33e7f0 (a java.util.ArrayList)
- locked 0x0007ff33e840 (a java.util.HashMap)
- locked 0x000783b06b18 (a java.lang.Class for java.net.URL)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.felix.framework.util.SecureAction.invoke(SecureAction.java:840)
at
org.apache.felix.framework.URLHandlers.unregisterFrameworkInstance(URLHandlers.java:635)
at
org.apache.felix.framework.URLHandlersActivator.stop(URLHandlersActivator.java:76)
at
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667)
at
org.apache.felix.framework.Felix$SystemBundleActivator.stop(Felix.java:4715)
at
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2530)
at org.apache.felix.framework.Felix$2.run(Felix.java:959)
at java.lang.Thread.run(Thread.java:724)
main:
at org.apache.felix.framework.URLHandlers.init(URLHandlers.java:150)
- waiting to lock 0x000783b06b18 (a java.lang.Class for
java.net.URL)
at
org.apache.felix.framework.URLHandlers.registerFrameworkInstance(URLHandlers.java:600)
- locked 0x0007ff33e7f0 (a java.util.ArrayList)
at
org.apache.felix.framework.URLHandlersActivator.start(URLHandlersActivator.java:71)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
at
org.apache.felix.framework.Felix$SystemBundleActivator.start(Felix.java:4634)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
at org.apache.felix.framework.Felix.init(Felix.java:783)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (FELIX-4540) Deadlock in BundleWiringImpl$BundleClassLoader.loadClass
Martin Lichtin created FELIX-4540:
-
Summary: Deadlock in BundleWiringImpl$BundleClassLoader.loadClass
Key: FELIX-4540
URL: https://issues.apache.org/jira/browse/FELIX-4540
Project: Felix
Issue Type: Bug
Environment: Karaf 2.3.4
Reporter: Martin Lichtin
{noformat}
Found one Java-level deadlock:
=
Pax Web Runtime worker:
waiting to lock monitor 0x0b0a1438 (object 0xfb585990, a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
which is held by Thread-15
Thread-15:
waiting to lock monitor 0x0b0a1388 (object 0xf7681f70, a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
which is held by Pax Web Runtime worker
Java stack information for the threads listed above:
===
Pax Web Runtime worker:
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
- waiting to lock 0xfb585990 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.ops4j.pax.web.service.internal.Activator.updateController(Activator.java:247)
at
org.ops4j.pax.web.service.internal.Activator$DynamicsServiceTrackerCustomizer$1.run(Activator.java:376)
at
org.ops4j.pax.web.service.internal.Executor$Future.run(Executor.java:47)
at
org.ops4j.pax.web.service.internal.Executor$Worker.run(Executor.java:128)
Thread-15:
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
- waiting to lock 0xf7681f70 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2128)
- locked 0xfb585990 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.ops4j.pax.web.extender.whiteboard.internal.util.WebContainerUtils.webContainerAvailable(WebContainerUtils.java:46)
at
org.ops4j.pax.web.extender.whiteboard.internal.util.WebContainerUtils.clinit(WebContainerUtils.java:35)
at
org.ops4j.pax.web.extender.whiteboard.internal.Activator.start(Activator.java:78)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1977)
at
[jira] [Commented] (FELIX-4540) Deadlock in BundleWiringImpl$BundleClassLoader.loadClass
[
https://issues.apache.org/jira/browse/FELIX-4540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042069#comment-14042069
]
Richard S. Hall commented on FELIX-4540:
I know nothing about Karaf, so it might be better to give us information about
the framework version instead.
Which version of Java are you using?
Deadlock in BundleWiringImpl$BundleClassLoader.loadClass
Key: FELIX-4540
URL: https://issues.apache.org/jira/browse/FELIX-4540
Project: Felix
Issue Type: Bug
Environment: Karaf 2.3.4
Reporter: Martin Lichtin
{noformat}
Found one Java-level deadlock:
=
Pax Web Runtime worker:
waiting to lock monitor 0x0b0a1438 (object 0xfb585990, a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
which is held by Thread-15
Thread-15:
waiting to lock monitor 0x0b0a1388 (object 0xf7681f70, a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
which is held by Pax Web Runtime worker
Java stack information for the threads listed above:
===
Pax Web Runtime worker:
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
- waiting to lock 0xfb585990 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.ops4j.pax.web.service.internal.Activator.updateController(Activator.java:247)
at
org.ops4j.pax.web.service.internal.Activator$DynamicsServiceTrackerCustomizer$1.run(Activator.java:376)
at
org.ops4j.pax.web.service.internal.Executor$Future.run(Executor.java:47)
at
org.ops4j.pax.web.service.internal.Executor$Worker.run(Executor.java:128)
Thread-15:
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
- waiting to lock 0xf7681f70 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2128)
- locked 0xfb585990 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
[jira] [Commented] (FELIX-4540) Deadlock in BundleWiringImpl$BundleClassLoader.loadClass
[
https://issues.apache.org/jira/browse/FELIX-4540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042080#comment-14042080
]
Achim Nierbeck commented on FELIX-4540:
---
Karaf 2.3.4 and higher is using Felix in version 4.0.3
Deadlock in BundleWiringImpl$BundleClassLoader.loadClass
Key: FELIX-4540
URL: https://issues.apache.org/jira/browse/FELIX-4540
Project: Felix
Issue Type: Bug
Environment: Karaf 2.3.4
Reporter: Martin Lichtin
{noformat}
Found one Java-level deadlock:
=
Pax Web Runtime worker:
waiting to lock monitor 0x0b0a1438 (object 0xfb585990, a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
which is held by Thread-15
Thread-15:
waiting to lock monitor 0x0b0a1388 (object 0xf7681f70, a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
which is held by Pax Web Runtime worker
Java stack information for the threads listed above:
===
Pax Web Runtime worker:
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
- waiting to lock 0xfb585990 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.ops4j.pax.web.service.internal.Activator.updateController(Activator.java:247)
at
org.ops4j.pax.web.service.internal.Activator$DynamicsServiceTrackerCustomizer$1.run(Activator.java:376)
at
org.ops4j.pax.web.service.internal.Executor$Future.run(Executor.java:47)
at
org.ops4j.pax.web.service.internal.Executor$Worker.run(Executor.java:128)
Thread-15:
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
- waiting to lock 0xf7681f70 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2128)
- locked 0xfb585990 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.ops4j.pax.web.extender.whiteboard.internal.util.WebContainerUtils.webContainerAvailable(WebContainerUtils.java:46)
at
[jira] [Commented] (FELIX-4540) Deadlock in BundleWiringImpl$BundleClassLoader.loadClass
[
https://issues.apache.org/jira/browse/FELIX-4540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042101#comment-14042101
]
Richard S. Hall commented on FELIX-4540:
And what about Java version?
Deadlock in BundleWiringImpl$BundleClassLoader.loadClass
Key: FELIX-4540
URL: https://issues.apache.org/jira/browse/FELIX-4540
Project: Felix
Issue Type: Bug
Environment: Karaf 2.3.4
Reporter: Martin Lichtin
{noformat}
Found one Java-level deadlock:
=
Pax Web Runtime worker:
waiting to lock monitor 0x0b0a1438 (object 0xfb585990, a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
which is held by Thread-15
Thread-15:
waiting to lock monitor 0x0b0a1388 (object 0xf7681f70, a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
which is held by Pax Web Runtime worker
Java stack information for the threads listed above:
===
Pax Web Runtime worker:
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
- waiting to lock 0xfb585990 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.ops4j.pax.web.service.internal.Activator.updateController(Activator.java:247)
at
org.ops4j.pax.web.service.internal.Activator$DynamicsServiceTrackerCustomizer$1.run(Activator.java:376)
at
org.ops4j.pax.web.service.internal.Executor$Future.run(Executor.java:47)
at
org.ops4j.pax.web.service.internal.Executor$Worker.run(Executor.java:128)
Thread-15:
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
- waiting to lock 0xf7681f70 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2128)
- locked 0xfb585990 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.ops4j.pax.web.extender.whiteboard.internal.util.WebContainerUtils.webContainerAvailable(WebContainerUtils.java:46)
at
[jira] [Updated] (FELIX-4540) Deadlock in BundleWiringImpl$BundleClassLoader.loadClass
[
https://issues.apache.org/jira/browse/FELIX-4540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Lichtin updated FELIX-4540:
--
Environment:
java version 1.7.0_55
Karaf 2.3.4, Felix 4.0.3
was:Karaf 2.3.4
Deadlock in BundleWiringImpl$BundleClassLoader.loadClass
Key: FELIX-4540
URL: https://issues.apache.org/jira/browse/FELIX-4540
Project: Felix
Issue Type: Bug
Environment: java version 1.7.0_55
Karaf 2.3.4, Felix 4.0.3
Reporter: Martin Lichtin
{noformat}
Found one Java-level deadlock:
=
Pax Web Runtime worker:
waiting to lock monitor 0x0b0a1438 (object 0xfb585990, a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
which is held by Thread-15
Thread-15:
waiting to lock monitor 0x0b0a1388 (object 0xf7681f70, a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
which is held by Pax Web Runtime worker
Java stack information for the threads listed above:
===
Pax Web Runtime worker:
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
- waiting to lock 0xfb585990 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.ops4j.pax.web.service.internal.Activator.updateController(Activator.java:247)
at
org.ops4j.pax.web.service.internal.Activator$DynamicsServiceTrackerCustomizer$1.run(Activator.java:376)
at
org.ops4j.pax.web.service.internal.Executor$Future.run(Executor.java:47)
at
org.ops4j.pax.web.service.internal.Executor$Worker.run(Executor.java:128)
Thread-15:
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
- waiting to lock 0xf7681f70 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2128)
- locked 0xfb585990 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.ops4j.pax.web.extender.whiteboard.internal.util.WebContainerUtils.webContainerAvailable(WebContainerUtils.java:46)
at
[jira] [Commented] (FELIX-4540) Deadlock in BundleWiringImpl$BundleClassLoader.loadClass
[
https://issues.apache.org/jira/browse/FELIX-4540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042119#comment-14042119
]
Richard S. Hall commented on FELIX-4540:
Just to cut to the chase, I'm guess that this is the standard JVM class loader
deadlock issue. If you are on Java 7, then you should try upgrading your
framework version since 4.0.3 does not take advantage of the parallel capable
class loaders introduced in Java, but more recent framework versions do.
Deadlock in BundleWiringImpl$BundleClassLoader.loadClass
Key: FELIX-4540
URL: https://issues.apache.org/jira/browse/FELIX-4540
Project: Felix
Issue Type: Bug
Environment: java version 1.7.0_55
Karaf 2.3.4, Felix 4.0.3
Reporter: Martin Lichtin
{noformat}
Found one Java-level deadlock:
=
Pax Web Runtime worker:
waiting to lock monitor 0x0b0a1438 (object 0xfb585990, a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
which is held by Thread-15
Thread-15:
waiting to lock monitor 0x0b0a1388 (object 0xf7681f70, a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
which is held by Pax Web Runtime worker
Java stack information for the threads listed above:
===
Pax Web Runtime worker:
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
- waiting to lock 0xfb585990 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.ops4j.pax.web.service.internal.Activator.updateController(Activator.java:247)
at
org.ops4j.pax.web.service.internal.Activator$DynamicsServiceTrackerCustomizer$1.run(Activator.java:376)
at
org.ops4j.pax.web.service.internal.Executor$Future.run(Executor.java:47)
at
org.ops4j.pax.web.service.internal.Executor$Worker.run(Executor.java:128)
Thread-15:
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
- waiting to lock 0xf7681f70 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2128)
- locked 0xfb585990 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
[jira] [Comment Edited] (FELIX-4540) Deadlock in BundleWiringImpl$BundleClassLoader.loadClass
[
https://issues.apache.org/jira/browse/FELIX-4540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042119#comment-14042119
]
Richard S. Hall edited comment on FELIX-4540 at 6/24/14 1:53 PM:
-
Just to cut to the chase, I'm guess that this is the standard JVM class loader
deadlock issue. If you are on Java 7, then you should try upgrading your
framework version since 4.0.3 does not take advantage of the parallel capable
class loaders introduced in Java 7, but more recent framework versions do.
was (Author: rickhall):
Just to cut to the chase, I'm guess that this is the standard JVM class loader
deadlock issue. If you are on Java 7, then you should try upgrading your
framework version since 4.0.3 does not take advantage of the parallel capable
class loaders introduced in Java, but more recent framework versions do.
Deadlock in BundleWiringImpl$BundleClassLoader.loadClass
Key: FELIX-4540
URL: https://issues.apache.org/jira/browse/FELIX-4540
Project: Felix
Issue Type: Bug
Environment: java version 1.7.0_55
Karaf 2.3.4, Felix 4.0.3
Reporter: Martin Lichtin
{noformat}
Found one Java-level deadlock:
=
Pax Web Runtime worker:
waiting to lock monitor 0x0b0a1438 (object 0xfb585990, a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
which is held by Thread-15
Thread-15:
waiting to lock monitor 0x0b0a1388 (object 0xf7681f70, a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
which is held by Pax Web Runtime worker
Java stack information for the threads listed above:
===
Pax Web Runtime worker:
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
- waiting to lock 0xfb585990 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.ops4j.pax.web.service.internal.Activator.updateController(Activator.java:247)
at
org.ops4j.pax.web.service.internal.Activator$DynamicsServiceTrackerCustomizer$1.run(Activator.java:376)
at
org.ops4j.pax.web.service.internal.Executor$Future.run(Executor.java:47)
at
org.ops4j.pax.web.service.internal.Executor$Worker.run(Executor.java:128)
Thread-15:
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
- waiting to lock 0xf7681f70 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2128)
- locked 0xfb585990 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
[jira] [Assigned] (FELIX-1651) Support * in servlet registrations
[ https://issues.apache.org/jira/browse/FELIX-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J.W. Janssen reassigned FELIX-1651: --- Assignee: J.W. Janssen Support * in servlet registrations -- Key: FELIX-1651 URL: https://issues.apache.org/jira/browse/FELIX-1651 Project: Felix Issue Type: Sub-task Components: HTTP Service Affects Versions: http-2.0.2 Reporter: Mirko Tschäni Assignee: J.W. Janssen At the moment it is only possible to register servlets with aliases like / or /some/path. Registering servlets with a wildcard alias (i.e. *.jpg or *.jsp) is supported yet. I think it would make sense to support wildcards in servlet mappings. I have also noticed, that filter mappings do support regular expressions in aliases, it might make sense to support regular expressions in servlet mappings as well (all though it is a little bit confusing to see that /test/* does not match /test/hello.txt in filter mappings, but i still prefer using regular expressions over the limited wildcard support in standard jee servlet mappings). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (FELIX-4541) Add support for multiple patterns in servlet/filter registration
J.W. Janssen created FELIX-4541: --- Summary: Add support for multiple patterns in servlet/filter registration Key: FELIX-4541 URL: https://issues.apache.org/jira/browse/FELIX-4541 Project: Felix Issue Type: Sub-task Components: HTTP Service Reporter: J.W. Janssen Assignee: J.W. Janssen RFC-189 allows servlets and filters to be registered with multiple paths (and even regex's for filters). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FELIX-4523) Deadlock in URLHandlers when Felix.init and Felix.stop are called concurrently
[
https://issues.apache.org/jira/browse/FELIX-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-4523:
--
Attachment: urlhandlers-2.patch
Updated patch.
Deadlock in URLHandlers when Felix.init and Felix.stop are called concurrently
--
Key: FELIX-4523
URL: https://issues.apache.org/jira/browse/FELIX-4523
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-4.2.1
Environment: linux, junittests
Reporter: Benjamin Rogge
Assignee: Karl Pauls
Attachments: urlhandlers-2.patch, urlhandlers.patch
From time to time we are experiencing a deadlock in the URLHandlers Class in
Apache Felix. We are using Felix as an embedded OSGi Container and
instantiate the Felix Framework via ServiceLoader and Framework Factory
ourselves. The situation is as follows: When Felix.stop and Felix.init are
called by different threads, eventually
URLHandlers.unregisterFrameworkListsForContextSearch and
URLHandlers.registerFrameworkInstance are called by the threads. There are
two locks: m_frameworks and the Class Object of URL (URL.class).
registerFrameworkInstance tries to aquire m_frameworks first and via the
constructor of URLHanders URL.class after that.
unregisterFrameworkListsForContextSearch tries to aquire URL.class first and
m_frameworks after that. This is a classic deadlock situation. The situation
arises in unittests where we frequently start and stop the felix framework.
Stacktracke log:
{code}
Found one Java-level deadlock:
=
FelixShutdown:
waiting to lock monitor 0x00ff7710 (object 0x0007ff33e7f0, a
java.util.ArrayList),
which is held by main
main:
waiting to lock monitor 0x022c4a08 (object 0x000783b06b18, a
java.lang.Class),
which is held by FelixShutdown
Java stack information for the threads listed above:
===
FelixShutdown:
at
org.apache.felix.framework.URLHandlers.unregisterFrameworkListsForContextSearch(URLHandlers.java:315)
- waiting to lock 0x0007ff33e7f0 (a java.util.ArrayList)
- locked 0x0007ff33e840 (a java.util.HashMap)
- locked 0x000783b06b18 (a java.lang.Class for java.net.URL)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.felix.framework.util.SecureAction.invoke(SecureAction.java:840)
at
org.apache.felix.framework.URLHandlers.unregisterFrameworkInstance(URLHandlers.java:635)
at
org.apache.felix.framework.URLHandlersActivator.stop(URLHandlersActivator.java:76)
at
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667)
at
org.apache.felix.framework.Felix$SystemBundleActivator.stop(Felix.java:4715)
at
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2530)
at org.apache.felix.framework.Felix$2.run(Felix.java:959)
at java.lang.Thread.run(Thread.java:724)
main:
at org.apache.felix.framework.URLHandlers.init(URLHandlers.java:150)
- waiting to lock 0x000783b06b18 (a java.lang.Class for
java.net.URL)
at
org.apache.felix.framework.URLHandlers.registerFrameworkInstance(URLHandlers.java:600)
- locked 0x0007ff33e7f0 (a java.util.ArrayList)
at
org.apache.felix.framework.URLHandlersActivator.start(URLHandlersActivator.java:71)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
at
org.apache.felix.framework.Felix$SystemBundleActivator.start(Felix.java:4634)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
at org.apache.felix.framework.Felix.init(Felix.java:783)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (FELIX-4523) Deadlock in URLHandlers when Felix.init and Felix.stop are called concurrently
[
https://issues.apache.org/jira/browse/FELIX-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042203#comment-14042203
]
Karl Pauls commented on FELIX-4523:
---
[~plastic-karma] cool. Please note, I uploaded a slightly modified patch
(urlhandlers-2.patch). Please use that one for your testing. Looking forward to
hear if it helps. Furthermore, if you manage to get this captured in
reproducible test case that would be even better :-).
Deadlock in URLHandlers when Felix.init and Felix.stop are called concurrently
--
Key: FELIX-4523
URL: https://issues.apache.org/jira/browse/FELIX-4523
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-4.2.1
Environment: linux, junittests
Reporter: Benjamin Rogge
Assignee: Karl Pauls
Attachments: urlhandlers-2.patch, urlhandlers.patch
From time to time we are experiencing a deadlock in the URLHandlers Class in
Apache Felix. We are using Felix as an embedded OSGi Container and
instantiate the Felix Framework via ServiceLoader and Framework Factory
ourselves. The situation is as follows: When Felix.stop and Felix.init are
called by different threads, eventually
URLHandlers.unregisterFrameworkListsForContextSearch and
URLHandlers.registerFrameworkInstance are called by the threads. There are
two locks: m_frameworks and the Class Object of URL (URL.class).
registerFrameworkInstance tries to aquire m_frameworks first and via the
constructor of URLHanders URL.class after that.
unregisterFrameworkListsForContextSearch tries to aquire URL.class first and
m_frameworks after that. This is a classic deadlock situation. The situation
arises in unittests where we frequently start and stop the felix framework.
Stacktracke log:
{code}
Found one Java-level deadlock:
=
FelixShutdown:
waiting to lock monitor 0x00ff7710 (object 0x0007ff33e7f0, a
java.util.ArrayList),
which is held by main
main:
waiting to lock monitor 0x022c4a08 (object 0x000783b06b18, a
java.lang.Class),
which is held by FelixShutdown
Java stack information for the threads listed above:
===
FelixShutdown:
at
org.apache.felix.framework.URLHandlers.unregisterFrameworkListsForContextSearch(URLHandlers.java:315)
- waiting to lock 0x0007ff33e7f0 (a java.util.ArrayList)
- locked 0x0007ff33e840 (a java.util.HashMap)
- locked 0x000783b06b18 (a java.lang.Class for java.net.URL)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.felix.framework.util.SecureAction.invoke(SecureAction.java:840)
at
org.apache.felix.framework.URLHandlers.unregisterFrameworkInstance(URLHandlers.java:635)
at
org.apache.felix.framework.URLHandlersActivator.stop(URLHandlersActivator.java:76)
at
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667)
at
org.apache.felix.framework.Felix$SystemBundleActivator.stop(Felix.java:4715)
at
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2530)
at org.apache.felix.framework.Felix$2.run(Felix.java:959)
at java.lang.Thread.run(Thread.java:724)
main:
at org.apache.felix.framework.URLHandlers.init(URLHandlers.java:150)
- waiting to lock 0x000783b06b18 (a java.lang.Class for
java.net.URL)
at
org.apache.felix.framework.URLHandlers.registerFrameworkInstance(URLHandlers.java:600)
- locked 0x0007ff33e7f0 (a java.util.ArrayList)
at
org.apache.felix.framework.URLHandlersActivator.start(URLHandlersActivator.java:71)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
at
org.apache.felix.framework.Felix$SystemBundleActivator.start(Felix.java:4634)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
at org.apache.felix.framework.Felix.init(Felix.java:783)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (FELIX-4542) Basic type validation for different types of the Attribute Definitions (AD) within the metatype
Konrad Windszus created FELIX-4542: -- Summary: Basic type validation for different types of the Attribute Definitions (AD) within the metatype Key: FELIX-4542 URL: https://issues.apache.org/jira/browse/FELIX-4542 Project: Felix Issue Type: Improvement Affects Versions: webconsole-4.2.2 Reporter: Konrad Windszus The OSGi Compendium 4.3 $105.6.1 defines the following types for the AD elements - String - Long - Double - Float - Integer - Byte - Char - Boolean - Short Currently all except boolean are rendered by the configuration tab in the web console as regular input fields (with type=text) with no further validation. For example it is possible to enter a string for an attribute with type Long. There is no exception in the log but the value is not changed (because it had the wrong type). One option would be to switch to HTML5 which supports a lot more types OOTB (http://www.w3schools.com/tags/att_input_type.asp) or use a library like http://jqueryvalidation.org/documentation/. For all numeric types the minimum and maximum should be set. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FELIX-4542) Basic type validation for different types of the Attribute Definitions (AD) within the metatype
[ https://issues.apache.org/jira/browse/FELIX-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated FELIX-4542: --- Description: The OSGi Compendium 4.3 $105.6.1 defines the following types for the AD elements - String - Long - Double - Float - Integer - Byte - Char - Boolean - Short Currently all except boolean are rendered by the configuration tab in the web console as regular input fields (with type=text) with no further validation. For example it is possible to enter a string for an attribute with type Long. There is no exception in the log but the value is not changed (because it had the wrong type). One option would be to switch to HTML5 which supports a lot more types OOTB (http://www.w3schools.com/tags/att_input_type.asp) or use a library like http://jqueryvalidation.org/documentation/. For all numeric types the minimum and maximum should be validated. was: The OSGi Compendium 4.3 $105.6.1 defines the following types for the AD elements - String - Long - Double - Float - Integer - Byte - Char - Boolean - Short Currently all except boolean are rendered by the configuration tab in the web console as regular input fields (with type=text) with no further validation. For example it is possible to enter a string for an attribute with type Long. There is no exception in the log but the value is not changed (because it had the wrong type). One option would be to switch to HTML5 which supports a lot more types OOTB (http://www.w3schools.com/tags/att_input_type.asp) or use a library like http://jqueryvalidation.org/documentation/. For all numeric types the minimum and maximum should be set. Basic type validation for different types of the Attribute Definitions (AD) within the metatype --- Key: FELIX-4542 URL: https://issues.apache.org/jira/browse/FELIX-4542 Project: Felix Issue Type: Improvement Affects Versions: webconsole-4.2.2 Reporter: Konrad Windszus The OSGi Compendium 4.3 $105.6.1 defines the following types for the AD elements - String - Long - Double - Float - Integer - Byte - Char - Boolean - Short Currently all except boolean are rendered by the configuration tab in the web console as regular input fields (with type=text) with no further validation. For example it is possible to enter a string for an attribute with type Long. There is no exception in the log but the value is not changed (because it had the wrong type). One option would be to switch to HTML5 which supports a lot more types OOTB (http://www.w3schools.com/tags/att_input_type.asp) or use a library like http://jqueryvalidation.org/documentation/. For all numeric types the minimum and maximum should be validated. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FELIX-4542) Basic type validation for different types of the Attribute Definitions (AD) within the metatype
[ https://issues.apache.org/jira/browse/FELIX-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated FELIX-4542: --- Description: The OSGi Compendium 4.3 $105.7.1 defines the following types for the AD elements - String - Long - Double - Float - Integer - Byte - Char - Boolean - Short - Password Currently all except boolean are rendered by the configuration tab in the web console as regular input fields (with type=text) with no further validation. For example it is possible to enter a string for an attribute with type Long. There is no exception in the log but the value is not changed (because it had the wrong type). One option would be to switch to HTML5 which supports a lot more types OOTB (http://www.w3schools.com/tags/att_input_type.asp) or use a library like http://jqueryvalidation.org/documentation/. For all numeric types the minimum and maximum should be validated. was: The OSGi Compendium 4.3 $105.6.1 defines the following types for the AD elements - String - Long - Double - Float - Integer - Byte - Char - Boolean - Short Currently all except boolean are rendered by the configuration tab in the web console as regular input fields (with type=text) with no further validation. For example it is possible to enter a string for an attribute with type Long. There is no exception in the log but the value is not changed (because it had the wrong type). One option would be to switch to HTML5 which supports a lot more types OOTB (http://www.w3schools.com/tags/att_input_type.asp) or use a library like http://jqueryvalidation.org/documentation/. For all numeric types the minimum and maximum should be validated. Basic type validation for different types of the Attribute Definitions (AD) within the metatype --- Key: FELIX-4542 URL: https://issues.apache.org/jira/browse/FELIX-4542 Project: Felix Issue Type: Improvement Affects Versions: webconsole-4.2.2 Reporter: Konrad Windszus The OSGi Compendium 4.3 $105.7.1 defines the following types for the AD elements - String - Long - Double - Float - Integer - Byte - Char - Boolean - Short - Password Currently all except boolean are rendered by the configuration tab in the web console as regular input fields (with type=text) with no further validation. For example it is possible to enter a string for an attribute with type Long. There is no exception in the log but the value is not changed (because it had the wrong type). One option would be to switch to HTML5 which supports a lot more types OOTB (http://www.w3schools.com/tags/att_input_type.asp) or use a library like http://jqueryvalidation.org/documentation/. For all numeric types the minimum and maximum should be validated. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FELIX-4281) Security Warning: Felix with Java Web Start
[ https://issues.apache.org/jira/browse/FELIX-4281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042562#comment-14042562 ] Nicolas Roduit commented on FELIX-4281: --- It is OK for me. I let Cesar Souza close the issue. Security Warning: Felix with Java Web Start --- Key: FELIX-4281 URL: https://issues.apache.org/jira/browse/FELIX-4281 Project: Felix Issue Type: Bug Environment: Windows 7 with Java 7 update 40, 64 bits Reporter: Cesar Souza Assignee: Karl Pauls Priority: Minor Fix For: framework-4.6.0 Attachments: message.zip, sec_action.patch, viewer.jnlp, webstart.patch Since the release of Java 7 update 40 the following warning occurs when you try to execute a signed (with valid certificate) Java Web Start application: - Security Warning Do you want to run this application? An unsigned application from the location below is requesting permission to run. http://.. Running unsigned applications like this will be blocked in a future release because it is potentially unsafe and a security risk - Although the Java recognizes the certificate in the first dialog, it shows the warning message when the Felix's init method is invoked. I have tested a same application over Java 7 update 21 and everything is ok. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (FELIX-4281) Security Warning: Felix with Java Web Start
[ https://issues.apache.org/jira/browse/FELIX-4281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cesar Souza closed FELIX-4281. -- Security Warning: Felix with Java Web Start --- Key: FELIX-4281 URL: https://issues.apache.org/jira/browse/FELIX-4281 Project: Felix Issue Type: Bug Environment: Windows 7 with Java 7 update 40, 64 bits Reporter: Cesar Souza Assignee: Karl Pauls Priority: Minor Fix For: framework-4.6.0 Attachments: message.zip, sec_action.patch, viewer.jnlp, webstart.patch Since the release of Java 7 update 40 the following warning occurs when you try to execute a signed (with valid certificate) Java Web Start application: - Security Warning Do you want to run this application? An unsigned application from the location below is requesting permission to run. http://.. Running unsigned applications like this will be blocked in a future release because it is potentially unsafe and a security risk - Although the Java recognizes the certificate in the first dialog, it shows the warning message when the Felix's init method is invoked. I have tested a same application over Java 7 update 21 and everything is ok. -- This message was sent by Atlassian JIRA (v6.2#6252)
