[jira] Commented: (MATH-438) Remove deprecated code
[ https://issues.apache.org/jira/browse/MATH-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965561#action_12965561 ] Phil Steitz commented on MATH-438: -- Revision 1040868: Replaced all occurrences of MaximumIterationsExceededException by MaxCountExceededExceptions, except in the deprecated class, ComvergenceAlgorithmImp. Once this class is removed, MaximumIterationsExceededException can be removed. > Remove deprecated code > -- > > Key: MATH-438 > URL: https://issues.apache.org/jira/browse/MATH-438 > Project: Commons Math > Issue Type: Task >Reporter: Gilles >Priority: Minor > Fix For: 3.0 > > > Task for keeping track of the removal of code deprecated in 2.2 and earlier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-447) Create a new "MathRuntimeException"
[
https://issues.apache.org/jira/browse/MATH-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965467#action_12965467
]
Gilles commented on MATH-447:
-
I like the code simplification that will result from a single exception
hierarchy, rooted at {{MathRuntimeException}}. But isn't it a problem to loose
the connection with the "standard" semantics: e.g.
{{MathIllegalArgumentException}} being a subclass of
{{IllegalArgumentException}}?
Or is it sufficient to have a policy stating that "CM will throw an instance of
{{MathIllegalArgumentException}} when encountering an illegal argument"?
> Create a new "MathRuntimeException"
> ---
>
> Key: MATH-447
> URL: https://issues.apache.org/jira/browse/MATH-447
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Fix For: 3.0
>
>
> A new {{MathRuntimeException}} will serve as a base class for all exception
> classes that need to wrap another exception (such as when the wrapped
> exception is deemed too low-level to be propagated).
> Since they share the same code, this class can also be the base class of
> {{MathUserException}}.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-447) Create a new "MathRuntimeException"
[
https://issues.apache.org/jira/browse/MATH-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965336#action_12965336
]
Luc Maisonobe commented on MATH-447:
I heartfully agree to this.
In fact, I even think it would be a better base class for
MathIllegalArugmentException than the java IllegalArgumentException( ditto for
illegal state and arithmetic)
> Create a new "MathRuntimeException"
> ---
>
> Key: MATH-447
> URL: https://issues.apache.org/jira/browse/MATH-447
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Fix For: 3.0
>
>
> A new {{MathRuntimeException}} will serve as a base class for all exception
> classes that need to wrap another exception (such as when the wrapped
> exception is deemed too low-level to be propagated).
> Since they share the same code, this class can also be the base class of
> {{MathUserException}}.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-446) New exceptions to replace those in package "special"
[
https://issues.apache.org/jira/browse/MATH-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965335#action_12965335
]
Luc Maisonobe commented on MATH-446:
I'll prefer simply propagate the more specific exception.
One way to be sure of what may be propagated is to temporarily have
MathIllegalArgumentException, MathIllegalStateException,
MathArithmeticException extend a checked rather than an unchecked exception,
then fix the throws/javadoc and then revert the exception back before commit.
This is how I handled FunctionEvaluationException, MatrixVisitorException and
DerivativeException ; it was much easier and less error-prone than reading code.
> New exceptions to replace those in package "special"
>
>
> Key: MATH-446
> URL: https://issues.apache.org/jira/browse/MATH-446
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gilles
>Priority: Minor
> Fix For: 3.0
>
>
> Classes in this package uses deprecated exception objects
> ({{MaxIterationsExceededException}}).
> Also, many methods have signatures that contain the checked "MathException".
> It should be removed.
> We can either let the {{MaxCountExceededException}} propagate, or wrap it
> into a more general type ({{MathIllegalStateException}} (?)).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-425) New exceptions to replace those in package "linear"
[
https://issues.apache.org/jira/browse/MATH-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965332#action_12965332
]
Luc Maisonobe commented on MATH-425:
I guess NumberIsTooLargeException should be the one. The error is triggered hen
a cutoff value provided by user is so large it is greater than the greatest
singular value.
> New exceptions to replace those in package "linear"
> ---
>
> Key: MATH-425
> URL: https://issues.apache.org/jira/browse/MATH-425
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Fix For: 3.0
>
>
> This issue is about removing the current set of exceptions located in the
> package {{linear}}. The new exceptions must be located in package
> {{exception}}.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-333) Unable to create a JDBC driver using custom class loader
[
https://issues.apache.org/jira/browse/DBCP-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965312#action_12965312
]
Sebb commented on DBCP-333:
---
What about the line a bit earlier which is called if driverClassLoader == null:
Class.forName(driverClassName);
In that case, driverFromCCL won't be initialised either.
It's not clear to me what the code is trying to achieve, but at least at
present it is self-consistent.
Replacing only one of the Class.forName() calls does not seem correct to me.
==
Also, why not replace:
Class.forName(driverClassName, true, driverClassLoader);
with
driverFromCCL = Class.forName(driverClassName, true, driverClassLoader);
Would that not work just as well? Similarly for
Class.forName(driverClassName);
==
The method could do with some Javadoc TLC to explain when the URL is used, and
when the classname is used.
> Unable to create a JDBC driver using custom class loader
>
>
> Key: DBCP-333
> URL: https://issues.apache.org/jira/browse/DBCP-333
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 1.3, 1.4
>Reporter: Krasimir Nedkov
> Fix For: 1.3.1, 1.4.1
>
>
> Hello,
> I'm unable to instantiate my JDBC driver using a custom class loader:
> BasicDataSource ds = new BasicDataSource();
> String connectURL =
> "jdbc:mysql://"+config.getHost()+"/"+config.getDatabaseName();
> ds.setDriverClassName(MySQLStore.MYSQL_DRIVER);
> ds.setDriverClassLoader(config.getClass().getClassLoader());
> .
> Having a look at the
> org.apache.commons.dbcp.BasicDataSource.createConnectionFactory() method
> implementation, I found that the class loader is actually ignored. In the
> first part of the method there is an attempt to load the class that seems to
> pass successfully, but the loaded class is not assigned to the driverFromCCL
> variable:
> if (driverClassLoader == null) {
> Class.forName(driverClassName);
> } else {
> Class.forName(driverClassName, true, driverClassLoader);
> }
> Then in the second part of the method driverFromCCL is still null and instead
> of instantiating the driver directly, DriverManager.getDriver(url) is called,
> which fails:
> if (driverFromCCL == null) {
> driver = DriverManager.getDriver(url);
> } else {
> // Usage of DriverManager is not possible, as it does not
> // respect the ContextClassLoader
> driver = (Driver) driverFromCCL.newInstance();
> if (!driver.acceptsURL(url)) {
> throw new SQLException("No suitable driver", "08001");
> }
> }
> Kind regards,
> Krasimir
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-447) Create a new "MathRuntimeException"
Create a new "MathRuntimeException"
---
Key: MATH-447
URL: https://issues.apache.org/jira/browse/MATH-447
Project: Commons Math
Issue Type: Improvement
Reporter: Gilles
Assignee: Gilles
Priority: Trivial
Fix For: 3.0
A new {{MathRuntimeException}} will serve as a base class for all exception
classes that need to wrap another exception (such as when the wrapped exception
is deemed too low-level to be propagated).
Since they share the same code, this class can also be the base class of
{{MathUserException}}.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-446) New exceptions to replace those in package "special"
New exceptions to replace those in package "special"
Key: MATH-446
URL: https://issues.apache.org/jira/browse/MATH-446
Project: Commons Math
Issue Type: Improvement
Reporter: Gilles
Priority: Minor
Fix For: 3.0
Classes in this package uses deprecated exception objects
({{MaxIterationsExceededException}}).
Also, many methods have signatures that contain the checked "MathException". It
should be removed.
We can either let the {{MaxCountExceededException}} propagate, or wrap it into
a more general type ({{MathIllegalStateException}} (?)).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-445) Replace "package.html" by "package-info.java"
Replace "package.html" by "package-info.java" - Key: MATH-445 URL: https://issues.apache.org/jira/browse/MATH-445 Project: Commons Math Issue Type: Task Reporter: Gilles Priority: Trivial Fix For: 3.0 The newest (and recommended, I think) way of documenting packages is through "package-info.java" files. CM still uses "package.html" files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-425) New exceptions to replace those in package "linear"
[
https://issues.apache.org/jira/browse/MATH-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965215#action_12965215
]
Gilles commented on MATH-425:
-
Class {{SingularValueDecompositionImpl}} still contains one occurrence of
{{MathRuntime}}, at line 195.
Please have a look, and let me know by which new exception it should be
replaced, or if an appropriate replacement is missing.
Same question for the two occurrences in {{RealVectorFormat}}.
> New exceptions to replace those in package "linear"
> ---
>
> Key: MATH-425
> URL: https://issues.apache.org/jira/browse/MATH-425
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Fix For: 3.0
>
>
> This issue is about removing the current set of exceptions located in the
> package {{linear}}. The new exceptions must be located in package
> {{exception}}.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-414) ConvergenceException in NormalDistributionImpl.cumulativeProbability()
[
https://issues.apache.org/jira/browse/MATH-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved MATH-414.
--
Resolution: Fixed
Fixed in r1040471
> ConvergenceException in NormalDistributionImpl.cumulativeProbability()
> --
>
> Key: MATH-414
> URL: https://issues.apache.org/jira/browse/MATH-414
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Jdk 1.6.
>Reporter: Gustav Ryd
>Priority: Minor
> Fix For: 2.2
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> I get a ConvergenceException in
> NormalDistributionImpl.cumulativeProbability() for very large/small
> parameters including Infinity, -Infinity.
> For instance in the following code:
> @Test
> public void testCumulative() {
> final NormalDistribution nd = new NormalDistributionImpl();
> for (int i = 0; i < 500; i++) {
> final double val = Math.exp(i);
> try {
> System.out.println("val = " + val + "
> cumulative = " + nd.cumulativeProbability(val));
> } catch (MathException e) {
> e.printStackTrace();
> fail();
> }
> }
> }
> In version 2.0, I get no exception.
> My suggestion is to change in the implementation of
> cumulativeProbability(double) to catch all ConvergenceException (and return
> for very large and very small values), not just
> MaxIterationsExceededException.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (VALIDATOR-289) UrlValidator.isValid does not properly validate *.travel domains
[ https://issues.apache.org/jira/browse/VALIDATOR-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] GM closed VALIDATOR-289. Resolution: Duplicate Fix Version/s: 1.4 first raised in 2005, fixed in 2007 in 1.4. 1.4 is not yet released. > UrlValidator.isValid does not properly validate *.travel domains > > > Key: VALIDATOR-289 > URL: https://issues.apache.org/jira/browse/VALIDATOR-289 > Project: Commons Validator > Issue Type: Bug >Affects Versions: 1.3.1 Release >Reporter: GM > Fix For: 1.4 > > > UrlValidator.isValid does not properly validate *.travel domains -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (VALIDATOR-289) UrlValidator.isValid does not properly validate *.travel domains
UrlValidator.isValid does not properly validate *.travel domains Key: VALIDATOR-289 URL: https://issues.apache.org/jira/browse/VALIDATOR-289 Project: Commons Validator Issue Type: Bug Affects Versions: 1.3.1 Release Reporter: Stefan UrlValidator.isValid does not properly validate *.travel domains -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CONFIGURATION-429) configuration values of nodes with children inconsistent
[
https://issues.apache.org/jira/browse/CONFIGURATION-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Silas De Munck closed CONFIGURATION-429.
Resolution: Not A Problem
> configuration values of nodes with children inconsistent
>
>
> Key: CONFIGURATION-429
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-429
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Silas De Munck
> Original Estimate: 0.08h
> Remaining Estimate: 0.08h
>
> {quote}
>
>
> 2
>
>
>
> {quote}
> In an XML configfile (see above) where I want to check if a specific node is
> specified. I do this using the containsKey() method on the configuration.
> In this case it will return true for the key "core.singlecore" but not for
> the key "core.multicore".
> If I change the multicore part to this (adding text as a child), it does
> return true.
> {quote}
>
> ABC
> 2
>
> {quote}
> As the containsKey() method depends on the getProperty() method, the same
> problem exists in that method.
> In the first case:
> "core.singlecore" returns an empty string
> "core.multicore" returns null
> and in the second case, "ABC" is returned.
> I would like it to also return an empty string in the first case for
> "core.multicore".
> This behaviour is caused by the code in lines 642-644 of
> XMLConfiguration.java (svn):
> {quote}
>if (text.length() > 0 || (!node.hasChildren() && node != getRoot()))
> \{
> node.setValue(text);
> \}
> {quote}
> I think it can be changed to just this:
> {quote}
> if (node != getRoot() || text.length() > 0)
> \{
> node.setValue(text);
> \}
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
