[VOTE CANCELLED] Release Apache Felix Http Base 3.0.14, Http Bridge 3.0.14, and Http Jetty 3.3.0

2016-10-03 Thread Carsten Ziegeler
Thanks for spotting Karl - I assume we have this problem with all of the http releases for quiet some time now. However, as I think we should fix this as, I'll hereby cancel the vote. Let's get it fixed and then cut a new release. Regards Carsten Karl Pauls wrote > Hm, I think we are running

Re: Re-Using an ExecutorService for Felix Resolver calls

2016-10-03 Thread Fabian Lange
Thanks, Karl! That happens when both just show as dev in my mail client. Was indeed intended for karaf-dev. Fabian > On 3 Oct 2016, at 23:14, Karl Pauls wrote: > > I guess I'm not sure if this message is intended for dev@felix or dev@karaf? > > regards, > > Karl > > On

Re: [VOTE] Release Apache Felix Http Base 3.0.14, Http Bridge 3.0.14, and Http Jetty 3.3.0

2016-10-03 Thread Karl Pauls
Hm, I think we are running into on of the NOTICE in the root of the bundle svn issues again. Both, Bridge and Jetty do not get their NOTICE copied into their binary jar causing the somewhat awkward situation that the source artifacts have a NOTICE claiming they contain code from the OSGi Alliance

Re: Re-Using an ExecutorService for Felix Resolver calls

2016-10-03 Thread Karl Pauls
I guess I'm not sure if this message is intended for dev@felix or dev@karaf? regards, Karl On Mon, Oct 3, 2016 at 9:21 PM, Fabian Lange wrote: > Hi, > what do you guys think about: > https://github.com/apache/karaf/pull/246 > > As noticed by me, and already

Re: [VOTE] Release Apache Felix Http Base 3.0.14, Http Bridge 3.0.14, and Http Jetty 3.3.0

2016-10-03 Thread Pierre De Rop
Checked signatures, did some basic tests. +1 (binding) thanks Carsten; regards /Pierre On Fri, Sep 30, 2016 at 11:24 PM, David Bosschaert < david.bosscha...@gmail.com> wrote: > +1 > > David > > On 30 September 2016 at 14:26, Carsten Ziegeler > wrote: > > > I would like

Re: [DISCUSS] Persistent wiring framework

2016-10-03 Thread Guillaume Nodet
2016-10-03 22:12 GMT+02:00 Karl Pauls : > On Mon, Oct 3, 2016 at 9:49 PM, Guillaume Nodet wrote: > > > An extension sounds doable. > > However, I found something weird: > > > > https://github.com/apache/felix/blob/trunk/framework/ > >

Re: [DISCUSS] Persistent wiring framework

2016-10-03 Thread Karl Pauls
On Mon, Oct 3, 2016 at 9:49 PM, Guillaume Nodet wrote: > An extension sounds doable. > However, I found something weird: > > https://github.com/apache/felix/blob/trunk/framework/ > src/main/java/org/apache/felix/framework/ExtensionManager.java#L505-L507 > > Is that expected

Re: [DISCUSS] Persistent wiring framework

2016-10-03 Thread Guillaume Nodet
An extension sounds doable. However, I found something weird: https://github.com/apache/felix/blob/trunk/framework/src/main/java/org/apache/felix/framework/ExtensionManager.java#L505-L507 Is that expected that the framework is using the classloader loading the framework instead of the

Re-Using an ExecutorService for Felix Resolver calls

2016-10-03 Thread Fabian Lange
Hi, what do you guys think about: https://github.com/apache/karaf/pull/246 As noticed by me, and already reported here: https://issues.apache.org/jira/browse/FELIX-5247 The current default behaviour is that every "resolve()" call will create a new Executor Pool with number of CPU Cores as size.

Re: [DISCUSS] Persistent wiring framework

2016-10-03 Thread Richard S. Hall
On 10/3/16 12:02 , Guillaume Nodet wrote: I have a use case where the wiring is a bit complicated. Karaf uses the felix resolver to compute the full wiring and then applies it. At this point, all the bundles are resolved and started correctly. If Karaf is restarted, the framework restarts and

[DISCUSS] Persistent wiring framework

2016-10-03 Thread Guillaume Nodet
I have a use case where the wiring is a bit complicated. Karaf uses the felix resolver to compute the full wiring and then applies it. At this point, all the bundles are resolved and started correctly. If Karaf is restarted, the framework restarts and resolves the bundles on its own, using a bad

Re: [DISCUSS] Release new gogo runtime / jline bundles

2016-10-03 Thread Guillaume Nodet
I've downgraded the requirement or the gogo-runtime to java 7. That's not really possible for the gogo-jline bundle which has a dependency on jline requiring java 8 atm. Given the amount of change, I think it would be better to bump the gogo-runtime bundle version. Given it's currently at 0.17,