[jira] [Closed] (FELIX-3645) SCR could not obtain lock in 5000 ms

[Felix Meschberger (JIRA)]

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

Felix Meschberger closed FELIX-3645.



Thanks for the update. So I close this (as the release is out already) and have 
updated the changelog in Rev. 1414557

> SCR could not obtain lock in 5000 ms
> 
>
> Key: FELIX-3645
> URL: https://issues.apache.org/jira/browse/FELIX-3645
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
> Environment: linux fc16, bipro, Java(TM) SE Runtime Environment 
> (build 1.6.0_32-b05)
>Reporter: Pierre De Rop
>Assignee: David Jencks
> Fix For: scr-1.6.2
>
> Attachments: 
> TEST-org.apache.felix.scr.integration.ComponentConcurrencyTest.xml
>
>
> I finally made an integration test and committed it in the trunk.
> This test sounds to reproduce the problem described in 
> http://www.mail-archive.com/dev@felix.apache.org/msg26360.html.
> the test contains the following files:
> src/test/resources/integration_test_component_concurrency.xml
> src/test/java/org/apache/felix/scr/integration/ComponentConcurrencyTest.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/A.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/B.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/C.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/AFactory.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/CFactory.java
> I also slightly modified 
> src/test/java/org/apache/felix/scr/integration/ComponentTestBase.java
> in order to use the apache log service, and also to declare the new package 
> from org/apache/felix/scr/integration/components/concurrency.
> The test does the following:
> A optionally depends on B (dynamic=true, cardinality=0..N)
> B depends on C
> A is a factory component and is created by the AFactory class, in an infinite 
> loop and in a dedicated thread.
> C is also a factory component and is created/disposed for ever, by the 
> CFactory class.
> the integration test uses the log service in order to track logged errors, 
> and runs 30 seconds.
> If after 30 seconds, some errors are detected, then the test fail.
> It seems that we have many exceptions when the test fail, which I did not 
> reproduced so far. (see many IllegalMonitorState Exceptions).
> The initial exception discussed from the post in the @dev list is also 
> reproduced.
> For example, I attached to this post my 
> target/failsafe-reports/TEST-org.apache.felix.scr.integration.ComponentConcurrencyTest.xml,
>  when the problem takes place.
> Please take a look starting at line 951, as well as at the corresponding 
> dumpstack at line 713, and also the "Locking activity before 
> IllegalMonitorStateException" log, line 887.
> Hope this will help.
> /pierre

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (FELIX-3645) SCR could not obtain lock in 5000 ms

[David Jencks (JIRA)]

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

David Jencks resolved FELIX-3645.
-

Resolution: Fixed

this was actually fixed in 1.6.2

> SCR could not obtain lock in 5000 ms
> 
>
> Key: FELIX-3645
> URL: https://issues.apache.org/jira/browse/FELIX-3645
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
> Environment: linux fc16, bipro, Java(TM) SE Runtime Environment 
> (build 1.6.0_32-b05)
>Reporter: Pierre De Rop
>Assignee: David Jencks
> Fix For: scr-1.6.2
>
> Attachments: 
> TEST-org.apache.felix.scr.integration.ComponentConcurrencyTest.xml
>
>
> I finally made an integration test and committed it in the trunk.
> This test sounds to reproduce the problem described in 
> http://www.mail-archive.com/dev@felix.apache.org/msg26360.html.
> the test contains the following files:
> src/test/resources/integration_test_component_concurrency.xml
> src/test/java/org/apache/felix/scr/integration/ComponentConcurrencyTest.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/A.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/B.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/C.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/AFactory.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/CFactory.java
> I also slightly modified 
> src/test/java/org/apache/felix/scr/integration/ComponentTestBase.java
> in order to use the apache log service, and also to declare the new package 
> from org/apache/felix/scr/integration/components/concurrency.
> The test does the following:
> A optionally depends on B (dynamic=true, cardinality=0..N)
> B depends on C
> A is a factory component and is created by the AFactory class, in an infinite 
> loop and in a dedicated thread.
> C is also a factory component and is created/disposed for ever, by the 
> CFactory class.
> the integration test uses the log service in order to track logged errors, 
> and runs 30 seconds.
> If after 30 seconds, some errors are detected, then the test fail.
> It seems that we have many exceptions when the test fail, which I did not 
> reproduced so far. (see many IllegalMonitorState Exceptions).
> The initial exception discussed from the post in the @dev list is also 
> reproduced.
> For example, I attached to this post my 
> target/failsafe-reports/TEST-org.apache.felix.scr.integration.ComponentConcurrencyTest.xml,
>  when the problem takes place.
> Please take a look starting at line 951, as well as at the corresponding 
> dumpstack at line 713, and also the "Locking activity before 
> IllegalMonitorStateException" log, line 887.
> Hope this will help.
> /pierre

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FELIX-3645) SCR could not obtain lock in 5000 ms

[David Jencks (JIRA)]

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

David Jencks updated FELIX-3645:


Fix Version/s: (was: scr-1.8.0)
   scr-1.6.2

> SCR could not obtain lock in 5000 ms
> 
>
> Key: FELIX-3645
> URL: https://issues.apache.org/jira/browse/FELIX-3645
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
> Environment: linux fc16, bipro, Java(TM) SE Runtime Environment 
> (build 1.6.0_32-b05)
>Reporter: Pierre De Rop
>Assignee: David Jencks
> Fix For: scr-1.6.2
>
> Attachments: 
> TEST-org.apache.felix.scr.integration.ComponentConcurrencyTest.xml
>
>
> I finally made an integration test and committed it in the trunk.
> This test sounds to reproduce the problem described in 
> http://www.mail-archive.com/dev@felix.apache.org/msg26360.html.
> the test contains the following files:
> src/test/resources/integration_test_component_concurrency.xml
> src/test/java/org/apache/felix/scr/integration/ComponentConcurrencyTest.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/A.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/B.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/C.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/AFactory.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/CFactory.java
> I also slightly modified 
> src/test/java/org/apache/felix/scr/integration/ComponentTestBase.java
> in order to use the apache log service, and also to declare the new package 
> from org/apache/felix/scr/integration/components/concurrency.
> The test does the following:
> A optionally depends on B (dynamic=true, cardinality=0..N)
> B depends on C
> A is a factory component and is created by the AFactory class, in an infinite 
> loop and in a dedicated thread.
> C is also a factory component and is created/disposed for ever, by the 
> CFactory class.
> the integration test uses the log service in order to track logged errors, 
> and runs 30 seconds.
> If after 30 seconds, some errors are detected, then the test fail.
> It seems that we have many exceptions when the test fail, which I did not 
> reproduced so far. (see many IllegalMonitorState Exceptions).
> The initial exception discussed from the post in the @dev list is also 
> reproduced.
> For example, I attached to this post my 
> target/failsafe-reports/TEST-org.apache.felix.scr.integration.ComponentConcurrencyTest.xml,
>  when the problem takes place.
> Please take a look starting at line 951, as well as at the corresponding 
> dumpstack at line 713, and also the "Locking activity before 
> IllegalMonitorStateException" log, line 887.
> Hope this will help.
> /pierre

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (FELIX-3716) Improve support for cardinality multiple

[Richard S. Hall (JIRA)]

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

Richard S. Hall resolved FELIX-3716.


Resolution: Fixed
  Assignee: Richard S. Hall

The "candLoop" for-loop label isn't necessary, is it? The "break" should only 
break out of the innermost loop, right?

Otherwise, I've reviewed the patch enough to know that I can't think of a 
better way to do it and it is close enough to what I envisioned. The main issue 
I'd like to get rid of is having to put the multiple cardinality permutation on 
the side, but I can't see how to do it so maybe it isn't possible. Admittedly, 
I can't give this as much thought as I would like, so I'll commit this patch 
save for the above exception.

Please close if satisfied.

> Improve support for cardinality multiple
> 
>
> Key: FELIX-3716
> URL: https://issues.apache.org/jira/browse/FELIX-3716
> Project: Felix
>  Issue Type: Bug
>  Components: Resolver
> Environment: All
>Reporter: Thomas Watson
>Assignee: Richard S. Hall
> Attachments: org.apache.felix.resolver.patch
>
>
> The resolver implementation currently ignores the cardinality directive.  We 
> should try to improve this to allow a requirement to get wired to multiple 
> providers if the cardinality directive is set to multiple.
> I have been working on a fix to this but am waiting for the fix in issue 3707 
> to get release first so I can base the patch off that fix.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-3553) Use of parallel class loading capability of JDK7

[Richard S. Hall (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505209#comment-13505209
 ] 

Richard S. Hall commented on FELIX-3553:


I will try to look at it, but it would definitely be better to make the patch 
against trunk. Thanks.

> Use of parallel class loading capability of JDK7
> 
>
> Key: FELIX-3553
> URL: https://issues.apache.org/jira/browse/FELIX-3553
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Reporter: Sahoo
> Fix For: framework-4.2.0
>
> Attachments: FELIX-3553.txt, felix_parallel_classloading.patch
>
>
> Is there any plan to make use of this feature [1] in Felix?
> [1] 
> http://download.java.net/jdk7/archive/b124/docs/technotes/guides/lang/cl-mt.html
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FELIX-3786) Create system paclage definintions for Java 8

[Richard S. Hall (JIRA)]

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

Richard S. Hall updated FELIX-3786:
---

Fix Version/s: framework-4.2.0

> Create system paclage definintions for Java 8
> -
>
> Key: FELIX-3786
> URL: https://issues.apache.org/jira/browse/FELIX-3786
> Project: Felix
>  Issue Type: Task
>  Components: Framework
>Affects Versions: framework-4.0.3
>Reporter: Felix Meschberger
> Fix For: framework-4.2.0
>
> Attachments: FELIX-3786.patch
>
>
> The framework currently supports Java platform definitions up to Java 7 but 
> is lacking Java 8 definitions. This results in the framework not properly 
> setting up on Java 8 platforms.
> Maybe we could create an interim definition based on the Java 7 definitions 
> and update the exports once the Java 8 platform API stabilizes ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Java 8 System Package Definitions

[Richard S. Hall]

Actually, Sahoo verified which packages were part of the Java platform 
API, but I used bnd to calculate the "uses" constraints...I can imagine 
no one would ever want to do that by hand. :-)


If there is a viable platform that people might use, then we should do 
it. A simple patch is just to copy the Java 7 API over to Java 8 for 
starters...


-> richard

On 11/27/12 05:26, Felix Meschberger wrote:

Hi all

IIRC Sahoo once came up with nicely done System Package Definitions for Java 
platform APIs which included uses clauses.

Does anyone know the state of the Java 8 platform API and whether it already 
makes sense to go down the road of creating these definitions ?

Regards
Felix

[jira] [Updated] (FELIX-3770) Upgrade jquery-ui to 1.9.1

[Henry Saginor (JIRA)]

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

Henry Saginor updated FELIX-3770:
-

Attachment: main_header.html.patch.txt

I am sorry. Attaching patch for main_header.html. All other files are new. But 
let me know if you want patches for all of them.

> Upgrade jquery-ui to 1.9.1
> --
>
> Key: FELIX-3770
> URL: https://issues.apache.org/jira/browse/FELIX-3770
> Project: Felix
>  Issue Type: New Feature
>  Components: Web Console
>Reporter: Henry Saginor
> Attachments: FELIX-3770.tar.gz, main_header.html.patch.txt
>
>
> It's time to upgrade jquery-ui used by Web Console. JQuery UI 1.9.1 has new 
> features like a menu widget that can be used to implement FELIX-3769. JQuery 
> core should probably be upgraded as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FELIX-3769) Improve the way Web Console UI manages growing number of plugins.

[Henry Saginor (JIRA)]

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

Henry Saginor updated FELIX-3769:
-

Attachment: FELIX-3769.tar.gz

I am sorry for not following the correct process. Updated attachment contains 
patch files.

> Improve the way Web Console UI manages growing number of plugins.
> -
>
> Key: FELIX-3769
> URL: https://issues.apache.org/jira/browse/FELIX-3769
> Project: Felix
>  Issue Type: New Feature
>  Components: Web Console
>Reporter: Henry Saginor
>Priority: Minor
> Attachments: FELIX-3769.tar.gz, FELIX-3769.tar.gz
>
>
> Something needs to be done about growing number of web console plugins. 
> Currently the UI displays a tab for each plugin. This makes the UI cluttered 
> as more and more plugins are added. To address the tabs should be replaced 
> with a tree structure or a drop-down menu.
> Felix Meschberger has proposed the following on the dev list to implement 
> this.
> "* Plugins registered as services may have a "felix.webconsole.category" 
> property
> indicating the category. Plugins not registering this property will be placed 
> in
> the default category
> * AbstractWebConsolePlugin is ammended with a getCategory() method, which may
> overwritten by implementations. The default implementation in the
> AbstractWebConsolePlugin class returns the default category
> * A default category can be configured
> * Categories are simple strings such as "OSGi" or relative paths such as
> "Sling/Main". Relative paths define multi-level trees. I think in general a
> single level is probably enough. Maybe we can start with just supporting a
> single level (so just plain strings).
> * Translation of categories is such that each segment in the path (or the
> complete string if there is no sub-categories) is converted into a translation
> label by prefixing with "category.". So the translation for the "OSGi" 
> category
> would be found with the translation string "category.OSGi".
> * The plugin navigation is refactored to move it to the left and render it as 
> a
> tree structure (I assume we can use the JQuery treetable plugin)."

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (FELIX-3553) Use of parallel class loading capability of JDK7

[Ulf Lilleengen (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504687#comment-13504687
 ] 

Ulf Lilleengen edited comment on FELIX-3553 at 11/27/12 3:55 PM:
-

I made a similar patch against 4.0.3 that we are testing out now, that tries to 
improve the attached patch(new patch attached):

- Properly signal that lock was removed from map using notifyAll
- Replaces the map with a set, and simplify/fix logic in the check. I think its 
a bit easier to understand at least.

It also:
- Adds registerAsParallelCapable
- Makes bundleclassloader and bundleclassloader5 static (I just used intellij's 
'make static' to get this done)

Still unresolved:
- Handling interruptedexception.

Let me know if you can review it, or if I should try produce a patch against 
trunk. Btw, if you have any stress tests that can easily reproduce the deadlock 
issues, that would also be very helpful. We are able to reproduce it, but it 
requires a lot of effort in terms of patching our system.

Thanks

  was (Author: lulf):
I made a similar patch against 4.0.3 that we are testing out now, that 
tries to improve the attached patch(new patch attached):

- Properly signal that lock was removed from map using notifyAll
- Replaces the map with a set, and simplify/fix logic in the check. I think its 
a bit easier to understand at least.

It also:
- Adds registerAsParallelCapable
- Makes bundleclassloader and bundleclassloader5 static (I just used intellij's 
'make static' to get this done)

Still unresolved:
- Handling interruptedexception.

Let me know if you can review it, or if I should try produce a patch against 
trunk. Btw, if you have any stress tests that can easily reproduce the deadlock 
issues, that would also be very helpful.

Thanks
  
> Use of parallel class loading capability of JDK7
> 
>
> Key: FELIX-3553
> URL: https://issues.apache.org/jira/browse/FELIX-3553
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Reporter: Sahoo
> Fix For: framework-4.2.0
>
> Attachments: FELIX-3553.txt, felix_parallel_classloading.patch
>
>
> Is there any plan to make use of this feature [1] in Felix?
> [1] 
> http://download.java.net/jdk7/archive/b124/docs/technotes/guides/lang/cl-mt.html
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (FELIX-3553) Use of parallel class loading capability of JDK7

[Ulf Lilleengen (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504687#comment-13504687
 ] 

Ulf Lilleengen edited comment on FELIX-3553 at 11/27/12 3:54 PM:
-

I made a similar patch against 4.0.3 that we are testing out now, that tries to 
improve the attached patch(new patch attached):

- Properly signal that lock was removed from map using notifyAll
- Replaces the map with a set, and simplify/fix logic in the check. I think its 
a bit easier to understand at least.

It also:
- Adds registerAsParallelCapable
- Makes bundleclassloader and bundleclassloader5 static (I just used intellij's 
'make static' to get this done)

Still unresolved:
- Handling interruptedexception.

Let me know if you can review it, or if I should try produce a patch against 
trunk. Btw, if you have any stress tests that can easily reproduce the deadlock 
issues, that would also be very helpful.

Thanks

  was (Author: lulf):
I made a similar patch against 4.0.3 that we are testing out now tries to 
improve the attached patch(new patch attached):

- Properly signal that lock was removed from map using notifyAll
- Replaces the map with a set, and simplify/fix logic in the check. I think its 
a bit easier to understand at least.

It also:
- Adds registerAsParallelCapable
- Makes bundleclassloader and bundleclassloader5 static (I just used intellij's 
'make static' to get this done)

Still unresolved:
- Handling interruptedexception.

Let me know if you can review it, or if I should try produce a patch against 
trunk. Btw, if you have any stress tests that can easily reproduce the deadlock 
issues, that would also be very helpful.

Thanks
  
> Use of parallel class loading capability of JDK7
> 
>
> Key: FELIX-3553
> URL: https://issues.apache.org/jira/browse/FELIX-3553
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Reporter: Sahoo
> Fix For: framework-4.2.0
>
> Attachments: FELIX-3553.txt, felix_parallel_classloading.patch
>
>
> Is there any plan to make use of this feature [1] in Felix?
> [1] 
> http://download.java.net/jdk7/archive/b124/docs/technotes/guides/lang/cl-mt.html
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-3553) Use of parallel class loading capability of JDK7

[Ulf Lilleengen (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504687#comment-13504687
 ] 

Ulf Lilleengen commented on FELIX-3553:
---

I made a similar patch against 4.0.3 that we are testing out now tries to 
improve the attached patch(new patch attached):

- Properly signal that lock was removed from map using notifyAll
- Replaces the map with a set, and simplify/fix logic in the check. I think its 
a bit easier to understand at least.

It also:
- Adds registerAsParallelCapable
- Makes bundleclassloader and bundleclassloader5 static (I just used intellij's 
'make static' to get this done)

Still unresolved:
- Handling interruptedexception.

Let me know if you can review it, or if I should try produce a patch against 
trunk. Btw, if you have any stress tests that can easily reproduce the deadlock 
issues, that would also be very helpful.

Thanks

> Use of parallel class loading capability of JDK7
> 
>
> Key: FELIX-3553
> URL: https://issues.apache.org/jira/browse/FELIX-3553
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Reporter: Sahoo
> Fix For: framework-4.2.0
>
> Attachments: FELIX-3553.txt, felix_parallel_classloading.patch
>
>
> Is there any plan to make use of this feature [1] in Felix?
> [1] 
> http://download.java.net/jdk7/archive/b124/docs/technotes/guides/lang/cl-mt.html
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FELIX-3553) Use of parallel class loading capability of JDK7

[Ulf Lilleengen (JIRA)]

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

Ulf Lilleengen updated FELIX-3553:
--

Attachment: felix_parallel_classloading.patch

> Use of parallel class loading capability of JDK7
> 
>
> Key: FELIX-3553
> URL: https://issues.apache.org/jira/browse/FELIX-3553
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Reporter: Sahoo
> Fix For: framework-4.2.0
>
> Attachments: FELIX-3553.txt, felix_parallel_classloading.patch
>
>
> Is there any plan to make use of this feature [1] in Felix?
> [1] 
> http://download.java.net/jdk7/archive/b124/docs/technotes/guides/lang/cl-mt.html
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-3770) Upgrade jquery-ui to 1.9.1

[Felix Meschberger (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-3770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504614#comment-13504614
 ] 

Felix Meschberger commented on FELIX-3770:
--

Thanks for the archive. We generally prefer real patches (not modified classes 
in full packaged in a ZIP) because this helps analyzing the differences.

You can create a patch easily using the svn diff command or using the "create 
patch" functionality in your IDE. 

> Upgrade jquery-ui to 1.9.1
> --
>
> Key: FELIX-3770
> URL: https://issues.apache.org/jira/browse/FELIX-3770
> Project: Felix
>  Issue Type: New Feature
>  Components: Web Console
>Reporter: Henry Saginor
> Attachments: FELIX-3770.tar.gz
>
>
> It's time to upgrade jquery-ui used by Web Console. JQuery UI 1.9.1 has new 
> features like a menu widget that can be used to implement FELIX-3769. JQuery 
> core should probably be upgraded as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-3769) Improve the way Web Console UI manages growing number of plugins.

[Felix Meschberger (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504613#comment-13504613
 ] 

Felix Meschberger commented on FELIX-3769:
--

Thanks for the archive. We generally prefer real patches (not modified classes 
in full packaged in a ZIP) because this helps analyzing the differences.

You can create a patch easily using the svn diff command or using the "create 
patch" functionality in your IDE.

> Improve the way Web Console UI manages growing number of plugins.
> -
>
> Key: FELIX-3769
> URL: https://issues.apache.org/jira/browse/FELIX-3769
> Project: Felix
>  Issue Type: New Feature
>  Components: Web Console
>Reporter: Henry Saginor
>Priority: Minor
> Attachments: FELIX-3769.tar.gz
>
>
> Something needs to be done about growing number of web console plugins. 
> Currently the UI displays a tab for each plugin. This makes the UI cluttered 
> as more and more plugins are added. To address the tabs should be replaced 
> with a tree structure or a drop-down menu.
> Felix Meschberger has proposed the following on the dev list to implement 
> this.
> "* Plugins registered as services may have a "felix.webconsole.category" 
> property
> indicating the category. Plugins not registering this property will be placed 
> in
> the default category
> * AbstractWebConsolePlugin is ammended with a getCategory() method, which may
> overwritten by implementations. The default implementation in the
> AbstractWebConsolePlugin class returns the default category
> * A default category can be configured
> * Categories are simple strings such as "OSGi" or relative paths such as
> "Sling/Main". Relative paths define multi-level trees. I think in general a
> single level is probably enough. Maybe we can start with just supporting a
> single level (so just plain strings).
> * Translation of categories is such that each segment in the path (or the
> complete string if there is no sub-categories) is converted into a translation
> label by prefixing with "category.". So the translation for the "OSGi" 
> category
> would be found with the translation string "category.OSGi".
> * The plugin navigation is refactored to move it to the left and render it as 
> a
> tree structure (I assume we can use the JQuery treetable plugin)."

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (FELIX-3787) NPE on reference update

[Felix Meschberger (JIRA)]

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

Felix Meschberger resolved FELIX-3787.
--

   Resolution: Fixed
Fix Version/s: scr-1.6.4

Thanks.

I can reproduce it now.

The issue occurs because this is a delayed component which is *not* activated 
yet and so the internal dependency map has not been setup, thus is null and the 
statement:

  Map bound = ( Map ) m_componentManager.getDependencyMap().get( this );

is expected to throw an NPE in this case.

Turns out it is nasty (and unneeded logging only) because the component has 
never been activated. Consequently this situation has no adverse consequences 
on operations (despite the logging).

Fixing this in Rev. 1414168 by guarding against missing dependencies map.

> NPE on reference update
> ---
>
> Key: FELIX-3787
> URL: https://issues.apache.org/jira/browse/FELIX-3787
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-1.6.2
>Reporter: Dmytro Pishchukhin
>Assignee: Felix Meschberger
> Fix For: scr-1.6.4
>
>
> I defined reference with annotation:
> @Reference(referenceInterface = Controller.class, cardinality = 
> ReferenceCardinality.MANDATORY_UNARY, policyOption = 
> ReferencePolicyOption.GREEDY)
> protected Controller controller;
> when I install a new service I got an error:
> java.lang.NullPointerException
> at 
> org.apache.felix.scr.impl.manager.DependencyManager.serviceAdded(DependencyManager.java:383)
> at 
> org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:159)
> at 
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
> at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
> at 
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3275) 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (FELIX-3787) NPE on reference update

[Felix Meschberger (JIRA)]

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

Felix Meschberger reassigned FELIX-3787:


Assignee: Felix Meschberger

> NPE on reference update
> ---
>
> Key: FELIX-3787
> URL: https://issues.apache.org/jira/browse/FELIX-3787
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-1.6.2
>Reporter: Dmytro Pishchukhin
>Assignee: Felix Meschberger
>
> I defined reference with annotation:
> @Reference(referenceInterface = Controller.class, cardinality = 
> ReferenceCardinality.MANDATORY_UNARY, policyOption = 
> ReferencePolicyOption.GREEDY)
> protected Controller controller;
> when I install a new service I got an error:
> java.lang.NullPointerException
> at 
> org.apache.felix.scr.impl.manager.DependencyManager.serviceAdded(DependencyManager.java:383)
> at 
> org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:159)
> at 
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
> at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
> at 
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3275) 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-3787) NPE on reference update

[Dmytro Pishchukhin (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504576#comment-13504576
 ] 

Dmytro Pishchukhin commented on FELIX-3787:
---

some additional info for the issue:

- there are 1+ Controller service. The difference is only SERVICE_RANK property.
- Component is in active state when only 1 Controller service is available. 
Component is in registered state when 2 Controller services are registered and 
in WebConsole I see that "No Services bound" for all references, but state is 
"Satisfied". After some time the Component state changes to active  

> NPE on reference update
> ---
>
> Key: FELIX-3787
> URL: https://issues.apache.org/jira/browse/FELIX-3787
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-1.6.2
>Reporter: Dmytro Pishchukhin
>
> I defined reference with annotation:
> @Reference(referenceInterface = Controller.class, cardinality = 
> ReferenceCardinality.MANDATORY_UNARY, policyOption = 
> ReferencePolicyOption.GREEDY)
> protected Controller controller;
> when I install a new service I got an error:
> java.lang.NullPointerException
> at 
> org.apache.felix.scr.impl.manager.DependencyManager.serviceAdded(DependencyManager.java:383)
> at 
> org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:159)
> at 
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
> at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
> at 
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3275) 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-3787) NPE on reference update

[Dmytro Pishchukhin (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504571#comment-13504571
 ] 

Dmytro Pishchukhin commented on FELIX-3787:
---


http://www.osgi.org/xmlns/scr/v1.2.0";>













> NPE on reference update
> ---
>
> Key: FELIX-3787
> URL: https://issues.apache.org/jira/browse/FELIX-3787
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-1.6.2
>Reporter: Dmytro Pishchukhin
>
> I defined reference with annotation:
> @Reference(referenceInterface = Controller.class, cardinality = 
> ReferenceCardinality.MANDATORY_UNARY, policyOption = 
> ReferencePolicyOption.GREEDY)
> protected Controller controller;
> when I install a new service I got an error:
> java.lang.NullPointerException
> at 
> org.apache.felix.scr.impl.manager.DependencyManager.serviceAdded(DependencyManager.java:383)
> at 
> org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:159)
> at 
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
> at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
> at 
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3275) 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-3787) NPE on reference update

[Felix Meschberger (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504569#comment-13504569
 ] 

Felix Meschberger commented on FELIX-3787:
--

Thanks for reporting.

Would you mind providing us with the component declaration which led to this 
issue ?

NB: I have seen this before but was not able to reproduce.

> NPE on reference update
> ---
>
> Key: FELIX-3787
> URL: https://issues.apache.org/jira/browse/FELIX-3787
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-1.6.2
>Reporter: Dmytro Pishchukhin
>
> I defined reference with annotation:
> @Reference(referenceInterface = Controller.class, cardinality = 
> ReferenceCardinality.MANDATORY_UNARY, policyOption = 
> ReferencePolicyOption.GREEDY)
> protected Controller controller;
> when I install a new service I got an error:
> java.lang.NullPointerException
> at 
> org.apache.felix.scr.impl.manager.DependencyManager.serviceAdded(DependencyManager.java:383)
> at 
> org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:159)
> at 
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
> at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
> at 
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3275) 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (FELIX-3787) NPE on reference update

[Dmytro Pishchukhin (JIRA)]

Dmytro Pishchukhin created FELIX-3787:
-

 Summary: NPE on reference update
 Key: FELIX-3787
 URL: https://issues.apache.org/jira/browse/FELIX-3787
 Project: Felix
  Issue Type: Bug
  Components: Declarative Services (SCR)
Affects Versions: scr-1.6.2
Reporter: Dmytro Pishchukhin


I defined reference with annotation:
@Reference(referenceInterface = Controller.class, cardinality = 
ReferenceCardinality.MANDATORY_UNARY, policyOption = 
ReferencePolicyOption.GREEDY)
protected Controller controller;

when I install a new service I got an error:
java.lang.NullPointerException
at 
org.apache.felix.scr.impl.manager.DependencyManager.serviceAdded(DependencyManager.java:383)
at 
org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:159)
at 
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
at 
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
at 
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260)
at org.apache.felix.framework.Felix.registerService(Felix.java:3275) 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (FELIX-3067) Prevent Deadlock Situation in Felix.acquireGlobalLock

[Bertrand Delacretaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504527#comment-13504527
 ] 

Bertrand Delacretaz edited comment on FELIX-3067 at 11/27/12 11:06 AM:
---

I can now reliably reproduce such deadlocks using my 
https://github.com/bdelacretaz/osgi-stresser stress test tool - requires a few 
manual steps but generates deadlocks after just a few seconds in my tests.

I'm using the Sling Launchpad for this, as that contains a number of bundles 
that can be uninstalled/started/stopped (like crazy) to expose the problem. It 
looks like lots of package refreshes helps expose deadlocks much quicker.

Here's my failure scenario (using a 1.6.0_37 JVM on macosx):
# Build Sling from http://svn.apache.org/repos/asf/sling/trunk, making sure 
it's using the Felix trunk's framework and scr modules (patch follows)
# Start Sling:
## cd launchpad/builder
## rm -rf sling (if needed to remove all previous state)
## java -jar target/org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
## Optionally add -Dsling.launchpad.log.level=4 to set OSGi log level to DEBUG, 
use with my FELIX-3785 patch to log locking operations
# Build the https://github.com/bdelacretaz/osgi-stresser bundle and install at 
start level 1 (so that it doesn't stop itself) from /system/console
# Connect to the tool's command line using telnet 1234

At this point the tool's stress test tasks can be started using the commands 
described at https://github.com/bdelacretaz/osgi-stresser - or simply use * r 
to start all tasks, at which point the tool should display something like

OSGI stresser> * r
sl task running - cycle time -1000 msec - levels=[3, 45, 8, 19, 30]
rp task running - cycle time 5000 msec - max wait for packages refresh=1
ss task running - cycle time 0 msec - bundle to stop and 
restart=org.apache.sling.junit.core
bu task running - cycle time -1000 msec - ignored symbolic names 
(patterns)=[commons, org.apache.felix, slf4j, ch.x42, log, org.osgi]
up task running - cycle time 0 msec - bundle to 
update=org.apache.sling.junit.core
OSGI stresser> 

the tasks then do crazy things to the OSGi framework, but (IMO) according to 
spec so should not cause any deadlocks - but they do.

The sling/logs/error.log shows what the tasks are doing, and a good way to 
detect the global/bundle locks deadlock is to try to refresh /system/console, 
that will block if the locks cannot be acquired.

  was (Author: bdelacretaz):
I can now reliably reproduce such deadlocks using my 
https://github.com/bdelacretaz/osgi-stresser stress test tool - requires a few 
manual steps but generates deadlocks after just a few seconds in my tests.

I'm using the Sling Launchpad for this, as that contains a number of bundles 
that can be uninstalled/started/stopped (like crazy) to expose the problem. It 
looks like lots of package refreshes helps expose deadlocks much quicker.

Here's my failure scenario:
# Build Sling from http://svn.apache.org/repos/asf/sling/trunk, making sure 
it's using the Felix trunk's framework and scr modules (patch follows)
# Start Sling:
## cd launchpad/builder
## rm -rf sling (if needed to remove all previous state)
## java -jar target/org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
## Optionally add -Dsling.launchpad.log.level=4 to set OSGi log level to DEBUG, 
use with my FELIX-3785 patch to log locking operations
# Build the https://github.com/bdelacretaz/osgi-stresser bundle and install at 
start level 1 (so that it doesn't stop itself) from /system/console
# Connect to the tool's command line using telnet 1234

At this point the tool's stress test tasks can be started using the commands 
described at https://github.com/bdelacretaz/osgi-stresser - or simply use * r 
to start all tasks, at which point the tool should display something like

OSGI stresser> * r
sl task running - cycle time -1000 msec - levels=[3, 45, 8, 19, 30]
rp task running - cycle time 5000 msec - max wait for packages refresh=1
ss task running - cycle time 0 msec - bundle to stop and 
restart=org.apache.sling.junit.core
bu task running - cycle time -1000 msec - ignored symbolic names 
(patterns)=[commons, org.apache.felix, slf4j, ch.x42, log, org.osgi]
up task running - cycle time 0 msec - bundle to 
update=org.apache.sling.junit.core
OSGI stresser> 

the tasks then do crazy things to the OSGi framework, but (IMO) according to 
spec so should not cause any deadlocks.

The sling/logs/error.log shows what the tasks are doing, and a good way to 
detect the global/bundle locks deadlock is to try to refresh /system/console, 
that will block if the locks cannot be acquired.
  
> Prevent Deadlock Situation in Felix.acquireGlobalLock
> -
>
> Key: FELIX-3067
> URL: https://issues.apache.org/jira/brow

[jira] [Comment Edited] (FELIX-3067) Prevent Deadlock Situation in Felix.acquireGlobalLock

[Bertrand Delacretaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504527#comment-13504527
 ] 

Bertrand Delacretaz edited comment on FELIX-3067 at 11/27/12 11:04 AM:
---

I can now reliably reproduce such deadlocks using my 
https://github.com/bdelacretaz/osgi-stresser stress test tool - requires a few 
manual steps but generates deadlocks after just a few seconds in my tests.

I'm using the Sling Launchpad for this, as that contains a number of bundles 
that can be uninstalled/started/stopped (like crazy) to expose the problem. It 
looks like lots of package refreshes helps expose deadlocks much quicker.

Here's my failure scenario:
# Build Sling from http://svn.apache.org/repos/asf/sling/trunk, making sure 
it's using the Felix trunk's framework and scr modules (patch follows)
# Start Sling:
## cd launchpad/builder
## rm -rf sling (if needed to remove all previous state)
## java -jar target/org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
## Optionally add -Dsling.launchpad.log.level=4 to set OSGi log level to DEBUG, 
use with my FELIX-3785 patch to log locking operations
# Build the https://github.com/bdelacretaz/osgi-stresser bundle and install at 
start level 1 (so that it doesn't stop itself) from /system/console
# Connect to the tool's command line using telnet 1234

At this point the tool's stress test tasks can be started using the commands 
described at https://github.com/bdelacretaz/osgi-stresser - or simply use * r 
to start all tasks, at which point the tool should display something like

OSGI stresser> * r
sl task running - cycle time -1000 msec - levels=[3, 45, 8, 19, 30]
rp task running - cycle time 5000 msec - max wait for packages refresh=1
ss task running - cycle time 0 msec - bundle to stop and 
restart=org.apache.sling.junit.core
bu task running - cycle time -1000 msec - ignored symbolic names 
(patterns)=[commons, org.apache.felix, slf4j, ch.x42, log, org.osgi]
up task running - cycle time 0 msec - bundle to 
update=org.apache.sling.junit.core
OSGI stresser> 

the tasks then do crazy things to the OSGi framework, but (IMO) according to 
spec so should not cause any deadlocks.

The sling/logs/error.log shows what the tasks are doing, and a good way to 
detect the global/bundle locks deadlock is to try to refresh /system/console, 
that will block if the locks cannot be acquired.

  was (Author: bdelacretaz):
I can now reliably reproduce such deadlocks using my 
https://github.com/bdelacretaz/osgi-stresser stress test tool - requires a few 
manual steps but generates deadlocks after just a few seconds in my tests.

I'm using the Sling Launchpad for this, as that contains a number of bundles 
that can be uninstalled/started/stopped (like crazy) to expose the problem. It 
looks like lots of package refreshes helps expose deadlocks much quicker.

Here's my failure scenario:
# Build Sling from http://svn.apache.org/repos/asf/sling/trunk, making sure 
it's using the Felix trunk's framework and scr modules (patch follows)
# Start Sling:
## cd launchpad/builder
## rm -rf sling (if needed to remove all previous state)
## java -jar target/org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
## Optionally add -Dsling.launchpad.log.level=4 to set OSGi log level to DEBUG, 
use with my FELIX-3785 patch to log locking operations
# Build the https://github.com/bdelacretaz/osgi-stresser bundle and install at 
start level 1 (so that it doesn't stop itself) from /system/console
# Connect to the tool's command line using telnet 1234

At this point the tool's stress test tasks can be started using the commands 
described at https://github.com/bdelacretaz/osgi-stresser - or simply use 

{code}
* r
{code}

to start all tasks, at which point the tool should display something like

{code}
OSGI stresser> * r
sl task running - cycle time -1000 msec - levels=[3, 45, 8, 19, 30]
rp task running - cycle time 5000 msec - max wait for packages refresh=1
ss task running - cycle time 0 msec - bundle to stop and 
restart=org.apache.sling.junit.core
bu task running - cycle time -1000 msec - ignored symbolic names 
(patterns)=[commons, org.apache.felix, slf4j, ch.x42, log, org.osgi]
up task running - cycle time 0 msec - bundle to 
update=org.apache.sling.junit.core
OSGI stresser> 
{code}

the tasks then do crazy things to the OSGi framework, but (IMO) according to 
spec so should not cause any deadlocks.

The sling/logs/error.log shows what the tasks are doing, and a good way to 
detect the global/bundle locks deadlock is to try to refresh /system/console, 
that will block if the locks cannot be acquired.
  
> Prevent Deadlock Situation in Felix.acquireGlobalLock
> -
>
> Key: FELIX-3067
> URL: https://issues.apache.org/jira/browse/FELIX-3067
>  

[jira] [Updated] (FELIX-3067) Prevent Deadlock Situation in Felix.acquireGlobalLock

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated FELIX-3067:
---

Attachment: FELIX-3067-sling.patch

Patch to use the Felix framework + scr snapshots in Sling launchpad

> Prevent Deadlock Situation in Felix.acquireGlobalLock
> -
>
> Key: FELIX-3067
> URL: https://issues.apache.org/jira/browse/FELIX-3067
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-3.0.7, framework-3.0.8, framework-3.0.9, 
> framework-3.2.0, framework-3.2.1, fileinstall-3.1.10
>Reporter: Felix Meschberger
> Attachments: FELIX-3067.patch, FELIX-3067-sling.patch
>
>
> Every now and then we encounter deadlock situations which involve the 
> Felix.acquireGlobalLock method. In our use case we have the following aspects 
> which contribute to this:
> (a) The Apache Felix Declarative Services implementation stops components 
> (and thus causes service unregistration) while the bundle lock is being held 
> because this happens in a SynchronousBundleListener while handling the 
> STOPPING bundle event. We have to do this to ensure the bundle is not really 
> stopped yet to properly stop the bundle's components.
> (b) Implementing a special class loader which involves dynamically resolving 
> packages which in turn uses the global lock
> (c) Eclipse Gemini Blueprint implementation which operates asynchronously
> (d) synchronization in application classes
> Often times, I would assume that we can self-heal such complex deadlck 
> situations, if we let acquireGlobalLock time out. Looking at the calles of 
> acquireGlobalLock there seems to already be provision to handle this case 
> since acquireGlobalLock returns true only if the global lock has actually 
> been acquired.
> This issue is kind of a companion to FELIX-3000 where deadlocks involve 
> sending service registration events while holding the bundle lock.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-3067) Prevent Deadlock Situation in Felix.acquireGlobalLock

[Bertrand Delacretaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504527#comment-13504527
 ] 

Bertrand Delacretaz commented on FELIX-3067:


5.6 deadlock, stress test tool?
jenkins tests
Sling log markers

from53 test, not enough memory for 5.6, uses plain java instead of 
/usr/java/jdk1.6.0_35/bin/java ?

I can now reliably reproduce such deadlocks using my 
https://github.com/bdelacretaz/osgi-stresser stress test tool - requires a few 
manual steps but generates deadlocks after just a few seconds in my tests.

I'm using the Sling Launchpad for this, as that contains a number of bundles 
that can be uninstalled/started/stopped (like crazy) to expose the problem. It 
looks like lots of package refreshes helps expose deadlocks much quicker.

Here's my failure scenario:
# Build Sling from http://svn.apache.org/repos/asf/sling/trunk, making sure 
it's using the Felix trunk's framework and scr modules (patch follows)
# Start Sling:
## cd launchpad/builder
## rm -rf sling (if needed to remove all previous state)
## java -jar target/org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
## Optionally add -Dsling.launchpad.log.level=4 to set OSGi log level to DEBUG, 
use with my FELIX-3785 patch to log locking operations
# Build the https://github.com/bdelacretaz/osgi-stresser bundle and install at 
start level 1 (so that it doesn't stop itself) from /system/console
# Connect to the tool's command line using telnet 1234

At this point the tool's stress test tasks can be started using the commands 
described at https://github.com/bdelacretaz/osgi-stresser - or simply use 

{code}
* r
{code}

to start all tasks, at which point the tool should display something like

{code}
OSGI stresser> * r
sl task running - cycle time -1000 msec - levels=[3, 45, 8, 19, 30]
rp task running - cycle time 5000 msec - max wait for packages refresh=1
ss task running - cycle time 0 msec - bundle to stop and 
restart=org.apache.sling.junit.core
bu task running - cycle time -1000 msec - ignored symbolic names 
(patterns)=[commons, org.apache.felix, slf4j, ch.x42, log, org.osgi]
up task running - cycle time 0 msec - bundle to 
update=org.apache.sling.junit.core
OSGI stresser> 
{code}

the tasks then do crazy things to the OSGi framework, but (IMO) according to 
spec so should not cause any deadlocks.

The sling/logs/error.log shows what the tasks are doing, and a good way to 
detect the global/bundle locks deadlock is to try to refresh /system/console, 
that will block if the locks cannot be acquired.

> Prevent Deadlock Situation in Felix.acquireGlobalLock
> -
>
> Key: FELIX-3067
> URL: https://issues.apache.org/jira/browse/FELIX-3067
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-3.0.7, framework-3.0.8, framework-3.0.9, 
> framework-3.2.0, framework-3.2.1, fileinstall-3.1.10
>Reporter: Felix Meschberger
> Attachments: FELIX-3067.patch
>
>
> Every now and then we encounter deadlock situations which involve the 
> Felix.acquireGlobalLock method. In our use case we have the following aspects 
> which contribute to this:
> (a) The Apache Felix Declarative Services implementation stops components 
> (and thus causes service unregistration) while the bundle lock is being held 
> because this happens in a SynchronousBundleListener while handling the 
> STOPPING bundle event. We have to do this to ensure the bundle is not really 
> stopped yet to properly stop the bundle's components.
> (b) Implementing a special class loader which involves dynamically resolving 
> packages which in turn uses the global lock
> (c) Eclipse Gemini Blueprint implementation which operates asynchronously
> (d) synchronization in application classes
> Often times, I would assume that we can self-heal such complex deadlck 
> situations, if we let acquireGlobalLock time out. Looking at the calles of 
> acquireGlobalLock there seems to already be provision to handle this case 
> since acquireGlobalLock returns true only if the global lock has actually 
> been acquired.
> This issue is kind of a companion to FELIX-3000 where deadlocks involve 
> sending service registration events while holding the bundle lock.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (FELIX-3067) Prevent Deadlock Situation in Felix.acquireGlobalLock

[Bertrand Delacretaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504527#comment-13504527
 ] 

Bertrand Delacretaz edited comment on FELIX-3067 at 11/27/12 10:54 AM:
---

I can now reliably reproduce such deadlocks using my 
https://github.com/bdelacretaz/osgi-stresser stress test tool - requires a few 
manual steps but generates deadlocks after just a few seconds in my tests.

I'm using the Sling Launchpad for this, as that contains a number of bundles 
that can be uninstalled/started/stopped (like crazy) to expose the problem. It 
looks like lots of package refreshes helps expose deadlocks much quicker.

Here's my failure scenario:
# Build Sling from http://svn.apache.org/repos/asf/sling/trunk, making sure 
it's using the Felix trunk's framework and scr modules (patch follows)
# Start Sling:
## cd launchpad/builder
## rm -rf sling (if needed to remove all previous state)
## java -jar target/org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
## Optionally add -Dsling.launchpad.log.level=4 to set OSGi log level to DEBUG, 
use with my FELIX-3785 patch to log locking operations
# Build the https://github.com/bdelacretaz/osgi-stresser bundle and install at 
start level 1 (so that it doesn't stop itself) from /system/console
# Connect to the tool's command line using telnet 1234

At this point the tool's stress test tasks can be started using the commands 
described at https://github.com/bdelacretaz/osgi-stresser - or simply use 

{code}
* r
{code}

to start all tasks, at which point the tool should display something like

{code}
OSGI stresser> * r
sl task running - cycle time -1000 msec - levels=[3, 45, 8, 19, 30]
rp task running - cycle time 5000 msec - max wait for packages refresh=1
ss task running - cycle time 0 msec - bundle to stop and 
restart=org.apache.sling.junit.core
bu task running - cycle time -1000 msec - ignored symbolic names 
(patterns)=[commons, org.apache.felix, slf4j, ch.x42, log, org.osgi]
up task running - cycle time 0 msec - bundle to 
update=org.apache.sling.junit.core
OSGI stresser> 
{code}

the tasks then do crazy things to the OSGi framework, but (IMO) according to 
spec so should not cause any deadlocks.

The sling/logs/error.log shows what the tasks are doing, and a good way to 
detect the global/bundle locks deadlock is to try to refresh /system/console, 
that will block if the locks cannot be acquired.

  was (Author: bdelacretaz):
5.6 deadlock, stress test tool?
jenkins tests
Sling log markers

from53 test, not enough memory for 5.6, uses plain java instead of 
/usr/java/jdk1.6.0_35/bin/java ?

I can now reliably reproduce such deadlocks using my 
https://github.com/bdelacretaz/osgi-stresser stress test tool - requires a few 
manual steps but generates deadlocks after just a few seconds in my tests.

I'm using the Sling Launchpad for this, as that contains a number of bundles 
that can be uninstalled/started/stopped (like crazy) to expose the problem. It 
looks like lots of package refreshes helps expose deadlocks much quicker.

Here's my failure scenario:
# Build Sling from http://svn.apache.org/repos/asf/sling/trunk, making sure 
it's using the Felix trunk's framework and scr modules (patch follows)
# Start Sling:
## cd launchpad/builder
## rm -rf sling (if needed to remove all previous state)
## java -jar target/org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
## Optionally add -Dsling.launchpad.log.level=4 to set OSGi log level to DEBUG, 
use with my FELIX-3785 patch to log locking operations
# Build the https://github.com/bdelacretaz/osgi-stresser bundle and install at 
start level 1 (so that it doesn't stop itself) from /system/console
# Connect to the tool's command line using telnet 1234

At this point the tool's stress test tasks can be started using the commands 
described at https://github.com/bdelacretaz/osgi-stresser - or simply use 

{code}
* r
{code}

to start all tasks, at which point the tool should display something like

{code}
OSGI stresser> * r
sl task running - cycle time -1000 msec - levels=[3, 45, 8, 19, 30]
rp task running - cycle time 5000 msec - max wait for packages refresh=1
ss task running - cycle time 0 msec - bundle to stop and 
restart=org.apache.sling.junit.core
bu task running - cycle time -1000 msec - ignored symbolic names 
(patterns)=[commons, org.apache.felix, slf4j, ch.x42, log, org.osgi]
up task running - cycle time 0 msec - bundle to 
update=org.apache.sling.junit.core
OSGI stresser> 
{code}

the tasks then do crazy things to the OSGi framework, but (IMO) according to 
spec so should not cause any deadlocks.

The sling/logs/error.log shows what the tasks are doing, and a good way to 
detect the global/bundle locks deadlock is to try to refresh /system/console, 
that will block if the locks cannot be acquired.
  
> Prevent Deadlock Situati

Re: pax-logging / log4 / Felix embedded in a Web App

[Bengt Rodehav]

OK - thanks,

/Bengt


2012/11/27 Karl Pauls 

> Equinox is doing some magic by default which is effectively setting the
> context classloader to load classes from the current bundle. This may or
> may not be what you want (in this specific case it is) -- hence, we don't
> do that in felix and you have to do that yourself. In any case, the spec is
> mum on the issue.
>
> regards,
>
> Karl
>
>
> On Tue, Nov 27, 2012 at 11:33 AM, Bengt Rodehav  wrote:
>
> > Thanks for the explanation. One question though:
> >
> > The problem I had (log4j classes were present in jar:s in the Windows
> > CLASSPATH which caused them to found by the application classloader)
> > disappeared  when using Equinox instead of Felix. What is Felix doing
> > different than Equinox? Is Equinox by default setting the CCL to null?
> >
> > /Bengt
> >
> >
> > 2012/11/27 Karl Pauls 
> >
> > > The problem is the context classloader. You have to make sure you set
> the
> > > context classloader to null when starting felix and when calling into
> > felix
> > > from the outside.
> > >
> > > The thing is, threads inherit the current context class loader.
> > > Furthermore, the context classloader gets set by the servlet container
> > when
> > > the bridge servlet is called.
> > >
> > > The problem is that log4j is stupid and assumes that it should use the
> > > context classloader first to try to find classes. That isn't going to
> > work
> > > when log4j is comming from a bundle -- hence, you have two options:
> > >
> > > 1. Set the context classloader to null while creating the framework
> > > instance and starting it _and_ set it to null when calling into the
> > > framework from the outside (_make sure_ to _set it back_ when you
> > return).
> > >
> > > 2. Don't provide log4j from a bundle but make it available via the
> system
> > > bundle (i.e., use a version that you have outside and delegate it
> down).
> > >
> > > regards,
> > >
> > > Karl
> > >
> > >
> > > On Tue, Nov 27, 2012 at 8:26 AM, Bengt Rodehav 
> > wrote:
> > >
> > > > Hello Charles,
> > > >
> > > > I recently had a similar problem that I brought up on the Karaf user
> > > list:
> > > >
> > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/karaf-user/201211.mbox/%3CCAJ0TPG%2BERzf6Q709cndh-YqfP_HQq%3DVk6iA4ZQfEtZE7tJPWUw%40mail.gmail.com%3E
> > > >
> > > > Although my problem was that the application classloader had already
> > > loaded
> > > > some log4j classes due to the CLASSPATH environment variable on
> > Windows,
> > > I
> > > > noted that everything worked fine using Equinox instead of Felix.
> > > >
> > > > Apparently Equinox does some tricks when it comes to hiding already
> > > loaded
> > > > classes. Maybe Felix developers can take a look at what Equinox is
> > doing
> > > > and perhaps do something similar in Felix thus making Felix more
> > > resilient
> > > > to "polluted" classloaders.
> > > >
> > > > /Bengt
> > > >
> > > >
> > > >
> > > > 2010/11/18 Charles Moulliard 
> > > >
> > > > > Hi,
> > > > >
> > > > > Some months ago, an interesting question has been drawn about the
> > > > > classloading issue of log4j class when we use pax-logging bundle
> > within
> > > > > Felix embedded in a web application.
> > > > >
> > > > > http://www.mail-archive.com/**dev@felix.apache.org/msg04908.**html
> <
> > > > http://www.mail-archive.com/dev@felix.apache.org/msg04908.html>
> > > > >
> > > > > I'm faced to the same issue when I would like to use Apache Karaf
> > (top
> > > > > level container of Apache Felix) deployed as a WAR.
> > > > >
> > > > > Does anybody has find a trick to solve the classloading issue ?
> > > > >
> > > > > INFO: locking
> > > > > 2010-11-18 18:08:36.667:INFO::Started
> SelectChannelConnector@0.0.0.
> > **
> > > > > 0:8080 
> > > > > [INFO] Started Jetty Server
> > > > > [INFO] Starting scanner at interval of 10 seconds.
> > > > > log4j:ERROR A "org.apache.log4j.**ConsoleAppender" object is not
> > > > > assignable to a "org.apache.log4j.Appender" variable.
> > > > > log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
> > > > > log4j:ERROR [4.0] whereas object of type
> > > > > log4j:ERROR "org.apache.log4j.**ConsoleAppender" was loaded by
> > > > > [ContextLoader@ServiceMix Embedded Example].
> > > > >
> > > > >
> > > > > Regards,
> > > > >
> > > > > Charles M.
> > > > > Apache Camel, ServiceMix & Karaf committer
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Karl Pauls
> > > karlpa...@gmail.com
> > > http://twitter.com/karlpauls
> > > http://www.linkedin.com/in/karlpauls
> > > https://profiles.google.com/karlpauls
> > >
> >
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls
>

Re: Java 8 System Package Definitions

[Felix Meschberger]

Hi

I have also created FELIX-3786 with a patch for an interim solution.

Regards
Felix

Am 27.11.2012 um 11:26 schrieb Felix Meschberger:

> Hi all
> 
> IIRC Sahoo once came up with nicely done System Package Definitions for Java 
> platform APIs which included uses clauses.
> 
> Does anyone know the state of the Java 8 platform API and whether it already 
> makes sense to go down the road of creating these definitions ?
> 
> Regards
> Felix

[jira] [Updated] (FELIX-3786) Create system paclage definintions for Java 8

[Felix Meschberger (JIRA)]

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

Felix Meschberger updated FELIX-3786:
-

Attachment: FELIX-3786.patch

Proposed patch for the interim solution:

  * Add ee-1.8 and eecap-1.8 properties
  * Add jre-1.8 property as copy of jre-1.7 exposing the same API at the new 
version 0.0.0.1_008_JavaSE

> Create system paclage definintions for Java 8
> -
>
> Key: FELIX-3786
> URL: https://issues.apache.org/jira/browse/FELIX-3786
> Project: Felix
>  Issue Type: Task
>  Components: Framework
>Affects Versions: framework-4.0.3
>Reporter: Felix Meschberger
> Attachments: FELIX-3786.patch
>
>
> The framework currently supports Java platform definitions up to Java 7 but 
> is lacking Java 8 definitions. This results in the framework not properly 
> setting up on Java 8 platforms.
> Maybe we could create an interim definition based on the Java 7 definitions 
> and update the exports once the Java 8 platform API stabilizes ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: pax-logging / log4 / Felix embedded in a Web App

[Karl Pauls]

Equinox is doing some magic by default which is effectively setting the
context classloader to load classes from the current bundle. This may or
may not be what you want (in this specific case it is) -- hence, we don't
do that in felix and you have to do that yourself. In any case, the spec is
mum on the issue.

regards,

Karl


On Tue, Nov 27, 2012 at 11:33 AM, Bengt Rodehav  wrote:

> Thanks for the explanation. One question though:
>
> The problem I had (log4j classes were present in jar:s in the Windows
> CLASSPATH which caused them to found by the application classloader)
> disappeared  when using Equinox instead of Felix. What is Felix doing
> different than Equinox? Is Equinox by default setting the CCL to null?
>
> /Bengt
>
>
> 2012/11/27 Karl Pauls 
>
> > The problem is the context classloader. You have to make sure you set the
> > context classloader to null when starting felix and when calling into
> felix
> > from the outside.
> >
> > The thing is, threads inherit the current context class loader.
> > Furthermore, the context classloader gets set by the servlet container
> when
> > the bridge servlet is called.
> >
> > The problem is that log4j is stupid and assumes that it should use the
> > context classloader first to try to find classes. That isn't going to
> work
> > when log4j is comming from a bundle -- hence, you have two options:
> >
> > 1. Set the context classloader to null while creating the framework
> > instance and starting it _and_ set it to null when calling into the
> > framework from the outside (_make sure_ to _set it back_ when you
> return).
> >
> > 2. Don't provide log4j from a bundle but make it available via the system
> > bundle (i.e., use a version that you have outside and delegate it down).
> >
> > regards,
> >
> > Karl
> >
> >
> > On Tue, Nov 27, 2012 at 8:26 AM, Bengt Rodehav 
> wrote:
> >
> > > Hello Charles,
> > >
> > > I recently had a similar problem that I brought up on the Karaf user
> > list:
> > >
> > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/karaf-user/201211.mbox/%3CCAJ0TPG%2BERzf6Q709cndh-YqfP_HQq%3DVk6iA4ZQfEtZE7tJPWUw%40mail.gmail.com%3E
> > >
> > > Although my problem was that the application classloader had already
> > loaded
> > > some log4j classes due to the CLASSPATH environment variable on
> Windows,
> > I
> > > noted that everything worked fine using Equinox instead of Felix.
> > >
> > > Apparently Equinox does some tricks when it comes to hiding already
> > loaded
> > > classes. Maybe Felix developers can take a look at what Equinox is
> doing
> > > and perhaps do something similar in Felix thus making Felix more
> > resilient
> > > to "polluted" classloaders.
> > >
> > > /Bengt
> > >
> > >
> > >
> > > 2010/11/18 Charles Moulliard 
> > >
> > > > Hi,
> > > >
> > > > Some months ago, an interesting question has been drawn about the
> > > > classloading issue of log4j class when we use pax-logging bundle
> within
> > > > Felix embedded in a web application.
> > > >
> > > > http://www.mail-archive.com/**dev@felix.apache.org/msg04908.**html<
> > > http://www.mail-archive.com/dev@felix.apache.org/msg04908.html>
> > > >
> > > > I'm faced to the same issue when I would like to use Apache Karaf
> (top
> > > > level container of Apache Felix) deployed as a WAR.
> > > >
> > > > Does anybody has find a trick to solve the classloading issue ?
> > > >
> > > > INFO: locking
> > > > 2010-11-18 18:08:36.667:INFO::Started SelectChannelConnector@0.0.0.
> **
> > > > 0:8080 
> > > > [INFO] Started Jetty Server
> > > > [INFO] Starting scanner at interval of 10 seconds.
> > > > log4j:ERROR A "org.apache.log4j.**ConsoleAppender" object is not
> > > > assignable to a "org.apache.log4j.Appender" variable.
> > > > log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
> > > > log4j:ERROR [4.0] whereas object of type
> > > > log4j:ERROR "org.apache.log4j.**ConsoleAppender" was loaded by
> > > > [ContextLoader@ServiceMix Embedded Example].
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Charles M.
> > > > Apache Camel, ServiceMix & Karaf committer
> > > >
> > >
> >
> >
> >
> > --
> > Karl Pauls
> > karlpa...@gmail.com
> > http://twitter.com/karlpauls
> > http://www.linkedin.com/in/karlpauls
> > https://profiles.google.com/karlpauls
> >
>



-- 
Karl Pauls
karlpa...@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls

[jira] [Created] (FELIX-3786) Create system paclage definintions for Java 8

[Felix Meschberger (JIRA)]

Felix Meschberger created FELIX-3786:


 Summary: Create system paclage definintions for Java 8
 Key: FELIX-3786
 URL: https://issues.apache.org/jira/browse/FELIX-3786
 Project: Felix
  Issue Type: Task
  Components: Framework
Affects Versions: framework-4.0.3
Reporter: Felix Meschberger


The framework currently supports Java platform definitions up to Java 7 but is 
lacking Java 8 definitions. This results in the framework not properly setting 
up on Java 8 platforms.

Maybe we could create an interim definition based on the Java 7 definitions and 
update the exports once the Java 8 platform API stabilizes ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: pax-logging / log4 / Felix embedded in a Web App

[Bengt Rodehav]

Thanks for the explanation. One question though:

The problem I had (log4j classes were present in jar:s in the Windows
CLASSPATH which caused them to found by the application classloader)
disappeared  when using Equinox instead of Felix. What is Felix doing
different than Equinox? Is Equinox by default setting the CCL to null?

/Bengt


2012/11/27 Karl Pauls 

> The problem is the context classloader. You have to make sure you set the
> context classloader to null when starting felix and when calling into felix
> from the outside.
>
> The thing is, threads inherit the current context class loader.
> Furthermore, the context classloader gets set by the servlet container when
> the bridge servlet is called.
>
> The problem is that log4j is stupid and assumes that it should use the
> context classloader first to try to find classes. That isn't going to work
> when log4j is comming from a bundle -- hence, you have two options:
>
> 1. Set the context classloader to null while creating the framework
> instance and starting it _and_ set it to null when calling into the
> framework from the outside (_make sure_ to _set it back_ when you return).
>
> 2. Don't provide log4j from a bundle but make it available via the system
> bundle (i.e., use a version that you have outside and delegate it down).
>
> regards,
>
> Karl
>
>
> On Tue, Nov 27, 2012 at 8:26 AM, Bengt Rodehav  wrote:
>
> > Hello Charles,
> >
> > I recently had a similar problem that I brought up on the Karaf user
> list:
> >
> >
> >
> http://mail-archives.apache.org/mod_mbox/karaf-user/201211.mbox/%3CCAJ0TPG%2BERzf6Q709cndh-YqfP_HQq%3DVk6iA4ZQfEtZE7tJPWUw%40mail.gmail.com%3E
> >
> > Although my problem was that the application classloader had already
> loaded
> > some log4j classes due to the CLASSPATH environment variable on Windows,
> I
> > noted that everything worked fine using Equinox instead of Felix.
> >
> > Apparently Equinox does some tricks when it comes to hiding already
> loaded
> > classes. Maybe Felix developers can take a look at what Equinox is doing
> > and perhaps do something similar in Felix thus making Felix more
> resilient
> > to "polluted" classloaders.
> >
> > /Bengt
> >
> >
> >
> > 2010/11/18 Charles Moulliard 
> >
> > > Hi,
> > >
> > > Some months ago, an interesting question has been drawn about the
> > > classloading issue of log4j class when we use pax-logging bundle within
> > > Felix embedded in a web application.
> > >
> > > http://www.mail-archive.com/**dev@felix.apache.org/msg04908.**html<
> > http://www.mail-archive.com/dev@felix.apache.org/msg04908.html>
> > >
> > > I'm faced to the same issue when I would like to use Apache Karaf (top
> > > level container of Apache Felix) deployed as a WAR.
> > >
> > > Does anybody has find a trick to solve the classloading issue ?
> > >
> > > INFO: locking
> > > 2010-11-18 18:08:36.667:INFO::Started SelectChannelConnector@0.0.0.**
> > > 0:8080 
> > > [INFO] Started Jetty Server
> > > [INFO] Starting scanner at interval of 10 seconds.
> > > log4j:ERROR A "org.apache.log4j.**ConsoleAppender" object is not
> > > assignable to a "org.apache.log4j.Appender" variable.
> > > log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
> > > log4j:ERROR [4.0] whereas object of type
> > > log4j:ERROR "org.apache.log4j.**ConsoleAppender" was loaded by
> > > [ContextLoader@ServiceMix Embedded Example].
> > >
> > >
> > > Regards,
> > >
> > > Charles M.
> > > Apache Camel, ServiceMix & Karaf committer
> > >
> >
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls
>

Java 8 System Package Definitions

[Felix Meschberger]

Hi all

IIRC Sahoo once came up with nicely done System Package Definitions for Java 
platform APIs which included uses clauses.

Does anyone know the state of the Java 8 platform API and whether it already 
makes sense to go down the road of creating these definitions ?

Regards
Felix

Re: pax-logging / log4 / Felix embedded in a Web App

[Karl Pauls]

The problem is the context classloader. You have to make sure you set the
context classloader to null when starting felix and when calling into felix
from the outside.

The thing is, threads inherit the current context class loader.
Furthermore, the context classloader gets set by the servlet container when
the bridge servlet is called.

The problem is that log4j is stupid and assumes that it should use the
context classloader first to try to find classes. That isn't going to work
when log4j is comming from a bundle -- hence, you have two options:

1. Set the context classloader to null while creating the framework
instance and starting it _and_ set it to null when calling into the
framework from the outside (_make sure_ to _set it back_ when you return).

2. Don't provide log4j from a bundle but make it available via the system
bundle (i.e., use a version that you have outside and delegate it down).

regards,

Karl


On Tue, Nov 27, 2012 at 8:26 AM, Bengt Rodehav  wrote:

> Hello Charles,
>
> I recently had a similar problem that I brought up on the Karaf user list:
>
>
> http://mail-archives.apache.org/mod_mbox/karaf-user/201211.mbox/%3CCAJ0TPG%2BERzf6Q709cndh-YqfP_HQq%3DVk6iA4ZQfEtZE7tJPWUw%40mail.gmail.com%3E
>
> Although my problem was that the application classloader had already loaded
> some log4j classes due to the CLASSPATH environment variable on Windows, I
> noted that everything worked fine using Equinox instead of Felix.
>
> Apparently Equinox does some tricks when it comes to hiding already loaded
> classes. Maybe Felix developers can take a look at what Equinox is doing
> and perhaps do something similar in Felix thus making Felix more resilient
> to "polluted" classloaders.
>
> /Bengt
>
>
>
> 2010/11/18 Charles Moulliard 
>
> > Hi,
> >
> > Some months ago, an interesting question has been drawn about the
> > classloading issue of log4j class when we use pax-logging bundle within
> > Felix embedded in a web application.
> >
> > http://www.mail-archive.com/**dev@felix.apache.org/msg04908.**html<
> http://www.mail-archive.com/dev@felix.apache.org/msg04908.html>
> >
> > I'm faced to the same issue when I would like to use Apache Karaf (top
> > level container of Apache Felix) deployed as a WAR.
> >
> > Does anybody has find a trick to solve the classloading issue ?
> >
> > INFO: locking
> > 2010-11-18 18:08:36.667:INFO::Started SelectChannelConnector@0.0.0.**
> > 0:8080 
> > [INFO] Started Jetty Server
> > [INFO] Starting scanner at interval of 10 seconds.
> > log4j:ERROR A "org.apache.log4j.**ConsoleAppender" object is not
> > assignable to a "org.apache.log4j.Appender" variable.
> > log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
> > log4j:ERROR [4.0] whereas object of type
> > log4j:ERROR "org.apache.log4j.**ConsoleAppender" was loaded by
> > [ContextLoader@ServiceMix Embedded Example].
> >
> >
> > Regards,
> >
> > Charles M.
> > Apache Camel, ServiceMix & Karaf committer
> >
>



-- 
Karl Pauls
karlpa...@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls