Re: [VOTE] Release Apache Felix CM Json 1.0.0

2020-04-16 Thread Jean-Baptiste Onofre
+1 (binding)

It’s great because I need this release for Karaf ;)

Thanks Carsten !

Regards
JB

> Le 17 avr. 2020 à 07:50, Carsten Ziegeler  a écrit :
> 
> Hi,
> 
> i've extracted the handling of json based configurations from the 
> configurator implementation and made a separate api out of it which allows to 
> read/write configuration (resources). Without this api, tooling needing to 
> deal with configuration resources either needed to reinvent the wheel or 
> depend on configurator implementation internals.
> 
> So please cast your vote for the first release of this module
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1332
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1332 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org



[VOTE] Release Apache Felix CM Json 1.0.0

2020-04-16 Thread Carsten Ziegeler

Hi,

i've extracted the handling of json based configurations from the 
configurator implementation and made a separate api out of it which 
allows to read/write configuration (resources). Without this api, 
tooling needing to deal with configuration resources either needed to 
reinvent the wheel or depend on configurator implementation internals.


So please cast your vote for the first release of this module

Staging repositories:
https://repository.apache.org/content/repositories/orgapachefelix-1332

You can use this UNIX script to download the release and verify the
signatures:
https://github.com/apache/felix-dev/blob/master/check_staged_release.sh

Usage:
sh check_staged_release.sh 1332 /tmp/felix-staging

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


[GitHub] [felix-atomos] stbischof opened a new pull request #21: change from Stream to List

2020-04-16 Thread GitBox
stbischof opened a new pull request #21: change from Stream to List
URL: https://github.com/apache/felix-atomos/pull/21
 
 
   


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


With regards,
Apache Git Services


[jira] [Resolved] (FELIX-6255) Allow to update a specific bundle through the UI

2020-04-16 Thread Carsten Ziegeler (Jira)


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

Carsten Ziegeler resolved FELIX-6255.
-
Resolution: Fixed

Implemented in 
https://github.com/apache/felix-dev/commit/900047476eb1a86891cc65c170b9792bbc3f3b81

> Allow to update a specific bundle through the UI
> 
>
> Key: FELIX-6255
> URL: https://issues.apache.org/jira/browse/FELIX-6255
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: webconsole-4.4.2
>
>
> If you upload a bundle through the web console UI, it has a "smart detection" 
> whether this is an update or an install of a new bundle. If a bundle with the 
> same BSN exists, it will be updated. If there is more than one bundle with 
> the same BSN, the one with the highest version will be used.
> This prevents updating the bundle with the lower BSN through the UI.
> We should add a button next to the bundle (like we already have for refresh, 
> remove etc.) which allows to update exactly this bundle.



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


[jira] [Assigned] (FELIX-6255) Allow to update a specific bundle through the UI

2020-04-16 Thread Carsten Ziegeler (Jira)


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

Carsten Ziegeler reassigned FELIX-6255:
---

Assignee: Carsten Ziegeler

> Allow to update a specific bundle through the UI
> 
>
> Key: FELIX-6255
> URL: https://issues.apache.org/jira/browse/FELIX-6255
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: webconsole-4.4.2
>
>
> If you upload a bundle through the web console UI, it has a "smart detection" 
> whether this is an update or an install of a new bundle. If a bundle with the 
> same BSN exists, it will be updated. If there is more than one bundle with 
> the same BSN, the one with the highest version will be used.
> This prevents updating the bundle with the lower BSN through the UI.
> We should add a button next to the bundle (like we already have for refresh, 
> remove etc.) which allows to update exactly this bundle.



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


[jira] [Closed] (FELIX-6220) Refactor injection implementation

2020-04-16 Thread Carsten Ziegeler (Jira)


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

Carsten Ziegeler closed FELIX-6220.
---

> Refactor injection implementation
> -
>
> Key: FELIX-6220
> URL: https://issues.apache.org/jira/browse/FELIX-6220
> Project: Felix
>  Issue Type: Improvement
>  Components: Declarative Services (SCR)
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: scr-2.1.18
>
>
> Over the last releases we already started to refactor the injection 
> implementation (constructor, field, reference injection) and use an internal 
> API layer to abstract from the actual implementation.
> However, the work is currently only half done, we have interfaces for some 
> parts but directly use implementations for others. We should try to clean 
> this up and have interfaces for everything



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


[jira] [Closed] (FELIX-6257) Update Jetty to 9.4.28.v20200408

2020-04-16 Thread Carsten Ziegeler (Jira)


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

Carsten Ziegeler closed FELIX-6257.
---

> Update Jetty to 9.4.28.v20200408
> 
>
> Key: FELIX-6257
> URL: https://issues.apache.org/jira/browse/FELIX-6257
> Project: Felix
>  Issue Type: Improvement
>  Components: HTTP Service
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: http.jetty-4.0.18
>
>
> We should update to the latest jetty release: 9.4.28.v20200408



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


[jira] [Closed] (FELIX-6253) Potential deadlock in HttpServiceRuntimeImpl updateChangeCount

2020-04-16 Thread Carsten Ziegeler (Jira)


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

Carsten Ziegeler closed FELIX-6253.
---

> Potential deadlock in HttpServiceRuntimeImpl updateChangeCount
> --
>
> Key: FELIX-6253
> URL: https://issues.apache.org/jira/browse/FELIX-6253
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.base-4.0.8, http.bridge-4.0.10, http.jetty-4.0.16
>Reporter: Karl Pauls
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: http.jetty-4.0.18, http.base-4.0.10, http.bridge-4.0.12
>
>
> There is a possible deadlock in the HttpServiceRuntimeImpl updateChangeCount 
> similar to FELIX-6252
> T



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


[jira] [Closed] (FELIX-6107) Loggging Passwords when invoking activate Method

2020-04-16 Thread Carsten Ziegeler (Jira)


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

Carsten Ziegeler closed FELIX-6107.
---

> Loggging Passwords when invoking activate Method
> 
>
> Key: FELIX-6107
> URL: https://issues.apache.org/jira/browse/FELIX-6107
> Project: Felix
>  Issue Type: Improvement
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.16
>Reporter: Stefan Bischof
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: scr-2.1.18
>
>
> Configurations with an MetaType - AttributeDefinitions of the Type "Password" 
> shouldn't be logged.
>  
> got this Log:
> {code:java}
> invoking activate: act: parameters [my.domain.my.Service$Cfg : {hashCode=0, 
> pw=hack, equals=false, annotationType=null, toString=null}]{code}
>  
> From:
> org.apache.felix.scr.impl.inject.methods.BaseMethod:invokeMethod:Line 226/227
>  
> The MetaType of the parameter is "password"
>  
>  
>  
>  
>  



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


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

2020-04-16 Thread Carsten Ziegeler (Jira)


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

Carsten Ziegeler closed FELIX-6251.
---

> 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
>Assignee: Tom Watson
>Priority: Major
> Fix For: scr-2.1.18
>
>  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] [Closed] (FELIX-6218) Replace kxml2 with standard SAX XML parser

2020-04-16 Thread Carsten Ziegeler (Jira)


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

Carsten Ziegeler closed FELIX-6218.
---

> Replace kxml2 with standard SAX XML parser
> --
>
> Key: FELIX-6218
> URL: https://issues.apache.org/jira/browse/FELIX-6218
> Project: Felix
>  Issue Type: Improvement
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.16
>Reporter: Mat Booth
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: scr-2.1.18
>
>
> Currently SCR requires kxml2 (and transitively xpp3) at build time and them 
> embeds some classes from these two libraries in the resulting Felix SCR 
> bundle. However these projects seem quite dead and have not seen any official 
> activity in many years. [1]
> When I tried to investigate why Felix SCR uses kxml2, I hit a dead-end 
> because the repository history does not go back far enough. SCR seems to have 
> been imported already using kxml2/xpp3.
> Two possibilities spring to mind:
>  * It was before Java 1.5, so there was no SAX implementation in the JDK yet
>  * SCR used to target some constrained execution environment that it no 
> longer supports.
> In either case, since Felix SCR now requires JavaSE-1.7 as its minimal 
> execution environment I advocate switching to the SAX implementation provided 
> by the JDK
>  
> I will post a PR
>  
> [1] http://www.xmlpull.org/



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


[jira] [Closed] (FELIX-6096) SCR fails if the Java Runtime Environment does not support permissions

2020-04-16 Thread Carsten Ziegeler (Jira)


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

Carsten Ziegeler closed FELIX-6096.
---

> SCR fails if the Java Runtime Environment does not support permissions
> --
>
> Key: FELIX-6096
> URL: https://issues.apache.org/jira/browse/FELIX-6096
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.16
>Reporter: Christoph Fiehe
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: scr-2.1.18
>
>
> SCR fails with a ClassNotFoundException, if the Java Runtime Environment does 
> not support permissions.
> In the method {{checkBundleLocation(String configBundleLocation, Bundle 
> bundle)}} of the class {{RegionConfigurationSupport}} there must be checked, 
> if security is supported by the underlying JRE like it is has been done in 
> {{AbstractComponentManager#hasServiceRegistrationPermissions}} or 
> {{DependencyManager#hasGetPermission}}.



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


[jira] [Closed] (FELIX-6241) IllegalStateException can be thrown from listener if BundleContext is invalid

2020-04-16 Thread Carsten Ziegeler (Jira)


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

Carsten Ziegeler closed FELIX-6241.
---

> IllegalStateException can be thrown from listener if BundleContext is invalid
> -
>
> Key: FELIX-6241
> URL: https://issues.apache.org/jira/browse/FELIX-6241
> Project: Felix
>  Issue Type: Improvement
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.16
>Reporter: Tom Watson
>Assignee: Tom Watson
>Priority: Major
> Fix For: scr-2.1.18
>
>
> If a bundle is stopped on one thread and SCR service listener is responding 
> to service events on another thread it is possible to see the following 
> exception get fired as a FrameworkEvent Error:
>  
> {{FrameworkEvent ERROR java.lang.IllegalStateException: BundleContext is no 
> longer valid}}
> {{    at 
> org.eclipse.osgi.internal.framework.BundleContextImpl.checkValid(BundleContextImpl.java:1055)}}
> {{    at 
> org.eclipse.osgi.internal.framework.BundleContextImpl.ungetService(BundleContextImpl.java:726)}}
> {{    at 
> org.apache.felix.scr.impl.manager.SingleRefPair.ungetServiceObjects(SingleRefPair.java:72)}}
> {{    at 
> org.apache.felix.scr.impl.manager.DependencyManager$AbstractCustomizer.ungetService(DependencyManager.java:226)}}
> {{    at 
> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:399)}}
> {{    at 
> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:294)}}
> {{    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)}}
>  
> The IllegalStateException should be caught here and ignored when trying to 
> unget a service.  A similar IllegalStateException is caught and ignored when 
> using ServiceObjects with 
> {{org.apache.felix.scr.impl.manager.AbstractPrototypeRefPair.doUngetService(ScrComponentContext,
>  T)}}



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


[jira] [Closed] (FELIX-6215) Cannot run scr unit tests on Java 11

2020-04-16 Thread Carsten Ziegeler (Jira)


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

Carsten Ziegeler closed FELIX-6215.
---

> Cannot run scr unit tests on Java 11
> 
>
> Key: FELIX-6215
> URL: https://issues.apache.org/jira/browse/FELIX-6215
> Project: Felix
>  Issue Type: Improvement
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.16
>Reporter: Mat Booth
>Assignee: Tom Watson
>Priority: Major
> Fix For: scr-2.1.18
>
>
> When trying to run unit tests for Felix SCR on a Java 11 VM, it fails with 
> this sort of error:
>  
> {code:java}
> [ERROR] test_packageT1SSI(org.apache.felix.scr.impl.inject.BindMethodTest)  
> Time elapsed: 0.009 s  <<< ERROR!
> org.mockito.exceptions.base.MockitoException: Mockito cannot mock this class: 
> interface org.osgi.framework.ServiceReference.Mockito can only mock 
> non-private & non-final classes.
> If you're not sure why you're getting this error, please report to the 
> mailing list.
> Java   : 11
> JVM vendor name: Oracle Corporation
> JVM vendor version : 11.0.6+10
> JVM name   : OpenJDK 64-Bit Server VM
> JVM version: 11.0.6+10
> JVM info   : mixed mode
> OS name: Linux
> OS version : 5.4.12-100.fc30.x86_64
> Underlying exception : java.lang.UnsupportedOperationException: Cannot define 
> class using reflection
>   at 
> org.apache.felix.scr.impl.inject.BindMethodTest.setUp(BindMethodTest.java:59)
> Caused by: java.lang.UnsupportedOperationException: Cannot define class using 
> reflection
>   at 
> org.apache.felix.scr.impl.inject.BindMethodTest.setUp(BindMethodTest.java:59)
> Caused by: java.lang.IllegalStateException: Could not find sun.misc.Unsafe
>   at 
> org.apache.felix.scr.impl.inject.BindMethodTest.setUp(BindMethodTest.java:59)
> Caused by: java.lang.NoSuchMethodException: 
> sun.misc.Unsafe.defineClass(java.lang.String, [B, int, int, 
> java.lang.ClassLoader, java.security.ProtectionDomain)
>   at 
> org.apache.felix.scr.impl.inject.BindMethodTest.setUp(BindMethodTest.java:59)
> {code}



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


[jira] [Closed] (FELIX-6252) Deadlock in SCR ComponentRegistry updateChangeCount

2020-04-16 Thread Carsten Ziegeler (Jira)


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

Carsten Ziegeler closed FELIX-6252.
---

> Deadlock in SCR ComponentRegistry updateChangeCount
> ---
>
> Key: FELIX-6252
> URL: https://issues.apache.org/jira/browse/FELIX-6252
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.16
>Reporter: Karl Pauls
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: scr-2.1.18
>
>
> There is a possible deadlock in the ComponentRegistry and it goes like this:
> The update of the change count is setting up a timer to execute a task while 
> it is holding a lock. The task in turn, is grabbing that lock when activated 
> and calls into the service registry while holding the lock. 
> Now, when a service gets unregistered that is coming from a factory - the 
> service registry will do an upcall that triggers scr to update the change 
> count and hence, trying to grab the lock mentioned above.
> That can cause a case where the task has the lock and is waiting in the 
> service registry which is waiting on scr, which is waiting for the lock.
> E.g.:
> For the tasks:
> {code:java}
>   java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for <0x0007bc02ea40> (a 
> java.util.concurrent.CountDownLatch$Sync)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
>   at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
>   at 
> org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:368)
>   at 
> org.apache.felix.framework.EventDispatcher.filterListenersUsingHooks(EventDispatcher.java:618)
>   at 
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:542)
>   at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
>   at org.apache.felix.framework.Felix.access$000(Felix.java:112)
>   at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:434)
>   at 
> org.apache.felix.framework.ServiceRegistry.servicePropertiesModified(ServiceRegistry.java:612)
>   at 
> org.apache.felix.framework.ServiceRegistrationImpl.setProperties(ServiceRegistrationImpl.java:132)
>   at 
> org.apache.felix.scr.impl.ComponentRegistry$4.run(ComponentRegistry.java:743)
>   - locked <0x00074376fb00> (a java.lang.Object)
>   at java.util.TimerThread.mainLoop(Timer.java:555)
>   at java.util.TimerThread.run(Timer.java:505)
> {code}
> and for the update:
> {code:java}
>   java.lang.Thread.State: BLOCKED (on object monitor)at 
> org.apache.felix.scr.impl.ComponentRegistry.updateChangeCount(ComponentRegistry.java:722)
> - waiting to lock <0x00074376fb00> (a java.lang.Object)at 
> org.apache.felix.scr.impl.BundleComponentActivator.updateChangeCount(BundleComponentActivator.java:778)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.setState(AbstractComponentManager.java:1420)
> at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:962)
> at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:900)
> at 
> org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:348)
> at 
> org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:248)
> at 
> org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:350)
> at 
> org.apache.felix.framework.EventDispatcher.filterListenersUsingHooks(EventDispatcher.java:618)
> at 
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:542)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
> at org.apache.felix.framework.Felix.access$000(Felix.java:112)at 
> org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:434)at 
> org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:170)
> {code}
> [~cziegeler], could you have a look and see if that is fixable by not holding 
> the lock while calling into the serviceregistry?



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


[jira] [Closed] (FELIX-6206) NPE in ComponentRegistry.getComponentHolders()

2020-04-16 Thread Carsten Ziegeler (Jira)


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

Carsten Ziegeler closed FELIX-6206.
---

> NPE in ComponentRegistry.getComponentHolders()
> --
>
> Key: FELIX-6206
> URL: https://issues.apache.org/jira/browse/FELIX-6206
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.14
>Reporter: Robert Varga
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: scr-2.1.18
>
> Attachments: 
> 0001-FELIX-6202-ignore-component-name-reservations-in-Com.patch
>
>
> We encountered the following splat in OpenDaylight:
> {code:java}
> java.lang.NullPointerException: null
>   at 
> org.apache.felix.scr.impl.ComponentRegistry.getComponentHolders(ComponentRegistry.java:360)
>  ~[?:?]
>   at 
> org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.getComponentDescriptionDTOs(ServiceComponentRuntimeImpl.java:76)
>  ~[?:?]
>   at 
> org.apache.karaf.scr.state.ScrBundleStateService.getDiag(ScrBundleStateService.java:43)
>  ~[?:?]
>   at 
> org.apache.karaf.bundle.core.internal.BundleServiceImpl.getDiag(BundleServiceImpl.java:112)
>  ~[?:?]
>   at Proxy3fe0a7aa_4f02_41e1_846b_e34ff5062233.getDiag(Unknown Source) 
> ~[?:?]
>   at 
> org.opendaylight.odlparent.bundlestest.lib.BundleDiagInfosImpl.forContext(BundleDiagInfosImpl.java:90)
>  ~[?:?]
>   at 
> org.opendaylight.odlparent.bundlestest.lib.TestBundleDiag.getBundleDiagInfos(TestBundleDiag.java:118)
>  ~[?:?]
>   at 
> org.awaitility.core.AbstractHamcrestCondition$1.eval(AbstractHamcrestCondition.java:50)
>  ~[?:?]
>   at 
> org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:190)
>  ~[?:?]
>   at 
> org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:177)
>  ~[?:?]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>  ~[?:?]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>  ~[?:?]
>   at java.lang.Thread.run(Thread.java:834) [?:?]{code}



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


[VOTE RESULT] Release http.base 4.0.10, http.bridge 4.0.12, and http.jetty 4.0.18

2020-04-16 Thread Carsten Ziegeler

The vote passes with 6 binding +1 votes and 1 non binding +1 vote

Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


Re: [VOTE] Release http.base 4.0.10, http.bridge 4.0.12, and http.jetty 4.0.18

2020-04-16 Thread Carsten Ziegeler

+1

Carsten

On 13.04.2020 17:43, Carsten Ziegeler wrote:

Hi,

We solved 2 issues in http.jetty 4.0.18:

https://issues.apache.org/jira/browse/FELIX-6257?jql=project%20%3D%20FELIX%20AND%20fixVersion%20%3D%20http.jetty-4.0.18 



and one issue in http.base 4.0.10 and http.bridge 4.0.12:
https://issues.apache.org/jira/browse/FELIX-6253

Staging repositories:
https://repository.apache.org/content/repositories/orgapachefelix-1330

You can use this UNIX script to download the release and verify the
signatures:
https://github.com/apache/felix-dev/blob/master/check_staged_release.sh

Usage:
sh check_staged_release.sh 1330 /tmp/felix-staging

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


--
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


[VOTE RESULT] Release Apache Felix SCR 2.1.18

2020-04-16 Thread Carsten Ziegeler

The vote passes with five binding and three non binding +1 votes

Thanks
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


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

2020-04-16 Thread A. J. David Bosschaert (Jira)


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

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

Fix in PR https://github.com/apache/felix-dev/pull/18

> 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-6242) Conversion of boolean to Long results in Integer

2020-04-16 Thread 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)


[GitHub] [felix-dev] bosschaert opened a new pull request #18: FELIX-6242 Conversion of boolean to Long results in Integer

2020-04-16 Thread GitBox
bosschaert opened a new 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


With regards,
Apache Git Services


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

2020-04-16 Thread A. J. David Bosschaert (Jira)


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

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



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


[GitHub] [felix-dev] bosschaert commented on issue #10: [converter] handle default methods - FELIX-6239

2020-04-16 Thread GitBox
bosschaert commented on issue #10: [converter] handle default methods - 
FELIX-6239
URL: https://github.com/apache/felix-dev/pull/10#issuecomment-614627240
 
 
   @stbischof is there more work needed or can 
https://issues.apache.org/jira/browse/FELIX-6239 be marked as resolved?


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


With regards,
Apache Git Services


[jira] [Resolved] (FELIX-6254) Package refresh does not attach fragments

2020-04-16 Thread Carsten Ziegeler (Jira)


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

Carsten Ziegeler resolved FELIX-6254.
-
Resolution: Fixed

Implemented in [1] - when installing a fragment, the start option is now 
ignored, if "refresh packages" is activated the host is refreshed. Similar of 
the global refresh packages is invoked, hosts of unattached fragments are 
refreshed

[1] 
https://github.com/apache/felix-dev/commit/a866b6d914ed8d4df53249d91c76648c81c36417

> Package refresh does not attach fragments
> -
>
> Key: FELIX-6254
> URL: https://issues.apache.org/jira/browse/FELIX-6254
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Affects Versions: webconsole-4.4.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: webconsole-4.4.2
>
>
> When a fragment bundle is installed and "Package Refresh" is invoked, the 
> fragment is not attached to its host. It requires to hit "Package Refresh" on 
> the host bundle.



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


Re: [VOTE] Release Apache Felix Parent 7

2020-04-16 Thread Georg Henzler

+1

-Georg

On 2020-04-15 20:53, Jean-Baptiste Onofre wrote:

+1 (binding)

Regards
JB

Le 15 avr. 2020 à 13:53, Carsten Ziegeler  a 
écrit :


Hi,

i've updated our parent pom to the latest plugin versions, switched to 
Java 8 as the default version (bnd >= 4.0.0 requires it anyway), 
changed http: urls to https: and allow to use Java versions > 9 for a 
project.


Staging repositories:
https://repository.apache.org/content/repositories/orgapachefelix-1331

You can use this UNIX script to download the release and verify the
signatures:
https://github.com/apache/felix-dev/blob/master/check_staged_release.sh

Usage:
sh check_staged_release.sh 1331 /tmp/felix-staging

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


[jira] [Resolved] (FELIX-6260) Require Java 8 and OSGi R6

2020-04-16 Thread Carsten Ziegeler (Jira)


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

Carsten Ziegeler resolved FELIX-6260.
-
Resolution: Fixed

Updated pom and dependencies in 1ef800e808

> Require Java 8 and OSGi R6
> --
>
> Key: FELIX-6260
> URL: https://issues.apache.org/jira/browse/FELIX-6260
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: webconsole-4.4.2
>
>
> The web console has very old code; in order to allow to add new functionality 
> and improve the code we should update the requirements to Java 8 and OSGi R6 
> - both are out for several years 



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


[jira] [Created] (FELIX-6260) Require Java 8 and OSGi R6

2020-04-16 Thread Carsten Ziegeler (Jira)
Carsten Ziegeler created FELIX-6260:
---

 Summary: Require Java 8 and OSGi R6
 Key: FELIX-6260
 URL: https://issues.apache.org/jira/browse/FELIX-6260
 Project: Felix
  Issue Type: Improvement
  Components: Web Console
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: webconsole-4.4.2


The web console has very old code; in order to allow to add new functionality 
and improve the code we should update the requirements to Java 8 and OSGi R6 - 
both are out for several years 



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