Re: [PATCH][HttpClient] bug 12607
Well it looks like the else is trying to correct the error where there is a spurious
'\r' by writing the full /r/n to
the output stream and trys again. But it doesn't try to correct for a '\n' in the
same way (it just writes it out in
state 0). This does not look particularly valuable.
Is it possible that we would be reading over some binary data that might have some
valid \r or \n hex values? In that
case we should try to correct for the spurious '\n' as well ... Otherwise throwing a
IOException seems prudent.
Ortwin Glück wrote:
As suggested by Martin Elwin.
Patch is for .../src/java/
Should we throw an Exception instead of this:
} else {
// this was not CRLF, so now write '\r' + this char
baos.write('\r');
baos.write(b);
state = 0;
}
I mean having \r inside a chunk size field is illegal and thus a
protocol violation. Comments from the real world?
? patch.diff
Index: org/apache/commons/httpclient/ChunkedInputStream.java
===
RCS file:
/home/cvspublic/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/ChunkedInputStream.java,v
retrieving revision 1.3
diff -u -w -r1.3 ChunkedInputStream.java
--- org/apache/commons/httpclient/ChunkedInputStream.java 12 Sep 2002 11:36:45
- 1.3
+++ org/apache/commons/httpclient/ChunkedInputStream.java 23 Sep 2002 14:13:24
-
@@ -134,7 +134,7 @@
nextChunk();
if (eof) return -1;
}
-len = Math.min(len, chunkSize);
+len = Math.min(len, chunkSize - pos);
int count = in.read(b, off, len);
pos += count;
return count;
@@ -172,22 +172,30 @@
*/
private static int getChunkSizeFromInputStream(final InputStream in) throws
IOException {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
-int b = in.read();
int state = 0;
while (state != 2) {
+int b = in.read();
if (b == -1) throw new IOException(chunked stream ended unexpectedly);
switch (state) {
case 0:
-if (b == '\r') state = 1;
+if (b == '\r') {
+state = 1;
+} else {
+baos.write(b);
+}
break;
case 1:
-if (b == '\n') state = 2;
-else state = 0;
+if (b == '\n') {
+state = 2;
+} else {
+// this was not CRLF, so now write '\r' + this char
+baos.write('\r');
+baos.write(b);
+state = 0;
+}
break;
default: throw new RuntimeException(assertion failed);
}
-if (state == 0) baos.write(b);
-if (state != 2) b = in.read();
}
//parse data
@@ -199,7 +207,7 @@
int result;
try {
-result = Integer.parseInt(dataString, 16);
+result = Integer.parseInt(dataString.trim(), 16);
} catch(NumberFormatException e) {
throw new IOException(Bad chunk size: +dataString);
}
Index: org/apache/commons/httpclient/HttpConnection.java
===
RCS file:
/home/cvspublic/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java,v
retrieving revision 1.20
diff -u -w -r1.20 HttpConnection.java
--- org/apache/commons/httpclient/HttpConnection.java 8 Sep 2002 05:35:09 -
1.20
+++ org/apache/commons/httpclient/HttpConnection.java 23 Sep 2002 14:13:26 -
@@ -455,7 +455,7 @@
*/
public InputStream getResponseInputStream(HttpMethod method)
throws IOException, IllegalStateException {
-log.trace(enter HttpConnection.getRequestOutputStream(HttpMethod));
+log.trace(enter HttpConnection.getResponseInputStream(HttpMethod));
assertOpen();
return _input;
}
Index: org/apache/commons/httpclient/WireLogInputStream.java
===
RCS file:
/home/cvspublic/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/WireLogInputStream.java,v
retrieving revision 1.3
diff -u -w -r1.3 WireLogInputStream.java
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For
DO NOT REPLY [Bug 8787] - Indexed field validation patch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8787. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8787 Indexed field validation patch --- Additional Comments From [EMAIL PROTECTED] 2002-09-24 07:37 --- You can validate indexed properties using the Validator. The trick is, you can't validate an individual indexed property. For example, if Bean Foo has a property Bar which is an array of values, you can validate the entire array. But you can't validate an individual value by itself (Bar[5] for example) Do you have a need to validate one specific entry in a Collection? Or would validating the entire Collection be ok? James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [HttpClient] [prelim-PATCH] NTLM Authentication
Hey Adrian, NTLM support is targeted as a HttpClient 2.1 feature on the bug you raised: http://issues.apache.org/bugzilla/show_bug.cgi?id=10851 There has not been a feature freeze for 2.0 yet, so we're still open to adding this earlier. There was also the idea for adding plugable authentication modules for just this purpose as well. You obviously have need for NTLM, so I'm OK with moving this up, with a few caveats: 1) Using the JCE is preferable to a seperate DES class. It must only be required at runtime if the NTLM auth code is actually executed (similar to how https works currently) 2) Testing for this is going to be difficult. A nice complete JUnit test suite is going to be necessisary 3) Need assurance that all code (particularly NTLM.java) is free to be licenced under the Apache software license. From my perspective, if you can meet these requirements, then NTLM is good to go for 2.0 BTW: Integration into Authenticator looks like the logical, minimal approach. Pluggable authentication modules can just be left as a future enhancement. I have now completed a patch to add NTLM authentication to the latest version of HttpClient, however there are a couple of issues remaining so it should considered beta-patch at this point and this is really a request for comment rather than a request for commit. The issues are: 1. Does not comply with current coding style of HttpClient - particularly in the new files. 2. Needs improvement to logging 3. Requires the Java Cryptography Extensions The first two just require me to get around to it, the third I'd like some comments on. My preference is to not depend on JCE and to implement DES encryption ourselves in a standalone form. To that end I have implemented the DES encryption through a wrapper file so that it is simple to switch later if required. Note that JCE does not work with JRE 1.1 at all and is an optional add on for 1.2 and 1.3. I recieved no reply from an email sent to the author of the DES encryption class I have previously mentioned and two of the author's email addresses bounced so chance of relicencing it under the Apache License is pretty much nil at this point. I have done some more research and found that the MD4 encryption can be avoided by using the Windows 98 version of the protocol which seems to be more reliable anyway. Any thoughts, comments or cryptography experts? The other thing I would like confirmation on is that the integration into HttpClient (in Authenticator.java) is the best way to do it. It certainly seems like it is, but I can't be certain of that since I don't know the HttpClient code particularly well. Thanks in advance, -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: VOTE: Release 1.0 of Validator
Hi James, Will expanded documentation be part of a release? I'm currently trying to use commons-validator in a stand-alone program (outside of Struts), but I'm having a hard time. I know that there's always the source to read, but I wouldn't object to: 1) A DTD of XSD file defining the configuration format (yes, I know it's simple, but it's good to specify things like these) 2) An explanation of how elements in the .xml configuration file map to members of the runtime object model -The mapping is absolutely nonintuitive (This is what I've figured out, I may be wrong): a validator element - an action at runtime? a name attrubute of a msg element - is referred to as the key 3) Improve the general documentation. For instance: what are Result Values? (from the getResultValueMap()). But even more important is a explanation of why to use something. (When do such Result Values come in handy?) Some (commented) sample code describing the most commons scenarios: -How do I reuse resources? Where do I put these and how do I refer to them? -How to internationalize resources? -How to write a new validator? -And *why the hell* should I call validator.addResource(java.util.List, myList) just to get some errors? I'd expect a validation framework to have a more robust way of error reporting. Anyway, if there's a good reason for this, document it. 4) General behaviour and flow of control. I've written a couple of validators and connected these to a field using depends=validateA,validateB Yet always, B is called first, and A is *always* called as well, no matter what the outcome of B was. It may be that I got I bad nightly release, but there no way to know by reading the documentation. Write down what the thing is supposed to actually do. Regards, tt -Original Message- From: James Turner [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 9:39 AM To: [EMAIL PROTECTED] Subject: VOTE: Release 1.0 of Validator Hi all, Validator should have a release before packages likes Struts make releases based on it. Therefore I am proposing to do a 1.0 release on 1 November, and volunteering to release manage it. There are at present very few bugs against Validator (6), some of which are either already closeable or could be fixed with little effort. However, I am about to release a near-complete rewrite of the core Validator methods (following the consensus of the previous vote on that matter), and want to give the new code some time to settle in and be tested before freeze. The proposed schedule is: 1 October - Feature freeze for Validator 1.0 15 October - Code freeze for Validator 1.0 1 November - Final Release Build The current outstanding bugs to fix in Validator before release are: 7318 javascript: zero - means bad integer?? 7349 Date Validation passes invalid date 8787 Indexed field validation patch 10584 Not all validation files are read in Validation PlugIn 10780 A few refactorings to Validator.java 10782 If two fields are required, and one has a mask, the mask is Please vote as follows: +1: I'm in favor of a Validator 1.0 release according to the schedule outlined 0: Like I care? -1: I have an objection either to the schedule, the release, or the choice of release manager (please specify) 3.1415926: I am an irrational person James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [HttpClient] Preferences Architecture Implementation Draft
Jeff Dever wrote: Hey Odi, I just made a few minor additions. Included. We also have to be careful of the NumberFormatExceptions that will be thrown by the parseInt() type calls. Perhaps there should be a ConfigurationException? Yes I was thinking about this as well. Problem here: you have to catch those ConfigurationExceptions somewhere (looks ugly) or make ConfigurationException a RuntimeException. Also I think that these related classes should be in their own package, such as httpclient.config. Yes why not. I am a little concerned about the use of the configuration object. I would expect calls to this to look like: String httpVersion = config.getStringValue(http.version); It seems a little verbose if it has to be used frequently. True but I don't see a shorter way to do it really. Do you? Of course we could use shorter method names... At the same time, we will have to be careful not to cache these values in case a user changes the config value during runtime. I really have to think the architecture over again. Maybe Configuration will not be immutable. We need one Configuration instance that can be shared among HttpClient or a HttpConnection and its Methods. This OR makes things really difficult. Who should hold the configuration object? I don't want the user having to supply a Configuration object. He should only need to supply Properties (patches) if needed. Making it a singleton does not help because we may want several HttpClients that use different settings. I think that this is a pretty good start. There are some bugs for configuration that are already opened: http://issues.apache.org/bugzilla/show_bug.cgi?id=10790 http://issues.apache.org/bugzilla/show_bug.cgi?id=10791 http://issues.apache.org/bugzilla/show_bug.cgi?id=10797 These bugs are targeted for HttpClient 2.1. Question: do people want this in the 2.0 release? I want it :-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [HttpClient] Preferences Architecture Implementation Draft
Question: do people want this in the 2.0 release? I want it :-) Me too! Go Odi! Not sure, though, if using the Configuration object directly during runtime is the prefered method. An idea might be to notify the different components (HttpConnection, HttpMethod, HttpState, etc) when they should reconsider the configuration parameters (after a runtime change for instance). Internally the components can cache the values or do whatever suits them... Kindly, /M -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core SetPropertiesTag.java CoreTagLibrary.java
jstrachan2002/09/24 03:55:59
Modified:jelly/src/java/org/apache/commons/jelly/tags/core
CoreTagLibrary.java
Added: jelly/src/java/org/apache/commons/jelly/tags/core
SetPropertiesTag.java
Log:
Added support for a j:setProperties tag which can make creating beans and setting
properties on them much simpler.
e.g.
j:new var=customer className=com.acme.MyCustomer/
j:setProperties object=${customer} name=James location=London
orders=${foo.findOrders()}/
Revision ChangesPath
1.15 +6 -5
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core/CoreTagLibrary.java
Index: CoreTagLibrary.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core/CoreTagLibrary.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- CoreTagLibrary.java 15 Jul 2002 15:06:19 - 1.14
+++ CoreTagLibrary.java 24 Sep 2002 10:55:59 - 1.15
@@ -99,6 +99,7 @@
// extensions to JSTL
registerTag(expr, ExprTag.class);
registerTag(new, NewTag.class);
+registerTag(setProperties, SetPropertiesTag.class);
registerTag(whitespace, WhitespaceTag.class);
registerTag(thread, ThreadTag.class);
registerTag(file, FileTag.class);
1.1
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core/SetPropertiesTag.java
Index: SetPropertiesTag.java
===
/*
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2002 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Commons, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*/
package org.apache.commons.jelly.tags.core;
import java.util.Map;
import org.apache.commons.beanutils.BeanUtils;
import org.apache.commons.jelly.MissingAttributeException;
import org.apache.commons.jelly.MapTagSupport;
import org.apache.commons.jelly.XMLOutput;
/**
* A tag which sets the bean properties on the given bean.
* So if you used it as follows, for example using the lt;j:newgt; tag.
* pre
* lt;j:new className=com.acme.Person var=person/gt;
* lt;j:setProperties
cvs commit: jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/define Customer.java
jstrachan2002/09/24 04:03:57
Modified:jelly/src/test/org/apache/commons/jelly/define Customer.java
Log:
Added support for a j:setProperties tag which can make creating beans and setting
properties on them much simpler.
e.g.
j:new var=customer className=com.acme.MyCustomer/
j:setProperties object=${customer} name=James location=London
orders=${foo.findOrders()}/
Revision ChangesPath
1.2 +4 -0
jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/define/Customer.java
Index: Customer.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/define/Customer.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Customer.java 17 Jul 2002 17:38:16 - 1.1
+++ Customer.java 24 Sep 2002 11:03:57 - 1.2
@@ -84,6 +84,10 @@
}
+public String toString() {
+return super.toString() + [name= + name + ;city= + city + ];
+}
+
// Properties
//-
/**
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly suite.jelly
jstrachan2002/09/24 04:04:56
Modified:jelly/src/test/org/apache/commons/jelly suite.jelly
Log:
Added support for a j:setProperties tag which can make creating beans and setting
properties on them much simpler.
e.g.
j:new var=customer className=com.acme.MyCustomer/
j:setProperties object=${customer} name=James location=London
orders=${foo.findOrders()}/
Revision ChangesPath
1.2 +24 -1
jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/suite.jelly
Index: suite.jelly
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/suite.jelly,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- suite.jelly 11 Aug 2002 11:45:19 - 1.1
+++ suite.jelly 24 Sep 2002 11:04:56 - 1.2
@@ -1,5 +1,8 @@
?xml version=1.0?
-test:suite xmlns:j=jelly:core xmlns:test=jelly:junit xmlns:x=jelly:xml
+test:suite
+ xmlns:j=jelly:core
+ xmlns:test=jelly:junit
+ xmlns:log=jelly:log
test:case name=testChoose
@@ -63,4 +66,24 @@
/test:case
+ test:case name=testNewAndSetProperties
+ j:new className=org.apache.commons.jelly.define.Customer
var=customer/
+ j:setProperties object=${customer} name=James city=London /
+
+ log:infoCreated a new bean: ${customer}/log:info
+
+ test:assert test=${customer != null}Created a customer
DynaBean/test:assert
+
+ test:assertEquals
+ expected=James
+ actual=${customer.name}/
+
+ test:assertEquals
+ expected=London
+ actual=${customer.city}/
+
+ test:assertEquals
+ expected=org.apache.commons.jelly.define.Customer
+ actual=${customer.class.name}/
+ /test:case
/test:suite
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core UseBeanTag.java CoreTagLibrary.java
jstrachan2002/09/24 04:38:53 Modified:jelly/src/java/org/apache/commons/jelly/tags/core CoreTagLibrary.java Added: jelly/src/java/org/apache/commons/jelly/tags/core UseBeanTag.java Log: Added a j:useBean tag to both mimick the similar JSP tag but also to combine it with the j:setProperties tag so that a fully configured bean can be created easily by a single tag. j:useBean var=foo class=com.acme.MyCustomer name=James location=London role=Hacker/ Where the above will create a new variable called 'foo' of type com.acme.MyCustomer and then will set the name, location and role properties to the values given. This tag is also useful as a base class for constructing arbitrary objects of certain kinds that can be configured and used in some script - such as to plug in arbitrary Actions into a workflow style script or in a simple testing framework etc. Revision ChangesPath 1.16 +6 -5 jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core/CoreTagLibrary.java Index: CoreTagLibrary.java === RCS file: /home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core/CoreTagLibrary.java,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- CoreTagLibrary.java 24 Sep 2002 10:55:59 - 1.15 +++ CoreTagLibrary.java 24 Sep 2002 11:38:53 - 1.16 @@ -100,6 +100,7 @@ registerTag(expr, ExprTag.class); registerTag(new, NewTag.class); registerTag(setProperties, SetPropertiesTag.class); +registerTag(useBean, UseBeanTag.class); registerTag(whitespace, WhitespaceTag.class); registerTag(thread, ThreadTag.class); registerTag(file, FileTag.class); 1.1 jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core/UseBeanTag.java Index: UseBeanTag.java === /* * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999-2002 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowlegement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names The Jakarta Project, Commons, and Apache Software *Foundation must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Group. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. */ package org.apache.commons.jelly.tags.core; import java.util.Map; import
cvs commit: jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly suite.jelly
jstrachan2002/09/24 04:39:50
Modified:jelly/src/test/org/apache/commons/jelly suite.jelly
Log:
Added a j:useBean tag to both mimick the similar JSP tag but also to combine it
with the j:setProperties tag so that a fully configured bean can be created easily
by a single tag.
j:useBean var=foo class=com.acme.MyCustomer name=James location=London
role=Hacker/
Where the above will create a new variable called 'foo' of type com.acme.MyCustomer
and then will set the name, location and role properties to the values given.
This tag is also useful as a base class for constructing arbitrary objects of
certain kinds that can be configured and used in some script - such as to plug in
arbitrary Actions into a workflow style script or in a simple testing framework etc.
Revision ChangesPath
1.3 +21 -1
jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/suite.jelly
Index: suite.jelly
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/suite.jelly,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- suite.jelly 24 Sep 2002 11:04:56 - 1.2
+++ suite.jelly 24 Sep 2002 11:39:50 - 1.3
@@ -72,7 +72,27 @@
log:infoCreated a new bean: ${customer}/log:info
- test:assert test=${customer != null}Created a customer
DynaBean/test:assert
+ test:assert test=${customer != null}Created a customer
bean/test:assert
+
+ test:assertEquals
+ expected=James
+ actual=${customer.name}/
+
+ test:assertEquals
+ expected=London
+ actual=${customer.city}/
+
+ test:assertEquals
+ expected=org.apache.commons.jelly.define.Customer
+ actual=${customer.class.name}/
+ /test:case
+
+ test:case name=testUseBean
+ j:useBean var=customer
class=org.apache.commons.jelly.define.Customer name=James city=London /
+
+ log:infoCreated a new bean: ${customer}/log:info
+
+ test:assert test=${customer != null}Created a customer
bean/test:assert
test:assertEquals
expected=James
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[GUMP] Build Failure - commons-latka
This email is autogenerated from the output from:
http://jakarta.apache.org/builds/gump/2002-09-24/commons-latka.html
Buildfile: build.xml
init:
[echo] latka 1.0-dev
jaxen-warn:
build-java:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/latka/target/classes
[javac] Compiling 71 source files to
/home/rubys/jakarta/jakarta-commons/latka/target/classes
[javac]
/home/rubys/jakarta/jakarta-commons/latka/src/java/org/apache/commons/latka/http/RequestImpl.java:307:
exception org.apache.commons.httpclient.HttpException has already been caught
[javac] } catch (HttpException e) {
[javac] ^
[javac] 1 error
BUILD FAILED
file:/home/rubys/jakarta/jakarta-commons/latka/build.xml:298: Compile failed; see the
compiler error output for details.
Total time: 4 seconds
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: VOTE: Release 1.0 of Validator
Taras, These are all excellent ideas. Would it be possible for you to submit a patch for one/all of these? You're input is very much welcomed and we would like to invite you to participate even more. Thanks, Scott Sanders -Original Message- From: Taras Tielkes [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 1:44 AM To: 'Jakarta Commons Developers List' Subject: RE: VOTE: Release 1.0 of Validator Hi James, Will expanded documentation be part of a release? I'm currently trying to use commons-validator in a stand-alone program (outside of Struts), but I'm having a hard time. I know that there's always the source to read, but I wouldn't object to: 1) A DTD of XSD file defining the configuration format (yes, I know it's simple, but it's good to specify things like these) 2) An explanation of how elements in the .xml configuration file map to members of the runtime object model -The mapping is absolutely nonintuitive (This is what I've figured out, I may be wrong): a validator element - an action at runtime? a name attrubute of a msg element - is referred to as the key 3) Improve the general documentation. For instance: what are Result Values? (from the getResultValueMap()). But even more important is a explanation of why to use something. (When do such Result Values come in handy?) Some (commented) sample code describing the most commons scenarios: -How do I reuse resources? Where do I put these and how do I refer to them? -How to internationalize resources? -How to write a new validator? -And *why the hell* should I call validator.addResource(java.util.List, myList) just to get some errors? I'd expect a validation framework to have a more robust way of error reporting. Anyway, if there's a good reason for this, document it. 4) General behaviour and flow of control. I've written a couple of validators and connected these to a field using depends=validateA,validateB Yet always, B is called first, and A is *always* called as well, no matter what the outcome of B was. It may be that I got I bad nightly release, but there no way to know by reading the documentation. Write down what the thing is supposed to actually do. Regards, tt -Original Message- From: James Turner [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 9:39 AM To: [EMAIL PROTECTED] Subject: VOTE: Release 1.0 of Validator Hi all, Validator should have a release before packages likes Struts make releases based on it. Therefore I am proposing to do a 1.0 release on 1 November, and volunteering to release manage it. There are at present very few bugs against Validator (6), some of which are either already closeable or could be fixed with little effort. However, I am about to release a near-complete rewrite of the core Validator methods (following the consensus of the previous vote on that matter), and want to give the new code some time to settle in and be tested before freeze. The proposed schedule is: 1 October - Feature freeze for Validator 1.0 15 October - Code freeze for Validator 1.0 1 November - Final Release Build The current outstanding bugs to fix in Validator before release are: 7318 javascript: zero - means bad integer?? 7349 Date Validation passes invalid date 8787 Indexed field validation patch 10584 Not all validation files are read in Validation PlugIn 10780 A few refactorings to Validator.java 10782 If two fields are required, and one has a mask, the mask is Please vote as follows: +1: I'm in favor of a Validator 1.0 release according to the schedule outlined 0: Like I care? -1: I have an objection either to the schedule, the release, or the choice of release manager (please specify) 3.1415926: I am an irrational person James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly TagLibrary.java
jstrachan2002/09/24 09:49:40
Modified:jelly/src/java/org/apache/commons/jelly/tags/ant
AntTagLibrary.java
jelly/src/java/org/apache/commons/jelly TagLibrary.java
Log:
Minor refactor to add the String - File converter to the standard Jelly libraries
rather than leaving it in the Ant tag library.
Revision ChangesPath
1.22 +0 -17
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/ant/AntTagLibrary.java
Index: AntTagLibrary.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/ant/AntTagLibrary.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- AntTagLibrary.java23 Sep 2002 12:35:22 - 1.21
+++ AntTagLibrary.java24 Sep 2002 16:49:40 - 1.22
@@ -61,8 +61,6 @@
*/
package org.apache.commons.jelly.tags.ant;
-import java.io.File;
-
import org.apache.commons.beanutils.ConvertUtils;
import org.apache.commons.beanutils.Converter;
import org.apache.commons.grant.GrantProject;
@@ -101,21 +99,6 @@
// register standard converters for Ant types
-ConvertUtils.register(
-new Converter() {
-public Object convert(Class type, Object value) {
-if ( value instanceof File ) {
-return (File) value;
-}
-else if ( value != null ) {
-String text = value.toString();
-return new File( text );
-}
-return null;
-}
-},
-File.class
-);
ConvertUtils.register(
new Converter() {
1.14 +30 -5
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/TagLibrary.java
Index: TagLibrary.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/TagLibrary.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- TagLibrary.java 5 Sep 2002 16:43:29 - 1.13
+++ TagLibrary.java 24 Sep 2002 16:49:40 - 1.14
@@ -62,9 +62,13 @@
package org.apache.commons.jelly;
+import java.io.File;
import java.util.HashMap;
import java.util.Map;
+import org.apache.commons.beanutils.ConvertUtils;
+import org.apache.commons.beanutils.Converter;
+
import org.apache.commons.jelly.expression.CompositeExpression;
import org.apache.commons.jelly.expression.ConstantExpression;
import org.apache.commons.jelly.expression.Expression;
@@ -82,6 +86,27 @@
public abstract class TagLibrary {
private Map tags = new HashMap();
+
+static {
+
+// register standard converters
+
+ConvertUtils.register(
+new Converter() {
+public Object convert(Class type, Object value) {
+if ( value instanceof File ) {
+return (File) value;
+}
+else if ( value != null ) {
+String text = value.toString();
+return new File( text );
+}
+return null;
+}
+},
+File.class
+);
+}
public TagLibrary() {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Test suites
Hello, I am curious as to how you have been approaching building tests for peculiar behavior of HTTP servers. I am having issues with particular HTTP servers in 1.1 mode with chunking, so I want to build a test for it without introducing a dependency on the uptime or software version of a particular server on the internet. How have you solved this problem in the past? -- Ryan Hoegg ISIS Networks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH][HttpClient] bug 12607
I went back to RFC2616 to find this (3.6.1): Chunked-Body = *chunk last-chunk trailer CRLF chunk = chunk-size [ chunk-extension ] CRLF chunk-data CRLF chunk-size = 1*HEX last-chunk = 1*(0) [ chunk-extension ] CRLF chunk-extension= *( ; chunk-ext-name [ = chunk-ext-val ] ) chunk-ext-name = token chunk-ext-val = token | quoted-string chunk-data = chunk-size(OCTET) trailer= *(entity-header CRLF) and this (2.2): token = 1*any CHAR except CTLs or separators Since chunk-extension includes only tokens and an = I read this to say that neither \r or \n is allowed before the first CRLF in a chunk. -- Ryan Hoegg ISIS Networks Ortwin Glück wrote: Not sure if single \n or \r is allowed here or not. Maybe leave it as it is. Real world guys anyone? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12152] - Combined property access ( b.mapped(bar/foo) ) throws excception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12152. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12152 Combined property access ( b.mapped(bar/foo) ) throws excception --- Additional Comments From [EMAIL PROTECTED] 2002-09-24 18:43 --- This seems to be the same problem as #10478 for which a patch has been submitted to [EMAIL PROTECTED] recently. Please verify. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/beanutils/src/test/org/apache/commons/beanutils PropertyUtilsTestCase.java TestBean.java
rdonkin 2002/09/24 11:45:54
Modified:beanutils/src/java/org/apache/commons/beanutils
PropertyUtils.java
beanutils/src/test/org/apache/commons/beanutils
PropertyUtilsTestCase.java TestBean.java
Log:
Fix for bug #10478. Submitted by Roland Huss.
Revision ChangesPath
1.31 +8 -5
jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/PropertyUtils.java
Index: PropertyUtils.java
===
RCS file:
/home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/PropertyUtils.java,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- PropertyUtils.java21 Jul 2002 00:20:44 - 1.30
+++ PropertyUtils.java24 Sep 2002 18:45:54 - 1.31
@@ -708,8 +708,11 @@
int indexOfMAPPED_DELIM2 = -1;
int indexOfNESTED_DELIM = -1;
while (true) {
+indexOfNESTED_DELIM = name.indexOf(NESTED_DELIM);
+indexOfMAPPED_DELIM = name.indexOf(MAPPED_DELIM);
indexOfMAPPED_DELIM2 = name.indexOf(MAPPED_DELIM2);
-if (indexOfMAPPED_DELIM2 = 0) {
+if (indexOfMAPPED_DELIM2 = 0 indexOfMAPPED_DELIM =0
+(indexOfNESTED_DELIM 0 || indexOfNESTED_DELIM
indexOfMAPPED_DELIM)) {
indexOfNESTED_DELIM =
name.indexOf(NESTED_DELIM, indexOfMAPPED_DELIM2);
} else {
1.22 +14 -4
jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java
Index: PropertyUtilsTestCase.java
===
RCS file:
/home/cvs/jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- PropertyUtilsTestCase.java21 Jul 2002 00:20:45 - 1.21
+++ PropertyUtilsTestCase.java24 Sep 2002 18:45:54 - 1.22
@@ -1103,6 +1103,16 @@
fail(Thew exception: + e);
}
+try
+{
+assertEquals(Can't retrieved nested with mapped property,
+ Mapped Value,
+ PropertyUtils.getNestedProperty(
+ bean,mappedNested.value(Mapped Key)));
+} catch (Exception e)
+{
+fail(Thew exception: + e);
+}
}
1.13 +23 -5
jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/TestBean.java
Index: TestBean.java
===
RCS file:
/home/cvs/jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/TestBean.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- TestBean.java 22 Jul 2002 00:02:01 - 1.12
+++ TestBean.java 24 Sep 2002 18:45:54 - 1.13
@@ -347,6 +347,24 @@
}
+/*
+ * Another nested reference to a bean containing mapp properties
+ */
+class MappedTestBean {
+public void setValue(String key,String val) { }
+public String getValue(String key) { return Mapped Value; }
+}
+
+private MappedTestBean mappedNested = null;
+
+public MappedTestBean getMappedNested() {
+if (mappedNested == null)
+{
+mappedNested = new MappedTestBean();
+}
+return mappedNested;
+}
+
/**
* A String property with an initial value of null.
*/
@@ -442,7 +460,7 @@
this.writeOnlyProperty = writeOnlyProperty;
}
-
+
// --- Static Variables
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10478] - Can't use . (dot) in mapped properties
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10478. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10478 Can't use . (dot) in mapped properties [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-09-24 18:54 --- commited patch submitted by Roland Huss. (thanks) hopefully this bug might stay fixed now :) - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12152] - Combined property access ( b.mapped(bar/foo) ) throws excception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12152. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12152 Combined property access ( b.mapped(bar/foo) ) throws excception [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-09-24 18:59 --- i concur. i've just committed the fix for #10478 so please test again against CVS HEAD. if the problem is still present then please reopen this bug report. - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[HttpClient] RE: Test suites
I am curious as to how you have been approaching building tests for peculiar behavior of HTTP servers. I don't think we have a good solution to this yet. Right now the httpclient tests fall into three cases: 1. pure unit tests - These simply exercise the classes directly, with no external dependencies. These are the tests that are executed by the test-nohost ant target, and are bundled into a Suite under org.apache.commons.httpclient.TestAllLocal. 2. webapp tests - These tests interact with a known webapp, typically running locally. The webapp is built using the compile.test-webapp target. This webapp needs to be deployed to some app server, and that server needs to be running in order to execute the tests. These are the tests that are executed by the test-webapp target, and are bundled into a suite under org.apache.commons.httpclient.TestAllWebapp. 3. internet tests - These tests interact with various servers out on the public internet (largely these are just the SSL tests). You need an internet connection to execute them, and obviously the external server needs to be up and running. These are the tests that are executed by the test-external target, and are bundled into a suite under org.apache.commons.httpclient.TestAllExternal. The test target executes all three of these suites. It should be possible to replace many of the category 2 and 3 tests with a mock server running in process and providing canned responses (or introspecting canned requests). This may prove complicated in implementation, but would certainly ease the configuration/external-dependency burdens in running the tests. A minor refactoring that makes it easier to plug in a response stream (or grab the request stream) in HttpConnection may simplify matters. I'd be willing to help out a bit with that, if someone wants to get it started. Otherwise I think the order above is preferred (i.e., if you can't add it as a pure test, use the webapp, and only if you can't easily add it to the webapp, rely upon some external server). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[beanutils] second opinion on bug #12728 please
(this is probably directed at scott or craig) could someone take a look at http://issues.apache.org/bugzilla/show_bug.cgi?id=12728 and give a second opinion? (i don't understand why this change is needed.) - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12728] - Cache Bug in the PropertyUtils.java line 889
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12728. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12728 Cache Bug in the PropertyUtils.java line 889 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2002-09-24 22:13 --- The patch attached to 12544 is correct. All that is being done is if the descriptor is not cached, it needs to be for future lookups. Scott -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Bugzilla Maintenance
Thanks Scott. On Tue, 24 Sep 2002, Scott Sanders wrote: After sending an email to root@nagoya, I found out that Craig is the annointed BugZilla guy for commons. Craig, would it be possible to get lang added as a component of the commons product? Thanks, Scott Sanders Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [HttpClient] [prelim-PATCH] NTLM Authentication
NTLM support is targeted as a HttpClient 2.1 feature on the bug you raised: http://issues.apache.org/bugzilla/show_bug.cgi?id=10851 There has not been a feature freeze for 2.0 yet, so we're still open to adding this earlier. There was also the idea for adding plugable authentication modules for just this purpose as well. You obviously have need for NTLM, so I'm OK with moving this up, with a few caveats: My original intent was to wait for plugable authentication modules however the schedule pressures that I'm under decreed that it had to be done now. I figure that I may as well do it in a way that can easily be incorporated back into HttpClient so that others can gain some use out of it as well. To do that though I need to run it past the experts here on the list as this is my first modifications to HttpClient or in fact any Jakarta project. Thanks for your help. It would be excellent if this could make the 2.0 release, particularly so if that release were to happen before our product has to ship. Regardless, we use only a small subset of the HttpClient functionality so we'd be happy with using a CVS version and putting it through our testing proceedures as we're yet to find any issues with the current CVS builds. 1) Using the JCE is preferable to a seperate DES class. It must only be required at runtime if the NTLM auth code is actually executed (similar to how https works currently) Okay, I will fold the DES stuff into the main NTLM class and ensure it is not needlessly required. 2) Testing for this is going to be difficult. A nice complete JUnit test suite is going to be necessisary Agreed. I'll base these off of the tests for the other authentication methods. 3) Need assurance that all code (particularly NTLM.java) is free to be licenced under the Apache software license. I can provide that assurance now since we will be using the JCE for encryption. BTW: Integration into Authenticator looks like the logical, minimal approach. Pluggable authentication modules can just be left as a future enhancement. Good to hear. Thanks for your assistance Jeff, you (and many others) are doing an sensational job around here. Yours, Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com This email and any files transmitted with it are confidential and intended solely for the use of the individual to whom they are addressed. Opinions contained in this email do not necessarily reflect the opinions of Ephox Corporation. If you have received this email in error please notify the sender immediately and delete all copies of the correspondence from your computer and/or computer network. No warranty is given that this message upon its receipt is virus free and the sender in this respect accepts no liability. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/lang RELEASE-NOTES.txt
bayard 2002/09/24 18:33:06 Modified:lang RELEASE-NOTES.txt Log: Release notes for Lang 1.0. Revision ChangesPath 1.3 +130 -18 jakarta-commons/lang/RELEASE-NOTES.txt Index: RELEASE-NOTES.txt === RCS file: /home/cvs/jakarta-commons/lang/RELEASE-NOTES.txt,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- RELEASE-NOTES.txt 25 Jul 2002 22:44:29 - 1.2 +++ RELEASE-NOTES.txt 25 Sep 2002 01:33:06 - 1.3 @@ -1,34 +1,146 @@ $Id$ Commons Lang Package -Version 1.0-b1 +Version 1.0 Release Notes INTRODUCTION: This document contains the release notes for this version of the Commons -Lang package. +Lang package. Commons Lang is a set of utility functions and reusable +components that should be a help in any Java environment. -There is a high demand for the functionality found in Commons Lang in other -Jakarta projects. Some are already using it, often because they submitted -the original code, other times because they find the functionality useful, -and other times because they want to release and don't want to depend upon a -nightly build of Commons Lang. - -Therefore this is a beta release of a stable api for these projects and any -other interested project to depend upon. - -It is important to note that this is not a traditional beta, a piece of -code thrown out with many bugs remaining. It is a beta because additional -classes are expected to be added before a full release, but the classes -contained in this release are not expected to change. +NEW FEATURES: +Since the release of the b1 package the following have been added: -NEW FEATURES: +lang. +SystemUtils: + Brings together many system specific variables under one easy component. + +exception. +ExceptionUtils: + Provides helpful static functions for dealing with Exceptions. +NestableError : + Adds nesting ability to Errors. + +enum sub-package: +A solid version of the typical Java translation of a C struct. + +builder sub-package: +A series of helpers for handling standard Object methods such as equals, +toString, compareTo and hashCode in a professional manner. -It's all a new feature. BUG FIXES: +StringUtils.stripStart and stripEnd were improved to match their Javadoc. +StringUtils.convertUnicodeToNative and convertNativeToUnicode both removed. +Both methods did not work properly. + + +DEPRECATIONS: + +Much of the exception subpackage was reworked betwen 1.0-b1 and 1.0. Apart +from this the API should have a high level of backward compatibility. + + +CHANGES: [In 'diff' format] + +Jar changes +=== + org.apache.commons.lang.exception.ExceptionUtils + org.apache.commons.lang.exception.NestableError + org.apache.commons.lang.ObjectUtils$Null + org.apache.commons.lang.ObjectUtils$1 + org.apache.commons.lang.enum.Enum$Entry + org.apache.commons.lang.enum.Enum$1 + org.apache.commons.lang.enum.Enum + org.apache.commons.lang.enum.EnumUtils + org.apache.commons.lang.enum.ValuedEnum + org.apache.commons.lang.builder.CompareToBuilder + org.apache.commons.lang.builder.EqualsBuilder + org.apache.commons.lang.builder.HashCodeBuilder + org.apache.commons.lang.builder.StandardToStringStyle + org.apache.commons.lang.builder.ToStringStyle$DefaultToStringStyle + org.apache.commons.lang.builder.ToStringStyle$NoFieldNameToStringStyle + org.apache.commons.lang.builder.ToStringStyle$SimpleToStringStyle + org.apache.commons.lang.builder.ToStringStyle$MultiLineToStringStyle + org.apache.commons.lang.builder.ToStringStyle$1 + org.apache.commons.lang.builder.ToStringStyle + org.apache.commons.lang.builder.ToStringBuilder + org.apache.commons.lang.SystemUtils + + +Class changes += +org.apache.commons.lang.exception.Nestable + + public abstract int getLength(); + public abstract int getThrowableCount(); + public abstract int indexOfThrowable(int, java.lang.Class); +--- + public abstract int indexOfThrowable(java.lang.Class, int); + public abstract void printStackTrace(java.io.PrintStream); + +org.apache.commons.lang.exception.NestableDelegate + + int getLength(); + java.lang.String getMessage(java.lang.String); + java.lang.String getMessage(java.lang.String); + java.lang.String getMessages()[]; + int getThrowableCount(); + java.lang.String getMessages()[]; + int indexOfThrowable(int, java.lang.Class); +--- + int indexOfThrowable(java.lang.Class, int); + +org.apache.commons.lang.exception.NestableException
Re: [HttpClient] URI request fix and multiple method fix
Jeff Dever [EMAIL PROTECTED] writes:
Hey Andrew,
Thanks for your comments. I definately agree with you regarding the
call to endSession() inside startSession(). Regarding the path
encoding, I'm not as sure. If the client was trying to refrence a web
page that lived in a directory with a space in it (evil, yes), the space
does need to be encoded. Is there a case where the current encoding is
causing problems?
Yes, the current encoding definitely causes problems. Right now,
normal servlets do not expend encoded arguments. Let's say I type
into my browser http://test/testservlet?foo=barbaz=schmoo
Now, what happens is that when req.getParameter inside
my servlet (req is HttpServletRequest) with argument foo, I get
bar, as expected.
However, if the requestor was HttpClient, the URI is encoded, so the
actual URI is ?foo=bar%26baz=schmoo (may not be actual, I'm just doing
this from memory, but you see what I mean). req.getParameter with
argument foo will now return bar%26baz=schmoo. This is
incorrect, and it was exactly the error I was seeing when using
HTTPClient against my Tomcat servlet.
We do appriciate your diffs, but the prefered diff format is unidiff
(diff -u) which is easier to read as it provides more context. Also it
is prefered that patches include JUnit test cases where possible.
Partiularly with the encoding, a test case that would fail with the
current code but passes after the patch is applied would be brilliant.
Thanks for the suggestions. I'll work on a JUnit test case and get
back to you. Or should I submit the patch for the test case to the
developer forum?
There is more information on contributing to Jakarta-Commons:
http://jakarta.apache.org/commons/patches.html
http://jakarta.apache.org/commons/patches.html
-jsd
-Original Message-
From: Andrew Hyatt [ mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] ]
Sent: Thursday, September 19, 2002 12:23 PM
To: [EMAIL PROTECTED]
Subject: [HttpClient] URI request fix and multiple method fix
There are two bugs in HttpClient I've noticed. One is the simple
matter that the HTTP request is escaped. It should not be. The
fix for this:
Index: HttpMethodBase.java
===
RCS file:
/home/cvspublic/jakarta-commons/httpclient/src/java/org/apache
/commons/httpclient/HttpMethodBase.java,v
retrieving revision 1.55
diff -r1.55 HttpMethodBase.java
1205,1206c1205
buf.append((null == reqPath)
? / : URIUtil.encode(reqPath,
URIUtil.pathSafe()));
---
buf.append(null == reqPath ? / : reqPath);
The next is that you cannot execute two methods in a row (to the same
url, with different parameters, say), instead you had to close
and create a new HttpClient. THe solution is simple, we just have to
make sure our session is closed before we open a new one. The
patch is:
Index: HttpClient.java
===
RCS file:
/home/cvspublic/jakarta-commons/httpclient/src/java/org/apache
/commons/httpclient/HttpClient.java,v
retrieving revision 1.54
diff -r1.54 HttpClient.java
192c192
---
196a197,204
// Stop the old session before creating a new one
try {
endSession();
} catch (IOException e) {
log.error(HttpClient.startSession: error
closing the old session before starting the new one);
}
BTW, for some reason I cannot subscribe to any of the jakarta lists.
So if you want to communicate with me, it would be most reliable to
mail me back at this address.
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12756] - [Patch] CallMethodRule/CallParamRule
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12756. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12756 [Patch] CallMethodRule/CallParamRule [EMAIL PROTECTED] changed: What|Removed |Added Summary|[Patch] |[Patch] |CallMethodRule/CallParamRule|CallMethodRule/CallParamRule --- Additional Comments From [EMAIL PROTECTED] 2002-09-25 01:55 --- It seems the fix from Bug#11693 has addressed (partly?) the last issue that CallMethodRule didn't work correctly in nested situation. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [beanutils] second opinion on bug #12728 please
robert burrell donkin [EMAIL PROTECTED] writes:
could someone take a look at
http://issues.apache.org/bugzilla/show_bug.cgi?id=12728
and give a second opinion?
(i don't understand why this change is needed.)
The original code:
PropertyDescriptor result = null;
FastHashMap mappedDescriptors =
getMappedPropertyDescriptors(bean);
//
if (result == null) {
// not found, try to create it
try {
result =
new MappedPropertyDescriptor(name, bean.getClass());
} catch (IntrospectionException ie) {
}
}
if (result != null) {
mappedDescriptorsCache.put(name, result);
}
return result;
where FastHashMap getMappedPropertyDescriptors(bean) above finally
results in a
return mappedDescriptorsCache.get(bean.getClass())
So, the values of the mappedDescriptorsCache-Map should probably be
FastHashMap's, not MappedPropertyDescriptor's like 'result'. So, from
my guess Alexander is wright with his analysis, at least from a
plausibility-point-of-view.
cu
--
...roland huss
consol.de
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[latka] [PATCH] for [GUMP] Build Failure
/http/RequestImpl.java:307: exception
org.apache.commons.httpclient.HttpException has already been caught [javac]
} catch (HttpException e) {
[javac] ^
[javac] 1 error
BUILD FAILED
file:/home/rubys/jakarta/jakarta-commons/latka/build.xml:298: Compile
failed; see the compiler error output for details.
Can someone apply this patch which swaps the order of the catch statements
causing this build failure?
Many Thanks,
Janek Bogucki
Index: src/java/org/apache/commons/latka/http/RequestImpl.java
===
RCS file:
/home/cvspublic/jakarta-commons/latka/src/java/org/apache/commons/latka/http/RequestImpl.java,v
retrieving revision 1.31
diff -u -r1.31 RequestImpl.java
--- src/java/org/apache/commons/latka/http/RequestImpl.java 18 Sep 2002 16:03:36
- 1.31
+++ src/java/org/apache/commons/latka/http/RequestImpl.java 24 Sep 2002 17:18:15
+-
@@ -301,11 +301,11 @@
_session.setReferer(new URL(_targetURL.getProtocol(), _host, _port,
_httpMethod.getPath()));
+} catch (HttpException e) {
+throw new IOException(e.toString());
} catch (IOException e) {
// rethrow it after closing the connection
throw e;
-} catch (HttpException e) {
-throw new IOException(e.toString());
} finally {
try {
closeConnection();
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10851] - Support for NTLM authentication
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10851. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10851 Support for NTLM authentication [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|commons-|[EMAIL PROTECTED] |[EMAIL PROTECTED] | Target Milestone|2.1 Final |2.0 milestone 2 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang StringUtils.java
bayard 2002/09/24 20:30:19
Modified:lang/src/java/org/apache/commons/lang StringUtils.java
Log:
Changed my name from 'Bayard'. Yeah yeah.
Revision ChangesPath
1.13 +9 -9
jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java
Index: StringUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- StringUtils.java 21 Sep 2002 05:02:43 - 1.12
+++ StringUtils.java 25 Sep 2002 03:30:19 - 1.13
@@ -68,7 +68,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Jon S. Stevens/a
* @author a href=mailto:[EMAIL PROTECTED];Daniel Rall/a
* @author a href=mailto:[EMAIL PROTECTED];Greg Coladonato/a
- * @author a href=mailto:[EMAIL PROTECTED];Bayard/a
+ * @author a href=mailto:[EMAIL PROTECTED];Henri Yandell/a
* @author a href=mailto:[EMAIL PROTECTED];Ed Korthof/a
* @author a href=mailto:[EMAIL PROTECTED]Rand McNeely/a
* @author a href=mailto:[EMAIL PROTECTED]Stephen Colebourne/a
@@ -80,7 +80,7 @@
/**
* The size of the buffer to use when working with I/O (4 kB).
*/
-public static int CHAR_BUFFER_SIZE = 4 * 1024;
+public static final int CHAR_BUFFER_SIZE = 4 * 1024;
/**
* StringUtils instances should NOT be constructed in standard programming.
@@ -1483,7 +1483,7 @@
*
* @param s the first String
* @param t the second String
- * @param result distance
+ * @return int result distance
*/
public static int getLevenshteinDistance(String s, String t) {
int d[][]; // matrix
@@ -1547,22 +1547,22 @@
* @return true if it only contains valid chars and is non-null
*/
public static boolean containsOnly(String str, char[] valid) {
-if(str == null || valid == null) {
+if (str == null || valid == null) {
return false;
}
int strSize = str.length();
int validSize = valid.length;
-for(int i=0; istrSize; i++) {
+for (int i = 0; i strSize; i++) {
boolean contains = false;
-for(int j=0; jvalidSize; j++) {
-if(valid[j] == str.charAt(i)) {
+for (int j = 0; j validSize; j++) {
+if (valid[j] == str.charAt(i)) {
contains = true;
break;
}
}
-if(!contains) {
+if (!contains) {
return false;
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[lang] Enum query
Any reason why the Enum class doesn't overload its methods with versions that don't take the Class object? So getEnumList() in the Enum class would call getEnumMap(this.getClass()) etc. It would also help the fact that Enum doesn't have getEnum(String)/getEnumMap/getEnumList/iterator in its API, making it hard to deal with Enums generically. Just a thought :) Hen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[HttpClient][PATCH] Basic Authentication does not use default credentials
Digest authentication falls back to the default credentials (state.getCredentials(null)) when credentials for the specific realm aren't found, however basic authentication doesn't currently do that. This patch makes basic authentication behave like digest authentication. There is the security issue of having the username and password sent in clear text without specifically saying to (normally it would be specified on a per realm basis so it would be known to be sent via clear text), however I think that's a little paranoid and it's better to behave consistently. Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com .. EditLive! The world leader in browser-based web authoring tools: Desktop Enterprise. .. This email and any files transmitted with it are confidential and intended solely for the use of the individual to whom they are addressed. Opinions contained in this email do not necessarily reflect the opinions of Ephox Corporation. If you have received this email in error please notify the sender immediately and delete all copies of the correspondence from your computer and/or computer network. No warranty is given that this message upon its receipt is virus free and the sender in this respect accepts no liability. basic_default.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [latka] [PATCH] RequestImpl.setVersion () throws NPE
Janek Bogucki [EMAIL PROTECTED] writes:
On Tuesday 17 September 2002 10:09 pm, Daniel Rall wrote:
Janek Bogucki [EMAIL PROTECTED] writes:
Index: RequestImpl.java
===
RCS file:
/home/cvspublic/jakarta-commons/latka/src/java/org/apache/commons/latka/h
ttp/RequestImpl.java,v retrieving revision 1.29
diff -u -r1.29 RequestImpl.java
--- RequestImpl.java 4 Sep 2002 02:59:26 - 1.29
+++ RequestImpl.java 17 Sep 2002 09:49:56 -
@@ -511,8 +511,10 @@
* @param version HTTP version
*/
public void setVersion(String version) {
-if (version.equals(HTTP_10)) {
+if (HTTP_10.equals(version)) {
((HttpMethodBase) _httpMethod).setHttp11(false);
+} else {
+((HttpMethodBase) _httpMethod).setHttp11(true);
}
}
}
I generally prefer the more brief style:
((HttpMethodBase) _httpMethod).setHttp11(!HTTP_10.equals(version));
Can you apply your compact version to the CVS source and remove my
patch from buzilla?
Janek, I'll leave it to an existing latka commiter. I updated the
Bugzilla report accordingly.
--
Daniel Rall [EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang][collections] ArrayUtils
Steve Downey [EMAIL PROTECTED] writes: Many bits and pieces of util have graduated, though, into lang and collections. I don't know how much momentum can be built around a subproject of 'useful code with no natural home', which is the usual operating definition of util. What is frustrating, though, is that almost every project has one, and there is a lot of overlap. Yes, I find it frustrating as well. I created [util] in the first place to try and address the overlap, and it has had success in that it has propogated its code into more specific projects like [lang], [collections], [io], and [codec]. -- Daniel Rall [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Release (1) Re: [lang] Added a couple of TODOs
Henri Yandell [EMAIL PROTECTED] writes: [question] I'm considering the authors to be Colebourne and Downey. So I need some nods from Daniel and Caswell. Also Ola Berg and Scott Sanders if they've been focusing on them at all. Sounds right to me. [question] Is there anything not in commons proper which people believe is highly -- Daniel Rall [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: StringUtils.containsOnly
Henri Yandell [EMAIL PROTECTED] writes: I've submitted Frederik's patch with the new method. Only odd boundary case I can see is that: containsOnly(, anything but null) returns true. This seems okay to me. A string object could contain the specified characters (but doesn't). containsOnly(null, anything) returns false. I could follow this on the grounds that a null string couldn't possibly contain any characters, so should fail. Still, I find the semantics confusing, since the same argument could be applied to the previous case as well. -- Daniel Rall [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Next stage in release
Steve Downey [EMAIL PROTECTED] writes: On Friday 20 September 2002 03:09 am, Henri Yandell wrote: Okay, I'm figuring that 1 and 2 are done. 1) Decide on what we want to go and what doesn't go. 2) All agree that we're happy with the state of what is going, including javadoc and unit tests. Which puts us on to: 3) Make a preliminery build available internally. I'd like to then run JDiff on this with the beta. This hopefully can make us aware of any issues. This means having tag stuff in cvs done at this point. I looked into JDiff, but the learning curve feels too high for the amount of effort I want to put in at the moment, so I wrote myself a script. Here's the output: http://www.generationjava.com/projects/vij/commons-lang.javadiff It basically tells us what has changed. It's in DIFF format [cuz I used diff] so the usualstuff. It shows that we have a bunch of new classes, that the exception classes have had some API change, that ObjectUtils has gained an inner class and a method, that NumberUtils has gained a few methods, and that StringUtils has lost 3 methods and gained a new one. It's not wonderful, but seems to do what a changelog should do to me :) Here's a Changlog generated from CVS commit comments: Generated using cvs2cl.pl, from http://www.red-bean.com/cvs2cl/ Karl's code is good. Also, I don't know how you produced diffs, but the diff provided by the GNU diffutils package has recursive capabilities: dlr@despot:lang$ alias dirdiff alias dirdiff='diff -drPN' I generally do comparisons like this using CVS: dlr@despot:lang$ cvs diff -r LANG_1_0_B1 ... Sorry if this is all obvious -- I just like people to have to do as little work as possible. :) -- Daniel Rall [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang] ready for a release
Stephen Colebourne [EMAIL PROTECTED] writes: - Should we add JDK1.2 to the dependencies list? +1 -- Daniel Rall [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Commons Lang release 1.0
Henri Yandell [EMAIL PROTECTED] writes: I'm proposing a vote for a 1.0 release of Commons Lang to be made. The difference from the b1 release may be seen at: http://www.generationjava.com/projects/vij/commons-lang.javadiff The changelog since then may be seen at: http://www.generationjava.com/maven/jakarta-commons/lang/commons-lang-Changelog.txt The mavenised version of the site may be seen at: http://www.generationjava.com/maven/jakarta-commons/lang/ [This is not planned for the actual site as yet, but has proven useful]. Daniel Rall or myself will do the actual release. I'm +1, but hopefully we'll get 3 +1's from non-Lang coders. +1, woo hoo! -- Daniel Rall [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java
dlr 2002/09/24 22:50:49
Modified:lang/src/test/org/apache/commons/lang/exception
ExceptionUtilsTestCase.java
Log:
Corrected semantics of ExceptionWithoutCause broken in CVS rev 1.3.
The point of the ExceptionWithoutCause is to test for false-positive
nested exception method signature matches. Documented this in the
header JavaDoc for both the ExceptionWithCause and
ExceptionWithoutCause classes, and changed the nested exception method
name of the latter from getCause() to getTargetException() to avoid
conflicts with getCause() method of JDK 1.4's Exception class (which
returns Throwable).
Revision ChangesPath
1.4 +11 -2
jakarta-commons/lang/src/test/org/apache/commons/lang/exception/ExceptionUtilsTestCase.java
Index: ExceptionUtilsTestCase.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/exception/ExceptionUtilsTestCase.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -u -r1.3 -r1.4
--- ExceptionUtilsTestCase.java 18 Sep 2002 15:47:44 - 1.3
+++ ExceptionUtilsTestCase.java 25 Sep 2002 05:50:49 - 1.4
@@ -107,6 +107,11 @@
assertEquals(ExceptionUtils.getThrowableCount(null), 0);
}
+/**
+ * Provides a method with a well known chained/nested exception
+ * name which matches the full signature (e.g. has a return value
+ * of codeThrowable/code.
+ */
private static class ExceptionWithCause extends Exception
{
private Throwable cause;
@@ -122,11 +127,15 @@
}
}
+/**
+ * Provides a method with a well known chained/nested exception
+ * name which does not match the full signature (e.g. lacks a
+ * return value of codeThrowable/code.
+ */
private static class ExceptionWithoutCause extends Exception
{
-public Throwable getCause()
+public void getTargetException()
{
-return null;
}
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java
I'm adding this correction to what's going into the release.
[EMAIL PROTECTED] writes:
dlr 2002/09/24 22:50:49
Modified:lang/src/test/org/apache/commons/lang/exception
ExceptionUtilsTestCase.java
Log:
Corrected semantics of ExceptionWithoutCause broken in CVS rev 1.3.
The point of the ExceptionWithoutCause is to test for false-positive
nested exception method signature matches. Documented this in the
header JavaDoc for both the ExceptionWithCause and
ExceptionWithoutCause classes, and changed the nested exception method
name of the latter from getCause() to getTargetException() to avoid
conflicts with getCause() method of JDK 1.4's Exception class (which
returns Throwable).
Revision ChangesPath
1.4 +11 -2
jakarta-commons/lang/src/test/org/apache/commons/lang/exception/ExceptionUtilsTestCase.java
Index: ExceptionUtilsTestCase.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/exception/ExceptionUtilsTestCase.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -u -r1.3 -r1.4
--- ExceptionUtilsTestCase.java 18 Sep 2002 15:47:44 - 1.3
+++ ExceptionUtilsTestCase.java 25 Sep 2002 05:50:49 - 1.4
@@ -107,6 +107,11 @@
assertEquals(ExceptionUtils.getThrowableCount(null), 0);
}
+/**
+ * Provides a method with a well known chained/nested exception
+ * name which matches the full signature (e.g. has a return value
+ * of codeThrowable/code.
+ */
private static class ExceptionWithCause extends Exception
{
private Throwable cause;
@@ -122,11 +127,15 @@
}
}
+/**
+ * Provides a method with a well known chained/nested exception
+ * name which does not match the full signature (e.g. lacks a
+ * return value of codeThrowable/code.
+ */
private static class ExceptionWithoutCause extends Exception
{
-public Throwable getCause()
+public void getTargetException()
{
-return null;
}
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
Daniel Rall [EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang] Builders complete?
Craig R. McClanahan [EMAIL PROTECTED] writes: On Wed, 18 Sep 2002, Henri Yandell wrote: Date: Wed, 18 Sep 2002 11:57:52 -0400 (EDT) From: Henri Yandell [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: [lang] Builders complete? I've no clear beliefs against it. I lack a good understanding of the whole of BeanUtils scope and size and I'm not sure whether this affects a Lang release. BeanUtils is one of those, I now know how to use, I will replace my own version, but I need to find out what it doesn't do that mine does and get inside it to feel good about it things :) In earlier discussions on this topic, I thought the conclusion was that [lang] would grab the MethodUtils class out of beanutils, and create a corresponding ConstructorUtils class for dynamically invoking constructors. At some appropriate time, [beanutils] could deprecate its own version of MethodUtils and declare a dependence on [lang] for this functionality. The rest of [beanutils] seems to me to be out of scope for [lang]. +1 on this proposition. What say the rest of the [lang] commiters? -- Daniel Rall [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/lang default.properties
dlr 2002/09/24 22:54:54
Modified:lang default.properties
Log:
Updated the component.version property for [lang] version 1.0-rc1.
Revision ChangesPath
1.3 +1 -1 jakarta-commons/lang/default.properties
Index: default.properties
===
RCS file: /home/cvs/jakarta-commons/lang/default.properties,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -u -r1.2 -r1.3
--- default.properties19 Jul 2002 03:39:48 - 1.2
+++ default.properties25 Sep 2002 05:54:54 - 1.3
@@ -11,7 +11,7 @@
component.title = Core Language Utilities
# The current version number of this component
-component.version = 1.0-dev
+component.version = 1.0-rc1
# The name that is used to create the jar file
final.name = ${component.name}-${component.version}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/lang .cvsignore
dlr 2002/09/24 22:55:31 Added: lang .cvsignore Log: Ignore the generated target/ directory. Revision ChangesPath 1.1 jakarta-commons/lang/.cvsignore Index: .cvsignore === target -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/lang default.properties
dlr 2002/09/24 22:57:36
Modified:lang default.properties
Log:
All build-generated content should reside under a single directory for easy cleaning.
Revision ChangesPath
1.4 +1 -1 jakarta-commons/lang/default.properties
Index: default.properties
===
RCS file: /home/cvs/jakarta-commons/lang/default.properties,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -u -r1.3 -r1.4
--- default.properties25 Sep 2002 05:54:54 - 1.3
+++ default.properties25 Sep 2002 05:57:36 - 1.4
@@ -23,7 +23,7 @@
conf.home = src/conf
# The base directory for distribution targets
-dist.home = dist
+dist.home = ${build.home}/dist
# The base directory for component sources
source.home = src/java
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/lang default.properties
dlr 2002/09/24 23:00:30
Modified:lang default.properties
Log:
Reverting last commit back to CVS rev 1.3. I would prefer to see the dist build
target create bundled archives.
Revision ChangesPath
1.5 +1 -1 jakarta-commons/lang/default.properties
Index: default.properties
===
RCS file: /home/cvs/jakarta-commons/lang/default.properties,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -u -r1.4 -r1.5
--- default.properties25 Sep 2002 05:57:36 - 1.4
+++ default.properties25 Sep 2002 06:00:30 - 1.5
@@ -23,7 +23,7 @@
conf.home = src/conf
# The base directory for distribution targets
-dist.home = ${build.home}/dist
+dist.home = dist
# The base directory for component sources
source.home = src/java
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Commons Lang release 1.0
I've tagged CVS as LANG_1_0_RC1, and prepared distributions of [lang] in .zip and .tar.gz formats. I need Hen to `chmod -R g+w /www/jakarta.apache.org/builds/jakarta-commons/release/commons-lang` before I can move the files from my homedir on apache.org to the download directory. Incidently, I was thinking that it would be great if the build files would produce the .tar.gz and .zip for you. I can move in Ant code to do this, but was wondering if Maven could take care of it for us (I built the packages via the vanilla Ant build file, BTW). -- Daniel Rall [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Next stage in release
On 24 Sep 2002, Daniel Rall wrote: http://www.generationjava.com/projects/vij/commons-lang.javadiff Also, I don't know how you produced diffs, but the diff provided by the GNU diffutils package has recursive capabilities: dlr@despot:lang$ alias dirdiff alias dirdiff='diff -drPN' I generally do comparisons like this using CVS: dlr@despot:lang$ cvs diff -r LANG_1_0_B1 ... Sorry if this is all obvious -- I just like people to have to do as little work as possible. :) The big thing for me was that I wanted to do diff on the javap output and not the source. Users don't generally care about source changing, but want to know if methods arrive/vanish/change etc. So http://www.generationjava.com/projects/vij/javadiff is a simple chunk of bash-scripting to do that. It also works on jars and not source. Something I couldn't see how to easily do in jdiff. I need to play with it some more :) Hen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Commons Lang release 1.0
On 24 Sep 2002, Daniel Rall wrote: I've tagged CVS as LANG_1_0_RC1, and prepared distributions of [lang] in .zip and .tar.gz formats. I need Hen to `chmod -R g+w /www/jakarta.apache.org/builds/jakarta-commons/release/commons-lang` before I can move the files from my homedir on apache.org to the download directory. Done. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Commons Lang release 1.0 release candidate 1 available
Commons Lang 1.0 RC1 is now available for download here: http://jakarta.apache.org/builds/jakarta-commons/release/commons-lang/v1.0-rc1/ Please let me know what issues you find with it. Everything seems to be in order -- I figure we cut the final by end of week (if not sooner). -- Daniel Rall [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
