[jira] [Commented] (LANG-739) ToStringBuilder leaks memory if toString method causes hash code to be changed
[
https://issues.apache.org/jira/browse/LANG-739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749458#comment-13749458
]
Allon Mureinik commented on LANG-739:
-
I am wondering if this is not a misuse of HashCodeBuilder.
Wouldn't the right usage be to define toString as transient and use the
overloaded HashCodeBuilder.reflectionHashCode(this, false)?
> ToStringBuilder leaks memory if toString method causes hash code to be changed
> --
>
> Key: LANG-739
> URL: https://issues.apache.org/jira/browse/LANG-739
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 2.3
>Reporter: Philippe Renon
>
> We have the following abstract class:
> {code}
> public class AbstractMessageItem {
> private String toString;
> public boolean equals(final Object obj) {
> return EqualsBuilder.reflectionEquals(this, obj);
> }
> public int hashCode() {
> return HashCodeBuilder.reflectionHashCode(this);
> }
> public String toString() {
> if (toString == null) {
> toString = ToStringBuilder.reflectionToString(this);
> }
> return toString;
> }
> }
> {code}
> We also have two concrete classes extending the above class and one of them
> has a reference to the other.
> Now, if we call toString() on the 1st one, this will in turn call toString()
> on the second one.
> The call to toString() on the second one will cause its hash code to be
> changed and as a consequence will also change the hashCode of the first one
> *while* computing its toString().
> This causes the _infinite loop avoidance_ mechanism (i.e. the registry) to
> fail to unregister some objects and memory will be leaked.
> I believe that this leak can be avoided by using the system identity hash
> code when registering objects (as is done in HashCodeBuilder) instead of the
> user hash code.
> I know the issue can be worked around by removing the toString field (and
> loosing a dubious "performance enhancement" hack) or by making it transient,
> but I think that other "mutating" toString() methods can happen in the field
> (sometimes for good reasons) and fixing ToStringBuilder can be of help in
> some cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CONFIGURATION-551) Make data type conversions extensible
[
https://issues.apache.org/jira/browse/CONFIGURATION-551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-551.
Resolution: Fixed
Data type conversions are now handled by an object implementing the simple
{{ConversionHandler}} interface. It is possible for applications to provide a
custom {{ConversionHandler}} implementation (either by creating a new
implementation from scratch or by extending the {{DefaultConversionHandler}}
class). This way the conversion mechanism can be adapted and/or extended.
> Make data type conversions extensible
> -
>
> Key: CONFIGURATION-551
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-551
> Project: Commons Configuration
> Issue Type: Improvement
> Components: Type conversion
>Affects Versions: 1.9
>Reporter: Oliver Heger
> Fix For: 2.0
>
>
> So far, a fix set of data type conversions is supported. Some are available
> directly in the {{Configuration}} interface (especially for primitive and
> standard Java types), others are provided by {{DataConfiguration}}.
> Currently, it is not easy possible for client applications to customize type
> conversions or add new converters.
> I am not sure whether we should go so far to implement yet another framework
> with type converters; at least not directly for version 2.0. However, there
> should be at least possibilities to hook into the conversion mechanism.
> Ideally, I would like to have a simple facade handling the different kinds of
> conversions. By providing alternative implementations, client applications
> should be able to adapt type conversions or even plug in a different
> conversion framework, e.g. Commons Beanutils.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CONFIGURATION-508) Add generic get method to convert config property to any object
[
https://issues.apache.org/jira/browse/CONFIGURATION-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-508.
Resolution: Fixed
Fix Version/s: 2.0
Generic get() methods have been added to the {{Configuration}} interface. These
methods delegate to a {{ConversionHandler}} object which is responsible for all
data type conversions. It is possible to replace the default conversion handler
to customize the conversion mechanism.
> Add generic get method to convert config property to any object
> ---
>
> Key: CONFIGURATION-508
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-508
> Project: Commons Configuration
> Issue Type: Improvement
> Components: Type conversion
>Affects Versions: 1.9
>Reporter: Matt Bertolini
> Labels: configuration, constructor, conversion, convert,
> generic, property, static, type, valueof
> Fix For: 2.0
>
>
> Now that commons configuration requires java 5.0+, I think we should consider
> adding a couple of new generic getter methods that will enable developers to
> automatically convert the configuration property to the object of their
> choice. I envision the API looking like the below:
> {code:java}
> public T get(String key, Class clazz);
> public T get(String key, Class clazz, T defaultValue);
> {code}
> The method would perform a five step process:
> # First it would get the string value, post interpolation.
> # Then it would check the given class for the existence of a static "valueOf"
> method with one String argument. If found, it would invoke that method with
> the interpolated string value.
> # If no static "valueOf" method is found, it would search for a constructor
> with one String argument. If that is found, it would construct a new instance
> of the class passing the interpolated string value.
> # If no constructor or static method is found, it will check if a default
> value was given, returning it if true.
> # Finally, if no default value is given, it checks to see if
> throwExceptionOnMissing is set to true. If so, it will throw the exception.
> If false, it will return null.
> This behavior is similar to how the Spring conversion service works. I
> believe that this feature would be a great help to developers as many of the
> values contained in configuration properties often times map over to various
> model objects.
> I am looking for some feedback on the idea. Let me know your thoughts. Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CONFIGURATION-26) Consider returning a concatenation of the list properties with getString()
[
https://issues.apache.org/jira/browse/CONFIGURATION-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-26.
---
Resolution: Fixed
While the requested feature is still not supported out of the box, it is now
possible to achieve the desired effect by using a custom {{ConversionHandler}}.
Each configuration object is now associated with a {{ConversionHandler}}
object. The conversion handler is responsible for all kinds of data type
conversions. This includes conversions from complex objects (like arrays or
lists) to single values. Here a custom {{ConversionHandler}} implementation can
hook in to return a verbatim string value or whatever it sees appropriate.
There is already a default implementation called {{DefaultConversionHandler}}
which offers some protected methods a subclass may override to adapt
conversions. The user's guide was updated to describe these new features.
> Consider returning a concatenation of the list properties with getString()
> --
>
> Key: CONFIGURATION-26
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-26
> Project: Commons Configuration
> Issue Type: Bug
>Reporter: Ittay Dror
>Priority: Minor
> Fix For: 2.0
>
>
> in AbstractConfiguration.resolveContainerStore (javadoc):
> * Returns an object from the store described by the key. If the value is a
> * List object, replace it with the first object in the list.
> but what if getProperty returns a List because this is the type of the
> property?
> this code will silently grab the first elemen. I don't understand why.
> Probably
> the reason is that some class extending AbstractConfiguration returns List
> for
> properties. In this case I think the better approach is to have that class
> return the first element instead, rather than returning the List and letting
> AbstractConfiguration (which is used by many other implementations, including
> outside of the configuration package) handle it
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-928) Alternative approach to matrix implementations
[ https://issues.apache.org/jira/browse/MATH-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-928: Fix Version/s: 3.3 > Alternative approach to matrix implementations > -- > > Key: MATH-928 > URL: https://issues.apache.org/jira/browse/MATH-928 > Project: Commons Math > Issue Type: New Feature >Reporter: Gilles >Priority: Minor > Labels: api > Fix For: 3.3 > > Attachments: basic_matrix.tar.gz > > > Old and recent discussions on the "dev" ML bought different, and > incompatible, viewpoints on how to provide matrix and linear algebra features > in Commons Math. > Problems with the current API have been summarized in MATH-765. > Those sometimes contributes to putting the CM matrix implementations into the > category of "bloated" code (too many methods that rebuff would-be > contributors from creating new subclasses that only need specific > functionality). > It also poses the question of "purpose": Which implementations are good for a > given usage? Or which should be avoided. > The Commons Math's development model assumes that the implementations were > created to answer some specific need of the contributor(s). But eventually, > the limitations of the ad-hoc implementations (often) do not make it to the > description (Javadoc, user guide, unit test, use cases); and the new tool > just becomes an additional "low-level" components of the library. > Such building blocks are then reused (as a black box) in another context, > e.g. another par of the library (which is a good thing), sometimes with > unforeseen (and not so good) consequences (cf. MATH-924). > It seems that Commons Math could either provide more building blocks (to try > and cover use cases that need different features), or "restrict" usage of the > classes that were maybe primarily developed for a specific usage. > As I hinted above, the former might be rendered more difficult by imposing a > relatively complex interface. > In this issue, I attempted to explore an alternative approach (which was > briefly mentioned more than a year ago, IIRC) by which matrix functionality > would be built up by mixing and matching simple (and more or less > independent) components. > As an example, I've implemented a new matrix class with a focus on > immutability. Certain uses might benefit from such a feature, while for > others, this will be drawback. > However, my hope would be that "elementary" building blocks could lend > themselves to "combinations" by which some algorithm would convert between > the various matrix implementations so as to use to most appropriate for a > given sequence of operations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-910) Patch to extend StringUtils
[ https://issues.apache.org/jira/browse/LANG-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timur Yarosh updated LANG-910: -- Attachment: (was: substring-matches-and-hard-space-normalize.patch) > Patch to extend StringUtils > --- > > Key: LANG-910 > URL: https://issues.apache.org/jira/browse/LANG-910 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.1 > Environment: Developed on Ubuntu 13.04 with openjdk 7u25 >Reporter: Timur Yarosh > Labels: patch > Fix For: 3.1 > > Attachments: substring-matches-and-white-space-normalize.patch > > > This patch extends StringUtils capabilities: added methods to find > substring(s) by Pattern. Also method > org.apache.commons.lang3.StringUtils#normalizeSpace now replaces ASCII #160 > char to normal whitespace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-910) Patch to extend StringUtils
[ https://issues.apache.org/jira/browse/LANG-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timur Yarosh updated LANG-910: -- Attachment: substring-matches-and-white-space-normalize.patch > Patch to extend StringUtils > --- > > Key: LANG-910 > URL: https://issues.apache.org/jira/browse/LANG-910 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.1 > Environment: Developed on Ubuntu 13.04 with openjdk 7u25 >Reporter: Timur Yarosh > Labels: patch > Fix For: 3.1 > > Attachments: substring-matches-and-white-space-normalize.patch > > > This patch extends StringUtils capabilities: added methods to find > substring(s) by Pattern. Also method > org.apache.commons.lang3.StringUtils#normalizeSpace now replaces ASCII #160 > char to normal whitespace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-910) Patch to extend StringUtils
[ https://issues.apache.org/jira/browse/LANG-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timur Yarosh updated LANG-910: -- Attachment: (was: substring-matches-and-hard-space-normalizer.patch) > Patch to extend StringUtils > --- > > Key: LANG-910 > URL: https://issues.apache.org/jira/browse/LANG-910 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.1 > Environment: Developed on Ubuntu 13.04 with openjdk 7u25 >Reporter: Timur Yarosh > Labels: patch > Fix For: 3.1 > > Attachments: substring-matches-and-hard-space-normalize.patch > > > This patch extends StringUtils capabilities: added methods to find > substring(s) by Pattern. Also method > org.apache.commons.lang3.StringUtils#normalizeSpace now replaces ASCII #160 > char to normal whitespace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-910) Patch to extend StringUtils
[ https://issues.apache.org/jira/browse/LANG-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timur Yarosh updated LANG-910: -- Attachment: substring-matches-and-hard-space-normalize.patch > Patch to extend StringUtils > --- > > Key: LANG-910 > URL: https://issues.apache.org/jira/browse/LANG-910 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.1 > Environment: Developed on Ubuntu 13.04 with openjdk 7u25 >Reporter: Timur Yarosh > Labels: patch > Fix For: 3.1 > > Attachments: substring-matches-and-hard-space-normalize.patch > > > This patch extends StringUtils capabilities: added methods to find > substring(s) by Pattern. Also method > org.apache.commons.lang3.StringUtils#normalizeSpace now replaces ASCII #160 > char to normal whitespace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-910) Patch to extend StringUtils
[ https://issues.apache.org/jira/browse/LANG-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timur Yarosh updated LANG-910: -- Attachment: substring-matches-and-hard-space-normalizer.patch > Patch to extend StringUtils > --- > > Key: LANG-910 > URL: https://issues.apache.org/jira/browse/LANG-910 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.1 > Environment: Developed on Ubuntu 13.04 with openjdk 7u25 >Reporter: Timur Yarosh > Labels: patch > Fix For: 3.1 > > Attachments: substring-matches-and-hard-space-normalizer.patch > > > This patch extends StringUtils capabilities: added methods to find > substring(s) by Pattern. Also method > org.apache.commons.lang3.StringUtils#normalizeSpace now replaces ASCII #160 > char to normal whitespace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-910) Patch to extend StringUtils
Timur Yarosh created LANG-910: - Summary: Patch to extend StringUtils Key: LANG-910 URL: https://issues.apache.org/jira/browse/LANG-910 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 3.1 Environment: Developed on Ubuntu 13.04 with openjdk 7u25 Reporter: Timur Yarosh Fix For: 3.1 This patch extends StringUtils capabilities: added methods to find substring(s) by Pattern. Also method org.apache.commons.lang3.StringUtils#normalizeSpace now replaces ASCII #160 char to normal whitespace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
