You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Vincenzo Gianferrari Pini (JIRA)" <se...@james.apache.org> on 2006/07/22 13:45:14 UTC
[jira] Resolved: (JAMES-574) Annoying logging of
whitelist/blacklist nomatching as "unknown host exception thrown: listname"
if INFO is enabled
[ http://issues.apache.org/jira/browse/JAMES-574?page=all ]
Vincenzo Gianferrari Pini resolved JAMES-574.
---------------------------------------------
Resolution: Fixed
Changed the log message level to debug when match fails.
> Annoying logging of whitelist/blacklist nomatching as "unknown host exception thrown: listname" if INFO is enabled
> ------------------------------------------------------------------------------------------------------------------
>
> Key: JAMES-574
> URL: http://issues.apache.org/jira/browse/JAMES-574
> Project: James
> Issue Type: Bug
> Components: SMTPServer
> Affects Versions: 2.3.0b3, 2.3.0b2, 2.3.0b1, 2.3.0a3, 2.3.0a2, 2.3.0a1, 3.0
> Reporter: Vincenzo Gianferrari Pini
> Assigned To: Vincenzo Gianferrari Pini
> Priority: Trivial
> Fix For: 2.3.0rc1, 3.0
>
>
> When a checkDNSRBL is done, in case getLogger().isInfoEnabled() is true, both successfull and unsuccessfull matches are being logged.
> While successfull matches are useful to log as INFO, the much more frequent unsuccessfull matches are logged as "unknown host exception thrown: listname", heavily increasing the size of the log file. Such log message is useful only in DEBUG mode.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES-574 -- which version?
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
I disagree. It was a bug, though trivial. And one year ago the behaviour
was like now after the fix (at least at info log level).
And if we find a bug, even not critical, whose fix is trivial, it can
and should be applied even to RC.
I would otherwise yesterday have voted -1 to "[VOTE] James 2.3.0rc1
Release", as it's been two weeks that I said that I was going to test
this weekend in my production system.
And JAMES-515 is not a fix to a bug, simply a cleanup that could
introduce problems to existing customers, and no perceived functional
advantage.
Vincenzo
Stefano Bagnara wrote:
> Noel J. Bergman wrote:
>
>> Vincenzo Gianferrari Pini
>>
>>> Resolution: Fixed
>>> Changed the log message level to debug when match fails.
>>> Key: JAMES-574
>>> URL: http://issues.apache.org/jira/browse/JAMES-574
>>> Affects Versions: 2.3.0b3, 2.3.0b2, 2.3.0b1, 2.3.0a3, 2.3.0a2,
>>> 2.3.0a1, 3.0
>>> Fix For: 2.3.0rc1, 3.0
>>
>>
>> Uh ... we already voted on and tagged RC1, right? Are we going to
>> re-roll RC1, or update JIRA to show this in RC2?
>>
>> --- Noel
>
>
> IMO this should have not been applied to 2.3 branch.
>
> We are in RC and we should apply only fixes to critical things. This
> is not really a bug, only an annoiance.
> We should put this stuff in 2.3.1 or 2.4
>
> Otherwise we should change our current 2.3 policy, and we should have
> not used the rc tag.
>
> If we start applying similar changes I don't see why we shouldn't
> apply http://issues.apache.org/jira/browse/JAMES-515
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES-574 -- which version?
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Stefano,
I agree :-) .
Ciao,
Vincenzo
Stefano Bagnara wrote:
> Vincenzo Gianferrari Pini wrote:
>
>> I don't want this to become a religion war (by definition a matter of
>> personal views :-) ).
>
>
> -0 is not a war ;-). In fact -0 is not a valid vote on code
> modifications. Only -1 and +1 are valid for "code modification" votes
> and 3 +1 are lazy consensus. So my -0 has the same validity of a "non
> vote".
>
> There are a bunch of other committers, I'll be happy to "accept" the
> patch if it will pass the vote. I just want to be sure we follow a
> consistent procedure when working on our branches. Imo a -0 made this
> clear more than a long discussion.
>
> I'd like to put emphasis on the fact that there is no shame in having
> different opinions.
>
> My personal idean about what can be done and what can't be done in rc
> status is much less strict and I would accept this and more changes,
> but we already used a different rule in past so I think that -0 is the
> right thing at this point.
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES-574 -- which version?
Posted by Stefano Bagnara <ap...@bago.org>.
Vincenzo Gianferrari Pini wrote:
> I don't want this to become a religion war (by definition a matter of
> personal views :-) ).
-0 is not a war ;-). In fact -0 is not a valid vote on code
modifications. Only -1 and +1 are valid for "code modification" votes
and 3 +1 are lazy consensus. So my -0 has the same validity of a "non vote".
There are a bunch of other committers, I'll be happy to "accept" the
patch if it will pass the vote. I just want to be sure we follow a
consistent procedure when working on our branches. Imo a -0 made this
clear more than a long discussion.
I'd like to put emphasis on the fact that there is no shame in having
different opinions.
My personal idean about what can be done and what can't be done in rc
status is much less strict and I would accept this and more changes, but
we already used a different rule in past so I think that -0 is the right
thing at this point.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES-574 -- which version?
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
I don't want this to become a religion war (by definition a matter of
personal views :-) ).
In any case I agree that a small bug like this should not delay the
timings for releasing 2.3.0 final. Rc1 is already tagged and should be
released as is.
For me is a +1 to apply the patch in the following release, rc2 or final
or whatever may be.
If no other fix has to be applied from now, and if the rule is (I don't
know it is true) that no fix should be applied between the last rc and
the final, I won't create a case on this, and I can apply this 20 chars
patch to my own system in any case (five totally useless lines in the
log file per incoming message, doubling its size, is really annoying IMHO).
In the meantime my weekend test on my production system seems to be
going on quite well. On next Monday evening, after a real weekday of
activity, I will let you know. BTW this is why I asked Norman to wait
until Monday before releasing RC1, but he convinced me that it would
have attracted more testers ... :-) .
Vincenzo
Stefano Bagnara wrote:
> I don't agree with Vincenzo about what is a bug and what could
> introduce problems, btw this is a matter of personal views, so here is
> my vote:
>
> -1 to reroll rc1: we already have the tag and an in-progress vote/test
> (i did this once, we already agreed this was a mistake, so try to not
> repeat this).
>
> -0 to apply the patch for the next rc: i think we could live we a
> debug logged as info in experimental code (disabled by default)
>
> So I'm not vetoing it, but I'll change it to +1 if we'll find much
> more bugs in RC1 and we'll have a longer release cycle for the next
> rc/tests.
>
> Imho it does not make sense to create a new release for a log change
> and delay even if few days our rc1 release, but I'm not the one that
> prepare releases and I can't know if this will really delay things.
>
> Stefano
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES-574 -- which version?
Posted by Stefano Bagnara <ap...@bago.org>.
I don't agree with Vincenzo about what is a bug and what could introduce
problems, btw this is a matter of personal views, so here is my vote:
-1 to reroll rc1: we already have the tag and an in-progress vote/test
(i did this once, we already agreed this was a mistake, so try to not
repeat this).
-0 to apply the patch for the next rc: i think we could live we a debug
logged as info in experimental code (disabled by default)
So I'm not vetoing it, but I'll change it to +1 if we'll find much more
bugs in RC1 and we'll have a longer release cycle for the next rc/tests.
Imho it does not make sense to create a new release for a log change and
delay even if few days our rc1 release, but I'm not the one that prepare
releases and I can't know if this will really delay things.
Stefano
Norman Maurer wrote:
> I also see no problems to this in rc1.. i can reroll the release or put
> it in rc2 ..
> +1 for rc2
> +0 rc1
>
> bye
> Norman
>
> Am Samstag, den 22.07.2006, 19:55 +0200 schrieb Vincenzo Gianferrari
> Pini:
>> I disagree. It was a bug, though trivial. And one year ago the behaviour
>> was like now after the fix (at least at info log level).
>>
>> And if we find a bug, even not critical, whose fix is trivial, it can
>> and should be applied even to RC.
>>
>> I would otherwise yesterday have voted -1 to "[VOTE] James 2.3.0rc1
>> Release", as it's been two weeks that I said that I was going to test
>> this weekend in my production system.
>>
>> And JAMES-515 is not a fix to a bug, simply a cleanup that could
>> introduce problems to existing customers, and no perceived functional
>> advantage.
>>
>> Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES-574 -- which version?
Posted by Norman Maurer <nm...@byteaction.de>.
Hi guys,
Am Sonntag, den 23.07.2006, 00:13 +0200 schrieb Stefano Bagnara:
> I don't agree with Vincenzo about what is a bug and what could introduce
> problems, btw this is a matter of personal views, so here is my vote:
>
For me its not a bug anyway... its a improvment
> -1 to reroll rc1: we already have the tag and an in-progress vote/test
> (i did this once, we already agreed this was a mistake, so try to not
> repeat this).
>
> -0 to apply the patch for the next rc: i think we could live we a debug
> logged as info in experimental code (disabled by default)
Like i said i have ni problems with that.. but not so importent for me..
i can life even without the patch..
>
> So I'm not vetoing it, but I'll change it to +1 if we'll find much more
> bugs in RC1 and we'll have a longer release cycle for the next rc/tests.
>
I don't hope so ..
> Imho it does not make sense to create a new release for a log change and
> delay even if few days our rc1 release, but I'm not the one that prepare
> releases and I can't know if this will really delay things.
>
Yes true... we should release rc1 without that change and put it maybe
in the next rc or the final.. Let us see..
> Stefano
>
> Norman Maurer wrote:
> > I also see no problems to this in rc1.. i can reroll the release or put
> > it in rc2 ..
> > +1 for rc2
> > +0 rc1
> >
> > bye
> > Norman
> >
> > Am Samstag, den 22.07.2006, 19:55 +0200 schrieb Vincenzo Gianferrari
> > Pini:
> >> I disagree. It was a bug, though trivial. And one year ago the behaviour
> >> was like now after the fix (at least at info log level).
> >>
> >> And if we find a bug, even not critical, whose fix is trivial, it can
> >> and should be applied even to RC.
> >>
> >> I would otherwise yesterday have voted -1 to "[VOTE] James 2.3.0rc1
> >> Release", as it's been two weeks that I said that I was going to test
> >> this weekend in my production system.
> >>
> >> And JAMES-515 is not a fix to a bug, simply a cleanup that could
> >> introduce problems to existing customers, and no perceived functional
> >> advantage.
> >>
> >> Vincenzo
bye
Norman
Re: JAMES-574 -- which version?
Posted by Norman Maurer <nm...@byteaction.de>.
I also see no problems to this in rc1.. i can reroll the release or put
it in rc2 ..
+1 for rc2
+0 rc1
bye
Norman
Am Samstag, den 22.07.2006, 19:55 +0200 schrieb Vincenzo Gianferrari
Pini:
> I disagree. It was a bug, though trivial. And one year ago the behaviour
> was like now after the fix (at least at info log level).
>
> And if we find a bug, even not critical, whose fix is trivial, it can
> and should be applied even to RC.
>
> I would otherwise yesterday have voted -1 to "[VOTE] James 2.3.0rc1
> Release", as it's been two weeks that I said that I was going to test
> this weekend in my production system.
>
> And JAMES-515 is not a fix to a bug, simply a cleanup that could
> introduce problems to existing customers, and no perceived functional
> advantage.
>
> Vincenzo
>
> Stefano Bagnara wrote:
>
> > Noel J. Bergman wrote:
> >
> >> Vincenzo Gianferrari Pini
> >>
> >>> Resolution: Fixed
> >>> Changed the log message level to debug when match fails.
> >>> Key: JAMES-574
> >>> URL: http://issues.apache.org/jira/browse/JAMES-574
> >>> Affects Versions: 2.3.0b3, 2.3.0b2, 2.3.0b1, 2.3.0a3, 2.3.0a2,
> >>> 2.3.0a1, 3.0
> >>> Fix For: 2.3.0rc1, 3.0
> >>
> >>
> >> Uh ... we already voted on and tagged RC1, right? Are we going to
> >> re-roll RC1, or update JIRA to show this in RC2?
> >>
> >> --- Noel
> >
> >
> > IMO this should have not been applied to 2.3 branch.
> >
> > We are in RC and we should apply only fixes to critical things. This
> > is not really a bug, only an annoiance.
> > We should put this stuff in 2.3.1 or 2.4
> >
> > Otherwise we should change our current 2.3 policy, and we should have
> > not used the rc tag.
> >
> > If we start applying similar changes I don't see why we shouldn't
> > apply http://issues.apache.org/jira/browse/JAMES-515
> >
> > Stefano
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-dev-help@james.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
> !EXCUBATOR:1,44c266bc43381548542968!
Re: JAMES-574 -- which version?
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Vincenzo Gianferrari Pini
>> Resolution: Fixed
>> Changed the log message level to debug when match fails.
>> Key: JAMES-574
>> URL: http://issues.apache.org/jira/browse/JAMES-574
>> Affects Versions: 2.3.0b3, 2.3.0b2, 2.3.0b1, 2.3.0a3, 2.3.0a2, 2.3.0a1, 3.0
>> Fix For: 2.3.0rc1, 3.0
>
> Uh ... we already voted on and tagged RC1, right? Are we going to re-roll RC1, or update JIRA to show this in RC2?
>
> --- Noel
IMO this should have not been applied to 2.3 branch.
We are in RC and we should apply only fixes to critical things. This is
not really a bug, only an annoiance.
We should put this stuff in 2.3.1 or 2.4
Otherwise we should change our current 2.3 policy, and we should have
not used the rc tag.
If we start applying similar changes I don't see why we shouldn't apply
http://issues.apache.org/jira/browse/JAMES-515
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
JAMES-574 -- which version?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Vincenzo Gianferrari Pini
> Resolution: Fixed
> Changed the log message level to debug when match fails.
> Key: JAMES-574
> URL: http://issues.apache.org/jira/browse/JAMES-574
> Affects Versions: 2.3.0b3, 2.3.0b2, 2.3.0b1, 2.3.0a3, 2.3.0a2, 2.3.0a1, 3.0
> Fix For: 2.3.0rc1, 3.0
Uh ... we already voted on and tagged RC1, right? Are we going to re-roll RC1, or update JIRA to show this in RC2?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org