DO NOT REPLY [Bug 24523] New: - provide encode/decode for quoted-printable and others
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=24523. 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=24523 provide encode/decode for quoted-printable and others Summary: provide encode/decode for quoted-printable and others Product: Commons Version: 1.0 Beta 1 Platform: Other URL: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20815 OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Codec AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] to the extent they need any (7bit, 8bit, binary, x-token, ...) FileUpload as per the above RFE URL could well profit from that to handle Content-Transfer-Encoding - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20815] - FileUpload always assumes transfer encoding to be BINARY and does not properly handle 'Content-Transfer-Encoding' header
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=20815. 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=20815 FileUpload always assumes transfer encoding to be BINARY and does not properly handle 'Content-Transfer-Encoding' header --- Additional Comments From [EMAIL PROTECTED] 2003-11-08 08:13 --- Commons Codec seems to offer base64 handling, unfortunately not yet the rest (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24523) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] Contributions
Hi, I am interested in working on the Math commons project, mainly in the linear algebra section. I have been toying with the idea of writing some methods and classes for manipulating matrices (determinates, rref. right, left, normalized/orthogonal-eigenvectors, and all that other fun stuff), but could not find an excuse to spend time on them. My question is, after looking at the javadocs and xref it seems like the RealMatrix has already been created and implemented, but from the User Guide in Linear Algebra it says This is yet to be written. How finished is this and what kind of work needs to be done on it? Are you looking to extend it with other operations? In general: What can I do? Also I have some java objects I wrote for a class (as in school) that perform complex number manipulation and complex polynomial manipulation that might be useful. Thanks Stou - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ANN][hivemind] hivemind has been temporarily taken offline
I'm temporarily bulding out a version of the site that doesn't include the clover report or code xref. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: John Keyes [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2003 12:12 PM To: Jakarta Commons Developers List Subject: Re: [ANN][hivemind] hivemind has been temporarily taken offline The website should also be taken offline also (the XRef of the code is available) to close the other public entry point. -John K On 7 Nov 2003, at 07:26, robert burrell donkin wrote: the jakarta-pmc have decided to take the hivemind directories offline for a temporary period. this decision was taken in order to protect every body involved from legal action. this is not a judgement of the legal rights and wrongs of the situation nor should it be construed as an admission of guilt. i'd like to thank howard for drawing these possible issues to our attention and hope that he continues to work with the pmc to help us resolve the issues as quickly as possible. the [EMAIL PROTECTED] mailing list is probably the best forum for future discussions of this action or the pmc can be mailed directly. thanks for your understanding. - robert - 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]
RE: [ANN][hivemind] hivemind has been temporarily taken offline
And I've taken down the binary/source downloads. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: Howard M. Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Saturday, November 08, 2003 8:24 AM To: 'Jakarta Commons Developers List' Subject: RE: [ANN][hivemind] hivemind has been temporarily taken offline I'm temporarily bulding out a version of the site that doesn't include the clover report or code xref. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: John Keyes [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2003 12:12 PM To: Jakarta Commons Developers List Subject: Re: [ANN][hivemind] hivemind has been temporarily taken offline The website should also be taken offline also (the XRef of the code is available) to close the other public entry point. -John K On 7 Nov 2003, at 07:26, robert burrell donkin wrote: the jakarta-pmc have decided to take the hivemind directories offline for a temporary period. this decision was taken in order to protect every body involved from legal action. this is not a judgement of the legal rights and wrongs of the situation nor should it be construed as an admission of guilt. i'd like to thank howard for drawing these possible issues to our attention and hope that he continues to work with the pmc to help us resolve the issues as quickly as possible. the [EMAIL PROTECTED] mailing list is probably the best forum for future discussions of this action or the pmc can be mailed directly. thanks for your understanding. - robert - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-95) invokeBody does not seem to work with nested tags
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-95
Here is an overview of the issue:
-
Key: JELLY-95
Summary: invokeBody does not seem to work with nested tags
Type: Bug
Status: Unassigned
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: jelly
Components:
core / taglib.core
Assignee:
Reporter: Vincent Massol
Created: Sat, 8 Nov 2003 9:19 AM
Updated: Sat, 8 Nov 2003 9:19 AM
Environment: commons-jelly-tags-define-20030211.142932.jar
commons-jelly-tags-ant-20030625.032346.jar
commons-jelly-20030902.160215.jar
Description:
Here is an example:
project
default=mytest
xmlns:j=jelly:core
xmlns:maven=jelly:maven
xmlns:ant=jelly:ant
xmlns:define=jelly:define
xmlns:mytaglib=mytaglib
define:taglib uri=mytaglib
define:tag name=mytag
ant:condition property=ok
define:invokeBody/
/ant:condition
/define:tag
/define:taglib
goal name=mytest
mytaglib:mytag
ant:equals arg1=arg arg2=arg/
/mytaglib:mytag
Result = ${ok}
/goal
goal name=mytest2
ant:condition property=ok2
ant:equals arg1=arg arg2=arg/
/ant:condition
Result = ${ok2}
/goal
/project
This results in:
E:\Dev\jakarta-cactus\integration\maven\samplemaven mytest
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0-rc1-SNAPSHOT
mytest:
[condition] [ERROR] Error in class org.apache.tools.ant.taskdefs.ConditionTask
BUILD FAILED
File.. file:/E:/Dev/jakarta-cactus/integration/maven/sample/
Element... ant:condition
Line.. 11
Column 36
You must nest a condition into condition
Total time: 2 seconds
Finished at: Sat Nov 08 16:12:38 CET 2003
E:\Dev\jakarta-cactus\integration\maven\sample
And:
E:\Dev\jakarta-cactus\integration\maven\samplemaven mytest2
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0-rc1-SNAPSHOT
BUILD SUCCESSFUL
Total time: 2 seconds
Finished at: Sat Nov 08 16:17:31 CET 2003
E:\Dev\jakarta-cactus\integration\maven\sample
Any idea?
Thanks
-Vincent
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Jelly] invokeBody with nested tags?
Thanks Peter,
Here is an example (I've created
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-95):
project
default=mytest
xmlns:j=jelly:core
xmlns:maven=jelly:maven
xmlns:ant=jelly:ant
xmlns:define=jelly:define
xmlns:mytaglib=mytaglib
define:taglib uri=mytaglib
define:tag name=mytag
ant:condition property=ok
define:invokeBody/
/ant:condition
/define:tag
/define:taglib
goal name=mytest
mytaglib:mytag
ant:equals arg1=arg arg2=arg/
/mytaglib:mytag
Result = ${ok}
/goal
goal name=mytest2
ant:condition property=ok2
ant:equals arg1=arg arg2=arg/
/ant:condition
Result = ${ok2}
/goal
/project
Calling mytest fails whereas mytest2 works.
Thanks
-Vincent
-Original Message-
From: peter royal [mailto:[EMAIL PROTECTED]
Sent: 03 November 2003 03:28
To: Jakarta Commons Developers List
Subject: Re: [Jelly] invokeBody with nested tags?
On Nov 2, 2003, at 9:21 AM, Vincent Massol wrote:
Does invokeBody only works with text? Can it work with nested tags
too?
How can I achieve the above?
From what I know, it *should* work. invokeBody invokes nested tags
when
called from tags defined in java, i don't see why it should be
different for jelly-based tags. if you work up a testcase and stick it
in jira, that'll increase chances of other eyes looking at it :)
-pete
-
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: [codec] Maven build oddity
Ah, that makes sense, thank you for the clarification. Yes, I am using Eclipse but I did not know that extssh was an eclipse only contraption. Eclipse now supports the ability to use a different cvs read and write protocol, I'll that a go. Gary -Original Message- From: __matthewHawthorne [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2003 19:45 To: Jakarta Commons Developers List Subject: Re: [codec] Maven build oddity I'll take a guess. In the log message, you can tell that it didn't like your CVSROOT. It looks like you checked out the code using the extssh method in Eclipse? I believe that this is an Eclipse-only connect method, and command line CVS tools don't like it. Perhaps StatCvs doesn't detect this problem very well and bombs via NullPointerException. For a quick fix, you can either check out using the :ext: method and tunnel through ssh, or just comment out the statcvs report in your project.xml when doing local builds. Hope this helps. Gary Gregory wrote: Hello, I've been using Maven to build [codec] locally. All goes well except this one goal: statcvs:generate: [echo] fetching cvs logs... [cvs] cvs log: Unknown method (`extssh') in CVSROOT. [cvs] cvs [log aborted]: Bad CVSROOT: `:extssh:[EMAIL PROTECTED]:/home/cvs'. [mkdir] Created dir: C:\cvs-store\apache.org\jakarta\commons\codec\target\docs\statcvs [mkdir] Created dir: C:\cvs-store\apache.org\jakarta\commons\codec\target\generated- xdocs\statcvs [java] StatCvs-XML - CVS statistics generation [java] [java] java.lang.NullPointerException [java] at net.sf.statcvs.Main.getModuleName(Main.java:193) [java] at net.sf.statcvs.Main.run(Main.java:159) [java] at net.sf.statcvs.Main.main(Main.java:78) [java] null [java] [ERROR] Java Result: 1 Any tips? Thanks, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/iterators ObjectArrayListIterator.java
scolebourne2003/11/08 10:37:16 Modified:collections/src/java/org/apache/commons/collections/iterators ObjectArrayListIterator.java Log: No change Revision ChangesPath 1.9 +3 -3 jakarta-commons/collections/src/java/org/apache/commons/collections/iterators/ObjectArrayListIterator.java Index: ObjectArrayListIterator.java === RCS file: /home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/iterators/ObjectArrayListIterator.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- ObjectArrayListIterator.java 9 Oct 2003 20:44:32 - 1.8 +++ ObjectArrayListIterator.java 8 Nov 2003 18:37:16 - 1.9 @@ -76,7 +76,7 @@ * @since Commons Collections 3.0 * @version $Revision$ $Date$ * - * @author a href=mailto:[EMAIL PROTECTED]Neil O'Toole/a + * @author Neil O'Toole * @author Stephen Colebourne * @author Phil Steitz */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/iterators SingletonListIterator.java
scolebourne2003/11/08 10:38:27
Modified:collections/src/java/org/apache/commons/collections/iterators
SingletonListIterator.java
Log:
No change
Revision ChangesPath
1.9 +3 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/iterators/SingletonListIterator.java
Index: SingletonListIterator.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/iterators/SingletonListIterator.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- SingletonListIterator.java9 Oct 2003 20:44:32 - 1.8
+++ SingletonListIterator.java8 Nov 2003 18:38:27 - 1.9
@@ -70,8 +70,7 @@
* @author Stephen Colebourne
* @author Rodney Waldhoff
*/
-public class SingletonListIterator
- implements ListIterator, ResetableListIterator {
+public class SingletonListIterator implements ListIterator, ResetableListIterator {
private boolean beforeFirst = true;
private boolean nextCalled = false;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Separate email list for math development?
I think the concern is more so that the content (mathematical algorithms) is outside the scope of interest of the Commons in general, while the discussions concerning package design are interesting to commons in general. This is much in the same way that the Http protocol discussions of HttpClient were too subject specific to be of interest of Commons and thus a new list was spawned for that subject matter. Commons Math Developers would be a list where discussion about internal algorithm issues can be discussed without the huge amounts of email we generate in the process getting dumped into the commons developer list and requiring filtering by everyone else. Of course we would promote that many Commons Developers actually join both lists and it still would be highly promoted that issues concerning the interaction of math with other Commons components be discussed on the Commons Developer list directly. Its a tough call, I'm not quite convinced theres enough [math] activity yet (even though I opened up the discussion). I fact, there was a long period in the fall where we didn't open any new discussions about math. -Mark John Keyes wrote: Is the goal to reduce the traffic on commons-dev? Are mail filters not sufficient? On a general note, a policy should be in place stating that if a commons project gets its own dev mailing list a PMC member MUST be subscribed to it. -John K On 8 Nov 2003, at 18:57, David Graham wrote: +1 David --- Mark R. Diggory [EMAIL PROTECTED] wrote: I know from positions taken by Craig and others there is some interest in seeing some of the discussion in the math project get moved off to another list. I know that sometimes the lengthy discussions we have about what must appear to some to be like String Theory, just PLAIN OUT THERE... ;) If its really in the publics interest, I'd be willing to propose possibly starting a separate math developers list. Let me know if theres really a consensus of opinion on this. -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - 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] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23270] - [collections] DoubleOreredMap enhancements
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=23270. 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=23270 [collections] DoubleOreredMap enhancements --- Additional Comments From [EMAIL PROTECTED] 2003-11-08 20:29 --- The DoubleOrderedMap has now been refactored as TreeBidiMap on the CVS. It fulfils the new interface BidiMap (along with other implementations DualHashBidiMap and DualTreeBidiMap). TreeBidiMap _should_ implement SortedBidiMap, but doesn't do so at present. Any patches to TreeBidiMap and its test class to achieve this (comparator usage and submaps) would be welcome. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Separate email list for math development?
I think the concern is more so that the content (mathematical algorithms) is outside the scope of interest of the Commons in general, while the discussions concerning package design are interesting to commons in general. This is much in the same way that the Http protocol discussions of HttpClient were too subject specific to be of interest of Commons and thus a new list was spawned for that subject matter. From what I remember HttpClient was granted a dedicated list purely based on the high level of traffic. I cannot see any real benefits of creating new lists purely on this basis (apart from the bandwidth saved, though if this is a concern you would probably be receiving digest mails or use gmane). Commons Math Developers would be a list where discussion about internal algorithm issues can be discussed without the huge amounts of email we generate in the process getting dumped into the commons developer list and requiring filtering by everyone else. Of course we would promote that many Commons Developers actually join both lists and it still would be highly promoted that issues concerning the interaction of math with other Commons components be discussed on the Commons Developer list directly. This means we have automatically complicated the interaction between Math developers and their community. I just see this as another layer of unnecessary indirection. Its a tough call, I'm not quite convinced theres enough [math] activity yet (even though I opened up the discussion). I fact, there was a long period in the fall where we didn't open any new discussions about math. My reason for commenting on this thread is to see if we can identify a real problem rather than segregating projects from the community. -John K - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient HttpConnection.java
olegk 2003/11/08 13:26:03
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpConnection.java
Log:
Fixes a minor bug in my previos patch (Input stream not properly 'wrapped' when
secure tunnel (SSL via proxy) is being established).
Contributed by Oleg Kalnichevski
Revision ChangesPath
1.80 +6 -5
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java
Index: HttpConnection.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java,v
retrieving revision 1.79
retrieving revision 1.80
diff -u -r1.79 -r1.80
--- HttpConnection.java 5 Nov 2003 20:45:34 - 1.79
+++ HttpConnection.java 8 Nov 2003 21:26:03 - 1.80
@@ -782,7 +782,8 @@
if (rcvBufSize = 0) {
socket.setReceiveBufferSize(rcvBufSize);
}
-inputStream = new PushbackInputStream(socket.getInputStream());
+inputStream = new PushbackInputStream(
+new WrappedInputStream(socket.getInputStream()));
outputStream = new BufferedOutputStream(
new WrappedOutputStream(socket.getOutputStream()),
socket.getSendBufferSize()
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Separate email list for math development?
John Keyes wrote: I think the concern is more so that the content (mathematical algorithms) is outside the scope of interest of the Commons in general, while the discussions concerning package design are interesting to commons in general. This is much in the same way that the Http protocol discussions of HttpClient were too subject specific to be of interest of Commons and thus a new list was spawned for that subject matter. From what I remember HttpClient was granted a dedicated list purely based on the high level of traffic. I cannot see any real benefits of creating new lists purely on this basis (apart from the bandwidth saved, though if this is a concern you would probably be receiving digest mails or use gmane). Commons Math Developers would be a list where discussion about internal algorithm issues can be discussed without the huge amounts of email we generate in the process getting dumped into the commons developer list and requiring filtering by everyone else. Of course we would promote that many Commons Developers actually join both lists and it still would be highly promoted that issues concerning the interaction of math with other Commons components be discussed on the Commons Developer list directly. This means we have automatically complicated the interaction between Math developers and their community. I just see this as another layer of unnecessary indirection. Probibly true. Its a tough call, I'm not quite convinced theres enough [math] activity yet (even though I opened up the discussion). I fact, there was a long period in the fall where we didn't open any new discussions about math. My reason for commenting on this thread is to see if we can identify a real problem rather than segregating projects from the community. -John K Sounds good, my concern was that others in the community were not happy with the amount of math traffic. The idea of an alternate list was just one possible direction. I agree that causing project segregation is a big concern and we should avoid allowing it to happen. However, as commons grows larger (or as projects outgrow the commons), there may be cases where this is neccessary. -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [collections] Resetable iterators
A few things.
On the one hand, there's nothing Iterator-specific about a reset()
method which supports a Resetable interface. However, there may be many
times where a single reference is appropriate for something that is both
Iterator and Resetable. What about providing both:
public interface ResetableIterator
extends Iterator, Resetable
{
}
I know this can lead to a combinatoric explosion on interfaces if
carried to the extreme but I think you can make a reasonable case here.
The big issue, though, is that the proper spelling is Resettable. :)
http://www.m-w.com/cgi-bin/dictionary?va=resettable
--lee
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Saturday, November 08, 2003 3:12 PM
To: Jakarta Commons Developers List
Subject: [collections] Resetable iterators
The ResetableIterator interface is causing hassles as I try to tidy the
code up ready for release. Out current design requires that there is a
ResetableIterator interface for each iterator type. And there are now 5
iterator types (normal, List, Map, Ordered, OrderedMap).
I would like to remove the Resetable*Iterator interfaces and replace
with a Resetable interface. The main impact is that an instanceof/cast
check will be required to check for resetability.
Iterator it = list.iterator();
it.next();
if (it instanceof Resetable) {
((Resetable) it).reset();
}
But this is not any different to how it would be anyway, as users would
have had to check for ResetableIterator.
Any objections to me making this change?
Stephen
-
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 project.properties
jkeyes 2003/11/08 14:10:00 Modified:cli/src/java/org/apache/commons/cli2 StringComparator.java Argument.java PatternBuilder.java ArgumentBuilder.java cli/src/java/org/apache/commons/cli Options.java MissingOptionException.java UnrecognizedOptionException.java BasicParser.java GnuParser.java Parser.java Util.java overview.html TypeHandler.java AlreadySelectedException.java CommandLine.java HelpFormatter.java OptionGroup.java MissingArgumentException.java Option.java CommandLineParser.java PatternOptionBuilder.java ParseException.java OptionValidator.java PosixParser.java package.html OptionBuilder.java cli/src/java/org/apache/commons/cli2/defaults/impl PreferencesImpl.java PropertiesImpl.java cli/src/test/org/apache/commons/cli2 ComparatorsTest.java ParentTestCase.java ArgumentTestCase.java GroupTestCase.java OptionTestCase.java cli/src/test/org/apache/commons/cli OptionBuilderTest.java BugsTest.java ApplicationTest.java GnuParseTest.java OptionsTest.java cli project.properties Log: - fixed line endings - some checkstyle changes Revision ChangesPath 1.2 +105 -105 jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/StringComparator.java http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/StringComparator.java.diff?r1=1.1r2=1.2 1.3 +14 -13 jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/Argument.java http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/Argument.java.diff?r1=1.2r2=1.3 1.3 +222 -222 jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/PatternBuilder.java http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/PatternBuilder.java.diff?r1=1.2r2=1.3 1.9 +73 -78 jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/ArgumentBuilder.java http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/ArgumentBuilder.java.diff?r1=1.8r2=1.9 1.8 +304 -304 jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/Options.java http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/Options.java.diff?r1=1.7r2=1.8 1.5 +81 -81 jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/MissingOptionException.java http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/MissingOptionException.java.diff?r1=1.4r2=1.5 1.5 +82 -82 jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/UnrecognizedOptionException.java http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/UnrecognizedOptionException.java.diff?r1=1.4r2=1.5 1.2 +91 -91 jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/BasicParser.java http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/BasicParser.java.diff?r1=1.1r2=1.2 1.2 +217 -217 jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/GnuParser.java http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/GnuParser.java.diff?r1=1.1r2=1.2 1.2 +460 -460 jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/Parser.java http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/Parser.java.diff?r1=1.1r2=1.2 1.2 +110 -110 jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/Util.java http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/Util.java.diff?r1=1.1r2=1.2 1.5 +28 -28 jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/overview.html http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/overview.html.diff?r1=1.4r2=1.5 1.5 +270 -270 jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/TypeHandler.java http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/TypeHandler.java.diff?r1=1.4r2=1.5 1.7 +82 -82 jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/AlreadySelectedException.java http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli/AlreadySelectedException.java.diff?r1=1.6r2=1.7 1.7 +364
Re: [all] Separate email list for math development?
Its a tough call, I'm not quite convinced theres enough [math] activity yet (even though I opened up the discussion). I fact, there was a long period in the fall where we didn't open any new discussions about math. My reason for commenting on this thread is to see if we can identify a real problem rather than segregating projects from the community. -John K Sounds good, my concern was that others in the community were not happy with the amount of math traffic. The idea of an alternate list was just one possible direction. I agree that causing project segregation is a big concern and we should avoid allowing it to happen. However, as commons grows larger (or as projects outgrow the commons), there may be cases where this is neccessary. I think the Wiki could play a part here where design decisions are edited and recorded. I haven't thought this through yet. -John K - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[validator] EmailTest failing
Hi all, I did a fresh checkout of validator this evening and the EmailTest failed. I'll look into this myself when I have a moment. However, I thought I'd ask if this is a known issue? I didn't see anything in the archives. Report follows:- Testsuite: org.apache.commons.validator.EmailTest Tests run: 7, Failures: 1, Errors: 0, Time elapsed: 4.45 sec Testcase: testEmail took 2.97 sec Testcase: testEmailExtension took 0.475 sec Testcase: testEmailWithDash took 0.208 sec Testcase: testEmailWithDotEnd took 0.194 sec Testcase: testEmailWithBogusCharacter took 0.18 sec Testcase: testEmailWithCommas took 0.191 sec Testcase: testEmailUserName took 0.194 sec FAILED Value [EMAIL PROTECTED] for the 'email' action should have failed. junit.framework.AssertionFailedError: Value [EMAIL PROTECTED] for the 'email' action should have failed. at org.apache.commons.validator.EmailTest.valueTest(EmailTest.java:341) at org.apache.commons.validator.EmailTest.testEmailUserName(EmailTest.java:256) at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:454) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:348) at org.apache.maven.cli.App.doMain(App.java:543) at org.apache.maven.cli.App.main(App.java:1109) at com.werken.forehead.Forehead.run(Forehead.java:543) at com.werken.forehead.Forehead.main(Forehead.java:573) Testcase: testEmailUserName Regards, -- Peter Courcoux [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Proposal for Package restructuring and Class renaming
--- Mark R. Diggory [EMAIL PROTECTED] wrote: Al Chou wrote: --- Mark R. Diggory [EMAIL PROTECTED] wrote: I have several modifications I'm planning to make, but in the spirit of consensus I want to propose them and attempt to get some agreement. So math developer opinions on the subject would be good. 1.) o.a.c.math.stat.distributions -- o.a.c.math.distributions Gives this package a more generic position to hold more than just stat distributions. What other kinds of distributions did you have in mind? I'm asking out of complete ignorance. Probability Distributions (Gamma, Beta, Poisson, Exponential, Logarithmic, Hyperbolic ...) great examples of these are in Colt's cern.jet.stat and cern.jet.random packages. ... but are bound up as implementations of RandomNumberGeneration classes...not that that a bad thing. Eventually ours could be used in random number generation, I think they should be a more dominant package. -Mark Would you move the existing ones into org.apache.commons.math.distributions.statistical or something so that the probability distributions could be organized together under *.probability? Also, I noticed that the current package uses the singular distribution rather than distributions. Al = Albert Davidson Chou Get answers to Mac questions at http://www.Mac-Mgrs.org/ . __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Proposal for Package restructuring and Class renaming
--- Mark R. Diggory [EMAIL PROTECTED] wrote: Al Chou wrote: --- Mark R. Diggory [EMAIL PROTECTED] wrote: ... 2.) Like in my last emails concerning Univariate I would like to, (and have done so in my checkout successfully) Make the following Class changes: interface o.a.c.m.stat.StoreUnivariate -- abstract class o.a.c.m.stat.DescriptiveStatistics this actually becomes a factory class and uses Discovery to instantiate new instances of the following implementations *default implementation* o.a.c.m.stat.StoreUnivariateImpl -- o.a.c.m.stat.univariate.StatisticsImpl Forgive me for not refamiliarizing myself with the code first, but should the storeless version perhaps be the default implementation instead? What do we lose by going that way? I'm thinking it would be nice to keep memory usage lower if possible. The Storeless version (UnivariateImpl) doesn't support rank Statistics because of its storeless nature, the more fully featured implementation is StoreUnivariateImpl, it does everything, but has the limitation of requiring storage of the values. These are two different implementations with different internal storage configurations. I choose StoreUnivariateImpl because I think the default should have full capabilities. The storeless version is more of an Optimized solution, It probably wise to suggest that one use it only if one needs that functionality (ie trying to get moments across huge datasets or realtime value streams of sorts) That sounds reasonable. Thanks for the refresher (I looked at the current code based on your remarks, too). Before we go overboard, can you give a quick example of instantiating one of the implementations? Or perhaps, both the default and one alternative ... Yes, like that For the default Discovery configured implementation: DescriptiveStatistics stats = DescriptiveStatistics.newInstance(); stats.addValue(5.0); ... double mean = stats.getMean(); For any alternate Implementations: DescriptiveStatistics stats = DescriptiveStatistics.newInstance(StorelessDescriptiveStatisticsImpl.class); stats.addValue(5.0); ... double mean = stats.getMean(); and/or DescriptiveStatistics stats = DescriptiveStatistics.newInstance(o.a.c.math.stat.impl.StorelessDescriptiveStatisticsImpl); stats.addValue(5.0); ... double mean = stats.getMean(); depending n which people like more OK, I see. The one thing I notice is that the names are getting awfully long, especially for the non-default case. I guess that's a price we pay for having descriptive (no play on words intended) names like DescriptiveStatistics Al __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Resetable iterators
From: Lee Crawford [EMAIL PROTECTED]
On the one hand, there's nothing Iterator-specific about a reset()
method which supports a Resetable interface. However, there may be many
times where a single reference is appropriate for something that is both
Iterator and Resetable. What about providing both:
public interface ResetableIterator
extends Iterator, Resetable
{
}
This is what we have now, and I'm arguing against.
I know this can lead to a combinatoric explosion on interfaces if
carried to the extreme but I think you can make a reasonable case here.
...because of the explosion of interfaces. We now have 5 basic iterator
types, doing resettable this way leads to 10 interfaces. It all works, but
is is desirable?
Stephen
The big issue, though, is that the proper spelling is Resettable. :)
http://www.m-w.com/cgi-bin/dictionary?va=resettable
--lee
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Saturday, November 08, 2003 3:12 PM
To: Jakarta Commons Developers List
Subject: [collections] Resetable iterators
The ResetableIterator interface is causing hassles as I try to tidy the
code up ready for release. Out current design requires that there is a
ResetableIterator interface for each iterator type. And there are now 5
iterator types (normal, List, Map, Ordered, OrderedMap).
I would like to remove the Resetable*Iterator interfaces and replace
with a Resetable interface. The main impact is that an instanceof/cast
check will be required to check for resetability.
Iterator it = list.iterator();
it.next();
if (it instanceof Resetable) {
((Resetable) it).reset();
}
But this is not any different to how it would be anyway, as users would
have had to check for ResetableIterator.
Any objections to me making this change?
Stephen
-
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-sandbox/cli project.properties
jkeyes 2003/11/08 16:24:58
Modified:cli project.properties
Log:
- bug 23757: Javadoc crosslinking
The attachment in Bugzilla was a direct fix to the build.xml
but as we generate this using Maven I made the fix
in project.properties. How to get this information into
the generated build.xml is unknown at this time. I have
asked the question on the maven users list.
Revision ChangesPath
1.7 +2 -2 jakarta-commons-sandbox/cli/project.properties
Index: project.properties
===
RCS file: /home/cvs/jakarta-commons-sandbox/cli/project.properties,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- project.properties8 Nov 2003 22:10:00 - 1.6
+++ project.properties9 Nov 2003 00:24:58 - 1.7
@@ -6,5 +6,5 @@
compile.optimize = off
compile.deprecation = off
-#maven.jarResources.basedir=${basedir}/src/java
-
+maven.javadoc.links=http://java.sun.com/j2se/1.3/docs/api/
+
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta-site2 karma
Quoting David Graham [EMAIL PROTECTED]: While trying to update the Jakarta news page for DbUtils I realized I don't have the karma to update it. So can one of you karma admins give me access? Done (better late than never :-). Thanks, David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announcement] DbUtils Promotion to Common Proper Completed
Quoting David Graham [EMAIL PROTECTED]: Commons DbUtils cvs tree is now under jakarta-commons instead of jakarta-commons-sandbox. Please update your local checkouts accordingly. More info on DbUtils can be found here: http://jakarta.apache.org/commons/dbutils/ David Effective tonight (20031109), the nightly build for dbutils will come from the promoted jakarta-commons directory rather than the sandbox. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23757] - Javadoc crosslinking
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=23757. 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=23757 Javadoc crosslinking [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2003-11-09 00:35 --- I have made the fix in project.properties. As the build.xml is generated by maven I am exploring whether maven can add the link element to the javadoc target in build.xml. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party libraries
On Wed, 5 Nov 2003, Mark R. Diggory wrote: Hmm, not to be critical, but 5.1 is almost at the end of its product lifecycle. Weblogic has had several releases since 5.1 that solve many of these issues do they not? I say this mostly to identify that there is a limitation as to how far back in terms of versioning we, as a new tool, should consider supporting. I would have attempted to deal with an issue like this with BEA, not neccessarily with the java community at large because they create too many jars (I'm saying this lightly). Not to nip a subject in the butt. But this has moved way off the issue associated with how dependent the different commons projects (and specifically related to math dependencies). I hope we can draw it back into this subject. -Mark I agree with minimizing the number of dependent Jar's. I also agree with statements made earlier in this thread related to supporting older JDKs (if JDK1.2 works for your app why should use of this component force you to change?) Regarding the logging; It has been suggested that the logging dependency be isolated to the test classes only on not required for the runtime lib. This makes sense to me, with the caveat that we must have a robust exception hierarchy so that logging can be plugged in at a higher level. Regarding the Discovery, I see only two instances where the DiscoveryClass is used (UnivariateRealSolverFactory, and DistributionFactory), both of which use only the newInstance(Class,String) method. Off hand I dont see the advantage of using the DiscoveryClass here, my impression is the find() methods are the 'meat' of the DiscoveryClass. commons-collections, this seems only prudent to keep, as I can only imagine that the linear algebraic routines will become more complicated, and collections lends itself naturally to mathematical constructs. this leaves commons-lang, and commons-beanutils None of these are used very extensively, however I can see how these are useful. commons-lang is used only in the MathException class, as a trade off for removing logging I think that the NestableException becomes necessary. commons-beanutils is used by the *Transformer classes (seems good to me). -- Matt Cliff Cliff Consulting 303.757.4912 720.280.6324 (c) The label said install Windows 98 or better so I installed Linux. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/xdocs/dtds - New directory
tobrien 2003/11/08 17:23:34 jakarta-commons/digester/xdocs/dtds - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/xdocs/dtds digester-rules.dtd
tobrien 2003/11/08 17:24:04 Added: digester/xdocs/dtds digester-rules.dtd Log: Digester dtd added to Digester site Revision ChangesPath 1.1 jakarta-commons/digester/xdocs/dtds/digester-rules.dtd Index: digester-rules.dtd === ?xml version=1.0 encoding=UTF-8 ? !-- Digester component of the Jakarta Commons Subproject DTD for the definition of Digester rules in XML. $Id: digester-rules.dtd,v 1.1 2003/11/09 01:24:04 tobrien Exp $ -- !-- This document type defines an XML format for defining Digester rules. Digester is a framework for pattern-matching-based parsing of XML into Java objects. See http://jakarta.apache.org/commons/digester.html. -- !ENTITY % rule-elements bean-property-setter-rule | call-method-rule | call-param-rule | object-param-rule | factory-create-rule | object-create-rule | set-properties-rule | set-property-rule | set-top-rule | set-next-rule !-- digester-rules is the root element. -- !ELEMENT digester-rules (pattern | include | bean-property-setter-rule | call-method-rule | call-param-rule | object-param-rule | factory-create-rule | object-create-rule | set-properties-rule | set-property-rule | set-top-rule | set-next-rule )* !-- pattern defines a matching pattern, or part of a matching pattern. Any rule nested in a pattern element prepends its parent's to its pattern. Patterns may be recursively nested. Example: pattern value=foo pattern value=bar object-create-rule pattern=baz classname=Fubar / /pattern /pattern The above sample fragment defines an ObjectCreateRule associated with the pattern foo/bar/baz. Note that the use of pattern elements is optional; an alternative is for each rule element to contain a 'pattern' attribute. -- !ELEMENT pattern (pattern | include | bean-property-setter-rule | call-method-rule | call-param-rule | factory-create-rule | object-create-rule | set-properties-rule | set-property-rule | set-top-rule | set-next-rule )* !ATTLIST pattern value CDATA #REQUIRED !-- include allows one set of digester rules to be included inside another. The 'path' attribute contains the URI of the document to include. Inclusion behaves as if the included rules document is 'macro-expanded' within the outer document. Programmatically initialized rules can be included as well, via the 'class' attribute. The 'class' attribute should contain the name of a class that implements org.apache.commons.digester.xmlrules.DigesterRulesSource. -- !ELEMENT include EMPTY !ATTLIST include path CDATA #IMPLIED class CDATA #IMPLIED !-- Each 'rule' element below corresponds to a concrete subclass of org.apache.framework.digester.Rule. Each 'rule' element has an optional 'pattern' attribute, which defines the pattern for that rule instance. If the rule element is nested inside one or more pattern elements, those patterns will be prepended to the pattern specified in the rule's 'pattern' attribute. -- !-- Bean Property Setter Rule -- !ELEMENT bean-property-setter-rule EMPTY !ATTLIST bean-property-setter-rule pattern CDATA #IMPLIED propertyname CDATA #IMPLIED !-- CallMethodRule -- !ELEMENT call-method-rule EMPTY !ATTLIST call-method-rule patternCDATA #IMPLIED methodname CDATA #REQUIRED paramcount CDATA #IMPLIED paramtypes CDATA #IMPLIED !-- CallParamRule attrname - set param from attribute value (cannot be combined with from-stack) from-stack - set param from stack (cannot be combined with attrname) -- !ELEMENT call-param-rule EMPTY !ATTLIST call-param-rule pattern CDATA #IMPLIED paramnumber CDATA #REQUIRED attrname CDATA #IMPLIED from-stack CDATA #IMPLIED !-- ObjectParamRule attrname - an arbitrary Object defined programatically, assigned if the element pattern AND specified attribute name are matched param - an arbitrary Object defined programatically, assigned when the element pattern associated with the Rule is matched type - class name for object value - initial value for the object -- !ELEMENT object-param-rule EMPTY !ATTLIST object-param-rule pattern CDATA #IMPLIED paramnumber CDATA #REQUIRED param CDATA #REQUIRED attrname CDATA #IMPLIED type CDATA #REQUIRED value CDATA #IMPLIED !-- FactoryCreateRule ignore-exceptions
cvs commit: jakarta-commons/digester/xdocs navigation.xml
tobrien 2003/11/08 17:24:28 Modified:digester/xdocs navigation.xml Log: entity reference to common commons nav updated to work with newer Maven Revision ChangesPath 1.4 +1 -1 jakarta-commons/digester/xdocs/navigation.xml Index: navigation.xml === RCS file: /home/cvs/jakarta-commons/digester/xdocs/navigation.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- navigation.xml28 Sep 2003 12:24:59 - 1.3 +++ navigation.xml9 Nov 2003 01:24:28 - 1.4 @@ -1,7 +1,7 @@ ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE project [ -!ENTITY commons-nav SYSTEM ../incl_nav.xml +!ENTITY commons-nav SYSTEM ../../incl_nav.xml ] project name=Digester - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: request sandbox karma
Quoting Brett Porter [EMAIL PROTECTED]: Hi, I was wondering if someone could grant me sandbox karma so I can make some contributions to commons-naming. My apache CVS username is brett. Thanks in advance, Brett Done, but I suspect you'll still have problems if you are not added to the jakarta Unix group ... drop a line to [EMAIL PROTECTED] (cc'd to [EMAIL PROTECTED]) to make that happen. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Chain] ContextToRequestCommand
Quoting Jeff Caddel [EMAIL PROTECTED]:
Any feedback on this Command implementation?
The idea is that as a chain of commands is executing objects get
aggregated into a map. The context holds a reference to the map. At
the tail end of the execution chain, this command places the objects
from the map into the request as request attributes so that front end
components (Tiles, JSP's etc) can display them.
If your application uses WebContext (or one of it's subclasses) as the Context
object being passed down the chain, you already have access to the request
attributes via the getRequestScope() method. There's also other Map-returning
methods on WebContext for lots of other useful stuff (headers, cookies, session
attributes, context attributes, context init parameters, ...).
On the attribute collections in particular, the Map implementation is two-way
... for example, usage like this:
public boolean execute(Context context) throws Exception {
...
WebContext wcontext = (WebContext) context;
// Following is equivalent to request.getAttribute(foo)
String fooValue = wcontext.getRequestScope().get(foo);
// Following is equivalent to request.setAttribute(foo, bar)
wcontext.getRequestScope().put(foo, bar);
...
}
makes a request attribute named foo with value bar visible to a JSP page (or
whatever) that will ultimately create the response.
Does this satisfy the sorts of requirements you were after?
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/chain/src/java/org/apache/commons/chain/web ChainResources.java
craigmcc2003/11/08 17:51:51
Modified:chain/src/java/org/apache/commons/chain/web
ChainResources.java
Log:
Deal correctly with null passed in as the resources parameter value (which
the Javadocs say is perfectly legal).
Submitted by: Jeff Caddel jcaddel at cox.net
Revision ChangesPath
1.4 +9 -3
jakarta-commons-sandbox/chain/src/java/org/apache/commons/chain/web/ChainResources.java
Index: ChainResources.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/chain/src/java/org/apache/commons/chain/web/ChainResources.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ChainResources.java 20 Oct 2003 17:12:07 - 1.3
+++ ChainResources.java 9 Nov 2003 01:51:51 - 1.4
@@ -105,6 +105,9 @@
static void parseClassResources(Catalog catalog, String resources,
ConfigParser parser) {
+if (resources == null) {
+return;
+}
ClassLoader loader =
Thread.currentThread().getContextClassLoader();
if (loader == null) {
@@ -155,6 +158,9 @@
String resources,
ConfigParser parser) {
+if (resources == null) {
+return;
+}
String path = null;
try {
while (true) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/chain/src/java/org/apache/commons/chain/web/servlet ChainProcessor.java
craigmcc2003/11/08 17:57:21 Modified:chain/src/java/org/apache/commons/chain/config ConfigRuleSet.java chain/src/java/org/apache/commons/chain/generic LookupCommand.java chain/src/java/org/apache/commons/chain/impl CatalogBase.java chain/src/java/org/apache/commons/chain/web WebContext.java chain/src/java/org/apache/commons/chain/web/servlet ChainProcessor.java Log: Add imports for class names used in [EMAIL PROTECTED] ...} tags in the Javadocs, to avoid warning messages from the javadoc tool in 1.4.2. Revision ChangesPath 1.4 +7 -4 jakarta-commons-sandbox/chain/src/java/org/apache/commons/chain/config/ConfigRuleSet.java Index: ConfigRuleSet.java === RCS file: /home/cvs/jakarta-commons-sandbox/chain/src/java/org/apache/commons/chain/config/ConfigRuleSet.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- ConfigRuleSet.java20 Oct 2003 05:25:41 - 1.3 +++ ConfigRuleSet.java9 Nov 2003 01:57:21 - 1.4 @@ -62,6 +62,9 @@ package org.apache.commons.chain.config; +import org.apache.commons.chain.Catalog; +import org.apache.commons.chain.Chain; +import org.apache.commons.chain.Command; import org.apache.commons.digester.Digester; import org.apache.commons.digester.RuleSetBase; 1.7 +5 -4 jakarta-commons-sandbox/chain/src/java/org/apache/commons/chain/generic/LookupCommand.java Index: LookupCommand.java === RCS file: /home/cvs/jakarta-commons-sandbox/chain/src/java/org/apache/commons/chain/generic/LookupCommand.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- LookupCommand.java20 Oct 2003 05:25:41 - 1.6 +++ LookupCommand.java9 Nov 2003 01:57:21 - 1.7 @@ -63,6 +63,7 @@ import org.apache.commons.chain.Catalog; +import org.apache.commons.chain.Chain; import org.apache.commons.chain.Command; import org.apache.commons.chain.Context; import org.apache.commons.chain.Filter; 1.9 +5 -4 jakarta-commons-sandbox/chain/src/java/org/apache/commons/chain/impl/CatalogBase.java Index: CatalogBase.java === RCS file: /home/cvs/jakarta-commons-sandbox/chain/src/java/org/apache/commons/chain/impl/CatalogBase.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- CatalogBase.java 20 Oct 2003 05:25:41 - 1.8 +++ CatalogBase.java 9 Nov 2003 01:57:21 - 1.9 @@ -66,6 +66,7 @@ import java.util.Iterator; import java.util.Map; import org.apache.commons.chain.Catalog; +import org.apache.commons.chain.Chain; import org.apache.commons.chain.Command; 1.4 +5 -4 jakarta-commons-sandbox/chain/src/java/org/apache/commons/chain/web/WebContext.java Index: WebContext.java === RCS file: /home/cvs/jakarta-commons-sandbox/chain/src/java/org/apache/commons/chain/web/WebContext.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- WebContext.java 20 Oct 2003 05:25:41 - 1.3 +++ WebContext.java 9 Nov 2003 01:57:21 - 1.4 @@ -64,6 +64,7 @@ import java.util.Map; +import org.apache.commons.chain.Context; import org.apache.commons.chain.impl.ContextBase; 1.4 +4 -3 jakarta-commons-sandbox/chain/src/java/org/apache/commons/chain/web/servlet/ChainProcessor.java Index: ChainProcessor.java === RCS file: /home/cvs/jakarta-commons-sandbox/chain/src/java/org/apache/commons/chain/web/servlet/ChainProcessor.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- ChainProcessor.java 20 Oct 2003 05:25:41 - 1.3 +++ ChainProcessor.java 9 Nov 2003 01:57:21 - 1.4 @@ -69,6 +69,7 @@ import javax.servlet.http.HttpServletResponse; import org.apache.commons.chain.Catalog; import org.apache.commons.chain.Command; +import org.apache.commons.chain.Context; import org.apache.commons.chain.web.ChainServlet; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [chain] Patch for ChainResources
Quoting Jeff Caddel [EMAIL PROTECTED]: ChainListener fails to initialize correctly if you leave out either of the two optional config parameters CONFIG_CLASS_RESOURCE or CONFIG_WEB_RESOURCE. The exception occurs in ChainResources when it tries to parse the comma separated list of resources passed in to it. If the list of resources is null things go awry. This patch alters ChainResources methods to return instead of attempting to parse if the resources passed into it are null. Another way to handle it would be to alter ChainListener so that it doesn't invoke ChainResources if it detects that it's initialization parameters haven't been set. I've applied your patch ... thanks! This is a great API by the way! It's lending itself very well to getting my business logic organized. I'd be interested in any example usage patterns that you'd be willing to describe, so we can ultimately create some best practices documentation. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/dbutils/src/test/org/apache/commons/dbutils BaseTestCase.java BasicRowProcessorTest.java TestBean.java
dgraham 2003/11/08 20:30:51
Modified:dbutils/src/java/org/apache/commons/dbutils
BasicRowProcessor.java
dbutils/src/test/org/apache/commons/dbutils
BaseTestCase.java BasicRowProcessorTest.java
TestBean.java
Log:
Refactored BasicRowProcessor toBean() and toBeanList()
to use a new common createBean() method. This fixed
a bug where toBean() and toBeanList() handled SQL NULL
differently. Now the handling is consistent with
ResultSet.get* methods.
Revision ChangesPath
1.2 +99 -52
jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/BasicRowProcessor.java
Index: BasicRowProcessor.java
===
RCS file:
/home/cvs/jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/BasicRowProcessor.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- BasicRowProcessor.java2 Nov 2003 19:15:23 - 1.1
+++ BasicRowProcessor.java9 Nov 2003 04:30:50 - 1.2
@@ -89,6 +89,24 @@
public class BasicRowProcessor implements RowProcessor {
/**
+ * Set a bean's primitive properties to these defaults when SQL NULL
+ * is returned. These are the same as the defaults that ResultSet get*
+ * methods return in the event of a NULL column.
+ */
+private static final Map primitveDefaults = new HashMap();
+
+static {
+primitveDefaults.put(Integer.TYPE, new Integer(0));
+primitveDefaults.put(Short.TYPE, new Short((short) 0));
+primitveDefaults.put(Byte.TYPE, new Byte((byte) 0));
+primitveDefaults.put(Float.TYPE, new Float(0));
+primitveDefaults.put(Double.TYPE, new Double(0));
+primitveDefaults.put(Long.TYPE, new Long(0));
+primitveDefaults.put(Boolean.TYPE, Boolean.FALSE);
+primitveDefaults.put(Character.TYPE, new Character('\u'));
+}
+
+/**
* Special array index that indicates there is no bean property that
* matches a column from a ResultSet.
*/
@@ -123,15 +141,13 @@
public Object[] toArray(ResultSet rs) throws SQLException {
ResultSetMetaData meta = rs.getMetaData();
int cols = meta.getColumnCount();
-Object[] objs = new Object[cols];
+Object[] result = new Object[cols];
for (int i = 0; i cols; i++) {
-Object obj = rs.getObject(i + 1);
-
-objs[i] = rs.wasNull() ? null : obj;
+result[i] = rs.getObject(i + 1);
}
-return objs;
+return result;
}
/**
@@ -148,38 +164,31 @@
*
* li
* The property's set method parameter type matches the column
- * type. If the datatypes do not match, the setter will not be called.
+ * type. If the data types do not match, the setter will not be called.
* /li
* /ol
+ *
+ * p
+ * Primitive bean properties are set to their defaults when SQL NULL is
+ * returned from the codeResultSet/code. Numeric fields are set to 0
+ * and booleans are set to false. Object bean properties are set to
+ * codenull/code when SQL NULL is returned. This is the same behavior
+ * as the codeResultSet/code get* methods.
+ * /p
+ *
* @see org.apache.commons.dbutils.RowProcessor#toBean(java.sql.ResultSet,
java.lang.Class)
*/
public Object toBean(ResultSet rs, Class type) throws SQLException {
-Object obj = newInstance(type);
-PropertyDescriptor[] pd = propertyDescriptors(type);
+PropertyDescriptor[] props = this.propertyDescriptors(type);
ResultSetMetaData rsmd = rs.getMetaData();
-int cols = rsmd.getColumnCount();
-for (int i = 1; i = cols; i++) {
-String columnName = rsmd.getColumnName(i);
-for (int j = 0; j pd.length; j++) {
-
-if (columnName.equalsIgnoreCase(pd[j].getName())) {
-Object value = rs.getObject(i);
+int[] columnToProperty = this.mapColumnsToProperties(rsmd, props);
-if (rs.wasNull()
- pd[j].getPropertyType().isPrimitive()) {
-continue;
-}
-
-callSetter(pd[j], obj, value);
-break;
-}
-}
-}
+int cols = rsmd.getColumnCount();
-return obj;
+return this.createBean(rs, type, props, columnToProperty, cols);
}
/**
@@ -196,9 +205,18 @@
*
* li
* The property's set method parameter type matches the column
- * type. If the datatypes do not match,
cvs commit: jakarta-commons/dbutils/src/test/org/apache/commons/dbutils BaseTestCase.java BasicRowProcessorTest.java TestBean.java
dgraham 2003/11/08 20:50:46
Modified:dbutils/src/test/org/apache/commons/dbutils
BaseTestCase.java BasicRowProcessorTest.java
TestBean.java
Log:
Fixed test bug by changing property and column name
to notDate.
Revision ChangesPath
1.3 +4 -4
jakarta-commons/dbutils/src/test/org/apache/commons/dbutils/BaseTestCase.java
Index: BaseTestCase.java
===
RCS file:
/home/cvs/jakarta-commons/dbutils/src/test/org/apache/commons/dbutils/BaseTestCase.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- BaseTestCase.java 9 Nov 2003 04:30:50 - 1.2
+++ BaseTestCase.java 9 Nov 2003 04:50:46 - 1.3
@@ -97,7 +97,7 @@
integerTest,
nullObjectTest,
nullPrimitiveTest,
-wrongType };
+notDate };
/**
* The number of columns in the MockResultSet.
1.3 +5 -5
jakarta-commons/dbutils/src/test/org/apache/commons/dbutils/BasicRowProcessorTest.java
Index: BasicRowProcessorTest.java
===
RCS file:
/home/cvs/jakarta-commons/dbutils/src/test/org/apache/commons/dbutils/BasicRowProcessorTest.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- BasicRowProcessorTest.java9 Nov 2003 04:30:50 - 1.2
+++ BasicRowProcessorTest.java9 Nov 2003 04:50:46 - 1.3
@@ -117,7 +117,7 @@
assertEquals(new Integer(4), b.getIntegerTest());
assertEquals(null, b.getNullObjectTest());
assertEquals(0, b.getNullPrimitiveTest());
-assertEquals(not a date, b.getNotADate());
+assertEquals(not a date, b.getNotDate());
}
public void testToBeanList() throws SQLException {
@@ -136,7 +136,7 @@
assertEquals(new Integer(4), b.getIntegerTest());
assertEquals(null, b.getNullObjectTest());
assertEquals(0, b.getNullPrimitiveTest());
-assertEquals(not a date, b.getNotADate());
+assertEquals(not a date, b.getNotDate());
}
public void testToMap() throws SQLException {
1.3 +8 -8
jakarta-commons/dbutils/src/test/org/apache/commons/dbutils/TestBean.java
Index: TestBean.java
===
RCS file:
/home/cvs/jakarta-commons/dbutils/src/test/org/apache/commons/dbutils/TestBean.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TestBean.java 9 Nov 2003 04:30:50 - 1.2
+++ TestBean.java 9 Nov 2003 04:50:46 - 1.3
@@ -97,7 +97,7 @@
* ResultSet does not match the type of the bean property. In this case,
* a Date will be returned but the property is a String.
*/
-private String notADate = not a date;
+private String notDate = not a date;
/**
* Constructor for TestBean.
@@ -170,12 +170,12 @@
nullPrimitiveTest = i;
}
-public String getNotADate() {
-return notADate;
+public String getNotDate() {
+return notDate;
}
-public void setNotADate(String string) {
-notADate = string;
+public void setNotDate(String string) {
+notDate = string;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/dbutils/src/java/org/apache/commons/dbutils ProxyFactory.java
dgraham 2003/11/08 20:54:32
Modified:dbutils/src/java/org/apache/commons/dbutils
ProxyFactory.java
Log:
Fix createCallableStatement() return type.
Revision ChangesPath
1.3 +4 -4
jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/ProxyFactory.java
Index: ProxyFactory.java
===
RCS file:
/home/cvs/jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/ProxyFactory.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ProxyFactory.java 5 Nov 2003 00:40:43 - 1.2
+++ ProxyFactory.java 9 Nov 2003 04:54:32 - 1.3
@@ -147,7 +147,7 @@
* Creates a new proxy codeCallableStatement/code object.
* @param handler The handler that intercepts/overrides method calls.
*/
-public PreparedStatement createCallableStatement(InvocationHandler handler) {
+public CallableStatement createCallableStatement(InvocationHandler handler) {
return (CallableStatement) Proxy.newProxyInstance(
handler.getClass().getClassLoader(),
callableStatementClass,
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24352] - NLTM Proxy and basic host authorization
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=24352. 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=24352 NLTM Proxy and basic host authorization --- Additional Comments From [EMAIL PROTECTED] 2003-11-08 11:14 --- The patch against CVS HEAD is virtually identical to that for 2.0 branch. The patch also solves the problem with auto-generated headers by restricting headers cleanup to 'Cookie' headers only. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24309] - MultiThreadedHttpConnectionManager daemon Thread never GC'd
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=24309. 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=24309 MultiThreadedHttpConnectionManager daemon Thread never GC'd [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|--- |2.0 Final - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22073] - Javadocs clean-up
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=22073. 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=22073 Javadocs clean-up [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24504] - Cannot create a document that has accent characters (Latin) in it's name
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=24504. 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=24504 Cannot create a document that has accent characters (Latin) in it's name --- Additional Comments From [EMAIL PROTECTED] 2003-11-08 11:29 --- Eric, My apologies, but I do not quite understand the nature of the problem. What do you mean by 'cannot create a document'? What do you mean by a document in the first place? Request content body? Response content body? what version of HttpClient are you using and what is it you are trying to get done? As to getAsciiBytes method, as its name implies it is supposed to return ASCII characters only. So, the behaviour of the method is correct. You might want to have a look at the HttpClient character encoding guide for more details: http://jakarta.apache.org/commons/httpclient/charencodings.html I'll have no choice but to mark the report as invalid unless more information is given Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Https proxy] Impossible to connect
I am +1 on this change. I think it is well justified. Oleg On Thu, 2003-11-06 at 09:59, Ortwin Glück wrote: Roland Weber wrote: Folks, this looks like an API error to me. The protocol security should depend on the actual type of the factory passed to the constructor, not on the type of the variable it is stored in! I agree. It is a design error to use polymorphism when the only difference in the method signature is a type within the same class hierarchy. Also the two constructors have duplicate code. The attached patch takes care of the problem in CVS HEAD. Odi __ - 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]
DO NOT REPLY [Bug 24154] - Setting CONNECTION_TIMEOUT and SO_TIMEOUT on a per-method basis
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=24154. 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=24154 Setting CONNECTION_TIMEOUT and SO_TIMEOUT on a per-method basis [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Status|NEW |ASSIGNED Priority|Other |Medium Target Milestone|--- |2.1 Final - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16729] - Allow redirects between hosts and ports
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=16729. 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=16729 Allow redirects between hosts and ports --- Additional Comments From [EMAIL PROTECTED] 2003-11-08 21:43 --- Created an attachment (id=9001) Cleanup patch 1 (take 1) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16729] - Allow redirects between hosts and ports
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=16729. 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=16729 Allow redirects between hosts and ports --- Additional Comments From [EMAIL PROTECTED] 2003-11-08 21:44 --- Folks, Somehow this crucial patch got neglected recently. As I was working on resolving another bug I found a few things about HttpMethodDirector which I thought might be potentially error-prone. For instance, I found the recursive invocation of MethodExecute particularly questionable. So, I took liberty of refactoring things quite a bit. Mike, I did go quite tough on your code, and changed a lot, so please do not hesitate to point out if you find anything disagreeable. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
