tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Enhancement review process?
Date Wed, 26 Oct 2011 19:40:28 GMT
On 26/10/2011 20:24, Francis Galiegue wrote:
> On Wed, Oct 26, 2011 at 21:17, Mark Thomas <> wrote:
>> On 26/10/2011 20:07, Francis Galiegue wrote:
>>> Hello,
>>> It has been now three weeks since I opened this enhancement request:
>>> I am confident enough with this patch that I actually use it instead
>>> of the existing RemoteAddrValve (since my implementation doesn't get
>>> confused by ::1 just to cite an example), but it has now been ten days
>>> and I haven't had a single comment on things to improve etc. How are
>>> enhancement requests reviewed?
>> Requests are reviewed as committers have the time and interest in the
>> features being implemented.
>> Your own comments on that bug seem to indicate that the patch has issues
>> with logging and exception handling. As soon as I saw that, the issue
>> went to the bottom of my todo list until the issues were fixed (or at
>> least understood).
> Well, to the best of my efforts, I couldn't get errors to be logged at
> all, which is why I was asking for guidance... Yes, guidance. I wasn't
> trying to sound alarming or anything, I was just being honest.
> So, at the very least, can you tell me how to achieve that?

Right now, no. I have other stuff I am working on. Will I get around to
looking at this filter? Eventually. When will that be? I simply can't
tell you. There is a good chance one of the other committers will get
there before me.

> This is
> what I was asking, and I kind of expected "go see this and that source
> file"... I didn't know such a comment would just make me as desirable
> as the pest...

Different committers will take a different view of things. Right now I'm
not sufficiently interested in that patch to investigate why there
appears to be a problem

>> You may also want to look at my commit from earlier today regarding
>> handling of errors in security concious filters and valves.
> Which, BTW, contains:
> +     * @return <code>true</true> if a problem should trigger the
> failure of this



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message