[jira] [Created] (FELIX-6700) Missing OSGi export-package in felix jetty12

[Antoine DESSAIGNE (Jira)]

Antoine DESSAIGNE created FELIX-6700:


 Summary: Missing OSGi export-package in felix jetty12
 Key: FELIX-6700
 URL: https://issues.apache.org/jira/browse/FELIX-6700
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http.jetty12-1.0.2
Reporter: Antoine DESSAIGNE


Hello everyone,

I just noticed that {{org.apache.felix.http.jetty12.light}} doesn't export the 
following packages
{noformat}
org.osgi.service.servlet.context;version="2.0.0";uses:="jakarta.servlet.http,org.osgi.framework"
org.osgi.service.servlet.runtime.dto;version="2.0.0";uses:="org.osgi.dto,org.osgi.framework.dto"
org.osgi.service.servlet.runtime;version="2.0.0";uses:="org.osgi.service.servlet.runtime.dto"
org.osgi.service.servlet.whiteboard;version="2.0.0";uses:="jakarta.servlet"
{noformat}

These packages are present in the jar and contains all the classes present in 
{{org.apache.felix.http.bridge}} and this one export the packages.

Is there a reason why they aren't present in the export package instruction of 
{{jetty12.light}} ? Thank you for your help



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (FELIX-6696) Resources content-type are no longer defined when using a whiteboard pattern

[Antoine DESSAIGNE (Jira)]

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

Antoine DESSAIGNE commented on FELIX-6696:
--

Hi [~cziegeler],

I've just tested it and it's working as expected, thank you for your help.

> Resources content-type are no longer defined when using a whiteboard pattern
> 
>
> Key: FELIX-6696
> URL: https://issues.apache.org/jira/browse/FELIX-6696
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-5.0.0
>Reporter: Antoine DESSAIGNE
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: http.jetty12-1.0.4, http.jetty-5.0.8
>
>
> Hello everyone,
> Resources content-type are no longer defined when using a whiteboard pattern.
> It seems to come from the following commit from FELIX-6584 
> https://github.com/apache/felix-dev/commit/886783ef1fe904c52391aba90171460415ff4f3c.
>  As such it reopened the FELIX-5110 bug.
> The Javadoc of {{ServletContextHelper.getMimeState(String)}} indicates this 
> as returned value ([see 
> Javadoc|https://docs.osgi.org/javadoc/osgi.cmpn/8.0.0/org/osgi/service/http/context/ServletContextHelper.html#getMimeType-java.lang.String-])
>  
> {quote}The MIME type (e.g. text/html) of the specified name or null to 
> indicate that the Http Whiteboard implementation should determine the MIME 
> type itself.{quote}
> Do you think it's possible to bring back the old behavior without breaking 
> FELIX-6584 ? Thank you.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (FELIX-6696) Resources content-type are no longer defined when using a whiteboard pattern

[Antoine DESSAIGNE (Jira)]

Antoine DESSAIGNE created FELIX-6696:


 Summary: Resources content-type are no longer defined when using a 
whiteboard pattern
 Key: FELIX-6696
 URL: https://issues.apache.org/jira/browse/FELIX-6696
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http.jetty-5.0.0
Reporter: Antoine DESSAIGNE


Hello everyone,

Resources content-type are no longer defined when using a whiteboard pattern.

It seems to come from the following commit from FELIX-6584 
https://github.com/apache/felix-dev/commit/886783ef1fe904c52391aba90171460415ff4f3c.
 As such it reopened the FELIX-5110 bug.

The Javadoc of {{ServletContextHelper.getMimeState(String)}} indicates this as 
returned value ([see 
Javadoc|https://docs.osgi.org/javadoc/osgi.cmpn/8.0.0/org/osgi/service/http/context/ServletContextHelper.html#getMimeType-java.lang.String-])
 
{quote}The MIME type (e.g. text/html) of the specified name or null to indicate 
that the Http Whiteboard implementation should determine the MIME type 
itself.{quote}

Do you think it's possible to bring back the old behavior without breaking 
FELIX-6584 ? Thank you.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (FELIX-6599) javax.servlet incompatibility between Felix HTTP Jetty Light 4.2.8 and Jetty 9.4.x

[Antoine DESSAIGNE (Jira)]

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

Antoine DESSAIGNE commented on FELIX-6599:
--

Thanks [~cziegeler] for letting me know. When using 
{{org.apache.felix.http.servlet-api}} (without {{tomcat-servlet-api}}) instead 
of {{javax.servlet-api}} then it's working fine

> javax.servlet incompatibility between Felix HTTP Jetty Light 4.2.8 and Jetty 
> 9.4.x
> --
>
> Key: FELIX-6599
> URL: https://issues.apache.org/jira/browse/FELIX-6599
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-4.2.8
>Reporter: Antoine DESSAIGNE
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: http.jetty-4.2.10, http.base-4.2.6, http.bridge-4.2.8
>
>
> Hello everyone,
> We detected what looks like an inconsistency in Felix HTTP Jetty Light 4.2.8 
> (where Jetty is an external jar and not inlined).
> In the {{MANIFEST.MF}} file we can see
> {noformat}
> Import-Package:
>  javax.servlet.descriptor;version="[3.1,4)"
>  javax.servlet.http;version="[3.1,4)"
>  javax.servlet;version="[3.1,4)"
>  ...
> Require-Capability: 
> osgi.contract;filter:="(&(osgi.contract=JavaServlet)(version=4.0))",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> {noformat}
> So it asks for {{javax.servlet}} in version range [3.1,4) but ask for a 4.0 
> Java Servlet capability. Unfortunately 
> {{org.apache.felix.http.base.internal.registry.PathResolverFactory}} uses 
> {{javax.servlet.http.MappingMatch}} which is only available starting in 4.0.
> Felix HTTP Jetty Light uses Jetty 9.4.50.v20221201 which requires 
> {{javax.servlet}} in version range [3.1,4).
> So it looks like in the 4.2.x branch, {{javax.servlet}} should be in 3.1.0 
> and {{javax.servlet.http.MappingMatch}} should not be used. Am I right or is 
> there something I did wrong?
> Thank you for your help



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (FELIX-6599) javax.servlet incompatibility between Felix HTTP Jetty Light 4.2.8 and Jetty 9.4.x

[Antoine DESSAIGNE (Jira)]

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

Antoine DESSAIGNE commented on FELIX-6599:
--

I use this (I left the comment as it's relevant)
{noformat}

javax.servlet
javax.servlet-api

3.1.0

{noformat}

What puzzles me the most is the import packages of Jetty itself (see the 
following properly formatted subset)
{noformat}
Import-Package:
 javax.servlet.annotation;version="[3.1.0,4)"
 javax.servlet.descriptor;version="[3.1.0,4)"
 javax.servlet.http;version="[3.1.0,4)"
 javax.servlet;version="[3.1.0,4)"
{noformat}

> javax.servlet incompatibility between Felix HTTP Jetty Light 4.2.8 and Jetty 
> 9.4.x
> --
>
> Key: FELIX-6599
> URL: https://issues.apache.org/jira/browse/FELIX-6599
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-4.2.8
>Reporter: Antoine DESSAIGNE
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: http.jetty-4.2.10, http.base-4.2.6, http.bridge-4.2.8
>
>
> Hello everyone,
> We detected what looks like an inconsistency in Felix HTTP Jetty Light 4.2.8 
> (where Jetty is an external jar and not inlined).
> In the {{MANIFEST.MF}} file we can see
> {noformat}
> Import-Package:
>  javax.servlet.descriptor;version="[3.1,4)"
>  javax.servlet.http;version="[3.1,4)"
>  javax.servlet;version="[3.1,4)"
>  ...
> Require-Capability: 
> osgi.contract;filter:="(&(osgi.contract=JavaServlet)(version=4.0))",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> {noformat}
> So it asks for {{javax.servlet}} in version range [3.1,4) but ask for a 4.0 
> Java Servlet capability. Unfortunately 
> {{org.apache.felix.http.base.internal.registry.PathResolverFactory}} uses 
> {{javax.servlet.http.MappingMatch}} which is only available starting in 4.0.
> Felix HTTP Jetty Light uses Jetty 9.4.50.v20221201 which requires 
> {{javax.servlet}} in version range [3.1,4).
> So it looks like in the 4.2.x branch, {{javax.servlet}} should be in 3.1.0 
> and {{javax.servlet.http.MappingMatch}} should not be used. Am I right or is 
> there something I did wrong?
> Thank you for your help



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (FELIX-6599) javax.servlet incompatibility between Felix HTTP Jetty Light 4.2.8 and Jetty 9.4.x

[Antoine DESSAIGNE (Jira)]

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

Antoine DESSAIGNE commented on FELIX-6599:
--

I don't know how it's possible to require servlet 4 implementation when Jetty 
9.4.x itself excludes servlet 4.

> javax.servlet incompatibility between Felix HTTP Jetty Light 4.2.8 and Jetty 
> 9.4.x
> --
>
> Key: FELIX-6599
> URL: https://issues.apache.org/jira/browse/FELIX-6599
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-4.2.8
>Reporter: Antoine DESSAIGNE
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: http.jetty-4.2.10, http.base-4.2.6, http.bridge-4.2.8
>
>
> Hello everyone,
> We detected what looks like an inconsistency in Felix HTTP Jetty Light 4.2.8 
> (where Jetty is an external jar and not inlined).
> In the {{MANIFEST.MF}} file we can see
> {noformat}
> Import-Package:
>  javax.servlet.descriptor;version="[3.1,4)"
>  javax.servlet.http;version="[3.1,4)"
>  javax.servlet;version="[3.1,4)"
>  ...
> Require-Capability: 
> osgi.contract;filter:="(&(osgi.contract=JavaServlet)(version=4.0))",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> {noformat}
> So it asks for {{javax.servlet}} in version range [3.1,4) but ask for a 4.0 
> Java Servlet capability. Unfortunately 
> {{org.apache.felix.http.base.internal.registry.PathResolverFactory}} uses 
> {{javax.servlet.http.MappingMatch}} which is only available starting in 4.0.
> Felix HTTP Jetty Light uses Jetty 9.4.50.v20221201 which requires 
> {{javax.servlet}} in version range [3.1,4).
> So it looks like in the 4.2.x branch, {{javax.servlet}} should be in 3.1.0 
> and {{javax.servlet.http.MappingMatch}} should not be used. Am I right or is 
> there something I did wrong?
> Thank you for your help



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (FELIX-6599) javax.servlet incompatibility between Felix HTTP Jetty Light 4.2.8 and Jetty 9.4.x

[Antoine DESSAIGNE (Jira)]

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

Antoine DESSAIGNE commented on FELIX-6599:
--

Hello [~cziegeler],

It looks like it still doesn't work. The {{org.apache.felix.http.jetty}} jar 
inlines the {{org.apache.felix.http.base}} jar, so it fails loading 
{{org.apache.felix.http.base.internal.dispatch.HttpServletMappingImpl}} because 
there are 2 imports from {{javax.servlet}} 4.0.

Here's the stack trace we have
{noformat}
2023-03-13 11:33:38,903 [qtp712325821-1883] WARN 
org.eclipse.jetty.server.HttpChannel - /favicon.ico
java.lang.NoClassDefFoundError: javax/servlet/http/HttpServletMapping
    at 
org.apache.felix.http.base.internal.dispatch.Dispatcher$1.doFilter(Dispatcher.java:139)
 ~[?:?]
    at 
org.apache.felix.http.base.internal.whiteboard.WhiteboardManager.invokePreprocessors(WhiteboardManager.java:986)
 ~[?:?]
    at 
org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:94)
 ~[?:?]
    at 
org.apache.felix.http.base.internal.dispatch.DispatcherServlet.service(DispatcherServlet.java:49)
 ~[?:?]
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) 
~[javax.servlet-api-3.1.0.jar:3.1.0]
    at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) 
~[?:?]
    at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:554) 
~[?:?]
...
{noformat}

What do you think? Thank you for your help.


> javax.servlet incompatibility between Felix HTTP Jetty Light 4.2.8 and Jetty 
> 9.4.x
> --
>
> Key: FELIX-6599
> URL: https://issues.apache.org/jira/browse/FELIX-6599
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-4.2.8
>Reporter: Antoine DESSAIGNE
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: http.jetty-4.2.10, http.base-4.2.6, http.bridge-4.2.8
>
>
> Hello everyone,
> We detected what looks like an inconsistency in Felix HTTP Jetty Light 4.2.8 
> (where Jetty is an external jar and not inlined).
> In the {{MANIFEST.MF}} file we can see
> {noformat}
> Import-Package:
>  javax.servlet.descriptor;version="[3.1,4)"
>  javax.servlet.http;version="[3.1,4)"
>  javax.servlet;version="[3.1,4)"
>  ...
> Require-Capability: 
> osgi.contract;filter:="(&(osgi.contract=JavaServlet)(version=4.0))",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> {noformat}
> So it asks for {{javax.servlet}} in version range [3.1,4) but ask for a 4.0 
> Java Servlet capability. Unfortunately 
> {{org.apache.felix.http.base.internal.registry.PathResolverFactory}} uses 
> {{javax.servlet.http.MappingMatch}} which is only available starting in 4.0.
> Felix HTTP Jetty Light uses Jetty 9.4.50.v20221201 which requires 
> {{javax.servlet}} in version range [3.1,4).
> So it looks like in the 4.2.x branch, {{javax.servlet}} should be in 3.1.0 
> and {{javax.servlet.http.MappingMatch}} should not be used. Am I right or is 
> there something I did wrong?
> Thank you for your help



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (FELIX-6599) javax.servlet incompatibility between Felix HTTP Jetty Light 4.2.8 and Jetty 9.4.x

[Antoine DESSAIGNE (Jira)]

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

Antoine DESSAIGNE commented on FELIX-6599:
--

Thank you [~cziegeler] for handling this so quickly

> javax.servlet incompatibility between Felix HTTP Jetty Light 4.2.8 and Jetty 
> 9.4.x
> --
>
> Key: FELIX-6599
> URL: https://issues.apache.org/jira/browse/FELIX-6599
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-4.2.8
>Reporter: Antoine DESSAIGNE
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: http.jetty-4.2.10, http.base-4.2.6, http.bridge-4.2.8
>
>
> Hello everyone,
> We detected what looks like an inconsistency in Felix HTTP Jetty Light 4.2.8 
> (where Jetty is an external jar and not inlined).
> In the {{MANIFEST.MF}} file we can see
> {noformat}
> Import-Package:
>  javax.servlet.descriptor;version="[3.1,4)"
>  javax.servlet.http;version="[3.1,4)"
>  javax.servlet;version="[3.1,4)"
>  ...
> Require-Capability: 
> osgi.contract;filter:="(&(osgi.contract=JavaServlet)(version=4.0))",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> {noformat}
> So it asks for {{javax.servlet}} in version range [3.1,4) but ask for a 4.0 
> Java Servlet capability. Unfortunately 
> {{org.apache.felix.http.base.internal.registry.PathResolverFactory}} uses 
> {{javax.servlet.http.MappingMatch}} which is only available starting in 4.0.
> Felix HTTP Jetty Light uses Jetty 9.4.50.v20221201 which requires 
> {{javax.servlet}} in version range [3.1,4).
> So it looks like in the 4.2.x branch, {{javax.servlet}} should be in 3.1.0 
> and {{javax.servlet.http.MappingMatch}} should not be used. Am I right or is 
> there something I did wrong?
> Thank you for your help



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (FELIX-6599) javax.servlet incompatibility between Felix HTTP Jetty Light 4.2.8 and Jetty 9.4.x

[Antoine DESSAIGNE (Jira)]

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

Antoine DESSAIGNE commented on FELIX-6599:
--

Hi [~cziegeler],

Unfortunately, I don't think this path is doable as Felix HTTP Jetty 4.2.8 uses 
Jetty 9.4.50 which requires {{javax.servlet}} in version 3.1 and not 4 (range 
is {{3.1,4)}})

> javax.servlet incompatibility between Felix HTTP Jetty Light 4.2.8 and Jetty 
> 9.4.x
> --
>
> Key: FELIX-6599
> URL: https://issues.apache.org/jira/browse/FELIX-6599
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-4.2.8
>Reporter: Antoine DESSAIGNE
>Priority: Major
>
> Hello everyone,
> We detected what looks like an inconsistency in Felix HTTP Jetty Light 4.2.8 
> (where Jetty is an external jar and not inlined).
> In the {{MANIFEST.MF}} file we can see
> {noformat}
> Import-Package:
>  javax.servlet.descriptor;version="[3.1,4)"
>  javax.servlet.http;version="[3.1,4)"
>  javax.servlet;version="[3.1,4)"
>  ...
> Require-Capability: 
> osgi.contract;filter:="(&(osgi.contract=JavaServlet)(version=4.0))",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> {noformat}
> So it asks for {{javax.servlet}} in version range [3.1,4) but ask for a 4.0 
> Java Servlet capability. Unfortunately 
> {{org.apache.felix.http.base.internal.registry.PathResolverFactory}} uses 
> {{javax.servlet.http.MappingMatch}} which is only available starting in 4.0.
> Felix HTTP Jetty Light uses Jetty 9.4.50.v20221201 which requires 
> {{javax.servlet}} in version range [3.1,4).
> So it looks like in the 4.2.x branch, {{javax.servlet}} should be in 3.1.0 
> and {{javax.servlet.http.MappingMatch}} should not be used. Am I right or is 
> there something I did wrong?
> Thank you for your help



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (FELIX-6599) javax.servlet incompatibility between Felix HTTP Jetty Light 4.2.8 and Jetty 9.4.x

[Antoine DESSAIGNE (Jira)]

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

Antoine DESSAIGNE updated FELIX-6599:
-
Component/s: HTTP Service
 (was: Lightweight HTTP Service)

> javax.servlet incompatibility between Felix HTTP Jetty Light 4.2.8 and Jetty 
> 9.4.x
> --
>
> Key: FELIX-6599
> URL: https://issues.apache.org/jira/browse/FELIX-6599
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-4.2.8
>Reporter: Antoine DESSAIGNE
>Priority: Major
>
> Hello everyone,
> We detected what looks like an inconsistency in Felix HTTP Jetty Light 4.2.8 
> (where Jetty is an external jar and not inlined).
> In the {{MANIFEST.MF}} file we can see
> {noformat}
> Import-Package:
>  javax.servlet.descriptor;version="[3.1,4)"
>  javax.servlet.http;version="[3.1,4)"
>  javax.servlet;version="[3.1,4)"
>  ...
> Require-Capability: 
> osgi.contract;filter:="(&(osgi.contract=JavaServlet)(version=4.0))",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> {noformat}
> So it asks for {{javax.servlet}} in version range [3.1,4) but ask for a 4.0 
> Java Servlet capability. Unfortunately 
> {{org.apache.felix.http.base.internal.registry.PathResolverFactory}} uses 
> {{javax.servlet.http.MappingMatch}} which is only available starting in 4.0.
> Felix HTTP Jetty Light uses Jetty 9.4.50.v20221201 which requires 
> {{javax.servlet}} in version range [3.1,4).
> So it looks like in the 4.2.x branch, {{javax.servlet}} should be in 3.1.0 
> and {{javax.servlet.http.MappingMatch}} should not be used. Am I right or is 
> there something I did wrong?
> Thank you for your help



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (FELIX-6599) javax.servlet incompatibility between Felix HTTP Jetty Light 4.2.8 and Jetty 9.4.x

[Antoine DESSAIGNE (Jira)]

Antoine DESSAIGNE created FELIX-6599:


 Summary: javax.servlet incompatibility between Felix HTTP Jetty 
Light 4.2.8 and Jetty 9.4.x
 Key: FELIX-6599
 URL: https://issues.apache.org/jira/browse/FELIX-6599
 Project: Felix
  Issue Type: Bug
  Components: Lightweight HTTP Service
Affects Versions: http.jetty-4.2.8
Reporter: Antoine DESSAIGNE


Hello everyone,

We detected what looks like an inconsistency in Felix HTTP Jetty Light 4.2.8 
(where Jetty is an external jar and not inlined).

In the {{MANIFEST.MF}} file we can see
{noformat}
Import-Package:
 javax.servlet.descriptor;version="[3.1,4)"
 javax.servlet.http;version="[3.1,4)"
 javax.servlet;version="[3.1,4)"
 ...
Require-Capability: 
osgi.contract;filter:="(&(osgi.contract=JavaServlet)(version=4.0))",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
{noformat}

So it asks for {{javax.servlet}} in version range [3.1,4) but ask for a 4.0 
Java Servlet capability. Unfortunately 
{{org.apache.felix.http.base.internal.registry.PathResolverFactory}} uses 
{{javax.servlet.http.MappingMatch}} which is only available starting in 4.0.

Felix HTTP Jetty Light uses Jetty 9.4.50.v20221201 which requires 
{{javax.servlet}} in version range [3.1,4).

So it looks like in the 4.2.x branch, {{javax.servlet}} should be in 3.1.0 and 
{{javax.servlet.http.MappingMatch}} should not be used. Am I right or is there 
something I did wrong?

Thank you for your help



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (FELIX-6516) Remove synchronization on Integer in Felix Framework

[Antoine DESSAIGNE (Jira)]

Antoine DESSAIGNE created FELIX-6516:


 Summary: Remove synchronization on Integer in Felix Framework
 Key: FELIX-6516
 URL: https://issues.apache.org/jira/browse/FELIX-6516
 Project: Felix
  Issue Type: Improvement
  Components: Framework
Reporter: Antoine DESSAIGNE


Hello,

In Java 16 was release [JEP 390|https://openjdk.java.net/jeps/390] which issues 
warning when trying to synchronize on value-based class such as Integer

I've found and fixed such usage in {{FrameworkStartLevelImpl}}.

Can you have a look? Thank you



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10

[Antoine DESSAIGNE (JIRA)]

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

Antoine DESSAIGNE commented on FELIX-5942:
--

Hello [~karlpauls],
Thanks for integrating it :)
Do you know when the release is planned ? As JDK11 will replace JDK10 in few 
hours :)
Thanks again.

> 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

[Antoine DESSAIGNE (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10

[Antoine DESSAIGNE (JIRA)]

 [ 
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

[Antoine DESSAIGNE (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Antoine DESSAIGNE (JIRA)]

 [ 
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

[Antoine DESSAIGNE (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Antoine DESSAIGNE (JIRA)]

 [ 
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 
> org.apac

[jira] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10

[Antoine DESSAIGNE (JIRA)]

 [ 
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

[Antoine DESSAIGNE (JIRA)]

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

[jira] [Comment Edited] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10

[Antoine DESSAIGNE (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Antoine DESSAIGNE (JIRA)]

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

[jira] [Commented] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10

[Antoine DESSAIGNE (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Antoine DESSAIGNE (JIRA)]

 [ 
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] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10

[Antoine DESSAIGNE (JIRA)]

 [ 
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] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10

[Antoine DESSAIGNE (JIRA)]

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

[jira] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10

[Antoine DESSAIGNE (JIRA)]

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

[jira] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10

[Antoine DESSAIGNE (JIRA)]

 [ 
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

[Antoine DESSAIGNE (JIRA)]

 [ 
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

[Antoine DESSAIGNE (JIRA)]

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

[jira] [Updated] (FELIX-5942) Felix Framework freezes when resolving classes in parallel with Java 10

[Antoine DESSAIGNE (JIRA)]

 [ 
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 (JIRA)]

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] [Commented] (FELIX-5765) An illegal reflective access operation has occurred

[Antoine DESSAIGNE (JIRA)]

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

Antoine DESSAIGNE commented on FELIX-5765:
--

Hello.
After enabling {{--illegal-access=warn}}, here are all the illegal reflective 
access operations detected while using my application
{noformat}
WARNING: Illegal reflective access by 
org.apache.felix.framework.ext.ClassPathExtenderFactory$DefaultClassLoaderExtender
 (file:org.apache.felix.framework-5.6.10.jar) to method 
java.net.URLClassLoader.addURL(java.net.URL)
WARNING: Illegal reflective access by 
org.apache.felix.framework.util.SecureAction 
(file:org.apache.felix.framework-5.6.10.jar) to field 
java.net.URL.streamHandlerLock
WARNING: Illegal reflective access by 
org.apache.felix.framework.util.SecureAction 
(file:org.apache.felix.framework-5.6.10.jar) to field java.net.URL.factory
WARNING: Illegal reflective access by 
org.apache.felix.framework.util.SecureAction 
(file:org.apache.felix.framework-5.6.10.jar) to field 
java.net.URL.defaultFactory
WARNING: Illegal reflective access by 
org.apache.felix.framework.util.SecureAction 
(file:org.apache.felix.framework-5.6.10.jar) to field java.net.URL.handlers
WARNING: Illegal reflective access by 
org.apache.felix.framework.util.SecureAction 
(file:org.apache.felix.framework-5.6.10.jar) to field 
java.net.URLConnection.handlers
WARNING: Illegal reflective access by 
org.apache.felix.framework.util.SecureAction 
(file:org.apache.felix.framework-5.6.10.jar) to method 
java.lang.ClassLoader.registerAsParallelCapable()
WARNING: Illegal reflective access by 
org.apache.felix.framework.util.SecureAction 
(file:org.apache.felix.framework-5.6.10.jar) to method 
java.lang.ClassLoader.registerAsParallelCapable()
{noformat}

> An illegal reflective access operation has occurred
> ---
>
> Key: FELIX-5765
> URL: https://issues.apache.org/jira/browse/FELIX-5765
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-5.6.10
> Environment: Linux + JDK 9.0.1
>Reporter: Li Xu
>Priority: Minor
>
> Just reporting this as instructed:
> {noformat}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by 
> org.apache.felix.framework.ext.ClassPathExtenderFactory$DefaultClassLoaderExtender
>  (file:/full-test/framework/org.apache.felix.framework-5.6.10.jar) to method 
> java.net.URLClassLoader.addURL(java.net.URL)
> WARNING: Please consider reporting this to the maintainers of 
> org.apache.felix.framework.ext.ClassPathExtenderFactory$DefaultClassLoaderExtender
> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {noformat}



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

[jira] [Commented] (FELIX-5664) Update Jetty to 9.3.20.v20170531 or 9.4.6.v20170531 to fix CVE-2017-9735

[Antoine DESSAIGNE (JIRA)]

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

Antoine DESSAIGNE commented on FELIX-5664:
--

Thank you very much!

> Update Jetty to 9.3.20.v20170531 or 9.4.6.v20170531 to fix CVE-2017-9735
> 
>
> Key: FELIX-5664
> URL: https://issues.apache.org/jira/browse/FELIX-5664
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-3.4.2
>Reporter: Antoine DESSAIGNE
>Assignee: Carsten Ziegeler
> Fix For: http.jetty-3.4.4
>
>
> The current http.jetty version uses Jetty 9.3.15.v20161220 which is sensitive 
> to CVE-2017-9735, see:
> * https://nvd.nist.gov/vuln/detail/CVE-2017-9735
> * https://github.com/eclipse/jetty.project/issues/1556
> The CVE fix has been released in Jetty 9.3.20.v20170531 or 9.4.6.v20170531, 
> so http.jetty need to be updated.



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

[jira] [Updated] (FELIX-5664) Update Jetty to 9.3.20.v20170531 or 9.4.6.v20170531 to fix CVE-2017-9735

[Antoine DESSAIGNE (JIRA)]

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

Antoine DESSAIGNE updated FELIX-5664:
-
Description: 
The current http.jetty version uses Jetty 9.3.15.v20161220 which is sensitive 
to CVE-2017-9735, see:
* https://nvd.nist.gov/vuln/detail/CVE-2017-9735
* https://github.com/eclipse/jetty.project/issues/1556

The CVE fix has been released in Jetty 9.3.20.v20170531 or 9.4.6.v20170531, so 
http.jetty need to be updated.

  was:
The current http.jetty version uses Jetty 9.3.15.v20161220 which is sensitive 
to CVE-2017-9735, see:
* https://nvd.nist.gov/vuln/detail/CVE-2017-9735
* https://github.com/eclipse/jetty.project/issues/1556

The CVE fix has been released in Jetty 9.4.6.v20170531, so http.jetty need to 
be updated.

Summary: Update Jetty to 9.3.20.v20170531 or 9.4.6.v20170531 to fix 
CVE-2017-9735  (was: Update Jetty to 9.4.6.v20170531 to fix CVE-2017-9735)

> Update Jetty to 9.3.20.v20170531 or 9.4.6.v20170531 to fix CVE-2017-9735
> 
>
> Key: FELIX-5664
> URL: https://issues.apache.org/jira/browse/FELIX-5664
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-3.4.2
>Reporter: Antoine DESSAIGNE
>
> The current http.jetty version uses Jetty 9.3.15.v20161220 which is sensitive 
> to CVE-2017-9735, see:
> * https://nvd.nist.gov/vuln/detail/CVE-2017-9735
> * https://github.com/eclipse/jetty.project/issues/1556
> The CVE fix has been released in Jetty 9.3.20.v20170531 or 9.4.6.v20170531, 
> so http.jetty need to be updated.



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

[jira] [Created] (FELIX-5664) Update Jetty to 9.4.6.v20170531 to fix CVE-2017-9735

[Antoine DESSAIGNE (JIRA)]

Antoine DESSAIGNE created FELIX-5664:


 Summary: Update Jetty to 9.4.6.v20170531 to fix CVE-2017-9735
 Key: FELIX-5664
 URL: https://issues.apache.org/jira/browse/FELIX-5664
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http.jetty-3.4.2
Reporter: Antoine DESSAIGNE


The current http.jetty version uses Jetty 9.3.15.v20161220 which is sensitive 
to CVE-2017-9735, see:
* https://nvd.nist.gov/vuln/detail/CVE-2017-9735
* https://github.com/eclipse/jetty.project/issues/1556

The CVE fix has been released in Jetty 9.4.6.v20170531, so http.jetty need to 
be updated.



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

[jira] [Created] (FELIX-5511) gogo runtime - Exception with a command named "?"

[Antoine DESSAIGNE (JIRA)]

Antoine DESSAIGNE created FELIX-5511:


 Summary: gogo runtime - Exception with a command named "?"
 Key: FELIX-5511
 URL: https://issues.apache.org/jira/browse/FELIX-5511
 Project: Felix
  Issue Type: Bug
  Components: Gogo Runtime
Affects Versions: gogo.runtime-1.0.0
Reporter: Antoine DESSAIGNE


Hello.

We currently use gogo runtime 0.16.2 and we have a command named "?" (fullname 
is "platform:?"), it's working fine.

I tried the update to version 1.0.0 and I have an exception when I try to use 
this command
{noformat}
java.io.IOException: no matches found: ?
at 
org.apache.felix.gogo.runtime.Expander.generateFileNames(Expander.java:650)
at org.apache.felix.gogo.runtime.Expander.expand(Expander.java:132)
at org.apache.felix.gogo.runtime.Expander.expand(Expander.java:74)
at org.apache.felix.gogo.runtime.Expander.expand(Expander.java:59)
at org.apache.felix.gogo.runtime.Closure.eval(Closure.java:354)
at 
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:415)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:367)
at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417)
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}

I can provide a pull request for it but I don't know how to fix it. One 
possible way is to not try to match file names when processing the first token. 
Would work in my case because it's the command but it may introduce lots of 
regression for other usages I'm not aware of.

Thank you very much for any help you can provide.



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

[jira] [Commented] (FELIX-4981) [Jetty] Change default behaviour of sendServerHeader from true to false

[Antoine DESSAIGNE (JIRA)]

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

Antoine DESSAIGNE commented on FELIX-4981:
--

Thanks a lot, that was fast !

> [Jetty] Change default behaviour of sendServerHeader from true to false
> ---
>
> Key: FELIX-4981
> URL: https://issues.apache.org/jira/browse/FELIX-4981
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-3.0.2
>Reporter: Adrien PAILHES
>Assignee: Carsten Ziegeler
> Fix For: http.jetty-3.1.0
>
>
> According to 
> http://felix.apache.org/documentation/subprojects/apache-felix-http-service.html#configuration-properties,
>  org.apache.felix.http.jetty.sendServerHeader default value is "false".
> In fact, if you look the code, it's "true".
> See org.apache.felix.http.jetty.internal.JettyConfig#isSendServerHeader on 
> the trunk:
> {code}
> public boolean isSendServerHeader()
> {
> return getBooleanProperty(FELIX_JETTY_SEND_SERVER_HEADER, true);
> }
> {code}
> Can we just set "false" as documented?



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

[jira] [Commented] (FELIX-4981) [Jetty] sendServerHeader default value is true instead of false as documented

[Antoine DESSAIGNE (JIRA)]

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

Antoine DESSAIGNE commented on FELIX-4981:
--

Hi,

Since it's nowadays considered as a security issue to send back those headers, 
it's not better to prevent from sending them by default ?

Thanks a lot.

> [Jetty] sendServerHeader default value is true instead of false as documented
> -
>
> Key: FELIX-4981
> URL: https://issues.apache.org/jira/browse/FELIX-4981
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-3.0.2
>Reporter: Adrien PAILHES
>Assignee: Carsten Ziegeler
> Fix For: http.jetty-3.1.0
>
>
> According to 
> http://felix.apache.org/documentation/subprojects/apache-felix-http-service.html#configuration-properties,
>  org.apache.felix.http.jetty.sendServerHeader default value is "false".
> In fact, if you look the code, it's "true".
> See org.apache.felix.http.jetty.internal.JettyConfig#isSendServerHeader on 
> the trunk:
> {code}
> public boolean isSendServerHeader()
> {
> return getBooleanProperty(FELIX_JETTY_SEND_SERVER_HEADER, true);
> }
> {code}
> Can we just set "false" as documented?



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