RE: FW: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2

[Gary Gregory]

Hello Steven and All:

Here is a fix for build problems on Sun Java 1.3.1 and 1.2.2.

Instead of using this odd way of invoking unit tests:









I changed this target on my machine to the more standard JUnit
invocation:









The test passed on 1.4.2_08, 1.3.1_14 and 1.2.2_017.

Shall I (or Steven) change the JUnit invocation style for all tests?

Gary

-Original Message-
From: Simon Kitching [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 26, 2005 9:07 PM
To: Jakarta Commons Developers List
Subject: Re: FW: [lang] DateUtils test fails under 1.2.2 and not under
1.4.2

On Thu, 2005-05-26 at 20:05 -0400, Steven Caswell wrote:
> That is so very odd. I'm at a loss to explain it. I don't have access
to a 
> system with JDK 1.3 so I'm not able to try it. Maybe someone else can
try?

I've also tried building with JDK1.2.2 on linux.

I got this as part of the output
   [java] Java 1.3 tests not run since the current version is 1.2.2
and also got the DateUtilsTest.testRound failure.

No other problems were encountered.

If Gary is running tests on Windows, then his problem might indicate a
windows-specific issue. Otherwise it looks to me like a system-specific
problem with Gary's setup.

Regards,

Simon




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34819] - [digester] NodeCreateRule Failing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34819





--- Additional Comments From [EMAIL PROTECTED]  2005-05-27 07:51 ---
(In reply to comment #7)
> Both assertions fail because ((Element)element).getLocalName() is "alpha", not
> null. I haven't yet figured out if this is OK or a bug in gnu classpath...

When xml namespaces are enabled, there are two parts to an element name: 
  namespaceURI and localname (eg "http://acme.com/ns";, "item")

When xml namespaces are disabled, there is one part to an element name:
   qname  (eg "ns:item")

Quite what localname should be when namespaces are disabled, or what qname
should be when namespaces are enabled is very ambiguous in the javadoc for
sax/dom at least. I suspect that Xerces reports NULL for qname when namespaces
are enabled, and NULL for localname when namespaces are disabled, while Aelfred
populates qname even when namespaces are disabled (reasonable) and populates
localname even when namespaces are enabled. Which XML parser is actually
complying with the SAX/DOM specs I don't know. Or whether the specs don't say
anything on this issue, in which case we should not be asserting one way or the
other.

And quite how localname/qname map to the DOM "NodeName" isn't clear from the
javadoc at least.

Writing a simple test harness and running it with Aelfred and Xerces should show
if this is the cause. Then we would have to figure out whether one of the
parsers was actually non-compliant with the specs. And if so, whether we should
try to "fix" the data the parser is reporting in NodeCreateRule or not. All
looks like a fair bit of work.

But the fact that those are the only test failures on kaffe/gnu-classpath is
great! [esp. as they might just be over-zealous asserts anyway, if the relevant
specs allow localname to be set when namespaces are enabled etc].


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35096] - [Digester][PATCH] Cannot add multiple CallMethodRules for the same pattern

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35096





--- Additional Comments From [EMAIL PROTECTED]  2005-05-27 07:32 ---
Hi Rahul,

Thanks very much for offering a patch for this. It is always good to see people
offering solutions rather than just problems :-).

I do have some concerns about this approach though, that mean I personally would
prefer not to see this patch committed as-is. If you wished to work on it some
more, I'd be happy to help. However CallMethodRule has acted this way since the
very first release, so I don't see it being worthwhile to delay the next release
to get this in. 

Of course others may see it differently; if any other digester committers are
listening, please speak up!

As I note below, a user rule should be able to do anything a built-in rule can.
So if this problem is solvable, then it should be solvable via a bunch of new
Rule classes that can be downloaded separate from the commons-digester release.
That would be a good thing I think as people can use them and give feedback
before the new functionality becomes part of the digester core. I think it quite
feasable to put such "extras" code up on the apache site somewhere for people to
download.


The concept of a stack of arrays was, I think, rather ugly in the first place.
Extending this by having a stack of lists of arrays isn't, in my opinion, the
way to go.

And while it really will be necessary to somehow link CallParamRule objects to
their associated CallMethodRule I don't think using integer indexes are the
solution. It just feels clumsy.

Having any kind of rule treated "special" by the digester core is also
undesirable. It is much nicer to have a core that just provides generic rule
services, and then the rule classes are layered on top. Ok, apart from all those
factory methods that are also on the Digester class. Having this layering means
that a user rule can do anything that a built-in rule can. Currently this is
true, and I'd like to see it stay that way.

I was experimenting a while ago with the following:
* 
having an interface (MethodInvoker or somesuch name) that the CallMethodRule
implements.

*
having XXParamRule objects obtain the Rules object from the digester and iterate
over the list of Rule objects until they find themself. The immediately
preceding MethodInvoker rule object is then the one that they associate themself
with. This can be done when setDigester is called, ie once only.

* 
having the MethodInvoker interface define method
   setParameter(int i, Object value)
that the various ParamRule objects could then call, rather than directly
accessing a "parameter stack" data structure.

*
having each CallMethodRule (which implements MethodInvoker) manage its own stack
of parameter data. This could still be a stack of arrays internally, but it is
now a data structure private to the class, which is better than the current
paramstack object which is exposed everywhere.

The bit about XXParamRule classes scanning the list of rules to find the
previous CallMethodRule means that code like this:
  digester.addCallMethod();  // rule 1
  digester.addCallParam(...);   // automatically associates with rule 1
  digester.addCallMethod();  // rule 2
  digester.addCallParam(...);   // automatically associates with rule 2
works in an intuitive fashion. A CallParamRule associates with the most recently
added CallMethodRule.

None of this should need changes to the digester core as far as I can see; it
can all be done as "user" rules, though of course that means duplicating or
subclassing a number of rule classes, and not having digester Factory methods
available (unless digester is also subclassed).

Of course all this is just theory. Well, some of it has been implemented in a
Ruby version of the digester I did.

I haven't felt the enthusiasm to test out the idea, look for flaws, implement
it, add unit tests, etc. for digester 1.x series.

I certainly do intend to do *something* to address the existing CallMethodRule
issue though for the digester 2.x series. [which has no release date planned 
yet].

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35097] - [Digester][PATCH] Obtaining String class in CallMethodRule

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35097





--- Additional Comments From [EMAIL PROTECTED]  2005-05-27 06:26 ---
(In reply to comment #1)

> I think I would prefer to commit this change *after* the release
> rather than immediately before.

Please, take your time. I wouldn't want to introduce 0.01% doubt at this stage.

-Rahul


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35097] - [Digester][PATCH] Obtaining String class in CallMethodRule

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35097





--- Additional Comments From [EMAIL PROTECTED]  2005-05-27 06:15 ---
Yes, that existing code is a bit .. different. 

I'm 99.99% sure that your change is correct. But as there isn't anything
*actually wrong with the existing code, and we are (hopefully) just a few days
from a release, I think I would prefer to commit this change *after* the release
rather than immediately before.

Unless you can see a situation where String.class works and "abc".getClass()
does not?


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35097] New: - [Digester][PATCH] Obtaining String class in CallMethodRule

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35097

   Summary: [Digester][PATCH] Obtaining String class in
CallMethodRule
   Product: Commons
   Version: 1.6 Final
  Platform: Other
OS/Version: other
Status: NEW
  Severity: trivial
  Priority: P2
 Component: Digester
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Recent musings on the CallMethodRule code brought to my notice an interesting 
construct for obtaining the String class ;-)

Inlining a patch, since its trivial:

Index: CallMethodRule.java
===
RCS file: /usr/local/cvsroot/apache/patches/commons-digester-1.6-
src/src/java/org/apache/commons/digester/CallMethodRule.java,v
retrieving revision 1.1
diff -c -r1.1 CallMethodRule.java
*** CallMethodRule.java 27 May 2005 02:52:14 -  1.2
--- CallMethodRule.java 27 May 2005 03:21:23 -
***
262c262
< this.paramTypes[i] = "abc".getClass();
---
> this.paramTypes[i] = String.class;
330c330
< this.paramTypes[i] = "abc".getClass();
---
> this.paramTypes[i] = String.class;
503c503
< paramTypes[0] = "abc".getClass();
---
> paramTypes[0] = String.class;

-Rahul

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FW: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2

[Simon Kitching]

On Thu, 2005-05-26 at 20:05 -0400, Steven Caswell wrote:
> That is so very odd. I'm at a loss to explain it. I don't have access to a 
> system with JDK 1.3 so I'm not able to try it. Maybe someone else can try?

I've also tried building with JDK1.2.2 on linux.

I got this as part of the output
   [java] Java 1.3 tests not run since the current version is 1.2.2
and also got the DateUtilsTest.testRound failure.

No other problems were encountered.

If Gary is running tests on Windows, then his problem might indicate a
windows-specific issue. Otherwise it looks to me like a system-specific
problem with Gary's setup.

Regards,

Simon




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35096] - [Digester][PATCH] Cannot add multiple CallMethodRules for the same pattern

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35096





--- Additional Comments From [EMAIL PROTECTED]  2005-05-27 06:03 ---
Created an attachment (id=15181)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15181&action=view)
Patch for adding the ability to add multiple CallMethodRules for the same
pattern


Zip contains proposed patches for:

src/java/o/a/c/d/
  CallMethodRule.java
  CallParamRule.java
  Digester.java

src/test/o/a/c/d/  
  CallMethodRuleTestCase.java

-Rahul


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35096] New: - [Digester][PATCH] Cannot add multiple CallMethodRules for the same pattern

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35096

   Summary: [Digester][PATCH] Cannot add multiple CallMethodRules
for the same pattern
   Product: Commons
   Version: 1.6 Final
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Digester
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


ISSUE:
The issue is summarized here, URI might get fragmented, copy with care [ 
http://marc.theaimsgroup.com/?l=jakarta-commons-user&m=111706440425278&w=2 ]

PROPOSED SOLUTION:
Instead of storing an object array as an element of the parameters stack in 
Digester (which is utilized by CallMethodRule and CallParamRule rules), store 
a list of object arrays.

Add an index property to CallMethodRule corresponding to its document order 
(within CallMethodRules for the same pattern), and use that to access the 
appropriate element within the list at the top of the parameters stack.

The same index provides users the ability to associate a CallParamRule with 
the appropriate CallMethodRule.

Patch is attached in next post. Javadoc needs to be brushed up, I can do that 
depending on interest in the patch. Patch also contains updated call method 
rule test cases (one change in the 'testTwoCalls' test case), all 15 now pass. 

There is full backward compatibility. Comments/suggestions welcome.

-Rahul

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: FW: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2

[Gary Gregory]

Well, it is not a real solution, just a data point in finding out what
is wrong. I'll keep looking tomorrow.

 

Gary

 



From: Steven Caswell [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 26, 2005 6:02 PM
To: Gary Gregory
Cc: Jakarta Commons Developers List
Subject: Re: FW: [lang] DateUtils test fails under 1.2.2 and not under
1.4.2

 

Glad you found it.

On 5/26/05, Gary Gregory <[EMAIL PROTECTED]> wrote:

Hi:

 

I found possible solution. With 1.3.1, if I set fork to false, the test
is found and run. Weird. 

 

Gary 

 



From: Steven Caswell [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 26, 2005 5:06 PM
To: Gary Gregory
Cc: Jakarta Commons Developers List
Subject: Re: FW: [lang] DateUtils test fails under 1.2.2 and not under
1.4.2

 

That is so very odd. I'm at a loss to explain it. I don't have access to
a system with JDK 1.3 so I'm not able to try it. Maybe someone else can
try?

One thing I did find I needed to do was to change th junit version in
default.properties from 3.7 to 3.8.1. Gary, could you try making this
change and building under 1.3.1? I'm just curious to see if this makes a
difference, though I don't see why it should.

Thanks.

On 5/25/05, Gary Gregory <[EMAIL PROTECTED]> wrote:

Steven:

 

I updated from CVS today and got new build.xml. I still get the error
below on Sun Java 1.3.1_14.

 

Thanks,

Gary 

 



From: Gary Gregory 
Sent: Tuesday, May 24, 2005 7:12 PM
To: 'Steven Caswell'
Cc: Jakarta Commons Developers List
Subject: RE: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2

 

Steven:

 

(You're welcome.)

 

Downloaded RC6a-src and I am now experiencing Weirdness: I run "ant
clean dist-build-2.1 test" which works fine on Sun Java 1.4.2_08.

 

On Sun Java 1.3.1_14 I get:

 

test.lang:

 [echo] Running lang package tests ...

 [java] Class not found "org.apache.commons.lang.LangTestSuite"

 

BUILD FAILED

C:\temp\commons-lang-2.1-RC6\build.xml:166: Java returned: 1

 

Which makes no sense at first glance.

 

Gary 

 



From: Steven Caswell [mailto: [EMAIL PROTECTED] 
Sent: Tuesday, May 24, 2005 7:00 PM
To: Gary Gregory
Cc: Jakarta Commons Developers List
Subject: Re: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2

 

Gary,

I put up the revised source distribution in
http://www.apache.org/~stevencaswell/commons-lang-2.1
 

I named them commons-lang-2.1-RC6a-src.* so you could easily tell they
are modified. I was just too lazy to change it to RC7 for a minor
non-code fix, and since there will probably be an RC7 with the date
utils test change.

Thanks for your patience and thanks for testing these things.

On 5/24/05, Steven Caswell <[EMAIL PROTECTED] > wrote:

Gary,

I have a fix for that problem. I'll go ahead and put up a corrected
source distribution with the fix and without the DateUtilsTest
correction so you can try 1.3.1.

 

On 5/24/05, Gary Gregory <[EMAIL PROTECTED] > wrote:

I'd like to check 1.3.1 but... running "ant clean build-dist-2.1 test"
from src-zip does not make it past text tests:

test.text:
 [echo] Running text package tests ...
 [java] Class not found "
org.apache.commons.lang.text.TextTestSuite"

BUILD FAILED
C:\temp\commons-lang-2.1-RC6\build.xml:206: Java returned: 1

Which should not be run in the 1st place...

(Ant 1.6.4 and Java 1.4.2_08) 

Gary

-Original Message-
From: Steven Caswell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 24, 2005 5:39 PM
To: Jakarta Commons Developers List 
Subject: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2

All,

I have discovered a group of tests in the DateUtils test case that fails

under 1.2.2 but not under 1.4.2. They are testing the DateUtils round 
method
when rounding a date in the MET timezone across the start and end of
DST. If
I remember correctly, this was in response to a user bug report. In
particular the test is at line 472 of the testRound method in 
DataUtilsTest.java.

The test passes fine when run under 1.4.2 but fails under 1.2.2. I don't

have a 1.3 installation available so I don't know if it passes or fails
under 1.3.

I propose that we put a condition around the test so that is only run 
when
the Java version is 1.4, and add a note to the round method javadoc and
the
release notes stating that the round method may not work properly in all

cases involving DST rollovers in previous JVMs, with this case as an 
example.

Thoughs?

--
Steven Caswell
[EMAIL PROTECTED]

Take back the web - http://www.mozilla.org




-- 
Steven Caswell
[EMAIL PROTECTED]

Take back the web - http://www.mozilla.org 




-- 
Steven Caswell
[EMAIL PROTECTED]

Take back the web - http://www.mozilla.org 




-- 
Steven Caswell
[EMAIL PROTECTED]

Take back the web - http://www.mozilla.org 




-- 
Steven Caswell
[EMAIL PROTECTED]

Take back the web - http://www.moz

DO NOT REPLY [Bug 32859] - [net] TFTPClient's send file discards last ack

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32859





--- Additional Comments From [EMAIL PROTECTED]  2005-05-27 04:12 ---
It is true that sendFile doesn't wait for a final ack (probably because
it was thought at the time that we didn't want to hang if the final ack
got lost).  Therefore, a UDP packet may remain queued for delivery to
user space, causing a problem on subsequent read operation on the same
socket.  However, a call to TFTP.discardPackets is the appropriate
(although imperfect if the last ack is delayed) workaround until we get
more information about the problem.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r178726 - /jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/tftp/TFTPClient.java

[dfs]

Author: dfs
Date: Thu May 26 19:00:13 2005
New Revision: 178726

URL: http://svn.apache.org/viewcvs?rev=178726&view=rev
Log:
Backed out change made in r161466 in response to issue #32859,
effectively reverting to r155429.  The patch from the issue
reporter has no effect other than to break TFTPClient.sendFile by
removing a final packet send.  If a corrected patch and verifying
test case are submitted the change can be reapplied.

Modified:

jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/tftp/TFTPClient.java

Modified: 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/tftp/TFTPClient.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/tftp/TFTPClient.java?rev=178726&r1=178725&r2=178726&view=diff
==
--- 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/tftp/TFTPClient.java
 (original)
+++ 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/tftp/TFTPClient.java
 Thu May 26 19:00:13 2005
@@ -372,7 +372,6 @@
 
 dataLength = lastBlock = hostPort = bytesRead = 0;
 block = 0;
-boolean lastAckWait = false;
 
 if (mode == TFTP.ASCII_MODE)
 input = new ToNetASCIIInputStream(input);
@@ -456,10 +455,7 @@
 if (lastBlock == block)
 {
 ++block;
-if (lastAckWait)
-  break _sendPacket;
-else
-  break _receivePacket;
+break _receivePacket;
 }
 else
 {
@@ -505,8 +501,9 @@
 data.setData(_sendBuffer, 4, offset - 4);
 sent = data;
 }
-while (dataLength == 0 || lastAckWait);
+while (dataLength == 0);
 
+bufferedSend(sent);
 endBufferedOps();
 }
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32859] - [net] TFTPClient's send file discards last ack

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32859


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2005-05-27 03:49 ---
I concur with your assessment Michael.  I don't see what this patch does
other than break TFTPClient.sendFile.  Even if lastAckWait were true, the
method would go into an infinite loop at the end.  I'm going to revert the
change.

If the original issue reporter believes there is a bug in sendFile, then
we're going to need a test program that reproduces the bug.  Submitting
a patch with only anectdotal support for there being a problem is
insufficient.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FW: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2

[Steven Caswell]

Simon,

Thanks for the tests. Glad to hear 1.5 is clean.

I found the same errors with the DateUtilsTest and I've got a fix ready to 
check in. I was waiting until we resolved these other issues.

There is a tag for RC6 but not for the RC6a because I built it from the head 
and from a couple of local changes. I plan to build an RC7 with the test 
source and configuration fixes and cross my fingers that it will be the 
golden one.


On 5/26/05, Simon Kitching <[EMAIL PROTECTED]> wrote:
> 
> Hi,
> 
> 
> with lang/trunk:
> "maven clean test" works for me with java1.5 on linux
> "ant clean dist-build-2.1 test" works for me with java1.5 on linux
> 
> with the contents of file commons-lang-2.1-RC6a-src.tar.gz:
> "maven clean test" works for me with java1.5 on linux
> "ant clean dist-build-2.1 test" works for me with java1.5 on linux
> 
> I used junit-3.8.1 with ant.
> 
> 
> "maven clean test" on lang/trunk or with the download RC6a file fails
> with java1.3.1 on linux:
> [junit] Tests run: 40, Failures: 1, Errors: 0, Time elapsed: 4.995 sec
> [junit] [ERROR] TEST org.apache.commons.lang.time.TimeTestSuite FAILED
> 
> $ cat target/test-reports/
> TEST-org.apache.commons.lang.time.TimeTestSuite.txt
> 
> Testcase: testRound(org.apache.commons.lang.time.DateUtilsTest):
> FAILED
> round MET date across DST change-over expected: 2003> but was:
> junit.framework.AssertionFailedError: round MET date across DST
> change-over expected: but was: 02:00:00 IRST 2003>
> at
> org.apache.commons.lang.time.DateUtilsTest.testRound(DateUtilsTest.java
> :472)
> 
> $ java -version
> java version "1.3.1_14"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_14-b03)
> Java HotSpot(TM) Client VM (build 1.3.1_14-b03, mixed mode)
> 
> 
> I did not get the reported problem:
> > [java] Class not found "org.apache.commons.lang.LangTestSuite"
> 
> 
> 
> I don't see any RC6 directory under lang/tags. I presume the .tar.gz
> file on your site is actually from HEAD?
> 
> 
> 
> Regards,
> 
> Simon
> 
> On Thu, 2005-05-26 at 20:05 -0400, Steven Caswell wrote:
> > That is so very odd. I'm at a loss to explain it. I don't have access to 
> a
> > system with JDK 1.3 so I'm not able to try it. Maybe someone else can 
> try?
> >
> > One thing I did find I needed to do was to change th junit version in
> > default.properties from 3.7 to 3.8.1. Gary, could you try making this 
> change
> > and building under 1.3.1? I'm just curious to see if this makes a
> > difference, though I don't see why it should.
> >
> > Thanks.
> >
> > On 5/25/05, Gary Gregory <[EMAIL PROTECTED]> wrote:
> > >
> > > Steven:
> > >
> > > I updated from CVS today and got new build.xml. I still get the error
> > > below on Sun Java 1.3.1_14.
> > >
> > > Thanks,
> > >
> > > Gary
> > >
> > > --
> > >
> > > *From:* Gary Gregory
> > > *Sent:* Tuesday, May 24, 2005 7:12 PM
> > > *To:* 'Steven Caswell'
> > > *Cc:* Jakarta Commons Developers List
> > > *Subject:* RE: [lang] DateUtils test fails under 1.2.2 and not under 
> 1.4.2
> > >
> > > Steven:
> > >
> > > (You're welcome.)
> > >
> > > Downloaded RC6a-src and I am now experiencing Weirdness: I run "ant 
> clean
> > > dist-build-2.1 test" which works fine on Sun Java 1.4.2_08.
> > >
> > > On Sun Java 1.3.1_14 I get:
> > >
> > > test.lang:
> > >
> > > [echo] Running lang package tests ...
> > >
> > > [java] Class not found "org.apache.commons.lang.LangTestSuite"
> > >
> > > BUILD FAILED
> > >
> > > C:\temp\commons-lang-2.1-RC6\build.xml:166: Java returned: 1
> > >
> > > Which makes no sense at first glance.
> > >
> > > Gary
> > >
> > > --
> > >
> > > *From:* Steven Caswell [mailto:[EMAIL PROTECTED]
> > > *Sent:* Tuesday, May 24, 2005 7:00 PM
> > > *To:* Gary Gregory
> > > *Cc:* Jakarta Commons Developers List
> > > *Subject:* Re: [lang] DateUtils test fails under 1.2.2 and not under 
> 1.4.2
> > >
> > > Gary,
> > >
> > > I put up the revised source distribution in
> > > http://www.apache.org/~stevencaswell/commons-lang-2.1<
> http://www.apache.org/%7Estevencaswell/commons-lang-2.1>
> > >
> > > I named them commons-lang-2.1-RC6a-src.* so you could easily tell they 
> are
> > > modified. I was just too lazy to change it to RC7 for a minor non-code 
> fix,
> > > and since there will probably be an RC7 with the date utils test 
> change.
> > >
> > > Thanks for your patience and thanks for testing these things.
> > >
> > > On 5/24/05, *Steven Caswell* <[EMAIL PROTECTED] > wrote:
> > >
> > > Gary,
> > >
> > > I have a fix for that problem. I'll go ahead and put up a corrected 
> source
> > > distribution with the fix and without the DateUtilsTest correction so 
> you
> > > can try 1.3.1.
> > >
> > > On 5/24/05, *Gary Gregory* <[EMAIL PROTECTED] > wrote:
> > >
> > > I'd like to check 1.3.1 but... running "ant clean build-dist-2.1 test"
> > > from src-zip does not make it past text tests:
> > >
> > > test.text:
> > > [echo] Running text package tests ...
> > 

Re: FW: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2

[Steven Caswell]

Glad you found it.

On 5/26/05, Gary Gregory <[EMAIL PROTECTED]> wrote:
> 
>  Hi:
> 
>  I found possible solution. With 1.3.1, if I set *fork* to *false*, the 
> test is found and run. Weird. 
> 
>  Gary
> 
>   --
>  
> *From:* Steven Caswell [mailto:[EMAIL PROTECTED] 
> *Sent:* Thursday, May 26, 2005 5:06 PM
> *To:* Gary Gregory
> *Cc:* Jakarta Commons Developers List
> *Subject:* Re: FW: [lang] DateUtils test fails under 1.2.2 and not under 
> 1.4.2
>  
>  That is so very odd. I'm at a loss to explain it. I don't have access to 
> a system with JDK 1.3 so I'm not able to try it. Maybe someone else can 
> try?
> 
> One thing I did find I needed to do was to change th junit version in 
> default.properties from 3.7 to 3.8.1. Gary, could you try making this 
> change and building under 1.3.1? I'm just curious to see if this makes a 
> difference, though I don't see why it should.
> 
> Thanks.
>  
> On 5/25/05, *Gary Gregory* <[EMAIL PROTECTED]> wrote:
>  
> Steven:
> 
>  I updated from CVS today and got new build.xml. I still get the error 
> below on Sun Java 1.3.1_14.
> 
>  Thanks,
> 
> Gary 
> 
>   --
>  
> *From:* Gary Gregory 
> *Sent:* Tuesday, May 24, 2005 7:12 PM
> *To:* 'Steven Caswell'
> *Cc:* Jakarta Commons Developers List
> *Subject:* RE: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2
>  
>  Steven:
> 
>  (You're welcome.)
> 
>  Downloaded RC6a-src and I am now experiencing Weirdness: I run "ant clean 
> dist-build-2.1 test" which works fine on Sun Java 1.4.2_08.
> 
>  On Sun Java 1.3.1_14 I get:
> 
>  test.lang:
> 
> [echo] Running lang package tests ...
> 
> [java] Class not found "org.apache.commons.lang.LangTestSuite"
> 
>  BUILD FAILED
> 
> C:\temp\commons-lang-2.1-RC6\build.xml:166: Java returned: 1
> 
>  Which makes no sense at first glance.
> 
>  Gary 
> 
>   --
>  
> *From:* Steven Caswell [mailto:[EMAIL PROTECTED] 
> *Sent:* Tuesday, May 24, 2005 7:00 PM
> *To:* Gary Gregory
> *Cc:* Jakarta Commons Developers List
> *Subject:* Re: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2
>  
>  Gary,
> 
> I put up the revised source distribution in 
> http://www.apache.org/~stevencaswell/commons-lang-2.1 
> 
> 
> I named them commons-lang-2.1-RC6a-src.* so you could easily tell they are 
> modified. I was just too lazy to change it to RC7 for a minor non-code fix, 
> and since there will probably be an RC7 with the date utils test change.
> 
> Thanks for your patience and thanks for testing these things.
>  
> On 5/24/05, *Steven Caswell* <[EMAIL PROTECTED] > wrote:
> 
> Gary,
> 
> I have a fix for that problem. I'll go ahead and put up a corrected source 
> distribution with the fix and without the DateUtilsTest correction so you 
> can try 1.3.1.
>  
>  On 5/24/05, *Gary Gregory* <[EMAIL PROTECTED] > wrote:
> 
> I'd like to check 1.3.1 but... running "ant clean build-dist-2.1 test"
> from src-zip does not make it past text tests:
> 
> test.text:
> [echo] Running text package tests ...
> [java] Class not found " org.apache.commons.lang.text.TextTestSuite"
> 
> BUILD FAILED
> C:\temp\commons-lang-2.1-RC6\build.xml:206: Java returned: 1
> 
> Which should not be run in the 1st place...
> 
> (Ant 1.6.4 and Java 1.4.2_08) 
> 
> Gary
> 
> -Original Message-
> From: Steven Caswell [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 24, 2005 5:39 PM
> To: Jakarta Commons Developers List 
> Subject: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2
> 
> All,
> 
> I have discovered a group of tests in the DateUtils test case that fails
> 
> under 1.2.2 but not under 1.4.2. They are testing the DateUtils round 
> method
> when rounding a date in the MET timezone across the start and end of
> DST. If
> I remember correctly, this was in response to a user bug report. In
> particular the test is at line 472 of the testRound method in 
> DataUtilsTest.java.
> 
> The test passes fine when run under 1.4.2 but fails under 1.2.2. I don't
> 
> have a 1.3 installation available so I don't know if it passes or fails
> under 1.3.
> 
> I propose that we put a condition around the test so that is only run 
> when
> the Java version is 1.4, and add a note to the round method javadoc and
> the
> release notes stating that the round method may not work properly in all
> 
> cases involving DST rollovers in previous JVMs, with this case as an 
> example.
> 
> Thoughs?
> 
> --
> Steven Caswell
> [EMAIL PROTECTED]
> 
> Take back the web - http://www.mozilla.org
>  
> 
> 
> 
> -- 
> Steven Caswell
> [EMAIL PROTECTED]
> 
> Take back the web - http://www.mozilla.org 
>  
> 
> 
> 
> -- 
> Steven Caswell
> [EMAIL PROTECTED]
> 
> Take back the web - http://www.mozilla.org 
>   
> 
> 
> 
> -- 
> Steven Caswell
> [EMAIL PROTECTED]
> 
> Take back the web - http://www.mozilla.org 
>  



-- 
Steven Caswell
[EMAIL PROTECTED]

Take back the web - http://www.moz

DO NOT REPLY [Bug 32859] - [net] TFTPClient's send file discards last ack

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32859


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2005-05-27 02:58 ---
FWIW restoring the deleted call to bufferedSend corrected the symptoms I had.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FW: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2

[Simon Kitching]

Hi,


with lang/trunk:
"maven clean test" works for me with java1.5 on linux
"ant clean dist-build-2.1 test" works for me with java1.5 on linux

with the contents of file commons-lang-2.1-RC6a-src.tar.gz:
"maven clean test" works for me with java1.5 on linux
"ant clean dist-build-2.1 test" works for me with java1.5 on linux

I used junit-3.8.1 with ant.


"maven clean test" on lang/trunk or with the download RC6a file fails
with java1.3.1 on linux:
 [junit] Tests run: 40, Failures: 1, Errors: 0, Time elapsed: 4.995 sec
 [junit] [ERROR] TEST org.apache.commons.lang.time.TimeTestSuite FAILED

$ cat target/test-reports/
  TEST-org.apache.commons.lang.time.TimeTestSuite.txt

Testcase: testRound(org.apache.commons.lang.time.DateUtilsTest):
FAILED
round MET date across DST change-over expected: but was:
junit.framework.AssertionFailedError: round MET date across DST
change-over expected: but was:
at
org.apache.commons.lang.time.DateUtilsTest.testRound(DateUtilsTest.java:472)

$ java -version
java version "1.3.1_14"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_14-b03)
Java HotSpot(TM) Client VM (build 1.3.1_14-b03, mixed mode)


I did not get the reported problem:
> [java] Class not found "org.apache.commons.lang.LangTestSuite"



I don't see any RC6 directory under lang/tags. I presume the .tar.gz
file on your site is actually from HEAD?



Regards,

Simon

On Thu, 2005-05-26 at 20:05 -0400, Steven Caswell wrote:
> That is so very odd. I'm at a loss to explain it. I don't have access to a 
> system with JDK 1.3 so I'm not able to try it. Maybe someone else can try?
> 
> One thing I did find I needed to do was to change th junit version in 
> default.properties from 3.7 to 3.8.1. Gary, could you try making this change 
> and building under 1.3.1? I'm just curious to see if this makes a 
> difference, though I don't see why it should.
> 
> Thanks.
> 
> On 5/25/05, Gary Gregory <[EMAIL PROTECTED]> wrote:
> > 
> >  Steven:
> > 
> >  I updated from CVS today and got new build.xml. I still get the error 
> > below on Sun Java 1.3.1_14.
> > 
> >  Thanks,
> > 
> > Gary
> > 
> >   --
> >  
> > *From:* Gary Gregory 
> > *Sent:* Tuesday, May 24, 2005 7:12 PM
> > *To:* 'Steven Caswell'
> > *Cc:* Jakarta Commons Developers List
> > *Subject:* RE: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2
> >  
> >  Steven:
> > 
> >  (You're welcome.)
> > 
> >  Downloaded RC6a-src and I am now experiencing Weirdness: I run "ant clean 
> > dist-build-2.1 test" which works fine on Sun Java 1.4.2_08.
> > 
> >  On Sun Java 1.3.1_14 I get:
> > 
> >  test.lang:
> > 
> > [echo] Running lang package tests ...
> > 
> > [java] Class not found "org.apache.commons.lang.LangTestSuite"
> > 
> >  BUILD FAILED
> > 
> > C:\temp\commons-lang-2.1-RC6\build.xml:166: Java returned: 1
> > 
> >  Which makes no sense at first glance.
> > 
> >  Gary
> > 
> >   --
> >  
> > *From:* Steven Caswell [mailto:[EMAIL PROTECTED] 
> > *Sent:* Tuesday, May 24, 2005 7:00 PM
> > *To:* Gary Gregory
> > *Cc:* Jakarta Commons Developers List
> > *Subject:* Re: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2
> >  
> >  Gary,
> > 
> > I put up the revised source distribution in 
> > http://www.apache.org/~stevencaswell/commons-lang-2.1
> > 
> > I named them commons-lang-2.1-RC6a-src.* so you could easily tell they are 
> > modified. I was just too lazy to change it to RC7 for a minor non-code fix, 
> > and since there will probably be an RC7 with the date utils test change.
> > 
> > Thanks for your patience and thanks for testing these things.
> >  
> > On 5/24/05, *Steven Caswell* <[EMAIL PROTECTED] > wrote:
> > 
> > Gary,
> > 
> > I have a fix for that problem. I'll go ahead and put up a corrected source 
> > distribution with the fix and without the DateUtilsTest correction so you 
> > can try 1.3.1.
> >  
> >  On 5/24/05, *Gary Gregory* <[EMAIL PROTECTED] > wrote:
> > 
> > I'd like to check 1.3.1 but... running "ant clean build-dist-2.1 test"
> > from src-zip does not make it past text tests:
> > 
> > test.text:
> > [echo] Running text package tests ...
> > [java] Class not found " org.apache.commons.lang.text.TextTestSuite"
> > 
> > BUILD FAILED
> > C:\temp\commons-lang-2.1-RC6\build.xml:206: Java returned: 1
> > 
> > Which should not be run in the 1st place...
> > 
> > (Ant 1.6.4 and Java 1.4.2_08) 
> > 
> > Gary
> > 
> > -Original Message-
> > From: Steven Caswell [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, May 24, 2005 5:39 PM
> > To: Jakarta Commons Developers List 
> > Subject: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2
> > 
> > All,
> > 
> > I have discovered a group of tests in the DateUtils test case that fails
> > 
> > under 1.2.2 but not under 1.4.2. They are testing the DateUtils round 
> > method
> > when rounding a date in the MET timezone across the start

RE: FW: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2

[Gary Gregory]

As a minor clean up facilitating debugging, I've refactored the unit
test fork attribute in a default.properties property named "test.fork",
the default is true, as in the build.xml file.

Gary

-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 26, 2005 5:37 PM
To: Steven Caswell
Cc: Jakarta Commons Developers List
Subject: RE: FW: [lang] DateUtils test fails under 1.2.2 and not under
1.4.2

Hi:

 

I found possible solution. With 1.3.1, if I set fork to false, the test
is found and run. Weird. 

 

Gary

 



From: Steven Caswell [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 26, 2005 5:06 PM
To: Gary Gregory
Cc: Jakarta Commons Developers List
Subject: Re: FW: [lang] DateUtils test fails under 1.2.2 and not under
1.4.2

 

That is so very odd. I'm at a loss to explain it. I don't have access to
a system with JDK 1.3 so I'm not able to try it. Maybe someone else can
try?

One thing I did find I needed to do was to change th junit version in
default.properties from 3.7 to 3.8.1. Gary, could you try making this
change and building under 1.3.1? I'm just curious to see if this makes a
difference, though I don't see why it should.

Thanks.

On 5/25/05, Gary Gregory <[EMAIL PROTECTED]> wrote:

Steven:

 

I updated from CVS today and got new build.xml. I still get the error
below on Sun Java 1.3.1_14.

 

Thanks,

Gary 

 



From: Gary Gregory 
Sent: Tuesday, May 24, 2005 7:12 PM
To: 'Steven Caswell'
Cc: Jakarta Commons Developers List
Subject: RE: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2

 

Steven:

 

(You're welcome.)

 

Downloaded RC6a-src and I am now experiencing Weirdness: I run "ant
clean dist-build-2.1 test" which works fine on Sun Java 1.4.2_08.

 

On Sun Java 1.3.1_14 I get:

 

test.lang:

 [echo] Running lang package tests ...

 [java] Class not found "org.apache.commons.lang.LangTestSuite"

 

BUILD FAILED

C:\temp\commons-lang-2.1-RC6\build.xml:166: Java returned: 1

 

Which makes no sense at first glance.

 

Gary 

 



From: Steven Caswell [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 24, 2005 7:00 PM
To: Gary Gregory
Cc: Jakarta Commons Developers List
Subject: Re: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2

 

Gary,

I put up the revised source distribution in
http://www.apache.org/~stevencaswell/commons-lang-2.1
 

I named them commons-lang-2.1-RC6a-src.* so you could easily tell they
are modified. I was just too lazy to change it to RC7 for a minor
non-code fix, and since there will probably be an RC7 with the date
utils test change.

Thanks for your patience and thanks for testing these things.

On 5/24/05, Steven Caswell <[EMAIL PROTECTED] > wrote:

Gary,

I have a fix for that problem. I'll go ahead and put up a corrected
source distribution with the fix and without the DateUtilsTest
correction so you can try 1.3.1.

 

On 5/24/05, Gary Gregory <[EMAIL PROTECTED] > wrote:

I'd like to check 1.3.1 but... running "ant clean build-dist-2.1 test"
from src-zip does not make it past text tests:

test.text:
 [echo] Running text package tests ...
 [java] Class not found "
org.apache.commons.lang.text.TextTestSuite"

BUILD FAILED
C:\temp\commons-lang-2.1-RC6\build.xml:206: Java returned: 1

Which should not be run in the 1st place...

(Ant 1.6.4 and Java 1.4.2_08) 

Gary

-Original Message-
From: Steven Caswell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 24, 2005 5:39 PM
To: Jakarta Commons Developers List 
Subject: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2

All,

I have discovered a group of tests in the DateUtils test case that fails

under 1.2.2 but not under 1.4.2. They are testing the DateUtils round 
method
when rounding a date in the MET timezone across the start and end of
DST. If
I remember correctly, this was in response to a user bug report. In
particular the test is at line 472 of the testRound method in 
DataUtilsTest.java.

The test passes fine when run under 1.4.2 but fails under 1.2.2. I don't

have a 1.3 installation available so I don't know if it passes or fails
under 1.3.

I propose that we put a condition around the test so that is only run 
when
the Java version is 1.4, and add a note to the round method javadoc and
the
release notes stating that the round method may not work properly in all

cases involving DST rollovers in previous JVMs, with this case as an 
example.

Thoughs?

--
Steven Caswell
[EMAIL PROTECTED]

Take back the web - http://www.mozilla.org




-- 
Steven Caswell
[EMAIL PROTECTED]

Take back the web - http://www.mozilla.org 




-- 
Steven Caswell
[EMAIL PROTECTED]

Take back the web - http://www.mozilla.org 




-- 
Steven Caswell
[EMAIL PROTECTED]

Take back the web - http://www.mozilla.org 


-
To unsubscribe, 

svn commit: r178721 - in /jakarta/commons/proper/lang/trunk: build.xml default.properties

[ggregory]

Author: ggregory
Date: Thu May 26 17:42:00 2005
New Revision: 178721

URL: http://svn.apache.org/viewcvs?rev=178721&view=rev
Log:
Refactor unit test fork attribute in a default.properties property named 
"test.fork", default is true, as in the build.xml file.

Modified:
jakarta/commons/proper/lang/trunk/build.xml
jakarta/commons/proper/lang/trunk/default.properties

Modified: jakarta/commons/proper/lang/trunk/build.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/build.xml?rev=178721&r1=178720&r2=178721&view=diff
==
--- jakarta/commons/proper/lang/trunk/build.xml (original)
+++ jakarta/commons/proper/lang/trunk/build.xml Thu May 26 17:42:00 2005
@@ -163,63 +163,63 @@
 
 
 
-
+
 
 
 
 
 
 
-
+
 
 
 
 
 
 
-
+
 
 
 
 
 
 
-
+
 
 
 
 
 
 
-
+
 
 
 
 
 
 
-
+
 
 
 
 
 
 
-
+
 
 
 
 
 
 
-
+
 
 
 
 
 
 
-
+
 
 
 

Modified: jakarta/commons/proper/lang/trunk/default.properties
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/default.properties?rev=178721&r1=178720&r2=178721&view=diff
==
--- jakarta/commons/proper/lang/trunk/default.properties (original)
+++ jakarta/commons/proper/lang/trunk/default.properties Thu May 26 17:42:00 
2005
@@ -52,6 +52,9 @@
 # The base directory for unit test sources
 test.home = src/test
 
+# Whether or not to fork tests
+test.fork = true
+
 # Should Java compilations set the 'debug' compiler option?
 compile.debug = true
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: FW: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2

[Gary Gregory]

Hi:

 

I found possible solution. With 1.3.1, if I set fork to false, the test
is found and run. Weird. 

 

Gary

 



From: Steven Caswell [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 26, 2005 5:06 PM
To: Gary Gregory
Cc: Jakarta Commons Developers List
Subject: Re: FW: [lang] DateUtils test fails under 1.2.2 and not under
1.4.2

 

That is so very odd. I'm at a loss to explain it. I don't have access to
a system with JDK 1.3 so I'm not able to try it. Maybe someone else can
try?

One thing I did find I needed to do was to change th junit version in
default.properties from 3.7 to 3.8.1. Gary, could you try making this
change and building under 1.3.1? I'm just curious to see if this makes a
difference, though I don't see why it should.

Thanks.

On 5/25/05, Gary Gregory <[EMAIL PROTECTED]> wrote:

Steven:

 

I updated from CVS today and got new build.xml. I still get the error
below on Sun Java 1.3.1_14.

 

Thanks,

Gary 

 



From: Gary Gregory 
Sent: Tuesday, May 24, 2005 7:12 PM
To: 'Steven Caswell'
Cc: Jakarta Commons Developers List
Subject: RE: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2

 

Steven:

 

(You're welcome.)

 

Downloaded RC6a-src and I am now experiencing Weirdness: I run "ant
clean dist-build-2.1 test" which works fine on Sun Java 1.4.2_08.

 

On Sun Java 1.3.1_14 I get:

 

test.lang:

 [echo] Running lang package tests ...

 [java] Class not found "org.apache.commons.lang.LangTestSuite"

 

BUILD FAILED

C:\temp\commons-lang-2.1-RC6\build.xml:166: Java returned: 1

 

Which makes no sense at first glance.

 

Gary 

 



From: Steven Caswell [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 24, 2005 7:00 PM
To: Gary Gregory
Cc: Jakarta Commons Developers List
Subject: Re: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2

 

Gary,

I put up the revised source distribution in
http://www.apache.org/~stevencaswell/commons-lang-2.1
 

I named them commons-lang-2.1-RC6a-src.* so you could easily tell they
are modified. I was just too lazy to change it to RC7 for a minor
non-code fix, and since there will probably be an RC7 with the date
utils test change.

Thanks for your patience and thanks for testing these things.

On 5/24/05, Steven Caswell <[EMAIL PROTECTED] > wrote:

Gary,

I have a fix for that problem. I'll go ahead and put up a corrected
source distribution with the fix and without the DateUtilsTest
correction so you can try 1.3.1.

 

On 5/24/05, Gary Gregory <[EMAIL PROTECTED] > wrote:

I'd like to check 1.3.1 but... running "ant clean build-dist-2.1 test"
from src-zip does not make it past text tests:

test.text:
 [echo] Running text package tests ...
 [java] Class not found "
org.apache.commons.lang.text.TextTestSuite"

BUILD FAILED
C:\temp\commons-lang-2.1-RC6\build.xml:206: Java returned: 1

Which should not be run in the 1st place...

(Ant 1.6.4 and Java 1.4.2_08) 

Gary

-Original Message-
From: Steven Caswell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 24, 2005 5:39 PM
To: Jakarta Commons Developers List 
Subject: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2

All,

I have discovered a group of tests in the DateUtils test case that fails

under 1.2.2 but not under 1.4.2. They are testing the DateUtils round 
method
when rounding a date in the MET timezone across the start and end of
DST. If
I remember correctly, this was in response to a user bug report. In
particular the test is at line 472 of the testRound method in 
DataUtilsTest.java.

The test passes fine when run under 1.4.2 but fails under 1.2.2. I don't

have a 1.3 installation available so I don't know if it passes or fails
under 1.3.

I propose that we put a condition around the test so that is only run 
when
the Java version is 1.4, and add a note to the round method javadoc and
the
release notes stating that the round method may not work properly in all

cases involving DST rollovers in previous JVMs, with this case as an 
example.

Thoughs?

--
Steven Caswell
[EMAIL PROTECTED]

Take back the web - http://www.mozilla.org




-- 
Steven Caswell
[EMAIL PROTECTED]

Take back the web - http://www.mozilla.org 




-- 
Steven Caswell
[EMAIL PROTECTED]

Take back the web - http://www.mozilla.org 




-- 
Steven Caswell
[EMAIL PROTECTED]

Take back the web - http://www.mozilla.org 

DO NOT REPLY [Bug 32859] - [net] TFTPClient's send file discards last ack

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32859


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




--- Additional Comments From [EMAIL PROTECTED]  2005-05-27 02:32 ---
I can't see how the flag in this patch helps anything. As far as I can tell, all
the lines in the patch that could make use of this new flag have + in front of
them. None of those lines set the flag to true, so the flag is always false and
the code pretty much does what it did before.

There is another delta in the patch that changes how bufferedSend is called.
This worries me because I'm having a problem where the last piece of the file
(or all of the file if it is small) is not sent to the server.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [digester] VOTE: create release 1.7

[Simon Kitching]

On Wed, 2005-05-25 at 17:35 +1200, Simon Kitching wrote:
> Hi All,
> 
> I'd like to propose that we do a release 1.7 of Digester.
> I'm willing to act as release manager for this.


Well, there hasn't been much response on this! So far:
  dion +1

PLEASE take a little time for this, otherwise a digester release will
not happen.

Before voting +1 there are two issues you need to consider:
a) is it an appropriate time for a digester release
b) is the release plan ok?
c) is simon the right person?

a:
  * have a look at bugzilla for digester, and verify that there is only
one outstanding bug entry, with a patch already committed (and it
only occurs with the Aelfred xml parser). In fact, it might be
closed by the time you look.
  * have a look at the commit history for digester
 (svn log -v -rn:HEAD proper/digester/trunk)
and verify that there really isn't much action going on
  * have a look at the release notes, and verify that there is some
stuff worth releasing.

I can't think of anything else that is relevant. So if these all look ok
to you, then I ask that you vote +1 on getting a release out.

b:
 * read the release plan (in my original email; link is below).

c:
  * I'm the only active digester maintainer
  * No-one else has volunteered
  * I don't eat babies [1] or summon demons [2]
(do those disqualify a release manager anyway?)

So unless you have a particular concern, then I ask that you vote +1 on
me being the release manager.

Note that this is not an *approval of a release candidate*, it's just a
vote to get the process started. There will also be a vote to approve a
specific release candidate build, at which time I hope people will
devote a little time to downloading and testing the .tar.gz, inspecting
the updated website, etc. - all that usual stuff.

Links:
  http://people.apache.org/~skitching/digester-1.7/RELEASE-NOTES.txt
  http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=111699930401946&w=2

[1] Babies have no taste.
[2] Daemons are a different matter.

Thanks,

Simon


> --
> 
> [ ] +1 on simon preparing release 1.7 of digester
> [ ] +0
> [ ] -0
> [ ] -1



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FW: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2

[Steven Caswell]

That is so very odd. I'm at a loss to explain it. I don't have access to a 
system with JDK 1.3 so I'm not able to try it. Maybe someone else can try?

One thing I did find I needed to do was to change th junit version in 
default.properties from 3.7 to 3.8.1. Gary, could you try making this change 
and building under 1.3.1? I'm just curious to see if this makes a 
difference, though I don't see why it should.

Thanks.

On 5/25/05, Gary Gregory <[EMAIL PROTECTED]> wrote:
> 
>  Steven:
> 
>  I updated from CVS today and got new build.xml. I still get the error 
> below on Sun Java 1.3.1_14.
> 
>  Thanks,
> 
> Gary
> 
>   --
>  
> *From:* Gary Gregory 
> *Sent:* Tuesday, May 24, 2005 7:12 PM
> *To:* 'Steven Caswell'
> *Cc:* Jakarta Commons Developers List
> *Subject:* RE: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2
>  
>  Steven:
> 
>  (You're welcome.)
> 
>  Downloaded RC6a-src and I am now experiencing Weirdness: I run "ant clean 
> dist-build-2.1 test" which works fine on Sun Java 1.4.2_08.
> 
>  On Sun Java 1.3.1_14 I get:
> 
>  test.lang:
> 
> [echo] Running lang package tests ...
> 
> [java] Class not found "org.apache.commons.lang.LangTestSuite"
> 
>  BUILD FAILED
> 
> C:\temp\commons-lang-2.1-RC6\build.xml:166: Java returned: 1
> 
>  Which makes no sense at first glance.
> 
>  Gary
> 
>   --
>  
> *From:* Steven Caswell [mailto:[EMAIL PROTECTED] 
> *Sent:* Tuesday, May 24, 2005 7:00 PM
> *To:* Gary Gregory
> *Cc:* Jakarta Commons Developers List
> *Subject:* Re: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2
>  
>  Gary,
> 
> I put up the revised source distribution in 
> http://www.apache.org/~stevencaswell/commons-lang-2.1
> 
> I named them commons-lang-2.1-RC6a-src.* so you could easily tell they are 
> modified. I was just too lazy to change it to RC7 for a minor non-code fix, 
> and since there will probably be an RC7 with the date utils test change.
> 
> Thanks for your patience and thanks for testing these things.
>  
> On 5/24/05, *Steven Caswell* <[EMAIL PROTECTED] > wrote:
> 
> Gary,
> 
> I have a fix for that problem. I'll go ahead and put up a corrected source 
> distribution with the fix and without the DateUtilsTest correction so you 
> can try 1.3.1.
>  
>  On 5/24/05, *Gary Gregory* <[EMAIL PROTECTED] > wrote:
> 
> I'd like to check 1.3.1 but... running "ant clean build-dist-2.1 test"
> from src-zip does not make it past text tests:
> 
> test.text:
> [echo] Running text package tests ...
> [java] Class not found " org.apache.commons.lang.text.TextTestSuite"
> 
> BUILD FAILED
> C:\temp\commons-lang-2.1-RC6\build.xml:206: Java returned: 1
> 
> Which should not be run in the 1st place...
> 
> (Ant 1.6.4 and Java 1.4.2_08) 
> 
> Gary
> 
> -Original Message-
> From: Steven Caswell [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 24, 2005 5:39 PM
> To: Jakarta Commons Developers List 
> Subject: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2
> 
> All,
> 
> I have discovered a group of tests in the DateUtils test case that fails
> 
> under 1.2.2 but not under 1.4.2. They are testing the DateUtils round 
> method
> when rounding a date in the MET timezone across the start and end of
> DST. If
> I remember correctly, this was in response to a user bug report. In
> particular the test is at line 472 of the testRound method in 
> DataUtilsTest.java.
> 
> The test passes fine when run under 1.4.2 but fails under 1.2.2. I don't
> 
> have a 1.3 installation available so I don't know if it passes or fails
> under 1.3.
> 
> I propose that we put a condition around the test so that is only run 
> when
> the Java version is 1.4, and add a note to the round method javadoc and
> the
> release notes stating that the round method may not work properly in all
> 
> cases involving DST rollovers in previous JVMs, with this case as an 
> example.
> 
> Thoughs?
> 
> --
> Steven Caswell
> [EMAIL PROTECTED]
> 
> Take back the web - http://www.mozilla.org
>  
> 
> 
> 
> -- 
> Steven Caswell
> [EMAIL PROTECTED]
> 
> Take back the web - http://www.mozilla.org 
>  
> 
> 
> 
> -- 
> Steven Caswell
> [EMAIL PROTECTED]
> 
> Take back the web - http://www.mozilla.org 
>  



-- 
Steven Caswell
[EMAIL PROTECTED]

Take back the web - http://www.mozilla.org

Re: [Proposal] Commons Filters

[Frank W. Zammetti]

Well, you are in a position to drive such a thing where I am not, so I 
will keep an interested eye on how it goes... I will have some code to 
contribute when it gets going.


I would also propose that what is currently in the Servlet package in 
the sandbox probably makes sense in a Web Commons project.  There isn't 
a ton there, but there is some stuff that could serve as a seed (albeit 
a small one) for Web Commons.  I'd hate to see some potentially useful 
code kind of wither away in a Servlet package that might not go much 
further on its own.


Frank


Martin Cooper wrote:

On 5/26/05, Simon Kitching <[EMAIL PROTECTED]> wrote:


You might want to read this email thread:

http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=111231929725398&w=2



That is in fact why I have not responded until now. As can be seen
from that thread, I volunteered to sound out the Taglibs community
prior to floating a "webapps commons" subproject. That's something I'm
hoping to get to over the long weekend.

--
Martin Cooper




Regards,

Simon

--
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?

On Thu, 2005-05-26 at 18:47 -0400, Frank W. Zammetti wrote:


I take the silence, aside from Max that is, to mean there is no interest
from the Commons dev community for this proposal?

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Wed, May 25, 2005 1:53 pm, Frank W. Zammetti said:


That sounds excellent.  There would be some obvious performance concerns
with such a filter, but it does sound like a useful function if one fully
understands the implications.

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Wed, May 25, 2005 1:43 pm, Rudman Max said:


Can we also add a Filter to replace a regex with some value in the
output? I've found myself having to write that a couple of times. I
can help contribute to this effort.

Max

On May 25, 2005, at 9:25 AM, Frank W. Zammetti wrote:



Proposal for Commons Filters Package (hope I did this right!)


Rationale
-
I frequently see questions asked on the Struts Users and Tomcat Users
lists that result in the answer "write a servlet filter for it".
There
are many functions which it would be nice to have available in a
filter in
a flexible, independant way, things that can be reused across many
projects without being tied to a particular framework or server.

With this in mind, I propose a new Commons Filters package.
Alternatively, this could be a new component under the Commons
Servlets
package, but that package would need to move in to the sandbox I
believe.
I am open to either approach, although I prefer the first.


Scope of the package

Any function which can be used independant of a given framework or app
server might be eligible.  By way of example, the following are some
filters I have written and which might make good candidates:

* CacheControlFilter - This allows for control of setting cache
headers,
similar to the Struts RequestProcessor's cachecontrol setting, but
in a
more fine-grained manner.

* AppAvailabilityFilter - This allows a developer to determine if an
application is available to users based on a defined "availability
window".

* InvalidUserRedirectFilter - This allows for redirection to a defined
page when a particular attribute is not found in session.


Interaction with other packages
---
Commons Logging would be used for all logging functionality, and
Commons
Digester would be used for any configuration file parsing that a
filter
might require.

I would be willing to provide at least a few initial filters to get
the
codebase going.  I am reasonably sure others will contribute their
work
quickly.


Identify the base name for the package
--
org.apache.commons.filters

Perhaps org.apache.commons.servletfilters might be more
appropriate, or if
put under the Servlets package then org.apache.commons.servlet.filters
would be the name.


Identify the coding conventions for this package

The code would use the Sun Standard coding conventions (mostly!).


Identify any Jakarta-Commons resources to be created

* Mailing list - Commons dev/user lists would be used, I do not
envision
this ever requiring its own list.  Besides, I agree with the
concept that
all Commons projects should probably use the same two lists to achieve
maximum benefit of a "Commons" project philosophy.

* CVS repository - Probably a root branch of the Jakarta-Commons
CVS?  I
leave this to those that know more than me to decide!

* Bugzilla - The package should be listed as a component of under the
Jakarta-Commons Bugzilla entry.


Identify the initial set of committers to be listed in the Status File

DO NOT REPLY [Bug 32590] - [beanutils] WrapDynaBean misleading error message: Property has no read method

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32590





--- Additional Comments From [EMAIL PROTECTED]  2005-05-27 01:29 ---
I don't think it is safe to modify this code to throw anything other than an
IllegalArgumentException; that could break user code.

But we could make the string message in the IllegalArgumentException more 
helpful.

The getSimpleProperty method already throws a nice selection of different
exceptions. In particular, it throws InvocationTargetException in the case that
this bugzilla entry is about.

So I would suggest this:
 try {
   value = ...
 } catch(IllegalArgumentException ..) {
throw new IllegalArgumentException("...");
 } catch(InvocationTargetException ex) {
throw new IllegalArgumentException(
  "An exception was thrown by the getter method for property + "  name);
 } catch(NoSuchMethodException ex) {
// throw IllegalArgumentException with appropriate
// message here...
 } catch(Throwable ex) {
// throw IllegalArgumentException with appropriate
// message here...
 }

And of course the javadoc would need a little update too.

Comments?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34819] - [digester] NodeCreateRule Failing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34819





--- Additional Comments From [EMAIL PROTECTED]  2005-05-27 01:14 ---
(In reply to comment #6)
> If it doesn't, please let
> me know.

Awesome! We're getting somewhere - only problem is failed assertion -


test.node:
 [echo] Running NodeCreateRule tests ...
 [java] ..F.F
 [java] Time: 0.652
 [java] There were 2 failures:
 [java] 1) testElement(org.apache.commons.digester.NodeCreateRuleTestCase)ju
nit.framework.AssertionFailedError
 [java]at org.apache.commons.digester.NodeCreateRuleTestCase.testElement
 (NodeCreateRuleTestCase.java:209)
 [java]at java.lang.reflect.Method.invokeNative (Method.java)
 [java]at java.lang.reflect.Method.invoke (Method.java:616)
 [java]at java.lang.VirtualMachine.invokeMain (VirtualMachine.java)
 [java]at java.lang.VirtualMachine.main (VirtualMachine.java:108)
 [java] 2) testDocumentFragment(org.apache.commons.digester.NodeCreateRuleTe
stCase)junit.framework.AssertionFailedError
 [java]at org.apache.commons.digester.NodeCreateRuleTestCase.testDocumen
tFragment (NodeCreateRuleTestCase.java:240)
 [java]at java.lang.reflect.Method.invokeNative (Method.java)
 [java]at java.lang.reflect.Method.invoke (Method.java:616)
 [java]at java.lang.VirtualMachine.invokeMain (VirtualMachine.java)
 [java]at java.lang.VirtualMachine.main (VirtualMachine.java:108)


Both assertions fail because ((Element)element).getLocalName() is "alpha", not
null. I haven't yet figured out if this is OK or a bug in gnu classpath...

Thanks again!

Jack

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposal] Commons Filters

[Martin Cooper]

On 5/26/05, Simon Kitching <[EMAIL PROTECTED]> wrote:
> You might want to read this email thread:
> 
> http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=111231929725398&w=2

That is in fact why I have not responded until now. As can be seen
from that thread, I volunteered to sound out the Taglibs community
prior to floating a "webapps commons" subproject. That's something I'm
hoping to get to over the long weekend.

--
Martin Cooper


> Regards,
> 
> Simon
> 
> --
> A. Because it breaks the logical sequence of discussion
> Q. Why is top posting bad?
> 
> On Thu, 2005-05-26 at 18:47 -0400, Frank W. Zammetti wrote:
> > I take the silence, aside from Max that is, to mean there is no interest
> > from the Commons dev community for this proposal?
> >
> > --
> > Frank W. Zammetti
> > Founder and Chief Software Architect
> > Omnytex Technologies
> > http://www.omnytex.com
> >
> > On Wed, May 25, 2005 1:53 pm, Frank W. Zammetti said:
> > > That sounds excellent.  There would be some obvious performance concerns
> > > with such a filter, but it does sound like a useful function if one fully
> > > understands the implications.
> > >
> > > --
> > > Frank W. Zammetti
> > > Founder and Chief Software Architect
> > > Omnytex Technologies
> > > http://www.omnytex.com
> > >
> > > On Wed, May 25, 2005 1:43 pm, Rudman Max said:
> > >> Can we also add a Filter to replace a regex with some value in the
> > >> output? I've found myself having to write that a couple of times. I
> > >> can help contribute to this effort.
> > >>
> > >> Max
> > >>
> > >> On May 25, 2005, at 9:25 AM, Frank W. Zammetti wrote:
> > >>
> > >>> Proposal for Commons Filters Package (hope I did this right!)
> > >>>
> > >>>
> > >>> Rationale
> > >>> -
> > >>> I frequently see questions asked on the Struts Users and Tomcat Users
> > >>> lists that result in the answer "write a servlet filter for it".
> > >>> There
> > >>> are many functions which it would be nice to have available in a
> > >>> filter in
> > >>> a flexible, independant way, things that can be reused across many
> > >>> projects without being tied to a particular framework or server.
> > >>>
> > >>> With this in mind, I propose a new Commons Filters package.
> > >>> Alternatively, this could be a new component under the Commons
> > >>> Servlets
> > >>> package, but that package would need to move in to the sandbox I
> > >>> believe.
> > >>> I am open to either approach, although I prefer the first.
> > >>>
> > >>>
> > >>> Scope of the package
> > >>> 
> > >>> Any function which can be used independant of a given framework or app
> > >>> server might be eligible.  By way of example, the following are some
> > >>> filters I have written and which might make good candidates:
> > >>>
> > >>> * CacheControlFilter - This allows for control of setting cache
> > >>> headers,
> > >>> similar to the Struts RequestProcessor's cachecontrol setting, but
> > >>> in a
> > >>> more fine-grained manner.
> > >>>
> > >>> * AppAvailabilityFilter - This allows a developer to determine if an
> > >>> application is available to users based on a defined "availability
> > >>> window".
> > >>>
> > >>> * InvalidUserRedirectFilter - This allows for redirection to a defined
> > >>> page when a particular attribute is not found in session.
> > >>>
> > >>>
> > >>> Interaction with other packages
> > >>> ---
> > >>> Commons Logging would be used for all logging functionality, and
> > >>> Commons
> > >>> Digester would be used for any configuration file parsing that a
> > >>> filter
> > >>> might require.
> > >>>
> > >>> I would be willing to provide at least a few initial filters to get
> > >>> the
> > >>> codebase going.  I am reasonably sure others will contribute their
> > >>> work
> > >>> quickly.
> > >>>
> > >>>
> > >>> Identify the base name for the package
> > >>> --
> > >>> org.apache.commons.filters
> > >>>
> > >>> Perhaps org.apache.commons.servletfilters might be more
> > >>> appropriate, or if
> > >>> put under the Servlets package then org.apache.commons.servlet.filters
> > >>> would be the name.
> > >>>
> > >>>
> > >>> Identify the coding conventions for this package
> > >>> 
> > >>> The code would use the Sun Standard coding conventions (mostly!).
> > >>>
> > >>>
> > >>> Identify any Jakarta-Commons resources to be created
> > >>> 
> > >>> * Mailing list - Commons dev/user lists would be used, I do not
> > >>> envision
> > >>> this ever requiring its own list.  Besides, I agree with the
> > >>> concept that
> > >>> all Commons projects should probably use the same two lists to achieve
> > >>> maximum benefit of a "Commons" project philosophy.
> > >>>
> > >>> * CVS repository - Probably a root branch of the Jakarta-Commons
> > >>> CVS?  I
> > >>> leave this to those that know more than me to decide!
> > >>>
> > >>> * 

DO NOT REPLY [Bug 35095] New: - Allow SetNextRule to fire on begin

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35095

   Summary: Allow SetNextRule to fire on begin
   Product: Commons
   Version: 1.6 Final
  Platform: All
OS/Version: other
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Digester
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Currently, SetNextRule always invokes the target method from its end method.

But there is no reason why it can't invoke the target from begin. This would be
useful in cases where it is desirable to build the parent/child relationship
before processing nested xml. In particular, using BeanPropertySetterRule
against nested xml elements can cause the setter methods to be called on a bean
before its parent/child relationship is set up and sometimes this is bad.

It should be possible to add options to the constructor of SetNextRule to
indicate if fire-at-end (existing) or fire-at-begin (new) behaviour is desired.

Of course the xmlrules module would need to be updated too.
And this feature probably could be applied to a few other rules.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposal] Commons Filters

[Frank W. Zammetti]

That's cool Simon, thank you for the reference.  I did not see that 
thread when it was live.


Can you, or anyone else, tell us where the "Web Commons" project is, if 
anywhere?  I don't see it in the sandbox, so I assume that means it 
never got off the ground?  It's only been a bit over a month or so since 
that thread as far as I can see, so maybe it's still germinating?


That would certainly be a good project to supercede what I proposed.

Frank

Simon Kitching wrote:

You might want to read this email thread:

http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=111231929725398&w=2

Regards,

Simon





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposal] Commons Filters

[Simon Kitching]

You might want to read this email thread:

http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=111231929725398&w=2

Regards,

Simon

-- 
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?

On Thu, 2005-05-26 at 18:47 -0400, Frank W. Zammetti wrote:
> I take the silence, aside from Max that is, to mean there is no interest
> from the Commons dev community for this proposal?
> 
> -- 
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> 
> On Wed, May 25, 2005 1:53 pm, Frank W. Zammetti said:
> > That sounds excellent.  There would be some obvious performance concerns
> > with such a filter, but it does sound like a useful function if one fully
> > understands the implications.
> >
> > --
> > Frank W. Zammetti
> > Founder and Chief Software Architect
> > Omnytex Technologies
> > http://www.omnytex.com
> >
> > On Wed, May 25, 2005 1:43 pm, Rudman Max said:
> >> Can we also add a Filter to replace a regex with some value in the
> >> output? I've found myself having to write that a couple of times. I
> >> can help contribute to this effort.
> >>
> >> Max
> >>
> >> On May 25, 2005, at 9:25 AM, Frank W. Zammetti wrote:
> >>
> >>> Proposal for Commons Filters Package (hope I did this right!)
> >>>
> >>>
> >>> Rationale
> >>> -
> >>> I frequently see questions asked on the Struts Users and Tomcat Users
> >>> lists that result in the answer "write a servlet filter for it".
> >>> There
> >>> are many functions which it would be nice to have available in a
> >>> filter in
> >>> a flexible, independant way, things that can be reused across many
> >>> projects without being tied to a particular framework or server.
> >>>
> >>> With this in mind, I propose a new Commons Filters package.
> >>> Alternatively, this could be a new component under the Commons
> >>> Servlets
> >>> package, but that package would need to move in to the sandbox I
> >>> believe.
> >>> I am open to either approach, although I prefer the first.
> >>>
> >>>
> >>> Scope of the package
> >>> 
> >>> Any function which can be used independant of a given framework or app
> >>> server might be eligible.  By way of example, the following are some
> >>> filters I have written and which might make good candidates:
> >>>
> >>> * CacheControlFilter - This allows for control of setting cache
> >>> headers,
> >>> similar to the Struts RequestProcessor's cachecontrol setting, but
> >>> in a
> >>> more fine-grained manner.
> >>>
> >>> * AppAvailabilityFilter - This allows a developer to determine if an
> >>> application is available to users based on a defined "availability
> >>> window".
> >>>
> >>> * InvalidUserRedirectFilter - This allows for redirection to a defined
> >>> page when a particular attribute is not found in session.
> >>>
> >>>
> >>> Interaction with other packages
> >>> ---
> >>> Commons Logging would be used for all logging functionality, and
> >>> Commons
> >>> Digester would be used for any configuration file parsing that a
> >>> filter
> >>> might require.
> >>>
> >>> I would be willing to provide at least a few initial filters to get
> >>> the
> >>> codebase going.  I am reasonably sure others will contribute their
> >>> work
> >>> quickly.
> >>>
> >>>
> >>> Identify the base name for the package
> >>> --
> >>> org.apache.commons.filters
> >>>
> >>> Perhaps org.apache.commons.servletfilters might be more
> >>> appropriate, or if
> >>> put under the Servlets package then org.apache.commons.servlet.filters
> >>> would be the name.
> >>>
> >>>
> >>> Identify the coding conventions for this package
> >>> 
> >>> The code would use the Sun Standard coding conventions (mostly!).
> >>>
> >>>
> >>> Identify any Jakarta-Commons resources to be created
> >>> 
> >>> * Mailing list - Commons dev/user lists would be used, I do not
> >>> envision
> >>> this ever requiring its own list.  Besides, I agree with the
> >>> concept that
> >>> all Commons projects should probably use the same two lists to achieve
> >>> maximum benefit of a "Commons" project philosophy.
> >>>
> >>> * CVS repository - Probably a root branch of the Jakarta-Commons
> >>> CVS?  I
> >>> leave this to those that know more than me to decide!
> >>>
> >>> * Bugzilla - The package should be listed as a component of under the
> >>> Jakarta-Commons Bugzilla entry.
> >>>
> >>>
> >>> Identify the initial set of committers to be listed in the Status File
> >>> --
> >>> Frank W. Zammetti, although I'm not sure I *can* be listed because
> >>> I have
> >>> no present involvement under Apache officially and I don't know
> >>> what the
> >>> rules/requirements are, so again I leave this to those that know
> >>> more than
> >>> me to decide... as long as I am

Re: [Proposal] Commons Filters

[Frank W. Zammetti]

I take the silence, aside from Max that is, to mean there is no interest
from the Commons dev community for this proposal?

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Wed, May 25, 2005 1:53 pm, Frank W. Zammetti said:
> That sounds excellent.  There would be some obvious performance concerns
> with such a filter, but it does sound like a useful function if one fully
> understands the implications.
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> On Wed, May 25, 2005 1:43 pm, Rudman Max said:
>> Can we also add a Filter to replace a regex with some value in the
>> output? I've found myself having to write that a couple of times. I
>> can help contribute to this effort.
>>
>> Max
>>
>> On May 25, 2005, at 9:25 AM, Frank W. Zammetti wrote:
>>
>>> Proposal for Commons Filters Package (hope I did this right!)
>>>
>>>
>>> Rationale
>>> -
>>> I frequently see questions asked on the Struts Users and Tomcat Users
>>> lists that result in the answer "write a servlet filter for it".
>>> There
>>> are many functions which it would be nice to have available in a
>>> filter in
>>> a flexible, independant way, things that can be reused across many
>>> projects without being tied to a particular framework or server.
>>>
>>> With this in mind, I propose a new Commons Filters package.
>>> Alternatively, this could be a new component under the Commons
>>> Servlets
>>> package, but that package would need to move in to the sandbox I
>>> believe.
>>> I am open to either approach, although I prefer the first.
>>>
>>>
>>> Scope of the package
>>> 
>>> Any function which can be used independant of a given framework or app
>>> server might be eligible.  By way of example, the following are some
>>> filters I have written and which might make good candidates:
>>>
>>> * CacheControlFilter - This allows for control of setting cache
>>> headers,
>>> similar to the Struts RequestProcessor's cachecontrol setting, but
>>> in a
>>> more fine-grained manner.
>>>
>>> * AppAvailabilityFilter - This allows a developer to determine if an
>>> application is available to users based on a defined "availability
>>> window".
>>>
>>> * InvalidUserRedirectFilter - This allows for redirection to a defined
>>> page when a particular attribute is not found in session.
>>>
>>>
>>> Interaction with other packages
>>> ---
>>> Commons Logging would be used for all logging functionality, and
>>> Commons
>>> Digester would be used for any configuration file parsing that a
>>> filter
>>> might require.
>>>
>>> I would be willing to provide at least a few initial filters to get
>>> the
>>> codebase going.  I am reasonably sure others will contribute their
>>> work
>>> quickly.
>>>
>>>
>>> Identify the base name for the package
>>> --
>>> org.apache.commons.filters
>>>
>>> Perhaps org.apache.commons.servletfilters might be more
>>> appropriate, or if
>>> put under the Servlets package then org.apache.commons.servlet.filters
>>> would be the name.
>>>
>>>
>>> Identify the coding conventions for this package
>>> 
>>> The code would use the Sun Standard coding conventions (mostly!).
>>>
>>>
>>> Identify any Jakarta-Commons resources to be created
>>> 
>>> * Mailing list - Commons dev/user lists would be used, I do not
>>> envision
>>> this ever requiring its own list.  Besides, I agree with the
>>> concept that
>>> all Commons projects should probably use the same two lists to achieve
>>> maximum benefit of a "Commons" project philosophy.
>>>
>>> * CVS repository - Probably a root branch of the Jakarta-Commons
>>> CVS?  I
>>> leave this to those that know more than me to decide!
>>>
>>> * Bugzilla - The package should be listed as a component of under the
>>> Jakarta-Commons Bugzilla entry.
>>>
>>>
>>> Identify the initial set of committers to be listed in the Status File
>>> --
>>> Frank W. Zammetti, although I'm not sure I *can* be listed because
>>> I have
>>> no present involvement under Apache officially and I don't know
>>> what the
>>> rules/requirements are, so again I leave this to those that know
>>> more than
>>> me to decide... as long as I am involved in some fashion I'm OK
>>> with it.
>>>
>>>
>>> --
>>> Frank W. Zammetti
>>> Founder and Chief Software Architect
>>> Omnytex Technologies
>>> http://www.omnytex.com
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED

RE: Commons-Collections enhanced with Java Generics Support

[Laurent Brucher]

Hi John,

First off, thanks for the time and effort you guys have put into the port.
Having joined Chris recently on the Collections15 port, I understand the
work that
is required to get this done.

Some comments and thoughts below.


> Our approach was to shoot for supporting generics in the 
> majority of the 
> classes. This was because we wanted to begin using the collections in 
> 1.5 in our own projects immediately, and there was no 
> existing solution 
> for us. Those classes that did not lend themselves well to 
> generics were 
> either not converted or were only partially converted. This way, the 
> software worked right away and was a clear improvement over the 
> non-generic collections. We agree that it has some 
> short-comings in the 
> partially-/non-converted areas and we look forward to working with 
> everybody to resolve those in the best way possible.
> 
I understand your needs to have something quick that fits your particular
needs.
But I feel like the ported [collections] should contain all of the current
features and
classes at the time it is released to the public, as you mentioned at the
end of your email.

> 
> Yes, we feel that the some of the internal implementations are 
> well-converted, but not all. We look forward to improving the use of 
> generics in those classes and throughout the source. These 
> refactors are 
> important, but will not change the experience for the users 
> of the library.

Well, I'd say that if the plan is to rework the internal implementation
anyway,
then I think this should be done first before releasing to public, saving
them
from potential bug fixes, etc. that may appear during the rework.


> 
> ---
> 3. Here's my biggest worry. The unit tests in 
> collections.sf.net don't 
> appear to have been modified to reflect the generification of 
> the APIs. 
> The 100% success rate of the unit tests is therefore 
> misleading, as it's 
> more of an indication that the original commons-collections code on 
> which the collections.sf.net port was based doesn't fail any 
> of its unit 
> tests. What's missing in the unit tests is an attempt to exercise the 
> generic modifications made to the APIs. Whilst updating the 
> unit tests 
> in collections15.sf.net, a fair number of minor errors where 
> uncovered. 
> They were typically problems whereby it became apparent when 
> writing the 
> unit tests that the generic arguments of various methods weren't 
> sufficiently flexible. I'm worried that since the unit tests in 
> collections.sf.net don't exercise the generic modification that have 
> been made, the modifications may not have been exercised at all.
> ---
> 
> On this point, I don't entirely agree. The behavior of a class is the 
> same at runtime regardless of whether the user used generics in the 
> source code or not. Any errors in our addition of generics to the 
> collections will manifest themselves at compile-time, not 
> runtime. Now, 
> such issues are important, and we should make sure that each 
> method of 
> each collection is defined consistently from a generics point 
> of view. 

Indeed, things will be the same at runtime. But I also feel that it is
essential to have unit tests written specifically for generics to ensure
the API is valid at compile time. This is what users will first run into
when moving to the new [collections].
Having said that and having gone through a bunch of them already, converting
those unit tests to use generics is far from being a straightforward task.
But gotta be done.


> Chris, thanks for these points. We agree that there should not be 
> duplicated effort on this project, and we look forward to open 
> collaboration on this. More work is certainly required to bring those 
> straggling non-generic collections in to the fold, but we 
> emphasize an 
> approach that retains the full, working funtionality of the 
> collections 
> during these early releases. That way, developers can use the 
> package, 
> get used to the generic versions of the collections, and 
> provide us with 
> valuable feedback.

I agree with that but I also remember Stephen's word recently saying that
the [collections] must not only be 'clean' but also be perceived to be
clean.
I do think it is important that early adopters feel comfortable with the
API once they start using them with generics and not only using the JAR with
their
previous, non-generic, code.

Finally, I do agree with both Chris and yourself that combining efforts is
certainly a better idea than duplicating them.
Looking forward to this then :o)

Laurent Brucher.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32420] - [collections] incorrect package name in file o.a.c.c.keyvalue.KeyValue

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32420


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-05-26 22:56 ---
I guess this was fixed ages ago.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34819] - [digester] NodeCreateRule Failing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34819





--- Additional Comments From [EMAIL PROTECTED]  2005-05-26 22:42 ---
Oops - using a java1.5 method in the unit test wasn't intentional. I have fixed
this. Hopefully the HEAD version now compiles for you. If it doesn't, please let
me know.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r178678 - /jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/SetNestedPropertiesRuleTestCase.java

[skitching]

Author: skitching
Date: Thu May 26 13:40:34 2005
New Revision: 178678

URL: http://svn.apache.org/viewcvs?rev=178678&view=rev
Log:
Fix accidental use of java1.5 method.

Modified:

jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/SetNestedPropertiesRuleTestCase.java

Modified: 
jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/SetNestedPropertiesRuleTestCase.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/SetNestedPropertiesRuleTestCase.java?rev=178678&r1=178677&r2=178678&view=diff
==
--- 
jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/SetNestedPropertiesRuleTestCase.java
 (original)
+++ 
jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/SetNestedPropertiesRuleTestCase.java
 Thu May 26 13:40:34 2005
@@ -179,7 +179,7 @@
 fail("No exception thrown by parse when unknown child element 
found.");
 } catch(org.xml.sax.SAXParseException e) {
 String msg = e.getMessage();
-if (msg.contains("badprop")) {
+if (msg.indexOf("badprop") >= 0) {
 // ok, this is expected; there is no "setBadprop" method on the
 // SimpleTestBean class...
 } else {



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r178664 - /jakarta/commons/proper/httpclient/trunk/release_notes.txt

[olegk]

Author: olegk
Date: Thu May 26 11:31:15 2005
New Revision: 178664

URL: http://svn.apache.org/viewcvs?rev=178664&view=rev
Log:
Fixed a typo

Modified:
jakarta/commons/proper/httpclient/trunk/release_notes.txt

Modified: jakarta/commons/proper/httpclient/trunk/release_notes.txt
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/release_notes.txt?rev=178664&r1=178663&r2=178664&view=diff
==
--- jakarta/commons/proper/httpclient/trunk/release_notes.txt (original)
+++ jakarta/commons/proper/httpclient/trunk/release_notes.txt Thu May 26 
11:31:15 2005
@@ -1,6 +1,6 @@
 Changes since Release Candidate 2:
 
- * 34961 - HttpClient now correctly handle escaped characters in HTTP header 
elements
+ * 34961 - HttpClient now correctly handles escaped characters in HTTP header 
elements
Contributed by Oleg Kalnichevski 
 
  * 34780 - HttpClient now always overrides the host of HostConfiguration if an 
absolute 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r178663 - /jakarta/commons/proper/httpclient/trunk/release_notes.txt

[olegk]

Author: olegk
Date: Thu May 26 11:30:31 2005
New Revision: 178663

URL: http://svn.apache.org/viewcvs?rev=178663&view=rev
Log:
PR #34961

Modified:
jakarta/commons/proper/httpclient/trunk/release_notes.txt

Modified: jakarta/commons/proper/httpclient/trunk/release_notes.txt
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/release_notes.txt?rev=178663&r1=178662&r2=178663&view=diff
==
--- jakarta/commons/proper/httpclient/trunk/release_notes.txt (original)
+++ jakarta/commons/proper/httpclient/trunk/release_notes.txt Thu May 26 
11:30:31 2005
@@ -1,10 +1,15 @@
 Changes since Release Candidate 2:
 
+ * 34961 - HttpClient now correctly handle escaped characters in HTTP header 
elements
+   Contributed by Oleg Kalnichevski 
+
  * 34780 - HttpClient now always overrides the host of HostConfiguration if an 
absolute 
request URI is given
+   Contributed by Oleg Kalnichevski 
 
  * 34740 - Connection with the proxy is not reopened if an proxy auth failure 
occurs 
while SSL tunnel is being established
+   Contributed by Oleg Kalnichevski 
 
  * 34721 - Virtual host setting is now correctly applied when parsing and 
matching 
cookies



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r178662 - in /jakarta/commons/proper/httpclient/trunk/src: java/org/apache/commons/httpclient/auth/ java/org/apache/commons/httpclient/cookie/ java/org/apache/commons/httpclient/util/ test/org/apache/commons/httpclient/

[olegk]

Author: olegk
Date: Thu May 26 11:21:14 2005
New Revision: 178662

URL: http://svn.apache.org/viewcvs?rev=178662&view=rev
Log:
PR #34961 (HttpClient does not correctly handle escaped characters in HTTP 
header elements)

Contributed by Oleg Kalnichevski
Reviewed by Ortwin Glück

Added:

jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/util/ParameterFormatter.java
   (with props)

jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/TestParameterFormatter.java
   (with props)
Modified:

jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/auth/DigestScheme.java

jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/cookie/RFC2109Spec.java

jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/util/ParameterParser.java

jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/TestNoHost.java

jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/TestParameterParser.java

Modified: 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/auth/DigestScheme.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/auth/DigestScheme.java?rev=178662&r1=178661&r2=178662&view=diff
==
--- 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/auth/DigestScheme.java
 (original)
+++ 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/auth/DigestScheme.java
 Thu May 26 11:21:14 2005
@@ -31,13 +31,17 @@
 
 import java.security.MessageDigest;
 import java.security.NoSuchAlgorithmException;
+import java.util.ArrayList;
+import java.util.List;
 import java.util.StringTokenizer;
 
 import org.apache.commons.httpclient.Credentials;
 import org.apache.commons.httpclient.HttpClientError;
 import org.apache.commons.httpclient.HttpMethod;
+import org.apache.commons.httpclient.NameValuePair;
 import org.apache.commons.httpclient.UsernamePasswordCredentials;
 import org.apache.commons.httpclient.util.EncodingUtil;
+import org.apache.commons.httpclient.util.ParameterFormatter;
 import org.apache.commons.logging.Log;
 import org.apache.commons.logging.LogFactory;
 
@@ -97,6 +101,7 @@
 private int qopVariant = QOP_MISSING;
 private String cnonce;
 
+private final ParameterFormatter formatter;
 /**
  * Default constructor for the digest authetication scheme.
  * 
@@ -105,6 +110,8 @@
 public DigestScheme() {
 super();
 this.complete = false;
+this.formatter = new ParameterFormatter();
+this.formatter.setAlwaysUseQuotes(true);
 }
 
 /**
@@ -138,8 +145,8 @@
  */
 public DigestScheme(final String challenge) 
   throws MalformedChallengeException {
-super(challenge);
-this.complete = true;
+this();
+processChallenge(challenge);
 }
 
 /**
@@ -431,7 +438,7 @@
 
 return serverDigest;
 }
-
+
 /**
  * Creates digest-response header as defined in RFC2617.
  * 
@@ -440,12 +447,12 @@
  * 
  * @return The digest-response as String.
  */
-private String createDigestHeader(String uname, String digest) throws 
AuthenticationException {
+private String createDigestHeader(final String uname, final String digest) 
+throws AuthenticationException {
 
 LOG.trace("enter DigestScheme.createDigestHeader(String, Map, "
 + "String)");
 
-StringBuffer sb = new StringBuffer();
 String uri = getParameter("uri");
 String realm = getParameter("realm");
 String nonce = getParameter("nonce");
@@ -455,22 +462,34 @@
 String qop = getParameter("qop");
 String algorithm = getParameter("algorithm");
 
-sb.append("username=\"" + uname + "\"")
-  .append(", realm=\"" + realm + "\"")
-  .append(", nonce=\"" + nonce + "\"").append(", uri=\"" + uri + "\"")
-  .append(", response=\"" + response + "\"");
+List params = new ArrayList(20);
+params.add(new NameValuePair("username", uname));
+params.add(new NameValuePair("realm", realm));
+params.add(new NameValuePair("nonce", nonce));
+params.add(new NameValuePair("uri", uri));
+params.add(new NameValuePair("response", response));
+
 if (qopVariant != QOP_MISSING) {
-sb.append(", qop=\"" + getQopVariantString() + "\"")
-  .append(", nc="+ NC)
-  .append(", cnonce=\"" + cnonce + "\"");
+params.add(new NameValuePair("qop", getQopVariantString()));
+params.add(new NameValuePair("nc", NC));
+params.add(new NameValuePair("cnonce", this.cnonce));
 }
 if (algorithm != null) {
-sb.append(", algor

[Jakarta-commons Wiki] Update of "MathWishList" by rodrigolopes

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" 
for change notification.

The following page has been changed by rodrigolopes:
http://wiki.apache.org/jakarta-commons/MathWishList

--
 * Support PRNG-pluggability throughout the random package - COMPLETED
 * Investigate alternative methods for generating values from discrete 
distributions [http://www.jstatsoft.org/v11/i03/]
   * Add sparse matrix implementation. 
[http://mail-archives.apache.org/eyebrowse/[EMAIL 
PROTECTED]&by=thread&from=736078]
+  * Add Vector implementation (RealVector would extend RealMatrix)
   * Add submatrix accessors - 
[http://issues.apache.org/bugzilla/show_bug.cgi?id=30896]
   * Develop Genetic Algorithms Framework 
[http://mail-archives.apache.org/eyebrowse/[EMAIL 
PROTECTED]&by=thread&from=882939]
   * Resampling [http://mail-archives.apache.org/eyebrowse/[EMAIL 
PROTECTED]&by=thread&from=582054]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Commons-Collections enhanced with Java Generics Support

[John Watkinson]

Hi Chris, you've made excellent points, which I'll address below:

---
1. The port appears to me to be a direct attempt to take the existing 
collections codebase and generify its API. It's an approach I initially 
took but abandoned after a while when I realised that much of the 
existing codebase was inappropriate for generifying. To clarify this, 
much of the current collections API is not typesafe, and raises problems 
when trying to generify it. For example, the ChainedTransformer class 
has a constructor that accepts a Collection. The javadoc indicates that 
this should be a collection of Transformer instances, and the resulting 
ChainedTransformer's transform method takes the input object and 
transforms it using each Transformer in the chain, returning the result. 
When generifying the class to ChainedTransformer, it's not 
possible to use the following constructor


  public ChainedTransformer(List> transformers)

because it's generally not possible to take the output of each of the 
chained Transformers and pass it into the next Transformer in the chain. 
After much consideration, it was decided that to maintain compile-time 
type safety, the behaviour of ChainedTransformer had to fundamentally 
change. This e-mail is already long enough, so I don't want to elaborate 
any further. The point I wish to make is that the collections.sf.net 
project addresses such issues by compromising type safety - it's 
constructor to ChainedTransformer is as follows


  public ChainedTransformer(Transformer[] transformers)

In this instance, the difficulties that generification raises have been 
skirted by sacrificing type-safety, and it's an approach that is taken 
throughout the collections.sf.net port of collections. I think this is 
an important point to consider, as probably the most important point of 
generics is to provide compile-time type-safety.

---

There are definitely some collections that don't take very well to 
generics. ChainedTransformer is one of the worst offenders, as it is not 
clear how it should be changed so as to make it support generics. Other 
collections that have problems are MultiMap and the TransforedXXX 
collections. However, there are some good solutions available for those, 
and we are working on them actively.


Our approach was to shoot for supporting generics in the majority of the 
classes. This was because we wanted to begin using the collections in 
1.5 in our own projects immediately, and there was no existing solution 
for us. Those classes that did not lend themselves well to generics were 
either not converted or were only partially converted. This way, the 
software worked right away and was a clear improvement over the 
non-generic collections. We agree that it has some short-comings in the 
partially-/non-converted areas and we look forward to working with 
everybody to resolve those in the best way possible.


It is our philosophy to not be bogged down by the more obscure cases 
(such as ChainedTransformer). Those few classes that just don't make 
sense at all from a generics point of view should perhaps just be 
labelled as such in the documentation.


---
2. Whilst the public API of the collections.sf.net port has been 
generified, the internal implementation is largely untouched. It's still 
the non-generic code that is present in the current  commons-collections 
codebase. From a black-box approach, this isn't especially important 
provided that the implementation honours the documented API. As I've 
mentioned earlier, this isn't the approach I've taken in 
collections15.sf.net, where all of the code has been fully generified, 
rather than just the API. This isn't a particular criticism of 
collections.sf.net - Sun's own implementation of ArrayList takes the 
same pragmatic approach - but it's just a difference I wanted to point 
out. I must say, however, that in the process of generifying all of the 
code in collections15.sf.net, a number of subtle improvements to the 
generified API became apparent that would not have been so had I only 
generified the public API. That this level of attention hasn't been paid 
to the implementation code in collections.sf.net, leads me to worry that 
the generification of the API isn't optimal, though I admit that this 
may be because my first stab at generifying the interfaces was not the 
best and so had to be changed a lot as I generified the implementing 
classes and the problems in the API became more apparent.

---

Yes, we feel that the some of the internal implementations are 
well-converted, but not all. We look forward to improving the use of 
generics in those classes and throughout the source. These refactors are 
important, but will not change the experience for the users of the library.


---
3. Here's my biggest worry. The unit tests in collections.sf.net don't 
appear to have been modified to reflect the generification of the APIs. 
The 100% success rate of the unit tests is therefore misleading, as it's 
mor

Re: [discovery] 0.3 release

[Rory Winston]

Henri Yandell <[EMAIL PROTECTED]> wrote:
 
> Not having SSH access seems a bit of a problem as a release manager.
> Updating the site, uploading the distributions all seem quite
> important components :)

Indeed. Nothing I can do about it right now, unfortunately.


> Take a look at the Lang release. I made a couple of RCs, and now
> Steven has made a bunch. Each time they were uploaded to
> people.apache.org (hard without SSH) and the community asked to check

Yes. I uploaded an RC previously to my Apache space and incorporated changes 
based on feedback to that RC.

> 
> a) Remove the links from the researchkitchen page for the moment.
> b) Hold for a few days until you get SSH back.
> c) Release them to your people.apache.org/~rwinston as an rc1 version
> (actually change the version in project.xml before building).
> d) Ask for opinions on the commons-dev list on the quality of the rc1.

Sure. I'm holding off until I get SSH access restored anyways. I've already 
been through the RC process, so I'm loath to kick it off again. I will, 
however, send an email to the PMC list. Thanks.


Rory



_
eircom broadband is now up to four times faster than before.
Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [discovery] 0.3 release

[Rory Winston]

Henri Yandell <[EMAIL PROTECTED]> wrote:
 
> Not having SSH access seems a bit of a problem as a release manager.
> Updating the site, uploading the distributions all seem quite
> important components :)

Indeed. Nothing I can do about it right now, unfortunately.


> Take a look at the Lang release. I made a couple of RCs, and now
> Steven has made a bunch. Each time they were uploaded to
> people.apache.org (hard without SSH) and the community asked to check

Yes. I uploaded an RC previously to my Apache space and incorporated changes 
based on feedback to that RC.

> 
> a) Remove the links from the researchkitchen page for the moment.
> b) Hold for a few days until you get SSH back.
> c) Release them to your people.apache.org/~rwinston as an rc1 version
> (actually change the version in project.xml before building).
> d) Ask for opinions on the commons-dev list on the quality of the rc1.

Sure. I'm holding off until I get SSH access restored anyways. I've already 
been through the RC process, so I'm loath to kick it off again. I will, 
however, send an email to the PMC list. Thanks.


Rory



_
eircom broadband is now up to four times faster than before.
Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34819] - [digester] NodeCreateRule Failing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34819





--- Additional Comments From [EMAIL PROTECTED]  2005-05-26 18:43 ---
(In reply to comment #4)
> Could you please pull the latest source from subversion and test?
> Or get a nightly build and test that...

Hmm - compile.tests in latest svn fails because gnu classpath doesn't yet
implement String.contains(CharSequence) -

[...]
[javac] Found 1 semantic error compiling
"/home/jablko/src/tmp/libcommons-digester-java/export/digester/trunk/src/test/org/apache/commons/digester/SetNestedPropertiesRuleTestCase.java":

[javac]182. if (msg.contains("badprop")) {
[javac] ^-^
[javac] *** Semantic Error: No accessible method with signature
"contains(java.lang.String)" was found in type "java.lang.String".
[...]


Not really worth reporting against classpath, however, since
Strin.contains(CharSequence) was added in java 1.5 & classpath isn't yet 1.5
compatible...

I may try back patching your changes to digester 1.6 & see how that works

Thanks sincerely for working on this!

Jack

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [doc] release procedure

[Henri Yandell]

On 5/21/05, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> They look a bit like something I do on Joda-Time, and vaguely similar to
>   [collections].
> 
> The basic idea is to link the latest version javadoc to a known fixed
> URL. To achieve this, each releases javadoc must be uploaded in a
> directory named api-1.1 or similar.
> 
> Thus your server contains:
>   api-1.0   (1.0 javadoc)
>   api-1.1   (1.1 javadoc)
>   apidocs   (SVN latest javadoc)
>   api   (Link to api-1.1)
> 
> I don't believe this in widespread use as a practice yet, although its a
> good idea.

Good idea, though I think it's something we should do at the release
level rather than inside each project/codebase.

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [discovery] 0.3 release

[Henri Yandell]

On 5/25/05, Rory Winston <[EMAIL PROTECTED]> wrote:
> Hi Simon,
> 
> Actually, I'm not a Discovery developer at all, I added my name to the 
> project.xml file (as Robert and Davinum did) so we could push out a release. 
> I have created a distribution release, however, I cannot push this to the 
> site as I have no FTP/SSH access at the moment. If anyone wants to get a hold 
> of the release version in a hurry, you can get them from here:
> 
> http://www.researchkitchen.co.uk/blog/commons-discovery-03/
> 
> These are the final versions, but they cannot be pushed to the Apache dist 
> directory at the moment. If this needs to be done anytime soon (i.e. in the 
> next few days), someone else will need to do it. I didnt anticipate being 
> stuck without either FTP or SSH access.
> 
> Rory

Not having SSH access seems a bit of a problem as a release manager.
Updating the site, uploading the distributions all seem quite
important components :)

The links on that page don't work, also you should probably be making
them release-candidiates rather than the real thing, if someone finds
a problem with the release, you may end up with an incorrect version
of 0.3 flying out there.

Take a look at the Lang release. I made a couple of RCs, and now
Steven has made a bunch. Each time they were uploaded to
people.apache.org (hard without SSH) and the community asked to check
them to see how they looked. Once they're considered good, lang will
do a release.

I'd suggest:

a) Remove the links from the researchkitchen page for the moment.
b) Hold for a few days until you get SSH back.
c) Release them to your people.apache.org/~rwinston as an rc1 version
(actually change the version in project.xml before building).
d) Ask for opinions on the commons-dev list on the quality of the rc1.

Also, I don't see a [RESULT] email for the original vote to release
Discovery, someone should tally the votes up and send that to
commons-dev (and Cc to [EMAIL PROTECTED]).

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23815] - [beanutils] PropertyUtils.getNestedProperty() doesn't allow getXxxx on Map-Instances any longer

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23815





--- Additional Comments From [EMAIL PROTECTED]  2005-05-26 15:35 ---
I think this compromise would suit all sides! I vote "Yes!" on this. :-)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35091] New: - DTD violation when using simple wrapping.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35091

   Summary: DTD violation when using simple wrapping.
   Product: Commons
   Version: unspecified
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Modeler
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


- using MBean implementation of sun j2sdk 1.5.0_02 win 32 bit

When just wrapping a class without overriding BaseModelMBean, a working
configuration looks like this:

 8< --

  



  

-- >8 

The class my.package.Pool:

 8< --
package my.package;

public class Pool
{
  Integer size = new Integer(42);
  public Pool(){}
  
  public Integer getSize() {
return size;
  }

  public void setSize(Integer size)
  {
this.size = size;
  }
}
-- >8 

The code to register the MBean inside the platform MBean server:

-- 8< 
  URL url= this.getClass().getResource("MBeanConfig.xml");
  Registry registry = Registry.getRegistry(null, null);
  registry.setMBeanServer(ManagementFactory.getPlatformMBeanServer());
  registry.loadMetadata(url);
  registry.loadMBeans(url);
--- >8 ---

The field viewed with jconsole (local connected) is
MBeans=>Tree=>myNonDefaultDomain=>Pool=>size = 42

Following the API-Docs one would expect
 8< --

  



  

-- >8 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23815] - [beanutils] PropertyUtils.getNestedProperty() doesn't allow getXxxx on Map-Instances any longer

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23815





--- Additional Comments From [EMAIL PROTECTED]  2005-05-26 11:04 ---
My summary of the situation:

When a lookup string "a.b" is passed to getNestedProperty and a implements the
Map interface then beanutils 1.7 always treats it as a Map only, and calls
a.get(b), even if there is a getB() method available. There is no way to access
the getter methods for standard properties on an object that also implements 
Map. 

Unfortunately, setNestedProperty acts differently. If a.setB(obj) is available
it gets called even if the object is a Map. Only if there is no appropriate
setter method does it call a.set("b").

This bugzilla request is to make the getter act like the setter.

--beanutils release history
beanutils 1.7 = 2004-08
beanutils 1.6.1 = 2003-02
beanutils 1.6 = 2003-01
beanutils 1.5 = 2002-10
beanutils 1.4 = 2002-08

-- PropertyUtils commit history
* in very early releases, map behaviour was not supported at all.
* r128486 by craigmcc (2001-08-22) added support for classes implementing Map.
However this behaviour was triggered only if "(" was in the name string,eg
"foo.bar(baz)". In other words, this change was backwards-compatible. Format
"a.b" always meant accessing a getB or setB method and never meant using a map
get("b") or set("b") method.
* r128586 (2002-07-16) by craigmcc deliberately changed the interpretation of
a.b to mean a.get("b") if a was a map, in order to be compatible with EL and
JSP2.0. This change was part of release 1.5 and of course broke backwards
compatibility with 1.4.
* r128642 (2002-11-26) by rdonkin introduced a change that made
setNestedProperty check for an explicit setter first before using the map, as a
response to bugzilla#14440. This partially restored compatibility with 1.4 for
setNestedProperty, but forgot to fix getNestedProperty. And it wasn't 100%
compatible with 1.5 as the map would never get updated if a property was
available. This was part of release 1.6.

It's really a rather unfortunate history.

So on to solutions.

We do, alas, need to make 1.7 incompatible with 1.6 :-(. Either we fix
setNestedProperty or we fix getNestedProperty; we clearly can't leave them
inconsistent.

How about we provide an option on class PropertyUtils that lets the user select:
 * map over props
   --> keep 1.6 behaviour for getNestedProperty
   --> breaks 1.6 compatibility with setNestedProperty
   --> the behaviour recommended by Craig McClanahan as being consistent
   with EL and JSP2.0
 * props over map
   --> keep the 1.6 behaviour for setNestedProperty
   --> breaks 1.6 compatibility with getNestedProperty
   --> the behaviour requested by this user and by #14440, and compatible with
   versions 1.4 and earlier.

Which is the default is debateable. I don't mind, and would probably let the
struts team decide.

Users could do
  PropertyUtilsBean.getInstance().setNestedPropertiesBehavior(
PropertyUtilsBean.PROPS_BEFORE_MAP);
or
  PropertyUtilsBean.getInstance().setNestedPropertiesBehavior(
PropertyUtilsBean.MAP_BEFORE_PROPS);


We then need to find all places where "if instanceof Map" is done and test the
user-selected behaviour to determine whether to check for a real property of the
specified name first.

Comments?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]