tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <felix.schumac...@internetallee.de>
Subject Re: svn commit: r1042786 - in /tomcat/trunk/java/org/apache: catalina/core/ catalina/loader/ tomcat/util/threads/
Date Tue, 07 Dec 2010 12:29:36 GMT
Am Montag, den 06.12.2010, 21:22 +0000 schrieb Mark Thomas:
> On 06/12/2010 20:49, slaurent@apache.org wrote:
> > Author: slaurent
> > Date: Mon Dec  6 20:49:14 2010
> > New Revision: 1042786
> > 
> > URL: http://svn.apache.org/viewvc?rev=1042786&view=rev
> 
> 
> > @@ -63,7 +72,7 @@ public class ThreadLocalLeakPreventionLi
> >          try {
> >              Lifecycle lifecycle = event.getLifecycle();
> >              if (Lifecycle.AFTER_START_EVENT.equals(event.getType())
> > -                    && lifecycle instanceof Server) {
> > +                && lifecycle instanceof Server) {
> >                  // when the server starts, we register ourself as listener for
> >                  // all context
> >                  // as well as container event listener so that we know when new
> 
> That indenting is now misleading (it was fine before) and the operator
> is still at the beginning of the line.
I just made a quick lookup for usage of (&&) operator at the end of line
versus (&&) operator at the beginning of the next line. It seems that
usage has changed between tomcat 6 and trunk.

In tomcat6.x it is

 > egrep -r "&&\s*$" * | wc -l # && at the end of line
 217
 > egrep -r "^\s*&&" * | wc -l # && at front of line
 228

that is slightly in favor of operator after line wrapping.

In tomcat.trunk it is now

 > egrep -r "&&\s*$" * | wc -l # && at the end of line
 279
 > egrep -r "^\s*&&" * | wc -l # && at front of line
 264

Which is favors operator before line wrapping. 

Java coding conventions and eclipse coding conventions both prefer
operator after line wrapping.

So is operator after line wrapping really a tomcat standard?

> 
> 
> > -            log.error("Exception processing event " + event, e);
> > +            String msg =
> > +                sm.getString(
> > +                    "threadLocalLeakPreventionListener.lifecycleEvent.error",
> > +                    event);
> > +            log.error(msg, e);
> 
> More auto formatting "helpfulness" by the look of it. No reason for
> String msg = sm.getString(
> not to be on one line.
It would probably break the 80 character limits :)
> 
> If we can pull some Eclipse settings together to help folks with this
> that would be great.
That would be great, if we knew what the conventions were.
http://tomcat.apache.org/getinvolved.html only mentions four
conventions.

> 
> Mark
Bye
 Felix
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message