[jira] [Created] (CONFIGURATION-456) AbstractConfiguration.getKeys(String prefix) docs doesn't say about the point ('.')
AbstractConfiguration.getKeys(String prefix) docs doesn't say about the point
('.')
---
Key: CONFIGURATION-456
URL: https://issues.apache.org/jira/browse/CONFIGURATION-456
Project: Commons Configuration
Issue Type: Bug
Components: Documentation
Affects Versions: 1.6
Reporter: Mirco Andreon
Priority: Trivial
For the method
org.apache.commons.configuration.AbstractConfiguration.getKeys(String prefix)
the documentation doesn't say that to the prefix will be added a point
character ('.') to filter the keys list
(http://commons.apache.org/configuration/apidocs/org/apache/commons/configuration/AbstractConfiguration.html#getKeys%28java.lang.String%29).
I discovered it only reading the source.
Maybe I should have known this behaviour, but I think a lot of occasional users
could face this unpredictable behaviour. Specifying this would be very helpfull.
Many thanks for your wonderful libraries!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-635) High order Brent-like bracketing solver
High order Brent-like bracketing solver --- Key: MATH-635 URL: https://issues.apache.org/jira/browse/MATH-635 Project: Commons Math Issue Type: New Feature Reporter: Luc Maisonobe Assignee: Luc Maisonobe Fix For: 3.0 The new bracketing solvers greatly improve usage. Unfortunately, for now there are only secant-based bracketing solvers available, and a wrapper which basically ends by adding a few secant steps to regular non-bracketing solvers. Changing the Brent solver to provide bracket selection on the final result would depart from the standard algorithm, which is a wrong move (see MATH-599 for a similar case recently resolved). It would be nice to set up another solver in the same spirit as Brent (i.e. using inverse polynomial interpolation when possible and falling back to dichotomy) while retaining bracketing. A nice and simple improvement is also to use higher order inverse polynomial interpolation by retaining several previous points. This allows to build a solver that have an higher order than Newton for example but still only needs function values and no derivatives at all. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-636) create solvers for Dfp based function
create solvers for Dfp based function - Key: MATH-636 URL: https://issues.apache.org/jira/browse/MATH-636 Project: Commons Math Issue Type: New Feature Reporter: Luc Maisonobe Assignee: Luc Maisonobe Fix For: 3.0 When validating some regular computations, we often end up doing some comparison with higher accuracy reference data. The Dfp package is a wonderful tool for that. This package can already be used in some of our regular algorithms as it already implements the Field interface. However, Dfp instances cannot be used in solvers yet. Setting up solvers that would take Field based function is not possible, as solvers do need an absolute value method to check convergence, and an ordering relation for bracketing. However, no such restriction exist for Dfp. It is very easy to convert some existing solvers to have a Dfp version. As the main purpose is high accuracy, and as implementing function for Dfp is cumbersome, a high order method using function values only and no need for implementing derivatives such as depicted in MATH-635 is a good choice. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-199) Http/Https listChildren browse support
[ https://issues.apache.org/jira/browse/VFS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072759#comment-13072759 ] Dmytro Polivenok commented on VFS-199: -- Added patch (trunk version) for parsing html response from http repository containing links to child directories/files using jSoup. Worked well for various http repositories. > Http/Https listChildren browse support > -- > > Key: VFS-199 > URL: https://issues.apache.org/jira/browse/VFS-199 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 1.1 >Reporter: Andrew Franklin > Attachments: HttpGetList.txt, VFS-199.patch > > > I think this was lodged at some time ago as VFS-79: > http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg83701.html. > Essentially the ability to browse http via the directory listing structure is > reasonably important for a number of use cases. > Mario noted in that previous bug that the parsing of the html isn't > necessarily trivial but I've submitted a patch that meets my requirements. > The patch uses java regular expressions which has the requirement of JVM > > 1.4. Submitting in the hope that other users will find it useful and maybe > we'll be able to tidy it to the point where it can be integrated into the vfs > mainline. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-199) Http/Https listChildren browse support
[ https://issues.apache.org/jira/browse/VFS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmytro Polivenok updated VFS-199: - Attachment: HttpGetList.txt > Http/Https listChildren browse support > -- > > Key: VFS-199 > URL: https://issues.apache.org/jira/browse/VFS-199 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 1.1 >Reporter: Andrew Franklin > Attachments: HttpGetList.txt, VFS-199.patch > > > I think this was lodged at some time ago as VFS-79: > http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg83701.html. > Essentially the ability to browse http via the directory listing structure is > reasonably important for a number of use cases. > Mario noted in that previous bug that the parsing of the html isn't > necessarily trivial but I've submitted a patch that meets my requirements. > The patch uses java regular expressions which has the requirement of JVM > > 1.4. Submitting in the hope that other users will find it useful and maybe > we'll be able to tidy it to the point where it can be integrated into the vfs > mainline. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (VFS-199) Http/Https listChildren browse support
[ https://issues.apache.org/jira/browse/VFS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072759#comment-13072759 ] Dmytro Polivenok edited comment on VFS-199 at 7/29/11 9:48 AM: --- Added HttpGetList patch (trunk version) for parsing html response from http repository containing links to child directories/files using jSoup. Worked well for various http repositories. was (Author: polivenok): Added patch (trunk version) for parsing html response from http repository containing links to child directories/files using jSoup. Worked well for various http repositories. > Http/Https listChildren browse support > -- > > Key: VFS-199 > URL: https://issues.apache.org/jira/browse/VFS-199 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 1.1 >Reporter: Andrew Franklin > Attachments: HttpGetList.txt, VFS-199.patch > > > I think this was lodged at some time ago as VFS-79: > http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg83701.html. > Essentially the ability to browse http via the directory listing structure is > reasonably important for a number of use cases. > Mario noted in that previous bug that the parsing of the html isn't > necessarily trivial but I've submitted a patch that meets my requirements. > The patch uses java regular expressions which has the requirement of JVM > > 1.4. Submitting in the hope that other users will find it useful and maybe > we'll be able to tidy it to the point where it can be integrated into the vfs > mainline. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBUTILS-79) fillStatement doesn't complain when there are too few parameters
fillStatement doesn't complain when there are too few parameters Key: DBUTILS-79 URL: https://issues.apache.org/jira/browse/DBUTILS-79 Project: Commons DbUtils Issue Type: Bug Affects Versions: 1.3 Reporter: William R. Speirs Fix For: 1.4 Unless I'm reading the code incorrectly, it appears that the fillStatement function does not complain if you provide too few parameters. For example, if you supply an SQL statement like: select * from blah where ? = ?; but only provide a single parameter "test", fillStatement returns without issue. However, only the first ? is actually set. Granted, this will almost always cause an exception to be thrown by the driver, but since there is already a check for too many parameters, why not check for too few as well? (FYI: I came across this bug, and a few others in my AsyncQueryRunner implementation, while re-writing the unit tests to use Mockito.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-635) High order Brent-like bracketing solver
[ https://issues.apache.org/jira/browse/MATH-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-635. Resolution: Fixed Fixed in subversion repository as of r1152276. > High order Brent-like bracketing solver > --- > > Key: MATH-635 > URL: https://issues.apache.org/jira/browse/MATH-635 > Project: Commons Math > Issue Type: New Feature >Reporter: Luc Maisonobe >Assignee: Luc Maisonobe > Fix For: 3.0 > > > The new bracketing solvers greatly improve usage. Unfortunately, for now > there are only secant-based bracketing solvers available, and a wrapper which > basically ends by adding a few secant steps to regular non-bracketing solvers. > Changing the Brent solver to provide bracket selection on the final result > would depart from the standard algorithm, which is a wrong move (see MATH-599 > for a similar case recently resolved). > It would be nice to set up another solver in the same spirit as Brent (i.e. > using inverse polynomial interpolation when possible and falling back to > dichotomy) while retaining bracketing. A nice and simple improvement is also > to use higher order inverse polynomial interpolation by retaining several > previous points. This allows to build a solver that have an higher order than > Newton for example but still only needs function values and no derivatives at > all. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-636) create solvers for Dfp based function
[ https://issues.apache.org/jira/browse/MATH-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-636. Resolution: Fixed Fixed in subversion repository as of r1152280 > create solvers for Dfp based function > - > > Key: MATH-636 > URL: https://issues.apache.org/jira/browse/MATH-636 > Project: Commons Math > Issue Type: New Feature >Reporter: Luc Maisonobe >Assignee: Luc Maisonobe > Fix For: 3.0 > > > When validating some regular computations, we often end up doing some > comparison with higher accuracy reference data. > The Dfp package is a wonderful tool for that. This package can already be > used in some of our regular algorithms as it already implements the Field > interface. However, Dfp instances cannot be used in solvers yet. > Setting up solvers that would take Field based function is not possible, as > solvers do need an absolute value method to check convergence, and an > ordering relation for bracketing. However, no such restriction exist for Dfp. > It is very easy to convert some existing solvers to have a Dfp version. As > the main purpose is high accuracy, and as implementing function for Dfp is > cumbersome, a high order method using function values only and no need for > implementing derivatives such as depicted in MATH-635 is a good choice. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-452) HierarchicalConfiguration with XPathExpressionEngine does not work when setting a new property
[
https://issues.apache.org/jira/browse/CONFIGURATION-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072989#comment-13072989
]
Oliver Heger commented on CONFIGURATION-452:
A fix was committed in revision 1152343. XPathExpressionEngine can now deal
with keys for adding or setting properties which do not have to contain a
whitespace. It tries to guess the location where to insert the new nodes.
I am not sure whether this fixes all problems or works with all possible keys.
It would be good if you could give it a try. Simple scenarios as in your
example should be supported now; I have added a new unit test class to verify
this.
I still have to update the Javadocs and the documentation accordingly.
> HierarchicalConfiguration with XPathExpressionEngine does not work when
> setting a new property
> --
>
> Key: CONFIGURATION-452
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-452
> Project: Commons Configuration
> Issue Type: Bug
> Components: Expression engine
>Affects Versions: 1.6
> Environment: all
>Reporter: Fabien Nisol
>Assignee: Oliver Heger
>
> The following code does not work as expected
> {code:title=Bug.java|borderStyle=solid}
> public class Bug {
> public static void main(String[] args) {
> try {
> XMLConfiguration config = new XMLConfiguration();
> // works
> config.setProperty("test.property[@attribute]",
> "value");
> config.setExpressionEngine(new XPathExpressionEngine());
> config.save(System.out);
> // works
> config.setProperty("test/property/@attribute", "value");
> // does not work
> config.setProperty("test/property/@attribute2",
> "value");
> } catch (ConfigurationException e) {
> // @FIXME Traitement d'exception par defaut
> throw new RuntimeException(e);
> }
> }
> }
> {code}
> hangs with the following exception:
> Exception in thread "main" java.lang.IllegalArgumentException: prepareAdd:
> Passed in key must contain a whitespace!
> at
> org.apache.commons.configuration.tree.xpath.XPathExpressionEngine.prepareAdd(XPathExpressionEngine.java:223)
> at
> org.apache.commons.configuration.HierarchicalConfiguration.addPropertyDirect(HierarchicalConfiguration.java:371)
> at
> org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.addPropertyDirect(AbstractHierarchicalFileConfiguration.java:140)
> at
> org.apache.commons.configuration.HierarchicalConfiguration.setProperty(HierarchicalConfiguration.java:749)
> at
> org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.setProperty(AbstractHierarchicalFileConfiguration.java:158)
> at Bug.main(Bug.java:29)
> the setProperty() method does not work if the property have to be added. This
> behavior is not really wanted, because in some generic cases, we don't know
> if the property is set or not before trying to set it.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-452) HierarchicalConfiguration with XPathExpressionEngine does not work when setting a new property
[
https://issues.apache.org/jira/browse/CONFIGURATION-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072996#comment-13072996
]
Fabien Nisol commented on CONFIGURATION-452:
Thanks, I will test this revision as soon as I am back working on the project
that needed that :P
> HierarchicalConfiguration with XPathExpressionEngine does not work when
> setting a new property
> --
>
> Key: CONFIGURATION-452
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-452
> Project: Commons Configuration
> Issue Type: Bug
> Components: Expression engine
>Affects Versions: 1.6
> Environment: all
>Reporter: Fabien Nisol
>Assignee: Oliver Heger
>
> The following code does not work as expected
> {code:title=Bug.java|borderStyle=solid}
> public class Bug {
> public static void main(String[] args) {
> try {
> XMLConfiguration config = new XMLConfiguration();
> // works
> config.setProperty("test.property[@attribute]",
> "value");
> config.setExpressionEngine(new XPathExpressionEngine());
> config.save(System.out);
> // works
> config.setProperty("test/property/@attribute", "value");
> // does not work
> config.setProperty("test/property/@attribute2",
> "value");
> } catch (ConfigurationException e) {
> // @FIXME Traitement d'exception par defaut
> throw new RuntimeException(e);
> }
> }
> }
> {code}
> hangs with the following exception:
> Exception in thread "main" java.lang.IllegalArgumentException: prepareAdd:
> Passed in key must contain a whitespace!
> at
> org.apache.commons.configuration.tree.xpath.XPathExpressionEngine.prepareAdd(XPathExpressionEngine.java:223)
> at
> org.apache.commons.configuration.HierarchicalConfiguration.addPropertyDirect(HierarchicalConfiguration.java:371)
> at
> org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.addPropertyDirect(AbstractHierarchicalFileConfiguration.java:140)
> at
> org.apache.commons.configuration.HierarchicalConfiguration.setProperty(HierarchicalConfiguration.java:749)
> at
> org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.setProperty(AbstractHierarchicalFileConfiguration.java:158)
> at Bug.main(Bug.java:29)
> the setProperty() method does not work if the property have to be added. This
> behavior is not really wanted, because in some generic cases, we don't know
> if the property is set or not before trying to set it.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-637) Simple utility for micro-benchmarking
Simple utility for micro-benchmarking - Key: MATH-637 URL: https://issues.apache.org/jira/browse/MATH-637 Project: Commons Math Issue Type: Wish Reporter: Gilles Assignee: Gilles Priority: Minor Fix For: 3.0 As per the discussion on the "dev" ML (with subject: "Simple benchmarking utility"), it would be useful to have an easy way to benchmark alternative implementations of some functionality. The proposed utility methods will be collected in a class located in the "src/test/java" part of the code repository. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-637) Simple utility for micro-benchmarking
[ https://issues.apache.org/jira/browse/MATH-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073034#comment-13073034 ] Gilles commented on MATH-637: - Initial code committed in revision 1152380. > Simple utility for micro-benchmarking > - > > Key: MATH-637 > URL: https://issues.apache.org/jira/browse/MATH-637 > Project: Commons Math > Issue Type: Wish >Reporter: Gilles >Assignee: Gilles >Priority: Minor > Labels: test > Fix For: 3.0 > > > As per the discussion on the "dev" ML (with subject: "Simple benchmarking > utility"), it would be useful to have an easy way to benchmark alternative > implementations of some functionality. > The proposed utility methods will be collected in a class located in the > "src/test/java" part of the code repository. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COMPRESS-151) ZipArchiveOutputStream sets general purpose bit 3 even for stored entries without a data descriptor
ZipArchiveOutputStream sets general purpose bit 3 even for stored entries without a data descriptor --- Key: COMPRESS-151 URL: https://issues.apache.org/jira/browse/COMPRESS-151 Project: Commons Compress Issue Type: Bug Affects Versions: 1.2 Reporter: Stefan Bodewig Assignee: Stefan Bodewig Priority: Minor Fix For: 1.3 I found this while testing ZIP64 support at the byte level. General purpose bit 3 is set if the size is stored inside a data descriptor which ZipArchiveOutputStream will only do if it writes DEFLATED entries to a non-seekable stream. Still that bit seems to be always set. It doesn't seem to cause interop problems, that's why I lowered its priority. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COMPRESS-151) ZipArchiveOutputStream sets general purpose bit 3 even for stored entries without a data descriptor
[ https://issues.apache.org/jira/browse/COMPRESS-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved COMPRESS-151. - Resolution: Invalid I got confused and looked at the wrong byte. The bit set is bit 11, the EFS flag and it is absolutely valid to set that. Will adjust my tests accordingly. > ZipArchiveOutputStream sets general purpose bit 3 even for stored entries > without a data descriptor > --- > > Key: COMPRESS-151 > URL: https://issues.apache.org/jira/browse/COMPRESS-151 > Project: Commons Compress > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Stefan Bodewig >Assignee: Stefan Bodewig >Priority: Minor > Fix For: 1.3 > > > I found this while testing ZIP64 support at the byte level. > General purpose bit 3 is set if the size is stored inside a data descriptor > which ZipArchiveOutputStream will only do if it writes DEFLATED entries to a > non-seekable stream. Still that bit seems to be always set. > It doesn't seem to cause interop problems, that's why I lowered its priority. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
