adaptTo() 2017 - slides online
the slides of the adaptTo() 2017 conference in berlin are now online - 24 talks plus lightning talks, 200 participants. you find the slides and code samples here: https://adapt.to/2017/schedule and some images... (more to follow) https://adapt.to/2017/en/conference/gallery.html this year we have also video recordings in high quality, published at youtube. the videos are linked in the talk page of the schedule as well (currently only from day 1 available - more to come soon). stefan
[VOTE] Release Apache Felix Metatype 1.1.6
I would like to call a vote on the following subproject releases: Apache Felix Metatype 1.1.6 http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.metatype-1.1.6/changelog.txt Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-1201/ 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 1201 /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 Metatype 1.1.6
+1 Carsten Ziegeler wrote > I would like to call a vote on the following subproject releases: > > Apache Felix Metatype 1.1.6 > http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.metatype-1.1.6/changelog.txt > > > Staging repositories: > https://repository.apache.org/content/repositories/orgapachefelix-1201/ > > 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 1201 /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 Metatype 1.1.6
+1 (binding) Regards JB On 09/28/2017 08:37 AM, Carsten Ziegeler wrote: I would like to call a vote on the following subproject releases: Apache Felix Metatype 1.1.6 http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.metatype-1.1.6/changelog.txt Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-1201/ 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 1201 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Regards Carsten -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: [ConfigAdmin] Changing handling of persistence managers
For configadmin 1.9 (R7 branch) I've implemented the following changes now: Only one PM is used. If no configuration (through framework prop) is provided the current file PM is used. The file PM is registered as a service with the name "file" If a config is provided, this is the name of the PM (service property) and only if that service is available, the CM is activated/registered. Service Ranking is handled in this case as well and the one with the specified name and highest ranking is used Regards Carsten Carsten Ziegeler wrote > Hi > > the current way of handling persistence managers in our config admin > implementation is not 100% reliable and ultimately can lead to confusion > and wrong results (see FELIX-5693 and FELIX-5685). > > Now, I've suggested an improvement in FELIX-5693 which should solve the > problem and provides a 100% compatible solution. However while > implementing this, I found out that being 100% compatible makes the code > really ugly. So I'm wondering now if we really need to go that far. > > Today, one can register as many persistence managers and *all* of them > are picked up and used ordered by service ranking. As the file PM is > registered by default, there is always one and this one is used from the > beginning. Some more details are in those issues. > > I think we should change this to: > - only one PM is used > - if no configuration (through framework prop) is provided the current > file PM is used > - the file PM is not registered as a service anymore (there is no use in > doing so) > - if a config is provided, this is the name of the PM (service property) > and only if that service is available, the CM is activated/registered > > This simplifies the config of the CM, the handling of PMs and also the > code. The downside is that if you want to use a custom PM it requires > you to set a configuration. As this is usually not the common use case I > think thats fine. > > If we want to be 100% compatible, then we have the ugly handling by > default and if you want to restrict this to just the file PM you have to > provide a config option. Which ultimately every user of our bundle > should do (unless a custom PM should be used) > > WDYT? > > Regards > Carsten > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
