DO NOT REPLY [Bug 9599] - Problem accessing LogFactoryImpl from servlet
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=9599. 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=9599 Problem accessing LogFactoryImpl from servlet --- Additional Comments From [EMAIL PROTECTED] 2002-09-26 07:08 --- I get the same problem if I attempt to prepend the commons-logging jar into my Xbootclasspath (I'm running Axis): All I need to do to generate the error is: Class.forName(org.apache.axis.configuration.EngineConfigurationFactoryFinder); And I get: java.lang.ExceptionInInitializerError: org.apache.commons.logging.LogConfigurationException: java.lang.NullPointerException at org.apache.commons.logging.LogFactory.newFactory (LogFactory.java:558) at org.apache.commons.logging.LogFactory.getFactory (LogFactory.java:355) at org.apache.commons.logging.LogFactory.getLog (LogFactory.java:409) at org.apache.axis.components.logger.LogFactory.getLog (LogFactory.java:76) at org.apache.axis.configuration.EngineConfigurationFactoryFinder.clinit (EngineConfigurationFactoryFinder.java:89) at java.lang.Class.forName1(Native Method) at java.lang.Class.forName(Class.java:142) at com.touchcorp.apps.kiosk.KioskServer.main (KioskServer.java:469) What is going on? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [HttpClient] Method to determine required credential type
Adrian Sutton wrote: No authentication required (because a request hasn't yet been made or because there was no 401 response): return null. Basic or Digest: return UsernamePasswordCredentials.class NTLM authentication: return NTCredentials.class Unsupported authentication scheme: null I'd rather throw an Exception if the scheme is not supported. Otherwise there is no way of distinguishing Unsupported auth and No auth required. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH][HttpClient] bug 12607
Ryan Hoegg wrote: chunk-extension= *( ; chunk-ext-name [ = chunk-ext-val ] ) chunk-ext-name = token chunk-ext-val = token | quoted-string 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. But the quoted string may contain virtually ANY character, no? Legal: 89ab;value\r\n 89ab;key=value\r\n 89ab;key=\value\\r\n 89ab;key=\line1\r\nline2\rline3\nline4\\r\n Illegal: 89ab;key=line1\rline2\r\n 89ab;key=line1\r\nline2\r\n Since we ignore everything after the ; anyway, I don't want to parse this, really. But we run into serious problems in the case where a \r\n occurs within the quoted string! I have never encountered a server using this in the real-world (but I haven't seen enough servers). So once again: Has anybody ever see a server using this? Odi -- 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 --- Additional Comments From [EMAIL PROTECTED] 2002-09-26 08:46 --- Created an attachment (id=3234) Test case for the enhancement -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang] StringUtils.containsOnly
My view is that one of the main advantages of StringUtils is to avoid NPEs. I actually thought that we'd been through all the methods and ensured that none of them did throw a NPE. As I sugested the method initially, I looked at what my own implementation of this does and what my needs are. Basically I find the current implementation fine: containsOnly(, anything but null) returns true containsOnly(null, anything) returns false Stephen - Original Message - From: Steve Downey [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, September 25, 2002 10:38 PM Subject: Re: StringUtils.containsOnly On Wednesday 25 September 2002 04:48 pm, Henri Yandell wrote: On Wed, 25 Sep 2002, Steve Downey wrote: 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. This should probably throw a NPE. It's not meaningful to ask if null contains a character. This sounds like a possibility to me, though nothing else in StringUtils throws an NPE, and I'd think there would be other candidates in there. Hmm? Yes, they do. For example, deleteWhiteSpace(null) will throw an NPE. I think center(null, 100) does also. As in the java.* classes, most occurances of NPE are not thrown explicitly, but because of accessing a null object. Looking more closely, the StringUtils classes will protect from NPE in cases where java.lang.String will NPE. The IndexOf type methods. And we avoid throwing IndexOutOfBounds exceptions in the left, mid, right methds, where String.substring() will throw them. Sometimes this makes sense. Providing a 'Safe' version of an API can be a useful utility. But I'm not convinced it should be general policy. -- 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]
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 --- Additional Comments From [EMAIL PROTECTED] 2002-09-26 08:46 --- I second this feature request. I'm not 100% sure why you would ever want to specify stackPos other than 0, but other than that I like the provided patch. I've attached a test case for this feature. The test case will add a new file CallMethodRuleTestCase.java, which contains all the CallMethodRule/CallParamRule related tests, some of which moved from RuleTestCase.java, and added an entry to build.xml. (this is because I believe that the tests concentrating on a single rule should be in their own dedicated test case). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13022] New: - Pass namespace URI and name args to the Rule methods
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=13022. 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=13022 Pass namespace URI and name args to the Rule methods Summary: Pass namespace URI and name args to the Rule methods Product: Commons Version: 1.3 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Digester AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] As an enhancement to the current Digester API, I propose to add new variants to the Rule methods begin(), body() and end(). Those new variants would accept the namespace URI and local/qualified name of the current element. As Rule is not an interface, but an abstract class, this change can be done without hurting backwards compatibility. It will loosen the coupling between Rule implementations and Digester, as the rule would get sufficient information about the current element, without needing to call Digester.getCurrentElementName(). In addition, it provides access to the current namespace URI, which is not possible with the current version of Digester. I'll be attaching a patch that implements these changes. This involves changes to Rule.java, Digester.java and BeanPropertySetterRule.java. The latter change is not totally necessary, but rather demonstrates the benefits of the proposed API. All other Rule implementations could be changed later to remove the plenty deprecation warnings. [I've posted this patch to the commons-dev list before, I'm just adding it here so it doesn't get lost] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13022] - Pass namespace URI and name args to the Rule methods
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=13022. 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=13022 Pass namespace URI and name args to the Rule methods --- Additional Comments From [EMAIL PROTECTED] 2002-09-26 09:19 --- Created an attachment (id=3235) Unified diff containing the changes described above -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13022] - Pass namespace URI and name args to the Rule methods
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=13022. 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=13022 Pass namespace URI and name args to the Rule methods [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13023] New: - New rule to build DOM nodes
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=13023. 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=13023 New rule to build DOM nodes Summary: New rule to build DOM nodes Product: Commons Version: 1.3 Final Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Digester AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This patch adds a new Rule implementation to Digester: NodeCreateRule. It can create DOM Element and DocumentFragment nodes that are populated with all XML content contained by the matching element, and pushed on Digester's object stack. A use case for this would be: you want to process XML documents that allow ANY content under certain nodes. Using a NodeCreateRule, Digester can capture that information in a DOM node for further processing by the application. Specifically, I've needed this feature for WebDAV XML request processing, but there has also been a related request on the commons-user list. Included in the patch is the NodeCreateRule class with full javadocs, as well as a corresponding test-case and a modification to build.xml to include that test-case. NOTE: this enhancement depends on the enhancement request in bug #13022. [I've already posted this patch to commons-dev - adding it here to so that it doesn't get lost] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13030] - Digester unable to resolve external DTD
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=13030. 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=13030 Digester unable to resolve external DTD --- Additional Comments From [EMAIL PROTECTED] 2002-09-26 12:14 --- Created an attachment (id=3240) Patch to register validation.dtd with the Digester -- 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/xml TransformTag.java
jstrachan2002/09/26 05:28:21
Modified:jelly/src/test/org/apache/commons/jelly/xml TestXMLTags.java
jelly/src/java/org/apache/commons/jelly/tags/xml
TransformTag.java
Added: jelly/src/test/org/apache/commons/jelly/xml
transformExampleSAXOutput.jelly
Log:
Added support in the x:transform tag so that output can be SAX events. This allows
more efficient SAX based XSLT pipelines.
So if users don't want to parse the output of the XSLT, they can just pipe it out as
SAX events.
Also added a test case of this.
Revision ChangesPath
1.6 +7 -0
jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/xml/TestXMLTags.java
Index: TestXMLTags.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/xml/TestXMLTags.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- TestXMLTags.java 25 Sep 2002 08:37:50 - 1.5
+++ TestXMLTags.java 26 Sep 2002 12:28:21 - 1.6
@@ -147,6 +147,13 @@
assertEquals(Produces the correct output, It works!, text);
}
+public void testTransformSAXOutput() throws Exception {
+String text = evaluteScriptAsText(
+src/test/org/apache/commons/jelly/xml/transformExampleSAXOutput.jelly
+);
+assertEquals(Produces the correct output, It works!, text);
+}
+
public void testTransformSchematron() throws Exception {
String text = evaluteScriptAsText(
src/test/org/apache/commons/jelly/xml/schematron/transformSchematronExample.jelly
1.1
jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/xml/transformExampleSAXOutput.jelly
Index: transformExampleSAXOutput.jelly
===
?xml version=1.0?
j:jelly xmlns:j=jelly:core xmlns:x=jelly:xml
x:parse var=xsl_doc
xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
version=1.0
xsl:template match=document
html
xsl:apply-templates/
body/body
/html
/xsl:template
xsl:template match=chapter
titlexsl:apply-templates//title
/xsl:template
/xsl:stylesheet
/x:parse
!-- here we're testing if the output of the XSLT comes out as SAX events
|| that the x:parse tag can then parse.
|| We're using the x:parse around the x:transform purely to test
|| that the x:transform is capable of outputting SAX events --
x:parse var=doc
x:transform xsl=${xsl_doc}
document
chapterIt works!/chapter
/document
/x:transform
/x:parse
x:expr select=$doc/html/title/
/j:jelly
1.2 +33 -12
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/xml/TransformTag.java
Index: TransformTag.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/xml/TransformTag.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TransformTag.java 25 Sep 2002 08:37:50 - 1.1
+++ TransformTag.java 26 Sep 2002 12:28:21 - 1.2
@@ -61,11 +61,14 @@
*/
package org.apache.commons.jelly.tags.xml;
+import javax.xml.transform.Result;
import javax.xml.transform.Source;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerException;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.URIResolver;
+import javax.xml.transform.sax.SAXResult;
+import javax.xml.transform.sax.SAXSource;
import javax.xml.transform.stream.StreamSource;
import org.apache.commons.jelly.XMLOutput;
@@ -117,9 +120,6 @@
* @throws Exception - when required attributes are missing
*/
public void doTag(XMLOutput output) throws Exception {
-if (this.getVar() == null) {
-throw new IllegalArgumentException(The var attribute cannot be null);
-}
Document xmlDocument = this.getXmlDocument(output);
Document xslDocument = this.parse(this.xsl);
@@ -127,13 +127,23 @@
Transformer transformer = tf.newTransformer(new
DocumentSource(xslDocument));
DocumentSource xmlDocSource = new DocumentSource(xmlDocument);
-DocumentResult result = new DocumentResult();
-
-transformer.transform(xmlDocSource, result);
-Document transformedDoc = result.getDocument();
+String var = getVar();
+if (var == null) {
+
Re: [PATCH][HttpClient] bug 12607
The text string parsing is really not fun. One day we should go to regex pattern matching, which is not to difficult to construct from the BNF in the relevent RFCs. It will also be easier to handle non-standard/malformatted responses. Perhaps that will be HttpClient 3.0 ... Ortwin Glück wrote: LWS= [CRLF] 1*( SP | HT ) Damn. We must parse this shit Ryan Hoegg wrote: I have never seen a server do this, but you are right about the quoted-string: quoted-string = ( *(qdtext | quoted-pair ) ) quoted-pair= \ CHAR qdtext = any TEXT except TEXT = any OCTET except CTLs, but including LWS So it seems that for each cunk-ext-val, we need to: 1) read the first char 2) if it is not a , proceed as we currently do 3) if it is, continue to read chars until a or a \ is reached 4) in the case of a \, skip the next character 5) in the case of a , ensure that we either have CRLF or ; 6) if we have ;, we read another token=token|quoted-string i.e. goto 1 This is my reading of RFC2616. -- 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]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestStreams.java
oglueck 2002/09/26 05:40:33
Modified:httpclient/src/java/org/apache/commons/httpclient
ChunkedInputStream.java
httpclient/src/test/org/apache/commons/httpclient
TestStreams.java
Log:
Patch by Martin Elwin fixes bug #12607. Test case included.
Parsing chunk extensions correctly.
Revision ChangesPath
1.5 +57 -30
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/ChunkedInputStream.java
Index: ChunkedInputStream.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/ChunkedInputStream.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ChunkedInputStream.java 23 Sep 2002 14:01:40 - 1.4
+++ ChunkedInputStream.java 26 Sep 2002 12:40:33 - 1.5
@@ -68,14 +68,15 @@
/**
* pTransparently coalesces chunks of a HTTP stream that uses Transfer-Encoding
* chunked./p
- *
+ *
* @see ResponseInputStream
- *
+ *
* @author Ortwin Glück
* @author Sean C. Sullivan
- *
+ * @author Martin Elwin
+ *
* @since 2.0
- *
+ *
*/
public class ChunkedInputStream extends InputStream {
@@ -86,22 +87,22 @@
private HttpMethod method;
/**
- *
- *
+ *
+ *
* @param in must be non-null
* @param method must be non-null
- *
- * @throws java.io.IOException
- * @throws java.lang.NullPointerException
- *
+ *
+ * @throws java.io.IOException
+ * @throws java.lang.NullPointerException
+ *
*/
public ChunkedInputStream(final InputStream in, final HttpMethod method) throws
IOException {
- if (null == in) {
- throw new NullPointerException(InputStream parameter);
- }
- if (null == method) {
- throw new NullPointerException(HttpMethod parameter);
- }
+ if (null == in) {
+throw new NullPointerException(InputStream parameter);
+ }
+ if (null == method) {
+throw new NullPointerException(HttpMethod parameter);
+ }
this.in = in;
this.method = method;
this.chunkSize = getChunkSizeFromInputStream(in);
@@ -164,7 +165,7 @@
* Positions the stream at the start of the next line.
*
* @return the chunk size as integer
- *
+ *
* @throws IOException when the chunk size could not be parsed
* @throws java.lang.RuntimeException
*
@@ -172,34 +173,60 @@
*/
private static int getChunkSizeFromInputStream(final InputStream in) throws
IOException {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
+int state = 0; //0: normal, 1: \r was scanned, 2: inside quoted string, -1:
end
+while (state != -1) {
int b = in.read();
-int state = 0;
-while (state != 2) {
if (b == -1) throw new IOException(chunked stream ended unexpectedly);
switch (state) {
case 0:
-if (b == '\r') state = 1;
+switch (b) {
+case '\r':
+state = 1;
break;
+case '\':
+state = 2;
+/* fall through */
+default:
+baos.write(b);
+}
+break;
+
case 1:
-if (b == '\n') state = 2;
-else state = 0;
+if (b == '\n') {
+state = -1;
+} else {
+// this was not CRLF
+throw new IOException(Protocol violation: Unexpected
single newline character in chunk size);
+}
+break;
+
+case 2:
+switch (b) {
+case '\\':
+b = in.read();
+baos.write(b);
+break;
+case '\':
+state = 0;
+/* fall through */
+default:
+baos.write(b);
+}
break;
default: throw new RuntimeException(assertion failed);
}
-if (state == 0) baos.write(b);
-if (state != 2) b = in.read();
}
//parse data
String dataString = new String(baos.toByteArray(), HTTP_ENC);
int separator = dataString.indexOf(';');
Re: [PATCH][HttpClient] bug 12607
Could you post the server's response? Ryan Hoegg wrote: Although it seems we will be going to BNF as a regex someday, I am suspicious that this very issue is causing incompatibility with a HTTP 1.1 server I am trying to access. So I may make a stab at parsing this chunk size thing as I wrote below. Am I right in assuming this patch should go to bug 12607? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: next possible commons project - [regexp] (or [template?])
From: Tomasz Pik [EMAIL PROTECTED]
Original Message
Java 1.4 has a new regex package, and there are others
that could be
considered if a reliance on 1.4 is to be avoided.
Maybe something like 'Commons Logging' - one hat (with limited
funcionality) for most of the regexp packages
(http://regex.info/java.html)?
Regards
Tomek Pik
Have you found a need for this? If so, have you got some code that
would provide a starting point?
While we're floating implementation-abstraction packages, I've
recently put together a very light weight package to abstract the api
of a templating system from the implementation. I have
implementations for Velocity and Jelly so far. I'd share if people
are interested. So far I'm getting by with basically two versions of
one API method:
public String mergeTemplate(String templateName, Map context)
and
public void mergeTemplate(String templateName, Map context, Writer writer)
It uses Commons Discovery for configuration. It works for me. But
then, my needs are pretty simple.
Joe
--
--
* Joe Germuska{ [EMAIL PROTECTED] }
It's pitiful, sometimes, if they've got it bad. Their eyes get
glazed, they go white, their hands tremble As I watch them I
often feel that a dope peddler is a gentleman compared with the man
who sells records.
--Sam Goody, 1956
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Jelly] patch: fix relative paths
This patch corrects a problem when specifying a relative path to run a script, i.e. jellyContext.runScript(some/relative/path/script.jelly, xmlOutput); Otto JellyContext.java.diff Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: next possible commons project - [regexp]
Daniel Rall wrote: Jeff Dever [EMAIL PROTECTED] writes: Jakarta does have a top level regexp project: http://jakarta.apache.org/regexp/ Jakarta Regexp is the more simple of the two Jakarta regex packages (I believe that Tomcat uses this one). ORO is much more full featured, offering the full power of Perl 5 regexes. How would yet another regex package seek to differentiate itself from the existing two? AND JDK 1.4 Regex? -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [logging] VOTE for cutting release 1.0.2
Richard has volunteered, with the exception of daedalus issues, which I volunteered to help him with. Scott -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 4:05 AM To: Jakarta Commons Developers List Subject: Re: [logging] VOTE for cutting release 1.0.2 On Wednesday, September 25, 2002, at 11:07 PM, Richard Sitze wrote: snip 4. Folks, if you are committers, please update the commons-logging STATUS.html document with your name, and that includes myself! :-) 1. i'd suggestion that people do this ASAP since (by my count) there are not enough votes from committers for the required quorum. 2. a release manager is required. that person needs to be a committer (see 1) and (probably) needs an account on daedelus. any volunteers? (FYI my vote would be binding...) - robert -- 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]
Re: next possible commons project - [regexp]
In the same way as [logging], by not being a regexp package itself. Of course it may just not be appropriate... Stephen - Original Message - From: Berin Loritsch [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Thursday, September 26, 2002 4:40 PM Subject: Re: next possible commons project - [regexp] Daniel Rall wrote: Jeff Dever [EMAIL PROTECTED] writes: Jakarta does have a top level regexp project: http://jakarta.apache.org/regexp/ Jakarta Regexp is the more simple of the two Jakarta regex packages (I believe that Tomcat uses this one). ORO is much more full featured, offering the full power of Perl 5 regexes. How would yet another regex package seek to differentiate itself from the existing two? AND JDK 1.4 Regex? -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- 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]
[discovery]
I went to find out more information about the discovery package, and the two links, best practices and the javadocs are both broken. Can someone point me to a correct URL (without having to download and build it first). Thanks, Robert
Re: next possible commons project - [regexp]
Jeff Dever [EMAIL PROTECTED] writes: Jakarta does have a top level regexp project: http://jakarta.apache.org/regexp/ Jakarta Regexp is the more simple of the two Jakarta regex packages (I believe that Tomcat uses this one). ORO is much more full featured, offering the full power of Perl 5 regexes. How would yet another regex package seek to differentiate itself from the existing two? -- Daniel Rall [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/xdocs components.xml discovery.xml
sanders 2002/09/26 09:08:39 Modified:docs commons.html components.html discovery.html xdocscomponents.xml discovery.xml Log: update discovery URLs Revision ChangesPath 1.52 +21 -0 jakarta-commons/docs/commons.html Index: commons.html === RCS file: /home/cvs/jakarta-commons/docs/commons.html,v retrieving revision 1.51 retrieving revision 1.52 diff -u -r1.51 -r1.52 --- commons.html 19 Sep 2002 21:04:26 - 1.51 +++ commons.html 26 Sep 2002 16:08:39 - 1.52 @@ -201,7 +201,9 @@ trtd blockquote p + The following proposals for new Commons Proper projects are currently pending : + /p ul @@ -209,25 +211,44 @@ bBeanUtils Package/b : Craig McClanahan /li + li + bDatabase Connection Pool Package/b : Rodney Waldhoff + /li + + li + bObject Pooling Package/b : Rodney Waldhoff + /li + + li + bCollections Package/b : Rodney Waldhoff + /li + + li + b Cactus, the renamed J2EEUnit/b : Vincent Massol + /li + + /ul p + Please see the jakarta-commons mail list for further details. + /p /blockquote /p 1.58 +1 -1 jakarta-commons/docs/components.html Index: components.html === RCS file: /home/cvs/jakarta-commons/docs/components.html,v retrieving revision 1.57 retrieving revision 1.58 diff -u -r1.57 -r1.58 --- components.html 19 Sep 2002 21:04:26 - 1.57 +++ components.html 26 Sep 2002 16:08:39 - 1.58 @@ -262,7 +262,7 @@ !-- /Digester -- !-- Discovery -- -dtbbiga href=http://cvs.apache.org/viewcvs/jakarta-commons/discovery/;Discovery/a/big/b/dt +dtbbiga href=http://jakarta.apache.org/commons/discovery/;Discovery/a/big/b/dt dd Commons-Discovery provides tools for locating resources (including classes) by mapping service/reference names to resource names using a variety of schemes. 1.6 +3 -4 jakarta-commons/docs/discovery.html Index: discovery.html === RCS file: /home/cvs/jakarta-commons/docs/discovery.html,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- discovery.html19 Sep 2002 21:04:26 - 1.5 +++ discovery.html26 Sep 2002 16:08:39 - 1.6 @@ -192,10 +192,9 @@ /td/tr trtd blockquote -pThe a href=http://jakarta.apache.org/commons/discovery/best-practices.html; -Best Practices/a document demonstrates best-practices for end-user developers -and for wrapper/factory classes that encapsulate discovery services./p -pThe a href=http://jakarta.apache.org/commons/discovery/api/index.html; +pThe a href=http://jakarta.apache.org/commons/discovery/;Home Page/a +tells you all about it./p +pThe a href=http://jakarta.apache.org/commons/discovery/apidocs/index.html; JavaDoc API documents/a are available online. In particular, you should read the package overview of the codeorg.apache.commons.discovery/code package./p 1.50 +1 -1 jakarta-commons/xdocs/components.xml Index: components.xml === RCS file: /home/cvs/jakarta-commons/xdocs/components.xml,v retrieving revision 1.49 retrieving revision 1.50 diff -u -r1.49 -r1.50 --- components.xml13 Sep 2002 04:10:08 - 1.49 +++ components.xml26 Sep 2002 16:08:39 - 1.50 @@ -95,7 +95,7 @@ !-- /Digester -- !-- Discovery -- -dtbbiga href=http://cvs.apache.org/viewcvs/jakarta-commons/discovery/;Discovery/a/big/b/dt +dtbbiga href=http://jakarta.apache.org/commons/discovery/;Discovery/a/big/b/dt dd Commons-Discovery provides tools for locating resources (including classes) by mapping service/reference names to resource names using a variety of schemes. 1.5 +3 -4 jakarta-commons/xdocs/discovery.xml Index: discovery.xml === RCS file: /home/cvs/jakarta-commons/xdocs/discovery.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- discovery.xml 16 Sep 2002 14:21:49 - 1.4 +++ discovery.xml 26 Sep 2002 16:08:39 - 1.5
RE: [discovery]
Try it again :) -Original Message- From: Robert [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 8:56 AM To: [EMAIL PROTECTED] Subject: [discovery] I went to find out more information about the discovery package, and the two links, best practices and the javadocs are both broken. Can someone point me to a correct URL (without having to download and build it first). Thanks, Robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [discovery]
On a related note, how do you update a 'mavenized' site such as discovery? It looks like James Strachan built the last one for discovery, how do I go about updating it, or can someone else please update it? Scott -Original Message- From: Scott Sanders Sent: Thursday, September 26, 2002 9:09 AM To: Jakarta Commons Developers List Subject: RE: [discovery] Try it again :) -Original Message- From: Robert [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 8:56 AM To: [EMAIL PROTECTED] Subject: [discovery] I went to find out more information about the discovery package, and the two links, best practices and the javadocs are both broken. Can someone point me to a correct URL (without having to download and build it first). Thanks, Robert -- 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]
Re: next possible commons project - [regexp]
Stephen Colebourne wrote: In the same way as [logging], by not being a regexp package itself. Of course it may just not be appropriate... To be honest, I don't like the autodiscovery mechanisms in Commons logging. I would be hard pressed to support another something like that for something less likely to be in widespread use. It is possible to just use the project that you need and stick with it for RegEx. There are very few projects out there that are meant to be used as a library that require a regex package (that I am aware of, but I don't get out much anymore). The chances of using two projects that require different RegEx solutions are so minute, that a commons version doesn't seem necessary. That's just my 2 cents. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] VOTE for cutting release 1.0.2
On Thursday, September 26, 2002, at 03:07 PM, Richard Sitze wrote: I volunteer(ed) [I wouldn't ask for a vote without doing that :-] I will happily stand aside if there is anyone with experience who would prefer to do it. i'm happy about you acting as release manager but it's probably better to say it explicitly. we gathered quite a few -1's (on this principle) the last time we tried to release without explicitly naming a release manager. - robert I DON'T have an account on daedelus, but I've had a number of offers from various folks, who do, that are willing to help me with that. *** Richard A. Sitze IBM WebSphere WebServices Development On Wednesday, September 25, 2002, at 11:07 PM, Richard Sitze wrote: snip 4. Folks, if you are committers, please update the commons-logging STATUS.html document with your name, and that includes myself! :-) 1. i'd suggestion that people do this ASAP since (by my count) there are not enough votes from committers for the required quorum. 2. a release manager is required. that person needs to be a committer (see 1) and (probably) needs an account on daedelus. any volunteers? (FYI my vote would be binding...) - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]. org For additional commands, e-mail: mailto:[EMAIL PROTECTED]. org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] VOTE for cutting release 1.0.2
now that richard is listed as a committer and we have a release manager, here's my +1. (by my count that's +3 (binding) votes now. which - i think - is enough to get started.) - robert On Thursday, September 26, 2002, at 04:48 PM, Scott Sanders wrote: Richard has volunteered, with the exception of daedalus issues, which I volunteered to help him with. Scott -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 4:05 AM To: Jakarta Commons Developers List Subject: Re: [logging] VOTE for cutting release 1.0.2 On Wednesday, September 25, 2002, at 11:07 PM, Richard Sitze wrote: snip 4. Folks, if you are committers, please update the commons-logging STATUS.html document with your name, and that includes myself! :-) 1. i'd suggestion that people do this ASAP since (by my count) there are not enough votes from committers for the required quorum. 2. a release manager is required. that person needs to be a committer (see 1) and (probably) needs an account on daedelus. any volunteers? (FYI my vote would be binding...) - robert -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]. org For additional commands, e-mail: mailto:[EMAIL PROTECTED]. org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[lang]Bug in StringUtils.deleteWhitespace()
I'm going through StringUtils, doing some doc cleanup. eg adding throws NullPointerException where a method will, and saying what will happen where it won't. I was going to add a note to this method, documenting which definition of whitespace was being used, when I realised something. The set of characters that deleteWhitespace cuts from a string doesn't match ANY of Java's definintions of whitespace. It will trim ' ' - space '\t' - horizontal tab '\r' - carriage return '\n' - line feed '\b' - backspace Backspace isn't a whitespace character. Formfeed, on the other hand, is. And this is ASCII (ISO-LATIN-1) only, Unicode has a superset definition of whitespace. I think the definition should be changed to: (cut and paste from javadoc for String.isSpace()) '\t' '\u0009' HORIZONTAL TABULATION '\n' '\u000A' NEW LINE '\f' '\u000C' FORM FEED '\r' '\u000D' CARRIAGE RETURN ' ' '\u0020' SPACE -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [logging] VOTE for cutting release 1.0.2
Steven, are you willing to either patch it to how you think it should work, or wait until a 1.1 release. The purpose of this release is to get another Apache product off of a nightly build before they ship. Are you still -1? Scott -Original Message- From: Steven Caswell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 1:22 PM To: 'Jakarta Commons Developers List' Subject: RE: [logging] VOTE for cutting release 1.0.2 I'm voting -1 because the issue I raised with the initialization of log4j added in 1.0.1 has not been resolved. http://marc.theaimsgroup.com/?l=jakarta-commons-devm=10305724 5722889w= 2 I assume this is a valid reason for a -1 vote. If not, someone please correct me (like I really need to say that :) ) Steven Caswell [EMAIL PROTECTED] a.k.a Mungo Knotwise of Michel Delving One ring to rule them all, one ring to find them... -Original Message- From: Richard Sitze [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 10:43 AM To: [EMAIL PROTECTED] Subject: [logging] VOTE for cutting release 1.0.2 There were some changes that went into commons-logging post 1.0.1. Not a lot of noise since then, so I'm presuming that things are stable. These changes are prereqs for AXIS 1.0 (scheduled for next week), so we would like to get them in a formal release. I'm a bit reluctant to call for a VOTE out of the blue, but there's no better way to learn than to try :-) So, this is a call for VOTE to cut a release 1.0.2. Target date is this weekend. I'd be happy to do what I can towards managing the release. ras *** Richard A. Sitze IBM WebSphere WebServices Development -- To unsubscribe, e-mail: mailto:commons-dev- [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]
Re: [logging] VOTE for cutting release 1.0.2
I volunteer to be the release manager. This is also my explicit vote for cutting 1.0.2: +1 By my count, current binding votes are at: +12 (scott sanders, richard sitze) +00 -10 *** Richard A. Sitze IBM WebSphere WebServices Development On Thursday, September 26, 2002, at 03:07 PM, Richard Sitze wrote: I volunteer(ed) [I wouldn't ask for a vote without doing that :-] I will happily stand aside if there is anyone with experience who would prefer to do it. i'm happy about you acting as release manager but it's probably better to say it explicitly. we gathered quite a few -1's (on this principle) the last time we tried to release without explicitly naming a release manager. - robert I DON'T have an account on daedelus, but I've had a number of offers from various folks, who do, that are willing to help me with that. *** Richard A. Sitze IBM WebSphere WebServices Development On Wednesday, September 25, 2002, at 11:07 PM, Richard Sitze wrote: snip 4. Folks, if you are committers, please update the commons-logging STATUS.html document with your name, and that includes myself! :-) 1. i'd suggestion that people do this ASAP since (by my count) there are not enough votes from committers for the required quorum. 2. a release manager is required. that person needs to be a committer (see 1) and (probably) needs an account on daedelus. any volunteers? (FYI my vote would be binding...) - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] . org For additional commands, e-mail: mailto:[EMAIL PROTECTED] . org -- 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: [logging] VOTE for cutting release 1.0.2
Correction, 3 +1s with Robert, and 1 -1 with Steven Caswell. Scott -Original Message- From: Richard Sitze [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 9:55 AM To: Jakarta Commons Developers List Subject: Re: [logging] VOTE for cutting release 1.0.2 I volunteer to be the release manager. This is also my explicit vote for cutting 1.0.2: +1 By my count, current binding votes are at: +12 (scott sanders, richard sitze) +00 -10 *** Richard A. Sitze IBM WebSphere WebServices Development On Thursday, September 26, 2002, at 03:07 PM, Richard Sitze wrote: I volunteer(ed) [I wouldn't ask for a vote without doing that :-] I will happily stand aside if there is anyone with experience who would prefer to do it. i'm happy about you acting as release manager but it's probably better to say it explicitly. we gathered quite a few -1's (on this principle) the last time we tried to release without explicitly naming a release manager. - robert I DON'T have an account on daedelus, but I've had a number of offers from various folks, who do, that are willing to help me with that. *** Richard A. Sitze IBM WebSphere WebServices Development On Wednesday, September 25, 2002, at 11:07 PM, Richard Sitze wrote: snip 4. Folks, if you are committers, please update the commons-logging STATUS.html document with your name, and that includes myself! :-) 1. i'd suggestion that people do this ASAP since (by my count) there are not enough votes from committers for the required quorum. 2. a release manager is required. that person needs to be a committer (see 1) and (probably) needs an account on daedelus. any volunteers? (FYI my vote would be binding...) - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] . org For additional commands, e-mail: mailto:[EMAIL PROTECTED] . org -- 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]
Re: [logging] VOTE for cutting release 1.0.2
I'll close the vote this evening. Unless the tallies change, I'll try to get a release out by end-of-day tomorrow. *** Richard A. Sitze IBM WebSphere WebServices Development now that richard is listed as a committer and we have a release manager, here's my +1. (by my count that's +3 (binding) votes now. which - i think - is enough to get started.) - robert On Thursday, September 26, 2002, at 04:48 PM, Scott Sanders wrote: Richard has volunteered, with the exception of daedalus issues, which I volunteered to help him with. Scott -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 4:05 AM To: Jakarta Commons Developers List Subject: Re: [logging] VOTE for cutting release 1.0.2 On Wednesday, September 25, 2002, at 11:07 PM, Richard Sitze wrote: snip 4. Folks, if you are committers, please update the commons-logging STATUS.html document with your name, and that includes myself! :-) 1. i'd suggestion that people do this ASAP since (by my count) there are not enough votes from committers for the required quorum. 2. a release manager is required. that person needs to be a committer (see 1) and (probably) needs an account on daedelus. any volunteers? (FYI my vote would be binding...) - robert -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] . org For additional commands, e-mail: mailto:[EMAIL PROTECTED] . org -- 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: [lang] StringUtils.containsOnly
On Thursday 26 September 2002 04:54 am, Stephen Colebourne wrote: My view is that one of the main advantages of StringUtils is to avoid NPEs. I actually thought that we'd been through all the methods and ensured that none of them did throw a NPE. I think that's overkill. You have to decide what to do with null, and often the right thing to do is throw an NPE. Treating null as generally isn't a good idea. If that's what you want, using StringUtils.clean() in the calling code works. As I sugested the method initially, I looked at what my own implementation of this does and what my needs are. Basically I find the current implementation fine: containsOnly(, anything but null) returns true containsOnly(null, anything) returns false Reasonable in this case. Although I'm not entirely convinced that containsOnly(string, null) shouldn't be an exception. If I were writing it from scratch, I'd probably leave it as one, but current clients now have reasonable expectation that it won't. IOW, I'm not suggesting changing anything, just clarifying documentation. Still, where we're writing methods that would naturally be part of the String API, ie instead of StringUtils.someMethod(string), we would have string.someMethod(), not throwing an NPE on someMethod(null) breaks the symmetry. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: next possible commons project - [regexp]
Stephen Colebourne writes: In the same way as [logging], by not being a regexp package itself. Of course it may just not be appropriate... I just want to point out that jakarta-oro is more than just a regular expression package and already contains the generic interfaces to wrap other packages (as it is, oro already implements 3 different regular expression grammars). It's a simple matter to add a factory to generate generic matchers for arbitrary regular expression packages. The project has plans to do this pending the completion of some other work, but anyone with an immediate need is welcome to put forth a design and start implementing. daniel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang] StringUtils.containsOnly
From: Steve Downey [EMAIL PROTECTED] On Thursday 26 September 2002 04:54 am, Stephen Colebourne wrote: My view is that one of the main advantages of StringUtils is to avoid NPEs. I actually thought that we'd been through all the methods and ensured that none of them did throw a NPE. I think that's overkill. You have to decide what to do with null, and often the right thing to do is throw an NPE. Treating null as generally isn't a good idea. If that's what you want, using StringUtils.clean() in the calling code works. I go further than this - in my world a product like [lang] would never throw NPEs. If it did then that would be a bug. If null is a disallowed parameter then that should be checked and thrown as an IllegalArgumentException. But thats just my coding style. Its probably a pity that we didn't agree a uniform approach to this, but its too late now. The priority is to document what we have correctly. Stephen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: next possible commons project - [regexp]
I just want to point out that jakarta-oro is more than just a regular expression package and already contains the generic interfaces to wrap other packages (as it is, oro already implements 3 different regular expression grammars). It's a simple matter to add a factory to generate generic matchers for arbitrary regular expression packages. The project has plans to do this pending the completion of some other work, but anyone with an immediate need is welcome to put forth a design and start implementing. Sounds like no work needed in commons then ;-) Stephen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang] StringUtils.containsOnly
Stephen Colebourne wrote: I go further than this - in my world a product like [lang] would never throw NPEs. If it did then that would be a bug. If null is a disallowed parameter then that should be checked and thrown as an IllegalArgumentException. But thats just my coding style. Its probably a pity that we didn't agree a uniform approach to this, but its too late now. The priority is to document what we have correctly. Stephen I have to agree with you on both of your points Stephen. NPE's are indicative of something terribly wrong. To me it is the Java equivalent of the C++ pointer error. At least with an IllegalArgumentException, you know you skrewed up using the method. An NPE could mean anything from an illegal argument (see, IllegalArgumentException) to the method is just completely foo-barred. I reserve NPEs for things that are foo-barred and IllegalArgumentExceptions for wrong arguments. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang]Bug in StringUtils.deleteWhitespace()
On Thursday 26 September 2002 12:50 pm, Steve Downey wrote: OOPS meant Character.isSpace() I think the definition should be changed to: (cut and paste from javadoc for String.isSpace()) '\t' '\u0009' HORIZONTAL TABULATION '\n' '\u000A' NEW LINE '\f' '\u000C' FORM FEED '\r' '\u000D' CARRIAGE RETURN ' ' '\u0020' SPACE -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH][HttpClient] bug 12607
I was just thinking that. It's a little ugly since there are a lot of exceptional productions, like any TEXT except , that would need to be defined, but even those aren't hard. On Thursday 26 September 2002 08:38 am, Jeff Dever wrote: The text string parsing is really not fun. One day we should go to regex pattern matching, which is not to difficult to construct from the BNF in the relevent RFCs. It will also be easier to handle non-standard/malformatted responses. Perhaps that will be HttpClient 3.0 ... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: next possible commons project
I don't think it makes sense. From a programmatic point of view, logging is side-effect free. Differences between logging packages are completely ignoreable. Even if logs are /dev/null. That is not the case for regular expressions. Different regular expression packages treat expressions differently. And converting between them is NOT possible. Differences would be very visible to the calling program. A match would return true with one package, false with another, and throw an exception with a third. There's a reason you have grep and egrep, and not just a single program. Not to mention perl, emacs, awk, ... The only sensible thing to do is to pick one and write the regular expressions in terms of that package, and test against that package. Now, jakarta does have two. I've always used ORO. I don't remember why I didn't use regexp. The fact that oro has had activity in the last 6 months is an important point, I think. The last two commits in regexp? 2001-08-24 17:58 jon * build/build-regexp.xml (1.10): do just enough work to allow an install-jar target this stuff needs to be upgraded 2001-04-12 18:03 gholam * build/build-regexp.xml (1.9): Added a few property imports users can override some settings. Is after the setting they should not be able to change eg project etc. Removed the build.compiler property from the build script. I prefer to have a global setting for this in ~/.ant/compiler.properties which can be overriden in this case by a value in ~/.ant/jakarta-regexp.properties. On Thursday 26 September 2002 09:04 am, Tomasz Pik wrote: Original Message Date: 26 Sep 2002 12:58:16 - Message-ID: [EMAIL PROTECTED] From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: DO NOT REPLY [Bug 13031] New: - Use regular expression (regex) pattern matching for parsing Status: Most of the parsing code in HttpClient is custom, and while fast, is potentially error prone. The traslation of the rfc BNF into regex would be a large maintainability improvement. Java 1.4 has a new regex package, and there are others that could be considered if a reliance on 1.4 is to be avoided. Maybe something like 'Commons Logging' - one hat (with limited funcionality) for most of the regexp packages (http://regex.info/java.html)? Regards Tomek Pik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: next possible commons project - [regexp]
On Thursday 26 September 2002 12:27 pm, Berin Loritsch wrote: Stephen Colebourne wrote: In the same way as [logging], by not being a regexp package itself. Of course it may just not be appropriate... To be honest, I don't like the autodiscovery mechanisms in Commons logging. I would be hard pressed to support another something like that for something less likely to be in widespread use. It is possible to just use the project that you need and stick with it for RegEx. There are very few projects out there that are meant to be used as a library that require a regex package (that I am aware of, but I don't get out much anymore). The chances of using two projects that require different RegEx solutions are so minute, that a commons version doesn't seem necessary. That's just my 2 cents. The odds of having two projects that require regexp packages that can also tolerate having the definition of regular expression changed underneath them approaches zero. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [discovery]
On a related note, how do you update a 'mavenized' site such as discovery? It looks like James Strachan built the last one for discovery, how do I go about updating it, or can someone else please update it? maven has a fancy goal that generates the site and updates cvs. of course, you'd need to install maven first... if that doesn't appeal let me know and i'll do give it a go. So, you do this on daedalus, or another machine and then scp up? Scott -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang] StringUtils.containsOnly
On Thu, 26 Sep 2002, Berin Loritsch wrote: Its probably a pity that we didn't agree a uniform approach to this, but its too late now. The priority is to document what we have correctly. Stephen I don't think this is a problem. The too late now. If we go from quiet-NPE it's a problem, but if we go from NPE-quiet behaviour then it's merely seen as strengthening the API, no one can or should be dependent on the NPE behaviour. Hen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang]Bug in StringUtils.deleteWhitespace()
Agreed. Need to change this to not use CharSetUtils probably and just return when Character.is.. returns true. My feckup I think. Want me to do the fix? Or you want to? Hen On Thu, 26 Sep 2002, Steve Downey wrote: On Thursday 26 September 2002 12:50 pm, Steve Downey wrote: OOPS meant Character.isSpace() I think the definition should be changed to: (cut and paste from javadoc for String.isSpace()) '\t' '\u0009' HORIZONTAL TABULATION '\n' '\u000A' NEW LINE '\f' '\u000C' FORM FEED '\r' '\u000D' CARRIAGE RETURN ' ' '\u0020' SPACE -- 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: [discovery]
Thanks, works now. The apache log (top left) doesn't show up, but I can live with that :-) - Robert -Original Message- From: Scott Sanders [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 11:09 AM To: Jakarta Commons Developers List Subject: RE: [discovery] Try it again :) -Original Message- From: Robert [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 8:56 AM To: [EMAIL PROTECTED] Subject: [discovery] I went to find out more information about the discovery package, and the two links, best practices and the javadocs are both broken. Can someone point me to a correct URL (without having to download and build it first). Thanks, Robert -- 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: [discovery]
On Thursday, September 26, 2002, at 07:01 PM, Scott Sanders wrote: On a related note, how do you update a 'mavenized' site such as discovery? It looks like James Strachan built the last one for discovery, how do I go about updating it, or can someone else please update it? maven has a fancy goal that generates the site and updates cvs. of course, you'd need to install maven first... if that doesn't appeal let me know and i'll do give it a go. So, you do this on daedalus, or another machine and then scp up? nope. local machine. not sure exactly what it does or how it works. you might need to do a checkout of cvs on daedalus to have the changes reflected on the live site - or then again, you might not. but i do know that's how i maintain the betwixt site (which is also mavenized). - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Design question on BeanUtils.populate()
i suppose that we could add another method which behaves as per the jsp spec. should be pretty simple to write (just remove parameters from the map). i don't know structs well enough to know whether this would be useful or not. - robert On Thursday, September 26, 2002, at 03:43 AM, Craig R. McClanahan wrote: On Wed, 25 Sep 2002, Scott Sanders wrote: Date: Wed, 25 Sep 2002 19:41:53 -0700 From: Scott Sanders [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List commons- [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: RE: Design question on BeanUtils.populate() Although jsp:setProperty was one of the inspirations that led to the creation of BeanUtils.populate(), I chose not to slavishly copy the JSP semantics -- in particular the very very wierd handling of zero-length Strings. I found it much more useful in typical form fill-in scenarios to deal with cases like this: * Form is displayed with a non-zero-length string value * User erases all the characters in the String (assumes an optional field) * When submitted, the corresponding bean property is changed to a zero length String The JSP semantics would fail to operate as expected in such a scenario Q. Is this going to be changed? I would -1 such a proposal. Q. Assuming above answer is no, why? Backwards compatibility. Every Struts-based app in the world depends on the current behavior implicitly, so changing it would break them all. I would also tend to agree. The jsp: semantic is brain dead. Sun, can you hear this? :) Of course ... but it's too late to change that semantic as well, for the same reason :-). Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]. org For additional commands, e-mail: mailto:[EMAIL PROTECTED]. org -- 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/sql QueryTag.java
jstrachan2002/09/26 11:35:23
Modified:jelly/src/java/org/apache/commons/jelly/tags/sql
QueryTag.java
Log:
Patch for bug scarab#12888
Revision ChangesPath
1.10 +18 -2
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/sql/QueryTag.java
Index: QueryTag.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/sql/QueryTag.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- QueryTag.java 1 Jun 2002 10:21:14 - 1.9
+++ QueryTag.java 26 Sep 2002 18:35:23 - 1.10
@@ -168,6 +168,8 @@
log.debug( About to lookup connection );
+ResultSet rs = null;
+Statement statement = null;
try {
conn = getConnection();
@@ -202,14 +204,14 @@
log.debug( About to execute query: + sqlStatement );
}
-ResultSet rs = null;
if ( hasParameters() ) {
PreparedStatement ps = conn.prepareStatement(sqlStatement);
setParameters(ps);
+statement = ps;
rs = ps.executeQuery();
}
else {
-Statement statement = conn.createStatement();
+statement = conn.createStatement();
rs = statement.executeQuery(sqlStatement);
}
@@ -220,6 +222,20 @@
throw new JellyException(sqlStatement + : + e.getMessage(), e);
}
finally {
+if (statement != null) {
+try {
+statement.close();
+}
+catch (SQLException e) {
+} // Not much we can do
+}
+if (rs != null) {
+try {
+rs.close();
+}
+catch (SQLException e) {
+} // Not much we can do
+}
if (conn != null !isPartOfTransaction) {
try {
conn.close();
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: next possible commons project - [regexp]
Steve Downey wrote: The odds of having two projects that require regexp packages that can also tolerate having the definition of regular expression changed underneath them approaches zero. I agree with this as far as most applications are concerned. I don't know the original motivation for this thread, but I can offer the reasons why it's thought to be useful in jakarta-oro. Having a generic API for regular expressions allows you to write text processing classes, for example tokenizers, whose use depends on user-defined regular expressions. The developer using the library can then choose a regular expression grammar that meets his particular needs or fancy. I view it more as a library-building convenience. But there are some instances where an application would make direct use of the facility. For example, a text search tool that lets you choose a regular expression grammar that you are familiar with. You write one search algorithm using a single set of interfaces, but the instances of those interfaces are user-determined and decided at run time. For the most part, however, applications that depend on statically predefined regular expression have no use for such a facility. In addition, the facility as conceived in jakarta-oro is not quite analogous to commons-logging because multiple regular expression engines can coexist in the same application and are not automatically chosen for you, while it's my understanding that commons-logging dynamically chooses one underlying logging library (which makes sense for logging). In any case, if anyone who has an immediate need for dynamically pluggable regular expression engines is welcome to make the addition to jakarta-oro instead of waiting for us to get around to it. daniel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12888] - [jelly] JDBC sql result set leak
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=12888. 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=12888 [jelly] JDBC sql result set leak [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-09-26 18:38 --- Well spotted Hristo. I've patched the code to close the statement then result set in the finally block. I hope thats the right order of doing things. This fix is now in CVS HEAD. -- 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/sql UpdateTag.java QueryTag.java
jstrachan2002/09/26 11:39:06
Modified:jelly/src/java/org/apache/commons/jelly/tags/sql
UpdateTag.java QueryTag.java
Log:
Patch for bug scarab#12889
Revision ChangesPath
1.6 +10 -1
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/sql/UpdateTag.java
Index: UpdateTag.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/sql/UpdateTag.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- UpdateTag.java1 Jun 2002 10:21:14 - 1.5
+++ UpdateTag.java26 Sep 2002 18:39:06 - 1.6
@@ -127,15 +127,17 @@
throw new JellyException(Resources.getMessage(SQL_NO_STATEMENT));
}
+Statement statement = null;
int result = 0;
try {
if ( hasParameters() ) {
PreparedStatement ps = conn.prepareStatement(sqlStatement);
+statement = ps;
setParameters(ps);
result = ps.executeUpdate();
}
else {
-Statement statement = conn.createStatement();
+statement = conn.createStatement();
result = statement.executeUpdate(sqlStatement);
}
if (var != null) {
@@ -146,6 +148,13 @@
throw new JellyException(sqlStatement + : + e.getMessage(), e);
}
finally {
+if (statement != null) {
+try {
+statement.close();
+}
+catch (SQLException e) {
+} // Not much we can do
+}
if (conn != null !isPartOfTransaction) {
try {
conn.close();
1.11 +1 -1
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/sql/QueryTag.java
Index: QueryTag.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/sql/QueryTag.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- QueryTag.java 26 Sep 2002 18:35:23 - 1.10
+++ QueryTag.java 26 Sep 2002 18:39:06 - 1.11
@@ -206,8 +206,8 @@
if ( hasParameters() ) {
PreparedStatement ps = conn.prepareStatement(sqlStatement);
-setParameters(ps);
statement = ps;
+setParameters(ps);
rs = ps.executeQuery();
}
else {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12889] - [jelly] MORE -JDBC sql result set leak.
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=12889. 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=12889 [jelly] MORE -JDBC sql result set leak. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-09-26 18:40 --- Well spotted Hristo. I've patched the code to close the statement in the finally block. This fix is now in CVS HEAD. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang] StringUtils.containsOnly
On Thursday 26 September 2002 01:23 pm, Berin Loritsch wrote: Stephen Colebourne wrote: I go further than this - in my world a product like [lang] would never throw NPEs. If it did then that would be a bug. If null is a disallowed parameter then that should be checked and thrown as an IllegalArgumentException. But thats just my coding style. Its probably a pity that we didn't agree a uniform approach to this, but its too late now. The priority is to document what we have correctly. Stephen I have to agree with you on both of your points Stephen. NPE's are indicative of something terribly wrong. To me it is the Java equivalent of the C++ pointer error. At least with an IllegalArgumentException, you know you skrewed up using the method. An NPE could mean anything from an illegal argument (see, IllegalArgumentException) to the method is just completely foo-barred. I reserve NPEs for things that are foo-barred and IllegalArgumentExceptions for wrong arguments. Well, I agree with you, Berin, and disagree with Stephen, I think. As I understand it, Stephen is arguing that StringUtils should never throw a runtime exception when presented with null. I'm arguing that it should. The runtime exception that java.lang.String throws in similar situations is NPE. IllegalArgumentException is starting to be adopted by other parts of the API for null arguments, eg JAXP, however. It was originally used for exceptions like undefined locale, or where an int is used as an enum and the argument wasn't one of the defined enums. If it is a case of arg == null, that can make sense. However, checking every object before access for being == to null, and converting that to a different exception leads to messy code. I don't like treating null as , which is the common 'solution' to avoiding NPEs. For example, in StringUtils.center(String str, int size), which embeds str in the center of a string of length size, right now you get an NPE if you call StringUtils.center(null, 80). You shouldn't ever call the method with null. It's not meaningful. I wouldn't like to see it return a string with 80 spaces. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] VOTE for cutting release 1.0.2
Richard Sitze wrote: I volunteer to be the release manager. This is also my explicit vote for cutting 1.0.2: +1 By my count, current binding votes are at: +12 (scott sanders, richard sitze) +00 -10 +1 as well. As this is a majority vote ( as any release vote ) - it seems to pass. ( unless 2 -1 votes will be made ). Regarding the status - not sure I understand what you need. If you are a commons commiter, you can add yourself to any commons project you like. Costin *** Richard A. Sitze IBM WebSphere WebServices Development On Thursday, September 26, 2002, at 03:07 PM, Richard Sitze wrote: I volunteer(ed) [I wouldn't ask for a vote without doing that :-] I will happily stand aside if there is anyone with experience who would prefer to do it. i'm happy about you acting as release manager but it's probably better to say it explicitly. we gathered quite a few -1's (on this principle) the last time we tried to release without explicitly naming a release manager. - robert I DON'T have an account on daedelus, but I've had a number of offers from various folks, who do, that are willing to help me with that. *** Richard A. Sitze IBM WebSphere WebServices Development On Wednesday, September 25, 2002, at 11:07 PM, Richard Sitze wrote: snip 4. Folks, if you are committers, please update the commons-logging STATUS.html document with your name, and that includes myself! :-) 1. i'd suggestion that people do this ASAP since (by my count) there are not enough votes from committers for the required quorum. 2. a release manager is required. that person needs to be a committer (see 1) and (probably) needs an account on daedelus. any volunteers? (FYI my vote would be binding...) - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] . org For additional commands, e-mail: mailto:[EMAIL PROTECTED] . org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang] StringUtils.containsOnly
On Thursday 26 September 2002 02:02 pm, Henri Yandell wrote: On Thu, 26 Sep 2002, Berin Loritsch wrote: Its probably a pity that we didn't agree a uniform approach to this, but its too late now. The priority is to document what we have correctly. Stephen I don't think this is a problem. The too late now. If we go from quiet-NPE it's a problem, but if we go from NPE-quiet behaviour then it's merely seen as strengthening the API, no one can or should be dependent on the NPE behaviour. Hen Actually, I strongly disagree with that. Going from NPE to quiet is a major change in behavior. Nulls will be treated as values, when they are not. And I wouldn't call it a strengthening of the API. It's a weakening of the preconditions. In any case, as I'm looking through right now, at least a few of the methods that claim not to thow NPEs, do. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang] StringUtils.containsOnly
Steve Downey wrote:
On Thursday 26 September 2002 01:23 pm, Berin Loritsch wrote:
Stephen Colebourne wrote:
I go further than this - in my world a product like [lang] would never
throw NPEs. If it did then that would be a bug. If null is a disallowed
parameter then that should be checked and thrown as an
IllegalArgumentException. But thats just my coding style.
Its probably a pity that we didn't agree a uniform approach to this, but
its too late now. The priority is to document what we have correctly.
Stephen
I have to agree with you on both of your points Stephen. NPE's are
indicative of something terribly wrong. To me it is the Java equivalent
of the C++ pointer error. At least with an IllegalArgumentException,
you know you skrewed up using the method. An NPE could mean anything
from an illegal argument (see, IllegalArgumentException) to the method
is just completely foo-barred. I reserve NPEs for things that are
foo-barred and IllegalArgumentExceptions for wrong arguments.
Well, I agree with you, Berin, and disagree with Stephen, I think.
As I understand it, Stephen is arguing that StringUtils should never throw a
runtime exception when presented with null. I'm arguing that it should. The
runtime exception that java.lang.String throws in similar situations is NPE.
IllegalArgumentException is starting to be adopted by other parts of the API
for null arguments, eg JAXP, however. It was originally used for exceptions
like undefined locale, or where an int is used as an enum and the argument
wasn't one of the defined enums.
If it is a case of arg == null, that can make sense. However, checking every
object before access for being == to null, and converting that to a different
exception leads to messy code.
Well, there is always this snippet:
public Handler createHander( String name, URL location, Class klass )
{
if ( null == name ||
null == location ||
null == klass )
{
throw new IllegalArgumentException( Cannot have any null
arguments);
}
//
}
I have seen a number of factory methods or methods with several
paramters perform this bulk null check. I have also seen the creation
of Validator classes. The Validator class would both ensure nothing was
null, and make sure methods were called in the proper order. The above
code would be rewritten using a Validator like this:
public Handler createHandler( String name, URL location, Class klass )
{
FactoryValidator.checkCreate( name, location, klass )
//
}
It cleans up the critical path for the code quite a bit while allowing
you to perform meaningful exceptions. It's more work, though.
I don't like treating null as , which is the common 'solution' to avoiding
NPEs. For example, in StringUtils.center(String str, int size), which embeds
str in the center of a string of length size, right now you get an NPE if you
call StringUtils.center(null, 80). You shouldn't ever call the method with
null. It's not meaningful. I wouldn't like to see it return a string with 80
spaces.
It really depends on the usage. When I have a class that has several
arguments in the constructor, I use several constructors and fill in the
blanks with reasonable defaults. It works well--but you have to
document what the defaults are.
In this case, you are probably right. It is not meaningful to center an
empty string either, but it is easier to code a loop that way:
while ( line = in.readLine() != null )
{
System.out.println( StringUtil.center( line, 80 ) );
}
Then again, what is the *harm* in converting null to an empty string?
Is the harm worse than throwing an exception? In the center() method,
there is no real harm. For something else, there may be some real harm.
If there is real harm, I always throw an exception.
--
They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety.
- Benjamin Franklin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang] StringUtils.containsOnly
Steve Downey wrote: On Thursday 26 September 2002 02:02 pm, Henri Yandell wrote: On Thu, 26 Sep 2002, Berin Loritsch wrote: Its probably a pity that we didn't agree a uniform approach to this, but its too late now. The priority is to document what we have correctly. Stephen I don't think this is a problem. The too late now. If we go from quiet-NPE it's a problem, but if we go from NPE-quiet behaviour then it's merely seen as strengthening the API, no one can or should be dependent on the NPE behaviour. Hen Actually, I strongly disagree with that. Going from NPE to quiet is a major change in behavior. Nulls will be treated as values, when they are not. And I wouldn't call it a strengthening of the API. It's a weakening of the preconditions. In any case, as I'm looking through right now, at least a few of the methods that claim not to thow NPEs, do. My point is not to remove the throwing of exceptions, but to throw an exception that is more meaningful. The NPE is automatically thrown by the system if you try to perform an action on a null reference--AKA the C++ pointer error analogy. That is why I prefer to use IllegalArgumentExceptions instead. We are not weakening preconditions, but we are letting the user of the API know where the problem is (in the arguments passed in). -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang] StringUtils.containsOnly
On Thu, 26 Sep 2002, Berin Loritsch wrote: Steve Downey wrote: In any case, as I'm looking through right now, at least a few of the methods that claim not to thow NPEs, do. My point is not to remove the throwing of exceptions, but to throw an exception that is more meaningful. The NPE is automatically thrown by the system if you try to perform an action on a null reference--AKA the C++ pointer error analogy. That is why I prefer to use IllegalArgumentExceptions instead. We are not weakening preconditions, but we are letting the user of the API know where the problem is (in the arguments passed in). Didn't this come up before? And large amounts of Java threw NPE instead of IAE in this case? Seem to recall deleting the thread last night while trimming my inbox... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang] StringUtils.containsOnly
On Thu, 26 Sep 2002, Steve Downey wrote: On Thursday 26 September 2002 02:02 pm, Henri Yandell wrote: I don't think this is a problem. The too late now. If we go from quiet-NPE it's a problem, but if we go from NPE-quiet behaviour then it's merely seen as strengthening the API, no one can or should be dependent on the NPE behaviour. Hen Actually, I strongly disagree with that. Going from NPE to quiet is a major change in behavior. Nulls will be treated as values, when they are not. And I wouldn't call it a strengthening of the API. It's a weakening of the preconditions. In any case, as I'm looking through right now, at least a few of the methods that claim not to thow NPEs, do. I don't see how it is a major change in behaviour. It in no way modifies the way a user would be using the API, unless I'm living in a perfect world where people wouldn't link functionality to the throwing of an NPE... Whereas the other direction, I can see people happily throwing in null's, then we change the library and suddenly their systems fall over. That's what I class a major API change. NPE - quiet shouldn't break anything using the API unless they're being very silly Hen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/recursion ElementBean.java TestRecursion.java
rdonkin 2002/09/26 12:29:34
Modified:betwixt/src/java/org/apache/commons/betwixt XMLBeanInfo.java
betwixt/src/test/org/apache/commons/betwixt/recursion
ElementBean.java TestRecursion.java
Log:
Fix bug with id generation when bean already had an id property.
Revision ChangesPath
1.4 +10 -3
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/XMLBeanInfo.java
Index: XMLBeanInfo.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/XMLBeanInfo.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- XMLBeanInfo.java 1 Jul 2002 18:44:15 - 1.3
+++ XMLBeanInfo.java 26 Sep 2002 19:29:33 - 1.4
@@ -124,10 +124,17 @@
/** Search attributes for one matching codeID/code attribute name */
public AttributeDescriptor getIDAttribute() {
-if ( cachedIDAttribute = false ) {
+//
+// XXX for some reason caching isn't working at the moment
+// it could be that this method is called too early
+// and not reset when attributes change
+// on the other hand, the speed gain is likely to be too
+// small to bother about
+//
+//if ( cachedIDAttribute = false ) {
idAttributeDescriptor = findIDAttribute();
-cachedIDAttribute = true;
-}
+ // cachedIDAttribute = true;
+//}
return idAttributeDescriptor;
}
1.2 +62 -1
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/recursion/ElementBean.java
Index: ElementBean.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/recursion/ElementBean.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ElementBean.java 30 Jul 2002 22:47:41 - 1.1
+++ ElementBean.java 26 Sep 2002 19:29:34 - 1.2
@@ -1,10 +1,71 @@
+/*
+ * $Header$
+ * $Revision$
+ * $Date$
+ *
+ *
+ *
+ * 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
Re: [lang] StringUtils.containsOnly
Henri Yandell wrote: On Thu, 26 Sep 2002, Berin Loritsch wrote: Steve Downey wrote: In any case, as I'm looking through right now, at least a few of the methods that claim not to thow NPEs, do. My point is not to remove the throwing of exceptions, but to throw an exception that is more meaningful. The NPE is automatically thrown by the system if you try to perform an action on a null reference--AKA the C++ pointer error analogy. That is why I prefer to use IllegalArgumentExceptions instead. We are not weakening preconditions, but we are letting the user of the API know where the problem is (in the arguments passed in). Didn't this come up before? Dunno, I wasn't paying attention. And large amounts of Java threw NPE instead of IAE in this case? That's a lemming argument if I ever heard it. All my friends are jumping off a cliff, it must be the right thing to do! ;P Seriously, my suggestion will help the users of the API to debug their applications faster. The fact that NPE is automatically thrown by the JVM makes it confusing to track down the origination of that exception. At least with an IAE the user has a clue that their code is at fault. Seem to recall deleting the thread last night while trimming my inbox... You will probably delete this as well -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: next possible commons project - [regexp]
On Thursday 26 September 2002 02:35 pm, Daniel F. Savarese wrote: Steve Downey wrote: The odds of having two projects that require regexp packages that can also tolerate having the definition of regular expression changed underneath them approaches zero. I agree with this as far as most applications are concerned. I don't know the original motivation for this thread, but I can offer the reasons why it's thought to be useful in jakarta-oro. The original motivation was a proposal to have a commons-regexp package like commons-logging that would abstract out the differences between different regexp packages. IOW, to be able to plug either jakarta-regexp or jakarta-oro in as implementation where a regexp is required. Actually the original motivation was the suggestion that HttpClient's parser use regular expressions to match parts of the HTTP spec, rather than write the parser by hand. The spec provides BNF, and converting that to regular expressions is fairly straightforward. Since the regular expressions would have to be defined and understood by HttpClient, changing the implementation of the regular expression parser would probably cause bugs. Either the regexp would be illegal, or return different results. Also, one of the motivations for commons-logging was that logging needs to interoperate. Two logging packages for an application is a disaster. Two regexp packages for an application is an inconvienence. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/recursion IdBean.java
rdonkin 2002/09/26 13:00:10
Added: betwixt/src/test/org/apache/commons/betwixt/recursion
IdBean.java
Log:
Fix bug with id generation when bean already had an id property.
Revision ChangesPath
1.1
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/recursion/IdBean.java
Index: IdBean.java
===
/*
* $Header:
/home/cvs/jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/recursion/IdBean.java,v
1.1 2002/09/26 20:00:10 rdonkin Exp $
* $Revision: 1.1 $
* $Date: 2002/09/26 20:00:10 $
*
*
*
* 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/.
*
* $Id: IdBean.java,v 1.1 2002/09/26 20:00:10 rdonkin Exp $
*/
package org.apache.commons.betwixt.recursion;
import java.util.ArrayList;
import java.util.List;
/**
* Used to test mapping of id's to
*
* @author Robert Burrell Donkin
* @version $Id: IdBean.java,v 1.1 2002/09/26 20:00:10 rdonkin Exp $
*/
public class IdBean
{
private String id;
private String notId;
public IdBean(String id)
{
setId(id);
}
public String getId()
{
return id;
}
public void setId(String id)
{
this.id = id;
}
public String getNotId()
{
return notId;
}
public void setNotId(String notId)
{
this.notId = notId;
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12888] - [jelly] JDBC sql result set leak
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=12888.
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=12888
[jelly] JDBC sql result set leak
--- Additional Comments From [EMAIL PROTECTED] 2002-09-26 20:26 ---
That's probably the wrong order. It's usual to close in inverse order from open.
Here's the canonical code for this kind of thing:
stmt = connection.prepareStatment(something);
try {
ResultSet rs = stmt.executeQuery();
try {
//do stuff with result set
} finally {
rs.close();
}
} finally {
stmt.close();
}
One of the guarantees of JDBC is that the creation methods never return null.
They will throw an exception. So the appropriate pattern to is to use
try{}finally{} directly after creation to clean up. Checks for null in a finally
block at the end of the entire method prove to be error prone under maintenance.
I believe closing a statement without closing the result set could lead to
exceptions, as the result set is attacted to the statement. Although in this
case, it's probably safe.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang] StringUtils.containsOnly
On Thursday 26 September 2002 03:28 pm, Berin Loritsch wrote: Steve Downey wrote: On Thursday 26 September 2002 02:02 pm, Henri Yandell wrote: On Thu, 26 Sep 2002, Berin Loritsch wrote: Its probably a pity that we didn't agree a uniform approach to this, but its too late now. The priority is to document what we have correctly. Stephen I don't think this is a problem. The too late now. If we go from quiet-NPE it's a problem, but if we go from NPE-quiet behaviour then it's merely seen as strengthening the API, no one can or should be dependent on the NPE behaviour. Hen Actually, I strongly disagree with that. Going from NPE to quiet is a major change in behavior. Nulls will be treated as values, when they are not. And I wouldn't call it a strengthening of the API. It's a weakening of the preconditions. In any case, as I'm looking through right now, at least a few of the methods that claim not to thow NPEs, do. My point is not to remove the throwing of exceptions, but to throw an exception that is more meaningful. The NPE is automatically thrown by the system if you try to perform an action on a null reference--AKA the C++ pointer error analogy. That is why I prefer to use IllegalArgumentExceptions instead. We are not weakening preconditions, but we are letting the user of the API know where the problem is (in the arguments passed in). But that's not what we're discussing. It's not whether NPE or IAE should be thrown, but whether an exception should be thrown at all. And in cases where detection of a null is trivial, I agree that IAE is more meaningful than NPE. Even though Sun didn't do things that way. Later today (hopefully) I'll post a documentation patch that will, with any luck, make things clearer. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang] StringUtils.containsOnly
On Thu, 26 Sep 2002, Berin Loritsch wrote: Henri Yandell wrote: Didn't this come up before? Dunno, I wasn't paying attention. And large amounts of Java threw NPE instead of IAE in this case? That's a lemming argument if I ever heard it. All my friends are jumping off a cliff, it must be the right thing to do! ;P Seriously, my suggestion will help the users of the API to debug their applications faster. The fact that NPE is automatically thrown by the JVM makes it confusing to track down the origination of that exception. At least with an IAE the user has a clue that their code is at fault. Yeah, I think it's something that needs to be done as a rule by the Lang project. All XxxUtils classes should protect from NPE and throw IAE. Big question for me is, does this hold up a 1.0 release? Modifying a method that currently takes null to throw an IAE is a big bomb for an addicted future user, does it matter if we release with quiet methods in some places? Equally, we have many addicted users already, so we're going to have the big bomb problem at some point. Hen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [beanutils] Question about BeanComparator
hi eric
1. i do think that an intelligent bean comparator would be cool and
plug-ins seem like the right way to do it.
2. just FYI we're pushing towards a beanutils release very soon now so be
careful about committing any signatures that might need to be changed
later.
- robert
On Thursday, September 26, 2002, at 10:24 PM, [EMAIL PROTECTED] wrote:
Hi,
This question is mostly focused for Henri, but anyone can comment. I am
working on a testcase for BeanComparator, and one that comes up is if I
try
and compare two Boolean objects. Because Boolean doesn't support
Comparable, they crash. I change BeanComparator to have a makeComparable
method:
private Comparable makeComparable( Object o )
throws ClassCastException {
Comparable value = null;
if ( o == null ) {
value = new String( );
}
else if ( o instanceof Boolean ) {
Boolean b = (Boolean) o;
if ( b.booleanValue() ) {
value = new Integer( 1 );
}
else {
value = new Integer( 0 );
}
}
else if ( o instanceof Comparable ) {
value = (Comparable) o;
}
else {
throw new ClassCastException( Object + o.getClass().getName()
+
is not a comparable datatype, or convertable. );
}
return value;
}
Now, I know that this means that as various datatypes are introduced, then
this needs to be changed. What I am wondering though is that being able
to
compare booleans is pretty basic. However, I was also thinking that I
would
create SafeComparator that would be smart enough to make nulls into blank
strings, booleans into 1 and 0 etc...? Heck, if you got crazy, it could
be
pluggable similar to the transformer stuff so that any datatype could be
made a comparable object. What are your opinions? I at least want to get
my first cut of unit tests into CVS.
Eric Pugh
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED].
org
For additional commands, e-mail: mailto:[EMAIL PROTECTED].
org
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[lang] [PATCH] StringUtils documentation
Added @throws for methods that throw exceptions, and brought docs in line with actual behavior for a couple of methods. In particular String.trim() doesn't actually trim just whitespace (!). I suspect poor original coding, then being stuck with it. WRT deleteWhitespace(String), I propose that this be broken into two methods, deleteSpace() and deleteWhitespace(), which would cut characters based on isSpace() and isWhitespace() respectively? This patch just documents the existing behavior. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang] [PATCH] StringUtils documentation
Tried to get this out before being called to dinner. Should have waited til
after. Patch attached.
On Thursday 26 September 2002 05:58 pm, Steve Downey wrote:
Added @throws for methods that throw exceptions, and brought docs in line
with actual behavior for a couple of methods. In particular String.trim()
doesn't actually trim just whitespace (!). I suspect poor original coding,
then being stuck with it.
WRT deleteWhitespace(String), I propose that this be broken into two
methods, deleteSpace() and deleteWhitespace(), which would cut characters
based on isSpace() and isWhitespace() respectively?
This patch just documents the existing behavior.
Index: StringUtils.java
===
RCS file: /home/cvspublic/jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java,v
retrieving revision 1.12
diff -u -w -r1.12 StringUtils.java
--- StringUtils.java 21 Sep 2002 05:02:43 - 1.12
+++ StringUtils.java 26 Sep 2002 21:52:49 -
@@ -95,8 +95,8 @@
//--
/**
- * Removes white space from both ends of this string, handling null
- * by returning an empty string.
+ * Removes control characters, including whitespace, from both ends of this
+ * string, handling null by returning an empty string.
*
* @see java.lang.String#trim()
* @param str the string to check
@@ -107,8 +107,8 @@
}
/**
- * Removes white space from both ends of this string, handling null
- * by returning null.
+ * Removes control characters, including whitespace, from both ends of this
+ * string, handling null by returning null.
*
* @see java.lang.String#trim()
* @param str the string to check
@@ -120,9 +120,11 @@
/**
* Deletes all whitespace from a String.
+ * Whitespace is defined as {' ', '\t', '\r', '\n', '\b'}
*
* @param str String target to delete whitespace from
* @return the text without whitespace
+ * @throws NullPointerException
*/
public static String deleteWhitespace(String str) {
return CharSetUtils.delete(str, \t\r\n\b);
@@ -156,6 +158,7 @@
* Nulls are handled without exceptions. Two codenull/code
* references are considered equal. Comparison is case sensitive.
*
+ * @see java.lang.String#equals(String)
* @param str1 the first string
* @param str2 the second string
* @return true if the Strings are equal, case sensitive, or both null
@@ -168,7 +171,7 @@
* Compares two Strings, returning true if they are equal ignoring case.
* Nulls are handled without exceptions. Two codenull/code
* references are considered equal. Comparison is case insensitive.
- *
+ * @see java.lang.String#equalsIgnoreCase(String)
* @param str1 the first string
* @param str2 the second string
* @return true if the Strings are equal, case insensitive, or both null
@@ -184,6 +187,7 @@
* @param str the string to check
* @param searchStrs the strings to search for
* @return the earliest index of any of the strings
+ * @throws NullPointerException if any of searchStrs[i] is null
*/
public static int indexOfAny(String str, String[] searchStrs) {
if ((str == null) || (searchStrs == null)) {
@@ -216,6 +220,7 @@
* @param str the string to check
* @param searchStrs the strings to search for
* @return the last index of any of the strings
+ * @throws NullPointerException if any of searchStrs[i] is null
*/
public static int lastIndexOfAny(String str, String[] searchStrs) {
if ((str == null) || (searchStrs == null)) {
@@ -569,6 +574,7 @@
* @param max maximum number of values to replace, or
* code-1/code if no maximum
* @return the text with any replacements processed
+ * @throws NullPointerException if repl is null
*/
public static String replace(String text, String repl, String with,
int max) {
@@ -598,6 +604,7 @@
* @param start int to start overlaying at
* @param end int to stop overlaying before
* @return String with overlayed text
+ * @throws NullPointerException if text or overlay is null
*/
public static String overlayString(String text, String overlay, int start, int end) {
return new StringBuffer(start + overlay.length() + text.length() - end + 1)
@@ -612,11 +619,13 @@
/**
* Center a string in a larger string of size n.
- * Uses spaces as the value to buffer the string with..
+ * Uses spaces as the value to buffer the string with.
+ * Equivalent to codecenter(str, size, )/code
*
* @param str String to center
* @param size int size of new String
* @return String containing centered String
+ * @throws NullPointerException if str
RE: [beanutils] Question about BeanComparator
I think Ola and Robert and Henri are all correct.. I think I was just
looking for a bit of a push in the right direction! Should I submit my test
case for BeanComparator now (with my test on booleans removed), or wait a
bit?
Also, I will pull out my code (in my environment I pretty much know if true
comes before false etc) and put them into some sort of SafeComparator in my
own tree.
Where is ObjectComparator in terms of work? Should I use it, or just go
with my own somewhat nasty SafeComparator filled with hardcoded assumptions?
Eric
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 26, 2002 6:03 PM
To: Jakarta Commons Developers List
Subject: Re: [beanutils] Question about BeanComparator
I concur with both Ola and Robert.
The Boolean aspect is just a single part of what I've been calling
ObjectComparator, a Comparator than can compare anything. It has big
issues in terms of having to delegate to various hard coded comparators,
and be pluggable with user's comparators.
There's nothing to stop you doing:
BeanComparator cmp = new BeanComparator(active, new BooleanComparator());
is there?
Hen
On Thu, 26 Sep 2002, robert burrell donkin wrote:
hi eric
1. i do think that an intelligent bean comparator would be cool and
plug-ins seem like the right way to do it.
2. just FYI we're pushing towards a beanutils release very soon now so be
careful about committing any signatures that might need to be changed
later.
- robert
On Thursday, September 26, 2002, at 10:24 PM, [EMAIL PROTECTED] wrote:
Hi,
This question is mostly focused for Henri, but anyone can comment. I am
working on a testcase for BeanComparator, and one that comes up is if I
try
and compare two Boolean objects. Because Boolean doesn't support
Comparable, they crash. I change BeanComparator to have a
makeComparable
method:
private Comparable makeComparable( Object o )
throws ClassCastException {
Comparable value = null;
if ( o == null ) {
value = new String( );
}
else if ( o instanceof Boolean ) {
Boolean b = (Boolean) o;
if ( b.booleanValue() ) {
value = new Integer( 1 );
}
else {
value = new Integer( 0 );
}
}
else if ( o instanceof Comparable ) {
value = (Comparable) o;
}
else {
throw new ClassCastException( Object + o.getClass().getName()
+
is not a comparable datatype, or convertable. );
}
return value;
}
Now, I know that this means that as various datatypes are introduced,
then
this needs to be changed. What I am wondering though is that being able
to
compare booleans is pretty basic. However, I was also thinking that I
would
create SafeComparator that would be smart enough to make nulls into
blank
strings, booleans into 1 and 0 etc...? Heck, if you got crazy, it could
be
pluggable similar to the transformer stuff so that any datatype could be
made a comparable object. What are your opinions? I at least want to
get
my first cut of unit tests into CVS.
Eric Pugh
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED].
org
For additional commands, e-mail:
mailto:[EMAIL PROTECTED].
org
--
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]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [beanutils] Question about BeanComparator
On Thursday 26 September 2002 05:59 pm, Ola Berg wrote: Eric Pugh writes: What I am wondering though is that being able to compare booleans is pretty basic. philosophical-mode Is it? Which one is larger, true or false? In your code you assumed that (true false). Why not the other way around? /philosophical-mode To me, it is tempting to consider them equal for sorting purposes, which means that boolean values should be ignored when comparing. That's bad. You don't want a disjunction between compareTo and equals. Since true != false, a comparison between true and false should order them. However, you're right the ordering is essentially arbitrary for true and false. On most chips, true would be less than false, since -1 0, and -1 is the usual definition of true at the chip level. Conventionally, though true false. Java dodges the issue by not defining on boolean types. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jelly .cvsignore
dion2002/09/26 16:03:53 Modified:jelly.cvsignore Log: Added eclipse classpath file Revision ChangesPath 1.10 +1 -0 jakarta-commons-sandbox/jelly/.cvsignore Index: .cvsignore === RCS file: /home/cvs/jakarta-commons-sandbox/jelly/.cvsignore,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- .cvsignore26 Sep 2002 18:07:37 - 1.9 +++ .cvsignore26 Sep 2002 23:03:53 - 1.10 @@ -8,3 +8,4 @@ snapshot.bat tmp demopage.html +.classpath -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [discovery]
Nope, you do it on your machine and it scps it all to daedalus and untars it there for you. -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers Scott Sanders [EMAIL PROTECTED] wrote on 27/09/2002 04:01:06 AM: On a related note, how do you update a 'mavenized' site such as discovery? It looks like James Strachan built the last one for discovery, how do I go about updating it, or can someone else please update it? maven has a fancy goal that generates the site and updates cvs. of course, you'd need to install maven first... if that doesn't appeal let me know and i'll do give it a go. So, you do this on daedalus, or another machine and then scp up? Scott -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [discovery]
maven site:deploy will do it. Is there an interest in getting it done automatically? i.e. similar to Craig's nightly builds, having a nightly site build for various mavenized projects? -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers Scott Sanders [EMAIL PROTECTED] wrote on 27/09/2002 02:12:50 AM: On a related note, how do you update a 'mavenized' site such as discovery? It looks like James Strachan built the last one for discovery, how do I go about updating it, or can someone else please update it? Scott -Original Message- From: Scott Sanders Sent: Thursday, September 26, 2002 9:09 AM To: Jakarta Commons Developers List Subject: RE: [discovery] Try it again :) -Original Message- From: Robert [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 8:56 AM To: [EMAIL PROTECTED] Subject: [discovery] I went to find out more information about the discovery package, and the two links, best practices and the javadocs are both broken. Can someone point me to a correct URL (without having to download and build it first). Thanks, Robert -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang] StringUtils.containsOnly
+1 on adding the throws for IllegalArgumentException. -1 on NPEs. +0 on silent failure. -- Daniel Rall [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: next possible commons project - [regexp]
Steve Downey [EMAIL PROTECTED] writes: On Thursday 26 September 2002 12:27 pm, Berin Loritsch wrote: Stephen Colebourne wrote: In the same way as [logging], by not being a regexp package itself. Of course it may just not be appropriate... To be honest, I don't like the autodiscovery mechanisms in Commons logging. I would be hard pressed to support another something like that for something less likely to be in widespread use. It is possible to just use the project that you need and stick with it for RegEx. There are very few projects out there that are meant to be used as a library that require a regex package (that I am aware of, but I don't get out much anymore). The chances of using two projects that require different RegEx solutions are so minute, that a commons version doesn't seem necessary. That's just my 2 cents. The odds of having two projects that require regexp packages that can also tolerate having the definition of regular expression changed underneath them approaches zero. I agree whole heartedly with that statement. Jakarta Regexp does not handle nearly the same range of regular expressions which ORO handles (its use case is different). Trying to treat the two engines as the same is insanity. -- Daniel Rall [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang]Bug in StringUtils.deleteWhitespace()
Let's get this change into the 1.0 final. Henri Yandell [EMAIL PROTECTED] writes: Agreed. Need to change this to not use CharSetUtils probably and just return when Character.is.. returns true. My feckup I think. Want me to do the fix? Or you want to? Hen On Thu, 26 Sep 2002, Steve Downey wrote: On Thursday 26 September 2002 12:50 pm, Steve Downey wrote: OOPS meant Character.isSpace() I think the definition should be changed to: (cut and paste from javadoc for String.isSpace()) '\t' '\u0009' HORIZONTAL TABULATION '\n' '\u000A' NEW LINE '\f' '\u000C' FORM FEED '\r' '\u000D' CARRIAGE RETURN ' ' '\u0020' SPACE -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [discovery]
Martin Cooper [EMAIL PROTECTED] wrote on 27/09/2002 09:18:48 AM: [snip] Is there an interest in getting it done automatically? i.e. similar to Craig's nightly builds, having a nightly site build for various mavenized projects? Sounds good to me. There was some discussion a while ago on general@ where a desire was expressed that the number of people who have direct access to daedalus should be limited. Having a nightly site update allows for updates for a project even when none of the project committers has privs on daedalus. (It also allows for cases like mine, where I've never got site:deploy to work from my Win98 box :) Which projects that you work with would you like updated regularly? I've got daedalus access, and a Win2k box that works for deployment. We can take the Win98 issue over to turbine-maven-user anytime -- Martin Cooper [snip] -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [discovery]
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 5:07 PM To: Jakarta Commons Developers List Subject: RE: [discovery] Martin Cooper [EMAIL PROTECTED] wrote on 27/09/2002 09:18:48 AM: [snip] Is there an interest in getting it done automatically? i.e. similar to Craig's nightly builds, having a nightly site build for various mavenized projects? Sounds good to me. There was some discussion a while ago on general@ where a desire was expressed that the number of people who have direct access to daedalus should be limited. Having a nightly site update allows for updates for a project even when none of the project committers has privs on daedalus. (It also allows for cases like mine, where I've never got site:deploy to work from my Win98 box :) Which projects that you work with would you like updated regularly? FileUpload and Resources, both in the sandbox (assuming you're going to do sandbox components - if not, don't worry about it). I've got daedalus access, and a Win2k box that works for deployment. We can take the Win98 issue over to turbine-maven-user anytime I tried to resolve it over there before, and got tangled up in the certificate tools. Jason mentioned the names of the tools, but I never quite figured out how to get it all to work. I haven't tried for a while, though. If I still have problems, I'll bring it up again over there. Thanks. -- Martin Cooper -- Martin Cooper [snip] -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers -- 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: [discovery]
Martin Cooper [EMAIL PROTECTED] wrote on 27/09/2002 09:57:21 AM: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 5:07 PM To: Jakarta Commons Developers List Subject: RE: [discovery] Martin Cooper [EMAIL PROTECTED] wrote on 27/09/2002 09:18:48 AM: [snip] Is there an interest in getting it done automatically? i.e. similar to Craig's nightly builds, having a nightly site build for various mavenized projects? Sounds good to me. There was some discussion a while ago on general@ where a desire was expressed that the number of people who have direct access to daedalus should be limited. Having a nightly site update allows for updates for a project even when none of the project committers has privs on daedalus. (It also allows for cases like mine, where I've never got site:deploy to work from my Win98 box :) Which projects that you work with would you like updated regularly? FileUpload and Resources, both in the sandbox (assuming you're going to do sandbox components - if not, don't worry about it). Yep, for sandbox, we could set up a reactor that works like the one for commons. I've got daedalus access, and a Win2k box that works for deployment. We can take the Win98 issue over to turbine-maven-user anytime I tried to resolve it over there before, and got tangled up in the certificate tools. Jason mentioned the names of the tools, but I never quite figured out how to get it all to work. I haven't tried for a while, though. If I still have problems, I'll bring it up again over there. Cool. -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13050] - Port 80 is needed to run tests
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=13050. 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=13050 Port 80 is needed to run tests --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 00:50 --- 2.0 Alpha 1 was distributed with Cactus 1.4.1: http://jakarta.apache.org/builds/jakarta-cactus/release/v1.4.1/jakarta-cactus- 13-1.4.1.zip -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang] StringUtils.containsOnly
What about this case:
public static int indexOfAny(String str, String[] searchStrs) {
if ((str == null) || (searchStrs == null)) {
return -1;
}
int sz = searchStrs.length;
// String's can't have a MAX_VALUEth index.
int ret = Integer.MAX_VALUE;
int tmp = 0;
for (int i = 0; i sz; i++) {
tmp = str.indexOf(searchStrs[i]);
if (tmp == -1) {
continue;
}
if (tmp ret) {
ret = tmp;
}
}
This throws a NullPointerException. Should we convert that to an IAE?
Also, this is a case of 'fixing' the standard Java library.
String.indexOf(String str) will throw a NPE if str is null. [That's where
indexOfAny will throw] It also can't be called on a null string.
I'm not saying there isn't a place for 'safe' APIs. But, in my opinion, they
should be an alternative, not the default.
On Thursday 26 September 2002 08:14 pm, Steven Caswell wrote:
My opinion, in this order:
+1 on silent handling of null
+1 on throwing IAE if silent handling doesn't make sense
-1 on throwing NPE
Steven Caswell
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/logging build.xml
rsitze 2002/09/26 19:02:06 Modified:logging build.xml Log: Version 1.0.2 Revision ChangesPath 1.20 +2 -2 jakarta-commons/logging/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-commons/logging/build.xml,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- build.xml 13 Aug 2002 01:22:33 - 1.19 +++ build.xml 27 Sep 2002 02:02:06 - 1.20 @@ -45,7 +45,7 @@ property name=component.title value=Logging Library/ !-- The current version number of this component -- - property name=component.version value=1.1-dev/ + property name=component.version value=1.0.2/ !-- The base directory for compilation targets -- property name=build.home value=target/ -- 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/http SessionTag.java Proxy.java OptionsTag.java HttpTagSupport.java BodyTag.java HeadTag.java ParameterTag.java GetTag.java DeleteTag.java HttpTagLibrary.java PutTag.java PostTag.java HeaderTag.java
dion2002/09/26 19:07:54
Modified:jelly/src/java/org/apache/commons/jelly/tags/http
GetTag.java DeleteTag.java HttpTagLibrary.java
PutTag.java PostTag.java HeaderTag.java
Added: jelly/src/java/org/apache/commons/jelly/tags/http
SessionTag.java Proxy.java OptionsTag.java
HttpTagSupport.java BodyTag.java HeadTag.java
ParameterTag.java
Log:
Move Latka HTTP Tag library over to Jelly
Revision ChangesPath
1.2 +30 -17
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/GetTag.java
Index: GetTag.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/GetTag.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- GetTag.java 24 Jun 2002 11:17:09 - 1.1
+++ GetTag.java 27 Sep 2002 02:07:54 - 1.2
@@ -7,7 +7,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 1999-2002 The Apache Software Foundation. All rights
+ * Copyright (c) 1999-2001 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -56,29 +56,42 @@
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
- *
- * $Id$
+ *
*/
+
package org.apache.commons.jelly.tags.http;
import java.net.MalformedURLException;
-import org.apache.commons.httpclient.HttpException;
-import org.apache.commons.httpclient.HttpMethod;
+import org.apache.commons.httpclient.HttpUrlMethod;
import org.apache.commons.httpclient.methods.UrlGetMethod;
-/**
- * Performs a HTTP GET request fron a given URL.
+/**
+ * A http get tag
*
- * @author a href=mailto:[EMAIL PROTECTED];James Strachan/a
- * @version $Revision$
+ * @author dion
+ * @version $Id$
*/
-public class GetTag extends MethodSupportTag {
-
+public class GetTag extends HttpTagSupport {
+
+/** the get method */
+private UrlGetMethod _getMethod;
+
+/**
+ * Creates a new instance of GetTag
+ */
+public GetTag() {
+}
+
/**
- * @return the HTTP method to invoke
+ * @return a url method for a get request
+ * @throws MalformedURLException when the url is bad
*/
-public HttpMethod getMethod() throws HttpException, MalformedURLException {
-return new UrlGetMethod(getUrl());
+protected HttpUrlMethod getHttpUrlMethod() throws MalformedURLException {
+if (_getMethod == null) {
+_getMethod = new UrlGetMethod(getResolvedUrl());
+}
+return _getMethod;
}
+
}
1.2 +30 -17
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/DeleteTag.java
Index: DeleteTag.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/DeleteTag.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- DeleteTag.java24 Jun 2002 11:17:09 - 1.1
+++ DeleteTag.java27 Sep 2002 02:07:54 - 1.2
@@ -7,7 +7,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 1999-2002 The Apache Software Foundation. All rights
+ * Copyright (c) 1999-2001 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -56,29 +56,42 @@
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
- *
- * $Id$
+ *
*/
+
package org.apache.commons.jelly.tags.http;
import java.net.MalformedURLException;
-import org.apache.commons.httpclient.HttpException;
-import org.apache.commons.httpclient.HttpMethod;
+import org.apache.commons.httpclient.HttpUrlMethod;
import org.apache.commons.httpclient.methods.UrlDeleteMethod;
-/**
- * Performs a HTTP POST request fron a given URL.
+/**
+ * A http delete tag
*
- * @author a href=mailto:[EMAIL PROTECTED];James Strachan/a
- * @version $Revision$
+ * @author dion
+ * @version $Id$
*/
-public class DeleteTag extends MethodSupportTag {
-
+public class DeleteTag extends HttpTagSupport {
+
+/** the delete method */
+private UrlDeleteMethod _deleteMethod;
+
+/**
+ * Creates a new instance of DeleteTag
+ */
+public DeleteTag() {
+}
+
/**
- * @return the
cvs commit: jakarta-commons-sandbox/jelly maven.xml project.xml
dion2002/09/26 19:12:31 Modified:jellymaven.xml project.xml Log: - Rearranged dependencies into alpha order on dep name - Added extra files to copy for postGoal on test:test Revision ChangesPath 1.35 +4 -0 jakarta-commons-sandbox/jelly/maven.xml Index: maven.xml === RCS file: /home/cvs/jakarta-commons-sandbox/jelly/maven.xml,v retrieving revision 1.34 retrieving revision 1.35 diff -u -r1.34 -r1.35 --- maven.xml 26 Sep 2002 18:07:37 - 1.34 +++ maven.xml 27 Sep 2002 02:12:31 - 1.35 @@ -24,6 +24,10 @@ fileset dir=src/test include name=**/*.properties/ include name=META-INF/services/*/ +include name=**/*.jelly/ +include name=**/*.xml/ +include name=**/*.dtd/ +include name=**/*.rng/ /fileset /copy /preGoal 1.74 +84 -86jakarta-commons-sandbox/jelly/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/jelly/project.xml,v retrieving revision 1.73 retrieving revision 1.74 diff -u -r1.73 -r1.74 --- project.xml 25 Sep 2002 18:36:59 - 1.73 +++ project.xml 27 Sep 2002 02:12:31 - 1.74 @@ -154,44 +154,33 @@ dependencies dependency - idjunit/id - version3.7/version -/dependency - -!-- for doclets -- -dependency - idjavadoc/id - version1.3/version -/dependency - -dependency - idjaxp/id - version1.2/version + idant/id + version1.5/version /dependency dependency - idxml-apis/id - version2.0.2/version + idant+optional/id + version1.5/version /dependency - + dependency - idxerces/id - version2.0.2/version + idcommons-beanutils/id + version1.4-dev/version /dependency - + dependency - idxalan/id - version2.3.1/version + idcommons-collections/id + version2.0/version /dependency - + dependency - idant/id - version1.5/version + idcommons-digester/id + versionSNAPSHOT/version /dependency - + dependency - idant+optional/id - version1.5/version + idcommons-discovery/id + versionSNAPSHOT/version /dependency dependency @@ -200,40 +189,49 @@ /dependency dependency + idcommons-jexl/id + version1.0-beta-1/version +/dependency + +dependency idcommons-logging/id version1.0/version /dependency dependency - idcommons-beanutils/id - version1.4-dev/version + iddom4j/id + version1.4-dev-7/version /dependency + !-- for the jelly startup scripts -- dependency - idcommons-collections/id - version2.0/version + idforehead/id + version1.0-beta-2/version + urlhttp://forehead.sf.net//url /dependency - + +!-- for doclets -- dependency - idcommons-digester/id - versionSNAPSHOT/version + idjavadoc/id + version1.3/version /dependency dependency - idcommons-discovery/id - versionSNAPSHOT/version + idjaxp/id + version1.2/version /dependency +!-- used by SQL library -- dependency - iddom4j/id - version1.4-dev-7/version + idjdbc/id + version2.0/version /dependency dependency - idcommons-jexl/id - version1.0-beta-1/version + idjunit/id + version3.7/version /dependency - + dependency idservletapi/id version2.3/version @@ -246,23 +244,25 @@ /dependency -- - !-- used by SQL library -- -dependency - idjdbc/id - version2.0/version -/dependency - - !-- used by werkz library -- +!-- used by werkz library -- dependency idwerkz/id version1.0-beta-2/version /dependency - !-- for the jelly startup scripts -- dependency - idforehead/id - version1.0-beta-2/version - urlhttp://forehead.sf.net//url + idxalan/id + version2.3.1/version +/dependency + +dependency + idxerces/id + version2.0.2/version +/dependency + +dependency + idxml-apis/id + version2.0.2/version /dependency !-- @@ -289,52 +289,63 @@ version2.2/version /dependency - !-- html taglib -- + !-- betwixt taglib -- dependency - idnekohtml/id -
cvs commit: jakarta-commons/logging/src/java/org/apache/commons/logging/impl LogFactoryImpl.java
rsitze 2002/09/26 19:14:57
Modified:logging/src/java/org/apache/commons/logging/impl
LogFactoryImpl.java
Log:
javadoc cleanup
Revision ChangesPath
1.15 +22 -17
jakarta-commons/logging/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
Index: LogFactoryImpl.java
===
RCS file:
/home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- LogFactoryImpl.java 30 Aug 2002 03:23:34 - 1.14
+++ LogFactoryImpl.java 27 Sep 2002 02:14:57 - 1.15
@@ -146,7 +146,7 @@
/**
* The deprecated system property used for backwards compatibility with
- * the old {@link LogSource} class.
+ * the old {@link org.apache.commons.logging.LogSource} class.
*/
protected static final String LOG_PROPERTY_OLD =
org.apache.commons.logging.log;
@@ -156,22 +156,24 @@
/**
- * The configuration attributes for this {@link LogFactory}.
+ * Configuration attributes
*/
protected Hashtable attributes = new Hashtable();
/**
- * The {@link Log} instances that have already been created, keyed by
- * logger name.
+ * The {@link org.apache.commons.logging.Log} instances that have
+ * already been created, keyed by logger name.
*/
protected Hashtable instances = new Hashtable();
/**
- * The one-argument constructor of the {@link Log} implementation class
- * that will be used to create new instances. This value is initialized
- * by codegetLogConstructor()/code, and then returned repeatedly.
+ * The one-argument constructor of the
+ * {@link org.apache.commons.logging.Log}
+ * implementation class that will be used to create new instances.
+ * This value is initialized by codegetLogConstructor()/code,
+ * and then returned repeatedly.
*/
protected Constructor logConstructor = null;
@@ -187,7 +189,7 @@
/**
* The one-argument codesetLogFactory/code method of the selected
- * {@link Log} method, if it exists.
+ * {@link org.apache.commons.logging.Log} method, if it exists.
*/
protected Method logMethod = null;
@@ -293,7 +295,8 @@
/**
- * Release any internal references to previously created {@link Log}
+ * Release any internal references to previously created
+ * {@link org.apache.commons.logging.Log}
* instances returned by this factory. This is useful environments
* like servlet containers, which implement application reloading by
* throwing away a ClassLoader. Dangling references to objects in that
@@ -349,7 +352,7 @@
/**
* pReturn the codeConstructor/code that can be called to instantiate
- * new {@link Log} instances./p
+ * new {@link org.apache.commons.logging.Log} instances./p
*
* pstrongIMPLEMENTATION NOTE/strong - Race conditions caused by
* calling this method from more than one thread are ignored, because
@@ -438,10 +441,11 @@
}
/**
- * p** MUST KEEP THIS METHOD PRIVATE **
+ * pMUST KEEP THIS METHOD PRIVATE
* /p
*
- * pThis method uses codeAccessController.doPrivileged()/code.
+ * pExposing this method establishes a security violation.
+ * This method uses codeAccessController.doPrivileged()/code.
* /p
*
* Load a class, try first the thread class loader, and
@@ -526,7 +530,8 @@
/**
- * Create and return a new {@link Log} instance for the specified name.
+ * Create and return a new {@link org.apache.commons.logging.Log}
+ * instance for the specified name.
*
* @param name Name of the new logger
*
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/logging/src/java/org/apache/commons/logging/impl LogFactoryImpl.java
rsitze 2002/09/26 19:16:44 Modified:logging/src/java/org/apache/commons/logging/impl LogFactoryImpl.java Log: javadoc cleanup Revision ChangesPath 1.16 +5 -6 jakarta-commons/logging/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java Index: LogFactoryImpl.java === RCS file: /home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- LogFactoryImpl.java 27 Sep 2002 02:14:57 - 1.15 +++ LogFactoryImpl.java 27 Sep 2002 02:16:44 - 1.16 @@ -441,8 +441,7 @@ } /** - * pMUST KEEP THIS METHOD PRIVATE - * /p + * MUST KEEP THIS METHOD PRIVATE * * pExposing this method establishes a security violation. * This method uses codeAccessController.doPrivileged()/code. -- 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/http - New directory
dion2002/09/26 19:18:06 jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/http - New directory -- 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/http http.jelly
dion2002/09/26 19:18:34
Added: jelly/src/test/org/apache/commons/jelly/http http.jelly
Log:
- Added sample file (later to be used in a test suite) showing the tags
Revision ChangesPath
1.1
jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/http/http.jelly
Index: http.jelly
===
?xml version=1.0?
j:jelly
xmlns:j=jelly:core
xmlns=jelly:org.apache.commons.jelly.tags.http.HttpTagLibrary
trim=false
!-- a session holds shared http state info
session --
session
Tests for Get tag
-
get var=mtc uri=http://www.multitask.com.au//
j:if test='${mtc.statusCode == 200}'
request ok
/j:if
Results for mtc url are:
http return code = ${mtc.statusCode}
http status text = '${mtc.statusText}'
size of result = ${mtc.responseBodyAsString.length()}
response time = ${mtc.responseTime}
j:forEach items=${mtc.responseHeaders} var=header indexVar=i
header[${i}] = ${header}
/j:forEach
!-- test parameters and headers --
get var=mtc2 uri=http://www.multitask.com.au/default.html;
parameter name=page value=mt @News/
parameter name=page2 value=junk/
header name=Content-Type value=text/plain/
/get
queryString = ${mtc2.queryString}, length =
${mtc2.responseBodyAsString.length()}
response time = ${mtc2.responseTime}
j:forEach items=${mtc2.requestHeaders} var=rHeader indexVar=i
reqHeader[${i}] = ${rHeader}
/j:forEach
!-- test a 404 --
get var=badurl uri=http://www.multitask.com.au/snafu.html/
http return code = ${badurl.statusCode}
bad response time = ${badurl.responseTime} in msec
Tests for Post tag
--
post var=jdc uri=http://developer.java.sun.com/servlet/SessionServlet;
parameter name=action value=login /
parameter name=url value=/developer/index.jshtml /
parameter name=UserId value= /
parameter name=Password value= /
/post
jdc login result = ${jdc.statusCode}
good login = ${jdc.responseBodyAsString.indexOf(Sorry!) == -1}
jdc response time = ${jdc.responseTime} in msec
j:forEach items=${jdc.responseHeaders} var=header indexVar=i
jdc.header[${i}] = ${header}
/j:forEach
Tests for Head tag
--
head var=jakarta uri=http://jakarta.apache.org//
j:forEach items=${jakarta.responseHeaders} var=header indexVar=i
header[${i}] = ${header}
/j:forEach
Tests for Options tag
-
options var=ms uri=http://www.microsoft.com//
j:forEach items=${ms.responseHeaders} var=header indexVar=i
header[${i}] = ${header}
/j:forEach
Tests for Body tag
--
j:set var=googleKey value= /
post var=google uri=http://api.google.com/search/beta2;
header name=Content-Type value=text/xml/
body
env:Envelope
xmlns:env=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:xsi=http://www.w3.org/1999/XMLSchema-instance;
xmlns:xsd=http://www.w3.org/1999/XMLSchema;
env:Body
ns1:doGoogleSearch xmlns:ns1=urn:GoogleSearch
env:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
ns1:key xsi:type=xsd:string${googleKey}/ns1:key
ns1:q xsi:type=xsd:stringjelly java xml/ns1:q
ns1:start xsi:type=xsd:int0/ns1:start
ns1:maxResults xsi:type=xsd:int10/ns1:maxResults
ns1:filter xsi:type=xsd:booleantrue/ns1:filter
ns1:restrict xsi:type=xsd:string/ns1:restrict
ns1:safeSearch xsi:type=xsd:booleanfalse/ns1:safeSearch
ns1:lr xsi:type=xsd:string/ns1:lr
ns1:ie xsi:type=xsd:stringlatin1/ns1:ie
ns1:oe xsi:type=xsd:stringlatin1/ns1:oe
/ns1:doGoogleSearch
/env:Body
/env:Envelope
/body
/post
j:forEach items=${google.requestHeaders} var=rHeader indexVar=i
reqHeader[${i}] = ${rHeader}
/j:forEach
google response = ${google.statusCode}, ${google.statusText}
${google.responseBodyAsString}
/session
session
Tests for Cookie tag
cvs commit: jakarta-commons/xdocs logging.xml components.xml
rsitze 2002/09/26 19:59:38 Modified:xdocslogging.xml components.xml Log: commons logging 1.0.2 release Revision ChangesPath 1.4 +2 -1 jakarta-commons/xdocs/logging.xml Index: logging.xml === RCS file: /home/cvs/jakarta-commons/xdocs/logging.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- logging.xml 13 Aug 2002 02:08:32 - 1.3 +++ logging.xml 27 Sep 2002 02:59:38 - 1.4 @@ -43,8 +43,9 @@ section name=Releases ul -lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1.0/;Version 1.0/a/li +lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1.0.2/;Version 1.0.2/a/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1.0.1/;Version 1.0.1/a/li +lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1.0/;Version 1.0/a/li /ul /section 1.51 +1 -0 jakarta-commons/xdocs/components.xml Index: components.xml === RCS file: /home/cvs/jakarta-commons/xdocs/components.xml,v retrieving revision 1.50 retrieving revision 1.51 diff -u -r1.50 -r1.51 --- components.xml26 Sep 2002 16:08:39 - 1.50 +++ components.xml27 Sep 2002 02:59:38 - 1.51 @@ -129,6 +129,7 @@ br/ Releases: ul + lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1.0.1/;Release 1.0.2/a - 27 Sep 2002/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1.0.1/;Release 1.0.1/a - 12 Aug 2002/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1.0/;Release 1.0/a - 20 Feb 2002/li /ul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/xdocs components.xml
sanders 2002/09/26 20:33:45 Modified:xdocscomponents.xml Log: caught Richard's typo :) Revision ChangesPath 1.52 +1 -1 jakarta-commons/xdocs/components.xml Index: components.xml === RCS file: /home/cvs/jakarta-commons/xdocs/components.xml,v retrieving revision 1.51 retrieving revision 1.52 diff -u -r1.51 -r1.52 --- components.xml27 Sep 2002 02:59:38 - 1.51 +++ components.xml27 Sep 2002 03:33:44 - 1.52 @@ -129,7 +129,7 @@ br/ Releases: ul - lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1.0.1/;Release 1.0.2/a - 27 Sep 2002/li + lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1.0.2/;Release 1.0.2/a - 27 Sep 2002/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1.0.1/;Release 1.0.1/a - 12 Aug 2002/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1.0/;Release 1.0/a - 20 Feb 2002/li /ul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [beanutils] Question about BeanComparator
On Thursday 26 September 2002 05:59 pm, Ola Berg wrote: Eric Pugh writes: What I am wondering though is that being able to compare booleans is pretty basic. However, I was also thinking that I would create SafeComparator that would be smart enough to make nulls into blank strings, booleans into 1 and 0 etc...? I see \safing\ these values as very problematic. Letting null having the same ordering impact as \\ could be regarded as intuitive, both indicating something like \value==nothing\ for ordering purposes (as opposed to identity purposes). No, that's probably a bad idea. Saying == null is likely to get you into trouble. You can't separate ordering from equals. compare == 0 is, by definition, an equality class. It might not be the same as equals(), but if it isn't you do need to be very careful. But adding +1 to false doesn\'t make it true (except in some dialects of assembler that is). And how would you compare null with fx. Integer? As in: bean a: Integer i = null; bean b: Integer i = new Integer(0); Or how no you compare null with negative infinity? Same way you compare a value with neg or pos infinity. You special case it. Null would have to be either greater or less than all other values, including Inf and NaN. Or define what ever you want, as long as it's outside of MAX and MIN. Take a look at [lang]'s CompareToBuilder, which has some reverse engineered code to deal with a total ordering of doubles and floats. It does not handle null, though. Can _any_ strategy in the SafeComparator be regarded _right_ here (ie is it possible to \safe\ the troublesome values in a meaningful way)? /O It's possible, the question is will it get you into trouble or not. What you do have to guarantee is the three requirements for comparison: sgn(x.compareTo(y)) == -sgn(y.compareTo(x)) (x.compareTo(y)0 y.compareTo(z)0) implies x.compareTo(z)0 x.compareTo(y)==0 implies that sgn(x.compareTo(z)) == sgn(y.compareTo(z)), for all z One important implication is that you can not meaningfully compare a subclass to a superclass. It will eventually cause a problem. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [beanutils] Question about BeanComparator
On Thu, 26 Sep 2002 [EMAIL PROTECTED] wrote: Where is ObjectComparator in terms of work? Should I use it, or just go with my own somewhat nasty SafeComparator filled with hardcoded assumptions? http://www.generationjava.com/maven/genjava/genjava-core/xref/com/generationjava/compare/ObjectComparator.html ClassRegistry has since spawned ClassMap as I've decided my Registry structure isn't worth enough over just using a Map. Will submit ClassMap to Collections as soon as I can find the time to pull that and a couple of other collection pieces together. One obvious improvement to me is to allow the instance to also have a map, so you can register static and instance comparators. Hen -- 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/26 22:53:37
Modified:lang/src/java/org/apache/commons/lang StringUtils.java
Log:
Added a patch with many improvements to the javadoc from Steve Downey.
Submitted by: Steve Downey
Revision ChangesPath
1.14 +47 -14
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.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- StringUtils.java 25 Sep 2002 03:30:19 - 1.13
+++ StringUtils.java 27 Sep 2002 05:53:37 - 1.14
@@ -95,8 +95,8 @@
//--
/**
- * Removes white space from both ends of this string, handling null
- * by returning an empty string.
+ * Removes control characters, including whitespace, from both ends of this
+ * string, handling null by returning an empty string.
*
* @see java.lang.String#trim()
* @param str the string to check
@@ -107,8 +107,8 @@
}
/**
- * Removes white space from both ends of this string, handling null
- * by returning null.
+ * Removes control characters, including whitespace, from both ends of this
+ * string, handling null by returning null.
*
* @see java.lang.String#trim()
* @param str the string to check
@@ -120,9 +120,11 @@
/**
* Deletes all whitespace from a String.
+ * Whitespace is defined as {' ', '\t', '\r', '\n', '\b'}
*
* @param str String target to delete whitespace from
* @return the text without whitespace
+ * @throws NullPointerException
*/
public static String deleteWhitespace(String str) {
return CharSetUtils.delete(str, \t\r\n\b);
@@ -156,6 +158,7 @@
* Nulls are handled without exceptions. Two codenull/code
* references are considered equal. Comparison is case sensitive.
*
+ * @see java.lang.String#equals(String)
* @param str1 the first string
* @param str2 the second string
* @return true if the Strings are equal, case sensitive, or both null
@@ -168,7 +171,7 @@
* Compares two Strings, returning true if they are equal ignoring case.
* Nulls are handled without exceptions. Two codenull/code
* references are considered equal. Comparison is case insensitive.
- *
+ * @see java.lang.String#equalsIgnoreCase(String)
* @param str1 the first string
* @param str2 the second string
* @return true if the Strings are equal, case insensitive, or both null
@@ -184,6 +187,7 @@
* @param str the string to check
* @param searchStrs the strings to search for
* @return the earliest index of any of the strings
+ * @throws NullPointerException if any of searchStrs[i] is null
*/
public static int indexOfAny(String str, String[] searchStrs) {
if ((str == null) || (searchStrs == null)) {
@@ -216,6 +220,7 @@
* @param str the string to check
* @param searchStrs the strings to search for
* @return the last index of any of the strings
+ * @throws NullPointerException if any of searchStrs[i] is null
*/
public static int lastIndexOfAny(String str, String[] searchStrs) {
if ((str == null) || (searchStrs == null)) {
@@ -569,6 +574,7 @@
* @param max maximum number of values to replace, or
* code-1/code if no maximum
* @return the text with any replacements processed
+ * @throws NullPointerException if repl is null
*/
public static String replace(String text, String repl, String with,
int max) {
@@ -598,6 +604,7 @@
* @param start int to start overlaying at
* @param end int to stop overlaying before
* @return String with overlayed text
+ * @throws NullPointerException if text or overlay is null
*/
public static String overlayString(String text, String overlay, int start, int
end) {
return new StringBuffer(start + overlay.length() + text.length() - end + 1)
@@ -612,11 +619,13 @@
/**
* Center a string in a larger string of size n.
- * Uses spaces as the value to buffer the string with..
+ * Uses spaces as the value to buffer the string with.
+ * Equivalent to codecenter(str, size, )/code
*
* @param str String to center
* @param size int size of new String
* @return String containing centered String
+ * @throws NullPointerException if str is null
*/
public static String center(String str, int size) {
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang StringUtils.java
bayard 2002/09/26 23:08:17
Modified:lang/src/test/org/apache/commons/lang
StringUtilsTrimEmptyTest.java
lang/src/java/org/apache/commons/lang StringUtils.java
Log:
Changed the deleteWhitespace method to delete according to Character.isWhitespce
Renamed the existing deleteWhitespace functionality to deleteSpaces.
This is in accordance with Character.isSpace.
Submitted by: Steve Downey's idea
Revision ChangesPath
1.5 +17 -4
jakarta-commons/lang/src/test/org/apache/commons/lang/StringUtilsTrimEmptyTest.java
Index: StringUtilsTrimEmptyTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/StringUtilsTrimEmptyTest.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- StringUtilsTrimEmptyTest.java 21 Jul 2002 20:19:50 - 1.4
+++ StringUtilsTrimEmptyTest.java 27 Sep 2002 06:08:16 - 1.5
@@ -122,13 +122,26 @@
assertEquals(true, StringUtils.isEmpty(null));
}
-public void testDeleteWhitespace() {
+public void testDeleteSpace() {
assertEquals(deleteWhitespace(String) failed,
, StringUtils.deleteWhitespace());
assertEquals(deleteWhitespace(String) failed,
- , StringUtils.deleteWhitespace(\t\t\n\n ));
+ , StringUtils.deleteWhitespace( \u000C \t\t\u001F\n\n
\u000B ));
+// Note: u-2007 and u-000A both cause problems in the source code
+// it should ignore 2007 but delete 000A
assertEquals(deleteWhitespace(String) failed,
- test, StringUtils.deleteWhitespace(t \t\ne\rs\n\n \tt));
+ \u00A0\u202F, StringUtils.deleteWhitespace( \u00A0
\t\t\n\n \u202F ));
+assertEquals(deleteWhitespace(String) failed,
+ \u00A0\u202F, StringUtils.deleteWhitespace(\u00A0\u202F));
+assertEquals(deleteWhitespace(String) failed,
+ test, StringUtils.deleteWhitespace(\u000Bt
\t\n\u0009e\rs\n\n \tt));
+
+assertEquals(deleteSpaces(String) failed,
+ , StringUtils.deleteSpaces());
+assertEquals(deleteSpaces(String) failed,
+ , StringUtils.deleteSpaces(\t\t\n\n ));
+assertEquals(deleteSpaces(String) failed,
+ test, StringUtils.deleteSpaces(t \t\ne\rs\n\n \tt));
}
public void testStrip() {
1.15 +23 -3
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.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- StringUtils.java 27 Sep 2002 05:53:37 - 1.14
+++ StringUtils.java 27 Sep 2002 06:08:16 - 1.15
@@ -119,15 +119,35 @@
}
/**
+ * Deletes all 'space' characters from a String.
+ * Spaces are defined as {' ', '\t', '\r', '\n', '\b'}
+ * in line with the deprecated Character.isSpace
+ *
+ * @param str String target to delete spaces from
+ * @return the text without spaces
+ * @throws NullPointerException
+ */
+public static String deleteSpaces(String str) {
+return CharSetUtils.delete(str, \t\r\n\b);
+}
+
+/**
* Deletes all whitespace from a String.
- * Whitespace is defined as {' ', '\t', '\r', '\n', '\b'}
+ * Whitespace is defined by Character.isWhitespace
*
* @param str String target to delete whitespace from
* @return the text without whitespace
* @throws NullPointerException
*/
public static String deleteWhitespace(String str) {
-return CharSetUtils.delete(str, \t\r\n\b);
+StringBuffer buffer = new StringBuffer();
+int sz = str.length();
+for (int i=0; isz; i++) {
+if(!Character.isWhitespace(str.charAt(i))) {
+buffer.append(str.charAt(i));
+}
+}
+return buffer.toString();
}
/**
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang]Bug in StringUtils.deleteWhitespace()
It's in, subject to Steve's approval. As is his javadoc patch. On 26 Sep 2002, Daniel Rall wrote: Let's get this change into the 1.0 final. Henri Yandell [EMAIL PROTECTED] writes: Agreed. Need to change this to not use CharSetUtils probably and just return when Character.is.. returns true. My feckup I think. Want me to do the fix? Or you want to? Hen On Thu, 26 Sep 2002, Steve Downey wrote: On Thursday 26 September 2002 12:50 pm, Steve Downey wrote: OOPS meant Character.isSpace() I think the definition should be changed to: (cut and paste from javadoc for String.isSpace()) '\t' '\u0009' HORIZONTAL TABULATION '\n' '\u000A' NEW LINE '\f' '\u000C' FORM FEED '\r' '\u000D' CARRIAGE RETURN ' ' '\u0020' SPACE -- 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]
