Dears,
I have a User bean with java.util.Set property.
I create a struts form with a list to select multiple values from and then
store them in the set.
I am getting this exception:
java.lang.IllegalArgumentException: Cannot invoke
com.myapp.struts.User.setValues - argument type mismatch
---
Hi Kris,
Kris Nuttycombe wrote on Tuesday, October 24, 2006 5:10 PM:
(Compare this with the JDK where they had to jump through ridiculous
hoops to make generics fully backwards-compatible, and created a
half-arsed mess in the process...)
This is the real problem. We must use a different
For someone who uses Commons Collections a lot in their applications, this
is going to be quite a pain if I want to upgrade. Yes, I realize that
there's such a thing as find and replace, but the fact that I have to do
that if I want to upgrade is just a bother. That's my $0.02.
On 10/25/06,
M$ FTP Virtual Folder support
-
Key: VFS-97
URL: http://issues.apache.org/jira/browse/VFS-97
Project: Commons VFS
Issue Type: New Feature
Affects Versions: 1.1 Final
Environment: current CVS version,
[ http://issues.apache.org/jira/browse/VFS-97?page=all ]
Sergey Vladimirov updated VFS-97:
-
Attachment: patch.txt
patch-testcase.txt
M$ FTP Virtual Folder support
-
Key: VFS-97
[ http://issues.apache.org/jira/browse/VFS-97?page=comments#action_12444637
]
Sergey Vladimirov commented on VFS-97:
--
In ideal case there is should be mount point of another fylesystem, i.e.
virtual direcotry should be considered as root
James Carman wrote on Wednesday, October 25, 2006 11:50 AM:
For someone who uses Commons Collections a lot in their
applications, this
is going to be quite a pain if I want to upgrade. Yes, I realize that
there's such a thing as find and replace, but the fact that I
have to do
that if I
[ http://issues.apache.org/jira/browse/VFS-90?page=all ]
Elifarley Callado Coelho updated VFS-90:
Attachment: RACRandomAccessFile.java.bz2
The attached class encapsulates a RandomAccessContent instance, allowing it to
be used as a
Stephen Colebourne wrote:
Because commons isn't like other OSS projects. We can't go around
changing our APIs freely, even between major versions. Its a simple case
of us being at the bottom of the stack of jars. If we do change an API,
any API then jar hell ensues because higher OSS
Well, the number is dependent on the strategy we are trying to achieve:
a) using '4' would indicate that every major version will have a new package
name, but then you can't use a major version to just remove deprections (a
compatible major version change)
b) using '5' would indicate the
Mario Ivankovits wrote on Wednesday, October 25, 2006 3:03 PM:
Well, the number is dependent on the strategy we are trying to
achieve:
a) using '4' would indicate that every major version will
have a new package name, but then you can't use a major
version to just remove deprections (a
From: Mario Ivankovits [EMAIL PROTECTED]
Well, the number is dependent on the strategy we are trying to achieve:
a) using '4' would indicate that every major version will have a new
package name, but then you can't use a major version to just remove
deprections (a compatible major
Documentation - Dependencies - DefaultConfigurationBuilder needs commons-jxpath
---
Key: CONFIGURATION-234
URL: http://issues.apache.org/jira/browse/CONFIGURATION-234
Stephen Colebourne wrote:
From: Mario Ivankovits [EMAIL PROTECTED]
Well, the number is dependent on the strategy we are trying to achieve:
a) using '4' would indicate that every major version will have a new package
name, but then you can't use a major version to just remove deprections (a
On 10/21/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
Henri Yandell wrote:
Why not just start a branch within Collections?
I don't see why this is a new component, are we going to be advising
people to use Collections 3.x on JDK 1.5+ for any reasons other than
legacy or instability of
I don't like forking all of commons together. To say
commons5-collections-1.0 doesn't work for me. Then, we have to get all of
the commons projects to decide on fork points. Am I understanding (c)
correctly?
On 10/25/06, Kris Nuttycombe [EMAIL PROTECTED] wrote:
Stephen Colebourne wrote:
On 10/25/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
Well, the number is dependent on the strategy we are trying to achieve:
a) using '4' would indicate that every major version will have a new package
name, but then you can't use a major version to just remove deprections (a
compatible
James Carman wrote:
I don't like forking all of commons together. To say
commons5-collections-1.0 doesn't work for me. Then, we have to get
all of
the commons projects to decide on fork points. Am I understanding (c)
correctly?
I don't think there has to be commons-wide fork at all. I just
Perhaps you could expand on what the issues are with the JDK approach
and why they're not desirable in Commons Collections - when I look at
the differences for example between the generified and non-generified
versions of java.util.List, I don't see the mess you describe.
Yes, this is
From: Niall Pemberton [EMAIL PROTECTED]
From a simplistic user perspective seems to me that the compatibility
achieved by the JDK is successful. I don't understand the intricacies
required to generify a library, but if we could do the same wouldn't
this be the best solution from a user
[
http://issues.apache.org/jira/browse/LANG-284?page=comments#action_12444696 ]
David Leal commented on LANG-284:
-
Dear Henri,
About your comment, that is why I have provided two methods, the method that
returns String[][]
From: Kris Nuttycombe [EMAIL PROTECTED]
James Carman wrote:
I don't like forking all of commons together. To say
commons5-collections-1.0 doesn't work for me. Then, we have to get
all of
the commons projects to decide on fork points. Am I understanding (c)
correctly?
I don't think
I'm not sure we're optimizing for the right thing by changing the
package names and creating parralel forks for Generic Collections.
Generics have done a pretty good job of dealing with backwards
compatibility. It feels like we will make the upgrade path for the vast
majority of people more
Stephen Colebourne wrote:
The problem is erasure. The JDK wipes all knowledge of the type that you
connect to the collection. Thus
ListString list = new ArrayList();
if (list instanceof ListInteger) {
}
fails to compile as the String type is erased.
In order to preserve backwards
I agree on the latter point - that JSE5 is in some ways a complete shift
in Java paradigm. Whatever solution is chosen going forward, +1 for a
cross-Commons approach... otherwise figuring out compatibility between
Commons JARs will become even tougher.
I dislike the idea of putting version
(Ok - how bizarre - I sent this mail yesterday (2 days?), but it went
nowhere...)
Definitely. It's built to be as api compatible as possible with
collections, while upgrading to generics. It's also going through the
process of making it easier to use from a generics side of things
(doesn't
On Mon, 2006-10-23 at 22:50 -0700, Thomas Dudziak wrote:
On 10/23/06, robert burrell donkin [EMAIL PROTECTED] wrote:
barring unforeseen events, i should have time on tuesday and wednesday.
the infrastructure should all be back up by then.
great, thanks! Let me know how I can help!
there
Hello,
I'm having trouble understanding how to compile the commons-finder
package. I've checked out commons-io and commons-finder from SVN, and
I can compile io using ant, but finder doesn't have a build.xml.
Pardon my stupidity, but I'm a maven newbie and I don't really
understand the
Hi Joshua,
Maven's a very online tool - and the current snapshot repository is
down (drive failure) so things are not as easy as they should be.
To build things you want to:
svn -N co http://svn.apache.org/repos/asf/jakarta/commons/trunks-sandbox/
commons-sandbox
cd commons-sandbox
mvn install
On 10/25/06, robert burrell donkin [EMAIL PROTECTED] wrote:
On Mon, 2006-10-23 at 22:50 -0700, Thomas Dudziak wrote:
On 10/23/06, robert burrell donkin [EMAIL PROTECTED] wrote:
barring unforeseen events, i should have time on tuesday and wednesday.
the infrastructure should all be back up
On 10/25/06, Henri Yandell [EMAIL PROTECTED] wrote:
Delegate to get the ddlutils guys to do lots of it :)
Funny.
But seriously, I'll gladly help with any issues, just assign them to 0.8.
cheers,
Tom
-
To unsubscribe,
On Oct 25, 2006, at 4:48 PM, Henri Yandell wrote:
What are you looking for in Finder by the way? The latest IO contains
'DirectoryWalker' which is the guts of finder, so it's possible that
that might be all you want.
I need to be able to filter a directory recursively by filename and
On Oct 25, 2006, at 4:48 PM, Henri Yandell wrote:
svn -N co http://svn.apache.org/repos/asf/jakarta/commons/trunks-
sandbox/
commons-sandbox
cd commons-sandbox
mvn install
cd ..
The SVN checkout works fine, but the mvn compile is giving me the
same PSM 'org.apache.commons:commons' not
On 10/25/06, Joshua ChaitinPollak [EMAIL PROTECTED] wrote:
On Oct 25, 2006, at 4:48 PM, Henri Yandell wrote:
What are you looking for in Finder by the way? The latest IO contains
'DirectoryWalker' which is the guts of finder, so it's possible that
that might be all you want.
I need to be
On 10/25/06, Joshua ChaitinPollak [EMAIL PROTECTED] wrote:
On Oct 25, 2006, at 4:48 PM, Henri Yandell wrote:
svn -N co http://svn.apache.org/repos/asf/jakarta/commons/trunks-
sandbox/
commons-sandbox
cd commons-sandbox
mvn install
cd ..
The SVN checkout works fine, but the mvn compile
On 10/25/06, Joshua ChaitinPollak [EMAIL PROTECTED] wrote:
On Oct 25, 2006, at 4:48 PM, Henri Yandell wrote:
svn -N co http://svn.apache.org/repos/asf/jakarta/commons/trunks-
sandbox/
commons-sandbox
cd commons-sandbox
mvn install
cd ..
The SVN checkout works fine, but the mvn compile
On Oct 25, 2006, at 6:04 PM, Niall Pemberton wrote:
As Henry said, sounds like DirectoryWalker (in Commons IO) should meet
your needs:
http://tinyurl.com/y8wxcb
Yup, I just build the commons-io jar and javadoc and was reading the
examples, this should be perfect, thanks.
Thanks for
Will Pugh wrote:
I'm not sure we're optimizing for the right thing by changing the
package names and creating parralel forks for Generic Collections.
Generics have done a pretty good job of dealing with backwards
compatibility. It feels like we will make the upgrade path for the vast
On 10/25/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
From: Niall Pemberton [EMAIL PROTECTED]
From a simplistic user perspective seems to me that the compatibility
achieved by the JDK is successful. I don't understand the intricacies
required to generify a library, but if we could do the
I for one would like to see the getInstance() methods renamed to
getClassName(). With java 5 static importing, it enables concise
construction/getting without specifying the class name. It's short,
highly readable, and most of the time the generic types can be inferred.
It's things like
On 10/25/06, Niall Pemberton [EMAIL PROTECTED] wrote:
snip/
Having said that, its not me thats going to be doing the work, but it
does seem valuable to discuss port vs. refactor rather than refactor
being a defacto decission and just having an argument on package
names.
snap/
:-)
Its not
Author: martinc
Date: Wed Oct 25 21:27:59 2006
New Revision: 467859
URL: http://svn.apache.org/viewvc?view=revrev=467859
Log:
Minor optimizations.
Modified:
jakarta/commons/sandbox/js2j/trunk/src/main/java/org/apache/commons/js2j/FileExtensions.java
42 matches
Mail list logo
