[lang] 2.2 update

[Henri Yandell <fl...@gmail.com>]

14 issues lined up for completion before 2.2 happens. Sorry if any of
these are just repeats of last time:

36666 	[lang] EnumUtils.getEnum() doesn't work well in 1.5
33965 	[lang] Can't XMLDecode an Enum
    These two might be related. Not looked at them much otherwise.

37499 	[lang] parseDate with TimeZone
   Can't see a non-cheesy way to implement this request. I feel that
the user should be the one doing hacks like this so would like to go
WONTFIX.

37690 	[lang] RandomStringUtils.random() family of methods creat...
    Don't know if anyone understands what private high surrogates are
etc. I'm not sure if I should be ignoring those in the fix or not.
Otherwise, seems fixable though I've not tested my idea out yet.

39254 	[lang] Expose DateIterator or add DateUtils.iterator(star...
    Do we want to expose this, or deprecate to remove in 3.0? Anyone
know what the use case was for these methods?

36061 	[lang] ToStringBuilder throws StackOverflowError when an ...
    Would appreciate if someone else could take a look at this.
Definitely a bug, but the fix reworks the source quite a lot, which
makes me uncomfortable and I'd appreciate a second opinion if someone
who knows this source has time. Also it then fails a test in
ArrayUtils so need to dig into that.

36873 	[lang] Extending VariableFormatter to use FormatPatterns
    Still in discussion on mailing list. Need a resolution.

36925 	[lang] Using ReflectionToStringBuilder and excluding secu...
     Bit worrying. Seems quite like the bugs 39398 and 39315 which
added the same to different classes. Are the changes in sync? Apart
from that, looks like this issue is ready to be resolved.

36584 	[lang] adding a StringUtils.replace method that takes an ...
    Not feeling too attracted to adding this method.

39167 	[lang] escapeXML() -> Not escaping low characters
38210 	[lang] StringEscaper.escapeXml() escapes characters > 0x7f
    Need to decide on these two escaping ones. Do we change our
behaviour? There was a bit of discussion on -user about this, Gary
said after reading the spec:

"So, 'low' or 'high' characters should not be escaped.

All of this leads me to think that we should deprecate escapeXml and
create: escapeXmlElementContent(String) and
escapeXmlAttributeContents(String, char) where the char denotes which
quote character to escape."

Not escaping low characters makes sense to me. I can't see any way we
should be escaping newlines, tabs etc in general. Maybe we could only
be escaping particular characters, or only when in quotes, but in
general this seems like a fuzzy area to be drawing lines in the sand.

For high characters, it does sound like we shouldn't be escaping the
characters and that one should be fixed.

Not looked at (recently):

36512 	[lang] Enhanced Class.forName version
38401 	[lang] DurationFormatUtils.formatPeriod() returns the wro...
37243 	[lang] DateUtils.truncate method is buggy when dealing wi...


Any thoughts are very appreciated,

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [lang] 2.2 update

[Henri Yandell <fl...@gmail.com>]

On 5/2/06, Henri Yandell <fl...@gmail.com> wrote:

> 39167   [lang] escapeXML() -> Not escaping low characters
> 38210   [lang] StringEscaper.escapeXml() escapes characters > 0x7f
>     Need to decide on these two escaping ones. Do we change our
> behaviour? There was a bit of discussion on -user about this, Gary
> said after reading the spec:

FYI:

http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200604.mbox/%3c19B78354A4AA3E4287384F3D30933F88B381A0@MAIL1.seagull.nl%3e

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org