Re: Proposal: New Committer - Marc Saegesser

On Wed, 20 Feb 2002, dIon Gillard wrote: > I'd like to propose Marc Saegesser as a committer on HttpClient. Mark > has posted some great functional patches for HttpClient in the last week > and is an active user with great ideas for taking it forward. > > Also, most of the 'usual' HttpClient c

Re: Proposal: New Committer - Marc Saegesser

On Wed, 20 Feb 2002, dIon Gillard wrote: > Date: Wed, 20 Feb 2002 17:39:07 +1100 > From: dIon Gillard <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > Subject: Proposal: New Committer - Marc Saegesser

Re: Proposal: New Committer - Marc Saegesser

> I'd like to propose Marc Saegesser as a committer on HttpClient. Mark > has posted some great functional patches for HttpClient in the last week > and is an active user with great ideas for taking it forward. > > Also, most of the 'usual' HttpClient committers are also busy with other > proj

Proposal: New Committer - Marc Saegesser

I'd like to propose Marc Saegesser as a committer on HttpClient. Mark has posted some great functional patches for HttpClient in the last week and is an active user with great ideas for taking it forward. Also, most of the 'usual' HttpClient committers are also busy with other projects, so Mar

RE: [VOTE] Logging 1.0 Release (again)

> -Original Message- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 19, 2002 8:27 PM > To: Jakarta Commons Developers List > Subject: RE: [VOTE] Logging 1.0 Release (again) > > > > > On Tue, 19 Feb 2002, Steve Downey wrote: > > > Date: Tue, 19 Feb 2

RE: Collections 2.0? (Collections 1.1 RIP)

[EMAIL PROTECTED] wrote: > > > I suppose it wasn't explicitly stated though. But I agree here. > > > Collections should be based on the 1.2 Collection APIs. > > > > Agreed - I don't think it makes much sense to have 1.1 > support for a library > > based on Java 2 collections. (Though with some An

Re: Collections 2.0? (Collections 1.1 RIP)

> > I suppose it wasn't explicitly stated though. But I agree here. > > Collections should be based on the 1.2 Collection APIs. > > Agreed - I don't think it makes much sense to have 1.1 support for a library > based on Java 2 collections. (Though with some Ant search & replace hacks we > could b

RE: [collections] unclear contract for LRUMap.setMaximumSize(int)

James Strachan wrote: > > - Original Message - > From: "Morgan Delagrange" <[EMAIL PROTECTED]> > > Hi all, > > > > This is strange. What is the proper behaviour of the > > LRUMap.setMaximumSize(int) method, do you think? One would > assume that, > if > > the current LRUMap has more ke

Re: [collections] unclear contract for LRUMap.setMaximumSize(int)

- Original Message - From: "Morgan Delagrange" <[EMAIL PROTECTED]> > Hi all, > > This is strange. What is the proper behaviour of the > LRUMap.setMaximumSize(int) method, do you think? One would assume that, if > the current LRUMap has more keys than the new maximum size, the LRUMap wou

Re: Collections 2.0? (Collections 1.1 RIP)

From: "Michael A. Smith" <[EMAIL PROTECTED]> > Someone recently brought up comparators. That would probably be a good > addition. Agreed - some good common comparators sound good. > There's probably others as well -- haven't seen a splay-tree > implementation yet, but does anyone actually use t

Re: [VOTE] Logging 1.0 Release (again)

> - Cut Here - > I vote as follows on the proposed Commons Logging 1.0 Release: > [X] +1 - I support this release and am willing to help > [ ] +0 - I support this release, but cannot assist > [ ] -0 - I don't support this release > [ ] -1 - I vote against this release (requires valid *tech

RE: [IO] proposal to make the following changes to FileUtils

Will do. Thanks. Steven Caswell [EMAIL PROTECTED] a.k.a Mungo Knotwise of Michel Delving "One ring to rule them all, one ring to find them..." -Original Message- From: Scott Sanders [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 19, 2002 6:54 PM To: Jakarta Commons Developers Lis

RE: [VOTE] Logging 1.0 Release (again)

-Original Message- From: Scott Sanders [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 19, 2002 5:11 PM To: Jakarta Commons Developers List Subject: RE: [VOTE] Logging 1.0 Release (again) - Cut Here - I vote as follows on the proposed Commons Logging 1.0 Release: [x] +1

cvs commit: jakarta-commons/xdocs betwixt.xml messenger.xml

jstrachan02/02/19 17:59:32 Modified:docs betwixt.html messenger.html xdocsbetwixt.xml messenger.xml Removed: docs/messenger/api allclasses-frame.html index-all.html index.html overview-frame.html overview-summa

Re: [VOTE] Logging 1.0 Release (again)

+0 > -- > To unsubscribe, e-mail: > For additional commands, e-mail: -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: For additional commands, e-mail:

RE: [VOTE] Logging 1.0 Release (again)

t; * Adding a log(Level, String) method to the Log interface. > > * Adding mechanisms to configure loggers through the Log interface. > > > > Going down the path of implementing any of these in the > > commons logging > > wrapper would violate the principle on which

RE: [VOTE] Logging 1.0 Release (again)

multiple underlying > wrapper implementations. > > Therefore, I propose the current code base (as currently > available in the > 20020219 nightly build) to be released as Commons Logging 1.0. I > volunteer to act as release manager, and will follow the > standard Commons &

RE: [VOTE] Logging 1.0 Release (again)

- Cut Here - I vote as follows on the proposed Commons Logging 1.0 Release: [x] +1 - I support this release and am willing to help [ ] +0 - I support this release, but cannot assist [ ] -0 - I don't support this release [ ] -1 - I vote against this release (requires valid *technical

Re: [VOTE] Logging 1.0 Release (again)

On Tue, 19 Feb 2002, Craig R. McClanahan wrote: > * Adding mechanisms to configure loggers through the Log interface. No need for that - passing attributes to the factory should be enough for most common needs. In time we'll need to document whatever attribute names are used for different fac

Re: [VOTE] Logging 1.0 Release (again)

on which this API was designed, of > being a very thin facade over the facilities of multiple underlying > wrapper implementations. > > Therefore, I propose the current code base (as currently available in the > 20020219 nightly build) to be released as Commons Logging 1.0.

Re: [VOTE] Logging 1.0 Release (again)

> - Cut Here - > I vote as follows on the proposed Commons Logging 1.0 Release: > [x] +1 - I support this release and am willing to help > [ ] +0 - I support this release, but cannot assist > [ ] -0 - I don't support this release > [ ] -1 - I vote against this release (requires valid *tech

[VOTE] Logging 1.0 Release (again)

he principle on which this API was designed, of being a very thin facade over the facilities of multiple underlying wrapper implementations. Therefore, I propose the current code base (as currently available in the 20020219 nightly build) to be released as Commons Logging 1.0. I volunteer to act as

cvs commit: jakarta-commons-sandbox/jelly build.xml

geirm 02/02/19 16:21:12 Modified:jellybuild.xml Log: to be consistent Revision ChangesPath 1.7 +2 -2 jakarta-commons-sandbox/jelly/build.xml Index: build.xml === RCS file: /home/cvs

Confusion over commons logging

Someone posted to the Velocity list asking about logging, suggesting that he was confused because he really liked log4j, Velocity uses logkit by default (and of course can use log4j), and as the user put it "Then there is the commons logger". Does anyone mind if I put up a page on the commons we

Re: Collections 2.0? (Collections 1.1 RIP)

- Original Message - From: <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, February 19, 2002 11:17 AM Subject: Re: Collections 2.0? (Collections 1.1 RIP) > > While my question is for new functionality I'd like to get in before a > 2.0 release

Re: [AltRMI] Event Notifier

Vinay, >Anyways on another page , I feel it would be good >exercise to have the Event Notifier pattern working >over AltRMI transport, >something along the lines of the same pattern >over RMI .(ref >http://www.javareport.com/html/from_pages/oldarticles.asp?ArticleID=132 > >) > >This would nec

[AltRMI] Event Notifier

Hi, > Sorry dude, I turned the bat files into ant targets > : > >ant -buildfile tests2.xml procon-serve >ant -buildfile tests2.xml procon-client Dont be sorry ! . I should be . Ant targets are more a consistent means to work with. Anyways on another page , I feel it would be good exerci

Re: [httpclient] Timeouts ?

You could use JDK 1.4 and then patch your local copy of HTTP Client. That's what I did. Otis On Tue, 19 February 2002, Donie Kelly wrote: > > Hi all > > I need the http client to timeout after 5 seconds of a connection attempt. > How do I set this timeout. I have looked in all the JavaDocs I

Re: [daemon] JSR 96 support?

> > > BTW have you seen the Java Service Wrapper? > > > > > > http://wrapper.sourceforge.net/doc/english/index.html > > > > > > I've not looked too deep yet at all 3 of these but its on my radar - I'd > > be > > > interested in any comments folk have on the pros & cons of the above. > > > > The Ja

Re: [daemon] JSR 96 support?

From: "Remy Maucherat" <[EMAIL PROTECTED]> > > I just spotted the daemon project in CVS and wondered if there was any > > intention of implementing JSR 96 > > > > http://jcp.org/jsr/detail/96.jsp > > > > Also I wonder if JSR 96 will release an open source reference > > implementation? > > I was, b

Re: Collections 2.0? (Collections 1.1 RIP)

While my question is for new functionality I'd like to get in before a 2.0 release, Berin's raises a good point. Is there a whole list of 'things that ought to be done' we could compile for Collections? Then target 2.0 with an aim to clear those up? Hell, Collections is pretty small, we could go

Re: [daemon] JSR 96 support?

> I just spotted the daemon project in CVS and wondered if there was any > intention of implementing JSR 96 > > http://jcp.org/jsr/detail/96.jsp > > Also I wonder if JSR 96 will release an open source reference > implementation? I was, but now it's not. But of course, we could still decide later

cvs commit: jakarta-commons-sandbox/betwixt PROPOSAL.html STATUS.html

jstrachan02/02/19 09:14:24 Modified:betwixt PROPOSAL.html STATUS.html Log: Updated the TODO list, removing completed tasks Revision ChangesPath 1.4 +1 -1 jakarta-commons-sandbox/betwixt/PROPOSAL.html Index: PROPOSAL.html ===

cvs commit: jakarta-commons/xdocs/stylesheets project.xml

jstrachan02/02/19 09:02:52 Modified:docs beanutils.html charter.html collections.html commons.html components.html contributors.html digester.html directory.html index.html license.html messenger.html releases.h

RE: HttpClient

Thanks, Amazing how many times I searched the archives - I was obviously looking for the wrong thing :-) Kevin Jones Developmentor www.develop.com > -Original Message- > From: Waldhoff, Rodney [mailto:[EMAIL PROTECTED]] > Sent: 19 February 2002 14:50 > To: 'Kevin Jones '; 'Jakarta Com

Re: Collections 2.0? (Collections 1.1 RIP)

[EMAIL PROTECTED] wrote: > Where should comparators go by the way? > > in > > collections.compare > collections.comparator > collections > comparator > compare If you upgrade to Collections 2.0, then you might as well upgrade the PriorityQueue interface and implementing classes to work with Ob

Re: Collections 2.0? (Collections 1.1 RIP)

Where should comparators go by the way? in collections.compare collections.comparator collections comparator compare ??? I had a couple of simple ones I wanted to commit and a more complex one that might take a fair bit more effort to merge with the Jakarta Bean-reflection system. (I have my o

Collections 2.0? (Collections 1.1 RIP)

It looks like the next Collections release may have to be a Major Release after all. Last night, I realized that if SequencedHashMap no longer extends from HashMap, then you will not be able to cast the new LRUMap to that class. So our options seem to be: 1. Keep HashMap as the superclass of

Re: [daemon] JSR 96 support?

James Strachan wrote: > > I just spotted the daemon project in CVS and wondered if there was any > intention of implementing JSR 96 yep but it changes. No because: http://marc.theaimsgroup.com/?l=tomcat-dev&m=101406076431158&w=2 > > http://jcp.org/jsr/detail/96.jsp > > Also I wonder if JSR 96

[httpclient] Timeouts ?

Hi all I need the http client to timeout after 5 seconds of a connection attempt. How do I set this timeout. I have looked in all the JavaDocs I think but I can't see anywhere to set a timeout... Donie -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: [pool] Examples ?

On Tue, 19 Feb 2002, Donie Kelly wrote: > Date: Tue, 19 Feb 2002 15:39:26 - > From: Donie Kelly <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > To: 'Jakarta Commons Developers List' <[EMAIL PROTECTED]> > Subject: [pool] Examples ? > > Hi all > > Are the

[httpclient] More HttpMultiClient patches - initial strict mode stuff

The attached are three patches that update my previous patches for the HttpMultiClient stuff. HttpMethodBase.java - Fixes a bug I created when I tried to fix the broken handling of a 100 status codes. I had this working correctly once, but due to sever fumble fingered-ness I trashed it. When I

[daemon] JSR 96 support?

I just spotted the daemon project in CVS and wondered if there was any intention of implementing JSR 96 http://jcp.org/jsr/detail/96.jsp Also I wonder if JSR 96 will release an open source reference implementation? BTW have you seen the Java Service Wrapper? http://wrapper.sourceforge.net/doc/

[pool] Examples ?

Hi all Are there any examples of how to use the object pool which are useful. Are these classes stable enough for production use yet? Thanks Donie -- To unsubscribe, e-mail: For additional commands, e-mail:

cvs commit: jakarta-commons/latka/src/java/org/apache/commons/latka/xml SuiteHandler.java

dion02/02/18 21:11:40 Modified:latka/src/java/org/apache/commons/latka/xml SuiteHandler.java Log: no message Revision ChangesPath 1.22 +2 -1 jakarta-commons/latka/src/java/org/apache/commons/latka/xml/SuiteHandler.java Index: S

cvs commit: jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/beanshell TestBeanShellEL.java

jstrachan02/02/19 07:40:58 Modified:jellybuild.properties.sample jelly/src/java/org/apache/commons/jelly Jelly.java jelly/src/java/org/apache/commons/jelly/expression/beanshell BeanShellExpression.java jelly/src/ja

[betwixt] customising the XML output is now working

I've just committed more changes to betwixt which support an XML descriptor which can be used to customize the XML output of specific types of beans. I've tried to allow the XML descriptor document to be small and brief - specifying only the things that need to be changed rather than repeating inf

cvs commit: jakarta-commons-sandbox/betwixt/src/test/org/apache/commons/digester/rss Image.betwixt Channel.betwixt

jstrachan02/02/19 07:31:30 Modified:betwixt build.xml betwixt/src/java/org/apache/commons/betwixt XMLIntrospector.java betwixt/src/java/org/apache/commons/betwixt/digester AddDefaultsRule.java AttributeRule.j

RE: HttpClient

I think the thread at http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg02313.html discusses this in some depth. -Original Message- From: Kevin Jones To: Jakarta Commons Developers List Sent: 2/19/02 1:32 AM Subject: HttpClient Folks, Not sure if this is the best place to a