[jira] [Commented] (BCEL-195) addition of hashCode() to generic/Instruction.java breaks Targeters
[
https://issues.apache.org/jira/browse/BCEL-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329936#comment-14329936
]
Mark Roberts commented on BCEL-195:
---
I think it would not occur if there was no Instruction.equals as then
InstructionComparator would no longer be called.(?)
The initialization order issue is hidden in the super call to BranchInstruction
init
which calls setTarget
which calls notifyTarget
which calls addTargeter
which calls targeters.add
which calls the java runtime for HashSet
which leads back to Instruction.equals
which calls InstructionComparator.equals
which sees it has a Select and calls getTargets
which returns null as the rest of the select instruction fields have not been
set
and t1.length goes boom
I believe I never saw it before as we had the hash function commented out. You
probably never saw it due to lack of code coverage.
Given that (I believe) InstructionComparator is fixed, I think you want to
leave in Instruction.equals so that the simple instructions do get cached.
And after thinking about this some more to write this email - I'm wondering if
InstructionComparator should always return false for Select as well? The odds
of two identical switches located at different locations in the code is
probably close to zero. Certainly never happens in our exhaustive test suite.
What do you think?
Mark
> addition of hashCode() to generic/Instruction.java breaks Targeters
> ---
>
> Key: BCEL-195
> URL: https://issues.apache.org/jira/browse/BCEL-195
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 6.0
>Reporter: Mark Roberts
> Attachments: b195.diff
>
>
> [Revision 1532198|http://svn.apache.org/r1532198] added a {{hashCode()}}
> function to the Instruction class. Unfortunately, this breaks the
> Instruction targeting mechanism. I understand the goal of trying to reuse
> instructions - an 'iadd' is the same as any other 'iadd'. However, one
> 'goto 50' is not the same as another 'goto 50' due to the way Targeters are
> implemented. If branch instructions are reused, then only one entry gets put
> on the Targeter list. So when some api is used to modify the instruction
> list and location 50 becomes location 52 ONLY ONE of the branches gets
> updated. A very bad thing. So unless you modify the hash to special case
> branch instructions (and there might be other instructions needing special
> treatment as well) its broken. We fixed it by simply commenting the hash out
> to make things like they used to be and all works great.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (BCEL-161) InstructionTargeters not being properly cleaned up.
[
https://issues.apache.org/jira/browse/BCEL-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg resolved BCEL-161.
-
Resolution: Duplicate
Fix Version/s: 6.0
> InstructionTargeters not being properly cleaned up.
> ---
>
> Key: BCEL-161
> URL: https://issues.apache.org/jira/browse/BCEL-161
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 5.3
>Reporter: Thiago
>Assignee: Apache Commons Developers
>Priority: Minor
> Fix For: 6.0
>
> Attachments: patch.diff
>
>
> It seems that InstructionTargeters are not being properly cleaned up when
> they are not used anymore. That is, when a targeter is replaced or removed
> (e.g., a LocalVariableGen is removed from a method), the targeter remains in
> the targeters list of its targets.
> For example, MethodGen's constructor which receives a Method uses its other
> constructor to initialize the object:
> {code}
> public MethodGen(Method m, String class_name, ConstantPoolGen cp) {
>this(
>m.getAccessFlags(),
>Type.getReturnType(m.getSignature()),
>Type.getArgumentTypes(m.getSignature()),
>null /* may be overridden anyway */,
>m.getName(),
>class_name,
>((m.getAccessFlags() & (Constants.ACC_ABSTRACT |
> Constants.ACC_NATIVE)) == 0) ? new InstructionList(m.getCode().getCode()) :
> null, cp);
> ...
> }
> {code}
> Because this call passes null as its 4th argument, the constructor will
> create placeholder LocalVariableGen for the arguments (like arg0, arg1, etc).
> Later in this constructor the arguments will be overridden (as indicated by
> the comment). However, the LocalVariableGens of the placeholder arguments (as
> well as the LocalVariableGen for the "this" variable) will remain in the
> targeter lists of the first and last instructions of the instruction list.
> To avoid this problem I am submitting a patch in attachment. It adds a new
> method to InstructionTargeter:
> {code}
> /**
> * Removes all targets of this targeter.
> */
> void removeTargets();
> {code}
> and implements it to remove the targeter from the target's lists. The patch
> also calls removeTargets() when discarding targeters in MethodGen.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (BCEL-161) InstructionTargeters not being properly cleaned up.
[
https://issues.apache.org/jira/browse/BCEL-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg resolved BCEL-161.
-
Resolution: Duplicate
Fix Version/s: 6.0
> InstructionTargeters not being properly cleaned up.
> ---
>
> Key: BCEL-161
> URL: https://issues.apache.org/jira/browse/BCEL-161
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 5.3
>Reporter: Thiago
>Assignee: Apache Commons Developers
>Priority: Minor
> Fix For: 6.0
>
> Attachments: patch.diff
>
>
> It seems that InstructionTargeters are not being properly cleaned up when
> they are not used anymore. That is, when a targeter is replaced or removed
> (e.g., a LocalVariableGen is removed from a method), the targeter remains in
> the targeters list of its targets.
> For example, MethodGen's constructor which receives a Method uses its other
> constructor to initialize the object:
> {code}
> public MethodGen(Method m, String class_name, ConstantPoolGen cp) {
>this(
>m.getAccessFlags(),
>Type.getReturnType(m.getSignature()),
>Type.getArgumentTypes(m.getSignature()),
>null /* may be overridden anyway */,
>m.getName(),
>class_name,
>((m.getAccessFlags() & (Constants.ACC_ABSTRACT |
> Constants.ACC_NATIVE)) == 0) ? new InstructionList(m.getCode().getCode()) :
> null, cp);
> ...
> }
> {code}
> Because this call passes null as its 4th argument, the constructor will
> create placeholder LocalVariableGen for the arguments (like arg0, arg1, etc).
> Later in this constructor the arguments will be overridden (as indicated by
> the comment). However, the LocalVariableGens of the placeholder arguments (as
> well as the LocalVariableGen for the "this" variable) will remain in the
> targeter lists of the first and last instructions of the instruction list.
> To avoid this problem I am submitting a patch in attachment. It adds a new
> method to InstructionTargeter:
> {code}
> /**
> * Removes all targets of this targeter.
> */
> void removeTargets();
> {code}
> and implements it to remove the targeter from the target's lists. The patch
> also calls removeTargets() when discarding targeters in MethodGen.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BCEL-161) InstructionTargeters not being properly cleaned up.
[
https://issues.apache.org/jira/browse/BCEL-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329783#comment-14329783
]
Emmanuel Bourg commented on BCEL-161:
-
Thank you very much for the report Thiago. I didn't notice this issue before
fixing BCEL-207 with a very similar approach. I added a package private
{{dispose()}} method to {{LocalVariableGen}} which is called from
{{MethodGen.removeLocalVariable}}.
You suggested adding a call to {{this.removeLocalVariables()}} in the
{{MethodGen}} constructor, but if I'm not mistaken this is not necessary since
the method is already called bellow when the attributes are parsed and the
LocalVariableTable is encountered.
It seems the {{removeTargets()}} method in {{CodeExceptionGen}}, {{Select}} and
{{BranchInstruction}} aren't used so I'll pass on them for now, but I like the
idea.
I applied your documentation improvements to InstructionTargeter.
> InstructionTargeters not being properly cleaned up.
> ---
>
> Key: BCEL-161
> URL: https://issues.apache.org/jira/browse/BCEL-161
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 5.3
>Reporter: Thiago
>Assignee: Apache Commons Developers
>Priority: Minor
> Attachments: patch.diff
>
>
> It seems that InstructionTargeters are not being properly cleaned up when
> they are not used anymore. That is, when a targeter is replaced or removed
> (e.g., a LocalVariableGen is removed from a method), the targeter remains in
> the targeters list of its targets.
> For example, MethodGen's constructor which receives a Method uses its other
> constructor to initialize the object:
> {code}
> public MethodGen(Method m, String class_name, ConstantPoolGen cp) {
>this(
>m.getAccessFlags(),
>Type.getReturnType(m.getSignature()),
>Type.getArgumentTypes(m.getSignature()),
>null /* may be overridden anyway */,
>m.getName(),
>class_name,
>((m.getAccessFlags() & (Constants.ACC_ABSTRACT |
> Constants.ACC_NATIVE)) == 0) ? new InstructionList(m.getCode().getCode()) :
> null, cp);
> ...
> }
> {code}
> Because this call passes null as its 4th argument, the constructor will
> create placeholder LocalVariableGen for the arguments (like arg0, arg1, etc).
> Later in this constructor the arguments will be overridden (as indicated by
> the comment). However, the LocalVariableGens of the placeholder arguments (as
> well as the LocalVariableGen for the "this" variable) will remain in the
> targeter lists of the first and last instructions of the instruction list.
> To avoid this problem I am submitting a patch in attachment. It adds a new
> method to InstructionTargeter:
> {code}
> /**
> * Removes all targets of this targeter.
> */
> void removeTargets();
> {code}
> and implements it to remove the targeter from the target's lists. The patch
> also calls removeTargets() when discarding targeters in MethodGen.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BCEL-161) InstructionTargeters not being properly cleaned up.
[
https://issues.apache.org/jira/browse/BCEL-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329783#comment-14329783
]
Emmanuel Bourg commented on BCEL-161:
-
Thank you very much for the report Thiago. I didn't notice this issue before
fixing BCEL-207 with a very similar approach. I added a package private
{{dispose()}} method to {{LocalVariableGen}} which is called from
{{MethodGen.removeLocalVariable}}.
You suggested adding a call to {{this.removeLocalVariables()}} in the
{{MethodGen}} constructor, but if I'm not mistaken this is not necessary since
the method is already called bellow when the attributes are parsed and the
LocalVariableTable is encountered.
It seems the {{removeTargets()}} method in {{CodeExceptionGen}}, {{Select}} and
{{BranchInstruction}} aren't used so I'll pass on them for now, but I like the
idea.
I applied your documentation improvements to InstructionTargeter.
> InstructionTargeters not being properly cleaned up.
> ---
>
> Key: BCEL-161
> URL: https://issues.apache.org/jira/browse/BCEL-161
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 5.3
>Reporter: Thiago
>Assignee: Apache Commons Developers
>Priority: Minor
> Attachments: patch.diff
>
>
> It seems that InstructionTargeters are not being properly cleaned up when
> they are not used anymore. That is, when a targeter is replaced or removed
> (e.g., a LocalVariableGen is removed from a method), the targeter remains in
> the targeters list of its targets.
> For example, MethodGen's constructor which receives a Method uses its other
> constructor to initialize the object:
> {code}
> public MethodGen(Method m, String class_name, ConstantPoolGen cp) {
>this(
>m.getAccessFlags(),
>Type.getReturnType(m.getSignature()),
>Type.getArgumentTypes(m.getSignature()),
>null /* may be overridden anyway */,
>m.getName(),
>class_name,
>((m.getAccessFlags() & (Constants.ACC_ABSTRACT |
> Constants.ACC_NATIVE)) == 0) ? new InstructionList(m.getCode().getCode()) :
> null, cp);
> ...
> }
> {code}
> Because this call passes null as its 4th argument, the constructor will
> create placeholder LocalVariableGen for the arguments (like arg0, arg1, etc).
> Later in this constructor the arguments will be overridden (as indicated by
> the comment). However, the LocalVariableGens of the placeholder arguments (as
> well as the LocalVariableGen for the "this" variable) will remain in the
> targeter lists of the first and last instructions of the instruction list.
> To avoid this problem I am submitting a patch in attachment. It adds a new
> method to InstructionTargeter:
> {code}
> /**
> * Removes all targets of this targeter.
> */
> void removeTargets();
> {code}
> and implements it to remove the targeter from the target's lists. The patch
> also calls removeTargets() when discarding targeters in MethodGen.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1074) Add a method to ArrayUtils for removing all occurrences of a given element
[
https://issues.apache.org/jira/browse/LANG-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329589#comment-14329589
]
haiyang li commented on LANG-1074:
--
updated. please review
> Add a method to ArrayUtils for removing all occurrences of a given element
> --
>
> Key: LANG-1074
> URL: https://issues.apache.org/jira/browse/LANG-1074
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: haiyang li
>Priority: Minor
> Fix For: Review Patch
>
> Attachments: LANG-1074.patch.txt
>
>
> Could we add the method: removeElementAll to remove all the occurrences of
> the specified element from the specified
> (boolean/char/byte/short/int/long/float/double/Object) array:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
> public static T[] removeElementAll(final T[] array, final Object
> element) {
> int index = indexOf(array, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(array);
> }
> int[] indices = new int[array.length - index];
> int count = 0;
> indices[count++] = index;
> for (;;) {
> index = indexOf(array, element, ++index);
> if (index == INDEX_NOT_FOUND) {
> break;
> } else {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) array, Arrays.copyOfRange(indices, 0,
> count));
> }
> {code}
> or maybe better:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
>public static T[] removeElement(final T[] a, final Object element,
> boolean removeAll) {
> int index = indexOf(a, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(a);
> } else if (!removeAll || index >= a.length - 1) {
> return remove(a, index);
> } else {
> int[] indices = new int[a.length - index];
> int count = 0;
> indices[count++] = index++;
>
> for (int len = a.length; index < len; index++) {
> if ((a[index] == null) ? element == null : (element == null ?
> false : a[index].equals(element))) {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) a, Arrays.copyOfRange(indices, 0,
> count));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1074) Add a method to ArrayUtils for removing all occurrences of a given element
[
https://issues.apache.org/jira/browse/LANG-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haiyang li updated LANG-1074:
-
Attachment: LANG-1074.patch.txt
> Add a method to ArrayUtils for removing all occurrences of a given element
> --
>
> Key: LANG-1074
> URL: https://issues.apache.org/jira/browse/LANG-1074
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: haiyang li
>Priority: Minor
> Fix For: Review Patch
>
> Attachments: LANG-1074.patch.txt
>
>
> Could we add the method: removeElementAll to remove all the occurrences of
> the specified element from the specified
> (boolean/char/byte/short/int/long/float/double/Object) array:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
> public static T[] removeElementAll(final T[] array, final Object
> element) {
> int index = indexOf(array, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(array);
> }
> int[] indices = new int[array.length - index];
> int count = 0;
> indices[count++] = index;
> for (;;) {
> index = indexOf(array, element, ++index);
> if (index == INDEX_NOT_FOUND) {
> break;
> } else {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) array, Arrays.copyOfRange(indices, 0,
> count));
> }
> {code}
> or maybe better:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
>public static T[] removeElement(final T[] a, final Object element,
> boolean removeAll) {
> int index = indexOf(a, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(a);
> } else if (!removeAll || index >= a.length - 1) {
> return remove(a, index);
> } else {
> int[] indices = new int[a.length - index];
> int count = 0;
> indices[count++] = index++;
>
> for (int len = a.length; index < len; index++) {
> if ((a[index] == null) ? element == null : (element == null ?
> false : a[index].equals(element))) {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) a, Arrays.copyOfRange(indices, 0,
> count));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1074) Add a method to ArrayUtils for removing all occurrences of a given element
[
https://issues.apache.org/jira/browse/LANG-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haiyang li updated LANG-1074:
-
Attachment: (was: LANG-1074.patch.txt)
> Add a method to ArrayUtils for removing all occurrences of a given element
> --
>
> Key: LANG-1074
> URL: https://issues.apache.org/jira/browse/LANG-1074
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: haiyang li
>Priority: Minor
> Fix For: Review Patch
>
>
> Could we add the method: removeElementAll to remove all the occurrences of
> the specified element from the specified
> (boolean/char/byte/short/int/long/float/double/Object) array:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
> public static T[] removeElementAll(final T[] array, final Object
> element) {
> int index = indexOf(array, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(array);
> }
> int[] indices = new int[array.length - index];
> int count = 0;
> indices[count++] = index;
> for (;;) {
> index = indexOf(array, element, ++index);
> if (index == INDEX_NOT_FOUND) {
> break;
> } else {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) array, Arrays.copyOfRange(indices, 0,
> count));
> }
> {code}
> or maybe better:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
>public static T[] removeElement(final T[] a, final Object element,
> boolean removeAll) {
> int index = indexOf(a, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(a);
> } else if (!removeAll || index >= a.length - 1) {
> return remove(a, index);
> } else {
> int[] indices = new int[a.length - index];
> int count = 0;
> indices[count++] = index++;
>
> for (int len = a.length; index < len; index++) {
> if ((a[index] == null) ? element == null : (element == null ?
> false : a[index].equals(element))) {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) a, Arrays.copyOfRange(indices, 0,
> count));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1074) Add a method to ArrayUtils for removing all occurrences of a given element
[
https://issues.apache.org/jira/browse/LANG-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haiyang li updated LANG-1074:
-
Attachment: LANG-1074.patch.txt
> Add a method to ArrayUtils for removing all occurrences of a given element
> --
>
> Key: LANG-1074
> URL: https://issues.apache.org/jira/browse/LANG-1074
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: haiyang li
>Priority: Minor
> Fix For: Review Patch
>
>
> Could we add the method: removeElementAll to remove all the occurrences of
> the specified element from the specified
> (boolean/char/byte/short/int/long/float/double/Object) array:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
> public static T[] removeElementAll(final T[] array, final Object
> element) {
> int index = indexOf(array, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(array);
> }
> int[] indices = new int[array.length - index];
> int count = 0;
> indices[count++] = index;
> for (;;) {
> index = indexOf(array, element, ++index);
> if (index == INDEX_NOT_FOUND) {
> break;
> } else {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) array, Arrays.copyOfRange(indices, 0,
> count));
> }
> {code}
> or maybe better:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
>public static T[] removeElement(final T[] a, final Object element,
> boolean removeAll) {
> int index = indexOf(a, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(a);
> } else if (!removeAll || index >= a.length - 1) {
> return remove(a, index);
> } else {
> int[] indices = new int[a.length - index];
> int count = 0;
> indices[count++] = index++;
>
> for (int len = a.length; index < len; index++) {
> if ((a[index] == null) ? element == null : (element == null ?
> false : a[index].equals(element))) {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) a, Arrays.copyOfRange(indices, 0,
> count));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1074) Add a method to ArrayUtils for removing all occurrences of a given element
[
https://issues.apache.org/jira/browse/LANG-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haiyang li updated LANG-1074:
-
Attachment: (was: LANG-1074.patch.txt)
> Add a method to ArrayUtils for removing all occurrences of a given element
> --
>
> Key: LANG-1074
> URL: https://issues.apache.org/jira/browse/LANG-1074
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: haiyang li
>Priority: Minor
> Fix For: Review Patch
>
>
> Could we add the method: removeElementAll to remove all the occurrences of
> the specified element from the specified
> (boolean/char/byte/short/int/long/float/double/Object) array:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
> public static T[] removeElementAll(final T[] array, final Object
> element) {
> int index = indexOf(array, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(array);
> }
> int[] indices = new int[array.length - index];
> int count = 0;
> indices[count++] = index;
> for (;;) {
> index = indexOf(array, element, ++index);
> if (index == INDEX_NOT_FOUND) {
> break;
> } else {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) array, Arrays.copyOfRange(indices, 0,
> count));
> }
> {code}
> or maybe better:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
>public static T[] removeElement(final T[] a, final Object element,
> boolean removeAll) {
> int index = indexOf(a, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(a);
> } else if (!removeAll || index >= a.length - 1) {
> return remove(a, index);
> } else {
> int[] indices = new int[a.length - index];
> int count = 0;
> indices[count++] = index++;
>
> for (int len = a.length; index < len; index++) {
> if ((a[index] == null) ? element == null : (element == null ?
> false : a[index].equals(element))) {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) a, Arrays.copyOfRange(indices, 0,
> count));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BCEL-195) addition of hashCode() to generic/Instruction.java breaks Targeters
[
https://issues.apache.org/jira/browse/BCEL-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329485#comment-14329485
]
Emmanuel Bourg commented on BCEL-195:
-
Thank you Mark. Could you explain the issue with the Select initialization?
Does it occur when {{Instruction.equals()}} is removed? I'd like to cover that
with a test.
> addition of hashCode() to generic/Instruction.java breaks Targeters
> ---
>
> Key: BCEL-195
> URL: https://issues.apache.org/jira/browse/BCEL-195
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 6.0
>Reporter: Mark Roberts
> Attachments: b195.diff
>
>
> [Revision 1532198|http://svn.apache.org/r1532198] added a {{hashCode()}}
> function to the Instruction class. Unfortunately, this breaks the
> Instruction targeting mechanism. I understand the goal of trying to reuse
> instructions - an 'iadd' is the same as any other 'iadd'. However, one
> 'goto 50' is not the same as another 'goto 50' due to the way Targeters are
> implemented. If branch instructions are reused, then only one entry gets put
> on the Targeter list. So when some api is used to modify the instruction
> list and location 50 becomes location 52 ONLY ONE of the branches gets
> updated. A very bad thing. So unless you modify the hash to special case
> branch instructions (and there might be other instructions needing special
> treatment as well) its broken. We fixed it by simply commenting the hash out
> to make things like they used to be and all works great.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BCEL-195) addition of hashCode() to generic/Instruction.java breaks Targeters
[
https://issues.apache.org/jira/browse/BCEL-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329454#comment-14329454
]
Mark Roberts commented on BCEL-195:
---
Okay - thanks for the pointer to InstructionComparator. I have tested and
prepared a new patch for this problem. Instruction.hash and Instruction.equal
are left untouched. InstructionComparator is modified to always say two branch
instructions are not equal. This fix exposed another problem in the order of
initialization for Select instructions. A fix for that is included as well.
> addition of hashCode() to generic/Instruction.java breaks Targeters
> ---
>
> Key: BCEL-195
> URL: https://issues.apache.org/jira/browse/BCEL-195
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 6.0
>Reporter: Mark Roberts
> Attachments: b195.diff
>
>
> [Revision 1532198|http://svn.apache.org/r1532198] added a {{hashCode()}}
> function to the Instruction class. Unfortunately, this breaks the
> Instruction targeting mechanism. I understand the goal of trying to reuse
> instructions - an 'iadd' is the same as any other 'iadd'. However, one
> 'goto 50' is not the same as another 'goto 50' due to the way Targeters are
> implemented. If branch instructions are reused, then only one entry gets put
> on the Targeter list. So when some api is used to modify the instruction
> list and location 50 becomes location 52 ONLY ONE of the branches gets
> updated. A very bad thing. So unless you modify the hash to special case
> branch instructions (and there might be other instructions needing special
> treatment as well) its broken. We fixed it by simply commenting the hash out
> to make things like they used to be and all works great.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (BCEL-195) addition of hashCode() to generic/Instruction.java breaks Targeters
[
https://issues.apache.org/jira/browse/BCEL-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Roberts updated BCEL-195:
--
Attachment: b195.diff
> addition of hashCode() to generic/Instruction.java breaks Targeters
> ---
>
> Key: BCEL-195
> URL: https://issues.apache.org/jira/browse/BCEL-195
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 6.0
>Reporter: Mark Roberts
> Attachments: b195.diff
>
>
> [Revision 1532198|http://svn.apache.org/r1532198] added a {{hashCode()}}
> function to the Instruction class. Unfortunately, this breaks the
> Instruction targeting mechanism. I understand the goal of trying to reuse
> instructions - an 'iadd' is the same as any other 'iadd'. However, one
> 'goto 50' is not the same as another 'goto 50' due to the way Targeters are
> implemented. If branch instructions are reused, then only one entry gets put
> on the Targeter list. So when some api is used to modify the instruction
> list and location 50 becomes location 52 ONLY ONE of the branches gets
> updated. A very bad thing. So unless you modify the hash to special case
> branch instructions (and there might be other instructions needing special
> treatment as well) its broken. We fixed it by simply commenting the hash out
> to make things like they used to be and all works great.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BCEL-195) addition of hashCode() to generic/Instruction.java breaks Targeters
[
https://issues.apache.org/jira/browse/BCEL-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329229#comment-14329229
]
Mark Roberts commented on BCEL-195:
---
so you're suggesting I try turning Instruction.hashCode() back on and removing
Instruction.equals() instead? I can try that with our test set. Does
InstructionComparator.equals get used by the HashSet.add()
method? If so, maybe the soulution is to change the (applicable part of) the
code to {code}
} else if (i1 instanceof BranchInstruction) {
return false;
} else if
{code}
> addition of hashCode() to generic/Instruction.java breaks Targeters
> ---
>
> Key: BCEL-195
> URL: https://issues.apache.org/jira/browse/BCEL-195
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 6.0
>Reporter: Mark Roberts
>
> [Revision 1532198|http://svn.apache.org/r1532198] added a {{hashCode()}}
> function to the Instruction class. Unfortunately, this breaks the
> Instruction targeting mechanism. I understand the goal of trying to reuse
> instructions - an 'iadd' is the same as any other 'iadd'. However, one
> 'goto 50' is not the same as another 'goto 50' due to the way Targeters are
> implemented. If branch instructions are reused, then only one entry gets put
> on the Targeter list. So when some api is used to modify the instruction
> list and location 50 becomes location 52 ONLY ONE of the branches gets
> updated. A very bad thing. So unless you modify the hash to special case
> branch instructions (and there might be other instructions needing special
> treatment as well) its broken. We fixed it by simply commenting the hash out
> to make things like they used to be and all works great.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1205) AbstractStorelessUnivariateStatistic should not extend AbstractUnivariateStatistic
[
https://issues.apache.org/jira/browse/MATH-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329170#comment-14329170
]
Phil Steitz commented on MATH-1205:
---
+1 to fix this for 4.x
> AbstractStorelessUnivariateStatistic should not extend
> AbstractUnivariateStatistic
> --
>
> Key: MATH-1205
> URL: https://issues.apache.org/jira/browse/MATH-1205
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Thomas Neidhart
>
> For a storeless statistic it is wrong to extend AbstractUnivariateStatistic
> as various fields and methods are inherited that do not make sense in case of
> a storeless statistic.
> This means a user can accidentially use a storeless statistic in a wrong way:
> {code}
> Mean mean = new Mean();
>
> mean.increment(1);
> mean.increment(2);
>
> mean.setData(new double[] { 1, 2, 3});
>
> System.out.println(mean.getResult());
> System.out.println(mean.evaluate());
> {code}
> will output
> {noformat}
> 1.5
> 2.0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (BCEL-195) addition of hashCode() to generic/Instruction.java breaks Targeters
[
https://issues.apache.org/jira/browse/BCEL-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg updated BCEL-195:
Affects Version/s: 6.0
> addition of hashCode() to generic/Instruction.java breaks Targeters
> ---
>
> Key: BCEL-195
> URL: https://issues.apache.org/jira/browse/BCEL-195
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 6.0
>Reporter: Mark Roberts
>
> [Revision 1532198|http://svn.apache.org/r1532198] added a {{hashCode()}}
> function to the Instruction class. Unfortunately, this breaks the
> Instruction targeting mechanism. I understand the goal of trying to reuse
> instructions - an 'iadd' is the same as any other 'iadd'. However, one
> 'goto 50' is not the same as another 'goto 50' due to the way Targeters are
> implemented. If branch instructions are reused, then only one entry gets put
> on the Targeter list. So when some api is used to modify the instruction
> list and location 50 becomes location 52 ONLY ONE of the branches gets
> updated. A very bad thing. So unless you modify the hash to special case
> branch instructions (and there might be other instructions needing special
> treatment as well) its broken. We fixed it by simply commenting the hash out
> to make things like they used to be and all works great.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BCEL-195) addition of hashCode() to generic/Instruction.java breaks Targeters
[
https://issues.apache.org/jira/browse/BCEL-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329160#comment-14329160
]
Emmanuel Bourg commented on BCEL-195:
-
Ok let me recap:
- {{InstructionHandler}} contains a {{Set}} of {{InstructionTarget}}. If the
same targeter is added twice it's referenced only once
- The {{BranchInstruction}} hierarchy implements {{InstructionTarget}} and
inherit the equals/hashCode methods from the base abstract {{Instruction}} class
- Before r1532198 the {{Instruction}} class defined the {{equals()}} method but
not {{hashCode()}}. Thus two instructions that were equal didn't have the same
hashcode. This was a violation of the equals/hashCode contract (equal objects
must have the same hashcode).
- This flaw allowed two distinct but equal instances of a {{BranchInstruction}}
to be listed as targeters of the same {{InstructionHandler}}, because the
{{HashSet}} holding the targeters checks the hashcode before calling
{{equals()}} to detect if it already contains the element.
- The addition of {{Instruction.hashCode()}} in r1532198 fixed this flaw but
had the side effect of "merging" equal but different {{BranchInstructions}} in
the set of targeters.
The issue here is not {{Instruction.hashCode()}} which is correct, but the
{{equals()}} implementation that is wrong. I agree with you that two GOTO 50
shouldn't be considered equal, it doesn't make sense for flow instructions. The
question is, do we even need this {{equals()}} method? What is it really used
for? I removed it and no test complained (but we have a poor coverage). I'm
pondering if I should either remove it (instruction equality can still be
checked with {{InstructionComparator}}) or just remove the code related to
{{BranchInstruction}} from {{InstructionComparator}}.
> addition of hashCode() to generic/Instruction.java breaks Targeters
> ---
>
> Key: BCEL-195
> URL: https://issues.apache.org/jira/browse/BCEL-195
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Reporter: Mark Roberts
>
> [Revision 1532198|http://svn.apache.org/r1532198] added a {{hashCode()}}
> function to the Instruction class. Unfortunately, this breaks the
> Instruction targeting mechanism. I understand the goal of trying to reuse
> instructions - an 'iadd' is the same as any other 'iadd'. However, one
> 'goto 50' is not the same as another 'goto 50' due to the way Targeters are
> implemented. If branch instructions are reused, then only one entry gets put
> on the Targeter list. So when some api is used to modify the instruction
> list and location 50 becomes location 52 ONLY ONE of the branches gets
> updated. A very bad thing. So unless you modify the hash to special case
> branch instructions (and there might be other instructions needing special
> treatment as well) its broken. We fixed it by simply commenting the hash out
> to make things like they used to be and all works great.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (COMPRESS-308) ZipEncodingHelper calls System.getProperty("file.encoding"); should use Charset.defaultCharset()
[
https://issues.apache.org/jira/browse/COMPRESS-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-308.
-
Resolution: Fixed
Fix Version/s: 1.10
fixed with svn revision 1661157
> ZipEncodingHelper calls System.getProperty("file.encoding"); should use
> Charset.defaultCharset()
>
>
> Key: COMPRESS-308
> URL: https://issues.apache.org/jira/browse/COMPRESS-308
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Sebb
>Priority: Minor
> Fix For: 1.10
>
>
> ZipEncodingHelper calls System.getProperty("file.encoding")
> However this can fail with a security exception.
> It should use Charset.defaultCharset() instead.
> This method also uses System.getProperty but does so as part of a
> doPrivileged block.
> AIUI this will be done in the protection domain of the JVM classes rather
> than the domain in which the Compress code runs, so should be less likely to
> fail.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BCEL-211) Some additional clone methods should be public.
[ https://issues.apache.org/jira/browse/BCEL-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329145#comment-14329145 ] Mark Roberts commented on BCEL-211: --- Yes - _this represents the 'this' pointer of the current method being symbolically executed. It is part of the current state of program execution. > Some additional clone methods should be public. > --- > > Key: BCEL-211 > URL: https://issues.apache.org/jira/browse/BCEL-211 > Project: Commons BCEL > Issue Type: Improvement >Reporter: Mark Roberts > Attachments: publics.diff > > > For a user program to inspect the current state of program execution, the > clone methods of Frame, LocalVariables and OperandStack need to be public. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (LANG-1069) CharSet.getInstance documentation does not clearly explain how to include negation character in set
[
https://issues.apache.org/jira/browse/LANG-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329129#comment-14329129
]
Arno Noordover edited comment on LANG-1069 at 2/20/15 4:31 PM:
---
I tried to show with this example that parsing is executed from left to right.
So the set containing a ^ is negated. The second ^ could also negate the set
containing a-d and then interpreting the first ^ in some undefined way.
was (Author: anoordover):
I tried to show with this example that parsing is execute from left to right.
So the set containing a ^ is negated. The second ^ could also negate the set
containing a-d and then interpreting the first ^ in some undefined way.
> CharSet.getInstance documentation does not clearly explain how to include
> negation character in set
> ---
>
> Key: LANG-1069
> URL: https://issues.apache.org/jira/browse/LANG-1069
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: Duncan Jones
>Priority: Minor
> Fix For: Review Patch
>
> Attachments: CharSet-1069.patch
>
>
> As discussed in [this Stack Overflow
> question|http://stackoverflow.com/questions/27070515/how-can-i-include-the-caret-character-in-an-apache-commons-charset],
> the documentation for {{CharSet.getInstance()}} don't explain clearly how to
> include the negation character ({{^}}) as a literal character.
> The two solutions suggested in the SO question are:
> {code:java}
> // Add the '^' on its own
> CharSet.getInstance("^", "otherlettershere");
> // Add the '^' as the last character
> CharSet.getInstance("otherlettershere^")
> {code}
> If those are the best options, we should add a line to the Javadoc to
> indicate this. If there is a better way, clearly that should be documented
> instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1069) CharSet.getInstance documentation does not clearly explain how to include negation character in set
[
https://issues.apache.org/jira/browse/LANG-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329129#comment-14329129
]
Arno Noordover commented on LANG-1069:
--
I tried to show with this example that parsing is execute from left to right.
So the set containing a ^ is negated. The second ^ could also negate the set
containing a-d and then interpreting the first ^ in some undefined way.
> CharSet.getInstance documentation does not clearly explain how to include
> negation character in set
> ---
>
> Key: LANG-1069
> URL: https://issues.apache.org/jira/browse/LANG-1069
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: Duncan Jones
>Priority: Minor
> Fix For: Review Patch
>
> Attachments: CharSet-1069.patch
>
>
> As discussed in [this Stack Overflow
> question|http://stackoverflow.com/questions/27070515/how-can-i-include-the-caret-character-in-an-apache-commons-charset],
> the documentation for {{CharSet.getInstance()}} don't explain clearly how to
> include the negation character ({{^}}) as a literal character.
> The two solutions suggested in the SO question are:
> {code:java}
> // Add the '^' on its own
> CharSet.getInstance("^", "otherlettershere");
> // Add the '^' as the last character
> CharSet.getInstance("otherlettershere^")
> {code}
> If those are the best options, we should add a line to the Javadoc to
> indicate this. If there is a better way, clearly that should be documented
> instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (POOL-288) Objects growing out of bound (beyond max limit)
[ https://issues.apache.org/jira/browse/POOL-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329125#comment-14329125 ] Phil Steitz commented on POOL-288: -- If objects fail activation, they will be destroyed and replaced by new ones. You should do the following: 1. Upgrade at least to 1.5.7 (if you have to have binary compat with 1.5.4 or ancient JDK). Better is pool 2.x (note some configs have changed - see website and changelog). 2. Put your counters in the factory makeObject and destroyObject methods. > Objects growing out of bound (beyond max limit) > --- > > Key: POOL-288 > URL: https://issues.apache.org/jira/browse/POOL-288 > Project: Commons Pool > Issue Type: Bug >Reporter: Abin > > My messaging application is a stand-alone spring boot application. I am > maintaining an apache commons pool of smpp sessions to be kept alive and used > when needed. But the pool starts to grow beyond its max limit. I have > explained my application design below. Any help/suggestion would be greatly > appreciated. > Current Design > I have an object pool of type ZdSmppSession (Apache Commons Pool), with pool > size set to 40 > Each ZdSmppSession has the following > 1. A sendMessage method > 2. A private variable of type com.cloudhopper.smpp.SmppSession > 3. A PostConstruct method > The Post Construct method does the following > 1. initiates a handshake and initialize the private variable > com.cloudhopper.smpp.SmppSession > 2. schedules an enquire link to be sent every 60 secs > I have about 120 worker threads which does the following > 1. Read message from rmq > 2. Get a ZdSmppSession object from pool > 3. Calls sendMessage on the object > 4. Release it back to pool > So when a ZdSmppSession object is created in the pool it is ready to send > messages > When ZdSmppSession is released back to pool it keeps the connection alive by > sending enquire link every 60 secs. A session object is never destructed. > Issue > The issue I am facing is that the pool grows beyond its maximum limit, even > though the max limit is set to 40. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (COMPRESS-309) BZip2CompressorInputStream return value wrong when told to read to a full buffer.
[
https://issues.apache.org/jira/browse/COMPRESS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-309.
-
Resolution: Fixed
Fix Version/s: 1.10
fixed with svn revision 1661151 - thanks!
> BZip2CompressorInputStream return value wrong when told to read to a full
> buffer.
> -
>
> Key: COMPRESS-309
> URL: https://issues.apache.org/jira/browse/COMPRESS-309
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.4.1, 1.9
>Reporter: Nathan Kronenfeld
> Labels: bzip2, compression
> Fix For: 1.10
>
>
> BZip2CompressorInputStream.read(buffer, offset, length) returns -1 when given
> an offset equal to the length of the buffer.
> This indicates, not that the buffer was full, but that the stream was
> finished.
> It seems like a pretty stupid thing to do - but I'm getting this when trying
> to use Kryo serialization (which is probably a bug on their part, too), so it
> does occur and has negative affects.
> Here's a JUnit test that shows the problem specifically:
> {noformat}
> @Test
> public void testApacheCommonsBZipUncompression () throws Exception {
> // Create a big random piece of data
> byte[] rawData = new byte[1048576];
> for (int i=0; i rawData[i] = (byte) Math.floor(Math.random()*256);
> }
> // Compress it
> ByteArrayOutputStream baos = new ByteArrayOutputStream();
> BZip2CompressorOutputStream bzipOut = new
> BZip2CompressorOutputStream(baos);
> bzipOut.write(rawData);
> bzipOut.flush();
> bzipOut.close();
> baos.flush();
> baos.close();
> // Try to read it back in
> ByteArrayInputStream bais = new
> ByteArrayInputStream(baos.toByteArray());
> BZip2CompressorInputStream bzipIn = new
> BZip2CompressorInputStream(bais);
> byte[] buffer = new byte[1024];
> // Works fine
> Assert.assertEquals(1024, bzipIn.read(buffer, 0, 1024));
> // Fails, returns -1 (indicating the stream is complete rather
> than that the buffer
> // was full)
> Assert.assertEquals(0, bzipIn.read(buffer, 1024, 0));
> // But if you change the above expected value to -1, the
> following line still works
> Assert.assertEquals(1024, bzipIn.read(buffer, 0, 1024));
> bzipIn.close();
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1065) Merge date and time together
[ https://issues.apache.org/jira/browse/LANG-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329097#comment-14329097 ] Paul Benedict commented on LANG-1065: - I don't know the average frequency of contributors on other tickets, but I think 2 people and a test is good community participation on a minor issue. Please do what you feel is best. > Merge date and time together > > > Key: LANG-1065 > URL: https://issues.apache.org/jira/browse/LANG-1065 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Paul Benedict >Priority: Minor > Fix For: Review Patch > > Original Estimate: 1h > Remaining Estimate: 1h > > I have 2 java.util.Date objects -- one with the correct date and one with the > correct time. This enhancement will create a new method to apply the > respective fragments to a new java.util.Date instance. > Possible signature: > public static Date merge(Date date, Date time); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (POOL-288) Objects growing out of bound (beyond max limit)
[ https://issues.apache.org/jira/browse/POOL-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329075#comment-14329075 ] Abin commented on POOL-288: --- Pool version : commons-pool-1.5.4.jar My counter is in the constructor of ZdSmppSession which is the pooled object. Pool config : This is the spring config for CommonsPoolTargetSource. With this config it should not create more than 40 objects, which it is doing One observation I made is that this does not happen when i do not call submit() method in the cloudhopper library. com.cloudhopper.smpp.SmppSession.submit(x, y); > Objects growing out of bound (beyond max limit) > --- > > Key: POOL-288 > URL: https://issues.apache.org/jira/browse/POOL-288 > Project: Commons Pool > Issue Type: Bug >Reporter: Abin > > My messaging application is a stand-alone spring boot application. I am > maintaining an apache commons pool of smpp sessions to be kept alive and used > when needed. But the pool starts to grow beyond its max limit. I have > explained my application design below. Any help/suggestion would be greatly > appreciated. > Current Design > I have an object pool of type ZdSmppSession (Apache Commons Pool), with pool > size set to 40 > Each ZdSmppSession has the following > 1. A sendMessage method > 2. A private variable of type com.cloudhopper.smpp.SmppSession > 3. A PostConstruct method > The Post Construct method does the following > 1. initiates a handshake and initialize the private variable > com.cloudhopper.smpp.SmppSession > 2. schedules an enquire link to be sent every 60 secs > I have about 120 worker threads which does the following > 1. Read message from rmq > 2. Get a ZdSmppSession object from pool > 3. Calls sendMessage on the object > 4. Release it back to pool > So when a ZdSmppSession object is created in the pool it is ready to send > messages > When ZdSmppSession is released back to pool it keeps the connection alive by > sending enquire link every 60 secs. A session object is never destructed. > Issue > The issue I am facing is that the pool grows beyond its maximum limit, even > though the max limit is set to 40. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (POOL-288) Objects growing out of bound (beyond max limit)
[ https://issues.apache.org/jira/browse/POOL-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329052#comment-14329052 ] Phil Steitz commented on POOL-288: -- What version of pool? Please provide the full pool config. I assume the counter is in the makeObject method of the factory? Do you also count destroyObject calls? > Objects growing out of bound (beyond max limit) > --- > > Key: POOL-288 > URL: https://issues.apache.org/jira/browse/POOL-288 > Project: Commons Pool > Issue Type: Bug >Reporter: Abin > > My messaging application is a stand-alone spring boot application. I am > maintaining an apache commons pool of smpp sessions to be kept alive and used > when needed. But the pool starts to grow beyond its max limit. I have > explained my application design below. Any help/suggestion would be greatly > appreciated. > Current Design > I have an object pool of type ZdSmppSession (Apache Commons Pool), with pool > size set to 40 > Each ZdSmppSession has the following > 1. A sendMessage method > 2. A private variable of type com.cloudhopper.smpp.SmppSession > 3. A PostConstruct method > The Post Construct method does the following > 1. initiates a handshake and initialize the private variable > com.cloudhopper.smpp.SmppSession > 2. schedules an enquire link to be sent every 60 secs > I have about 120 worker threads which does the following > 1. Read message from rmq > 2. Get a ZdSmppSession object from pool > 3. Calls sendMessage on the object > 4. Release it back to pool > So when a ZdSmppSession object is created in the pool it is ready to send > messages > When ZdSmppSession is released back to pool it keeps the connection alive by > sending enquire link every 60 secs. A session object is never destructed. > Issue > The issue I am facing is that the pool grows beyond its maximum limit, even > though the max limit is set to 40. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (BCEL-195) addition of hashCode() to generic/Instruction.java breaks Targeters
[
https://issues.apache.org/jira/browse/BCEL-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg updated BCEL-195:
Description: [Revision 1532198|http://svn.apache.org/r1532198] added a
{{hashCode()}} function to the Instruction class. Unfortunately, this breaks
the Instruction targeting mechanism. I understand the goal of trying to reuse
instructions - an 'iadd' is the same as any other 'iadd'. However, one 'goto
50' is not the same as another 'goto 50' due to the way Targeters are
implemented. If branch instructions are reused, then only one entry gets put
on the Targeter list. So when some api is used to modify the instruction list
and location 50 becomes location 52 ONLY ONE of the branches gets updated. A
very bad thing. So unless you modify the hash to special case branch
instructions (and there might be other instructions needing special treatment
as well) its broken. We fixed it by simply commenting the hash out to make
things like they used to be and all works great. (was: revision 1532198 added
a hashCode() function to the Instruction class. Unfortunately, this breaks the
Instruction targeting mechanism. I understand the goal of trying to reuse
instructions - an 'iadd' is the same as any other 'iadd'. However, one 'goto
50' is not the same as another 'goto 50' due to the way Targeters are
implemented. If branch instructions are reused, then only one entry gets put
on the Targeter list. So when some api is used to modify the instruction list
and location 50 becomes location 52 ONLY ONE of the branches gets updated. A
very bad thing. So unless you modify the hash to special case branch
instructions (and there might be other instructions needing special treatment
as well) its broken. We fixed it by simply commenting the hash out to make
things like they used to be and all works great.)
> addition of hashCode() to generic/Instruction.java breaks Targeters
> ---
>
> Key: BCEL-195
> URL: https://issues.apache.org/jira/browse/BCEL-195
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Reporter: Mark Roberts
>
> [Revision 1532198|http://svn.apache.org/r1532198] added a {{hashCode()}}
> function to the Instruction class. Unfortunately, this breaks the
> Instruction targeting mechanism. I understand the goal of trying to reuse
> instructions - an 'iadd' is the same as any other 'iadd'. However, one
> 'goto 50' is not the same as another 'goto 50' due to the way Targeters are
> implemented. If branch instructions are reused, then only one entry gets put
> on the Targeter list. So when some api is used to modify the instruction
> list and location 50 becomes location 52 ONLY ONE of the branches gets
> updated. A very bad thing. So unless you modify the hash to special case
> branch instructions (and there might be other instructions needing special
> treatment as well) its broken. We fixed it by simply commenting the hash out
> to make things like they used to be and all works great.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BCEL-211) Some additional clone methods should be public.
[
https://issues.apache.org/jira/browse/BCEL-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329045#comment-14329045
]
Emmanuel Bourg commented on BCEL-211:
-
The patch also makes the {{_this}} variable in the {{Frame}} class public, is
this intended?
> Some additional clone methods should be public.
> ---
>
> Key: BCEL-211
> URL: https://issues.apache.org/jira/browse/BCEL-211
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Mark Roberts
> Attachments: publics.diff
>
>
> For a user program to inspect the current state of program execution, the
> clone methods of Frame, LocalVariables and OperandStack need to be public.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (BCEL-207) RemoveLocalVariable(s) doesn't remove the associated Targetters.
[ https://issues.apache.org/jira/browse/BCEL-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved BCEL-207. - Resolution: Fixed Fix Version/s: 6.0 This is now fixed on the trunk and I added a test case. Thank you Mark. > RemoveLocalVariable(s) doesn't remove the associated Targetters. > > > Key: BCEL-207 > URL: https://issues.apache.org/jira/browse/BCEL-207 > Project: Commons BCEL > Issue Type: Bug >Reporter: Mark Roberts > Fix For: 6.0 > > Attachments: methodgen3.diff > > > RemoveLocalVariable(s) doesn't remove the associated Targetters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (BCEL-207) RemoveLocalVariable(s) doesn't remove the associated Targetters.
[ https://issues.apache.org/jira/browse/BCEL-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328942#comment-14328942 ] Mark Roberts commented on BCEL-207: --- oh, I see - you are talking about re-factoring the code. In that case, why not just have removeLocalVariables call removeLocalVariable within the loop instead of the notifyTarget(s). Originially, I was worried about the performance of n variable_vec.remove(s) versus a single variable_vec.clear - but I suspect that in the vast majority of cases the number of locals would be fairly small. > RemoveLocalVariable(s) doesn't remove the associated Targetters. > > > Key: BCEL-207 > URL: https://issues.apache.org/jira/browse/BCEL-207 > Project: Commons BCEL > Issue Type: Bug >Reporter: Mark Roberts > Attachments: methodgen3.diff > > > RemoveLocalVariable(s) doesn't remove the associated Targetters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (POOL-288) Objects growing out of bound (beyond max limit)
[ https://issues.apache.org/jira/browse/POOL-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328936#comment-14328936 ] Abin commented on POOL-288: --- The object I am pooling is ZdSmppSession. I am printing a log in the constructor of this class and by counting the number of times the log is printed I can figure out how many times the object was created in the pool (The object is never initialized within the application). Once an instance of ZdSmppSession is created it starts sending an enquire_link every 60 seconds. I have verified the number of unique enquire_links sent and it confirms that there are more that the max count of objects expected. I am using org.springframework.aop.target.CommonsPoolTargetSource which implements org.apache.commons.pool.PoolableObjectFactory. It is a TargetSource implementation that holds objects in a configurable Apache Commons Pool. The spring version is 4.0.5 > Objects growing out of bound (beyond max limit) > --- > > Key: POOL-288 > URL: https://issues.apache.org/jira/browse/POOL-288 > Project: Commons Pool > Issue Type: Bug >Reporter: Abin > > My messaging application is a stand-alone spring boot application. I am > maintaining an apache commons pool of smpp sessions to be kept alive and used > when needed. But the pool starts to grow beyond its max limit. I have > explained my application design below. Any help/suggestion would be greatly > appreciated. > Current Design > I have an object pool of type ZdSmppSession (Apache Commons Pool), with pool > size set to 40 > Each ZdSmppSession has the following > 1. A sendMessage method > 2. A private variable of type com.cloudhopper.smpp.SmppSession > 3. A PostConstruct method > The Post Construct method does the following > 1. initiates a handshake and initialize the private variable > com.cloudhopper.smpp.SmppSession > 2. schedules an enquire link to be sent every 60 secs > I have about 120 worker threads which does the following > 1. Read message from rmq > 2. Get a ZdSmppSession object from pool > 3. Calls sendMessage on the object > 4. Release it back to pool > So when a ZdSmppSession object is created in the pool it is ready to send > messages > When ZdSmppSession is released back to pool it keeps the connection alive by > sending enquire link every 60 secs. A session object is never destructed. > Issue > The issue I am facing is that the pool grows beyond its maximum limit, even > though the max limit is set to 40. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1049) SerializationUtils.deserialize() can not be used within OSGi
[
https://issues.apache.org/jira/browse/LANG-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328932#comment-14328932
]
Duncan Jones commented on LANG-1049:
Understood. I propose we leave this as it is then, since the comment thread
explains the direction we wish to go.
Patches welcome for {{SerializationUtils.deserialize()}}.
> SerializationUtils.deserialize() can not be used within OSGi
>
>
> Key: LANG-1049
> URL: https://issues.apache.org/jira/browse/LANG-1049
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 2.6
> Environment: Equinox
>Reporter: Marcus Klein
>Priority: Blocker
>
> SerializationUtils.deserialize() throws a SerializationException if objects
> should be deserialized that can not be resolved by OSGi classloader of
> org.apache.commons.lang bundle.
> To solve this problem I suggest to allow buddy classloading within
> commons.lang to allow other bundles to register their class loaders.
> Please add
> Eclipse-BuddyPolicy: registered
> to the MANIFEST.MF of commons.lang to solve this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BCEL-207) RemoveLocalVariable(s) doesn't remove the associated Targetters.
[
https://issues.apache.org/jira/browse/BCEL-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328929#comment-14328929
]
Emmanuel Bourg commented on BCEL-207:
-
Actually the {{dispose()}} method would call {{notifyTarget}}, and
{{removeLocalVariable}} would call {{dispose()}}. This avoids repeating the
{{notifyTarget}} in two methods for the same purpose.
> RemoveLocalVariable(s) doesn't remove the associated Targetters.
>
>
> Key: BCEL-207
> URL: https://issues.apache.org/jira/browse/BCEL-207
> Project: Commons BCEL
> Issue Type: Bug
>Reporter: Mark Roberts
> Attachments: methodgen3.diff
>
>
> RemoveLocalVariable(s) doesn't remove the associated Targetters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BCEL-207) RemoveLocalVariable(s) doesn't remove the associated Targetters.
[ https://issues.apache.org/jira/browse/BCEL-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328924#comment-14328924 ] Mark Roberts commented on BCEL-207: --- I'm sorry, I don't follow you - how does that fix the removeLocalVariable problem? If you don't delete the targeters and try to reuse the localVariable it would have to have the exact same live range as the previous one. But before that problem, I think you run into null pointer issues with the method's StackMap. > RemoveLocalVariable(s) doesn't remove the associated Targetters. > > > Key: BCEL-207 > URL: https://issues.apache.org/jira/browse/BCEL-207 > Project: Commons BCEL > Issue Type: Bug >Reporter: Mark Roberts > Attachments: methodgen3.diff > > > RemoveLocalVariable(s) doesn't remove the associated Targetters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1049) SerializationUtils.deserialize() can not be used within OSGi
[ https://issues.apache.org/jira/browse/LANG-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328922#comment-14328922 ] Marcus Klein commented on LANG-1049: My alternative option is currently NOT to use SerializationUtils.deserialize(). In my eyes this is not an alternative option. Please add as feature request, what Joerg describes. But I personally don't see this as a feature request. The purpose of org.apache.commons.lang is to provide utilities for easier Java coding. Furthermore org.apache.commons.lang is exposed as being compatible with OSGi. But as described here, the utility is not usable in OSGi because of framework/classloader restrictions. If org.apache.commons.lang would not be exposed as OSGi compatible, this would be a feature request, of course. In this case it is a bug. > SerializationUtils.deserialize() can not be used within OSGi > > > Key: LANG-1049 > URL: https://issues.apache.org/jira/browse/LANG-1049 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 2.6 > Environment: Equinox >Reporter: Marcus Klein >Priority: Blocker > > SerializationUtils.deserialize() throws a SerializationException if objects > should be deserialized that can not be resolved by OSGi classloader of > org.apache.commons.lang bundle. > To solve this problem I suggest to allow buddy classloading within > commons.lang to allow other bundles to register their class loaders. > Please add > Eclipse-BuddyPolicy: registered > to the MANIFEST.MF of commons.lang to solve this problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (POOL-288) Objects growing out of bound (beyond max limit)
[ https://issues.apache.org/jira/browse/POOL-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328911#comment-14328911 ] Phil Steitz commented on POOL-288: -- How do you know the pool is growing beyond the max configured size? Are you getting values from getNumActive + getNumIdle beyond the configured max total? What version of pool are you running? > Objects growing out of bound (beyond max limit) > --- > > Key: POOL-288 > URL: https://issues.apache.org/jira/browse/POOL-288 > Project: Commons Pool > Issue Type: Bug >Reporter: Abin > > My messaging application is a stand-alone spring boot application. I am > maintaining an apache commons pool of smpp sessions to be kept alive and used > when needed. But the pool starts to grow beyond its max limit. I have > explained my application design below. Any help/suggestion would be greatly > appreciated. > Current Design > I have an object pool of type ZdSmppSession (Apache Commons Pool), with pool > size set to 40 > Each ZdSmppSession has the following > 1. A sendMessage method > 2. A private variable of type com.cloudhopper.smpp.SmppSession > 3. A PostConstruct method > The Post Construct method does the following > 1. initiates a handshake and initialize the private variable > com.cloudhopper.smpp.SmppSession > 2. schedules an enquire link to be sent every 60 secs > I have about 120 worker threads which does the following > 1. Read message from rmq > 2. Get a ZdSmppSession object from pool > 3. Calls sendMessage on the object > 4. Release it back to pool > So when a ZdSmppSession object is created in the pool it is ready to send > messages > When ZdSmppSession is released back to pool it keeps the connection alive by > sending enquire link every 60 secs. A session object is never destructed. > Issue > The issue I am facing is that the pool grows beyond its maximum limit, even > though the max limit is set to 40. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (LANG-1070) confusing example in ArrayUtils.add()
[
https://issues.apache.org/jira/browse/LANG-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328904#comment-14328904
]
Duncan Jones edited comment on LANG-1070 at 2/20/15 1:25 PM:
-
The Javadoc is inconsistent. It gives the example of {{ArrayUtils.add(null,
null) = \[null\]}} and states that {{array}} and {{element}} can both be null.
But later it describes the behaviour differently:
bq. [The method returns] a new array containing the existing elements plus the
new element The returned array type will be that of the input array (unless
null), in which case it will have the same type as the element. _If both are
null, an IllegalArgumentException is thrown_
It's not clear to me whether we can adjust the behaviour under the
justification that it's a bug (versus documented behaviour).
was (Author: dmjones500):
The Javadoc is inconsistent. It gives the example of {{ArrayUtils.add(null,
null) = \[null\]}} and states that {{array}} and {{element}} can both be null.
But later it describes the behaviour differently:
bq. [The method returns] a new array containing the existing elements plus the
new element The returned array type will be that of the input array (unless
null), in which case it will have the same type as the element. _If both are
null, an IllegalArgumentException is thrown_
> confusing example in ArrayUtils.add()
> -
>
> Key: LANG-1070
> URL: https://issues.apache.org/jira/browse/LANG-1070
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: Paul Pogonyshev
>Priority: Trivial
>
> Method documentation claims that
> ArrayUtils.add(null, null) = null
> However, this is not true since this parameter combination leads to an
> exception.
> Either remove this line from documentation, or rewrite it to explicitly
> mention the exception. Maybe there are other related methods with similar
> problem in the docs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1070) confusing example in ArrayUtils.add()
[
https://issues.apache.org/jira/browse/LANG-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328904#comment-14328904
]
Duncan Jones commented on LANG-1070:
The Javadoc is inconsistent. It gives the example of {{ArrayUtils.add(null,
null) = \[null\]}} and states that {{array}} and {{element}} can both be null.
But later it describes the behaviour differently:
bq. [The method returns] a new array containing the existing elements plus the
new element The returned array type will be that of the input array (unless
null), in which case it will have the same type as the element. _If both are
null, an IllegalArgumentException is thrown_
> confusing example in ArrayUtils.add()
> -
>
> Key: LANG-1070
> URL: https://issues.apache.org/jira/browse/LANG-1070
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: Paul Pogonyshev
>Priority: Trivial
>
> Method documentation claims that
> ArrayUtils.add(null, null) = null
> However, this is not true since this parameter combination leads to an
> exception.
> Either remove this line from documentation, or rewrite it to explicitly
> mention the exception. Maybe there are other related methods with similar
> problem in the docs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1074) Add a method to ArrayUtils for removing all occurrences of a given element
[
https://issues.apache.org/jira/browse/LANG-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328896#comment-14328896
]
Duncan Jones commented on LANG-1074:
[~lihy70]: Are you willing to update the patch to address Benedikt's comments?
Specifically:
- Rename to {{removeAllOccurences(...)}}
- Drop the {{boolean removeAll}} parameter.
You should also add {{@since 3.4}} to the Javadoc for the new methods.
Then we can look to getting this added to trunk.
> Add a method to ArrayUtils for removing all occurrences of a given element
> --
>
> Key: LANG-1074
> URL: https://issues.apache.org/jira/browse/LANG-1074
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: haiyang li
>Priority: Minor
> Fix For: Review Patch
>
> Attachments: LANG-1074.patch.txt
>
>
> Could we add the method: removeElementAll to remove all the occurrences of
> the specified element from the specified
> (boolean/char/byte/short/int/long/float/double/Object) array:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
> public static T[] removeElementAll(final T[] array, final Object
> element) {
> int index = indexOf(array, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(array);
> }
> int[] indices = new int[array.length - index];
> int count = 0;
> indices[count++] = index;
> for (;;) {
> index = indexOf(array, element, ++index);
> if (index == INDEX_NOT_FOUND) {
> break;
> } else {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) array, Arrays.copyOfRange(indices, 0,
> count));
> }
> {code}
> or maybe better:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
>public static T[] removeElement(final T[] a, final Object element,
> boolean removeAll) {
> int index = indexOf(a, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(a);
> } else if (!removeAll || index >= a.length - 1) {
> return remove(a, index);
> } else {
> int[] indices = new int[a.length - index];
> int count = 0;
> indices[count++] = index++;
>
> for (int len = a.length; index < len; index++) {
> if ((a[index] == null) ? element == null : (element == null ?
> false : a[index].equals(element))) {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) a, Arrays.copyOfRange(indices, 0,
> count));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1049) SerializationUtils.deserialize() can not be used within OSGi
[ https://issues.apache.org/jira/browse/LANG-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328887#comment-14328887 ] Duncan Jones commented on LANG-1049: [~marcus.klein]: do you think this issue should become a feature request, asking for what Joerg describes? Or are you happy that we close this, because you have found an alternative option? > SerializationUtils.deserialize() can not be used within OSGi > > > Key: LANG-1049 > URL: https://issues.apache.org/jira/browse/LANG-1049 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 2.6 > Environment: Equinox >Reporter: Marcus Klein >Priority: Blocker > > SerializationUtils.deserialize() throws a SerializationException if objects > should be deserialized that can not be resolved by OSGi classloader of > org.apache.commons.lang bundle. > To solve this problem I suggest to allow buddy classloading within > commons.lang to allow other bundles to register their class loaders. > Please add > Eclipse-BuddyPolicy: registered > to the MANIFEST.MF of commons.lang to solve this problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1065) Merge date and time together
[ https://issues.apache.org/jira/browse/LANG-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328884#comment-14328884 ] Duncan Jones commented on LANG-1065: bq. We have a pull request with tests. Evidently, that means someone else wants this functionality too. Perhaps the patch submitter desperately needs this functionality himself, but perhaps he just enjoys creating patches and contributing to the community. Either way, two users interested in a feature is not proof of a general need amongst the Lang user base. We have to go with our gut on this sort of decision. Mine still says this is too specific and Lang would not benefit from its inclusion. But please feel free to present further arguments explaining why this code would be useful to more users. I think a real-life use-case would help us understand why you would use it. > Merge date and time together > > > Key: LANG-1065 > URL: https://issues.apache.org/jira/browse/LANG-1065 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Paul Benedict >Priority: Minor > Fix For: Review Patch > > Original Estimate: 1h > Remaining Estimate: 1h > > I have 2 java.util.Date objects -- one with the correct date and one with the > correct time. This enhancement will create a new method to apply the > respective fragments to a new java.util.Date instance. > Possible signature: > public static Date merge(Date date, Date time); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1069) CharSet.getInstance documentation does not clearly explain how to include negation character in set
[
https://issues.apache.org/jira/browse/LANG-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328881#comment-14328881
]
Duncan Jones commented on LANG-1069:
Can you explain why you think {{CharSet.getInstance("^^a-d")}} is a corner
case? You've explicitly listed it in the documentation as an example, but I
don't understand why it requires special attention.
> CharSet.getInstance documentation does not clearly explain how to include
> negation character in set
> ---
>
> Key: LANG-1069
> URL: https://issues.apache.org/jira/browse/LANG-1069
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: Duncan Jones
>Priority: Minor
> Fix For: Review Patch
>
> Attachments: CharSet-1069.patch
>
>
> As discussed in [this Stack Overflow
> question|http://stackoverflow.com/questions/27070515/how-can-i-include-the-caret-character-in-an-apache-commons-charset],
> the documentation for {{CharSet.getInstance()}} don't explain clearly how to
> include the negation character ({{^}}) as a literal character.
> The two solutions suggested in the SO question are:
> {code:java}
> // Add the '^' on its own
> CharSet.getInstance("^", "otherlettershere");
> // Add the '^' as the last character
> CharSet.getInstance("otherlettershere^")
> {code}
> If those are the best options, we should add a line to the Javadoc to
> indicate this. If there is a better way, clearly that should be documented
> instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCS-142) CDI extension doesn't work if not scanned
[ https://issues.apache.org/jira/browse/JCS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-142: --- Description: With CDI 1.1 we can solve it properly > CDI extension doesn't work if not scanned > - > > Key: JCS-142 > URL: https://issues.apache.org/jira/browse/JCS-142 > Project: Commons JCS > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: jcs-2.0-alpha-2 > > > With CDI 1.1 we can solve it properly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCS-142) CDI extension doesn't work if not scanned
[ https://issues.apache.org/jira/browse/JCS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved JCS-142. Resolution: Fixed Fix Version/s: jcs-2.0-alpha-2 > CDI extension doesn't work if not scanned > - > > Key: JCS-142 > URL: https://issues.apache.org/jira/browse/JCS-142 > Project: Commons JCS > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: jcs-2.0-alpha-2 > > > With CDI 1.1 we can solve it properly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCS-142) CDI extension doesn't work if not scanned
[ https://issues.apache.org/jira/browse/JCS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-142: --- Summary: CDI extension doesn't work if not scanned (was: CDi extension doesn't work if not scanned) > CDI extension doesn't work if not scanned > - > > Key: JCS-142 > URL: https://issues.apache.org/jira/browse/JCS-142 > Project: Commons JCS > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JCS-142) CDi extension doesn't work if not scanned
Romain Manni-Bucau created JCS-142: -- Summary: CDi extension doesn't work if not scanned Key: JCS-142 URL: https://issues.apache.org/jira/browse/JCS-142 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MATH-1205) AbstractStorelessUnivariateStatistic should not extend AbstractUnivariateStatistic
Thomas Neidhart created MATH-1205:
-
Summary: AbstractStorelessUnivariateStatistic should not extend
AbstractUnivariateStatistic
Key: MATH-1205
URL: https://issues.apache.org/jira/browse/MATH-1205
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.4.1
Reporter: Thomas Neidhart
For a storeless statistic it is wrong to extend AbstractUnivariateStatistic as
various fields and methods are inherited that do not make sense in case of a
storeless statistic.
This means a user can accidentially use a storeless statistic in a wrong way:
{code}
Mean mean = new Mean();
mean.increment(1);
mean.increment(2);
mean.setData(new double[] { 1, 2, 3});
System.out.println(mean.getResult());
System.out.println(mean.evaluate());
{code}
will output
{noformat}
1.5
2.0
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BCEL-207) RemoveLocalVariable(s) doesn't remove the associated Targetters.
[
https://issues.apache.org/jira/browse/BCEL-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328858#comment-14328858
]
Emmanuel Bourg commented on BCEL-207:
-
What about adding a {{dispose()}} method in {{LocalVariableGen}} performing
this cleanup and also clearing the handlers defining the scope? Thus removing a
local variable would make it ready to be reused elsewhere, if ever that could
make sense.
> RemoveLocalVariable(s) doesn't remove the associated Targetters.
>
>
> Key: BCEL-207
> URL: https://issues.apache.org/jira/browse/BCEL-207
> Project: Commons BCEL
> Issue Type: Bug
>Reporter: Mark Roberts
> Attachments: methodgen3.diff
>
>
> RemoveLocalVariable(s) doesn't remove the associated Targetters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (BCEL-213) invokedynamic support for InstructionFinder
Emmanuel Bourg created BCEL-213: --- Summary: invokedynamic support for InstructionFinder Key: BCEL-213 URL: https://issues.apache.org/jira/browse/BCEL-213 Project: Commons BCEL Issue Type: Improvement Reporter: Emmanuel Bourg Priority: Minor InstructionFinder doesn't know about invokedynamic and is unable to match it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (BCEL-110) Problem with JAXB if the bcel classloader is used
[ https://issues.apache.org/jira/browse/BCEL-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328743#comment-14328743 ] Thomas Neidhart commented on BCEL-110: -- The most likely cause for this is because the bcel Classloader does not follow the Java 2 classloader delegation pattern. Depending on the setup, it might use a SyntheticRepository to load the class from the classpath (which also includes the system classes, and org.xml.sax.InputSource is part of them) instead of using the bootstrap classloader to load system classes. Furthermore the bcel ClassLoader does not correctly call definePackage, so clazz.getPackage() might be null and cause problems in some cases. > Problem with JAXB if the bcel classloader is used > - > > Key: BCEL-110 > URL: https://issues.apache.org/jira/browse/BCEL-110 > Project: Commons BCEL > Issue Type: Bug > Components: Main >Affects Versions: 5.2 > Environment: Operating System: Windows XP > Platform: PC >Reporter: Oleg Barmin >Assignee: Apache Commons Developers > > When I try to run program with a JAXB code I got an exception if the bcel > classloader is used. > Exception in thread "main" java.lang.LinkageError: Class > org/xml/sax/InputSource > violates loader constraints > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(Unknown Source) > at java.lang.ClassLoader.defineClass(Unknown Source) > at org.apache.bcel.util.ClassLoader.loadClass(ClassLoader.java:127) > at java.lang.ClassLoader.loadClass(Unknown Source) > at java.lang.ClassLoader.loadClassInternal(Unknown Source) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown > Source) > at > advdebug.config.parser.impl.runtime.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:140) > at > javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:131) > at > javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:136) > at > javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:145) > at > javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:163) > at test.Test.main(Test.java:47) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (BCEL-110) Problem with JAXB if the bcel classloader is used
[ https://issues.apache.org/jira/browse/BCEL-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328743#comment-14328743 ] Thomas Neidhart commented on BCEL-110: -- The most likely cause for this is because the bcel Classloader does not follow the Java 2 classloader delegation pattern. Depending on the setup, it might use a SyntheticRepository to load the class from the classpath (which also includes the system classes, and org.xml.sax.InputSource is part of them) instead of using the bootstrap classloader to load system classes. Furthermore the bcel ClassLoader does not correctly call definePackage, so clazz.getPackage() might be null and cause problems in some cases. > Problem with JAXB if the bcel classloader is used > - > > Key: BCEL-110 > URL: https://issues.apache.org/jira/browse/BCEL-110 > Project: Commons BCEL > Issue Type: Bug > Components: Main >Affects Versions: 5.2 > Environment: Operating System: Windows XP > Platform: PC >Reporter: Oleg Barmin >Assignee: Apache Commons Developers > > When I try to run program with a JAXB code I got an exception if the bcel > classloader is used. > Exception in thread "main" java.lang.LinkageError: Class > org/xml/sax/InputSource > violates loader constraints > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(Unknown Source) > at java.lang.ClassLoader.defineClass(Unknown Source) > at org.apache.bcel.util.ClassLoader.loadClass(ClassLoader.java:127) > at java.lang.ClassLoader.loadClass(Unknown Source) > at java.lang.ClassLoader.loadClassInternal(Unknown Source) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown > Source) > at > advdebug.config.parser.impl.runtime.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:140) > at > javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:131) > at > javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:136) > at > javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:145) > at > javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:163) > at test.Test.main(Test.java:47) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (BCEL-176) util.ClassPath.getClassFile(String name, String suffix) - unused loop variable
[
https://issues.apache.org/jira/browse/BCEL-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg resolved BCEL-176.
-
Resolution: Fixed
Fix Version/s: 6.0
> util.ClassPath.getClassFile(String name, String suffix) - unused loop variable
> --
>
> Key: BCEL-176
> URL: https://issues.apache.org/jira/browse/BCEL-176
> Project: Commons BCEL
> Issue Type: Bug
>Reporter: Sebb
>Priority: Trivial
> Fix For: 6.0
>
>
> The method util.ClassPath.getClassFile(String name, String suffix) uses a for
> loop, but does not use the variable in the loop.
> {code}
> for (PathEntry path : paths) {
> ...
> }
> {code}
> It looks like the loop is redundant and should be removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (BCEL-176) util.ClassPath.getClassFile(String name, String suffix) - unused loop variable
[
https://issues.apache.org/jira/browse/BCEL-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg updated BCEL-176:
Priority: Trivial (was: Major)
> util.ClassPath.getClassFile(String name, String suffix) - unused loop variable
> --
>
> Key: BCEL-176
> URL: https://issues.apache.org/jira/browse/BCEL-176
> Project: Commons BCEL
> Issue Type: Bug
>Reporter: Sebb
>Priority: Trivial
> Fix For: 6.0
>
>
> The method util.ClassPath.getClassFile(String name, String suffix) uses a for
> loop, but does not use the variable in the loop.
> {code}
> for (PathEntry path : paths) {
> ...
> }
> {code}
> It looks like the loop is redundant and should be removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
