Re: [VOTE] Release Apache Felix Parent 7

2020-04-15 Thread Jean-Baptiste Onofre 
+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

Re: [VOTE] Release Apache Felix Parent 7

2020-04-15 Thread Pierre De Rop 
+1

pierre

On Wed, Apr 15, 2020 at 4:13 PM  wrote:

> +1
>
> David
>
> On Wed, 15 Apr 2020 at 12:53, Carsten Ziegeler 
> wrote:
>
> > 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] [Commented] (FELIX-4682) [DS] NPE during deactivation of OSGi framework

2020-04-15 Thread Arnoud Glimmerveen (Jira) 


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

Arnoud Glimmerveen commented on FELIX-4682:
---

[~bdaniel] as this issue only happened very sporadically, it will be tricky to 
verify if FELIX-6251 actually solved it. Looking at the changes, I agree it is 
likely that it at least influences the behaviour observed in this issue, and 
possibly also solving it. 

Should we consider/mark this issue as a duplicate of FLEIX-6251 and close it 
once 2.1.18 release has been completed?

> [DS] NPE during deactivation of OSGi framework
> --
>
> Key: FELIX-4682
> URL: https://issues.apache.org/jira/browse/FELIX-4682
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-1.8.2
> Environment: Equinox OSGi 3.8.2 
> Felix SCR 1.8.2
>Reporter: Arnoud Glimmerveen
>Priority: Major
>
> During the shutdown of the OSGi framework (Equinox), the following 
> NullPointerException was thrown:
> {noformat}
> java.lang.NullPointerException
> at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:964)
> at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:895)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1506)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1401)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.untrack(ServiceTracker.java:1261)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1440)
> at 
> org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:107)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:861)
> at 
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at 
> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:819)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry$1.run(ServiceRegistry.java:775)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:773)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:225)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.unregister(AbstractComponentManager.java:1011)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.unregister(AbstractComponentManager.java:992)
> at 
> org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:141)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterService(AbstractComponentManager.java:1054)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:900)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:883)
> at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:974)
> at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:895)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1506)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1401)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.untrack(ServiceTracker.java:1261)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1440)
> at 
> org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:107)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:861)
> at 
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at 
> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:819)
> at 
>

[jira] [Resolved] (FELIX-4682) [DS] NPE during deactivation of OSGi framework

2020-04-15 Thread Tom Watson (Jira) 


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

Tom Watson resolved FELIX-4682.
---
Resolution: Duplicate

> [DS] NPE during deactivation of OSGi framework
> --
>
> Key: FELIX-4682
> URL: https://issues.apache.org/jira/browse/FELIX-4682
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-1.8.2
> Environment: Equinox OSGi 3.8.2 
> Felix SCR 1.8.2
>Reporter: Arnoud Glimmerveen
>Priority: Major
>
> During the shutdown of the OSGi framework (Equinox), the following 
> NullPointerException was thrown:
> {noformat}
> java.lang.NullPointerException
> at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:964)
> at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:895)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1506)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1401)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.untrack(ServiceTracker.java:1261)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1440)
> at 
> org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:107)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:861)
> at 
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at 
> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:819)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry$1.run(ServiceRegistry.java:775)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:773)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:225)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.unregister(AbstractComponentManager.java:1011)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.unregister(AbstractComponentManager.java:992)
> at 
> org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:141)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterService(AbstractComponentManager.java:1054)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:900)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:883)
> at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:974)
> at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:895)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1506)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1401)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.untrack(ServiceTracker.java:1261)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1440)
> at 
> org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:107)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:861)
> at 
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at 
> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:819)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry$1.run(ServiceRegistry.java:775)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:773)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:225)
> at 
>

[jira] [Commented] (FELIX-4682) [DS] NPE during deactivation of OSGi framework

2020-04-15 Thread Tom Watson (Jira) 


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

Tom Watson commented on FELIX-4682:
---

I agree, this will be fixed in the next release

> [DS] NPE during deactivation of OSGi framework
> --
>
> Key: FELIX-4682
> URL: https://issues.apache.org/jira/browse/FELIX-4682
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-1.8.2
> Environment: Equinox OSGi 3.8.2 
> Felix SCR 1.8.2
>Reporter: Arnoud Glimmerveen
>Priority: Major
>
> During the shutdown of the OSGi framework (Equinox), the following 
> NullPointerException was thrown:
> {noformat}
> java.lang.NullPointerException
> at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:964)
> at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:895)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1506)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1401)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.untrack(ServiceTracker.java:1261)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1440)
> at 
> org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:107)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:861)
> at 
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at 
> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:819)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry$1.run(ServiceRegistry.java:775)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:773)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:225)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.unregister(AbstractComponentManager.java:1011)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.unregister(AbstractComponentManager.java:992)
> at 
> org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:141)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterService(AbstractComponentManager.java:1054)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:900)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:883)
> at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:974)
> at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:895)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1506)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1401)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.untrack(ServiceTracker.java:1261)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1440)
> at 
> org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:107)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:861)
> at 
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at 
> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:819)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry$1.run(ServiceRegistry.java:775)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:773)
> at 
>

[jira] [Commented] (FELIX-4682) [DS] NPE during deactivation of OSGi framework

2020-04-15 Thread Brent Daniel (Jira) 


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

Brent Daniel commented on FELIX-4682:
-

This should be fixed now by Tom's changes in 
https://issues.apache.org/jira/browse/FELIX-6251

> [DS] NPE during deactivation of OSGi framework
> --
>
> Key: FELIX-4682
> URL: https://issues.apache.org/jira/browse/FELIX-4682
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-1.8.2
> Environment: Equinox OSGi 3.8.2 
> Felix SCR 1.8.2
>Reporter: Arnoud Glimmerveen
>Priority: Major
>
> During the shutdown of the OSGi framework (Equinox), the following 
> NullPointerException was thrown:
> {noformat}
> java.lang.NullPointerException
> at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:964)
> at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:895)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1506)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1401)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.untrack(ServiceTracker.java:1261)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1440)
> at 
> org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:107)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:861)
> at 
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at 
> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:819)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry$1.run(ServiceRegistry.java:775)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:773)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:225)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.unregister(AbstractComponentManager.java:1011)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.unregister(AbstractComponentManager.java:992)
> at 
> org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:141)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterService(AbstractComponentManager.java:1054)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:900)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:883)
> at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:974)
> at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:895)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1506)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1401)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.untrack(ServiceTracker.java:1261)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1440)
> at 
> org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:107)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:861)
> at 
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at 
> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:819)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry$1.run(ServiceRegistry.java:775)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:773)
> at 
>

Re: [VOTE] Release Apache Felix Parent 7

2020-04-15 Thread davidb 
+1

David

On Wed, 15 Apr 2020 at 12:53, Carsten Ziegeler  wrote:

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

Re: [VOTE] Release Apache Felix Parent 7

2020-04-15 Thread Carsten Ziegeler 

+1

Carsten

On 15.04.2020 13:53, Carsten Ziegeler wrote:

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


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

Re: [VOTE] Release Apache Felix Parent 7

2020-04-15 Thread Raymond Auge 
+1

- Ray

On Wed, Apr 15, 2020 at 7:53 AM Carsten Ziegeler 
wrote:

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


-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)

[jira] [Updated] (FELIX-6259) java.util.ConcurrentModificationException building Apache Commons CSV on Java 15-EA

2020-04-15 Thread Gary D. Gregory (Jira) 


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

Gary D. Gregory updated FELIX-6259:
---
  Component/s: Maven Bundle Plugin
Affects Version/s: maven-bundle-plugin-4.2.1

> java.util.ConcurrentModificationException building Apache Commons CSV on Java 
> 15-EA
> ---
>
> Key: FELIX-6259
> URL: https://issues.apache.org/jira/browse/FELIX-6259
> Project: Felix
>  Issue Type: Bug
>  Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-4.2.1
>Reporter: Gary D. Gregory
>Priority: Major
>
> We get a java.util.ConcurrentModificationException building Apache Commons 
> CSV when building with Java 15-EA:
> {noformat}
> openjdk version "15-ea" 2020-09-15
> OpenJDK Runtime Environment (build 15-ea+18-776)
> OpenJDK 64-Bit Server VM (build 15-ea+18-776, mixed mode, sharing)
> {noformat}
> ConcurrentModificationException:
> {noformat}
> [INFO] --- maven-bundle-plugin:4.2.1:manifest (bundle-manifest) @ commons-csv 
> ---
> [ERROR] An internal error occurred
> java.util.ConcurrentModificationException
> at java.util.TreeMap.callMappingFunctionWithCheck (TreeMap.java:742)
> at java.util.TreeMap.computeIfAbsent (TreeMap.java:558)
> at aQute.bnd.osgi.Jar.putResource (Jar.java:288)
> at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:202)
> at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:177)
> at java.nio.file.Files.walkFileTree (Files.java:2804)
> at aQute.bnd.osgi.Jar.buildFromDirectory (Jar.java:176)
> at aQute.bnd.osgi.Jar. (Jar.java:119)
> at aQute.bnd.osgi.Jar. (Jar.java:172)
> at org.apache.felix.bundleplugin.BundlePlugin.getOSGiBuilder 
> (BundlePlugin.java:604)
> at org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer 
> (ManifestPlugin.java:285)
> at org.apache.felix.bundleplugin.ManifestPlugin.execute 
> (ManifestPlugin.java:111)
> at org.apache.felix.bundleplugin.BundlePlugin.execute 
> (BundlePlugin.java:364)
> 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:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:564)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main 
> (Launcher.java:347)
> {noformat}
> Full log: [https://pastebin.com/c3H3Zi7X]
> Travis log: [https://travis-ci.org/github/apache/commons-csv/jobs/675190349]



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

[jira] [Updated] (FELIX-6259) java.util.ConcurrentModificationException building Apache Commons CSV on Java 15-EA

2020-04-15 Thread Gary D. Gregory (Jira) 


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

Gary D. Gregory updated FELIX-6259:
---
Description: 
We get a java.util.ConcurrentModificationException building Apache Commons CSV 
when building with Java 15-EA:
{noformat}
openjdk version "15-ea" 2020-09-15
OpenJDK Runtime Environment (build 15-ea+18-776)
OpenJDK 64-Bit Server VM (build 15-ea+18-776, mixed mode, sharing)
{noformat}
ConcurrentModificationException:
{noformat}
[INFO] --- maven-bundle-plugin:4.2.1:manifest (bundle-manifest) @ commons-csv 
---
[ERROR] An internal error occurred
java.util.ConcurrentModificationException
at java.util.TreeMap.callMappingFunctionWithCheck (TreeMap.java:742)
at java.util.TreeMap.computeIfAbsent (TreeMap.java:558)
at aQute.bnd.osgi.Jar.putResource (Jar.java:288)
at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:202)
at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:177)
at java.nio.file.Files.walkFileTree (Files.java:2804)
at aQute.bnd.osgi.Jar.buildFromDirectory (Jar.java:176)
at aQute.bnd.osgi.Jar. (Jar.java:119)
at aQute.bnd.osgi.Jar. (Jar.java:172)
at org.apache.felix.bundleplugin.BundlePlugin.getOSGiBuilder 
(BundlePlugin.java:604)
at org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer 
(ManifestPlugin.java:285)
at org.apache.felix.bundleplugin.ManifestPlugin.execute 
(ManifestPlugin.java:111)
at org.apache.felix.bundleplugin.BundlePlugin.execute 
(BundlePlugin.java:364)
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:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:564)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:347)
{noformat}
Full log: [https://pastebin.com/c3H3Zi7X]

Travis log: [https://travis-ci.org/github/apache/commons-csv/jobs/675190349]

  was:
We get a java.util.ConcurrentModificationException building Apache Commons CSV 
when building with Java 15-EA:
{noformat}
openjdk version "15-ea" 2020-09-15
OpenJDK Runtime Environment (build 15-ea+18-776)
OpenJDK 64-Bit Server VM (build 15-ea+18-776, mixed mode, sharing)
{noformat}
ConcurrentModificationException:
{noformat}
[INFO] --- maven-bundle-plugin:4.2.1:manifest (bundle-manifest) @ commons-csv 
---
[ERROR] An internal error occurred
java.util.ConcurrentModificationException
at java.util.TreeMap.callMappingFunctionWithCheck (TreeMap.java:742)
at java.util.TreeMap.computeIfAbsent (TreeMap.java:558)
at aQute.bnd.osgi.Jar.putResource (Jar.java:288)
at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:202)
at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:177)
at java.nio.file.Files.walkFileTree (Files.java:2804)
at aQute.bnd.osgi.Jar.buildFromDirectory (Jar.java:176)
at aQute.bnd.osgi.Jar. (Jar.java:119)
at aQute.bnd.osgi.Jar. (Jar.java:172)
at org.apache.felix.bundleplugin.BundlePlugin.getOSGiBuilder 
(BundlePlugin.java:604)
at org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer 
(ManifestPlugin.java:285)
at org.apache.felix.bundleplugin.ManifestPlugin.execute 
(ManifestPlugin.java:111)
at org.apache.felix.bundleplugin.BundlePlugin.execute 
(BundlePlugin.java:364)
at

[jira] [Created] (FELIX-6259) java.util.ConcurrentModificationException building Apache Commons CSV on Java 15-EA

2020-04-15 Thread Gary D. Gregory (Jira) 
Gary D. Gregory created FELIX-6259:
--

 Summary: java.util.ConcurrentModificationException building Apache 
Commons CSV on Java 15-EA
 Key: FELIX-6259
 URL: https://issues.apache.org/jira/browse/FELIX-6259
 Project: Felix
  Issue Type: Bug
Reporter: Gary D. Gregory


We get a java.util.ConcurrentModificationException building Apache Commons CSV 
when building with Java 15-EA:
{noformat}
openjdk version "15-ea" 2020-09-15
OpenJDK Runtime Environment (build 15-ea+18-776)
OpenJDK 64-Bit Server VM (build 15-ea+18-776, mixed mode, sharing)
{noformat}
ConcurrentModificationException:
{noformat}
[INFO] --- maven-bundle-plugin:4.2.1:manifest (bundle-manifest) @ commons-csv 
---
[ERROR] An internal error occurred
java.util.ConcurrentModificationException
at java.util.TreeMap.callMappingFunctionWithCheck (TreeMap.java:742)
at java.util.TreeMap.computeIfAbsent (TreeMap.java:558)
at aQute.bnd.osgi.Jar.putResource (Jar.java:288)
at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:202)
at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:177)
at java.nio.file.Files.walkFileTree (Files.java:2804)
at aQute.bnd.osgi.Jar.buildFromDirectory (Jar.java:176)
at aQute.bnd.osgi.Jar. (Jar.java:119)
at aQute.bnd.osgi.Jar. (Jar.java:172)
at org.apache.felix.bundleplugin.BundlePlugin.getOSGiBuilder 
(BundlePlugin.java:604)
at org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer 
(ManifestPlugin.java:285)
at org.apache.felix.bundleplugin.ManifestPlugin.execute 
(ManifestPlugin.java:111)
at org.apache.felix.bundleplugin.BundlePlugin.execute 
(BundlePlugin.java:364)
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:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:564)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:347)
{noformat}
Full log: [https://pastebin.com/c3H3Zi7X]



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

[VOTE] Release Apache Felix Parent 7

2020-04-15 Thread Carsten Ziegeler 

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

Re: Proposal for a microservice blueprint

2020-04-15 Thread Christian Schneider 
I am not considering to do anything with native code at the moment. Atomos
might be an optional optimization but it is not what I want to focus on.

What I have in mind is a simple felix based microservice with just some
added services to make it fit nicely into the cloud. On the aries thread
Romain described nicely what additional services you typically want in the
cloud.

I think the startup speed is not a big issue. My example starts in about 2
seconds that is totally fine for normal services. Only for serverless you
might want a quicker startup.

Christian


-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

RE: How to handle SIGTERM

2020-04-15 Thread GLIMMERVEEN Arnoud 
Hi David,

Do you see that deleting a pod takes a long time? In my experience there is a 
particular way you must start your Java process/OSGi container in order for 
these signals to propagate, this is described here 
(https://hynek.me/articles/docker-signals/).

Best regards,

Arnoud

-Original Message-
From: David Leangen [mailto:o...@leangen.net]
Sent: Wednesday, 15 April, 2020 09:31
To: dev@felix.apache.org
Subject: How to handle SIGTERM

Hi!

Does Felix have a way of handling a SIGTERM event?

I was not able to find any documentation about that.

I am trying to containerize my app and run it in Kubernetes. It looks like 
Kubernetes can send a SIGTERM event to a container, and the container is 
expected to shutdown gracefully (do whatever cleanup is necessary).

If the container running Felix receives this signal, what happens to Felix? How 
can I gracefully handle this type of situation?


Thanks!
=David




Disclaimer:

If you are not the intended recipient of this email, please notify the sender 
and
delete it.
Any unauthorized copying, disclosure or distribution of this email or its
attachment(s) is forbidden.
Thales Nederland BV will not accept liability for any damage caused by this 
email or
its attachment(s).
Thales Nederland BV is seated in Hengelo and is registered at the Chamber of
Commerce under number 06061578.

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

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


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

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

Thanks for the additional tests [~cziegeler]! I hope to look at fixing this 
soon.

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

How to handle SIGTERM

2020-04-15 Thread David Leangen 
Hi!

Does Felix have a way of handling a SIGTERM event?

I was not able to find any documentation about that.

I am trying to containerize my app and run it in Kubernetes. It looks like 
Kubernetes can send a SIGTERM event to a container, and the container is 
expected to shutdown gracefully (do whatever cleanup is necessary).

If the container running Felix receives this signal, what happens to Felix? How 
can I gracefully handle this type of situation?


Thanks!
=David

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

2020-04-15 Thread Carsten Ziegeler (Jira) 


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

Carsten Ziegeler commented on FELIX-6242:
-

https://github.com/apache/felix-dev/blob/master/cm.json/src/test/java/org/apache/felix/cm/json/impl/TypeConverterTest.java#L454
 contains some test cases showing the  problem - the tests are commented out 
there as they currently fail

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

Re: Proposal for a microservice blueprint

2020-04-15 Thread Jean-Baptiste Onofre 
And here’s come Winegrower: the OSGi programming flavor (with service) with a 
single flat class loader ;)

Regards
JB

> Le 15 avr. 2020 à 08:11, Grzegorz Grzybek  a écrit :
> 
> Hello
> 
> First, I'm not good at telling what should be done or providing visions for
> something new and revolutionary. I'm experienced with checking what SHOULD
> NOT be done and how to polish/stabilize/cleanup existing things, created by
> much clever people than me.
> 
> [...] such as graalvm or quarkus. (I know so little about this that I could
>> be wrong about what these are).
>> 
> 
> I can provide a little explanation, but I'm not core Quarkus dev. When
> talking about "cloud", the above are very important.
> 
> GraalVM is based on HotSpot with these (roughly) differences:
> - through JVMCI interface (https://openjdk.java.net/jeps/243) the normal
> _compiler_ of hotspot (the bytecode -> native code compiler, not the source
> -> bytecode one) is replaced by Graal compiler
> - Graal compiler is written in Java, so it's JITted itself
> - Graal claims to create better native code
> - *Graal allows ahead-of-time compilation*
> - SubstrateVM being part of Graal has `native-image` tool, so you can get
> ELF binary from a Jar
> 
> Quarkus leverages the above, and brings many dev-friendly aspects to it
> (it's developed by Red Hat and it's kind of similar situation as with
> Kubernetes - OpenShift) - mind that I'm not much experienced with it yet
> - brings new tools to the dev toolkit (mostly maven plugins)
> - brings an API to expose the ahead-of-time aspects of Graal - generally,
> you can mark methods/classes of your code (through annotations) as "running
> in build phase"
> - "build phase" is executed before even starting the VM. Imagine
> HIbernate. When you create Hibernate based µservice and you start it, lots
> of time is spent reading XML/annotations and building SessionFactory. With
> Quarkus, this *all can be done at build phase* and you end up with bytecode
> (or in native case - premade memory pages that can simply be mapped to your
> process). Then when your main() starts, you don't have to create
> SessionFactory - you *have it*
> 
> Mind that the above is not precise, but should not miss the picture (I'm
> for example not sure about the premade memory pages).
> 
> OK. Now what should be avoided. In Red Hat Fuse 6 was based only on Karaf.
> Fuse 7 though has more forms and there's a lot about OpenShift. The
> problematic thing was - how to put Karaf into OpenShift.
> 
> Think about what is important in "cloud" - you need your pod/container
> start as fast as possible because of all this scaling-to-demand thing.
> Imagine lambda-functions (or whatever it's called nowadays). If a µservice
> would spend 95% of the time building SessionFactory and 5% inserting the
> record into database, it'd be crazy.
> 
> With OSGi, lots of warmup comes from bundle resolution. I know the
> resolution state can be persisted. But still.
> 
> I don't have clear answers or even clear feedback to this thread. I feel
> one thing - there are 2 critical and fundamental OSGi aspects:
> - module layer (bundles, manifests, caps-reqs)
> - service layer (service registry)
> 
> And while the service layer (supported by e.g., SCR annotations/runtime) is
> *the synonym of µservices* (see blog from 2010 when no one talked about it
> yet: https://blog.osgi.org/2010/03/services.html), the module layer is what
> may be a problem here.
> 
> All the effort with felix-connect, Atomos (which I've just checked covers
> SubstrateVM scenarios - I wasn't aware of this) is about making
> module-layer more cloud friendly.
> 
> I feel a little confused. Having worked 100% with OSGi for >6 years I found
> the original module layer the most important thing - because of the bundle
> resolution, cap-req matching, versioning, bundle revisions and wirings. The
> API and programming model aspect of OSGi was not that important which has
> two consequences:
> 1) I just got used to it that I have access to BundleContext,
> BundleRevision and other API interfaces and e.g., blueprint.xml format
> 2) If not the module layer of OSGi, nothing would keep me using the above
> API
> 
> CDI and Spring (annotations, XML) are other, widely used programming (and
> code-architecting) models and I somehow feel that when module layer is
> gone, these models are simply better, more flexible and less constraining
> than SCR or Blueprint.
> 
> So when OSGi "adopts" the module layer to the "cloud", turning it into
> flat-classpath deployment, what's the reason to call it OSGi at all?
> 
> Please don't get me wrong - I'm not going to sabotage any effort, I want to
> avoid the confusion.
> 
> Imagine this
> - we turn module layer into flat classpath
> - we use aries-cdi to allow programming beans/services using CDI
> annotations (JavaEE)
> - we use aries-jaxrs to create WS/REST endpoints using Jax-RS annotations
> (JavaEE)
> - we hide BundleContext.getServiceReference()/getService() APi
> 
>

Re: Proposal for a microservice blueprint

2020-04-15 Thread Grzegorz Grzybek 
Hello

First, I'm not good at telling what should be done or providing visions for
something new and revolutionary. I'm experienced with checking what SHOULD
NOT be done and how to polish/stabilize/cleanup existing things, created by
much clever people than me.

[...] such as graalvm or quarkus. (I know so little about this that I could
> be wrong about what these are).
>

I can provide a little explanation, but I'm not core Quarkus dev. When
talking about "cloud", the above are very important.

GraalVM is based on HotSpot with these (roughly) differences:
 - through JVMCI interface (https://openjdk.java.net/jeps/243) the normal
_compiler_ of hotspot (the bytecode -> native code compiler, not the source
-> bytecode one) is replaced by Graal compiler
 - Graal compiler is written in Java, so it's JITted itself
 - Graal claims to create better native code
 - *Graal allows ahead-of-time compilation*
 - SubstrateVM being part of Graal has `native-image` tool, so you can get
ELF binary from a Jar

Quarkus leverages the above, and brings many dev-friendly aspects to it
(it's developed by Red Hat and it's kind of similar situation as with
Kubernetes - OpenShift) - mind that I'm not much experienced with it yet
 - brings new tools to the dev toolkit (mostly maven plugins)
 - brings an API to expose the ahead-of-time aspects of Graal - generally,
you can mark methods/classes of your code (through annotations) as "running
in build phase"
 - "build phase" is executed before even starting the VM. Imagine
HIbernate. When you create Hibernate based µservice and you start it, lots
of time is spent reading XML/annotations and building SessionFactory. With
Quarkus, this *all can be done at build phase* and you end up with bytecode
(or in native case - premade memory pages that can simply be mapped to your
process). Then when your main() starts, you don't have to create
SessionFactory - you *have it*

Mind that the above is not precise, but should not miss the picture (I'm
for example not sure about the premade memory pages).

OK. Now what should be avoided. In Red Hat Fuse 6 was based only on Karaf.
Fuse 7 though has more forms and there's a lot about OpenShift. The
problematic thing was - how to put Karaf into OpenShift.

Think about what is important in "cloud" - you need your pod/container
start as fast as possible because of all this scaling-to-demand thing.
Imagine lambda-functions (or whatever it's called nowadays). If a µservice
would spend 95% of the time building SessionFactory and 5% inserting the
record into database, it'd be crazy.

With OSGi, lots of warmup comes from bundle resolution. I know the
resolution state can be persisted. But still.

I don't have clear answers or even clear feedback to this thread. I feel
one thing - there are 2 critical and fundamental OSGi aspects:
 - module layer (bundles, manifests, caps-reqs)
 - service layer (service registry)

And while the service layer (supported by e.g., SCR annotations/runtime) is
*the synonym of µservices* (see blog from 2010 when no one talked about it
yet: https://blog.osgi.org/2010/03/services.html), the module layer is what
may be a problem here.

All the effort with felix-connect, Atomos (which I've just checked covers
SubstrateVM scenarios - I wasn't aware of this) is about making
module-layer more cloud friendly.

I feel a little confused. Having worked 100% with OSGi for >6 years I found
the original module layer the most important thing - because of the bundle
resolution, cap-req matching, versioning, bundle revisions and wirings. The
API and programming model aspect of OSGi was not that important which has
two consequences:
1) I just got used to it that I have access to BundleContext,
BundleRevision and other API interfaces and e.g., blueprint.xml format
2) If not the module layer of OSGi, nothing would keep me using the above
API

CDI and Spring (annotations, XML) are other, widely used programming (and
code-architecting) models and I somehow feel that when module layer is
gone, these models are simply better, more flexible and less constraining
than SCR or Blueprint.

So when OSGi "adopts" the module layer to the "cloud", turning it into
flat-classpath deployment, what's the reason to call it OSGi at all?

Please don't get me wrong - I'm not going to sabotage any effort, I want to
avoid the confusion.

Imagine this
 - we turn module layer into flat classpath
 - we use aries-cdi to allow programming beans/services using CDI
annotations (JavaEE)
 - we use aries-jaxrs to create WS/REST endpoints using Jax-RS annotations
(JavaEE)
 - we hide BundleContext.getServiceReference()/getService() APi

Where's the OSGi then?

I don't have answers. As I've noted at the beginning, I'm experienced with
imagining what could go wrong (though I'm never 100% right) and with making
things maintainable (pax-logging refactoring and now pax-web refactoring).

>From my experience, the biggest problem with OSGi is that when you install
a lot of feature into Karaf (or