[configuration][PATCH]HierarchicalConfiguration
Hi, I have now created a patch with my first implementation of HierarchicalConfiguration and related classes. Here are some remarks to the new classes: HierarchicalConfiguration This is a base class for configuration classes that use a hierarchical schema to store their properties. The class is fully functional and provides meaningful implementations for all abstract methods defined in AbstractConfiguration. HierarchicalDOM4JConfiguration A sub class of HierarchicalConfiguration that allows to parse XML documents using DOM4J. This class does the same as DOM4JConfiguration, but keeps the structure of the parsed documents. Saving of configuration properties is not implemented yet. HierarchicalConfigurationXMLReader This class is a faked SAX parser that operates on HierarchicalConfiguration objects. It processes a configuration object and generates corresponding SAX events that can be caught and evaluated by a ContentHandler implementation. The associated unit test shows how this class can be used to construct a DOM4J document from a configuration object. With this class it should also be possible to feed configuration objects into a Digester. ConfigurationKey This class is used internaly to construct keys and iterate over the single parts a key consists of. I made it public because it may be useful for clients as well. The class hides the concrete syntax of a property key, so instead of dealing with strings, property delimiters, index or attribute markers a client only needs to call methods of this class. There are unit tests for each of these classes; according to the reports they have a quite high coverage rate ;-) Please send me your critics, ideas and suggestions and your thoughts how (and if) to integrate this stuff with the existing code. I think the concept of transforming a Configuration object to XML by using a simplified SAX parser could be useful for non hierarchical configuration objects, too. So it would be nice to have a corresponding implementation. Then there is another idea that came me when I wrote HierarchicalDOM4JConfiguration: How about separating the code for writing configuration objects from the configuration classes? There could be different ConfigurationOutputter classes for different formats (properties, XML, ...). This would have a couple of advantages, e.g. it would allow to save configuration data in another format than it was loaded from. What do you mean? Oli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23940] New: - [Chain][PATCH] tabs to spaces, Log name fix
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=23940. 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=23940 [Chain][PATCH] tabs to spaces, Log name fix Summary: [Chain][PATCH] tabs to spaces, Log name fix Product: Commons Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Sandbox AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Patch attached. Just converted a bunch of tabs to spaces (4) and fixed one instance of incorrect Log name (result of copy/paste from another class). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23940] - [Chain][PATCH] tabs to spaces, Log name fix
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=23940. 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=23940 [Chain][PATCH] tabs to spaces, Log name fix --- Additional Comments From [EMAIL PROTECTED] 2003-10-20 14:24 --- Created an attachment (id=8629) Diff of the whole hierarchy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [Chain] [PATCH] tabs to spaces, log name fix
Of course they prefer that. This was easier. :) The patch is now in Bugzilla. Otis Get your own 800 number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag On Thu, 16 Oct 2003, Sgarlata Matt ([EMAIL PROTECTED]) wrote: Otis, I noticed none of the committers responded to this email. The Commiters of the Chain package prefer that you submit patches like this through BugZilla. You should put [Chain][PATCH] in the subject of the BugZilla ticket as you did here in the subject of the email. Add 'PatchAvailable' to the keywords (without the apostrophes). Make sure you mark the bug as an enhancement rather than as a defect. You can access BugZilla here: http://issues.apache.org/bugzilla/ If you don't have an account, it only takes a minute to set one up for yourself. Matt - Original Message - From: otisg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 16, 2003 5:33 AM Subject: [Chain] [PATCH] tabs to spaces, log name fix Patch attached. Just converted a bunch of tabs to spaces (4) and fixed one instance of incorrect Log name (result of copy/paste from another class). Otis Get your own 800 number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[digester] Feature addition to digester
Hi,
I'd like to add a feature to the digester, allowing property
replacement, similar to Ant. Basically, ${...} in an attribute value
would get replaced by a property value.
The following elements would be added:
* PropertySource interface, containing a String getProperty(String key)
method
* Digester.setPropertySources(PropertySource[] sources), which would:
- enable property replacement (this would be disable otherwise, for
100% compatibility)
- use the sources in the given order until one returns a non null
value; if all return null, no replacement occurs
The implementation is very simple, and the code is present in the Tomcat
sources.
This would allow nice dynamic integration capabilities for files a
container which XML files are parsed by the digester, and (more
generally) will allow cool Ant-like properties management.
I can commit a patch if the feature is considered useful (the Tomcat
community certainly did like it).
Comments ?
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Doing a rollback() in PoolableConnectionFactory.passivateObject
Hi, We are using BasicDataSource for managing db connections to Postgresql (v7.3). By default our connections have autoCommit set to false and we manage our transactions so that no connection is ever returned to the pool while transaction is active. In the Postgresql log we saw tons of messages: Oct 20 08:12:19 flatiron postgres[12177]: [27558] WARNING: ROLLBACK: no transaction in progress It appears that when a connection is returned to the pool and the autocommit is false, a rollback() is called on the connection. Is there a way to turn this behavior off? Wouldn't it be better to keep track of whether transaction is in progress on and rollback() then? Although the rollback is harmless it does create a performance issue - we have an extra database call each time a connection is put back in the pool. Any suggestions wil be greatly appreciated. ...richie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dbutils] Enhanced* classes
The Enhanced* classes don't really seem to be enhanced versions of their
standard counterparts. For example, EnhancedResultSet has this method:
public Long getLongObject(String column) throws SQLException {
return new Long(getLong(column));
}
How is that enhanced over the standard rs.getObject(col) which performs
automatic type conversions or new Long(rs.getLong(col)) ?
To use these enhanced methods you must cast to the specific implementation
class you're using which is a poor practice. It's been nearly a year
since they were first committed and haven't been updated since.
If no one is opposed, I'll remove these classes tommorrow.
David
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] Feature addition to digester
I could see how it could be useful. If you are willing to commit and
support it, and the code is backwards-compatible (should be), then I am
+1. Go for it.
Scott
On Monday, October 20, 2003, at 08:13 AM, Remy Maucherat wrote:
Hi,
I'd like to add a feature to the digester, allowing property
replacement, similar to Ant. Basically, ${...} in an attribute value
would get replaced by a property value.
The following elements would be added:
* PropertySource interface, containing a String getProperty(String
key) method
* Digester.setPropertySources(PropertySource[] sources), which would:
- enable property replacement (this would be disable otherwise, for
100% compatibility)
- use the sources in the given order until one returns a non null
value; if all return null, no replacement occurs
The implementation is very simple, and the code is present in the
Tomcat sources.
This would allow nice dynamic integration capabilities for files a
container which XML files are parsed by the digester, and (more
generally) will allow cool Ant-like properties management.
I can commit a patch if the feature is considered useful (the Tomcat
community certainly did like it).
Comments ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbutils] Enhanced* classes
David Graham wrote:
The Enhanced* classes don't really seem to be enhanced versions of their
standard counterparts. For example, EnhancedResultSet has this method:
public Long getLongObject(String column) throws SQLException {
return new Long(getLong(column));
}
What about:
public Long getLongObject(String column) throws SQLException {
long result = getLong(column);
if (wasNull()) {
return null;
} else {
return new Long(result);
}
}
How is that enhanced over the standard rs.getObject(col) which performs
automatic type conversions or new Long(rs.getLong(col)) ?
Maybe this method check agains null too?
Regards,
Tomek
David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][Pool] Release Commons-Pool v1.1
+0 David --- Dirk Verbeeck [EMAIL PROTECTED] wrote: This is a call for a vote to release version 1.1 of Commons Pool. After a three week review/test period, it's now time to make the final release. There are no unresolved issues, more info below. your votes, please: Release Commons-Pool 1.1 - [ ] +1 I support this release and will help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons: -- Official Site:http://jakarta.apache.org/commons/pool/ Release Canidate: http://jakarta.apache.org/commons/pool/downloads.html Changes: http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/pool/release_notes.txt?rev=HEADcontent-type=text/plain -- Dirk Verbeeck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][DBCP] Release Commons-DBCP v1.1
+1 David --- Dirk Verbeeck [EMAIL PROTECTED] wrote: This is a call for a vote to release version 1.1 of Commons DBCP. After a three week review/test period, it's now time to make the final release. There are no unresolved issues, more info below. your votes, please: Release Commons-DBCP 1.1 - [ ] +1 I support this release and will help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons: -- Official Site:http://jakarta.apache.org/commons/dbcp/ Release Canidate: http://jakarta.apache.org/commons/dbcp/downloads.html Changes: http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/dbcp/release_notes.txt?rev=HEADcontent-type=text/plain -- Dirk Verbeeck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][Pool] Release Commons-Pool v1.1
Dirk Verbeeck wrote: This is a call for a vote to release version 1.1 of Commons Pool. After a three week review/test period, it's now time to make the final release. There are no unresolved issues, more info below. your votes, please: Release Commons-Pool 1.1 - [ ] +1 I support this release and will help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons: +0 -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][DBCP] Release Commons-DBCP v1.1
Dirk Verbeeck wrote: This is a call for a vote to release version 1.1 of Commons DBCP. After a three week review/test period, it's now time to make the final release. There are no unresolved issues, more info below. your votes, please: Release Commons-DBCP 1.1 - [ ] +1 I support this release and will help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons: +1 -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][DBCP] Release Commons-DBCP v1.1
+0 -Original Message- From: Dirk Verbeeck [mailto:[EMAIL PROTECTED] Sent: Monday, October 20, 2003 11:28 To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: [VOTE][DBCP] Release Commons-DBCP v1.1 This is a call for a vote to release version 1.1 of Commons DBCP. After a three week review/test period, it's now time to make the final release. There are no unresolved issues, more info below. your votes, please: Release Commons-DBCP 1.1 - [ ] +1 I support this release and will help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons: -- Official Site:http://jakarta.apache.org/commons/dbcp/ Release Canidate: http://jakarta.apache.org/commons/dbcp/downloads.html Changes: http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta- commons/dbcp/release_notes.txt?rev=HEADcontent-type=text/plain -- Dirk Verbeeck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][Pool] Release Commons-Pool v1.1
+0 Gary -Original Message- From: Dirk Verbeeck [mailto:[EMAIL PROTECTED] Sent: Monday, October 20, 2003 11:27 To: Jakarta Commons Developers List Cc: [EMAIL PROTECTED] Subject: [VOTE][Pool] Release Commons-Pool v1.1 This is a call for a vote to release version 1.1 of Commons Pool. After a three week review/test period, it's now time to make the final release. There are no unresolved issues, more info below. your votes, please: Release Commons-Pool 1.1 - [ ] +1 I support this release and will help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons: -- Official Site:http://jakarta.apache.org/commons/pool/ Release Canidate: http://jakarta.apache.org/commons/pool/downloads.html Changes: http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta- commons/pool/release_notes.txt?rev=HEADcontent-type=text/plain -- Dirk Verbeeck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][DBCP] Release Commons-DBCP v1.1
Are you planning to include the changes made yesterday by John McNally? I believe that those were the first non-test changes since RC2 was cut. As a basic statement, the code going into a release (not the CVS) should be frozen. Considering the importance of getting this out with Tomcat 5, if the Tomcat folks are OK with the release, I'm fine, too. And no such issue with pool. I am going to cut a test build of James today (just watching it run on a server at the moment to make sure everything is healthy), and then update our next one to use the new Pool and DBCP code. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][Pool] Release Commons-Pool v1.1
The release itself is no problem, I'll only have to install some PGP software to sign the release. Remains the jakarta-site update and the commons site to list the new releases. I haven't done that before (I don't have karma for the main jakarta site yet, I think) I'll try the update locally and let you know if I need help. Thanks for asking, Dirk Shapira, Yoav wrote: Howdy, +1. Do you need any concrete help? It seems like the release is all ready to go... Yoav Shapira Millennium ChemInformatics - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][DBCP] Release Commons-DBCP v1.1
I'll tag build 1.1 final right now and wait 2-3 days for the result of the vote. I don't think the last commit from John demands for a new release candidate/review cycle. If there are no -1 votes (blocking issues in final build) then I'll announce v1.1 on wednesday evening. -- Dirk Noel J. Bergman wrote: Are you planning to include the changes made yesterday by John McNally? I believe that those were the first non-test changes since RC2 was cut. As a basic statement, the code going into a release (not the CVS) should be frozen. Considering the importance of getting this out with Tomcat 5, if the Tomcat folks are OK with the release, I'm fine, too. And no such issue with pool. I am going to cut a test build of James today (just watching it run on a server at the moment to make sure everything is healthy), and then update our next one to use the new Pool and DBCP code. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/pool/xdocs downloads.xml
dirkv 2003/10/20 12:48:37 Modified:pool/xdocs downloads.xml Log: prepare for 1.1 final Revision ChangesPath 1.8 +4 -1 jakarta-commons/pool/xdocs/downloads.xml Index: downloads.xml === RCS file: /home/cvs/jakarta-commons/pool/xdocs/downloads.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- downloads.xml 11 Oct 2003 18:02:05 - 1.7 +++ downloads.xml 20 Oct 2003 19:48:37 - 1.8 @@ -10,6 +10,7 @@ section name=Releases pThe following releases are available:/p ul + liRelease 1.1 - 20 October 2003/li liRelease 1.0.1 - 12 August 2002/li liRelease 1.0 - 4 May 2002/li /ul @@ -38,6 +39,7 @@ /p /section +!-- section name=Release Candidate p Release candidates for the upcoming 1.1 release can be downloaded @@ -51,6 +53,7 @@ Final release target is 20 October 2003. /p /section +-- /body /document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/pool project.xml
dirkv 2003/10/20 12:49:01 Modified:pool project.xml Log: prepare for 1.1 final Revision ChangesPath 1.17 +4 -9 jakarta-commons/pool/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/pool/project.xml,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- project.xml 13 Oct 2003 18:08:52 - 1.16 +++ project.xml 20 Oct 2003 19:49:00 - 1.17 @@ -9,7 +9,7 @@ shortDescriptionCommons Object Pooling Library/shortDescription descriptionCommons Object Pooling Library/description - currentVersion1.1-RC2/currentVersion + currentVersion1.1/currentVersion versions version id1.0/id @@ -22,14 +22,9 @@ tagPOOL_1_0_1/tag /version version - id1.1-RC1/id - name1.1-RC1/name - tagPOOL_1_1_RC1/tag -/version -version - id1.1-RC2/id - name1.1-RC2/name - tagPOOL_1_1_RC2/tag + id1.1/id + name1.1/name + tagPOOL_1_1/tag /version /versions branches - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/dbcp/xdocs downloads.xml
dirkv 2003/10/20 12:49:57 Modified:dbcp/xdocs downloads.xml Log: prepare for 1.1 final Revision ChangesPath 1.3 +5 -2 jakarta-commons/dbcp/xdocs/downloads.xml Index: downloads.xml === RCS file: /home/cvs/jakarta-commons/dbcp/xdocs/downloads.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- downloads.xml 11 Oct 2003 18:01:37 - 1.2 +++ downloads.xml 20 Oct 2003 19:49:56 - 1.3 @@ -10,7 +10,8 @@ section name=Releases pThe following releases are available:/p ul - liVersion 1.0 - 12 Aug 2002/li + liVersion 1.1 - 20 October 2003/li + liVersion 1.0 - 12 August 2002/li /ul br/ p @@ -37,6 +38,7 @@ /p /section +!-- section name=Release Candidate p Release candidates for the upcoming 1.1 release can be downloaded @@ -50,5 +52,6 @@ Final release target is 20 October 2003. /p /section +-- /body /document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/dbcp project.xml
dirkv 2003/10/20 12:50:25 Modified:dbcp project.xml Log: prepare for 1.1 final Revision ChangesPath 1.18 +5 -10 jakarta-commons/dbcp/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/dbcp/project.xml,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- project.xml 13 Oct 2003 18:09:14 - 1.17 +++ project.xml 20 Oct 2003 19:50:25 - 1.18 @@ -9,7 +9,7 @@ shortDescriptionCommons Database Connection Pooling/shortDescription descriptionCommons Database Connection Pooling/description - currentVersion1.1-RC2/currentVersion + currentVersion1.1/currentVersion versions version id1.0/id @@ -17,14 +17,9 @@ tagDBCP_1_0/tag /version version - id1.1-RC1/id - name1.1-RC1/name - tagDBCP_1_1_RC1/tag -/version -version - id1.1-RC2/id - name1.1-RC2/name - tagDBCP_1_1_RC2/tag + id1.1/id + name1.1/name + tagDBCP_1_1/tag /version /versions branches @@ -88,7 +83,7 @@ /dependency dependency idcommons-pool/id - version1.1-RC2/version + version1.1/version /dependency dependency idjdbc/id - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][DBCP] Release Commons-DBCP v1.1
I'll tag build 1.1 final right now and wait 2-3 days for the result of the vote. I'm in the process of uploading the new James test build, and will grab the new Commons jars as soon as you post that they are available. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] Feature addition to digester
On Tue, 2003-10-21 at 05:16, Craig R. McClanahan wrote:
Remy Maucherat wrote:
Hi,
I'd like to add a feature to the digester, allowing property
replacement, similar to Ant. Basically, ${...} in an attribute value
would get replaced by a property value.
And +1 from me.
Could you please make the character that marks the start of the
variable configurable? eg allow:
${foo} or #{foo} or var{foo}
This is because I use the sequence ${xxx} in attributes already in one
application.
And how about allowing variable evaluation in element bodies as well as
attributes?
I actually have implemented this functionality already for digester, but
not in a very nice way; I would certainly be interested in testing or
otherwise helping with this feature implementation.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to call a constructor with my own values (rather than the XML attributes or elements)
Hi Kumar, You can use the ObjectParamRule to pass literal strings (or other objects) to methods. There is also a PathCallParamRule class in CVS, but it was added since the last release so you would need to download it from CVS. Regards, Simon On Tue, 2003-10-21 at 03:03, Kumar Pankaj wrote: Hi Gurus, I have been totally stumped by this. I want to set a property in Java bean based on the pattern (it does not have any attributes) Following is my simple XML ?xml version=1.0 encoding=UTF-8? content Film KeywordTom Cruise/Keyword Headline TextTitleHiMission Impossible/TextTitleHi /Headline /Film Literature KeywordVikram Seth/Keyword Headline TextTitleHiPrinciples of Life/TextTitleHi /Headline /Literature /content For this, i want to create a single Java object named Content and set the propoerty called category to Film when it comes to Film pattern. Now, I have not been able to use either set-properties-rule or call-method-rule because none of them can pass the pattern name as parameters to the methods. Thanks in Advance, Pankaj - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][Pool] Release Commons-Pool v1.1
On Mon, 2003-10-20 at 11:27, Dirk Verbeeck wrote: This is a call for a vote to release version 1.1 of Commons Pool. After a three week review/test period, it's now time to make the final release. There are no unresolved issues, more info below. your votes, please: Release Commons-Pool 1.1 - [X] +1 I support this release and will help john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][DBCP] Release Commons-DBCP v1.1
On Mon, 2003-10-20 at 11:27, Dirk Verbeeck wrote: This is a call for a vote to release version 1.1 of Commons DBCP. After a three week review/test period, it's now time to make the final release. There are no unresolved issues, more info below. your votes, please: Release Commons-DBCP 1.1 - [X] +1 I support this release and will help john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[digester] why private XXXRule in DigesterRuleParser?
hello, why do classes like PatternRule have private access? now, for adding my own rules which may use surrounding pattern, i just copied the PatternRule source [very brown imho] why not make them protected or public? ricardo Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] why private XXXRule in DigesterRuleParser?
Hi Ricky, You must be referring to xmlrules/DigesterRuleParser.java I'm no expert on the xmlrules package. However it is normal practice for classes created solely for the purpose of implementing function X to be declared private. The PatternRule class appears to have been created *not* with the intention of providing additional services to users of Digester, but solely as an implementation detail of the xmlrules functionality. As such, private seems the appropriate scope to me. If you feel that the functionality of the PatternRule is useful outside of the xmlrules package, then consideration could be given to promoting the class to public. Note however that any class or method declared public (or protected) is part of the public interface to a package, and must: (a) be documented much more thoroughly than private/package classes (b) be backwards-compatible in future releases (c) be deprecated before removal So a class really should only be public if it needs to be. Regards, Simon On Tue, 2003-10-21 at 10:02, Ricky Panaglucci wrote: hello, why do classes like PatternRule have private access? now, for adding my own rules which may use surrounding pattern, i just copied the PatternRule source [very brown imho] why not make them protected or public? ricardo Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/validation Validator.java
jkeyes 2003/10/20 14:23:57
Modified:cli/src/java/org/apache/commons/cli2/validation
Validator.java
Log:
- added Apache License
- fixed author tag
- added javadoc
Revision ChangesPath
1.2 +80 -19
jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/validation/Validator.java
Index: Validator.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/validation/Validator.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Validator.java18 Oct 2003 22:00:17 - 1.1
+++ Validator.java20 Oct 2003 21:23:57 - 1.2
@@ -1,19 +1,80 @@
-/*
- * Created on 25-Aug-2003
- *
- * To change the template for this generated file go to
- * Window - Preferences - Java - Code Generation - Code and Comments
- */
-package org.apache.commons.cli2.validation;
-
-import java.util.List;
-
-/**
- * @author Rob
- *
- * To change the template for this generated type comment go to
- * Window - Preferences - Java - Code Generation - Code and Comments
- */
-public interface Validator {
- public void validate(final List values) throws InvalidArgumentException;
-}
+/*
+ * $Header$
+ * $Revision$
+ * $Date$
+ *
+ *
+ *
+ * The Apache Software License, Version 1.1
+ *
+ * Copyright (c) 2003 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 GroupImpl.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
+ * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+ * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
+ * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ *
+ * This software consists of voluntary contributions made by many
+ * individuals on behalf of the Apache Software Foundation. For more
+ * information on the Apache Software Foundation, please see
+ * http://www.apache.org/.
+ *
+ */
+package org.apache.commons.cli2.validation;
+
+import java.util.List;
+
+/**
+ * @author Rob Oxspring
+ */
+public interface Validator {
+
+/**
+ * Validate the specified values (List of Strings).
+ *
+ * @param values
+ * the values to validate
+ *
+ * @throws InvalidArgumentException
+ * if any of the specified values are not valid
+ */
+ void validate(final List values) throws InvalidArgumentException;
+}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] plugins module ready for evaluation
On Sunday, October 5, 2003, at 10:53 PM, Simon Kitching wrote: snip Hmm .. but calling Digester.setLogger probably doesn't override the object known to the LogFactory... What exactly is the purpose of being able to set the Log object used by a class or instance? so the instance used to log by digester can be set programmatically at runtime. this is a useful feature because: 1. it's a very convenient way to bypass the usual commons-logging configuration infrastructure. for example, it's often easier (when debugging) to setLogger programmatically on a particular instance than to reconfigure everything. 2. it allows digester to participate properly in frameworks based on inversion-of-control. (frameworks of this type are configured and controlled in a parent-child fashion. the Log to be used by a digester should be controlled by the component owning digester) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/validation StringValidator.java
jkeyes 2003/10/20 14:26:56
Added: cli/src/java/org/apache/commons/cli2/validation
StringValidator.java
Log:
- a validator for string values, when constructing the
validator pass in the list of permitted values
Revision ChangesPath
1.1
jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/validation/StringValidator.java
Index: StringValidator.java
===
/*
* $Header:
/home/cvs/jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/validation/StringValidator.java,v
1.1 2003/10/20 21:26:56 jkeyes Exp $
* $Revision: 1.1 $
* $Date: 2003/10/20 21:26:56 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 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 GroupImpl.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*/
package org.apache.commons.cli2.validation;
import java.util.Iterator;
import java.util.List;
import java.util.ListIterator;
/**
* A Validator for a list of known string values.
*
* @author John Keyes
*/
public class StringValidator implements Validator {
/** List of permitted values */
private List validValues;
/** Stringified version of values */
private String valuesStr;
/**
* Creates a new StringValidator for the specified values.
*
* @param values
* the list of permitted values
*/
public StringValidator(final List values) {
this.validValues = values;
}
/**
* Validate the list of values against the list
* of permitted values.
*
* @see org.apache.commons.cli2.validation.Validator#validate(java.util.List)
*/
public void validate(final List values) throws InvalidArgumentException {
for (final Iterator iter = values.iterator(); iter.hasNext();) {
final String value = (String) iter.next();
if (!this.validValues.contains(value)) {
throw new InvalidArgumentException(' + value + ' is not allowed.
Permitted values are:
+ getValuesAsString());
}
}
}
/**
* Returns the permitted values in a String
*
* @return String
* formatted list of values
cvs commit: jakarta-commons-sandbox/cli/src/test/org/apache/commons/cli2/apps - New directory
jkeyes 2003/10/20 14:28:08 jakarta-commons-sandbox/cli/src/test/org/apache/commons/cli2/apps - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/cli/src/test/org/apache/commons/cli2 ApplicationTest.java
jkeyes 2003/10/20 14:28:18 Modified:cli/src/test/org/apache/commons/cli2 ApplicationTest.java Added: cli/src/test/org/apache/commons/cli2/apps LsTest.java Log: - factored out ls test from ApplicationTest - WIP LsTest Revision ChangesPath 1.1 jakarta-commons-sandbox/cli/src/test/org/apache/commons/cli2/apps/LsTest.java Index: LsTest.java === /* * $Header: /home/cvs/jakarta-commons-sandbox/cli/src/test/org/apache/commons/cli2/apps/LsTest.java,v 1.1 2003/10/20 21:28:18 jkeyes Exp $ * $Revision: 1.1 $ * $Date: 2003/10/20 21:28:18 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 2003 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 GroupImpl. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. * */ package org.apache.commons.cli2.apps; import java.util.ArrayList; import java.util.List; import junit.framework.Test; import junit.framework.TestCase; import junit.framework.TestSuite; import org.apache.commons.cli2.ArgumentBuilder; import org.apache.commons.cli2.CommandLine; import org.apache.commons.cli2.CommandLineParser; import org.apache.commons.cli2.DefaultOptionBuilder; import org.apache.commons.cli2.Group; import org.apache.commons.cli2.GroupBuilder; import org.apache.commons.cli2.Option; import org.apache.commons.cli2.OptionException; import org.apache.commons.cli2.validation.StringValidator; /** * p * Test the codels/code command. Duplicated Option types * are not tested e.g. -a and -d are the same Option type. * /p * * p * The following is the man output for 'ls'. See http://www.rt.com/man/ls.1.html. * /p * * pre * LS(1) FSF LS(1) * * NAME * ls - list directory contents * * SYNOPSIS * ls [OPTION]... [FILE]... * * DESCRIPTION * List information about the FILEs (the current directory by * default). Sort entries alphabetically if none of -cftuSUX * nor --sort. * * -a, --all * do not hide entries starting with . * * -A, --almost-all * do not list implied . and .. * * -b, --escape * print octal escapes for nongraphic characters * * --block-size=SIZE *
Re: [digester] plugins module ready for evaluation
On Sunday, October 5, 2003, at 10:53 PM, Simon Kitching wrote: On Sun, 2003-10-05 at 00:43, robert burrell donkin wrote: snip 7. Logs at the moment, each plugin class uses it's own and the log cannot be set. i'm not in favour of this pattern for several reasons. most rules implementations use the digester log and i'd prefer to switch as many classes as possible to use the log and give the others setters and getters. I disagree with this one. I think having a different logger on each class is one of the most wonderful features of logging, giving much better control of output. Having all logging going via single Log object means that there is no control over what gets logged and what doesn't for different components of Digester. And Digester generates some serious log output when enabled! agreed. the drawback of this approach is that limits the contexts in which digester plug-ins can be used. some frameworks have good reasons to want to be able to control where the output of the log goes. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/validation UrlValidator.java FileValidator.java DateValidator.java NumberValidator.java InvalidArgumentException.java ClassValidator.java
jkeyes 2003/10/20 14:40:44
Modified:cli/src/java/org/apache/commons/cli2/validation
UrlValidator.java FileValidator.java
DateValidator.java NumberValidator.java
InvalidArgumentException.java ClassValidator.java
Log:
- added Apache license
- fixed author tag
Revision ChangesPath
1.2 +109 -58
jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/validation/UrlValidator.java
Index: UrlValidator.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/validation/UrlValidator.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- UrlValidator.java 18 Oct 2003 22:00:17 - 1.1
+++ UrlValidator.java 20 Oct 2003 21:40:44 - 1.2
@@ -1,58 +1,109 @@
-/*
- * Created on 25-Aug-2003
- *
- * To change the template for this generated file go to
- * Window - Preferences - Java - Code Generation - Code and Comments
- */
-package org.apache.commons.cli2.validation;
-
-import java.net.MalformedURLException;
-import java.net.URL;
-import java.util.List;
-import java.util.ListIterator;
-
-/**
- * @author Rob
- *
- * To change the template for this generated type comment go to
- * Window - Preferences - Java - Code Generation - Code and Comments
- */
-public class UrlValidator implements Validator {
-
- private String protocol = null;
-
- /* (non-Javadoc)
- * @see org.apache.commons.cli2.validation.Validator#validate(java.util.List)
- */
- public void validate(final List values) throws InvalidArgumentException {
- for (final ListIterator i = values.listIterator(); i.hasNext();) {
- final String name = (String) i.next();
- try {
- final URL url = new URL(name);
-
- if (protocol != null
!protocol.equals(url.getProtocol())) {
- throw new InvalidArgumentException(name);
- }
-
- i.set(url);
- } catch (final MalformedURLException mue) {
- throw new InvalidArgumentException(
- Cannot understand url: + name);
- }
- }
- }
-
- /**
- * @return
- */
- public String getProtocol() {
- return protocol;
- }
-
- /**
- * @param protocol
- */
- public void setProtocol(String protocol) {
- this.protocol = protocol;
- }
-}
+/*
+ * $Header$
+ * $Revision$
+ * $Date$
+ *
+ *
+ *
+ * The Apache Software License, Version 1.1
+ *
+ * Copyright (c) 2003 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 GroupImpl.
+ *
+ * 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
Re: [digester] why private XXXRule in DigesterRuleParser?
simon, nevermind, i don't remember what i did, but pattern value=child object-create-rule classname=xxx/ set-generic-properties-rule/ set-next-rule methodname=addChild/ /pattern now works with [d instanceof Digester] d.addFactoryCreate(*/set-generic-properties-rule, new SetGenericPropertiesRuleFactory()); // d.addRule(*/set-generic-properties-rule, new XPatternRule(pattern)); --- thought i need this d.addSetNext(*/set-generic-properties-rule, add, Rule.class.getName()); (XXGenericXX some Castor related stuff) i've been using Digester for 3 days now and haven't digged the push/pop stuff completely yet... your arguments regarding private use have been absorbed though thanks ricardo --- Simon Kitching [EMAIL PROTECTED] wrote: Hi Ricky, You must be referring to xmlrules/DigesterRuleParser.java I'm no expert on the xmlrules package. However it is normal practice for classes created solely for the purpose of implementing function X to be declared private. The PatternRule class appears to have been created *not* with the intention of providing additional services to users of Digester, but solely as an implementation detail of the xmlrules functionality. As such, private seems the appropriate scope to me. If you feel that the functionality of the PatternRule is useful outside of the xmlrules package, then consideration could be given to promoting the class to public. Note however that any class or method declared public (or protected) is part of the public interface to a package, and must: (a) be documented much more thoroughly than private/package classes (b) be backwards-compatible in future releases (c) be deprecated before removal So a class really should only be public if it needs to be. Regards, Simon On Tue, 2003-10-21 at 10:02, Ricky Panaglucci wrote: hello, why do classes like PatternRule have private access? now, for adding my own rules which may use surrounding pattern, i just copied the PatternRule source [very brown imho] why not make them protected or public? ricardo Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/validation UrlValidator.java FileValidator.java NumberValidator.java InvalidArgumentException.java
jkeyes 2003/10/20 14:46:13
Modified:cli/src/java/org/apache/commons/cli2/validation
UrlValidator.java FileValidator.java
NumberValidator.java InvalidArgumentException.java
Log:
- removed TABs
Revision ChangesPath
1.3 +38 -37
jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/validation/UrlValidator.java
Index: UrlValidator.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/validation/UrlValidator.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- UrlValidator.java 20 Oct 2003 21:40:44 - 1.2
+++ UrlValidator.java 20 Oct 2003 21:46:13 - 1.3
@@ -70,40 +70,41 @@
*/
public class UrlValidator implements Validator {
- private String protocol = null;
+private String protocol = null;
- /* (non-Javadoc)
- * @see org.apache.commons.cli2.validation.Validator#validate(java.util.List)
- */
- public void validate(final List values) throws InvalidArgumentException {
- for (final ListIterator i = values.listIterator(); i.hasNext();) {
- final String name = (String) i.next();
- try {
- final URL url = new URL(name);
+/* (non-Javadoc)
+ * @see org.apache.commons.cli2.validation.Validator#validate(java.util.List)
+ */
+public void validate(final List values) throws InvalidArgumentException {
+for (final ListIterator i = values.listIterator(); i.hasNext();) {
+final String name = (String) i.next();
+try {
+final URL url = new URL(name);
- if (protocol != null
!protocol.equals(url.getProtocol())) {
- throw new InvalidArgumentException(name);
- }
+if (protocol != null !protocol.equals(url.getProtocol())) {
+throw new InvalidArgumentException(name);
+}
- i.set(url);
- } catch (final MalformedURLException mue) {
- throw new InvalidArgumentException(
- Cannot understand url: + name);
- }
- }
- }
+i.set(url);
+}
+catch (final MalformedURLException mue) {
+throw new InvalidArgumentException(
+Cannot understand url: + name);
+}
+}
+}
- /**
- * @return
- */
- public String getProtocol() {
- return protocol;
- }
+/**
+ * @return
+ */
+public String getProtocol() {
+return protocol;
+}
- /**
- * @param protocol
- */
- public void setProtocol(String protocol) {
- this.protocol = protocol;
- }
+/**
+ * @param protocol
+ */
+public void setProtocol(String protocol) {
+this.protocol = protocol;
+}
}
1.3 +135 -134
jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/validation/FileValidator.java
Index: FileValidator.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/validation/FileValidator.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- FileValidator.java20 Oct 2003 21:40:44 - 1.2
+++ FileValidator.java20 Oct 2003 21:46:13 - 1.3
@@ -69,136 +69,137 @@
*/
public class FileValidator implements Validator {
- public static FileValidator getExistingInstance() {
- final FileValidator validator = new FileValidator();
- validator.setExisting(true);
- return validator;
- }
-
- public static FileValidator getExistingFileInstance() {
- final FileValidator validator = new FileValidator();
- validator.setExisting(true);
- validator.setFile(true);
- return validator;
- }
-
- public static FileValidator getExistingDirectoryInstance() {
- final FileValidator validator = new FileValidator();
- validator.setExisting(true);
- validator.setDirectory(true);
- return validator;
- }
-
- private boolean readable = false;
- private boolean writable = false;
- private boolean existing = false;
- private boolean directory = false;
- private boolean file = false;
- private boolean hidden = false;
-
- /*
Re: [VOTE][DBCP] Release Commons-DBCP v1.1
New jars are available from the usual place http://cvs.apache.org/~dirkv/builds/ PS: can you check if the signature commons-dbcp-1.1-src.tar.gz.asc is OK? -- Dirk Noel J. Bergman wrote: I'll tag build 1.1 final right now and wait 2-3 days for the result of the vote. I'm in the process of uploading the new James test build, and will grab the new Commons jars as soon as you post that they are available. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] plugins module ready for evaluation
On Tue, 2003-10-21 at 10:29, robert burrell donkin wrote: On Sunday, October 5, 2003, at 10:53 PM, Simon Kitching wrote: snip Hmm .. but calling Digester.setLogger probably doesn't override the object known to the LogFactory... What exactly is the purpose of being able to set the Log object used by a class or instance? so the instance used to log by digester can be set programmatically at runtime. this is a useful feature because: 1. it's a very convenient way to bypass the usual commons-logging configuration infrastructure. for example, it's often easier (when debugging) to setLogger programmatically on a particular instance than to reconfigure everything. Easier than changing the logging config file for the appropriate logging implementation (eg the log4j.properties or log4j.xml file)? 2. it allows digester to participate properly in frameworks based on inversion-of-control. (frameworks of this type are configured and controlled in a parent-child fashion. the Log to be used by a digester should be controlled by the component owning digester) This approach requires: (a) The framework to call setLog on each component used by the framework which has a dedicated Log object. Imagine a framework which uses Digester + Net + CLI, where each component works like Digester, requiring the user to call setLog on each one in turn. (b) Requiring classes to log via some object stored on some main object in the component, like all classes in the Digester project are required to get the Log object from their owning Digester object. In fact, in many projects this will not be feasable; it only works in Digester because every object of interest happens to have a reference to an owning Digester object. Isn't it much cleaner for the calling framework to set up an appropriate implementation of org.apache.commons.loggging.Logfactory that does whatever the framework wants with respect to logging? If the calling framework wants all logging (regardless of category) to go to one destination, then it creates a LogFactory implementation which returns a single Log object always, and that Log object's implementation writes to the desired destination. All those getLog and setLog calls go away. Objects don't need to have references to the master object which holds the Log object to use. Objects log via their own Category, so that filtering can be applied appropriately. Thoughts?? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] First steps
If everyone else is OK with releasing the 1.0 version under org.apache.commons.collections.primitives (rather than o.a..commons.primitives), that sounds OK to me. If we were to repackage along the type-of-collection lines, we'd likely be able to deprecate-and-move from o.a.c.primitives as well, but I guess this way gives us the freedom to choose the new packaging arbitrarily. On Sat, 18 Oct 2003, Stephen Colebourne wrote: The reason that this matters is that there are interfaces involved that we can't change later. So what might get changed? Well I don't see the need to remove anything from the current interfaces. I do believe that there are some methods that can be added. (separate email thread). Can we execute the 1.0 release before digging too deeply into changes to the existing structure? -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
An recurring problem(extracting one property out of an ArrayList containing a Bean)
Hi,
Is there a method in the BeanUtils package that allows you to extract one
property as a String[] out of an ArrayList containing a collection of Beans?
The only thing I found that was close to what I want is:
public static String[] getArrayProperty(Object bean, String
name)
throws IllegalAccessException, InvocationTargetException,
NoSuchMethodException {}
, but I need something that takes an ArrayList instead of a Bean Object
Any hints appreciated!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestCookie.java TestWebappCookie.java
olegk 2003/10/20 15:17:12
Modified:httpclient/src/examples CookieDemoApp.java
FormLoginDemo.java
httpclient/src/java/org/apache/commons/httpclient
Cookie.java HttpMethodBase.java HttpState.java
httpclient/src/java/org/apache/commons/httpclient/cookie
CookiePolicy.java
httpclient/src/java/org/apache/commons/httpclient/params
DefaultHttpParamsFactory.java HttpMethodParams.java
httpclient/src/test/org/apache/commons/httpclient
TestCookie.java TestWebappCookie.java
Log:
PR# 21151 (Customizable Cookie Policy)
The patch extends CookiePolicy class with a custom cookie specification plug-in
mechanism.
Contributed by Oleg Kalnichevski
Reviewed by Michael Becke
Revision ChangesPath
1.12 +12 -10jakarta-commons/httpclient/src/examples/CookieDemoApp.java
Index: CookieDemoApp.java
===
RCS file: /home/cvs/jakarta-commons/httpclient/src/examples/CookieDemoApp.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- CookieDemoApp.java3 Oct 2003 20:57:35 - 1.11
+++ CookieDemoApp.java20 Oct 2003 22:17:11 - 1.12
@@ -108,24 +108,26 @@
Cookie mycookie = new Cookie(.foobar.com, mycookie, stuff, /, null,
false);
// and then added to your HTTP state instance
initialState.addCookie(mycookie);
+
+// Get HTTP client instance
+HttpClient httpclient = new HttpClient();
+httpclient.getParams().setConnectionTimeout(3);
+httpclient.setState(initialState);
+
// RFC 2101 cookie management spec is used per default
// to parse, validate, format match cookies
-initialState.setCookiePolicy(CookiePolicy.RFC2109);
+httpclient.getParams().setCookiePolicy(CookiePolicy.RFC_2109);
// A different cookie management spec can be selected
// when desired
-// initialState.setCookiePolicy(CookiePolicy.NETSCAPE_DRAFT);
+//httpclient.getParams().setCookiePolicy(CookiePolicy.NETSCAPE);
// Netscape Cookie Draft spec is provided for completeness
// You would hardly want to use this spec in real life situations
-// initialState.setCookiePolicy(CookiePolicy.COMPATIBILITY);
+
//httppclient.getParams().setCookiePolicy(CookiePolicy.BROWSER_COMPATIBILITY);
// Compatibility policy is provided in order to mimic cookie
// management of popular web browsers that is in some areas
// not 100% standards compliant
-// Get HTTP client instance
-HttpClient httpclient = new HttpClient();
-httpclient.getParams().setConnectionTimeout(3);
-httpclient.setState(initialState);
// Get HTTP GET method
GetMethod httpget = new GetMethod(strURL);
// Execute HTTP GET
1.3 +1 -1 jakarta-commons/httpclient/src/examples/FormLoginDemo.java
Index: FormLoginDemo.java
===
RCS file: /home/cvs/jakarta-commons/httpclient/src/examples/FormLoginDemo.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- FormLoginDemo.java17 Jul 2003 21:57:42 - 1.2
+++ FormLoginDemo.java20 Oct 2003 22:17:11 - 1.3
@@ -84,7 +84,7 @@
HttpClient client = new HttpClient();
client.getHostConfiguration().setHost(LOGON_SITE, LOGON_PORT, http);
-client.getState().setCookiePolicy(CookiePolicy.COMPATIBILITY);
+client.getParams().setCookiePolicy(CookiePolicy.BROWSER_COMPATIBILITY);
// 'developer.java.sun.com' has cookie compliance problems
// Their session cookie's domain attribute is in violation of the RFC2109
// We have to resort to using compatibility cookie policy
1.40 +11 -6
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/Cookie.java
Index: Cookie.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/Cookie.java,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- Cookie.java 5 Jul 2003 22:31:20 - 1.39
+++ Cookie.java 20 Oct 2003 22:17:11 - 1.40
@@ -468,8 +468,13 @@
* @return a string suitable for sending in a Cookie header.
*/
public String toExternalForm() {
-return CookiePolicy.getSpecByVersion(
-getVersion()).formatCookie(this);
+CookieSpec spec = null;
+if (getVersion() 0) {
+spec =
cvs commit: jakarta-commons-sandbox/primitives/src/java/org/apache/commons/primitive/list/impl StringBufferCharList.java
scolebourne2003/10/20 15:19:40
Added: primitives/src/java/org/apache/commons/primitive/list/impl
StringBufferCharList.java
Log:
Specialised list implementatoin
Revision ChangesPath
1.1
jakarta-commons-sandbox/primitives/src/java/org/apache/commons/primitive/list/impl/StringBufferCharList.java
Index: StringBufferCharList.java
===
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 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 acknowledgement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgement may appear in the software itself,
*if and wherever such third-party acknowledgements 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 Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*/
package org.apache.commons.primitive.list.impl;
import org.apache.commons.primitive.list.CharList;
/**
* Unmodifiable CharList wrapped around a StringBuffer.
* p
* This class implements [EMAIL PROTECTED] java.util.List List} allowing
* seamless integration with other APIs.
*
* @author Stephen Colebourne
* @version $Id: StringBufferCharList.java,v 1.1 2003/10/20 22:19:40 scolebourne Exp
$
* @since 1.0
*/
public class StringBufferCharList extends AbstractCharList {
/** The String being wrapped */
protected final StringBuffer stringBuffer;
/**
* Decorates the specified string buffer with a StringBufferCharList.
* p
* The specified buffer is used as the datasource, so changes to one
* will affect the other.
*
* @param buf the string buffer to decorate, must not be null
* @throws IllegalArgumentException if the string is null
*/
public static StringBufferCharList decorate(StringBuffer buf) {
if (buf == null) {
throw new IllegalArgumentException(StringBuffer must not be null);
}
return new StringBufferCharList(buf);
}
//---
/**
* Constructor that uses an empty string as the datasource.
*/
public StringBufferCharList() {
super();
this.stringBuffer = new StringBuffer();
}
/**
* Constructor that copies the specified list.
*
* @param list the list to copy, must not be null
* @throws IllegalArgumentException if the list is null
*/
public StringBufferCharList(CharList list) {
Re: [digester] plugins module ready for evaluation
Simon Kitching wrote: On Tue, 2003-10-21 at 10:29, robert burrell donkin wrote: On Sunday, October 5, 2003, at 10:53 PM, Simon Kitching wrote: snip Hmm .. but calling Digester.setLogger probably doesn't override the object known to the LogFactory... What exactly is the purpose of being able to set the Log object used by a class or instance? so the instance used to log by digester can be set programmatically at runtime. this is a useful feature because: 1. it's a very convenient way to bypass the usual commons-logging configuration infrastructure. for example, it's often easier (when debugging) to setLogger programmatically on a particular instance than to reconfigure everything. Easier than changing the logging config file for the appropriate logging implementation (eg the log4j.properties or log4j.xml file)? No. Consider a use case like Tomcat, where Digester is used both by the container (to parse server.xml and web.xml files) and also by an application (say, Struts reading struts-config.xml). It's entirely reasonable to for someone to want the digester log output for the container's use of Digester to go to the container's logging hierarchy, and the webapp's use of Digester to log to a webapp hierarchy. 2. it allows digester to participate properly in frameworks based on inversion-of-control. (frameworks of this type are configured and controlled in a parent-child fashion. the Log to be used by a digester should be controlled by the component owning digester) This approach requires: (a) The framework to call setLog on each component used by the framework which has a dedicated Log object. *Allows* not *requires*. If you don't call setLog() you get the default names. Imagine a framework which uses Digester + Net + CLI, where each component works like Digester, requiring the user to call setLog on each one in turn. (b) Requiring classes to log via some object stored on some main object in the component, like all classes in the Digester project are required to get the Log object from their owning Digester object. In fact, in many projects this will not be feasable; it only works in Digester because every object of interest happens to have a reference to an owning Digester object. *Allows* not *requires*. If you don't call setLog() you get the default names. Isn't it much cleaner for the calling framework to set up an appropriate implementation of org.apache.commons.loggging.Logfactory that does whatever the framework wants with respect to logging? If the calling framework wants all logging (regardless of category) to go to one destination, then it creates a LogFactory implementation which returns a single Log object always, and that Log object's implementation writes to the desired destination. Can you show me how you'd solve the problem posed above about Tomcat? Especially in the case where you're running in a restricted environment where you are not allowed to modify the LogFactory in the container itself? All those getLog and setLog calls go away. Objects don't need to have references to the master object which holds the Log object to use. Objects log via their own Category, so that filtering can be applied appropriately. Thoughts?? Regards, Simon If you go back in the commons-dev message archives, you'll find that the reason setLog exists in the first place is because the Avalon folks (who know a little about IoC :-) said they needed it. You seem to be arguing the opposite position, which is kinda interesting. But, at the end of the day, I can't see why having an optional method to set the Log object a Digester instance can use causes you any grief if you never call it. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestCookie.java
olegk 2003/10/20 15:26:28
Modified:httpclient/src/java/org/apache/commons/httpclient/cookie
CookieSpecBase.java
httpclient/src/test/org/apache/commons/httpclient
TestCookie.java
Log:
PR# 23866 (Invalid cookie causing IllegalArgumentException)
Contributed by Oleg Kalnichevski
Reviewed by Michael Becke
Revision ChangesPath
1.19 +14 -10
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/cookie/CookieSpecBase.java
Index: CookieSpecBase.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/cookie/CookieSpecBase.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- CookieSpecBase.java 13 Jul 2003 21:29:05 - 1.18
+++ CookieSpecBase.java 20 Oct 2003 22:26:28 - 1.19
@@ -206,13 +206,17 @@
for (int i = 0; i headerElements.length; i++) {
HeaderElement headerelement = headerElements[i];
-Cookie cookie = new Cookie(host,
- headerelement.getName(),
- headerelement.getValue(),
- defaultPath,
- null,
- false);
-
+Cookie cookie = null;
+try {
+cookie = new Cookie(host,
+headerelement.getName(),
+headerelement.getValue(),
+defaultPath,
+null,
+false);
+} catch (IllegalArgumentException e) {
+throw new MalformedCookieException(e.getMessage());
+}
// cycle through the parameters
NameValuePair[] parameters = headerelement.getParameters();
// could be null. In case only a header element and no parameters.
1.25 +12 -10
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestCookie.java
Index: TestCookie.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestCookie.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- TestCookie.java 20 Oct 2003 22:17:12 - 1.24
+++ TestCookie.java 20 Oct 2003 22:26:28 - 1.25
@@ -787,10 +787,11 @@
public void testInvalidCookieName() {
try
{
-Cookie dummy = new Cookie(localhost, invalid name, cooke name may
not have blanks);
-fail(IllegalArgumentException must have been thrown);
+CookieSpec parser = new CookieSpecBase();
+parser.parse(localhost, 80, /, false, invalid name=);
+fail(MalformedCookieException must have been thrown);
}
-catch(IllegalArgumentException e)
+catch(MalformedCookieException e)
{
// Expected
}
@@ -803,10 +804,11 @@
public void testInvalidCookieName2() {
try
{
-Cookie dummy = new Cookie(localhost, $invalid_name, cooke name may
not start with $);
-fail(IllegalArgumentException must have been thrown);
+CookieSpec parser = new CookieSpecBase();
+parser.parse(localhost, 80, /, false, $invalid_name=);
+fail(MalformedCookieException must have been thrown);
}
-catch(IllegalArgumentException e)
+catch(MalformedCookieException e)
{
// Expected
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] First steps
I'm +1 to this, as it gets the release out quickly for users, and clears the way for [collections]. Discussion can wait a while. Stephen PS. There are 'how to do a release' notes on the commons website, although I don't fancy executing them for collections! - Original Message - From: Rodney Waldhoff [EMAIL PROTECTED] If everyone else is OK with releasing the 1.0 version under org.apache.commons.collections.primitives (rather than o.a..commons.primitives), that sounds OK to me. If we were to repackage along the type-of-collection lines, we'd likely be able to deprecate-and-move from o.a.c.primitives as well, but I guess this way gives us the freedom to choose the new packaging arbitrarily. On Sat, 18 Oct 2003, Stephen Colebourne wrote: The reason that this matters is that there are interfaces involved that we can't change later. So what might get changed? Well I don't see the need to remove anything from the current interfaces. I do believe that there are some methods that can be added. (separate email thread). Can we execute the 1.0 release before digging too deeply into changes to the existing structure? -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestCookie.java
olegk 2003/10/20 15:27:37
Modified:httpclient/src/java/org/apache/commons/httpclient/cookie
Tag: HTTPCLIENT_2_0_BRANCH CookieSpecBase.java
httpclient/src/test/org/apache/commons/httpclient Tag:
HTTPCLIENT_2_0_BRANCH TestCookie.java
Log:
PR# 23866 (Invalid cookie causing IllegalArgumentException)
Contributed by Oleg Kalnichevski
Reviewed by Michael Becke
Revision ChangesPath
No revision
No revision
1.16.2.1 +14 -10
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/cookie/CookieSpecBase.java
Index: CookieSpecBase.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/cookie/CookieSpecBase.java,v
retrieving revision 1.16
retrieving revision 1.16.2.1
diff -u -r1.16 -r1.16.2.1
--- CookieSpecBase.java 12 Jun 2003 19:12:16 - 1.16
+++ CookieSpecBase.java 20 Oct 2003 22:27:37 - 1.16.2.1
@@ -189,13 +189,17 @@
for (int i = 0; i headerElements.length; i++) {
HeaderElement headerelement = headerElements[i];
-Cookie cookie = new Cookie(host,
- headerelement.getName(),
- headerelement.getValue(),
- defaultPath,
- null,
- false);
-
+Cookie cookie = null;
+try {
+cookie = new Cookie(host,
+headerelement.getName(),
+headerelement.getValue(),
+defaultPath,
+null,
+false);
+} catch (IllegalArgumentException e) {
+throw new MalformedCookieException(e.getMessage());
+}
// cycle through the parameters
NameValuePair[] parameters = headerelement.getParameters();
// could be null. In case only a header element and no parameters.
No revision
No revision
1.22.2.1 +12 -10
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestCookie.java
Index: TestCookie.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestCookie.java,v
retrieving revision 1.22
retrieving revision 1.22.2.1
diff -u -r1.22 -r1.22.2.1
--- TestCookie.java 12 Jun 2003 19:12:16 - 1.22
+++ TestCookie.java 20 Oct 2003 22:27:37 - 1.22.2.1
@@ -786,10 +786,11 @@
public void testInvalidCookieName() {
try
{
-Cookie dummy = new Cookie(localhost, invalid name, cooke name may
not have blanks);
-fail(IllegalArgumentException must have been thrown);
+CookieSpec parser = new CookieSpecBase();
+parser.parse(localhost, 80, /, false, invalid name=);
+fail(MalformedCookieException must have been thrown);
}
-catch(IllegalArgumentException e)
+catch(MalformedCookieException e)
{
// Expected
}
@@ -802,10 +803,11 @@
public void testInvalidCookieName2() {
try
{
-Cookie dummy = new Cookie(localhost, $invalid_name, cooke name may
not start with $);
-fail(IllegalArgumentException must have been thrown);
+CookieSpec parser = new CookieSpecBase();
+parser.parse(localhost, 80, /, false, $invalid_name=);
+fail(MalformedCookieException must have been thrown);
}
-catch(IllegalArgumentException e)
+catch(MalformedCookieException e)
{
// Expected
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/primitives/src/java/org/apache/commons/primitive/list/impl StringBufferCharList.java
scolebourne2003/10/20 15:35:52 Modified:primitives/src/java/org/apache/commons/primitive/list/impl StringBufferCharList.java Log: Javadoc fix Revision ChangesPath 1.2 +2 -2 jakarta-commons-sandbox/primitives/src/java/org/apache/commons/primitive/list/impl/StringBufferCharList.java Index: StringBufferCharList.java === RCS file: /home/cvs/jakarta-commons-sandbox/primitives/src/java/org/apache/commons/primitive/list/impl/StringBufferCharList.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- StringBufferCharList.java 20 Oct 2003 22:19:40 - 1.1 +++ StringBufferCharList.java 20 Oct 2003 22:35:52 - 1.2 @@ -56,7 +56,7 @@ import org.apache.commons.primitive.list.CharList; /** - * Unmodifiable CharList wrapped around a StringBuffer. + * CharList implementation that uses a StringBuffer internally. * p * This class implements [EMAIL PROTECTED] java.util.List List} allowing * seamless integration with other APIs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] plugins module ready for evaluation
On Tue, 2003-10-21 at 11:26, Craig R. McClanahan wrote: Simon Kitching wrote: Regarding your tomcat example, I will have to have a think about this. I'm no expert on complex container architectures, nor on Tomcat, so if you and the Avalon team say the setLog() approach is the only way to go, I'll believe you. Nevertheless, the current approach *feels* wrong to me. I'm just trying to understand why it is necessary to do logging in this way. If you go back in the commons-dev message archives, you'll find that the reason setLog exists in the first place is because the Avalon folks (who know a little about IoC :-) said they needed it. You seem to be arguing the opposite position, which is kinda interesting. But, at the end of the day, I can't see why having an optional method to set the Log object a Digester instance can use causes you any grief if you never call it. The problem is not that the method exists on the Digester class. I'm looking at this from the point-of-view of a contributor to Digester, not a user (hence the dev list address). The problem is that in order to integrate with this solution, every class written for the Digester which needs to log output *must* do: digester.getLog().warn(oops) rather than Logger log = LogFactory.getLogger(ThisClass.class) .. log.warn(oops) The first implication is that with this pattern, *every* object which wants to log output *requires* a reference to whatever object is the holder of the master Log object (a Digester instance in this case). This looks like undesirable coupling to me; I find it difficult to believe that many other projects would be *able* to implement this pattern. For example, the commons-net project: does every object have a reference to some master object that can be used to hold a central Log object? Also see the xmlrules module. This creates new Digester objects to parse the xmlrules input files, but doesn't copy the set Log object. So currently xmlrules is broken with respect to Log behaviour: there is no way for the framework to control the Log object used by the Digester instances created by xmlrules. While this could be considered a bug in xmlrules, I think it shows a flaw in the concept of a centralised Log object attached to some master object; the log control doesn't automatically propagate, but instead requires explicit code. The second implication of the centralised Log object pattern is that there is a single Category for all output generated by all classes in the Digester project. This seems a shame. It may be acceptable for a project of Digester size (20-30 classes), but I presume that there is a limit beyond which this would not be acceptable. Does Tomcat use a single Category to output all of its logging? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections AbstractTestList.java
scolebourne2003/10/20 15:58:28
Modified:collections/src/test/org/apache/commons/collections
AbstractTestList.java
Log:
Handle testing data of size 1
Revision ChangesPath
1.3 +18 -7
jakarta-commons/collections/src/test/org/apache/commons/collections/AbstractTestList.java
Index: AbstractTestList.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/AbstractTestList.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- AbstractTestList.java 10 Oct 2003 21:19:39 - 1.2
+++ AbstractTestList.java 20 Oct 2003 22:58:28 - 1.3
@@ -365,12 +365,23 @@
verify();
list2 = Arrays.asList(getFullElements());
-Collections.reverse(list2);
-assertEquals(
-Full list shouldn't equal full list with same elements but different
order,
-false, list.equals(list2));
-verify();
+if (list2.size() 2 isAddSupported()) {
+// main list is only size 1, so lets add other elements to get a better
list
+list.addAll(Arrays.asList(getOtherElements()));
+confirmed.addAll(Arrays.asList(getOtherElements()));
+list2 = new ArrayList(list2);
+list2.addAll(Arrays.asList(getOtherElements()));
+}
+if (list2.size() 1) {
+Collections.reverse(list2);
+assertEquals(
+Full list shouldn't equal full list with same elements but
different order,
+false, list.equals(list2));
+verify();
+}
+resetFull();
+list = getList();
assertEquals(List shouldn't equal String, false, list.equals());
verify();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/dbutils/src/java/org/apache/commons/dbutils QueryRunner.java
dgraham 2003/10/20 17:12:58
Modified:dbutils/src/java/org/apache/commons/dbutils QueryRunner.java
Log:
Added javadoc and more versions of query() and update(). There are
now methods that take 0, 1, or an array of replacement parameters.
Revision ChangesPath
1.6 +203 -42
jakarta-commons-sandbox/dbutils/src/java/org/apache/commons/dbutils/QueryRunner.java
Index: QueryRunner.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/dbutils/src/java/org/apache/commons/dbutils/QueryRunner.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- QueryRunner.java 20 Oct 2003 02:10:21 - 1.5
+++ QueryRunner.java 21 Oct 2003 00:12:58 - 1.6
@@ -66,7 +66,9 @@
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Types;
+import java.util.ArrayList;
import java.util.Arrays;
+import java.util.List;
import javax.sql.DataSource;
@@ -97,18 +99,36 @@
}
/**
- * Constructor for QueryRunner.
- * @param ds The codeDataSource/code to retrieve connections
- * from.
+ * Constructor for QueryRunner. Methods that do not take a
+ * codeConnection/code parameter will retrieve connections from this
+ * codeDataSource/code.
+ *
+ * @param ds The codeDataSource/code to retrieve connections from.
*/
public QueryRunner(DataSource ds) {
super();
this.ds = ds;
}
-public boolean execute(
+/**
+ * Execute any SQL statement and return all the results in an
+ * codeObject[]/code. Callers are responsible for connection cleanup.
+ *
+ * @param conn The connection to execute the query with.
+ * @param sql The SQL statement.
+ * @param params SQL replacement parameters; codenull/code if no
+ * parameters are required.
+ * @param rsh The handler to generate result objects with
+ * @param rsmdh Handles the meta data.
+ * @param userObject Object to pass to the handler.
+ * @return An array filled with result objects from the handler for each
+ * codeResultSet/code returned by the query; codenull/code if the
+ * statment was an UPDATE.
+ * @throws SQLException
+ */
+public Object[] execute(
Connection conn,
-String query,
+String sql,
Object[] params,
ResultSetHandler rsh,
ResultSetMetaDataHandler rsmdh,
@@ -118,37 +138,40 @@
PreparedStatement stmt = null;
ResultSet rs = null;
+List results = new ArrayList();
+
try {
-stmt = conn.prepareStatement(query);
-fillStatement(stmt, params);
+stmt = conn.prepareStatement(sql);
+this.fillStatement(stmt, params);
if (!stmt.execute()) {
-return false;
+return null;
}
do {
rs = stmt.getResultSet();
if (rs != null) {
rs = this.wrap(rs);
-
+
if (rsmdh != null) {
rsmdh.handle(rs.getMetaData());
}
-rsh.handle(rs, params, userObject);
+results.add(rsh.handle(rs, params, userObject));
}
} while (stmt.getMoreResults());
} catch (SQLException e) {
-rethrow(e, query, params);
+rethrow(e, sql, params);
} finally {
DbUtils.closeQuietly(rs);
DbUtils.closeQuietly(stmt);
}
-return true;
+Object[] res = new Object[results.size()];
+return results.toArray(res);
}
/**
@@ -183,35 +206,86 @@
}
/**
- * Creates a PreparedStatement using the String and Object array,
- * executes this using the Connection, and returns the results
- * inside an Iterator.
- * Null values in the Object array will be passed to the driver.
+ * Execute an SQL SELECT query with a single replacement parameter. The
+ * caller is responsible for connection cleanup.
+ *
+ * @param conn The connection to execute the query in.
+ * @param sql The query to execute.
+ * @param param The replacement parameter.
+ * @param rsh The handler that converts the results into an object.
+ * @return The object returned by the handler.
+ * @throws SQLException
*/
public Object query(
Connection conn,
-String query,
+String sql,
+Object param,
+ResultSetHandler rsh)
+throws SQLException {
+
+return this.query(conn, sql, new
Re: [primitives] First steps
+1 to the collections.primitives package. The releasing for collections was not too bad last time. One part of it is special to collections, though I don't remember why without looking at the site. I'm still happy to do the sys-adminning if you need. Hen On Mon, 20 Oct 2003, Stephen Colebourne wrote: I'm +1 to this, as it gets the release out quickly for users, and clears the way for [collections]. Discussion can wait a while. Stephen PS. There are 'how to do a release' notes on the commons website, although I don't fancy executing them for collections! - Original Message - From: Rodney Waldhoff [EMAIL PROTECTED] If everyone else is OK with releasing the 1.0 version under org.apache.commons.collections.primitives (rather than o.a..commons.primitives), that sounds OK to me. If we were to repackage along the type-of-collection lines, we'd likely be able to deprecate-and-move from o.a.c.primitives as well, but I guess this way gives us the freedom to choose the new packaging arbitrarily. On Sat, 18 Oct 2003, Stephen Colebourne wrote: The reason that this matters is that there are interfaces involved that we can't change later. So what might get changed? Well I don't see the need to remove anything from the current interfaces. I do believe that there are some methods that can be added. (separate email thread). Can we execute the 1.0 release before digging too deeply into changes to the existing structure? -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/net project.xml
brekke 2003/10/20 20:21:41 Modified:net project.xml Log: version number for release to 1.1.0 Revision ChangesPath 1.33 +4 -4 jakarta-commons/net/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/net/project.xml,v retrieving revision 1.32 retrieving revision 1.33 diff -u -r1.32 -r1.33 --- project.xml 6 Oct 2003 03:33:29 - 1.32 +++ project.xml 21 Oct 2003 03:21:41 - 1.33 @@ -4,7 +4,7 @@ pomVersion3/pomVersion nameJakarta Commons/Net/name idcommons-net/id - currentVersion1.1.0-rc1/currentVersion + currentVersion1.1.0/currentVersion organization nameApache Software Foundation/name urlhttp://jakarta.apache.org//url @@ -56,9 +56,9 @@ tagNET_1_0_0/tag /version version - id1.1.0-rc1/id - name1.1.0-rc1/name - tagNET_1_1_0_rc1/tag + id1.1.0/id + name1.1.0/name + tagNET_1_1_0/tag /version /versions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULTS][VOTE] Release Jakarta/Commons v1.1.0
Voting results: +1 Daniel F. Savarese [EMAIL PROTECTED] +1 Bruno D'Avanzo [EMAIL PROTECTED] +1 Jeffrey D. Brekke [EMAIL PROTECTED] +1 Matthew Hawthorne [EMAIL PROTECTED] +0 Henri Yandell [EMAIL PROTECTED] +0 Yoav Shapira [EMAIL PROTECTED] This satisfies the Jakarta/Commons Charter and I will proceed to cut a release in the next few days. The code has been tagged in CVS as NET_1_1_0. -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbutils] Enhanced* classes
I object to deleting them, but agree they don't offer much.
They really exist as an example of the 'driver' package, and should move
into some kind of example documentation. They would make a better example
if the setLong/getLong methods do the null checking.
Switching to using DynamicProxies for driver would make more sense as it
would allow the JDBC 1/2/3 issue to become a non-issue. I plan to start
looking into this so all of the driver package may become a pre-jdk-1.3
thing and be ignored (?). Bit confused as to whether CGLib offers anything
here.
Hen
On Mon, 20 Oct 2003, David Graham wrote:
--- Tomasz Pik [EMAIL PROTECTED] wrote:
David Graham wrote:
The Enhanced* classes don't really seem to be enhanced versions of
their
standard counterparts. For example, EnhancedResultSet has this
method:
public Long getLongObject(String column) throws SQLException {
return new Long(getLong(column));
}
What about:
public Long getLongObject(String column) throws SQLException {
long result = getLong(column);
if (wasNull()) {
return null;
} else {
return new Long(result);
}
}
How is that enhanced over the standard rs.getObject(col) which
performs
automatic type conversions or new Long(rs.getLong(col)) ?
Maybe this method check agains null too?
There is a SqlNullCheckedResultSet wrapper class that assigns a default
value for null fields. This conforms to the ResultSet interface so it
doesn't require casting to use it.
David
Regards,
Tomek
David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] plugins module ready for evaluation
Simon Kitching wrote: On Tue, 2003-10-21 at 11:26, Craig R. McClanahan wrote: Simon Kitching wrote: Regarding your tomcat example, I will have to have a think about this. I'm no expert on complex container architectures, nor on Tomcat, so if you and the Avalon team say the setLog() approach is the only way to go, I'll believe you. Nevertheless, the current approach *feels* wrong to me. I'm just trying to understand why it is necessary to do logging in this way. If you go back in the commons-dev message archives, you'll find that the reason setLog exists in the first place is because the Avalon folks (who know a little about IoC :-) said they needed it. You seem to be arguing the opposite position, which is kinda interesting. But, at the end of the day, I can't see why having an optional method to set the Log object a Digester instance can use causes you any grief if you never call it. The problem is not that the method exists on the Digester class. I'm looking at this from the point-of-view of a contributor to Digester, not a user (hence the dev list address). The problem is that in order to integrate with this solution, every class written for the Digester which needs to log output *must* do: digester.getLog().warn(oops) rather than Logger log = LogFactory.getLogger(ThisClass.class) .. log.warn(oops) Why? The first approach is only required if you want your log messages to go to the same Log instance that Digester is using. If you don't care, don't bother. And, without a getLog() call, it would not even be *possible* to share the same Log instance, which is what the Avalon folks were complaining about. The first implication is that with this pattern, *every* object which wants to log output *requires* a reference to whatever object is the holder of the master Log object (a Digester instance in this case). Even if this were a *must* requirement, how many objects n the Digester API don't have a Digester instance already? That's right, basically none of them :-). This looks like undesirable coupling to me; I find it difficult to believe that many other projects would be *able* to implement this pattern. For example, the commons-net project: does every object have a reference to some master object that can be used to hold a central Log object? Also see the xmlrules module. This creates new Digester objects to parse the xmlrules input files, but doesn't copy the set Log object. So currently xmlrules is broken with respect to Log behaviour: there is no way for the framework to control the Log object used by the Digester instances created by xmlrules. While this could be considered a bug in xmlrules, I think it shows a flaw in the concept of a centralised Log object attached to some master object; the log control doesn't automatically propagate, but instead requires explicit code. The second implication of the centralised Log object pattern is that there is a single Category for all output generated by all classes in the Digester project. This seems a shame. It may be acceptable for a project of Digester size (20-30 classes), but I presume that there is a limit beyond which this would not be acceptable. Does Tomcat use a single Category to output all of its logging? Centralized logging for Digester is used by the standard Digester classes to minimize the number of log names you have to administer. Whether you utilize it in your own code (or whether your own code is even aware that the possibility exists) is totally up to you. Regards, Simon Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/xdocs navigation.xml
matth 2003/10/20 21:37:15 Modified:io/src/java/org/apache/commons/io/input package.html io/src/java/org/apache/commons/io/output package.html io/xdocs navigation.xml Log: Added self to STATUS, fixed bad HTML in package descriptions, updated navigation to include commons links. Revision ChangesPath 1.2 +7 -1 jakarta-commons-sandbox/io/src/java/org/apache/commons/io/input/package.html Index: package.html === RCS file: /home/cvs/jakarta-commons-sandbox/io/src/java/org/apache/commons/io/input/package.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- package.html 17 Oct 2003 20:15:46 - 1.1 +++ package.html 21 Oct 2003 04:37:15 - 1.2 @@ -1,2 +1,8 @@ -Implementations of input classes, such as |InputStream| and |Reader|. +html +body +Implementations of input classes, such as +codeInputStream/code and +codeReader/code. +/body +/html 1.2 +7 -1 jakarta-commons-sandbox/io/src/java/org/apache/commons/io/output/package.html Index: package.html === RCS file: /home/cvs/jakarta-commons-sandbox/io/src/java/org/apache/commons/io/output/package.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- package.html 17 Oct 2003 20:15:46 - 1.1 +++ package.html 21 Oct 2003 04:37:15 - 1.2 @@ -1,2 +1,8 @@ -Implementations of output classes, such as |OutputStream| and |Writer|. +html +body +Implementations of output classes, such as +codeOutputStream/code and +codeWriter/code. +/body +/html 1.2 +14 -3 jakarta-commons-sandbox/io/xdocs/navigation.xml Index: navigation.xml === RCS file: /home/cvs/jakarta-commons-sandbox/io/xdocs/navigation.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- navigation.xml21 Sep 2003 17:57:00 - 1.1 +++ navigation.xml21 Oct 2003 04:37:15 - 1.2 @@ -1,15 +1,26 @@ ?xml version=1.0? -project name=commons-io href= +!DOCTYPE project [ +!ENTITY commons-nav SYSTEM ../../incl_nav.xml +] -titlecommons-io/title +project name=IO + +titleIO/title + +organizationLogo href=/images/jakarta-logo-blue.gif +Jakarta + /organizationLogo body -menu name=Navigation +menu name=Commons IO item name=Tasks href=tasks.html/ /menu +commons-nav; + /body /project + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io STATUS.html
matth 2003/10/20 21:37:50 Modified:io STATUS.html Log: Added self to STATUS Revision ChangesPath 1.12 +25 -24jakarta-commons-sandbox/io/STATUS.html Index: STATUS.html === RCS file: /home/cvs/jakarta-commons-sandbox/io/STATUS.html,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- STATUS.html 21 Aug 2003 19:11:44 - 1.11 +++ STATUS.html 21 Oct 2003 04:37:50 - 1.12 @@ -4,28 +4,28 @@ titleStatus File for Jakarta Commons IO Component/title /head body bgcolor=white - -div align=center + +div align=center h1The Jakarta Commons emIO/em Component/h1 $Id$br - a href=#Introduction[Introduction]/a a href=#Dependencies[Dependencies]/a -a href=#Release%20Info[Release Info]/a a href=#Committers[Committers]/a + a href=#Introduction[Introduction]/a a href=#Dependencies[Dependencies]/a +a href=#Release%20Info[Release Info]/a a href=#Committers[Committers]/a a href=#Action%20Items[Action Items]/a br br /div - - -a name=Introduction/a + + +a name=Introduction/a h31. INTRODUCTION/h3 - + pThe emIO/em Component contains a set of Java classes that provide I/O functionality above and beyond what the JDK provides out of the box.nbsp;/p - + h32. DEPENDENCIES/h3 - + pThe emIO/em component is dependent upon the following external components for development and use:/p - + ul lia href=http://java.sun.com/j2se;Java Development Kit/a (Version 1.2 or later)/li @@ -35,24 +35,24 @@ /ul -a name=Release Info/a +a name=Release Info/a h33. RELEASE INFO/h3 - + pCurrent Release: IO is yet to be released. We hope it will be RSN./p - + pPlanned Next Release: Real Soon Now :) See the a href=#Action%20ItemsAction Items/a list for tasks that need to be completed prior to this release./p -a name=Committers/a +a name=Committers/a h34. COMMITTERS/h3 - + pThe following individuals are the primary developers and maintainers of this component. Developers who plan to use emIO/em in their own projects are encouraged to collaborate on the future development of this component to ensure that it continues to meet a variety of needs./p - + ul lia href=mailto:[EMAIL PROTECTED]Scott Sanders/a/li lia href=mailto:[EMAIL PROTECTED]dIon Gillard/a/li @@ -60,14 +60,15 @@ lia href=maito:[EMAIL PROTECTED]Henri Yandell/abr/li lia href=maito:[EMAIL PROTECTED]Stephen Colebourne/abr/li lia href=maito:[EMAIL PROTECTED]Jeremias Maerki/abr/li + liMatthew Hawthorne/libr/ liFancy volunteering? We need you!/li /ul -a name=Action Items/a +a name=Action Items/a h35. ACTION ITEMS/h3 - -pThe following action items need to be completed prior to a Version 1.0 + +pThe following action items need to be completed prior to a Version 1.0 release of this component:/p ul liCompress - Move the compress sub-package out of IO - READY/li @@ -76,7 +77,7 @@ liExtract code from IOUtils to CopyUtils? /li liRemove StreamUtils as all its methods are in IOUtils - DONE/li liIOUtils: Remove the toByteArray() variants with the bufferSize -parameter. Reasoning can be found at +parameter. Reasoning can be found at http://www.mail-archive.com/[EMAIL PROTECTED]/msg19703.html/li liIOUtils: Change toByteArray() methods to use the new ByteArrayOutputStream which should improve performance considerably./li @@ -116,11 +117,11 @@ td align=centerEveryone/td /tr tr - tdstrongInstall / Use Documentation/strong. Create simple + tdstrongInstall / Use Documentation/strong. Create simple installation and User's Guide documentation for this component./td td align=centereveryone/td /tr - + /tbody /table br - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
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=15435. 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=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-10-20 12:14 --- Oleg, Ah. I see what you are doing. This seems like a decent solution, nothing better comes to mind. To keep things consistent I think setSoTimeout(int) should still set the timeout on the socket, if present. The new Javadoc @link on setSoTimeout() should be changed to setSocketTimeout(). Other than that I think it's good to be committed. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
