Re: Build failure

Hi Nick, Nicholas Lesiecki wrote: Team, I hope I got my build problems resolved, and that my passing tests now accurately reflect a successful build. If not I'll see what I can do tomorrow morning... At least here the full build is working again. Thanks! -- Christopher Lenz /=/ cmlenz at gmx.de -

cvs commit: jakarta-cactus/framework/src/java/share/org/apache/cactus RequestDirectives.java

cmlenz 2003/06/26 15:15:28 Modified:framework/src/java/share/org/apache/cactus RequestDirectives.java Log: Some cleanup, renamed addCactusCommand() to addDirective() and made it private, etc. Revision ChangesPath 1.2 +45 -53 jakarta-cact

cvs commit: jakarta-cactus/framework/src/java/share/org/apache/cactus WebRequest.java

cmlenz 2003/06/26 15:14:01 Modified:framework/src/java/share/org/apache/cactus WebRequest.java Log: Remove unused variable Revision ChangesPath 1.25 +1 -5 jakarta-cactus/framework/src/java/share/org/apache/cactus/WebRequest.java Index: WebRequest.java =

cvs commit: jakarta-cactus/framework/src/test/share/org/apache/cactus RequestDirectivesTest.java TestWebRequest.java

ndlesiecki2003/06/26 08:09:02 Modified:framework/src/test/share/org/apache/cactus TestWebRequest.java Added: framework/src/test/share/org/apache/cactus/util UniqueGeneratorTest.java framework/src/test/share/org/apache

cvs commit: jakarta-cactus/framework/src/java/share/org/apache/cactus RequestDirectives.java WebRequest.java AbstractWebServerTestCase.java

ndlesiecki2003/06/26 08:07:56 Modified:framework/src/java/share/org/apache/cactus/client/connector/http DefaultHttpClient.java framework/src/java/share/org/apache/cactus WebRequest.java AbstractWebServerTestCase.java Added:

cvs commit: jakarta-cactus checkstyle.xml

ndlesiecki2003/06/26 08:06:36 Modified:.checkstyle.xml Log: turned back on the check on private methods CVS: -- CVS: PR: CVS: If this change addresses a PR in the problem report tracking CVS: data

Build failure

Team, I hope I got my build problems resolved, and that my passing tests now accurately reflect a successful build. If not I'll see what I can do tomorrow morning... Cheers, nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For a

Re: Your commits

Hey, thanks. > etc. I wanted to say that it is not because I sent several emails that I > do not view your code positively. Quite the opposite! That's fine, I always welcome constructive criticism. Or even informational criticism. I just wish we could pair. Email discussions are so inefficient!

Re: cvs commit:jakarta-cactus/framework/src/java/share/org/apache/cactusAbstractWebServerTestCase.java

I implemented your general suggestions. I'm afraid I didn't understand very well what you meant by limiting the size of the key to 32 bits. By odd coincidence, my generated ids end up at approx. 32 characters. I don't think we should be too concerned about the exact number of bytes pushed about. If

Re: cvs commit:jakarta-cactus/samples/servlet/src/test-cactus/share/org/apache/cactus/sample/unit TestHttpSession.java

Bizarrely, this does not fail on my box. Maybe if I were to run against a another container... In any case, I made a change that I hope should fix it. And the tests still pass. I'm making this change on the plane, so I can't DL another container. Let me know if it works... Cheers, Nick On 6/23/03

[GUMP] Build Failure - jakarta-cactus-sample-servlet-13

isplay: [echo] - Cactus Servlet Sample 20030626 - [echo] java.class.path = /home/rubys/jakarta/xml-commons/java/external/build/xml-apis.jar:/home/rubys/jakarta/xml-xerces2/java/build/xmlParserAPIs.jar:/home/rubys/jakarta/xml-xerces2/java/build/xercesImpl.jar:.:/usr/java/j2sdk1.4.1_

[GUMP] Build Failure - jakarta-cactus-sample-servlet-12

isplay: [echo] - Cactus Servlet Sample 20030626 - [echo] java.class.path = /home/rubys/jakarta/xml-commons/java/external/build/xml-apis.jar:/home/rubys/jakarta/xml-xerces2/java/build/xmlParserAPIs.jar:/home/rubys/jakarta/xml-xerces2/java/build/xercesImpl.jar:.:/usr/java/j2sdk1.4.1_

Re: Unique ID like session ID?

Lesiecki Nicholas wrote: What do you all think of generating the uniqueId on the server side? The question of uniqueness then becomes much, much easier. We could simply store the id in a cookie cactus_test_id (like jsessionid) and have subsequent requests pull the value of the cookie from the respo