[jira] [Commented] (MATH-413) Miscellaneous issues concerning the optimization package
[
https://issues.apache.org/jira/browse/MATH-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090885#comment-13090885
]
Gilles commented on MATH-413:
-
{{LevenbergMarquardtOptimizer}} updated in revision 1161463.
Miscellaneous issues concerning the optimization package
--
Key: MATH-413
URL: https://issues.apache.org/jira/browse/MATH-413
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
Revision 990792 contains changes triggered the following issues:
* [MATH-394|https://issues.apache.org/jira/browse/MATH-394]
* [MATH-397|https://issues.apache.org/jira/browse/MATH-397]
* [MATH-404|https://issues.apache.org/jira/browse/MATH-404]
This issue collects the currently still unsatisfactory code (not necessarily
sorted in order of annoyance):
# BrentOptimizer: a specific convergence checker must be used.
LevenbergMarquardtOptimizer also has specific convergence checks.
# Trying to make convergence checking independent of the optimization
algorithm creates problems (conceptual and practical):
** See BrentOptimizer and LevenbergMarquardtOptimizer, the algorithm
passes points to the convergence checker, but the actual meaning of the
points can very well be different in the caller (optimization algorithm) and
the callee (convergence checker).
** In PowellOptimizer the line search (BrentOptimizer) tolerances depend
on the tolerances within the main algorithm. Since tolerances come with
ConvergenceChecker and so can be changed at any time, it is awkward to
adapt the values within the line search optimizer without exposing its
internals (BrentOptimizer field) to the enclosing class (PowellOptimizer).
# Given the numerous changes, some Javadoc comments might be out-of-sync,
although I did try to update them all.
# Class DirectSearchOptimizer (in package optimization.direct) inherits
from class AbstractScalarOptimizer (in package optimization.general).
# Some interfaces are defined in package optimization but their base
implementations (abstract class that contain the boiler-plate code) are in
package optimization.general (e.g.
DifferentiableMultivariateVectorialOptimizer and
BaseAbstractVectorialOptimizer).
# No check is performed to ensure the the convergence checker has been set
(see e.g. BrentOptimizer and PowellOptimizer); if it hasn't there will be
a NPE. The alternative is to initialize a default checker that will never be
used in case the user had intended to explicitly sets the checker.
# NonLinearConjugateGradientOptimizer: Ugly workaround for the checked
ConvergenceException.
# Everywhere, we trail the checked FunctionEvaluationException although it
is never used.
# There remains some duplicate code (such as the multi-start loop in the
various MultiStart... implementations).
# The ConvergenceChecker interface is very general (the converged method
can take any number of ...PointValuePair). However there remains a
semantic problem: One cannot be sure that the list of points means the same
thing for the caller of converged and within the implementation of the
ConvergenceChecker that was independently set.
# It is not clear whether it is wise to aggregate the counter of gradient
evaluations to the function evaluation counter. In
LevenbergMarquartdOptimizer for example, it would be unfair to do so.
Currently I had to remove all tests referring to gradient and Jacobian
evaluations.
# In AbstractLeastSquaresOptimizer and LevenbergMarquardtOptimizer,
occurences of OptimizationException were replaced by the unchecked
ConvergenceException but in some cases it might not be the most appropriate
one.
# MultiStartUnivariateRealOptimizer: in the other classes
(MultiStartMultivariate...) similar to this one, the randomization is on
the firts-guess value while in this class, it is on the search interval. I
think that here also we should randomly choose the start value (within the
user-selected interval).
# The Javadoc utility raises warnings (see output of mvn site) which I
couldn't figure out how to correct.
# Some previously existing classes and interfaces have become no more than a
specialisation of new generics classes; it might be interesting to remove
them in order to reduce the number of classes and thus limit the potential
for confusion.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (NET-420) Retrieving files from AS400 FTP systems returns null timestamps in FTPFile.getTimestamp
Retrieving files from AS400 FTP systems returns null timestamps in FTPFile.getTimestamp --- Key: NET-420 URL: https://issues.apache.org/jira/browse/NET-420 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 2.0 Environment: Commons Net 2.0 FTP System: AS400 systems Reporter: Ramya Rajendiran Priority: Critical We are trying to list files from AS400 systems and retrieve the timestamps from these files using the following code: FTPClientConfig conf = new FTPClientConfig(FTPClientConfig.SYST_AS400); conf.setDefaultDateFormatStr(MM/dd/yy HH:mm:ss); ftpClient.configure(conf); ftpClient.connect(hostName); FTPFile[] file = ftpClient.listFiles(remoteFileName); Calendar timeStamp = files[0].getTimestamp(); timeStamp returned is always null. I have also tried various setting other parsers.. but that also does not work: FTPListParseEngine engine = ftpClient.initiateListParsing(org.apache.commons.net.ftp.parser.OS400FTPEntryParser,remoteFileName); FTPFile[] files = engine.getNext(25); The LIST command which is used internally in the FTPClient retrieves the timestamps successfully. However after parsing the FTPFile has a null value for the timestamp field. I tried the latest commons net 3.0.1 and the problem still exists. Please help us fix this problem. It is critical to us. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-744) StringUtils throws java.security.AccessControlException on Google App Engine
[
https://issues.apache.org/jira/browse/LANG-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13091043#comment-13091043
]
Gary D. Gregory commented on LANG-744:
--
This is not a bug but the way Java Security Manager is designed to work.
The patch should be reverted IMO because the exception is correct.
This does not only happen with GAE, it happens anytime when running under
Java's security manager ({{-Djava.security.manager}})
I do not think we should swallow the exception. In my case, I need to give
proper rights to the code.
In my test at work with the security manager enabled I see:
{{java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessClassInPackage.sun.text)}}
Which means I need to add the following to my .policy file:
{noformat}
grant {
// ...
// Apache Commons Lang3
permission java.lang.RuntimePermission accessClassInPackage.sun.text;
// ...
};
{noformat}
StringUtils throws java.security.AccessControlException on Google App Engine
Key: LANG-744
URL: https://issues.apache.org/jira/browse/LANG-744
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.0.1
Environment: Google App Engine
Reporter: Clément Denis
Fix For: 3.0.2
In the static initializer of org.apache.commons.lang3.StringUtils, there is
an attempt to load the class sun.text.Normalizer.
Such a class is prohibited on Google App Engine, and the static intializer
throws a java.security.AccessControlException.
{code}
Caused by: java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessClassInPackage.sun.text)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
at
java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:166)
at
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512)
at java.lang.Class.checkMemberAccess(Class.java:2164)
at java.lang.Class.getMethod(Class.java:1602)
at org.apache.commons.lang3.StringUtils.clinit(StringUtils.java:739)
{code}
The exception should be caught in the catch clauses around
loadClass(sun.text.Normalizer).
Commons lang 2 worked fine on GAE.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-744) StringUtils throws java.security.AccessControlException on Google App Engine
[
https://issues.apache.org/jira/browse/LANG-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13091062#comment-13091062
]
Clément Denis commented on LANG-744:
I don't agree with that.
The security manager cannot be changed in GAE, or in any other managed
environment with strong security policiy.
The use of a sun.* class is basically a hack, so I don't see why it should
prevent me from using StringUtils in GAE.
From a user point of view, it's a huge regression (I think I'm right when I
say that StringUtils is one of the most widely used class in commons-lang).
It would be acceptable if the method stripAccents raised a RuntimeError if no
Normalizer could be found.
But this bug prevents the use of the whole class.
StringUtils throws java.security.AccessControlException on Google App Engine
Key: LANG-744
URL: https://issues.apache.org/jira/browse/LANG-744
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.0.1
Environment: Google App Engine
Reporter: Clément Denis
Fix For: 3.0.2
In the static initializer of org.apache.commons.lang3.StringUtils, there is
an attempt to load the class sun.text.Normalizer.
Such a class is prohibited on Google App Engine, and the static intializer
throws a java.security.AccessControlException.
{code}
Caused by: java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessClassInPackage.sun.text)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
at
java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:166)
at
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512)
at java.lang.Class.checkMemberAccess(Class.java:2164)
at java.lang.Class.getMethod(Class.java:1602)
at org.apache.commons.lang3.StringUtils.clinit(StringUtils.java:739)
{code}
The exception should be caught in the catch clauses around
loadClass(sun.text.Normalizer).
Commons lang 2 worked fine on GAE.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-744) StringUtils throws java.security.AccessControlException on Google App Engine
[
https://issues.apache.org/jira/browse/LANG-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13091073#comment-13091073
]
Gary D. Gregory commented on LANG-744:
--
The current exception tell you what to do for a normal set up with a security
manager, clean and simple.
If you do not control the security manager, then you are in a pickle. Perhaps
we need some toggle.
The current implementation should at least be revisited because it is wrong to
set sunAvailable to false when in fact I can fix the exception as a user by
editing a text file that can be passed in on the JVM CLI. If I never know that
an exception was thrown, I cannot fix the problem.
StringUtils throws java.security.AccessControlException on Google App Engine
Key: LANG-744
URL: https://issues.apache.org/jira/browse/LANG-744
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.0.1
Environment: Google App Engine
Reporter: Clément Denis
Fix For: 3.0.2
In the static initializer of org.apache.commons.lang3.StringUtils, there is
an attempt to load the class sun.text.Normalizer.
Such a class is prohibited on Google App Engine, and the static intializer
throws a java.security.AccessControlException.
{code}
Caused by: java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessClassInPackage.sun.text)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
at
java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:166)
at
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512)
at java.lang.Class.checkMemberAccess(Class.java:2164)
at java.lang.Class.getMethod(Class.java:1602)
at org.apache.commons.lang3.StringUtils.clinit(StringUtils.java:739)
{code}
The exception should be caught in the catch clauses around
loadClass(sun.text.Normalizer).
Commons lang 2 worked fine on GAE.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (POOL-189) close() does not release threads blocked on borrowObject()
close() does not release threads blocked on borrowObject() -- Key: POOL-189 URL: https://issues.apache.org/jira/browse/POOL-189 Project: Commons Pool Issue Type: Bug Affects Versions: 1.5.6 Environment: java 1.6.0_24 Reporter: Adrian Nistor Hi, When I call close() and borrowObject() concurrently with no objects in the pool, close() will finish but borrowObject() is blocked forever. The documentation of close() mentions that borrowObject() should fail with IllegalStateException, so I would expect the waiting threads to throw IllegalStateException. I will attach a test that exposes this problem. For this test, the expected output is: 0 1 2 ... 4999 DONE But when the bug manifests (almost always for this test), the output is: 0 1 2 The test does not finish, it just gets stuck after printing several values. Is this a bug or am I reading the documentation wrongly? Is there a patch for this? Thanks! Adrian -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (POOL-189) close() does not release threads blocked on borrowObject()
[ https://issues.apache.org/jira/browse/POOL-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Nistor updated POOL-189: --- Attachment: Test.java close() does not release threads blocked on borrowObject() -- Key: POOL-189 URL: https://issues.apache.org/jira/browse/POOL-189 Project: Commons Pool Issue Type: Bug Affects Versions: 1.5.6 Environment: java 1.6.0_24 Reporter: Adrian Nistor Attachments: Test.java Hi, When I call close() and borrowObject() concurrently with no objects in the pool, close() will finish but borrowObject() is blocked forever. The documentation of close() mentions that borrowObject() should fail with IllegalStateException, so I would expect the waiting threads to throw IllegalStateException. I will attach a test that exposes this problem. For this test, the expected output is: 0 1 2 ... 4999 DONE But when the bug manifests (almost always for this test), the output is: 0 1 2 The test does not finish, it just gets stuck after printing several values. Is this a bug or am I reading the documentation wrongly? Is there a patch for this? Thanks! Adrian -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-420) Retrieving files from AS400 FTP systems returns null timestamps in FTPFile.getTimestamp
[ https://issues.apache.org/jira/browse/NET-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13091494#comment-13091494 ] Sebb commented on NET-420: -- Can you provide access to an AS400 FTP server for testing purposes? If not, please at least provide a full listing as returned by the LIST command. Retrieving files from AS400 FTP systems returns null timestamps in FTPFile.getTimestamp --- Key: NET-420 URL: https://issues.apache.org/jira/browse/NET-420 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 2.0 Environment: Commons Net 2.0 FTP System: AS400 systems Reporter: Ramya Rajendiran Priority: Critical We are trying to list files from AS400 systems and retrieve the timestamps from these files using the following code: FTPClientConfig conf = new FTPClientConfig(FTPClientConfig.SYST_AS400); conf.setDefaultDateFormatStr(MM/dd/yy HH:mm:ss); ftpClient.configure(conf); ftpClient.connect(hostName); FTPFile[] file = ftpClient.listFiles(remoteFileName); Calendar timeStamp = files[0].getTimestamp(); timeStamp returned is always null. I have also tried various setting other parsers.. but that also does not work: FTPListParseEngine engine = ftpClient.initiateListParsing(org.apache.commons.net.ftp.parser.OS400FTPEntryParser,remoteFileName); FTPFile[] files = engine.getNext(25); The LIST command which is used internally in the FTPClient retrieves the timestamps successfully. However after parsing the FTPFile has a null value for the timestamp field. I tried the latest commons net 3.0.1 and the problem still exists. Please help us fix this problem. It is critical to us. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-420) Retrieving files from AS400 FTP systems returns null timestamps in FTPFile.getTimestamp
[ https://issues.apache.org/jira/browse/NET-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13091536#comment-13091536 ] Ramya Rajendiran commented on NET-420: -- Sorry that I can not provide an AS400 system.It is inside our intranet. This is the raw listing of the file. Ithas no contents. -rwxrwxrwx 1 RAMYARAJ 0 22 Aug 25 22:31 file.txt Thanks! Retrieving files from AS400 FTP systems returns null timestamps in FTPFile.getTimestamp --- Key: NET-420 URL: https://issues.apache.org/jira/browse/NET-420 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 2.0 Environment: Commons Net 2.0 FTP System: AS400 systems Reporter: Ramya Rajendiran Priority: Critical We are trying to list files from AS400 systems and retrieve the timestamps from these files using the following code: FTPClientConfig conf = new FTPClientConfig(FTPClientConfig.SYST_AS400); conf.setDefaultDateFormatStr(MM/dd/yy HH:mm:ss); ftpClient.configure(conf); ftpClient.connect(hostName); FTPFile[] file = ftpClient.listFiles(remoteFileName); Calendar timeStamp = files[0].getTimestamp(); timeStamp returned is always null. I have also tried various setting other parsers.. but that also does not work: FTPListParseEngine engine = ftpClient.initiateListParsing(org.apache.commons.net.ftp.parser.OS400FTPEntryParser,remoteFileName); FTPFile[] files = engine.getNext(25); The LIST command which is used internally in the FTPClient retrieves the timestamps successfully. However after parsing the FTPFile has a null value for the timestamp field. I tried the latest commons net 3.0.1 and the problem still exists. Please help us fix this problem. It is critical to us. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-748) Change StringUtils.chomp(String, String) to be the same as StringUtils.removeEnd
Change StringUtils.chomp(String, String) to be the same as StringUtils.removeEnd
Key: LANG-748
URL: https://issues.apache.org/jira/browse/LANG-748
Project: Commons Lang
Issue Type: Improvement
Reporter: Henri Yandell
Verneri Åberg reported on the list:
I was just browsing through StringUtils Api (versions 2.5, 2.6 and
3.0.1) and found two very similar looking methods
chomp(String,String)
and
removeEnd(String, String)
So I started to wonder what is the difference here and looked at the
source code.
To my astonishment the only difference is that chomp returns the source
string immediately if the removed string is null and remove end
additionally checks for empty strings too.
So wouldn't it be better to substitute the duplication by simply
replacing the chomp method with following version?
public String chomp(String source, String separator) {
return removeEnd(source,separator);
}
Or is there some hidden idea for two different implementations of the
same string chompping function? if there is maybe it should be added to
both methods javadocs?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (LANG-748) Change StringUtils.chomp(String, String) to be the same as StringUtils.removeEnd
[
https://issues.apache.org/jira/browse/LANG-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed LANG-748.
--
Resolution: Fixed
Fix Version/s: 3.0.2
svn ci -m Deprecating chomp(String, String) per Verneri Åberg's report in
LANG-748
Sendingsrc/main/java/org/apache/commons/lang3/StringUtils.java
Transmitting file data .
Committed revision 1161997.
Change StringUtils.chomp(String, String) to be the same as
StringUtils.removeEnd
Key: LANG-748
URL: https://issues.apache.org/jira/browse/LANG-748
Project: Commons Lang
Issue Type: Improvement
Reporter: Henri Yandell
Fix For: 3.0.2
Verneri Åberg reported on the list:
I was just browsing through StringUtils Api (versions 2.5, 2.6 and
3.0.1) and found two very similar looking methods
chomp(String,String)
and
removeEnd(String, String)
So I started to wonder what is the difference here and looked at the
source code.
To my astonishment the only difference is that chomp returns the source
string immediately if the removed string is null and remove end
additionally checks for empty strings too.
So wouldn't it be better to substitute the duplication by simply
replacing the chomp method with following version?
public String chomp(String source, String separator) {
return removeEnd(source,separator);
}
Or is there some hidden idea for two different implementations of the
same string chompping function? if there is maybe it should be added to
both methods javadocs?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
