[jira] [Updated] (LANG-613) ConstructorUtils.getAccessibleConstructor() Does Not Check the Accessibility of Enclosing Classes
[ https://issues.apache.org/jira/browse/LANG-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Tels updated LANG-613: -- Attachment: LANG-613_Recursive_visibility_check_up_the_enclosing_tree.patch I've uploaded a patch with a check that a constructor is either: - For a normal, top-level class; or - for an inner class that is a public, top-level class enclosed in a (set of) classes such that it is still visible. For the visibility rule I have maintained the existing rule in ConstructorUtils that "visible" means "public". However, that is not quite correct in reality -- a constructor of an inner class can still be visible if it is contained within a class with default or protected visibility and the accessing code is in the right package. I'll leave the code this way as long as the Commons-Lang team does not decide to change the definition used. > ConstructorUtils.getAccessibleConstructor() Does Not Check the Accessibility > of Enclosing Classes > - > > Key: LANG-613 > URL: https://issues.apache.org/jira/browse/LANG-613 > Project: Commons Lang > Issue Type: Bug > Components: lang.reflect.* >Affects Versions: 3.0 >Reporter: David M. Sledge >Priority: Minor > Fix For: 3.x > > Attachments: > LANG-613_Recursive_visibility_check_up_the_enclosing_tree.patch > > > ConstructorUtils.getAccessibleConstructor() checks if the declaring class is > public but not whether it's a top-level class or an enclosed one. > Consequently, with enclosed declaring classes, the method does not check if > the enclosing class is public, or it's enclosing class, or it's enclosing > class, etc... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-674) NumberUtils and decimal point characte
[ https://issues.apache.org/jira/browse/LANG-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096760#comment-13096760 ] Ben Tels commented on LANG-674: --- I have to say I agree with Stevo that something is rotten in the state of Denmark with this one. True, what exactly is wrong depends on your point of view, but it is definitely something. If, as Stephen says, the semantics of NumberUtils should match those of Java sourcecode, then the simple problem is that the documentation on the methods in NumberUtils doesn't SAY that. Or otherwise doesn't say that you're supposed to use input formatted according to the en_US locale. >From a different point of view, the (larger) problem may indeed be that the >NumberUtils methods do not take locale into account. In the nl locale, as >Stevo says, the value "123,4" is a valid number equivalent to 1234/10. Perhaps a good solution is to do both: overload all the methods that take String arguments to take a Locale argument as well, then put in the documentation that the existing methods implicitly use locale en_US. > NumberUtils and decimal point characte > -- > > Key: LANG-674 > URL: https://issues.apache.org/jira/browse/LANG-674 > Project: Commons Lang > Issue Type: Bug > Components: lang.math.* >Reporter: Henri Yandell > Fix For: 3.x > > > Stevo Slavić reports on commons-user: > Is there any valid reason why '.' is hardcoded as decimal point > character in lang.math.NumberUtils, commons-lang (2.6) ? Shouldn't > this be locale dependent? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-172) implementation of implicit Runge-Kutta method for stiff differential equations
[ https://issues.apache.org/jira/browse/MATH-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096692#comment-13096692 ] Dennis Hendriks commented on MATH-172: -- Luc, thanks for the in-depth answer. It makes it all much clearer. It sounds like you are well on your way with this. Keep up the good work! > implementation of implicit Runge-Kutta method for stiff differential equations > -- > > Key: MATH-172 > URL: https://issues.apache.org/jira/browse/MATH-172 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: James Housden >Assignee: Luc Maisonobe > Fix For: 3.0 > > Attachments: bdf-2009-07-07.patch > > > In version 1.2 several explicit Runge-Kutta methods have been implemented > which work fine for non-stiff problems. However these methods are not > suitable for stiff equations. The implementation of an implicit Runge-Kutta > method such as Radau5 would extend the functionality of the ode package to > cover the solution of stiff ordinary differential equations. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-655) General framework for iterative algorithms
[
https://issues.apache.org/jira/browse/MATH-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096691#comment-13096691
]
Sébastien Brisard commented on MATH-655:
All right. I also like Phil's idea. I'll do the indicated changes. It's true
that the renamed {{IterationManager}} can be seen as a kind of improved
{{Incrementor}}. I guess the best place to put the proposed classes would be
o.a.c.m.utils (just like {{Incrementor}}).
I'll try and include this new feature in the ConjugateGradient method, see how
it works.
Thanks for your advice!
> General framework for iterative algorithms
> --
>
> Key: MATH-655
> URL: https://issues.apache.org/jira/browse/MATH-655
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Priority: Minor
> Labels: algorithm, events
> Attachments: iterative-algorithm.zip
>
>
> Following the thread [Monitoring iterative
> algorithms|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/%3CCAGRH7HrgcgoBA=jcoKovjiQU=TjpQHnspBkOGNCu7oDdKk=k...@mail.gmail.com%3E],
> here is a first attempt at defining a general enough framework for iterative
> algorithms at large. At the moment, the classes provide support for
> * maximum number of iterations
> * events handling
> ** initialization event (prior to entering the main loop),
> ** iteration event (after completion of one iteration),
> ** termination event (after termination of the main loop).
> These classes do not yet provide support for a stopping criterion.
> Some points worth to note
> * For the time being, the classes are part of the o.a.c.m.linear package.
> * For the time being, {{IterativeAlgorithm.incrementIterationCount()}} throws
> a {{TooManyEvaluationsException}}. If the proposed new feature is integrated
> into CM, then a proper {{TooManyIterationsException}} should be created, from
> which the former could derive.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-419) Not possible to call FTPClient.abort() method correctly
[ https://issues.apache.org/jira/browse/NET-419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096681#comment-13096681 ] Bogdan Drozdowski commented on NET-419: --- No need to ping us. We see your message. We may not reply immediately, but your issue is still open. The problem is that it's not that easy just to provide thread-safety. If the methods are synchronized, you won't be able to call abort() when another method is executing (like retrieveFile()). Perhaps just command sending should be synchronized (to synchronize the input/output buffers), but that won't always solve the problem, because some commands (like file send/retrieve) have two replies and the client needs to wait for the second one, so it needs to be in the synchronized block while the operation you want to abort is being performed. Right now we dont' have synchronized blocks, so you can call abort() at any time (and mostly it will work). If we had everything synchronized, you wouldn't be able to call abort() during the operation at all. So even if the current solution is not perfect, the synchronized solution is even worse. This needs a re-think of what should be done. > Not possible to call FTPClient.abort() method correctly > --- > > Key: NET-419 > URL: https://issues.apache.org/jira/browse/NET-419 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.0 > Environment: java version "1.6.0_26" > Java(TM) SE Runtime Environment (build 1.6.0_26-b03) > Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) > Linux cattie 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC 2011 > x86_64 x86_64 x86_64 GNU/Linux >Reporter: Tomas Mysik > > Unfortunately, it seems that there are difficulties of using FTPClient.abort() > method [1][2]. Also, it is really not clear how the abort() method should be > called/used at all - if from another thread (as I would expect) then there is > a problem with > thread-safety: FTPClient itself is not thread-safe so it means that some > custom lock/monitor must be used; but this lock will prevent calling abort() > on > the FTPClient while it is downloading/uploading file since file > upload/download > itself is blocking... > If I'm wrong and the abort() method works then an example in Javadoc would be > more than welcome. > Thanks a lot. > [1] > http://apache-commons.680414.n4.nabble.com/Net-FTPClient-abort-problem-td739542.html > [2] http://www.tikalk.com/java/forums/apache-ftp-client-abort-transfer -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-655) General framework for iterative algorithms
[
https://issues.apache.org/jira/browse/MATH-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096676#comment-13096676
]
Luc Maisonobe commented on MATH-655:
I think composition would be fine. Most probably, most immediate changes in ODE
would be limited to our own classes and not user classes. The changes in user
classes could be dealt with progressively if we deprecate an interface and set
up other interfaces.
We have to be aware that the continuous output and events handling features in
ODE are really very important. But I think the proposed API improves things and
suits our needs. I did not try to go all the way and check it on real code, but
I am confident it will be possible.
> General framework for iterative algorithms
> --
>
> Key: MATH-655
> URL: https://issues.apache.org/jira/browse/MATH-655
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Priority: Minor
> Labels: algorithm, events
> Attachments: iterative-algorithm.zip
>
>
> Following the thread [Monitoring iterative
> algorithms|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/%3CCAGRH7HrgcgoBA=jcoKovjiQU=TjpQHnspBkOGNCu7oDdKk=k...@mail.gmail.com%3E],
> here is a first attempt at defining a general enough framework for iterative
> algorithms at large. At the moment, the classes provide support for
> * maximum number of iterations
> * events handling
> ** initialization event (prior to entering the main loop),
> ** iteration event (after completion of one iteration),
> ** termination event (after termination of the main loop).
> These classes do not yet provide support for a stopping criterion.
> Some points worth to note
> * For the time being, the classes are part of the o.a.c.m.linear package.
> * For the time being, {{IterativeAlgorithm.incrementIterationCount()}} throws
> a {{TooManyEvaluationsException}}. If the proposed new feature is integrated
> into CM, then a proper {{TooManyIterationsException}} should be created, from
> which the former could derive.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-655) General framework for iterative algorithms
[
https://issues.apache.org/jira/browse/MATH-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096670#comment-13096670
]
Phil Steitz commented on MATH-655:
--
Luc, what do you think about my idea of using composition - so the ODE classes
would include a monitor element that extends the base monitor?
> General framework for iterative algorithms
> --
>
> Key: MATH-655
> URL: https://issues.apache.org/jira/browse/MATH-655
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Priority: Minor
> Labels: algorithm, events
> Attachments: iterative-algorithm.zip
>
>
> Following the thread [Monitoring iterative
> algorithms|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/%3CCAGRH7HrgcgoBA=jcoKovjiQU=TjpQHnspBkOGNCu7oDdKk=k...@mail.gmail.com%3E],
> here is a first attempt at defining a general enough framework for iterative
> algorithms at large. At the moment, the classes provide support for
> * maximum number of iterations
> * events handling
> ** initialization event (prior to entering the main loop),
> ** iteration event (after completion of one iteration),
> ** termination event (after termination of the main loop).
> These classes do not yet provide support for a stopping criterion.
> Some points worth to note
> * For the time being, the classes are part of the o.a.c.m.linear package.
> * For the time being, {{IterativeAlgorithm.incrementIterationCount()}} throws
> a {{TooManyEvaluationsException}}. If the proposed new feature is integrated
> into CM, then a proper {{TooManyIterationsException}} should be created, from
> which the former could derive.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-172) implementation of implicit Runge-Kutta method for stiff differential equations
[ https://issues.apache.org/jira/browse/MATH-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096643#comment-13096643 ] Luc Maisonobe commented on MATH-172: The fact is our ODE package implies really rich algorithms. For example, it is mandatory to provide a continuous output over the last computed step, and it is mandatory to support discrete events. When a reference algorithm did not support these features, we had to add them by ourselves. It was never a problem since efficient and complex algorithms do provide the necessary features already. We had to do the math only for really trivial cases like Euler or classical Runge-Kutta. For Adams or BDF algorithms, continuous output is not a problem, because the formula are already based on interpolation, so the interpolator is already there, we simply make it available to the step handlers. Events handling was more difficult but we have already factored some of the code. Another point is I really need adaptive step size, so while I was setting up the method, I extended it at the same time. This is not something I invented myself, there are several references about this and the Nordiseck vector method was a perfect fit for my needs. I did not find however a thourough algorithm with all the features I needed, I only found a lot of different papers addressing different parts, and I basically gather everything in one implementation. I recently found another reference about adaptive step size Adams methods but did not had time to review it and compare it with Nordsieck vector approach. One thing that could be done would be to implement simpler stiff methods, like for exemple implicit Runge-Kutta. I have tried this but am not sure I still have my attempts around. There are several different ways to solve the implicit system, using simple iterations, trying to solve the system completely, trying to solve it by using only the diagonal elements of the Jacobian ... I think we need to have all these methods available with a user setting. > implementation of implicit Runge-Kutta method for stiff differential equations > -- > > Key: MATH-172 > URL: https://issues.apache.org/jira/browse/MATH-172 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: James Housden >Assignee: Luc Maisonobe > Fix For: 3.0 > > Attachments: bdf-2009-07-07.patch > > > In version 1.2 several explicit Runge-Kutta methods have been implemented > which work fine for non-stiff problems. However these methods are not > suitable for stiff equations. The implementation of an implicit Runge-Kutta > method such as Radau5 would extend the functionality of the ode package to > cover the solution of stiff ordinary differential equations. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-655) General framework for iterative algorithms
[
https://issues.apache.org/jira/browse/MATH-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096640#comment-13096640
]
Luc Maisonobe commented on MATH-655:
As a side note, I have compared with design with the needs of the ODE package.
Here are the main differences I see.
In ODE, event detection (i.e. what occurs before firing the event) is almost
the main feature, it is done using the g() function which performs the bridge
between a continuous state and discrete events. I think this could not be
extended to general purpose events, so leaving detection out of the API as you
proposed it is a good idea. We could use this framework and would still need
out own code to adapt to it. Typically, we would keep our g function, and the
ODE solver would use it to fire the event.
In ODE, event detection and handling are grouped in the same object, and
independent of other events. This means that if class cA detects and handles
event eA, class cB which is dedicated to event eB will never be notified for
this. In your design the exact opposite approach is taken: events firing and
handling are decoupled, and classes listening for events will be notified for
all events, not only one. Here again, I think your approach is a good idea, and
it is closer to well known design patterns. We could probably deprecate our
EventHandler interface and replace it by one interface for detection (using the
g function) and another interface for listening.
> General framework for iterative algorithms
> --
>
> Key: MATH-655
> URL: https://issues.apache.org/jira/browse/MATH-655
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Priority: Minor
> Labels: algorithm, events
> Attachments: iterative-algorithm.zip
>
>
> Following the thread [Monitoring iterative
> algorithms|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/%3CCAGRH7HrgcgoBA=jcoKovjiQU=TjpQHnspBkOGNCu7oDdKk=k...@mail.gmail.com%3E],
> here is a first attempt at defining a general enough framework for iterative
> algorithms at large. At the moment, the classes provide support for
> * maximum number of iterations
> * events handling
> ** initialization event (prior to entering the main loop),
> ** iteration event (after completion of one iteration),
> ** termination event (after termination of the main loop).
> These classes do not yet provide support for a stopping criterion.
> Some points worth to note
> * For the time being, the classes are part of the o.a.c.m.linear package.
> * For the time being, {{IterativeAlgorithm.incrementIterationCount()}} throws
> a {{TooManyEvaluationsException}}. If the proposed new feature is integrated
> into CM, then a proper {{TooManyIterationsException}} should be created, from
> which the former could derive.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-657) Division by zero
[
https://issues.apache.org/jira/browse/MATH-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096621#comment-13096621
]
Gilles commented on MATH-657:
-
I've just posted a mail on "dev".
IMO, the main argument is consistency. Also with how reals (i.e. {{double}})
work; IIUC, MATH-164 triggered a change for that same reason.
Arne Plöse is a user and [reported|MATH-620] that the previous behaviour was
not fine for him.
I don't think that this one change can have a discernible performance impact.
It might not be necessary to map all {{Complex}} instances that have an
infinite component to a single object. I pointed it as a convenient
justification for fixing a bug (and for not fixing the other two points
reported by Arne in MATH-620).
> Division by zero
>
>
> Key: MATH-657
> URL: https://issues.apache.org/jira/browse/MATH-657
> Project: Commons Math
> Issue Type: Bug
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Fix For: 3.0
>
>
> In class {{Complex}}, division by zero always returns NaN. I think that it
> should return NaN only when the numerator is also {{ZERO}}, otherwise the
> result should be {{INF}}. See
> [here|http://en.wikipedia.org/wiki/Riemann_sphere#Arithmetic_operations].
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (BEANUTILS-399) MappedMethodReference does not reconstruct method the same way MappedPropertyDescriptor does
[ https://issues.apache.org/jira/browse/BEANUTILS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Sauder updated BEANUTILS-399: Comment: was deleted (was: Tried to also create a unit test for this. However I failed to produce a memory leak with MemoryLeakTestCase with my JVM.) > MappedMethodReference does not reconstruct method the same way > MappedPropertyDescriptor does > > > Key: BEANUTILS-399 > URL: https://issues.apache.org/jira/browse/BEANUTILS-399 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.3 > Environment: OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode) >Reporter: Oliver Sauder >Priority: Critical > Fix For: 1.8.4 > > Attachments: fix-reconstruction-of-lost-method-with-test.patch > > > In case the MappedMethodReference has lost its reference due to garbage > collection the reconstruction only works for methods which have the exact > parameter types. In other cases a RuntimeException is thrown. > However when MappedPropertyDescriptor creates such a MappedMethodReference it > also finds methods which are compatible for given types. > Marking critical as under high load this bug can occur and stop the system > from working as expected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (BEANUTILS-399) MappedMethodReference does not reconstruct method the same way MappedPropertyDescriptor does
[ https://issues.apache.org/jira/browse/BEANUTILS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Sauder updated BEANUTILS-399: Attachment: (was: fix-reconstruction-of-lost-method.patch) > MappedMethodReference does not reconstruct method the same way > MappedPropertyDescriptor does > > > Key: BEANUTILS-399 > URL: https://issues.apache.org/jira/browse/BEANUTILS-399 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.3 > Environment: OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode) >Reporter: Oliver Sauder >Priority: Critical > Fix For: 1.8.4 > > Attachments: fix-reconstruction-of-lost-method-with-test.patch > > > In case the MappedMethodReference has lost its reference due to garbage > collection the reconstruction only works for methods which have the exact > parameter types. In other cases a RuntimeException is thrown. > However when MappedPropertyDescriptor creates such a MappedMethodReference it > also finds methods which are compatible for given types. > Marking critical as under high load this bug can occur and stop the system > from working as expected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (BEANUTILS-399) MappedMethodReference does not reconstruct method the same way MappedPropertyDescriptor does
[ https://issues.apache.org/jira/browse/BEANUTILS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Sauder updated BEANUTILS-399: Attachment: fix-reconstruction-of-lost-method-with-test.patch Adjusted SomeMappedPojo.java so MemoryLeakTestCase.testMappedPropertyDescriptor_MappedMethodReference1 will reproduce this issue. > MappedMethodReference does not reconstruct method the same way > MappedPropertyDescriptor does > > > Key: BEANUTILS-399 > URL: https://issues.apache.org/jira/browse/BEANUTILS-399 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.3 > Environment: OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode) >Reporter: Oliver Sauder >Priority: Critical > Fix For: 1.8.4 > > Attachments: fix-reconstruction-of-lost-method-with-test.patch, > fix-reconstruction-of-lost-method.patch > > > In case the MappedMethodReference has lost its reference due to garbage > collection the reconstruction only works for methods which have the exact > parameter types. In other cases a RuntimeException is thrown. > However when MappedPropertyDescriptor creates such a MappedMethodReference it > also finds methods which are compatible for given types. > Marking critical as under high load this bug can occur and stop the system > from working as expected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
