[jira] [Updated] (LOGGING-157) Fix javadoc 1.8 errors and some warnings
[ https://issues.apache.org/jira/browse/LOGGING-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LOGGING-157: - Summary: Fix javadoc 1.8 errors and some warnings (was: FIx javadoc 1.8 errors and some warnings) > Fix javadoc 1.8 errors and some warnings > > > Key: LOGGING-157 > URL: https://issues.apache.org/jira/browse/LOGGING-157 > Project: Commons Logging > Issue Type: Bug >Reporter: Ville Skyttä >Priority: Minor > Labels: patch > Attachments: 0001-Fix-Javadoc-1.8-errors-and-some-warnings.patch > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (EMAIL-136) Fix Javadoc 1.8 errors
[
https://issues.apache.org/jira/browse/EMAIL-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved EMAIL-136.
Resolution: Fixed
Fix Version/s: 1.4
Assignee: Gary Gregory
{noformat}
commit -m "[EMAIL-136] Fix Javadoc 1.8 errors."
C:/vcs/svn/apache/commons/trunks-proper/email/src/main/java/org/apache/commons/mail/ImageHtmlEmail.java
C:/vcs/svn/apache/commons/trunks-proper/email/src/changes/changes.xml
C:/vcs/svn/apache/commons/trunks-proper/email/src/main/java/org/apache/commons/mail/HtmlEmail.java
C:/vcs/svn/apache/commons/trunks-proper/email/src/main/java/org/apache/commons/mail/Email.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/email/src/changes/changes.xml
Sending
C:/vcs/svn/apache/commons/trunks-proper/email/src/main/java/org/apache/commons/mail/Email.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/email/src/main/java/org/apache/commons/mail/HtmlEmail.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/email/src/main/java/org/apache/commons/mail/ImageHtmlEmail.java
Transmitting file data ...
Committed revision 1563555.
{noformat}
> Fix Javadoc 1.8 errors
> --
>
> Key: EMAIL-136
> URL: https://issues.apache.org/jira/browse/EMAIL-136
> Project: Commons Email
> Issue Type: Bug
>Reporter: Ville Skyttä
>Assignee: Gary Gregory
>Priority: Minor
> Labels: patch
> Fix For: 1.4
>
> Attachments: 0001-Fix-Javadoc-1.8-errors.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (EMAIL-136) Fix Javadoc 1.8 errors
[ https://issues.apache.org/jira/browse/EMAIL-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated EMAIL-136: --- Summary: Fix Javadoc 1.8 errors (was: Fix javadoc 1.8 errors) > Fix Javadoc 1.8 errors > -- > > Key: EMAIL-136 > URL: https://issues.apache.org/jira/browse/EMAIL-136 > Project: Commons Email > Issue Type: Bug >Reporter: Ville Skyttä >Priority: Minor > Labels: patch > Fix For: 1.4 > > Attachments: 0001-Fix-Javadoc-1.8-errors.patch > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (EMAIL-136) Fix javadoc 1.8 errors
[ https://issues.apache.org/jira/browse/EMAIL-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated EMAIL-136: --- Summary: Fix javadoc 1.8 errors (was: FIx javadoc 1.8 errors) > Fix javadoc 1.8 errors > -- > > Key: EMAIL-136 > URL: https://issues.apache.org/jira/browse/EMAIL-136 > Project: Commons Email > Issue Type: Bug >Reporter: Ville Skyttä >Priority: Minor > Labels: patch > Attachments: 0001-Fix-Javadoc-1.8-errors.patch > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CONFIGURATION-565) Add a getEncryptedString method in the Configuration interface
[
https://issues.apache.org/jira/browse/CONFIGURATION-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petar Tahchiev updated CONFIGURATION-565:
-
Description:
Hi guys,
it would be really awesome if the {{Configuration}} could be created with a
passphrase (another constructor which accepts a string, let's say
'mypassphrase') and then you also add a method in the interface (let's say
getEncodedString('database.password')) so we could have encoded properties in
our properties files. Internally the method just needs to delegate to jasypt's
{{StandardPBEStringEncryptor}} for instance
{code}
StandardPBEStringEncryptor encryptor = new StandardPBEStringEncryptor();
encryptor.setPassword("mypassphrase");
encryptor.decrypt("database.password");
{code}
decrypt the value and then return the decrypted value. This will allow for more
secure property files.
was:
Hi guys,
it would be really awesome if the {{Configuration}} could be created with a
passphrase (let's say 'mypassphrase') and then you also add a method in the
interface (let's say getEncodedString('database.password')) so we could have
encoded properties in our properties files. Internally the method just needs to
delegate to jasypt's {{StandardPBEStringEncryptor}} for instance
{code}
StandardPBEStringEncryptor encryptor = new StandardPBEStringEncryptor();
encryptor.setPassword("mypassphrase");
encryptor.decrypt("database.password");
{code}
decrypt the value and then return the decrypted value. This will allow for more
secure property files.
> Add a getEncryptedString method in the Configuration interface
> --
>
> Key: CONFIGURATION-565
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-565
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Expression engine
>Affects Versions: 2.x
>Reporter: Petar Tahchiev
>
> Hi guys,
> it would be really awesome if the {{Configuration}} could be created with a
> passphrase (another constructor which accepts a string, let's say
> 'mypassphrase') and then you also add a method in the interface (let's say
> getEncodedString('database.password')) so we could have encoded properties in
> our properties files. Internally the method just needs to delegate to
> jasypt's {{StandardPBEStringEncryptor}} for instance
> {code}
> StandardPBEStringEncryptor encryptor = new StandardPBEStringEncryptor();
> encryptor.setPassword("mypassphrase");
> encryptor.decrypt("database.password");
> {code}
> decrypt the value and then return the decrypted value. This will allow for
> more secure property files.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (CONFIGURATION-565) Add a getEncryptedString method in the Configuration interface
Petar Tahchiev created CONFIGURATION-565:
Summary: Add a getEncryptedString method in the Configuration
interface
Key: CONFIGURATION-565
URL: https://issues.apache.org/jira/browse/CONFIGURATION-565
Project: Commons Configuration
Issue Type: New Feature
Components: Expression engine
Affects Versions: 2.x
Reporter: Petar Tahchiev
Hi guys,
it would be really awesome if the {{Configuration}} could be created with a
passphrase (let's say 'mypassphrase') and then you also add a method in the
interface (let's say getEncodedString('database.password')) so we could have
encoded properties in our properties files. Internally the method just needs to
delegate to jasypt's {{StandardPBEStringEncryptor}} for instance
{code}
StandardPBEStringEncryptor encryptor = new StandardPBEStringEncryptor();
encryptor.setPassword("mypassphrase");
encryptor.decrypt("database.password");
{code}
decrypt the value and then return the decrypted value. This will allow for more
secure property files.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Comment Edited] (EXEC-80) NPE in EnvironmentUtils.toString(map)
[
https://issues.apache.org/jira/browse/EXEC-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13888670#comment-13888670
]
Karl Heinz Marbaise edited comment on EXEC-80 at 2/1/14 6:55 PM:
-
Attached patch with according unit tests based on trunk@1563452
was (Author: khmarbaise):
Attached patch with according unit tests.
> NPE in EnvironmentUtils.toString(map)
> -
>
> Key: EXEC-80
> URL: https://issues.apache.org/jira/browse/EXEC-80
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.2
> Environment: all
>Reporter: Karl Heinz Marbaise
>Priority: Critical
> Attachments: EXEC-80.patch
>
>
> I have drilled down a problem in the above class method which can be checked
> by using the following unit test:
> {code}
> @Test
> public void toStringTest() {
> Map map = new HashMap();
> map.put("key", null);
> String[] result = EnvironmentUtils.toStrings(map);
> assertThat(result.length).isEqualTo(1);
> }
> {code}
> The above test will fail with an NullPointerException..as expected, cause the
> method accesses the key as well as the value by using the following code line:
> {code}
> result[i] = entry.getKey().toString() + "=" + entry.getValue().toString();
> {code}
> It should be checked if key and/or value are null. If you would use the
> following code:
> {code}
> public static String[] toStrings(final Map environment) {
> if (environment == null) {
> return null;
> }
> final String[] result = new String[environment.size()];
> int i = 0;
> for (final Iterator iter = environment.entrySet().iterator();
> iter.hasNext();) {
> final Map.Entry entry = (Map.Entry) iter.next();
> String key = entry.getKey() == null ? "" :
> entry.getKey().toString();
> String value = entry.getValue() == null ? "" :
> entry.getValue().toString();
> result[i] = key + "=" + value;
> i++;
> }
> return result;
> }
> {code}
> it will solve the issue.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (EXEC-80) NPE in EnvironmentUtils.toString(map)
[
https://issues.apache.org/jira/browse/EXEC-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated EXEC-80:
Attachment: EXEC-80.patch
Attached patch with according unit tests.
> NPE in EnvironmentUtils.toString(map)
> -
>
> Key: EXEC-80
> URL: https://issues.apache.org/jira/browse/EXEC-80
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.2
> Environment: all
>Reporter: Karl Heinz Marbaise
>Priority: Critical
> Attachments: EXEC-80.patch
>
>
> I have drilled down a problem in the above class method which can be checked
> by using the following unit test:
> {code}
> @Test
> public void toStringTest() {
> Map map = new HashMap();
> map.put("key", null);
> String[] result = EnvironmentUtils.toStrings(map);
> assertThat(result.length).isEqualTo(1);
> }
> {code}
> The above test will fail with an NullPointerException..as expected, cause the
> method accesses the key as well as the value by using the following code line:
> {code}
> result[i] = entry.getKey().toString() + "=" + entry.getValue().toString();
> {code}
> It should be checked if key and/or value are null. If you would use the
> following code:
> {code}
> public static String[] toStrings(final Map environment) {
> if (environment == null) {
> return null;
> }
> final String[] result = new String[environment.size()];
> int i = 0;
> for (final Iterator iter = environment.entrySet().iterator();
> iter.hasNext();) {
> final Map.Entry entry = (Map.Entry) iter.next();
> String key = entry.getKey() == null ? "" :
> entry.getKey().toString();
> String value = entry.getValue() == null ? "" :
> entry.getValue().toString();
> result[i] = key + "=" + value;
> i++;
> }
> return result;
> }
> {code}
> it will solve the issue.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (EXEC-80) NPE in EnvironmentUtils.toString(map)
Karl Heinz Marbaise created EXEC-80:
---
Summary: NPE in EnvironmentUtils.toString(map)
Key: EXEC-80
URL: https://issues.apache.org/jira/browse/EXEC-80
Project: Commons Exec
Issue Type: Bug
Affects Versions: 1.2
Environment: all
Reporter: Karl Heinz Marbaise
Priority: Critical
I have drilled down a problem in the above class method which can be checked by
using the following unit test:
{code}
@Test
public void toStringTest() {
Map map = new HashMap();
map.put("key", null);
String[] result = EnvironmentUtils.toStrings(map);
assertThat(result.length).isEqualTo(1);
}
{code}
The above test will fail with an NullPointerException..as expected, cause the
method accesses the key as well as the value by using the following code line:
{code}
result[i] = entry.getKey().toString() + "=" + entry.getValue().toString();
{code}
It should be checked if key and/or value are null. If you would use the
following code:
{code}
public static String[] toStrings(final Map environment) {
if (environment == null) {
return null;
}
final String[] result = new String[environment.size()];
int i = 0;
for (final Iterator iter = environment.entrySet().iterator();
iter.hasNext();) {
final Map.Entry entry = (Map.Entry) iter.next();
String key = entry.getKey() == null ? "" :
entry.getKey().toString();
String value = entry.getValue() == null ? "" :
entry.getValue().toString();
result[i] = key + "=" + value;
i++;
}
return result;
}
{code}
it will solve the issue.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (LANG-964) Create fluent APIs where possible
[
https://issues.apache.org/jira/browse/LANG-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13888654#comment-13888654
]
Oliver Heger commented on LANG-964:
---
While I like fluent interfaces in general, I am not sure whether this is the
correct approach for the fundamental functionality provided by [lang]. The
static utility methods may be a bit old-fashioned, but their usage is
straight-forward and efficient - a fluent API probably involves creating
intermediate objects for each call. And don't forget that it is a major effort
to rework the whole code base in a consistent way.
> Create fluent APIs where possible
> -
>
> Key: LANG-964
> URL: https://issues.apache.org/jira/browse/LANG-964
> Project: Commons Lang
> Issue Type: Task
> Components: General
>Reporter: Benedikt Ritter
> Fix For: 4.0
>
>
> A lot of commons-lang is design in an old fashioned way using static util
> methods. The problem of this design is, that it encodes a language into
> method names leading to lots of variations of the same method in one class.
> For example StringUtils has over 180 methods, 9 of which a related to
> splitting.
> Instead of overloading methods and creating method name variations, we should
> try to implement fluent APIs. Examples:
> Instead of:
> {code:java}
> StringEscapeUtils.escapeHtml3(String)
> StringEscapeUtils.escapeHtml4(String)
> StringEscapeUtils.escapeXml(String)
> {code}
> the API could look like:
> {code:java}
> StringEscaping.escape(String).with(Escaping.HTML_3)
> StringEscaping.escape(String).with(Escaping.HTML_4)
> StringEscaping.escape(String).with(Escaping.XML)
> {code}
> So no additional methods are necessary when adding new escaping. There are
> more examples in commons-lang where the fluent design can be applied.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (LANG-963) Clarify behavior of StringEscapeUtils.escapeXml be renaming it to StringEscapeUtils.escapeXmlEntities
[
https://issues.apache.org/jira/browse/LANG-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13888561#comment-13888561
]
Benedikt Ritter commented on LANG-963:
--
I'm undecided whether we should change escapeHtml3 and escapeHtml4 to
escapeHtml_3_Entities and escapeHtml_4_Entities... I don't like the underscores
but I see no better way to decode the version into the method name. Further
more this will be aligned to what we have for XML escaping after LANG-955 is
resolved.
> Clarify behavior of StringEscapeUtils.escapeXml be renaming it to
> StringEscapeUtils.escapeXmlEntities
> -
>
> Key: LANG-963
> URL: https://issues.apache.org/jira/browse/LANG-963
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
> Fix For: 3.3
>
>
> Although the documentation of {{StringEscaspeUtils.escapeXml(String)}} makes
> explicit that the method can only handle the basic XML entities, this should
> be clarified by renaming the method. The old method has be be deprecated and
> forwarded to the new method.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Comment Edited] (LANG-922) Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of BooleanUtils.xor(booleans...)
[ https://issues.apache.org/jira/browse/LANG-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13888558#comment-13888558 ] Benedikt Ritter edited comment on LANG-922 at 2/1/14 12:39 PM: --- bq. I'd like to get away from static util methods that take 4 parameters I've created LANG-964 to track the creation of fluent APIs, since this has to wait until 4.0. was (Author: britter): bq. I'd like to get away from static util methods that take 4 parameters I've created LANG-964 to track the creating of fluent APIs, since this has to wait until 4.0. > Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of > BooleanUtils.xor(booleans...) > > > Key: LANG-922 > URL: https://issues.apache.org/jira/browse/LANG-922 > Project: Commons Lang > Issue Type: Task > Components: lang.* >Reporter: Benedikt Ritter > Fix For: Discussion > > > The old implementation (prior to r1532476) of BooleanUtils.xor(boolean...) > checked if the provided array contained exactly one boolean with value true. > This was changed because it is not the correct behavior for an XOR operation. > To preserve the behavior we should add BooleanUtils.isOneTrue(boolean...) and > BooleanUtils.isOneTrue(Boolean...) (and possibly the equivalents for > isOneFalse). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (LANG-922) Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of BooleanUtils.xor(booleans...)
[ https://issues.apache.org/jira/browse/LANG-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13888558#comment-13888558 ] Benedikt Ritter commented on LANG-922: -- bq. I'd like to get away from static util methods that take 4 parameters I've created LANG-964 to track the creating of fluent APIs, since this has to wait until 4.0. > Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of > BooleanUtils.xor(booleans...) > > > Key: LANG-922 > URL: https://issues.apache.org/jira/browse/LANG-922 > Project: Commons Lang > Issue Type: Task > Components: lang.* >Reporter: Benedikt Ritter > Fix For: Discussion > > > The old implementation (prior to r1532476) of BooleanUtils.xor(boolean...) > checked if the provided array contained exactly one boolean with value true. > This was changed because it is not the correct behavior for an XOR operation. > To preserve the behavior we should add BooleanUtils.isOneTrue(boolean...) and > BooleanUtils.isOneTrue(Boolean...) (and possibly the equivalents for > isOneFalse). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (LANG-964) Create fluent APIs where possible
Benedikt Ritter created LANG-964:
Summary: Create fluent APIs where possible
Key: LANG-964
URL: https://issues.apache.org/jira/browse/LANG-964
Project: Commons Lang
Issue Type: Task
Components: General
Reporter: Benedikt Ritter
Fix For: 4.0
A lot of commons-lang is design in an old fashioned way using static util
methods. The problem of this design is, that it encodes a language into method
names leading to lots of variations of the same method in one class. For
example StringUtils has over 180 methods, 9 of which a related to splitting.
Instead of overloading methods and creating method name variations, we should
try to implement fluent APIs. Examples:
Instead of:
{code:java}
StringEscapeUtils.escapeHtml3(String)
StringEscapeUtils.escapeHtml4(String)
StringEscapeUtils.escapeXml(String)
{code}
the API could look like:
{code:java}
StringEscaping.escape(String).with(Escaping.HTML_3)
StringEscaping.escape(String).with(Escaping.HTML_4)
StringEscaping.escape(String).with(Escaping.XML)
{code}
So no additional methods are necessary when adding new escaping. There are more
examples in commons-lang where the fluent design can be applied.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (LANG-955) Add methods for removing all invalid characters according to XML 1.0 and XML 1.1 in an input string to StringEscapeUtils
[
https://issues.apache.org/jira/browse/LANG-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-955:
-
Summary: Add methods for removing all invalid characters according to XML
1.0 and XML 1.1 in an input string to StringEscapeUtils (was:
StringEscapeUtils.escapeXml doesn't remove invalid characters)
> Add methods for removing all invalid characters according to XML 1.0 and XML
> 1.1 in an input string to StringEscapeUtils
>
>
> Key: LANG-955
> URL: https://issues.apache.org/jira/browse/LANG-955
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.1
> Environment: Ubuntu 13.10
>Reporter: Adam Hooper
>Assignee: Benedikt Ritter
> Labels: xml
> Fix For: 3.3, Review Patch
>
>
> escapeXml lets non-text characters pass through into XML files:
> {code}
> scala>
> org.apache.commons.lang3.StringEscapeUtils.escapeXml("\u0004").codePointAt(0)
> res4: Int = 4
> {code}
> I would expect the result to be an exception -- either from StringEscapeUtils
> (refusing to encode it) or, preferably, from String.codePointAt, complaining
> that the string is empty. \u0004 is not a valid character in XML 1.0, and
> there is no way to represent it in an XML document -- not even by escaping it.
> Wikipedia summarizes the characters that are not allowed in XML -- even after
> escaping: http://en.wikipedia.org/wiki/Valid_characters_in_XML. The reason
> for disallowing them: XML is a text interchange format, and control
> characters are not text.
> If StringEscapeUtils.escapeXml allows invalid XML characters through --
> whether escaped or not -- it generates invalid XML. Valid XML parsers will
> refuse to read such files.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (LANG-955) StringEscapeUtils.escapeXml doesn't remove invalid characters
[
https://issues.apache.org/jira/browse/LANG-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-955:
-
Issue Type: Improvement (was: Bug)
> StringEscapeUtils.escapeXml doesn't remove invalid characters
> -
>
> Key: LANG-955
> URL: https://issues.apache.org/jira/browse/LANG-955
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.1
> Environment: Ubuntu 13.10
>Reporter: Adam Hooper
>Assignee: Benedikt Ritter
> Labels: xml
> Fix For: 3.3, Review Patch
>
>
> escapeXml lets non-text characters pass through into XML files:
> {code}
> scala>
> org.apache.commons.lang3.StringEscapeUtils.escapeXml("\u0004").codePointAt(0)
> res4: Int = 4
> {code}
> I would expect the result to be an exception -- either from StringEscapeUtils
> (refusing to encode it) or, preferably, from String.codePointAt, complaining
> that the string is empty. \u0004 is not a valid character in XML 1.0, and
> there is no way to represent it in an XML document -- not even by escaping it.
> Wikipedia summarizes the characters that are not allowed in XML -- even after
> escaping: http://en.wikipedia.org/wiki/Valid_characters_in_XML. The reason
> for disallowing them: XML is a text interchange format, and control
> characters are not text.
> If StringEscapeUtils.escapeXml allows invalid XML characters through --
> whether escaped or not -- it generates invalid XML. Valid XML parsers will
> refuse to read such files.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (LANG-963) Clarify behavior of StringEscapeUtils.escapeXml be renaming it to StringEscapeUtils.escapeXmlEntities
[
https://issues.apache.org/jira/browse/LANG-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13888546#comment-13888546
]
Benedikt Ritter commented on LANG-963:
--
{{escapeHtml3}} and {{escapeHtml4}} also only escape entities and should be
renamed likewise
> Clarify behavior of StringEscapeUtils.escapeXml be renaming it to
> StringEscapeUtils.escapeXmlEntities
> -
>
> Key: LANG-963
> URL: https://issues.apache.org/jira/browse/LANG-963
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
> Fix For: 3.3
>
>
> Although the documentation of {{StringEscaspeUtils.escapeXml(String)}} makes
> explicit that the method can only handle the basic XML entities, this should
> be clarified by renaming the method. The old method has be be deprecated and
> forwarded to the new method.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (LANG-955) StringEscapeUtils.escapeXml doesn't remove invalid characters
[
https://issues.apache.org/jira/browse/LANG-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13888545#comment-13888545
]
Benedikt Ritter commented on LANG-955:
--
I've created LANG-963 for changing the name of
{{StringEscapeUtils.escapeXml(String)}} to
StringEscapeUtils.escapeXmlEntities(String)
> StringEscapeUtils.escapeXml doesn't remove invalid characters
> -
>
> Key: LANG-955
> URL: https://issues.apache.org/jira/browse/LANG-955
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.1
> Environment: Ubuntu 13.10
>Reporter: Adam Hooper
>Assignee: Benedikt Ritter
> Labels: xml
> Fix For: 3.3, Review Patch
>
>
> escapeXml lets non-text characters pass through into XML files:
> {code}
> scala>
> org.apache.commons.lang3.StringEscapeUtils.escapeXml("\u0004").codePointAt(0)
> res4: Int = 4
> {code}
> I would expect the result to be an exception -- either from StringEscapeUtils
> (refusing to encode it) or, preferably, from String.codePointAt, complaining
> that the string is empty. \u0004 is not a valid character in XML 1.0, and
> there is no way to represent it in an XML document -- not even by escaping it.
> Wikipedia summarizes the characters that are not allowed in XML -- even after
> escaping: http://en.wikipedia.org/wiki/Valid_characters_in_XML. The reason
> for disallowing them: XML is a text interchange format, and control
> characters are not text.
> If StringEscapeUtils.escapeXml allows invalid XML characters through --
> whether escaped or not -- it generates invalid XML. Valid XML parsers will
> refuse to read such files.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Comment Edited] (LANG-955) StringEscapeUtils.escapeXml doesn't remove invalid characters
[
https://issues.apache.org/jira/browse/LANG-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13888545#comment-13888545
]
Benedikt Ritter edited comment on LANG-955 at 2/1/14 11:45 AM:
---
I've created LANG-963 for changing the name of
{{StringEscapeUtils.escapeXml(String)}} to
{{StringEscapeUtils.escapeXmlEntities(String)}}
was (Author: britter):
I've created LANG-963 for changing the name of
{{StringEscapeUtils.escapeXml(String)}} to
StringEscapeUtils.escapeXmlEntities(String)
> StringEscapeUtils.escapeXml doesn't remove invalid characters
> -
>
> Key: LANG-955
> URL: https://issues.apache.org/jira/browse/LANG-955
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.1
> Environment: Ubuntu 13.10
>Reporter: Adam Hooper
>Assignee: Benedikt Ritter
> Labels: xml
> Fix For: 3.3, Review Patch
>
>
> escapeXml lets non-text characters pass through into XML files:
> {code}
> scala>
> org.apache.commons.lang3.StringEscapeUtils.escapeXml("\u0004").codePointAt(0)
> res4: Int = 4
> {code}
> I would expect the result to be an exception -- either from StringEscapeUtils
> (refusing to encode it) or, preferably, from String.codePointAt, complaining
> that the string is empty. \u0004 is not a valid character in XML 1.0, and
> there is no way to represent it in an XML document -- not even by escaping it.
> Wikipedia summarizes the characters that are not allowed in XML -- even after
> escaping: http://en.wikipedia.org/wiki/Valid_characters_in_XML. The reason
> for disallowing them: XML is a text interchange format, and control
> characters are not text.
> If StringEscapeUtils.escapeXml allows invalid XML characters through --
> whether escaped or not -- it generates invalid XML. Valid XML parsers will
> refuse to read such files.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (LANG-963) Clarify behavior of StringEscapeUtils.escapeXml be renaming it to StringEscapeUtils.escapeXmlEntities
Benedikt Ritter created LANG-963:
Summary: Clarify behavior of StringEscapeUtils.escapeXml be
renaming it to StringEscapeUtils.escapeXmlEntities
Key: LANG-963
URL: https://issues.apache.org/jira/browse/LANG-963
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Reporter: Benedikt Ritter
Assignee: Benedikt Ritter
Fix For: 3.3
Although the documentation of {{StringEscaspeUtils.escapeXml(String)}} makes
explicit that the method can only handle the basic XML entities, this should be
clarified by renaming the method. The old method has be be deprecated and
forwarded to the new method.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (LANG-922) Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of BooleanUtils.xor(booleans...)
[
https://issues.apache.org/jira/browse/LANG-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13888538#comment-13888538
]
Benedikt Ritter commented on LANG-922:
--
I'd like to get away from static util methods that take 4 parameters. How about:
{code}
Frequency.of(12).in(myIntArray).equalTo(2)
Frequency.of(12).in(myIntArray).lessThan(2)
Frequency.of(12).in(myIntArray).greaterThan(2)
{code}
> Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of
> BooleanUtils.xor(booleans...)
>
>
> Key: LANG-922
> URL: https://issues.apache.org/jira/browse/LANG-922
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
> Fix For: Discussion
>
>
> The old implementation (prior to r1532476) of BooleanUtils.xor(boolean...)
> checked if the provided array contained exactly one boolean with value true.
> This was changed because it is not the correct behavior for an XOR operation.
> To preserve the behavior we should add BooleanUtils.isOneTrue(boolean...) and
> BooleanUtils.isOneTrue(Boolean...) (and possibly the equivalents for
> isOneFalse).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (LANG-922) Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of BooleanUtils.xor(booleans...)
[ https://issues.apache.org/jira/browse/LANG-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated LANG-922: - Assignee: (was: Benedikt Ritter) > Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of > BooleanUtils.xor(booleans...) > > > Key: LANG-922 > URL: https://issues.apache.org/jira/browse/LANG-922 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Reporter: Benedikt Ritter > Fix For: Discussion > > > The old implementation (prior to r1532476) of BooleanUtils.xor(boolean...) > checked if the provided array contained exactly one boolean with value true. > This was changed because it is not the correct behavior for an XOR operation. > To preserve the behavior we should add BooleanUtils.isOneTrue(boolean...) and > BooleanUtils.isOneTrue(Boolean...) (and possibly the equivalents for > isOneFalse). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (LANG-922) Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of BooleanUtils.xor(booleans...)
[ https://issues.apache.org/jira/browse/LANG-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated LANG-922: - Issue Type: Task (was: Bug) > Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of > BooleanUtils.xor(booleans...) > > > Key: LANG-922 > URL: https://issues.apache.org/jira/browse/LANG-922 > Project: Commons Lang > Issue Type: Task > Components: lang.* >Reporter: Benedikt Ritter > Fix For: Discussion > > > The old implementation (prior to r1532476) of BooleanUtils.xor(boolean...) > checked if the provided array contained exactly one boolean with value true. > This was changed because it is not the correct behavior for an XOR operation. > To preserve the behavior we should add BooleanUtils.isOneTrue(boolean...) and > BooleanUtils.isOneTrue(Boolean...) (and possibly the equivalents for > isOneFalse). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (EMAIL-136) FIx javadoc 1.8 errors
[ https://issues.apache.org/jira/browse/EMAIL-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ville Skyttä updated EMAIL-136: --- Attachment: 0001-Fix-Javadoc-1.8-errors.patch > FIx javadoc 1.8 errors > -- > > Key: EMAIL-136 > URL: https://issues.apache.org/jira/browse/EMAIL-136 > Project: Commons Email > Issue Type: Bug >Reporter: Ville Skyttä >Priority: Minor > Labels: patch > Attachments: 0001-Fix-Javadoc-1.8-errors.patch > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (EMAIL-136) FIx javadoc 1.8 errors
Ville Skyttä created EMAIL-136: -- Summary: FIx javadoc 1.8 errors Key: EMAIL-136 URL: https://issues.apache.org/jira/browse/EMAIL-136 Project: Commons Email Issue Type: Bug Reporter: Ville Skyttä Priority: Minor Attachments: 0001-Fix-Javadoc-1.8-errors.patch -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (LANG-946) ConstantInitializerTest fails when building with IBM JDK 7
[
https://issues.apache.org/jira/browse/LANG-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter resolved LANG-946.
--
Resolution: Fixed
Fixed in revision 1563388.
> ConstantInitializerTest fails when building with IBM JDK 7
> --
>
> Key: LANG-946
> URL: https://issues.apache.org/jira/browse/LANG-946
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.concurrent.*
>Affects Versions: 3.2.1
> Environment: IBM JDK 7
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
> Fix For: 3.3
>
>
> Found by Jörg Schaible during the vote for 3.2.1 RC1 [1]:
> {code}
> == %<
> Failed tests:
> ConstantInitializerTest.testToString:122 Wrong string:
> ConstantInitializer@-669671219 [ object = 42 ]
> == %<
> {code}
> [1] http://markmail.org/message/7exdutk2cktec2yy
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (LOGGING-157) FIx javadoc 1.8 errors and some warnings
[ https://issues.apache.org/jira/browse/LOGGING-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ville Skyttä updated LOGGING-157: - Attachment: 0001-Fix-Javadoc-1.8-errors-and-some-warnings.patch > FIx javadoc 1.8 errors and some warnings > > > Key: LOGGING-157 > URL: https://issues.apache.org/jira/browse/LOGGING-157 > Project: Commons Logging > Issue Type: Bug >Reporter: Ville Skyttä >Priority: Minor > Labels: patch > Attachments: 0001-Fix-Javadoc-1.8-errors-and-some-warnings.patch > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (LOGGING-157) FIx javadoc 1.8 errors and some warnings
Ville Skyttä created LOGGING-157: Summary: FIx javadoc 1.8 errors and some warnings Key: LOGGING-157 URL: https://issues.apache.org/jira/browse/LOGGING-157 Project: Commons Logging Issue Type: Bug Reporter: Ville Skyttä Priority: Minor Attachments: 0001-Fix-Javadoc-1.8-errors-and-some-warnings.patch -- This message was sent by Atlassian JIRA (v6.1.5#6160)
