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

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6242:
-

Author: ASF GitHub Bot
Created on: 17/Apr/20 08:01
Start Date: 17/Apr/20 08:01
Worklog Time Spent: 10m 
  Work Description: bosschaert commented on pull request #18: FELIX-6242 
Conversion of boolean to Long results in Integer
URL: https://github.com/apache/felix-dev/pull/18
 
 
   
 

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: 423982)
Time Spent: 20m  (was: 10m)

> 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
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> 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] [Work logged] (FELIX-6242) Conversion of boolean to Long results in Integer

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6242:
-

Author: ASF GitHub Bot
Created on: 16/Apr/20 13:06
Start Date: 16/Apr/20 13:06
Worklog Time Spent: 10m 
  Work Description: bosschaert commented on pull request #18: FELIX-6242 
Conversion of boolean to Long results in Integer
URL: https://github.com/apache/felix-dev/pull/18
 
 
   
 

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: 423443)
Remaining Estimate: 0h
Time Spent: 10m

> 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
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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] [Work logged] (FELIX-6203) Make bundleplugin pom.proterties reproducible

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6203:
-

Author: ASF GitHub Bot
Created on: 12/Apr/20 13:01
Start Date: 12/Apr/20 13:01
Worklog Time Spent: 10m 
  Work Description: doggy-dev commented on pull request #17: FELIX-6203 
skip adding comments in pom.properties
URL: https://github.com/apache/felix-dev/pull/17
 
 
   
 

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: 420936)
Remaining Estimate: 0h
Time Spent: 10m

> Make bundleplugin pom.proterties reproducible
> -
>
> Key: FELIX-6203
> URL: https://issues.apache.org/jira/browse/FELIX-6203
> Project: Felix
>  Issue Type: Improvement
>  Components: Maven Bundle Plugin
>Reporter: Bernhard M. Wiedemann
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> For reproducible builds, we want to be able to produce the same results from 
> the same inputs.
> However the pom.properties file generted by maven-plugin-bundle varied across 
> builds, because it contains a timestamp.
> [https://github.com/apache/felix/pull/209] fixes this for us.
> The alternative approach would be to drop the timestamp, if it is not needed.
>  



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

[jira] [Work logged] (FELIX-6058) Add Bundle-Activator metadata back to gogo-jline

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6058:
-

Author: ASF GitHub Bot
Created on: 09/Apr/20 20:55
Start Date: 09/Apr/20 20:55
Worklog Time Spent: 10m 
  Work Description: glimmerveen commented on pull request #16: [FELIX-6058] 
Re-added Bundle-Activator to gogo.jline bundle
URL: https://github.com/apache/felix-dev/pull/16
 
 
   Currently the gogo.jline bundle stand-alone is not usable. There was already 
an open PR on the felix repo (https://github.com/apache/felix/pull/184), but 
given the state of the felix repository, this will not get merged.
   
   This PR ensures that the Bundle-Activator headers is set as instruction on 
the maven-bundle-plugin, making the gogo.jline bundle both usable stand-alone 
and in the context of Karaf's shell.core where the gogo.jline package is 
inlined.
 

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: 419747)
Remaining Estimate: 0h
Time Spent: 10m

> Add Bundle-Activator metadata back to gogo-jline
> 
>
> Key: FELIX-6058
> URL: https://issues.apache.org/jira/browse/FELIX-6058
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo JLine
>Affects Versions: gogo.jline-1.1.4
>Reporter: Pleeplop
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> gogo-jline is missing bundle-activator metadata so the bundle isn't working 
> anymore.
>  
> I know the header was removed because of integration problem with karaf 
> FELIX-6030
>  
> Maybe a karaf compatible change could be to use bundle-activator bnd 
> instruction from maven-bundle-plugin.
>  see [https://github.com/apache/felix/pull/184]



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

[jira] [Work logged] (FELIX-6251) Possible NullPointerException when DependencyManager.m_tracker is null

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6251:
-

Author: ASF GitHub Bot
Created on: 08/Apr/20 15:32
Start Date: 08/Apr/20 15:32
Worklog Time Spent: 10m 
  Work Description: tjwatson commented on pull request #15: FELIX-6251 - 
Fix NPE in DependencyManager for references to m_tracker
URL: https://github.com/apache/felix-dev/pull/15
 
 
   
 

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: 418632)
Time Spent: 20m  (was: 10m)

> Possible NullPointerException when DependencyManager.m_tracker is null
> --
>
> Key: FELIX-6251
> URL: https://issues.apache.org/jira/browse/FELIX-6251
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.16
>Reporter: Tom Watson
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The following NullPointerException can happen once the tracker is closed and 
> nulled out.  There are a few places where a null check is done.  But there 
> are many more where the null 
> org.apache.felix.scr.impl.manager.DependencyManager.m_tracker would cause an 
> NPE.
> {code:java}
> FrameworkEvent ERROR java.lang.NullPointerException
>   at 
> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:379)
>   at 
> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:296)
>   at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1242)
>   at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1137)
>   at 
> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.untrack(ServiceTracker.java:997)
>   at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1176)
>   at 
> org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.serviceChanged(BundleComponentActivator.java:125)
>   at 
> org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:113)
>   at 
> org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:985)
>   at 
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
>   at 
> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:151)
>   at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:896)
>   at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:834)
>   at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:227)
> {code}



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

[jira] [Work logged] (FELIX-6251) Possible NullPointerException when DependencyManager.m_tracker is null

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6251:
-

Author: ASF GitHub Bot
Created on: 08/Apr/20 15:31
Start Date: 08/Apr/20 15:31
Worklog Time Spent: 10m 
  Work Description: tjwatson commented on pull request #15: FELIX-6251 - 
Fix NPE in DependencyManager for references to m_tracker
URL: https://github.com/apache/felix-dev/pull/15
 
 
   Need to ensure the tracker is not null.  Also calls to tracked can
   return null and need to be handled without an NPE
 

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: 418631)
Remaining Estimate: 0h
Time Spent: 10m

> Possible NullPointerException when DependencyManager.m_tracker is null
> --
>
> Key: FELIX-6251
> URL: https://issues.apache.org/jira/browse/FELIX-6251
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.16
>Reporter: Tom Watson
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The following NullPointerException can happen once the tracker is closed and 
> nulled out.  There are a few places where a null check is done.  But there 
> are many more where the null 
> org.apache.felix.scr.impl.manager.DependencyManager.m_tracker would cause an 
> NPE.
> {code:java}
> FrameworkEvent ERROR java.lang.NullPointerException
>   at 
> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:379)
>   at 
> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:296)
>   at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1242)
>   at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1137)
>   at 
> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.untrack(ServiceTracker.java:997)
>   at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1176)
>   at 
> org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.serviceChanged(BundleComponentActivator.java:125)
>   at 
> org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:113)
>   at 
> org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:985)
>   at 
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
>   at 
> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:151)
>   at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:896)
>   at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:834)
>   at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:227)
> {code}



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

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

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6239:
-

Author: ASF GitHub Bot
Created on: 26/Mar/20 12:32
Start Date: 26/Mar/20 12:32
Worklog Time Spent: 10m 
  Work Description: bosschaert commented on pull request #10: [converter] 
handle default methods - FELIX-6239
URL: https://github.com/apache/felix-dev/pull/10
 
 
   
 

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: 410236)
Time Spent: 20m  (was: 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: 20m
>  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)

[jira] [Work logged] (FELIX-6246) Package External Utility Packages inside referenced Healthcheck Bundles

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6246:
-

Author: ASF GitHub Bot
Created on: 22/Mar/20 23:22
Start Date: 22/Mar/20 23:22
Worklog Time Spent: 10m 
  Work Description: amitjoy commented on pull request #11: [FELIX-6246] 
Packaged External Library Packages inside the Bundles
URL: https://github.com/apache/felix-dev/pull/11
 
 
   For small IoT devices, it would definitely matter if someone needs to 
introduce Apache Commons Lang (~500KB) to use Felix Health Checks even if none 
of the other runtime bundles don't use Apache Commons. Therefore, this MR 
packages all external library packages inside the referenced bundles.
 

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: 407679)
Remaining Estimate: 0h
Time Spent: 10m

> Package External Utility Packages inside referenced Healthcheck Bundles
> ---
>
> Key: FELIX-6246
> URL: https://issues.apache.org/jira/browse/FELIX-6246
> Project: Felix
>  Issue Type: Improvement
>  Components: Health Checks
>Affects Versions: healthcheck.core 2.0.6
>Reporter: Amit Mondal
>Priority: Minor
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> For small IoT devices, it would definitely matter if someone needs to 
> introduce Apache Commons Lang (~500KB) to use Felix Health Checks even if 
> none of the other runtime bundles don't use Apache Commons library. 
> Therefore, this MR packages all external library packages inside the 
> referenced bundles.



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

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

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

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

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

[jira] [Work logged] (FELIX-6193) Update maven-archiver + plexus-utils

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6193:
-

Author: ASF GitHub Bot
Created on: 15/Mar/20 10:53
Start Date: 15/Mar/20 10:53
Worklog Time Spent: 10m 
  Work Description: cziegeler commented on pull request #8: FELIX-6193 - 
Update maven-archiver + plexus-utils
URL: https://github.com/apache/felix-dev/pull/8
 
 
   
 

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: 403571)
Remaining Estimate: 0h
Time Spent: 10m

> Update maven-archiver + plexus-utils
> 
>
> Key: FELIX-6193
> URL: https://issues.apache.org/jira/browse/FELIX-6193
> Project: Felix
>  Issue Type: Improvement
>  Components: Maven Bundle Plugin
>Reporter: Colm O hEigeartaigh
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: maven-bundle-plugin-4.2.2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should update the versions of maven-archiver + plexus-utils in the 
> maven-bundle-plugin to remove the CVEs:
> plexus-archiver-2.8.1.jar 
> (pkg:maven/org.codehaus.plexus/plexus-archiver@2.8.1, 
> cpe:2.3:a:plexus-archiver_project:plexus-archiver:2.8.1:*:*:*:*:*:*:*) : 
> CVE-2018-1002200
> plexus-utils-3.0.10.jar (pkg:maven/org.codehaus.plexus/plexus-utils@3.0.10, 
> cpe:2.3:a:plexus-utils_project:plexus-utils:3.0.10:*:*:*:*:*:*:*) : 
> CVE-2017-1000487, Directory traversal in org.codehaus.plexus.util.Expand, 
> Possible XML Injection



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

[jira] [Work logged] (FELIX-6234) Update Snakeyaml

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6234:
-

Author: ASF GitHub Bot
Created on: 14/Mar/20 14:23
Start Date: 14/Mar/20 14:23
Worklog Time Spent: 10m 
  Work Description: cziegeler commented on pull request #2: FELIX-6234 - 
Updating Snakeyaml
URL: https://github.com/apache/felix-dev/pull/2
 
 
   
 

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: 403441)
Time Spent: 20m  (was: 10m)

> Update Snakeyaml
> 
>
> Key: FELIX-6234
> URL: https://issues.apache.org/jira/browse/FELIX-6234
> Project: Felix
>  Issue Type: Improvement
>  Components: Converter
>Reporter: Colm O hEigeartaigh
>Priority: Major
> Fix For: converter-1.0.14
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Please update Snakeyaml to 1.26, as it fixes some potential security issues 
> regarding denial of service attacks. I will submit a PR.



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

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

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6238:
-

Author: ASF GitHub Bot
Created on: 09/Mar/20 19:35
Start Date: 09/Mar/20 19:35
Worklog Time Spent: 10m 
  Work Description: stbischof commented on pull request #9: Convert to 
Interface without methods - FELIX-6238
URL: https://github.com/apache/felix-dev/pull/9
 
 
   https://issues.apache.org/jira/browse/FELIX-6238
 

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: 400325)
Remaining Estimate: 0h
Time Spent: 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: 10m
>  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-6228) Atomos maven plugin

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6228:
-

Author: ASF GitHub Bot
Created on: 06/Mar/20 19:10
Start Date: 06/Mar/20 19:10
Worklog Time Spent: 10m 
  Work Description: tjwatson commented on pull request #1: FELIX-6228: 
Atomos maven plugin
URL: https://github.com/apache/felix-atomos/pull/1
 
 
   
 

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: 399300)
Remaining Estimate: 0h
Time Spent: 10m

> Atomos maven plugin
> ---
>
> Key: FELIX-6228
> URL: https://issues.apache.org/jira/browse/FELIX-6228
> Project: Felix
>  Issue Type: Improvement
>  Components: Atomos
>Reporter: Tom Watson
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Copied from https://github.com/tjwatson/atomos/issues/15
> For example, the following can be considered for an Atomos maven plugin:
> - Reflection Configuration: the org.atomos.substrate.config.ReflectConfig 
> class provides a gogo command reflectConfig that generates a json config for 
> specifying the required class reflection information for Bundle activators 
> and for OSGi Declarative services. It would be good to have a plugin that can 
> do the same when creating a native image.
> - Resource Configuration: the org.atomos.substrate.config.ResourceConfig 
> class provides a gogo command resourceConfig that generates a json config for 
> specifying the required resource matching patterns to include package 
> resources in a native image. It would be good to have a plugin that can do 
> the same when creating a native image.
> - Bundle Entry Configuration: the 
> org.atomos.substrate.config.SubstrateService class provides a gogo command 
> substrateBundles that can be used to extract the non-package resources used 
> for bundle entry content (for example META-INF/MANIFEST.MF and Declarative 
> Service XML files) into a directory structure that can be used during native 
> image generation to include a index for Atomos to discover the included 
> bundles and their entries. It would be good to have a plugin that can do the 
> same when creating a native image.



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

[jira] [Work logged] (FELIX-6232) Allow Webconsole to install parallel versions of bundles

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6232:
-

Author: ASF GitHub Bot
Created on: 06/Mar/20 07:46
Start Date: 06/Mar/20 07:46
Worklog Time Spent: 10m 
  Work Description: cziegeler commented on pull request #1: FELIX-6232 - 
adding option to install parallel version of bundle
URL: https://github.com/apache/felix-dev/pull/1
 
 
   
 

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: 398973)
Time Spent: 20m  (was: 10m)

> Allow Webconsole to install parallel versions of bundles
> 
>
> Key: FELIX-6232
> URL: https://issues.apache.org/jira/browse/FELIX-6232
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Affects Versions: webconsole-4.3.16
>Reporter: Dominik Süß
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> While Felix supports running multiple versions of the same bundle in parallel 
> and visualization of the bundles works fine the BundlesServlet as well as the 
> dialogs to upload a bundle currently provide no control over installing vs 
> updating of a version.
> The intended behavior of patch proposal is to add a corresponding flag - the 
> implementation already updates always the last bundle found in case of an 
> update when multiple versions are already present - this behavior is not 
> being touched.



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

[jira] [Work logged] (FELIX-6227) Atomos index runtime independent of native image

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6227:
-

Author: ASF GitHub Bot
Created on: 05/Mar/20 19:30
Start Date: 05/Mar/20 19:30
Worklog Time Spent: 10m 
  Work Description: tjwatson commented on pull request #6: FELIX-6227 - Add 
configuration for path to Atomos index
URL: https://github.com/apache/felix-atomos/pull/6
 
 
   
 

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: 398624)
Time Spent: 20m  (was: 10m)

> Atomos index runtime independent of native image
> 
>
> Key: FELIX-6227
> URL: https://issues.apache.org/jira/browse/FELIX-6227
> Project: Felix
>  Issue Type: Improvement
>  Components: Atomos
>Reporter: Karl Pauls
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I think it might be nice to have a general atomos runtime that works from an 
> index file similar to what is currently available with the 
> AtomosRuntimeSubstrate. 
> Something like: if an index file is given (or present) it reads the bundle 
> identities from the index files as well as their resource locations. 



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

[jira] [Work logged] (FELIX-6227) Atomos index runtime independent of native image

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6227:
-

Author: ASF GitHub Bot
Created on: 05/Mar/20 17:49
Start Date: 05/Mar/20 17:49
Worklog Time Spent: 10m 
  Work Description: tjwatson commented on pull request #6: FELIX-6227 - Add 
configuration for path to Atomos index
URL: https://github.com/apache/felix-atomos/pull/6
 
 
   Instead of using an atomos.load.index option with FIRST|IGNORE
   this change adds an option atomos.index.path that allows
   the specification of a path to the Atomos index resource.
   If set to IGNORE then no Atomos index is loaded.
   The path may begin with a '/', but is not required
   to.  The value is the path to the index resource
   and the parent path of the resource will be used
   as the relative path for all the bundle indexes
 

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: 398547)
Remaining Estimate: 0h
Time Spent: 10m

> Atomos index runtime independent of native image
> 
>
> Key: FELIX-6227
> URL: https://issues.apache.org/jira/browse/FELIX-6227
> Project: Felix
>  Issue Type: Improvement
>  Components: Atomos
>Reporter: Karl Pauls
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I think it might be nice to have a general atomos runtime that works from an 
> index file similar to what is currently available with the 
> AtomosRuntimeSubstrate. 
> Something like: if an index file is given (or present) it reads the bundle 
> identities from the index files as well as their resource locations. 



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

[jira] [Work logged] (FELIX-6237) Add ModuleConnector META-INF/services support

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6237:
-

Author: ASF GitHub Bot
Created on: 05/Mar/20 14:18
Start Date: 05/Mar/20 14:18
Worklog Time Spent: 10m 
  Work Description: tjwatson commented on pull request #5: FELIX-6237
URL: https://github.com/apache/felix-atomos/pull/5
 
 
   
 

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: 398391)
Time Spent: 20m  (was: 10m)

> Add ModuleConnector META-INF/services support
> -
>
> Key: FELIX-6237
> URL: https://issues.apache.org/jira/browse/FELIX-6237
> Project: Felix
>  Issue Type: Improvement
>  Components: Atomos
>Reporter: Tom Watson
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> It would be useful to allow Atomos's ModuleConnector implementation to be 
> discovered using the ServiceLoader.  This would allow a general framework 
> launcher find an available ModuleConnector implementation and launch a 
> framework with the connector without any knowledge of the connector details.



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

[jira] [Work logged] (FELIX-6237) Add ModuleConnector META-INF/services support

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6237:
-

Author: ASF GitHub Bot
Created on: 05/Mar/20 14:09
Start Date: 05/Mar/20 14:09
Worklog Time Spent: 10m 
  Work Description: tjwatson commented on pull request #5: FELIX-6237
URL: https://github.com/apache/felix-atomos/pull/5
 
 
   
 

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: 398388)
Remaining Estimate: 0h
Time Spent: 10m

> Add ModuleConnector META-INF/services support
> -
>
> Key: FELIX-6237
> URL: https://issues.apache.org/jira/browse/FELIX-6237
> Project: Felix
>  Issue Type: Improvement
>  Components: Atomos
>Reporter: Tom Watson
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It would be useful to allow Atomos's ModuleConnector implementation to be 
> discovered using the ServiceLoader.  This would allow a general framework 
> launcher find an available ModuleConnector implementation and launch a 
> framework with the connector without any knowledge of the connector details.



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

[jira] [Work logged] (FELIX-6235) Disallow DTDs when reading OBR repository files

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6235:
-

Author: ASF GitHub Bot
Created on: 03/Mar/20 07:59
Start Date: 03/Mar/20 07:59
Worklog Time Spent: 10m 
  Work Description: coheigea commented on pull request #4: FELIX-6235 - 
Disallow DTDs when reading OBR repository files
URL: https://github.com/apache/felix-dev/pull/4
 
 
   
 

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: 396685)
Remaining Estimate: 0h
Time Spent: 10m

> Disallow DTDs when reading OBR repository files
> ---
>
> Key: FELIX-6235
> URL: https://issues.apache.org/jira/browse/FELIX-6235
> Project: Felix
>  Issue Type: Improvement
>  Components: Maven Bundle Plugin
>Reporter: Colm O hEigeartaigh
>Priority: Major
> Fix For: maven-bundle-plugin-4.2.2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Disallow DTDs when reading OBR repository files, as it could lead to security 
> issues.



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

[jira] [Work logged] (FELIX-6234) Update Snakeyaml

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6234:
-

Author: ASF GitHub Bot
Created on: 03/Mar/20 07:43
Start Date: 03/Mar/20 07:43
Worklog Time Spent: 10m 
  Work Description: coheigea commented on pull request #2: FELIX-6234 - 
Updating Snakeyaml
URL: https://github.com/apache/felix-dev/pull/2
 
 
   
 

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: 396674)
Remaining Estimate: 0h
Time Spent: 10m

> Update Snakeyaml
> 
>
> Key: FELIX-6234
> URL: https://issues.apache.org/jira/browse/FELIX-6234
> Project: Felix
>  Issue Type: Improvement
>  Components: Converter
>Reporter: Colm O hEigeartaigh
>Priority: Major
> Fix For: converter-1.0.14
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Please update Snakeyaml to 1.26, as it fixes some potential security issues 
> regarding denial of service attacks. I will submit a PR.



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

[jira] [Work logged] (FELIX-6232) Allow Webconsole to install parallel versions of bundles

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6232:
-

Author: ASF GitHub Bot
Created on: 02/Mar/20 10:42
Start Date: 02/Mar/20 10:42
Worklog Time Spent: 10m 
  Work Description: DominikSuess commented on pull request #1: FELIX-6232 - 
adding option to install parallel version of bundle
URL: https://github.com/apache/felix-dev/pull/1
 
 
   
 

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: 396039)
Remaining Estimate: 0h
Time Spent: 10m

> Allow Webconsole to install parallel versions of bundles
> 
>
> Key: FELIX-6232
> URL: https://issues.apache.org/jira/browse/FELIX-6232
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Affects Versions: webconsole-4.3.16
>Reporter: Dominik Süß
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> While Felix supports running multiple versions of the same bundle in parallel 
> and visualization of the bundles works fine the BundlesServlet as well as the 
> dialogs to upload a bundle currently provide no control over installing vs 
> updating of a version.
> The intended behavior of patch proposal is to add a corresponding flag - the 
> implementation already updates always the last bundle found in case of an 
> update when multiple versions are already present - this behavior is not 
> being touched.



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

[jira] [Work logged] (FELIX-6226) Code cleanup for Atomos

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6226:
-

Author: ASF GitHub Bot
Created on: 27/Feb/20 17:16
Start Date: 27/Feb/20 17:16
Worklog Time Spent: 10m 
  Work Description: tjwatson commented on pull request #3: FELIX-6226: Code 
clean up
URL: https://github.com/apache/felix-atomos/pull/3
 
 
   
 

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: 394326)
Time Spent: 20m  (was: 10m)

> Code cleanup for Atomos
> ---
>
> Key: FELIX-6226
> URL: https://issues.apache.org/jira/browse/FELIX-6226
> Project: Felix
>  Issue Type: Improvement
>  Components: Atomos
>Reporter: Tom Watson
>Assignee: Tom Watson
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Doing some minor clean up of the code:
> - Move LoaderType from AtomosRuntime to AtomosLayer
> - remove unnecessary public modifier
> - Use method references where possible
> - Remove extra lambdas where possible
> - Fix up javadoc link issues
> - remove unused params
> - remove unused methods/constructors
> Using this issue to see if linking works from felix-atomos github repository 
> PRs



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

[jira] [Work logged] (FELIX-6226) Code cleanup for Atomos

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on FELIX-6226:
-

Author: ASF GitHub Bot
Created on: 27/Feb/20 17:11
Start Date: 27/Feb/20 17:11
Worklog Time Spent: 10m 
  Work Description: tjwatson commented on pull request #3: FELIX-6226: Code 
clean up
URL: https://github.com/apache/felix-atomos/pull/3
 
 
   - Move LoaderType from AtomosRuntime to AtomosLayer
   - remove unnecessary public modifier
   - Use method references where possible
   - Remove extra lambdas where possible
   - Fix up javadoc link issues
   - remove unused params
   - remove unused methods/constructors
 

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: 394324)
Remaining Estimate: 0h
Time Spent: 10m

> Code cleanup for Atomos
> ---
>
> Key: FELIX-6226
> URL: https://issues.apache.org/jira/browse/FELIX-6226
> Project: Felix
>  Issue Type: Improvement
>  Components: Atomos
>Reporter: Tom Watson
>Assignee: Tom Watson
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Doing some minor clean up of the code:
> - Move LoaderType from AtomosRuntime to AtomosLayer
> - remove unnecessary public modifier
> - Use method references where possible
> - Remove extra lambdas where possible
> - Fix up javadoc link issues
> - remove unused params
> - remove unused methods/constructors
> Using this issue to see if linking works from felix-atomos github repository 
> PRs



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

[jira] [Commented] (FELIX-6038) Need gogo command, runtime, and shell to support java 7

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6038:
---

Github user sebratton closed the pull request at:

https://github.com/apache/felix/pull/171


> Need gogo command, runtime, and shell to support java 7 
> 
>
> Key: FELIX-6038
> URL: https://issues.apache.org/jira/browse/FELIX-6038
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo Command, Gogo Runtime, Gogo Shell
>Affects Versions: gogo.runtime-1.1.2, gogo.shell-1.1.2, gogo.command-1.1.0
>Reporter: Samuel Bratton
>Assignee: Thomas Watson
>Priority: Minor
> Fix For: gogo.shell-1.1.4, gogo.command-1.1.2, gogo.runtime-1.1.4
>
>
> Command, runtime, and shell currently produce bundles that require JavaSE 
> version=1.8. We need to continue support for java 7 a bit longer. This will 
> need updates to some poms and minor syntax changes to convert code that uses 
> new Java 8 syntax back to Java 7.



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

[jira] [Commented] (FELIX-6046) gogo shell interrupts wrong thread on Activator stop

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6046:
---

Github user sebratton closed the pull request at:

https://github.com/apache/felix/pull/181


> gogo shell interrupts wrong thread on Activator stop 
> -
>
> Key: FELIX-6046
> URL: https://issues.apache.org/jira/browse/FELIX-6046
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo Shell
>Affects Versions: gogo.shell-1.1.2
>Reporter: Samuel Bratton
>Assignee: Thomas Watson
>Priority: Minor
> Fix For: gogo.shell-1.1.4
>
>
> gogo shell interrupts the thread calling stop rather than the shell thread 
> itself.



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

[jira] [Commented] (FELIX-6050) Get rid of SinglePrototypeRefPair

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6050:
---

GitHub user tjwatson opened a pull request:

https://github.com/apache/felix/pull/182

FELIX-6050 - remove SinglePrototypeRefPair



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tjwatson/felix FELIX-6050

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/182.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #182


commit 1d2a62c36a7bb5ce8cf538447fcbe9d85265c343
Author: Tom Watson 
Date:   2019-02-06T21:13:33Z

FELIX-6050 - remove SinglePrototypeRefPair




> Get rid of SinglePrototypeRefPair
> -
>
> Key: FELIX-6050
> URL: https://issues.apache.org/jira/browse/FELIX-6050
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.14
>Reporter: Thomas Watson
>Assignee: Thomas Watson
>Priority: Minor
>
> The SCR implementation has two classes that keep track of prototype 
> references from a service component:
> org.apache.felix.scr.impl.manager.MultiplePrototypeRefPair
> org.apache.felix.scr.impl.manager.SinglePrototypeRefPair
> I'm not entirely sure what motivated the need for Multiple vs. Single here.  
> The Single one gets used if the service component is a singleton service 
> component.  The Multiple one gets used for service components that are bundle 
> or prototype service components.  The Multiple one will key the instances of 
> the referenced prototype service by the ComponentContextImpl for the 
> requiring service component.  That way if there are multiple instances of the 
> requiring component each instance (and therefore ComponentContextImpl 
> insteance) will get a unique instance of the required prototype service.
> It appears the thought was that some optimizations could have been realized 
> for the Singleton case so it has a specialized class separate from Multiple.  
> But I think this only makes the code hard to understand and I question that 
> the current state of the code is providing any performance improvement.
> I propose we remove the SinglePrototypeRefPair and rename the 
> MultiplePrototypeRefPair to be simply PrototypeRefPair.



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

[jira] [Commented] (FELIX-6043) ClassNotFoundException org.osgi.util.function.Function

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6043:
---

Github user pleeplop closed the pull request at:

https://github.com/apache/felix/pull/177


> ClassNotFoundException org.osgi.util.function.Function
> --
>
> Key: FELIX-6043
> URL: https://issues.apache.org/jira/browse/FELIX-6043
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.14
>Reporter: Pleeplop
>Priority: Minor
> Fix For: scr-2.1.16
>
>
> The manifest declares org.osgi.util.function as exported but it is not 
> embedded.
> A quick fix is to declare the dependency with maven
> see https://github.com/apache/felix/pull/177



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

[jira] [Commented] (FELIX-6044) Component deactivation does not cause reference services to be ungotten

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6044:
---

Github user tjwatson closed the pull request at:

https://github.com/apache/felix/pull/180


> Component deactivation does not cause reference services to be ungotten
> ---
>
> Key: FELIX-6044
> URL: https://issues.apache.org/jira/browse/FELIX-6044
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.14
>Reporter: Thomas Watson
>Priority: Major
>
> The fix to FELIX-5974 has caused an issue for the default reference scope of 
> bundle.  When a component has a simple @Reference and that component is 
> deactivated the services that it references will not be ungotten by SCR.  
> This causes all kinds of issues for use counting of the consumed service.
> The issue is that 
> org.apache.felix.scr.impl.manager.DependencyManager.close(ComponentContextImpl,
>  EdgeInfo) is calling RefPair.unsetServiceObject now for all RefPair types.  
> The RefPair types MultiplePrototypeRefPair and SinglePrototypeRefPair were 
> updated to have unsetServiceObject to also have that service be ungotten.  
> But the default SingleRefPair type was not.  This causes issues when 
> ultimately the DependencyManagers are deactivated later which then closes the 
> customizer for the dependency and 
> org.apache.felix.scr.impl.manager.DependencyManager.AbstractCustomizer.ungetService(RefPair  T>) is called.  By this time there will now be a null service and it will 
> not be ungotten.



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

[jira] [Commented] (FELIX-6046) gogo shell interrupts wrong thread on Activator stop

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6046:
---

GitHub user sebratton opened a pull request:

https://github.com/apache/felix/pull/181

FELIX-6046 - fix gogo shell thread interrupt.

proposed fix for FELIX-6046

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sebratton/felix gogo-shell-6046

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/181.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #181


commit ff104db634f48d9009eb51f156400586272c3a29
Author: Samuel E Bratton 
Date:   2019-02-01T21:27:58Z

FELIX-6046 - fix gogo shell thread interrupt.




> gogo shell interrupts wrong thread on Activator stop 
> -
>
> Key: FELIX-6046
> URL: https://issues.apache.org/jira/browse/FELIX-6046
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo Shell
>Affects Versions: gogo.shell-1.1.2
>Reporter: Samuel Bratton
>Priority: Minor
>
> gogo shell interrupts the thread calling stop rather than the shell thread 
> itself.



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

[jira] [Commented] (FELIX-6044) Component deactivation does not cause reference services to be ungotten

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6044:
---

GitHub user tjwatson opened a pull request:

https://github.com/apache/felix/pull/180

FELIX-6044 - avoid calling ungetServiceObject too early for simple case of 
SingleRefPair



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tjwatson/felix FELIX-6044

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/180.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #180


commit bf7f727dc812458133e1f8814a9f4ae6b5df3988
Author: Tom Watson 
Date:   2019-02-01T17:28:38Z

FELIX-6044 - avoid calling ungetServiceObject too early for simple case
of SingleRefPair




> Component deactivation does not cause reference services to be ungotten
> ---
>
> Key: FELIX-6044
> URL: https://issues.apache.org/jira/browse/FELIX-6044
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.14
>Reporter: Thomas Watson
>Priority: Major
>
> The fix to FELIX-5974 has caused an issue for the default reference scope of 
> bundle.  When a component has a simple @Reference and that component is 
> deactivated the services that it references will not be ungotten by SCR.  
> This causes all kinds of issues for use counting of the consumed service.
> The issue is that 
> org.apache.felix.scr.impl.manager.DependencyManager.close(ComponentContextImpl,
>  EdgeInfo) is calling RefPair.unsetServiceObject now for all RefPair types.  
> The RefPair types MultiplePrototypeRefPair and SinglePrototypeRefPair were 
> updated to have unsetServiceObject to also have that service be ungotten.  
> But the default SingleRefPair type was not.  This causes issues when 
> ultimately the DependencyManagers are deactivated later which then closes the 
> customizer for the dependency and 
> org.apache.felix.scr.impl.manager.DependencyManager.AbstractCustomizer.ungetService(RefPair  T>) is called.  By this time there will now be a null service and it will 
> not be ungotten.



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

[jira] [Commented] (FELIX-6042) Lists are not recognized as typed properties

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6042:
---

Github user asfgit closed the pull request at:

https://github.com/apache/felix/pull/176


> Lists are not recognized as typed properties
> 
>
> Key: FELIX-6042
> URL: https://issues.apache.org/jira/browse/FELIX-6042
> Project: Felix
>  Issue Type: Bug
>  Components: Utils
>Reporter: Christoph Fiehe
>Assignee: David Bosschaert
>Priority: Major
>
> The issue is related to TypedProperties and appears only when lists are 
> deserialized. It was originally reported by 
> [t...@quarendon.net|mailto:t...@quarendon.net] (Apparent bug storing 
> collection in org.apache.felix.utils.properties.TypedProperties) in the Felix 
> mailing list.
> The class org.apache.felix.utils.properties.Properties.PropertiesReader uses 
> an incomplete regular expression, so that lists are not recognized as typed 
> properties and get interpreted as strings.
> Extending the regular expression will fix the issue.



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

[jira] [Commented] (FELIX-6042) Lists are not recognized as typed properties

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6042:
---

GitHub user cfiehe opened a pull request:

https://github.com/apache/felix/pull/176

FELIX-6042: Fix the regular expression, so that lists get recognized …

…as typed properties.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cfiehe/felix FELIX-6042

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/176.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #176


commit 3bea403475bbd66fd3eb82e1765901d542c10d7a
Author: Christoph Fiehe 
Date:   2019-01-30T16:08:46Z

FELIX-6042: Fix the regular expression, so that lists get recognized as 
typed properties.




> Lists are not recognized as typed properties
> 
>
> Key: FELIX-6042
> URL: https://issues.apache.org/jira/browse/FELIX-6042
> Project: Felix
>  Issue Type: Bug
>  Components: Utils
>Reporter: Christoph Fiehe
>Priority: Major
>
> The issue is related to TypedProperties and appears only when lists are 
> deserialized. It was originally reported by 
> [t...@quarendon.net|mailto:t...@quarendon.net] (Apparent bug storing 
> collection in org.apache.felix.utils.properties.TypedProperties) in the Felix 
> mailing list.
> The class org.apache.felix.utils.properties.Properties.PropertiesReader uses 
> an incomplete regular expression, so that lists are not recognized as typed 
> properties and get interpreted as strings.
> Extending the regular expression will fix the issue.



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

[jira] [Commented] (FELIX-6029) Felix Http Jetty does not have a service capability for the HttpService

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6029:
---

Github user timothyjward closed the pull request at:

https://github.com/apache/felix/pull/175


> Felix Http Jetty does not have a service capability for the HttpService
> ---
>
> Key: FELIX-6029
> URL: https://issues.apache.org/jira/browse/FELIX-6029
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-4.0.6
>Reporter: Timothy Ward
>Priority: Major
> Fix For: http.jetty-4.0.8
>
>
> The Felix Http Jetty bundle provides an HttpService service but does not have 
> a Provide-Capability for it. This prevents bundles which use the HttpService 
> from resolving when used with Felix Http Jetty.



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

[jira] [Commented] (FELIX-6041) scr gogo commands require gogo runtime to be present when scr resolves

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6041:
---

Github user tjwatson closed the pull request at:

https://github.com/apache/felix/pull/174


> scr gogo commands require gogo runtime to be present when scr resolves
> --
>
> Key: FELIX-6041
> URL: https://issues.apache.org/jira/browse/FELIX-6041
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.14
>Reporter: Thomas Watson
>Priority: Major
>
> I cannot seem to find the actual jira issue this was worked under.  At some 
> point in the 2.1 version of SCR the scr gogo commands were significantly 
> reworked with the following commit:
> https://github.com/apache/felix/commit/d6232f91ffb386835d3ae22dd2f003c854310ef5
> This put a hard dependency on the gogo package 
> {{org.apache.felix.service.command}} package.  The dependency was declared as 
> optional, but this means that if the gogo.runtime bundle is 
> installed/resolved after the scr bundle then the scr bundle will never wire 
> to the package for the Converter service.  SCR then proceeds to register a 
> Converter service using a ServiceFactory, but this service cannot be used for 
> two reasons.
> # For the gogo.runtime to see the service the scr bundle must be wired to the 
> service package otherwise the framework will not give the service to the 
> gogo.runtime.
> # Even if the gogo.runtime could see the service the ServiceFactory would 
> ultimately fail to create the Converter service object with some class 
> loading error.
> This ultimately leaves the scr commands that require DTO conversion/formating 
> by the gogo.runtime to fall back to using toString which prints out confusing 
> (for the user) json like output.
> Perhaps some use of late binding dynamic import could be used, but that would 
> require some kind of trigger to SCR to load the class from the package to 
> force the dynamic wire and then registration of the Converter service.  Even 
> then it would cause a re-resolve of the SCR bundle if the gogo bundles are 
> then uninstalled which I would like to avoid.
> One possible solution is to track the CommandProcessor service and when it is 
> available then register a Proxy Converter service with the BundleContext of 
> the bundle that registers the CommandProcessor.  This way we do not need a 
> hard requirement on the {{org.apache.felix.service.command}} in order to get 
> good output from the scr gogo commands.



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

[jira] [Commented] (FELIX-6029) Felix Http Jetty does not have a service capability for the HttpService

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6029:
---

GitHub user timothyjward opened a pull request:

https://github.com/apache/felix/pull/175

Add a capability advertising that the HttpService is provided by this…

… bundle

Fixes FELIX-6029

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/timothyjward/felix httpservice-cap

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/175.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #175


commit 0e1bc622c612c6e4f7ce075cfedb7a3d72063609
Author: Tim Ward 
Date:   2019-01-29T16:16:58Z

Add a capability advertising that the HttpService is provided by this bundle




> Felix Http Jetty does not have a service capability for the HttpService
> ---
>
> Key: FELIX-6029
> URL: https://issues.apache.org/jira/browse/FELIX-6029
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-4.0.6
>Reporter: Timothy Ward
>Priority: Major
> Fix For: http.jetty-4.0.8
>
>
> The Felix Http Jetty bundle provides an HttpService service but does not have 
> a Provide-Capability for it. This prevents bundles which use the HttpService 
> from resolving when used with Felix Http Jetty.



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

[jira] [Commented] (FELIX-6041) scr gogo commands require gogo runtime to be present when scr resolves

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6041:
---

GitHub user tjwatson opened a pull request:

https://github.com/apache/felix/pull/174

FELIX-6041 - allow scr commands to work when gogo.runtime resolves later

Remove the optional dependency on org.apache.felix.service.command
package to allow gogo.runtime to be installed and resolved after the SCR
bundle.  This allows the scr gogo commands to work while avoiding a wire
from the SCR bundle to the gogo packages.

This is achieved by generating a proxy instance of the Converter service
and registering it with the gogo.runtime BundleContext (or what ever
bundle registers the CommandProcessor service.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tjwatson/felix FELIX-6041

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/174.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #174


commit 787f792afaaabcf6f5b50e1af4c496814f3c8364
Author: Tom Watson 
Date:   2019-01-29T15:45:12Z

FELIX-6041 - allow scr commands to work when gogo.runtime resolves later

Remove the optional dependency on org.apache.felix.service.command
package to allow gogo.runtime to be installed and resolved after the SCR
bundle.  This allows the scr gogo commands to work while avoiding a wire
from the SCR bundle to the gogo packages.

This is achieved by generating a proxy instance of the Converter service
and registering it with the gogo.runtime BundleContext (or what ever
bundle registers the CommandProcessor service.




> scr gogo commands require gogo runtime to be present when scr resolves
> --
>
> Key: FELIX-6041
> URL: https://issues.apache.org/jira/browse/FELIX-6041
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.14
>Reporter: Thomas Watson
>Priority: Major
>
> I cannot seem to find the actual jira issue this was worked under.  At some 
> point in the 2.1 version of SCR the scr gogo commands were significantly 
> reworked with the following commit:
> https://github.com/apache/felix/commit/d6232f91ffb386835d3ae22dd2f003c854310ef5
> This put a hard dependency on the gogo package 
> {{org.apache.felix.service.command}} package.  The dependency was declared as 
> optional, but this means that if the gogo.runtime bundle is 
> installed/resolved after the scr bundle then the scr bundle will never wire 
> to the package for the Converter service.  SCR then proceeds to register a 
> Converter service using a ServiceFactory, but this service cannot be used for 
> two reasons.
> # For the gogo.runtime to see the service the scr bundle must be wired to the 
> service package otherwise the framework will not give the service to the 
> gogo.runtime.
> # Even if the gogo.runtime could see the service the ServiceFactory would 
> ultimately fail to create the Converter service object with some class 
> loading error.
> This ultimately leaves the scr commands that require DTO conversion/formating 
> by the gogo.runtime to fall back to using toString which prints out confusing 
> (for the user) json like output.
> Perhaps some use of late binding dynamic import could be used, but that would 
> require some kind of trigger to SCR to load the class from the package to 
> force the dynamic wire and then registration of the Converter service.  Even 
> then it would cause a re-resolve of the SCR bundle if the gogo bundles are 
> then uninstalled which I would like to avoid.
> One possible solution is to track the CommandProcessor service and when it is 
> available then register a Proxy Converter service with the BundleContext of 
> the bundle that registers the CommandProcessor.  This way we do not need a 
> hard requirement on the {{org.apache.felix.service.command}} in order to get 
> good output from the scr gogo commands.



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

[jira] [Commented] (FELIX-6026) SCR command problems

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6026:
---

Github user tjwatson closed the pull request at:

https://github.com/apache/felix/pull/172


> SCR command problems
> 
>
> Key: FELIX-6026
> URL: https://issues.apache.org/jira/browse/FELIX-6026
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.14
>Reporter: Brent Daniel
>Priority: Major
>
> There are a couple of problems resulting from the changes to SCR commands in 
> [https://github.com/apache/felix/pull/130] .
> First, ScrInfo is not registered as a service when ds.info.service=true is 
> specified in config admin. The core issue is that the setScrCommand method of 
> ScrConfigurationImpl is never called, so it will not be available in this 
> block around line 208:
> {code:java}
> if ( scrCommand != null )
> {
> scrCommand.updateProvideScrInfoService( infoAsService() );
> }
> {code}
> That can be fixed by adding the following to the Activator.doStart() method 
> (though I haven't spent much time thinking about better solutions):
> {code:java}
> m_configuration.setScrCommand(m_componentCommands);
> {code}
> Second, the ScrInfo list() and info() implementation no longer accept a null 
> component ID. The javadoc for ScrInfo still indicates that a null ID will 
> give information for all components. We have found this function invaluable 
> for dumping the state of every component, so it would be nice to get this 
> back.
>  



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

[jira] [Commented] (FELIX-6026) SCR command problems

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6026:
---

GitHub user tjwatson opened a pull request:

https://github.com/apache/felix/pull/172

FELIX-6026 - Fix ScrInfo service issues



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tjwatson/felix FELIX-6026

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/172.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #172


commit 07c1ebab265fc88fb95f34efad8a51e73220b009
Author: Tom Watson 
Date:   2019-01-25T14:27:14Z

FELIX-6026 - Fix ScrInfo service issues




> SCR command problems
> 
>
> Key: FELIX-6026
> URL: https://issues.apache.org/jira/browse/FELIX-6026
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.14
>Reporter: Brent Daniel
>Priority: Major
>
> There are a couple of problems resulting from the changes to SCR commands in 
> [https://github.com/apache/felix/pull/130] .
> First, ScrInfo is not registered as a service when ds.info.service=true is 
> specified in config admin. The core issue is that the setScrCommand method of 
> ScrConfigurationImpl is never called, so it will not be available in this 
> block around line 208:
> {code:java}
> if ( scrCommand != null )
> {
> scrCommand.updateProvideScrInfoService( infoAsService() );
> }
> {code}
> That can be fixed by adding the following to the Activator.doStart() method 
> (though I haven't spent much time thinking about better solutions):
> {code:java}
> m_configuration.setScrCommand(m_componentCommands);
> {code}
> Second, the ScrInfo list() and info() implementation no longer accept a null 
> component ID. The javadoc for ScrInfo still indicates that a null ID will 
> give information for all components. We have found this function invaluable 
> for dumping the state of every component, so it would be nice to get this 
> back.
>  



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

[jira] [Commented] (FELIX-6038) Need gogo command, runtime, and shell to support java 7

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6038:
---

GitHub user sebratton opened a pull request:

https://github.com/apache/felix/pull/171

pull back in Java 7 support for gogo runtime,shell and console

This is for jira FELIX-6038

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sebratton/felix supportJava7

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/171.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #171


commit 52326f130881027a0117ca253274261ed8045b7f
Author: Samuel E Bratton 
Date:   2019-01-23T16:06:52Z

pull back in Java 7 support for gogo runtime,shell and console




> Need gogo command, runtime, and shell to support java 7 
> 
>
> Key: FELIX-6038
> URL: https://issues.apache.org/jira/browse/FELIX-6038
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo Command, Gogo Runtime, Gogo Shell
>Affects Versions: gogo.runtime-1.1.2, gogo.shell-1.1.2, gogo.command-1.1.0
>Reporter: Samuel Bratton
>Assignee: Thomas Watson
>Priority: Minor
>
> Command, runtime, and shell currently produce bundles that require JavaSE 
> version=1.8. We need to continue support for java 7 a bit longer. This will 
> need updates to some poms and minor syntax changes to convert code that uses 
> new Java 8 syntax back to Java 7.



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

[jira] [Commented] (FELIX-6036) Race condition prevents optional/greedy ref setter method from being called

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6036:
---

Github user tjwatson closed the pull request at:

https://github.com/apache/felix/pull/170


> Race condition prevents optional/greedy ref setter method from being called
> ---
>
> Key: FELIX-6036
> URL: https://issues.apache.org/jira/browse/FELIX-6036
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.14
>Reporter: Brent Daniel
>Assignee: Thomas Watson
>Priority: Major
>
> I have a component with an optional/dynamic/greedy reference. The target is 
> registered directly with OSGi using BundleContext.registerService(). 
> Normally, either SingleDynamicCustomizer.addedService() or 
> SingleComponentManager.createImplementationObject() will succeed in binding 
> the reference, but there is a race condition that can prevent the setter 
> method from ever being called. 
>  
> The failure path is as follows:
> 1) SingleComponentManager.createImplementationObject calls open() on each of 
> its DependencyManagers. This generates an OpenStatus where the RefPair list 
> is empty because our target has not been registered yet. 
> 2) Before createImplementationObject() can set the component context, the 
> customizer's addedService() method is called in response to the target 
> service registration. It attempts to bind the target service, but that will 
> not happen because the component context has not been set yet. 
> 3) createImplementationObject then creates the implementation, sets the 
> component context, and goes through the list of OpenStatus objects to bind 
> target services. The RefPair list for the OpenStatus object will still be 
> empty, so we will not call the setter method for the reference we're 
> concerned about. 
>  
> I'm not sure of a good way to fix this. I couldn't come up with a good 
> approach using synchronization or earlier creation of the implementation 
> object. At the moment I am working around this by refreshing the list of 
> RefPairs in the OpenStatus object at the top of 
> DependencyManager.bindDependency():
>  
> {code:java}
> // Refresh ref list before binding
> synchronized(m_tracker.tracked()) {
>status.refs=m_customizer.getRefs(status.trackingCount);
> }
> {code}
>  



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

[jira] [Commented] (FELIX-6034) Gogo JLine requirement doesn't allow to embed gogo.jline

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6034:
---

Github user jbonofre closed the pull request at:

https://github.com/apache/felix/pull/169


> Gogo JLine requirement doesn't allow to embed gogo.jline
> 
>
> Key: FELIX-6034
> URL: https://issues.apache.org/jira/browse/FELIX-6034
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo JLine
>Affects Versions: gogo.jline-1.1.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>
> Felix Gogo Jline 1.1.2 introduced a Requirement:
> {code}
> @Requirement(
> effective = "active",
> namespace = "org.apache.felix.gogo",
> name = "command.implementation",
> version = "1.0.0"
> )
> {code}
> This requirement is a contract to find concrete command. However, in the case 
> of Gogo JLine embedded as a standalone bundle, waiting for commands 
> implementation (later on), this requirement doesn't allow to start. That's 
> the case in Apache Karaf shell.
> [~rotty3000] do you mind if I remove this requirement (as I did other fixes 
> like in {{Posix}} commands) ? We could add this Requirement in gogo.jline 2.x 
> and then, I will have to find a bypass or at least a fake command providing a 
> capability.



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

[jira] [Commented] (FELIX-6036) Race condition prevents optional/greedy ref setter method from being called

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6036:
---

GitHub user tjwatson opened a pull request:

https://github.com/apache/felix/pull/170

FELIX-6036 - avoid stashing stale RefPair objects in OpenStatus



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tjwatson/felix fixSCR-6036

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/170.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #170


commit 072aa9539a9ce1636304ee25e4b1fc598959a393
Author: Tom Watson 
Date:   2019-01-24T16:46:13Z

FELIX-6036 - avoid stashing stale RefPair objects in OpenStatus




> Race condition prevents optional/greedy ref setter method from being called
> ---
>
> Key: FELIX-6036
> URL: https://issues.apache.org/jira/browse/FELIX-6036
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.14
>Reporter: Brent Daniel
>Priority: Major
>
> I have a component with an optional/dynamic/greedy reference. The target is 
> registered directly with OSGi using BundleContext.registerService(). 
> Normally, either SingleDynamicCustomizer.addedService() or 
> SingleComponentManager.createImplementationObject() will succeed in binding 
> the reference, but there is a race condition that can prevent the setter 
> method from ever being called. 
>  
> The failure path is as follows:
> 1) SingleComponentManager.createImplementationObject calls open() on each of 
> its DependencyManagers. This generates an OpenStatus where the RefPair list 
> is empty because our target has not been registered yet. 
> 2) Before createImplementationObject() can set the component context, the 
> customizer's addedService() method is called in response to the target 
> service registration. It attempts to bind the target service, but that will 
> not happen because the component context has not been set yet. 
> 3) createImplementationObject then creates the implementation, sets the 
> component context, and goes through the list of OpenStatus objects to bind 
> target services. The RefPair list for the OpenStatus object will still be 
> empty, so we will not call the setter method for the reference we're 
> concerned about. 
>  
> I'm not sure of a good way to fix this. I couldn't come up with a good 
> approach using synchronization or earlier creation of the implementation 
> object. At the moment I am working around this by refreshing the list of 
> RefPairs in the OpenStatus object at the top of 
> DependencyManager.bindDependency():
>  
> {code:java}
> // Refresh ref list before binding
> synchronized(m_tracker.tracked()) {
>status.refs=m_customizer.getRefs(status.trackingCount);
> }
> {code}
>  



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

[jira] [Commented] (FELIX-6034) Gogo JLine requirement doesn't allow to embed gogo.jline

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6034:
---

GitHub user jbonofre opened a pull request:

https://github.com/apache/felix/pull/169

[FELIX-6034] Remove Requirement from Gogo JLine



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jbonofre/felix FELIX-6034

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/169.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #169


commit 0232e90938528333cf1e4a74adf8d372778d8ed5
Author: Paul McCulloch 
Date:   2018-10-17T15:34:26Z

FELIX-5968 Posix 'ls' command ignores .. unless -a is specified

FELIX-5968
Posix 'ls' command ignores .. unless -a is specified

commit b8468b585a4d3b806cd0f2305b27c92b10b00473
Author: Jean-Baptiste Onofré 
Date:   2019-01-22T14:16:14Z

[FELIX-6030] Remove @Header on Gogo JLine Activator to avoid issue in 
Apache Karaf shell

commit 9cabff641bd7cea4b606d0ee3251cd44ba8e289c
Author: Jean-Baptiste Onofré 
Date:   2019-01-22T14:20:25Z

[FELIX-5963] Use named ExecutorService

commit bdb9fe5c0a84cacf198ffddc48dd14332cbe8125
Author: jbonofre 
Date:   2019-01-22T14:36:59Z

[FELIX-5963] This closes #168

git-svn-id: https://svn.apache.org/repos/asf/felix/trunk@1851825 
13f79535-47bb-0310-9956-ffa450edef68

commit 960943684003e763669bb662d6c220702602446c
Author: jbonofre 
Date:   2019-01-22T14:40:53Z

[FELIX-5968] This closes #158

git-svn-id: https://svn.apache.org/repos/asf/felix/trunk@1851826 
13f79535-47bb-0310-9956-ffa450edef68

commit 4a4df4950e045eb7bcebf2c5fc9d8fc8b6cd8b6f
Author: jbonofre 
Date:   2019-01-22T14:54:54Z

[FELIX-6030] This closes #167

git-svn-id: https://svn.apache.org/repos/asf/felix/trunk@1851828 
13f79535-47bb-0310-9956-ffa450edef68

commit 58c69580de5385b7ebd018f9abe56270779d7b97
Author: Jean-Baptiste Onofré 
Date:   2019-01-22T14:06:10Z

[FELIX-6033] Align Felix Gogo wc posix action compliant with concrete posix 
one

commit 0485eaf87c1237b7ab724cfd67fa1529697558b9
Author: jbonofre 
Date:   2019-01-22T16:25:39Z

[FELIX-6033] This closes #166

git-svn-id: https://svn.apache.org/repos/asf/felix/trunk@1851830 
13f79535-47bb-0310-9956-ffa450edef68

commit db0db44b5bdb798ae0d309fe0414b390f63552da
Author: Jean-Baptiste Onofré 
Date:   2019-01-23T06:52:28Z

[FELIX-6034] Remove Requirement from Gogo JLine




> Gogo JLine requirement doesn't allow to embed gogo.jline
> 
>
> Key: FELIX-6034
> URL: https://issues.apache.org/jira/browse/FELIX-6034
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo JLine
>Affects Versions: gogo.jline-1.1.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: gogo.jline-1.1.3
>
>
> Felix Gogo Jline 1.1.2 introduced a Requirement:
> {code}
> @Requirement(
> effective = "active",
> namespace = "org.apache.felix.gogo",
> name = "command.implementation",
> version = "1.0.0"
> )
> {code}
> This requirement is a contract to find concrete command. However, in the case 
> of Gogo JLine embedded as a standalone bundle, waiting for commands 
> implementation (later on), this requirement doesn't allow to start. That's 
> the case in Apache Karaf shell.
> [~rotty3000] do you mind if I remove this requirement (as I did other fixes 
> like in {{Posix}} commands) ? We could add this Requirement in gogo.jline 2.x 
> and then, I will have to find a bypass or at least a fake command providing a 
> capability.



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

[jira] [Commented] (FELIX-6033) wc command should be compliant with posix ones

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6033:
---

Github user asfgit closed the pull request at:

https://github.com/apache/felix/pull/166


> wc command should be compliant with posix ones
> --
>
> Key: FELIX-6033
> URL: https://issues.apache.org/jira/browse/FELIX-6033
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo JLine
>Affects Versions: gogo.jline-1.1.0, gogo.jline-1.1.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: gogo.jline-1.1.3
>
>
> The Posix {{wc}} command formatting is not fully correct. For instance, a 
> simple:
> {code}
> echo "foo\nbar"|wc -l
> {code}
> displays:
> {code}
>2 2
> {code}
> So the output formatting is not correct (result is displayed twice) and 
> {{wc}} can't be easily used in scripting.
> To be compliant with standard Posix {{wc}} command, the output should be:
> {code}
> 2
> {code}
> I'm adding tests and fixes.



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

[jira] [Commented] (FELIX-6030) @Header in gogo.jline causing maven-bundle-plugin failure

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6030:
---

Github user asfgit closed the pull request at:

https://github.com/apache/felix/pull/167


> @Header in gogo.jline causing maven-bundle-plugin failure
> -
>
> Key: FELIX-6030
> URL: https://issues.apache.org/jira/browse/FELIX-6030
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo JLine
>Affects Versions: gogo.jline-1.1.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: gogo.jline-1.1.3
>
>
> In the https://svn.apache.org/viewvc?view=revision=1849343 revision, 
> Gogo JLine bundle {{Activator}} now contains:
> {code}
> @Header(name = Constants.BUNDLE_ACTIVATOR, value = "${@class}")
> {code}
> In Karaf, we "wrap" {{gogo.jline}} in Karaf {{shell.core}}:
> {code}
> 
> org.apache.felix
> maven-bundle-plugin
> 
> 
> 
> org.osgi.service.event;resolution:=optional,
> org.apache.karaf.branding;resolution:=optional,
> !org.apache.felix.gogo.jline*,
> !org.apache.sshd.*,
> *   
> 
> 
> 
> org.apache.karaf.shell.api.*;version=${project.version},
> 
> org.apache.karaf.shell.support.*;version=${project.version},
> org.apache.felix.service.command,
> org.apache.felix.service.threadio
> 
> 
> org.apache.karaf.service.guard.tools,
> org.apache.karaf.shell.impl.*,
> org.apache.karaf.util,
> org.apache.karaf.util.filesstream,
> org.apache.karaf.util.jaas,
> org.apache.karaf.util.tracker,
> org.apache.felix.utils.properties,
> org.apache.felix.utils.extender,
> org.apache.felix.utils.manifest,
> org.apache.felix.gogo.jline,
> org.apache.felix.gogo.runtime,
> org.apache.felix.gogo.runtime.threadio,
> org.apache.felix.service.command,
> org.apache.felix.service.threadio,
> 
> 
> 
> osgi.service;effective:=active;objectClass=org.apache.karaf.shell.api.console.SessionFactory
> 
> 
> org.apache.karaf.shell.impl.console.osgi.Activator
> 
> 
> 
> org.apache.karaf.shell.impl.console.standalone.Main
> 
> 
> true
> 
> 
> {code}
> Since the introduction of {{@Header}} in Felix Gogo JLine, the build fails 
> with:
> {code}
> [ERROR] Bundle 
> org.apache.karaf.shell:org.apache.karaf.shell.core:bundle:4.2.3-SNAPSHOT : 
> The Bundle-Activator header only supports a single type. The following types 
> were found: 
> org.apache.karaf.shell.impl.console.osgi.Activator,org.apache.felix.gogo.jline.Activator.
>  This usually happens when a macro resolves to multiple types
> [ERROR] Error(s) found in bundle configuration
> {code}
> [~rotty3000] do you know a workaround in the {{maven-bundle-plugin}} about 
> that ? If not, do you mind if I remove {{@Header}} from Gogo JLine Activator ?
> Thanks.
> JB



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

[jira] [Commented] (FELIX-5963) Gogo runtime should use named executor threads

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5963:
---

Github user asfgit closed the pull request at:

https://github.com/apache/felix/pull/168


> Gogo runtime should use named executor threads
> --
>
> Key: FELIX-5963
> URL: https://issues.apache.org/jira/browse/FELIX-5963
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo Runtime
>Reporter: Raymond Augé
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: gogo.runtime-1.1.4
>
>
> Simplifies diagnostics



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

[jira] [Commented] (FELIX-5968) Posix 'ls' command ignores .. unless -a is specified

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5968:
---

Github user asfgit closed the pull request at:

https://github.com/apache/felix/pull/158


> Posix 'ls' command ignores .. unless -a is specified
> 
>
> Key: FELIX-5968
> URL: https://issues.apache.org/jira/browse/FELIX-5968
> Project: Felix
>  Issue Type: Bug
>  Components:  Console, Gogo JLine
>Reporter: Paul McCulloch
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: gogo.jline-1.1.3
>
>
> The ls command in org.apache.felix.gogo.jline.Posix applies a filter to all 
> paths beginning with a period. .. (parent) begins with a period, but isn't a 
> hidden directory. .(current) should also be listed without -a.



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

[jira] [Commented] (FELIX-5963) Gogo runtime should use named executor threads

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5963:
---

GitHub user jbonofre opened a pull request:

https://github.com/apache/felix/pull/168

[FELIX-5963] Use named ExecutorService



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jbonofre/felix FELIX-5963

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/168.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #168


commit 9cabff641bd7cea4b606d0ee3251cd44ba8e289c
Author: Jean-Baptiste Onofré 
Date:   2019-01-22T14:20:25Z

[FELIX-5963] Use named ExecutorService




> Gogo runtime should use named executor threads
> --
>
> Key: FELIX-5963
> URL: https://issues.apache.org/jira/browse/FELIX-5963
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo Runtime
>Reporter: Raymond Augé
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: gogo.runtime-1.1.4
>
>
> Simplifies diagnostics



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

[jira] [Commented] (FELIX-6030) @Header in gogo.jline causing maven-bundle-plugin failure

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6030:
---

GitHub user jbonofre opened a pull request:

https://github.com/apache/felix/pull/167

[FELIX-6030] Remove @Header on Gogo JLine Activator to avoid issue in 
Apache Karaf shell



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jbonofre/felix FELIX-6030

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/167.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #167


commit b8468b585a4d3b806cd0f2305b27c92b10b00473
Author: Jean-Baptiste Onofré 
Date:   2019-01-22T14:16:14Z

[FELIX-6030] Remove @Header on Gogo JLine Activator to avoid issue in 
Apache Karaf shell




> @Header in gogo.jline causing maven-bundle-plugin failure
> -
>
> Key: FELIX-6030
> URL: https://issues.apache.org/jira/browse/FELIX-6030
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo JLine
>Affects Versions: gogo.jline-1.1.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: gogo.jline-1.1.3
>
>
> In the https://svn.apache.org/viewvc?view=revision=1849343 revision, 
> Gogo JLine bundle {{Activator}} now contains:
> {code}
> @Header(name = Constants.BUNDLE_ACTIVATOR, value = "${@class}")
> {code}
> In Karaf, we "wrap" {{gogo.jline}} in Karaf {{shell.core}}:
> {code}
> 
> org.apache.felix
> maven-bundle-plugin
> 
> 
> 
> org.osgi.service.event;resolution:=optional,
> org.apache.karaf.branding;resolution:=optional,
> !org.apache.felix.gogo.jline*,
> !org.apache.sshd.*,
> *   
> 
> 
> 
> org.apache.karaf.shell.api.*;version=${project.version},
> 
> org.apache.karaf.shell.support.*;version=${project.version},
> org.apache.felix.service.command,
> org.apache.felix.service.threadio
> 
> 
> org.apache.karaf.service.guard.tools,
> org.apache.karaf.shell.impl.*,
> org.apache.karaf.util,
> org.apache.karaf.util.filesstream,
> org.apache.karaf.util.jaas,
> org.apache.karaf.util.tracker,
> org.apache.felix.utils.properties,
> org.apache.felix.utils.extender,
> org.apache.felix.utils.manifest,
> org.apache.felix.gogo.jline,
> org.apache.felix.gogo.runtime,
> org.apache.felix.gogo.runtime.threadio,
> org.apache.felix.service.command,
> org.apache.felix.service.threadio,
> 
> 
> 
> osgi.service;effective:=active;objectClass=org.apache.karaf.shell.api.console.SessionFactory
> 
> 
> org.apache.karaf.shell.impl.console.osgi.Activator
> 
> 
> 
> org.apache.karaf.shell.impl.console.standalone.Main
> 
> 
> true
> 
> 
> {code}
> Since the introduction of {{@Header}} in Felix Gogo JLine, the build fails 
> with:
> {code}
> [ERROR] Bundle 
> org.apache.karaf.shell:org.apache.karaf.shell.core:bundle:4.2.3-SNAPSHOT : 
> The Bundle-Activator header only supports a single type. The following types 
> were found: 
> org.apache.karaf.shell.impl.console.osgi.Activator,org.apache.felix.gogo.jline.Activator.
>  This usually happens when a macro resolves to multiple types
> [ERROR] Error(s) found in bundle configuration
> {code}
> [~rotty3000] do you know a workaround in the {{maven-bundle-plugin}} about 
> that ? If not, do you mind if I remove {{@Header}} from Gogo JLine Activator ?
> Thanks.
> JB



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

[jira] [Commented] (FELIX-6033) wc command should be compliant with posix ones

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6033:
---

GitHub user jbonofre opened a pull request:

https://github.com/apache/felix/pull/166

[FELIX-6033] Align Felix Gogo wc posix action compliant with concrete posix 
one



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jbonofre/felix FELIX-6033

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/166.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #166


commit 2ff4867362fb0cc7bb3783a0c8b28510b2feb58a
Author: Jean-Baptiste Onofré 
Date:   2019-01-22T14:06:10Z

[FELIX-6033] Align Felix Gogo wc posix action compliant with concrete posix 
one




> wc command should be compliant with posix ones
> --
>
> Key: FELIX-6033
> URL: https://issues.apache.org/jira/browse/FELIX-6033
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo JLine
>Affects Versions: gogo.jline-1.1.0, gogo.jline-1.1.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: gogo.jline-1.1.3
>
>
> The Posix {{wc}} command formatting is not fully correct. For instance, a 
> simple:
> {code}
> echo "foo\nbar"|wc -l
> {code}
> displays:
> {code}
>2 2
> {code}
> So the output formatting is not correct (result is displayed twice) and 
> {{wc}} can't be easily used in scripting.
> To be compliant with standard Posix {{wc}} command, the output should be:
> {code}
> 2
> {code}
> I'm adding tests and fixes.



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

[jira] [Commented] (FELIX-6023) SCR bnd plugin sometimes fails with IncompatibleClassChangeError: Implementing class

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6023:
---

Github user asfgit closed the pull request at:

https://github.com/apache/felix/pull/165


> SCR bnd plugin sometimes fails with IncompatibleClassChangeError: 
> Implementing class
> 
>
> Key: FELIX-6023
> URL: https://issues.apache.org/jira/browse/FELIX-6023
> Project: Felix
>  Issue Type: Bug
>  Components: SCR Tooling
>Affects Versions: scr bnd plugin 1.9.0
> Environment: Maven home: /usr/local/Cellar/maven/3.6.0/libexec
> Java version: 1.8.0_192, vendor: Oracle Corporation, runtime: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_192.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.2", arch: "x86_64", family: "mac"
>Reporter: Mark Adamcin
>Assignee: Stefan Seifert
>Priority: Major
>  Labels: patch-available
> Attachments: com.adobe.acs.acs-aem-commons-bundle.bnd-1.9.0.log, 
> com.adobe.acs.acs-aem-commons-bundle.bnd-1.9.1-SNAPSHOT.log
>
>
>  
> When building a project where a newer version of a dependency is embedded in 
> the project artifact with a conflicting older version of said dependency is 
> also present on the classpath, SOME environments encounter an exception that 
> is similar to the following:
> {noformat}
> [ERROR] Manifest com.adobe.acs:acs-aem-commons-bundle:bundle:3.19.1-SNAPSHOT 
> : Got unexpected exception while 
> analyzing:org.apache.felix.scrplugin.SCRDescriptorException: Unable to load 
> compiled class: com.google.common.base.Suppliers$SupplierFunctionImpl
>   at 
> org.apache.felix.scrplugin.helper.ClassScanner.scanSources(ClassScanner.java:156)
>   at 
> org.apache.felix.scrplugin.SCRDescriptorGenerator.execute(SCRDescriptorGenerator.java:146)
>   at 
> org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin.analyzeJar(SCRDescriptorBndPlugin.java:178)
>   at aQute.bnd.osgi.Analyzer.doPlugins(Analyzer.java:820)
>   at aQute.bnd.osgi.Analyzer.analyze(Analyzer.java:229)
>   at aQute.bnd.osgi.Builder.analyze(Builder.java:408)
>   at aQute.bnd.osgi.Analyzer.calcManifest(Analyzer.java:850)
>   at aQute.bnd.osgi.Builder.build(Builder.java:116)
>   at 
> org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer(ManifestPlugin.java:291)
>   at 
> org.apache.felix.bundleplugin.ManifestPlugin.execute(ManifestPlugin.java:98)
>   at 
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:384)
>   at 
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:375)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
>   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.IncompatibleClassChangeError: Implementing class
>   at 

[jira] [Commented] (FELIX-6023) SCR bnd plugin sometimes fails with IncompatibleClassChangeError: Implementing class

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6023:
---

GitHub user adamcin opened a pull request:

https://github.com/apache/felix/pull/165

FELIX-6023 bnd scrplugin preserve sequence of classpath entries.

Replace the HashSet used for deduping classpath entries with a 
LinkedHashSet to retain the precedence established by the Analyzer.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/adamcin/felix FELIX-6023

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/165.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #165


commit 0e50d6bdff9f53ef6fb5efe9aa8f9ff88d4c82d1
Author: Mark Adamcin 
Date:   2019-01-10T20:29:40Z

FELIX-6023 bnd scrplugin preserve sequence of classpath entries.




> SCR bnd plugin sometimes fails with IncompatibleClassChangeError: 
> Implementing class
> 
>
> Key: FELIX-6023
> URL: https://issues.apache.org/jira/browse/FELIX-6023
> Project: Felix
>  Issue Type: Bug
>  Components: SCR Tooling
>Affects Versions: scr bnd plugin 1.9.0
> Environment: Maven home: /usr/local/Cellar/maven/3.6.0/libexec
> Java version: 1.8.0_192, vendor: Oracle Corporation, runtime: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_192.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.2", arch: "x86_64", family: "mac"
>Reporter: Mark Adamcin
>Priority: Major
> Attachments: com.adobe.acs.acs-aem-commons-bundle.bnd-1.9.0.log, 
> com.adobe.acs.acs-aem-commons-bundle.bnd-1.9.1-SNAPSHOT.log
>
>
>  
> When building a project where a newer version of a dependency is embedded in 
> the project artifact with a conflicting older version of said dependency is 
> also present on the classpath, SOME environments encounter an exception that 
> is similar to the following:
> {noformat}
> [ERROR] Manifest com.adobe.acs:acs-aem-commons-bundle:bundle:3.19.1-SNAPSHOT 
> : Got unexpected exception while 
> analyzing:org.apache.felix.scrplugin.SCRDescriptorException: Unable to load 
> compiled class: com.google.common.base.Suppliers$SupplierFunctionImpl
>   at 
> org.apache.felix.scrplugin.helper.ClassScanner.scanSources(ClassScanner.java:156)
>   at 
> org.apache.felix.scrplugin.SCRDescriptorGenerator.execute(SCRDescriptorGenerator.java:146)
>   at 
> org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin.analyzeJar(SCRDescriptorBndPlugin.java:178)
>   at aQute.bnd.osgi.Analyzer.doPlugins(Analyzer.java:820)
>   at aQute.bnd.osgi.Analyzer.analyze(Analyzer.java:229)
>   at aQute.bnd.osgi.Builder.analyze(Builder.java:408)
>   at aQute.bnd.osgi.Analyzer.calcManifest(Analyzer.java:850)
>   at aQute.bnd.osgi.Builder.build(Builder.java:116)
>   at 
> org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer(ManifestPlugin.java:291)
>   at 
> org.apache.felix.bundleplugin.ManifestPlugin.execute(ManifestPlugin.java:98)
>   at 
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:384)
>   at 
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:375)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
>   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> 

[jira] [Commented] (FELIX-5143) Gogo Command bundle should not include org.osgi.service.log classes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5143:
---

Github user xfournet closed the pull request at:

https://github.com/apache/felix/pull/49


> Gogo Command bundle should not include org.osgi.service.log classes
> ---
>
> Key: FELIX-5143
> URL: https://issues.apache.org/jira/browse/FELIX-5143
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo Command
>Reporter: Xavier Fournet
>Priority: Major
> Fix For: gogo.command-1.1.0
>
>
> The classes of org.osgi.service.log are present in the Gogo command jar files.
> The bundle should instead import this package. It seems that there was a 
> confusion between Export-Package and Import-Package in the BND directives in 
> pom.xml



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

[jira] [Commented] (FELIX-5997) Hashcode check doesn't work with fragment

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5997:
---

Github user asfgit closed the pull request at:

https://github.com/apache/felix/pull/164


> Hashcode check doesn't work with fragment
> -
>
> Key: FELIX-5997
> URL: https://issues.apache.org/jira/browse/FELIX-5997
> Project: Felix
>  Issue Type: Bug
>  Components: Utils
>Affects Versions: utils-1.11.0
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: utils-1.11.2
>
>
> With the introduction of hashcode in {{AbstractCapabilityRequirement}}, utils 
> is not able to deal with fragment.



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

[jira] [Commented] (FELIX-5997) Hashcode check doesn't work with fragment

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5997:
---

GitHub user jbonofre opened a pull request:

https://github.com/apache/felix/pull/164

[FELIX-5997] Remove hashcode and equals from AbstractCapabilityRequirement 
to deal with fragment



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jbonofre/felix FELIX-5997

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/164.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #164


commit 1a74794ae49aceae5a4c45893f31910af0363d38
Author: Jean-Baptiste Onofré 
Date:   2018-12-11T16:24:00Z

[FELIX-5997] Remove hashcode and equals from AbstractCapabilityRequirement 
to deal with fragment




> Hashcode check doesn't work with fragment
> -
>
> Key: FELIX-5997
> URL: https://issues.apache.org/jira/browse/FELIX-5997
> Project: Felix
>  Issue Type: Bug
>  Components: Utils
>Affects Versions: utils-1.11.0
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: utils-1.11.2
>
>
> With the introduction of hashcode in {{AbstractCapabilityRequirement}}, utils 
> is not able to deal with fragment.



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

[jira] [Commented] (FELIX-5978) Felix framework unable to retrieve custom URL handlers when security is on

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5978:
---

Github user asfgit closed the pull request at:

https://github.com/apache/felix/pull/160


> Felix framework unable to retrieve custom URL handlers when security is on
> --
>
> Key: FELIX-5978
> URL: https://issues.apache.org/jira/browse/FELIX-5978
> Project: Felix
>  Issue Type: Bug
>Affects Versions: framework-6.0.0, framework-6.0.1
>Reporter: Timothy Ward
>Priority: Critical
> Fix For: framework-6.0.2
>
>
> When running with multiple frameworks in the same VM, custom URL Handlers, 
> and OSGi security on there are a couple of problems:
>  
> Firstly, this security exception results in the custom URL handler being 
> ignored. The framework should really be using a doPriv here.
> {code:java}
> java.security.AccessControlException: access denied 
> ("java.lang.RuntimePermission" "getClassLoader")
> at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> at java.lang.Class.getClassLoader(Class.java:683)
> at 
> org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:690)
> at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574)
> at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
> at java.net.URL.toExternalForm(URL.java:929)
> at java.net.URL.toString(URL.java:915)
> at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:762)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2344)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClassParallel(BundleWiringImpl.java:2162)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2096)
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1565)
> at 
> org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at 
> org.apache.felix.cm.impl.ConfigurationManager.configure(ConfigurationManager.java:758)
> {code}
> Secondly, the wrong framework is returned some of the time due to the logic 
> of URLHandlers.getFrameworkContext() - in this method it assumes that there 
> will be a bundle class loader on the stack, which is not true when the 
> launcher is starting a bundle (the framework reflectively loads the Activator 
> type which requires a URL check to set the security domain).



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

[jira] [Commented] (FELIX-5978) Felix framework unable to retrieve custom URL handlers when security is on

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5978:
---

GitHub user timothyjward opened a pull request:

https://github.com/apache/felix/pull/160

[FELIX-5978] Ensure getClassLoader() is called in a safe way when sec…

…urity is enabled

Previously URLHandlers would explode when security was on because it didn't 
have permission to get the ClassLoader all the way down the stack

Signed-off-by: Tim Ward 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/timothyjward/felix FELIX-5978

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/160.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #160


commit e30d80a31b03731fd1b67fb551d58b10741eb5d1
Author: Tim Ward 
Date:   2018-11-08T12:11:29Z

[FELIX-5978] Ensure getClassLoader() is called in a safe way when security 
is enabled

Previously URLHandlers would explode when security was on because it didn't 
have permission to get the ClassLoader all the way down the stack

Signed-off-by: Tim Ward 




> Felix framework unable to retrieve custom URL handlers when security is on
> --
>
> Key: FELIX-5978
> URL: https://issues.apache.org/jira/browse/FELIX-5978
> Project: Felix
>  Issue Type: Bug
>Affects Versions: framework-6.0.0, framework-6.0.1
>Reporter: Timothy Ward
>Priority: Critical
> Fix For: framework-6.0.2
>
>
> When running with multiple frameworks in the same VM, custom URL Handlers, 
> and OSGi security on there are a couple of problems:
>  
> Firstly, this security exception results in the custom URL handler being 
> ignored. The framework should really be using a doPriv here.
> {code:java}
> java.security.AccessControlException: access denied 
> ("java.lang.RuntimePermission" "getClassLoader")
> at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> at java.lang.Class.getClassLoader(Class.java:683)
> at 
> org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:690)
> at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574)
> at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
> at java.net.URL.toExternalForm(URL.java:929)
> at java.net.URL.toString(URL.java:915)
> at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:762)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2344)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClassParallel(BundleWiringImpl.java:2162)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2096)
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1565)
> at 
> org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at 
> org.apache.felix.cm.impl.ConfigurationManager.configure(ConfigurationManager.java:758)
> {code}
> Secondly, the wrong framework is returned some of the time due to the logic 
> of URLHandlers.getFrameworkContext() - in this method it assumes that there 
> will be a bundle class loader on the stack, which is not true when the 
> launcher is starting a bundle (the framework reflectively loads the Activator 
> type which requires a URL check to set the security domain).



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

[jira] [Commented] (FELIX-5974) Prototype scope references are not released on deactivation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5974:
---

GitHub user timothyjward opened a pull request:

https://github.com/apache/felix/pull/159

Provide a refactoring to simplify prototype reference access

This should also Fix FELIX-5974

Signed-off-by: Tim Ward 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/timothyjward/felix FELIX-5974

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/159.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #159


commit 1a0973e08353bb0c4e959fb2a01b861c9cfcc39b
Author: Tim Ward 
Date:   2018-10-26T12:20:11Z

Provide a refactoring to simplify prototype reference access

This should also Fix FELIX-5974

Signed-off-by: Tim Ward 




> Prototype scope references are not released on deactivation
> ---
>
> Key: FELIX-5974
> URL: https://issues.apache.org/jira/browse/FELIX-5974
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.12
>Reporter: Timothy Ward
>Priority: Major
> Fix For: scr-2.1.14
>
>
> Having read the stack overflow question on [Stack 
> Overflow|https://stackoverflow.com/questions/52839641/osgi-ds-prototype-reference-not-released]
>  I was pretty certain that the user must be doing something wrong, but in 
> fact it seems as though SCR does a bad job of releasing Prototype scoped 
> references when a component is disposed.
> I looked into the code, and it seems that there are a lot of conflicting 
> locations where prototype scope services are obtained and released. I propose 
> tidying this up so that the ComponentServiceObjects is *always* used 
> internally regardless of whether it is injected or not. This encapsulates all 
> the access in a single location so it is less likely that the objects will 
> leak.



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

[jira] [Commented] (FELIX-5968) Posix 'ls' command ignores .. unless -a is specified

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5968:
---

GitHub user paul-mcculloch opened a pull request:

https://github.com/apache/felix/pull/158

FELIX-5968 Posix 'ls' command ignores .. unless -a is specified

FELIX-5968
Posix 'ls' command ignores .. unless -a is specified

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/paul-mcculloch/felix trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/158.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #158


commit 0232e90938528333cf1e4a74adf8d372778d8ed5
Author: Paul McCulloch 
Date:   2018-10-17T15:34:26Z

FELIX-5968 Posix 'ls' command ignores .. unless -a is specified

FELIX-5968
Posix 'ls' command ignores .. unless -a is specified




> Posix 'ls' command ignores .. unless -a is specified
> 
>
> Key: FELIX-5968
> URL: https://issues.apache.org/jira/browse/FELIX-5968
> Project: Felix
>  Issue Type: Bug
>  Components:  Console, Gogo JLine
>Reporter: Paul McCulloch
>Priority: Minor
>
> The ls command in org.apache.felix.gogo.jline.Posix applies a filter to all 
> paths beginning with a period. .. (parent) begins with a period, but isn't a 
> hidden directory. .(current) should also be listed without -a.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5942:
---

Github user asfgit closed the pull request at:

https://github.com/apache/felix/pull/156


> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in 
> Object.wait()  [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at java.lang.Object.wait(java.base@10.0.2/Native Method)
>   - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
>   at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
>   at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
>   - waiting to re-lock in wait() <0x0006c931dd20> (a 
> [Ljava.lang.Object;)
>   at 
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
>   at 
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
>   at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
>   at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
>   at 
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue : 
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
>  * Lots of threads trying to acquire the global lock
>  ** here we're resolving a class from a bundle with dynamic import packages
>  * An Oracle JDK 10 or OpenJDK 11
>  ** it's working fine with Oracle JDK 8
>  
> Replacing the {{m_bundleLock}} by a fair {{ReentrantLock}} with a 
> {{Condition}} makes it work with 10 parallel threads but still fails with 100 
> threads.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5942:
---

GitHub user adessaigne opened a pull request:

https://github.com/apache/felix/pull/156

FELIX-5942 - Replace wait/notify by lock/conditions in Felix to avoid freeze

Fix proposal for 
[FELIX-5942](https://issues.apache.org/jira/browse/FELIX-5942).

Instead of a single `Object` with calls to `wait` and `notifyAll` we're 
using a `Lock` with 2 `Condition` objects :
* one when the waiting conditions on global lock acquisition have changed
* one when the waiting conditions on bundle lock acquisition have changed

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/adessaigne/felix FELIX-5942

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/156.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #156


commit d906ec37291bbc7d9fd4bd3211aaae0b4f9eac00
Author: Antoine DESSAIGNE 
Date:   2018-09-24T15:22:12Z

FELIX-5942 - Replace wait/notify by lock/conditions in Felix to avoid freeze




> Felix Framework freezes when resolving classes in parallel with Java 10
> ---
>
> Key: FELIX-5942
> URL: https://issues.apache.org/jira/browse/FELIX-5942
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Antoine DESSAIGNE
>Assignee: Karl Pauls
>Priority: Major
> Attachments: ConcurrentClassLoaderTest.java
>
>
> Hello.
> When resolving a class in parallel in Java 10, you end up with a freeze.
> You end up with threads beeing blocked
> {noformat}
> "Thread-99" #121 prio=5 os_prio=0 tid=0x01bdaf679000 nid=0x69d4 in 
> Object.wait()  [0x00296d0fe000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at java.lang.Object.wait(java.base@10.0.2/Native Method)
>   - waiting on <0x0006c931dd20> (a [Ljava.lang.Object;)
>   at java.lang.Object.wait(java.base@10.0.2/Object.java:328)
>   at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4301)
>   - waiting to re-lock in wait() <0x0006c931dd20> (a 
> [Ljava.lang.Object;)
>   at 
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:413)
>   at 
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3318)
>   at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1618)
>   at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
>   at 
> org.apache.felix.framework.ConcurrentClassLoaderTest$1.run(ConcurrentClassLoaderTest.java:69){noformat}
> You'll find attached a test reproducing the issue : 
> [^ConcurrentClassLoaderTest.java]
> Here's what you need to freeze felix :
>  * Lots of threads trying to acquire the global lock
>  ** here we're resolving a class from a bundle with dynamic import packages
>  * An Oracle JDK 10 or OpenJDK 11
>  ** it's working fine with Oracle JDK 8
>  
> Replacing the {{m_bundleLock}} by a fair {{ReentrantLock}} with a 
> {{Condition}} makes it work with 10 parallel threads but still fails with 100 
> threads.



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

[jira] [Commented] (FELIX-5010) NPE when resolving bundle with a header "Bundle-NativeCode = *"

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5010:
---

GitHub user timothyjward opened a pull request:

https://github.com/apache/felix/pull/154

Integration tests verifying the fix for FELIX-5010

Signed-off-by: Tim Ward 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/timothyjward/felix 5010-integration-test

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/154.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #154


commit a61c459e7f3ee09e0a8a41805fbfeaff5c39e74c
Author: Tim Ward 
Date:   2018-09-12T17:08:14Z

Integration tests verifying the fix for FELIX-5010

Signed-off-by: Tim Ward 




> NPE when resolving bundle with a header "Bundle-NativeCode = *"
> ---
>
> Key: FELIX-5010
> URL: https://issues.apache.org/jira/browse/FELIX-5010
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-5.0.1
>Reporter: Guillaume Nodet
>Assignee: Bob Paulin
>Priority: Major
> Fix For: framework-5.2.0
>
>
> {code}
> java.lang.NullPointerException
>   at 
> org.apache.felix.framework.capabilityset.CapabilitySet.match(CapabilitySet.java:197)[org.apache.felix.framework-5.0.1.jar:]
>   at 
> org.apache.felix.framework.capabilityset.CapabilitySet.match(CapabilitySet.java:187)[org.apache.felix.framework-5.0.1.jar:]
>   at 
> org.apache.felix.framework.StatefulResolver.findProvidersInternal(StatefulResolver.java:229)[org.apache.felix.framework-5.0.1.jar:]
>   at 
> org.apache.felix.framework.ResolveContextImpl.findProviders(ResolveContextImpl.java:89)[org.apache.felix.framework-5.0.1.jar:]
>   at 
> org.apache.felix.resolver.Candidates.populate(Candidates.java:198)[org.apache.felix.framework-5.0.1.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:199)[org.apache.felix.framework-5.0.1.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:140)[org.apache.felix.framework-5.0.1.jar:]
>   at 
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:431)[org.apache.felix.framework-5.0.1.jar:]
>   at 
> org.apache.felix.framework.Felix.resolveBundles(Felix.java:4073)[org.apache.felix.framework-5.0.1.jar:]
>   at 
> org.apache.felix.framework.FrameworkWiringImpl.resolveBundles(FrameworkWiringImpl.java:133)[org.apache.felix.framework-5.0.1.jar:]
> {code}



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

[jira] [Commented] (FELIX-5901) Update to latest jQuery UI 1.12.1

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5901:
---

Github user asfgit closed the pull request at:

https://github.com/apache/felix/pull/152


> Update to latest jQuery UI 1.12.1
> -
>
> Key: FELIX-5901
> URL: https://issues.apache.org/jira/browse/FELIX-5901
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Affects Versions: webconsole-4.3.8
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: webconsole-4.3.8
>
> Attachments: patch-FELIX-5901.diff
>
>
> We're currently using jQuery UI 1.9.2 and therefore should update to the 
> latest version.



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

[jira] [Commented] (FELIX-5901) Update to latest jQuery UI 1.12.1

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5901:
---

GitHub user catalan-adobe opened a pull request:

https://github.com/apache/felix/pull/152

FELIX-5901 Update jquery-ui CSS + i18n

* Update jquery-ui style related files and fixed minor UI glitches
* Use `smoothness` theme (equivalent of previous `base` theme)
* Update i18n to latest version

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/catalan-adobe/felix FELIX-5901

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/152.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #152


commit a1d0a1c40205cf1cee768c52152256a1632ea377
Author: catalan 
Date:   2018-09-07T11:53:05Z

FELIX-5901 Align jquery-ui CSS + Fix console UI

commit 796262e1aa91e97b9e6c91c5af4d2a7808a9c516
Author: catalan 
Date:   2018-09-10T09:30:16Z

FELIX-5901 Replace jQueryUI base theme by smoothness theme

commit fb3681ca7b27146cc6515e719709676e427f0d8f
Author: catalan 
Date:   2018-09-10T12:40:32Z

FELIX-5901 Updated jquery-ui i18n




> Update to latest jQuery UI 1.12.1
> -
>
> Key: FELIX-5901
> URL: https://issues.apache.org/jira/browse/FELIX-5901
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Affects Versions: webconsole-4.3.8
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: webconsole-4.3.8
>
> Attachments: patch-FELIX-5901.diff
>
>
> We're currently using jQuery UI 1.9.2 and therefore should update to the 
> latest version.



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

[jira] [Commented] (FELIX-5908) NoClassDefFoundError for the CM Security Domain combiner

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5908:
---

GitHub user timothyjward opened a pull request:

https://github.com/apache/felix/pull/150

Configuration Admin Security can cause a NoClassDefFoundError

Fixes FELIX-5908

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/timothyjward/felix config-security

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/150.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #150


commit 561a99c53854c0449bd922a344f9eee513df5222
Author: Tim Ward 
Date:   2018-08-15T12:21:20Z

FELIX-5908 - Tests to demonstrate the NoClassDefFoundError that can occur 
with security on

Also includes general security tests to ensure that Config Admin runs 
correctly with Security on

Signed-off-by: Tim Ward 

commit 007a88b104deb92fcd890d81bbac5a0df1ec4708
Author: Tim Ward 
Date:   2018-08-15T12:52:30Z

FELIX-5908 Avoid a NoClassDefFoundError by eagerly instantiating the 
ProtectionDomain

Signed-off-by: Tim Ward 




> NoClassDefFoundError for the CM Security Domain combiner
> 
>
> Key: FELIX-5908
> URL: https://issues.apache.org/jira/browse/FELIX-5908
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.9.4
>Reporter: Timothy Ward
>Priority: Major
>
> This is a pretty weird bug, so I'll try to explain it.
> When running with security on the Configuration Admin Updater thread applies 
> an Access Control Context which, amongst other things, sets up a Domain 
> Combiner. This Domain Combiner lazily creates a combined Protection Domain 
> based on the target bundle.
>  
> All of this works fine until you end up in the following situation:
>  # The MS/MSF being called attempts to perform a checked operation (for which 
> they may or may not have permission)
>  # The Check causes the CM Domain Combiner to be instantiated, triggering a 
> class load if it is the first time
>  # The Loading of the class can then trigger *more* security checks in some 
> cases, for example setting the CodeSource of the class being defined can 
> require a security check if there are multiple frameworks in the VM, or if 
> the code was installed from a custom URL handler that has a custom 
> toExternalForm() implementation
>  # This security check retrievers the CM Domain Combiner, which attempts to 
> load the class again
>  # The Java ClassLoader detects the cycle and throws a NoClassDefFoundError
>  
> I am setting up a "simple" test demonstrating this (it necessarily has 
> several moving parts) and a proposed patch.
>  



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

[jira] [Commented] (FELIX-5883) Add support to enable and configure the jetty GzipHandler to the entire server

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5883:
---

Github user enapps-enorman closed the pull request at:

https://github.com/apache/felix/pull/146


> Add support to enable and configure the jetty GzipHandler to the entire server
> --
>
> Key: FELIX-5883
> URL: https://issues.apache.org/jira/browse/FELIX-5883
> Project: Felix
>  Issue Type: Improvement
>  Components: HTTP Service
>Affects Versions: http.jetty-4.0.0, http.jetty-4.0.2
>Reporter: Eric Norman
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: http.jetty-4.0.4
>
> Attachments: FELIX-5883-documentation.patch
>
>
>  
> As per [1], jetty provides a GzipHandler that fixes many of the bugs in 
> commonly available compression filters.  Unlike 3rd party GzipFilters, this 
> mechanism works with asynchronously generated responses and does not need to 
> wrap the response or it's output stream. Instead it uses the efficient 
> HttpOutput.Interceptor mechanism.
> It should be possible to enable and configure this GzipHandler with Felix 
> Http Jetty.
>  # https://www.eclipse.org/jetty/documentation/9.4.x/gzip-filter.html



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

[jira] [Commented] (FELIX-5900) Donating a tool able to generate markdown documentation for SCR and Metatype

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5900:
---

GitHub user simonetripodi opened a pull request:

https://github.com/apache/felix/pull/149

FELIX-5900 - Donating a tool able to generate markdown documentation for 
SCR and Metatype



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/simonetripodi/felix trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/149.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #149


commit 40fb087538ede72274271085a879d05315dc3870
Author: Simo Tripodi 
Date:   2018-08-06T08:55:31Z

[PROPOSAL] add new MOJOs able to generate the Markdown documentation
from metatypes and SCR XML representation




> Donating a tool able to generate markdown documentation for SCR and Metatype
> 
>
> Key: FELIX-5900
> URL: https://issues.apache.org/jira/browse/FELIX-5900
> Project: Felix
>  Issue Type: New Feature
>Reporter: Simone Tripodi
>Priority: Major
>
> after collected a series of feedbacks from  dev@sling.a.o , I am here to 
> propose a couple of new Maven MOJOs to be included in the Felix codebase, 
> able to generate final-user markdown documentation from SCR and Metatype 
> medata descriptors.
> Advantages of producing such documentation, are:
>  * for an internal use, having such catalogue could reduce the development 
> efforts, maybe there are services already available for certain operations 
> that don’t need to be re-implemented; moreover, it can improve/simplify 
> heterogeneous teams integration work.
>  * from customers point of view, it would be good to know what solutions are 
> already offered, to develop their needs on top of our solutions; moreover, 
> under a security PoV, admins can have an overall view to identify which are 
> potential entry-points that can be attacked.
> If you want to have a look at the output, I tested the MOJOs against a couple 
> of Apache Sling projects and collected all of them under a private public 
> GitHub repo[1], it should be easy enough understanding how traverse rendered 
> data.
> How it works: it is a couple of plain-old Maven3 MOJOs which can be 
> configured directly in the POM, I packaged already all the sources in order 
> to be donated to the ASF, I just would like to start the discussion in order 
> to understand if the community is interested on that tool and which steps are 
> required in order to have it accepted. 
> I identified the osgicheck-maven-plugin[2] as the best candidate in order to 
> host the new codebase.
> [1] https://github.com/simonetripodi/mddoc-samples
> [2] https://github.com/apache/felix/tree/trunk/tools/osgicheck-maven-plugin



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

[jira] [Commented] (FELIX-5898) java.io.NotSerializableException: org.apache.felix.configurator.impl.json.OrderedDictionary

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5898:
---

GitHub user cvgaviao opened a pull request:

https://github.com/apache/felix/pull/148

Fixing FELIX-5898

added java.io.Serializable to
org.apache.felix.configurator.impl.json.OrderedDictionary

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cvgaviao/felix FELIX-5898

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/148.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #148


commit cf774aa6d4622a4d235b63a1649ad82cbb669f2f
Author: Cristiano Gavião 
Date:   2018-08-05T19:03:43Z

Fixing FELIX-5898

added java.io.Serializable to
org.apache.felix.configurator.impl.json.OrderedDictionary




> java.io.NotSerializableException: 
> org.apache.felix.configurator.impl.json.OrderedDictionary
> ---
>
> Key: FELIX-5898
> URL: https://issues.apache.org/jira/browse/FELIX-5898
> Project: Felix
>  Issue Type: Bug
>  Components: Configurator
>Affects Versions: configurator-1.0.2
>Reporter: Cristiano Gavião
>Priority: Blocker
>
> I'm using ubuntu 18.04 with Java 8.
> I've created a simple example in order to test felix.configurator bundle. 
> When running the example inside a Eclipse PDE I received the exception below:
> {code:java}
> 14:32:53.253||ERROR|Unable to persist state to 
> state.ser|L.org.apache.felix.configurator||L.o.a.f.configurator@?[Apache 
> Felix Configurator Worker Thread]
> java.io.NotSerializableException: 
> org.apache.felix.configurator.impl.json.OrderedDictionary
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at 
> org.apache.felix.configurator.impl.model.Config.writeObject(Config.java:80)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1140)
> at 
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> at 
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at java.util.ArrayList.writeObject(ArrayList.java:766)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1140)
> at 
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> at 
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at 
> org.apache.felix.configurator.impl.model.ConfigList.writeObject(ConfigList.java:59)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1140)
> at 
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> at 
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at java.util.TreeMap.writeObject(TreeMap.java:2438)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at 

[jira] [Commented] (FELIX-5892) Repeated calls to getFactoryConfiguration return different configuration instances

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5892:
---

GitHub user timothyjward opened a pull request:

https://github.com/apache/felix/pull/147

[FELIX-5892] Repeated calls to getFactoryConfiguration return differe…

…nt backing instances

Signed-off-by: Tim Ward 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/timothyjward/felix config-cache

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/147.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #147


commit 8c1932171b8ecb88223430928433ffe9bcaf87c5
Author: Tim Ward 
Date:   2018-07-27T14:32:04Z

[FELIX-5892] Repeated calls to getFactoryConfiguration return different 
backing instances

Signed-off-by: Tim Ward 




> Repeated calls to getFactoryConfiguration return different configuration 
> instances
> --
>
> Key: FELIX-5892
> URL: https://issues.apache.org/jira/browse/FELIX-5892
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.9.2
>Reporter: Timothy Ward
>Priority: Blocker
>
> When using the new getFactoryConfiguration methods the Configuration Admin 
> implementation does not store a newly created configuration in its local 
> cache. This results in a new configuration object being created each time 
> which means that the revision field is reset to 1. Any updates made to the 
> newly acquired configuration are thus not delivered to ManagedServiceFactory 
> instances because they are deemed to be "too old", at least until the 
> revision count of the new configuration overtakes the old one.



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

[jira] [Commented] (FELIX-5883) Add support to enable and configure the jetty GzipHandler to the entire server

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5883:
---

GitHub user enapps-enorman opened a pull request:

https://github.com/apache/felix/pull/146

FELIX-5883 Add support to enable and configure the jetty GzipHandler to the 
entire server

Please consider these changes to add GzipHandler support

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/enapps-enorman/felix trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/146.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #146


commit 85f539152d824a7805619e44a8d29e295ba1d0a5
Author: Eric Norman 
Date:   2018-07-10T19:07:57Z

FELIX-5883 Add support to enable and configure the jetty GzipHandler to
the entire server




> Add support to enable and configure the jetty GzipHandler to the entire server
> --
>
> Key: FELIX-5883
> URL: https://issues.apache.org/jira/browse/FELIX-5883
> Project: Felix
>  Issue Type: Improvement
>  Components: HTTP Service
>Affects Versions: http.jetty-4.0.0
>Reporter: Eric Norman
>Priority: Major
>
>  
> As per [1], jetty provides a GzipHandler that fixes many of the bugs in 
> commonly available compression filters.  Unlike 3rd party GzipFilters, this 
> mechanism works with asynchronously generated responses and does not need to 
> wrap the response or it's output stream. Instead it uses the efficient 
> HttpOutput.Interceptor mechanism.
> It should be possible to enable and configure this GzipHandler with Felix 
> Http Jetty.
>  # https://www.eclipse.org/jetty/documentation/9.4.x/gzip-filter.html



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

[jira] [Commented] (FELIX-5698) Bundle plugin cannot cope with Java 9 module-info.java

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5698:
---

Github user johnpoth closed the pull request at:

https://github.com/apache/felix/pull/122


> Bundle plugin cannot cope with Java 9 module-info.java
> --
>
> Key: FELIX-5698
> URL: https://issues.apache.org/jira/browse/FELIX-5698
> Project: Felix
>  Issue Type: Bug
>  Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.3.0
> Environment: java version "9"
> Java(TM) SE Runtime Environment (build 9+181)
> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>Reporter: Mark Raynsford
>Priority: Major
> Fix For: maven-bundle-plugin-3.5.0
>
>
> Please see the trivial repro case at:
> [maven-bundle-plugin-20170923|https://github.com/io7m/maven-bundle-plugin-20170923]
> The plugin fails with:
> {noformat}
> [ERROR] Bundle com.io7m.bugs:maven-bundle-plugin-20170923:bundle:0.1.0 : 
> Exception: java.lang.ArrayIndexOutOfBoundsException: 19
> [ERROR] Bundle com.io7m.bugs:maven-bundle-plugin-20170923:bundle:0.1.0 : 
> Invalid class file module-info.class 
> (java.lang.ArrayIndexOutOfBoundsException: 19)
> {noformat}
> There doesn't appear to be a way to exclude the module-info.java files from 
> BND's class file analysis. An easy fix for this bug would be to simple ignore 
> module-info.java files as they're irrelevant for OSGi (but will be present in 
> projects that aim to support both OSGi and Jigsaw).



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

[jira] [Commented] (FELIX-5795) Maven Bundle Plugin Should Upgrade to Use Maven Dependency Tree 3.x

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5795:
---

GitHub user gnodet opened a pull request:

https://github.com/apache/felix/pull/143

[FELIX-5795] Maven Bundle Plugin Should Upgrade to Use Maven Dependen…

…cy Tree 3.x

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gnodet/felix FELIX-5795

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/143.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #143


commit 770c4656670a9b4a2fddbe137a15cae9a7cb7805
Author: Guillaume Nodet 
Date:   2018-06-15T12:12:06Z

[FELIX-5795] Maven Bundle Plugin Should Upgrade to Use Maven Dependency 
Tree 3.x




> Maven Bundle Plugin Should Upgrade to Use Maven Dependency Tree 3.x
> ---
>
> Key: FELIX-5795
> URL: https://issues.apache.org/jira/browse/FELIX-5795
> Project: Felix
>  Issue Type: Wish
>  Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.5.0
>Reporter: Kai-Chung Yan
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: maven-bundle-plugin-4.0.0
>
>
> Currently Maven Bundle Plugin uses 
> [DependencyTree|https://github.com/apache/maven-dependency-tree/blob/maven-dependency-tree-2.1/src/main/java/org/apache/maven/shared/dependency/tree/DependencyTreeBuilder.java]
>  API which is removed in the latest Maven Dependency Tree (3.0.1). The usage 
> is in 
> [BundleAllPlugin.java|https://github.com/apache/felix/blob/maven-bundle-plugin-3.5.0/src/main/java/org/apache/felix/bundleplugin/BundleAllPlugin.java#L57].
> Would be great if the plugin take an update. As of Buster, Debian already 
> updated Maven Dependency Tree to 3.x, which renders Maven Bundle Plugin 
> [FTBFS|https://bugs.debian.org/880886] (fail to build from source).
> -This won't be a trivial fix as quite a few APIs are removed.- The 
> maintainers in Fedora has written a 
> [patch|https://src.fedoraproject.org/rpms/maven-plugin-bundle/blob/master/f/0001-Port-to-current-maven-dependency-tree.patch]
>  to fix this, please consider adopting it.



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

[jira] [Commented] (FELIX-5866) scr does not respect the log level set in LoggerAdmin

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5866:
---

Github user rotty3000 closed the pull request at:

https://github.com/apache/felix/pull/142


> scr does not respect the log level set in LoggerAdmin
> -
>
> Key: FELIX-5866
> URL: https://issues.apache.org/jira/browse/FELIX-5866
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Reporter: Raymond Augé
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: scr-2.1.2
>
>
> With R7 logging, configuration of logging levels takes place through the 
> LoggerAdmin.
> SCR first checks it's own log level configuration ignoring the level set in 
> LoggerAdmin.
> I believe that when r7 logging is enabled, the SCR should first check the 
> LoggerAdmin level and only then fallback to the SCR configuration.



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

[jira] [Commented] (FELIX-5867) reference field of type Logger for service LoggerFactory is always null

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5867:
---

Github user rotty3000 closed the pull request at:

https://github.com/apache/felix/pull/141


> reference field of type Logger for service LoggerFactory is always null
> ---
>
> Key: FELIX-5867
> URL: https://issues.apache.org/jira/browse/FELIX-5867
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Reporter: Raymond Augé
>Priority: Major
>
> When trying the following snippet as defined in the r7 spec:
> {code}
> import org.osgi.service.component.annotations.Activate;
> import org.osgi.service.component.annotations.Component;
> import org.osgi.service.component.annotations.Reference;
> import org.osgi.service.log.Logger;
> import org.osgi.service.log.LoggerFactory;
> @Component
> public class WithLogger {
>     @Reference(service = LoggerFactory.class)
>     private Logger logger;
>     @Activate
>     void activate() {
>         logger.info(l -> l.info("TESTING"));
>     }
> }
> {code}
> the logger field is always null with no obvious errors in the logs.
> There's an obvious error due to the NPE in the activate method, but not why 
> the reference field is null.
>  The SCR logs as follows:
> {code}
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37) BundleComponentActivator : 
> Bundle active
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)BundleComponentActivator : 
> Descriptor locations 
> OSGI-INF/org.apache.aries.cdi.test.components.WithLogger.xml
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37) BundleComponentActivator : 
> ComponentHolder created.
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)BundleComponentActivator : May 
> enable component holder org.apache.aries.cdi.test.components.WithLogger
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)BundleComponentActivator 
> :Enabling component holder org.apache.aries.cdi.test.components.WithLogger
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)Querying state disabled
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)Querying state disabled
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)Component can not be activated 
> since it is in state disabled
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)Querying state disabled
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37) Updating target filters
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)No change in target property 
> for dependency logger: currently registered: false
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37) No existing service listener 
> to unregister for dependency logger
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)Setting target property for 
> dependency logger to null
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)New service tracker for 
> logger, initial active: false, previous references: {}, classFilter: 
> (objectClass=org.osgi.service.log.LoggerFactory), eventFilter null, 
> initialReferenceFilter (objectClass=org.osgi.service.log.LoggerFactory)
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)dm logger tracker reset 
> (closed)
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)classNameFilter: 
> (objectClass=org.osgi.service.log.LoggerFactory) event filter: null
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)dm logger tracking 1 
> SingleStatic added \{org.osgi.service.log.LogService, 
> org.osgi.service.log.LoggerFactory, 
> org.eclipse.equinox.log.ExtendedLogService}=\{service.id=2, 
> service.bundleid=0, service.scope=bundle} (enter)
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)dm logger tracking 1 
> SingleStatic active: false trackerOpened: 

[jira] [Commented] (FELIX-5866) scr does not respect the log level set in LoggerAdmin

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5866:
---

GitHub user rotty3000 opened a pull request:

https://github.com/apache/felix/pull/142

FELIX-5866 scr does not respect the log level set in LoggerAdmin

Signed-off-by: Raymond Auge 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/rotty3000/felix FELIX-5866

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/142.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #142


commit ec5bd8e0d2b4b87207a2b176912c948b882d4332
Author: Raymond Auge 
Date:   2018-06-12T17:33:52Z

FELIX-5866 scr does not respect the log level set in LoggerAdmin

Signed-off-by: Raymond Auge 




> scr does not respect the log level set in LoggerAdmin
> -
>
> Key: FELIX-5866
> URL: https://issues.apache.org/jira/browse/FELIX-5866
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Reporter: Raymond Augé
>Priority: Major
> Fix For: scr-2.1.2
>
>
> With R7 logging, configuration of logging levels takes place through the 
> LoggerAdmin.
> SCR first checks it's own log level configuration ignoring the level set in 
> LoggerAdmin.
> I believe that when r7 logging is enabled, the SCR should first check the 
> LoggerAdmin level and only then fallback to the SCR configuration.



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

[jira] [Commented] (FELIX-5867) reference field of type Logger for service LoggerFactory is always null

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5867:
---

GitHub user rotty3000 opened a pull request:

https://github.com/apache/felix/pull/141

FELIX-5867 reference field of type Logger for service LoggerFactory i…

…s always null

Signed-off-by: Raymond Auge 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/rotty3000/felix FELIX-5867

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/141.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #141


commit ef4dbf7629f7264f1311d3c2b3548c7c8feb21dc
Author: Raymond Auge 
Date:   2018-06-12T20:30:30Z

FELIX-5867 reference field of type Logger for service LoggerFactory is 
always null

Signed-off-by: Raymond Auge 




> reference field of type Logger for service LoggerFactory is always null
> ---
>
> Key: FELIX-5867
> URL: https://issues.apache.org/jira/browse/FELIX-5867
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Reporter: Raymond Augé
>Priority: Major
>
> When trying the following snippet as defined in the r7 spec:
> {code}
> import org.osgi.service.component.annotations.Activate;
> import org.osgi.service.component.annotations.Component;
> import org.osgi.service.component.annotations.Reference;
> import org.osgi.service.log.Logger;
> import org.osgi.service.log.LoggerFactory;
> @Component
> public class WithLogger {
>     @Reference(service = LoggerFactory.class)
>     private Logger logger;
>     @Activate
>     void activate() {
>         logger.info(l -> l.info("TESTING"));
>     }
> }
> {code}
> the logger field is always null with no obvious errors in the logs.
> There's an obvious error due to the NPE in the activate method, but not why 
> the reference field is null.
>  The SCR logs as follows:
> {code}
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37) BundleComponentActivator : 
> Bundle active
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)BundleComponentActivator : 
> Descriptor locations 
> OSGI-INF/org.apache.aries.cdi.test.components.WithLogger.xml
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37) BundleComponentActivator : 
> ComponentHolder created.
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)BundleComponentActivator : May 
> enable component holder org.apache.aries.cdi.test.components.WithLogger
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)BundleComponentActivator 
> :Enabling component holder org.apache.aries.cdi.test.components.WithLogger
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)Querying state disabled
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)Querying state disabled
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)Component can not be activated 
> since it is in state disabled
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)Querying state disabled
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37) Updating target filters
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)No change in target property 
> for dependency logger: currently registered: false
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37) No existing service listener 
> to unregister for dependency logger
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)Setting target property for 
> dependency logger to null
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> cdi-itests.services-one:0.0.2.201806121839 (37)New service tracker for 
> logger, initial active: false, previous references: {}, classFilter: 
> (objectClass=org.osgi.service.log.LoggerFactory), eventFilter null, 
> initialReferenceFilter (objectClass=org.osgi.service.log.LoggerFactory)
> [main] DEBUG LogService.cdi-itests.services-one:? - bundle 
> 

[jira] [Commented] (FELIX-5860) Upgrade to OSGi Compendium 6.0.0

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5860:
---

GitHub user jbonofre opened a pull request:

https://github.com/apache/felix/pull/139

[FELIX-5860] Upgrade to OSGi Compendium 6.0.0



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jbonofre/felix FELIX-5860

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/139.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #139


commit db96915d1ad7cd414881dc5284e1b7ad879aaad1
Author: Jean-Baptiste Onofré 
Date:   2018-05-23T14:45:36Z

[FELIX-5860] Upgrade to OSGi Compendium 6.0.0




> Upgrade to OSGi Compendium 6.0.0
> 
>
> Key: FELIX-5860
> URL: https://issues.apache.org/jira/browse/FELIX-5860
> Project: Felix
>  Issue Type: Improvement
>  Components: Connect
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: connect-0.2.0
>
>




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

[jira] [Commented] (FELIX-4193) make maven bundle plugin generate indexes compliant with the R5 Repository Service Specification

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-4193:
---

GitHub user manandbytes opened a pull request:

https://github.com/apache/felix/pull/138

FELIX-4193 - Make maven bundle plugin generate indexes compliant with…

… the R5 Repository Service Specification

According to Apache Felix OSGi Bundle Repository (OBR) homepage [1]:

As of release 2.0.x Felix OBR also supports the OSGi Repository
1.0 specification. Chapter 132 in the OSGi R5 Enterprise
specification.

Upgrade dependency o.a.f.bundlerepository AKA 'Felix OBR' from the
ancient 1.6.x to the latest release.

[1] 
https://felix.apache.org/documentation/subprojects/apache-felix-osgi-bundle-repository.html

Signed-off-by: Mykola Nikishov 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/manandbytes/felix felix-4193-update-obr

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/138.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #138


commit 111ade29163306420e28cd0c41203f3cfc44a735
Author: Mykola Nikishov 
Date:   2018-05-22T20:14:52Z

FELIX-4193 - Make maven bundle plugin generate indexes compliant with the 
R5 Repository Service Specification

According to Apache Felix OSGi Bundle Repository (OBR) homepage [1]:

As of release 2.0.x Felix OBR also supports the OSGi Repository
1.0 specification. Chapter 132 in the OSGi R5 Enterprise
specification.

Upgrade dependency o.a.f.bundlerepository AKA 'Felix OBR' from the
ancient 1.6.x to the latest release.

[1] 
https://felix.apache.org/documentation/subprojects/apache-felix-osgi-bundle-repository.html

Signed-off-by: Mykola Nikishov 




> make maven bundle plugin generate indexes compliant with the R5 Repository 
> Service Specification
> 
>
> Key: FELIX-4193
> URL: https://issues.apache.org/jira/browse/FELIX-4193
> Project: Felix
>  Issue Type: Improvement
>  Components: Maven Bundle Plugin
>Reporter: Cristiano Gavião
>Priority: Major
>
> Currently the index generated by maven-bundle-plugin cannot be used by a 
> Repository Service.
> So I would like to generate a repository indexes compliant with the 
> Repository Service Specification version 1.0, as defined in the OSGi Service 
> Platform Service Compendium, Release 5.
> BND or Bindex could be used since they already are compliant.



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

[jira] [Commented] (FELIX-5850) ResourceBuilder should do deal with null bundle manifest version

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5850:
---

Github user jbonofre closed the pull request at:

https://github.com/apache/felix/pull/137


> ResourceBuilder should do deal with null bundle manifest version
> 
>
> Key: FELIX-5850
> URL: https://issues.apache.org/jira/browse/FELIX-5850
> Project: Felix
>  Issue Type: Bug
>  Components: Utils
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: utils-1.11.2
>
>
> The {{ResourceBuilder#doBuild}} should deal with empty (null) bundle manifest 
> version.
> We should do:
> {code}
> private static String getBundleManifestVersion(Map 
> headerMap) {
> return headerMap.get(Constants.BUNDLE_MANIFESTVERSION);
> }
>...
>// Verify that only manifest version 2 is specified.
> String manifestVersion = getBundleManifestVersion(headerMap);
> if (!"2".equals(manifestVersion)) {
> throw new BundleException("Bundle-ManifestVersion must be 2 but 
> is: " + manifestVersion);
> }
> {code}
> I will provide a PR (and test with Karaf itest).



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

[jira] [Commented] (FELIX-5850) ResourceBuilder should do deal with null bundle manifest version

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5850:
---

GitHub user jbonofre opened a pull request:

https://github.com/apache/felix/pull/137

[FELIX-5850] Deal with non present Bundle-ManifestVersion header



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jbonofre/felix FELIX-5850

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/137.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #137


commit 3feb7cdc85446a9092b482b9b7ec70f2adf9df54
Author: Jean-Baptiste Onofré 
Date:   2018-05-10T16:49:57Z

[FELIX-5850] Deal with non present Bundle-ManifestVersion header




> ResourceBuilder should do deal with null bundle manifest version
> 
>
> Key: FELIX-5850
> URL: https://issues.apache.org/jira/browse/FELIX-5850
> Project: Felix
>  Issue Type: Bug
>  Components: Utils
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: utils-1.11.2
>
>
> The {{ResourceBuilder#doBuild}} should deal with empty (null) bundle manifest 
> version.
> We should do:
> {code}
> private static String getBundleManifestVersion(Map 
> headerMap) {
> return headerMap.get(Constants.BUNDLE_MANIFESTVERSION);
> }
>...
>// Verify that only manifest version 2 is specified.
> String manifestVersion = getBundleManifestVersion(headerMap);
> if (!"2".equals(manifestVersion)) {
> throw new BundleException("Bundle-ManifestVersion must be 2 but 
> is: " + manifestVersion);
> }
> {code}
> I will provide a PR (and test with Karaf itest).



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

[jira] [Commented] (FELIX-5832) ConfigInstaller should only handle events for configurations it manages

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5832:
---

GitHub user cgdrake opened a pull request:

https://github.com/apache/felix/pull/134

[FELIX-5832] Only handle ConfigurationEvents for config objects managed by 
us



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cgdrake/felix bugfix/FELIX-5832

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/134.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #134






> ConfigInstaller should only handle events for configurations it manages
> ---
>
> Key: FELIX-5832
> URL: https://issues.apache.org/jira/browse/FELIX-5832
> Project: Felix
>  Issue Type: Bug
>  Components: File Install
>Affects Versions: fileinstall-3.6.0, fileinstall-3.6.2
>Reporter: Chris Drake
>Priority: Major
> Attachments: ConfigInstaller.diff
>
>
> Recent changes introduced by FELIX-5609 have caused ConfigInstaller to 
> incorrectly write configuration objets which it does not manage to disk.
> For example, given:
> {code:java}
> felix.fileinstall.filter=.*\\.cfg|.*\\.json{code}
> and a CustomConfigInstaller implementing the ArtifactInstaller and 
> ConfigurationListener interfaces for .json configuration files, the 
> expectation is that .cfg files will be installed and written back to disk by 
> Felix's ConfigInstaller.  Any .json configuration files will be installed and 
> written to disk by the CustomConfigInstaller. Unfortunately since FileInstall 
> 3.6.0, .json config files written to disk by the CustomConfigInstaller are 
> overwritten by Felix's own ConfigInstaller.
> The regression is caused by a change to the ConfigInstaller, whereby 
> ConfigurationEvents for _*all configuration objects*_ are handled as apposed 
> to previous behaviour where only those configuration objects managed by the 
> Felix ConfigInstaller (aka .cfg and .config) are managed.



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

[jira] [Commented] (FELIX-5831) Async/sync Thread Pool Ratio is not changeable at runtime

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5831:
---

Github user asfgit closed the pull request at:

https://github.com/apache/felix/pull/133


> Async/sync Thread Pool Ratio is not changeable at runtime
> -
>
> Key: FELIX-5831
> URL: https://issues.apache.org/jira/browse/FELIX-5831
> Project: Felix
>  Issue Type: Bug
>  Components: Event Admin
>Affects Versions: eventadmin-1.4.10
>Reporter: Benjamin Graf
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: eventadmin-1.5.0
>
>
> There is a small bug in Configuration.java line 338. I think it should be
> {code:java}
> config.get(...){code}
> instead of 
> {code:java}
> m_bundleContext.getProperty(...){code}
> to be changeable at runtime.



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

[jira] [Commented] (FELIX-5831) Async/sync Thread Pool Ratio is not changeable at runtime

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5831:
---

GitHub user graben opened a pull request:

https://github.com/apache/felix/pull/133

FELIX-5831: Use config instead of bundleContext to get property



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/graben/felix FELIX-5831

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/133.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #133


commit 61a37fbc8fc5c5a154f05339e5d5d0d0a763bd2c
Author: Benjamin Graf 
Date:   2018-04-16T18:31:14Z

FELIX-5831: Use config instead of bundleContext to get property




> Async/sync Thread Pool Ratio is not changeable at runtime
> -
>
> Key: FELIX-5831
> URL: https://issues.apache.org/jira/browse/FELIX-5831
> Project: Felix
>  Issue Type: Bug
>  Components: Event Admin
>Affects Versions: eventadmin-1.4.10
>Reporter: Benjamin Graf
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: eventadmin-1.5.0
>
>
> There is a small bug in Configuration.java line 338. I think it should be
> {code:java}
> config.get(...){code}
> instead of 
> {code:java}
> m_bundleContext.getProperty(...){code}
> to be changeable at runtime.



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

[jira] [Commented] (FELIX-5782) allow resolver errors to be introspected

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5782:
---

Github user rotty3000 closed the pull request at:

https://github.com/apache/felix/pull/132


> allow resolver errors to be introspected
> 
>
> Key: FELIX-5782
> URL: https://issues.apache.org/jira/browse/FELIX-5782
> Project: Felix
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Raymond Augé
>Assignee: Thomas Watson
>Priority: Minor
>
> The current model for resolver errors does not provide any means of 
> introspecting deeper knowledge that the resolver gained. The information is 
> internal only, which makes user feedback more difficult to produce than 
> necessary.
> I propose to expose the error types by means of an exported package 
> {{org.apache.felix.resolver.error}}. This will allow interested clients to 
> dig more deeply into the reasons for resolution failure in order to provide 
> better feedback to users.



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

[jira] [Commented] (FELIX-5782) allow resolver errors to be introspected

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5782:
---

GitHub user rotty3000 opened a pull request:

https://github.com/apache/felix/pull/132

FELIX-5782 allow resolver errors to be introspected

Signed-off-by: Raymond Augé 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/rotty3000/felix resolver.introspection

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/132.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #132


commit a9ed345c6fb0d9cab23c6e7189728766ef114d61
Author: Raymond Augé 
Date:   2018-01-31T20:31:18Z

FELIX-5782 allow resolver errors to be introspected

Signed-off-by: Raymond Augé 




> allow resolver errors to be introspected
> 
>
> Key: FELIX-5782
> URL: https://issues.apache.org/jira/browse/FELIX-5782
> Project: Felix
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Raymond Augé
>Assignee: Thomas Watson
>Priority: Minor
>
> The current model for resolver errors does not provide any means of 
> introspecting deeper knowledge that the resolver gained. The information is 
> internal only, which makes user feedback more difficult to produce than 
> necessary.
> I propose to expose the error types by means of an exported package 
> {{org.apache.felix.resolver.error}}. This will allow interested clients to 
> dig more deeply into the reasons for resolution failure in order to provide 
> better feedback to users.



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

[jira] [Commented] (FELIX-5782) allow resolver errors to be introspected

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5782:
---

Github user rotty3000 closed the pull request at:

https://github.com/apache/felix/pull/131


> allow resolver errors to be introspected
> 
>
> Key: FELIX-5782
> URL: https://issues.apache.org/jira/browse/FELIX-5782
> Project: Felix
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Raymond Augé
>Assignee: Thomas Watson
>Priority: Minor
>
> The current model for resolver errors does not provide any means of 
> introspecting deeper knowledge that the resolver gained. The information is 
> internal only, which makes user feedback more difficult to produce than 
> necessary.
> I propose to expose the error types by means of an exported package 
> {{org.apache.felix.resolver.error}}. This will allow interested clients to 
> dig more deeply into the reasons for resolution failure in order to provide 
> better feedback to users.



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

[jira] [Commented] (FELIX-5782) allow resolver errors to be introspected

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5782:
---

GitHub user rotty3000 opened a pull request:

https://github.com/apache/felix/pull/131

FELIX-5782 allow resolver errors to be introspected

Signed-off-by: Raymond Augé 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/rotty3000/felix trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/131.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #131


commit 07e9f6ccb6be3c9fa193bcfc1ded607a7622eecd
Author: Raymond Augé 
Date:   2018-01-31T20:31:18Z

FELIX-5782 allow resolver errors to be introspected

Signed-off-by: Raymond Augé 




> allow resolver errors to be introspected
> 
>
> Key: FELIX-5782
> URL: https://issues.apache.org/jira/browse/FELIX-5782
> Project: Felix
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Raymond Augé
>Assignee: Raymond Augé
>Priority: Minor
>
> The current model for resolver errors does not provide any means of 
> introspecting deeper knowledge that the resolver gained. The information is 
> internal only, which makes user feedback more difficult to produce than 
> necessary.
> I propose to expose the error types by means of an exported package 
> {{org.apache.felix.resolver.error}}. This will allow interested clients to 
> dig more deeply into the reasons for resolution failure in order to provide 
> better feedback to users.



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

[jira] [Commented] (FELIX-5464) java.lang.NullPointerException at org.apache.felix.scrplugin.helper.ClassScanner.processClass(ClassScanner.java:207)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5464:
---

GitHub user sjhiggs opened a pull request:

https://github.com/apache/felix/pull/126

FELIX-5464: NPE in org.apache.felix.scrplugin.helper.ClassScanner

Couldn't make this happen by invoking public method in a unit test, but 
checked for null InputStream before closing, logged debug message otherwise.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sjhiggs/felix FELIX-5464

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/126.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #126


commit fb55f8043dd06501803aa1028102d7affea2f186
Author: Stephen Higgs 
Date:   2017-10-30T01:12:17Z

FELIX-5464: NPE in org.apache.felix.scrplugin.helper.ClassScanner




> java.lang.NullPointerException at 
> org.apache.felix.scrplugin.helper.ClassScanner.processClass(ClassScanner.java:207)
> 
>
> Key: FELIX-5464
> URL: https://issues.apache.org/jira/browse/FELIX-5464
> Project: Felix
>  Issue Type: Bug
>  Components: SCR Tooling
>Affects Versions: scr generator 1.15.0
> Environment: Jenkins 2.36
> Maven 3.3.9
> Java 1.7.0_79
>Reporter: Alexander Nöhrer
>
> I am encountering this problem on and off again only within our Jenkins build 
> environment, I cannot reproduce it locally with the same java and maven 
> version. Also after some code changes not related to SCR annotated classes it 
> works again then it doesn't.
> Unfortunately I also was not able to produce a minimum example to reproduce 
> this.
> Basically I guess what would already help, is to check against 'null' and log 
> the 'pathToClassFile' that caused the input to be 'null'.
> By the way I wanted to do this myself just to get more information what is 
> wrong in my environment, however the http://felix.apache.org/downloads.cgi 
> links for the generator sources return 404...
> Here the output on Jenkins:
> [ERROR] Failed to execute goal org.apache.felix:maven-scr-plugin:1.23.0:scr 
> (generate-scr-scrdescriptor) on project XXX: Execution 
> generate-scr-scrdescriptor of goal 
> org.apache.felix:maven-scr-plugin:1.23.0:scr failed. NullPointerException -> 
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.felix:maven-scr-plugin:1.23.0:scr 
> (generate-scr-scrdescriptor) on project inew-commons-rest-exporter-rest: 
> Execution generate-scr-scrdescriptor of goal 
> org.apache.felix:maven-scr-plugin:1.23.0:scr failed.
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
>   at 
> org.jvnet.hudson.maven3.launcher.Maven33Launcher.main(Maven33Launcher.java:129)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:330)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:238)
>   at jenkins.maven3.agent.Maven33Main.launch(Maven33Main.java:176)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 

[jira] [Commented] (FELIX-5724) FileInstall does not detect undeployed files at startup

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5724:
---

Github user grgrzybek closed the pull request at:

https://github.com/apache/felix/pull/125


> FileInstall does not detect undeployed files at startup
> ---
>
> Key: FELIX-5724
> URL: https://issues.apache.org/jira/browse/FELIX-5724
> Project: Felix
>  Issue Type: Bug
>  Components: File Install
>Reporter: Guillaume Nodet
> Fix For: fileinstall-3.7.0
>
>




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

[jira] [Commented] (FELIX-5724) FileInstall does not detect undeployed files at startup

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5724:
---

GitHub user grgrzybek opened a pull request:

https://github.com/apache/felix/pull/125

[FELIX-5724] Handle CM_DELETED properly (+tests)



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/grgrzybek/felix FELIX-5724

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/125.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #125


commit e29ff308a317998e4027ef771cf5b0f004600723
Author: Grzegorz Grzybek 
Date:   2017-10-23T10:34:43Z

[FELIX-5724] Handle CM_DELETED properly (+tests)




> FileInstall does not detect undeployed files at startup
> ---
>
> Key: FELIX-5724
> URL: https://issues.apache.org/jira/browse/FELIX-5724
> Project: Felix
>  Issue Type: Bug
>  Components: File Install
>Reporter: Guillaume Nodet
>




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

[jira] [Commented] (FELIX-5651) Disable Log history in Gogo console

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5651:
---

Github user asfgit closed the pull request at:

https://github.com/apache/felix/pull/112


> Disable Log history in Gogo console
> ---
>
> Key: FELIX-5651
> URL: https://issues.apache.org/jira/browse/FELIX-5651
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo JLine
>Affects Versions: gogo.jline-1.0.6
>Reporter: Mickaël SEBIRE
> Fix For: gogo.jline-1.0.10
>
>
> In some case, it can be usefull to disable the command history for an 
> application.
> If the user that starts the application does not have the right to create a 
> directory in its home directory.
> I would to had a command line parameter : "--nohistory" to disable the usage 
> of the history.



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

[jira] [Commented] (FELIX-5698) Bundle plugin cannot cope with Java 9 module-info.java

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5698:
---

GitHub user johnpoth opened a pull request:

https://github.com/apache/felix/pull/122

[FELIX-5698] Upgrade biz.aQute.bndlib to 3.5.0 for Java 9 GA support

https://issues.apache.org/jira/browse/FELIX-5698

Thanks!

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/johnpoth/felix FELIX-5698

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/122.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #122


commit 17dd7598750e33cd93854aa1bf5b1d647dc86c5a
Author: jpoth 
Date:   2017-10-03T10:21:18Z

[FELIX-5698] Upgrade biz.aQute.bndlib to 3.5.0 for Java 9 GA support




> Bundle plugin cannot cope with Java 9 module-info.java
> --
>
> Key: FELIX-5698
> URL: https://issues.apache.org/jira/browse/FELIX-5698
> Project: Felix
>  Issue Type: Bug
>  Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.3.0
> Environment: java version "9"
> Java(TM) SE Runtime Environment (build 9+181)
> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>Reporter: Mark Raynsford
>
> Please see the trivial repro case at:
> [maven-bundle-plugin-20170923|https://github.com/io7m/maven-bundle-plugin-20170923]
> The plugin fails with:
> {noformat}
> [ERROR] Bundle com.io7m.bugs:maven-bundle-plugin-20170923:bundle:0.1.0 : 
> Exception: java.lang.ArrayIndexOutOfBoundsException: 19
> [ERROR] Bundle com.io7m.bugs:maven-bundle-plugin-20170923:bundle:0.1.0 : 
> Invalid class file module-info.class 
> (java.lang.ArrayIndexOutOfBoundsException: 19)
> {noformat}
> There doesn't appear to be a way to exclude the module-info.java files from 
> BND's class file analysis. An easy fix for this bug would be to simple ignore 
> module-info.java files as they're irrelevant for OSGi (but will be present in 
> projects that aim to support both OSGi and Jigsaw).



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

[jira] [Commented] (FELIX-4447) Regression in ScrShellCommand (NPE caused by falsy regex)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-4447:
---

GitHub user cgdrake opened a pull request:

https://github.com/apache/felix/pull/120

[FELIX-4447] fix regexp, thanks to Olivier Fayau

git-svn-id: https://svn.apache.org/repos/asf/felix/trunk/scr@1591422 
13f79535-47bb-0310-9956-ffa450edef68

Given that this is a low impact and trivial fix which causes a fair bit of 
aggrevation, it would be great if this could be merged into the scr-1.8.x 
branch and released in 1.8.5.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cgdrake/felix scr-1.8.x

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/120.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #120


commit 29e5f8d247c5e927b6e703a7b1ed2f87d5015fa7
Author: David Jencks 
Date:   2014-04-30T18:01:38Z

[FELIX-4447] fix regexp, thanks to Olivier Fayau

git-svn-id: https://svn.apache.org/repos/asf/felix/trunk/scr@1591422 
13f79535-47bb-0310-9956-ffa450edef68




> Regression in ScrShellCommand (NPE caused by falsy regex)
> -
>
> Key: FELIX-4447
> URL: https://issues.apache.org/jira/browse/FELIX-4447
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR), Script Console Plugin
>Affects Versions: scr-1.8.0, scr-1.8.2
>Reporter: Olivier Fayau
>Assignee: David Jencks
>  Labels: easyfix
> Fix For: scr-2.0.0
>
>
> Using felix console and DS (scr + shell +shell tui), the command scr doesn't 
> work anymore.
> Sample : 
> scr list
> -> Unable to execute command: java.lang.NullPointerException
> java.lang.NullPointerException
>   at 
> org.apache.felix.scr.impl.ScrShellCommand.help(ScrShellCommand.java:116)
>   at 
> org.apache.felix.scr.impl.ScrShellCommand.execute(ScrShellCommand.java:75)
>   at 
> org.apache.felix.shell.impl.Activator$ShellServiceImpl.executeCommand(Activator.java:249)
>   at 
> org.apache.felix.shell.tui.Activator$ShellTuiRunnable.run(Activator.java:184)
>   at java.lang.Thread.run(Unknown Source)
> Looking at source code, in ScrShellCommand.execute(), command is splitted by 
> the falsy regex "//s".
> This should be "\\s+" instead.



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

[jira] [Commented] (FELIX-5680) Add createResource(URLConnection conn) to DataModelHelperImpl to support URLs that require Authentication

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5680:
---

GitHub user dangiankit opened a pull request:

https://github.com/apache/felix/pull/119

[FELIX-5680] Add createResource(URLConnection conn) to DataModelHelperImpl

- Allows for URLs to support Authorization and other HttpHeaders.
- Calls FileUtil.openURL(URLConnection conn) rather than 
FileUtil.openURL(URL url).
- JIRA: https://issues.apache.org/jira/browse/FELIX-5680

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dangiankit/felix AD-FELIX-5680

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/119.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #119


commit 533e0e926567efe509f3f75c15b5a8bb906adea4
Author: dangiankit 
Date:   2017-08-28T16:16:09Z

[FELIX-5680] Add createResource(URLConnection conn) to DataModelHelperImpl

- Allows for URLs to support Authorization and other HttpHeaders.
- Calls FileUtil.openURL(URLConnection conn) rather than
FileUtil.openURL(URL url).




> Add createResource(URLConnection conn) to DataModelHelperImpl to support URLs 
> that require Authentication
> -
>
> Key: FELIX-5680
> URL: https://issues.apache.org/jira/browse/FELIX-5680
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.10
> Environment: macOS 10.12.6, Felix 5.6.4
>Reporter: Ankit Dangi
> Fix For: bundlerepository-2.0.12
>
>
> Referring to classes: 
> * org.apache.felix.bundlerepository.impl.DataModelHelperImpl.java 
> * org.apache.felix.bundlerepository.impl.FileUtil.java
> Current scenario: The method DataModelHelperImpl.createResource(URL 
> bundleUrl) has an inner method loadEntry(String name) that calls 
> FileUtil.openURL(bundleUrl) on the line 479. FileUtil.openURL(URL bundleURL) 
> is a helper function for FileUtil.openURL(URLConnection conn). 
> Problem: It restricts the use of URL connections that require authorization. 
> As a result, a 401 error occurs for bundleURLs that require 
> HttpHeaders.AUTHORIZATION. Note: It is not the same as setting 
> Proxy-Authorization because Authorization is a different HTTPHeader. 
> Possible Solution: Overload the DataModelHelperImpl.createResource() such 
> that it takes as input a URLConnection object which then calls the 
> FileUtil.openURL(conn). An URLConnection object has method 
> setRequestProperty(key, value) which could then make it possible for 
> DataModelHelperImpl.createResource() to handle diverse scenarios. 



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

[jira] [Commented] (FELIX-5412) Pretty format not implemented in JSON serializer

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5412:
---

Github user dleangen closed the pull request at:

https://github.com/apache/felix/pull/118


> Pretty format not implemented in JSON serializer
> 
>
> Key: FELIX-5412
> URL: https://issues.apache.org/jira/browse/FELIX-5412
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Reporter: David Leangen
>Assignee: David Leangen
>
> There is a configuration for "pretty" formatting, but it has not yet been 
> implemented.



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

[jira] [Commented] (FELIX-5412) Pretty format not implemented in JSON serializer

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5412:
---

GitHub user dleangen opened a pull request:

https://github.com/apache/felix/pull/118

[FELIX-5412] Pretty format not implemented in JSON serializer

@bosschaert, here is the PR for your review and so we can discuss. If 
approved, I will accept and merge.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dleangen/felix serializer-formatting

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/118.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #118


commit 9d07ca06ef4769a378046b2706f0126e7c0738b7
Author: David Leangen 
Date:   2017-08-24T11:26:15Z

[FELIX-5412] Pretty format not implemented in JSON serializer




> Pretty format not implemented in JSON serializer
> 
>
> Key: FELIX-5412
> URL: https://issues.apache.org/jira/browse/FELIX-5412
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Reporter: David Leangen
>Assignee: David Leangen
>
> There is a configuration for "pretty" formatting, but it has not yet been 
> implemented.



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

[jira] [Commented] (FELIX-5665) High CPU usage on sun.reflect.Generated* class loads by log4j

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5665:
---

Github user asfgit closed the pull request at:

https://github.com/apache/felix/pull/116


> High CPU usage on sun.reflect.Generated* class loads by log4j 
> --
>
> Key: FELIX-5665
> URL: https://issues.apache.org/jira/browse/FELIX-5665
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-5.6.4
>Reporter: AnilKumar Attuluri
> Fix For: framework-5.6.8
>
> Attachments: FELIX-5665.patch, IMG_1.jpg, IMG_2.jpg
>
>
> We have been running some performance tests to prepare our OSGi bundle 
> (*running in Apache Karaf*) for production.
> Just to give some background about our OSGi bundle, we converted an existing 
> Spring application into an OSGi bundle with all the current dependencies 
> packaged into the bundle as an uber artifact.
> When we run >= 500 TPS (each of these calls results in a http call made via a 
> library) we run into this high CPU usage spikes reaching up to 100% CPU. 
> Please see the image attached, the spikes in the image are 100% CPU usage 
> while the average is about 40%. Also see the CPU sampler image which points 
> to 
> *org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation*
> Is there an existing bug/documentation that already captures this?
> We don't see this behavior when we run the same app in standalone JVM.
>  



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

[jira] [Commented] (FELIX-5665) High CPU usage on sun.reflect.Generated* class loads by log4j

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5665:
---

GitHub user anilutcs opened a pull request:

https://github.com/apache/felix/pull/116

Terminate class load for sun.reflect.GeneratedMethodAccessor* when the 
property is set

Refer to https://issues.apache.org/jira/browse/FELIX-5665 for more details.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/anilutcs/felix trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/116.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #116


commit 27be0aa4a0c04e5028c2bc959d3576e928b123d5
Author: aattuluri 
Date:   2017-08-08T23:12:03Z

Add property based termination of class search for 
sun.reflect.GeneratedMethodAccessor* classes.

commit daad505112c1cca0e6490c6a4c3462fe32a4ad3a
Author: aattuluri 
Date:   2017-08-09T03:49:06Z

Move termination to not incur the cost of boot delegation.

commit e06ff2a77aa395a0140512168a22cb6237638ed1
Author: aattuluri 
Date:   2017-08-09T03:56:06Z

Rename property.




> High CPU usage on sun.reflect.Generated* class loads by log4j 
> --
>
> Key: FELIX-5665
> URL: https://issues.apache.org/jira/browse/FELIX-5665
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-5.6.4
>Reporter: AnilKumar Attuluri
> Fix For: framework-5.6.8
>
> Attachments: IMG_1.jpg, IMG_2.jpg
>
>
> We have been running some performance tests to prepare our OSGi bundle 
> (*running in Apache Karaf*) for production.
> Just to give some background about our OSGi bundle, we converted an existing 
> Spring application into an OSGi bundle with all the current dependencies 
> packaged into the bundle as an uber artifact.
> When we run >= 500 TPS (each of these calls results in a http call made via a 
> library) we run into this high CPU usage spikes reaching up to 100% CPU. 
> Please see the image attached, the spikes in the image are 100% CPU usage 
> while the average is about 40%. Also see the CPU sampler image which points 
> to 
> *org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation*
> Is there an existing bug/documentation that already captures this?
> We don't see this behavior when we run the same app in standalone JVM.
>  



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

[jira] [Commented] (FELIX-5669) Registering a PersistenceManager causes duplicate caches

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-5669:
---

Github user brjeter closed the pull request at:

https://github.com/apache/felix/pull/115


> Registering a PersistenceManager causes duplicate caches
> 
>
> Key: FELIX-5669
> URL: https://issues.apache.org/jira/browse/FELIX-5669
> Project: Felix
>  Issue Type: Bug
>Affects Versions: configadmin-1.8.12
>Reporter: Brandan Jeter
>Assignee: Carsten Ziegeler
> Fix For: configadmin-1.9.0
>
>
> When registering a PersistenceManager, the next call to a method in 
> ConfigurationManager will call getPersistenceManagers(). Instead of 
> preserving the existing CachingPersistenceManagerProxy that wraps the default 
> FilePersistenceManager, ConfigurationManager creates a brand new one. But 
> previous Configuration objects still have reference to the old 
> CachingPersistenceManagerProxy, so when one of them gets deleted/updated it 
> does not get deleted/updated in the ConfigurationManager's reference.



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