[jira] [Commented] (FELIX-6729) Infinite recursion observed with Felix Main and Felix Framework jar usage
[ https://issues.apache.org/jira/browse/FELIX-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888066#comment-17888066 ] Karl Pauls commented on FELIX-6729: --- Finally, the url handlers are using a shortcut if there is only one framework instance around at a time. So assuming you have nothing else in the stack that uses Felix as well, it seems like you are somehow starting a new framework before the old one has shutdown. Is it possible that you are not stopping the framework on a redeploy and as a consequence have more than on framework active? If so, you might want to try to make sure you have the old framework shutdown before the new one gets started. That might already be enough. > Infinite recursion observed with Felix Main and Felix Framework jar usage > - > > Key: FELIX-6729 > URL: https://issues.apache.org/jira/browse/FELIX-6729 > Project: Felix > Issue Type: Bug > Components: Framework, Main >Affects Versions: framework-7.0.5 > Environment: Oracle WebLogic on which Custom Plugin applications have > been deployed which uses the "org.apache.felix.org.apache.felix.main.jar" and > "org.apache.felix.framework.jar" jar as 3rd party references for OSGi > implementation. > Operating System : Oracle Linux >Reporter: Mahesh Kantharaj >Priority: Blocker > Fix For: framework-7.0.5 > > Original Estimate: 168h > Remaining Estimate: 168h > > The Custom Plugin which references the > "org.apache.felix.org.apache.felix.main.jar" and > "org.apache.felix.framework.jar" 3rd Party jars is deployed on WLS (Oracle > WebLogic Server). The Felix Framework jar is used in the Custom Plugin to > enable the plugin to interact with the OAM (Oracle Access Manager) system > wherein it helps in integrating the custom plugin with the OAM seamlessly and > efficiently. > However there is an intermittent issue that is observed during the > initialization phase (Deployed Server restart) of the custom plugin wherein > repeated looping is observed with the below mentioned stack upon > java.net.URL usage. > This results in Stack Over Exception with an abnormal compressed class space > growth that eventually leads to Out of Memory exception and thereby the JVM > crashes. The only workaround available with us now is to perform the Server > restart on which the custom plugin is deployed so that the Full GC is > triggered and thereby the compressed class space is cleared as a temporary > relief to the issue. We would like to have the URL Handler related looping > stack from Felix Main and Framework to be investigated to devise a solution > from Apache team, to resolve the issue (This seems to be a race condition > scenario based on issue symptoms). > at > org.apache.felix.framework.util.SecureAction.getDeclaredMethod(SecureAction.java:850) > at > org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:752) > at > org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574) > at > org.apache.felix.framework.URLHandlersStreamHandlerProxy.parseURL(URLHandlersStreamHandlerProxy.java:369) > at java.net.URL.(URL.java:639) > at java.net.URL.(URL.java:507) > ** > The complete stack trace having the deep recursive call related to Felix jar > is pasted below for your reference: > Thread [ACTIVE] ExecuteThread: '37' for queue: > 'weblogic.kernel.Default (self-tuning)' Defining > org.osgi.service.packageadmin.ExportedPackage from > file:/p01/app/oracle/oam12c/wlserver/server/lib/org.apache.felix.org.apache.felix.main.jar > in 'weblogic-launcher' > java.lang.Exception > at > sun.misc.URLClassPath$FileLoader.getResource(URLClassPath.java:1340) > at sun.misc.URLClassPath.getResource(URLClassPath.java:250) > at java.net.URLClassLoader$1.run(URLClassLoader.java:366) > at java.net.URLClassLoader$1.run(URLClassLoader.java:363) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:362) > at java.lang.ClassLoader.loadClass(ClassLoader.java:418) > at java.lang.ClassLoader.loadClass(ClassLoader.java:351) > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2701) > at java.lang.Class.getDeclaredMethod(Class.java:2128) > at > org.apache.felix.framework.util.SecureAction.getDeclaredMethod(SecureAction.java:850) > at > org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:752) > at > org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerSe
[jira] [Commented] (FELIX-6729) Infinite recursion observed with Felix Main and Felix Framework jar usage
[
https://issues.apache.org/jira/browse/FELIX-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888065#comment-17888065
]
Karl Pauls commented on FELIX-6729:
---
Can you share the stack trace with the stack overflow exception in 7.0.5? What
you provided there doesn't show a recursion. Additionally, what is the problem
you are observing that is caused be the exception (other than the exception
itself)?
Wrt. the disabling, I'm not sure why you are trying to do it via the config - I
suppose it depends on how you are launching the framework but you can just pass
framework properties to it:
https://docs.osgi.org/specification/osgi.core/8.0.0/framework.lifecycle.html#framework.lifecycle.launchingproperties
If you need todo it via the jars, I'm confused as IIRC, neither the framework
nor the main jar contain any of the places you mention
("config/config.properties", "classes/config.properties",
"resources/config.properties"). The main jar has an embedded config.properties
but in the root (and an additional default.properties in the root as well).
> Infinite recursion observed with Felix Main and Felix Framework jar usage
> -
>
> Key: FELIX-6729
> URL: https://issues.apache.org/jira/browse/FELIX-6729
> Project: Felix
> Issue Type: Bug
> Components: Framework, Main
>Affects Versions: framework-7.0.5
> Environment: Oracle WebLogic on which Custom Plugin applications have
> been deployed which uses the "org.apache.felix.org.apache.felix.main.jar" and
> "org.apache.felix.framework.jar" jar as 3rd party references for OSGi
> implementation.
> Operating System : Oracle Linux
>Reporter: Mahesh Kantharaj
>Priority: Blocker
> Fix For: framework-7.0.5
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> The Custom Plugin which references the
> "org.apache.felix.org.apache.felix.main.jar" and
> "org.apache.felix.framework.jar" 3rd Party jars is deployed on WLS (Oracle
> WebLogic Server). The Felix Framework jar is used in the Custom Plugin to
> enable the plugin to interact with the OAM (Oracle Access Manager) system
> wherein it helps in integrating the custom plugin with the OAM seamlessly and
> efficiently.
> However there is an intermittent issue that is observed during the
> initialization phase (Deployed Server restart) of the custom plugin wherein
> repeated looping is observed with the below mentioned stack upon
> java.net.URL usage.
> This results in Stack Over Exception with an abnormal compressed class space
> growth that eventually leads to Out of Memory exception and thereby the JVM
> crashes. The only workaround available with us now is to perform the Server
> restart on which the custom plugin is deployed so that the Full GC is
> triggered and thereby the compressed class space is cleared as a temporary
> relief to the issue. We would like to have the URL Handler related looping
> stack from Felix Main and Framework to be investigated to devise a solution
> from Apache team, to resolve the issue (This seems to be a race condition
> scenario based on issue symptoms).
> at
> org.apache.felix.framework.util.SecureAction.getDeclaredMethod(SecureAction.java:850)
> at
> org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:752)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.parseURL(URLHandlersStreamHandlerProxy.java:369)
> at java.net.URL.(URL.java:639)
> at java.net.URL.(URL.java:507)
> **
> The complete stack trace having the deep recursive call related to Felix jar
> is pasted below for your reference:
> Thread [ACTIVE] ExecuteThread: '37' for queue:
> 'weblogic.kernel.Default (self-tuning)' Defining
> org.osgi.service.packageadmin.ExportedPackage from
> file:/p01/app/oracle/oam12c/wlserver/server/lib/org.apache.felix.org.apache.felix.main.jar
> in 'weblogic-launcher'
> java.lang.Exception
> at
> sun.misc.URLClassPath$FileLoader.getResource(URLClassPath.java:1340)
> at sun.misc.URLClassPath.getResource(URLClassPath.java:250)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.
[jira] [Commented] (FELIX-6729) Infinite recursion observed with Felix Main and Felix Framework jar usage
[ https://issues.apache.org/jira/browse/FELIX-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887614#comment-17887614 ] Karl Pauls commented on FELIX-6729: --- Hi [~mahesh.kantharaj], to disable the url handlers you have to pass the property to the framework via the framework properties. As mentioned in the documentation, that is not a system property but needs to be done via the framework properties. Regardless, I'm not 100% sure I read the situation the same way. It seems like with 7.0.5 you don't get an infinite recursion anymore but somehow get an exception. However, I would have thought that exception is just caught and shouldn't necessarily do harm. Can you see if you get something on stdout regarding this exception and describe what is breaking? Additionally, what java/jdk are you on (I assume there is no easy way for me to reproduce this, right)? > Infinite recursion observed with Felix Main and Felix Framework jar usage > - > > Key: FELIX-6729 > URL: https://issues.apache.org/jira/browse/FELIX-6729 > Project: Felix > Issue Type: Bug > Components: Framework, Main >Affects Versions: framework-7.0.5 > Environment: Oracle WebLogic on which Custom Plugin applications have > been deployed which uses the "org.apache.felix.org.apache.felix.main.jar" and > "org.apache.felix.framework.jar" jar as 3rd party references for OSGi > implementation. > Operating System : Oracle Linux >Reporter: Mahesh Kantharaj >Priority: Blocker > Fix For: framework-7.0.5 > > Original Estimate: 168h > Remaining Estimate: 168h > > The Custom Plugin which references the > "org.apache.felix.org.apache.felix.main.jar" and > "org.apache.felix.framework.jar" 3rd Party jars is deployed on WLS (Oracle > WebLogic Server). The Felix Framework jar is used in the Custom Plugin to > enable the plugin to interact with the OAM (Oracle Access Manager) system > wherein it helps in integrating the custom plugin with the OAM seamlessly and > efficiently. > However there is an intermittent issue that is observed during the > initialization phase (Deployed Server restart) of the custom plugin wherein > repeated looping is observed with the below mentioned stack upon > java.net.URL usage. > This results in Stack Over Exception with an abnormal compressed class space > growth that eventually leads to Out of Memory exception and thereby the JVM > crashes. The only workaround available with us now is to perform the Server > restart on which the custom plugin is deployed so that the Full GC is > triggered and thereby the compressed class space is cleared as a temporary > relief to the issue. We would like to have the URL Handler related looping > stack from Felix Main and Framework to be investigated to devise a solution > from Apache team, to resolve the issue (This seems to be a race condition > scenario based on issue symptoms). > at > org.apache.felix.framework.util.SecureAction.getDeclaredMethod(SecureAction.java:850) > at > org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:752) > at > org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574) > at > org.apache.felix.framework.URLHandlersStreamHandlerProxy.parseURL(URLHandlersStreamHandlerProxy.java:369) > at java.net.URL.(URL.java:639) > at java.net.URL.(URL.java:507) > ** > The complete stack trace having the deep recursive call related to Felix jar > is pasted below for your reference: > Thread [ACTIVE] ExecuteThread: '37' for queue: > 'weblogic.kernel.Default (self-tuning)' Defining > org.osgi.service.packageadmin.ExportedPackage from > file:/p01/app/oracle/oam12c/wlserver/server/lib/org.apache.felix.org.apache.felix.main.jar > in 'weblogic-launcher' > java.lang.Exception > at > sun.misc.URLClassPath$FileLoader.getResource(URLClassPath.java:1340) > at sun.misc.URLClassPath.getResource(URLClassPath.java:250) > at java.net.URLClassLoader$1.run(URLClassLoader.java:366) > at java.net.URLClassLoader$1.run(URLClassLoader.java:363) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:362) > at java.lang.ClassLoader.loadClass(ClassLoader.java:418) > at java.lang.ClassLoader.loadClass(ClassLoader.java:351) > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2701) > at java.lang.Class.getDeclaredMethod(Class.java:2128) > at > org.apache.felix.framework.util.SecureAction.getDeclaredMethod(SecureAction.java:850) > at
[jira] [Commented] (FELIX-6729) Repeated Looping observed with Felix Main and Felix Framework jar usage
[ https://issues.apache.org/jira/browse/FELIX-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886406#comment-17886406 ] Karl Pauls commented on FELIX-6729: --- Additionally, it sounds strange that they would have both, framework and main on the class path. The main jar does contain the framework already so it shouldn't be needed to have both on the class path. Regardless, I don't think that is the issue but it might be related as judging by the stack trace, you are not using 7.0.5 but <=6.0.4. The URLHandlers have been reworked quite a bit since then - can you please try to identify where <=6.0.4 comes into the mix (as the URLHandlers are shared, it could be anything in the JVM) and see if updating to 7.0.5 helps? > Repeated Looping observed with Felix Main and Felix Framework jar usage > --- > > Key: FELIX-6729 > URL: https://issues.apache.org/jira/browse/FELIX-6729 > Project: Felix > Issue Type: Bug > Components: Framework, Main >Affects Versions: framework-7.0.5 > Environment: Oracle WebLogic on which Custom Plugin applications have > been deployed which uses the "org.apache.felix.org.apache.felix.main.jar" and > "org.apache.felix.framework.jar" jar as 3rd party references for OSGi > implementation. > Operating System : Oracle Linux >Reporter: Mahesh Kantharaj >Priority: Blocker > Fix For: framework-7.0.5 > > Original Estimate: 168h > Remaining Estimate: 168h > > The Custom Plugin which references the > "org.apache.felix.org.apache.felix.main.jar" and > "org.apache.felix.framework.jar" 3rd Party jars is deployed on WLS (Oracle > WebLogic Server). The Felix Framework jar is used in the Custom Plugin to > enable the plugin to interact with the OAM (Oracle Access Manager) system > wherein it helps in integrating the custom plugin with the OAM seamlessly and > efficiently. > However there is an intermittent issue that is observed during the > initialization phase (Deployed Server restart) of the custom plugin wherein > repeated looping is observed 3ith the below mentioned stack upon > java.net.URL usage. > This results in Stack Over Exception with an abnormal compressed class space > growth that eventually leads to Out of Memory exception and thereby the JVM > crashes. The only workaround available with us now is to perform the Server > restart on which the custom plugin is deployed so that the Full GC is > triggered and thereby the compressed class space is cleared as a temporary > relief to the issue. We would like to have the URL Handler related looping > stack from Felix Main and Framework to be investigated to devise a solution > from Apache team, to resolve the issue (This seems to be a race condition > scenario based on issue symptoms). > at > org.apache.felix.framework.util.SecureAction.getDeclaredMethod(SecureAction.java:850) > at > org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:752) > at > org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574) > at > org.apache.felix.framework.URLHandlersStreamHandlerProxy.parseURL(URLHandlersStreamHandlerProxy.java:369) > at java.net.URL.(URL.java:639) > at java.net.URL.(URL.java:507) > ** > The complete stack trace having the deep recursive call related to Felix jar > is pasted below for your reference: > Thread [ACTIVE] ExecuteThread: '37' for queue: > 'weblogic.kernel.Default (self-tuning)' Defining > org.osgi.service.packageadmin.ExportedPackage from > file:/p01/app/oracle/oam12c/wlserver/server/lib/org.apache.felix.org.apache.felix.main.jar > in 'weblogic-launcher' > java.lang.Exception > at > sun.misc.URLClassPath$FileLoader.getResource(URLClassPath.java:1340) > at sun.misc.URLClassPath.getResource(URLClassPath.java:250) > at java.net.URLClassLoader$1.run(URLClassLoader.java:366) > at java.net.URLClassLoader$1.run(URLClassLoader.java:363) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:362) > at java.lang.ClassLoader.loadClass(ClassLoader.java:418) > at java.lang.ClassLoader.loadClass(ClassLoader.java:351) > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2701) > at java.lang.Class.getDeclaredMethod(Class.java:2128) > at > org.apache.felix.framework.util.SecureAction.getDeclaredMethod(SecureAction.java:850) > at > org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:752) > at > org.apache.felix.framework.URLHandlersStreamHa
[jira] [Commented] (FELIX-6729) Repeated Looping observed with Felix Main and Felix Framework jar usage
[ https://issues.apache.org/jira/browse/FELIX-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886403#comment-17886403 ] Karl Pauls commented on FELIX-6729: --- You could try to disable the url handlers (by setting felix.service.urlhandlers=false). > Repeated Looping observed with Felix Main and Felix Framework jar usage > --- > > Key: FELIX-6729 > URL: https://issues.apache.org/jira/browse/FELIX-6729 > Project: Felix > Issue Type: Bug > Components: Framework, Main >Affects Versions: framework-7.0.5 > Environment: Oracle WebLogic on which Custom Plugin applications have > been deployed which uses the "org.apache.felix.org.apache.felix.main.jar" and > "org.apache.felix.framework.jar" jar as 3rd party references for OSGi > implementation. > Operating System : Oracle Linux >Reporter: Mahesh Kantharaj >Priority: Blocker > Fix For: framework-7.0.5 > > Original Estimate: 168h > Remaining Estimate: 168h > > The Custom Plugin which references the > "org.apache.felix.org.apache.felix.main.jar" and > "org.apache.felix.framework.jar" 3rd Party jars is deployed on WLS (Oracle > WebLogic Server). The Felix Framework jar is used in the Custom Plugin to > enable the plugin to interact with the OAM (Oracle Access Manager) system > wherein it helps in integrating the custom plugin with the OAM seamlessly and > efficiently. > However there is an intermittent issue that is observed during the > initialization phase (Deployed Server restart) of the custom plugin wherein > repeated looping is observed 3ith the below mentioned stack upon > java.net.URL usage. > This results in Stack Over Exception with an abnormal compressed class space > growth that eventually leads to Out of Memory exception and thereby the JVM > crashes. The only workaround available with us now is to perform the Server > restart on which the custom plugin is deployed so that the Full GC is > triggered and thereby the compressed class space is cleared as a temporary > relief to the issue. We would like to have the URL Handler related looping > stack from Felix Main and Framework to be investigated to devise a solution > from Apache team, to resolve the issue (This seems to be a race condition > scenario based on issue symptoms). > at > org.apache.felix.framework.util.SecureAction.getDeclaredMethod(SecureAction.java:850) > at > org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:752) > at > org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574) > at > org.apache.felix.framework.URLHandlersStreamHandlerProxy.parseURL(URLHandlersStreamHandlerProxy.java:369) > at java.net.URL.(URL.java:639) > at java.net.URL.(URL.java:507) > ** > The complete stack trace having the deep recursive call related to Felix jar > is pasted below for your reference: > Thread [ACTIVE] ExecuteThread: '37' for queue: > 'weblogic.kernel.Default (self-tuning)' Defining > org.osgi.service.packageadmin.ExportedPackage from > file:/p01/app/oracle/oam12c/wlserver/server/lib/org.apache.felix.org.apache.felix.main.jar > in 'weblogic-launcher' > java.lang.Exception > at > sun.misc.URLClassPath$FileLoader.getResource(URLClassPath.java:1340) > at sun.misc.URLClassPath.getResource(URLClassPath.java:250) > at java.net.URLClassLoader$1.run(URLClassLoader.java:366) > at java.net.URLClassLoader$1.run(URLClassLoader.java:363) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:362) > at java.lang.ClassLoader.loadClass(ClassLoader.java:418) > at java.lang.ClassLoader.loadClass(ClassLoader.java:351) > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2701) > at java.lang.Class.getDeclaredMethod(Class.java:2128) > at > org.apache.felix.framework.util.SecureAction.getDeclaredMethod(SecureAction.java:850) > at > org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:752) > at > org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574) > at > org.apache.felix.framework.URLHandlersStreamHandlerProxy.parseURL(URLHandlersStreamHandlerProxy.java:369) > at java.net.URL.(URL.java:639) > at java.net.URL.(URL.java:507) > at > sun.misc.URLClassPath$FileLoader.getResource(URLClassPath.java:1340) > at sun.misc.URLClassPath.getResource(URLClassPath.java:250) > at java.net.URLClassLoader$1.run(URLC
[jira] [Updated] (FELIX-6664) Comment Removing on JSONSupport MemoryInefficient
[
https://issues.apache.org/jira/browse/FELIX-6664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-6664:
--
Fix Version/s: cm.json-2.0.2
> Comment Removing on JSONSupport MemoryInefficient
> -
>
> Key: FELIX-6664
> URL: https://issues.apache.org/jira/browse/FELIX-6664
> Project: Felix
> Issue Type: Improvement
>Affects Versions: cm.json-2.0.0
>Reporter: Dominik Süß
>Priority: Major
> Fix For: cm.json-2.0.2
>
>
> While using JSONSupport in Context of the Sling Featurelauncher we recently
> stumbled over an OOM exception related to how JSONSupport handles removal of
> comments:
> {code}
> java.lang.OutOfMemoryError: Java heap space
> at java.base/java.util.Arrays.copyOfRange(Arrays.java:4030)
> at java.base/java.lang.StringUTF16.newString(StringUTF16.java:1025)
> at java.base/java.lang.StringBuilder.toString(StringBuilder.java:454)
> at
> org.apache.felix.cm.json.io.impl.JsonSupport.removeComments(JsonSupport.java:308)
> at
> org.apache.felix.cm.json.io.impl.JsonSupport.createCommentRemovingReader(JsonSupport.java:244)
> at
> org.apache.felix.cm.json.io.Configurations.jsonCommentAwareReader(Configurations.java:70)
> at
> org.apache.sling.feature.io.json.FeatureJSONReader.readFeature(FeatureJSONReader.java:676)
> {code}
> https://github.com/apache/felix-dev/blob/91432d1a3f08520d5eb75b5c8e3443bb75f7c467/cm.json/src/main/java/org/apache/felix/cm/json/io/impl/JsonSupport.java#L233-L257
> The code does use a StringWriter to create a full String representation of
> the featuremodel and then acts on that model. As this featuremodel can
> contain a lot of metadata in comments those can get a significant size and
> when being used in a resource constrained environment can lead to memory
> issues.
> I prepared a patch that doesn't touch the removal logic but simply creates a
> custom BufferedReader that performs the removal on read and therefore
> eliminates the most prominent area for resource optimization.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (FELIX-6591) Memory leak in Felix Framework Security extension
[
https://issues.apache.org/jira/browse/FELIX-6591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls closed FELIX-6591.
-
Released
> Memory leak in Felix Framework Security extension
> -
>
> Key: FELIX-6591
> URL: https://issues.apache.org/jira/browse/FELIX-6591
> Project: Felix
> Issue Type: Bug
> Components: Framework Security
>Affects Versions: framework.security-2.8.3
>Reporter: Chris Rankin
>Assignee: Karl Pauls
>Priority: Major
> Labels: MemoryLeak, memory-leak
> Fix For: framework.security-2.8.4
>
>
> Our project loads and unloads a lot of bundles over time, and we have noticed
> that the JVM quickly spends the majority of its time collecting its garbage.
> We have identified the Framework Security extension as one source of this
> problem. Specifically, the suspiciously large number of {{Conditions}} and
> {{Permissions}} objects in every heap dump.
> The {{Permissions}} objects are _definitely_ leaking because
> {{Permission.Entry.hashCode()}} should use {{Arrays.hashCode(entry)}} instead
> of {{entry.hashCode()}} when {{entry}} is an array.
> I have also reimplemented {{Conditions}} to listen for
> {{BundleEvent.UNINSTALLED}} instead of relying on multiple
> {{{}WeakHashMap{}}}s. This is consistent with a TODO comment for this class,
> and allows the {{Conditions}} objects to be deleted _immediately_ instead of
> waiting for the garbage collector to realise that they are no longer
> referenced.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (FELIX-6591) Memory leak in Felix Framework Security extension
[
https://issues.apache.org/jira/browse/FELIX-6591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved FELIX-6591.
---
Fix Version/s: framework.security-2.8.4
Resolution: Fixed
I applied the PR - thanks a lot.
> Memory leak in Felix Framework Security extension
> -
>
> Key: FELIX-6591
> URL: https://issues.apache.org/jira/browse/FELIX-6591
> Project: Felix
> Issue Type: Bug
> Components: Framework Security
>Affects Versions: framework.security-2.8.3
>Reporter: Chris Rankin
>Assignee: Karl Pauls
>Priority: Major
> Labels: MemoryLeak, memory-leak
> Fix For: framework.security-2.8.4
>
>
> Our project loads and unloads a lot of bundles over time, and we have noticed
> that the JVM quickly spends the majority of its time collecting its garbage.
> We have identified the Framework Security extension as one source of this
> problem. Specifically, the suspiciously large number of {{Conditions}} and
> {{Permissions}} objects in every heap dump.
> The {{Permissions}} objects are _definitely_ leaking because
> {{Permission.Entry.hashCode()}} should use {{Arrays.hashCode(entry)}} instead
> of {{entry.hashCode()}} when {{entry}} is an array.
> I have also reimplemented {{Conditions}} to listen for
> {{BundleEvent.UNINSTALLED}} instead of relying on multiple
> {{{}WeakHashMap{}}}s. This is consistent with a TODO comment for this class,
> and allows the {{Conditions}} objects to be deleted _immediately_ instead of
> waiting for the garbage collector to realise that they are no longer
> referenced.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (FELIX-6591) Memory leak in Felix Framework Security extension
[
https://issues.apache.org/jira/browse/FELIX-6591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reassigned FELIX-6591:
-
Assignee: Karl Pauls
> Memory leak in Felix Framework Security extension
> -
>
> Key: FELIX-6591
> URL: https://issues.apache.org/jira/browse/FELIX-6591
> Project: Felix
> Issue Type: Bug
> Components: Framework Security
>Affects Versions: framework.security-2.8.3
>Reporter: Chris Rankin
>Assignee: Karl Pauls
>Priority: Major
> Labels: MemoryLeak, memory-leak
>
> Our project loads and unloads a lot of bundles over time, and we have noticed
> that the JVM quickly spends the majority of its time collecting its garbage.
> We have identified the Framework Security extension as one source of this
> problem. Specifically, the suspiciously large number of {{Conditions}} and
> {{Permissions}} objects in every heap dump.
> The {{Permissions}} objects are _definitely_ leaking because
> {{Permission.Entry.hashCode()}} should use {{Arrays.hashCode(entry)}} instead
> of {{entry.hashCode()}} when {{entry}} is an array.
> I have also reimplemented {{Conditions}} to listen for
> {{BundleEvent.UNINSTALLED}} instead of relying on multiple
> {{{}WeakHashMap{}}}s. This is consistent with a TODO comment for this class,
> and allows the {{Conditions}} objects to be deleted _immediately_ instead of
> waiting for the garbage collector to realise that they are no longer
> referenced.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (FELIX-6536) DirectoryRevision causes java.io.IOException: File outside the root on windows
[ https://issues.apache.org/jira/browse/FELIX-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed FELIX-6536. - > DirectoryRevision causes java.io.IOException: File outside the root on windows > -- > > Key: FELIX-6536 > URL: https://issues.apache.org/jira/browse/FELIX-6536 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-7.0.4 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.5 > > > When exploded bundles are used, the resulting DirectoryRevision is not > normalizing the path correctly on windows and as a consequence, throws > java.io.IOException: File outside the root -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (FELIX-6536) DirectoryRevision causes java.io.IOException: File outside the root on windows
[ https://issues.apache.org/jira/browse/FELIX-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved FELIX-6536. --- Resolution: Fixed Fixed in https://github.com/apache/felix-dev/pull/155. Thanks to [~chadwilson] for finding and reporting this. > DirectoryRevision causes java.io.IOException: File outside the root on windows > -- > > Key: FELIX-6536 > URL: https://issues.apache.org/jira/browse/FELIX-6536 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-7.0.4 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.5 > > > When exploded bundles are used, the resulting DirectoryRevision is not > normalizing the path correctly on windows and as a consequence, throws > java.io.IOException: File outside the root -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (FELIX-6536) DirectoryRevision causes java.io.IOException: File outside the root on windows
Karl Pauls created FELIX-6536: - Summary: DirectoryRevision causes java.io.IOException: File outside the root on windows Key: FELIX-6536 URL: https://issues.apache.org/jira/browse/FELIX-6536 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-7.0.4 Reporter: Karl Pauls Assignee: Karl Pauls Fix For: framework-7.0.5 When exploded bundles are used, the resulting DirectoryRevision is not normalizing the path correctly on windows and as a consequence, throws java.io.IOException: File outside the root -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (FELIX-6488) Optimize ServiceReference.isAssignableTo
[ https://issues.apache.org/jira/browse/FELIX-6488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated FELIX-6488: -- Fix Version/s: framework-7.0.6 (was: framework-7.0.5) > Optimize ServiceReference.isAssignableTo > > > Key: FELIX-6488 > URL: https://issues.apache.org/jira/browse/FELIX-6488 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-7.0.3 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.6 > > > The ServiceReference.isAssignableTo(Bundle bundle, String className) does > some complicated check to see if the service is assignable. This includes > trying to load classes and catching CNFE to see if providers and/or > requesters have access to the given class. > As that is done quite a bit (it is used in service event dispatching and > service lookup) it would be good to optimize this to either not throw CNFE > during the lookup or maybe at least cache the results to not have them be > done all the time. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (FELIX-6529) Improve memory usage ManifestParser using String deduplication
[ https://issues.apache.org/jira/browse/FELIX-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed FELIX-6529. - > Improve memory usage ManifestParser using String deduplication > -- > > Key: FELIX-6529 > URL: https://issues.apache.org/jira/browse/FELIX-6529 > Project: Felix > Issue Type: Improvement >Reporter: Johannes Edmeier >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.4 > > Attachments: ManifestParser.patch, image-2022-05-13-14-16-39-509.png, > image-2022-05-13-14-17-55-965.png > > > In my heap dump I've seen a lot of duplicate Strings produced by the > ManifestParser. > It creates a lot of equal strings for the keys in the manifest but doesn't > deduplicate them and they're hold forever producing a lot on retained heap. > I've patched the ManifestParser to deduplicate just the keys and could save > ~8 Megs of heap. > Total usage before: 38MB after: 30MB > Duplicated Strings before: > !image-2022-05-13-14-16-39-509.png|width=658,height=203! > Duplicated Strings after: > !image-2022-05-13-14-17-55-965.png|width=793,height=200! > See patch attached. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (FELIX-6534) System bundle findEntries returns entries in case of fragments
[ https://issues.apache.org/jira/browse/FELIX-6534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed FELIX-6534. - > System bundle findEntries returns entries in case of fragments > -- > > Key: FELIX-6534 > URL: https://issues.apache.org/jira/browse/FELIX-6534 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-7.0.3 >Reporter: Carsten Ziegeler >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.4 > > > According to > http://docs.osgi.org/specification/osgi.core/7.0.0/framework.api.html#org.osgi.framework.launch.Framework.findEntries-String-String-boolean- > findEntries on the system bundle should not return entries. > However, currently the implementation returns matching entries from extension > fragments. > But then trying to get such an entry via getEntry returns null (which seems > to be correct) > So findEntries should be changed to not return entries from extension > fragments -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (FELIX-6522) Empty name is not allowed in JDK17+
[ https://issues.apache.org/jira/browse/FELIX-6522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed FELIX-6522. - > Empty name is not allowed in JDK17+ > --- > > Key: FELIX-6522 > URL: https://issues.apache.org/jira/browse/FELIX-6522 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-7.0.3 >Reporter: David Matějček >Assignee: Karl Pauls >Priority: Blocker > Labels: patch-available, pull-request-available > Fix For: framework-7.0.4 > > Original Estimate: 1h > Remaining Estimate: 1h > > h3. Bug > When GlassFish enables the SecurityManager, it is unable to start on JDK17 > and JDK18, because BundleWiringImpl throws IAE. > h3. Cause > BasicPermission.init checks for an empty string since JDK17 (maybe earlier, > but in JDK11 did not). Some capabilities return an empty string (I did not > investigate which, I just saw the stacktrace in GlassFish). > CapabilityPermission constructor then crashes. > h5. Minor note > The SecurityManager feature is now deprecated in JDK and marked for removal, > so there should be some plan for Felix soon. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (FELIX-6535) Cleanup path handling in DirectoryContent
[ https://issues.apache.org/jira/browse/FELIX-6535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed FELIX-6535. - > Cleanup path handling in DirectoryContent > - > > Key: FELIX-6535 > URL: https://issues.apache.org/jira/browse/FELIX-6535 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-7.0.3 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.4 > > > The DirectoryContent path handling could be improved by using the canonical > path and cleaning up the exception handling. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (FELIX-6533) Felix released as milestone version cannot parse it's own version id
[ https://issues.apache.org/jira/browse/FELIX-6533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed FELIX-6533. - > Felix released as milestone version cannot parse it's own version id > > > Key: FELIX-6533 > URL: https://issues.apache.org/jira/browse/FELIX-6533 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-7.0.3 >Reporter: David Matějček >Assignee: Karl Pauls >Priority: Blocker > Labels: patch-available, patch-with-test > Fix For: framework-7.0.4 > > Original Estimate: 4h > Remaining Estimate: 4h > > We tried to prerelease a custom built version for GlassFish, but it it not > able to start now. The version id was 7.0.4-omnifish-M1; Felix changed it to > 7.0.4.omnifish.M1 on startup and then crashed, because dots are not allowed > in classifier. > h3. Cause > I found that it tries to "cleanup" the Maven version, but does it wrong and > then tries to parse the result again which fails. > *Solution* > I am creating PR right after this issue. Felix already has the correct > implementation usable for this, so I just moved it to the new > VersionConverter class, updated all references and also extended tests. It is > backward compatible despite the bit of refactoring. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (FELIX-6516) Remove synchronization on Integer in Felix Framework
[
https://issues.apache.org/jira/browse/FELIX-6516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls closed FELIX-6516.
-
> 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
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.4
>
>
> 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.7#820007)
[jira] [Commented] (FELIX-6529) Improve memory usage ManifestParser using String deduplication
[ https://issues.apache.org/jira/browse/FELIX-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17540889#comment-17540889 ] Karl Pauls commented on FELIX-6529: --- [~amitmondal], I might be wrong, but I don't see these being related to keys anymore. Maybe you could help in finding out where they come from (looks like at a minimum quite some are parsed filters) and open a new issue(s) for further optimizations. Additionally, for this issue, I would still be interested in the overall impact. You said that just interning the keys did save you 8mb in your use-case. What did you save with this fix? > Improve memory usage ManifestParser using String deduplication > -- > > Key: FELIX-6529 > URL: https://issues.apache.org/jira/browse/FELIX-6529 > Project: Felix > Issue Type: Improvement >Reporter: Johannes Edmeier >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.4 > > Attachments: ManifestParser.patch, image-2022-05-13-14-16-39-509.png, > image-2022-05-13-14-17-55-965.png > > > In my heap dump I've seen a lot of duplicate Strings produced by the > ManifestParser. > It creates a lot of equal strings for the keys in the manifest but doesn't > deduplicate them and they're hold forever producing a lot on retained heap. > I've patched the ManifestParser to deduplicate just the keys and could save > ~8 Megs of heap. > Total usage before: 38MB after: 30MB > Duplicated Strings before: > !image-2022-05-13-14-16-39-509.png|width=658,height=203! > Duplicated Strings after: > !image-2022-05-13-14-17-55-965.png|width=793,height=200! > See patch attached. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (FELIX-6535) Cleanup path handling in DirectoryContent
[ https://issues.apache.org/jira/browse/FELIX-6535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved FELIX-6535. --- Resolution: Fixed > Cleanup path handling in DirectoryContent > - > > Key: FELIX-6535 > URL: https://issues.apache.org/jira/browse/FELIX-6535 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-7.0.3 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.4 > > > The DirectoryContent path handling could be improved by using the canonical > path and cleaning up the exception handling. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (FELIX-6529) Improve memory usage ManifestParser using String deduplication
[
https://issues.apache.org/jira/browse/FELIX-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539842#comment-17539842
]
Karl Pauls commented on FELIX-6529:
---
[~amitmondal]:
I think you can just add it to your settings, something like:
{noformat}
apache.snapshots
Apache Development Snapshot Repository
https://repository.apache.org/content/repositories/snapshots/
false
true
{noformat}
> Improve memory usage ManifestParser using String deduplication
> --
>
> Key: FELIX-6529
> URL: https://issues.apache.org/jira/browse/FELIX-6529
> Project: Felix
> Issue Type: Improvement
>Reporter: Johannes Edmeier
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.4
>
> Attachments: ManifestParser.patch, image-2022-05-13-14-16-39-509.png,
> image-2022-05-13-14-17-55-965.png
>
>
> In my heap dump I've seen a lot of duplicate Strings produced by the
> ManifestParser.
> It creates a lot of equal strings for the keys in the manifest but doesn't
> deduplicate them and they're hold forever producing a lot on retained heap.
> I've patched the ManifestParser to deduplicate just the keys and could save
> ~8 Megs of heap.
> Total usage before: 38MB after: 30MB
> Duplicated Strings before:
> !image-2022-05-13-14-16-39-509.png|width=658,height=203!
> Duplicated Strings after:
> !image-2022-05-13-14-17-55-965.png|width=793,height=200!
> See patch attached.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (FELIX-6529) Improve memory usage ManifestParser using String deduplication
[ https://issues.apache.org/jira/browse/FELIX-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539837#comment-17539837 ] Karl Pauls commented on FELIX-6529: --- [~amitmondal] - thanks, I deployed a new 7.1.0-SNAPSHOT for now so maybe you could test that one already. Otherwise, I'm planning to cut 7.0.4 soon as well. > Improve memory usage ManifestParser using String deduplication > -- > > Key: FELIX-6529 > URL: https://issues.apache.org/jira/browse/FELIX-6529 > Project: Felix > Issue Type: Improvement >Reporter: Johannes Edmeier >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.4 > > Attachments: ManifestParser.patch, image-2022-05-13-14-16-39-509.png, > image-2022-05-13-14-17-55-965.png > > > In my heap dump I've seen a lot of duplicate Strings produced by the > ManifestParser. > It creates a lot of equal strings for the keys in the manifest but doesn't > deduplicate them and they're hold forever producing a lot on retained heap. > I've patched the ManifestParser to deduplicate just the keys and could save > ~8 Megs of heap. > Total usage before: 38MB after: 30MB > Duplicated Strings before: > !image-2022-05-13-14-16-39-509.png|width=658,height=203! > Duplicated Strings after: > !image-2022-05-13-14-17-55-965.png|width=793,height=200! > See patch attached. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (FELIX-6535) Cleanup path handling in DirectoryContent
[ https://issues.apache.org/jira/browse/FELIX-6535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated FELIX-6535: -- Description: The DirectoryContent path handling could be improved by using the canonical path and cleaning up the exception handling. (was: The DirectoryContent path handling could be improved by using the canonical path.) > Cleanup path handling in DirectoryContent > - > > Key: FELIX-6535 > URL: https://issues.apache.org/jira/browse/FELIX-6535 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-7.0.3 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.4 > > > The DirectoryContent path handling could be improved by using the canonical > path and cleaning up the exception handling. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (FELIX-6535) Cleanup path handling in DirectoryContent
Karl Pauls created FELIX-6535: - Summary: Cleanup path handling in DirectoryContent Key: FELIX-6535 URL: https://issues.apache.org/jira/browse/FELIX-6535 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-7.0.3 Reporter: Karl Pauls Assignee: Karl Pauls Fix For: framework-7.0.4 The DirectoryContent path handling could be improved by using the canonical path. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (FELIX-6516) Remove synchronization on Integer in Felix Framework
[
https://issues.apache.org/jira/browse/FELIX-6516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved FELIX-6516.
---
Resolution: Fixed
I applied the PR - thanks!
> 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
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.4
>
>
> 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.7#820007)
[jira] [Assigned] (FELIX-6516) Remove synchronization on Integer in Felix Framework
[
https://issues.apache.org/jira/browse/FELIX-6516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reassigned FELIX-6516:
-
Assignee: Karl Pauls (was: Jean-Baptiste Onofré)
> 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
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.4
>
>
> 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.7#820007)
[jira] [Resolved] (FELIX-6529) Improve memory usage ManifestParser using String deduplication
[ https://issues.apache.org/jira/browse/FELIX-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved FELIX-6529. --- Resolution: Fixed I merged my PR - [~amitmondal], I hope it helps in your case too (it does reduce memory usage for at least one example case I did). > Improve memory usage ManifestParser using String deduplication > -- > > Key: FELIX-6529 > URL: https://issues.apache.org/jira/browse/FELIX-6529 > Project: Felix > Issue Type: Improvement >Reporter: Johannes Edmeier >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.4 > > Attachments: ManifestParser.patch, image-2022-05-13-14-16-39-509.png, > image-2022-05-13-14-17-55-965.png > > > In my heap dump I've seen a lot of duplicate Strings produced by the > ManifestParser. > It creates a lot of equal strings for the keys in the manifest but doesn't > deduplicate them and they're hold forever producing a lot on retained heap. > I've patched the ManifestParser to deduplicate just the keys and could save > ~8 Megs of heap. > Total usage before: 38MB after: 30MB > Duplicated Strings before: > !image-2022-05-13-14-16-39-509.png|width=658,height=203! > Duplicated Strings after: > !image-2022-05-13-14-17-55-965.png|width=793,height=200! > See patch attached. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (FELIX-6488) Optimize ServiceReference.isAssignableTo
[ https://issues.apache.org/jira/browse/FELIX-6488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated FELIX-6488: -- Fix Version/s: framework-7.0.5 (was: framework-7.0.4) > Optimize ServiceReference.isAssignableTo > > > Key: FELIX-6488 > URL: https://issues.apache.org/jira/browse/FELIX-6488 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-7.0.3 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.5 > > > The ServiceReference.isAssignableTo(Bundle bundle, String className) does > some complicated check to see if the service is assignable. This includes > trying to load classes and catching CNFE to see if providers and/or > requesters have access to the given class. > As that is done quite a bit (it is used in service event dispatching and > service lookup) it would be good to optimize this to either not throw CNFE > during the lookup or maybe at least cache the results to not have them be > done all the time. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (FELIX-6533) Felix released as milestone version cannot parse it's own version id
[ https://issues.apache.org/jira/browse/FELIX-6533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved FELIX-6533. --- Resolution: Fixed Thanks, I merged the PR > Felix released as milestone version cannot parse it's own version id > > > Key: FELIX-6533 > URL: https://issues.apache.org/jira/browse/FELIX-6533 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-7.0.3 >Reporter: David Matějček >Assignee: Karl Pauls >Priority: Blocker > Labels: patch-available, patch-with-test > Fix For: framework-7.0.4 > > Original Estimate: 4h > Remaining Estimate: 4h > > We tried to prerelease a custom built version for GlassFish, but it it not > able to start now. The version id was 7.0.4-omnifish-M1; Felix changed it to > 7.0.4.omnifish.M1 on startup and then crashed, because dots are not allowed > in classifier. > h3. Cause > I found that it tries to "cleanup" the Maven version, but does it wrong and > then tries to parse the result again which fails. > *Solution* > I am creating PR right after this issue. Felix already has the correct > implementation usable for this, so I just moved it to the Version class > (which seems to be a natural place for this), updated all references and also > extended tests. It is backward compatible despite the bit of refactoring. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (FELIX-6534) System bundle findEntries returns entries in case of fragments
[ https://issues.apache.org/jira/browse/FELIX-6534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved FELIX-6534. --- Resolution: Fixed Fixed in https://github.com/apache/felix-dev/pull/153 > System bundle findEntries returns entries in case of fragments > -- > > Key: FELIX-6534 > URL: https://issues.apache.org/jira/browse/FELIX-6534 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-7.0.3 >Reporter: Carsten Ziegeler >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.4 > > > According to > http://docs.osgi.org/specification/osgi.core/7.0.0/framework.api.html#org.osgi.framework.launch.Framework.findEntries-String-String-boolean- > findEntries on the system bundle should not return entries. > However, currently the implementation returns matching entries from extension > fragments. > But then trying to get such an entry via getEntry returns null (which seems > to be correct) > So findEntries should be changed to not return entries from extension > fragments -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (FELIX-6534) System bundle findEntries returns entries in case of fragments
[ https://issues.apache.org/jira/browse/FELIX-6534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539549#comment-17539549 ] Karl Pauls commented on FELIX-6534: --- Yup, looks like a bug that got introduced when extensions started to have real fragment wires. > System bundle findEntries returns entries in case of fragments > -- > > Key: FELIX-6534 > URL: https://issues.apache.org/jira/browse/FELIX-6534 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-7.0.3 >Reporter: Carsten Ziegeler >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.4 > > > According to > http://docs.osgi.org/specification/osgi.core/7.0.0/framework.api.html#org.osgi.framework.launch.Framework.findEntries-String-String-boolean- > findEntries on the system bundle should not return entries. > However, currently the implementation returns matching entries from extension > fragments. > But then trying to get such an entry via getEntry returns null (which seems > to be correct) > So findEntries should be changed to not return entries from extension > fragments -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (FELIX-6534) System bundle findEntries returns entries in case of fragments
[ https://issues.apache.org/jira/browse/FELIX-6534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls reassigned FELIX-6534: - Assignee: Karl Pauls > System bundle findEntries returns entries in case of fragments > -- > > Key: FELIX-6534 > URL: https://issues.apache.org/jira/browse/FELIX-6534 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-7.0.3 >Reporter: Carsten Ziegeler >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.4 > > > According to > http://docs.osgi.org/specification/osgi.core/7.0.0/framework.api.html#org.osgi.framework.launch.Framework.findEntries-String-String-boolean- > findEntries on the system bundle should not return entries. > However, currently the implementation returns matching entries from extension > fragments. > But then trying to get such an entry via getEntry returns null (which seems > to be correct) > So findEntries should be changed to not return entries from extension > fragments -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (FELIX-6533) Felix released as milestone version cannot parse it's own version id
[ https://issues.apache.org/jira/browse/FELIX-6533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539548#comment-17539548 ] Karl Pauls commented on FELIX-6533: --- [~dmatej], I commented on the PR as well - however, could you maybe describe what the version is you have and how it goes wrong (just so that we have that covered in this issue). > Felix released as milestone version cannot parse it's own version id > > > Key: FELIX-6533 > URL: https://issues.apache.org/jira/browse/FELIX-6533 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-7.0.3 >Reporter: David Matějček >Assignee: Karl Pauls >Priority: Blocker > Labels: patch-available, patch-with-test > Fix For: framework-7.0.4 > > Original Estimate: 4h > Remaining Estimate: 4h > > We tried to prerelease a custom built version for GlassFish, but it it not > able to start now. > h3. Cause > I found that it tries to "cleanup" the Maven version, but does it wrong and > then tries to parse the result again which fails. > *Solution* > I am creating PR right after this issue. Felix already has the correct > implementation usable for this, so I just moved it to the Version class > (which seems to be a natural place for this), updated all references and also > extended tests. It is backward compatible despite the bit of refactoring. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (FELIX-6533) Felix released as milestone version cannot parse it's own version id
[ https://issues.apache.org/jira/browse/FELIX-6533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls reassigned FELIX-6533: - Assignee: Karl Pauls > Felix released as milestone version cannot parse it's own version id > > > Key: FELIX-6533 > URL: https://issues.apache.org/jira/browse/FELIX-6533 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-7.0.3 >Reporter: David Matějček >Assignee: Karl Pauls >Priority: Blocker > Labels: patch-available, patch-with-test > Fix For: framework-7.0.4 > > Original Estimate: 4h > Remaining Estimate: 4h > > We tried to prerelease a custom built version for GlassFish, but it it not > able to start now. > h3. Cause > I found that it tries to "cleanup" the Maven version, but does it wrong and > then tries to parse the result again which fails. > *Solution* > I am creating PR right after this issue. Felix already has the correct > implementation usable for this, so I just moved it to the Version class > (which seems to be a natural place for this), updated all references and also > extended tests. It is backward compatible despite the bit of refactoring. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (FELIX-6529) Improve memory usage ManifestParser using String deduplication
[ https://issues.apache.org/jira/browse/FELIX-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538938#comment-17538938 ] Karl Pauls commented on FELIX-6529: --- [~amitmondal], could you try my PR and see if it helps in our case? https://github.com/apache/felix-dev/pull/151 > Improve memory usage ManifestParser using String deduplication > -- > > Key: FELIX-6529 > URL: https://issues.apache.org/jira/browse/FELIX-6529 > Project: Felix > Issue Type: Improvement >Reporter: Johannes Edmeier >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.4 > > Attachments: ManifestParser.patch, image-2022-05-13-14-16-39-509.png, > image-2022-05-13-14-17-55-965.png > > > In my heap dump I've seen a lot of duplicate Strings produced by the > ManifestParser. > It creates a lot of equal strings for the keys in the manifest but doesn't > deduplicate them and they're hold forever producing a lot on retained heap. > I've patched the ManifestParser to deduplicate just the keys and could save > ~8 Megs of heap. > Total usage before: 38MB after: 30MB > Duplicated Strings before: > !image-2022-05-13-14-16-39-509.png|width=658,height=203! > Duplicated Strings after: > !image-2022-05-13-14-17-55-965.png|width=793,height=200! > See patch attached. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (FELIX-6529) Improve memory usage ManifestParser using String deduplication
[ https://issues.apache.org/jira/browse/FELIX-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538039#comment-17538039 ] Karl Pauls commented on FELIX-6529: --- Right, I had the same question as [~gnodet], shouldn't we just use String.intern() instead - that would potentially even help in cases where there is more than one framework at the same time. > Improve memory usage ManifestParser using String deduplication > -- > > Key: FELIX-6529 > URL: https://issues.apache.org/jira/browse/FELIX-6529 > Project: Felix > Issue Type: Improvement >Reporter: Johannes Edmeier >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.4 > > Attachments: ManifestParser.patch, image-2022-05-13-14-16-39-509.png, > image-2022-05-13-14-17-55-965.png > > > In my heap dump I've seen a lot of duplicate Strings produced by the > ManifestParser. > It creates a lot of equal strings for the keys in the manifest but doesn't > deduplicate them and they're hold forever producing a lot on retained heap. > I've patched the ManifestParser to deduplicate just the keys and could save > ~8 Megs of heap. > Total usage before: 38MB after: 30MB > Duplicated Strings before: > !image-2022-05-13-14-16-39-509.png|width=658,height=203! > Duplicated Strings after: > !image-2022-05-13-14-17-55-965.png|width=793,height=200! > See patch attached. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (FELIX-6522) Empty name is not allowed in JDK17+
[ https://issues.apache.org/jira/browse/FELIX-6522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved FELIX-6522. --- Resolution: Fixed Thanks. I applied the patch. Wrt. a release - I'll try to cut one soon. > Empty name is not allowed in JDK17+ > --- > > Key: FELIX-6522 > URL: https://issues.apache.org/jira/browse/FELIX-6522 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-7.0.3 >Reporter: David Matějček >Assignee: Karl Pauls >Priority: Blocker > Labels: patch-available, pull-request-available > Fix For: framework-7.0.4 > > Original Estimate: 1h > Remaining Estimate: 1h > > h3. Bug > When GlassFish enables the SecurityManager, it is unable to start on JDK17 > and JDK18, because BundleWiringImpl throws IAE. > h3. Cause > BasicPermission.init checks for an empty string since JDK17 (maybe earlier, > but in JDK11 did not). Some capabilities return an empty string (I did not > investigate which, I just saw the stacktrace in GlassFish). > CapabilityPermission constructor then crashes. > h5. Minor note > The SecurityManager feature is now deprecated in JDK and marked for removal, > so there should be some plan for Felix soon. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (FELIX-6529) Improve memory usage ManifestParser using String deduplication
[ https://issues.apache.org/jira/browse/FELIX-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls reassigned FELIX-6529: - Assignee: Karl Pauls > Improve memory usage ManifestParser using String deduplication > -- > > Key: FELIX-6529 > URL: https://issues.apache.org/jira/browse/FELIX-6529 > Project: Felix > Issue Type: Improvement >Reporter: Johannes Edmeier >Assignee: Karl Pauls >Priority: Major > Attachments: ManifestParser.patch, image-2022-05-13-14-16-39-509.png, > image-2022-05-13-14-17-55-965.png > > > In my heap dump I've seen a lot of duplicate Strings produced by the > ManifestParser. > It creates a lot of equal strings for the keys in the manifest but doesn't > deduplicate them and they're hold forever producing a lot on retained heap. > I've patched the ManifestParser to deduplicate just the keys and could save > ~8 Megs of heap. > Total usage before: 38MB after: 30MB > Duplicated Strings before: > !image-2022-05-13-14-16-39-509.png|width=658,height=203! > Duplicated Strings after: > !image-2022-05-13-14-17-55-965.png|width=793,height=200! > See patch attached. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (FELIX-6529) Improve memory usage ManifestParser using String deduplication
[ https://issues.apache.org/jira/browse/FELIX-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated FELIX-6529: -- Fix Version/s: framework-7.0.4 > Improve memory usage ManifestParser using String deduplication > -- > > Key: FELIX-6529 > URL: https://issues.apache.org/jira/browse/FELIX-6529 > Project: Felix > Issue Type: Improvement >Reporter: Johannes Edmeier >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.4 > > Attachments: ManifestParser.patch, image-2022-05-13-14-16-39-509.png, > image-2022-05-13-14-17-55-965.png > > > In my heap dump I've seen a lot of duplicate Strings produced by the > ManifestParser. > It creates a lot of equal strings for the keys in the manifest but doesn't > deduplicate them and they're hold forever producing a lot on retained heap. > I've patched the ManifestParser to deduplicate just the keys and could save > ~8 Megs of heap. > Total usage before: 38MB after: 30MB > Duplicated Strings before: > !image-2022-05-13-14-16-39-509.png|width=658,height=203! > Duplicated Strings after: > !image-2022-05-13-14-17-55-965.png|width=793,height=200! > See patch attached. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (FELIX-6522) Empty name is not allowed in JDK17+
[ https://issues.apache.org/jira/browse/FELIX-6522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls reassigned FELIX-6522: - Assignee: Karl Pauls > Empty name is not allowed in JDK17+ > --- > > Key: FELIX-6522 > URL: https://issues.apache.org/jira/browse/FELIX-6522 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-7.0.3 >Reporter: David Matějček >Assignee: Karl Pauls >Priority: Blocker > Labels: patch-available > Fix For: framework-7.0.4 > > Original Estimate: 1h > Remaining Estimate: 1h > > h3. Bug > When GlassFish enables the SecurityManager, it is unable to start on JDK17 > and JDK18, because BundleWiringImpl throws IAE. > h3. Cause > BasicPermission.init checks for an empty string since JDK17 (maybe earlier, > but in JDK11 did not). Some capabilities return an empty string (I did not > investigate which, I just saw the stacktrace in GlassFish). > CapabilityPermission constructor then crashes. > h5. Minor note > The SecurityManager feature is now deprecated in JDK and marked for removal, > so there should be some plan for Felix soon. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (FELIX-6502) Java 11+ support
[ https://issues.apache.org/jira/browse/FELIX-6502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488132#comment-17488132 ] Karl Pauls commented on FELIX-6502: --- A PR would certainly be interesting! > Java 11+ support > > > Key: FELIX-6502 > URL: https://issues.apache.org/jira/browse/FELIX-6502 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Reporter: Alexander Shaklein >Priority: Minor > > I have made some changes in ipojo projects to work in java 11+. > The were successfully tested on java 11, 16. Should i make a PR or i can work > with fork alone? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (FELIX-6488) Optimize ServiceReference.isAssignableTo
Karl Pauls created FELIX-6488: - Summary: Optimize ServiceReference.isAssignableTo Key: FELIX-6488 URL: https://issues.apache.org/jira/browse/FELIX-6488 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-7.0.3 Reporter: Karl Pauls Assignee: Karl Pauls Fix For: framework-7.0.4 The ServiceReference.isAssignableTo(Bundle bundle, String className) does some complicated check to see if the service is assignable. This includes trying to load classes and catching CNFE to see if providers and/or requesters have access to the given class. As that is done quite a bit (it is used in service event dispatching and service lookup) it would be good to optimize this to either not throw CNFE during the lookup or maybe at least cache the results to not have them be done all the time. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (FELIX-6484) Update logback dependency to 1.2.8 (fix for LOGBACK-1591)
[ https://issues.apache.org/jira/browse/FELIX-6484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17459570#comment-17459570 ] Karl Pauls commented on FELIX-6484: --- Thanks [~rombert], I changed the title. > Update logback dependency to 1.2.8 (fix for LOGBACK-1591) > - > > Key: FELIX-6484 > URL: https://issues.apache.org/jira/browse/FELIX-6484 > Project: Felix > Issue Type: Task > Components: Felix Logback >Reporter: Raymond Augé >Assignee: Raymond Augé >Priority: Major > Fix For: felix-logback-1.0.6 > > > See http://logback.qos.ch/news.html#:~:text=Release%20of%20version%201.2.8 > FYI felix.logback does not contain the affected version of logback. We're > just updating the transitive dependency so that in cases where transitive > deps are used a secured version is used. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (FELIX-6484) Update logback dependency to 1.2.8 (fix for LOGBACK-1591)
[ https://issues.apache.org/jira/browse/FELIX-6484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated FELIX-6484: -- Summary: Update logback dependency to 1.2.8 (fix for LOGBACK-1591) (was: Update logback dependency to overcome CVE-2021-44228) > Update logback dependency to 1.2.8 (fix for LOGBACK-1591) > - > > Key: FELIX-6484 > URL: https://issues.apache.org/jira/browse/FELIX-6484 > Project: Felix > Issue Type: Task > Components: Felix Logback >Reporter: Raymond Augé >Assignee: Raymond Augé >Priority: Major > Fix For: felix-logback-1.0.6 > > > See http://logback.qos.ch/news.html#:~:text=Release%20of%20version%201.2.8 > FYI felix.logback does not contain the affected version of logback. We're > just updating the transitive dependency so that in cases where transitive > deps are used a secured version is used. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (FELIX-3351) Permissions.createPermission(String name, String action, Class target) Fails for action == null
[ https://issues.apache.org/jira/browse/FELIX-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed FELIX-3351. - > Permissions.createPermission(String name, String action, Class target) Fails > for action == null > --- > > Key: FELIX-3351 > URL: https://issues.apache.org/jira/browse/FELIX-3351 > Project: Felix > Issue Type: Bug > Components: Framework Security >Affects Versions: framework.security-1.4.1 >Reporter: Bob Ziuchkovski >Assignee: Karl Pauls >Priority: Minor > Fix For: framework.security-2.8.3 > > Attachments: felix_permission_noaction.patch > > > java.security.Permission has a single constructor, Permission(String name). > While many subclasses add another constructor with sig (String name, String > actions), this is not a requirement for Permission subclasses and custom > permissions without the actions arg are not properly handled by > createPermission(). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (FELIX-6442) NPE when generating ServiceReferenceDTOs
[
https://issues.apache.org/jira/browse/FELIX-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls closed FELIX-6442.
-
> NPE when generating ServiceReferenceDTOs
>
>
> Key: FELIX-6442
> URL: https://issues.apache.org/jira/browse/FELIX-6442
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-7.0.1
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: framework-7.0.3
>
>
> Sometimes when iterating over SCR DTOs, a NPE occurs - I suspect this is a
> race condition with the framework unregistering a service
> {noformat}
>
> [pool-85-thread-1] java.lang.NullPointerException: null at
> org.apache.felix.framework.DTOFactory.createServiceReferenceDTO(DTOFactory.java:349)
> at
> org.apache.felix.framework.DTOFactory.createServiceReferenceDTOArray(DTOFactory.java:341)
> at
> org.apache.felix.framework.DTOFactory.createDTO(DTOFactory.java:106) at
> org.apache.felix.framework.BundleImpl.adapt(BundleImpl.java:1160) at
> org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(ServiceComponentRuntimeImpl.java:303)
> [org.apache.felix.scr:2.1.26] at
> org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.satisfiedRefManagersToDTO(ServiceComponentRuntimeImpl.java:250)
> [org.apache.felix.scr:2.1.26] at
> org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.managerToConfiguration(ServiceComponentRuntimeImpl.java:215)
> [org.apache.felix.scr:2.1.26] at
> org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.getComponentConfigurationDTOs(ServiceComponentRuntimeImpl.java:141)
> [org.apache.felix.scr:2.1.26] at
> org.apache.felix.rootcause.DSRootCause.getRootCause(DSRootCause.java:60)
> [org.apache.felix.rootcause:0.1.0] at
> org.apache.felix.rootcause.DSRootCause.getRootCause(DSRootCause.java:51)
> [org.apache.felix.rootcause:0.1.0] at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source) at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(Unknown Source) at
> java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(Unknown
> Source) at
> java.base/java.util.stream.AbstractPipeline.copyInto(Unknown Source) at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(Unknown
> Source) at
> java.base/java.util.stream.AbstractPipeline.evaluate(Unknown Source) at
> java.base/java.util.stream.ReferencePipeline.collect(Unknown Source) at
> org.apache.felix.systemready.impl.ComponentsCheck.getStatus(ComponentsCheck.java:97)
> at
> org.apache.felix.systemready.impl.SystemReadyMonitorImpl.getStatus(SystemReadyMonitorImpl.java:150)
> at
> org.apache.felix.systemready.impl.SystemReadyMonitorImpl.lambda$evaluateAllChecks$2(SystemReadyMonitorImpl.java:133)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source) at
> java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(Unknown
> Source) at
> java.base/java.util.stream.AbstractPipeline.copyInto(Unknown Source) at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(Unknown
> Source) at
> java.base/java.util.stream.AbstractPipeline.evaluate(Unknown Source) at
> java.base/java.util.stream.ReferencePipeline.collect(Unknown Source) at
> org.apache.felix.systemready.impl.SystemReadyMonitorImpl.evaluateAllChecks(SystemReadyMonitorImpl.java:135)
> at
> org.apache.felix.systemready.impl.SystemReadyMonitorImpl.check(SystemReadyMonitorImpl.java:119)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> at
> java.base/java.util.concurrent.FutureTask.runAndReset(Unknown Source) at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
> Source) at
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (FELIX-6468) felix.main-7.0.1 jar file entries have bogus timestamps
[
https://issues.apache.org/jira/browse/FELIX-6468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls closed FELIX-6468.
-
> felix.main-7.0.1 jar file entries have bogus timestamps
> ---
>
> Key: FELIX-6468
> URL: https://issues.apache.org/jira/browse/FELIX-6468
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-7.0.1
>Reporter: Gjøran Voldengen
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.3
>
> Attachments: exception.txt
>
>
> Many file entries in the {{felix-main-7.0.1.jar}} file have the date
> 17-Nov-2070.
> This causes the {{maven-dependency-plugin}} to fail when the
> {{unpack-dependencies}} goal is used to unpack a jar file containing the
> felix-main jar. The plugin fails with the message "Negative time". The full
> exepction is attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (FELIX-6467) `AllPermission` not checked when updating `ConditionalPermissionAdmin`
[ https://issues.apache.org/jira/browse/FELIX-6467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed FELIX-6467. - > `AllPermission` not checked when updating `ConditionalPermissionAdmin` > -- > > Key: FELIX-6467 > URL: https://issues.apache.org/jira/browse/FELIX-6467 > Project: Felix > Issue Type: Bug > Components: Conditional Permission Admin >Affects Versions: framework.security-2.8.1 >Reporter: Joel Dudley >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.3, framework.security-2.8.3 > > > `ConditionalPermissionUpdate.commit()` should check whether the caller has > `AllPermission` before committing the updated permissions. The Javadocs state: > _"Throws:_ > _*SecurityException – If the caller does not have AllPermission.*_ > _IllegalStateException – If this update's Conditional Permissions are not > valid or inconsistent. For example, this update has two Conditional > Permissions in it with the same name"_ > This check is not performed (it is performed in the deprecated > `addConditionalPermissionInfo()` and `setConditionalPermissionInfo()` > methods). > As a result, there is no way to prevent arbitrary code that can access the > `ConditionalPermissionAdmin` from modifying the permissions at will. > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (FELIX-6429) IllegalArgumentException that should not happen
[
https://issues.apache.org/jira/browse/FELIX-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls closed FELIX-6429.
-
> IllegalArgumentException that should not happen
> ---
>
> Key: FELIX-6429
> URL: https://issues.apache.org/jira/browse/FELIX-6429
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-7.0.0
>Reporter: Jürgen Albert
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.3
>
>
> We recently stumbled a couple of times over an IllegalArgumentException when
> calling ServiceObjects.ungetService. In our case we are always in an async
> process and the service we are calling unget for ist already unregistered.
> According to the org.osgi.framework.ServiceObjects Spec the Exception will be
> thrown under the following circumstances:
> {code:java}
> @throws IllegalArgumentException If the specified service object is
>{@code null} or was not provided by a {@code ServiceObjects}
>object for the associated service.
> {code}
> I can guarantee that both conditions are not meet in our case. It is simply
> that the service is already unregistered.
> If I read the javadoc correctly it should simply do nothing in such a case. I
> haven't checked with the Spec though.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (FELIX-6468) felix.main-7.0.1 jar file entries have bogus timestamps
[
https://issues.apache.org/jira/browse/FELIX-6468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved FELIX-6468.
---
Resolution: Fixed
> felix.main-7.0.1 jar file entries have bogus timestamps
> ---
>
> Key: FELIX-6468
> URL: https://issues.apache.org/jira/browse/FELIX-6468
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-7.0.1
>Reporter: Gjøran Voldengen
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.2
>
> Attachments: exception.txt
>
>
> Many file entries in the {{felix-main-7.0.1.jar}} file have the date
> 17-Nov-2070.
> This causes the {{maven-dependency-plugin}} to fail when the
> {{unpack-dependencies}} goal is used to unpack a jar file containing the
> felix-main jar. The plugin fails with the message "Negative time". The full
> exepction is attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (FELIX-3351) Permissions.createPermission(String name, String action, Class target) Fails for action == null
[ https://issues.apache.org/jira/browse/FELIX-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved FELIX-3351. --- Resolution: Fixed > Permissions.createPermission(String name, String action, Class target) Fails > for action == null > --- > > Key: FELIX-3351 > URL: https://issues.apache.org/jira/browse/FELIX-3351 > Project: Felix > Issue Type: Bug > Components: Framework Security >Affects Versions: framework.security-1.4.1 >Reporter: Bob Ziuchkovski >Assignee: Karl Pauls >Priority: Minor > Fix For: framework.security-2.8.2 > > Attachments: felix_permission_noaction.patch > > > java.security.Permission has a single constructor, Permission(String name). > While many subclasses add another constructor with sig (String name, String > actions), this is not a requirement for Permission subclasses and custom > permissions without the actions arg are not properly handled by > createPermission(). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (FELIX-3351) Permissions.createPermission(String name, String action, Class target) Fails for action == null
[ https://issues.apache.org/jira/browse/FELIX-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated FELIX-3351: -- Fix Version/s: framework.security-2.8.2 > Permissions.createPermission(String name, String action, Class target) Fails > for action == null > --- > > Key: FELIX-3351 > URL: https://issues.apache.org/jira/browse/FELIX-3351 > Project: Felix > Issue Type: Bug > Components: Framework Security >Affects Versions: framework.security-1.4.1 >Reporter: Bob Ziuchkovski >Assignee: Karl Pauls >Priority: Minor > Fix For: framework.security-2.8.2 > > Attachments: felix_permission_noaction.patch > > > java.security.Permission has a single constructor, Permission(String name). > While many subclasses add another constructor with sig (String name, String > actions), this is not a requirement for Permission subclasses and custom > permissions without the actions arg are not properly handled by > createPermission(). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (FELIX-6467) `AllPermission` not checked when updating `ConditionalPermissionAdmin`
[ https://issues.apache.org/jira/browse/FELIX-6467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved FELIX-6467. --- Resolution: Fixed Thanks [~joeldudley] - I fixed it in https://github.com/apache/felix-dev/pull/113 Will do a release soon. > `AllPermission` not checked when updating `ConditionalPermissionAdmin` > -- > > Key: FELIX-6467 > URL: https://issues.apache.org/jira/browse/FELIX-6467 > Project: Felix > Issue Type: Bug > Components: Conditional Permission Admin >Affects Versions: framework.security-2.8.1 >Reporter: Joel Dudley >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.2, framework.security-2.8.2 > > > `ConditionalPermissionUpdate.commit()` should check whether the caller has > `AllPermission` before committing the updated permissions. The Javadocs state: > _"Throws:_ > _*SecurityException – If the caller does not have AllPermission.*_ > _IllegalStateException – If this update's Conditional Permissions are not > valid or inconsistent. For example, this update has two Conditional > Permissions in it with the same name"_ > This check is not performed (it is performed in the deprecated > `addConditionalPermissionInfo()` and `setConditionalPermissionInfo()` > methods). > As a result, there is no way to prevent arbitrary code that can access the > `ConditionalPermissionAdmin` from modifying the permissions at will. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FELIX-6467) `AllPermission` not checked when updating `ConditionalPermissionAdmin`
[ https://issues.apache.org/jira/browse/FELIX-6467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated FELIX-6467: -- Fix Version/s: framework-7.0.2 > `AllPermission` not checked when updating `ConditionalPermissionAdmin` > -- > > Key: FELIX-6467 > URL: https://issues.apache.org/jira/browse/FELIX-6467 > Project: Felix > Issue Type: Bug > Components: Conditional Permission Admin >Affects Versions: framework.security-2.8.1 >Reporter: Joel Dudley >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.2, framework.security-2.8.2 > > > `ConditionalPermissionUpdate.commit()` should check whether the caller has > `AllPermission` before committing the updated permissions. The Javadocs state: > _"Throws:_ > _*SecurityException – If the caller does not have AllPermission.*_ > _IllegalStateException – If this update's Conditional Permissions are not > valid or inconsistent. For example, this update has two Conditional > Permissions in it with the same name"_ > This check is not performed (it is performed in the deprecated > `addConditionalPermissionInfo()` and `setConditionalPermissionInfo()` > methods). > As a result, there is no way to prevent arbitrary code that can access the > `ConditionalPermissionAdmin` from modifying the permissions at will. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FELIX-6468) felix.main-7.0.1 jar file entries have bogus timestamps
[
https://issues.apache.org/jira/browse/FELIX-6468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17434750#comment-17434750
]
Karl Pauls commented on FELIX-6468:
---
Strange - I'll try to avoid it for the next release. Thanks for reporting!
> felix.main-7.0.1 jar file entries have bogus timestamps
> ---
>
> Key: FELIX-6468
> URL: https://issues.apache.org/jira/browse/FELIX-6468
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-7.0.1
>Reporter: Gjøran Voldengen
>Assignee: Karl Pauls
>Priority: Major
> Attachments: exception.txt
>
>
> Many file entries in the {{felix-main-7.0.1.jar}} file have the date
> 17-Nov-2070.
> This causes the {{maven-dependency-plugin}} to fail when the
> {{unpack-dependencies}} goal is used to unpack a jar file containing the
> felix-main jar. The plugin fails with the message "Negative time". The full
> exepction is attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6468) felix.main-7.0.1 jar file entries have bogus timestamps
[
https://issues.apache.org/jira/browse/FELIX-6468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-6468:
--
Fix Version/s: framework-7.0.2
> felix.main-7.0.1 jar file entries have bogus timestamps
> ---
>
> Key: FELIX-6468
> URL: https://issues.apache.org/jira/browse/FELIX-6468
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-7.0.1
>Reporter: Gjøran Voldengen
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.2
>
> Attachments: exception.txt
>
>
> Many file entries in the {{felix-main-7.0.1.jar}} file have the date
> 17-Nov-2070.
> This causes the {{maven-dependency-plugin}} to fail when the
> {{unpack-dependencies}} goal is used to unpack a jar file containing the
> felix-main jar. The plugin fails with the message "Negative time". The full
> exepction is attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (FELIX-6468) felix.main-7.0.1 jar file entries have bogus timestamps
[
https://issues.apache.org/jira/browse/FELIX-6468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reassigned FELIX-6468:
-
Assignee: Karl Pauls
> felix.main-7.0.1 jar file entries have bogus timestamps
> ---
>
> Key: FELIX-6468
> URL: https://issues.apache.org/jira/browse/FELIX-6468
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-7.0.1
>Reporter: Gjøran Voldengen
>Assignee: Karl Pauls
>Priority: Major
> Attachments: exception.txt
>
>
> Many file entries in the {{felix-main-7.0.1.jar}} file have the date
> 17-Nov-2070.
> This causes the {{maven-dependency-plugin}} to fail when the
> {{unpack-dependencies}} goal is used to unpack a jar file containing the
> felix-main jar. The plugin fails with the message "Negative time". The full
> exepction is attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6467) `AllPermission` not checked when updating `ConditionalPermissionAdmin`
[ https://issues.apache.org/jira/browse/FELIX-6467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated FELIX-6467: -- Fix Version/s: framework.security-2.8.2 > `AllPermission` not checked when updating `ConditionalPermissionAdmin` > -- > > Key: FELIX-6467 > URL: https://issues.apache.org/jira/browse/FELIX-6467 > Project: Felix > Issue Type: Bug > Components: Conditional Permission Admin >Affects Versions: framework.security-2.8.1 >Reporter: Joel Dudley >Assignee: Karl Pauls >Priority: Major > Fix For: framework.security-2.8.2 > > > `ConditionalPermissionUpdate.commit()` should check whether the caller has > `AllPermission` before committing the updated permissions. The Javadocs state: > _"Throws:_ > _*SecurityException – If the caller does not have AllPermission.*_ > _IllegalStateException – If this update's Conditional Permissions are not > valid or inconsistent. For example, this update has two Conditional > Permissions in it with the same name"_ > This check is not performed (it is performed in the deprecated > `addConditionalPermissionInfo()` and `setConditionalPermissionInfo()` > methods). > As a result, there is no way to prevent arbitrary code that can access the > `ConditionalPermissionAdmin` from modifying the permissions at will. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (FELIX-6467) `AllPermission` not checked when updating `ConditionalPermissionAdmin`
[ https://issues.apache.org/jira/browse/FELIX-6467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls reassigned FELIX-6467: - Assignee: Karl Pauls > `AllPermission` not checked when updating `ConditionalPermissionAdmin` > -- > > Key: FELIX-6467 > URL: https://issues.apache.org/jira/browse/FELIX-6467 > Project: Felix > Issue Type: Bug > Components: Conditional Permission Admin >Affects Versions: framework.security-2.8.1 >Reporter: Joel Dudley >Assignee: Karl Pauls >Priority: Major > > `ConditionalPermissionUpdate.commit()` should check whether the caller has > `AllPermission` before committing the updated permissions. The Javadocs state: > _"Throws:_ > _*SecurityException – If the caller does not have AllPermission.*_ > _IllegalStateException – If this update's Conditional Permissions are not > valid or inconsistent. For example, this update has two Conditional > Permissions in it with the same name"_ > This check is not performed (it is performed in the deprecated > `addConditionalPermissionInfo()` and `setConditionalPermissionInfo()` > methods). > As a result, there is no way to prevent arbitrary code that can access the > `ConditionalPermissionAdmin` from modifying the permissions at will. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (FELIX-6429) IllegalArgumentException that should not happen
[
https://issues.apache.org/jira/browse/FELIX-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved FELIX-6429.
---
Resolution: Fixed
Done in https://github.com/apache/felix-dev/pull/102
> IllegalArgumentException that should not happen
> ---
>
> Key: FELIX-6429
> URL: https://issues.apache.org/jira/browse/FELIX-6429
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-7.0.0
>Reporter: Jürgen Albert
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.2
>
>
> We recently stumbled a couple of times over an IllegalArgumentException when
> calling ServiceObjects.ungetService. In our case we are always in an async
> process and the service we are calling unget for ist already unregistered.
> According to the org.osgi.framework.ServiceObjects Spec the Exception will be
> thrown under the following circumstances:
> {code:java}
> @throws IllegalArgumentException If the specified service object is
>{@code null} or was not provided by a {@code ServiceObjects}
>object for the associated service.
> {code}
> I can guarantee that both conditions are not meet in our case. It is simply
> that the service is already unregistered.
> If I read the javadoc correctly it should simply do nothing in such a case. I
> haven't checked with the Spec though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6429) IllegalArgumentException that should not happen
[
https://issues.apache.org/jira/browse/FELIX-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-6429:
--
Fix Version/s: framework-7.0.2
> IllegalArgumentException that should not happen
> ---
>
> Key: FELIX-6429
> URL: https://issues.apache.org/jira/browse/FELIX-6429
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-7.0.0
>Reporter: Jürgen Albert
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.2
>
>
> We recently stumbled a couple of times over an IllegalArgumentException when
> calling ServiceObjects.ungetService. In our case we are always in an async
> process and the service we are calling unget for ist already unregistered.
> According to the org.osgi.framework.ServiceObjects Spec the Exception will be
> thrown under the following circumstances:
> {code:java}
> @throws IllegalArgumentException If the specified service object is
>{@code null} or was not provided by a {@code ServiceObjects}
>object for the associated service.
> {code}
> I can guarantee that both conditions are not meet in our case. It is simply
> that the service is already unregistered.
> If I read the javadoc correctly it should simply do nothing in such a case. I
> haven't checked with the Spec though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (FELIX-6429) IllegalArgumentException that should not happen
[
https://issues.apache.org/jira/browse/FELIX-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reopened FELIX-6429:
---
Yes, that would be a bug. If it is just a question of several unget throwing it
wouldn't be but if it is caused by an unregister that is different.
> IllegalArgumentException that should not happen
> ---
>
> Key: FELIX-6429
> URL: https://issues.apache.org/jira/browse/FELIX-6429
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-7.0.0
>Reporter: Jürgen Albert
>Assignee: Karl Pauls
>Priority: Major
>
> We recently stumbled a couple of times over an IllegalArgumentException when
> calling ServiceObjects.ungetService. In our case we are always in an async
> process and the service we are calling unget for ist already unregistered.
> According to the org.osgi.framework.ServiceObjects Spec the Exception will be
> thrown under the following circumstances:
> {code:java}
> @throws IllegalArgumentException If the specified service object is
>{@code null} or was not provided by a {@code ServiceObjects}
>object for the associated service.
> {code}
> I can guarantee that both conditions are not meet in our case. It is simply
> that the service is already unregistered.
> If I read the javadoc correctly it should simply do nothing in such a case. I
> haven't checked with the Spec though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6429) IllegalArgumentException that should not happen
[
https://issues.apache.org/jira/browse/FELIX-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418113#comment-17418113
]
Karl Pauls commented on FELIX-6429:
---
[~jalbert], I think it would be good if you could either restate again what
exactly you are doing, what happens, and what you expect. Preferably with a
test case.
> IllegalArgumentException that should not happen
> ---
>
> Key: FELIX-6429
> URL: https://issues.apache.org/jira/browse/FELIX-6429
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-7.0.0
>Reporter: Jürgen Albert
>Assignee: Karl Pauls
>Priority: Major
>
> We recently stumbled a couple of times over an IllegalArgumentException when
> calling ServiceObjects.ungetService. In our case we are always in an async
> process and the service we are calling unget for ist already unregistered.
> According to the org.osgi.framework.ServiceObjects Spec the Exception will be
> thrown under the following circumstances:
> {code:java}
> @throws IllegalArgumentException If the specified service object is
>{@code null} or was not provided by a {@code ServiceObjects}
>object for the associated service.
> {code}
> I can guarantee that both conditions are not meet in our case. It is simply
> that the service is already unregistered.
> If I read the javadoc correctly it should simply do nothing in such a case. I
> haven't checked with the Spec though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (FELIX-6429) IllegalArgumentException that should not happen
[
https://issues.apache.org/jira/browse/FELIX-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved FELIX-6429.
---
Fix Version/s: (was: framework-7.0.2)
Resolution: Won't Fix
Hi [~jalbert], I talked about this a bit with [~tjwatson] and [~cziegeler] - we
think this is working as designed as technically, when the service is
unregistered, it is not provided by the ServiceObjects anymore. It should have
the same effect in equinox/RI.
I'll close this one as Won't Fix - if you think this should be clarified it
probably should be done in OSGi first.
> IllegalArgumentException that should not happen
> ---
>
> Key: FELIX-6429
> URL: https://issues.apache.org/jira/browse/FELIX-6429
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-7.0.0
>Reporter: Jürgen Albert
>Assignee: Karl Pauls
>Priority: Major
>
> We recently stumbled a couple of times over an IllegalArgumentException when
> calling ServiceObjects.ungetService. In our case we are always in an async
> process and the service we are calling unget for ist already unregistered.
> According to the org.osgi.framework.ServiceObjects Spec the Exception will be
> thrown under the following circumstances:
> {code:java}
> @throws IllegalArgumentException If the specified service object is
>{@code null} or was not provided by a {@code ServiceObjects}
>object for the associated service.
> {code}
> I can guarantee that both conditions are not meet in our case. It is simply
> that the service is already unregistered.
> If I read the javadoc correctly it should simply do nothing in such a case. I
> haven't checked with the Spec though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (FELIX-6429) IllegalArgumentException that should not happen
[
https://issues.apache.org/jira/browse/FELIX-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17410420#comment-17410420
]
Karl Pauls edited comment on FELIX-6429 at 9/6/21, 7:13 AM:
Yes, this seems to be a bug.
{{ServiceObjects.ungetService}} will throw an IllegalArgumentException when the
usage count would drop below 0 which is not what the java doc is saying from
several angles.
was (Author: karlpauls):
Yes, this seems to be a bug.
> IllegalArgumentException that should not happen
> ---
>
> Key: FELIX-6429
> URL: https://issues.apache.org/jira/browse/FELIX-6429
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-7.0.0
>Reporter: Jürgen Albert
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.2
>
>
> We recently stumbled a couple of times over an IllegalArgumentException when
> calling ServiceObjects.ungetService. In our case we are always in an async
> process and the service we are calling unget for ist already unregistered.
> According to the org.osgi.framework.ServiceObjects Spec the Exception will be
> thrown under the following circumstances:
> {code:java}
> @throws IllegalArgumentException If the specified service object is
>{@code null} or was not provided by a {@code ServiceObjects}
>object for the associated service.
> {code}
> I can guarantee that both conditions are not meet in our case. It is simply
> that the service is already unregistered.
> If I read the javadoc correctly it should simply do nothing in such a case. I
> haven't checked with the Spec though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6429) IllegalArgumentException that should not happen
[
https://issues.apache.org/jira/browse/FELIX-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-6429:
--
Fix Version/s: framework-7.0.2
> IllegalArgumentException that should not happen
> ---
>
> Key: FELIX-6429
> URL: https://issues.apache.org/jira/browse/FELIX-6429
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-7.0.0
>Reporter: Jürgen Albert
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.2
>
>
> We recently stumbled a couple of times over an IllegalArgumentException when
> calling ServiceObjects.ungetService. In our case we are always in an async
> process and the service we are calling unget for ist already unregistered.
> According to the org.osgi.framework.ServiceObjects Spec the Exception will be
> thrown under the following circumstances:
> {code:java}
> @throws IllegalArgumentException If the specified service object is
>{@code null} or was not provided by a {@code ServiceObjects}
>object for the associated service.
> {code}
> I can guarantee that both conditions are not meet in our case. It is simply
> that the service is already unregistered.
> If I read the javadoc correctly it should simply do nothing in such a case. I
> haven't checked with the Spec though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6429) IllegalArgumentException that should not happen
[
https://issues.apache.org/jira/browse/FELIX-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17410420#comment-17410420
]
Karl Pauls commented on FELIX-6429:
---
Yes, this seems to be a bug.
> IllegalArgumentException that should not happen
> ---
>
> Key: FELIX-6429
> URL: https://issues.apache.org/jira/browse/FELIX-6429
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-7.0.0
>Reporter: Jürgen Albert
>Priority: Major
>
> We recently stumbled a couple of times over an IllegalArgumentException when
> calling ServiceObjects.ungetService. In our case we are always in an async
> process and the service we are calling unget for ist already unregistered.
> According to the org.osgi.framework.ServiceObjects Spec the Exception will be
> thrown under the following circumstances:
> {code:java}
> @throws IllegalArgumentException If the specified service object is
>{@code null} or was not provided by a {@code ServiceObjects}
>object for the associated service.
> {code}
> I can guarantee that both conditions are not meet in our case. It is simply
> that the service is already unregistered.
> If I read the javadoc correctly it should simply do nothing in such a case. I
> haven't checked with the Spec though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (FELIX-6429) IllegalArgumentException that should not happen
[
https://issues.apache.org/jira/browse/FELIX-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reassigned FELIX-6429:
-
Assignee: Karl Pauls
> IllegalArgumentException that should not happen
> ---
>
> Key: FELIX-6429
> URL: https://issues.apache.org/jira/browse/FELIX-6429
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-7.0.0
>Reporter: Jürgen Albert
>Assignee: Karl Pauls
>Priority: Major
>
> We recently stumbled a couple of times over an IllegalArgumentException when
> calling ServiceObjects.ungetService. In our case we are always in an async
> process and the service we are calling unget for ist already unregistered.
> According to the org.osgi.framework.ServiceObjects Spec the Exception will be
> thrown under the following circumstances:
> {code:java}
> @throws IllegalArgumentException If the specified service object is
>{@code null} or was not provided by a {@code ServiceObjects}
>object for the associated service.
> {code}
> I can guarantee that both conditions are not meet in our case. It is simply
> that the service is already unregistered.
> If I read the javadoc correctly it should simply do nothing in such a case. I
> haven't checked with the Spec though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6442) NPE when generating ServiceReferenceDTOs
[
https://issues.apache.org/jira/browse/FELIX-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17395651#comment-17395651
]
Karl Pauls commented on FELIX-6442:
---
Good catch.
> NPE when generating ServiceReferenceDTOs
>
>
> Key: FELIX-6442
> URL: https://issues.apache.org/jira/browse/FELIX-6442
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-7.0.1
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: framework-7.0.2
>
>
> Sometimes when iterating over SCR DTOs, a NPE occurs - I suspect this is a
> race condition with the framework unregistering a service
> {noformat}
>
> [pool-85-thread-1] java.lang.NullPointerException: null at
> org.apache.felix.framework.DTOFactory.createServiceReferenceDTO(DTOFactory.java:349)
> at
> org.apache.felix.framework.DTOFactory.createServiceReferenceDTOArray(DTOFactory.java:341)
> at
> org.apache.felix.framework.DTOFactory.createDTO(DTOFactory.java:106) at
> org.apache.felix.framework.BundleImpl.adapt(BundleImpl.java:1160) at
> org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(ServiceComponentRuntimeImpl.java:303)
> [org.apache.felix.scr:2.1.26] at
> org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.satisfiedRefManagersToDTO(ServiceComponentRuntimeImpl.java:250)
> [org.apache.felix.scr:2.1.26] at
> org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.managerToConfiguration(ServiceComponentRuntimeImpl.java:215)
> [org.apache.felix.scr:2.1.26] at
> org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.getComponentConfigurationDTOs(ServiceComponentRuntimeImpl.java:141)
> [org.apache.felix.scr:2.1.26] at
> org.apache.felix.rootcause.DSRootCause.getRootCause(DSRootCause.java:60)
> [org.apache.felix.rootcause:0.1.0] at
> org.apache.felix.rootcause.DSRootCause.getRootCause(DSRootCause.java:51)
> [org.apache.felix.rootcause:0.1.0] at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source) at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(Unknown Source) at
> java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(Unknown
> Source) at
> java.base/java.util.stream.AbstractPipeline.copyInto(Unknown Source) at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(Unknown
> Source) at
> java.base/java.util.stream.AbstractPipeline.evaluate(Unknown Source) at
> java.base/java.util.stream.ReferencePipeline.collect(Unknown Source) at
> org.apache.felix.systemready.impl.ComponentsCheck.getStatus(ComponentsCheck.java:97)
> at
> org.apache.felix.systemready.impl.SystemReadyMonitorImpl.getStatus(SystemReadyMonitorImpl.java:150)
> at
> org.apache.felix.systemready.impl.SystemReadyMonitorImpl.lambda$evaluateAllChecks$2(SystemReadyMonitorImpl.java:133)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source) at
> java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(Unknown
> Source) at
> java.base/java.util.stream.AbstractPipeline.copyInto(Unknown Source) at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(Unknown
> Source) at
> java.base/java.util.stream.AbstractPipeline.evaluate(Unknown Source) at
> java.base/java.util.stream.ReferencePipeline.collect(Unknown Source) at
> org.apache.felix.systemready.impl.SystemReadyMonitorImpl.evaluateAllChecks(SystemReadyMonitorImpl.java:135)
> at
> org.apache.felix.systemready.impl.SystemReadyMonitorImpl.check(SystemReadyMonitorImpl.java:119)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> at
> java.base/java.util.concurrent.FutureTask.runAndReset(Unknown Source) at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
> Source) at
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (FELIX-6398) Update framework packages to osgi.core 8
[
https://issues.apache.org/jira/browse/FELIX-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls closed FELIX-6398.
-
> Update framework packages to osgi.core 8
>
>
> Key: FELIX-6398
> URL: https://issues.apache.org/jira/browse/FELIX-6398
> Project: Felix
> Issue Type: Improvement
> Components: Framework, Framework Security, Resolver
>Affects Versions: framework-7.0.0
>Reporter: Carsten Ziegeler
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.1, resolver-2.0.4, framework.security-2.8.1
>
>
> Although the R8 api is implemented by the framework, some of the package
> versions are slightly lower than the official R8 osgi.core jar - which can
> lead to unresolved packages if compiled against that jar but used with the
> Apache Felix Framework.
> These are the packages from osgi.core 8.0.0 which have lower versions in the
> release:
> {noformat}
> org.osgi.dto {version=1.1.1}
> org.osgi.resource {version=1.0.1}
> org.osgi.resource.dto {version=1.0.1}
> org.osgi.service.packageadmin {version=1.2.1}
> org.osgi.service.resolver {version=1.1.1}
> org.osgi.service.startlevel{version=1.1.1}
> org.osgi.service.url {version=1.0.1}
> org.osgi.util.tracker {version=1.5.3}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (FELIX-6430) Felix uses sun.misc.Unsafe, crashed on JDK 17
[
https://issues.apache.org/jira/browse/FELIX-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls closed FELIX-6430.
-
> Felix uses sun.misc.Unsafe, crashed on JDK 17
> -
>
> Key: FELIX-6430
> URL: https://issues.apache.org/jira/browse/FELIX-6430
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-7.0.0
>Reporter: Arjan Tijms
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.1
>
>
> When running on JDK 17, Felix crashes with the following exception:
>
> {noformat}
> java.lang.NoSuchMethodException:
> sun.misc.Unsafe.defineAnonymousClass(java.lang.Class,[B,[Ljava.lang.Object;)
> at java.base/java.lang.Class.getMethod(Class.java:2227)
> at
> org.apache.felix.framework.util.SecureAction.getAccessor(SecureAction.java:1134)
> at
> org.apache.felix.framework.util.SecureAction.(SecureAction.java:86)
> at org.apache.felix.framework.Felix.(Felix.java:114)
> at
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:30)
> {noformat}
> The offending code in question reflectively uses {{sun.misc.Unsafe}}
> {code:java}
> private static Consumer getAccessor(Class clazz) {
> String packageName = clazz.getPackage().getName();
>
> if ("java.net".equals(packageName) ||
> "jdk.internal.loader".equals(packageName)) {
> if (m_accessorCache == null) {
> try {
> // Use reflection on Unsafe to avoid having to compile
> against it
> Class unsafeClass = Class.forName("sun.misc.Unsafe");
> Field theUnsafe = unsafeClass.getDeclaredField("theUnsafe");
>
> // NOTE: deep reflection is allowed on sun.misc package for
> java 9.
> theUnsafe.setAccessible(true);
> Object unsafe = theUnsafe.get(null);
>
> // using defineAnonymousClass here because it seems more
> simple
> // to get what we need
> Method defineAnonymousClass =
> unsafeClass.getMethod("defineAnonymousClass",
> Class.class,
> byte[].class,
> Object[].class);
>
> // The bytes stored in a resource to avoid real loading of it
> // (see accessible.src for source).
> Class> result =
>(Class>)
>defineAnonymousClass.invoke(
> unsafe, URL.class,
> accessor, null);
> m_accessorCache = result.getConstructor().newInstance();
> } catch (Throwable t) {
> t.printStackTrace();
> m_accessorCache =
> objects -> AccessibleObject.setAccessible(objects, true);
> }
> }
>
> return m_accessorCache;
> }
>
> return objects -> AccessibleObject.setAccessible(objects, true);
> }
> {code}
> For JDK 17+ it may be needed to stop using {{sun.misc.Unsafe}} and use a JDK
> replacement?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (FELIX-6287) Support running on module path
[
https://issues.apache.org/jira/browse/FELIX-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls closed FELIX-6287.
-
> Support running on module path
> --
>
> Key: FELIX-6287
> URL: https://issues.apache.org/jira/browse/FELIX-6287
> Project: Felix
> Issue Type: Improvement
>Affects Versions: framework-6.0.3
>Reporter: Florian Brunner
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.1
>
> Attachments: module-path-issue-1.txt, module-path-issue-2.txt
>
>
> Currently, when running the framework on the module path, I get the following
> exception:
> {code:java}
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> protected boolean java.net.URLStreamHandler.equals(java.net.URL,java.net.URL)
> accessible: module java.base does not "opens java.net" to module
> org.apache.felix.framework
> {code}
> and
> {code:java}
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.felix.framework.URLHandlersStreamHandlerProxy
> {code}
> Make sure the framework works properly on the module-path as well
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (FELIX-6433) Felix 6.0.4 doesn't work on JDK 17
[ https://issues.apache.org/jira/browse/FELIX-6433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed FELIX-6433. - > Felix 6.0.4 doesn't work on JDK 17 > -- > > Key: FELIX-6433 > URL: https://issues.apache.org/jira/browse/FELIX-6433 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-6.0.4 >Reporter: Arjan Tijms >Assignee: Karl Pauls >Priority: Major > Fix For: framework-6.0.5 > > > When running on JDK 17, Felix can not reflect on all necessary classes. We > need to define a list of add-opens to make it work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (FELIX-6416) Special case JDK9+ URLClassLoader url resource loading
[
https://issues.apache.org/jira/browse/FELIX-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls closed FELIX-6416.
-
> Special case JDK9+ URLClassLoader url resource loading
> --
>
> Key: FELIX-6416
> URL: https://issues.apache.org/jira/browse/FELIX-6416
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.4
> Environment: MacOS
>Reporter: Piotr Klimczak
>Assignee: Karl Pauls
>Priority: Blocker
> Fix For: framework-7.0.1, framework-6.0.5
>
>
> '#' sign represents URL fragment and is not valid URL path element.
> As per spec it is not allowed for it to be a part of path and instead must be
> URL encoded.
> So for example for file in location in UNIX systems:
> "/Users/piotrklimczak/test#", the valid URL encoding to load it in Java is:
> {code:java}
> new File(new URL("file:///Users/piotrklimczak/test%23").toURI()) {code}
> Works.
> While
> {code:java}
> new File(new URL("file:///Users/piotrklimczak/test#").toURI()) {code}
> Returns java.lang.IllegalArgumentException in Java: URI has a fragment
> component
> FELIX-6326 effectively allows '#' to be accepted as valid URL path element,
> which in turn breaks JDK9+ URLClassLoader which is using URL fragment (ref)
> to deal with multi-release jars.
> This then breaks pax-transx-tm-narayana installation in Karaf 4.3.1 (which
> uses URLClassLoader).
> In my opinion FELIX-6326 should be reverted and users should be encoding
> special characters correctly in their resource paths as per above example.
> I've taken a risk to mark it as a blocker as effectively it blocks using
> Narayana TM, rendering Karaf 4.3.1 not usable for us.
> Feel free to downgrade it if my judgement failed here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (FELIX-6426) Update Apache Tomcat dependency from felix servlet-api to the latest 8 version
[ https://issues.apache.org/jira/browse/FELIX-6426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed FELIX-6426. - > Update Apache Tomcat dependency from felix servlet-api to the latest 8 version > -- > > Key: FELIX-6426 > URL: https://issues.apache.org/jira/browse/FELIX-6426 > Project: Felix > Issue Type: Improvement > Components: HTTP Service >Affects Versions: http.servlet-api-1.1.2 >Reporter: Natalia Angulo Herrera >Assignee: Karl Pauls >Priority: Major > Fix For: http.servlet-api-1.1.4 > > > Update Apache Tomcat dependency from felix servlet-api to the latest 8 version -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (FELIX-6433) Felix 6.0.4 doesn't work on JDK 17
[ https://issues.apache.org/jira/browse/FELIX-6433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved FELIX-6433. --- Resolution: Fixed Fixed in https://github.com/apache/felix-dev/commit/d56ed62f4c0162c584e6db96bd89b56a89ae26d6 > Felix 6.0.4 doesn't work on JDK 17 > -- > > Key: FELIX-6433 > URL: https://issues.apache.org/jira/browse/FELIX-6433 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-6.0.4 >Reporter: Arjan Tijms >Assignee: Karl Pauls >Priority: Major > Fix For: framework-6.0.5 > > > When running on JDK 17, Felix can not reflect on all necessary classes. We > need to define a list of add-opens to make it work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FELIX-6430) Felix uses sun.misc.Unsafe, crashed on JDK 17
[
https://issues.apache.org/jira/browse/FELIX-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362459#comment-17362459
]
Karl Pauls commented on FELIX-6430:
---
I’ll try to get a 7.0.1 release with this change done next week.
> Felix uses sun.misc.Unsafe, crashed on JDK 17
> -
>
> Key: FELIX-6430
> URL: https://issues.apache.org/jira/browse/FELIX-6430
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-7.0.0
>Reporter: Arjan Tijms
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.1
>
>
> When running on JDK 17, Felix crashes with the following exception:
>
> {noformat}
> java.lang.NoSuchMethodException:
> sun.misc.Unsafe.defineAnonymousClass(java.lang.Class,[B,[Ljava.lang.Object;)
> at java.base/java.lang.Class.getMethod(Class.java:2227)
> at
> org.apache.felix.framework.util.SecureAction.getAccessor(SecureAction.java:1134)
> at
> org.apache.felix.framework.util.SecureAction.(SecureAction.java:86)
> at org.apache.felix.framework.Felix.(Felix.java:114)
> at
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:30)
> {noformat}
> The offending code in question reflectively uses {{sun.misc.Unsafe}}
> {code:java}
> private static Consumer getAccessor(Class clazz) {
> String packageName = clazz.getPackage().getName();
>
> if ("java.net".equals(packageName) ||
> "jdk.internal.loader".equals(packageName)) {
> if (m_accessorCache == null) {
> try {
> // Use reflection on Unsafe to avoid having to compile
> against it
> Class unsafeClass = Class.forName("sun.misc.Unsafe");
> Field theUnsafe = unsafeClass.getDeclaredField("theUnsafe");
>
> // NOTE: deep reflection is allowed on sun.misc package for
> java 9.
> theUnsafe.setAccessible(true);
> Object unsafe = theUnsafe.get(null);
>
> // using defineAnonymousClass here because it seems more
> simple
> // to get what we need
> Method defineAnonymousClass =
> unsafeClass.getMethod("defineAnonymousClass",
> Class.class,
> byte[].class,
> Object[].class);
>
> // The bytes stored in a resource to avoid real loading of it
> // (see accessible.src for source).
> Class> result =
>(Class>)
>defineAnonymousClass.invoke(
> unsafe, URL.class,
> accessor, null);
> m_accessorCache = result.getConstructor().newInstance();
> } catch (Throwable t) {
> t.printStackTrace();
> m_accessorCache =
> objects -> AccessibleObject.setAccessible(objects, true);
> }
> }
>
> return m_accessorCache;
> }
>
> return objects -> AccessibleObject.setAccessible(objects, true);
> }
> {code}
> For JDK 17+ it may be needed to stop using {{sun.misc.Unsafe}} and use a JDK
> replacement?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6433) Felix 6.0.4 doesn't work on JDK 17
[
https://issues.apache.org/jira/browse/FELIX-6433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-6433:
--
Description:
When running on JDK 17, Felix can not reflect on all necessary classes. We need
to define a list of add-opens to make it work.
was:
When running on JDK 17, Felix can not reflect on all necessary
{noformat}
java.lang.NoSuchMethodException:
sun.misc.Unsafe.defineAnonymousClass(java.lang.Class,[B,[Ljava.lang.Object;)
at java.base/java.lang.Class.getMethod(Class.java:2227)
at
org.apache.felix.framework.util.SecureAction.getAccessor(SecureAction.java:1134)
at org.apache.felix.framework.util.SecureAction.(SecureAction.java:86)
at org.apache.felix.framework.Felix.(Felix.java:114)
at
org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:30)
{noformat}
The offending code in question reflectively uses {{sun.misc.Unsafe}}
{code:java}
private static Consumer getAccessor(Class clazz) {
String packageName = clazz.getPackage().getName();
if ("java.net".equals(packageName) ||
"jdk.internal.loader".equals(packageName)) {
if (m_accessorCache == null) {
try {
// Use reflection on Unsafe to avoid having to compile against
it
Class unsafeClass = Class.forName("sun.misc.Unsafe");
Field theUnsafe = unsafeClass.getDeclaredField("theUnsafe");
// NOTE: deep reflection is allowed on sun.misc package for
java 9.
theUnsafe.setAccessible(true);
Object unsafe = theUnsafe.get(null);
// using defineAnonymousClass here because it seems more simple
// to get what we need
Method defineAnonymousClass =
unsafeClass.getMethod("defineAnonymousClass",
Class.class,
byte[].class,
Object[].class);
// The bytes stored in a resource to avoid real loading of it
// (see accessible.src for source).
Class> result =
(Class>)
defineAnonymousClass.invoke(
unsafe, URL.class,
accessor, null);
m_accessorCache = result.getConstructor().newInstance();
} catch (Throwable t) {
t.printStackTrace();
m_accessorCache =
objects -> AccessibleObject.setAccessible(objects, true);
}
}
return m_accessorCache;
}
return objects -> AccessibleObject.setAccessible(objects, true);
}
{code}
For JDK 17+ it may be needed to stop using {{sun.misc.Unsafe}} and use a JDK
replacement?
> Felix 6.0.4 doesn't work on JDK 17
> --
>
> Key: FELIX-6433
> URL: https://issues.apache.org/jira/browse/FELIX-6433
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-6.0.4
>Reporter: Arjan Tijms
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-6.0.5
>
>
> When running on JDK 17, Felix can not reflect on all necessary classes. We
> need to define a list of add-opens to make it work.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6433) Felix 6.0.4 doesn't work on JDK 17
[ https://issues.apache.org/jira/browse/FELIX-6433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated FELIX-6433: -- Component/s: Framework > Felix 6.0.4 doesn't work on JDK 17 > -- > > Key: FELIX-6433 > URL: https://issues.apache.org/jira/browse/FELIX-6433 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-6.0.4 >Reporter: Arjan Tijms >Assignee: Karl Pauls >Priority: Major > Fix For: framework-6.0.5 > > > When running on JDK 17, Felix can not reflect on all necessary classes. We > need to define a list of add-opens to make it work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FELIX-6433) Felix 6.0.4 doesn't work on JDK 17
[
https://issues.apache.org/jira/browse/FELIX-6433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-6433:
--
Description:
When running on JDK 17, Felix can not reflect on all necessary
{noformat}
java.lang.NoSuchMethodException:
sun.misc.Unsafe.defineAnonymousClass(java.lang.Class,[B,[Ljava.lang.Object;)
at java.base/java.lang.Class.getMethod(Class.java:2227)
at
org.apache.felix.framework.util.SecureAction.getAccessor(SecureAction.java:1134)
at org.apache.felix.framework.util.SecureAction.(SecureAction.java:86)
at org.apache.felix.framework.Felix.(Felix.java:114)
at
org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:30)
{noformat}
The offending code in question reflectively uses {{sun.misc.Unsafe}}
{code:java}
private static Consumer getAccessor(Class clazz) {
String packageName = clazz.getPackage().getName();
if ("java.net".equals(packageName) ||
"jdk.internal.loader".equals(packageName)) {
if (m_accessorCache == null) {
try {
// Use reflection on Unsafe to avoid having to compile against
it
Class unsafeClass = Class.forName("sun.misc.Unsafe");
Field theUnsafe = unsafeClass.getDeclaredField("theUnsafe");
// NOTE: deep reflection is allowed on sun.misc package for
java 9.
theUnsafe.setAccessible(true);
Object unsafe = theUnsafe.get(null);
// using defineAnonymousClass here because it seems more simple
// to get what we need
Method defineAnonymousClass =
unsafeClass.getMethod("defineAnonymousClass",
Class.class,
byte[].class,
Object[].class);
// The bytes stored in a resource to avoid real loading of it
// (see accessible.src for source).
Class> result =
(Class>)
defineAnonymousClass.invoke(
unsafe, URL.class,
accessor, null);
m_accessorCache = result.getConstructor().newInstance();
} catch (Throwable t) {
t.printStackTrace();
m_accessorCache =
objects -> AccessibleObject.setAccessible(objects, true);
}
}
return m_accessorCache;
}
return objects -> AccessibleObject.setAccessible(objects, true);
}
{code}
For JDK 17+ it may be needed to stop using {{sun.misc.Unsafe}} and use a JDK
replacement?
was:
When running on JDK 17, Felix crashes with the following exception:
{noformat}
java.lang.NoSuchMethodException:
sun.misc.Unsafe.defineAnonymousClass(java.lang.Class,[B,[Ljava.lang.Object;)
at java.base/java.lang.Class.getMethod(Class.java:2227)
at
org.apache.felix.framework.util.SecureAction.getAccessor(SecureAction.java:1134)
at org.apache.felix.framework.util.SecureAction.(SecureAction.java:86)
at org.apache.felix.framework.Felix.(Felix.java:114)
at
org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:30)
{noformat}
The offending code in question reflectively uses {{sun.misc.Unsafe}}
{code:java}
private static Consumer getAccessor(Class clazz) {
String packageName = clazz.getPackage().getName();
if ("java.net".equals(packageName) ||
"jdk.internal.loader".equals(packageName)) {
if (m_accessorCache == null) {
try {
// Use reflection on Unsafe to avoid having to compile against
it
Class unsafeClass = Class.forName("sun.misc.Unsafe");
Field theUnsafe = unsafeClass.getDeclaredField("theUnsafe");
// NOTE: deep reflection is allowed on sun.misc package for
java 9.
theUnsafe.setAccessible(true);
Object unsafe = theUnsafe.get(null);
// using defineAnonymousClass here because it seems more simple
// to get what we need
Method defineAnonymousClass =
unsafeClass.getMethod("defineAnonymousClass",
Class.class,
byte[].class,
Object[].class);
// The bytes stored in a resource to avoid real loading of it
// (see accessible.src for source).
Class> result =
(Class>)
defineAnonymousClass.invoke(
unsafe, URL.class,
accessor, null);
m_accessorCache = result.getConstructor().newInstance();
} catch (Throwable t) {
t.printStackTrace();
m_accessorCache =
[jira] [Updated] (FELIX-6433) Felix 6.0.4 doesn't work on JDK 17
[
https://issues.apache.org/jira/browse/FELIX-6433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-6433:
--
Summary: Felix 6.0.4 doesn't work on JDK 17 (was: Backport - Felix uses
sun.misc.Unsafe, crashed on JDK 17)
> Felix 6.0.4 doesn't work on JDK 17
> --
>
> Key: FELIX-6433
> URL: https://issues.apache.org/jira/browse/FELIX-6433
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-6.0.4
>Reporter: Arjan Tijms
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-6.0.5
>
>
> When running on JDK 17, Felix crashes with the following exception:
>
> {noformat}
> java.lang.NoSuchMethodException:
> sun.misc.Unsafe.defineAnonymousClass(java.lang.Class,[B,[Ljava.lang.Object;)
> at java.base/java.lang.Class.getMethod(Class.java:2227)
> at
> org.apache.felix.framework.util.SecureAction.getAccessor(SecureAction.java:1134)
> at
> org.apache.felix.framework.util.SecureAction.(SecureAction.java:86)
> at org.apache.felix.framework.Felix.(Felix.java:114)
> at
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:30)
> {noformat}
> The offending code in question reflectively uses {{sun.misc.Unsafe}}
> {code:java}
> private static Consumer getAccessor(Class clazz) {
> String packageName = clazz.getPackage().getName();
>
> if ("java.net".equals(packageName) ||
> "jdk.internal.loader".equals(packageName)) {
> if (m_accessorCache == null) {
> try {
> // Use reflection on Unsafe to avoid having to compile
> against it
> Class unsafeClass = Class.forName("sun.misc.Unsafe");
> Field theUnsafe = unsafeClass.getDeclaredField("theUnsafe");
>
> // NOTE: deep reflection is allowed on sun.misc package for
> java 9.
> theUnsafe.setAccessible(true);
> Object unsafe = theUnsafe.get(null);
>
> // using defineAnonymousClass here because it seems more
> simple
> // to get what we need
> Method defineAnonymousClass =
> unsafeClass.getMethod("defineAnonymousClass",
> Class.class,
> byte[].class,
> Object[].class);
>
> // The bytes stored in a resource to avoid real loading of it
> // (see accessible.src for source).
> Class> result =
>(Class>)
>defineAnonymousClass.invoke(
> unsafe, URL.class,
> accessor, null);
> m_accessorCache = result.getConstructor().newInstance();
> } catch (Throwable t) {
> t.printStackTrace();
> m_accessorCache =
> objects -> AccessibleObject.setAccessible(objects, true);
> }
> }
>
> return m_accessorCache;
> }
>
> return objects -> AccessibleObject.setAccessible(objects, true);
> }
> {code}
> For JDK 17+ it may be needed to stop using {{sun.misc.Unsafe}} and use a JDK
> replacement?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6433) Backport - Felix uses sun.misc.Unsafe, crashed on JDK 17
[
https://issues.apache.org/jira/browse/FELIX-6433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-6433:
--
Summary: Backport - Felix uses sun.misc.Unsafe, crashed on JDK 17 (was:
CLONE - Felix uses sun.misc.Unsafe, crashed on JDK 17)
> Backport - Felix uses sun.misc.Unsafe, crashed on JDK 17
>
>
> Key: FELIX-6433
> URL: https://issues.apache.org/jira/browse/FELIX-6433
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-7.0.0
>Reporter: Arjan Tijms
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-6.0.5
>
>
> When running on JDK 17, Felix crashes with the following exception:
>
> {noformat}
> java.lang.NoSuchMethodException:
> sun.misc.Unsafe.defineAnonymousClass(java.lang.Class,[B,[Ljava.lang.Object;)
> at java.base/java.lang.Class.getMethod(Class.java:2227)
> at
> org.apache.felix.framework.util.SecureAction.getAccessor(SecureAction.java:1134)
> at
> org.apache.felix.framework.util.SecureAction.(SecureAction.java:86)
> at org.apache.felix.framework.Felix.(Felix.java:114)
> at
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:30)
> {noformat}
> The offending code in question reflectively uses {{sun.misc.Unsafe}}
> {code:java}
> private static Consumer getAccessor(Class clazz) {
> String packageName = clazz.getPackage().getName();
>
> if ("java.net".equals(packageName) ||
> "jdk.internal.loader".equals(packageName)) {
> if (m_accessorCache == null) {
> try {
> // Use reflection on Unsafe to avoid having to compile
> against it
> Class unsafeClass = Class.forName("sun.misc.Unsafe");
> Field theUnsafe = unsafeClass.getDeclaredField("theUnsafe");
>
> // NOTE: deep reflection is allowed on sun.misc package for
> java 9.
> theUnsafe.setAccessible(true);
> Object unsafe = theUnsafe.get(null);
>
> // using defineAnonymousClass here because it seems more
> simple
> // to get what we need
> Method defineAnonymousClass =
> unsafeClass.getMethod("defineAnonymousClass",
> Class.class,
> byte[].class,
> Object[].class);
>
> // The bytes stored in a resource to avoid real loading of it
> // (see accessible.src for source).
> Class> result =
>(Class>)
>defineAnonymousClass.invoke(
> unsafe, URL.class,
> accessor, null);
> m_accessorCache = result.getConstructor().newInstance();
> } catch (Throwable t) {
> t.printStackTrace();
> m_accessorCache =
> objects -> AccessibleObject.setAccessible(objects, true);
> }
> }
>
> return m_accessorCache;
> }
>
> return objects -> AccessibleObject.setAccessible(objects, true);
> }
> {code}
> For JDK 17+ it may be needed to stop using {{sun.misc.Unsafe}} and use a JDK
> replacement?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6433) CLONE - Felix uses sun.misc.Unsafe, crashed on JDK 17
[
https://issues.apache.org/jira/browse/FELIX-6433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-6433:
--
Fix Version/s: (was: framework-7.0.1)
framework-6.0.5
> CLONE - Felix uses sun.misc.Unsafe, crashed on JDK 17
> -
>
> Key: FELIX-6433
> URL: https://issues.apache.org/jira/browse/FELIX-6433
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-7.0.0
>Reporter: Arjan Tijms
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-6.0.5
>
>
> When running on JDK 17, Felix crashes with the following exception:
>
> {noformat}
> java.lang.NoSuchMethodException:
> sun.misc.Unsafe.defineAnonymousClass(java.lang.Class,[B,[Ljava.lang.Object;)
> at java.base/java.lang.Class.getMethod(Class.java:2227)
> at
> org.apache.felix.framework.util.SecureAction.getAccessor(SecureAction.java:1134)
> at
> org.apache.felix.framework.util.SecureAction.(SecureAction.java:86)
> at org.apache.felix.framework.Felix.(Felix.java:114)
> at
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:30)
> {noformat}
> The offending code in question reflectively uses {{sun.misc.Unsafe}}
> {code:java}
> private static Consumer getAccessor(Class clazz) {
> String packageName = clazz.getPackage().getName();
>
> if ("java.net".equals(packageName) ||
> "jdk.internal.loader".equals(packageName)) {
> if (m_accessorCache == null) {
> try {
> // Use reflection on Unsafe to avoid having to compile
> against it
> Class unsafeClass = Class.forName("sun.misc.Unsafe");
> Field theUnsafe = unsafeClass.getDeclaredField("theUnsafe");
>
> // NOTE: deep reflection is allowed on sun.misc package for
> java 9.
> theUnsafe.setAccessible(true);
> Object unsafe = theUnsafe.get(null);
>
> // using defineAnonymousClass here because it seems more
> simple
> // to get what we need
> Method defineAnonymousClass =
> unsafeClass.getMethod("defineAnonymousClass",
> Class.class,
> byte[].class,
> Object[].class);
>
> // The bytes stored in a resource to avoid real loading of it
> // (see accessible.src for source).
> Class> result =
>(Class>)
>defineAnonymousClass.invoke(
> unsafe, URL.class,
> accessor, null);
> m_accessorCache = result.getConstructor().newInstance();
> } catch (Throwable t) {
> t.printStackTrace();
> m_accessorCache =
> objects -> AccessibleObject.setAccessible(objects, true);
> }
> }
>
> return m_accessorCache;
> }
>
> return objects -> AccessibleObject.setAccessible(objects, true);
> }
> {code}
> For JDK 17+ it may be needed to stop using {{sun.misc.Unsafe}} and use a JDK
> replacement?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (FELIX-6433) CLONE - Felix uses sun.misc.Unsafe, crashed on JDK 17
Karl Pauls created FELIX-6433:
-
Summary: CLONE - Felix uses sun.misc.Unsafe, crashed on JDK 17
Key: FELIX-6433
URL: https://issues.apache.org/jira/browse/FELIX-6433
Project: Felix
Issue Type: Bug
Affects Versions: framework-7.0.0
Reporter: Arjan Tijms
Assignee: Karl Pauls
Fix For: framework-7.0.1
When running on JDK 17, Felix crashes with the following exception:
{noformat}
java.lang.NoSuchMethodException:
sun.misc.Unsafe.defineAnonymousClass(java.lang.Class,[B,[Ljava.lang.Object;)
at java.base/java.lang.Class.getMethod(Class.java:2227)
at
org.apache.felix.framework.util.SecureAction.getAccessor(SecureAction.java:1134)
at org.apache.felix.framework.util.SecureAction.(SecureAction.java:86)
at org.apache.felix.framework.Felix.(Felix.java:114)
at
org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:30)
{noformat}
The offending code in question reflectively uses {{sun.misc.Unsafe}}
{code:java}
private static Consumer getAccessor(Class clazz) {
String packageName = clazz.getPackage().getName();
if ("java.net".equals(packageName) ||
"jdk.internal.loader".equals(packageName)) {
if (m_accessorCache == null) {
try {
// Use reflection on Unsafe to avoid having to compile against
it
Class unsafeClass = Class.forName("sun.misc.Unsafe");
Field theUnsafe = unsafeClass.getDeclaredField("theUnsafe");
// NOTE: deep reflection is allowed on sun.misc package for
java 9.
theUnsafe.setAccessible(true);
Object unsafe = theUnsafe.get(null);
// using defineAnonymousClass here because it seems more simple
// to get what we need
Method defineAnonymousClass =
unsafeClass.getMethod("defineAnonymousClass",
Class.class,
byte[].class,
Object[].class);
// The bytes stored in a resource to avoid real loading of it
// (see accessible.src for source).
Class> result =
(Class>)
defineAnonymousClass.invoke(
unsafe, URL.class,
accessor, null);
m_accessorCache = result.getConstructor().newInstance();
} catch (Throwable t) {
t.printStackTrace();
m_accessorCache =
objects -> AccessibleObject.setAccessible(objects, true);
}
}
return m_accessorCache;
}
return objects -> AccessibleObject.setAccessible(objects, true);
}
{code}
For JDK 17+ it may be needed to stop using {{sun.misc.Unsafe}} and use a JDK
replacement?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6433) Backport - Felix uses sun.misc.Unsafe, crashed on JDK 17
[
https://issues.apache.org/jira/browse/FELIX-6433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-6433:
--
Affects Version/s: (was: framework-7.0.0)
framework-6.0.4
> Backport - Felix uses sun.misc.Unsafe, crashed on JDK 17
>
>
> Key: FELIX-6433
> URL: https://issues.apache.org/jira/browse/FELIX-6433
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-6.0.4
>Reporter: Arjan Tijms
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-6.0.5
>
>
> When running on JDK 17, Felix crashes with the following exception:
>
> {noformat}
> java.lang.NoSuchMethodException:
> sun.misc.Unsafe.defineAnonymousClass(java.lang.Class,[B,[Ljava.lang.Object;)
> at java.base/java.lang.Class.getMethod(Class.java:2227)
> at
> org.apache.felix.framework.util.SecureAction.getAccessor(SecureAction.java:1134)
> at
> org.apache.felix.framework.util.SecureAction.(SecureAction.java:86)
> at org.apache.felix.framework.Felix.(Felix.java:114)
> at
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:30)
> {noformat}
> The offending code in question reflectively uses {{sun.misc.Unsafe}}
> {code:java}
> private static Consumer getAccessor(Class clazz) {
> String packageName = clazz.getPackage().getName();
>
> if ("java.net".equals(packageName) ||
> "jdk.internal.loader".equals(packageName)) {
> if (m_accessorCache == null) {
> try {
> // Use reflection on Unsafe to avoid having to compile
> against it
> Class unsafeClass = Class.forName("sun.misc.Unsafe");
> Field theUnsafe = unsafeClass.getDeclaredField("theUnsafe");
>
> // NOTE: deep reflection is allowed on sun.misc package for
> java 9.
> theUnsafe.setAccessible(true);
> Object unsafe = theUnsafe.get(null);
>
> // using defineAnonymousClass here because it seems more
> simple
> // to get what we need
> Method defineAnonymousClass =
> unsafeClass.getMethod("defineAnonymousClass",
> Class.class,
> byte[].class,
> Object[].class);
>
> // The bytes stored in a resource to avoid real loading of it
> // (see accessible.src for source).
> Class> result =
>(Class>)
>defineAnonymousClass.invoke(
> unsafe, URL.class,
> accessor, null);
> m_accessorCache = result.getConstructor().newInstance();
> } catch (Throwable t) {
> t.printStackTrace();
> m_accessorCache =
> objects -> AccessibleObject.setAccessible(objects, true);
> }
> }
>
> return m_accessorCache;
> }
>
> return objects -> AccessibleObject.setAccessible(objects, true);
> }
> {code}
> For JDK 17+ it may be needed to stop using {{sun.misc.Unsafe}} and use a JDK
> replacement?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (FELIX-6432) NoSuchMethodException: sun.misc.Unsafe.defineAnonymousClass with Felix 7.0.0 and JDK17b25
[
https://issues.apache.org/jira/browse/FELIX-6432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved FELIX-6432.
---
Resolution: Duplicate
Fix in trunk already - will be part of the upcoming 7.0.1 release. Thanks for
reporting!
> NoSuchMethodException: sun.misc.Unsafe.defineAnonymousClass with Felix 7.0.0
> and JDK17b25
> -
>
> Key: FELIX-6432
> URL: https://issues.apache.org/jira/browse/FELIX-6432
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-7.0.0
>Reporter: Ludovic HOCHET
>Priority: Major
>
> When running our application with JDK17b25 we get the following exception:
> {noformat}
> java.lang.NoSuchMethodException:
> sun.misc.Unsafe.defineAnonymousClass(java.lang.Class,[B,[Ljava.lang.Object;)
> at java.base/java.lang.Class.getMethod(Class.java:2227)
> at
> org.apache.felix.framework.util.SecureAction.getAccessor(SecureAction.java:1134)
> at
> org.apache.felix.framework.util.SecureAction.(SecureAction.java:86)
> at org.apache.felix.framework.Felix.(Felix.java:114)
> at
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:30)
> at
> java.lang.NoSuchMethodException:
> sun.misc.Unsafe.defineAnonymousClass(java.lang.Class,[B,[Ljava.lang.Object;)
> at java.base/java.lang.Class.getMethod(Class.java:2227)
> at
> org.apache.felix.framework.util.SecureAction.getAccessor(SecureAction.java:1134)
> at
> org.apache.felix.framework.util.SecureAction.setAccesssible(SecureAction.java:998)
> at
> org.apache.felix.framework.ext.ClassPathExtenderFactory$DefaultClassLoaderExtender.(ClassPathExtenderFactory.java:55)
> at
> org.apache.felix.framework.ExtensionManager.(ExtensionManager.java:152)
> at
> org.apache.felix.framework.Felix.initializeFrameworkProperties(Felix.java:4881)
> at org.apache.felix.framework.Felix.(Felix.java:405)
> at org.apache.felix.framework.Felix.(Felix.java:355)
> at
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:30)
> at
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6416) Special case JDK9+ URLClassLoader url resource loading
[
https://issues.apache.org/jira/browse/FELIX-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-6416:
--
Summary: Special case JDK9+ URLClassLoader url resource loading (was:
FELIX-6326 breaks JDK9+ URLClassLoader by allowing incorrect URL paths)
> Special case JDK9+ URLClassLoader url resource loading
> --
>
> Key: FELIX-6416
> URL: https://issues.apache.org/jira/browse/FELIX-6416
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.4
> Environment: MacOS
>Reporter: Piotr Klimczak
>Assignee: Karl Pauls
>Priority: Blocker
> Fix For: framework-7.0.2, framework-6.0.5
>
>
> '#' sign represents URL fragment and is not valid URL path element.
> As per spec it is not allowed for it to be a part of path and instead must be
> URL encoded.
> So for example for file in location in UNIX systems:
> "/Users/piotrklimczak/test#", the valid URL encoding to load it in Java is:
> {code:java}
> new File(new URL("file:///Users/piotrklimczak/test%23").toURI()) {code}
> Works.
> While
> {code:java}
> new File(new URL("file:///Users/piotrklimczak/test#").toURI()) {code}
> Returns java.lang.IllegalArgumentException in Java: URI has a fragment
> component
> FELIX-6326 effectively allows '#' to be accepted as valid URL path element,
> which in turn breaks JDK9+ URLClassLoader which is using URL fragment (ref)
> to deal with multi-release jars.
> This then breaks pax-transx-tm-narayana installation in Karaf 4.3.1 (which
> uses URLClassLoader).
> In my opinion FELIX-6326 should be reverted and users should be encoding
> special characters correctly in their resource paths as per above example.
> I've taken a risk to mark it as a blocker as effectively it blocks using
> Narayana TM, rendering Karaf 4.3.1 not usable for us.
> Feel free to downgrade it if my judgement failed here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6430) Felix uses sun.misc.Unsafe, crashed on JDK 17
[
https://issues.apache.org/jira/browse/FELIX-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-6430:
--
Fix Version/s: (was: framework-6.0.5)
> Felix uses sun.misc.Unsafe, crashed on JDK 17
> -
>
> Key: FELIX-6430
> URL: https://issues.apache.org/jira/browse/FELIX-6430
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-7.0.0
>Reporter: Arjan Tijms
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.2
>
>
> When running on JDK 17, Felix crashes with the following exception:
>
> {noformat}
> java.lang.NoSuchMethodException:
> sun.misc.Unsafe.defineAnonymousClass(java.lang.Class,[B,[Ljava.lang.Object;)
> at java.base/java.lang.Class.getMethod(Class.java:2227)
> at
> org.apache.felix.framework.util.SecureAction.getAccessor(SecureAction.java:1134)
> at
> org.apache.felix.framework.util.SecureAction.(SecureAction.java:86)
> at org.apache.felix.framework.Felix.(Felix.java:114)
> at
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:30)
> {noformat}
> The offending code in question reflectively uses {{sun.misc.Unsafe}}
> {code:java}
> private static Consumer getAccessor(Class clazz) {
> String packageName = clazz.getPackage().getName();
>
> if ("java.net".equals(packageName) ||
> "jdk.internal.loader".equals(packageName)) {
> if (m_accessorCache == null) {
> try {
> // Use reflection on Unsafe to avoid having to compile
> against it
> Class unsafeClass = Class.forName("sun.misc.Unsafe");
> Field theUnsafe = unsafeClass.getDeclaredField("theUnsafe");
>
> // NOTE: deep reflection is allowed on sun.misc package for
> java 9.
> theUnsafe.setAccessible(true);
> Object unsafe = theUnsafe.get(null);
>
> // using defineAnonymousClass here because it seems more
> simple
> // to get what we need
> Method defineAnonymousClass =
> unsafeClass.getMethod("defineAnonymousClass",
> Class.class,
> byte[].class,
> Object[].class);
>
> // The bytes stored in a resource to avoid real loading of it
> // (see accessible.src for source).
> Class> result =
>(Class>)
>defineAnonymousClass.invoke(
> unsafe, URL.class,
> accessor, null);
> m_accessorCache = result.getConstructor().newInstance();
> } catch (Throwable t) {
> t.printStackTrace();
> m_accessorCache =
> objects -> AccessibleObject.setAccessible(objects, true);
> }
> }
>
> return m_accessorCache;
> }
>
> return objects -> AccessibleObject.setAccessible(objects, true);
> }
> {code}
> For JDK 17+ it may be needed to stop using {{sun.misc.Unsafe}} and use a JDK
> replacement?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6430) Felix uses sun.misc.Unsafe, crashed on JDK 17
[
https://issues.apache.org/jira/browse/FELIX-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17361222#comment-17361222
]
Karl Pauls commented on FELIX-6430:
---
[~dmatej] - thanks for the inspiration. This should be fixed in trunk. I pushed
a new snapshot so you should be able to try it out using 7.1.0-SNAPSHOT.
> Felix uses sun.misc.Unsafe, crashed on JDK 17
> -
>
> Key: FELIX-6430
> URL: https://issues.apache.org/jira/browse/FELIX-6430
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-7.0.0
>Reporter: Arjan Tijms
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.2, framework-6.0.5
>
>
> When running on JDK 17, Felix crashes with the following exception:
>
> {noformat}
> java.lang.NoSuchMethodException:
> sun.misc.Unsafe.defineAnonymousClass(java.lang.Class,[B,[Ljava.lang.Object;)
> at java.base/java.lang.Class.getMethod(Class.java:2227)
> at
> org.apache.felix.framework.util.SecureAction.getAccessor(SecureAction.java:1134)
> at
> org.apache.felix.framework.util.SecureAction.(SecureAction.java:86)
> at org.apache.felix.framework.Felix.(Felix.java:114)
> at
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:30)
> {noformat}
> The offending code in question reflectively uses {{sun.misc.Unsafe}}
> {code:java}
> private static Consumer getAccessor(Class clazz) {
> String packageName = clazz.getPackage().getName();
>
> if ("java.net".equals(packageName) ||
> "jdk.internal.loader".equals(packageName)) {
> if (m_accessorCache == null) {
> try {
> // Use reflection on Unsafe to avoid having to compile
> against it
> Class unsafeClass = Class.forName("sun.misc.Unsafe");
> Field theUnsafe = unsafeClass.getDeclaredField("theUnsafe");
>
> // NOTE: deep reflection is allowed on sun.misc package for
> java 9.
> theUnsafe.setAccessible(true);
> Object unsafe = theUnsafe.get(null);
>
> // using defineAnonymousClass here because it seems more
> simple
> // to get what we need
> Method defineAnonymousClass =
> unsafeClass.getMethod("defineAnonymousClass",
> Class.class,
> byte[].class,
> Object[].class);
>
> // The bytes stored in a resource to avoid real loading of it
> // (see accessible.src for source).
> Class> result =
>(Class>)
>defineAnonymousClass.invoke(
> unsafe, URL.class,
> accessor, null);
> m_accessorCache = result.getConstructor().newInstance();
> } catch (Throwable t) {
> t.printStackTrace();
> m_accessorCache =
> objects -> AccessibleObject.setAccessible(objects, true);
> }
> }
>
> return m_accessorCache;
> }
>
> return objects -> AccessibleObject.setAccessible(objects, true);
> }
> {code}
> For JDK 17+ it may be needed to stop using {{sun.misc.Unsafe}} and use a JDK
> replacement?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (FELIX-6430) Felix uses sun.misc.Unsafe, crashed on JDK 17
[
https://issues.apache.org/jira/browse/FELIX-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved FELIX-6430.
---
Resolution: Fixed
> Felix uses sun.misc.Unsafe, crashed on JDK 17
> -
>
> Key: FELIX-6430
> URL: https://issues.apache.org/jira/browse/FELIX-6430
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-7.0.0
>Reporter: Arjan Tijms
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.2, framework-6.0.5
>
>
> When running on JDK 17, Felix crashes with the following exception:
>
> {noformat}
> java.lang.NoSuchMethodException:
> sun.misc.Unsafe.defineAnonymousClass(java.lang.Class,[B,[Ljava.lang.Object;)
> at java.base/java.lang.Class.getMethod(Class.java:2227)
> at
> org.apache.felix.framework.util.SecureAction.getAccessor(SecureAction.java:1134)
> at
> org.apache.felix.framework.util.SecureAction.(SecureAction.java:86)
> at org.apache.felix.framework.Felix.(Felix.java:114)
> at
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:30)
> {noformat}
> The offending code in question reflectively uses {{sun.misc.Unsafe}}
> {code:java}
> private static Consumer getAccessor(Class clazz) {
> String packageName = clazz.getPackage().getName();
>
> if ("java.net".equals(packageName) ||
> "jdk.internal.loader".equals(packageName)) {
> if (m_accessorCache == null) {
> try {
> // Use reflection on Unsafe to avoid having to compile
> against it
> Class unsafeClass = Class.forName("sun.misc.Unsafe");
> Field theUnsafe = unsafeClass.getDeclaredField("theUnsafe");
>
> // NOTE: deep reflection is allowed on sun.misc package for
> java 9.
> theUnsafe.setAccessible(true);
> Object unsafe = theUnsafe.get(null);
>
> // using defineAnonymousClass here because it seems more
> simple
> // to get what we need
> Method defineAnonymousClass =
> unsafeClass.getMethod("defineAnonymousClass",
> Class.class,
> byte[].class,
> Object[].class);
>
> // The bytes stored in a resource to avoid real loading of it
> // (see accessible.src for source).
> Class> result =
>(Class>)
>defineAnonymousClass.invoke(
> unsafe, URL.class,
> accessor, null);
> m_accessorCache = result.getConstructor().newInstance();
> } catch (Throwable t) {
> t.printStackTrace();
> m_accessorCache =
> objects -> AccessibleObject.setAccessible(objects, true);
> }
> }
>
> return m_accessorCache;
> }
>
> return objects -> AccessibleObject.setAccessible(objects, true);
> }
> {code}
> For JDK 17+ it may be needed to stop using {{sun.misc.Unsafe}} and use a JDK
> replacement?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-5878) Implement resolve timeout
[ https://issues.apache.org/jira/browse/FELIX-5878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated FELIX-5878: -- Fix Version/s: (was: framework-7.0.2) > Implement resolve timeout > - > > Key: FELIX-5878 > URL: https://issues.apache.org/jira/browse/FELIX-5878 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-5.6.10, framework-6.0.0 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > > We should implement a resolve timeout to make sure we don't attempt to > resolve forever. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FELIX-6139) Felix framework does not list it's full capabilties in it's manifest
[
https://issues.apache.org/jira/browse/FELIX-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-6139:
--
Fix Version/s: (was: framework-7.0.2)
> Felix framework does not list it's full capabilties in it's manifest
>
>
> Key: FELIX-6139
> URL: https://issues.apache.org/jira/browse/FELIX-6139
> Project: Felix
> Issue Type: Improvement
> Components: Framework
>Reporter: Raymond Augé
>Priority: Major
>
> Because Felix framework does not list any capabilities _other than_ the
> packages it exports, it cannot be distinguished in a repository other than
> directly by it's bsn. This makes it impossible to select through capabilities
> that only a framework implementation could provide:
> {code}
> osgi.wiring.package;filter:='(osgi.wiring.package=org.osgi.framework.launch)',\
> osgi.service;filter:='(objectClass=org.osgi.service.startlevel.StartLevel)'
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6430) Felix uses sun.misc.Unsafe, crashed on JDK 17
[
https://issues.apache.org/jira/browse/FELIX-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-6430:
--
Fix Version/s: framework-6.0.5
> Felix uses sun.misc.Unsafe, crashed on JDK 17
> -
>
> Key: FELIX-6430
> URL: https://issues.apache.org/jira/browse/FELIX-6430
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-7.0.0
>Reporter: Arjan Tijms
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.2, framework-6.0.5
>
>
> When running on JDK 17, Felix crashes with the following exception:
>
> {noformat}
> java.lang.NoSuchMethodException:
> sun.misc.Unsafe.defineAnonymousClass(java.lang.Class,[B,[Ljava.lang.Object;)
> at java.base/java.lang.Class.getMethod(Class.java:2227)
> at
> org.apache.felix.framework.util.SecureAction.getAccessor(SecureAction.java:1134)
> at
> org.apache.felix.framework.util.SecureAction.(SecureAction.java:86)
> at org.apache.felix.framework.Felix.(Felix.java:114)
> at
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:30)
> {noformat}
> The offending code in question reflectively uses {{sun.misc.Unsafe}}
> {code:java}
> private static Consumer getAccessor(Class clazz) {
> String packageName = clazz.getPackage().getName();
>
> if ("java.net".equals(packageName) ||
> "jdk.internal.loader".equals(packageName)) {
> if (m_accessorCache == null) {
> try {
> // Use reflection on Unsafe to avoid having to compile
> against it
> Class unsafeClass = Class.forName("sun.misc.Unsafe");
> Field theUnsafe = unsafeClass.getDeclaredField("theUnsafe");
>
> // NOTE: deep reflection is allowed on sun.misc package for
> java 9.
> theUnsafe.setAccessible(true);
> Object unsafe = theUnsafe.get(null);
>
> // using defineAnonymousClass here because it seems more
> simple
> // to get what we need
> Method defineAnonymousClass =
> unsafeClass.getMethod("defineAnonymousClass",
> Class.class,
> byte[].class,
> Object[].class);
>
> // The bytes stored in a resource to avoid real loading of it
> // (see accessible.src for source).
> Class> result =
>(Class>)
>defineAnonymousClass.invoke(
> unsafe, URL.class,
> accessor, null);
> m_accessorCache = result.getConstructor().newInstance();
> } catch (Throwable t) {
> t.printStackTrace();
> m_accessorCache =
> objects -> AccessibleObject.setAccessible(objects, true);
> }
> }
>
> return m_accessorCache;
> }
>
> return objects -> AccessibleObject.setAccessible(objects, true);
> }
> {code}
> For JDK 17+ it may be needed to stop using {{sun.misc.Unsafe}} and use a JDK
> replacement?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6416) FELIX-6326 breaks JDK9+ URLClassLoader by allowing incorrect URL paths
[
https://issues.apache.org/jira/browse/FELIX-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-6416:
--
Fix Version/s: framework-6.0.5
> FELIX-6326 breaks JDK9+ URLClassLoader by allowing incorrect URL paths
> --
>
> Key: FELIX-6416
> URL: https://issues.apache.org/jira/browse/FELIX-6416
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-6.0.4
> Environment: MacOS
>Reporter: Piotr Klimczak
>Assignee: Karl Pauls
>Priority: Blocker
> Fix For: framework-7.0.2, framework-6.0.5
>
>
> '#' sign represents URL fragment and is not valid URL path element.
> As per spec it is not allowed for it to be a part of path and instead must be
> URL encoded.
> So for example for file in location in UNIX systems:
> "/Users/piotrklimczak/test#", the valid URL encoding to load it in Java is:
> {code:java}
> new File(new URL("file:///Users/piotrklimczak/test%23").toURI()) {code}
> Works.
> While
> {code:java}
> new File(new URL("file:///Users/piotrklimczak/test#").toURI()) {code}
> Returns java.lang.IllegalArgumentException in Java: URI has a fragment
> component
> FELIX-6326 effectively allows '#' to be accepted as valid URL path element,
> which in turn breaks JDK9+ URLClassLoader which is using URL fragment (ref)
> to deal with multi-release jars.
> This then breaks pax-transx-tm-narayana installation in Karaf 4.3.1 (which
> uses URLClassLoader).
> In my opinion FELIX-6326 should be reverted and users should be encoding
> special characters correctly in their resource paths as per above example.
> I've taken a risk to mark it as a blocker as effectively it blocks using
> Narayana TM, rendering Karaf 4.3.1 not usable for us.
> Feel free to downgrade it if my judgement failed here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6430) Felix uses sun.misc.Unsafe, crashed on JDK 17
[
https://issues.apache.org/jira/browse/FELIX-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17361077#comment-17361077
]
Karl Pauls commented on FELIX-6430:
---
I have a fix for that - will be in the next release. Thanks for reporting!
> Felix uses sun.misc.Unsafe, crashed on JDK 17
> -
>
> Key: FELIX-6430
> URL: https://issues.apache.org/jira/browse/FELIX-6430
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-7.0.0
>Reporter: Arjan Tijms
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.2
>
>
> When running on JDK 17, Felix crashes with the following exception:
>
> {noformat}
> java.lang.NoSuchMethodException:
> sun.misc.Unsafe.defineAnonymousClass(java.lang.Class,[B,[Ljava.lang.Object;)
> at java.base/java.lang.Class.getMethod(Class.java:2227)
> at
> org.apache.felix.framework.util.SecureAction.getAccessor(SecureAction.java:1134)
> at
> org.apache.felix.framework.util.SecureAction.(SecureAction.java:86)
> at org.apache.felix.framework.Felix.(Felix.java:114)
> at
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:30)
> {noformat}
> The offending code in question reflectively uses {{sun.misc.Unsafe}}
> {code:java}
> private static Consumer getAccessor(Class clazz) {
> String packageName = clazz.getPackage().getName();
>
> if ("java.net".equals(packageName) ||
> "jdk.internal.loader".equals(packageName)) {
> if (m_accessorCache == null) {
> try {
> // Use reflection on Unsafe to avoid having to compile
> against it
> Class unsafeClass = Class.forName("sun.misc.Unsafe");
> Field theUnsafe = unsafeClass.getDeclaredField("theUnsafe");
>
> // NOTE: deep reflection is allowed on sun.misc package for
> java 9.
> theUnsafe.setAccessible(true);
> Object unsafe = theUnsafe.get(null);
>
> // using defineAnonymousClass here because it seems more
> simple
> // to get what we need
> Method defineAnonymousClass =
> unsafeClass.getMethod("defineAnonymousClass",
> Class.class,
> byte[].class,
> Object[].class);
>
> // The bytes stored in a resource to avoid real loading of it
> // (see accessible.src for source).
> Class> result =
>(Class>)
>defineAnonymousClass.invoke(
> unsafe, URL.class,
> accessor, null);
> m_accessorCache = result.getConstructor().newInstance();
> } catch (Throwable t) {
> t.printStackTrace();
> m_accessorCache =
> objects -> AccessibleObject.setAccessible(objects, true);
> }
> }
>
> return m_accessorCache;
> }
>
> return objects -> AccessibleObject.setAccessible(objects, true);
> }
> {code}
> For JDK 17+ it may be needed to stop using {{sun.misc.Unsafe}} and use a JDK
> replacement?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (FELIX-6430) Felix uses sun.misc.Unsafe, crashed on JDK 17
[
https://issues.apache.org/jira/browse/FELIX-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reassigned FELIX-6430:
-
Assignee: Karl Pauls
> Felix uses sun.misc.Unsafe, crashed on JDK 17
> -
>
> Key: FELIX-6430
> URL: https://issues.apache.org/jira/browse/FELIX-6430
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-7.0.0
>Reporter: Arjan Tijms
>Assignee: Karl Pauls
>Priority: Major
>
> When running on JDK 17, Felix crashes with the following exception:
>
> {noformat}
> java.lang.NoSuchMethodException:
> sun.misc.Unsafe.defineAnonymousClass(java.lang.Class,[B,[Ljava.lang.Object;)
> at java.base/java.lang.Class.getMethod(Class.java:2227)
> at
> org.apache.felix.framework.util.SecureAction.getAccessor(SecureAction.java:1134)
> at
> org.apache.felix.framework.util.SecureAction.(SecureAction.java:86)
> at org.apache.felix.framework.Felix.(Felix.java:114)
> at
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:30)
> {noformat}
> The offending code in question reflectively uses {{sun.misc.Unsafe}}
> {code:java}
> private static Consumer getAccessor(Class clazz) {
> String packageName = clazz.getPackage().getName();
>
> if ("java.net".equals(packageName) ||
> "jdk.internal.loader".equals(packageName)) {
> if (m_accessorCache == null) {
> try {
> // Use reflection on Unsafe to avoid having to compile
> against it
> Class unsafeClass = Class.forName("sun.misc.Unsafe");
> Field theUnsafe = unsafeClass.getDeclaredField("theUnsafe");
>
> // NOTE: deep reflection is allowed on sun.misc package for
> java 9.
> theUnsafe.setAccessible(true);
> Object unsafe = theUnsafe.get(null);
>
> // using defineAnonymousClass here because it seems more
> simple
> // to get what we need
> Method defineAnonymousClass =
> unsafeClass.getMethod("defineAnonymousClass",
> Class.class,
> byte[].class,
> Object[].class);
>
> // The bytes stored in a resource to avoid real loading of it
> // (see accessible.src for source).
> Class> result =
>(Class>)
>defineAnonymousClass.invoke(
> unsafe, URL.class,
> accessor, null);
> m_accessorCache = result.getConstructor().newInstance();
> } catch (Throwable t) {
> t.printStackTrace();
> m_accessorCache =
> objects -> AccessibleObject.setAccessible(objects, true);
> }
> }
>
> return m_accessorCache;
> }
>
> return objects -> AccessibleObject.setAccessible(objects, true);
> }
> {code}
> For JDK 17+ it may be needed to stop using {{sun.misc.Unsafe}} and use a JDK
> replacement?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6430) Felix uses sun.misc.Unsafe, crashed on JDK 17
[
https://issues.apache.org/jira/browse/FELIX-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-6430:
--
Fix Version/s: framework-7.0.2
> Felix uses sun.misc.Unsafe, crashed on JDK 17
> -
>
> Key: FELIX-6430
> URL: https://issues.apache.org/jira/browse/FELIX-6430
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-7.0.0
>Reporter: Arjan Tijms
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.2
>
>
> When running on JDK 17, Felix crashes with the following exception:
>
> {noformat}
> java.lang.NoSuchMethodException:
> sun.misc.Unsafe.defineAnonymousClass(java.lang.Class,[B,[Ljava.lang.Object;)
> at java.base/java.lang.Class.getMethod(Class.java:2227)
> at
> org.apache.felix.framework.util.SecureAction.getAccessor(SecureAction.java:1134)
> at
> org.apache.felix.framework.util.SecureAction.(SecureAction.java:86)
> at org.apache.felix.framework.Felix.(Felix.java:114)
> at
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:30)
> {noformat}
> The offending code in question reflectively uses {{sun.misc.Unsafe}}
> {code:java}
> private static Consumer getAccessor(Class clazz) {
> String packageName = clazz.getPackage().getName();
>
> if ("java.net".equals(packageName) ||
> "jdk.internal.loader".equals(packageName)) {
> if (m_accessorCache == null) {
> try {
> // Use reflection on Unsafe to avoid having to compile
> against it
> Class unsafeClass = Class.forName("sun.misc.Unsafe");
> Field theUnsafe = unsafeClass.getDeclaredField("theUnsafe");
>
> // NOTE: deep reflection is allowed on sun.misc package for
> java 9.
> theUnsafe.setAccessible(true);
> Object unsafe = theUnsafe.get(null);
>
> // using defineAnonymousClass here because it seems more
> simple
> // to get what we need
> Method defineAnonymousClass =
> unsafeClass.getMethod("defineAnonymousClass",
> Class.class,
> byte[].class,
> Object[].class);
>
> // The bytes stored in a resource to avoid real loading of it
> // (see accessible.src for source).
> Class> result =
>(Class>)
>defineAnonymousClass.invoke(
> unsafe, URL.class,
> accessor, null);
> m_accessorCache = result.getConstructor().newInstance();
> } catch (Throwable t) {
> t.printStackTrace();
> m_accessorCache =
> objects -> AccessibleObject.setAccessible(objects, true);
> }
> }
>
> return m_accessorCache;
> }
>
> return objects -> AccessibleObject.setAccessible(objects, true);
> }
> {code}
> For JDK 17+ it may be needed to stop using {{sun.misc.Unsafe}} and use a JDK
> replacement?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (FELIX-6426) Update Apache Tomcat dependency from felix servlet-api to the latest 8 version
[ https://issues.apache.org/jira/browse/FELIX-6426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls reassigned FELIX-6426: - Assignee: Karl Pauls > Update Apache Tomcat dependency from felix servlet-api to the latest 8 version > -- > > Key: FELIX-6426 > URL: https://issues.apache.org/jira/browse/FELIX-6426 > Project: Felix > Issue Type: Improvement > Components: HTTP Service >Affects Versions: http.servlet-api-1.1.2 >Reporter: Natalia Angulo Herrera >Assignee: Karl Pauls >Priority: Major > Fix For: http.servlet-api-1.1.4 > > > Update Apache Tomcat dependency from felix servlet-api to the latest 8 version -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (FELIX-6426) Update Apache Tomcat dependency from felix servlet-api to the latest 8 version
[ https://issues.apache.org/jira/browse/FELIX-6426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved FELIX-6426. --- Resolution: Fixed Merged - thanks a lot! > Update Apache Tomcat dependency from felix servlet-api to the latest 8 version > -- > > Key: FELIX-6426 > URL: https://issues.apache.org/jira/browse/FELIX-6426 > Project: Felix > Issue Type: Improvement > Components: HTTP Service >Affects Versions: http.servlet-api-1.1.2 >Reporter: Natalia Angulo Herrera >Assignee: Karl Pauls >Priority: Major > Fix For: http.servlet-api-1.1.4 > > > Update Apache Tomcat dependency from felix servlet-api to the latest 8 version -- This message was sent by Atlassian Jira (v8.3.4#803005)
