[jira] [Updated] (FELIX-6664) Comment Removing on JSONSupport MemoryInefficient

2023-11-09 Thread Karl Pauls (Jira)


 [ 
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

2023-05-02 Thread Karl Pauls (Jira)


 [ 
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

2023-04-14 Thread Karl Pauls (Jira)


 [ 
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

2023-02-07 Thread Karl Pauls (Jira)


 [ 
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

2022-06-09 Thread Karl Pauls (Jira)


 [ 
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

2022-05-26 Thread Karl Pauls (Jira)


 [ 
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

2022-05-26 Thread Karl Pauls (Jira)
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

2022-05-26 Thread Karl Pauls (Jira)


 [ 
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

2022-05-25 Thread Karl Pauls (Jira)


 [ 
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

2022-05-25 Thread Karl Pauls (Jira)


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

2022-05-25 Thread Karl Pauls (Jira)


 [ 
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

2022-05-25 Thread Karl Pauls (Jira)


 [ 
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

2022-05-25 Thread Karl Pauls (Jira)


 [ 
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

2022-05-25 Thread Karl Pauls (Jira)


 [ 
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

2022-05-23 Thread Karl Pauls (Jira)


[ 
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

2022-05-20 Thread Karl Pauls (Jira)


 [ 
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

2022-05-19 Thread Karl Pauls (Jira)


[ 
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

2022-05-19 Thread Karl Pauls (Jira)


[ 
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

2022-05-19 Thread Karl Pauls (Jira)


 [ 
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

2022-05-19 Thread Karl Pauls (Jira)
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

2022-05-19 Thread Karl Pauls (Jira)


 [ 
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

2022-05-19 Thread Karl Pauls (Jira)


 [ 
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

2022-05-19 Thread Karl Pauls (Jira)


 [ 
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

2022-05-19 Thread Karl Pauls (Jira)


 [ 
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

2022-05-19 Thread Karl Pauls (Jira)


 [ 
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

2022-05-19 Thread Karl Pauls (Jira)


 [ 
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

2022-05-19 Thread Karl Pauls (Jira)


[ 
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

2022-05-19 Thread Karl Pauls (Jira)


 [ 
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

2022-05-19 Thread Karl Pauls (Jira)


[ 
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

2022-05-19 Thread Karl Pauls (Jira)


 [ 
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

2022-05-18 Thread Karl Pauls (Jira)


[ 
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

2022-05-17 Thread Karl Pauls (Jira)


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

2022-05-13 Thread Karl Pauls (Jira)


 [ 
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

2022-05-13 Thread Karl Pauls (Jira)


 [ 
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

2022-05-13 Thread Karl Pauls (Jira)


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

2022-04-25 Thread Karl Pauls (Jira)


 [ 
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

2022-02-07 Thread Karl Pauls (Jira)


[ 
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

2021-12-21 Thread Karl Pauls (Jira)
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)

2021-12-14 Thread Karl Pauls (Jira)


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

2021-12-14 Thread Karl Pauls (Jira)


 [ 
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

2021-12-06 Thread Karl Pauls (Jira)


 [ 
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

2021-12-06 Thread Karl Pauls (Jira)


 [ 
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

2021-12-06 Thread Karl Pauls (Jira)


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

2021-12-06 Thread Karl Pauls (Jira)


 [ 
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

2021-12-06 Thread Karl Pauls (Jira)


 [ 
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

2021-12-02 Thread Karl Pauls (Jira)


 [ 
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

2021-12-02 Thread Karl Pauls (Jira)


 [ 
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

2021-12-02 Thread Karl Pauls (Jira)


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

2021-11-03 Thread Karl Pauls (Jira)


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

2021-10-27 Thread Karl Pauls (Jira)


 [ 
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

2021-10-27 Thread Karl Pauls (Jira)


[ 
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

2021-10-27 Thread Karl Pauls (Jira)


 [ 
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

2021-10-27 Thread Karl Pauls (Jira)


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

2021-10-26 Thread Karl Pauls (Jira)


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

2021-10-26 Thread Karl Pauls (Jira)


 [ 
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

2021-09-23 Thread Karl Pauls (Jira)


 [ 
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

2021-09-23 Thread Karl Pauls (Jira)


 [ 
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

2021-09-23 Thread Karl Pauls (Jira)


 [ 
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

2021-09-21 Thread Karl Pauls (Jira)


[ 
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

2021-09-21 Thread Karl Pauls (Jira)


 [ 
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

2021-09-06 Thread Karl Pauls (Jira)


[ 
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

2021-09-06 Thread Karl Pauls (Jira)


 [ 
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

2021-09-06 Thread Karl Pauls (Jira)


[ 
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

2021-09-06 Thread Karl Pauls (Jira)


 [ 
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

2021-08-08 Thread Karl Pauls (Jira)


[ 
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

2021-06-21 Thread Karl Pauls (Jira)


 [ 
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

2021-06-21 Thread Karl Pauls (Jira)


 [ 
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

2021-06-21 Thread Karl Pauls (Jira)


 [ 
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

2021-06-21 Thread Karl Pauls (Jira)


 [ 
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

2021-06-21 Thread Karl Pauls (Jira)


 [ 
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

2021-06-15 Thread Karl Pauls (Jira)


 [ 
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

2021-06-15 Thread Karl Pauls (Jira)


 [ 
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

2021-06-12 Thread Karl Pauls (Jira)


[ 
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

2021-06-11 Thread Karl Pauls (Jira)


 [ 
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

2021-06-11 Thread Karl Pauls (Jira)


 [ 
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

2021-06-11 Thread Karl Pauls (Jira)


 [ 
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

2021-06-11 Thread Karl Pauls (Jira)


 [ 
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

2021-06-11 Thread Karl Pauls (Jira)


 [ 
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

2021-06-11 Thread Karl Pauls (Jira)


 [ 
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

2021-06-11 Thread Karl Pauls (Jira)
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

2021-06-11 Thread Karl Pauls (Jira)


 [ 
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

2021-06-11 Thread Karl Pauls (Jira)


 [ 
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

2021-06-10 Thread Karl Pauls (Jira)


 [ 
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

2021-06-10 Thread Karl Pauls (Jira)


 [ 
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

2021-06-10 Thread Karl Pauls (Jira)


[ 
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

2021-06-10 Thread Karl Pauls (Jira)


 [ 
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

2021-06-10 Thread Karl Pauls (Jira)


 [ 
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

2021-06-10 Thread Karl Pauls (Jira)


 [ 
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

2021-06-10 Thread Karl Pauls (Jira)


 [ 
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

2021-06-10 Thread Karl Pauls (Jira)


 [ 
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

2021-06-10 Thread Karl Pauls (Jira)


[ 
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

2021-06-10 Thread Karl Pauls (Jira)


 [ 
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

2021-06-10 Thread Karl Pauls (Jira)


 [ 
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

2021-06-09 Thread Karl Pauls (Jira)


 [ 
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

2021-06-09 Thread Karl Pauls (Jira)


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


[jira] [Updated] (FELIX-6426) Update Apache Tomcat dependency from felix servlet-api to the latest 8 version

2021-06-09 Thread Karl Pauls (Jira)


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

Karl Pauls updated FELIX-6426:
--
Component/s: (was: Felix Commons)
 HTTP Service

> 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
>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] [Updated] (FELIX-6426) Update Apache Tomcat dependency from felix servlet-api to the latest 8 version

2021-06-09 Thread Karl Pauls (Jira)


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

Karl Pauls updated FELIX-6426:
--
Fix Version/s: http.servlet-api-1.1.4

> 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: Felix Commons
>Affects Versions: http.servlet-api-1.1.2
>Reporter: Natalia Angulo Herrera
>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] [Updated] (FELIX-6426) Update Apache Tomcat dependency from felix servlet-api to the latest 8 version

2021-06-09 Thread Karl Pauls (Jira)


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

Karl Pauls updated FELIX-6426:
--
Issue Type: Improvement  (was: Bug)

> 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: Felix Commons
>Reporter: Natalia Angulo Herrera
>Priority: Major
>
> 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] [Updated] (FELIX-6426) Update Apache Tomcat dependency from felix servlet-api to the latest 8 version

2021-06-09 Thread Karl Pauls (Jira)


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

Karl Pauls updated FELIX-6426:
--
Affects Version/s: http.servlet-api-1.1.2

> 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: Felix Commons
>Affects Versions: http.servlet-api-1.1.2
>Reporter: Natalia Angulo Herrera
>Priority: Major
>
> 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-6416) FELIX-6326 breaks JDK9+ URLClassLoader by allowing incorrect URL paths

2021-05-26 Thread Karl Pauls (Jira)


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

Karl Pauls resolved FELIX-6416.
---
Resolution: Fixed

Fixed in https://github.com/apache/felix-dev/pull/77

Thanks a lot for the report and the test case!

> 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
>
>
> '#' 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)


  1   2   3   4   5   6   7   8   9   10   >