Re: [VOTE] Release Apache Felix Utils 1.11.4

[clement escoffier]

+1,

Regards,

Clement
On 11 Nov 2019 at 10:45 +0100, Pierre De Rop , wrote:
> Hi,
>
> +1
>
> regards
> Pierre
>
> On Mon, Nov 11, 2019 at 7:54 AM Carsten Ziegeler 
> wrote:
>
> > +1
> >
> > Carsten
> >
> > Am 10.11.2019 um 08:30 schrieb Jean-Baptiste Onofré:
> > > Hi all,
> > >
> > > I submit Apache Felix Utils 1.11.4 to your vote.
> > >
> > > The following issues were fixed:
> > > https://issues.apache.org/jira/projects/FELIX/versions/12344906
> > >
> > > Staging repositories:
> > > https://repository.apache.org/content/repositories/orgapachefelix-1320/
> > >
> > > 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 1320 /tmp/felix-staging
> > >
> > > Please vote to approve this release:
> > >
> > > [ ] +1 Approve the release
> > > [ ] -1 Veto the release (please provide specific comments)
> > >
> > > This majority vote is open for at least 72 hours.
> > >
> > > Regards
> > > JB
> > >
> >
> > --
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org
> >

Re: [VOTE] Release Config Admin Interpolation Plugin 0.0.4

[clement escoffier]

+1,

Regards,

Clement
On 11 Nov 2019 at 14:21 +0100, Raymond Auge , wrote:
> +1
>
> - Ray
>
> On Mon, Nov 11, 2019, 05:34 Jean-Baptiste Onofré,  wrote:
>
> > +1 (binding)
> >
> > Regards
> > JB
> >
> > On 11/11/2019 10:36, dav...@apache.org wrote:
> > > I would like to call a vote on the Apache Felix Config Admin
> > Interpolation
> > > Plugin 0.0.4
> > >
> > > The following issues were fixed:
> > > https://issues.apache.org/jira/projects/FELIX/versions/12345964
> > >
> > > Staging repositories:
> > > https://repository.apache.org/content/repositories/orgapachefelix-1321/
> > >
> > > 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 1321 /tmp/felix-staging
> > >
> > > Please vote to approve this release:
> > >
> > > [ ] +1 Approve the release
> > > [ ] -1 Veto the release (please provide specific comments)
> > >
> > > This majority vote is open for at least 72 hours.
> > >
> > > Best regards,
> > >
> > > David Bosschaert
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >

Re: [VOTE] Apache Felix Framework 6.0.3 and related subproject releases

[clement escoffier]

+1,

Clement

Le ven. 26 avr. 2019 à 17:48, Raymond Auge  a
écrit :

> +1
>
> - Ray
>
> On Fri, Apr 26, 2019 at 2:48 AM David Bosschaert <
> david.bosscha...@gmail.com>
> wrote:
>
> > +1
> >
> > David
> >
> > On Thu, 25 Apr 2019 at 15:09, Karl Pauls  wrote:
> >
> > > I would like to call a vote on the following subproject releases:
> > >
> > > framework 6.0.3
> > > main 6.0.3
> > > main.distribution 6.0.3
> > >
> > > The main changelogs are in jira and at:
> > >
> > >
> >
> https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.framework-6.0.3/doc/changelog.txt
> > >
> > > Staging repositories:
> > >
> https://repository.apache.org/content/repositories/orgapachefelix-1298/
> > >
> > > 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 1298 /tmp/felix-staging
> > >
> > > Please vote to approve this release:
> > >
> > > [ ] +1 Approve the release
> > > [ ] -1 Veto the release (please provide specific comments)
> > >
> >
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>

Re: [VOTE] Release Felix Converter version 1.0.4

[clement escoffier]

+1,

Clement

> On 17 Feb 2019, at 10:03, Carsten Ziegeler  wrote:
> 
> +1
> 
> 
> Raymond Auge wrote
>> I'd like to call a vote for the release of Felix Converter 1.0.4
>> The release notes are here:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100=12344669
>> The staging repository is here:
>> https://repository.apache.org/content/repositories/orgapachefelix-1284
>> 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 1284 /tmp/felix-staging
>> Please vote to approve this release:
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> This vote will be open for 72 hours.
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Felix Parent POM and Http Projects

[Clement Escoffier]

+1,

Regards,

Clement

> On 20 Sep 2018, at 10:49, Carsten Ziegeler  wrote:
> 
> That's the idea - we still have some hours left for the 72h
> 
> Carsten
> 
> 
> Karl Pauls wrote
>> That said, @Carsten Ziegeler, could you please call this vote and get
>> the artifacts released ASAP? The releases you and @David Bosschaert
>> are going atm all depend on the parent pom which makes it hard to
>> validate that they are building.
>> 
>> I know, it is nitpicking but technically, we shouldn't release with
>> dependencies on unreleased things...
>> 
>> regards,
>> 
>> Karl
>> On Thu, Sep 20, 2018 at 10:25 AM Karl Pauls  wrote:
>>> 
>>> +1
>>> 
>>> regards,
>>> 
>>> Karl
>>> On Mon, Sep 17, 2018 at 8:44 PM Carsten Ziegeler  
>>> wrote:
 
 As I needed to update the parent poms to the latest Apache parent pom
 21, I've included the parent pom in this vote.
 
 So this vote is about the release of
 - Parent Pom 6 (updated to Apache parent 21)
 - Http Parent Pom 12 (updated to parent 6)
 - Http Base 4.0.4 (solved 1 issues :
 https://issues.apache.org/jira/browse/FELIX-5928)
 - Http Bridge 4.0.4 (solved 1 issue :
 https://issues.apache.org/jira/browse/FELIX-5928)
 - Http Proxy 3.0.4 (solved 1 issue :
 https://issues.apache.org/jira/browse/FELIX-5897)
 - Http Jetty 4.0.6 (solved 3 issues:
 https://issues.apache.org/jira/projects/FELIX/versions/12343843)
 
 
 Staging repositories:
 https://repository.apache.org/content/repositories/orgapachefelix-1255/
 https://repository.apache.org/content/repositories/orgapachefelix-1256/
 
 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 1255 /tmp/felix-staging
 sh check_staged_release.sh 1256 /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
>>> 
>>> 
>>> 
>>> --
>>> Karl Pauls
>>> karlpa...@gmail.com
>> 
>> 
>> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org 

Re: [VOTE] Apache Felix Framework 6.0.0 and related subproject releases

[Clement Escoffier]

+1,

Clement

> On 4 Jul 2018, at 01:11, Thomas Watson  wrote:
> 
> +1
> 
> 
> On Tue, Jul 3, 2018, 10:03 AM Karl Pauls  wrote:
> 
>> I would like to call a vote on the following subproject releases:
>> 
>> resolver 2.0.0
>> framework 6.0.0
>> main 6.0.0
>> main.distribution 6.0.0
>> 
>> The main changelogs are in jira and at:
>> 
>> https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.resolver-2.0.0/doc/changelog.txt
>> 
>> https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.framework-6.0.0/doc/changelog.txt
>> 
>> Staging repositories:
>> https://repository.apache.org/content/repositories/orgapachefelix-1234/
>> 
>> 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 1234 /tmp/felix-staging
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> 

Re: [VOTE] Felix Converter 1.0.0

[Clement Escoffier]

+1,

Regards,

Clement

> On 23 Apr 2018, at 17:12, Karl Pauls  wrote:
> 
> +1
> 
> regards,
> 
> Karl
> 
> On Mon, Apr 23, 2018 at 5:06 PM, Francois Papon
>  wrote:
>> +1 (non-binding)
>> 
>> Thanks
>> 
>> François
>> 
>> 
>> Le 23/04/2018 à 17:15, dav...@apache.org a écrit :
>>> Hi all,
>>> 
>>> I would like to call a vote on the Felix Converter version 1.0.0.
>>> The Converter implements chapter 707 of the new OSGi R7 Compendium
>>> Specifications which can be found here:
>>> https://osgi.org/specification/osgi.cmpn/7.0.0/util.converter.html
>>> 
>>> As the OSGi R7 API is now available in Maven Central as released artifacts,
>>> the release of the Felix Converter can take place.
>>> 
>>> Staging repositories:
>>> https://repository.apache.org/content/repositories/orgapachefelix-1218/
>>> 
>>> 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 1218 /tmp/felix-staging
>>> 
>>> Please vote to approve this release:
>>> 
>>> [ ] +1 Approve the release
>>> [ ] -1 Veto the release (please provide specific comments)
>>> 
>>> This vote will be open for at least 72 hours.
>>> 
>>> Best regards,
>>> 
>>> David
>>> 
>> 
> 
> 
> 
> -- 
> Karl Pauls
> karlpa...@gmail.com

Re: [VOTE] Release Apache Felix Resolver 1.16.0

[Clement Escoffier]

+1,

Clement

> On 9 Mar 2018, at 22:44, Karl Pauls  wrote:
> 
> I would like to call a vote on the following subproject release:
> 
> resolver 1.16.0
> 
> The main changelogs are in jira and at:
> 
> https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.resolver-1.16.0/doc/changelog.txt
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1215/
> 
> 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 1215 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)

Re: [VOTE] Release Apache Felix Maven Bundle Plugin 3.5.0

[Clement Escoffier]

+1,

Regards,

Clement

> On 3 Jan 2018, at 14:02, Neil Bartlett  wrote:
> 
> +1
> 
> On Wed, Jan 3, 2018 at 1:02 PM, Karl Pauls  wrote:
> 
>> +1
>> 
>> regards,
>> 
>> Karl
>> 
>> On Wed, Jan 3, 2018 at 1:52 PM, Stefan Seifert 
>> wrote:
>>> Hi,
>>> 
>>> We solved 1 issues in this release:
>>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12342311
>>> 
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/orgapachefelix-1212/
>>> 
>>> 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 1212 /tmp/felix-staging
>>> 
>>> Please vote to approve this release:
>>> 
>>> [ ] +1 Approve the release
>>> [ ] -1 Veto the release (please provide specific comments)
>>> 
>>> This vote will be open for 72 hours.
>>> 
>>> stefan
>>> 
>> 
>> 
>> 
>> --
>> Karl Pauls
>> karlpa...@gmail.com
>> 

Re: [VOTE] Release Apache Felix Maven Bundle Plugin 3.4.0

[Clement Escoffier]

+1,

Regards,

Clement

> On 14 Dec 2017, at 17:30, Karl Pauls  wrote:
> 
> I would like to call a vote on the following subproject release:
> 
> Apache Felix Maven Bundle Plugin 3.4.0
> 
> We solved 5 issues in this release
> https://issues.apache.org/jira/projects/FELIX/versions/12339958
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1211/
> 
> 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 1211 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)

Re: [VOTE] Apache Felix Framework 5.6.10 and related subproject releases

[clement escoffier]

+1,

Clement

On Fri 10 Nov 2017 at 18:03, Raymond Auge  wrote:

> +1 (non-binding)
>
> On Fri, Nov 10, 2017 at 11:19 AM, Jean-Baptiste Onofré 
> wrote:
>
> > +1 (binding)
> >
> > Regards
> > JB
> >
> >
> > On 11/10/2017 05:16 PM, Neil Bartlett wrote:
> >
> >> +1 (non-binding)
> >>
> >> This is a very important release with lots of Java 9 goodies (while
> still
> >> being compatible with Java 1.6 through 1.8). Thanks Karl!
> >>
> >> On Fri, Nov 10, 2017 at 3:00 PM, Karl Pauls 
> wrote:
> >>
> >> I would like to call a vote on the following subproject releases:
> >>>
> >>> framework  5.6.10
> >>> main 5.6.10
> >>> main.distribution 5.6.10
> >>>
> >>> The main changelogs are in jira and at:
> >>> https://svn.apache.org/repos/asf/felix/releases/org.apache.
> >>> felix.framework-5.6.10/doc/changelog.txt
> >>>
> >>> Staging repositories:
> >>>
> https://repository.apache.org/content/repositories/orgapachefelix-1206/
> >>>
> >>> 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 1206 /tmp/felix-staging
> >>>
> >>> Please vote to approve this release:
> >>>
> >>> [ ] +1 Approve the release
> >>> [ ] -1 Veto the release (please provide specific comments)
> >>>
> >>>
> >>
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>

Re: [VOTE] Release Apache Felix Metatype 1.1.4

[Clement Escoffier]

+1,

Regards,

Clement

> On 28 Aug 2017, at 15:37, Carsten Ziegeler  wrote:
> 
> +1
> 
>  
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Felix EventAdmin 1.4.10

[Clement Escoffier]

+1,

Regards,

Clement

> On 28 Aug 2017, at 15:54, Carsten Ziegeler  wrote:
> 
> We solved one issue in this release:
> 
> https://issues.apache.org/jira/browse/FELIX-5567
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1194/
> 
> 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 1194 /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 ConfigAdmin 1.8.16

[Clement Escoffier]

+1,

Regards,

Clement

> On 4 Aug 2017, at 10:46, David Bosschaert  wrote:
> 
> +1
> 
> David
> 
> On 4 August 2017 at 06:26, Carsten Ziegeler  wrote:
> 
>> We fixed one issue in this release:
>> https://issues.apache.org/jira/browse/FELIX-5669
>> 
>> Staging repositories:
>> https://repository.apache.org/content/repositories/orgapachefelix-1191/
>> 
>> 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 1191 /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 Http SslFilter 1.2.2

[Clement Escoffier]

+1,

Regards,

Clement

> On 5 Jul 2017, at 16:19, Jean-Baptiste Onofré  wrote:
> 
> +1 (binding)
> 
> Regards
> JB
> 
> On 07/05/2017 04:17 PM, Carsten Ziegeler wrote:
>> +1
>>  
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: [VOTE] Apache Felix Dependency Manager Release R11

[Clement Escoffier]

+1,

Regards,

Clement

> On 28 Jun 2017, at 09:52, David Bosschaert  wrote:
> 
> +1
> 
> David
> 
> On 27 June 2017 at 09:17, Pierre De Rop  wrote:
> 
>> Hello all,
>> 
>> After a failed attempt to release the DM-R10 release, I would like to call
>> for a new vote on the Dependency Manager toplevel release R11.
>> 
>> The following issues were solved:
>> 
>> ** Bug
>>* [FELIX-5630] - NullObject is created for a required dependency if the
>> component is removed and added again to the dependency manager
>>* [FELIX-5636] - Component of aspect service does not have any service
>> properties anymore
>>* [FELIX-5657] - DM released sources can't be rebuilt
>> 
>> ** Improvement
>>* [FELIX-5619] - MultiProperyFilterIndex memory consumption
>>* [FELIX-5623] - Improve performance of ComponentImpl.getName method
>>* [FELIX-5650] - Support latest version of Gogo
>>* [FELIX-5653] - Simplify DM-Lambda samples
>>* [FELIX-5658] - Include poms in dm artifacts
>> 
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> 
>> 
>> http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/
>> check_staged_release.sh
>> 
>> Usage:
>> 
>>sh check_staged_release.sh r11 /tmp/felix-staging
>> 
>> This script, unlike the original Felix check_stage_release.sh, is specific
>> to the new Dependency Manager release process (see FELIX-4818) and will
>> download staging from https://dist.apache.org/repos/dist/dev/felix instead
>> of http://repository.apache.org/content/repositories.
>> 
>> To rebuild the DM binaries from the source, you can then refer to
>> https://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/
>> resources/src/README.src
>> 
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> 
>> 
>> Many thanks;
>> 
>> regards;
>> /Pierre
>> 

Re: [VOTE] framework 5.6.4, resolver 1.14.0, and related subproject releases

[Clement Escoffier]

+1,

Regards,

Clement

> On 22 May 2017, at 06:31, Carsten Ziegeler  wrote:
> 
> +1
> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] main.distribution 5.6.2-update1

[Clement Escoffier]

+1,

Regards,

Clement

> On 28 Feb 2017, at 09:53, David Bosschaert  wrote:
> 
> +1
> 
> David
> 
> On 27 February 2017 at 20:46, Karl Pauls  wrote:
> 
>> I would like to call a vote on a release of a quick fix of the Felix
>> framework convenience distribution i.e.,
>> 
>> main.distribution 5.6.2-update1
>> 
>> The main change is tracked by FELIX-5569 - in a nutshell, we are
>> missing a bundle in the distribution required by jline to be able to
>> run on windows out of the box.
>> 
>> Staging repositories:
>> https://repository.apache.org/content/repositories/orgapachefelix-1172/
>> 
>> 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 1172 /tmp/felix-staging
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> 

Re: [VOTE] framework 5.6.2, resolver 1.12.0, and related subproject releases

[Clement Escoffier]

+1,

Regards,

Clement

> On 17 Feb 2017, at 08:20, Jean-Baptiste Onofré  wrote:
> 
> +1 (binding)
> 
> Regards
> JB
> 
> On 02/16/2017 10:38 PM, Karl Pauls wrote:
>> I would like to call a vote on the following subproject releases:
>> 
>> resolver 1.12.0
>> framework  5.6.2
>> main 5.6.2
>> main.distribution 5.6.2
>> 
>> The main changelogs are in jira and at:
>> https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.framework-5.6.2/doc/changelog.txt
>> https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.resolver-1.12.0/doc/changelog.txt
>> 
>> Staging repositories:
>> https://repository.apache.org/content/repositories/orgapachefelix-1169/
>> https://repository.apache.org/content/repositories/orgapachefelix-1170/
>> 
>> 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 1169 /tmp/felix-staging
>> sh check_staged_release.sh 1170 /tmp/felix-staging
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: [VOTE] Release Apache Felix SCR 2.0.8 and Utils 1.8.6

[Clement Escoffier]

+1,

Regards,

Clement

Re: [VOTE] Release Apache Felix scr bnd plugin 1.7.2

[Clement Escoffier]

+1,

Regards,

Clement


> On 27 Dec 2016, at 17:21, Stefan Seifert  wrote:
> 
> Hi,
> 
> We solved 1 issues in this release:
> https://issues.apache.org/jira/browse/FELIX/fixforversion/12338917
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1157/
> 
> 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 1157 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote will be open for 72 hours.
> 
> stefan
> 

Re: [VOTE] framework 5.6.1 and related subproject releases

[Clement Escoffier]

+1,

Regards,

Clement

> On 22 Oct 2016, at 10:43, Carsten Ziegeler  wrote:
> 
> +1
> 
> -- 
> 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
> 

Re: [VOTE] Release Apache Felix Http Base 3.0.16, Http Bridge 3.0.16, and Http Jetty 3.4.0

[Clement Escoffier]

+1,

Regards,

Clement
> On 5 oct. 2016, at 07:02, Karl Pauls  wrote:
> 
> +1
> 
> regards,
> 
> Karl
> 
> On Wed, Oct 5, 2016 at 1:25 PM, Carsten Ziegeler 
> wrote:
> 
>> I would like to call a vote on the following subproject releases:
>> 
>> Http Base 3.0.16 (2 issues)
>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12338092
>> 
>> Http Bridge 3.0.16 (2 issues)
>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12338093
>> 
>> Http Jetty 3.4.0 (3 issues)
>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12338094
>> 
>> 
>> Staging repositories:
>> https://repository.apache.org/content/repositories/orgapachefelix-1141/
>> https://repository.apache.org/content/repositories/orgapachefelix-1142/
>> 
>> 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 1141 /tmp/felix-staging
>> sh check_staged_release.sh 1142 /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
>> 
> 
> 
> 
> -- 
> Karl Pauls
> karlpa...@gmail.com

[jira] [Resolved] (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 resolved FELIX-5285.
--
Resolution: Fixed

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

[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=15452530#comment-15452530
 ] 

Clement Escoffier commented on FELIX-5285:
--

Patched applied in trunk. I'm deploying the snapshots.

Thanks ! 

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

[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=15452420#comment-15452420
 ] 

Clement Escoffier commented on FELIX-5285:
--

Working on it, should land in the trunk tonight.

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

Re: [VOTE] Release Apache Felix Http SSL Filter 1.0.8

[Clement Escoffier]

+1,

Regards,

Clement

> On 2 août 2016, at 10:43, Carsten Ziegeler  wrote:
> 
> +1
> 
> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
> 

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

[Clement Escoffier]

+1,

Regards,

Clement

> On 18 juil. 2016, at 09:20, Carsten Ziegeler  wrote:
> 
> +1
> 
> 
> 
> 
> -- 
> 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 
&g

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

Re: [VOTE] Release Apache Felix Maven Bundle Plugin 3.2.0

[clement escoffier]

+1,

Regards,

Clement 

> On 15 juil. 2016, at 14:11, Jamie G.  wrote:
> 
> +1 (non-binding)
> 
> On Fri, Jul 15, 2016 at 7:25 AM, Christian Schneider
>  wrote:
>> +1 (non binding)
>> 
>> m2e integration and bndlib 3.2.0 support are really great.
>> I just tested on the cxf-dosgi build and found no regressions till now.
>> 
>> Christian
>> 
>>> On 15.07.2016 07:56, Carsten Ziegeler wrote:
>>> 
>>> I would like to call a vote for the maven bundle plugin
>>> 
>>> We solved six issues in this release:
>>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12335566
>>> 
>>> Staging repositories:
>>> https://repository.apache.org/content/repositories/orgapachefelix-1130/
>>> 
>>> 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 1130 /tmp/felix-staging
>>> 
>>> Please vote to approve this release:
>>> 
>>> [ ] +1 Approve the release
>>> [ ] -1 Veto the release (please provide specific comments)
>>> 
>>> Regards
>>> Carsten
>> 
>> 
>> 
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>> 
>> Open Source Architect
>> http://www.talend.com
>> 

[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=15361024#comment-15361024
 ] 

Clement Escoffier commented on FELIX-5285:
--

Will have a look this week (just back from the US, I'm out of phase ;-)).

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

[jira] [Comment Edited] (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=15348258#comment-15348258
 ] 

Clement Escoffier edited comment on FELIX-5285 at 6/24/16 1:32 PM:
---

Hi,

If you could provide a test case that would be great. If in addition you can 
provide a patch that would be awesome.


was (Author: clement.escoffier):
Hi,

If you could provide a test case that would be great. IF in addition you can 
provide a patch that would be awesome.

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

[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=15348258#comment-15348258
 ] 

Clement Escoffier commented on FELIX-5285:
--

Hi,

If you could provide a test case that would be great. IF in addition you can 
provide a patch that would be awesome.

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

Re: [VOTE] Release Apache Felix Http SSLFilter 1.0.6

[Clement Escoffier]

+1,

Regards,

Clement
> On 19 juin 2016, at 16:27, Carsten Ziegeler  wrote:
> 
> +1
> 
> 
> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[jira] [Commented] (FELIX-5278) Error in method managedInjectedObject of InstanceManager

[Clement Escoffier (JIRA)]

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

Clement Escoffier commented on FELIX-5278:
--

BTW there is a way to inject an existing "service object" in an iPOJO 
container. I can't remember the name of the property. You may be able to use 
this mechanism.

> Error in method managedInjectedObject of InstanceManager
> 
>
> Key: FELIX-5278
> URL: https://issues.apache.org/jira/browse/FELIX-5278
> Project: Felix
>  Issue Type: Bug
>  Components: iPOJO
>Affects Versions: ipojo-runtime-1.12.1
> Environment: Ubuntu 
>Reporter: Aygalinc Colin
>  Labels: patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> In InstanceManager.java, the method managedInjectedObject at line 1016 can 
> throw an java.lang.NoSuchMethodException in case of extension of the 
> InstanceManager.
> I recommend to change the line 1016:
> Method setIM = m_clazz.getDeclaredMethod("_setInstanceManager", new 
> Class[]{this.getClass()});
> by :
> Method setIM = m_clazz.getDeclaredMethod("_setInstanceManager", new new 
> Class[]{InstanceManager.class});
> because iPOJO manipulation always produces a _setInstanceManager method with 
> an InstanceManager.class attribute.
>  



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

[jira] [Commented] (FELIX-5278) Error in method managedInjectedObject of InstanceManager

[Clement Escoffier (JIRA)]

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

Clement Escoffier commented on FELIX-5278:
--

The instance manager is not really made to be extended, it heavily depends on 
the bytecode manipulation. 

In this context, it's would make more sense to extend iPOJO by providing a new 
"component type type", such as composite.

> Error in method managedInjectedObject of InstanceManager
> 
>
> Key: FELIX-5278
> URL: https://issues.apache.org/jira/browse/FELIX-5278
> Project: Felix
>  Issue Type: Bug
>  Components: iPOJO
>Affects Versions: ipojo-runtime-1.12.1
> Environment: Ubuntu 
>Reporter: Aygalinc Colin
>  Labels: patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> In InstanceManager.java, the method managedInjectedObject at line 1016 can 
> throw an java.lang.NoSuchMethodException in case of extension of the 
> InstanceManager.
> I recommend to change the line 1016:
> Method setIM = m_clazz.getDeclaredMethod("_setInstanceManager", new 
> Class[]{this.getClass()});
> by :
> Method setIM = m_clazz.getDeclaredMethod("_setInstanceManager", new new 
> Class[]{InstanceManager.class});
> because iPOJO manipulation always produces a _setInstanceManager method with 
> an InstanceManager.class attribute.
>  



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

[jira] [Commented] (FELIX-5278) Error in method managedInjectedObject of InstanceManager

[Clement Escoffier (JIRA)]

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

Clement Escoffier commented on FELIX-5278:
--

can throw ? or throws ?

> Error in method managedInjectedObject of InstanceManager
> 
>
> Key: FELIX-5278
> URL: https://issues.apache.org/jira/browse/FELIX-5278
> Project: Felix
>  Issue Type: Bug
>  Components: iPOJO
>Affects Versions: ipojo-runtime-1.12.1
> Environment: Ubuntu 
>Reporter: Aygalinc Colin
>  Labels: patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> In InstanceManager.java, the method managedInjectedObject at line 1016 can 
> throw an java.lang.NoSuchMethodException in case of extension of the 
> InstanceManager.
> I recommend to change the line 1016:
> Method setIM = m_clazz.getDeclaredMethod("_setInstanceManager", new 
> Class[]{this.getClass()});
> by :
> Method setIM = m_clazz.getDeclaredMethod("_setInstanceManager", new new 
> Class[]{InstanceManager.class});
> because iPOJO manipulation always produces a _setInstanceManager method with 
> an InstanceManager.class attribute.
>  



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

Re: [VOTE] Release Apache Felix WebConsole 4.2.16

[Clement Escoffier]

+1,

Regards,

Clement 

> On 3 juin 2016, at 10:03, Carsten Ziegeler  wrote:
> 
> We still need one binding vote, anyone?
> 
> Thanks
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] SCR Tooling Bnd Plugin 1.5.0

[Clement Escoffier]

+1,

Regards,

Clement

> On 23 mai 2016, at 07:19, Carsten Ziegeler  wrote:
> 
> +1
> 
> Thanks
> Carsten
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Felix File Install 3.5.4

[Clement Escoffier]

+1,

Clement 


> On 1 avr. 2016, at 17:03, dav...@apache.org wrote:
> 
> Hi all,
> 
> I'm calling a vote on the Felix File Install 3.5.4
> 
> The following issues were solved since 3.5.2:
> FELIX-4934 Only log failures for consistently failing bundles
> FELIX-5218 Fileinstall MemoryLeak / Performance degradation in
> WatcherScanner
> FELIX-5217 Fileinstall is handling removal of many files inefficiently
> FELIX-5209 [FileInstall] use framework bundle location to get framework
> bundle
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1119
> 
> 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 1119 /tmp/felix-fileinstall-check
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote will remain open for at least 72 hours.
> 
> Best regards,
> 
> David Bosschaert

Re: [VOTE] Release Apache Felix http.base 3.0.4, http.bridge 3.0.4, and http.jetty 3.1.4

[Clement Escoffier]

+1,

Regards,

Clement

> On 28 nov. 2015, at 19:35, Pierre De Rop  wrote:
> 
> Hi;
> 
> Checked signatures, rebuilt the binaries from the sources, did some basic
> tests.
> 
> +1
> 
> thanks
> /Pierre
> 
> On Sat, Nov 28, 2015 at 1:06 AM, Jamie G.  wrote:
> 
>> +1 (non-binding)
>> 
>> On Thu, Nov 26, 2015 at 11:41 AM, Benson Margulies
>>  wrote:
>>> Yes, I was surprised to get three links to the same list.
>>> On Nov 26, 2015 9:00 AM, "Jean-Baptiste Onofré"  wrote:
>>> 
 +1 (non binding)
 
 Regards
 JB
 
 On 11/26/2015 02:46 PM, David Bosschaert wrote:
 
> +1
> 
> David
> 
> On 26 November 2015 at 13:09, Carsten Ziegeler 
> wrote:
> 
>> Hi,
>> 
>> We solved some issues for this release:
>> 
>> http.base 3.0.4 (4 issues)
>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12333777
>> 
>> http.bridge 3.0.4 (4 issues)
>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12333779
>> 
>> http.jetty 3.1.4 (6 issues)
>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12333778
>> 
>> Staging repository:
>> 
>> https://repository.apache.org/content/repositories/orgapachefelix-1105/
>> 
>> 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 1105 /tmp/felix-staging
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> 
>> This vote will be open for at least 72 hours.
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>> 
> 
 --
 Jean-Baptiste Onofré
 jbono...@apache.org
 http://blog.nanthrax.net
 Talend - http://www.talend.com
 
>> 

Re: [VOTE] framework 5.4.0 and related subproject releases (take 2)

[Clement Escoffier]

+1,

Regards,

Clement

On 14 octobre 2015 at 06:57:51, Carsten Ziegeler (cziege...@apache.org) wrote:

+1 

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

Re: [VOTE] Release Apache Felix Metatype 1.1.2

[Clement Escoffier]

+1,

Regards,

Clement

On 10 août 2015 at 11:05:31, Carsten Ziegeler (cziege...@apache.org) wrote:

+1  

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

Re: [VOTE] Release Apache Felix Metatype 1.1.0

[Clement Escoffier]

+1, 

Regards,

Clement

On 7 août 2015 at 02:18:22, Carsten Ziegeler (cziege...@apache.org) wrote:

This metatype release implements the R6 version of the metatype spec.  

https://issues.apache.org/jira/browse/FELIX/fixforversion/12332142  



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

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 1078 /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 Configadmin 1.8.8

[Clement Escoffier]

+1,

Regards,

Clement

On 7 août 2015 at 02:50:14, Carsten Ziegeler (cziege...@apache.org) wrote:

We solved three issues in this release  

https://issues.apache.org/jira/browse/FELIX/fixforversion/12332748  



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

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 1079 /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 Eventadmin 1.4.4

[Clement Escoffier]

+1,

Regards,

Clement

On 7 août 2015 at 03:01:48, Carsten Ziegeler (cziege...@apache.org) wrote:

We solved four issues in this release  

https://issues.apache.org/jira/browse/FELIX/fixforversion/12328642  



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

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 1080 /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 Http Service

[Clement Escoffier]

+1,

Regards,

Clement

On 6 août 2015 at 01:46:38, David Bosschaert (david.bosscha...@gmail.com) wrote:

+1  

David  

On 5 August 2015 at 18:39, Carsten Ziegeler cziege...@apache.org wrote:  
 We've solved a lot of issues in this release, but also implemented the  
 just released OSGi R6 Http Whiteboard specification. Issues solved:  
  
 I would like to call a vote on the following subproject releases:  
  
 http.parent 7  
 https://issues.apache.org/jira/browse/FELIX/fixforversion/12333131  
  
 http.api 3.0.0  
 (see base)  
  
 http.servlet-api 1.1.2  
 https://issues.apache.org/jira/browse/FELIX/fixforversion/12332372  
  
 http.base 3.0.0  
 https://issues.apache.org/jira/browse/FELIX/fixforversion/12327157)  
  
 http.jetty 3.1.0  
 https://issues.apache.org/jira/browse/FELIX/fixforversion/12329568 (doc  
 issue is still open, I'll close it once the release is available)  
  
 http.whiteboard 3.0.0  
 https://issues.apache.org/jira/browse/FELIX/fixforversion/12332374  
  
 http.sslfilter 1.0.2  
 https://issues.apache.org/jira/browse/FELIX/fixforversion/12332263  
  
  
  
 Staging repository  
 https://repository.apache.org/content/repositories/orgapachefelix-1076/  
  
 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 1076 /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 Webconsole 4.2.10

[Clement Escoffier]

+1,

Regards,

Clement

On 19 juillet 2015 at 15:50:33, Carsten Ziegeler (cziege...@apache.org) wrote:

We're still missing a binding vote. Anyone please? 

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

Re: [VOTE] Release Parent POM 3

[Clement Escoffier]

+1,

Regards,

Clement


 On 19 juin 2015, at 08:54, Carsten Ziegeler cziege...@apache.org wrote:
 
 Hi,
 
 It's a very long time since our latest parent pom release. I've updated
 the pom to work with never maven versions and also support setting the
 target java version (from java 3 to java 8) (see FELIX-4932)
 
 Staging repositories:
 https://repository.apache.org/content/repositories/orgapachefelix-1074/
 
 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 1074 /tmp/felix-staging
 
 Please vote to approve this release:
 
 [ ] +1 Approve the release
 [ ] -1 Veto the release (please provide specific comments)
 
 -- 
 Carsten Ziegeler
 Adobe Research Switzerland
 cziege...@apache.org

Re: [VOTE] framework 5.0.1 and related subproject releases (take2)

[Clement Escoffier]

+1,

Regards,

Clement

 On 17 juin 2015, at 17:19, Karl Pauls karlpa...@gmail.com wrote:
 
 I would like to call a vote on the following subproject releases:
 
 resolver 1.4.0
 framework  5.0.1
 main 5.0.1
 main.distribution 5.0.1
 
 The main changelogs are in jira and at:
 https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.resolver-1.4.0/doc/changelog.txt
 https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.framework-5.0.1/doc/changelog.txt
 
 Staging repositories:
 https://repository.apache.org/content/repositories/orgapachefelix-1073/
 
 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 1073 /tmp/felix-staging
 
 Please vote to approve this release:
 
 [ ] +1 Approve the release
 [ ] -1 Veto the release (please provide specific comments)

Re: [VOTE] Release Apache Felix Http-sslfilter 1.0.0

[clement escoffier]

+1,

Regards,

Clement

2015-05-02 14:51 GMT+02:00 Carsten Ziegeler cziege...@apache.org:

 Anyone else?

 Thanks
 Carsten

 Am 29.04.15 um 16:50 schrieb Carsten Ziegeler:
  Hi,
 
  We solved 2 issues in this release:
  https://issues.apache.org/jira/browse/FELIX/fixforversion/12332243
 
 
  Staging repository:
  https://repository.apache.org/content/repositories/orgapachefelix-1067/
 
  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 1067 /tmp/felix-staging
 
  Please vote to approve this release:
 
  [ ] +1 Approve the release
  [ ] -1 Veto the release (please provide specific comments)
 
  This vote will be open for at least 72 hours.
 
  Regards
  Carsten
 


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

Re: [VOTE] Release Apache Felix Web Console Memory Usage Plugin 1.0.6

[clement escoffier]

+1,

Regards,

Clement

2015-04-27 8:35 GMT+02:00 Carsten Ziegeler cziege...@apache.org:

 We're missing some votes here, anyone?

 Thanks
 Carsten

 Am 24.04.15 um 08:22 schrieb Carsten Ziegeler:
  Hi,
 
  We solved 1 issue in this release:
  https://issues.apache.org/jira/browse/FELIX-4862
 
 
  Staging repository:
  https://repository.apache.org/content/repositories/orgapachefelix-1066/
 
  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 1066 /tmp/felix-staging
 
  Please vote to approve this release:
 
  [ ] +1 Approve the release
  [ ] -1 Veto the release (please provide specific comments)
 
  This vote will be open for at least 72 hours.
 
  Regards
  Carsten
 


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

Re: Could a member of Felix PMC upload Apache Felix Metatype Service version 1.0.12 artifacts?

[clement escoffier]

Hi,

if you send me the artifacts (or tell me where I can find them) I can
upload them.

Cheers,

Clement

2015-04-20 20:59 GMT+02:00 Sahoo sanjeeb.sa...@oracle.com:


 On 18/04/15 4:39 pm, Sahoo wrote:

 Hi,

 It appears I don't have privileges to upload the artifacts to the
 distribution area.

  svn: E195023: Commit failed (details follow):
 svn: E195023: Changing file
 '/private/tmp/felix/org.apache.felix.metatype-1.0.10-javadoc.jar' is
 forbidden by the server
 svn: E175013: Access to
 '/repos/dist/!svn/txr/8647-7ic/release/felix/org.apache.felix.metatype-1.0.10-javadoc.jar'
 forbidden


 May I request a member of the PMC to upload the artifacts please? They
 have been released to maven repository already.

 Can anyone having necessary privileges please upload the artifacts to
 downloads area?

 Thanks,
 Sahoo


 Thanks,
 Sahoo

  Original Message 
 Subject: [RESULT] [VOTE] Release Apache Felix Metatype Service
 version 1.0.12
 Date: Sat, 18 Apr 2015 16:03:33 -0700
 From: Sahoo sanjeeb.sa...@oracle.com
 Reply-To: dev@felix.apache.org, sanjeeb.sa...@oracle.com
 Organization: Oracle America, Inc.
 To: dev@felix.apache.org dev@felix.apache.org



 Hi,

 The vote has passed with the following result :

+1 (binding): Jan Willem Janssen,Guillaume Nodet,David Bosschaert,
 Carsten Ziegeler,Pierre De Rop

+1 (non binding): Jean-Baptiste Onofré

 I will copy this release to the Felix dist directory and
 promote the artifacts to the central Maven repository.


 Thanks,
 Sahoo

  Original Message 
 Subject: Re: [VOTE] Release Apache Felix Metatype Service version
 1.0.12
 Date: Wed, 15 Apr 2015 07:42:12 +
 From: Jan Willem Janssenjanwillem.jans...@luminis.eu
 To: dev@felix.apache.orgdev@felix.apache.org
 CC: sanjeeb.sa...@oracle.comsanjeeb.sa...@oracle.com



 The links in the original vote are messed up. Below are the correct links
 for the staging repository:

On 15 Apr 2015, at 02:22, Sahoosanjeeb.sa...@oracle.com   wrote:


 Staging repository:

 https://repository.apache.org/content/repositories/orgapachefelix-1059

 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 1059 /tmp/felix-staging

 Please vote to approve this release:

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

 This vote will be open for 72 hours.

 --
 Met vriendelijke groeten | Kind regards

 Jan Willem Janssen | Software Architect
 +31 631 765 814

 My world is revolving around INAETICS and Amdatu

 Luminis Technologies B.V.
 Churchillplein 1
 7314 BZ   Apeldoorn
 +31 88 586 46 00

 http://www.luminis-technologies.com
 http://www.luminis.eu

 KvK (CoC) 09 16 28 93
 BTW (VAT) NL8169.78.566.B.01

Re: Could a member of Felix PMC upload Apache Felix Metatype Service version 1.0.12 artifacts?

[clement escoffier]

Even faster ;-)

Clement

2015-04-21 9:03 GMT+02:00 Carsten Ziegeler cziege...@apache.org:

 Am 20.04.15 um 20:59 schrieb Sahoo:

 
  May I request a member of the PMC to upload the artifacts please? They
  have been released to maven repository already.
  Can anyone having necessary privileges please upload the artifacts to
  downloads area?
 
 Done

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

Re: [VOTE] framework 5.0.0 and related subproject releases

[clement escoffier]

+1,

Regards,

Clement

2015-04-20 14:48 GMT+02:00 Carsten Ziegeler cziege...@apache.org:

 Am 20.04.15 um 14:22 schrieb Karl Pauls:
  I would like to call a vote on the following subproject releases:
 
  resolver 1.2.0
  framework  5.0.0
  main 5.0.0
  main.distribution 5.0.0
 
 +1

 Carsten

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

Re: [VOTE] Release ConfigAdmin 1.8.4

[clement escoffier]

+1,

Regards,

Clement

2015-04-20 10:21 GMT+02:00 David Bosschaert david.bosscha...@gmail.com:

 +1

 David

 On 18 April 2015 at 11:33, Guillaume Nodet gno...@apache.org wrote:
  We solved following issues in this release:
 
  ** Bug
 
  * [FELIX-4846] - Wrong exception type in list operation
 
  * [FELIX-4851] - ConfigAdmin only forwards ConfigurationEvents to
  ConfigurationListeners which are provided by bundles that are in state
  ACTIVE
 
  * [FELIX-4855] - ConfigAdmin does not update ManagedServiceFactory on
  framework restart
 
  Staging repository:
 
   https://repository.apache.org/content/repositories/orgapachefelix-1061
 
  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 [YOUR REPOSITORY ID] /tmp/felix-staging
 
  Please vote to approve this release:
 
  [ ] +1 Approve the release
  [ ] -1 Veto the release (please provide specific comments)
 
  Thanks,
  Guillaume Nodet

Re: [VOTE] framework 5.0.0 and related subproject releases (take 2)

[clement escoffier]

+1,

Regards,

Clement

2015-04-20 20:01 GMT+02:00 Carsten Ziegeler cziege...@apache.org:

 Am 20.04.15 um 17:01 schrieb Karl Pauls:
  I would like to call a vote on the following subproject releases:
 
  resolver 1.2.0
  framework  5.0.0
  main 5.0.0
  main.distribution 5.0.0
 
  This is the second attempt because we had to fix some issue with packages
  being included in the framework that shouldn't have been in there --
 hence,
  please recast your votes if you already did vote previously.
 
  The main changelogs are in jira and at:
 
 https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.resolver-1.2.0/doc/changelog.txt
 
 https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.framework-5.0.0/doc/changelog.txt
 
  Staging repositories:
  https://repository.apache.org/content/repositories/orgapachefelix-1064/
 
  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 1064 /tmp/felix-staging
 
  Please vote to approve this release:
 
  [ ] +1 Approve the release
  [ ] -1 Veto the release (please provide specific comments)
 

 +1

 Carsten

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

[jira] [Commented] (FELIX-4842) CONTEXT.Source.INSTANCE cannot work

[Clement Escoffier (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-4842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14395732#comment-14395732
 ] 

Clement Escoffier commented on FELIX-4842:
--

Any reason why you are not using annotations ? 
In XML, the value should be INSTANCE and not Source.INSTANCE.



 CONTEXT.Source.INSTANCE cannot work
 ---

 Key: FELIX-4842
 URL: https://issues.apache.org/jira/browse/FELIX-4842
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Affects Versions: ipojo-runtime-1.12.1
Reporter: armroe

 CONTEXT.Source.INSTANCE annotation cannot work. BundleContext cannot be 
 injected and always null.
 there is no problem with CONTEXT.Source.COMPONENT.



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

[jira] [Commented] (FELIX-4842) CONTEXT.Source.INSTANCE cannot work

[Clement Escoffier (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-4842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14394102#comment-14394102
 ] 

Clement Escoffier commented on FELIX-4842:
--

How is the instance created ?

Context source does only work for instance declared from XML, @Instantiate and 
@Configuration. 
If you create the instance using the API or the configuration admin, they are 
no way to retrieve the bundle creating the instance.


 CONTEXT.Source.INSTANCE cannot work
 ---

 Key: FELIX-4842
 URL: https://issues.apache.org/jira/browse/FELIX-4842
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Affects Versions: ipojo-runtime-1.12.1
Reporter: armroe

 CONTEXT.Source.INSTANCE annotation cannot work. BundleContext cannot be 
 injected and always null.
 there is no problem with CONTEXT.Source.COMPONENT.



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

Re: [VOTE] Release webconsole-4.2.8, webconsole-useradmin-plugin-1.0.2 and webconsole-upnp-plugin-1.0.6

[clement escoffier]

+1,

Regards,

Clement

2015-03-14 14:39 GMT+01:00 Carsten Ziegeler cziege...@apache.org:

 Am 13.03.15 um 08:56 schrieb Valentin Valchev:
  There is no a single vote yet. Come on people.
 

 Sorry, somehow I missed the vote mail :(

 Here's my +1 for the three releases.

 Regards
 Carsten

 
  Regards,
  Valentin
 
  On 10/03/2015 15:30, Valentin Valchev wrote:
  Hi all,
  There are 3 new releases waiting for your approval:
 
  * webconsole-4.2.8
 
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12329340styleName=TextprojectId=12310100
 
  * webconsole-useradmin-plugin-1.0.2
 
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12329243styleName=TextprojectId=12310100
 
  * webconsole-upnp-plugin-1.0.6
 
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12329242styleName=TextprojectId=12310100
 
 
 
  Staging repository:
  https://repository.apache.org/content/repositories/orgapachefelix-1057/
 
  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 1057 /tmp/felix-staging
 
  Please vote to approve this release:
 
  [ ] +1 Approve the release
  [ ] -1 Veto the release (please provide specific comments)
 
  This vote will be open for at least 72 hours.
 
 
  Regards,
  Valentin
 
 
 


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

Re: [VOTE] framework 4.6.1 and related subproject releases

[clement escoffier]

+1,

Regards,

Clement

2015-03-03 13:21 GMT+01:00 Guillaume Nodet gno...@apache.org:

 +1

 2015-03-03 11:26 GMT+01:00 Karl Pauls karlpa...@gmail.com:

  I would like to call a vote on the following subproject releases:
 
  framework  4.6.1
  main 4.6.1
  main.distribution 4.6.1
 
  The main changelog is in jira and at:
 
 
 https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.framework-4.6.1/doc/changelog.txt
 
  Staging repositories:
  https://repository.apache.org/content/repositories/orgapachefelix-1053
 
  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 1053 /tmp/felix-staging
 
  Please vote to approve this release:
 
  [ ] +1 Approve the release
  [ ] -1 Veto the release (please provide specific comments)
 

Re: [VOTE] Release Apache Felix Http 2.4.0

[clement escoffier]

+1,

Regards,

Clement

2015-01-29 14:52 GMT+01:00 Carsten Ziegeler cziege...@apache.org:

 +1

 Carsten


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

Re: [iPOJO] Non-primitive typed properties and constructors

[Clement Escoffier]

Hi,

On 29 janvier 2015 at 18:34:08, Benjamin Debeerst 
(benjamin.debee...@younicos.com) wrote:

Dear iPOJO developers, 

I've stumbled upon a situation with fields in components that are annotated 
with @Property but are of non-primitive and non-String type. 

iPOJO has the nice feature that you still can provide default values and 
configurations as Strings and it will try to find an appropriate String 
constructor for that object. This is done in the Property class [1], starting 
from line 436 (v1.12.0). However, it will only look for the one constructor 
with a single String argument and ignore constructors with the Object argument. 

For example, I often have joda-time Duration and DateTime objects as 
configurations. Those only have Object constructors which still parse Strings 
properly. Wouldn't it be a nice feature if the Property class could fall back 
and try the Object constructor when no String constructor could be found? At 
the moment I have to make them String properties and parse those into shadow 
members upon activation, which is a little cumbersome. 
Yes, definitely a good idea!



For my own types, I'd be able to add a String constructor, but since this is an 
external library, a cannot do that as easily. 

Please let me know what you think of it and if there are any connected issues 
I'd have to think of, and I'd happily provide a patch / pull request. Should I 
open an issue on github or Jira? 
Please open a ticket in Jira (https://issues.apache.org/jira/browse/FELIX). If 
you can attach a patch that would be awesome (and I will be really happy to 
integrate it)

Cheers,

Clement





Kind regards, 
Benjamin 


[1] 
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.felix/org.apache.felix.ipojo/1.12.0/org/apache/felix/ipojo/util/Property.java#436
 

Re: [VOTE] Release Apache Felix Web Console 4.2.6

[clement escoffier]

+1,

Regards,

Clement

2015-01-26 14:29 GMT+01:00 David Bosschaert david.bosscha...@gmail.com:

 +1

 David

 On 26 January 2015 at 14:12, Carsten Ziegeler cziege...@apache.org
 wrote:
  Hi,
 
  We solved 10 issues in this release:
  https://issues.apache.org/jira/browse/FELIX/fixforversion/12329145
 
 
  Staging repository:
  https://repository.apache.org/content/repositories/orgapachefelix-1050/
 
  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 1050 /tmp/felix-staging
 
  Please vote to approve this release:
 
  [ ] +1 Approve the release
  [ ] -1 Veto the release (please provide specific comments)
 
  This vote will be open for at least 72 hours.
 
  Regards
  Carsten
  --
  Carsten Ziegeler
  Adobe Research Switzerland
  cziege...@apache.org

Re: [VOTE] framework 4.6.0 and related subproject releases

[Clement Escoffier]

Awesome !

+1

Cheers,

Clement


On 12 janvier 2015 at 18:27:11, Stuart McCulloch (mccu...@gmail.com) wrote:

+1 checked signatures, ran RAT checks, tested distribution, also tested 
rebuilding it from source 

On Monday, 12 January 2015 at 00:16, Karl Pauls wrote: 

 I would like to call a vote on the following subproject releases: 
 
 framework 4.6.0 
 main 4.6.0 
 main.distribution 4.6.0 
 
 The main changelog is in jira and at: 
 http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.framework-4.6.0/doc/changelog.txt
  
 
 Staging repositories: 
 https://repository.apache.org/content/repositories/orgapachefelix-1049 
 
 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 (http://check_staged_release.sh) 1049 
 /tmp/felix-staging 
 
 Please vote to approve this release: 
 
 [ ] +1 Approve the release 
 [ ] -1 Veto the release (please provide specific comments) 
 
 

[jira] [Commented] (FELIX-4745) Support for aspectj advice static method

[Clement Escoffier (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265755#comment-14265755
 ] 

Clement Escoffier commented on FELIX-4745:
--

Patches are the usual way for iPOJO. As our code is on SVN (and as I don't use 
the github mirrors), PR would be useless.

 Support for aspectj advice static method
 

 Key: FELIX-4745
 URL: https://issues.apache.org/jira/browse/FELIX-4745
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Affects Versions: ipojo-manipulator-1.12.0, ipojo-manipulator-1.12.1
Reporter: Olivier NOUGUIER
Assignee: Clement Escoffier
Priority: Minor
 Attachments: 0001-FELIX-4745-naive-fix.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 When using aspectj to weave classes prior to iPojo packaging, injected advice 
 are ignore by iPojo bytecode manipulation.
 Then NPE are thrown in the advice because of the lazy initialization 
 mechanism of @Requires services.
 In my usecase, I want to weave @Transactional springframework aspect in iPojo 
 component. 
 Code generated:
 static final String updateName_aroundBody0(SignupTestDao ajc$this, String 
 name) {
   LOGGER.info(*ajc$this.testDao*);
   for (Test test : *ajc$this.testDao*.findAll()) {
 test.setName(name);
 *ajc$this.testDao*.update(test);
 if (name.equals(boom)) {
   throw new RuntimeException(boom);
 }
   }
   return done;
 }
 Code expected:
 static final String updateName_aroundBody0(SignupTestDao ajc$this, String 
 name)
 {
   LOGGER.info(*ajc$this.__gettestDao()*);
   for (Test test : *ajc$this.__gettestDao()*.findAll()) {
 test.setName(name);
 *ajc$this.__gettestDao()*.update(test);
 if (name.equals(boom)) {
   throw new RuntimeException(boom);
 }
   }
   return done;
 }
 A naive fix is to apply iPojo bytecode manipulation to static methods... see 
 the patch provided.



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

Re: [VOTE] Release Apache Felix SCR Annotations 1.9.10

[Clement Escoffier]

+1,

Regards,

Clement

On 5 janvier 2015 at 17:58:27, Carsten Ziegeler (cziege...@apache.org) wrote:

Am 05.01.15 um 17:36 schrieb Carsten Ziegeler: 
 Hi, 
 
 we fixed one issue: 
 
 https://issues.apache.org/jira/browse/FELIX-4648 
 
 Staging repository: 
 https://repository.apache.org/content/repositories/orgapachefelix-1048/ 
 
 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 1048 /tmp/felix-staging 
 
 Please vote to approve this release: 
 
 [ ] +1 Approve the release 
 [ ] -1 Veto the release (please provide specific comments) 
 
 This vote will be open for 72 hours. 
 
 Regards 
 Carsten 
 
+1 

Carsten 

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

[jira] [Commented] (FELIX-4745) Support for aspectj advice static method

[Clement Escoffier (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263847#comment-14263847
 ] 

Clement Escoffier commented on FELIX-4745:
--

iPOJO does not manipulate static method as static method do not have a 
'reference' on the instance manager. In your case you inject a reference on the 
object into a static method. We could track this pattern. It's obviously only 
valid for field accesses (as method are replaced by _proxies_).

To sum up that would mean:

* analyzing static method
* check access for non static field belonging to the component class (owner is 
the component class)
* replacing these accesses by the `__get` or `__set` calls.

 Support for aspectj advice static method
 

 Key: FELIX-4745
 URL: https://issues.apache.org/jira/browse/FELIX-4745
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Affects Versions: ipojo-manipulator-1.12.0
Reporter: Olivier NOUGUIER
Priority: Minor
 Attachments: 0001-FELIX-4745-naive-fix.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 When using aspectj to weave classes prior to iPojo packaging, injected advice 
 are ignore by iPojo bytecode manipulation.
 Then NPE are thrown in the advice because of the lazy initialization 
 mechanism of @Requires services.
 In my usecase, I want to weave @Transactional springframework aspect in iPojo 
 component. 
 Code generated:
 static final String updateName_aroundBody0(SignupTestDao ajc$this, String 
 name) {
   LOGGER.info(*ajc$this.testDao*);
   for (Test test : *ajc$this.testDao*.findAll()) {
 test.setName(name);
 *ajc$this.testDao*.update(test);
 if (name.equals(boom)) {
   throw new RuntimeException(boom);
 }
   }
   return done;
 }
 Code expected:
 static final String updateName_aroundBody0(SignupTestDao ajc$this, String 
 name)
 {
   LOGGER.info(*ajc$this.__gettestDao()*);
   for (Test test : *ajc$this.__gettestDao()*.findAll()) {
 test.setName(name);
 *ajc$this.__gettestDao()*.update(test);
 if (name.equals(boom)) {
   throw new RuntimeException(boom);
 }
   }
   return done;
 }
 A naive fix is to apply iPojo bytecode manipulation to static methods... see 
 the patch provided.



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

[jira] [Assigned] (FELIX-4745) Support for aspectj advice static method

[Clement Escoffier (JIRA)]

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

Clement Escoffier reassigned FELIX-4745:


Assignee: Clement Escoffier

 Support for aspectj advice static method
 

 Key: FELIX-4745
 URL: https://issues.apache.org/jira/browse/FELIX-4745
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Affects Versions: ipojo-manipulator-1.12.0, ipojo-manipulator-1.12.1
Reporter: Olivier NOUGUIER
Assignee: Clement Escoffier
Priority: Minor
 Attachments: 0001-FELIX-4745-naive-fix.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 When using aspectj to weave classes prior to iPojo packaging, injected advice 
 are ignore by iPojo bytecode manipulation.
 Then NPE are thrown in the advice because of the lazy initialization 
 mechanism of @Requires services.
 In my usecase, I want to weave @Transactional springframework aspect in iPojo 
 component. 
 Code generated:
 static final String updateName_aroundBody0(SignupTestDao ajc$this, String 
 name) {
   LOGGER.info(*ajc$this.testDao*);
   for (Test test : *ajc$this.testDao*.findAll()) {
 test.setName(name);
 *ajc$this.testDao*.update(test);
 if (name.equals(boom)) {
   throw new RuntimeException(boom);
 }
   }
   return done;
 }
 Code expected:
 static final String updateName_aroundBody0(SignupTestDao ajc$this, String 
 name)
 {
   LOGGER.info(*ajc$this.__gettestDao()*);
   for (Test test : *ajc$this.__gettestDao()*.findAll()) {
 test.setName(name);
 *ajc$this.__gettestDao()*.update(test);
 if (name.equals(boom)) {
   throw new RuntimeException(boom);
 }
   }
   return done;
 }
 A naive fix is to apply iPojo bytecode manipulation to static methods... see 
 the patch provided.



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

[jira] [Updated] (FELIX-4745) Support for aspectj advice static method

[Clement Escoffier (JIRA)]

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

Clement Escoffier updated FELIX-4745:
-
Affects Version/s: ipojo-manipulator-1.12.1

 Support for aspectj advice static method
 

 Key: FELIX-4745
 URL: https://issues.apache.org/jira/browse/FELIX-4745
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Affects Versions: ipojo-manipulator-1.12.0, ipojo-manipulator-1.12.1
Reporter: Olivier NOUGUIER
Assignee: Clement Escoffier
Priority: Minor
 Attachments: 0001-FELIX-4745-naive-fix.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 When using aspectj to weave classes prior to iPojo packaging, injected advice 
 are ignore by iPojo bytecode manipulation.
 Then NPE are thrown in the advice because of the lazy initialization 
 mechanism of @Requires services.
 In my usecase, I want to weave @Transactional springframework aspect in iPojo 
 component. 
 Code generated:
 static final String updateName_aroundBody0(SignupTestDao ajc$this, String 
 name) {
   LOGGER.info(*ajc$this.testDao*);
   for (Test test : *ajc$this.testDao*.findAll()) {
 test.setName(name);
 *ajc$this.testDao*.update(test);
 if (name.equals(boom)) {
   throw new RuntimeException(boom);
 }
   }
   return done;
 }
 Code expected:
 static final String updateName_aroundBody0(SignupTestDao ajc$this, String 
 name)
 {
   LOGGER.info(*ajc$this.__gettestDao()*);
   for (Test test : *ajc$this.__gettestDao()*.findAll()) {
 test.setName(name);
 *ajc$this.__gettestDao()*.update(test);
 if (name.equals(boom)) {
   throw new RuntimeException(boom);
 }
   }
   return done;
 }
 A naive fix is to apply iPojo bytecode manipulation to static methods... see 
 the patch provided.



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

[jira] [Commented] (FELIX-4745) Support for aspectj advice static method

[Clement Escoffier (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263848#comment-14263848
 ] 

Clement Escoffier commented on FELIX-4745:
--

I will look to your patch this week. I'm only worried about the reuse of the 
whole code adapter. I may require some adaptations.

 Support for aspectj advice static method
 

 Key: FELIX-4745
 URL: https://issues.apache.org/jira/browse/FELIX-4745
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Affects Versions: ipojo-manipulator-1.12.0
Reporter: Olivier NOUGUIER
Priority: Minor
 Attachments: 0001-FELIX-4745-naive-fix.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 When using aspectj to weave classes prior to iPojo packaging, injected advice 
 are ignore by iPojo bytecode manipulation.
 Then NPE are thrown in the advice because of the lazy initialization 
 mechanism of @Requires services.
 In my usecase, I want to weave @Transactional springframework aspect in iPojo 
 component. 
 Code generated:
 static final String updateName_aroundBody0(SignupTestDao ajc$this, String 
 name) {
   LOGGER.info(*ajc$this.testDao*);
   for (Test test : *ajc$this.testDao*.findAll()) {
 test.setName(name);
 *ajc$this.testDao*.update(test);
 if (name.equals(boom)) {
   throw new RuntimeException(boom);
 }
   }
   return done;
 }
 Code expected:
 static final String updateName_aroundBody0(SignupTestDao ajc$this, String 
 name)
 {
   LOGGER.info(*ajc$this.__gettestDao()*);
   for (Test test : *ajc$this.__gettestDao()*.findAll()) {
 test.setName(name);
 *ajc$this.__gettestDao()*.update(test);
 if (name.equals(boom)) {
   throw new RuntimeException(boom);
 }
   }
   return done;
 }
 A naive fix is to apply iPojo bytecode manipulation to static methods... see 
 the patch provided.



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

Re: [VOTE] Release of iPOJO Manipulator and Runtime 1.12.1

[clement escoffier]

Sorry, I should improve my counting skills, missed Pierre's vote.

Clement

2014-12-24 8:25 GMT+01:00 Clement Escoffier clement.escoff...@gmail.com:

 Still one +1 missing, anyone willing to do a Christmas present ?

 Regards,

 Clement

 On 23 décembre 2014 at 12:12:09, Carsten Ziegeler (cziege...@apache.org)
 wrote:

 +1

 Sorry, I missed this one initially

 Carsten

 Am 23.12.14 um 08:58 schrieb Clement Escoffier:
  +1,
 
  Regards,
 
  Clement
 
  PS: 2 bindings votes missing, anyone ?
  On 21 décembre 2014 at 05:57:05, Jean-Baptiste Onofré (j...@nanthrax.net)
 wrote:
 
  +1 (non binding)
 
  Regards
  JB
 
  On 12/20/2014 11:42 PM, Pierre De Rop wrote:
  Hello Clement;
 
  +1
 
  regards
  /Pierre
 
  On Tue, Dec 16, 2014 at 3:20 PM, Clement Escoffier 
  clement.escoff...@gmail.com wrote:
 
  Hi,
 
  It's time to cut a release of the iPOJO manipulator (1.12.1) and
 runtime
  (1.12.1). Both projects are containing several modules:
 
  The org.apache.felix.ipojo.manipulator-project contains:
  * bnd-ipojo-plugin
  * maven-ipojo-plugin
  * org.apache.felix.ipojo.annotations
  * org.apache.felix.ipojo.ant
  * org.apache.felix.ipojo.manipulator
  * org.apache.felix.ipojo.manipulator.online
 
  The org.apache.felix.ipojo.runtime-project contains:
  * org.apache.felix.ipojo
  * org.apache.felix.ipojo.api
  * org.apache.felix.ipojo.composite
  * org.apache.felix.ipojo.distribution.10mintutorial
  * org.apache.felix.ipojo.distribution.maventutorial
  * org.apache.felix.ipojo.distribution.quickstart
  * org.apache.felix.ipojo.features
  * org.apache.felix.ipojo.gogo
 
  It's a bug fix release. The changelogs are below.
 
  Staging repository:
 
 https://repository.apache.org/content/repositories/orgapachefelix-1047/
 
  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 1047 /tmp/felix-staging
 
  Please vote to approve this release:
  [ ] +1 Approve the release
  [ ] -1 Veto the release (please provide specific comments)
 
  This vote will be open for 72 hours (at least).
 
  Regards,
 
  Clement
 
  
  Changelog of the runtime project (1.12.1):
 
  ** Bug
  * [FELIX-3836] - NPE when calling InstanceDescription.getDescription()
  * [FELIX-4565] - Occasional ArrayIndexOutOfBoundException in iPOJO's
  ProvidedServiceHandler
  * [FELIX-4646] - @Context(Context.Source.INSTANCE) does not inject
  bundle context
  * [FELIX-4713] - Error in ProvidedServiceHandler.checkProvidedService
  : only the first service is checked
  * [FELIX-4715] - instance bundle context injection does not works
  * [FELIX-4716] - Bundle org.apache.felix.ipojo physically contains
  OSGi API classes
  * [FELIX-4717] - Cannot use the stream API on injected collections
  * [FELIX-4728] - InstanceManager concurrency issue
 
  Changelog of the manipulator project (1.12.1):
 
  ** Bug
  * [FELIX-4612] - @PostRegistration is not being called
  * [FELIX-4620] - Warning should be removed when @Configuration is used
  * [FELIX-4668] - Can not use @Stereotype annotated annotation from
  another bundle (unless its package is included or re-exported)
  * [FELIX-4725] - Inner Class Manipulation uses the wrong 'access
 level'
 
 
  --
  Jean-Baptiste Onofré
  jbono...@apache.org
  http://blog.nanthrax.net
  Talend - http://www.talend.com
 


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

[RESULT][VOTE] Release of iPOJO Manipulator and Runtime 1.12.1

[clement escoffier]

Hi,

The vote has passed. Thanks to everyone.

I'm going to upload the released artifacts right now !

Regards,

Clement

2014-12-24 15:13 GMT+01:00 clement escoffier clement.escoff...@gmail.com:

 Sorry, I should improve my counting skills, missed Pierre's vote.

 Clement

 2014-12-24 8:25 GMT+01:00 Clement Escoffier clement.escoff...@gmail.com:

 Still one +1 missing, anyone willing to do a Christmas present ?

 Regards,

 Clement

 On 23 décembre 2014 at 12:12:09, Carsten Ziegeler (cziege...@apache.org)
 wrote:

 +1

 Sorry, I missed this one initially

 Carsten

 Am 23.12.14 um 08:58 schrieb Clement Escoffier:
  +1,
 
  Regards,
 
  Clement
 
  PS: 2 bindings votes missing, anyone ?
  On 21 décembre 2014 at 05:57:05, Jean-Baptiste Onofré (j...@nanthrax.net)
 wrote:
 
  +1 (non binding)
 
  Regards
  JB
 
  On 12/20/2014 11:42 PM, Pierre De Rop wrote:
  Hello Clement;
 
  +1
 
  regards
  /Pierre
 
  On Tue, Dec 16, 2014 at 3:20 PM, Clement Escoffier 
  clement.escoff...@gmail.com wrote:
 
  Hi,
 
  It's time to cut a release of the iPOJO manipulator (1.12.1) and
 runtime
  (1.12.1). Both projects are containing several modules:
 
  The org.apache.felix.ipojo.manipulator-project contains:
  * bnd-ipojo-plugin
  * maven-ipojo-plugin
  * org.apache.felix.ipojo.annotations
  * org.apache.felix.ipojo.ant
  * org.apache.felix.ipojo.manipulator
  * org.apache.felix.ipojo.manipulator.online
 
  The org.apache.felix.ipojo.runtime-project contains:
  * org.apache.felix.ipojo
  * org.apache.felix.ipojo.api
  * org.apache.felix.ipojo.composite
  * org.apache.felix.ipojo.distribution.10mintutorial
  * org.apache.felix.ipojo.distribution.maventutorial
  * org.apache.felix.ipojo.distribution.quickstart
  * org.apache.felix.ipojo.features
  * org.apache.felix.ipojo.gogo
 
  It's a bug fix release. The changelogs are below.
 
  Staging repository:
 
 https://repository.apache.org/content/repositories/orgapachefelix-1047/
 
  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 1047 /tmp/felix-staging
 
  Please vote to approve this release:
  [ ] +1 Approve the release
  [ ] -1 Veto the release (please provide specific comments)
 
  This vote will be open for 72 hours (at least).
 
  Regards,
 
  Clement
 
  
  Changelog of the runtime project (1.12.1):
 
  ** Bug
  * [FELIX-3836] - NPE when calling
 InstanceDescription.getDescription()
  * [FELIX-4565] - Occasional ArrayIndexOutOfBoundException in iPOJO's
  ProvidedServiceHandler
  * [FELIX-4646] - @Context(Context.Source.INSTANCE) does not inject
  bundle context
  * [FELIX-4713] - Error in ProvidedServiceHandler.checkProvidedService
  : only the first service is checked
  * [FELIX-4715] - instance bundle context injection does not works
  * [FELIX-4716] - Bundle org.apache.felix.ipojo physically contains
  OSGi API classes
  * [FELIX-4717] - Cannot use the stream API on injected collections
  * [FELIX-4728] - InstanceManager concurrency issue
 
  Changelog of the manipulator project (1.12.1):
 
  ** Bug
  * [FELIX-4612] - @PostRegistration is not being called
  * [FELIX-4620] - Warning should be removed when @Configuration is
 used
  * [FELIX-4668] - Can not use @Stereotype annotated annotation from
  another bundle (unless its package is included or re-exported)
  * [FELIX-4725] - Inner Class Manipulation uses the wrong 'access
 level'
 
 
  --
  Jean-Baptiste Onofré
  jbono...@apache.org
  http://blog.nanthrax.net
  Talend - http://www.talend.com
 


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

[jira] [Closed] (FELIX-4565) Occasional ArrayIndexOutOfBoundException in iPOJO's ProvidedServiceHandler

[Clement Escoffier (JIRA)]

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

Clement Escoffier closed FELIX-4565.


 Occasional ArrayIndexOutOfBoundException in iPOJO's ProvidedServiceHandler
 --

 Key: FELIX-4565
 URL: https://issues.apache.org/jira/browse/FELIX-4565
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Affects Versions: ipojo-runtime-1.11.2
 Environment: Karaf 2.3.3 / Windows 7 64 bit
Reporter: Benjamin Debeerst
Assignee: Clement Escoffier
 Fix For: ipojo-runtime-1.12.1


 I have an iPOJO (1.11.2) component using the @ServiceController annotation to 
 control the service publishing. Most of the time this works perfectly fine, 
 but occasionally I get an ArrayIndexOutOfBoundsException.
 {code}
 java.lang.ArrayIndexOutOfBoundsException: 4
at 
 org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.__M_onSet(ProvidedServiceHandler.java:416)[83:org.apache.felix.ipojo:1.11.2]
at 
 org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.onSet(ProvidedServiceHandler.java)[83:org.apache.felix.ipojo:1.11.2]
at 
 org.apache.felix.ipojo.InstanceManager.onSet(InstanceManager.java:1401)[83:org.apache.felix.ipojo:1.11.2]
[..] (My own code following, where the service controller 
 boolean is manipulated)
 {code}
 Unfortunately I cannot share the consumer code nor reproduce the problem. I 
 looked into [iPOJOs 
 code|http://grepcode.com/file/repo1.maven.org/maven2/org.apache.felix/org.apache.felix.ipojo/1.11.2/org/apache/felix/ipojo/handlers/providedservice/ProvidedServiceHandler.java#416]
  to see what's going on, and there we have:
 {code}
 for (int j = 0; j  svc.getProperties().length; j++) { Property prop = 
 svc.getProperties()[j];
[...]
 }
 {code}
 Which looks like a proper race condition to me, if svc.getProperties() 
 changes its value in the meantime because of missing synchronizations. I 
 don't see any synchronizations there, but I also don't know if they would be 
 appropriate in the first place.



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

[jira] [Closed] (FELIX-4717) Cannot use the stream API on injected collections

[Clement Escoffier (JIRA)]

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

Clement Escoffier closed FELIX-4717.


 Cannot use the stream API on injected collections
 -

 Key: FELIX-4717
 URL: https://issues.apache.org/jira/browse/FELIX-4717
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Affects Versions: ipojo-runtime-1.12.0
Reporter: Clement Escoffier
Assignee: Clement Escoffier
 Fix For: ipojo-runtime-1.12.1


 An incompatible class change error is thrown when the stream API is used on 
 injected collections:
 {code}
 [ERROR]  : java.lang.IncompatibleClassChangeError: Conflicting default 
 methods: java/util/List.spliterator java/util/Set.spliterator
 java.lang.IllegalStateException: java.lang.IncompatibleClassChangeError: 
 Conflicting default methods: java/util/List.spliterator 
 java/util/Set.spliterator
   at 
 org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.__M_stateChanged(LifecycleCallbackHandler.java:171)
  ~[org.apache.felix.ipojo-1.12.0.jar:na]
   at 
 org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.stateChanged(LifecycleCallbackHandler.java)
  ~[org.apache.felix.ipojo-1.12.0.jar:na]
   at 
 org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:560) 
 [org.apache.felix.ipojo-1.12.0.jar:na]
   at 
 org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:440) 
 [org.apache.felix.ipojo-1.12.0.jar:na]
   at 
 org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:179)
  [org.apache.felix.ipojo-1.12.0.jar:na]
   at 
 org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:319)
  [org.apache.felix.ipojo-1.12.0.jar:na]
   at 
 org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:240)
  [org.apache.felix.ipojo-1.12.0.jar:na]
   at 
 org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:312)
  [org.apache.felix.ipojo-1.12.0.jar:na]
   at 
 org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:306)
  [org.apache.felix.ipojo-1.12.0.jar:na]
   at 
 org.apache.felix.ipojo.extender.internal.queue.JobInfoCallable.call(JobInfoCallable.java:114)
  [org.apache.felix.ipojo-1.12.0.jar:na]
   at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0]
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
  [na:1.8.0]
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
  [na:1.8.0]
   at java.lang.Thread.run(Thread.java:744) [na:1.8.0]
 Caused by: java.lang.IncompatibleClassChangeError: Conflicting default 
 methods: java/util/List.spliterator java/util/Set.spliterator
   at 
 org.apache.felix.ipojo.handlers.dependency.ServiceCollection.spliterator(ServiceCollection.java)
  ~[org.apache.felix.ipojo-1.12.0.jar:na]
   at java.util.Collection.stream(Collection.java:581) ~[na:1.8.0]
   at 
 org.wisdom.samples.SamplesController.__M_test(SamplesController.java:100) 
 ~[na:na]
   at org.wisdom.samples.SamplesController.test(SamplesController.java) 
 ~[na:na]
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
 ~[na:1.8.0]
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
 ~[na:1.8.0]
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  ~[na:1.8.0]
   at java.lang.reflect.Method.invoke(Method.java:483) ~[na:1.8.0]
   at org.apache.felix.ipojo.util.Callback.call(Callback.java:233) 
 ~[org.apache.felix.ipojo-1.12.0.jar:na]
   at org.apache.felix.ipojo.util.Callback.call(Callback.java:193) 
 ~[org.apache.felix.ipojo-1.12.0.jar:na]
   at 
 org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.call(LifecycleCallback.java:86)
  ~[org.apache.felix.ipojo-1.12.0.jar:na]
   at 
 org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.__M_stateChanged(LifecycleCallbackHandler.java:162)
  ~[org.apache.felix.ipojo-1.12.0.jar:na]
   ... 13 common frames omitted
 {code}



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

[jira] [Closed] (FELIX-4668) Can not use @Stereotype annotated annotation from another bundle (unless its package is included or re-exported)

[Clement Escoffier (JIRA)]

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

Clement Escoffier closed FELIX-4668.


 Can not use @Stereotype annotated annotation from another bundle (unless its 
 package is included or re-exported)
 

 Key: FELIX-4668
 URL: https://issues.apache.org/jira/browse/FELIX-4668
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
 Environment: maven-ipojo-plugin 1.12.0
Reporter: Milen Dyankov
Assignee: Clement Escoffier
Priority: Minor
  Labels: ipojo-manipulator, maven
 Fix For: ipojo-manipulator-1.12.1

 Attachments: stereotype-test.zip


 Here are the steps:
 # create a bundle (say Stereotype) that exports package 
 {{test.ipojo.stereotype}} containing
 ## the {{MyInterface}} interface 
 ## the {{MyComponent}} annotation:
 {code}
 @Component
 @Provides (specifications = MyInterface.class)
 @Stereotype
 @Target(TYPE)
 public @interface  MyComponent {
 }
 {code}
 # build and install Stereotype in local maven repo
 # using maven, create another bundle (say Stereotype-bundle) containing a 
 class that uses the stereotype:
 {code}
 @MyComponent
 public class ComponentByStereotype extends ComponentBase implements 
 AnotherInterface 
 {code}
 # configure BND of Stereotype-bundle like this (the bundle does not need to 
 export or include any package):
 {code:xml}
 Bundle-SymbolicName${project.groupId}.${project.artifactId}/Bundle-SymbolicName
 Bundle-Version${project.version}/Bundle-Version
 Import-Packagetest.ipojo.stereotype,*/Import-Package
 Private-Package/Private-Package
 Export-Package/Export-Package
 {code}
 # make sure Stereotype-bundle has Stereotype in it's maven dependencies
 # configure {{maven-ipojo-plugin}} in Stereotype-bundle
 {code:xml}
 plugin
   groupIdorg.apache.felix/groupId
   artifactIdmaven-ipojo-plugin/artifactId
   version1.12.0/version
   executions
   execution
   goals
   goalipojo-bundle/goal
   /goals
   /execution
   /executions
 /plugin
 {code}
 # Try to build 'Stereotype-bundle'
 +Expected result:+ The  'Stereotype-bundle' will be build and @MyComponent 
 annotation will be processed.
 +Actual result:+ The @MyComponent annotation is NOT processed. The following 
 is displayed in console:
 {code}
 [WARNING] Class test.ipojo.bundle.ComponentByStereotype has not been marked 
 as a component type (no @Component, @Handler, ...). It will be ignored by the 
 iPOJO manipulator.
 {code}



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

[jira] [Closed] (FELIX-4620) Warning should be removed when @Configuration is used

[Clement Escoffier (JIRA)]

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

Clement Escoffier closed FELIX-4620.


 Warning should be removed when @Configuration is used
 -

 Key: FELIX-4620
 URL: https://issues.apache.org/jira/browse/FELIX-4620
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Affects Versions: ipojo-manipulator-1.12.0
Reporter: Thomas Leveque
Assignee: Clement Escoffier
Priority: Minor
 Fix For: ipojo-manipulator-1.12.1


 Following warning should be removed when a class used the @Configuration 
 annotation.
 has not been marked as a component type (no @Component, @Handler, ...). It 
 will be ignored by the iPOJO manipulator.



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

[jira] [Closed] (FELIX-4646) @Context(Context.Source.INSTANCE) does not inject bundle context

[Clement Escoffier (JIRA)]

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

Clement Escoffier closed FELIX-4646.


 @Context(Context.Source.INSTANCE) does not inject bundle context
 

 Key: FELIX-4646
 URL: https://issues.apache.org/jira/browse/FELIX-4646
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Affects Versions: ipojo-runtime-1.12.0
 Environment: JAVA 1.8
Reporter: Pierrick
Assignee: Clement Escoffier
Priority: Blocker
 Fix For: ipojo-runtime-1.12.1


 I would like to use the bundle context for each instanciate of my bundle with 
 this code :
 @Context(Context.Source.INSTANCE)
 private BundleContext _context;
 But the context return is null.
 If I use Context.Source.COMPONENT for the context definition, the context 
 field is injected.



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

[jira] [Closed] (FELIX-4612) @PostRegistration is not being called

[Clement Escoffier (JIRA)]

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

Clement Escoffier closed FELIX-4612.


 @PostRegistration is not being called
 -

 Key: FELIX-4612
 URL: https://issues.apache.org/jira/browse/FELIX-4612
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
 Environment: Seen on felix and equinox
Reporter: Luke Winkenbach
Assignee: Clement Escoffier
 Fix For: ipojo-manipulator-1.12.1

 Attachments: post_registration_fix.diff


 When a simple service starts up, I expect to see the following:
 # Constructor called
 # @Validate method called
 # @PostRegistration called
 Instead, what is seen is:
 # Constructor called
 # @Validate method called
 # @Post*Un*registration called
 Here is the service implementation:
 {code:title=TestServiceImpl.java|borderStyle=solid}
 @Component
 @Provides
 @Instantiate
 public class TestServiceImpl implements TestService
 {
   @Requires 
   LogService log;
   
   public TestServiceImpl()
   {
 log.log(LogService.LOG_ERROR, TestServiceImpl Constructor);
   }
   
   @Validate
   public void validate()
   {
 log.log(LogService.LOG_ERROR, Validate);
   }
   
   @Invalidate
   public void invalidate()
   {
 log.log(LogService.LOG_ERROR, Invalidate);
   }
   
   @PostRegistration
   public void name(ServiceReference ref)
   {
 log.log(LogService.LOG_ERROR, PostRegistration);
   }
   
   @PostUnregistration
   public void uname(ServiceReference ref)
   {
 log.log(LogService.LOG_ERROR, PostUnregistration);
   }
 }
 {code}



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

[jira] [Closed] (FELIX-4728) InstanceManager concurrency issue

[Clement Escoffier (JIRA)]

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

Clement Escoffier closed FELIX-4728.


 InstanceManager concurrency issue
 -

 Key: FELIX-4728
 URL: https://issues.apache.org/jira/browse/FELIX-4728
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Affects Versions: ipojo-runtime-1.11.2
Reporter: Niels Beekman
Assignee: Clement Escoffier
 Fix For: ipojo-runtime-1.12.1


 We observed a race condition in InstanceManager.onEntry. This is caused by 
 improperly synchronized access on a HashMap. Unlike reported in FELIX-3500, 
 we did not get an exception, but high cpu usage due to the data race. See the 
 relevant thread stacks in the comments.



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

[jira] [Closed] (FELIX-4725) Inner Class Manipulation uses the wrong 'access level'

[Clement Escoffier (JIRA)]

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

Clement Escoffier closed FELIX-4725.


 Inner Class Manipulation uses the wrong 'access level'
 --

 Key: FELIX-4725
 URL: https://issues.apache.org/jira/browse/FELIX-4725
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Affects Versions: ipojo-manipulator-1.12.0
Reporter: Clement Escoffier
Assignee: Clement Escoffier
 Fix For: ipojo-manipulator-1.12.1


 When the manipulator manipulates inner classes, the copied method are reusing 
 the same access level than the initial (original method). For instance 
 {code}public void foo(){code}  is replaced by {code}public void 
 __foo(){code}. However, reusing the same access level leads to a (missing) 
 mediation on the invoke instruction we need to use to invoke this method. 
 Despite this is working on traditional JVM (Oracle, HotSpot...), it fails on 
 Dalvik. 
 The fix is straightforward. Copied methods should be private:
 {code}private void __foo(){code}
 Thus, we just need to use the {code}INVOKE_SPECIAL{code} instruction.



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

[jira] [Closed] (FELIX-3836) NPE when calling InstanceDescription.getDescription() ; // HandlerDescription is missing for org.apache.felix.ipojo.handlers.event:subscriber handler

[Clement Escoffier (JIRA)]

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

Clement Escoffier closed FELIX-3836.


 NPE when calling InstanceDescription.getDescription() ; //  
 HandlerDescription is missing for 
 org.apache.felix.ipojo.handlers.event:subscriber handler
 --

 Key: FELIX-3836
 URL: https://issues.apache.org/jira/browse/FELIX-3836
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Reporter: Jérémy Cazaux
Assignee: Clement Escoffier
 Fix For: ipojo-runtime-1.12.1

 Attachments: bug.png


 java.lang.NullPointerException
   at 
 org.apache.felix.ipojo.architecture.InstanceDescription.getDescription(InstanceDescription.java:164)
   at 
 org.apache.felix.ipojo.PrimitiveInstanceDescription.getDescription(PrimitiveInstanceDescription.java:165)
 NPE when executing this line in the InstanceDescription :
 instance.addElement(m_handlers[i].getHandlerInfo()); 
 My component has 4 handlers : [org.ow2.jonas.ipojo.interceptor:interceptor, 
 org.apache.felix.ipojo:provides, 
 org.apache.felix.ipojo.handlers.event:subscriber, 
 org.apache.felix.ipojo:architecture]
 cazauxj@jonas$ inspect service capability 103
 JOnAS :: Services :: JOnAS report :: Extensions :: Deployables (103) provides 
 services:
 ---
 component.class = 
 org.ow2.jonas.report.extensions.deployables.internal.DeployablesReportExtension
 component.description = factory name=DeployablesReportExtension 
 bundle=103 state=valid 
 implementation-class=org.ow2.jonas.report.extensions.deployables.internal.DeployablesReportExtension
 requiredhandlers list=[org.ow2.jonas.ipojo.interceptor:interceptor, 
 org.apache.felix.ipojo:provides, 
 org.apache.felix.ipojo.handlers.event:subscriber, 
 org.apache.felix.ipojo:architecture]
 missinghandlers list=[]
 provides specification=org.ow2.jonas.report.api.IReportExtension
 property name=namespace type=java.lang.String 
 value=http://jonas.ow2.org/report/deployables/1.0;
 property name=event.topics type=java.util.Dictionary value={}
 property name=event.filter type=java.util.Dictionary value={}
 inherited interfaces=[org.ow2.jonas.report.api.IReportExtension] 
 superclasses=[]
 component.properties = 
 [Lorg.apache.felix.ipojo.architecture.PropertyDescription;@19c59085
 component.providedServiceSpecifications = 
 org.ow2.jonas.report.api.IReportExtension
 factory.name = DeployablesReportExtension
 factory.state = 1
 objectClass = org.apache.felix.ipojo.Factory, 
 org.osgi.service.cm.ManagedServiceFactory
 service.id = 299
 service.pid = DeployablesReportExtension
 
 factory.name = DeployablesReportExtension
 instance.name = DeployablesReportExtension-0
 namespace = http://jonas.ow2.org/report/deployables/1.0
 objectClass = org.ow2.jonas.report.api.IReportExtension
 service.id = 303
 When debugging, it looks like that the array of HandlerDescription does 
 contain the correct number of element (4) but the element with index 2 is 
 NULL. So the HandlerDescription is missing for 
 org.apache.felix.ipojo.handlers.event:subscriber handler. However, all 
 HandlerManager  are available from the InstanceManager (the HandlerManager 
 associated to the subscriber handler is not null). I have attached a picture 
 to illustrate this.



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

[jira] [Closed] (FELIX-4715) instance bundle context injection does not works

[Clement Escoffier (JIRA)]

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

Clement Escoffier closed FELIX-4715.


 instance bundle context injection does not works
 

 Key: FELIX-4715
 URL: https://issues.apache.org/jira/browse/FELIX-4715
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Affects Versions: ipojo-runtime-1.12.0
 Environment: Ubuntu 14.04 LTS and Mac OS X
Reporter: Thomas Leveque
Assignee: Clement Escoffier
 Fix For: ipojo-runtime-1.12.1


 Using @Context(Context.Source.INSTANCE) field injection injects null value.
 I tested it on iPOJO 1.11.x and it was working.



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

Re: [VOTE] Release of iPOJO Manipulator and Runtime 1.12.1

[Clement Escoffier]

Still one +1 missing, anyone willing to do a Christmas present ? 

Regards,

Clement
On 23 décembre 2014 at 12:12:09, Carsten Ziegeler (cziege...@apache.org) wrote:

+1  

Sorry, I missed this one initially  

Carsten  

Am 23.12.14 um 08:58 schrieb Clement Escoffier:  
 +1,  
  
 Regards,  
  
 Clement  
  
 PS: 2 bindings votes missing, anyone ?  
 On 21 décembre 2014 at 05:57:05, Jean-Baptiste Onofré (j...@nanthrax.net) 
 wrote:  
  
 +1 (non binding)  
  
 Regards  
 JB  
  
 On 12/20/2014 11:42 PM, Pierre De Rop wrote:  
 Hello Clement;  
  
 +1  
  
 regards  
 /Pierre  
  
 On Tue, Dec 16, 2014 at 3:20 PM, Clement Escoffier   
 clement.escoff...@gmail.com wrote:  
  
 Hi,  
  
 It's time to cut a release of the iPOJO manipulator (1.12.1) and runtime  
 (1.12.1). Both projects are containing several modules:  
  
 The org.apache.felix.ipojo.manipulator-project contains:  
 * bnd-ipojo-plugin  
 * maven-ipojo-plugin  
 * org.apache.felix.ipojo.annotations  
 * org.apache.felix.ipojo.ant  
 * org.apache.felix.ipojo.manipulator  
 * org.apache.felix.ipojo.manipulator.online  
  
 The org.apache.felix.ipojo.runtime-project contains:  
 * org.apache.felix.ipojo  
 * org.apache.felix.ipojo.api  
 * org.apache.felix.ipojo.composite  
 * org.apache.felix.ipojo.distribution.10mintutorial  
 * org.apache.felix.ipojo.distribution.maventutorial  
 * org.apache.felix.ipojo.distribution.quickstart  
 * org.apache.felix.ipojo.features  
 * org.apache.felix.ipojo.gogo  
  
 It's a bug fix release. The changelogs are below.  
  
 Staging repository:  
 https://repository.apache.org/content/repositories/orgapachefelix-1047/  
  
 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 1047 /tmp/felix-staging  
  
 Please vote to approve this release:  
 [ ] +1 Approve the release  
 [ ] -1 Veto the release (please provide specific comments)  
  
 This vote will be open for 72 hours (at least).  
  
 Regards,  
  
 Clement  
  
   
 Changelog of the runtime project (1.12.1):  
  
 ** Bug  
 * [FELIX-3836] - NPE when calling InstanceDescription.getDescription()  
 * [FELIX-4565] - Occasional ArrayIndexOutOfBoundException in iPOJO's  
 ProvidedServiceHandler  
 * [FELIX-4646] - @Context(Context.Source.INSTANCE) does not inject  
 bundle context  
 * [FELIX-4713] - Error in ProvidedServiceHandler.checkProvidedService  
 : only the first service is checked  
 * [FELIX-4715] - instance bundle context injection does not works  
 * [FELIX-4716] - Bundle org.apache.felix.ipojo physically contains  
 OSGi API classes  
 * [FELIX-4717] - Cannot use the stream API on injected collections  
 * [FELIX-4728] - InstanceManager concurrency issue  
  
 Changelog of the manipulator project (1.12.1):  
  
 ** Bug  
 * [FELIX-4612] - @PostRegistration is not being called  
 * [FELIX-4620] - Warning should be removed when @Configuration is used  
 * [FELIX-4668] - Can not use @Stereotype annotated annotation from  
 another bundle (unless its package is included or re-exported)  
 * [FELIX-4725] - Inner Class Manipulation uses the wrong 'access level'  
  
  
 --  
 Jean-Baptiste Onofré  
 jbono...@apache.org  
 http://blog.nanthrax.net  
 Talend - http://www.talend.com  
  


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

Re: [VOTE] Release of iPOJO Manipulator and Runtime 1.12.1

[Clement Escoffier]

+1,

Regards,

Clement

PS: 2 bindings votes missing, anyone ? 
On 21 décembre 2014 at 05:57:05, Jean-Baptiste Onofré (j...@nanthrax.net) wrote:

+1 (non binding)  

Regards  
JB  

On 12/20/2014 11:42 PM, Pierre De Rop wrote:  
 Hello Clement;  
  
 +1  
  
 regards  
 /Pierre  
  
 On Tue, Dec 16, 2014 at 3:20 PM, Clement Escoffier   
 clement.escoff...@gmail.com wrote:  
  
 Hi,  
  
 It's time to cut a release of the iPOJO manipulator (1.12.1) and runtime  
 (1.12.1). Both projects are containing several modules:  
  
 The org.apache.felix.ipojo.manipulator-project contains:  
 * bnd-ipojo-plugin  
 * maven-ipojo-plugin  
 * org.apache.felix.ipojo.annotations  
 * org.apache.felix.ipojo.ant  
 * org.apache.felix.ipojo.manipulator  
 * org.apache.felix.ipojo.manipulator.online  
  
 The org.apache.felix.ipojo.runtime-project contains:  
 * org.apache.felix.ipojo  
 * org.apache.felix.ipojo.api  
 * org.apache.felix.ipojo.composite  
 * org.apache.felix.ipojo.distribution.10mintutorial  
 * org.apache.felix.ipojo.distribution.maventutorial  
 * org.apache.felix.ipojo.distribution.quickstart  
 * org.apache.felix.ipojo.features  
 * org.apache.felix.ipojo.gogo  
  
 It's a bug fix release. The changelogs are below.  
  
 Staging repository:  
 https://repository.apache.org/content/repositories/orgapachefelix-1047/  
  
 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 1047 /tmp/felix-staging  
  
 Please vote to approve this release:  
 [ ] +1 Approve the release  
 [ ] -1 Veto the release (please provide specific comments)  
  
 This vote will be open for 72 hours (at least).  
  
 Regards,  
  
 Clement  
  
   
 Changelog of the runtime project (1.12.1):  
  
 ** Bug  
 * [FELIX-3836] - NPE when calling InstanceDescription.getDescription()  
 * [FELIX-4565] - Occasional ArrayIndexOutOfBoundException in iPOJO's  
 ProvidedServiceHandler  
 * [FELIX-4646] - @Context(Context.Source.INSTANCE) does not inject  
 bundle context  
 * [FELIX-4713] - Error in ProvidedServiceHandler.checkProvidedService  
 : only the first service is checked  
 * [FELIX-4715] - instance bundle context injection does not works  
 * [FELIX-4716] - Bundle org.apache.felix.ipojo physically contains  
 OSGi API classes  
 * [FELIX-4717] - Cannot use the stream API on injected collections  
 * [FELIX-4728] - InstanceManager concurrency issue  
  
 Changelog of the manipulator project (1.12.1):  
  
 ** Bug  
 * [FELIX-4612] - @PostRegistration is not being called  
 * [FELIX-4620] - Warning should be removed when @Configuration is used  
 * [FELIX-4668] - Can not use @Stereotype annotated annotation from  
 another bundle (unless its package is included or re-exported)  
 * [FELIX-4725] - Inner Class Manipulation uses the wrong 'access level'  
  

--  
Jean-Baptiste Onofré  
jbono...@apache.org  
http://blog.nanthrax.net  
Talend - http://www.talend.com  

[VOTE] Release of iPOJO Manipulator and Runtime 1.12.1

[Clement Escoffier]

Hi,

It's time to cut a release of the iPOJO manipulator (1.12.1) and runtime 
(1.12.1). Both projects are containing several modules:

The org.apache.felix.ipojo.manipulator-project contains:
* bnd-ipojo-plugin
* maven-ipojo-plugin
* org.apache.felix.ipojo.annotations
* org.apache.felix.ipojo.ant
* org.apache.felix.ipojo.manipulator
* org.apache.felix.ipojo.manipulator.online

The org.apache.felix.ipojo.runtime-project contains:
* org.apache.felix.ipojo
* org.apache.felix.ipojo.api
* org.apache.felix.ipojo.composite
* org.apache.felix.ipojo.distribution.10mintutorial
* org.apache.felix.ipojo.distribution.maventutorial
* org.apache.felix.ipojo.distribution.quickstart
* org.apache.felix.ipojo.features
* org.apache.felix.ipojo.gogo

It's a bug fix release. The changelogs are below.

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

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 1047 /tmp/felix-staging

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours (at least).

Regards,

Clement


Changelog of the runtime project (1.12.1):

** Bug
    * [FELIX-3836] - NPE when calling InstanceDescription.getDescription()
    * [FELIX-4565] - Occasional ArrayIndexOutOfBoundException in iPOJO's 
ProvidedServiceHandler
    * [FELIX-4646] - @Context(Context.Source.INSTANCE) does not inject bundle 
context
    * [FELIX-4713] - Error in ProvidedServiceHandler.checkProvidedService : 
only the first service is checked
    * [FELIX-4715] - instance bundle context injection does not works
    * [FELIX-4716] - Bundle org.apache.felix.ipojo physically contains OSGi API 
classes
    * [FELIX-4717] - Cannot use the stream API on injected collections
    * [FELIX-4728] - InstanceManager concurrency issue

Changelog of the manipulator project (1.12.1):

** Bug
    * [FELIX-4612] - @PostRegistration is not being called
    * [FELIX-4620] - Warning should be removed when @Configuration is used
    * [FELIX-4668] - Can not use @Stereotype annotated annotation from another 
bundle (unless its package is included or re-exported)
    * [FELIX-4725] - Inner Class Manipulation uses the wrong 'access level'

Re: [VOTE] Release Apache Felix Web Console Event Plugin 1.1.2

[Clement Escoffier]

Hi,

I can’t find your PGP public key in http://www.apache.org/dist/felix/KEYS. 
Could you update it, so we can check your release.
You can check the Appendix A of 
http://felix.apache.org/documentation/development/release-management-nexus.html 
to get the upload instruction.

Cheers,

Clement
On 16 décembre 2014 at 13:43:00, Valentin Valchev (v.valc...@prosyst.bg) wrote:

Call for a vote on Apache Felix Web Console Event Plugin 1.1.2  

Staging repository available at  

https://repository.apache.org/content/groups/staging/org/apache/felix/org.apache.felix.webconsole.plugins.event/1.1.2/
  

Release Notes - Felix - Version webconsole-event-plugin-1.1.2  

---  

** Bug  
* [FELIX-4573] - Web Console Event plugin might cease operation if Event 
property is null  
* [FELIX-4731] - Event plugin native2ascii plugin conflicts with Eclipse  
* [FELIX-4732] - Web Console event plugin is not compatible with OSGi/Minimum 
EE  

** New Feature  
* [FELIX-4499] - BundleEventConverter reports UNINSTALLED for UNRESOLVED events 
 
* [FELIX-4500] - EventListener should implement SynchronousBundleListener  


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 1046 /tmp/felix-staging  


Please vote to approve this release:  

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

This vote will be open for 72 hours.  


Best regards,  
Valentin Valchev  

--  

-  
Valentin Valchev · Lead Software Engineer  
ProSyst Labs EOOD  
1606 Sofia, Bulgaria · 48 Vladajska Str.  
Tel. +359 (0)2 952 35 81; Fax +359 (0)2 953 26 17  
http://www.prosyst.com · v.valc...@prosyst.bg  
-  
stay in touch with your product.  
-  

Re: [VOTE] Release Apache Felix Web Console Event Plugin 1.1.2

[Clement Escoffier]

Hi,


On 16 décembre 2014 at 16:34:42, Valentin Valchev (v.valc...@prosyst.bg) wrote:

Hello Clement,
Right, I didn't modified the file, but I was pointed to this FAQ:
http://people.apache.org/~henkp/checker/faq.html#3

please note that KEYS files are deprecated in that they could/should be 
generated
from the info maintained in id.apache.org.
Oh, right, just got your key 
(http://people.apache.org/keys/committer/vvalchev.asc) and was able to verify 
the releases. 



So I'm not sure if I should manually update the file or wait for some scheduled 
operation?
So, no problem at all. As soon as there is a way to retrieve your key, it’s 
fine. 

Regards,

Clement



Regards,
Valentin


On 16/12/2014 16:28, Clement Escoffier wrote:
Hi,

I can’t find your PGP public key in http://www.apache.org/dist/felix/KEYS. 
Could you update it, so we can check your release.
You can check the Appendix A of 
http://felix.apache.org/documentation/development/release-management-nexus.html 
to get the upload instruction.

Cheers,

Clement
On 16 décembre 2014 at 13:43:00, Valentin Valchev (v.valc...@prosyst.bg) wrote:

Call for a vote on Apache Felix Web Console Event Plugin 1.1.2   

Staging repository available at   

https://repository.apache.org/content/groups/staging/org/apache/felix/org.apache.felix.webconsole.plugins.event/1.1.2/
   

Release Notes - Felix - Version webconsole-event-plugin-1.1.2   

---   

** Bug   
* [FELIX-4573] - Web Console Event plugin might cease operation if Event 
property is null   
* [FELIX-4731] - Event plugin native2ascii plugin conflicts with Eclipse   
* [FELIX-4732] - Web Console event plugin is not compatible with OSGi/Minimum 
EE   

** New Feature   
* [FELIX-4499] - BundleEventConverter reports UNINSTALLED for UNRESOLVED events 
  
* [FELIX-4500] - EventListener should implement SynchronousBundleListener   


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 1046 /tmp/felix-staging   


Please vote to approve this release:   

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

This vote will be open for 72 hours.   


Best regards,   
Valentin Valchev   

--   

-   
Valentin Valchev · Lead Software Engineer   
ProSyst Labs EOOD   
1606 Sofia, Bulgaria · 48 Vladajska Str.   
Tel. +359 (0)2 952 35 81; Fax +359 (0)2 953 26 17   
http://www.prosyst.com · v.valc...@prosyst.bg   
-   
stay in touch with your product.   
-   




--  

-
Valentin Valchev · Lead Software Engineer
ProSyst Labs EOOD
1606 Sofia, Bulgaria · 48 Vladajska Str.
Tel. +359 (0)2 952 35 81; Fax +359 (0)2 953 26 17
http://www.prosyst.com · v.valc...@prosyst.bg
-
stay in touch with your product.
-

Re: [VOTE] Release Apache Felix Web Console UPnP Plugin 1.0.4

[Clement Escoffier]

+1,

Regards,

Clement

On 16 décembre 2014 at 13:41:57, Valentin Valchev (v.valc...@prosyst.bg) wrote:

Call for a vote on Apache Felix Web Console UPnP Plugin 1.0.4  

Staging repository available at  
https://repository.apache.org/content/groups/staging/org/apache/felix/org.apache.felix.webconsole.plugins.upnp/1.0.4/
  

Release Notes - Felix - Version webconsole-upnp-plugin-1.0.4  

---  

** Bug  
* [FELIX-3589] - The service id link for UPnP devices doesn't work  
* [FELIX-3595] - NPE in ControlServlet.addingService  
* [FELIX-3669] - NPE in ControlServlet.deviceToJSON  
* [FELIX-4012] - Sometimes the UPnP plugin fails to start due to  
device being removed from network  
* [FELIX-4013] - Incorrect usage of ServiceTracker.size() in UPnP Plugin  
* [FELIX-4032] - UPnP Plugin small refactoring  
* [FELIX-4560] - Unsynchonized access to map can cause infinite loop  
in UPnP web console plugin  
* [FELIX-4733] - UPnP plugin native2ascii plugin conflicts with  
Eclipse m2e  


** Improvement  
* [FELIX-3861] - Set felix.webconsole.category on Web Console plugins  
* [FELIX-4016] - Provide more meta data to the UPnP action arguments  


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 1046 /tmp/felix-staging  


Please vote to approve this release:  

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

This vote will be open for 72 hours.  


Best regards,  
Valentin Valchev  

--  

-  
Valentin Valchev · Lead Software Engineer  
ProSyst Labs EOOD  
1606 Sofia, Bulgaria · 48 Vladajska Str.  
Tel. +359 (0)2 952 35 81; Fax +359 (0)2 953 26 17  
http://www.prosyst.com · v.valc...@prosyst.bg  
-  
stay in touch with your product.  
-  

Re: [VOTE] Release Apache Felix Web Console User Admin Plugin 1.0.0

[Clement Escoffier]

+1,

Regards,

Clement


On 16 décembre 2014 at 13:42:07, Valentin Valchev (v.valc...@prosyst.bg) wrote:

Call for a vote on Apache Felix Web Console User Admin Plugin 1.0.0  

Staging repository available at  
https://repository.apache.org/content/groups/staging/org/apache/felix/org.apache.felix.webconsole.plugins.useradmin/1.0.0/
  

Release Notes - Felix - Version webconsole-useradmin-plugin-1.0.0  

---  

** Bug  
* [FELIX-3633] - User Admin Plugin - no German translation  
* [FELIX-3634] - User Admin Plugin - no Russian translation  

** Improvement  
* [FELIX-2254] - User Admin Plugin  
* [FELIX-3861] - Set felix.webconsole.category on Web Console plugins  
* [FELIX-4703] - User Admin plugin should use all available to the  
JVM crypto algorithms  


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 1046 /tmp/felix-staging  


Please vote to approve this release:  

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

This vote will be open for 72 hours.  


Best regards,  
Valentin Valchev  

--  

-  
Valentin Valchev · Lead Software Engineer  
ProSyst Labs EOOD  
1606 Sofia, Bulgaria · 48 Vladajska Str.  
Tel. +359 (0)2 952 35 81; Fax +359 (0)2 953 26 17  
http://www.prosyst.com · v.valc...@prosyst.bg  
-  
stay in touch with your product.  
-  

Re: [VOTE] Release Apache Felix Web Console Event Plugin 1.1.2

[Clement Escoffier]

+1,

Regards,

Clement

On 16 décembre 2014 at 13:43:00, Valentin Valchev (v.valc...@prosyst.bg) wrote:

Call for a vote on Apache Felix Web Console Event Plugin 1.1.2  

Staging repository available at  

https://repository.apache.org/content/groups/staging/org/apache/felix/org.apache.felix.webconsole.plugins.event/1.1.2/
  

Release Notes - Felix - Version webconsole-event-plugin-1.1.2  

---  

** Bug  
* [FELIX-4573] - Web Console Event plugin might cease operation if Event 
property is null  
* [FELIX-4731] - Event plugin native2ascii plugin conflicts with Eclipse  
* [FELIX-4732] - Web Console event plugin is not compatible with OSGi/Minimum 
EE  

** New Feature  
* [FELIX-4499] - BundleEventConverter reports UNINSTALLED for UNRESOLVED events 
 
* [FELIX-4500] - EventListener should implement SynchronousBundleListener  


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 1046 /tmp/felix-staging  


Please vote to approve this release:  

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

This vote will be open for 72 hours.  


Best regards,  
Valentin Valchev  

--  

-  
Valentin Valchev · Lead Software Engineer  
ProSyst Labs EOOD  
1606 Sofia, Bulgaria · 48 Vladajska Str.  
Tel. +359 (0)2 952 35 81; Fax +359 (0)2 953 26 17  
http://www.prosyst.com · v.valc...@prosyst.bg  
-  
stay in touch with your product.  
-  

[jira] [Assigned] (FELIX-4728) InstanceManager concurrency issue

[Clement Escoffier (JIRA)]

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

Clement Escoffier reassigned FELIX-4728:


Assignee: Clement Escoffier

 InstanceManager concurrency issue
 -

 Key: FELIX-4728
 URL: https://issues.apache.org/jira/browse/FELIX-4728
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Affects Versions: ipojo-runtime-1.11.2
Reporter: Niels Beekman
Assignee: Clement Escoffier

 We observed a race condition in InstanceManager.onEntry. This is caused by 
 improperly synchronized access on a HashMap. Unlike reported in FELIX-3500, 
 we did not get an exception, but high cpu usage due to the data race. See the 
 relevant thread stacks in the comments.



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

[jira] [Commented] (FELIX-4728) InstanceManager concurrency issue

[Clement Escoffier (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14243815#comment-14243815
 ] 

Clement Escoffier commented on FELIX-4728:
--

Do you have a way to reproduce it ?

 InstanceManager concurrency issue
 -

 Key: FELIX-4728
 URL: https://issues.apache.org/jira/browse/FELIX-4728
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Affects Versions: ipojo-runtime-1.11.2
Reporter: Niels Beekman
Assignee: Clement Escoffier

 We observed a race condition in InstanceManager.onEntry. This is caused by 
 improperly synchronized access on a HashMap. Unlike reported in FELIX-3500, 
 we did not get an exception, but high cpu usage due to the data race. See the 
 relevant thread stacks in the comments.



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

Re: [VOTE] Release Apache Felix Web Console 4.2.4

[Clement Escoffier]

+1,

Regards,

Clement

On 10 décembre 2014 at 14:58:11, Carsten Ziegeler (cziege...@apache.org) wrote:

+1  

Carsten  

Am 09.12.14 um 16:16 schrieb Valentin Valchev:  
 Call for a vote on Apache Felix Web Console 4.2.4  
  
 Staging repository available at  
  
 https://repository.apache.org/content/groups/staging/org/apache/felix/org.apache.felix.webconsole/4.2.4/
   
  
 Release Notes - Felix - Version webconsole-4.2.4  
  
 ** Bug  
 * [FELIX-3817] - Form parameters might clash with configuration  
 parameters  
 * [FELIX-4558] - Web Console Service plugin doesn't list properties  
 with value 0  
 * [FELIX-4562] - Web Console License plugin fails to load files  
 * [FELIX-4572] - Web Console may cause NPE on refresh packages  
 * [FELIX-4610] - WebConsole doesn't start with Java Security enabled  
 * [FELIX-4652] - Security problem with  
 AbstractWebConsolePlugin.spoolResource  
 * [FELIX-4660] - Security problem in WebConsoleUtil.getParameter()  
 method  
 * [FELIX-4662] - WebConsole Xdialog javascript function is not  
 working correctly  
  
 ** Improvement  
 * [FELIX-3848] - Differentiate between unbound and new configuration  
 * [FELIX-4711] - Web Console: False AJAX error displayed on deleting  
 or unbinding config  
  
  
 Please review and vote !  
  
 Best regards,  
 Valentin Valchev  
  


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

[jira] [Created] (FELIX-4725) Inner Class Manipulation uses the wrong 'access level'

[Clement Escoffier (JIRA)]

Clement Escoffier created FELIX-4725:


 Summary: Inner Class Manipulation uses the wrong 'access level'
 Key: FELIX-4725
 URL: https://issues.apache.org/jira/browse/FELIX-4725
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Affects Versions: ipojo-manipulator-1.12.0
Reporter: Clement Escoffier
Assignee: Clement Escoffier
 Fix For: ipojo-manipulator-1.12.1


When the manipulator manipulates inner classes, the copied method are reusing 
the same access level than the initial (original method). For instance 
{code}public void foo(){code}  is replaced by {code}public void __foo(){code}. 
However, reusing the same access level leads to a (missing) mediation on the 
invoke instruction we need to use to invoke this method. Despite this is 
working on traditional JVM (Oracle, HotSpot...), it fails on Dalvik. 

The fix is straightforward. Copied methods should be private:

{code}private void __foo(){code}

Thus, we just need to use the {code}INVOKE_SPECIAL{code} instruction.



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

[jira] [Commented] (FELIX-3836) NPE when calling InstanceDescription.getDescription() ; // HandlerDescription is missing for org.apache.felix.ipojo.handlers.event:subscriber handler

[Clement Escoffier (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-3836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14240772#comment-14240772
 ] 

Clement Escoffier commented on FELIX-3836:
--

[~sauthieg] is right. Fixing it right now.

 NPE when calling InstanceDescription.getDescription() ; //  
 HandlerDescription is missing for 
 org.apache.felix.ipojo.handlers.event:subscriber handler
 --

 Key: FELIX-3836
 URL: https://issues.apache.org/jira/browse/FELIX-3836
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Reporter: Jérémy Cazaux
Assignee: Clement Escoffier
 Fix For: ipojo-eventadmin-handler-1.8.2

 Attachments: bug.png


 java.lang.NullPointerException
   at 
 org.apache.felix.ipojo.architecture.InstanceDescription.getDescription(InstanceDescription.java:164)
   at 
 org.apache.felix.ipojo.PrimitiveInstanceDescription.getDescription(PrimitiveInstanceDescription.java:165)
 NPE when executing this line in the InstanceDescription :
 instance.addElement(m_handlers[i].getHandlerInfo()); 
 My component has 4 handlers : [org.ow2.jonas.ipojo.interceptor:interceptor, 
 org.apache.felix.ipojo:provides, 
 org.apache.felix.ipojo.handlers.event:subscriber, 
 org.apache.felix.ipojo:architecture]
 cazauxj@jonas$ inspect service capability 103
 JOnAS :: Services :: JOnAS report :: Extensions :: Deployables (103) provides 
 services:
 ---
 component.class = 
 org.ow2.jonas.report.extensions.deployables.internal.DeployablesReportExtension
 component.description = factory name=DeployablesReportExtension 
 bundle=103 state=valid 
 implementation-class=org.ow2.jonas.report.extensions.deployables.internal.DeployablesReportExtension
 requiredhandlers list=[org.ow2.jonas.ipojo.interceptor:interceptor, 
 org.apache.felix.ipojo:provides, 
 org.apache.felix.ipojo.handlers.event:subscriber, 
 org.apache.felix.ipojo:architecture]
 missinghandlers list=[]
 provides specification=org.ow2.jonas.report.api.IReportExtension
 property name=namespace type=java.lang.String 
 value=http://jonas.ow2.org/report/deployables/1.0;
 property name=event.topics type=java.util.Dictionary value={}
 property name=event.filter type=java.util.Dictionary value={}
 inherited interfaces=[org.ow2.jonas.report.api.IReportExtension] 
 superclasses=[]
 component.properties = 
 [Lorg.apache.felix.ipojo.architecture.PropertyDescription;@19c59085
 component.providedServiceSpecifications = 
 org.ow2.jonas.report.api.IReportExtension
 factory.name = DeployablesReportExtension
 factory.state = 1
 objectClass = org.apache.felix.ipojo.Factory, 
 org.osgi.service.cm.ManagedServiceFactory
 service.id = 299
 service.pid = DeployablesReportExtension
 
 factory.name = DeployablesReportExtension
 instance.name = DeployablesReportExtension-0
 namespace = http://jonas.ow2.org/report/deployables/1.0
 objectClass = org.ow2.jonas.report.api.IReportExtension
 service.id = 303
 When debugging, it looks like that the array of HandlerDescription does 
 contain the correct number of element (4) but the element with index 2 is 
 NULL. So the HandlerDescription is missing for 
 org.apache.felix.ipojo.handlers.event:subscriber handler. However, all 
 HandlerManager  are available from the InstanceManager (the HandlerManager 
 associated to the subscriber handler is not null). I have attached a picture 
 to illustrate this.



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

[jira] [Resolved] (FELIX-3836) NPE when calling InstanceDescription.getDescription() ; // HandlerDescription is missing for org.apache.felix.ipojo.handlers.event:subscriber handler

[Clement Escoffier (JIRA)]

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

Clement Escoffier resolved FELIX-3836.
--
   Resolution: Fixed
Fix Version/s: (was: ipojo-eventadmin-handler-1.8.2)
   ipojo-runtime-1.12.1

Fixed in trunk.

 NPE when calling InstanceDescription.getDescription() ; //  
 HandlerDescription is missing for 
 org.apache.felix.ipojo.handlers.event:subscriber handler
 --

 Key: FELIX-3836
 URL: https://issues.apache.org/jira/browse/FELIX-3836
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Reporter: Jérémy Cazaux
Assignee: Clement Escoffier
 Fix For: ipojo-runtime-1.12.1

 Attachments: bug.png


 java.lang.NullPointerException
   at 
 org.apache.felix.ipojo.architecture.InstanceDescription.getDescription(InstanceDescription.java:164)
   at 
 org.apache.felix.ipojo.PrimitiveInstanceDescription.getDescription(PrimitiveInstanceDescription.java:165)
 NPE when executing this line in the InstanceDescription :
 instance.addElement(m_handlers[i].getHandlerInfo()); 
 My component has 4 handlers : [org.ow2.jonas.ipojo.interceptor:interceptor, 
 org.apache.felix.ipojo:provides, 
 org.apache.felix.ipojo.handlers.event:subscriber, 
 org.apache.felix.ipojo:architecture]
 cazauxj@jonas$ inspect service capability 103
 JOnAS :: Services :: JOnAS report :: Extensions :: Deployables (103) provides 
 services:
 ---
 component.class = 
 org.ow2.jonas.report.extensions.deployables.internal.DeployablesReportExtension
 component.description = factory name=DeployablesReportExtension 
 bundle=103 state=valid 
 implementation-class=org.ow2.jonas.report.extensions.deployables.internal.DeployablesReportExtension
 requiredhandlers list=[org.ow2.jonas.ipojo.interceptor:interceptor, 
 org.apache.felix.ipojo:provides, 
 org.apache.felix.ipojo.handlers.event:subscriber, 
 org.apache.felix.ipojo:architecture]
 missinghandlers list=[]
 provides specification=org.ow2.jonas.report.api.IReportExtension
 property name=namespace type=java.lang.String 
 value=http://jonas.ow2.org/report/deployables/1.0;
 property name=event.topics type=java.util.Dictionary value={}
 property name=event.filter type=java.util.Dictionary value={}
 inherited interfaces=[org.ow2.jonas.report.api.IReportExtension] 
 superclasses=[]
 component.properties = 
 [Lorg.apache.felix.ipojo.architecture.PropertyDescription;@19c59085
 component.providedServiceSpecifications = 
 org.ow2.jonas.report.api.IReportExtension
 factory.name = DeployablesReportExtension
 factory.state = 1
 objectClass = org.apache.felix.ipojo.Factory, 
 org.osgi.service.cm.ManagedServiceFactory
 service.id = 299
 service.pid = DeployablesReportExtension
 
 factory.name = DeployablesReportExtension
 instance.name = DeployablesReportExtension-0
 namespace = http://jonas.ow2.org/report/deployables/1.0
 objectClass = org.ow2.jonas.report.api.IReportExtension
 service.id = 303
 When debugging, it looks like that the array of HandlerDescription does 
 contain the correct number of element (4) but the element with index 2 is 
 NULL. So the HandlerDescription is missing for 
 org.apache.felix.ipojo.handlers.event:subscriber handler. However, all 
 HandlerManager  are available from the InstanceManager (the HandlerManager 
 associated to the subscriber handler is not null). I have attached a picture 
 to illustrate this.



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

[jira] [Updated] (FELIX-4716) Bundle org.apache.felix.ipojo physically contains OSGi API classes

[Clement Escoffier (JIRA)]

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

Clement Escoffier updated FELIX-4716:
-
Fix Version/s: ipojo-runtime-1.12.1

 Bundle org.apache.felix.ipojo physically contains OSGi API classes
 --

 Key: FELIX-4716
 URL: https://issues.apache.org/jira/browse/FELIX-4716
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Affects Versions: ipojo-runtime-1.12.0
 Environment: ubuntu 14, karaf
Reporter: Karl Leopold
Assignee: Clement Escoffier
 Fix For: ipojo-runtime-1.12.1


 The _org.apache.felix.ipojo_ bundle imports, exports and physically contains 
 interface-classes of packages _org.osgi.services.cm_ and 
 _org.osgi.services.log_, both with version 1.3.
 I'm running ipojo in karaf 3.0.2. There, these osgi-packages also exists, 
 just in another version.
 Sometimes it happens that a bundle of mine, which has a package-dependency on 
 _org.osgi.services.cm_ is bound to the ipojo-version instead of the one of 
 felix/karaf. Now, the bundle is resolved, but the service dependency on the 
 ConfigurationAdmin can never be resolved, because the implementation is 
 incompatible to the imported interface.
 I can fix that, if I play around with the bundle start levels.
 Anyway, I think it's a bug in iPOJO, because it should not inline any OSGi 
 API packages.



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

[jira] [Resolved] (FELIX-4716) Bundle org.apache.felix.ipojo physically contains OSGi API classes

[Clement Escoffier (JIRA)]

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

Clement Escoffier resolved FELIX-4716.
--
Resolution: Fixed

Fixed in trunk by creating a 'bare' bundle that does not include the classes 
from the compendium.

 Bundle org.apache.felix.ipojo physically contains OSGi API classes
 --

 Key: FELIX-4716
 URL: https://issues.apache.org/jira/browse/FELIX-4716
 Project: Felix
  Issue Type: Bug
  Components: iPOJO
Affects Versions: ipojo-runtime-1.12.0
 Environment: ubuntu 14, karaf
Reporter: Karl Leopold
Assignee: Clement Escoffier

 The _org.apache.felix.ipojo_ bundle imports, exports and physically contains 
 interface-classes of packages _org.osgi.services.cm_ and 
 _org.osgi.services.log_, both with version 1.3.
 I'm running ipojo in karaf 3.0.2. There, these osgi-packages also exists, 
 just in another version.
 Sometimes it happens that a bundle of mine, which has a package-dependency on 
 _org.osgi.services.cm_ is bound to the ipojo-version instead of the one of 
 felix/karaf. Now, the bundle is resolved, but the service dependency on the 
 ConfigurationAdmin can never be resolved, because the implementation is 
 incompatible to the imported interface.
 I can fix that, if I play around with the bundle start levels.
 Anyway, I think it's a bug in iPOJO, because it should not inline any OSGi 
 API packages.



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