[jira] [Created] (FELIX-5943) Felix Framework / Resolver Dependency
Tom Rutchik created FELIX-5943: -- Summary: Felix Framework / Resolver Dependency Key: FELIX-5943 URL: https://issues.apache.org/jira/browse/FELIX-5943 Project: Felix Issue Type: Improvement Components: Framework Reporter: Tom Rutchik The packaging of Felix framework and resolver seems not to be done in an OSGI manner. "Org.apache.felix.framework" and "org.apache.felix.resolver" sources are separate components, but are combined together in the resultant "org.apache.felix.framework" jar file. It's not specified as a dependency but seems to be assembled in a copy and paste manner. The reason its done this way is probably due to the dependency of "org.apache.felix.resolver" on an earlier version of the Felix framework. "Org.apache.felix.framework" has as a dependency on "org.apache.felix.resolver" and vice-a-versa. This cyclic specification is what makes it problematic and why the assemble was done in this copy and paste manner. Obviously, the packaging of the two sources as one jar makes for a simple and convienient one jar dependence for embedding Felix into an application. I discovered this issue, when I added the framework source to my application and then discovered that the framework required the Resolver class which was missing, so I added a dependency for the Resolver in my application. This appeared to work, until some magic threshold was hit that cause the class resolution order to change. What I discovered was that I had two different copies of "org.osgi.framework.Version" in my application. For a while, I was getting the newer version of "Version" that contained the "valueOf" method in it. When that magical threshold was hit, it caused me to get the older version of "Version" which didn't have the "valueOf" method in it, which cause the code to crash. A tough problem to track down. The root cause, IMHO, however comes back to an improper specification of the dependency. I think it fair to say the Felix framework and resolver components aren't constructed in a manner congruent with OSGI principals. Embedding the source into a application rather then adding a jar dependency can be useful to developers who kind-a wants to look-behind-the-curtain if they are running into some non-obvious issues with their OSGI embedded environment. It's often a lot little easier to debug in this configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [VOTE] Release osgicheck maven plugin 0.1.0
On 25 Sep 2018, at 0:44, Carsten Ziegeler wrote: > If you find any additional bugs or want improvements, please file them > as jira issues Wildo - was actually meaning to do that last night but got side tracked. So far it seems to be working well when run from an actual build with an artefact. --- "The ease with which a change can be implemented has no relevance at all to whether it is the right change for the (Java) Platform for all time." Mark Reinhold. Mark Derricutt http://www.theoryinpractice.net http://www.chaliceofblood.net http://plus.google.com/+MarkDerricutt http://twitter.com/talios http://facebook.com/mderricutt signature.asc Description: OpenPGP digital signature
[jira] [Updated] (FELIX-5683) getServiceProperties returns null instead of empty dictionary
[
https://issues.apache.org/jira/browse/FELIX-5683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5683:
-
Fix Version/s: org.apache.felix.dependencymanager-r12
> getServiceProperties returns null instead of empty dictionary
> -
>
> Key: FELIX-5683
> URL: https://issues.apache.org/jira/browse/FELIX-5683
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r9
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r12
>
>
> There are two issues:
> 1)
> In the felix users mailing list (see [1]), Bram reported the following:
> when you set a component service properties like this:
> {code}
> Component component =
> m_dependencyManager.createComponent().setInterface(ApplicationService.class.getName(),new
> Properties());
> component.getServiceProperties().put("a", "b");
> {code}
> then you get a NPE because the component.getServiceProperties() method
> returns null instead of the empty dictionary that has been set in the
> setInterfaceMethod.
> This is a regression made in r9 release, in the FELIX-5522 where a
> refactoring was done regarding aspect service properties.
> A fix can be made in order to behave like before (that is : avoid the NPE).
> 2)
> Bram, I may be wrong but I think that one new issue is that the dictionary
> returned by the getServiceProperties() method was so far (since the initial
> version of felix dm 2.0.1) a copy of the service properties dictionary
> maintained in the ComponentImpl, so if you would like to do set service
> properties like this:
> {code}
> Component component =
> m_dependencyManager.createComponent().setInterface(ApplicationService.class.getName(),new
> Properties());
> component.getServiceProperties().put("a", "b");
> m_dependencyManager.add(component); // won't add "a=b" properties
> {code}
> then the "a" property will be set in the copy of the internal dictionary
> returned by the getServiceProperties() method, and the "a=b" service
> properties won't be set when the component is added in the
> m_dependencyManager.
> So, if what I'm saying is correct and if you would like to see this new
> behavior implemented, please open a new jira issue and I will manage to
> implement it; thanks
> PS: I'm now fixing the 1) regression, in order to avoid the NPE.
> [1] http://www.mail-archive.com/users%40felix.apache.org/msg17939.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] felix pull request #156: FELIX-5942 - Replace wait/notify by lock/conditions...
Github user asfgit closed the pull request at: https://github.com/apache/felix/pull/156 ---
[jira] [Resolved] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved FELIX-5942.
---
Resolution: Fixed
Fix Version/s: framework-6.0.2
[~antoine.dessaigne], it looks like newer jdk versions have a changed behaviour
when it comes to fairness and synchronized. Good catch - I applied a modified
version of your patch that uses only one condition but sets the the lock to be
fair. It seems to work with your test.
Feel free to reopen this issue if it doesn't work for you. Many thanks for
reporting and providing the patch!
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-6.0.2
>
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global lock
> ** here we're resolving a class from a bundle with dynamic import packages
> * An Oracle JDK 10 or OpenJDK 11
> ** it's working fine with Oracle JDK 8
>
> Replacing the {{m_bundleLock}} by a fair {{ReentrantLock}} with a
> {{Condition}} makes it work with 10 parallel threads but still fails with 100
> threads.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16626230#comment-16626230
]
ASF GitHub Bot commented on FELIX-5942:
---
Github user asfgit closed the pull request at:
https://github.com/apache/felix/pull/156
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global lock
> ** here we're resolving a class from a bundle with dynamic import packages
> * An Oracle JDK 10 or OpenJDK 11
> ** it's working fine with Oracle JDK 8
>
> Replacing the {{m_bundleLock}} by a fair {{ReentrantLock}} with a
> {{Condition}} makes it work with 10 parallel threads but still fails with 100
> threads.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [VOTE] Release Apache Felix Metatype 1.2.2
+1 (binding) Regards JB Le 24 sept. 2018 à 17:40, à 17:40, Timothy Ward a écrit: >+1 (non-binding) > >> On 24 Sep 2018, at 11:26, Francois Papon > wrote: >> >> +1 (non-binding) >> >> Thanks ! >> >> Regards, >> >> François Papon >> fpa...@apache.org >> >> Le 23/09/2018 à 13:34, Carsten Ziegeler a écrit : >>> Hi all, >>> >>> we fixed one issue: >>> https://issues.apache.org/jira/browse/FELIX-5936 >>> >>> >>> Staging repositories: >>> >https://repository.apache.org/content/repositories/orgapachefelix-1261/ >>> >>> 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 1261 /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 at least 72 hours. >>> >>> Regards >>> Carsten >>
Re: [VOTE] Release Apache Felix Metatype 1.2.2
+1 (non-binding) > On 24 Sep 2018, at 11:26, Francois Papon wrote: > > +1 (non-binding) > > Thanks ! > > Regards, > > François Papon > fpa...@apache.org > > Le 23/09/2018 à 13:34, Carsten Ziegeler a écrit : >> Hi all, >> >> we fixed one issue: >> https://issues.apache.org/jira/browse/FELIX-5936 >> >> >> Staging repositories: >> https://repository.apache.org/content/repositories/orgapachefelix-1261/ >> >> 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 1261 /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 at least 72 hours. >> >> Regards >> Carsten >
[GitHub] felix pull request #156: FELIX-5942 - Replace wait/notify by lock/conditions...
GitHub user adessaigne opened a pull request: https://github.com/apache/felix/pull/156 FELIX-5942 - Replace wait/notify by lock/conditions in Felix to avoid freeze Fix proposal for [FELIX-5942](https://issues.apache.org/jira/browse/FELIX-5942). Instead of a single `Object` with calls to `wait` and `notifyAll` we're using a `Lock` with 2 `Condition` objects : * one when the waiting conditions on global lock acquisition have changed * one when the waiting conditions on bundle lock acquisition have changed You can merge this pull request into a Git repository by running: $ git pull https://github.com/adessaigne/felix FELIX-5942 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/felix/pull/156.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #156 commit d906ec37291bbc7d9fd4bd3211aaae0b4f9eac00 Author: Antoine DESSAIGNE Date: 2018-09-24T15:22:12Z FELIX-5942 - Replace wait/notify by lock/conditions in Felix to avoid freeze ---
[jira] [Commented] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625984#comment-16625984
]
Antoine DESSAIGNE commented on FELIX-5942:
--
Hello [~karlpauls],
I've just opened the [pull request
#156|https://github.com/apache/felix/pull/156] with a fix proposal
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global lock
> ** here we're resolving a class from a bundle with dynamic import packages
> * An Oracle JDK 10 or OpenJDK 11
> ** it's working fine with Oracle JDK 8
>
> Replacing the {{m_bundleLock}} by a fair {{ReentrantLock}} with a
> {{Condition}} makes it work with 10 parallel threads but still fails with 100
> threads.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625982#comment-16625982
]
ASF GitHub Bot commented on FELIX-5942:
---
GitHub user adessaigne opened a pull request:
https://github.com/apache/felix/pull/156
FELIX-5942 - Replace wait/notify by lock/conditions in Felix to avoid freeze
Fix proposal for
[FELIX-5942](https://issues.apache.org/jira/browse/FELIX-5942).
Instead of a single `Object` with calls to `wait` and `notifyAll` we're
using a `Lock` with 2 `Condition` objects :
* one when the waiting conditions on global lock acquisition have changed
* one when the waiting conditions on bundle lock acquisition have changed
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/adessaigne/felix FELIX-5942
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/felix/pull/156.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #156
commit d906ec37291bbc7d9fd4bd3211aaae0b4f9eac00
Author: Antoine DESSAIGNE
Date: 2018-09-24T15:22:12Z
FELIX-5942 - Replace wait/notify by lock/conditions in Felix to avoid freeze
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global lock
> ** here we're resolving a class from a bundle with dynamic import packages
> * An Oracle JDK 10 or OpenJDK 11
> ** it's working fine with Oracle JDK 8
>
> Replacing the {{m_bundleLock}} by a fair {{ReentrantLock}} with a
> {{Condition}} makes it work with 10 parallel threads but still fails with 100
> threads.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoine DESSAIGNE updated FELIX-5942:
-
Description:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue :
[^ConcurrentClassLoaderTest.java]
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** here we're resolving a class from a bundle with dynamic import packages
* An Oracle JDK 10 or OpenJDK 11
** it's working fine with Oracle JDK 8
Replacing the {{m_bundleLock}} by a fair {{ReentrantLock}} with a {{Condition}}
makes it work with 10 parallel threads but still fails with 100 threads.
was:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue :
[^ConcurrentClassLoaderTest.java]
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** here we're resolving a class from a bundle with dynamic import packages
* An Oracle JDK 10 or OpenJDK 11
** it's working fine with Oracle JDK 8 with 10 threads
Replacing the {{m_bundleLock}} by a fair {{ReentrantLock}} with a {{Condition}}
makes it work with 10 parallel threads but still fails with 100 threads.
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
[jira] [Comment Edited] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625846#comment-16625846
]
Antoine DESSAIGNE edited comment on FELIX-5942 at 9/24/18 2:37 PM:
---
Hello [~karlpauls],
Sure :)
* with Oracle JDK 10 : freeze
* with OpenJDK 11 (last early access) : freeze
* with Oracle JDK 8
was (Author: antoine.dessaigne):
Hello [~karlpauls],
Sure :)
* with Oracle JDK 10 : freeze
* with OpenJDK 11 (last early access) : freeze
* with Oracle JDK 8 : it's working fine with 10 threads
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global lock
> ** here we're resolving a class from a bundle with dynamic import packages
> * An Oracle JDK 10 or OpenJDK 11
> ** it's working fine with Oracle JDK 8
>
> Replacing the {{m_bundleLock}} by a fair {{ReentrantLock}} with a
> {{Condition}} makes it work with 10 parallel threads but still fails with 100
> threads.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoine DESSAIGNE updated FELIX-5942:
-
Description:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue :
[^ConcurrentClassLoaderTest.java]
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** here we're resolving a class from a bundle with dynamic import packages
* An Oracle JDK 10 or OpenJDK 11
** it's working fine with Oracle JDK 8 with 10 threads
Replacing the {{m_bundleLock}} by a fair {{ReentrantLock}} with a {{Condition}}
makes it work with 10 parallel threads but still fails with 100 threads.
was:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue :
[^ConcurrentClassLoaderTest.java]
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** here we're resolving a class from a bundle with dynamic import packages
* An Oracle JDK 10 or OpenJDK 11
** it's working fine with Oracle JDK 8
Replacing the {{m_bundleLock}} by a fair {{ReentrantLock}} with a {{Condition}}
makes it work with 10 parallel threads but still fails with 100 threads.
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
[jira] [Comment Edited] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625846#comment-16625846
]
Antoine DESSAIGNE edited comment on FELIX-5942 at 9/24/18 2:22 PM:
---
Hello [~karlpauls],
Sure :)
* with Oracle JDK 10 : freeze
* with OpenJDK 11 (last early access) : freeze
* with Oracle JDK 8 : it's working fine with 10 threads
was (Author: antoine.dessaigne):
Hello [~karlpauls],
Sure :)
* with Oracle JDK 10 : freeze
* with OpenJDK 11 (last early access) : freeze
* with Oracle JDK 8 : it's working fine
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global lock
> ** here we're resolving a class from a bundle with dynamic import packages
> * An Oracle JDK 10 or OpenJDK 11
> ** it's working fine with Oracle JDK 8
>
> Replacing the {{m_bundleLock}} by a fair {{ReentrantLock}} with a
> {{Condition}} makes it work with 10 parallel threads but still fails with 100
> threads.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoine DESSAIGNE updated FELIX-5942:
-
Description:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue :
[^ConcurrentClassLoaderTest.java]
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** here we're resolving a class from a bundle with dynamic import packages
* An Oracle JDK 10 or OpenJDK 11
** it's working fine with Oracle JDK 8
Replacing the {{m_bundleLock}} by a fair {{ReentrantLock}} with a {{Condition}}
makes it work with 10 parallel threads but still fails with 100 threads.
was:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue :
[^ConcurrentClassLoaderTest.java]
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** here we're resolving a class from a bundle with dynamic import packages
* An Oracle JDK 10 or OpenJDK 11
** it's working with fine with Oracle JDK 8
Replacing the {{m_bundleLock}} by a fair {{ReentrantLock}} with a {{Condition}}
makes it work with 10 parallel threads but still fails with 100 threads.
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
>
[jira] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoine DESSAIGNE updated FELIX-5942:
-
Description:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue :
[^ConcurrentClassLoaderTest.java]
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** here we're resolving a class from a bundle with dynamic import packages
* An Oracle JDK 10 or OpenJDK 11
** it's working with fine with Oracle JDK 8
Replacing the {{m_bundleLock}} by a fair {{ReentrantLock}} with a {{Condition}}
makes it work with 10 parallel threads but still fails with 100 threads.
was:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue :
[^ConcurrentClassLoaderTest.java]
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** here we're resolving a class from a bundle with dynamic import packages
* An Oracle JDK 10 or OpenJDK 11
** it's working with fine with Oracle JDK 8
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
>
[jira] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoine DESSAIGNE updated FELIX-5942:
-
Description:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue :
[^ConcurrentClassLoaderTest.java]
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** here we're resolving a class from a bundle with dynamic import packages
* An Oracle JDK 10 or OpenJDK 11
** it's working with fine with Oracle JDK 8
was:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue :
[^ConcurrentClassLoaderTest.java]
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** Here we're resolving a class from a bundle with dynamic import packages
* An Oracle JDK 10 or OpenJDK
** with an OpenJDK 11 it's not working
** with an Oracle Java 8 it's working
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global
[jira] [Comment Edited] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625846#comment-16625846
]
Antoine DESSAIGNE edited comment on FELIX-5942 at 9/24/18 1:50 PM:
---
Hello [~karlpauls],
Sure :)
* with Oracle JDK 10 : freeze
* with OpenJDK 11 (last early access) : freeze
* with Oracle JDK 8 : it's working fine
was (Author: antoine.dessaigne):
Hello [~karlpauls],
Sure :)
* with Oracle JDK 10 : freeze
* with OpenJDK 11 (last early access) : free
* with Oracle JDK 8 : it's working fine
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global lock
> ** Here we're resolving a class from a bundle with dynamic import packages
> * An Oracle JDK 10 or OpenJDK
> ** with an OpenJDK 11 it's not working
> ** with an Oracle Java 8 it's working
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoine DESSAIGNE updated FELIX-5942:
-
Description:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue :
[^ConcurrentClassLoaderTest.java]
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** Here we're resolving a class from a bundle with dynamic import packages
* An Oracle JDK 10 or OpenJDK
** with an OpenJDK 11 it's not working
** with an Oracle Java 8 it's working
was:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue :
[^ConcurrentClassLoaderTest.java]
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** Here we're resolving a class from a bundle with dynamic import packages
* An Oracle Java 10
** with an OpenJDK 11 it's not working
** with an Oracle Java 8 it's working
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying
[jira] [Commented] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625846#comment-16625846
]
Antoine DESSAIGNE commented on FELIX-5942:
--
Hello [~karlpauls],
Sure :)
* with Oracle JDK 10 : freeze
* with OpenJDK 11 (last early access) : free
* with Oracle JDK 8 : it's working fine
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global lock
> ** Here we're resolving a class from a bundle with dynamic import packages
> * An Oracle Java 10
> ** with an OpenJDK 11 it's not working
> ** with an Oracle Java 8 it's working
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoine DESSAIGNE updated FELIX-5942:
-
Attachment: (was: ConcurrentClassLoaderTest.java)
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global lock
> ** Here we're resolving a class from a bundle with dynamic import packages
> * An Oracle Java 10
> ** with an OpenJDK 11 it's not working
> ** with an Oracle Java 8 it's working
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625843#comment-16625843
]
Karl Pauls edited comment on FELIX-5942 at 9/24/18 1:48 PM:
[~antoine.dessaigne], can you clarify what this part means:
* An Oracle Java 10
** with an OpenJDK 11 it's not working
** with an Oracle Java 8 it's working
what is working on what version and is not working on which version?
was (Author: karlpauls):
[~antoine.dessaigne], can you clarify what this part means:
* An Oracle Java 10
** with an OpenJDK 11 it's not working
** with an Oracle Java 8 it's working
what is working on what is not working on which version?
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global lock
> ** Here we're resolving a class from a bundle with dynamic import packages
> * An Oracle Java 10
> ** with an OpenJDK 11 it's not working
> ** with an Oracle Java 8 it's working
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625843#comment-16625843
]
Karl Pauls commented on FELIX-5942:
---
[~antoine.dessaigne], can you clarify what this part means:
* An Oracle Java 10
** with an OpenJDK 11 it's not working
** with an Oracle Java 8 it's working
what is working on what is not working on which version?
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java,
> ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global lock
> ** Here we're resolving a class from a bundle with dynamic import packages
> * An Oracle Java 10
> ** with an OpenJDK 11 it's not working
> ** with an Oracle Java 8 it's working
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoine DESSAIGNE updated FELIX-5942:
-
Attachment: ConcurrentClassLoaderTest.java
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java,
> ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global lock
> ** Here we're resolving a class from a bundle with dynamic import packages
> * An Oracle Java 10
> ** with an OpenJDK 11 it's not working
> ** with an Oracle Java 8 it's working
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reassigned FELIX-5942:
-
Assignee: Karl Pauls
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global lock
> ** Here we're resolving a class from a bundle with dynamic import packages
> * An Oracle Java 10
> ** with an OpenJDK 11 it's not working
> ** with an Oracle Java 8 it's working
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoine DESSAIGNE updated FELIX-5942:
-
Description:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue :
[^ConcurrentClassLoaderTest.java]
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** Here we're resolving a class from a bundle with dynamic import packages
* An Oracle Java 10
** with an OpenJDK 11 it's not working
** with an Oracle Java 8 it's working
was:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue :
[^ConcurrentClassLoaderTest.java]
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** Here we're resolving a class from a bundle with dynamic import packages
* A Java 10 runtime
** Using a Java 8 runtime it's working
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global lock
> ** Here we're resolving a class from a bundle with
[jira] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoine DESSAIGNE updated FELIX-5942:
-
Description:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue :
[^ConcurrentClassLoaderTest.java]
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** Here we're resolving a class from a bundle with dynamic import packages
* A Java 10 runtime
** Using a Java 8 runtime it's working
was:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue :
[^ConcurrentClassLoaderTest.java]
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** Here we're resolving a class from a bundle with dynamic import packages
* A Java 10 runtime
** Using a Java 10 runtime it's working
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global lock
> ** Here we're resolving a class from a bundle with dynamic import packages
> * A Java 10
[jira] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoine DESSAIGNE updated FELIX-5942:
-
Attachment: (was: ConcurrentClassLoaderTest.java)
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global lock
> ** Here we're resolving a class from a bundle with dynamic import packages
> * A Java 10 runtime
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoine DESSAIGNE updated FELIX-5942:
-
Attachment: ConcurrentClassLoaderTest.java
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global lock
> ** Here we're resolving a class from a bundle with dynamic import packages
> * A Java 10 runtime
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoine DESSAIGNE updated FELIX-5942:
-
Description:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue :
[^ConcurrentClassLoaderTest.java]
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** Here we're resolving a class from a bundle with dynamic import packages
* A Java 10 runtime
** Using a Java 10 runtime it's working
was:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue :
[^ConcurrentClassLoaderTest.java]
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** Here we're resolving a class from a bundle with dynamic import packages
* A Java 10 runtime
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global lock
> ** Here we're resolving a class from a bundle with dynamic import packages
> * A Java 10 runtime
> ** Using a Java 10 runtime it's
[jira] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
[
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoine DESSAIGNE updated FELIX-5942:
-
Description:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue :
[^ConcurrentClassLoaderTest.java]
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** Here we're resolving a class from a bundle with dynamic import packages
* A Java 10 runtime
was:
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue.
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** Here we're resolving a class from a bundle with dynamic import packages
* A Java 10 runtime
> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
> Object.wait() [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.Object.wait(java.base@10.0.2/Native Method)
> - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
> - waiting to re-lock in wait() <0x0006c931dd20> (a
> [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue :
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
> * Lots of threads trying to acquire the global lock
> ** Here we're resolving a class from a bundle with dynamic import packages
> * A Java 10 runtime
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10
Antoine DESSAIGNE created FELIX-5942:
Summary: Felix Framework freezes when resolving classes in
parallel with Java 10
Key: FELIX-5942
URL: https://issues.apache.org/jira/browse/FELIX-5942
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-6.0.1
Reporter: Antoine DESSAIGNE
Attachments: ConcurrentClassLoaderTest.java
Hello.
When resolving a class in parallel in Java 10, you end up with a freeze.
You end up with threads beeing blocked
{noformat}
"Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in
Object.wait() [0x00296d0fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(java.base@10.0.2/Native Method)
- waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
- waiting to re-lock in wait() <0x0006c931dd20> (a
[Ljava.lang.Object;)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at
org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
You'll find attached a test reproducing the issue.
Here's what you need to freeze felix :
* Lots of threads trying to acquire the global lock
** Here we're resolving a class from a bundle with dynamic import packages
* A Java 10 runtime
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5941) DM APi enhancements
[
https://issues.apache.org/jira/browse/FELIX-5941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5941:
-
Description:
in [https://github.com/pderop/dm.enhanced,] some enhancements have been done
regarding the dm API, and the intent of this issue is to merge the improvements
into the felix trunk:
* the api to define aspects and adapters have been reworked (but dm API
remains {{backward compatible}})
* you can now declare multiple property type interfaces when using
Configuration Dependency or Factory Components (this was needed to implement
the enhancements for the annotations)
* configuration dependency using metatypes can now declare property types
* Allow to specify if propagated configuration dependencies must override
service service properties (it was not possible to override service properties
with propagated service properties so far)
* Added the following signatures in Component interface:
** setInterface(Class serviceName, Dictionary properties)
** setInterface(Class[] serviceNames, Dictionary properties)
h3. *Aspect/Adapters Api enhancements*
So far, aspects or adapters were defined using many methods from
DependencyManager or DependencyActivatorBase classes:
For example, in DependencyManager.java, we currently have many signatures
{code:java}
public class DependencyManager {
public Component createAdapterService(Class serviceInterface, String
serviceFilter) {...}
public Component createAdapterService(Class serviceInterface, String
serviceFilter, String autoConfig) {...}
public Component createAdapterService(Class serviceInterface, String
serviceFilter, String add, String change, String remove) {...}
public Component createAdapterService(Class serviceInterface, String
serviceFilter, String add, String change, String remove, String swap) {...}
public Component createAdapterService(Class serviceInterface, String
serviceFilter, String autoConfig, Object callbackInstance, String add, String
change, String remove, String swap, boolean propagate) {...}
public Component createFactoryConfigurationAdapterService(String
factoryPid, String update, boolean propagate) {...}
public Component createFactoryConfigurationAdapterService(String
factoryPid, String update, boolean propagate, Object callbackInstance) {...}
public Component createFactoryConfigurationAdapterService(String
factoryPid, String update, boolean propagate, Class configType) {...}
public Component createFactoryConfigurationAdapterService(String
factoryPid, String update, boolean propagate, Object callbackInstance, Class
configType) {...}
public Component createAdapterFactoryConfigurationService(String
factoryPid, String update, boolean propagate,String heading, String desc,
String localization, PropertyMetaData[] propertiesMetaData) {...}
public Component createBundleAdapterService(int bundleStateMask, String
bundleFilter, boolean propagate) {...}
public Component createBundleAdapterService(int bundleStateMask, String
bundleFilter, boolean propagate, Object callbackInstance, String add, String
change, String remove) {...}
public Component createResourceAdapterService(String resourceFilter,
boolean propagate, Object callbackInstance, String callbackChanged) {...}
public Component createResourceAdapterService(String resourceFilter,
boolean propagate, Object callbackInstance, String callbackSet, String
callbackChanged)
public Component createResourceAdapterService(String resourceFilter, Object
propagateCallbackInstance, String propagateCallbackMethod, Object
callbackInstance, String callbackChanged) {...}
public Component createResourceAdapterService(String resourceFilter, Object
propagateCallbackInstance, String propagateCallbackMethod, Object
callbackInstance, String callbackSet, String callbackChanged) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking, String autoConfig) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking, String add, String change, String remove) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking, String add, String change, String remove, String
swap) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking, Object callbackInstance, String add, String change,
String remove, String swap) {...}{code}
So, we have simplified the usage of the aspect/adapters like this: instead of
having to use some of the many methods from the DependencyManager or
DependencyActivatorBase, we have added some new interfaces for the aspect and
adapters, and these interfaces are extending the Component interface.
[jira] [Updated] (FELIX-5941) DM APi enhancements
[
https://issues.apache.org/jira/browse/FELIX-5941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5941:
-
Description:
in [https://github.com/pderop/dm.enhanced,] some enhancements have been done
regarding the dm API:
* the api to define aspects and adapters have been reworked (but dm API
remains {{backward compatible}})
* you can now declare multiple property type interfaces when using
Configuration Dependency or Factory Components (this was needed to implement
the enhancements for the annotations)
* configuration dependency using metatypes can now declare property types
* Allow to specify if propagated configuration dependencies must override
service service properties (it was not possible to override service properties
with propagated service properties so far)
* Added the following signatures in Component interface:
** setInterface(Class serviceName, Dictionary properties)
** setInterface(Class[] serviceNames, Dictionary properties)
h3. *Aspect/Adapters Api enhancements*
So far, aspects or adapters were defined using many methods from
DependencyManager or DependencyActivatorBase classes:
For example, in DependencyManager.java, we currently have many signatures
{code:java}
public class DependencyManager {
public Component createAdapterService(Class serviceInterface, String
serviceFilter) {...}
public Component createAdapterService(Class serviceInterface, String
serviceFilter, String autoConfig) {...}
public Component createAdapterService(Class serviceInterface, String
serviceFilter, String add, String change, String remove) {...}
public Component createAdapterService(Class serviceInterface, String
serviceFilter, String add, String change, String remove, String swap) {...}
public Component createAdapterService(Class serviceInterface, String
serviceFilter, String autoConfig, Object callbackInstance, String add, String
change, String remove, String swap, boolean propagate) {...}
public Component createFactoryConfigurationAdapterService(String
factoryPid, String update, boolean propagate) {...}
public Component createFactoryConfigurationAdapterService(String
factoryPid, String update, boolean propagate, Object callbackInstance) {...}
public Component createFactoryConfigurationAdapterService(String
factoryPid, String update, boolean propagate, Class configType) {...}
public Component createFactoryConfigurationAdapterService(String
factoryPid, String update, boolean propagate, Object callbackInstance, Class
configType) {...}
public Component createAdapterFactoryConfigurationService(String
factoryPid, String update, boolean propagate,String heading, String desc,
String localization, PropertyMetaData[] propertiesMetaData) {...}
public Component createBundleAdapterService(int bundleStateMask, String
bundleFilter, boolean propagate) {...}
public Component createBundleAdapterService(int bundleStateMask, String
bundleFilter, boolean propagate, Object callbackInstance, String add, String
change, String remove) {...}
public Component createResourceAdapterService(String resourceFilter,
boolean propagate, Object callbackInstance, String callbackChanged) {...}
public Component createResourceAdapterService(String resourceFilter,
boolean propagate, Object callbackInstance, String callbackSet, String
callbackChanged)
public Component createResourceAdapterService(String resourceFilter, Object
propagateCallbackInstance, String propagateCallbackMethod, Object
callbackInstance, String callbackChanged) {...}
public Component createResourceAdapterService(String resourceFilter, Object
propagateCallbackInstance, String propagateCallbackMethod, Object
callbackInstance, String callbackSet, String callbackChanged) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking, String autoConfig) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking, String add, String change, String remove) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking, String add, String change, String remove, String
swap) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking, Object callbackInstance, String add, String change,
String remove, String swap) {...}{code}
So, we have simplified the usage of the aspect/adapters like this: instead of
having to use some of the many methods from the DependencyManager or
DependencyActivatorBase, we have added some new interfaces for the aspect and
adapters, and these interfaces are extending the Component interface. All other
existing methods have been moved to
[jira] [Updated] (FELIX-5941) DM APi enhancements
[
https://issues.apache.org/jira/browse/FELIX-5941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5941:
-
Description:
in [https://github.com/pderop/dm.enhanced,] some enhancements have been done
regarding the dm API:
* the api to define aspects and adapters have been reworked (but dm API
remains {{backward compatible}})
* you can now declare multiple property type interfaces when using
Configuration Dependency or Factory Components (this was needed to implement
the enhancements for the annotations)
* configuration dependency using metatypes can now declare property types
* Allow to specify if propagated configuration dependencies must override
service service properties (it was not possible to override service properties
with propagated service properties so far)
* Added the following signatures in Component interface:
** setInterface(Class serviceName, Dictionary properties)
** setInterface(Class[] serviceNames, Dictionary properties)
h3. *Aspect/Adapters Api enhancements*
So far, aspects or adapters were defined using many methods from
DependencyManager or DependencyActivatorBase classes:
For example, in DependencyManager.java, we currently have many signatures
{code:java}
public class DependencyManager {
public Component createAdapterService(Class serviceInterface, String
serviceFilter) {...}
public Component createAdapterService(Class serviceInterface, String
serviceFilter, String autoConfig) {...}
public Component createAdapterService(Class serviceInterface, String
serviceFilter, String add, String change, String remove) {...}
public Component createAdapterService(Class serviceInterface, String
serviceFilter, String add, String change, String remove, String swap) {...}
public Component createAdapterService(Class serviceInterface, String
serviceFilter, String autoConfig, Object callbackInstance, String add, String
change, String remove, String swap, boolean propagate) {...}
public Component createFactoryConfigurationAdapterService(String
factoryPid, String update, boolean propagate) {...}
public Component createFactoryConfigurationAdapterService(String
factoryPid, String update, boolean propagate, Object callbackInstance) {...}
public Component createFactoryConfigurationAdapterService(String
factoryPid, String update, boolean propagate, Class configType) {...}
public Component createFactoryConfigurationAdapterService(String
factoryPid, String update, boolean propagate, Object callbackInstance, Class
configType) {...}
public Component createAdapterFactoryConfigurationService(String
factoryPid, String update, boolean propagate,String heading, String desc,
String localization, PropertyMetaData[] propertiesMetaData) {...}
public Component createBundleAdapterService(int bundleStateMask, String
bundleFilter, boolean propagate) {...}
public Component createBundleAdapterService(int bundleStateMask, String
bundleFilter, boolean propagate, Object callbackInstance, String add, String
change, String remove) {...}
public Component createResourceAdapterService(String resourceFilter,
boolean propagate, Object callbackInstance, String callbackChanged) {...}
public Component createResourceAdapterService(String resourceFilter,
boolean propagate, Object callbackInstance, String callbackSet, String
callbackChanged)
public Component createResourceAdapterService(String resourceFilter, Object
propagateCallbackInstance, String propagateCallbackMethod, Object
callbackInstance, String callbackChanged) {...}
public Component createResourceAdapterService(String resourceFilter, Object
propagateCallbackInstance, String propagateCallbackMethod, Object
callbackInstance, String callbackSet, String callbackChanged) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking, String autoConfig) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking, String add, String change, String remove) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking, String add, String change, String remove, String
swap) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking, Object callbackInstance, String add, String change,
String remove, String swap) {...}{code}
So, we have simplified the usage of the aspect/adapters like this: instead of
having to use some of the many methods from the DependencyManager or
DependencyActivatorBase, we have added some new interfaces for the aspect and
adapters, and these interfaces are extending the Component interface. All other
existing methods have been moved to
[jira] [Created] (FELIX-5941) DM APi enhancements
Pierre De Rop created FELIX-5941:
Summary: DM APi enhancements
Key: FELIX-5941
URL: https://issues.apache.org/jira/browse/FELIX-5941
Project: Felix
Issue Type: Improvement
Components: Dependency Manager
Reporter: Pierre De Rop
Assignee: Pierre De Rop
Fix For: org.apache.felix.dependencymanager-r12
in [https://github.com/pderop/dm.enhanced,] some enhancements have been done
regarding the dm API:
* the api to define aspects and adapters have been reworked (but dm API
remains {{backward compatible}})
* you can now declare multiple property type interfaces when using
Configuration Dependency or Factory Components (this was needed to implement
the enhancements for the annotations)
* configuration dependency using metatypes can now declare property types
* Allow to specify if propagated configuration dependencies must override
service service properties (it was not possible to override service properties
with propagated service properties so far)
* Added the following signatures in Component interface:
** setInterface(Class serviceName, Dictionary properties)
** setInterface(Class[] serviceNames, Dictionary properties)
h3.
[|https://github.com/pderop/dm.enhanced#aspectadapters-api-enhancements]*Aspect/Adapters
Api enhancements*
So far, aspects or adapters were defined using many methods from
DependencyManager or DependencyActivatorBase classes:
For example, in DependencyManager.java, we currently have many signatures
{code:java}
public class DependencyManager {
public Component createAdapterService(Class serviceInterface, String
serviceFilter) {...}
public Component createAdapterService(Class serviceInterface, String
serviceFilter, String autoConfig) {...}
public Component createAdapterService(Class serviceInterface, String
serviceFilter, String add, String change, String remove) {...}
public Component createAdapterService(Class serviceInterface, String
serviceFilter, String add, String change, String remove, String swap) {...}
public Component createAdapterService(Class serviceInterface, String
serviceFilter, String autoConfig, Object callbackInstance, String add, String
change, String remove, String swap, boolean propagate) {...}
public Component createFactoryConfigurationAdapterService(String
factoryPid, String update, boolean propagate) {...}
public Component createFactoryConfigurationAdapterService(String
factoryPid, String update, boolean propagate, Object callbackInstance) {...}
public Component createFactoryConfigurationAdapterService(String
factoryPid, String update, boolean propagate, Class configType) {...}
public Component createFactoryConfigurationAdapterService(String
factoryPid, String update, boolean propagate, Object callbackInstance, Class
configType) {...}
public Component createAdapterFactoryConfigurationService(String
factoryPid, String update, boolean propagate,String heading, String desc,
String localization, PropertyMetaData[] propertiesMetaData) {...}
public Component createBundleAdapterService(int bundleStateMask, String
bundleFilter, boolean propagate) {...}
public Component createBundleAdapterService(int bundleStateMask, String
bundleFilter, boolean propagate, Object callbackInstance, String add, String
change, String remove) {...}
public Component createResourceAdapterService(String resourceFilter,
boolean propagate, Object callbackInstance, String callbackChanged) {...}
public Component createResourceAdapterService(String resourceFilter,
boolean propagate, Object callbackInstance, String callbackSet, String
callbackChanged)
public Component createResourceAdapterService(String resourceFilter, Object
propagateCallbackInstance, String propagateCallbackMethod, Object
callbackInstance, String callbackChanged) {...}
public Component createResourceAdapterService(String resourceFilter, Object
propagateCallbackInstance, String propagateCallbackMethod, Object
callbackInstance, String callbackSet, String callbackChanged) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking, String autoConfig) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking, String add, String change, String remove) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking, String add, String change, String remove, String
swap) {...}
public Component createAspectService(Class serviceInterface, String
serviceFilter, int ranking, Object callbackInstance, String add, String change,
String remove, String swap) {...}{code}
So, we have simplified the usage of the aspect/adapters like
Re: [VOTE] Release osgicheck maven plugin 0.1.0
Thanks for reporting, the plugin requires that the project has built the bundle before. I've new added an extra check stating this (FELIX-5940) If you find any additional bugs or want improvements, please file them as jira issues Thanks Carsten Mark Derricutt wrote > Caused by: java.lang.NullPointerException > at java.util.zip.ZipFile. (ZipFile.java:213) > at java.util.zip.ZipFile. (ZipFile.java:155) > at java.util.jar.JarFile. (JarFile.java:166) > at java.util.jar.JarFile. (JarFile.java:130) > at > org.apache.felix.maven.osgicheck.impl.featureutil.ManifestUtil.getManifest > (ManifestUtil.java:42) > at org.apache.felix.maven.osgicheck.impl.CheckMojo.doExecute > (CheckMojo.java:149) > at org.apache.felix.maven.osgicheck.impl.CheckMojo.execute > (CheckMojo.java:126) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo > (DefaultBuildPluginManager.java:137) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:208) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:154) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:146) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Updated] (FELIX-5939) DM annotations enhancements
[
https://issues.apache.org/jira/browse/FELIX-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5939:
-
Description:
Some DM annotations improvements have been done regarding DM Annotation in this
github project: [https://github.com/pderop/dm.enhanced,] and the intent is to
merge the improvements to the felix trunk.
Essentially, the following DM annotations enhancements and modifications have
been done:
* in OSGi R7, declarative service now provides a @ComponentPropertyType
annotation that can be used to defined user defined property type annotations.
Now this annotation is used by other R7 libraries, like jaxrs whiteboard R7
API. So the DM annotation scanner has been enhanced for the support of the DS
@ComponentPropertyType, allowing you to reuse user defined annotations from
other r7 libraries (whiteboad, etc ...). The dm annotation plugin has been
enhanced by reusing some part of the ds annotation scanner from bndlib, which
is full of reusable useful code which has been applied to dm (scanning of
property types, PREFIX_, etc ...). For consistency api reasons, a new
@PropertyType annotation has also been added to the DM annotation API: this
annotation has the same semantics has the DS @ComponentPropertyType annotations.
* allow ServiceDependency to auto detect the service type when the annotation
is applied on a collection class field
* removed FactoryComponentAdapterService (some attributes have been added in
the Component annotation in order to declare factory pid components with the
@Component annotation)
* removed some old annotations / attributes. The attributes and annotations
related to metatype have been removed since you can now use the standard
metatype annotations. if users need to use old version, then the previous old
4.2.1 annotations can be used, because the dm runtime is compatible with old
and new annotations version.
* removed "dereference" attribute in ServiceDependencyAnnotation, because we
can now infer if the service dependency callbacks accepts a ServiceReference or
a ServiceObjects parameter
Since some incompatible changes have been made, the major version of the
annotation bundle has been bumped to 5.0.0.
*User defined property types examples:*
So far, you could define component service properties using DM @Property
annotation, and component configuration could be declared as user defined
interfaces. You can now declare user-defined annotations which can be used to
specify both service properties and component configuration. It means that
instead of declaring service properties using @Property annotation, you can now
use your own annotations (which must be annotated with the new @PropertyType
annotation, or using the standard @ComponentPropertyType annotation.
For example, let’s assume your write an OSGi r7 jaxrs servlet context which
needs the two following service properties:
{code:java}
osgi.http.whiteboard.context.name
osgi.http.whiteboard.context.path
{code}
Then you can first define your own annotation (but you could also reuse the
default annotations provided by the new jaxrs whiteboard r7 api, from the
org.osgi.service.jaxrs.whiteboard.propertytypes package):
{code:java}
import org.apache.felix.dependencymanager.annotation.PropertyType;
@PropertyType
@interface ServletContext {
String osgi_http_whiteboard_context_name() default AppServletContext.NAME;
String osgi_http_whiteboard_context_path();
}
{code}
In the above, the underscore is mapped to ".", and you can apply the above
annotation on top of your component like this:
{code:java}
@Component
@ServletContext(osgi_http_whiteboard_context_path="/game")
public class AppServletContext extends ServletContextHelper {
}
{code}
You can also use configuration admin service in order to override the default
service properties:
{code:java}
@Component
@ServletContext(osgi_http_whiteboard_context_path="/game")
public class AppServletContext extends ServletContextHelper {
@ConfigurationDependency(propagate=true, pid="my.pid")
void updated(ServletContext cnf) {
// if some properties are not present in the configuration, then the
ones used in the
// annotation will be used.
// The configuration admin properties, if defined, will override the
default configurations
// defined in the annotations
}
}
{code}
You can also define multiple property type annotations, and possibly single
valued annotation, like it is the case with standard r7 DS. In this case, you
can use the standard R7 PREFIX_ constants in order to specify the property
prefix, and the property name will be derived from the single valued annotation
(using camel case convention):
{code:java}
@PropertyType
@interface ContextName {
// will map to "osgi.http.whiteboard.context.name" property name
String PREFIX_="osgi.http.whiteboard.";
String value();
}
[jira] [Resolved] (FELIX-5940) NPE when project artifact has not been built
[ https://issues.apache.org/jira/browse/FELIX-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-5940. - Resolution: Fixed Added extra check in rev 1841833 > NPE when project artifact has not been built > > > Key: FELIX-5940 > URL: https://issues.apache.org/jira/browse/FELIX-5940 > Project: Felix > Issue Type: Bug > Components: Tooling >Affects Versions: osgicheck-maven-plugin 0.1.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: osgicheck-maven-plugin 0.2.0 > > > Caused by: java.lang.NullPointerException > at java.util.zip.ZipFile. (ZipFile.java:213) > at java.util.zip.ZipFile. (ZipFile.java:155) > at java.util.jar.JarFile. (JarFile.java:166) > at java.util.jar.JarFile. (JarFile.java:130) > at org.apache.felix.maven.osgicheck.impl.featureutil.ManifestUtil.getManifest > (ManifestUtil.java:42) > at org.apache.felix.maven.osgicheck.impl.CheckMojo.doExecute > (CheckMojo.java:149) > at org.apache.felix.maven.osgicheck.impl.CheckMojo.execute > (CheckMojo.java:126) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo > (DefaultBuildPluginManager.java:137) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:208) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:154) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:146) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-5940) NPE when project artifact has not been built
[ https://issues.apache.org/jira/browse/FELIX-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-5940: Component/s: Tooling > NPE when project artifact has not been built > > > Key: FELIX-5940 > URL: https://issues.apache.org/jira/browse/FELIX-5940 > Project: Felix > Issue Type: Bug > Components: Tooling >Affects Versions: osgicheck-maven-plugin 0.1.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: osgicheck-maven-plugin 0.2.0 > > > Caused by: java.lang.NullPointerException > at java.util.zip.ZipFile. (ZipFile.java:213) > at java.util.zip.ZipFile. (ZipFile.java:155) > at java.util.jar.JarFile. (JarFile.java:166) > at java.util.jar.JarFile. (JarFile.java:130) > at org.apache.felix.maven.osgicheck.impl.featureutil.ManifestUtil.getManifest > (ManifestUtil.java:42) > at org.apache.felix.maven.osgicheck.impl.CheckMojo.doExecute > (CheckMojo.java:149) > at org.apache.felix.maven.osgicheck.impl.CheckMojo.execute > (CheckMojo.java:126) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo > (DefaultBuildPluginManager.java:137) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:208) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:154) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:146) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-5939) DM annotations enhancements
[
https://issues.apache.org/jira/browse/FELIX-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5939:
-
Description:
Some DM annotations improvements have been done regarding DM Annotation in this
github project: [https://github.com/pderop/dm.enhanced,] and the intent is to
merge the improvements to the felix trunk.
Essentially, the following DM annotations enhancements and modifications have
been done:
* in OSGi R7, declarative service now provides a @ComponentPropertyType
annotation that can be used to defined user defined property type annotations.
Now this annotation is used by other R7 libraries, like jaxrs whiteboard R7
API. So the DM annotation scanner has been enhanced for the support of the DS
@ComponentPropertyType, allowing you to reuse user defined annotations from
other r7 libraries (whiteboad, etc ...). The dm annotation plugin has been
enhanced by reusing some part of the ds annotation scanner from bndlib, which
is full of reusable useful code which has been applied to dm (scanning of
property types, PREFIX_, etc ...). For consistency api reasons, a new
@PropertyType annotation has also been added to the DM annotation API: this
annotation has the same semantics has the DS @ComponentPropertyType annotations.
* allow ServiceDependency to auto detect the service type when the annotation
is applied on a collection class field
* removed FactoryComponentAdapterService (some attributes have been added in
the Component annotation in order to declare factory pid components with the
@Component annotation)
* removed some old annotations / attributes. The attributes and annotations
related to metatype have been removed since you can now use the standard
metatype annotations. if users need to use old version, then the previous old
4.2.1 annotations can be used, because the dm runtime is compatible with old
and new annotations version.
* removed "dereference" attribute in ServiceDependencyAnnotation, because we
can now infer if the service dependency callbacks accepts a ServiceReference or
a ServiceObjects parameter
Since some incompatible changes have been made, the major version of the
annotation bundle has been bumped to 5.0.0.
*User defined property types examples:*
So far, you could define component service properties using DM @Property
annotation, and component configuration could be declared as user defined
interfaces. You can now declare user-defined annotations which can be used to
specify both service properties and component configuration. It means that
instead of declaring service properties using @Property annotation, you can now
use your own annotations (which must be annotated with the new @PropertyType
annotation, or using the standard @ComponentPropertyType annotation.
For example, let’s assume your write an OSGi r7 jaxrs servlet context which
needs the two following service properties:
{code:java}
osgi.http.whiteboard.context.name
osgi.http.whiteboard.context.path
{code}
Then you can first define your own annotation (but you could also reuse the
default annotations provided by the new jaxrs whiteboard r7 api, from the
org.osgi.service.jaxrs.whiteboard.propertytypes package):
{code:java}
import org.apache.felix.dependencymanager.annotation.PropertyType;
@PropertyType
@interface ServletContext {
String osgi_http_whiteboard_context_name() default AppServletContext.NAME;
String osgi_http_whiteboard_context_path();
}
{code}
In the above, the underscore is mapped to ".", and you can apply the above
annotation on top of your component like this:
{code:java}
@Component
@ServletContext(osgi_http_whiteboard_context_path="/game")
public class AppServletContext extends ServletContextHelper {
}
{code}
You can also use configuration admin service in order to override the default
service properties:
{code:java}
@Component
@ServletContext(osgi_http_whiteboard_context_path="/game")
public class AppServletContext extends ServletContextHelper {
@ConfigurationDependency(propagate=true, pid="my.pid")
void updated(ServletContext cnf) {
// if some properties are not present in the configuration, then the
ones used in the
// annotation will be used.
// The configuration admin properties, if defined, will override the
default configurations
// defined in the annotations
}
}
{code}
You can also define multiple property type annotations, and possibly single
valued annotation, like it is the case with standard r7 DS. In this case, you
can use the standard R7 PREFIX_ constants in order to specify the property
prefix, and the property name will be derived from the single valued annotation
(using camel case convention):
{code:java}
@PropertyType
@interface ContextName {
// will map to "osgi.http.whiteboard.context.name" property name
String PREFIX_="osgi.http.whiteboard.";
String value();
}
[jira] [Updated] (FELIX-5939) DM annotations enhancements
[
https://issues.apache.org/jira/browse/FELIX-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5939:
-
Description:
Some DM annotations improvements have been done regarding DM Annotation in this
github project: [https://github.com/pderop/dm.enhanced,] and the intent is to
merge the improvements to the felix trunk.
Essentially, the following DM annotations enhancements and modifications have
been done:
* in OSGi R7, declarative service now provides a @ComponentPropertyType
annotation that can be used to defined user defined property type annotations.
Now this annotation is used by other R7 libraries, like jaxrs whiteboard R7
API. So the DM annotation scanner has been enhanced for the support of the DS
@ComponentPropertyType, allowing you to reuse user defined annotations from
other r7 libraries (whiteboad, etc ...). The dm annotation plugin has been
enhanced by reusing some part of the ds annotation scanner from bndlib, which
is full of reusable useful code which has been applied to dm (scanning of
property types, PREFIX_, etc ...). For consistency api reasons, a new
@PropertyType annotation has also been added to the DM annotation API: this
annotation has the same semantics has the DS @ComponentPropertyType annotations.
* allow ServiceDependency to auto detect the service type when the annotation
is applied on a collection class field
* removed FactoryComponentAdapterService (some attributes have been added in
the Component annotation in order to declare factory pid components with the
@Component annotation)
* removed some old annotations / attributes. The attributes and annotations
related to metatype have been removed since you can now use the standard
metatype annotations. if users need to use old version, then the previous old
4.2.1 annotations can be used, because the dm runtime is compatible with old
and new annotations version.
* removed "dereference" attribute in ServiceDependencyAnnotation, because we
can now infer if the service dependency callbacks accepts a ServiceReference or
a ServiceObjects parameter
Since some incompatible changes have been made, the major version of the
annotation bundle has been bumped to 5.0.0.
*User defined property types examples:*
So far, you could define component service properties using DM @Property
annotation, and component configuration could be declared as user defined
interfaces. You can now declare user-defined annotations which can be used to
specify both service properties and component configuration. It means that
instead of declaring service properties using @Property annotation, you can now
use your own annotations (which must be annotated with the new @PropertyType
annotation, or using the standard @ComponentPropertyType annotation.
For example, let’s assume your write an OSGi r7 jaxrs servlet context which
needs the two following service properties:
{code:java}
osgi.http.whiteboard.context.name
osgi.http.whiteboard.context.path
{code}
Then you can first define your own annotation (but you could also reuse the
default annotations provided by the new jaxrs whiteboard r7 api, from the
org.osgi.service.jaxrs.whiteboard.propertytypes package):
{code:java}
import org.apache.felix.dependencymanager.annotation.PropertyType;
@PropertyType
@interface ServletContext {
String osgi_http_whiteboard_context_name() default AppServletContext.NAME;
String osgi_http_whiteboard_context_path();
}
{code}
In the above, the underscore is mapped to ".", and you can apply the above
annotation on top of your component like this:
{code:java}
@Component
@ServletContext(osgi_http_whiteboard_context_path="/game")
public class AppServletContext extends ServletContextHelper {
}
{code}
You can also use configuration admin service in order to override the default
service properties:
{code:java}
@Component
@ServletContext(osgi_http_whiteboard_context_path="/game")
public class AppServletContext extends ServletContextHelper {
@ConfigurationDependency(propagate=true, pid="my.pid")
void updated(ServletContext cnf) {
// if some properties are not present in the configuration, then the
ones used in the
// annotation will be used.
// The configuration admin properties, if defined, will override the
default configurations
// defined in the annotations
}
}
{code}
You can also define multiple property type annotations, and possibly single
valued annotation, like it is the case with standard r7 DS. In this case, you
can use the standard R7 PREFIX_ constants in order to specify the property
prefix, and the property name will be derived from the single valued annotation
(using camel case convention):
{code:java}
@PropertyType
@interface ContextName {
// will map to "osgi.http.whiteboard.context.name" property name
String PREFIX_="osgi.http.whiteboard.";
String value();
[jira] [Created] (FELIX-5940) NPE when project artifact has not been built
Carsten Ziegeler created FELIX-5940: --- Summary: NPE when project artifact has not been built Key: FELIX-5940 URL: https://issues.apache.org/jira/browse/FELIX-5940 Project: Felix Issue Type: Bug Affects Versions: osgicheck-maven-plugin 0.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: osgicheck-maven-plugin 0.2.0 Caused by: java.lang.NullPointerException at java.util.zip.ZipFile. (ZipFile.java:213) at java.util.zip.ZipFile. (ZipFile.java:155) at java.util.jar.JarFile. (JarFile.java:166) at java.util.jar.JarFile. (JarFile.java:130) at org.apache.felix.maven.osgicheck.impl.featureutil.ManifestUtil.getManifest (ManifestUtil.java:42) at org.apache.felix.maven.osgicheck.impl.CheckMojo.doExecute (CheckMojo.java:149) at org.apache.felix.maven.osgicheck.impl.CheckMojo.execute (CheckMojo.java:126) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-5939) DM annotations enhancements
Pierre De Rop created FELIX-5939:
Summary: DM annotations enhancements
Key: FELIX-5939
URL: https://issues.apache.org/jira/browse/FELIX-5939
Project: Felix
Issue Type: Improvement
Components: Dependency Manager, Dependency Manager Annotations
Affects Versions: org.apache.felix.dependencymanager-r11
Reporter: Pierre De Rop
Assignee: Pierre De Rop
Fix For: org.apache.felix.dependencymanager-r12
Some DM annotations improvements have been done regarding DM Annotation in this
github project: [https://github.com/pderop/dm.enhanced,] and the intent is to
merge the improvements to the felix trunk.
Essentially, the following DM annotations enhancements and modifications have
been done:
* in OSGi R7, declarative service now provides a @ComponentPropertyType
annotation that can be used to defined user defined property type annotations.
Now this annotation is used by other R7 libraries, like jaxrs whiteboard R7
API. So the DM annotation scanner has been enhanced for the support of the DS
@ComponentPropertyType, allowing you to reuse user defined annotations from
other r7 libraries (whiteboad, etc ...). The dm annotation plugin has been
enhanced by reusing some part of the ds annotation scanner from bndlib, which
is full of reusable useful code which has been applied to dm (scanning of
property types, PREFIX_, etc ...). For consistency api reasons, a new
@PropertyType annotation has also been added to the DM annotation API: this
annotation has the same semantics has the DS @ComponentPropertyType annotations.
* allow ServiceDependency to auto detect the service type when the annotation
is applied on a collection class field
* removed FactoryComponentAdapterService (some attributes have been added in
the Component annotation in order to declare factory pid components with the
@Component annotation)
* removed some old annotations / attributes. The attributes and annotations
related to metatype have been removed since you can now use the standard
metatype annotations. if users need to use old version, then the previous old
4.2.1 annotations can be used, because the dm runtime is compatible with old
and new annotations version.
* removed "dereference" attribute in ServiceDependencyAnnotation, because we
can now infer if the service dependency callbacks accepts a ServiceReference or
a ServiceObjects parameter
Since some incompatible changes have been made, the major version of the
annotation bundle has been bumped to 5.0.0.
*User defined property types examples:*
So far, you could define component service properties using DM @Property
annotation, and component configuration could be declared as user defined
interfaces. You can now declare user-defined annotations which can be used to
specify both service properties and component configuration. It means that
instead of declaring service properties using @Property annotation, you can now
use your own annotations (which must be annotated with the new @PropertyType
annotation, or using the standard @ComponentPropertyType annotation.
For example, let’s assume your write an OSGi r7 jaxrs servlet context which
needs the two following service properties:
{code:java}
osgi.http.whiteboard.context.name
osgi.http.whiteboard.context.path
{code}
Then you can first define your own annotation (but you could also reuse the
default annotations provided by the new jaxrs whiteboard r7 api, from the
org.osgi.service.jaxrs.whiteboard.propertytypes package):
{code:java}
import org.apache.felix.dependencymanager.annotation.PropertyType;
@PropertyType
@interface ServletContext {
String osgi_http_whiteboard_context_name() default AppServletContext.NAME;
String osgi_http_whiteboard_context_path();
}
{code}
In the above, the underscore is mapped to ".", and you can apply the above
annotation on top of your component like this:
{code:java}
@Component
@ServletContext(osgi_http_whiteboard_context_path="/game")
public class AppServletContext extends ServletContextHelper {
}
\{code}
You can also use configuration admin service in order to override the default
service properties:
{code:java}
@Component
@ServletContext(osgi_http_whiteboard_context_path="/game")
public class AppServletContext extends ServletContextHelper {
@ConfigurationDependency(propagate=true, pid="my.pid")
void updated(ServletContext cnf) {
// if some properties are not present in the configuration, then the
ones used in the
// annotation will be used.
// The configuration admin properties, if defined, will override the
default configurations
// defined in the annotations
}
}
\{code}
You can also define multiple property type annotations, and possibly single
valued annotation, like it is the case with standard r7 DS. In this case, you
can use the standard R7
Re: [VOTE] Release Apache Felix Metatype 1.2.2
+1 (non-binding) Thanks ! Regards, François Papon fpa...@apache.org Le 23/09/2018 à 13:34, Carsten Ziegeler a écrit : > Hi all, > > we fixed one issue: > https://issues.apache.org/jira/browse/FELIX-5936 > > > Staging repositories: > https://repository.apache.org/content/repositories/orgapachefelix-1261/ > > 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 1261 /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 at least 72 hours. > > Regards > Carsten
