[jira] [Work logged] (FELIX-6239) Converter should be able to invoke default methods in Interfaces

2020-03-18 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/FELIX-6239?focusedWorklogId=405659=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-405659
 ]

ASF GitHub Bot logged work on FELIX-6239:
-

Author: ASF GitHub Bot
Created on: 18/Mar/20 18:17
Start Date: 18/Mar/20 18:17
Worklog Time Spent: 10m 
  Work Description: stbischof commented on pull request #10: [converter] 
handle default methods - FELIX-6239
URL: https://github.com/apache/felix-dev/pull/10
 
 
   https://issues.apache.org/jira/browse/FELIX-6239
   
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 405659)
Remaining Estimate: 0h
Time Spent: 10m

> Converter should be able to invoke default methods in Interfaces
> 
>
> Key: FELIX-6239
> URL: https://issues.apache.org/jira/browse/FELIX-6239
> Project: Felix
>  Issue Type: New Feature
>  Components: Converter
>Reporter: Stefan Bischof
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Would be nice if Converter could invoke default methods in Interfaces.
> https://github.com/apache/felix-dev/blob/f4304bdea3fb9280ccc0b75dc97275125bc5cbfb/converter/converter/src/main/java/org/osgi/util/converter/ConvertingImpl.java#L807-L820
> I didn't found a proper way to invoke default methods <= and > Java 8.
> Test: 
> {code:java}
>  interface InterfaceWithDefault
>  {
>default String s()
>{
>  return "s";
> }
>  }
> @Test()
> public void testInterfaceWithDefault() throws Exception
> {
>InterfaceWithDefault i = Converters.standardConverter().convert(new 
> HashMap()).to(InterfaceWithDefault.class);
>assertEquals("s", i.s());
> }
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [felix-dev] stbischof opened a new pull request #10: [converter] handle default methods - FELIX-6239

2020-03-18 Thread GitBox
stbischof opened a new pull request #10: [converter] handle default methods - 
FELIX-6239
URL: https://github.com/apache/felix-dev/pull/10
 
 
   https://issues.apache.org/jira/browse/FELIX-6239
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Comment Edited] (FELIX-6243) Link to root Felix object leaks to GC root

2020-03-18 Thread Andrey Davydov (Jira)


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

Andrey Davydov edited comment on FELIX-6243 at 3/18/20, 5:04 PM:
-

as I understand during tests, problem is actual when MSSQL jdbc drivers run 
inside my custom bundle. For all other bundles in our app everything works 
fine. So it is my problem.

But I think, that reafactor ThreadFactory from nested to outer class is good 
idea anyway and it will be good to shutdown ThreadPool Executor during Felix 
stop. It make Felix collectable 60 seconds early, it is good for test routines, 
when felix start/stop repeatedly for every test.

 

 

 


was (Author: andrey.davydov):
as I understand during tests, problem is actual when MSSQL jdbc drivers run 
inside my custom bundle. For all other bundles in our app everything works fine.

But I think, that reafactor ThreadFactory from nested to outer class is good 
idea anyway and it will be good to shutdown ThreadPool Executor during Felix 
stop. It make Felix collectable 60 seconds early, it is good for test routines, 
when felix start/stop repeatedly for every test.

 

 

 

> Link to root Felix object leaks to GC root
> --
>
> Key: FELIX-6243
> URL: https://issues.apache.org/jira/browse/FELIX-6243
> Project: Felix
>  Issue Type: Bug
>Affects Versions: framework-6.0.3
>Reporter: Andrey Davydov
>Priority: Major
> Attachments: felix.png
>
>
> Tested on java8.
> Felix object creates StatefulResolver and then  StatefulResolver  get link to 
> Felix. 
> StatefulResolver creates Executor in getExecutor() using nested class as 
> ThreadFactory (when FelixConstants.RESOLVER_PARALLELISM greater then 1)
>  
> So every thread in Executor has link to Executor
> Executor has link to ThreadFactory
> ThreadFactory has link to StatefulResolver, because it is nested
> StatefulResolver has link to Felix
>  
> And it is the way from GC root to Felix and GC can't collect Felix after 
> Felix.stop() and all external refs to Felix cut.
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (FELIX-6243) Link to root Felix object leaks to GC root

2020-03-18 Thread Andrey Davydov (Jira)


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

Andrey Davydov commented on FELIX-6243:
---

as I understand during tests, problem is actual when MSSQL jdbc drivers run 
inside my custom bundle. For all other bundles in our app everything works fine.

But I think, that reafactor ThreadFactory from nested to outer class is good 
idea anyway and it will be good to shutdown ThreadPool Executor during Felix 
stop. It make Felix collectable 60 seconds early, it is good for test routines, 
when felix start/stop repeatedly for every test.

 

 

 

> Link to root Felix object leaks to GC root
> --
>
> Key: FELIX-6243
> URL: https://issues.apache.org/jira/browse/FELIX-6243
> Project: Felix
>  Issue Type: Bug
>Affects Versions: framework-6.0.3
>Reporter: Andrey Davydov
>Priority: Major
> Attachments: felix.png
>
>
> Tested on java8.
> Felix object creates StatefulResolver and then  StatefulResolver  get link to 
> Felix. 
> StatefulResolver creates Executor in getExecutor() using nested class as 
> ThreadFactory (when FelixConstants.RESOLVER_PARALLELISM greater then 1)
>  
> So every thread in Executor has link to Executor
> Executor has link to ThreadFactory
> ThreadFactory has link to StatefulResolver, because it is nested
> StatefulResolver has link to Felix
>  
> And it is the way from GC root to Felix and GC can't collect Felix after 
> Felix.stop() and all external refs to Felix cut.
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (FELIX-6239) Converter should be able to invoke default methods in Interfaces

2020-03-18 Thread A. J. David Bosschaert (Jira)


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

A. J. David Bosschaert commented on FELIX-6239:
---

[~bisch...@jena.de] wrote:

bq. I didn't found a proper way to invoke default methods <= and > Java 8.

Well they are only there after Java 8, so before Java 8 we don't need to do 
anything.
I guess this can be done via Java 8 reflection somehow...

> Converter should be able to invoke default methods in Interfaces
> 
>
> Key: FELIX-6239
> URL: https://issues.apache.org/jira/browse/FELIX-6239
> Project: Felix
>  Issue Type: New Feature
>  Components: Converter
>Reporter: Stefan Bischof
>Priority: Minor
>
> Would be nice if Converter could invoke default methods in Interfaces.
> https://github.com/apache/felix-dev/blob/f4304bdea3fb9280ccc0b75dc97275125bc5cbfb/converter/converter/src/main/java/org/osgi/util/converter/ConvertingImpl.java#L807-L820
> I didn't found a proper way to invoke default methods <= and > Java 8.
> Test: 
> {code:java}
>  interface InterfaceWithDefault
>  {
>default String s()
>{
>  return "s";
> }
>  }
> @Test()
> public void testInterfaceWithDefault() throws Exception
> {
>InterfaceWithDefault i = Converters.standardConverter().convert(new 
> HashMap()).to(InterfaceWithDefault.class);
>assertEquals("s", i.s());
> }
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (FELIX-6238) Convert to Interface without methods without Exception

2020-03-18 Thread A. J. David Bosschaert (Jira)


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

A. J. David Bosschaert resolved FELIX-6238.
---
Resolution: Fixed

> Convert to Interface without methods without Exception
> --
>
> Key: FELIX-6238
> URL: https://issues.apache.org/jira/browse/FELIX-6238
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Reporter: Stefan Bischof
>Assignee: Stefan Bischof
>Priority: Critical
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
>  
> Converter should Convert to an Interface without methods without Exception
> Example
> {code:java}
> public interface I
> {
> }{code}
>  
> {code:java}
>  I i = Converters.standardConverter()
>  .convert(Map.of("a", "b"))
>  .to(I.class);{code}
> throws Exception:
> {code:java}
> org.osgi.util.converter.ConversionException: Cannot convert a to interface 
> org.apache.felix.atomos.substrate.core.I
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.ConvertingImpl.to(ConvertingImpl.java:212)
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:176)
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:139)
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.ConvertingImpl.convertMapEntryToSingleValue(ConvertingImpl.java:260)
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.ConvertingImpl.to(ConvertingImpl.java:197)
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:176)
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:139)
>  
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (FELIX-6238) Convert to Interface without methods without Exception

2020-03-18 Thread A. J. David Bosschaert (Jira)


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

A. J. David Bosschaert reassigned FELIX-6238:
-

Assignee: Stefan Bischof

> Convert to Interface without methods without Exception
> --
>
> Key: FELIX-6238
> URL: https://issues.apache.org/jira/browse/FELIX-6238
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Reporter: Stefan Bischof
>Assignee: Stefan Bischof
>Priority: Critical
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
>  
> Converter should Convert to an Interface without methods without Exception
> Example
> {code:java}
> public interface I
> {
> }{code}
>  
> {code:java}
>  I i = Converters.standardConverter()
>  .convert(Map.of("a", "b"))
>  .to(I.class);{code}
> throws Exception:
> {code:java}
> org.osgi.util.converter.ConversionException: Cannot convert a to interface 
> org.apache.felix.atomos.substrate.core.I
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.ConvertingImpl.to(ConvertingImpl.java:212)
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:176)
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:139)
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.ConvertingImpl.convertMapEntryToSingleValue(ConvertingImpl.java:260)
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.ConvertingImpl.to(ConvertingImpl.java:197)
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:176)
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:139)
>  
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (FELIX-6238) Convert to Interface without methods without Exception

2020-03-18 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/FELIX-6238?focusedWorklogId=405547=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-405547
 ]

ASF GitHub Bot logged work on FELIX-6238:
-

Author: ASF GitHub Bot
Created on: 18/Mar/20 16:14
Start Date: 18/Mar/20 16:14
Worklog Time Spent: 10m 
  Work Description: bosschaert commented on pull request #9: Convert to 
Interface without methods - FELIX-6238
URL: https://github.com/apache/felix-dev/pull/9
 
 
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 405547)
Time Spent: 20m  (was: 10m)

> Convert to Interface without methods without Exception
> --
>
> Key: FELIX-6238
> URL: https://issues.apache.org/jira/browse/FELIX-6238
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Reporter: Stefan Bischof
>Priority: Critical
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
>  
> Converter should Convert to an Interface without methods without Exception
> Example
> {code:java}
> public interface I
> {
> }{code}
>  
> {code:java}
>  I i = Converters.standardConverter()
>  .convert(Map.of("a", "b"))
>  .to(I.class);{code}
> throws Exception:
> {code:java}
> org.osgi.util.converter.ConversionException: Cannot convert a to interface 
> org.apache.felix.atomos.substrate.core.I
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.ConvertingImpl.to(ConvertingImpl.java:212)
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:176)
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:139)
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.ConvertingImpl.convertMapEntryToSingleValue(ConvertingImpl.java:260)
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.ConvertingImpl.to(ConvertingImpl.java:197)
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:176)
>  at 
> org.osgi.util.converter@1.0.1/org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:139)
>  
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [felix-dev] bosschaert merged pull request #9: Convert to Interface without methods - FELIX-6238

2020-03-18 Thread GitBox
bosschaert merged pull request #9: Convert to Interface without methods - 
FELIX-6238
URL: https://github.com/apache/felix-dev/pull/9
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Commented] (FELIX-6243) Link to root Felix object leaks to GC root

2020-03-18 Thread Karl Pauls (Jira)


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

Karl Pauls commented on FELIX-6243:
---

Hm, I'm not sure I understand the problem yet. The resolver threads should 
timeout after a minute which should make this similar to the  
RESOLVER_PARALLELISM=1 case (after a minute of inactivity). I guess the 
question is what is holding on to the felix object in the first place...

> Link to root Felix object leaks to GC root
> --
>
> Key: FELIX-6243
> URL: https://issues.apache.org/jira/browse/FELIX-6243
> Project: Felix
>  Issue Type: Bug
>Affects Versions: framework-6.0.3
>Reporter: Andrey Davydov
>Priority: Major
> Attachments: felix.png
>
>
> Tested on java8.
> Felix object creates StatefulResolver and then  StatefulResolver  get link to 
> Felix. 
> StatefulResolver creates Executor in getExecutor() using nested class as 
> ThreadFactory (when FelixConstants.RESOLVER_PARALLELISM greater then 1)
>  
> So every thread in Executor has link to Executor
> Executor has link to ThreadFactory
> ThreadFactory has link to StatefulResolver, because it is nested
> StatefulResolver has link to Felix
>  
> And it is the way from GC root to Felix and GC can't collect Felix after 
> Felix.stop() and all external refs to Felix cut.
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (FELIX-6230) Vulnerable dependencies in your project.(CVEs)

2020-03-18 Thread Carsten Ziegeler (Jira)


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

Carsten Ziegeler edited comment on FELIX-6230 at 3/18/20, 1:32 PM:
---

Thanks for reporting this - please note that in most cases these are just build 
time dependencies not runtime dependencies. At runtime newer versions of the 
libraries can be used. Nevertheless we should update the dependencies.

Next time, please create issues per sub project as this makes tracking them 
much easier for users and developers.

I've updated all dependencies, except for this one:

examples/jaas/jdbc-h2 : com.h2database : h2 : 1.3.171 -- > 1.4.198, 1.4.199, 
1.4.200|





was (Author: cziegeler):
Thanks for reporting this - please note that in most cases these are just build 
time dependencies not runtime dependencies. At runtime newer versions of the 
libraries can be used. Nevertheless we should update the dependencies.

Next time, please create issues per sub project as this makes tracking them 
much easier for users and developers.

||Project|Library|Suggest Update||
|-http/sslfilter-|-commons-collections : commons-collections : 3.2.1-|-3.2.2-|
|-http/whiteboard-|-commons-collections : commons-collections : 3.2.1-|-3.2.2-|
|-http/jetty-|-org.eclipse.jetty : 9.4.11.v20180605-|-9.4.26.v20200117-|
|-http/cometd-|-org.eclipse.jetty :* :  9.3.8.v20160314-|-9.4.26.v20200117-|
|-deploymentadmin/itest-|-org.bouncycastle : * : 1.54-|-1.60, 1.61, 1.62, 1.63, 
1.64-|
|-deploymentadmin/itest-|-ch.qos.logback : logback-core-|-> 1.2.0-|
|-deploymentadmin/itest-|-ch.qos.logback : logback-classic-|-> 1.2.0-|
|-deploymentadmin/itest-|-org.ops4j.pax.url : pax-url-aether : 1.6.0-|-2.6.2-|
|-ipojo/manipulator/maven-ipojo-plugin-|-xerces-|-remove-|
|-ipojo/manipulator/maven-ipojo-plugin-|-org.codehaus.plexus : plexus-utils : 
2.0.5-|-3.0.16-|
|-useradmin/itest-|-org.ops4j.pax.runner : pax-runner-no-jcl : 1.7.6-|-1.9.0-|
|ipojo/* (several subprojects)|ch.qos.logback : logback-core : 0.9.x|> 1.2.0|
|ipojo/* (several subprojects)|ch.qos.logback : logback-classic : 0.9.x|> 1.2.0|
|ipojo/distributions/ipojo-webconsole-quicktart|commons-fileupload : 
commons-fileupload : 1.2.2|1.4|
|-scr-|-ch.qos.logback : logback-core : 0.9.29-|-> 1.2.0-|
|-scr-|-ch.qos.logback : logback-classic: 0.9.29-|-> 1.2.0-|
|-systemready-|-ch.qos.logback : logback-core : 1.0.13-|-> 1.2.0-|
|-systemready-|-ch.qos.logback : logback-classic : 1.0.13-|-> 1.2.0-|
|-tools/org.apache.felix.scr.ant-|-org.apache.ant : ant : 1.7.0-|-1.10.0, 
1.10.1, 1.10.2, 1.10.3, 1.10.4, 1.10.5, 1.10.6, 1.10.7, 1.7.1, 1.8.4, 1.9.0, 
1.9.1, 1.9.10, 1.9.11, 1.9.12, 1.9.13, 1.9.14, 1.9.2, 1.9.3, 1.9.4, 1.9.5, 
1.9.6, 1.9.7, 1.9.8, 1.9.9-|
|-tools/maven-bundle-plugin-|-org.codehaus.plexus : plexus-utils : 
3.0.10-|-3.3.0-|
|-tools/maven-bundle-plugin/src/it/embed-multiple-artifacts-|-org.apache.commons
 : commons-compress : 1.10-|-1.19-|
|-tools/maven-bundle-plugin/src/it/dep-reduced-|-org.apache.commons : 
commons-compress : 1.10-|-1.19-|
|examples/jaas/jdbc-h2|com.h2database : h2 : 1.3.171|1.4.198, 1.4.199, 1.4.200|
|-webconsole-plugins/subsystems-|-commons-fileupload : commons-fileupload : 
1.3.2-|-1.4-|
|-.webconsole-plugins/deppack-|-commons-fileupload : commons-fileupload : 
1.3.2-|-1.4-|
|-webconsole-plugins/script-console-|-commons-fileupload : commons-fileupload : 
1.3.2-|-1.4-|
|-webconsole-|-commons-fileupload : commons-fileupload : 1.2.1-|-1.4-|
|-tools/maven-scr-plugin/src/it/*-|-org.apache.sling : org.apache.sling.api : 
2.2.0-|-> 2.9.0-|
|-bundlerepository-|-org.codehaus.woodstox : woodstox-core-asl : 4.0.7-|-4.2.0, 
4.2.1, 4.3.0, 4.4.0, 4.4.1-|



> Vulnerable dependencies in your project.(CVEs)
> --
>
> Key: FELIX-6230
> URL: https://issues.apache.org/jira/browse/FELIX-6230
> Project: Felix
>  Issue Type: Bug
>Reporter: XuCongying
>Priority: Major
>
> Hi,
> I found some CVEs in the library dependencies, which may affect the security 
> of your projects. To prevent potential risk it may cause, I suggest a library 
> update. See details below:
>  Vulnerable Library Version: commons-collections : commons-collections : 3.2.1
>   CVE ID: 
> [CVE-2015-6420](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6420)
>   Import Path: http/sslfilter/pom.xml, http/whiteboard/pom.xml
>   Suggested Safe Versions: 20030418.083655, 20031027.00, 20040102.233541, 
> 20040616, 3.2.2
>  Vulnerable Library Version: org.bouncycastle : bcpkix-jdk15on : 1.54
>   CVE ID: 
> [CVE-2017-13098](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13098),
>  
> [CVE-2016-1000341](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1000341),
>  
> [CVE-2018-1000613](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000613)
>   Import Path: 

[jira] [Comment Edited] (FELIX-6230) Vulnerable dependencies in your project.(CVEs)

2020-03-18 Thread Carsten Ziegeler (Jira)


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

Carsten Ziegeler edited comment on FELIX-6230 at 3/18/20, 1:21 PM:
---

Thanks for reporting this - please note that in most cases these are just build 
time dependencies not runtime dependencies. At runtime newer versions of the 
libraries can be used. Nevertheless we should update the dependencies.

Next time, please create issues per sub project as this makes tracking them 
much easier for users and developers.

||Project|Library|Suggest Update||
|-http/sslfilter-|-commons-collections : commons-collections : 3.2.1-|-3.2.2-|
|-http/whiteboard-|-commons-collections : commons-collections : 3.2.1-|-3.2.2-|
|-http/jetty-|-org.eclipse.jetty : 9.4.11.v20180605-|-9.4.26.v20200117-|
|-http/cometd-|-org.eclipse.jetty :* :  9.3.8.v20160314-|-9.4.26.v20200117-|
|-deploymentadmin/itest-|-org.bouncycastle : * : 1.54-|-1.60, 1.61, 1.62, 1.63, 
1.64-|
|-deploymentadmin/itest-|-ch.qos.logback : logback-core-|-> 1.2.0-|
|-deploymentadmin/itest-|-ch.qos.logback : logback-classic-|-> 1.2.0-|
|-deploymentadmin/itest-|-org.ops4j.pax.url : pax-url-aether : 1.6.0-|-2.6.2-|
|-ipojo/manipulator/maven-ipojo-plugin-|-xerces-|-remove-|
|-ipojo/manipulator/maven-ipojo-plugin-|-org.codehaus.plexus : plexus-utils : 
2.0.5-|-3.0.16-|
|-useradmin/itest-|-org.ops4j.pax.runner : pax-runner-no-jcl : 1.7.6-|-1.9.0-|
|ipojo/* (several subprojects)|ch.qos.logback : logback-core : 0.9.x|> 1.2.0|
|ipojo/* (several subprojects)|ch.qos.logback : logback-classic : 0.9.x|> 1.2.0|
|ipojo/distributions/ipojo-webconsole-quicktart|commons-fileupload : 
commons-fileupload : 1.2.2|1.4|
|-scr-|-ch.qos.logback : logback-core : 0.9.29-|-> 1.2.0-|
|-scr-|-ch.qos.logback : logback-classic: 0.9.29-|-> 1.2.0-|
|-systemready-|-ch.qos.logback : logback-core : 1.0.13-|-> 1.2.0-|
|-systemready-|-ch.qos.logback : logback-classic : 1.0.13-|-> 1.2.0-|
|-tools/org.apache.felix.scr.ant-|-org.apache.ant : ant : 1.7.0-|-1.10.0, 
1.10.1, 1.10.2, 1.10.3, 1.10.4, 1.10.5, 1.10.6, 1.10.7, 1.7.1, 1.8.4, 1.9.0, 
1.9.1, 1.9.10, 1.9.11, 1.9.12, 1.9.13, 1.9.14, 1.9.2, 1.9.3, 1.9.4, 1.9.5, 
1.9.6, 1.9.7, 1.9.8, 1.9.9-|
|-tools/maven-bundle-plugin-|-org.codehaus.plexus : plexus-utils : 
3.0.10-|-3.3.0-|
|-tools/maven-bundle-plugin/src/it/embed-multiple-artifacts-|-org.apache.commons
 : commons-compress : 1.10-|-1.19-|
|-tools/maven-bundle-plugin/src/it/dep-reduced-|-org.apache.commons : 
commons-compress : 1.10-|-1.19-|
|examples/jaas/jdbc-h2|com.h2database : h2 : 1.3.171|1.4.198, 1.4.199, 1.4.200|
|-webconsole-plugins/subsystems-|-commons-fileupload : commons-fileupload : 
1.3.2-|-1.4-|
|-.webconsole-plugins/deppack-|-commons-fileupload : commons-fileupload : 
1.3.2-|-1.4-|
|-webconsole-plugins/script-console-|-commons-fileupload : commons-fileupload : 
1.3.2-|-1.4-|
|-webconsole-|-commons-fileupload : commons-fileupload : 1.2.1-|-1.4-|
|-tools/maven-scr-plugin/src/it/*-|-org.apache.sling : org.apache.sling.api : 
2.2.0-|-> 2.9.0-|
|-bundlerepository-|-org.codehaus.woodstox : woodstox-core-asl : 4.0.7-|-4.2.0, 
4.2.1, 4.3.0, 4.4.0, 4.4.1-|




was (Author: cziegeler):
Thanks for reporting this - please note that in most cases these are just build 
time dependencies not runtime dependencies. At runtime newer versions of the 
libraries can be used. Nevertheless we should update the dependencies.

Next time, please create issues per sub project as this makes tracking them 
much easier for users and developers.

||Project|Library|Suggest Update||
|-http/sslfilter-|-commons-collections : commons-collections : 3.2.1-|-3.2.2-|
|-http/whiteboard-|-commons-collections : commons-collections : 3.2.1-|-3.2.2-|
|-http/jetty-|-org.eclipse.jetty : 9.4.11.v20180605-|-9.4.26.v20200117-|
|-http/cometd-|-org.eclipse.jetty :* :  9.3.8.v20160314-|-9.4.26.v20200117-|
|-deploymentadmin/itest-|-org.bouncycastle : * : 1.54-|-1.60, 1.61, 1.62, 1.63, 
1.64-|
|-deploymentadmin/itest-|-ch.qos.logback : logback-core-|-> 1.2.0-|
|-deploymentadmin/itest-|-ch.qos.logback : logback-classic-|-> 1.2.0-|
|-deploymentadmin/itest-|-org.ops4j.pax.url : pax-url-aether : 1.6.0-|-2.6.2-|
|ipojo/manipulator/maven-ipojo-plugin|org.ops4j.pax.runner : pax-runner-no-jcl 
: 1.7.6|2.12.0|
|ipojo/manipulator/maven-ipojo-plugin|org.codehaus.plexus : plexus-utils : 
2.0.5|3.0.16|
|ipojo/manipulator/maven-ipojo-ant.task|org.ops4j.pax.runner : 
pax-runner-no-jcl : 1.7.6|2.12.0|
|ipojo/* (several subprojects)|ch.qos.logback : logback-core : 0.9.x|> 1.2.0|
|ipojo/* (several subprojects)|ch.qos.logback : logback-classic : 0.9.x|> 1.2.0|
|ipojo/distributions/ipojo-webconsole-quicktart|commons-fileupload : 
commons-fileupload : 1.2.2|1.4|
|-scr-|-ch.qos.logback : logback-core : 0.9.29-|-> 1.2.0-|
|-scr-|-ch.qos.logback : logback-classic: 0.9.29-|-> 1.2.0-|
|-systemready-|-ch.qos.logback : logback-core : 1.0.13-|-> 1.2.0-|

[jira] [Commented] (FELIX-6243) Link to root Felix object leaks to GC root

2020-03-18 Thread Andrey Davydov (Jira)


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

Andrey Davydov commented on FELIX-6243:
---

When FelixConstants.RESOLVER_PARALLELISM is exactly one, Felix object not 
collected by GC too, but I can't understend why. JvisualVM says that it don't 
see GC root for Felix object =((( 

> Link to root Felix object leaks to GC root
> --
>
> Key: FELIX-6243
> URL: https://issues.apache.org/jira/browse/FELIX-6243
> Project: Felix
>  Issue Type: Bug
>Affects Versions: framework-6.0.3
>Reporter: Andrey Davydov
>Priority: Major
> Attachments: felix.png
>
>
> Tested on java8.
> Felix object creates StatefulResolver and then  StatefulResolver  get link to 
> Felix. 
> StatefulResolver creates Executor in getExecutor() using nested class as 
> ThreadFactory (when FelixConstants.RESOLVER_PARALLELISM greater then 1)
>  
> So every thread in Executor has link to Executor
> Executor has link to ThreadFactory
> ThreadFactory has link to StatefulResolver, because it is nested
> StatefulResolver has link to Felix
>  
> And it is the way from GC root to Felix and GC can't collect Felix after 
> Felix.stop() and all external refs to Felix cut.
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (FELIX-6242) Conversion of boolean to Long results in Integer

2020-03-18 Thread A. J. David Bosschaert (Jira)


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

A. J. David Bosschaert reassigned FELIX-6242:
-

Assignee: A. J. David Bosschaert

> Conversion of boolean to Long results in Integer
> 
>
> Key: FELIX-6242
> URL: https://issues.apache.org/jira/browse/FELIX-6242
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Affects Versions: converter-1.0.12
>Reporter: Carsten Ziegeler
>Assignee: A. J. David Bosschaert
>Priority: Major
> Fix For: converter-1.0.14
>
>
> When converting a boolean to a Long, an Integer is returned. the following 
> test fails:
> assertEquals(Long.valueOf(1), 
> converter.convert(Boolean.TRUE).to(Long.class));



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (FELIX-6243) Link to root Felix object leaks to GC root

2020-03-18 Thread Andrey Davydov (Jira)
Andrey Davydov created FELIX-6243:
-

 Summary: Link to root Felix object leaks to GC root
 Key: FELIX-6243
 URL: https://issues.apache.org/jira/browse/FELIX-6243
 Project: Felix
  Issue Type: Bug
Affects Versions: framework-6.0.3
Reporter: Andrey Davydov
 Attachments: felix.png

Tested on java8.

Felix object creates StatefulResolver and then  StatefulResolver  get link to 
Felix. 

StatefulResolver creates Executor in getExecutor() using nested class as 
ThreadFactory (when FelixConstants.RESOLVER_PARALLELISM greater then 1)

 

So every thread in Executor has link to Executor

Executor has link to ThreadFactory

ThreadFactory has link to StatefulResolver, because it is nested

StatefulResolver has link to Felix

 

And it is the way from GC root to Felix and GC can't collect Felix after 
Felix.stop() and all external refs to Felix cut.

 

 

 

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (FELIX-6242) Conversion of boolean to Long results in Integer

2020-03-18 Thread Carsten Ziegeler (Jira)
Carsten Ziegeler created FELIX-6242:
---

 Summary: Conversion of boolean to Long results in Integer
 Key: FELIX-6242
 URL: https://issues.apache.org/jira/browse/FELIX-6242
 Project: Felix
  Issue Type: Bug
  Components: Converter
Affects Versions: converter-1.0.12
Reporter: Carsten Ziegeler
 Fix For: converter-1.0.14


When converting a boolean to a Long, an Integer is returned. the following test 
fails:

assertEquals(Long.valueOf(1), 
converter.convert(Boolean.TRUE).to(Long.class));





--
This message was sent by Atlassian Jira
(v8.3.4#803005)