On 10 Oct 2002, John McNally wrote:
This class is badly named and I am not sure it belongs in collections.
The original use of this class was to join sql fragments together to
form a where clause or a list of columns, etc. So its class doc should
be something like:
This behavour is
oglueck 2002/10/11 00:37:46
Modified:httpclient/src/java/org/apache/commons/httpclient
Cookie.java
Log:
more date formats by Justin Bedard
Revision ChangesPath
1.23 +15 -22
From: Berin Loritsch [EMAIL PROTECTED]
Not sure about the name, but I like the concept. Maybe we can call it
Klass
(sounds the same)?
Any particular reason for not liking clazz??. Its not that important, I
guess klass would be fine. ;-)
Stephen
--
To unsubscribe, e-mail: mailto:[EMAIL
oglueck 2002/10/11 01:34:32
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpMethodBase.java
httpclient/src/test/org/apache/commons/httpclient
TestMethodsNoHost.java
Log:
Handling presence of both
oglueck 2002/10/11 06:03:34
Modified:httpclient/src/test/org/apache/commons/httpclient
TestMethodsNoHost.java
Log:
added test for auto close connections
optimized imports
Revision ChangesPath
1.9 +33 -5
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=10151.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
oglueck 2002/10/11 05:59:07
Modified:httpclient/src/test/org/apache/commons/httpclient
SimpleHttpConnection.java
Log:
fixed indentation
Revision ChangesPath
1.3 +32 -32
Ok,
if it is not some TM we can use one, I see no major difference
clazz/klass/klazz ... .
I wouldn't worry about either of these as they are not java related.
A google search for 'java clazz' revealed a java package for class
handling in an IDE - no conflict though, as the package was not
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=12841.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 11, 2002 12:40 AM
To: Jakarta Commons Developers List
Subject: Re: [clazz] New project? [was Re: [lang] Proposal for *NEXT*
version]
From: Berin Loritsch [EMAIL PROTECTED]
Not sure
rsitze 2002/10/11 09:04:18
Modified:discovery .cvsignore
Log:
Revision ChangesPath
1.2 +5 -0 jakarta-commons/discovery/.cvsignore
Index: .cvsignore
===
RCS file:
Has anyone thought of implementing Digester type functionality using the
DOM API?
--
Ceki
TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793
--
To unsubscribe, e-mail:
On Fri, 11 Oct 2002, Ceki Gülcü wrote:
Date: Fri, 11 Oct 2002 18:21:09 +0200
From: Ceki Gülcü [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: DOM-based Digester?
Has anyone thought of implementing Digester type functionality
It looks like this message should have gone to commons-dev.
--- Forwarded Message
From: [EMAIL PROTECTED]
Subject: FTP Client, release quality?
To: [EMAIL PROTECTED]
X-Mailer: Lotus Notes Release 5.0.6 December 14, 2000
Message-ID: [EMAIL PROTECTED]
Date: Fri, 11 Oct 2002 09:14:36 -0500
Craig,
One can (easily?) convert a DOM tree into a SAX event stream but
that's not what I had meant. I meant writing a new tool leveraging the DOM
api to perform rule based XML processing a la commons-digester.
Has anyone given that some thought?
At 09:27 11.10.2002 -0700, Craig R. McClanahan
At 12:21 am 12-10-2002, you wrote:
Has anyone thought of implementing Digester type functionality using the
DOM API?
Just curious: why does one need that?
--
John Yu
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
At 00:37 12.10.2002 +0800, John Yu wrote:
At 12:21 am 12-10-2002, you wrote:
Has anyone thought of implementing Digester type functionality using the
DOM API?
Just curious: why does one need that?
Because rule based processing is useful regardless of whether SAX or DOM is
being used. One
Hey all,
I finished a rough cut conversion of the Latka tags
and validators to Jelly. The Jelly tags have syntax
identical to the previous Latka tags. I think it will
be pretty easy to emulate Latka variables inside the
Jelly expression language (JEXL). With a patch I made
to Jelly this week,
Ah I should note this. The only incompatibility I see
with the new Jelly tags is wrt. existing custom
validators. Any XML handlers written for the old tags
would have to be reimplemented as Jelly tags. It's
not a difficult task (it takes less than a few minutes
in most cases), but it does
prickett2002/10/11 10:20:56
jakarta-commons-sandbox/periodicity/src/plugins-build/database/src - New directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
prickett2002/10/11 10:21:12
jakarta-commons-sandbox/periodicity/src/plugins-build/database/src/java - New
directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
ceki2002/10/11 10:21:23
Modified:joranspecification.html
Log:
more explanations on what joran is supposed to do.
Revision ChangesPath
1.2 +42 -16jakarta-commons-sandbox/joran/specification.html
Index: specification.html
prickett2002/10/11 10:21:31
jakarta-commons-sandbox/periodicity/src/plugins-build/database/src/java/org - New
directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
prickett2002/10/11 10:21:58
jakarta-commons-sandbox/periodicity/src/plugins-build/database/src/java/org/apache -
New directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
prickett2002/10/11 10:22:16
jakarta-commons-sandbox/periodicity/src/plugins-build/database/src/java/org/apache/commons
- New directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
prickett2002/10/11 10:23:15
jakarta-commons-sandbox/periodicity/src/plugins-build/database/src/java/org/apache/commons/periodicity/database
- New directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
prickett2002/10/11 10:23:31
jakarta-commons-sandbox/periodicity/src/plugins-build/database/src/java/org/apache/commons/periodicity/util
- New directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
prickett2002/10/11 10:37:21
Modified:periodicity/src/plugins-build/database project.xml
Added:
periodicity/src/plugins-build/database/src/java/org/apache/commons/periodicity/ant
GetDatabaseConnectionTask.java
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 11, 2002 9:47 AM
To: Jakarta Commons Developers List
Subject: Re: DOM-based Digester?
At 00:37 12.10.2002 +0800, John Yu wrote:
At 12:21 am 12-10-2002, you wrote:
Has anyone thought of
turner 2002/10/11 11:03:22
jakarta-commons/validator/conf - New directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
turner 2002/10/11 11:03:29
jakarta-commons/validator/conf/share - New directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
turner 2002/10/11 11:05:28
Added: validator/conf/share validator_1_0.dtd
Log:
Move the ruleset DTD from Struts to Commons, change version to 1.0, remove
struts-specfic comments from the DTD comments
Revision ChangesPath
1.1
morgand 2002/10/11 11:38:10
Modified:latka/src/java/org/apache/commons/latka
AbstractReporter.java Latka.java XMLReporter.java
latka/src/java/org/apache/commons/latka/jelly
JellyUtils.java SuiteTag.java
prickett2002/10/11 11:44:59
Modified:periodicity project.properties
periodicity/conf/build build.properties
periodicity/src/plugins-build/database plugin.jelly
project.xml
Removed: periodicity/src/plugins-build/database
jericho 2002/10/11 12:03:30
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpException.java
Log:
- The recommendation use for bug #8140 may be a negetive integer.
Please refer to this, TIA, [EMAIL PROTECTED]
Revision ChangesPath
prickett2002/10/11 12:43:26
Modified:periodicity/src/plugins-build/database project.xml
Log:
Added a dependency to the velocity-dvsl package so tat we could use
the xdoc plugin for maven.
Revision ChangesPath
1.5 +7 -0
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=13549.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
turner 2002/10/11 13:11:56
jakarta-commons/validator/src/example/org/apache/commons/validator/example - New
directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
turner 2002/10/11 13:17:50
Added: validator/src/example/org/apache/commons/validator/example
applicationResources.properties ValidateBean.java
ValidateExample.java validator-example.xml
Removed:
turner 2002/10/11 13:18:05
Modified:validator build.xml
Log:
Move the examples into their own package under validator (closes bug 13549)
Revision ChangesPath
1.10 +1 -1 jakarta-commons/validator/build.xml
Index: build.xml
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=13549.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I've been coding up the new reflection handling code (low level) for [lang].
And I've discovered that the Sun implementation (1.3.1) is screwed.
Consider:
Class A. Defines _public_ field named 'number' value 1
Class B. Subclass of A. Defines _private_ field named 'number' value 2
Interface I.
Martin (and others)
On a suggestion by Craig, I had a look at the commons resources
XMLMessageResources. It appears (and I could be wrong) that this
implementation expects a structure similar to this:
(I couldn't find any samples or test data, so I just guessing by browsing
the code)
messages
-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 11, 2002 2:29 PM
To: 'Struts Developers List'; Commons Developers List
Subject: RE: [Resources] XMLMessageResources and Proposal
-Original Message-
From: James Mitchell
Oh, one thing I forgot to mention.
Not sure if we overlooked it, but I was wondering how are you handling
special (XML/HTML) character data? Especially for Struts (errors.header and
errors.footer)
One peice of functionality that I am adding will (for the most part) take
care of that in a clean
45 matches
Mail list logo