[jira] [Updated] (LANG-1000) ParseException when trying to parse UTC dates with Z as zone designator using DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT
[
https://issues.apache.org/jira/browse/LANG-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-1000:
--
Fix Version/s: Patch Needed
ParseException when trying to parse UTC dates with Z as zone designator using
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT
---
Key: LANG-1000
URL: https://issues.apache.org/jira/browse/LANG-1000
Project: Commons Lang
Issue Type: Bug
Affects Versions: 3.3.2
Reporter: Holger Stenzhorn
Priority: Minor
Fix For: Patch Needed
I have the {{String}} {{2013-11-18T12:48:05Z}} which I want to parse into a
{{Date}} using {{DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT}}.
According to [http://en.wikipedia.org/wiki/ISO_8601#UTC] the {{Z}} at the end
should be a valid abbreviation for {{UTC+00:00}} (or {{UTC}}) and so all
should be fine.
But when I am trying to do so I get the following exception:
{code}
java.text.ParseException: Unparseable date: 2013-11-18T12:48:05Z does not
match
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (LANG-1003) DurationFormatUtils are not able to handle negative durations/periods
[
https://issues.apache.org/jira/browse/LANG-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987488#comment-13987488
]
Benedikt Ritter commented on LANG-1003:
---
Makes sense to me.
DurationFormatUtils are not able to handle negative durations/periods
-
Key: LANG-1003
URL: https://issues.apache.org/jira/browse/LANG-1003
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 3.3.2
Reporter: Michael Osipov
Priority: Critical
Fix For: Patch Needed
It spits out complete garbage.
{code}
System.out.println(DurationFormatUtils.formatDurationHMS(-3454));
System.out.println(DurationFormatUtils.formatPeriodISO(4000, 3000));
{code}
{noformat}
0:00:-3.-454
P-1Y11M30DT23H59M59.000S
{noformat}
I should throw an {{IllegalArgumentException}} if duration is 0 or period
diff is 0.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (LANG-1003) DurationFormatUtils are not able to handle negative durations/periods
[
https://issues.apache.org/jira/browse/LANG-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-1003:
--
Fix Version/s: Patch Needed
DurationFormatUtils are not able to handle negative durations/periods
-
Key: LANG-1003
URL: https://issues.apache.org/jira/browse/LANG-1003
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 3.3.2
Reporter: Michael Osipov
Priority: Critical
Fix For: Patch Needed
It spits out complete garbage.
{code}
System.out.println(DurationFormatUtils.formatDurationHMS(-3454));
System.out.println(DurationFormatUtils.formatPeriodISO(4000, 3000));
{code}
{noformat}
0:00:-3.-454
P-1Y11M30DT23H59M59.000S
{noformat}
I should throw an {{IllegalArgumentException}} if duration is 0 or period
diff is 0.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (LANG-1004) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa
[ https://issues.apache.org/jira/browse/LANG-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated LANG-1004: -- Fix Version/s: Patch Needed DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa -- Key: LANG-1004 URL: https://issues.apache.org/jira/browse/LANG-1004 Project: Commons Lang Issue Type: Bug Components: lang.text.* Affects Versions: 3.3.2 Reporter: Michael Osipov Fix For: Patch Needed This method has several flaws: 1. Javadoc says: The format used is ISO8601-like: H:m:s.S. but the method call supplies H:mm:ss.SSS 2. ISO time never omits leading zeros, so the proper pattern must be HH:mm:ss.SSS 3. The method name says: HMS but omits the second fraction. Since the use of fractions is optional, the method should use HH:mm:ss and update the Javadoc as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (COLLECTIONS-519) private constructors in utility classes break existing code
[ https://issues.apache.org/jira/browse/COLLECTIONS-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved COLLECTIONS-519. - Resolution: Won't Fix Fix Version/s: (was: 4.1) Reverted commit after veto in r1591832. private constructors in utility classes break existing code --- Key: COLLECTIONS-519 URL: https://issues.apache.org/jira/browse/COLLECTIONS-519 Project: Commons Collections Issue Type: Bug Affects Versions: 4.x Reporter: Radoslav Paskalev Hello, In collections version 4.x all utility classes (example ListUtils, MapUtils, PredicateUtils) have private constructors. I consider this to be a serious bug, as it breaks any possibility the classes to be extended by the users. The javadoc says that constructors are private in order to prevent class instantiation but this object instantiation is not really problem and i think it is more important to allow classes to be extended. The possibility to extend utility classes was one of the major selling points of commons.lang and commons.collections projects. In the latest commons.lang project the utility classes still have public constructors. Best Regards -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (COLLECTIONS-519) private constructors in utility classes break existing code
[ https://issues.apache.org/jira/browse/COLLECTIONS-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart reopened COLLECTIONS-519: - private constructors in utility classes break existing code --- Key: COLLECTIONS-519 URL: https://issues.apache.org/jira/browse/COLLECTIONS-519 Project: Commons Collections Issue Type: Bug Affects Versions: 4.x Reporter: Radoslav Paskalev Hello, In collections version 4.x all utility classes (example ListUtils, MapUtils, PredicateUtils) have private constructors. I consider this to be a serious bug, as it breaks any possibility the classes to be extended by the users. The javadoc says that constructors are private in order to prevent class instantiation but this object instantiation is not really problem and i think it is more important to allow classes to be extended. The possibility to extend utility classes was one of the major selling points of commons.lang and commons.collections projects. In the latest commons.lang project the utility classes still have public constructors. Best Regards -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-751) Standard algorithms in computational geometry
[ https://issues.apache.org/jira/browse/MATH-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-751. -- Resolution: Won't Fix Standard algorithms in computational geometry - Key: MATH-751 URL: https://issues.apache.org/jira/browse/MATH-751 Project: Commons Math Issue Type: New Feature Reporter: Thomas Neidhart Priority: Minor Labels: geometric Fix For: 4.0 CM is currently lacking support for several standard algorithms in computational geometry like triangulation, voronoi diagrams,... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-1081) Support writing a linear problem to a commonly used format, e.g. MPS
[ https://issues.apache.org/jira/browse/MATH-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-1081. --- Resolution: Won't Fix Support writing a linear problem to a commonly used format, e.g. MPS Key: MATH-1081 URL: https://issues.apache.org/jira/browse/MATH-1081 Project: Commons Math Issue Type: New Feature Reporter: Thomas Neidhart This would allow users to more easily create test reports by saving their problem and attaching it to an issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-750) Voronoi diagram algorithm
[ https://issues.apache.org/jira/browse/MATH-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-750. -- Resolution: Won't Fix Voronoi diagram algorithm - Key: MATH-750 URL: https://issues.apache.org/jira/browse/MATH-750 Project: Commons Math Issue Type: Sub-task Reporter: Thomas Neidhart Priority: Minor Labels: 2d, geometric It would be nice to have an implementation of Voronoi diagrams in CM see [http://en.wikipedia.org/wiki/Voronoi_diagram]. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-1076) Add a MPS file parser to improve testing of the SimplexSolver
[ https://issues.apache.org/jira/browse/MATH-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-1076. --- Resolution: Won't Fix Add a MPS file parser to improve testing of the SimplexSolver - Key: MATH-1076 URL: https://issues.apache.org/jira/browse/MATH-1076 Project: Commons Math Issue Type: Improvement Reporter: Thomas Neidhart Attachments: MATH-1076.patch There are lots of test problems for linear programming in the MPS format. We should add a parser for this format to test our SimplexSolver implementation with these problems and compare with other solvers. The parser could be added also to the -tools jar as it might be of interest for users to load and execute such problems. Format: http://lpsolve.sourceforge.net/5.5/mps-format.htm Data Files: http://www.netlib.org/lp/data/ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-982) Improvements to the User Guide
[ https://issues.apache.org/jira/browse/MATH-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-982. -- Resolution: Won't Fix Improvements to the User Guide -- Key: MATH-982 URL: https://issues.apache.org/jira/browse/MATH-982 Project: Commons Math Issue Type: Improvement Reporter: Thomas Neidhart -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-752) Triangulation algorithm
[ https://issues.apache.org/jira/browse/MATH-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-752. -- Resolution: Won't Fix Triangulation algorithm --- Key: MATH-752 URL: https://issues.apache.org/jira/browse/MATH-752 Project: Commons Math Issue Type: Sub-task Reporter: Thomas Neidhart Priority: Minor Labels: 2d, 3d, geometric, spherical The geometric package is currently lacking an algorithm for [Delaunay Triangulation|http://en.wikipedia.org/wiki/Delaunay_triangulation]. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-1071) Improve genetic algorithms section of user guide
[ https://issues.apache.org/jira/browse/MATH-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-1071. --- Resolution: Won't Fix Improve genetic algorithms section of user guide Key: MATH-1071 URL: https://issues.apache.org/jira/browse/MATH-1071 Project: Commons Math Issue Type: Sub-task Reporter: Thomas Neidhart Assignee: Thomas Neidhart -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-944) Consider making a generic version of class Frequency
[ https://issues.apache.org/jira/browse/MATH-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-944. -- Resolution: Won't Fix Consider making a generic version of class Frequency Key: MATH-944 URL: https://issues.apache.org/jira/browse/MATH-944 Project: Commons Math Issue Type: Improvement Affects Versions: 3.1 Reporter: Thomas Neidhart Priority: Minor Fix For: 4.0 Attachments: Frequency.java The current version of the Frequency class is quite complex, as it has to handle different input values and does a lot of casting. The class is also not very safe in the sense that adding different data types will lead to runtime exceptions. The class could be simplified by introducing a generic version. The only downside so far is that the current version treats ints and longs together, which would not be possible with a generic version. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-1064) Improve optimization section of user guide
[ https://issues.apache.org/jira/browse/MATH-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-1064. --- Resolution: Won't Fix Improve optimization section of user guide -- Key: MATH-1064 URL: https://issues.apache.org/jira/browse/MATH-1064 Project: Commons Math Issue Type: Sub-task Reporter: Thomas Neidhart Add more description how to use the different optimizers with their mandatory and optional parameters. Add some (simple) examples. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-959) Add HAC clustering algorithm
[ https://issues.apache.org/jira/browse/MATH-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-959. -- Resolution: Won't Fix Add HAC clustering algorithm Key: MATH-959 URL: https://issues.apache.org/jira/browse/MATH-959 Project: Commons Math Issue Type: Sub-task Reporter: Thomas Neidhart Assignee: Thomas Neidhart Fix For: 4.0 Attachments: MATH-748.zip Add at least one hierarchical clustering algorithm. With the refactoring of the clustering package, this should now be feasible as the Cluster class can be extended. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-1078) Support DEVEX pivot selection rule for SimplexSolver
[ https://issues.apache.org/jira/browse/MATH-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-1078. --- Resolution: Won't Fix Support DEVEX pivot selection rule for SimplexSolver Key: MATH-1078 URL: https://issues.apache.org/jira/browse/MATH-1078 Project: Commons Math Issue Type: Improvement Reporter: Thomas Neidhart Description of various pivot selection rules: http://cs.nyu.edu/courses/fall12/CSCI-GA.2945-002/pastproject2.pdf -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-1061) Improve filter section of user guide
[ https://issues.apache.org/jira/browse/MATH-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-1061. --- Resolution: Won't Fix Improve filter section of user guide Key: MATH-1061 URL: https://issues.apache.org/jira/browse/MATH-1061 Project: Commons Math Issue Type: Sub-task Reporter: Thomas Neidhart Assignee: Thomas Neidhart Improve the filter section with better explanation and graphical output illustrating the filter mechanism. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MATH-463) Monte Carlo engine with 1D path
[ https://issues.apache.org/jira/browse/MATH-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated MATH-463: - Assignee: (was: Thomas Neidhart) Monte Carlo engine with 1D path --- Key: MATH-463 URL: https://issues.apache.org/jira/browse/MATH-463 Project: Commons Math Issue Type: New Feature Reporter: Pavel Ryzhov Fix For: 4.0 Attachments: mc1.patch Quite simple Monte-Carlo engine: 1. Generates N samples (paths) of Ito process with given drift and diffusion. It uses simple Euler discretization on equally spaced time scale. 2. For each path evaluate some path function and provide this value to SummaryStatistics. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (COLLECTIONS-440) Consider including heap implementations from java-heaps project
[ https://issues.apache.org/jira/browse/COLLECTIONS-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved COLLECTIONS-440. - Resolution: Won't Fix Consider including heap implementations from java-heaps project --- Key: COLLECTIONS-440 URL: https://issues.apache.org/jira/browse/COLLECTIONS-440 Project: Commons Collections Issue Type: New Feature Reporter: Thomas Neidhart Fix For: 4.x http://code.google.com/p/java-heaps/ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (COLLECTIONS-431) Add useful collections from commons-graph
[ https://issues.apache.org/jira/browse/COLLECTIONS-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved COLLECTIONS-431. - Resolution: Won't Fix Add useful collections from commons-graph - Key: COLLECTIONS-431 URL: https://issues.apache.org/jira/browse/COLLECTIONS-431 Project: Commons Collections Issue Type: Improvement Affects Versions: 4.0 Reporter: Thomas Neidhart Fix For: 4.x Attachments: COLLECTIONS-431.patch Commons-graph has support for DisjointSet and FibonacciHeap which could be of interest also for CC. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (COLLECTIONS-465) Add more static helper functions to IteratorUtils CollectionUtils
[ https://issues.apache.org/jira/browse/COLLECTIONS-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved COLLECTIONS-465. - Resolution: Won't Fix Add more static helper functions to IteratorUtils CollectionUtils --- Key: COLLECTIONS-465 URL: https://issues.apache.org/jira/browse/COLLECTIONS-465 Project: Commons Collections Issue Type: Sub-task Components: Iterator Reporter: Thomas Neidhart Fix For: 4.x The Iter class from the jena projects contains a lot of convenience methods for iterators. We should implement the same in our IteratorUtils class. Also consider several methods in class Iterators from guava project. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (LANG-1003) DurationFormatUtils are not able to handle negative durations/periods
[
https://issues.apache.org/jira/browse/LANG-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987532#comment-13987532
]
Benedikt Ritter commented on LANG-1003:
---
Thanks for the report!
{code}
bene@localhost:~/workspace/apache/commons/lang$ svn ci -m LANG-1003:
DurationFormatUtils are not able to handle negative durations/periods. Reported
by Michael Osipov.
Sendingsrc/changes/changes.xml
Sending
src/main/java/org/apache/commons/lang3/time/DurationFormatUtils.java
Sending
src/test/java/org/apache/commons/lang3/time/DurationFormatUtilsTest.java
Transmitting file data ...
Committed revision 1591840.
{code}
DurationFormatUtils are not able to handle negative durations/periods
-
Key: LANG-1003
URL: https://issues.apache.org/jira/browse/LANG-1003
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 3.3.2
Reporter: Michael Osipov
Assignee: Benedikt Ritter
Priority: Critical
Fix For: 3.4
It spits out complete garbage.
{code}
System.out.println(DurationFormatUtils.formatDurationHMS(-3454));
System.out.println(DurationFormatUtils.formatPeriodISO(4000, 3000));
{code}
{noformat}
0:00:-3.-454
P-1Y11M30DT23H59M59.000S
{noformat}
I should throw an {{IllegalArgumentException}} if duration is 0 or period
diff is 0.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (LANG-1003) DurationFormatUtils are not able to handle negative durations/periods
[
https://issues.apache.org/jira/browse/LANG-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter resolved LANG-1003.
---
Resolution: Fixed
Fix Version/s: (was: Patch Needed)
3.4
DurationFormatUtils are not able to handle negative durations/periods
-
Key: LANG-1003
URL: https://issues.apache.org/jira/browse/LANG-1003
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 3.3.2
Reporter: Michael Osipov
Assignee: Benedikt Ritter
Priority: Critical
Fix For: 3.4
It spits out complete garbage.
{code}
System.out.println(DurationFormatUtils.formatDurationHMS(-3454));
System.out.println(DurationFormatUtils.formatPeriodISO(4000, 3000));
{code}
{noformat}
0:00:-3.-454
P-1Y11M30DT23H59M59.000S
{noformat}
I should throw an {{IllegalArgumentException}} if duration is 0 or period
diff is 0.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (LANG-1003) DurationFormatUtils are not able to handle negative durations/periods
[
https://issues.apache.org/jira/browse/LANG-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated LANG-1003:
-
Description:
It spits out complete garbage.
{code}
System.out.println(DurationFormatUtils.formatDurationHMS(-3454));
System.out.println(DurationFormatUtils.formatPeriodISO(4000, 3000));
{code}
{noformat}
0:00:-3.-454
P-1Y11M30DT23H59M59.000S
{noformat}
It should throw an {{IllegalArgumentException}} if duration is 0 or period
diff is 0.
was:
It spits out complete garbage.
{code}
System.out.println(DurationFormatUtils.formatDurationHMS(-3454));
System.out.println(DurationFormatUtils.formatPeriodISO(4000, 3000));
{code}
{noformat}
0:00:-3.-454
P-1Y11M30DT23H59M59.000S
{noformat}
I should throw an {{IllegalArgumentException}} if duration is 0 or period
diff is 0.
DurationFormatUtils are not able to handle negative durations/periods
-
Key: LANG-1003
URL: https://issues.apache.org/jira/browse/LANG-1003
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 3.3.2
Reporter: Michael Osipov
Assignee: Benedikt Ritter
Priority: Critical
Fix For: 3.4
It spits out complete garbage.
{code}
System.out.println(DurationFormatUtils.formatDurationHMS(-3454));
System.out.println(DurationFormatUtils.formatPeriodISO(4000, 3000));
{code}
{noformat}
0:00:-3.-454
P-1Y11M30DT23H59M59.000S
{noformat}
It should throw an {{IllegalArgumentException}} if duration is 0 or period
diff is 0.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SANDBOX-473) Exception raised during Transformation
[ https://issues.apache.org/jira/browse/SANDBOX-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987557#comment-13987557 ] Benedikt Ritter commented on SANDBOX-473: - NIce patch. I currently don't know where we are going with the Transformer interface. I'll apply the patch for now, but could be that the Transformer will be dropped all togehter. :) Exception raised during Transformation -- Key: SANDBOX-473 URL: https://issues.apache.org/jira/browse/SANDBOX-473 Project: Commons Sandbox Issue Type: Task Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Yogesh Rao Fix For: Nightly Builds Attachments: TransformationException.java.txt, Transformer.java.txt The convert method within the Transformer interface does not throw a exception. How about creating an exception which would be thrown by the convert method when encountered with an issue? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SANDBOX-473) Exception raised during Transformation
[ https://issues.apache.org/jira/browse/SANDBOX-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987560#comment-13987560 ] Benedikt Ritter commented on SANDBOX-473: - Hello Yogesh, your patch needs some tiddy up before I can apply it :-) * please intend your code using only spaces and not tabs. * please make sure new files have the Apache License Header Regards, Benedikt Exception raised during Transformation -- Key: SANDBOX-473 URL: https://issues.apache.org/jira/browse/SANDBOX-473 Project: Commons Sandbox Issue Type: Task Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Yogesh Rao Fix For: Nightly Builds Attachments: TransformationException.java.txt, Transformer.java.txt The convert method within the Transformer interface does not throw a exception. How about creating an exception which would be thrown by the convert method when encountered with an issue? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SANDBOX-362) Create basic unit tests for all classes
[ https://issues.apache.org/jira/browse/SANDBOX-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter resolved SANDBOX-362. - Resolution: Fixed All subtasks have been resolved. Create basic unit tests for all classes --- Key: SANDBOX-362 URL: https://issues.apache.org/jira/browse/SANDBOX-362 Project: Commons Sandbox Issue Type: Test Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Benedikt Ritter Assignee: Simone Tripodi Attachments: ArgumentTest.zip, SANDBOX-362-BeanUtilsTest.txt, SANDBOX-362-ConstructorTestCase.txt, SANDBOX-362-RefactoringOfArgumentTest.txt, SANDBOX-362-RefactoringOfAssertionsTest.txt, SANDBOX-362-TypeUtilsTest.txt Back up all existing implementations with unit tests: * Argument * Assertions * BeanUtils * DefaultBeanAccessor * DefaultClassAccessor * MethodRegistry * TypeUtils -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SANDBOX-472) Transformer Registry
[ https://issues.apache.org/jira/browse/SANDBOX-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987565#comment-13987565 ] Benedikt Ritter commented on SANDBOX-472: - Hello Yogesh, we will need this functionality in order to make BU2 a substitute for BeanUtils 1. Currently I'm only having a vague plan on how to implement this. One thing I know for sure is, that I don't want to have static methods that configure how BeanUtils work. In BeanUtils1 you can register new Converters using static methods. At the moment I'm thinking about something like this: The BeanUtils class will serve like some kind of factory for BeanUtils instances. It provides a preconfigured BeanUtils instance which has the standard Converts registered. If users need a custom instance they can use a builder kind of API to create a new instance, which they can pass around and do stuff with. The standard instance that is registered on the factory can not be changed to preserve behavior. So implementing the registry is the second step. First we need to decide how the API for customizing BeanUtils instances will look like. Transformer Registry Key: SANDBOX-472 URL: https://issues.apache.org/jira/browse/SANDBOX-472 Project: Commons Sandbox Issue Type: Task Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Yogesh Rao Fix For: Nightly Builds Hi, This is my first development JIRA for BU2 so apologies in case i m missing out on basics. Beanutils1 has a functionality wherein all the converters are registered and are called when conversion in value is required. This functionality is missing for BU2 project. I also saw that BeanUtils1 uses WeakFastHashMap for this, which seems like is having issues across architectures and did see few JIRA's on this. Wanted inputs if having a synchronized instance of WeakHashMap wrapped in the TransformerRegsitry class and providing methods to register, deregister, restoreDefault, lookup be desired? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SANDBOX-462) Refactoring of AccessibleObjectsRegistry
[ https://issues.apache.org/jira/browse/SANDBOX-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987566#comment-13987566 ] Benedikt Ritter commented on SANDBOX-462: - Any news here? Do you want to provide a second patch? ;-) Refactoring of AccessibleObjectsRegistry Key: SANDBOX-462 URL: https://issues.apache.org/jira/browse/SANDBOX-462 Project: Commons Sandbox Issue Type: Improvement Components: BeanUtils2 Reporter: Andre Diermann Priority: Minor Attachments: Commons-BeanUtils2-462#1.patch Summary: The AccessibleObjectsRegistry class provides two get methods, while one is a convenient method for the other. Both methods take one conditional parameter, boolean exact, and the actual get method is very long, which makes it somehow complex to understand. Suggestion: What could be improved IMHO: - Instead of using conditional methods, like get(boolean doSomethingSpecialIfTrue, ...), it is more convenient to provide dedicated methods like getSomething() and getAnotherThing(). - In this regard the difference between an exact or, let's call it, matching descriptor should be expressed through inheritance rather than object allocation (= expressing it by a field boolean exact). - The very long get method should be refined - Another very minor issue is the naming of the paramTypes field within the inner AccessibleObjectDescriptor class, which I would suggest to rename to parameterTypes to fit the naming of the other occurrences. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SANDBOX-462) Refactoring of AccessibleObjectsRegistry
[ https://issues.apache.org/jira/browse/SANDBOX-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987571#comment-13987571 ] Andre Diermann commented on SANDBOX-462: Sure, waiting for your response on my questions two comments before :-) Refactoring of AccessibleObjectsRegistry Key: SANDBOX-462 URL: https://issues.apache.org/jira/browse/SANDBOX-462 Project: Commons Sandbox Issue Type: Improvement Components: BeanUtils2 Reporter: Andre Diermann Priority: Minor Attachments: Commons-BeanUtils2-462#1.patch Summary: The AccessibleObjectsRegistry class provides two get methods, while one is a convenient method for the other. Both methods take one conditional parameter, boolean exact, and the actual get method is very long, which makes it somehow complex to understand. Suggestion: What could be improved IMHO: - Instead of using conditional methods, like get(boolean doSomethingSpecialIfTrue, ...), it is more convenient to provide dedicated methods like getSomething() and getAnotherThing(). - In this regard the difference between an exact or, let's call it, matching descriptor should be expressed through inheritance rather than object allocation (= expressing it by a field boolean exact). - The very long get method should be refined - Another very minor issue is the naming of the paramTypes field within the inner AccessibleObjectDescriptor class, which I would suggest to rename to parameterTypes to fit the naming of the other occurrences. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (LANG-1004) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa
[ https://issues.apache.org/jira/browse/LANG-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated LANG-1004: - Description: This method has several flaws: 1. Javadoc says: The format used is ISO8601-like: H:m:s.S. but the method call supplies H:mm:ss.SSS 2. ISO time never omits leading zeros, so the proper pattern must be HH:mm:ss.SSS 3. The method name says: HMS but includes the second fraction. Since the use of fractions is optional, the method should use HH:mm:ss and update the Javadoc as well. was: This method has several flaws: 1. Javadoc says: The format used is ISO8601-like: H:m:s.S. but the method call supplies H:mm:ss.SSS 2. ISO time never omits leading zeros, so the proper pattern must be HH:mm:ss.SSS 3. The method name says: HMS but omits the second fraction. Since the use of fractions is optional, the method should use HH:mm:ss and update the Javadoc as well. DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa -- Key: LANG-1004 URL: https://issues.apache.org/jira/browse/LANG-1004 Project: Commons Lang Issue Type: Bug Components: lang.text.* Affects Versions: 3.3.2 Reporter: Michael Osipov Fix For: Patch Needed This method has several flaws: 1. Javadoc says: The format used is ISO8601-like: H:m:s.S. but the method call supplies H:mm:ss.SSS 2. ISO time never omits leading zeros, so the proper pattern must be HH:mm:ss.SSS 3. The method name says: HMS but includes the second fraction. Since the use of fractions is optional, the method should use HH:mm:ss and update the Javadoc as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (LANG-1004) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa
[ https://issues.apache.org/jira/browse/LANG-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated LANG-1004: - Attachment: LANG-1004.patch Benedikt. have a look at the patch. DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa -- Key: LANG-1004 URL: https://issues.apache.org/jira/browse/LANG-1004 Project: Commons Lang Issue Type: Bug Components: lang.text.* Affects Versions: 3.3.2 Reporter: Michael Osipov Fix For: Patch Needed Attachments: LANG-1004.patch This method has several flaws: 1. Javadoc says: The format used is ISO8601-like: H:m:s.S. but the method call supplies H:mm:ss.SSS 2. ISO time never omits leading zeros, so the proper pattern must be HH:mm:ss.SSS 3. The method name says: HMS but includes the second fraction. Since the use of fractions is optional, the method should use HH:mm:ss and update the Javadoc as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (VFS-129) SFTP: proxy support with Username / Password
[ https://issues.apache.org/jira/browse/VFS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987666#comment-13987666 ] George Toma commented on VFS-129: - Hi, I'm using Apache Commons VFS library, and If possible, can someone post when this functionality will be available ? Possible on 2.1 release ( As Rob mentioned, SftpFileSystemConfigBuilder.getInstance().setProxyUserAuthenticator method is not available on 2.0 API, but on 2.1 snapshot there is : setProxyUser(FileSystemOptions opts, String proxyUser) method, which is not compatible with the authentication requirements, username password )? Regards, George SFTP: proxy support with Username / Password Key: VFS-129 URL: https://issues.apache.org/jira/browse/VFS-129 Project: Commons VFS Issue Type: Improvement Environment: All Reporter: Graham Cruickshanks Priority: Minor Fix For: 2.0 Attachments: SftpClientFactory.java, SftpFileSystemConfigBuilder.java SFTP proxy implementation does not have authenticator support, so can't tunnel through HTTP proxy via HTTPS port (443). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (VFS-167) [FTP] Proxy Support (similiar to VFS-84 for SFTP)
[ https://issues.apache.org/jira/browse/VFS-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987669#comment-13987669 ] George Toma commented on VFS-167: - Hi Bernd, Could you please also create the mechanism of HTTP and SOCKS5 proxy authentication for this functionality ( @see VFS-129 ticket), or should be raised another JIRA ticket for this requirement ? Regards, George [FTP] Proxy Support (similiar to VFS-84 for SFTP) - Key: VFS-167 URL: https://issues.apache.org/jira/browse/VFS-167 Project: Commons VFS Issue Type: Improvement Affects Versions: Nightly Builds Environment: Window 2000 and java Reporter: vikas Assignee: Bernd Eckenfels Priority: Minor Fix For: 2.1 I am given proxy support for SFTP by using bug 84 code. What is the way to give proxy support in FTP? Please help asap if possible then we me the way? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (VFS-473) org.apache.commons.vfs2.provider.smb.SmbFileProvider not available in version 2.x
[ https://issues.apache.org/jira/browse/VFS-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987700#comment-13987700 ] Gary Gregory commented on VFS-473: -- Not a bug, not a blocker, nice to have, release early, release often ;) org.apache.commons.vfs2.provider.smb.SmbFileProvider not available in version 2.x - Key: VFS-473 URL: https://issues.apache.org/jira/browse/VFS-473 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Environment: Windows 7 Professional 64 bit, Java 1.6 Reporter: Ranajyoti Chakraborti org.apache.commons.vfs2.provider.smb.SmbFileProvider not available in version 2.x. This appears in version 21.x documentation but the class and package got left out from the jar file. The last it was available was version 20050307052300. Has this support removed on purpose? If not can you please release a version with this class as soon as you can. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (VFS-428) DavException: (301) Moved Permanently
[
https://issues.apache.org/jira/browse/VFS-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987704#comment-13987704
]
Gary Gregory commented on VFS-428:
--
Fine with me, RERO.
DavException: (301) Moved Permanently
--
Key: VFS-428
URL: https://issues.apache.org/jira/browse/VFS-428
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0, 2.1
Environment: Apache 2.2.22 as Testerver and setted up like
http://commons.apache.org/vfs/testserver.html (but changed the 'crypt'
password)
Reporter: Robert Kornmesser
Priority: Blocker
Labels: webdav
Running the WebdavProviderTestCase using mvn -P webdav clean test
-Dtest.webdav.uri=webdav://vfsusr:vfstest@localhost/vfstest
-Dtest=WebdavProviderTestCase results in
{code}DavException: (301) Moved Permanently
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.645 sec
FAILURE!
Results :
Tests in error:
junit.framework.TestSuite@55c9be00(org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1):
Could not determine the type of file
webdav://vfsusr:@localhost/vfstest/read-tests.
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
{code}
The deeper Problem is, that the HttpClient using by VFS does not append a
trailing slash and mod_dir of httpd has DirectorySlash On per default. So
httpd send 301 redirect to the same url with / appended.
I know that for this reason of problematic webdav client apache introduced
redirect-carefully for some user agents using the BrowserMatch directive.
So I just tried adding the following into my Directory directive
{code}
BrowserMatch ^Jakarta-Commons-VFS redirect-carefully
BrowserMatch ^Jakarta Commons-HttpClient/3.0 redirect-carefully
BrowserMatch ^Jakarta Commons-HttpClient/3.1 redirect-carefully
{code}
Its needed to have Jakarta-Commons-VFS *and* Jakarta Commons-HttpClient
because of two requests from commons vfs using two different user agents.
But instead of solving the issue, I get for every FileObject.getChildren()
call at least one FileObject of type imaginary with the same basename as the
parent. Thats not a problem at all (besides that this is totally wrong!) but
deleting a parent just dont work anymore, because of an *non-existent*
imaginary file inside the dir which cannot be deleted of course.
To cut a long story short, what is the right httpd webdav server config to
use 2.0 Release version of VFS?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (VFS-167) [FTP] Proxy Support (similiar to VFS-84 for SFTP)
[ https://issues.apache.org/jira/browse/VFS-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987716#comment-13987716 ] George Toma commented on VFS-167: - Hi Bernd, Shouldn't the FTP proxy functionality be consistent with the SFTP proxy functionality ( SftpFileSystemConfigBuilder.PROXY_SOCKS5, the only SOCKS protocol supported is 5, and on FTP we can select 4 5 ) ? Regards, George [FTP] Proxy Support (similiar to VFS-84 for SFTP) - Key: VFS-167 URL: https://issues.apache.org/jira/browse/VFS-167 Project: Commons VFS Issue Type: Improvement Affects Versions: Nightly Builds Environment: Window 2000 and java Reporter: vikas Assignee: Bernd Eckenfels Priority: Minor Fix For: 2.1 I am given proxy support for SFTP by using bug 84 code. What is the way to give proxy support in FTP? Please help asap if possible then we me the way? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (IO-442) Javadoc contradictory for FileFilterUtils.ageFileFilter(cutoff) and the filter it constructs: AgeFileFilter(cutoff)
Simon Robinson created IO-442:
-
Summary: Javadoc contradictory for
FileFilterUtils.ageFileFilter(cutoff) and the filter it constructs:
AgeFileFilter(cutoff)
Key: IO-442
URL: https://issues.apache.org/jira/browse/IO-442
Project: Commons IO
Issue Type: Bug
Components: Filters
Affects Versions: 2.4
Reporter: Simon Robinson
Priority: Trivial
Documentation states that it returns true if the file is *after* cutoff... but
the code does opposite!
{code}
/**
* Returns a filter that returns true if the file was last modified *after*
* the specified cutoff time.
*/
{code}
BUT..the code constructs the following:
{code}
public static IOFileFilter ageFileFilter(long cutoff) {
return new AgeFileFilter(cutoff);
}
{code}
And the Javadoc for this AgeFileFilter says...OLDER i.e. before
{code}
/**
* Constructs a new age file filter for files equal to or older than
* a certain cutoff
*
* @param cutoff the threshold age of the files
*/
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (IO-442) Javadoc contradictory for FileFilterUtils.ageFileFilter(cutoff) and the filter it constructs: AgeFileFilter(cutoff)
[
https://issues.apache.org/jira/browse/IO-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Robinson updated IO-442:
--
Description:
Documentation states that it returns true if the file is *after* cutoff... but
the code does opposite!
{code}
/**
* Returns a filter that returns true if the file was last modified after
* the specified cutoff time.
*/
{code}
BUT..the code constructs the following:
{code}
public static IOFileFilter ageFileFilter(long cutoff) {
return new AgeFileFilter(cutoff);
}
{code}
And the Javadoc for this AgeFileFilter says...OLDER i.e. before
{code}
/**
* Constructs a new age file filter for files equal to or older than
* a certain cutoff
*
* @param cutoff the threshold age of the files
*/
{code}
was:
Documentation states that it returns true if the file is *after* cutoff... but
the code does opposite!
{code}
/**
* Returns a filter that returns true if the file was last modified *after*
* the specified cutoff time.
*/
{code}
BUT..the code constructs the following:
{code}
public static IOFileFilter ageFileFilter(long cutoff) {
return new AgeFileFilter(cutoff);
}
{code}
And the Javadoc for this AgeFileFilter says...OLDER i.e. before
{code}
/**
* Constructs a new age file filter for files equal to or older than
* a certain cutoff
*
* @param cutoff the threshold age of the files
*/
{code}
Javadoc contradictory for FileFilterUtils.ageFileFilter(cutoff) and the
filter it constructs: AgeFileFilter(cutoff)
---
Key: IO-442
URL: https://issues.apache.org/jira/browse/IO-442
Project: Commons IO
Issue Type: Bug
Components: Filters
Affects Versions: 2.4
Reporter: Simon Robinson
Priority: Trivial
Documentation states that it returns true if the file is *after* cutoff...
but the code does opposite!
{code}
/**
* Returns a filter that returns true if the file was last modified after
* the specified cutoff time.
*/
{code}
BUT..the code constructs the following:
{code}
public static IOFileFilter ageFileFilter(long cutoff) {
return new AgeFileFilter(cutoff);
}
{code}
And the Javadoc for this AgeFileFilter says...OLDER i.e. before
{code}
/**
* Constructs a new age file filter for files equal to or older than
* a certain cutoff
*
* @param cutoff the threshold age of the files
*/
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (IO-442) Javadoc contradictory for FileFilterUtils.ageFileFilter(cutoff) and the filter it constructs: AgeFileFilter(cutoff)
[
https://issues.apache.org/jira/browse/IO-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Robinson updated IO-442:
--
Description:
Documentation states that it returns true if the file is *after* cutoff... but
the code does opposite!
{code}
/**
* Returns a filter that returns true if the file was last modified after
* the specified cutoff time.
*/
{code}
BUT..the code constructs the following:
{code}
public static IOFileFilter ageFileFilter(long cutoff) {
return new AgeFileFilter(cutoff);
}
{code}
And the Javadoc for this AgeFileFilter says...OLDER i.e. before
{code}
/**
* Constructs a new age file filter for files equal to or older than
* a certain cutoff
*
* @param cutoff the threshold age of the files
*/
{code}
Which is it?!
was:
Documentation states that it returns true if the file is *after* cutoff... but
the code does opposite!
{code}
/**
* Returns a filter that returns true if the file was last modified after
* the specified cutoff time.
*/
{code}
BUT..the code constructs the following:
{code}
public static IOFileFilter ageFileFilter(long cutoff) {
return new AgeFileFilter(cutoff);
}
{code}
And the Javadoc for this AgeFileFilter says...OLDER i.e. before
{code}
/**
* Constructs a new age file filter for files equal to or older than
* a certain cutoff
*
* @param cutoff the threshold age of the files
*/
{code}
Javadoc contradictory for FileFilterUtils.ageFileFilter(cutoff) and the
filter it constructs: AgeFileFilter(cutoff)
---
Key: IO-442
URL: https://issues.apache.org/jira/browse/IO-442
Project: Commons IO
Issue Type: Bug
Components: Filters
Affects Versions: 2.4
Reporter: Simon Robinson
Priority: Trivial
Documentation states that it returns true if the file is *after* cutoff...
but the code does opposite!
{code}
/**
* Returns a filter that returns true if the file was last modified after
* the specified cutoff time.
*/
{code}
BUT..the code constructs the following:
{code}
public static IOFileFilter ageFileFilter(long cutoff) {
return new AgeFileFilter(cutoff);
}
{code}
And the Javadoc for this AgeFileFilter says...OLDER i.e. before
{code}
/**
* Constructs a new age file filter for files equal to or older than
* a certain cutoff
*
* @param cutoff the threshold age of the files
*/
{code}
Which is it?!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (JCS-122) rework logging?
Romain Manni-Bucau created JCS-122: -- Summary: rework logging? Key: JCS-122 URL: https://issues.apache.org/jira/browse/JCS-122 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau currently JCS relies on [logging] Would be great to get rid of this dependency. Solutions I see: 1) use JUL (with extensibility like in http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/logger/) 2) write a little factory with a jcs.Logger to be able to switch Goal is to be able to adapt to frameworks and users. Guess first will be often JUL (TomEE), second SLF4J, [logging]... I'm for 1) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (LANG-1004) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa
[ https://issues.apache.org/jira/browse/LANG-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987919#comment-13987919 ] Benedikt Ritter commented on LANG-1004: --- Hi Michael, nice patch! However I'm a bit afraid this change will break clients that are using the method as it is now. What do you think? The main use case is probably formatting for displaying a value (in the GUI or in some kind of log file). So it may not be a problem? Benedikt DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa -- Key: LANG-1004 URL: https://issues.apache.org/jira/browse/LANG-1004 Project: Commons Lang Issue Type: Bug Components: lang.text.* Affects Versions: 3.3.2 Reporter: Michael Osipov Fix For: Patch Needed Attachments: LANG-1004.patch This method has several flaws: 1. Javadoc says: The format used is ISO8601-like: H:m:s.S. but the method call supplies H:mm:ss.SSS 2. ISO time never omits leading zeros, so the proper pattern must be HH:mm:ss.SSS 3. The method name says: HMS but includes the second fraction. Since the use of fractions is optional, the method should use HH:mm:ss and update the Javadoc as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (LANG-1004) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa
[
https://issues.apache.org/jira/browse/LANG-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987919#comment-13987919
]
Benedikt Ritter edited comment on LANG-1004 at 5/2/14 5:10 PM:
---
Hi Michael,
nice patch! However I'm a bit afraid this change will break clients that are
using the method as it is now. What do you think? The main use case is probably
formatting for displaying a value (in the GUI or in some kind of log file). So
it may not be a problem?
Benedikt
EDIT: how about providing a new method called {{formatDurationISOHMS}} which
formats the way you propose?
was (Author: britter):
Hi Michael,
nice patch! However I'm a bit afraid this change will break clients that are
using the method as it is now. What do you think? The main use case is probably
formatting for displaying a value (in the GUI or in some kind of log file). So
it may not be a problem?
Benedikt
DurationFormatUtils#formatDurationHMS implementation does not correspond to
Javadoc and vice versa
--
Key: LANG-1004
URL: https://issues.apache.org/jira/browse/LANG-1004
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 3.3.2
Reporter: Michael Osipov
Fix For: Patch Needed
Attachments: LANG-1004.patch
This method has several flaws:
1. Javadoc says: The format used is ISO8601-like: H:m:s.S. but the method
call supplies H:mm:ss.SSS
2. ISO time never omits leading zeros, so the proper pattern must be
HH:mm:ss.SSS
3. The method name says: HMS but includes the second fraction.
Since the use of fractions is optional, the method should use HH:mm:ss and
update the Javadoc as well.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JCS-122) rework logging?
[ https://issues.apache.org/jira/browse/JCS-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987924#comment-13987924 ] Joerg Schaible commented on JCS-122: The intention of [logging] is to enable users to adapt to other frameworks ;-) rework logging? --- Key: JCS-122 URL: https://issues.apache.org/jira/browse/JCS-122 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau currently JCS relies on [logging] Would be great to get rid of this dependency. Solutions I see: 1) use JUL (with extensibility like in http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/logger/) 2) write a little factory with a jcs.Logger to be able to switch Goal is to be able to adapt to frameworks and users. Guess first will be often JUL (TomEE), second SLF4J, [logging]... I'm for 1) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (JCS-122) rework logging?
[ https://issues.apache.org/jira/browse/JCS-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987967#comment-13987967 ] Romain Manni-Bucau commented on JCS-122: Yes but reality today is a lot rely on slf4j and the other point is we'll need JUL for tomee without commons-logging. rework logging? --- Key: JCS-122 URL: https://issues.apache.org/jira/browse/JCS-122 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau currently JCS relies on [logging] Would be great to get rid of this dependency. Solutions I see: 1) use JUL (with extensibility like in http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/logger/) 2) write a little factory with a jcs.Logger to be able to switch Goal is to be able to adapt to frameworks and users. Guess first will be often JUL (TomEE), second SLF4J, [logging]... I'm for 1) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (VFS-167) [FTP] Proxy Support (similiar to VFS-84 for SFTP)
[ https://issues.apache.org/jira/browse/VFS-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13988310#comment-13988310 ] Bernd Eckenfels commented on VFS-167: - George, well yes it should. However the proxy support for SFTP and FTP is just a thin layer on top of the actual implementation (JSch in case of ssh and commons.net.ftp in case of FTP). Jsch has its own classes for proxies, and therefore can support proxy authentication. The FTPClient only support java.net.Proxy (or a Socket factory). So while it is possible to add more proxy functionality it is a more complex change. I only have added the proposed minor change. I do wonder if there is a common socket factory in commons net or somewhere which could be used and if somebody want to take over that task. I will close this bug, can you open a new one in regards to the proxy authentication (and mention this comment). [FTP] Proxy Support (similiar to VFS-84 for SFTP) - Key: VFS-167 URL: https://issues.apache.org/jira/browse/VFS-167 Project: Commons VFS Issue Type: Improvement Affects Versions: Nightly Builds Environment: Window 2000 and java Reporter: vikas Assignee: Bernd Eckenfels Priority: Minor Fix For: 2.1 I am given proxy support for SFTP by using bug 84 code. What is the way to give proxy support in FTP? Please help asap if possible then we me the way? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (VFS-167) [FTP] Proxy Support (similiar to VFS-84 for SFTP)
[ https://issues.apache.org/jira/browse/VFS-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels resolved VFS-167. - Resolution: Fixed [FTP] Proxy Support (similiar to VFS-84 for SFTP) - Key: VFS-167 URL: https://issues.apache.org/jira/browse/VFS-167 Project: Commons VFS Issue Type: Improvement Affects Versions: Nightly Builds Environment: Window 2000 and java Reporter: vikas Assignee: Bernd Eckenfels Priority: Minor Fix For: 2.1 I am given proxy support for SFTP by using bug 84 code. What is the way to give proxy support in FTP? Please help asap if possible then we me the way? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (VFS-521) [RAM][tests] Failure with Java 8
Bernd Eckenfels created VFS-521: --- Summary: [RAM][tests] Failure with Java 8 Key: VFS-521 URL: https://issues.apache.org/jira/browse/VFS-521 Project: Commons VFS Issue Type: Bug Affects Versions: 2.1 Environment: Win64 with Maven 3.0.5 and Java 1.8.0_05 Reporter: Bernd Eckenfels Assignee: Bernd Eckenfels Priority: Blocker When running the unit tests the RAM provider custom tests fails only with Java 8 (build and runtime): Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.019 sec FAILURE! - in org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest testSmallFS(org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest) Time elapsed: 0.012 sec ERROR! java.lang.IllegalArgumentException: Self-suppression not permitted at org.apache.commons.vfs2.provider.ram.RamFileObject.resize(RamFileObject.java:277) at org.apache.commons.vfs2.provider.ram.RamFileOutputStream.write(RamFileOutputStream.java:68) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) at org.apache.commons.vfs2.util.MonitorOutputStream.flush(MonitorOutputStream.java:114) at java.io.FilterOutputStream.close(FilterOutputStream.java:158) at org.apache.commons.vfs2.util.MonitorOutputStream.close(MonitorOutputStream.java:54) at org.apache.commons.vfs2.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:711) at org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest.testSmallFS(CustomRamProviderTest.java:264) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (VFS-428) DavException: (301) Moved Permanently
[
https://issues.apache.org/jira/browse/VFS-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Eckenfels updated VFS-428:
Priority: Major (was: Blocker)
DavException: (301) Moved Permanently
--
Key: VFS-428
URL: https://issues.apache.org/jira/browse/VFS-428
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0, 2.1
Environment: Apache 2.2.22 as Testerver and setted up like
http://commons.apache.org/vfs/testserver.html (but changed the 'crypt'
password)
Reporter: Robert Kornmesser
Labels: webdav
Running the WebdavProviderTestCase using mvn -P webdav clean test
-Dtest.webdav.uri=webdav://vfsusr:vfstest@localhost/vfstest
-Dtest=WebdavProviderTestCase results in
{code}DavException: (301) Moved Permanently
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.645 sec
FAILURE!
Results :
Tests in error:
junit.framework.TestSuite@55c9be00(org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1):
Could not determine the type of file
webdav://vfsusr:@localhost/vfstest/read-tests.
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
{code}
The deeper Problem is, that the HttpClient using by VFS does not append a
trailing slash and mod_dir of httpd has DirectorySlash On per default. So
httpd send 301 redirect to the same url with / appended.
I know that for this reason of problematic webdav client apache introduced
redirect-carefully for some user agents using the BrowserMatch directive.
So I just tried adding the following into my Directory directive
{code}
BrowserMatch ^Jakarta-Commons-VFS redirect-carefully
BrowserMatch ^Jakarta Commons-HttpClient/3.0 redirect-carefully
BrowserMatch ^Jakarta Commons-HttpClient/3.1 redirect-carefully
{code}
Its needed to have Jakarta-Commons-VFS *and* Jakarta Commons-HttpClient
because of two requests from commons vfs using two different user agents.
But instead of solving the issue, I get for every FileObject.getChildren()
call at least one FileObject of type imaginary with the same basename as the
parent. Thats not a problem at all (besides that this is totally wrong!) but
deleting a parent just dont work anymore, because of an *non-existent*
imaginary file inside the dir which cannot be deleted of course.
To cut a long story short, what is the right httpd webdav server config to
use 2.0 Release version of VFS?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Reopened] (LANG-1003) DurationFormatUtils are not able to handle negative durations/periods
[
https://issues.apache.org/jira/browse/LANG-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reopened LANG-1003:
--
Reopening because you forgot to document those runtime exception with
{{@throws}}.
DurationFormatUtils are not able to handle negative durations/periods
-
Key: LANG-1003
URL: https://issues.apache.org/jira/browse/LANG-1003
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 3.3.2
Reporter: Michael Osipov
Assignee: Benedikt Ritter
Priority: Critical
Fix For: 3.4
It spits out complete garbage.
{code}
System.out.println(DurationFormatUtils.formatDurationHMS(-3454));
System.out.println(DurationFormatUtils.formatPeriodISO(4000, 3000));
{code}
{noformat}
0:00:-3.-454
P-1Y11M30DT23H59M59.000S
{noformat}
It should throw an {{IllegalArgumentException}} if duration is 0 or period
diff is 0.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (VFS-521) [RAM][tests] Failure with Java 8
[ https://issues.apache.org/jira/browse/VFS-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13988334#comment-13988334 ] Bernd Eckenfels commented on VFS-521: - This seems to be a java8 thing, this test actually expects a `new IOException()` and instead of this the self suppression is alerted. Internetz say it is related to try with resource, however we dont use that (at least not in the VFS code). Maybe its a test framework problem? [RAM][tests] Failure with Java 8 Key: VFS-521 URL: https://issues.apache.org/jira/browse/VFS-521 Project: Commons VFS Issue Type: Bug Affects Versions: 2.1 Environment: Win64 with Maven 3.0.5 and Java 1.8.0_05 Reporter: Bernd Eckenfels Assignee: Bernd Eckenfels Priority: Blocker When running the unit tests the RAM provider custom tests fails only with Java 8 (build and runtime): Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.019 sec FAILURE! - in org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest testSmallFS(org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest) Time elapsed: 0.012 sec ERROR! java.lang.IllegalArgumentException: Self-suppression not permitted at org.apache.commons.vfs2.provider.ram.RamFileObject.resize(RamFileObject.java:277) at org.apache.commons.vfs2.provider.ram.RamFileOutputStream.write(RamFileOutputStream.java:68) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) at org.apache.commons.vfs2.util.MonitorOutputStream.flush(MonitorOutputStream.java:114) at java.io.FilterOutputStream.close(FilterOutputStream.java:158) at org.apache.commons.vfs2.util.MonitorOutputStream.close(MonitorOutputStream.java:54) at org.apache.commons.vfs2.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:711) at org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest.testSmallFS(CustomRamProviderTest.java:264) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (LANG-1004) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa
[
https://issues.apache.org/jira/browse/LANG-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13988341#comment-13988341
]
Michael Osipov commented on LANG-1004:
--
I guess you are right about the usecase but we *cannot* do assumptions about
the client. So the impact should be minimal. In this case, she should stick to
{{HH:mm:ss.SSS}} and improve the docs. However, would could spawn another
ticket for Lang 4 to split method into two methods, one for {{HH:mm:ss}} and
one {{formatDurationHMSwithFrac}} or something like this (maybe a boolean flag)
which will use {{HH:mm:ss.SSS}}. Same applies for the ISO duration of course.
I wouldn't bloat the API with another method but I would rather add something
like I did for
[MNG-5176|https://jira.codehaus.org/browse/MNG-5176?focusedCommentId=340413page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-340413].
DurationFormatUtils#formatDurationHMS implementation does not correspond to
Javadoc and vice versa
--
Key: LANG-1004
URL: https://issues.apache.org/jira/browse/LANG-1004
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 3.3.2
Reporter: Michael Osipov
Fix For: Patch Needed
Attachments: LANG-1004.patch, LANG-1004_v2.patch
This method has several flaws:
1. Javadoc says: The format used is ISO8601-like: H:m:s.S. but the method
call supplies H:mm:ss.SSS
2. ISO time never omits leading zeros, so the proper pattern must be
HH:mm:ss.SSS
3. The method name says: HMS but includes the second fraction.
Since the use of fractions is optional, the method should use HH:mm:ss and
update the Javadoc as well.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (LANG-1004) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa
[ https://issues.apache.org/jira/browse/LANG-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated LANG-1004: - Attachment: LANG-1004_v2.patch Have a look at the new patch. DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa -- Key: LANG-1004 URL: https://issues.apache.org/jira/browse/LANG-1004 Project: Commons Lang Issue Type: Bug Components: lang.text.* Affects Versions: 3.3.2 Reporter: Michael Osipov Fix For: Patch Needed Attachments: LANG-1004.patch, LANG-1004_v2.patch This method has several flaws: 1. Javadoc says: The format used is ISO8601-like: H:m:s.S. but the method call supplies H:mm:ss.SSS 2. ISO time never omits leading zeros, so the proper pattern must be HH:mm:ss.SSS 3. The method name says: HMS but includes the second fraction. Since the use of fractions is optional, the method should use HH:mm:ss and update the Javadoc as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (VFS-521) [RAM][tests] Failure with Java 8
[ https://issues.apache.org/jira/browse/VFS-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13988334#comment-13988334 ] Bernd Eckenfels edited comment on VFS-521 at 5/2/14 10:22 PM: -- This seems to be a java8 thing. The test actually expexts an IOException, and in the above stacktrace location it is actually thrown: org.apache.commons.vfs2.provider.ram.RamFileObject.resize(RamFileObject.java:277) But the runtime seems to wrap this in an IlelgalArgumentException. Internez say it is related to try with resource (which can collect suppressed exceptions), however we don't use that (at least not in the VFS code). Maybe its a test test-framework or JUnit problem? was (Author: b.eckenfels): This seems to be a java8 thing, this test actually expects a `new IOException()` and instead of this the self suppression is alerted. Internetz say it is related to try with resource, however we dont use that (at least not in the VFS code). Maybe its a test framework problem? [RAM][tests] Failure with Java 8 Key: VFS-521 URL: https://issues.apache.org/jira/browse/VFS-521 Project: Commons VFS Issue Type: Bug Affects Versions: 2.1 Environment: Win64 with Maven 3.0.5 and Java 1.8.0_05 Reporter: Bernd Eckenfels Assignee: Bernd Eckenfels Priority: Blocker When running the unit tests the RAM provider custom tests fails only with Java 8 (build and runtime): Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.019 sec FAILURE! - in org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest testSmallFS(org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest) Time elapsed: 0.012 sec ERROR! java.lang.IllegalArgumentException: Self-suppression not permitted at org.apache.commons.vfs2.provider.ram.RamFileObject.resize(RamFileObject.java:277) at org.apache.commons.vfs2.provider.ram.RamFileOutputStream.write(RamFileOutputStream.java:68) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) at org.apache.commons.vfs2.util.MonitorOutputStream.flush(MonitorOutputStream.java:114) at java.io.FilterOutputStream.close(FilterOutputStream.java:158) at org.apache.commons.vfs2.util.MonitorOutputStream.close(MonitorOutputStream.java:54) at org.apache.commons.vfs2.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:711) at org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest.testSmallFS(CustomRamProviderTest.java:264) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (LANG-1004) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa
[ https://issues.apache.org/jira/browse/LANG-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated LANG-1004: - Attachment: (was: LANG-1004_v2.patch) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa -- Key: LANG-1004 URL: https://issues.apache.org/jira/browse/LANG-1004 Project: Commons Lang Issue Type: Bug Components: lang.text.* Affects Versions: 3.3.2 Reporter: Michael Osipov Fix For: Patch Needed Attachments: LANG-1004.patch, LANG-1004_v2.patch This method has several flaws: 1. Javadoc says: The format used is ISO8601-like: H:m:s.S. but the method call supplies H:mm:ss.SSS 2. ISO time never omits leading zeros, so the proper pattern must be HH:mm:ss.SSS 3. The method name says: HMS but includes the second fraction. Since the use of fractions is optional, the method should use HH:mm:ss and update the Javadoc as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Issue Comment Deleted] (LANG-1004) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa
[ https://issues.apache.org/jira/browse/LANG-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated LANG-1004: - Comment: was deleted (was: Have a look at the new patch.) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa -- Key: LANG-1004 URL: https://issues.apache.org/jira/browse/LANG-1004 Project: Commons Lang Issue Type: Bug Components: lang.text.* Affects Versions: 3.3.2 Reporter: Michael Osipov Fix For: Patch Needed Attachments: LANG-1004.patch, LANG-1004_v2.patch This method has several flaws: 1. Javadoc says: The format used is ISO8601-like: H:m:s.S. but the method call supplies H:mm:ss.SSS 2. ISO time never omits leading zeros, so the proper pattern must be HH:mm:ss.SSS 3. The method name says: HMS but includes the second fraction. Since the use of fractions is optional, the method should use HH:mm:ss and update the Javadoc as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (LANG-1004) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa
[ https://issues.apache.org/jira/browse/LANG-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated LANG-1004: - Attachment: LANG-1004_v2.patch Have a look at the new patch. DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa -- Key: LANG-1004 URL: https://issues.apache.org/jira/browse/LANG-1004 Project: Commons Lang Issue Type: Bug Components: lang.text.* Affects Versions: 3.3.2 Reporter: Michael Osipov Fix For: Patch Needed Attachments: LANG-1004.patch, LANG-1004_v2.patch This method has several flaws: 1. Javadoc says: The format used is ISO8601-like: H:m:s.S. but the method call supplies H:mm:ss.SSS 2. ISO time never omits leading zeros, so the proper pattern must be HH:mm:ss.SSS 3. The method name says: HMS but includes the second fraction. Since the use of fractions is optional, the method should use HH:mm:ss and update the Javadoc as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (LANG-1004) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa
[
https://issues.apache.org/jira/browse/LANG-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13988341#comment-13988341
]
Michael Osipov edited comment on LANG-1004 at 5/2/14 10:26 PM:
---
I guess you are right about the usecase but we *cannot* do assumptions about
the client. So the impact should be minimal. In this case, we should stick to
{{HH:mm:ss.SSS}} and improve the docs. However, we could spawn another ticket
for Lang 4 to split method into two methods, one for {{HH:mm:ss}} and one
{{formatDurationHMSwithFrac}} or something like this (maybe a boolean flag)
which will use {{HH:mm:ss.SSS}}. Same applies for the ISO duration of course.
I wouldn't bloat the API with another method but I would rather add something
like I did for
[MNG-5176|https://jira.codehaus.org/browse/MNG-5176?focusedCommentId=340413page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-340413].
was (Author: michael-o):
I guess you are right about the usecase but we *cannot* do assumptions about
the client. So the impact should be minimal. In this case, she should stick to
{{HH:mm:ss.SSS}} and improve the docs. However, would could spawn another
ticket for Lang 4 to split method into two methods, one for {{HH:mm:ss}} and
one {{formatDurationHMSwithFrac}} or something like this (maybe a boolean flag)
which will use {{HH:mm:ss.SSS}}. Same applies for the ISO duration of course.
I wouldn't bloat the API with another method but I would rather add something
like I did for
[MNG-5176|https://jira.codehaus.org/browse/MNG-5176?focusedCommentId=340413page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-340413].
DurationFormatUtils#formatDurationHMS implementation does not correspond to
Javadoc and vice versa
--
Key: LANG-1004
URL: https://issues.apache.org/jira/browse/LANG-1004
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 3.3.2
Reporter: Michael Osipov
Fix For: Patch Needed
Attachments: LANG-1004.patch, LANG-1004_v2.patch
This method has several flaws:
1. Javadoc says: The format used is ISO8601-like: H:m:s.S. but the method
call supplies H:mm:ss.SSS
2. ISO time never omits leading zeros, so the proper pattern must be
HH:mm:ss.SSS
3. The method name says: HMS but includes the second fraction.
Since the use of fractions is optional, the method should use HH:mm:ss and
update the Javadoc as well.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (VFS-521) [RAM][tests] Failure with Java 8
[
https://issues.apache.org/jira/browse/VFS-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13988355#comment-13988355
]
Bernd Eckenfels commented on VFS-521:
-
The whole stacktrace is more informative, it looks like:
{code}
??? Catched IAEjava.lang.IllegalArgumentException: Self-suppression not
permitted
at java.lang.Throwable.addSuppressed(Throwable.java:1043)
at java.io.FilterOutputStream.close(FilterOutputStream.java:159)
at
org.apache.commons.vfs2.util.MonitorOutputStream.close(MonitorOutputStream.java:54)
at
org.apache.commons.vfs2.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:710)
at
org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest.testSmallFS(CustomRamProviderTest.java:264)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.io.IOException: FileSystem capacity (10) exceeded.
at
org.apache.commons.vfs2.provider.ram.RamFileObject.resize(RamFileObject.java:277)
at
org.apache.commons.vfs2.provider.ram.RamFileOutputStream.write(RamFileOutputStream.java:68)
at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at
org.apache.commons.vfs2.util.MonitorOutputStream.flush(MonitorOutputStream.java:114)
at java.io.FilterOutputStream.close(FilterOutputStream.java:158)
... 28 more
{code}
[RAM][tests] Failure with Java 8
Key: VFS-521
URL: https://issues.apache.org/jira/browse/VFS-521
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.1
Environment: Win64 with Maven 3.0.5 and Java 1.8.0_05
Reporter: Bernd Eckenfels
Assignee: Bernd Eckenfels
Priority: Blocker
When running the unit tests the RAM provider custom tests fails only with
Java 8 (build and runtime):
Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.019 sec
FAILURE! - in org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest
testSmallFS(org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest)
Time elapsed: 0.012 sec ERROR!
java.lang.IllegalArgumentException: Self-suppression not permitted
at
org.apache.commons.vfs2.provider.ram.RamFileObject.resize(RamFileObject.java:277)
at
org.apache.commons.vfs2.provider.ram.RamFileOutputStream.write(RamFileOutputStream.java:68)
at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at
[jira] [Created] (LANG-1005) Extend DurationFormatUtils#formatDurationISO default pattern to match #formatDurationHMS
Michael Osipov created LANG-1005:
Summary: Extend DurationFormatUtils#formatDurationISO default
pattern to match #formatDurationHMS
Key: LANG-1005
URL: https://issues.apache.org/jira/browse/LANG-1005
Project: Commons Lang
Issue Type: Improvement
Components: lang.text.*
Affects Versions: 3.3.2
Reporter: Michael Osipov
Currently, {{formatDuration}} will specify {{HH:mm:ss.SSS}} but
{{formatDurationISO}} specifies {{'P''Y'M'M'd'DT'H'H'm'M's.S'S'}}. Both
should have a uniform definition, i.e., it should be
{{'P''Y'M'M'd'DT'H'H'm'M's.SSS'S'}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (VFS-521) [RAM][tests] Failure with Java 8
[ https://issues.apache.org/jira/browse/VFS-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels updated VFS-521: Labels: java8 tests (was: ) [RAM][tests] Failure with Java 8 Key: VFS-521 URL: https://issues.apache.org/jira/browse/VFS-521 Project: Commons VFS Issue Type: Bug Affects Versions: 2.1 Environment: Win64 with Maven 3.0.5 and Java 1.8.0_05 Reporter: Bernd Eckenfels Assignee: Bernd Eckenfels Priority: Blocker Labels: java8, tests Attachments: fos.patch When running the unit tests the RAM provider custom tests fails only with Java 8 (build and runtime): Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.019 sec FAILURE! - in org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest testSmallFS(org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest) Time elapsed: 0.012 sec ERROR! java.lang.IllegalArgumentException: Self-suppression not permitted at org.apache.commons.vfs2.provider.ram.RamFileObject.resize(RamFileObject.java:277) at org.apache.commons.vfs2.provider.ram.RamFileOutputStream.write(RamFileOutputStream.java:68) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) at org.apache.commons.vfs2.util.MonitorOutputStream.flush(MonitorOutputStream.java:114) at java.io.FilterOutputStream.close(FilterOutputStream.java:158) at org.apache.commons.vfs2.util.MonitorOutputStream.close(MonitorOutputStream.java:54) at org.apache.commons.vfs2.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:711) at org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest.testSmallFS(CustomRamProviderTest.java:264) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (VFS-521) [RAM][tests] Failure with Java 8
[ https://issues.apache.org/jira/browse/VFS-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels updated VFS-521: Attachment: fos.patch The above patch does fix the problem for Java 8 and it also avoids using the unsafe super.close() method. What do you think? (it does not use the suppressed warnings feature as this is Java 5 code). [RAM][tests] Failure with Java 8 Key: VFS-521 URL: https://issues.apache.org/jira/browse/VFS-521 Project: Commons VFS Issue Type: Bug Affects Versions: 2.1 Environment: Win64 with Maven 3.0.5 and Java 1.8.0_05 Reporter: Bernd Eckenfels Assignee: Bernd Eckenfels Priority: Blocker Labels: java8, tests Attachments: fos.patch When running the unit tests the RAM provider custom tests fails only with Java 8 (build and runtime): Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.019 sec FAILURE! - in org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest testSmallFS(org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest) Time elapsed: 0.012 sec ERROR! java.lang.IllegalArgumentException: Self-suppression not permitted at org.apache.commons.vfs2.provider.ram.RamFileObject.resize(RamFileObject.java:277) at org.apache.commons.vfs2.provider.ram.RamFileOutputStream.write(RamFileOutputStream.java:68) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) at org.apache.commons.vfs2.util.MonitorOutputStream.flush(MonitorOutputStream.java:114) at java.io.FilterOutputStream.close(FilterOutputStream.java:158) at org.apache.commons.vfs2.util.MonitorOutputStream.close(MonitorOutputStream.java:54) at org.apache.commons.vfs2.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:711) at org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest.testSmallFS(CustomRamProviderTest.java:264) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DBCP-412) dbcp2.PoolableConnection.close raises NullPointerException
[
https://issues.apache.org/jira/browse/DBCP-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved DBCP-412.
--
Resolution: Fixed
PDS constructor check added in r1592119
dbcp2.PoolableConnection.close raises NullPointerException
--
Key: DBCP-412
URL: https://issues.apache.org/jira/browse/DBCP-412
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 2.0
Environment: Mac OSX, Java 7, SQLAzure
Reporter: Davide Caroselli
Priority: Minor
Labels: NullPointerException, PoolableConnection
Fix For: 2.0.1
Attachments: DBCP-412.patch
I found a critical error while closing a PoolableConnection.
Here's the code to reproduce the bug (largely copied from the example shown
in the Apache DBCP site):
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
public static void main(String[] args) throws Throwable {
Class.forName(com.microsoft.sqlserver.jdbc.SQLServerDriver);
DataSource dataSource = setupDataSource(jdbcUrl);
Connection connection = null;
PreparedStatement statement = null;
ResultSet result = null;
try {
connection = dataSource.getConnection();
statement = connection.prepareStatement(SELECT 1);
result = statement.executeQuery();
} finally {
result.close();
statement.close();
connection.close();
}
}
public static DataSource setupDataSource(String connectURI) {
ConnectionFactory connectionFactory = new
DriverManagerConnectionFactory(connectURI, null);
PoolableConnectionFactory poolableConnectionFactory = new
PoolableConnectionFactory(connectionFactory, null);
ObjectPoolPoolableConnection connectionPool = new
GenericObjectPool(poolableConnectionFactory);
PoolingDataSourcePoolableConnection dataSource = new
PoolingDataSource(connectionPool);
return dataSource;
}
{code}
When the code tries to close the connection (in the final block), an
exception is raised:
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
Exception in thread main java.lang.NullPointerException
at
org.apache.commons.dbcp2.PoolableConnection.close(PoolableConnection.java:151)
at
org.apache.commons.dbcp2.DelegatingConnection.closeInternal(DelegatingConnection.java:235)
at
org.apache.commons.dbcp2.DelegatingConnection.close(DelegatingConnection.java:218)
at
org.apache.commons.dbcp2.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:212)
at
dbcp.PoolingDataSourceExample2.closeQuietly(PoolingDataSourceExample2.java:64)
at
dbcp.PoolingDataSourceExample2.main(PoolingDataSourceExample2.java:43){code}
As I can see, the problem is the _pool variable inside PoolableConnection
but I could not find any solution.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (DBCP-417) BasicManagedDataSource does not free connection after transaction is commited
[
https://issues.apache.org/jira/browse/DBCP-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved DBCP-417.
--
Resolution: Fixed
Patch committed in r1592132
BasicManagedDataSource does not free connection after transaction is commited
-
Key: DBCP-417
URL: https://issues.apache.org/jira/browse/DBCP-417
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 2.0
Environment: Geronimo TM and JOTM, H2Database JDBC Driver
Reporter: Balazs Zsoldos
Priority: Blocker
Fix For: 2.0.1
Attachments: DBCP-417.patch, test-dbcp2-BasicManagedDataSource.zip
When a JTA Transaction is commited, the Managed connection is not available
again. The pool is becomes exhausted.
To reproduce:
{code:java}
Jotm jotm = new Jotm(true, false);
JdbcDataSource h2DataSource = new JdbcDataSource();
h2DataSource.setUrl(jdbc:h2:mem:test_mem);
BasicManagedDataSource basicManagedDataSource = new BasicManagedDataSource();
basicManagedDataSource.setTransactionManager(jotm.getTransactionManager());
basicManagedDataSource.setXaDataSourceInstance(h2DataSource);
basicManagedDataSource.setMaxTotal(2);
basicManagedDataSource.setMaxIdle(2);
UserTransaction userTransaction = jotm.getUserTransaction();
userTransaction.begin();
Connection connection = basicManagedDataSource.getConnection();
connection.close();
userTransaction.commit();
userTransaction.begin();
connection = basicManagedDataSource.getConnection();
connection.close();
userTransaction.commit();
// The managed datasource will block here as there is no available connection
userTransaction.begin();
connection = basicManagedDataSource.getConnection();
connection.close();
userTransaction.commit();
{code}
Set the priority to Blocker as BasicManagedDataSource cannot be used at all
with the bug.
Tested with Geronimo Transaction Manager and JOTM.
This worked well with version 1.4.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (VFS-521) [RAM][tests] Failure with Java 8
[
https://issues.apache.org/jira/browse/VFS-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13988355#comment-13988355
]
Bernd Eckenfels edited comment on VFS-521 at 5/3/14 1:13 AM:
-
The whole stacktrace is more informative, it looks like:
{code}
java.lang.IllegalArgumentException: Self-suppression not permitted
at java.lang.Throwable.addSuppressed(Throwable.java:1043)
at java.io.FilterOutputStream.close(FilterOutputStream.java:159)
at
org.apache.commons.vfs2.util.MonitorOutputStream.close(MonitorOutputStream.java:54)
at
org.apache.commons.vfs2.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:710)
at
org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest.testSmallFS(CustomRamProviderTest.java:264)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.io.IOException: FileSystem capacity (10) exceeded.
at
org.apache.commons.vfs2.provider.ram.RamFileObject.resize(RamFileObject.java:277)
at
org.apache.commons.vfs2.provider.ram.RamFileOutputStream.write(RamFileOutputStream.java:68)
at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at
org.apache.commons.vfs2.util.MonitorOutputStream.flush(MonitorOutputStream.java:114)
at java.io.FilterOutputStream.close(FilterOutputStream.java:158)
... 28 more
{code}
was (Author: b.eckenfels):
The whole stacktrace is more informative, it looks like:
{code}
??? Catched IAEjava.lang.IllegalArgumentException: Self-suppression not
permitted
at java.lang.Throwable.addSuppressed(Throwable.java:1043)
at java.io.FilterOutputStream.close(FilterOutputStream.java:159)
at
org.apache.commons.vfs2.util.MonitorOutputStream.close(MonitorOutputStream.java:54)
at
org.apache.commons.vfs2.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:710)
at
org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest.testSmallFS(CustomRamProviderTest.java:264)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
[jira] [Updated] (VFS-521) [RAM][tests] Failure with Java 8
[
https://issues.apache.org/jira/browse/VFS-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Eckenfels updated VFS-521:
Description:
When running the unit tests the RAM provider custom tests fails only with Java
8 (build and runtime):
{code}
Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.019 sec
FAILURE! - in org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest
testSmallFS(org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest)
Time elapsed: 0.012 sec ERROR!
java.lang.IllegalArgumentException: Self-suppression not permitted
at
org.apache.commons.vfs2.provider.ram.RamFileObject.resize(RamFileObject.java:277)
at
org.apache.commons.vfs2.provider.ram.RamFileOutputStream.write(RamFileOutputStream.java:68)
at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at
org.apache.commons.vfs2.util.MonitorOutputStream.flush(MonitorOutputStream.java:114)
at java.io.FilterOutputStream.close(FilterOutputStream.java:158)
at
org.apache.commons.vfs2.util.MonitorOutputStream.close(MonitorOutputStream.java:54)
at
org.apache.commons.vfs2.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:711)
at
org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest.testSmallFS(CustomRamProviderTest.java:264)
{code}
was:
When running the unit tests the RAM provider custom tests fails only with Java
8 (build and runtime):
Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.019 sec
FAILURE! - in org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest
testSmallFS(org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest)
Time elapsed: 0.012 sec ERROR!
java.lang.IllegalArgumentException: Self-suppression not permitted
at
org.apache.commons.vfs2.provider.ram.RamFileObject.resize(RamFileObject.java:277)
at
org.apache.commons.vfs2.provider.ram.RamFileOutputStream.write(RamFileOutputStream.java:68)
at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at
org.apache.commons.vfs2.util.MonitorOutputStream.flush(MonitorOutputStream.java:114)
at java.io.FilterOutputStream.close(FilterOutputStream.java:158)
at
org.apache.commons.vfs2.util.MonitorOutputStream.close(MonitorOutputStream.java:54)
at
org.apache.commons.vfs2.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:711)
at
org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest.testSmallFS(CustomRamProviderTest.java:264)
[RAM][tests] Failure with Java 8
Key: VFS-521
URL: https://issues.apache.org/jira/browse/VFS-521
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.1
Environment: Win64 with Maven 3.0.5 and Java 1.8.0_05
Reporter: Bernd Eckenfels
Assignee: Bernd Eckenfels
Priority: Blocker
Labels: java8, tests
Attachments: fos.patch
When running the unit tests the RAM provider custom tests fails only with
Java 8 (build and runtime):
{code}
Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.019 sec
FAILURE! - in org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest
testSmallFS(org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest)
Time elapsed: 0.012 sec ERROR!
java.lang.IllegalArgumentException: Self-suppression not permitted
at
org.apache.commons.vfs2.provider.ram.RamFileObject.resize(RamFileObject.java:277)
at
org.apache.commons.vfs2.provider.ram.RamFileOutputStream.write(RamFileOutputStream.java:68)
at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at
org.apache.commons.vfs2.util.MonitorOutputStream.flush(MonitorOutputStream.java:114)
at java.io.FilterOutputStream.close(FilterOutputStream.java:158)
at
org.apache.commons.vfs2.util.MonitorOutputStream.close(MonitorOutputStream.java:54)
at
org.apache.commons.vfs2.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:711)
at
org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest.testSmallFS(CustomRamProviderTest.java:264)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SANDBOX-473) Exception raised during Transformation
[ https://issues.apache.org/jira/browse/SANDBOX-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13988577#comment-13988577 ] Yogesh Rao commented on SANDBOX-473: Will certainly tidy up.. i thought i had applied the maven code setting to my eclipse IDE.. looks like it didn't apply.. will fix and re upload it. Also on this functionality i saw in BU1 that few automatic conversions for e.g. between Boolean to String or Boolean to Integer were automatically handled. I noticed the current code base didn't support this and Transformer interface seemed to me like the next generation Converter interface from BU1. Regards, -Yogesh Exception raised during Transformation -- Key: SANDBOX-473 URL: https://issues.apache.org/jira/browse/SANDBOX-473 Project: Commons Sandbox Issue Type: Task Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Yogesh Rao Fix For: Nightly Builds Attachments: TransformationException.java.txt, Transformer.java.txt The convert method within the Transformer interface does not throw a exception. How about creating an exception which would be thrown by the convert method when encountered with an issue? -- This message was sent by Atlassian JIRA (v6.2#6252)
