[jira] [Updated] (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
]
Henri Yandell updated LANG-786:
---
Fix Version/s: 3.2
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
Fix For: 3.2
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] [Commented] (LANG-462) FastDateFormat supports parse
[ https://issues.apache.org/jira/browse/LANG-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192040#comment-13192040 ] Henri Yandell commented on LANG-462: Thanks Charles - that does indeed apply cleanly :) A couple of FindBugs errors pop up for FormatCache$MultipartKey. Looks very fixable. The big question, as you pointed out, is the removal of the four protected methods. They've been there since the code was added in Lang 2.0, and as there's no way to know if they've been used I expect the mailing list to fairly unhappy at the idea of removing the methods. Any reason why you couldn't have the four methods sitting on top of the underlying printer? We could deprecate them for removal in 4.0. FastDateFormat supports parse - Key: LANG-462 URL: https://issues.apache.org/jira/browse/LANG-462 Project: Commons Lang Issue Type: New Feature Components: lang.time.* Reporter: Franz Wong Fix For: 3.x Attachments: DateParser.patch, LANG-462-FormatCache.patch, LANG-462-Hen.patch, UseFormatCache.patch, lang462.patch, with_interfaces.patch, with_interfaces2.patch, with_updated_tests.patch Currently FastDateFormat only supports formatting the ISO8601 time zone, however, it doesn't support parsing such string to Date. -- 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] [Commented] (MATH-575) Exceptions in genetics package or not consistent with the rest of [math]
[ https://issues.apache.org/jira/browse/MATH-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192047#comment-13192047 ] Thomas Neidhart commented on MATH-575: -- Fixed in r1235197. Thanks for your suggestions! Exceptions in genetics package or not consistent with the rest of [math] Key: MATH-575 URL: https://issues.apache.org/jira/browse/MATH-575 Project: Commons Math Issue Type: Bug Affects Versions: 2.0, 2.1, 2.2 Reporter: Phil Steitz Priority: Minor Fix For: 3.0 InvalidRepresentationException is checked and non-localized. This exception should be placed in the [math] hierarchy. The AbstractListChromosome constructor also throws a non-localised IAE, which should be replaced by an appropriate [math] exception. -- 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] [Commented] (MATH-668) Polygon difference function produces erroneous results with certain polygons
[ https://issues.apache.org/jira/browse/MATH-668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192076#comment-13192076 ] Thomas Neidhart commented on MATH-668: -- I have checked the attached test cases: - circle test: you remove the outer circle from the inner one, resulting in an empty polygon set, which is correct behaviour. If you switch the two circles, the correct result is returned: a PolygonsSet with two loops: the two circles itself. - testdifference2: the described behaviour is implementation specific due to the way the hyperplane is cut when subtracting the two regions. Polygon difference function produces erroneous results with certain polygons Key: MATH-668 URL: https://issues.apache.org/jira/browse/MATH-668 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Curtis Jensen Assignee: Luc Maisonobe Labels: difference, math,, polygon, Fix For: 3.0 Attachments: PolygonsSetCircleTest.java, PolygonsSetTest.java Original Estimate: 168h Remaining Estimate: 168h For some polygons, the difference function produces erroneous results. This appears to happen when one polygon is completely encompassed in another, and the outer has multiple concave sections. -- 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] [Commented] (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:comment-tabpanelfocusedCommentId=13192085#comment-13192085
]
Hugo de Almeida Cocharro commented on JXPATH-154:
-
Thanks a lot, I build the current 1.4 from svn and it fixes our case.
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}
...
b:foo xmlns:b=bla xmlns=test111!-- No nodes are placed in the
tree within ns test111 but the attribute is still there.--
b:bara/b:bar !-- is in ns 'bla' --
test xmlns=/test !-- does not have a namespace --
/b:foo
/...
{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] [Commented] (SANDBOX-355) Provide Flow algorithms
[
https://issues.apache.org/jira/browse/SANDBOX-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192127#comment-13192127
]
Simone Tripodi commented on SANDBOX-355:
Hi Claudio,
your patch has been applied, see [r1235238|], thanks!!!
Just as a side notes:
* I simplified the {{FlowNetworkHandler}} implementation, extending the
{{BaseGraphVisitHandler}} that already contains basic {{GraphVisitHandler}}
methods implementation that match with the actual needs.
* I think we could extract an interface from {{PredecessorsList}} and move the
implementation in the {{{model}} sub-package... WDYT?
I will let the issue open for future Flow-related algorithms patches.
Thanks for your hard work!
Provide Flow algorithms
---
Key: SANDBOX-355
URL: https://issues.apache.org/jira/browse/SANDBOX-355
Project: Commons Sandbox
Issue Type: New Feature
Components: Graph
Reporter: Simone Tripodi
Attachments: SANDBOX-355_FordFulkersonImplementationAndTest.patch
right now the {{org.apache.commons.graph.flow}} package contains an empty
implementation of
[Ford-Fulkerson|http://en.wikipedia.org/wiki/Ford%E2%80%93Fulkerson_algorithm]'s
algorithm, that needs to be filled.
Other algorithms that work on resolving Flow-related problems, are welcome.
--
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] [Commented] (SANDBOX-355) Provide Flow algorithms
[
https://issues.apache.org/jira/browse/SANDBOX-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192152#comment-13192152
]
Claudio Squarcella commented on SANDBOX-355:
Hi Simone,
thanks for simplifying the implementation, well done :)
Also: yes I agree, let's move {{PredecessorsList}} somewhere more general.
As a further step the [algorithm by Edmonds and
Karp|http://en.wikipedia.org/wiki/Edmonds%E2%80%93Karp_algorithm] should be
very easy to add, reusing most of the code I provided with the patch.
Ciao,
Claudio
Provide Flow algorithms
---
Key: SANDBOX-355
URL: https://issues.apache.org/jira/browse/SANDBOX-355
Project: Commons Sandbox
Issue Type: New Feature
Components: Graph
Reporter: Simone Tripodi
Attachments: SANDBOX-355_FordFulkersonImplementationAndTest.patch
right now the {{org.apache.commons.graph.flow}} package contains an empty
implementation of
[Ford-Fulkerson|http://en.wikipedia.org/wiki/Ford%E2%80%93Fulkerson_algorithm]'s
algorithm, that needs to be filled.
Other algorithms that work on resolving Flow-related problems, are welcome.
--
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] [Created] (OGNL-47) CLONE - Unable to use Struts 2.3.1.2 appliation with OGNL 3.0.3 by enabling security manager but same application works with OGNL 3.0.4
CLONE - Unable to use Struts 2.3.1.2 appliation with OGNL 3.0.3 by enabling security manager but same application works with OGNL 3.0.4 --- Key: OGNL-47 URL: https://issues.apache.org/jira/browse/OGNL-47 Project: Commons OGNL Issue Type: Bug Reporter: kesava Priority: Blocker Unable to use Struts 2.3.1.1 application with OGNL 3.0.3 by enabling security manager but same application works with OGNL 3.0.2. Steps to reproduce 1.Enable security manager 2.Load the app Caught an Ognl exception while getting property serviceProviders - Class: ognl.ObjectPropertyAccessor File: ObjectPropertyAccessor.java Method: getPossibleProperty Line: 69 - ognl/ObjectPropertyAccessor.java:69:-1 at com.opensymphony.xwork2.ognl.accessor.CompoundRootAccessor.getProperty(CompoundRootAccessor.java:142) at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:2303) at ognl.ASTProperty.getValueBody(ASTProperty.java:114) at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:212) at ognl.SimpleNode.getValue(SimpleNode.java:258) at ognl.Ognl.getValue(Ognl.java:494) at ognl.Ognl.getValue(Ognl.java:458) at com.opensymphony.xwork2.ognl.OgnlUtil.getValue(OgnlUtil.java:213) at com.opensymphony.xwork2.ognl.OgnlValueStack.getValueUsingOgnl(OgnlValueStack.java:277) at com.opensymphony.xwork2.ognl.OgnlValueStack.tryFindValue(OgnlValueStack.java:260) at com.opensymphony.xwork2.ognl.OgnlValueStack.tryFindValueWhenExpressionIsNotNull(OgnlValueStack.java:242) at com.opensymphony.xwork2.ognl.OgnlValueStack.findValue(OgnlValueStack.java:222) at com.opensymphony.xwork2.ognl.OgnlValueStack.findValue(OgnlValueStack.java:284) at org.apache.struts2.views.velocity.StrutsVelocityContext.internalGet(StrutsVelocityContext.java:91) at org.apache.velocity.context.AbstractContext.get(AbstractContext.java:193) at org.apache.velocity.context.InternalContextAdapterImpl.get(InternalContextAdapterImpl.java:286) at org.apache.velocity.runtime.parser.node.ASTReference.getVariableValue(ASTReference.java:843) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:222) at org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:507) at org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71) at org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336) at org.apache.velocity.runtime.directive.Parse.render(Parse.java:263) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336) at org.apache.velocity.runtime.directive.Parse.render(Parse.java:263) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336) at org.apache.velocity.Template.merge(Template.java:328) at org.apache.velocity.Template.merge(Template.java:235) at org.apache.struts2.dispatcher.VelocityResult.doExecute(VelocityResult.java:156) at org.apache.struts2.dispatcher.StrutsResultSupport.execute(StrutsResultSupport.java:186) at com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:374) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:278) at com.sony.sce.producttool.web.CacheFlushFilterInterceptor$2.call(CacheFlushFilterInterceptor.java:69) at com.sony.sce.producttool.web.CacheFlushFilterInterceptor$2.call(CacheFlushFilterInterceptor.java:1) at com.sony.sce.producttool.web.CacheFlushFilterInterceptor.callWithHandling(CacheFlushFilterInterceptor.java:79) at com.sony.sce.producttool.web.CacheFlushFilterInterceptor.intercept(CacheFlushFilterInterceptor.java:67) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at com.opensymphony.xwork2.interceptor.ChainingInterceptor.intercept(ChainingInterceptor.java:145) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:176) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249)
[jira] [Updated] (OGNL-47) Unable to use Struts 2.3.1.2 appliation with OGNL 3.0.4 by enabling security manager
[ https://issues.apache.org/jira/browse/OGNL-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kesava updated OGNL-47: --- Summary: Unable to use Struts 2.3.1.2 appliation with OGNL 3.0.4 by enabling security manager (was: CLONE - Unable to use Struts 2.3.1.2 appliation with OGNL 3.0.4 by enabling security manager ) Unable to use Struts 2.3.1.2 appliation with OGNL 3.0.4 by enabling security manager - Key: OGNL-47 URL: https://issues.apache.org/jira/browse/OGNL-47 Project: Commons OGNL Issue Type: Bug Reporter: kesava Priority: Blocker Unable to use Struts 2.3.1.2 application with OGNL 3.0.4 by enabling security manager Steps to reproduce 1.Enable security manager 2.Load the app Caught an Ognl exception while getting property serviceProviders - Class: ognl.ObjectPropertyAccessor File: ObjectPropertyAccessor.java Method: getPossibleProperty Line: 69 - ognl/ObjectPropertyAccessor.java:69:-1 at com.opensymphony.xwork2.ognl.accessor.CompoundRootAccessor.getProperty(CompoundRootAccessor.java:142) at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:2303) at ognl.ASTProperty.getValueBody(ASTProperty.java:114) at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:212) at ognl.SimpleNode.getValue(SimpleNode.java:258) at ognl.Ognl.getValue(Ognl.java:494) at ognl.Ognl.getValue(Ognl.java:458) at com.opensymphony.xwork2.ognl.OgnlUtil.getValue(OgnlUtil.java:213) at com.opensymphony.xwork2.ognl.OgnlValueStack.getValueUsingOgnl(OgnlValueStack.java:277) at com.opensymphony.xwork2.ognl.OgnlValueStack.tryFindValue(OgnlValueStack.java:260) at com.opensymphony.xwork2.ognl.OgnlValueStack.tryFindValueWhenExpressionIsNotNull(OgnlValueStack.java:242) at com.opensymphony.xwork2.ognl.OgnlValueStack.findValue(OgnlValueStack.java:222) at com.opensymphony.xwork2.ognl.OgnlValueStack.findValue(OgnlValueStack.java:284) at org.apache.struts2.views.velocity.StrutsVelocityContext.internalGet(StrutsVelocityContext.java:91) at org.apache.velocity.context.AbstractContext.get(AbstractContext.java:193) at org.apache.velocity.context.InternalContextAdapterImpl.get(InternalContextAdapterImpl.java:286) at org.apache.velocity.runtime.parser.node.ASTReference.getVariableValue(ASTReference.java:843) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:222) at org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:507) at org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71) at org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336) at org.apache.velocity.runtime.directive.Parse.render(Parse.java:263) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336) at org.apache.velocity.runtime.directive.Parse.render(Parse.java:263) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336) at org.apache.velocity.Template.merge(Template.java:328) at org.apache.velocity.Template.merge(Template.java:235) at org.apache.struts2.dispatcher.VelocityResult.doExecute(VelocityResult.java:156) at org.apache.struts2.dispatcher.StrutsResultSupport.execute(StrutsResultSupport.java:186) at com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:374) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:278) at com.sony.sce.producttool.web.CacheFlushFilterInterceptor$2.call(CacheFlushFilterInterceptor.java:69) at com.sony.sce.producttool.web.CacheFlushFilterInterceptor$2.call(CacheFlushFilterInterceptor.java:1) at com.sony.sce.producttool.web.CacheFlushFilterInterceptor.callWithHandling(CacheFlushFilterInterceptor.java:79) at com.sony.sce.producttool.web.CacheFlushFilterInterceptor.intercept(CacheFlushFilterInterceptor.java:67) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at com.opensymphony.xwork2.interceptor.ChainingInterceptor.intercept(ChainingInterceptor.java:145) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at
[jira] [Commented] (SANDBOX-362) Create basic unit tests for all classes
[ https://issues.apache.org/jira/browse/SANDBOX-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192486#comment-13192486 ] Benedikt Ritter commented on SANDBOX-362: - Forgot to mention: I also added some not null checks to TypeUtil. Create basic unit tests for all classes --- Key: SANDBOX-362 URL: https://issues.apache.org/jira/browse/SANDBOX-362 Project: Commons Sandbox Issue Type: Test Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Benedikt Ritter Attachments: ArgumentTest.zip, SANDBOX-362-RefactoringOfArgumentTest.txt, SANDBOX-362-TypeUtilsTest.txt Back up all existing implementations with unit tests: * Argument * Assertions * BeanUtils * DefaultBeanAccessor * DefaultClassAccessor * MethodRegistry * TypeUtils -- 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] [Updated] (SANDBOX-362) Create basic unit tests for all classes
[ https://issues.apache.org/jira/browse/SANDBOX-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated SANDBOX-362: Attachment: SANDBOX-362-TypeUtilsTest.txt Hi, I have created a patch that adds a unit test for type utils. The test consists of 244 test methods. To be honest, it has been a lot of copy and paste work. But I think that TypeUtils is one of the central classes, so one test more or less doesn't hurt (or does it?). I wanted to test at least every possible combination of primtives and wrapper types. If you think, that the test is to huge, just let me know! @Simo: if you apply the patch, think very carefully if you want to change TypeUtils afterwards. It will beak a bazillion tests ;-) Create basic unit tests for all classes --- Key: SANDBOX-362 URL: https://issues.apache.org/jira/browse/SANDBOX-362 Project: Commons Sandbox Issue Type: Test Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Benedikt Ritter Attachments: ArgumentTest.zip, SANDBOX-362-RefactoringOfArgumentTest.txt, SANDBOX-362-TypeUtilsTest.txt Back up all existing implementations with unit tests: * Argument * Assertions * BeanUtils * DefaultBeanAccessor * DefaultClassAccessor * MethodRegistry * TypeUtils -- 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] [Commented] (SANDBOX-362) Create basic unit tests for all classes
[ https://issues.apache.org/jira/browse/SANDBOX-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192501#comment-13192501 ] Simone Tripodi commented on SANDBOX-362: hey, I usually run tests before committing! Create basic unit tests for all classes --- Key: SANDBOX-362 URL: https://issues.apache.org/jira/browse/SANDBOX-362 Project: Commons Sandbox Issue Type: Test Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Benedikt Ritter Attachments: ArgumentTest.zip, SANDBOX-362-RefactoringOfArgumentTest.txt, SANDBOX-362-TypeUtilsTest.txt Back up all existing implementations with unit tests: * Argument * Assertions * BeanUtils * DefaultBeanAccessor * DefaultClassAccessor * MethodRegistry * TypeUtils -- 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] [Updated] (SANDBOX-355) Provide Flow algorithms
[
https://issues.apache.org/jira/browse/SANDBOX-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claudio Squarcella updated SANDBOX-355:
---
Attachment: SANDBOX-355_FixBugInFordFulkerson.patch
Hi,
I am attaching a patch fixing a bug in my previous implementation of
{{FordFulkerson}}. No {{unchecked}} type casting anymore, this one should be ok
:)
Claudio
Provide Flow algorithms
---
Key: SANDBOX-355
URL: https://issues.apache.org/jira/browse/SANDBOX-355
Project: Commons Sandbox
Issue Type: New Feature
Components: Graph
Reporter: Simone Tripodi
Attachments: SANDBOX-355_FixBugInFordFulkerson.patch,
SANDBOX-355_FordFulkersonImplementationAndTest.patch
right now the {{org.apache.commons.graph.flow}} package contains an empty
implementation of
[Ford-Fulkerson|http://en.wikipedia.org/wiki/Ford%E2%80%93Fulkerson_algorithm]'s
algorithm, that needs to be filled.
Other algorithms that work on resolving Flow-related problems, are welcome.
--
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] [Commented] (LANG-462) FastDateFormat supports parse
[ https://issues.apache.org/jira/browse/LANG-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192687#comment-13192687 ] Charles Honton commented on LANG-462: - 1. Methods FastDateFormat$NumberRule selectNumberRule(int, int) and ListRule parsePattern() couldn't have been overridden because NumberRule and Rule were private to FastDateFormat. 2. Due to the factory pattern used, it's unlikely other two methods would have been overridden. 3. The four methods are highly implementation specific. I consider it a mistake that the methods were exposed. FastDateFormat supports parse - Key: LANG-462 URL: https://issues.apache.org/jira/browse/LANG-462 Project: Commons Lang Issue Type: New Feature Components: lang.time.* Reporter: Franz Wong Fix For: 3.x Attachments: DateParser.patch, LANG-462-FormatCache.patch, LANG-462-Hen.patch, UseFormatCache.patch, lang462.patch, with_interfaces.patch, with_interfaces2.patch, with_updated_tests.patch Currently FastDateFormat only supports formatting the ISO8601 time zone, however, it doesn't support parsing such string to Date. -- 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] [Commented] (OGNL-47) Unable to use Struts 2.3.1.2 appliation with OGNL 3.0.4 by enabling security manager
[ https://issues.apache.org/jira/browse/OGNL-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192843#comment-13192843 ] Maurizio Cucchiara commented on OGNL-47: Hi Kesave and thank you for the issue submission. Could you provide some more details? like for example how did you enable security manager? Are you using tomcat? Unable to use Struts 2.3.1.2 appliation with OGNL 3.0.4 by enabling security manager - Key: OGNL-47 URL: https://issues.apache.org/jira/browse/OGNL-47 Project: Commons OGNL Issue Type: Bug Reporter: kesava Priority: Blocker Unable to use Struts 2.3.1.2 application with OGNL 3.0.4 by enabling security manager Steps to reproduce 1.Enable security manager 2.Load the app Caught an Ognl exception while getting property serviceProviders - Class: ognl.ObjectPropertyAccessor File: ObjectPropertyAccessor.java Method: getPossibleProperty Line: 69 - ognl/ObjectPropertyAccessor.java:69:-1 at com.opensymphony.xwork2.ognl.accessor.CompoundRootAccessor.getProperty(CompoundRootAccessor.java:142) at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:2303) at ognl.ASTProperty.getValueBody(ASTProperty.java:114) at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:212) at ognl.SimpleNode.getValue(SimpleNode.java:258) at ognl.Ognl.getValue(Ognl.java:494) at ognl.Ognl.getValue(Ognl.java:458) at com.opensymphony.xwork2.ognl.OgnlUtil.getValue(OgnlUtil.java:213) at com.opensymphony.xwork2.ognl.OgnlValueStack.getValueUsingOgnl(OgnlValueStack.java:277) at com.opensymphony.xwork2.ognl.OgnlValueStack.tryFindValue(OgnlValueStack.java:260) at com.opensymphony.xwork2.ognl.OgnlValueStack.tryFindValueWhenExpressionIsNotNull(OgnlValueStack.java:242) at com.opensymphony.xwork2.ognl.OgnlValueStack.findValue(OgnlValueStack.java:222) at com.opensymphony.xwork2.ognl.OgnlValueStack.findValue(OgnlValueStack.java:284) at org.apache.struts2.views.velocity.StrutsVelocityContext.internalGet(StrutsVelocityContext.java:91) at org.apache.velocity.context.AbstractContext.get(AbstractContext.java:193) at org.apache.velocity.context.InternalContextAdapterImpl.get(InternalContextAdapterImpl.java:286) at org.apache.velocity.runtime.parser.node.ASTReference.getVariableValue(ASTReference.java:843) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:222) at org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:507) at org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71) at org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336) at org.apache.velocity.runtime.directive.Parse.render(Parse.java:263) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336) at org.apache.velocity.runtime.directive.Parse.render(Parse.java:263) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336) at org.apache.velocity.Template.merge(Template.java:328) at org.apache.velocity.Template.merge(Template.java:235) at org.apache.struts2.dispatcher.VelocityResult.doExecute(VelocityResult.java:156) at org.apache.struts2.dispatcher.StrutsResultSupport.execute(StrutsResultSupport.java:186) at com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:374) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:278) at com.sony.sce.producttool.web.CacheFlushFilterInterceptor$2.call(CacheFlushFilterInterceptor.java:69) at com.sony.sce.producttool.web.CacheFlushFilterInterceptor$2.call(CacheFlushFilterInterceptor.java:1) at com.sony.sce.producttool.web.CacheFlushFilterInterceptor.callWithHandling(CacheFlushFilterInterceptor.java:79) at com.sony.sce.producttool.web.CacheFlushFilterInterceptor.intercept(CacheFlushFilterInterceptor.java:67) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at com.opensymphony.xwork2.interceptor.ChainingInterceptor.intercept(ChainingInterceptor.java:145) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at
[jira] [Commented] (MATH-732) Major Speed Improvement to 1D Discrete Fourier Transform (approximately 5x-9x improvement). Preserved public API 100%. Removed unnecessary use of instance variables and i
[ https://issues.apache.org/jira/browse/MATH-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192851#comment-13192851 ] Bruce A Johnson commented on MATH-732: -- I see your benchmark program does the speed test with a real array as input. Do you know if similar speed gains are present when using a complex array? Major Speed Improvement to 1D Discrete Fourier Transform (approximately 5x-9x improvement). Preserved public API 100%. Removed unnecessary use of instance variables and instance state. Key: MATH-732 URL: https://issues.apache.org/jira/browse/MATH-732 Project: Commons Math Issue Type: Improvement Affects Versions: 3.0 Reporter: Kurt Ostfeld Labels: api, perfomance Fix For: 3.0 Attachments: DFTPerformanceWithPatch.png, DFTPerformanceWithoutPatch.png, FastFourierTransformer.java.diff, FastFourierTransformer.java.diff, FastFourierTransformerTest.java.diff, FastFourierTransformerTest.java.diff, Main.java I wrote my own Discrete Fourier Transform function in Java and ran some benchmarks and found that it ran dramatically faster than the Apache library implementation. This is a pretty straight forward implementation of the standard Cooley Tukey algorithm that I read out of a textbook. This passes all the Apache library test cases plus several I had written on my own. I created a source code library patch that preserves the public API completely while changing the internal implementation to achieve the performance improvement. In addition to the performance issue, I suggest that Discrete Fourier Transform functionality be provided as stateless pure functions (in Java this would be implemented with static methods) just like most other math functions. As-is, the library requires the user to instantiate a Transformer instance which maintains instance state, which is an unecessary complexity for a pure math function. I held off on this change since it would change the public API and affect existing code. However, I see similar backward compatability breaking API changes are already in the FastFourierTransformer class in the 3.0 code base. -- 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
