commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [configuration] 1.10 regression / backwards-incompatible change in MapConfiguration.convertPropertiesToMap ?
Date Wed, 13 Jan 2016 22:23:44 GMT
On Wed, Jan 13, 2016 at 11:43 AM, Norbert Kiesel <nkiesel@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

>
> </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-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message