[jira] Created: (JXPATH-81) Allow paramaterized accessors
Allow paramaterized accessors - Key: JXPATH-81 URL: https://issues.apache.org/jira/browse/JXPATH-81 Project: Commons JXPath Issue Type: Improvement Reporter: Rob van Dort Priority: Minor As I could make up until now, only attribute accessors without parameters are allowed, e.g. public Address getAddress(). Attribute accessors with an underlying map can be used, e.g. public Map getAddress() (see Map Element Access in JXPath User Guide) In some cases it may be useful to use accessors with parameters, e.g. public Address getAddress(String addressType), this is a feature I would like to see added to JXPath. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JXPATH-81) Allow paramaterized accessors
[ https://issues.apache.org/jira/browse/JXPATH-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493376 ] Matt Benson commented on JXPATH-81: --- I am far from an XPath XPert; however I must say I have never noticed any example syntax that would imply this capability. Remember that JXPath is primarily an XPath implementation, albeit one that happens to know how to process Java object hierarchies as if they were XML documents. If it's not in the syntax specification it would seem to be a candidate for a custom extension function. Allow paramaterized accessors - Key: JXPATH-81 URL: https://issues.apache.org/jira/browse/JXPATH-81 Project: Commons JXPath Issue Type: Improvement Reporter: Rob van Dort Priority: Minor As I could make up until now, only attribute accessors without parameters are allowed, e.g. public Address getAddress(). Attribute accessors with an underlying map can be used, e.g. public Map getAddress() (see Map Element Access in JXPath User Guide) In some cases it may be useful to use accessors with parameters, e.g. public Address getAddress(String addressType), this is a feature I would like to see added to JXPath. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (IO-117) EndianUtils.readSwappedUnsignedInteger() may return a negative number
[ https://issues.apache.org/jira/browse/IO-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated IO-117: - Fix Version/s: 1.4 EndianUtils.readSwappedUnsignedInteger() may return a negative number - Key: IO-117 URL: https://issues.apache.org/jira/browse/IO-117 Project: Commons IO Issue Type: Bug Affects Versions: 1.3.1 Reporter: Hiroshi Ikeda Fix For: 1.4 Attachments: EndianUtilsTest.java, IO-117.patch Methods about reading unsigned-integer in class EndianUtils may return a negative number, due to casting int to long. Calculations with operator etc. are under integer in these methods so its results are integer, then implicit casting the results to long keeps its positive/negative sign. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (IO-110) FileSystemUtils.freeSpaceKb does not work on AIX
[ https://issues.apache.org/jira/browse/IO-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated IO-110: - Fix Version/s: 1.4 Marking these as 1.4 fix versions - not that we'll have any access to said platforms so it's more a question of cleaning these issues up if we don't hear back by the time of 1.4. FileSystemUtils.freeSpaceKb does not work on AIX - Key: IO-110 URL: https://issues.apache.org/jira/browse/IO-110 Project: Commons IO Issue Type: Bug Affects Versions: 1.2 Environment: AIX operating system version 5.3 $ uname AIX $ oslevel -r 5300-04 Reporter: Nagarajan Ragunathan Fix For: 1.4 FileSystemUtils.freeSpaceKb does not work on AIX. Throws IOException . It is due to the format of 'df -k' output on AIX Operating System. $ df -k / Filesystem1024-blocks Free %UsedIused %Iused Mounted on /dev/hd4 262144168324 36% 391610% / Note the fourth entry is %Used. 'df -kt' command provides the format expected by freeSpaceKb method. $ df -kt / Filesystem1024-blocks Used Free %Used Mounted on /dev/hd4 262144 93820168324 36% / So, for AIX operating system, change it to use 'df -kt ' instead of df -k -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-216) Improvement of error recovery in KeyedCPDSConnectionFactory
[ https://issues.apache.org/jira/browse/DBCP-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated DBCP-216: --- Fix Version/s: 1.3 Improvement of error recovery in KeyedCPDSConnectionFactory --- Key: DBCP-216 URL: https://issues.apache.org/jira/browse/DBCP-216 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 1.2.2 Environment: Windows XP, Java 1.5.0_06-b05, Sybase ASE 12.5.4, jConnect 6.0.5 EBF 13862, Commons Pool 1.3 Reporter: Marcos Sanz Fix For: 1.3 Attachments: KeyedCPDSConnectionFactory.java.diff Attached you'll find a patch that improves the recovery of the class in different error situations. 1. The addition of removeConnectionEventListener() in destroyObject() ensures that the listener is removed, which is not guaranteed to have happened upon call of destroyObject(). We are for sure not interested any more in events, since we are about to destroy. 2. The same addition is made to connectionClosed(). Additionally, we have substituted there the call to destroyObject() with a call to pool.invalidateObject(). This is necessary because otherwise the object is destroyed but not removed from the pool. 3. The same substitution is made in connectionErrorOccurred(), otherwise the object might remain in the pool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (IO-109) FileSystemUtils freeSpaceUnix does not work for HP-UX 11
[
https://issues.apache.org/jira/browse/IO-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated IO-109:
-
Fix Version/s: 1.4
Marking these as 1.4 fix versions - not that we'll have any access to said
platforms so it's more a question of cleaning these issues up if we don't hear
back by the time of 1.4.
FileSystemUtils freeSpaceUnix does not work for HP-UX 11
Key: IO-109
URL: https://issues.apache.org/jira/browse/IO-109
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 1.2
Environment: uname -a
HP-UX mbfwdv B.11.11 U 9000/800 3509210950 unlimited-user license
Reporter: Christopher Olsen
Fix For: 1.4
Attachments: FileSystemUtils-HP-UX.fix
The freeSpaceUnix method does not work under HP-UX. The df command under
HP-UX is the old System V varient and the fields are not in the correct
order. This diff modifies the code to use the 'bdf' command when HP-UX is
detected:
--- FileSystemUtils.java2006-03-19 12:42:48.0 -0800
+++ FileSystemUtils-HP-UX-Fix.java 2007-01-11 13:05:34.844269000 -0800
@@ -51,13 +51,15 @@
private static final int WINDOWS = 1;
/** Operating system state flag for Unix. */
private static final int UNIX = 2;
+/** Unix variant name */
+ private static String osName = null;
/** The operating system flag. */
private static final int OS;
static {
int os = OTHER;
try {
-String osName = System.getProperty(os.name);
+osName = System.getProperty(os.name);
if (osName == null) {
throw new IOException(os.name not found);
}
@@ -287,9 +289,18 @@
}
path = FilenameUtils.normalize(path);
+ // HP-UX sucks we need to use bdf instead
+ String dfCmd = df;
+ String dfOpts = -k;
+ if (osName.indexOf(hp-ux) != -1)
+ {
+ dfCmd = bdf;
+ dfOpts = ;
+ }
+
// build and run the 'dir' command
String[] cmdAttribs =
-(kb ? new String[] {df, -k, path} : new String[] {df,
path});
+(kb ? new String[] {dfCmd, dfOpts, path} : new String[] {dfCmd,
path});
// read the output from the command until we come to the second line
long bytes = -1;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-217) Closing of underlaying connection instead of the PoolGuardConnectionWrapper
[ https://issues.apache.org/jira/browse/DBCP-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated DBCP-217: --- Fix Version/s: 1.3 Closing of underlaying connection instead of the PoolGuardConnectionWrapper --- Key: DBCP-217 URL: https://issues.apache.org/jira/browse/DBCP-217 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.2 Reporter: Sebastian Mancke Fix For: 1.3 Attachments: connectionCloseFix.patch Is state: If I obtain the Connection of a Statement (stmt.getConnection()), created with dbcp, the returned Object is the underlaying pooled connection. Closing this connection multiple times may close the connection of another process. It should be: The Wrapper over the connection PoolGuardConnectionWrapper should be returned instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CLI-126) CLI2 should support multiple property args on command line
[ https://issues.apache.org/jira/browse/CLI-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated CLI-126: -- Fix Version/s: 2.1 I know it's 6 months later - but I'm sure it would help this issue if you can attach your workaround Sanjay. CLI2 should support multiple property args on command line -- Key: CLI-126 URL: https://issues.apache.org/jira/browse/CLI-126 Project: Commons CLI Issue Type: Improvement Components: CLI-2.x Affects Versions: 2.0 Reporter: Sanjay Dahiya Fix For: 2.1 If I specify a command line like -Dsomekey=value1 -Xsomekey=value2, after parsing the value of somekey is overwritten as WritableCommandLine maintains a single set for all properties irrespective of switch. There should be a way of handling this case. CommandLine should probably return a set of all the switches from which we get properties. comments? I can submit a patch for this if its ok to make this change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-240) MultiValueMap should implement Serializable
[ https://issues.apache.org/jira/browse/COLLECTIONS-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated COLLECTIONS-240: -- Fix Version/s: 3.3 +1 MultiValueMap should implement Serializable --- Key: COLLECTIONS-240 URL: https://issues.apache.org/jira/browse/COLLECTIONS-240 Project: Commons Collections Issue Type: Bug Components: Map Affects Versions: 3.2 Reporter: Wouter de Vaal Fix For: 3.3 Collection classes should be serializable as they are frequently used in model classes which need to be serializable, for example in a HttpSession object within a servlet container cluster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-221) CompositeCollection, CompositeMap, CompositeSet should implement Serializable
[ https://issues.apache.org/jira/browse/COLLECTIONS-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated COLLECTIONS-221: -- Fix Version/s: 3.3 +1 CompositeCollection, CompositeMap, CompositeSet should implement Serializable - Key: COLLECTIONS-221 URL: https://issues.apache.org/jira/browse/COLLECTIONS-221 Project: Commons Collections Issue Type: Bug Components: Collection, Map, Set Affects Versions: 3.2 Reporter: Pal Denes Priority: Minor Fix For: 3.3 These classes should implement Serializable as usually all generial collection classes do. (At least I cannot think of a reason why they shouldn't and currently their usage is quite limited, like in RMI or http-sessions.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-233) Closure is an inaccurate name
[
https://issues.apache.org/jira/browse/COLLECTIONS-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated COLLECTIONS-233:
--
Affects Version/s: (was: Generics)
Fix Version/s: Generics
Given that Java will be giving us Closures at some point in the future, it does
seem that the Generics version of Collections should consider changing the
name. Switching 'Generics' from affects version to fix version.
Closure is an inaccurate name
-
Key: COLLECTIONS-233
URL: https://issues.apache.org/jira/browse/COLLECTIONS-233
Project: Commons Collections
Issue Type: Improvement
Components: Collection
Reporter: Stephen Kestle
Fix For: Generics
The Closure in commons collections is not named well: for non-functional
programmers it will induce a what's that?, and for functional programmers
it will confuse expectations.
From http://en.wikipedia.org/wiki/Closure_(computer_science):
A closure combines the code of a function with a special lexical environment
bound to that function (scope).
Java cannot pass functions, so the only way this can be done is with an
(inner) class, as follows (also from wikipedia):
class CalculationWindow extends JFrame {
private JButton btnSave;
...
public final calculateInSeparateThread(final URI uri) {
// The expression new Runnable() { ... } is an anonymous class.
Runnable runner = new Runnable() {
void run() {
// It can access final local variables:
calculate(uri);
// It can access private fields of the enclosing class:
btnSave.setEnabled(true);
}
};
new Thread(runner).start();
}
}
Note how the Runnable accesses the btnSave variable in the function scope.
This special lexical environment is NOT the same as passing a parameter
through a constructor OR execute method. A Closure should NOT take a
parameter for execute. It is not actually possible to have a Closure
object, as that breaks the lexical environment.
So, what to do?
I would propose an interface called Processor. It is more intuitive and has
many real world examples that can anchor the term so that it makes sense to
the average programmer.
For example, when applying for a passport, some documentation needs to be
filled out, and then it will go through a process to get you a passport. You
hand (or send) your forms to a clerk (Processor), and that's it. The
Processor does not reply - the context that is passed in your form (your
details) allows a message to be sent back at a later date.
For backwards compatibility the interface would be
public interface ProcessorT extends ClosureT{}
with the appropriate documentation. Closure would be deprecated with an
appropriate explanation.
However, it may be acceptable with the new version just to do a rename.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-220) Serialization/Deserialization doesn't work well with empty buffers.
[
https://issues.apache.org/jira/browse/COLLECTIONS-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated COLLECTIONS-220:
--
Fix Version/s: 3.3
Nice simple patch. +1.
Serialization/Deserialization doesn't work well with empty buffers.
---
Key: COLLECTIONS-220
URL: https://issues.apache.org/jira/browse/COLLECTIONS-220
Project: Commons Collections
Issue Type: Bug
Components: Buffer
Affects Versions: 3.2
Reporter: Jose Luis Huertas
Priority: Minor
Fix For: 3.3
Attachments: COLLECTIONS-200.patch, SerializationTest.java
When I serialize the queue to disk an it has elements, all works ok, but when
I serialize an empty queue I have some problems when I create a new object
using the serialized file.
When I deserialize the queue it has a 'buffer' with size 1 (with null
content), 'tail' and 'head' fields are 0 (they are declared transient). So,
when I try to add a new object to the queue, the sentence:
Object[] tmp = new Object[((buffer.length - 1) * 2) + 1];
Is executed in the add() method to increase the buffer length, but the buffer
remains with the same size! (buffer.length = 1 -- (1 - 1) * 2 + 1 = 1). So,
the object is added and when the tail is going to be incremented, it is reset
to 0!!
private int increment(int index) {
index++;
if (index = buffer.length) {
index = 0;
}
return index;
}
So it is impossible to add new elements after an empty queue has been
serialized / deserialized.
I attach a simple TestCase where this is proved. The example works when you
use XMLEncoder to serialize the buffer but doesn't work if you use
ObjectOutputStream or XStream.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-231) Not return the base interface on decorate
[ https://issues.apache.org/jira/browse/COLLECTIONS-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated COLLECTIONS-231: -- Fix Version/s: 3.3 Makes sense to me. Not return the base interface on decorate - Key: COLLECTIONS-231 URL: https://issues.apache.org/jira/browse/COLLECTIONS-231 Project: Commons Collections Issue Type: Improvement Components: Map Affects Versions: 3.2 Reporter: Torsten Curdt Fix For: 3.3 At the moment I don't see a reason why the static decorate method does not return ListOrderedMap but just the base interface OrderedMap. I want to decorate a Map to be a ListOrderedMap but due to the fact that the constructor is not visible and decorate only returns the base interface OrderedMap an unnecessary cast is required. ListOrderedMap map = (ListOrderedMap)ListOrderedMap.decorate(new MyMap()); As the decorate method is static and not part of any interface it should be fine to return the real type instead of the base. Otherwise I'd suggest to make the constructor visible. From the API POV It is not really understandable why this ListOrderedMap map = new ListOrderedMap(); is fine and creates a HashMap under the hood while this ListOrderedMap map = new ListOrderedMap(new MyMap())); is not ok. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-235) Missing static int ListUtils.indexOf(List,Predicate) method
[ https://issues.apache.org/jira/browse/COLLECTIONS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated COLLECTIONS-235: -- Fix Version/s: 3.3 +1 for 3.3 consideration. Missing static int ListUtils.indexOf(List,Predicate) method --- Key: COLLECTIONS-235 URL: https://issues.apache.org/jira/browse/COLLECTIONS-235 Project: Commons Collections Issue Type: New Feature Affects Versions: 3.2 Reporter: Nathan Egge Fix For: 3.3 Attachments: COLLECTIONS-235.patch Similar to this method on CollectionUtils: public static Object find(Collection c,Predicate p) there should be the following method on ListUtils: public static int indexOf(List l,Predicate p) which returns the index of the first Object in the List where the Predicate evaluates true. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r534976 - in /jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections: ./ buffer/ collection/ list/ map/
Author: bayard
Date: Thu May 3 12:54:44 2007
New Revision: 534976
URL: http://svn.apache.org/viewvc?view=revrev=534976
Log:
Applying Mark Hindess' patch from COLLECTIONS-232 that cleans up the ordering
of various assertEquals to be expected,actual and not actual,expected and also
fixes various assertEquals to assertNulls where applicable
Modified:
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestArrayList.java
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestArrayStack.java
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestCollectionUtils.java
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestExtendedProperties.java
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestMapUtils.java
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestTreeMap.java
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/buffer/TestPredicatedBuffer.java
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/collection/AbstractTestCollection.java
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/collection/TestCompositeCollection.java
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/list/AbstractTestList.java
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/map/AbstractTestMap.java
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/map/TestCaseInsensitiveMap.java
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/map/TestLazySortedMap.java
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/map/TestPredicatedSortedMap.java
Modified:
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestArrayList.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestArrayList.java?view=diffrev=534976r1=534975r2=534976
==
---
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestArrayList.java
(original)
+++
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestArrayList.java
Thu May 3 12:54:44 2007
@@ -54,7 +54,7 @@
//---
public void testNewArrayList() {
assertTrue(New list is empty, list.isEmpty());
-assertEquals(New list has size zero, list.size(), 0);
+assertEquals(New list has size zero, 0, list.size());
try {
list.get(1);
@@ -67,8 +67,8 @@
public void testSearch() {
list.add(First Item);
list.add(Last Item);
-assertEquals(First item is 'First Item', list.get(0), First Item);
-assertEquals(Last Item is 'Last Item', list.get(1), Last Item);
+assertEquals(First item is 'First Item', First Item, list.get(0));
+assertEquals(Last Item is 'Last Item', Last Item, list.get(1));
}
}
Modified:
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestArrayStack.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestArrayStack.java?view=diffrev=534976r1=534975r2=534976
==
---
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestArrayStack.java
(original)
+++
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/TestArrayStack.java
Thu May 3 12:54:44 2007
@@ -58,7 +58,7 @@
public void testNewStack() {
assertTrue(New stack is empty, stack.empty());
-assertEquals(New stack has size zero, stack.size(), 0);
+assertEquals(New stack has size zero, 0, stack.size());
try {
stack.peek();
@@ -80,26 +80,26 @@
stack.push(First Item);
assertTrue(Stack is not empty, !stack.empty());
-assertEquals(Stack size is one, stack.size(), 1);
+assertEquals(Stack size is one, 1, stack.size());
assertEquals(Top item is 'First Item',
- (String) stack.peek(), First Item);
-assertEquals(Stack size is one, stack.size(), 1);
+ First Item, (String) stack.peek());
+assertEquals(Stack size is one, 1, stack.size());
stack.push(Second Item);
-assertEquals(Stack size is two, stack.size(), 2);
+assertEquals(Stack size is two, 2, stack.size());
assertEquals(Top item is 'Second Item',
- (String) stack.peek(),
[jira] Closed: (COLLECTIONS-232) Some tests contain assertEquals arguments in the incorrect order
[ https://issues.apache.org/jira/browse/COLLECTIONS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed COLLECTIONS-232. - Resolution: Fixed Thanks Mark, patch applied. svn ci -m Applying Mark Hindess' patch from COLLECTIONS-232 that cleans up the ordering of various assertEquals to be expected,actual and not actual,expected and also fixes various assertEquals to assertNulls where applicable src/ Sendingsrc/test/org/apache/commons/collections/TestArrayList.java Sendingsrc/test/org/apache/commons/collections/TestArrayStack.java Sendingsrc/test/org/apache/commons/collections/TestCollectionUtils.java Sending src/test/org/apache/commons/collections/TestExtendedProperties.java Sendingsrc/test/org/apache/commons/collections/TestMapUtils.java Sendingsrc/test/org/apache/commons/collections/TestTreeMap.java Sending src/test/org/apache/commons/collections/buffer/TestPredicatedBuffer.java Sending src/test/org/apache/commons/collections/collection/AbstractTestCollection.java Sending src/test/org/apache/commons/collections/collection/TestCompositeCollection.java Sending src/test/org/apache/commons/collections/list/AbstractTestList.java Sendingsrc/test/org/apache/commons/collections/map/AbstractTestMap.java Sending src/test/org/apache/commons/collections/map/TestCaseInsensitiveMap.java Sending src/test/org/apache/commons/collections/map/TestLazySortedMap.java Sending src/test/org/apache/commons/collections/map/TestPredicatedSortedMap.java Transmitting file data .. Committed revision 534976. Some tests contain assertEquals arguments in the incorrect order Key: COLLECTIONS-232 URL: https://issues.apache.org/jira/browse/COLLECTIONS-232 Project: Commons Collections Issue Type: Improvement Reporter: Mark Hindess Priority: Trivial Fix For: 3.3 Attachments: fix.assertEquals.usage.diff A few tests have the expected and actual arguments to assertEquals in the wrong order. This can lead to very confusing failure messages. I'll attach a patch to fix some of the more obvious ones. I've also replaced a couple of assertTrue(blah.size() == 0) with assertEquals(0, blah.size()) since the later typically gives a more helpful failure message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-231) Not return the base interface on decorate
[ https://issues.apache.org/jira/browse/COLLECTIONS-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493501 ] Stephen Colebourne commented on COLLECTIONS-231: This change cannot be made as changing the return type is binary incompatible. The constructor is not public as it has a different meaning to a constructor taking a map on a HashMap (decorate vs copy). Not return the base interface on decorate - Key: COLLECTIONS-231 URL: https://issues.apache.org/jira/browse/COLLECTIONS-231 Project: Commons Collections Issue Type: Improvement Components: Map Affects Versions: 3.2 Reporter: Torsten Curdt Fix For: 3.3 At the moment I don't see a reason why the static decorate method does not return ListOrderedMap but just the base interface OrderedMap. I want to decorate a Map to be a ListOrderedMap but due to the fact that the constructor is not visible and decorate only returns the base interface OrderedMap an unnecessary cast is required. ListOrderedMap map = (ListOrderedMap)ListOrderedMap.decorate(new MyMap()); As the decorate method is static and not part of any interface it should be fine to return the real type instead of the base. Otherwise I'd suggest to make the constructor visible. From the API POV It is not really understandable why this ListOrderedMap map = new ListOrderedMap(); is fine and creates a HashMap under the hood while this ListOrderedMap map = new ListOrderedMap(new MyMap())); is not ok. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (IO-110) FileSystemUtils.freeSpaceKb does not work on AIX
[ https://issues.apache.org/jira/browse/IO-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nagarajan Ragunathan closed IO-110. --- Resolution: Fixed Fix Version/s: (was: 1.4) 1.3.1 it works. FileSystemUtils.freeSpaceKb does not work on AIX - Key: IO-110 URL: https://issues.apache.org/jira/browse/IO-110 Project: Commons IO Issue Type: Bug Affects Versions: 1.2 Environment: AIX operating system version 5.3 $ uname AIX $ oslevel -r 5300-04 Reporter: Nagarajan Ragunathan Fix For: 1.3.1 FileSystemUtils.freeSpaceKb does not work on AIX. Throws IOException . It is due to the format of 'df -k' output on AIX Operating System. $ df -k / Filesystem1024-blocks Free %UsedIused %Iused Mounted on /dev/hd4 262144168324 36% 391610% / Note the fourth entry is %Used. 'df -kt' command provides the format expected by freeSpaceKb method. $ df -kt / Filesystem1024-blocks Used Free %Used Mounted on /dev/hd4 262144 93820168324 36% / So, for AIX operating system, change it to use 'df -kt ' instead of df -k -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-231) Not return the base interface on decorate
[ https://issues.apache.org/jira/browse/COLLECTIONS-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493527 ] Stephen Kestle commented on COLLECTIONS-231: So - fix for generics? Not return the base interface on decorate - Key: COLLECTIONS-231 URL: https://issues.apache.org/jira/browse/COLLECTIONS-231 Project: Commons Collections Issue Type: Improvement Components: Map Affects Versions: 3.2 Reporter: Torsten Curdt Fix For: 3.3 At the moment I don't see a reason why the static decorate method does not return ListOrderedMap but just the base interface OrderedMap. I want to decorate a Map to be a ListOrderedMap but due to the fact that the constructor is not visible and decorate only returns the base interface OrderedMap an unnecessary cast is required. ListOrderedMap map = (ListOrderedMap)ListOrderedMap.decorate(new MyMap()); As the decorate method is static and not part of any interface it should be fine to return the real type instead of the base. Otherwise I'd suggest to make the constructor visible. From the API POV It is not really understandable why this ListOrderedMap map = new ListOrderedMap(); is fine and creates a HashMap under the hood while this ListOrderedMap map = new ListOrderedMap(new MyMap())); is not ok. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
