Re: [VOTE] Release Apache Felix SCR 2.0.4

[Bram Pouwelse]

Hi,

I just downloaded this version but the website still links to 2.0.2 (
http://ftp.nluug.nl/internet/apache//felix/org.apache.felix.scr-2.0.2.jar)
that version is not available there anymore but changing the link version
in the link to 2.0.4 works.

Regards,
Bram

On Fri, Jul 8, 2016 at 10:03 AM Carsten Ziegeler 
wrote:

> The vote passes with four binding +1 votes and three non binding +1 votes
>
> Thanks everyone
>
>  Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

[jira] [Closed] (FELIX-5308) Inconsistent Validation with Metatype Container

[JBodkin (JIRA)]

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

JBodkin closed FELIX-5308.
--
Resolution: Invalid

> Inconsistent Validation with Metatype Container
> ---
>
> Key: FELIX-5308
> URL: https://issues.apache.org/jira/browse/FELIX-5308
> Project: Felix
>  Issue Type: Bug
>  Components: SCR Tooling
>Affects Versions: maven-scr-plugin 1.22.0
>Reporter: JBodkin
>
> There are inconsistence warnings that are produced when generating the 
> components using the maven-scr-plugin.
> Case 1
> {code}
> @Component(label = "Alphabet")
> {code}
> {quote}
> Component x.y.Z has set a label. However metatype is set to false. This label 
> is ignored.
> {quote}
> Case 2
> {code}
> @Component(metatype = true, label = "Alphabet")
> {code}
> {quote}
> @Component : Component is defined to generate metatype information, however 
> no properties have been defined; in case no properties are wanted, consider 
> to use 'metatype=false'
> {quote}
> As an developer, if I enable strictMode, the build will always fail as either 
> the code in SCRDescriptorGenerator.java or Validator.java will output the 
> above warnings as errors.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5308) Inconsistent Validation with Metatype Container

[JBodkin (JIRA)]

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

JBodkin commented on FELIX-5308:


Thanks, that makes more sense now. I was thinking the the description attribute 
in the @Component annotation also drove the Service Description that can be 
seen in the Felix Console when inspecting an specific service however this is 
not the case.

> Inconsistent Validation with Metatype Container
> ---
>
> Key: FELIX-5308
> URL: https://issues.apache.org/jira/browse/FELIX-5308
> Project: Felix
>  Issue Type: Bug
>  Components: SCR Tooling
>Affects Versions: maven-scr-plugin 1.22.0
>Reporter: JBodkin
>
> There are inconsistence warnings that are produced when generating the 
> components using the maven-scr-plugin.
> Case 1
> {code}
> @Component(label = "Alphabet")
> {code}
> {quote}
> Component x.y.Z has set a label. However metatype is set to false. This label 
> is ignored.
> {quote}
> Case 2
> {code}
> @Component(metatype = true, label = "Alphabet")
> {code}
> {quote}
> @Component : Component is defined to generate metatype information, however 
> no properties have been defined; in case no properties are wanted, consider 
> to use 'metatype=false'
> {quote}
> As an developer, if I enable strictMode, the build will always fail as either 
> the code in SCRDescriptorGenerator.java or Validator.java will output the 
> above warnings as errors.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Initial implementation for Configurator (RFC 218) and Configuration Admin Updates (RFC 227)

[Carsten Ziegeler]

Hi,

the OSGi spec groups are working on something called the configurator
(RFC 218), see https://github.com/osgi/design/tree/master/rfcs/rfc0218
which - simply put - allows to provide configurations through resources
in a bundle.

I've started an initial implementation which should be feature complete
but is not really tested atm, a smoke test succeeds at least :)
The implementation is at:
https://svn.apache.org/repos/asf/felix/sandbox/configurator

The configurator is based on new features in configuration admin (RFC
227), see https://github.com/osgi/design/tree/master/rfcs/rfc0227
The initial implementation is at:
https://svn.apache.org/repos/asf/felix/sandbox/configadmin-r7
As with the configurator, the implementation is feature complete but
only partially tested.

In addition the configurator requires the new converter service
(implemented by David) at
https://svn.apache.org/repos/asf/felix/trunk/converter and a yaml
parser. It currently uses snakeyaml (
https://bitbucket.org/asomov/snakeyaml)

In order to get the configurator running you need to deploy those for
bundles.

Feedback, improvements, bug reports welcome of course :)
But please note that it would be better to have the discussions about
the RFCs itself via the OSGi feedback mechanism, which is the OSGi issue
tracker and/or the OSGi mailing list. Of course we can prediscuss things
here and then bring it forward.

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

[jira] [Commented] (FELIX-5285) iPojo does not delegate to the right classloader for Nullable Proxy instantiation

[Clement Escoffier (JIRA)]

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

Clement Escoffier commented on FELIX-5285:
--

The patch looks good to me. I'm wondering if the same trick need to be done in 
the composition support.

> iPojo does not delegate to the right classloader for Nullable Proxy 
> instantiation
> -
>
> Key: FELIX-5285
> URL: https://issues.apache.org/jira/browse/FELIX-5285
> Project: Felix
>  Issue Type: Bug
>  Components: iPOJO
>Reporter: Emmanuel Juste
>Assignee: Clement Escoffier
> Attachments: FELIX-5285.patch
>
>
> iPojo runtime & api: 1.12.1 
> Felix framework: 4.2.1
> This issue is similar to https://issues.apache.org/jira/browse/FELIX-2093
> This interface exist in v1.0 of an api and is exported by the system bundle 
> (felix) A
> {code}package com.data.service
> public interface DataService
> {
> public void search(String condition);
> }{code}
> A bundle, B, imports com.data.service;version=1.0:
> {code}@Requires(optional = true)
> private DataServiceImpl dataServiceImpl;{code}
> where DataServiceImpl only implements the interface
> All is working well at this point.
> Then, the api evolves with a new method:
> {code}package com.data.service
> import com.data.service.conditions.Condition;
> public interface DataService
> {
> public void search(String condition);
> public void search(Condition condition);
> }{code}
> still exported by system bundle A but now as version 1.1
> The bundle B is not recompiled against this new version and does not import 
> the new package com.data.service.conditions
> Now, when bundle B runs with v1.1 of the api, the requires of DataServiceImpl 
> is failing in Dependency.createNullableObject() 
> (http://felix.apache.org/ipojo/api/1.12.1/src-html/org/apache/felix/ipojo/handlers/dependency/Dependency.html
>  line 433) when creating the proxy: the proxy class is created w/o issue but 
> when an instance of this proxy class is done, there is a Class.forName() done 
> that fails to load the class Condition because it is not imported
> Since the class Condition is already available and allows to create the proxy 
> class, it would make sense to use it instead of trying to load it thru the 
> bundle classloader
> To achieve this, the methods of the specification could be browsed, for each 
> parameters and return types the classloader could be collected and given to 
> the NullableClassLoader. All classloaders could be asked to load the class. 
> At some point, the classloader of Condition would be queried and would return 
> the class
> I don't know if this is breaking OSGi principles but I think it can fix this 
> issue
> NB: I also tried to export the new api with uses directive:
> com.data.service;version=1.1;uses:="com.data.service.conditions"
> with no result. If I understand correctly uses directive is not supposed to 
> add implicit package import to bundle B, but are only used by the OSGi 
> framework to help it on the wiring process
> Here's the cause exception thrown in java.lang.IllegalStateException: Cannot 
> create the Nullable object, a referenced class cannot be loaded:
> {code}java.lang.NoClassDefFoundError: *** Class 
> 'com.data.service.conditions.Condition' was not found because bundle B [5] 
> does not import 'com.data.service.conditions' even though bundle 
> org.apache.felix.framework [0] does export it. Additionally, the class is 
> also available from the system class loader. There are two fixes: 1) Add an 
> import for 'com.data.service.conditions' to bundle B [5]; imports are 
> necessary for each class directly touched by bundle code or indirectly 
> touched, such as super classes if their methods are used. 2) Add package 
> 'com.data.service.conditions' to the 'org.osgi.framework.bootdelegation' 
> property; a library or VM bug can cause classes to be loaded by the wrong 
> class loader. The first approach is preferable for preserving modularity. 
> ***{code}
> And the stack trace of the loadClass that fails:
> {code}"[iPOJO] pool-1-thread-1@4605" daemon prio=5 tid=0x21 nid=NA runnable 
> java.lang.Thread.State: RUNNABLE
> at 
> org.apache.felix.ipojo.handlers.dependency.Dependency$NullableClassLoader.loadClass(Dependency.java:1072)
> at java.lang.Class.forName0(Class.java:-1)
> at java.lang.Class.forName(Class.java:264)
> at com.sun.proxy.$Proxy154.(Unknown Source:-1)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java:-1)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> 

[jira] [Closed] (FELIX-5149) Update to bndlib 3.1.0

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler closed FELIX-5149.
---

> Update to bndlib 3.1.0
> --
>
> Key: FELIX-5149
> URL: https://issues.apache.org/jira/browse/FELIX-5149
> Project: Felix
>  Issue Type: Improvement
>  Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.0.1
>Reporter: Stefan Seifert
>Assignee: Carsten Ziegeler
> Fix For: maven-bundle-plugin-3.2.0
>
> Attachments: FELIX-5149_bndlip-3.1.0.patch
>
>
> bndlib 3.1.0 was released some days ago.
> we should update maven-bundle-plugin to this version.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (FELIX-5253) Update to bndlib 3.2.0

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler closed FELIX-5253.
---

> Update to bndlib 3.2.0
> --
>
> Key: FELIX-5253
> URL: https://issues.apache.org/jira/browse/FELIX-5253
> Project: Felix
>  Issue Type: Improvement
>  Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.0.1
>Reporter: Konrad Windszus
>Assignee: Carsten Ziegeler
> Fix For: maven-bundle-plugin-3.2.0
>
>
> As soon as bndlib 3.2.0 is out, maven-bundle-plugin should be updated as 
> well. The release should happen on the 13th of May 
> (https://groups.google.com/forum/#!topic/bndtools-users/adMX-cCKVC8).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (FELIX-5285) iPojo does not delegate to the right classloader for Nullable Proxy instantiation

[Clement Escoffier (JIRA)]

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

Clement Escoffier reassigned FELIX-5285:


Assignee: Clement Escoffier

> iPojo does not delegate to the right classloader for Nullable Proxy 
> instantiation
> -
>
> Key: FELIX-5285
> URL: https://issues.apache.org/jira/browse/FELIX-5285
> Project: Felix
>  Issue Type: Bug
>  Components: iPOJO
>Reporter: Emmanuel Juste
>Assignee: Clement Escoffier
> Attachments: FELIX-5285.patch
>
>
> iPojo runtime & api: 1.12.1 
> Felix framework: 4.2.1
> This issue is similar to https://issues.apache.org/jira/browse/FELIX-2093
> This interface exist in v1.0 of an api and is exported by the system bundle 
> (felix) A
> {code}package com.data.service
> public interface DataService
> {
> public void search(String condition);
> }{code}
> A bundle, B, imports com.data.service;version=1.0:
> {code}@Requires(optional = true)
> private DataServiceImpl dataServiceImpl;{code}
> where DataServiceImpl only implements the interface
> All is working well at this point.
> Then, the api evolves with a new method:
> {code}package com.data.service
> import com.data.service.conditions.Condition;
> public interface DataService
> {
> public void search(String condition);
> public void search(Condition condition);
> }{code}
> still exported by system bundle A but now as version 1.1
> The bundle B is not recompiled against this new version and does not import 
> the new package com.data.service.conditions
> Now, when bundle B runs with v1.1 of the api, the requires of DataServiceImpl 
> is failing in Dependency.createNullableObject() 
> (http://felix.apache.org/ipojo/api/1.12.1/src-html/org/apache/felix/ipojo/handlers/dependency/Dependency.html
>  line 433) when creating the proxy: the proxy class is created w/o issue but 
> when an instance of this proxy class is done, there is a Class.forName() done 
> that fails to load the class Condition because it is not imported
> Since the class Condition is already available and allows to create the proxy 
> class, it would make sense to use it instead of trying to load it thru the 
> bundle classloader
> To achieve this, the methods of the specification could be browsed, for each 
> parameters and return types the classloader could be collected and given to 
> the NullableClassLoader. All classloaders could be asked to load the class. 
> At some point, the classloader of Condition would be queried and would return 
> the class
> I don't know if this is breaking OSGi principles but I think it can fix this 
> issue
> NB: I also tried to export the new api with uses directive:
> com.data.service;version=1.1;uses:="com.data.service.conditions"
> with no result. If I understand correctly uses directive is not supposed to 
> add implicit package import to bundle B, but are only used by the OSGi 
> framework to help it on the wiring process
> Here's the cause exception thrown in java.lang.IllegalStateException: Cannot 
> create the Nullable object, a referenced class cannot be loaded:
> {code}java.lang.NoClassDefFoundError: *** Class 
> 'com.data.service.conditions.Condition' was not found because bundle B [5] 
> does not import 'com.data.service.conditions' even though bundle 
> org.apache.felix.framework [0] does export it. Additionally, the class is 
> also available from the system class loader. There are two fixes: 1) Add an 
> import for 'com.data.service.conditions' to bundle B [5]; imports are 
> necessary for each class directly touched by bundle code or indirectly 
> touched, such as super classes if their methods are used. 2) Add package 
> 'com.data.service.conditions' to the 'org.osgi.framework.bootdelegation' 
> property; a library or VM bug can cause classes to be loaded by the wrong 
> class loader. The first approach is preferable for preserving modularity. 
> ***{code}
> And the stack trace of the loadClass that fails:
> {code}"[iPOJO] pool-1-thread-1@4605" daemon prio=5 tid=0x21 nid=NA runnable 
> java.lang.Thread.State: RUNNABLE
> at 
> org.apache.felix.ipojo.handlers.dependency.Dependency$NullableClassLoader.loadClass(Dependency.java:1072)
> at java.lang.Class.forName0(Class.java:-1)
> at java.lang.Class.forName(Class.java:264)
> at com.sun.proxy.$Proxy154.(Unknown Source:-1)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java:-1)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> at 

[jira] [Closed] (FELIX-5258) Add a new MOJO which verifies the bundle integrity

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler closed FELIX-5258.
---

> Add a new MOJO which verifies the bundle integrity
> --
>
> Key: FELIX-5258
> URL: https://issues.apache.org/jira/browse/FELIX-5258
> Project: Felix
>  Issue Type: New Feature
>  Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.0.1
>Reporter: Simone Tripodi
>Assignee: Carsten Ziegeler
> Fix For: maven-bundle-plugin-3.2.0
>
> Attachments: FELIX-5258.patch, FELIX-5258.patch.1, FELIX-5258.patch.2
>
>
> In my company it happens sometimes that people using the _Maven Bundle 
> Plugin_ to produce the bundle misinterpret the configuration settings, 
> producing a {{MANIFEST}} file with invalid OSGi entries, i.e. given a project 
> with the following structure:
> {noformat}
> myproject
> ├── src
> │   ├── main
> │   │   ├── java
> │   │   │   └── org
> │   │   │   └── apache
> │   │   │   ├── acme
> │   │   │   │   ├── utils
> {noformat}
> and the {{pom.xml}} is wrongly configured as:
> {noformat}
> 
> org.apache.felix
> maven-bundle-plugin
> true
> 
> 
> 
> nothing
> 
> 
> 
> 
> {noformat}
> it makes the {{Export-Package}} header resulting as {{Export-Package: 
> nothing}}.
> A MOJO, invoked during the {{verify}} phase, would be very useful to check 
> the target bundle integrity and prevent this kind of wrong exports.
> Patch is coming.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (FELIX-5233) New JPA analyser for the maven bundle plugin

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler closed FELIX-5233.
---

> New JPA analyser for the maven bundle plugin
> 
>
> Key: FELIX-5233
> URL: https://issues.apache.org/jira/browse/FELIX-5233
> Project: Felix
>  Issue Type: New Feature
>  Components: Maven Bundle Plugin
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: maven-bundle-plugin-3.2.0
>
>
> When dealing with JPA, requirements can be generated when injecting 
> EntityManager / EntityManagerFactory objects.
> However, the maven plugin does not automatically generate those, which leads 
> to mismatch and unresolved requirements.
> This plugin would analyse the bundle and look for the {{Meta-Persistence}} 
> header, find the persistent units and generate capabilities / requirements 
> accordingly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Felix Http Base 3.0.10, Http Bridge 3.0.10, and Http Jetty 3.2.2

[Carsten Ziegeler]

+1


 

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

[VOTE] Release Apache Felix Http Base 3.0.10, Http Bridge 3.0.10, and Http Jetty 3.2.2

[Carsten Ziegeler]

I would like to call a vote for

Http Base 3.0.10 (1 issue solved)
https://issues.apache.org/jira/browse/FELIX-5302

Http Bridge 3.0.10 (1 issue solved)
https://issues.apache.org/jira/browse/FELIX-5302

Http Jetty 3.2.2 (5 issues solved)
https://issues.apache.org/jira/browse/FELIX/fixforversion/12335474

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

You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1131 /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] [Updated] (FELIX-5221) Reduce locking when service are registered/unregistered

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated FELIX-5221:

Assignee: (was: Carsten Ziegeler)

> Reduce locking when service are registered/unregistered
> ---
>
> Key: FELIX-5221
> URL: https://issues.apache.org/jira/browse/FELIX-5221
> Project: Felix
>  Issue Type: Improvement
>  Components: HTTP Service
>Reporter: Carsten Ziegeler
> Fix For: http.base-3.0.12
>
>
> Currently when a new service is added/removed/modified through the 
> whiteboard, the whole process is done within one global lock, forcing all 
> operations to be done in sequence.
> In addition, this code calls out to the service registry, which we should 
> avoid.
> I think we can solve this by treating SCH registration differently from all 
> other services and use something like a change count for the SCH 
> registrations: when a new whiteboard service is added, it's processed with 
> the current set of SCHs. Once it's done it compares the current change count 
> to the one from when the registration started. If it's different, it updates 
> the registration. This is repeated until the count is equal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-5221) Reduce locking when service are registered/unregistered

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated FELIX-5221:

Fix Version/s: (was: http.base-3.0.10)

> Reduce locking when service are registered/unregistered
> ---
>
> Key: FELIX-5221
> URL: https://issues.apache.org/jira/browse/FELIX-5221
> Project: Felix
>  Issue Type: Improvement
>  Components: HTTP Service
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: http.base-3.0.12
>
>
> Currently when a new service is added/removed/modified through the 
> whiteboard, the whole process is done within one global lock, forcing all 
> operations to be done in sequence.
> In addition, this code calls out to the service registry, which we should 
> avoid.
> I think we can solve this by treating SCH registration differently from all 
> other services and use something like a change count for the SCH 
> registrations: when a new whiteboard service is added, it's processed with 
> the current set of SCHs. Once it's done it compares the current change count 
> to the one from when the registration started. If it's different, it updates 
> the registration. This is repeated until the count is equal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-5221) Reduce locking when service are registered/unregistered

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated FELIX-5221:

Fix Version/s: http.base-3.0.12

> Reduce locking when service are registered/unregistered
> ---
>
> Key: FELIX-5221
> URL: https://issues.apache.org/jira/browse/FELIX-5221
> Project: Felix
>  Issue Type: Improvement
>  Components: HTTP Service
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: http.base-3.0.12
>
>
> Currently when a new service is added/removed/modified through the 
> whiteboard, the whole process is done within one global lock, forcing all 
> operations to be done in sequence.
> In addition, this code calls out to the service registry, which we should 
> avoid.
> I think we can solve this by treating SCH registration differently from all 
> other services and use something like a change count for the SCH 
> registrations: when a new whiteboard service is added, it's processed with 
> the current set of SCHs. Once it's done it compares the current change count 
> to the one from when the registration started. If it's different, it updates 
> the registration. This is repeated until the count is equal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[VOTE RESULT] Release Apache Felix Maven Bundle Plugin 3.2.0

[Carsten Ziegeler]

The vote passed with three binding +1 votes and four non binding +1 votes

 Thanks everyone

Carsten

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

[jira] [Resolved] (FELIX-5307) Update jetty to 9.3.9.v20160517

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved FELIX-5307.
-
Resolution: Fixed

Updated in rev 1753149

> Update jetty to 9.3.9.v20160517
> ---
>
> Key: FELIX-5307
> URL: https://issues.apache.org/jira/browse/FELIX-5307
> Project: Felix
>  Issue Type: Improvement
>  Components: HTTP Service
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: http.jetty-3.2.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FELIX-5307) Update jetty to 9.3.9.v20160517

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created FELIX-5307:
---

 Summary: Update jetty to 9.3.9.v20160517
 Key: FELIX-5307
 URL: https://issues.apache.org/jira/browse/FELIX-5307
 Project: Felix
  Issue Type: Improvement
  Components: HTTP Service
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: http.jetty-3.2.2






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)