Am 13.01.2016 um 23:23 schrieb Gary Gregory: > On Wed, Jan 13, 2016 at 11:43 AM, Norbert Kiesel <nkie...@metricstream.com> > wrote: > >>> Hi Norbert, >>> >>> due to lack of time, I recently only focused on Configuration 2.0 and >>> intended to let the 1.x series slowly die. Therefore, my priority is to >>> get 2.0 ready and push the release out. If I understand correctly, the >>> implementation in 2.0 satisfies your needs, except that some generic >>> types still have to be adapted (passing a Map<String, ?> to the >>> constructor rather than a Map<String, Object>). Is this correct? >> >> Yes, 2.0 satifies our need (even the current version, though I agree with >> your >> suggested type change). >> >>> >>> Patches for a 1.11 fix release are of course welcome, but I cannot >>> promise that I will be able to actually do a 1.11 release in the near >>> future. If somebody else steps up and volunteers to do this, this would >>> of course be another story. >> >> Understood. Really only trying to help here, not to produce more work for >> you >> or the community. We will simply stick with 1.9 until 2.0 is out. >> >>> >>> ... >>> >>>> >>>> The way out for a potential 1.11 would be to override more of the the >>>> AbstractMap API to make that a mutable map backed by the Properties >> object. Do >>>> you want me to provide a patch along these lines? >>> >>> This approach would probably work, but it seems like unnecessary >>> complexity. Accessing the passed in Properties object directly - as done >>> in 2.0 - is more straight-forward, isn't it? >> >> This would break backwards compatibility: 1.x promises to actively weed out >> entries with non-string keys from the passed Properties object. So anyone >> depending on this would be in for a surprise. 2.0 instead warns callers >> that they have to >> ensure that they don't pass such entries. This makes life simpler for the >> implementation >> and is IMHO very good for an API-breaking 2.x but not for 1.x. >> >> I don't want to waste anyone's time here, so unless you tell me that you >> want to see the >> revised patch or otherwise actively engage, I will shut up on this topic. >> Was a pleasure to >> talk to you and thanks for your community work! >> > > Thank you for your understanding and help. We are all volunteers short on > time. > > You might want to submit a 1.x patch in case an RM decides to push out a > release. That would grease the wheels a bit. Just in case... > > Gary
Full agreement to what Gary said. Many thanks for your support and constructive feedback, Norbert! Oliver > >> >> </nk> >> >> Confidentiality Notice:This email and any files transmitted with it are >> confidential and intended solely for the use of the individual or entity to >> whom they are addressed. This message contains confidential information and >> is intended only for the individual named. If you are not the named >> addressee you should not disseminate, distribute or copy this e-mail. >> Please notify the sender immediately by e-mail if you have received this >> e-mail by mistake and delete this e-mail from your system. If you are not >> the intended recipient you are notified that disclosing, copying, >> distributing or taking any action in reliance on the contents of this >> information is strictly prohibited >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >> For additional commands, e-mail: user-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
