[jira] [Updated] (CONFIGURATION-647) INI removable delimiter spaces
[ https://issues.apache.org/jira/browse/CONFIGURATION-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] green updated CONFIGURATION-647: Attachment: java.patch Don't really have much time, but I made something. Is that alright? > INI removable delimiter spaces > -- > > Key: CONFIGURATION-647 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-647 > Project: Commons Configuration > Issue Type: Improvement > Components: Format >Affects Versions: 2.x >Reporter: green >Priority: Minor > Labels: INI, delimiter, remove, spaces, store, write > Attachments: java.patch > > > org.apache.commons.configuration2.INIConfiguration.write creates INI files > with spaces around the '=' delimiter. Older software which is not expecting > extra spaces can break. Would be great if delimiter spaces were configurable. > Thx! -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (CONFIGURATION-647) INI removable delimiter spaces
[ https://issues.apache.org/jira/browse/CONFIGURATION-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15877029#comment-15877029 ] green edited comment on CONFIGURATION-647 at 2/21/17 11:44 PM: --- Don't really have much time, but I made something. Is that alright? See java.patch Attachment. was (Author: green): Don't really have much time, but I made something. Is that alright? > INI removable delimiter spaces > -- > > Key: CONFIGURATION-647 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-647 > Project: Commons Configuration > Issue Type: Improvement > Components: Format >Affects Versions: 2.x >Reporter: green >Priority: Minor > Labels: INI, delimiter, remove, spaces, store, write > Attachments: java.patch > > > org.apache.commons.configuration2.INIConfiguration.write creates INI files > with spaces around the '=' delimiter. Older software which is not expecting > extra spaces can break. Would be great if delimiter spaces were configurable. > Thx! -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (LANG-945) ToStringBuilder can expose passwords and other sensitive data in logs
D Green created LANG-945: Summary: ToStringBuilder can expose passwords and other sensitive data in logs Key: LANG-945 URL: https://issues.apache.org/jira/browse/LANG-945 Project: Commons Lang Issue Type: New Feature Components: lang.builder.* Reporter: D Green We just noticed ToStringBuilder was exposing passwords in our logs - would be nice to have a way of either ignoring or obfiscating the value of fields either by passing in a vararg to the builder or having an annotation to do this. Also, 'password' could possibly always be obfiscated by default? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (LANG-985) ToStringBuilder reliably handle OpenPojo @BusinessKey annotated instances
D Green created LANG-985:
Summary: ToStringBuilder reliably handle OpenPojo @BusinessKey
annotated instances
Key: LANG-985
URL: https://issues.apache.org/jira/browse/LANG-985
Project: Commons Lang
Issue Type: Wish
Components: lang.builder.*
Reporter: D Green
Priority: Minor
We use Google's OpenPojo library, annotating DTOs and persistence entities with
@BusinessKey in order to remove boilerplate hashcode() and equals().
I recently started noticing toString() was throwing exceptions when I didn't
populate @BusinessKey annotated field(s) as I was using the Null Object
Pattern. A workaround was to populate dummy values but there's a risk this
could be considered a real value further down the line, so looked for an
alternative solution and came up with the following extending
StandardToStringStyle:-
import org.apache.commons.lang3.builder.StandardToStringStyle;
import org.apache.commons.lang3.builder.ToStringStyle;
import com.openpojo.business.annotation.BusinessKey;
import com.openpojo.business.exception.BusinessException;
public class CustomToStringStyle extends StandardToStringStyle {
public static final ToStringStyle OPENPOJO_SAFE_STYLE =
createOpenPojoSafeStyle();
/**
* Works better with {@link BusinessKey} annotated OpenPojo classes.
*
* This instance does not call {@link ToStringStyle}.register(...)
* which can throw a {@link BusinessException} if the key hasn't been
* populated, for example if you used the Null Object Pattern.
*/
private static ToStringStyle createOpenPojoSafeStyle() {
final StandardToStringStyle style = new StandardToStringStyle();
style.setUseClassName(false);
style.setUseIdentityHashCode(false);
return style;
}
}
Used as follows:
@Override
public String toString() {
return ToStringBuilder.reflectionToString(this,
CustomToStringStyle.OPENPOJO_SAFE_STYLE);
}
I realise this doesn't handle recursion in fields because it skips over
ToStringStyle.register(..) but this suffices for our use case right now -
perhaps an alternative implementation overriding register() that uses a List
(with documented performance penalty) could be added.
Is there anything already in Commons that could do this? If not we would like
this to be considered for inclusion in commons lang (happy to help out with
development), potentially with implementation improvements by those who know
the code base better.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (LANG-985) ToStringBuilder reliably handle OpenPojo @BusinessKey annotated instances
[
https://issues.apache.org/jira/browse/LANG-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
D Green updated LANG-985:
-
Description:
We use Google's OpenPojo library, annotating DTOs and persistence entities with
@BusinessKey in order to remove boilerplate hashcode() and equals().
I recently started noticing toString() was throwing exceptions when I didn't
populate @BusinessKey annotated field(s) as I was using the Null Object
Pattern. A workaround was to populate dummy values but there's a risk this
could be considered a real value further down the line, so looked for an
alternative solution and came up with the following extending
StandardToStringStyle:-
import org.apache.commons.lang3.builder.StandardToStringStyle;
import org.apache.commons.lang3.builder.ToStringStyle;
import com.openpojo.business.annotation.BusinessKey;
import com.openpojo.business.exception.BusinessException;
public class CustomToStringStyle extends StandardToStringStyle {
public static final ToStringStyle OPENPOJO_SAFE_STYLE =
createOpenPojoSafeStyle();
/**
* Works better with {@link BusinessKey} annotated OpenPojo classes.
*
* This instance does not call {@link ToStringStyle}.register(...)
* which can throw a {@link BusinessException} if the key hasn't been
* populated, for example if you used the Null Object Pattern.
*/
private static ToStringStyle createOpenPojoSafeStyle() {
final StandardToStringStyle style = new StandardToStringStyle();
style.setUseClassName(false);
style.setUseIdentityHashCode(false);
return style;
}
}
Used as follows:
{code}
@Override
public String toString() {
return ToStringBuilder.reflectionToString(this,
CustomToStringStyle.OPENPOJO_SAFE_STYLE);
}
{code}
I realise this doesn't handle recursion in fields because it skips over
ToStringStyle.register(..) but this suffices for our use case right now -
perhaps an alternative implementation overriding register() that uses a List
(with documented performance penalty) could be added.
Is there anything already in Commons that could do this? If not we would like
this to be considered for inclusion in commons lang (happy to help out with
development), potentially with implementation improvements by those who know
the code base better.
was:
We use Google's OpenPojo library, annotating DTOs and persistence entities with
@BusinessKey in order to remove boilerplate hashcode() and equals().
I recently started noticing toString() was throwing exceptions when I didn't
populate @BusinessKey annotated field(s) as I was using the Null Object
Pattern. A workaround was to populate dummy values but there's a risk this
could be considered a real value further down the line, so looked for an
alternative solution and came up with the following extending
StandardToStringStyle:-
import org.apache.commons.lang3.builder.StandardToStringStyle;
import org.apache.commons.lang3.builder.ToStringStyle;
import com.openpojo.business.annotation.BusinessKey;
import com.openpojo.business.exception.BusinessException;
public class CustomToStringStyle extends StandardToStringStyle {
public static final ToStringStyle OPENPOJO_SAFE_STYLE =
createOpenPojoSafeStyle();
/**
* Works better with {@link BusinessKey} annotated OpenPojo classes.
*
* This instance does not call {@link ToStringStyle}.register(...)
* which can throw a {@link BusinessException} if the key hasn't been
* populated, for example if you used the Null Object Pattern.
*/
private static ToStringStyle createOpenPojoSafeStyle() {
final StandardToStringStyle style = new StandardToStringStyle();
style.setUseClassName(false);
style.setUseIdentityHashCode(false);
return style;
}
}
Used as follows:
@Override
public String toString() {
return ToStringBuilder.reflectionToString(this,
CustomToStringStyle.OPENPOJO_SAFE_STYLE);
}
I realise this doesn't handle recursion in fields because it skips over
ToStringStyle.register(..) but this suffices for our use case right now -
perhaps an alternative implementation overriding register() that uses a List
(with documented performance penalty) could be added.
Is there anything already in Commons that could do this? If not we would like
this to be considered for inclusion in commons lang (happy to help out with
development), potentially with implementation improvements by those who know
the code base better.
> ToStringBuilder reliably handle OpenPojo @BusinessKey annotated instances
> -
>
> Key: LANG-985
> URL: https://issues.apache.org/jira/browse/LANG-985
> Project: Commons Lang
> Issue Type: Wish
> Components: lang.builder.*
>Reporter: D Green
[jira] [Updated] (LANG-985) ToStringBuilder reliably handle OpenPojo @BusinessKey annotated instances
[
https://issues.apache.org/jira/browse/LANG-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
D Green updated LANG-985:
-
Description:
We use Google's OpenPojo library, annotating DTOs and persistence entities with
@BusinessKey in order to remove boilerplate hashcode() and equals().
I recently started noticing toString() was throwing exceptions when I didn't
populate @BusinessKey annotated field(s) as I was using the Null Object
Pattern. A workaround was to populate dummy values but there's a risk this
could be considered a real value further down the line, so looked for an
alternative solution and came up with the following extending
StandardToStringStyle:-
{code}
import org.apache.commons.lang3.builder.StandardToStringStyle;
import org.apache.commons.lang3.builder.ToStringStyle;
import com.openpojo.business.annotation.BusinessKey;
import com.openpojo.business.exception.BusinessException;
public class CustomToStringStyle extends StandardToStringStyle {
public static final ToStringStyle OPENPOJO_SAFE_STYLE =
createOpenPojoSafeStyle();
/**
* Works better with {@link BusinessKey} annotated OpenPojo classes.
*
* This instance does not call {@link ToStringStyle}.register(...)
* which can throw a {@link BusinessException} if the key hasn't been
* populated, for example if you used the Null Object Pattern.
*/
private static ToStringStyle createOpenPojoSafeStyle() {
final StandardToStringStyle style = new StandardToStringStyle();
style.setUseClassName(false);
style.setUseIdentityHashCode(false);
return style;
}
}
{code}
Used as follows:
{code}
@Override
public String toString() {
return ToStringBuilder.reflectionToString(this,
CustomToStringStyle.OPENPOJO_SAFE_STYLE);
}
{code}
I realise this doesn't handle recursion in fields because it skips over
ToStringStyle.register(..) but this suffices for our use case right now -
perhaps an alternative implementation overriding register() that uses a List
(with documented performance penalty) could be added.
Is there anything already in Commons that could do this? If not we would like
this to be considered for inclusion in commons lang (happy to help out with
development), potentially with implementation improvements by those who know
the code base better.
was:
We use Google's OpenPojo library, annotating DTOs and persistence entities with
@BusinessKey in order to remove boilerplate hashcode() and equals().
I recently started noticing toString() was throwing exceptions when I didn't
populate @BusinessKey annotated field(s) as I was using the Null Object
Pattern. A workaround was to populate dummy values but there's a risk this
could be considered a real value further down the line, so looked for an
alternative solution and came up with the following extending
StandardToStringStyle:-
import org.apache.commons.lang3.builder.StandardToStringStyle;
import org.apache.commons.lang3.builder.ToStringStyle;
import com.openpojo.business.annotation.BusinessKey;
import com.openpojo.business.exception.BusinessException;
public class CustomToStringStyle extends StandardToStringStyle {
public static final ToStringStyle OPENPOJO_SAFE_STYLE =
createOpenPojoSafeStyle();
/**
* Works better with {@link BusinessKey} annotated OpenPojo classes.
*
* This instance does not call {@link ToStringStyle}.register(...)
* which can throw a {@link BusinessException} if the key hasn't been
* populated, for example if you used the Null Object Pattern.
*/
private static ToStringStyle createOpenPojoSafeStyle() {
final StandardToStringStyle style = new StandardToStringStyle();
style.setUseClassName(false);
style.setUseIdentityHashCode(false);
return style;
}
}
Used as follows:
{code}
@Override
public String toString() {
return ToStringBuilder.reflectionToString(this,
CustomToStringStyle.OPENPOJO_SAFE_STYLE);
}
{code}
I realise this doesn't handle recursion in fields because it skips over
ToStringStyle.register(..) but this suffices for our use case right now -
perhaps an alternative implementation overriding register() that uses a List
(with documented performance penalty) could be added.
Is there anything already in Commons that could do this? If not we would like
this to be considered for inclusion in commons lang (happy to help out with
development), potentially with implementation improvements by those who know
the code base better.
> ToStringBuilder reliably handle OpenPojo @BusinessKey annotated instances
> -
>
> Key: LANG-985
> URL: https://issues.apache.org/jira/browse/LANG-985
> Project: Commons Lang
> Issue Type: Wish
> Components: lang.builder.*
>
[jira] [Updated] (LANG-985) ToStringBuilder reliably handle OpenPojo @BusinessKey annotated instances
[
https://issues.apache.org/jira/browse/LANG-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Green updated LANG-985:
-
Description:
We use Google's OpenPojo library, annotating DTOs and persistence entities with
@BusinessKey in order to remove boilerplate hashcode() and equals().
I recently started noticing toString() was throwing exceptions when I didn't
populate @BusinessKey annotated field(s) as I was using the Null Object
Pattern. A workaround was to populate dummy values but there's a risk this
could be considered a real value further down the line, so looked for an
alternative solution and came up with the following extending
StandardToStringStyle:-
{code}
import org.apache.commons.lang3.builder.StandardToStringStyle;
import org.apache.commons.lang3.builder.ToStringStyle;
public class CustomToStringStyle extends StandardToStringStyle {
public static final ToStringStyle OPENPOJO_SAFE_STYLE =
createOpenPojoSafeStyle();
/**
* Works better with {@link com.openpojo.business.annotation.BusinessKey}
annotated OpenPojo classes.
*
* This instance does not call {@link ToStringStyle}.register(...)
* which can throw a {@link
com.openpojo.business.exception.BusinessException}
* if the key hasn't been populated, for example if you used the Null
Object Pattern.
*/
private static ToStringStyle createOpenPojoSafeStyle() {
final StandardToStringStyle style = new StandardToStringStyle();
style.setUseClassName(false);
style.setUseIdentityHashCode(false);
return style;
}
}
{code}
Used as follows:
{code}
@Override
public String toString() {
return ToStringBuilder.reflectionToString(this,
CustomToStringStyle.OPENPOJO_SAFE_STYLE);
}
{code}
I realise this doesn't handle recursion in fields because it skips over
ToStringStyle.register(..) but this suffices for our use case right now -
perhaps an alternative implementation overriding register() that uses a List
(with documented performance penalty) could be added.
Is there anything already in Commons that could do this? If not we would like
this to be considered for inclusion in commons lang (happy to help out with
development), potentially with implementation improvements by those who know
the code base better.
was:
We use Google's OpenPojo library, annotating DTOs and persistence entities with
@BusinessKey in order to remove boilerplate hashcode() and equals().
I recently started noticing toString() was throwing exceptions when I didn't
populate @BusinessKey annotated field(s) as I was using the Null Object
Pattern. A workaround was to populate dummy values but there's a risk this
could be considered a real value further down the line, so looked for an
alternative solution and came up with the following extending
StandardToStringStyle:-
{code}
import org.apache.commons.lang3.builder.StandardToStringStyle;
import org.apache.commons.lang3.builder.ToStringStyle;
import com.openpojo.business.annotation.BusinessKey;
import com.openpojo.business.exception.BusinessException;
public class CustomToStringStyle extends StandardToStringStyle {
public static final ToStringStyle OPENPOJO_SAFE_STYLE =
createOpenPojoSafeStyle();
/**
* Works better with {@link BusinessKey} annotated OpenPojo classes.
*
* This instance does not call {@link ToStringStyle}.register(...)
* which can throw a {@link BusinessException} if the key hasn't been
* populated, for example if you used the Null Object Pattern.
*/
private static ToStringStyle createOpenPojoSafeStyle() {
final StandardToStringStyle style = new StandardToStringStyle();
style.setUseClassName(false);
style.setUseIdentityHashCode(false);
return style;
}
}
{code}
Used as follows:
{code}
@Override
public String toString() {
return ToStringBuilder.reflectionToString(this,
CustomToStringStyle.OPENPOJO_SAFE_STYLE);
}
{code}
I realise this doesn't handle recursion in fields because it skips over
ToStringStyle.register(..) but this suffices for our use case right now -
perhaps an alternative implementation overriding register() that uses a List
(with documented performance penalty) could be added.
Is there anything already in Commons that could do this? If not we would like
this to be considered for inclusion in commons lang (happy to help out with
development), potentially with implementation improvements by those who know
the code base better.
> ToStringBuilder reliably handle OpenPojo @BusinessKey annotated instances
> -
>
> Key: LANG-985
> URL: https://issues.apache.org/jira/browse/LANG-985
> Project: Commons Lang
> Issue Type: Wish
> Components: lang.builder.*
>Reporter: D
[jira] [Commented] (LANG-1062) Use Java 8 features to improve EqualsBuilder
[
https://issues.apache.org/jira/browse/LANG-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14598514#comment-14598514
]
Alan Green commented on LANG-1062:
--
A couple of thoughts:
1. The attribute access functions could be applied to both objects in the
equality, so append only needs one argument:
{code}
return EqualsBuilder.test(this, obj).append(o -> o.id).isEquals();
{code}
2. It would make sense to provide a single function that accepts a collection
of attribute access functions:
{code}
return EqualsBuilder.test(this, obj).appendAll(Arrays.asList(o -> o.id, o ->
o.name, o -> o.color)).isEquals();
{code}
3. Since the common case is for hashCode and equality to work over the same
member attributes, they could share this list:
{code}
private static final List> EQUAL_ATTRS = Arrays.asList(o
-> o.id, o -> o.name, o -> o.color);
public boolean equals(final Object obj) {
return EqualsBuilder.test(this, obj).appendAll(EQUAL_ATTRS).isEquals();
}
public int hashCode() {
return HashCodeBuilder.for(this).appendAll(EQUAL_ATTRS).build();
}
{code}
> Use Java 8 features to improve EqualsBuilder
>
>
> Key: LANG-1062
> URL: https://issues.apache.org/jira/browse/LANG-1062
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.builder.*
>Affects Versions: 3.3.2
>Reporter: Bruce Brouwer
> Fix For: 4.0
>
>
> Remove the need for boilerplate code still necessary with EqualsBuilder.
> Instead of checking for instanceOf or equality checks, it would be nice to be
> able to write this:
> {code}
> public boolean equals(final Object obj) {
> return EqualsBuilder.test(this, obj).append(this.id, o -> o.id).isEquals();
> }
> {code}
> I think this could generally work with a subclass of EqualsBuilder with a
> generic type, like this:
> {code}
> public class LambdaEqualsBuilder extends EqualsBuilder {
> private final T obj;
> public LambdaEqualsBuilder(final T _this, final Object obj) {
> if (_this != obj && !_this.getClass().isInstance(obj)) {
> appendSuper(false);
> this.obj = null;
> } else {
> this.obj = (T) obj;
> }
> }
> public LambdaEqualsBuilder append(final P a, final Function
> b) {
> if (isEquals()) {
> return (LambdaEqualsBuilder) append(a, b.apply(obj));
> }
> return this;
> }
> // This might actually go in EqualsBuilder itself
> public static LambdaEqualsBuilder test(final E _this, final Object
> _that) {
> return new LambdaEqualsBuilder(_this, _that);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
