[jira] [Commented] (MATH-878) G-Test (Log-Likelihood ratio - LLR test) in math.stat.inference
[ https://issues.apache.org/jira/browse/MATH-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483005#comment-13483005 ] Radoslav Tsvetkov commented on MATH-878: I'll add the changes in next 2 days. > G-Test (Log-Likelihood ratio - LLR test) in math.stat.inference > --- > > Key: MATH-878 > URL: https://issues.apache.org/jira/browse/MATH-878 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.1, 3.2, 4.0 > Environment: Netbeans >Reporter: Radoslav Tsvetkov > Labels: features, test > Fix For: 3.1 > > Attachments: MATH-878_gTest_12102012.patch, > MATH-878_gTest_15102012.patch, vcs-diff16294.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > 1. Implementation of G-Test (Log-Likelihood ratio LLR test for independence > and goodnes-of-fit) > 2. Reference: http://en.wikipedia.org/wiki/G-test > 3. Reasons-Usefulness: G-tests are tests are increasingly being used in > situations where chi-squared tests were previously recommended. > The approximation to the theoretical chi-squared distribution for the G-test > is better than for the Pearson chi-squared tests. In cases where Observed > >2*Expected for some cell case, the G-test is always better than the > chi-squared test. > For testing goodness-of-fit the G-test is infinitely more efficient than the > chi squared test in the sense of Bahadur, but the two tests are equally > efficient in the sense of Pitman or in the sense of Hodge and Lehman. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IMAGING-95) Some tiff processing takes very long
[ https://issues.apache.org/jira/browse/IMAGING-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damjan Jovanovic resolved IMAGING-95. - Resolution: Fixed Fix Version/s: 1.0 Fixed. Thank you for your patch! > Some tiff processing takes very long > > > Key: IMAGING-95 > URL: https://issues.apache.org/jira/browse/IMAGING-95 > Project: Commons Imaging > Issue Type: Bug > Components: Format: TIFF >Affects Versions: 1.0 >Reporter: Amit Gupta > Fix For: 1.0 > > Attachments: tiff_perf_fix2.patch > > > org.apache.commons.imaging.formats.tiff.TiffReader.getTiffRawImageData(ByteSource, > TiffDirectory) 226635 1 > org.apache.commons.imaging.common.bytesource.ByteSourceInputStream.getBlock(int, > int) 226588 5616 > org.apache.commons.imaging.common.BinaryFileFunctions.skipBytes(InputStream, > int) 226526 5616 > org.apache.commons.imaging.common.BinaryFileFunctions.skipBytes(InputStream, > int, String) 226526 5616 > org.apache.commons.imaging.common.bytesource.ByteSourceInputStream$CacheReadingInputStream.read(byte[], > int, int) 226526 188656860 > org.apache.commons.imaging.common.bytesource.ByteSourceInputStream$CacheBlock.getNext() >64581 188651244 > skip bytes is being called repeatedly again and again, last column is > invocation count in one call tree. Second column is total number of time > taken by that method in that call tree.. > and skip method is not overridden > org.apache.commons.imaging.common.bytesource.ByteSourceInputStream.CacheReadingInputStream > and default implementation of InputStream tries to use read method (which is > overridden in CacheReadingInputStream) to skip. > In case of a tiff, which has large number of strips, skip is repeatedly > called and use of read is inefficient as it tried to do a System.arraycopy. > array copy is not needed in case of skip operation, as the bytes were already > read in block/cached, we can simply jump the pointer (block by block) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OGNL-225) Merge pull request - Avoid creating empty class array
[ https://issues.apache.org/jira/browse/OGNL-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukasz Lenart updated OGNL-225: --- Summary: Merge pull request - Avoid creating empty class array (was: Merger pull request - Avoid creating empty class array) > Merge pull request - Avoid creating empty class array > - > > Key: OGNL-225 > URL: https://issues.apache.org/jira/browse/OGNL-225 > Project: Commons OGNL > Issue Type: Improvement > Components: Core Runtime >Affects Versions: 3.0 >Reporter: Lukasz Lenart >Priority: Minor > > https://github.com/jkuhnert/ognl/pull/3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OGNL-148) @DatePicker is not working
[ https://issues.apache.org/jira/browse/OGNL-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukasz Lenart resolved OGNL-148. Resolution: Invalid It has nothing to do with OGNL > @DatePicker is not working > -- > > Key: OGNL-148 > URL: https://issues.apache.org/jira/browse/OGNL-148 > Project: Commons OGNL > Issue Type: Bug > Environment: Tapestry 4.1.3 >Reporter: adapala venkta >Assignee: Jesse Kuhnert > > Hai, > i am facing a problem regarding DatePicker.I am using Tapestry 4.1.3 > version. > When i am using DatePicker alone it is working fine but when i am using > inside FloatingPlane it is giving an Javascript error and it is not > working.The error is "calendar_DatePicker_7 is undefined " in IE 6 version. > Eventhough i cleared the cache in IE the same javascript error is found. > The sample code snippet is > class="floatingPaneStyle" hasShadow="true" resizable="false" > > translator="translator:date,pattern=MM/dd/" /> > > Can anyone give some solution to this problem. > Thanks in advance. > sasidhar -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-153) OGNL is taking too much time while fetching values from stack, when 'mapname.key' is given for fetching values, which map been defined in the action class.
[ https://issues.apache.org/jira/browse/OGNL-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482979#comment-13482979 ] Lukasz Lenart commented on OGNL-153: Is it related to Struts 2 ? Did you try to use the latest version ? > OGNL is taking too much time while fetching values from stack, when > 'mapname.key' is given for fetching values, which map been defined in the > action class. > --- > > Key: OGNL-153 > URL: https://issues.apache.org/jira/browse/OGNL-153 > Project: Commons OGNL > Issue Type: Bug >Affects Versions: 2.6.11 >Reporter: sujin >Assignee: Jesse Kuhnert > > OGNL is taking too much time while fetching values from stack, when > 'mapname.key' is given for fetching values, which map been defined in the > action class. > > TPS drastically comes down when map.key is used for fetching values. > (Has this been fixed or a ptach been provided for this) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IMAGING-91) ByteSourceInputStream.streamLength could be a long
[ https://issues.apache.org/jira/browse/IMAGING-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damjan Jovanovic resolved IMAGING-91. - Resolution: Fixed Fix Version/s: 1.0 Thank you, it's fixed now :). > ByteSourceInputStream.streamLength could be a long > -- > > Key: IMAGING-91 > URL: https://issues.apache.org/jira/browse/IMAGING-91 > Project: Commons Imaging > Issue Type: Improvement >Reporter: Sebb >Priority: Trivial > Fix For: 1.0 > > > ByteSourceInputStream.streamLength is currently a Long. > Since it has to be positive, it could be converted to an long, e.g. using -1 > as the equivalent of null. > This would save some boxing/unboxing and instance creation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-185) Performance issue on high load (thread blocking)
[ https://issues.apache.org/jira/browse/OGNL-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482977#comment-13482977 ] Lukasz Lenart commented on OGNL-185: This issue can be closed as the related Struts2 issues was already solved. > Performance issue on high load (thread blocking) > > > Key: OGNL-185 > URL: https://issues.apache.org/jira/browse/OGNL-185 > Project: Commons OGNL > Issue Type: Bug >Reporter: Christian Grobmeier >Assignee: Maurizio Cucchiara >Priority: Critical > Attachments: thread-dump-lock2.txt, thread-dump-lock.txt > > > The Struts project is suffering from an issue occuring from OGNL on heavy > load. > The issue in question (with details) is: > https://issues.apache.org/jira/browse/WW-3580 > A similar issues has been reported in the OpenSymphony bugtracker: > https://issues.apache.org/jira/browse/WW-3580 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-167) Critical performance issue in production environment as thread dumps are leading to OGNL 3.0 thread blocking! Website could be backed out!
[ https://issues.apache.org/jira/browse/OGNL-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482971#comment-13482971 ] Lukasz Lenart commented on OGNL-167: Did you try to use the latest Struts2/OGNL ? The problem should be solved. > Critical performance issue in production environment as thread dumps are > leading to OGNL 3.0 thread blocking! Website could be backed out! > -- > > Key: OGNL-167 > URL: https://issues.apache.org/jira/browse/OGNL-167 > Project: Commons OGNL > Issue Type: Bug > Environment: Struts 2.2.1 >Reporter: Shishir Kumar Bala >Assignee: Jesse Kuhnert >Priority: Blocker > > My web application based on Struts 2.2.1 is using OGNL 3.0. This web > application is rolled into production; however, due to serious performance > considerations the website is in danger of being rolled back. The thread > dumps indicate 'BLOCKING' at > ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:804). > The thread trace is as: > "httpSSLWorkerThread-6357-6" daemon prio=3 tid=0x01a07000 nid=0xa6 > waiting for monitor entry [0xb6d79000..0xb6d7faf0] >java.lang.Thread.State: BLOCKED (on object monitor) > at ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:804) > - waiting to lock <0xcca6d328> (a java.lang.reflect.Method) > at ognl.OgnlRuntime.getMethodValue(OgnlRuntime.java:1434) > at > ognl.ObjectPropertyAccessor.getPossibleProperty(ObjectPropertyAccessor.java:60) > at > ognl.ObjectPropertyAccessor.getProperty(ObjectPropertyAccessor.java:147) > at > com.opensymphony.xwork2.ognl.accessor.ObjectAccessor.getProperty(ObjectAccessor.java:17) > at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:2230) > at > com.opensymphony.xwork2.ognl.accessor.CompoundRootAccessor.getProperty(CompoundRootAccessor.java:137) > at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:2230) > 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 sun.reflect.GeneratedMethodAccessor111.invoke(Unknown Source) > > quot;httpSSLWorkerThread-6357-4" daemon prio=3 tid=0x01a56800 nid=0xa4 > runnable [0xb6f79000..0xb6f7fbf0] >java.lang.Thread.State: RUNNABLE > at java.security.AccessController.$$YJP$$doPrivileged(Native Method) > at java.security.AccessController.doPrivileged(AccessController.java) > at > com.sun.enterprise.security.provider.PolicyFile.addPermissions(PolicyFile.java:1333) > at > com.sun.enterprise.security.provider.PolicyFile.getPermissions(PolicyFile.java:1290) > at > com.sun.enterprise.security.provider.PolicyFile.getPermissions(PolicyFile.java:1256) > at > com.sun.enterprise.security.provider.PolicyFile.getPermissions(PolicyFile.java:1198) > at > com.sun.enterprise.security.provider.PolicyFile.implies(PolicyFile.java:1153) > at > com.sun.enterprise.security.provider.BasePolicyWrapper.doImplies(BasePolicyWrapper.java:383) > at > com.sun.enterprise.security.provider.BasePolicyWrapper.implies(BasePolicyWrapper.java:237) > at java.security.ProtectionDomain.implies(ProtectionDomain.java:213) > at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:301) > at > java.security.AccessController.checkPermission(AccessController.java:546) > at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) > at > java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:107) > at ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:839) > - locked <0xcca6d328> (a java.lang.reflect.Method) > at ognl.OgnlRuntime.getMethodValue(OgnlRuntime.java:1434) > at > ognl.ObjectPropertyAccessor.getPossibleProperty(ObjectPropertyAccessor.java:60) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, se
[jira] [Commented] (OGNL-170) OGNL Expression Take CPU of the application High
[ https://issues.apache.org/jira/browse/OGNL-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482966#comment-13482966 ] Lukasz Lenart commented on OGNL-170: Is it still related with the latest version of OGNL 3.x ? > OGNL Expression Take CPU of the application High > > > Key: OGNL-170 > URL: https://issues.apache.org/jira/browse/OGNL-170 > Project: Commons OGNL > Issue Type: Bug > Components: Infrastructure (website/etc) > Environment: ALL >Reporter: Kaushik Lakshminarayanan >Assignee: Jesse Kuhnert >Priority: Blocker > > When running Struts with OGNL CPU is buring high.No threads are in Blocked > stage. > We are using 3.0. Please advise latest stable version. > JSTL is faster when we replace code instead of OGNL. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-177) Unable to use Struts 2.3.1.2 application with OGNL 3.0.4 by enabling security manager
[
https://issues.apache.org/jira/browse/OGNL-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482964#comment-13482964
]
Lukasz Lenart commented on OGNL-177:
Is it related to WW-3746 ? If so the problem is already solved with OGNL 3.0.5
- https://github.com/jkuhnert/ognl
> Unable to use Struts 2.3.1.2 application with OGNL 3.0.4 by enabling security
> manager
> --
>
> Key: OGNL-177
> URL: https://issues.apache.org/jira/browse/OGNL-177
> 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
> {noformat}
> 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)
>
[jira] [Commented] (IMAGING-96) Full exif tag description ?
[
https://issues.apache.org/jira/browse/IMAGING-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482963#comment-13482963
]
Damjan Jovanovic commented on IMAGING-96:
-
Through what API?
You can already do this:
{code}
TiffDirectory tiffDirectory = ...
int exposureProgram =
tiffDirectory.getSingleFieldValue(ExifTagConstants.EXIF_TAG_EXPOSURE_PROGRAM);
switch (exposureProgram) {
case EXPOSURE_PROGRAM_VALUE_MANUAL: return "manual";
}
{code}
> Full exif tag description ?
>
>
> Key: IMAGING-96
> URL: https://issues.apache.org/jira/browse/IMAGING-96
> Project: Commons Imaging
> Issue Type: Question
> Components: Format: JPEG
>Reporter: Piotr Czajka
>
> Is it possible to get a full exif tag description ?
> e.g.
> Simple output from Imaging:
> //...
> ExposureProgram : 1
> //...
> In exif tagg spec. I found :
> ExposureProgram
> The specification defines these values:
> 0 = Not defined
> 1 = Manual
> 2 = Normal program
> 3 = Aperture priority
> 4 = Shutter priority
> 5 = Creative program (biased toward depth of field)
> 6 = Action program (biased toward fast shutter speed)
> 7 = Portrait mode (for closeup photos with the background out of focus)
> 8 = Landscape mode (for landscape photos with the background in focus)
> Can I receive description in that form :
> ExposureProgram : Manual ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-757) ResizableDoubleArray is not thread-safe yet has some synch. methods
[ https://issues.apache.org/jira/browse/MATH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482890#comment-13482890 ] Gilles commented on MATH-757: - Wouldn't removing it break _usage_: from supposedly thread-safe to definitely unsafe? > ResizableDoubleArray is not thread-safe yet has some synch. methods > --- > > Key: MATH-757 > URL: https://issues.apache.org/jira/browse/MATH-757 > Project: Commons Math > Issue Type: Bug >Reporter: Sebb > Fix For: 3.1 > > > ResizableDoubleArray has several synchronised methods, but is not > thread-safe, because class variables are not always accessed using the lock. > Is the class supposed to be thread-safe? > If so, all accesses (read and write) need to be synch. > If not, the synch. qualifiers could be dropped. > In any case, the protected fields need to be made private. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-845) Spelling fixes
[
https://issues.apache.org/jira/browse/LANG-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved LANG-845.
---
Resolution: Fixed
Fix Version/s: 3.2
Patch applied, thank you! The DateUtilsTest changes did not apply cleanly to
trunk, so I excluded them.
{noformat}
commit -m "[LANG-845] Spelling fixes." (16 paths specified)
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/changes/changes.xml
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/main/java/org/apache/commons/lang3/ArrayUtils.java
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/main/java/org/apache/commons/lang3/ClassUtils.java
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/main/java/org/apache/commons/lang3/exception/ExceptionUtils.java
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/main/java/org/apache/commons/lang3/math/Fraction.java
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/main/java/org/apache/commons/lang3/text/StrBuilder.java
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/main/java/org/apache/commons/lang3/text/StrMatcher.java
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/main/java/org/apache/commons/lang3/time/StopWatch.java
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/site/resources/release-notes/RELEASE-NOTES-1.0.txt
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/site/resources/release-notes/RELEASE-NOTES-2.0.txt
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/site/resources/release-notes/RELEASE-NOTES-3.0.txt
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/site/xdoc/developerguide.xml
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/site/xdoc/mail-lists.xml
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/site/xdoc/upgradeto2_0.xml
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/site/xdoc/upgradeto3_0.xml
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/site/xdoc/userguide.xml
Transmitting file data ...
Committed revision 1401523.
{noformat}
> Spelling fixes
> --
>
> Key: LANG-845
> URL: https://issues.apache.org/jira/browse/LANG-845
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Ville Skyttä
>Priority: Minor
> Labels: patch
> Fix For: 3.2
>
> Attachments: 0001-Spelling-fixes.patch
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-339) StringEscapeUtils.escapeHtml() escapes multibyte characters like Chinese, Japanese, etc.
[ https://issues.apache.org/jira/browse/LANG-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LANG-339: -- Summary: StringEscapeUtils.escapeHtml() escapes multibyte characters like Chinese, Japanese, etc. (was: StringEscapeUtils.escapeHtml() escapes multibyte characters like Chinese, Japanes, etc.) > StringEscapeUtils.escapeHtml() escapes multibyte characters like Chinese, > Japanese, etc. > > > Key: LANG-339 > URL: https://issues.apache.org/jira/browse/LANG-339 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 2.3 > Environment: Operating System: All > Platform: All >Reporter: Guo Yong > Fix For: 3.0 > > > StringEscapeUtils.escapeHtml() escapes multibyte characters like Chinese, > Japanes, etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-769) Please restore NotImplementedException and UnhandledException
[
https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482875#comment-13482875
]
Gary Gregory commented on LANG-769:
---
Interesting, NotImplementedException could mean, "not yet" or "not ever". So
expressing the intention in the positive could help: {{ToDoException}},
{{ToBeImplementedException}}, and the like. I could see usage like {{throw new
ToDoException("LANG-987");}}
> Please restore NotImplementedException and UnhandledException
> -
>
> Key: LANG-769
> URL: https://issues.apache.org/jira/browse/LANG-769
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.exception.*
>Reporter: david cogen
>Priority: Minor
>
> Why were these removed? I found these very useful and used them often. As the
> version 2.6 api javadoc states, "This exception supplements the standard
> exception classes by providing a more semantically rich description of the
> problem."
> Just want you to realize that these have found direct use outside the
> library; not just internal use within commons-lang.
> I will define these missing classes myself, or maybe include both
> commons-lang and commons-lang3 (but I really don't to do that). It would be
> very nice to have these back.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-352) Spelling fixes
[
https://issues.apache.org/jira/browse/IO-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved IO-352.
-
Resolution: Fixed
Fix Version/s: 2.5
Thank you for the patch. 2 files did not apply cleanly so I excluded those.
{noformat}
commit -m "[IO-352] Spelling fixes." (17 paths specified)
SendingC:/svn/org/apache/commons/trunks-proper/io/RELEASE-NOTES.txt
SendingC:/svn/org/apache/commons/trunks-proper/io/build.xml
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/changes/changes.xml
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/changes/release-notes.vm
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/EndianUtils.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/IOUtils.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/ThreadMonitor.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/comparator/ExtensionFileComparator.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/comparator/NameFileComparator.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/comparator/PathFileComparator.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/filefilter/TrueFileFilter.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/input/ReversedLinesFileReader.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/output/ByteArrayOutputStream.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/site/xdoc/mail-lists.xml
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/site/xdoc/upgradeto1_1.xml
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/test/java/org/apache/commons/io/DirectoryWalkerTestCase.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/test/java/org/apache/commons/io/DirectoryWalkerTestCaseJava4.java
Transmitting file data ...
Committed revision 1401522.
{noformat}
> Spelling fixes
> --
>
> Key: IO-352
> URL: https://issues.apache.org/jira/browse/IO-352
> Project: Commons IO
> Issue Type: Improvement
>Reporter: Ville Skyttä
>Priority: Minor
> Labels: patch
> Fix For: 2.5
>
> Attachments: 0001-Spelling-fixes.patch
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-757) ResizableDoubleArray is not thread-safe yet has some synch. methods
[ https://issues.apache.org/jira/browse/MATH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482823#comment-13482823 ] Sebb commented on MATH-757: --- The synch. keyword does not affect binary or source compatibility. > ResizableDoubleArray is not thread-safe yet has some synch. methods > --- > > Key: MATH-757 > URL: https://issues.apache.org/jira/browse/MATH-757 > Project: Commons Math > Issue Type: Bug >Reporter: Sebb > Fix For: 3.1 > > > ResizableDoubleArray has several synchronised methods, but is not > thread-safe, because class variables are not always accessed using the lock. > Is the class supposed to be thread-safe? > If so, all accesses (read and write) need to be synch. > If not, the synch. qualifiers could be dropped. > In any case, the protected fields need to be made private. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-757) ResizableDoubleArray is not thread-safe yet has some synch. methods
[ https://issues.apache.org/jira/browse/MATH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482806#comment-13482806 ] Gilles commented on MATH-757: - Yes, the object is mutable; I actually meant to increase the degree of encapsulation by removing some bells and whistles that will hardly be used (what kind of situation would need a change of those "contraction/expansion" properties during the lifetime of the object?). This class represents an array of primitive doubles that can adapt its size. Fine, but if CM does not use whatever refinement can be put into such a functionality, I don't see why we should maintain an overly complicated object. I'd guess that users would not look at CM for this kind of utility (which belongs to e.g. "Commons Primitives"). I can understand the existence of this class in CM given the no-dependencies requirement, but that leads us back to my point (why maintain functionality beyond what is used internally?). Of course, I do not suggest to remove the methods right now; just starting a discussion for 4.0. At this time, I'm not even sure that the "synchronized" keywords can be removed (wouldn't it break compatibility?). > ResizableDoubleArray is not thread-safe yet has some synch. methods > --- > > Key: MATH-757 > URL: https://issues.apache.org/jira/browse/MATH-757 > Project: Commons Math > Issue Type: Bug >Reporter: Sebb > Fix For: 3.1 > > > ResizableDoubleArray has several synchronised methods, but is not > thread-safe, because class variables are not always accessed using the lock. > Is the class supposed to be thread-safe? > If so, all accesses (read and write) need to be synch. > If not, the synch. qualifiers could be dropped. > In any case, the protected fields need to be made private. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-769) Please restore NotImplementedException and UnhandledException
[
https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482741#comment-13482741
]
Steve Gillam commented on LANG-769:
---
Disambiguation/Accuracy of the semantic (and, thus, its name) is key here -
otherwise it will quickly lose it's worth and become a valid candidate for
disappearing again (as any such should be).
Whilst Not(Un)Implemented is the most often created it does not communicate the
semantic well and could well be confused with the permanent decision not to
implement an optionalAPI call.
It somehow needs to represent itself (and, thus, the response (human/systemic)
as being a function of the development lifecycle ('You told me you'd
finished!'). Perhaps others cleverer than I can propose a succinct
representation?
Obviously it needs to be a subclass of RuntimeException so we don't have to run
around polluting 'completed' code with throws clauses :)
> Please restore NotImplementedException and UnhandledException
> -
>
> Key: LANG-769
> URL: https://issues.apache.org/jira/browse/LANG-769
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.exception.*
>Reporter: david cogen
>Priority: Minor
>
> Why were these removed? I found these very useful and used them often. As the
> version 2.6 api javadoc states, "This exception supplements the standard
> exception classes by providing a more semantically rich description of the
> problem."
> Just want you to realize that these have found direct use outside the
> library; not just internal use within commons-lang.
> I will define these missing classes myself, or maybe include both
> commons-lang and commons-lang3 (but I really don't to do that). It would be
> very nice to have these back.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-845) Spelling fixes
Ville Skyttä created LANG-845: - Summary: Spelling fixes Key: LANG-845 URL: https://issues.apache.org/jira/browse/LANG-845 Project: Commons Lang Issue Type: Improvement Reporter: Ville Skyttä Priority: Minor Attachments: 0001-Spelling-fixes.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-845) Spelling fixes
[ https://issues.apache.org/jira/browse/LANG-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ville Skyttä updated LANG-845: -- Attachment: 0001-Spelling-fixes.patch > Spelling fixes > -- > > Key: LANG-845 > URL: https://issues.apache.org/jira/browse/LANG-845 > Project: Commons Lang > Issue Type: Improvement >Reporter: Ville Skyttä >Priority: Minor > Labels: patch > Attachments: 0001-Spelling-fixes.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-352) Spelling fixes
[ https://issues.apache.org/jira/browse/IO-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ville Skyttä updated IO-352: Attachment: 0001-Spelling-fixes.patch > Spelling fixes > -- > > Key: IO-352 > URL: https://issues.apache.org/jira/browse/IO-352 > Project: Commons IO > Issue Type: Improvement >Reporter: Ville Skyttä >Priority: Minor > Labels: patch > Attachments: 0001-Spelling-fixes.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-352) Spelling fixes
Ville Skyttä created IO-352: --- Summary: Spelling fixes Key: IO-352 URL: https://issues.apache.org/jira/browse/IO-352 Project: Commons IO Issue Type: Improvement Reporter: Ville Skyttä Priority: Minor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-882) Complete decomposition solver support in EigenDecomposition for complex eigenvalues
Thomas Neidhart created MATH-882: Summary: Complete decomposition solver support in EigenDecomposition for complex eigenvalues Key: MATH-882 URL: https://issues.apache.org/jira/browse/MATH-882 Project: Commons Math Issue Type: Bug Affects Versions: 3.1 Reporter: Thomas Neidhart Fix For: 4.0 The current DecompositionSolver in EigenDecomposition only supports real eigenvalues. With the recently added support for non-symmetric matrices, also complex eigenvalues are possible as result of the decomposition. In such a case, an MathUnsupportedOperationException is thrown when trying to get a DecompositionSolver with getSolver(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-440) [SFTP] Stream (e.g. netcat) proxy for Sftp file system (aka ProxyCommand)
[
https://issues.apache.org/jira/browse/VFS-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482666#comment-13482666
]
Gary Gregory commented on VFS-440:
--
Sadly no.
> [SFTP] Stream (e.g. netcat) proxy for Sftp file system (aka ProxyCommand)
> -
>
> Key: VFS-440
> URL: https://issues.apache.org/jira/browse/VFS-440
> Project: Commons VFS
> Issue Type: Improvement
>Reporter: Benjamin Piwowarski
>Priority: Minor
> Labels: proxy, sftp
> Attachments: sftp-stream-proxy.diff, sftp-stream-proxy-v2.diff
>
>
> What I propose is to add the possibility to connect to a remote SSH server
> through an SSH connection stream (instead of an HTTP or SOCKS proxy). See for
> instance
> http://backdrift.org/transparent-proxy-with-ssh
> for a use case.
> This simulates a ProxyCommand where the command is run on a SSH host.
> The patch also contains a test for the new functionality.
> Example of use (with the netcat command nc -q 0 HOSTNAME PORT)
> {code:java}
> builder.setProxyType(opts, SftpFileSystemConfigBuilder.PROXY_STREAM);
> builder.setProxyCommand(opts, SftpStreamProxy.NETCAT_COMMAND);
> builder.setProxyHost(opts, "gate.way.host");
> builder.setProxyPort(opts, 22);
> builder.setProxyOptions(opts, proxyOptions);
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-440) [SFTP] Stream (e.g. netcat) proxy for Sftp file system (aka ProxyCommand)
[
https://issues.apache.org/jira/browse/VFS-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482663#comment-13482663
]
Benjamin Piwowarski commented on VFS-440:
-
Yes, the test should be platform independent (the nc command is built it into
the SSH test server, so it shouldn't matter whether it is run on Windows or
not). I will try latter to see what might be wrong. Can you see how many tests
have been run?
> [SFTP] Stream (e.g. netcat) proxy for Sftp file system (aka ProxyCommand)
> -
>
> Key: VFS-440
> URL: https://issues.apache.org/jira/browse/VFS-440
> Project: Commons VFS
> Issue Type: Improvement
>Reporter: Benjamin Piwowarski
>Priority: Minor
> Labels: proxy, sftp
> Attachments: sftp-stream-proxy.diff, sftp-stream-proxy-v2.diff
>
>
> What I propose is to add the possibility to connect to a remote SSH server
> through an SSH connection stream (instead of an HTTP or SOCKS proxy). See for
> instance
> http://backdrift.org/transparent-proxy-with-ssh
> for a use case.
> This simulates a ProxyCommand where the command is run on a SSH host.
> The patch also contains a test for the new functionality.
> Example of use (with the netcat command nc -q 0 HOSTNAME PORT)
> {code:java}
> builder.setProxyType(opts, SftpFileSystemConfigBuilder.PROXY_STREAM);
> builder.setProxyCommand(opts, SftpStreamProxy.NETCAT_COMMAND);
> builder.setProxyHost(opts, "gate.way.host");
> builder.setProxyPort(opts, 22);
> builder.setProxyOptions(opts, proxyOptions);
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-757) ResizableDoubleArray is not thread-safe yet has some synch. methods
[ https://issues.apache.org/jira/browse/MATH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482623#comment-13482623 ] Phil Steitz commented on MATH-757: -- Good catch on the extraneous should Contract above. That only has relevance in the addElementRolling method, so I would see the above change as safe. On the other point, I disagree. This class is by nature mutable - it maintains a dynamic data structure. To make it threadsafe, we would have to protect all of the data members. The protected methods are there to allow subclasses to override specific behaviors. Eliminating mutability of exposed properties limits the functionality of the class. We don't use that mutability now in [math], but the class is public and others may use it. The key point is that making things like expansion factor and expansion mode immutable does little / nothing to move toward threadsafety, while limiting functionality. > ResizableDoubleArray is not thread-safe yet has some synch. methods > --- > > Key: MATH-757 > URL: https://issues.apache.org/jira/browse/MATH-757 > Project: Commons Math > Issue Type: Bug >Reporter: Sebb > Fix For: 3.1 > > > ResizableDoubleArray has several synchronised methods, but is not > thread-safe, because class variables are not always accessed using the lock. > Is the class supposed to be thread-safe? > If so, all accesses (read and write) need to be synch. > If not, the synch. qualifiers could be dropped. > In any case, the protected fields need to be made private. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-226) Race condition with OgnlRuntime.getMethod
[ https://issues.apache.org/jira/browse/OGNL-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482616#comment-13482616 ] Lukasz Lenart commented on OGNL-226: Pull request accepted, should it be applied to Apache OGNL ? > Race condition with OgnlRuntime.getMethod > - > > Key: OGNL-226 > URL: https://issues.apache.org/jira/browse/OGNL-226 > Project: Commons OGNL > Issue Type: Bug > Components: Core Runtime >Affects Versions: 3.0 >Reporter: Johno Crawford >Priority: Minor > Attachments: OgnlRuntimeTest.java > > > If there are two consecutive calls to OgnlRuntime.getMethod before the result > is cached it may erroneously return null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OGNL-224) Performance - Locking and performance problem with OgnlRuntime.findParameterTypes
[ https://issues.apache.org/jira/browse/OGNL-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukasz Lenart resolved OGNL-224. Resolution: Fixed Fix Version/s: 3.0 it'll be included with 3.0.6 release > Performance - Locking and performance problem with > OgnlRuntime.findParameterTypes > - > > Key: OGNL-224 > URL: https://issues.apache.org/jira/browse/OGNL-224 > Project: Commons OGNL > Issue Type: Improvement > Components: Core Runtime >Affects Versions: 3.0 >Reporter: Pelladi Gabor >Assignee: Lukasz Lenart >Priority: Minor > Labels: patch, perfomance > Fix For: 3.0 > > Attachments: OGNL-224.patch, OgnlRuntimeTest.java > > > I am using struts2 and under heavy load (around 100 threads) many threads are > in BLOCKED state because of OgnlRuntime.findParameterTypes(). The actions we > use have a generic superclass like: > public class PersonalCaptureAction extends DataCaptureAction > OGNL handles this very bad, it enters > synchronized (_genericMethodParameterTypesCache) > all the time, at every property access of the Action. A possible workaround > is to introduce another layer of superclass that is not generic. > I know that in current OGNL trunk (4.0-SNAPSHOT) caching has been rewritten, > but Struts2 is using 3.0.5, and maybe it could be fixed as 3.0.6 in the git > tree I found: > https://github.com/jkuhnert/ognl > I will attach a patch and a testcase. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-224) Performance - Locking and performance problem with OgnlRuntime.findParameterTypes
[ https://issues.apache.org/jira/browse/OGNL-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482606#comment-13482606 ] Lukasz Lenart commented on OGNL-224: Done, I was able to merge the patch into current source code > Performance - Locking and performance problem with > OgnlRuntime.findParameterTypes > - > > Key: OGNL-224 > URL: https://issues.apache.org/jira/browse/OGNL-224 > Project: Commons OGNL > Issue Type: Improvement > Components: Core Runtime >Affects Versions: 3.0 >Reporter: Pelladi Gabor >Assignee: Lukasz Lenart >Priority: Minor > Labels: patch, perfomance > Attachments: OGNL-224.patch, OgnlRuntimeTest.java > > > I am using struts2 and under heavy load (around 100 threads) many threads are > in BLOCKED state because of OgnlRuntime.findParameterTypes(). The actions we > use have a generic superclass like: > public class PersonalCaptureAction extends DataCaptureAction > OGNL handles this very bad, it enters > synchronized (_genericMethodParameterTypesCache) > all the time, at every property access of the Action. A possible workaround > is to introduce another layer of superclass that is not generic. > I know that in current OGNL trunk (4.0-SNAPSHOT) caching has been rewritten, > but Struts2 is using 3.0.5, and maybe it could be fixed as 3.0.6 in the git > tree I found: > https://github.com/jkuhnert/ognl > I will attach a patch and a testcase. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-440) [SFTP] Stream (e.g. netcat) proxy for Sftp file system (aka ProxyCommand)
[
https://issues.apache.org/jira/browse/VFS-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482603#comment-13482603
]
Gary Gregory commented on VFS-440:
--
Hi Benjamin,
Thank you, the new patch is easier to look at.
When I test the build with "mvn test", it hangs, and I see the following on the
console:
{noformat}
Running org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase
Sftp server started on port 63772
true
created threads still running:
#1: mainNioProcessor-17 not_a_daemonclass
java.util.concurrent.ThreadPoolExecutor$Worker
#2: mainpool-11-thread-1not_a_daemonclass
java.util.concurrent.ThreadPoolExecutor$Worker
#3: mainConnect thread localhost sessiondaemon class
com.jcraft.jsch.Session
#4: mainThread-24 not_a_daemonclass
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem
#5: mainNioProcessor-13 not_a_daemonclass
java.util.concurrent.ThreadPoolExecutor$Worker
#6: mainConnect thread localhost sessiondaemon class
com.jcraft.jsch.Session
#7: mainThread-26 not_a_daemonclass
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem
#8: mainNioProcessor-14 not_a_daemonclass
java.util.concurrent.ThreadPoolExecutor$Worker
#9: mainConnect thread localhost sessiondaemon class
com.jcraft.jsch.Session
#10: main Thread-28 not_a_daemonclass
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem
#11: main NioProcessor-15 not_a_daemonclass
java.util.concurrent.ThreadPoolExecutor$Worker
#12: main Connect thread localhost sessiondaemon class
com.jcraft.jsch.Session
#13: main Thread-30 not_a_daemonclass
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem
#14: main Thread-33 not_a_daemonclass
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem
#15: main Thread-49 not_a_daemonclass
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem
#16: main Thread-50 not_a_daemonclass
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem
#17: main Thread-51 not_a_daemonclass
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem
created threads still running:
#1: mainConnect thread localhost sessiondaemon class
com.jcraft.jsch.Session
#2: mainNioProcessor-17 not_a_daemonclass
java.util.concurrent.ThreadPoolExecutor$Worker
#3: mainfrom nc daemon class
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$7
#4: mainto nc daemon class
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$7
#5: mainConnect thread localhost sessiondaemon class
com.jcraft.jsch.Session
#6: mainThread-55 not_a_daemonclass
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem
#7: mainThread-57 not_a_daemonclass
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem
{noformat}
But... I am on Windows. My set up is:
Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
Maven home: C:\Java\apache-maven-3.0.4\bin\..
Java version: 1.6.0_35, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_35\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Is the new test platform independent?
If not, it should be skipped for Windows and if run, it should return an error.
Is the issue that the embedded SFTP server is trying to run the nc command (and
there is nc.exe on Windows)?
> [SFTP] Stream (e.g. netcat) proxy for Sftp file system (aka ProxyCommand)
> -
>
> Key: VFS-440
> URL: https://issues.apache.org/jira/browse/VFS-440
> Project: Commons VFS
> Issue Type: Improvement
>Reporter: Benjamin Piwowarski
>Priority: Minor
> Labels: proxy, sftp
> Attachments: sftp-stream-proxy.diff, sftp-stream-proxy-v2.diff
>
>
> What I propose is to add the possibility to connect to a remote SSH server
> through an SSH connection stream (instead of an HTTP or SOCKS proxy). See for
> instance
> http://backdrift.org/transparent-proxy-with-ssh
> for a use case.
> This simulates a ProxyCommand where the command is run on a SSH host.
> The patch also contains a test for the new functionality.
> Example of use (with the netcat command nc -q 0 HOSTNAME PORT)
> {code:java}
> builder.setProxyType(opts, SftpFileSystemConfigBuilder.PROXY_STREAM);
> builder.setP
[jira] [Commented] (LANG-769) Please restore NotImplementedException and UnhandledException
[
https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482567#comment-13482567
]
Gary Gregory commented on LANG-769:
---
I can see that there can be a subtle difference between
{{NotImplementedException}} and {{UnsupportedOperationException}}, so I am in
favor of adding NotImplementedException back, which could also be named
{{UnimplementedException }}
> Please restore NotImplementedException and UnhandledException
> -
>
> Key: LANG-769
> URL: https://issues.apache.org/jira/browse/LANG-769
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.exception.*
>Reporter: david cogen
>Priority: Minor
>
> Why were these removed? I found these very useful and used them often. As the
> version 2.6 api javadoc states, "This exception supplements the standard
> exception classes by providing a more semantically rich description of the
> problem."
> Just want you to realize that these have found direct use outside the
> library; not just internal use within commons-lang.
> I will define these missing classes myself, or maybe include both
> commons-lang and commons-lang3 (but I really don't to do that). It would be
> very nice to have these back.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (LANG-769) Please restore NotImplementedException and UnhandledException
[
https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482567#comment-13482567
]
Gary Gregory edited comment on LANG-769 at 10/23/12 6:52 PM:
-
I can see that there can be a subtle difference between
{{NotImplementedException}} and {{UnsupportedOperationException}}, so I am in
favor of adding {{NotImplementedException}} back, which could also be named
{{UnimplementedException}}
was (Author: garydgregory):
I can see that there can be a subtle difference between
{{NotImplementedException}} and {{UnsupportedOperationException}}, so I am in
favor of adding NotImplementedException back, which could also be named
{{UnimplementedException }}
> Please restore NotImplementedException and UnhandledException
> -
>
> Key: LANG-769
> URL: https://issues.apache.org/jira/browse/LANG-769
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.exception.*
>Reporter: david cogen
>Priority: Minor
>
> Why were these removed? I found these very useful and used them often. As the
> version 2.6 api javadoc states, "This exception supplements the standard
> exception classes by providing a more semantically rich description of the
> problem."
> Just want you to realize that these have found direct use outside the
> library; not just internal use within commons-lang.
> I will define these missing classes myself, or maybe include both
> commons-lang and commons-lang3 (but I really don't to do that). It would be
> very nice to have these back.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-769) Please restore NotImplementedException and UnhandledException
[
https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482555#comment-13482555
]
Steve Gillam commented on LANG-769:
---
If we're down to quoting design principles G. Booch is God: "An abstraction
denotes the essential characteristics of an object that distinguish it from all
other kinds of object and thus provide crisply defined conceptual boundaries,
relative to the perspective of the viewer." (Object-Oriented Design With
Applications, Benjamin/Cummings, Menlo Park, California, 1991.)
Exception("NullPointer") (and synonyms) -> NullPointerException
UnSupportedOperationException("NotImplemented") (and synonyms) ->
NotImplementedException
Is it an abstraction relevant to the community at large? Not counting those in
this thread... .Net, IBM, Google, NetBeans, JBoss, Mozilla...(gave up counting)
> Please restore NotImplementedException and UnhandledException
> -
>
> Key: LANG-769
> URL: https://issues.apache.org/jira/browse/LANG-769
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.exception.*
>Reporter: david cogen
>Priority: Minor
>
> Why were these removed? I found these very useful and used them often. As the
> version 2.6 api javadoc states, "This exception supplements the standard
> exception classes by providing a more semantically rich description of the
> problem."
> Just want you to realize that these have found direct use outside the
> library; not just internal use within commons-lang.
> I will define these missing classes myself, or maybe include both
> commons-lang and commons-lang3 (but I really don't to do that). It would be
> very nice to have these back.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-769) Please restore NotImplementedException and UnhandledException
[ https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482367#comment-13482367 ] Charles Honton commented on LANG-769: - Joshua Bloch's "Item 60: Favor the use of standard exceptions" (From "Effective Java") is appropriate here. I recommend using java.lang.UnsupportedOperationException and java.lang.IllegalStateException. If you need additional context, use a constructor that sets the detail message. > Please restore NotImplementedException and UnhandledException > - > > Key: LANG-769 > URL: https://issues.apache.org/jira/browse/LANG-769 > Project: Commons Lang > Issue Type: Improvement > Components: lang.exception.* >Reporter: david cogen >Priority: Minor > > Why were these removed? I found these very useful and used them often. As the > version 2.6 api javadoc states, "This exception supplements the standard > exception classes by providing a more semantically rich description of the > problem." > Just want you to realize that these have found direct use outside the > library; not just internal use within commons-lang. > I will define these missing classes myself, or maybe include both > commons-lang and commons-lang3 (but I really don't to do that). It would be > very nice to have these back. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-226) Race condition with OgnlRuntime.getMethod
[ https://issues.apache.org/jira/browse/OGNL-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482354#comment-13482354 ] Johno Crawford commented on OGNL-226: - PR with fix at https://github.com/jkuhnert/ognl/pull/4 > Race condition with OgnlRuntime.getMethod > - > > Key: OGNL-226 > URL: https://issues.apache.org/jira/browse/OGNL-226 > Project: Commons OGNL > Issue Type: Bug > Components: Core Runtime >Affects Versions: 3.0 >Reporter: Johno Crawford >Priority: Minor > Attachments: OgnlRuntimeTest.java > > > If there are two consecutive calls to OgnlRuntime.getMethod before the result > is cached it may erroneously return null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OGNL-226) Race condition with OgnlRuntime.getMethod
[ https://issues.apache.org/jira/browse/OGNL-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johno Crawford updated OGNL-226: Flags: Patch > Race condition with OgnlRuntime.getMethod > - > > Key: OGNL-226 > URL: https://issues.apache.org/jira/browse/OGNL-226 > Project: Commons OGNL > Issue Type: Bug > Components: Core Runtime >Affects Versions: 3.0 >Reporter: Johno Crawford >Priority: Minor > Attachments: OgnlRuntimeTest.java > > > If there are two consecutive calls to OgnlRuntime.getMethod before the result > is cached it may erroneously return null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-351) The Tailer keeps closing and re-opening file, leads to logs lost while file rotation.
Wally Qiao created IO-351: - Summary: The Tailer keeps closing and re-opening file, leads to logs lost while file rotation. Key: IO-351 URL: https://issues.apache.org/jira/browse/IO-351 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 2.4 Environment: Linux/Win Reporter: Wally Qiao If reOpen is true, log texts reading lost while file rotation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-757) ResizableDoubleArray is not thread-safe yet has some synch. methods
[
https://issues.apache.org/jira/browse/MATH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482289#comment-13482289
]
Gilles commented on MATH-757:
-
I find the "addElement" method a little strange:
{code}
public synchronized void addElement(double value) {
numElements++;
if ((startIndex + numElements) > internalArray.length) {
expand();
}
internalArray[startIndex + (numElements - 1)] = value;
if (shouldContract()) {
contract();
}
}
{code}
Why would we want to contract just after _adding_ an element?
This seems to be arguably useful only if the "initial capacity" was not set
correctly. In fact, the current code always contracts the array (created with
the default constructor) at the first call to "addElement" because the default
initial capacity (16) is "too large" for an array that contains a single
element...
The method would also probably be slightly more efficient if written as:
{code}
public synchronized void addElement(double value) {
if (internalArray.length <= startIndex + numElements) {
expand();
}
internalArray[startIndex + numElements++] = value;
}
{code}
> ResizableDoubleArray is not thread-safe yet has some synch. methods
> ---
>
> Key: MATH-757
> URL: https://issues.apache.org/jira/browse/MATH-757
> Project: Commons Math
> Issue Type: Bug
>Reporter: Sebb
> Fix For: 3.1
>
>
> ResizableDoubleArray has several synchronised methods, but is not
> thread-safe, because class variables are not always accessed using the lock.
> Is the class supposed to be thread-safe?
> If so, all accesses (read and write) need to be synch.
> If not, the synch. qualifiers could be dropped.
> In any case, the protected fields need to be made private.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-757) ResizableDoubleArray is not thread-safe yet has some synch. methods
[ https://issues.apache.org/jira/browse/MATH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482280#comment-13482280 ] Gilles commented on MATH-757: - The class is also more complicated than necessary by having public and protected setters for variables that are only set at construction. Removing those would allow making the corresponding fields private (and thus getting closer to the goal of thread-safety, by immutability). > ResizableDoubleArray is not thread-safe yet has some synch. methods > --- > > Key: MATH-757 > URL: https://issues.apache.org/jira/browse/MATH-757 > Project: Commons Math > Issue Type: Bug >Reporter: Sebb > Fix For: 3.1 > > > ResizableDoubleArray has several synchronised methods, but is not > thread-safe, because class variables are not always accessed using the lock. > Is the class supposed to be thread-safe? > If so, all accesses (read and write) need to be synch. > If not, the synch. qualifiers could be dropped. > In any case, the protected fields need to be made private. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMMONSSITE-72) Workround for MSITE-646/MSITE-660: relative Javadoc links are mangled
[ https://issues.apache.org/jira/browse/COMMONSSITE-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated COMMONSSITE-72: Attachment: COMMONSSITE-72.patch > Workround for MSITE-646/MSITE-660: relative Javadoc links are mangled > - > > Key: COMMONSSITE-72 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-72 > Project: Commons All > Issue Type: Improvement >Reporter: Sebb > Attachments: COMMONSSITE-72.patch > > > As reported in FUNCTOR-23, relative links to Javadoc methods are mangled by > Doxia. > Since absolute links are not mangled, one work-round is to convert all such > Javadoc links to absolute links. However that causes various problems. > An alternative work-round is to convert links to absolute, but using a fixed > dummy host name prefix, and then remove the dummy prefix after the output has > been processed by Doxia. > This is easy to do using the Velocity Macro stylesheet. > See attached patch to follow. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COMMONSSITE-72) Workround for MSITE-646/MSITE-660: relative Javadoc links are mangled
Sebb created COMMONSSITE-72: --- Summary: Workround for MSITE-646/MSITE-660: relative Javadoc links are mangled Key: COMMONSSITE-72 URL: https://issues.apache.org/jira/browse/COMMONSSITE-72 Project: Commons All Issue Type: Improvement Reporter: Sebb As reported in FUNCTOR-23, relative links to Javadoc methods are mangled by Doxia. Since absolute links are not mangled, one work-round is to convert all such Javadoc links to absolute links. However that causes various problems. An alternative work-round is to convert links to absolute, but using a fixed dummy host name prefix, and then remove the dummy prefix after the output has been processed by Doxia. This is easy to do using the Velocity Macro stylesheet. See attached patch to follow. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-836) StrSubstitutor does not support StringBuilder or CharSequence
[ https://issues.apache.org/jira/browse/LANG-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482231#comment-13482231 ] Sebb commented on LANG-836: --- Thanks, unfortunately the patch breaks binary compatibility. > StrSubstitutor does not support StringBuilder or CharSequence > - > > Key: LANG-836 > URL: https://issues.apache.org/jira/browse/LANG-836 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb > Attachments: LANG-836.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-440) [SFTP] Stream (e.g. netcat) proxy for Sftp file system (aka ProxyCommand)
[
https://issues.apache.org/jira/browse/VFS-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Piwowarski updated VFS-440:
Attachment: sftp-stream-proxy-v2.diff
Cleaned up patch with more comments
> [SFTP] Stream (e.g. netcat) proxy for Sftp file system (aka ProxyCommand)
> -
>
> Key: VFS-440
> URL: https://issues.apache.org/jira/browse/VFS-440
> Project: Commons VFS
> Issue Type: Improvement
>Reporter: Benjamin Piwowarski
>Priority: Minor
> Labels: proxy, sftp
> Attachments: sftp-stream-proxy.diff, sftp-stream-proxy-v2.diff
>
>
> What I propose is to add the possibility to connect to a remote SSH server
> through an SSH connection stream (instead of an HTTP or SOCKS proxy). See for
> instance
> http://backdrift.org/transparent-proxy-with-ssh
> for a use case.
> This simulates a ProxyCommand where the command is run on a SSH host.
> The patch also contains a test for the new functionality.
> Example of use (with the netcat command nc -q 0 HOSTNAME PORT)
> {code:java}
> builder.setProxyType(opts, SftpFileSystemConfigBuilder.PROXY_STREAM);
> builder.setProxyCommand(opts, SftpStreamProxy.NETCAT_COMMAND);
> builder.setProxyHost(opts, "gate.way.host");
> builder.setProxyPort(opts, 22);
> builder.setProxyOptions(opts, proxyOptions);
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-836) StrSubstitutor does not support StringBuilder or CharSequence
[ https://issues.apache.org/jira/browse/LANG-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud BRUNET updated LANG-836: --- Attachment: LANG-836.patch Added an implementation : - StrBuilder(String) -> StrBuilder(CharSequence) - replace() methods use CharSequence - added replaceIn(StringBuilder) methods > StrSubstitutor does not support StringBuilder or CharSequence > - > > Key: LANG-836 > URL: https://issues.apache.org/jira/browse/LANG-836 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb > Attachments: LANG-836.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-769) Please restore NotImplementedException and UnhandledException
[ https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482206#comment-13482206 ] Steve Gillam commented on LANG-769: --- All the difference in the world - 'NotImplemented' is typically static and nothing YOU can do will change it, 'Unsupported' is typically state driven (e.g driveBicycle(fish)). My client wants to know the difference (esp. during rapid TDD): 'Unsupported': I think you've been silly 'NotImplemented': come back later or go shout at somebody. > Please restore NotImplementedException and UnhandledException > - > > Key: LANG-769 > URL: https://issues.apache.org/jira/browse/LANG-769 > Project: Commons Lang > Issue Type: Improvement > Components: lang.exception.* >Reporter: david cogen >Priority: Minor > > Why were these removed? I found these very useful and used them often. As the > version 2.6 api javadoc states, "This exception supplements the standard > exception classes by providing a more semantically rich description of the > problem." > Just want you to realize that these have found direct use outside the > library; not just internal use within commons-lang. > I will define these missing classes myself, or maybe include both > commons-lang and commons-lang3 (but I really don't to do that). It would be > very nice to have these back. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (LANG-837) ObjectUtils.identityToString does not support StringBuilder or StrBuilder or Appendable
[
https://issues.apache.org/jira/browse/LANG-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482202#comment-13482202
]
Arnaud BRUNET edited comment on LANG-837 at 10/23/12 8:37 AM:
--
Added 3 new methods :
{code}
public static void identityToString(Appendable appendable, Object object)
throws IOException
public static void identityToString(StrBuilder builder, Object object)
public static void identityToString(StringBuilder builder, Object object)
{code}
was (Author: gronono):
Adding 3 new methods :
{code}
public static void identityToString(Appendable appendable, Object object)
throws IOException
public static void identityToString(StrBuilder builder, Object object)
public static void identityToString(StringBuilder builder, Object object)
{code}
> ObjectUtils.identityToString does not support StringBuilder or StrBuilder or
> Appendable
> ---
>
> Key: LANG-837
> URL: https://issues.apache.org/jira/browse/LANG-837
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Sebb
> Attachments: LANG-837.patch
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-837) ObjectUtils.identityToString does not support StringBuilder or StrBuilder or Appendable
[
https://issues.apache.org/jira/browse/LANG-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud BRUNET updated LANG-837:
---
Attachment: LANG-837.patch
Adding 3 new methods :
{code}
public static void identityToString(Appendable appendable, Object object)
throws IOException
public static void identityToString(StrBuilder builder, Object object)
public static void identityToString(StringBuilder builder, Object object)
{code}
> ObjectUtils.identityToString does not support StringBuilder or StrBuilder or
> Appendable
> ---
>
> Key: LANG-837
> URL: https://issues.apache.org/jira/browse/LANG-837
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Sebb
> Attachments: LANG-837.patch
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-350) Maven-Bundle-Plugin imports version 2.4 as 1.4
Adrian Moerchen created IO-350:
--
Summary: Maven-Bundle-Plugin imports version 2.4 as 1.4
Key: IO-350
URL: https://issues.apache.org/jira/browse/IO-350
Project: Commons IO
Issue Type: Bug
Affects Versions: 2.4
Reporter: Adrian Moerchen
Attachments: commons-io-osgi-bug.zip
In 2.4 you added
{code}
org.apache.commons.io;
org.apache.commons.io.comparator;
org.apache.commons.io.filefilter;
org.apache.commons.io.input;
org.apache.commons.io.output;version=1.4.;-noimport:=true,
org.apache.commons.io;
org.apache.commons.io.comparator;
org.apache.commons.io.filefilter;
org.apache.commons.io.input;
org.apache.commons.io.output;
org.apache.commons.io.*;version=${project.version};-noimport:=true
{code}
This creates an entry in the MANIFEST.MF like
{code}
Import-Package: org.apache.commons.io;version="[1.4,2)"
{code}
Which leads to our bundles not working with 2.4, as we are exporting 2.4 and
not 1.4 in our application.
I think the solution is, that if somebody want's to use it as 1.4 he should
export the packages as 1.4 by themselves.
I added an example project.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-350) Maven-Bundle-Plugin imports version 2.4 as 1.4
[
https://issues.apache.org/jira/browse/IO-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrian Moerchen updated IO-350:
---
Attachment: commons-io-osgi-bug.zip
> Maven-Bundle-Plugin imports version 2.4 as 1.4
> --
>
> Key: IO-350
> URL: https://issues.apache.org/jira/browse/IO-350
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Adrian Moerchen
> Attachments: commons-io-osgi-bug.zip
>
>
> In 2.4 you added
> {code}
>
>
> org.apache.commons.io;
> org.apache.commons.io.comparator;
> org.apache.commons.io.filefilter;
> org.apache.commons.io.input;
> org.apache.commons.io.output;version=1.4.;-noimport:=true,
>
> org.apache.commons.io;
> org.apache.commons.io.comparator;
> org.apache.commons.io.filefilter;
> org.apache.commons.io.input;
> org.apache.commons.io.output;
> org.apache.commons.io.*;version=${project.version};-noimport:=true
>
> {code}
> This creates an entry in the MANIFEST.MF like
> {code}
> Import-Package: org.apache.commons.io;version="[1.4,2)"
> {code}
> Which leads to our bundles not working with 2.4, as we are exporting 2.4 and
> not 1.4 in our application.
> I think the solution is, that if somebody want's to use it as 1.4 he should
> export the packages as 1.4 by themselves.
> I added an example project.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
