[jira] [Resolved] (JXPATH-152) Concurrent access on hashmap of JXPathIntrospector
[
https://issues.apache.org/jira/browse/JXPATH-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved JXPATH-152.
Resolution: Fixed
Fix Version/s: 1.4
Assignee: Matt Benson
It would seem that synchronizing access to the {{HashMap}}s' {{#put}} calls
would defend against the worst-case scenarios you suggest. Thanks for the
report!
{quote}
Committed revision 1293412.
{quote}
> Concurrent access on hashmap of JXPathIntrospector
> --
>
> Key: JXPATH-152
> URL: https://issues.apache.org/jira/browse/JXPATH-152
> Project: Commons JXPath
> Issue Type: Bug
>Affects Versions: 1.3
> Environment: Java5, Windows/AIX
>Reporter: pleutre
>Assignee: Matt Benson
>Priority: Minor
> Fix For: 1.4
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> JXPathIntrospector.registerDynamicClass method can be called in static part
> of classes.
> If two classes A & B try to registerDynamicClass in the same time a
> concurrent access exception can append on hashmap of JXPathIntrospector.
> Replace hashmap by concurrent hashmap or synchronized access to these
> hashmaps.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FUNCTOR-10) throw NullPointerException for illegal null values
[
https://issues.apache.org/jira/browse/FUNCTOR-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved FUNCTOR-10.
Resolution: Fixed
Committed revision 1234990.
> throw NullPointerException for illegal null values
> --
>
> Key: FUNCTOR-10
> URL: https://issues.apache.org/jira/browse/FUNCTOR-10
> Project: Commons Functor
> Issue Type: Improvement
>Reporter: Emmanuel Bourg
>Assignee: Matt Benson
>
> for better alignment with JSE, {{[lang]}}, etc. Currently
> {{IllegalArgumentException}} is thrown.
> Per http://markmail.org/message/ythw55yad5lrvqrj
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-786) StringUtils equals() relies on undefined behavior
[
https://issues.apache.org/jira/browse/LANG-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved LANG-786.
--
Resolution: Fixed
Hi, Daniel, and thanks for your contribution! Notwithstanding the obvious
potential for arguments about OO design and method overloading, I have reworked
your patch so that {{String-String}} comparisons are still handled in the body
of the basic {{equals(CharSequence, CharSequence)}} method; thus no exception
is needed in {{StringUtilsTest#testStringUtilsCharSequenceContract()}}.
Specifically I have retained your {{StringUtilsEqualsIndexOfTest}} improvements.
{{Committed revision 1234915.}}
> StringUtils equals() relies on undefined behavior
> -
>
> Key: LANG-786
> URL: https://issues.apache.org/jira/browse/LANG-786
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.x
> Environment: java version "1.7.0_02"
> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
> Fedora 15 AMD64
>Reporter: Daniel Trebbien
> Labels: StringUtils
> Attachments: equals.patch
>
>
> Since the {{java.lang.CharSequence}} class was first introduced in 1.4, the
> JavaDoc block has contained the following note:
> {quote}
> This interface does not refine the general contracts of the equals and
> hashCode methods. The result of comparing two objects that implement
> CharSequence is therefore, in general, undefined. Each object may be
> implemented by a different class, and there is no guarantee that each class
> will be capable of testing its instances for equality with those of the other.
> {quote}
> When the signature of the StringUtils equals() method was changed from
> {{equals(String, String)}} to {{equals(CharSequence, CharSequence)}} in
> R920543, the implementation still relied on calling
> CharSequence#equals(Object) even though, in general, the result is undefined.
> One example where {{equals(Object)}} returns {{false}} even though, as
> CharSequences, two objects represent equal sequences is when one object is an
> instance of {{javax.lang.model.element.Name}} and the other object is a
> String.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FUNCTOR-13) EachElement should be able to work on any Iterable
[ https://issues.apache.org/jira/browse/FUNCTOR-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson resolved FUNCTOR-13. Resolution: Fixed Committed revision 1234401. > EachElement should be able to work on any Iterable > -- > > Key: FUNCTOR-13 > URL: https://issues.apache.org/jira/browse/FUNCTOR-13 > Project: Commons Functor > Issue Type: Improvement >Reporter: Emmanuel Bourg > > from http://markmail.org/message/ythw55yad5lrvqrj -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JXPATH-153) Wrong entry IMPORT-PACKAGE in the file MANIFEST.MF for jdom and commons-beanutils
[ https://issues.apache.org/jira/browse/JXPATH-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson resolved JXPATH-153. Resolution: Fixed Committed revision 1234382. > Wrong entry IMPORT-PACKAGE in the file MANIFEST.MF for jdom and > commons-beanutils > - > > Key: JXPATH-153 > URL: https://issues.apache.org/jira/browse/JXPATH-153 > Project: Commons JXPath > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Jens Teutenberg > Fix For: 1.4 > > > commons-beanutils and jdom are optional dependencies. But they are configured > as required in the entry IMPORT-PACKAGE in the file MANIFEST.MF. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JXPATH-139) Wrong xpath expression passed to extension function does not throw JXPathNotFoundException
[
https://issues.apache.org/jira/browse/JXPATH-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved JXPATH-139.
Resolution: Invalid
Hello, and sorry for the long wait. I have looked at this before, but have
finally realized that this issue is invalid. You must bear in mind that this
is xpath, so when you pass a path to a function, you are really passing the set
of nodes that matches that query, in this case "those nodes relative to the
current path (root) whose qname matches 'valueXXX'." This empty nodeset is
then converted to a string, yielding the value "". Unfortunately this does
mean that your jxpath expressions will not automatically break when
refactorings change property names.
> Wrong xpath expression passed to extension function does not throw
> JXPathNotFoundException
> --
>
> Key: JXPATH-139
> URL: https://issues.apache.org/jira/browse/JXPATH-139
> Project: Commons JXPath
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Petras
>
> If xpath expression, which do not map to bean properties, is passed to
> extension function, JXPathNotFoundException is not thrown. It seems
> inconsistent behaviour and it is difficult to test these expressions if they
> do not fail for example after code refactoring.
> Here is a test case:
> {code}
> // Extension function
> public static class StringFunctions {
> public static String left(String param, int len) {
> System.out.println("Received: '" + param + "'");
> if(param == null) return null;
> return param.substring(0, Math.min(len, param.length()));
> }
> }
> {code}
> {code}
> // Value object to use
> public class VO {
> String value = null;
> public String getValue() { return value; }
> public void setValue(String value) { this.value = value; }
> }
> {code}
> {code}
> @Test
> public void testLeftFunctionWrongPath() {
> VO vo = new VO();
> vo.setValue("1234567890");
> JXPathContext ctx = JXPathContext.newContext(vo);
> ctx.setFunctions(new ClassFunctions(StringFunctions.class, "util"));
>
> // OK, StringFunctions.left() receives "1234567890"
> path = "util:left(value, 5)";
> ctx.getValue(path);
>
> // JXPathNotFoundException is not thrown, StringFunctions.left()
> receives an empty string
> String wrongPath = "util:left(valueXXX, 5)";
> ctx.getValue(wrongPath);
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JXPATH-154) Resetting the default namespace causes a serious endless loop when requesting .asPath() on a node.
[
https://issues.apache.org/jira/browse/JXPATH-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved JXPATH-154.
Resolution: Fixed
Fix Version/s: 1.4
> Resetting the default namespace causes a serious endless loop when requesting
> .asPath() on a node.
> --
>
> Key: JXPATH-154
> URL: https://issues.apache.org/jira/browse/JXPATH-154
> Project: Commons JXPath
> Issue Type: Bug
>Affects Versions: 1.3
> Environment: jxpath eclipse plugin from orbit
>Reporter: Hugo de Almeida Cocharro
> Fix For: 1.4
>
>
> sample smaller case:
> {code}
> <...>
>
> a
>
>
>
> {code}
> when requesting .asPath() on the 'test' node, it loops in
> org.apache.commons.jxpath.ri.NamespaceResolver.getPrefix(NodePointer,
> String),
> and if it didn't loop it would create a wrong xpath '//b:fo/null:test'
> DOMNodePointer.asPath().
> So I think that the fix should be in
> org.apache.commons.jxpath.ri.model.dom.DOMNodePointer.asPath()
> {code}
>
> String ln = DOMNodePointer.getLocalName(node);
> String nsURI = getNamespaceURI();
> if (nsURI == null) {
> buffer.append(ln);
> buffer.append('[');
>
> buffer.append(getRelativePositionByName()).append(']');
> }
> else {
> String prefix =
> getNamespaceResolver().getPrefix(nsURI);
> if (prefix != null) {
> ...
> {code}
> should become
> {code}
> ...
> String ln = DOMNodePointer.getLocalName(node);
> String nsURI = getNamespaceURI();
> if (nsURI == null || nsURI.length() == 0) { // check for
> empty string which means that the node doesn't have a namespace.
> buffer.append(ln);
> buffer.append('[');
>
> buffer.append(getRelativePositionByName()).append(']');
> }
> else {
> String prefix =
> getNamespaceResolver().getPrefix(nsURI);
> if (prefix != null) {
> ...
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DIGESTER-153) Add Constructor support to ObjectCreateRule
[ https://issues.apache.org/jira/browse/DIGESTER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson resolved DIGESTER-153. -- Resolution: Fixed Committed revision 1209953. > Add Constructor support to ObjectCreateRule > --- > > Key: DIGESTER-153 > URL: https://issues.apache.org/jira/browse/DIGESTER-153 > Project: Commons Digester > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Simone Tripodi >Assignee: Simone Tripodi > Fix For: 3.2 > > > As shown in the past, the stack method of Digester has some [limitations > |http://markmail.org/message/wick27gw6n5weqk2] for fully support the > Constructors - it basically cannot use elements in the body as constructor > arguments - but it could support arguments extracted from attributes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-775) TypeUtils.getTypeArguments() misses type arguments for partially-assigned classes
[
https://issues.apache.org/jira/browse/LANG-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved LANG-775.
--
Resolution: Fixed
Fix Version/s: 3.2
rev 1203429
> TypeUtils.getTypeArguments() misses type arguments for partially-assigned
> classes
> -
>
> Key: LANG-775
> URL: https://issues.apache.org/jira/browse/LANG-775
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.1
>Reporter: Matt Benson
>Assignee: Matt Benson
> Fix For: 3.2
>
>
> failing test code to add to TypeUtilsTest.testGetTypeArguments():
> {code}
> typeVarAssigns = TypeUtils.getTypeArguments(Other.class, This.class);
> Assert.assertEquals(2, typeVarAssigns.size());
> Assert.assertEquals(String.class,
> typeVarAssigns.get(This.class.getTypeParameters()[0]));
> Assert.assertEquals(Other.class.getTypeParameters()[0],
> typeVarAssigns.get(This.class.getTypeParameters()[1]));
> {code}
> These should pass based on:
> {code}
> public interface This {
> }
> public class Other implements This {
> }
> {code}
> This case fails because the current code ignores the Other class due to its
> specifying its own type variables, which is obviously incorrect. This report
> is extrapolated from an offline report received by Hen.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-776) TypeUtilsTest contains incorrect type assignability assertion due to lost/skipped type variable information during the decision process
[
https://issues.apache.org/jira/browse/LANG-776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved LANG-776.
--
Resolution: Fixed
Fix Version/s: 3.2
rev 1203429
> TypeUtilsTest contains incorrect type assignability assertion due to
> lost/skipped type variable information during the decision process
> ---
>
> Key: LANG-776
> URL: https://issues.apache.org/jira/browse/LANG-776
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.1
>Reporter: Matt Benson
>Assignee: Matt Benson
> Fix For: 3.2
>
>
> {{TypeUtilsTest}} originally contained the following under
> #{{testIsAssignable()}}:
> {code}
> Assert.assertTrue("WRONG!", TypeUtils.isAssignable(dingType, disType));
> {code}
> For background:
> {code}
> public interface This {
> }
> public class Other implements This {
> }
> public class Thing extends Other {
> }
> {code}
> {{}} refers to a type parameter on the {{TypeUtilsTest}} class itself.
> {{disType}} and {{dingType}} refer to the generic types of the following
> fields, respectively:
> {code}
> public This dis;
> public Thing ding;
> {code}
> Thus the assertion in question declares that type {{Thing}} is assignable to
> {{This}}. If we start at {{This}} we can see that the
> implementing class {{Other}} maps its {{T}} type parameter to the {{V}} type
> parameter of {{This}}. From this point we can proceed down to {{Thing}} and
> see that it maps the {{B}} type parameter of the enclosing {{TypeUtilsTest}}
> class to the {{T}} type parameter of {{Other}}. Thus it is fairly obvious
> that only a {{TypeUtilsTest.Thing}} is assignable to {{This String>}}. From this we can determine that the intent of the message in the
> original test assertion must indeed have been to flag an incorrect assertion.
> This is the associated bug report.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DIGESTER-153) Add Constructor support to ObjectCreateRule
[ https://issues.apache.org/jira/browse/DIGESTER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson resolved DIGESTER-153. -- Resolution: Fixed Committed revision 1200623. > Add Constructor support to ObjectCreateRule > --- > > Key: DIGESTER-153 > URL: https://issues.apache.org/jira/browse/DIGESTER-153 > Project: Commons Digester > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Simone Tripodi >Assignee: Simone Tripodi > Fix For: 3.2 > > > As shown in the past, the stack method of Digester has some [limitations > |http://markmail.org/message/wick27gw6n5weqk2] for fully support the > Constructors - it basically cannot use elements in the body as constructor > arguments - but it could support arguments extracted from attributes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
