DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25818.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25818.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On 30-Dec-03, at 22:08 Uhr, Phil Steitz wrote:
David Graham wrote:
There will always be users that will complain when changing Java
versions.
The only semi-valid reason I've heard to not upgrade to 1.4 is that
product X requires 1.3 and product X is expensive.
Where often Product X is a
Howdy,
With a bunch of +1s and no other votes, congrats Bill ;) The voting
thread is archived here:
http://marc.theaimsgroup.com/?l=jakarta-commons-devm=107279251613063w=
2. I believe the account and karma are already all set, this email is
just a formality.
Happy new year to all ;)
Yoav
Shapira, Yoav wrote:
Howdy,
Here is a recent TSS survey of J2EE containers that shows jdk levels
supported by different containers:
http://www.theserverside.com/reviews/matrix.jsp
Please be careful when relying on these -- for example, it doesn't have
tomcat 5. ;) I wish there was some sort
In message [EMAIL PROTECTED], Steve Cohen writes:
But what about my point that what we have now is NOT 1.1 compatible?
VMSFTPEntryParser broke that, although it could, if necessary, be
reimplemented to use Hashtable instead of HashMap.
I misread your email (unfortunately an increasingly common
In message [EMAIL PROTECTED], Geir Magnusson
Jr writes:
Don't forget that not all platforms have 1.4 or a mature 1.4 that
people trust. it too a while for apple to get 1.4 out to OS X - I
wouldn't use OS X in production of course, but it's my development
platform...
Absolutely. J2SE 1.4
Actually It seems that the URL should not contain port 8080 in it.
http://nagoya.apache.org/scarab/issues/id/JAKA22
The attachment seems to be missing there and I seem to not have the correct
role to change my ticket :-(
My problem is very simple in fact.
When we process a directory with a
This makes a lot of sense, Daniel, and as long as I stay unemployed, I will
even have time to devote to the project :-)
I am not completely CVS-literate and setting up the branches is beyond my
current level of experience but probably would be good experience for me.
I am working now on a
Without seeing your code, just from your description, it sounds to me as if
the problem is not with the HashMap itself but with the way equals() is
written in the class of the objects you are storing in the HashMap. What is
that class?
The contract between equals() and hashCode() states that
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25818.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I like the idea of supporting older jvm versions while moving forward
with new development. I would suggest we do the branching slightly
different than you have described. I've found that keeping normal
development happening on the HEAD branch to be more beneficial than an
experimental branch.
Currently BeanComparator will fall over on a null, as
'testCompareWithNulls' unit test shows.
Is there a lot of objection to making it more user friendly and making it
wrap NullComparator instead of ComparableComparator so that nulls do not
break?
[NullComparator wraps ComparableComparator by
I know that some have objected to this in the past, but I think this is a
good idea.
I think that BeanComparator should work with nulls
out-of-the-box the question arises - are nulls first or last? There is
an old issue that deals with this:
Dunno. If I supply my own Comparator to BeanComparator, I think it's up to
me as to whether it blows up. No magic.
For the first/last question, it's easy. Use whathever NullComparator does
by default. Someone is always free to specify NullComparator(true) as a
comparator to beancomparator.
Or
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25849.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
ggregory2003/12/31 14:01:06
Modified:lang/src/test/org/apache/commons/lang SystemUtilsTest.java
Log:
PR: http://issues.apache.org/bugzilla/show_bug.cgi?id=25849
Added to SystemUtils: getJavaHome, getJavaIoTmpDir, getUserDir, getUserHome.
Sorted source (Eclispe).
Revision
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25849.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I've found that keeping normal development happening on the
HEAD branch to be more beneficial than an experimental
branch. We would branch for bug fixes only, all new
development proceeds on HEAD.
If projects start moving to Subversion, which will start happening next year
anyway, these
In message [EMAIL PROTECTED], Jeffrey D. Brekke writes:
After we make a 1.1 compatible release and tag, that will be the
branch point for any 1.1 fixes. Next we can make a release with 1.2
support and tag, that will be the branch point for any 1.2 related
fixes. All development then proceeds on
I wrote:
In message [EMAIL PROTECTED], Jeffrey D. Brekke writes:
Its just a suggestion. I can live with an experimental branch also,
just in other projects I've been involved with, if HEAD isn't the
focal point of new development, it get confusing where to put stuff,
what is working, etc.
I
In message [EMAIL PROTECTED], steve cohen writes:
I am not completely CVS-literate and setting up the branches is beyond my
current level of experience but probably would be good experience for me.
In my response to Jeffrey's email, I asked about whether we wanted to
replace the existing
I wrote:
Sanity check the steps to make sure this is what we want:
o rename NET_1_1_0 tag to something else, let's say FOO
o tag FOO as NET_1_1_0, this time with the -b flag to make it a branch tag
I left out delete the FOO tag ...
If that seems like not a good thing, another option is to
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24327.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi everybody :)
and first of all, I wish you all an happy new year :))
and now is my question/remark (i don't know if it's better to post it here, or in the
user mailing list, or as a comment in bugzilla, but I don't want to cross post, so for
now I post it only here - let me know if I should
We ran into the same problem (and used the same temporary workaround). It
seems to me that HttpAuthenticator.selectAuthScheme should take into account
the credentials that are available, skipping authentications schemes without
credentials. In your case, since you only provided
When attempting to run the example source code at the bottom of
http://jakarta.apache.org/commons/httpclient/tutorial.html within
JRun/ColdFusion MX, I get the following error:
[1]org.apache.commons.logging.LogConfigurationException:
java.lang.ClassCastException
at
Chris,
Looks suspiciously like a ClassLoader problem, and not directly related
to HttpClient. I suggest looking on the net for compatibility issues
with JRun/ColdFusion MX and commons-logging.
Also see the logging instructions for HttpClient here:
28 matches
Mail list logo
