How Tomcat Works ...

[cm...@acedsl.com]

 I recently finished reading the book and found it a little bit nonsensical 
since it deals mostly with TC 4.0. Anyway, here are a couple of other things I 
noticed 
 
 On page 142 listing 7.7 there is a piece of 'good-looking', but, functionally 
speaking, really putrid code that made me wondered if it was true code or 
deprecated one. 
 
 Inside of 
 jakarta-tomcat-5.5.9-src/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/AccessLogValve.java 
 
 I found a very similar code to the one on the book. 
 
    /** 
     * Log the specified message to the log file, switching files if the date 
     * has changed since the previous log call. 
     * 
     * @param message Message to be logged 
     * @param date the current Date object (so this method doesn't need to 
     *        create a new one) 
     */ 
    public void log(String message, Date date) { 
 
        if (rotatable){ 
            // Only do a logfile switch check once a second, max. 
            long systime = System.currentTimeMillis(); 
            if ((systime - rotationLastChecked) > 1000) { 
 
                // We need a new currentDate 
                currentDate = new Date(systime); 
                rotationLastChecked = systime; 
 
                // Check for a change of date 
                String tsDate = dateFormatter.format(currentDate); 
 
                // If the date has changed, switch log files 
                if (!dateStamp.equals(tsDate)) { 
                    synchronized (this) { 
                        if (!dateStamp.equals(tsDate)) { 
                            close(); 
                            dateStamp = tsDate; 
                            open(); 
                        } 
                    } 
                } 
 
            } 
        } 
 
        // Log this message 
        if (writer != null) { 
            writer.println(message); 
        } 
 
    } 
 
// __ Here is the outline/some pseudo code that is more flexible regarding 
when do you want to 'cut' the log files (size checks can be easily implemented 
as well) and doesn't do any String comparisons and stuff 
 
/* 
 XML Log descriptor file would look like 
 . UGT time should be used in servers 
 . military time in XM descriptor for 'tf' time frames 
 . a day has 60*60*24 seconds a week *= 7, so an int is safe to carry values 
and diffs 
 . defintion should be defined within weeks for them to have all the same 
number of days 
 . ix_dr: index of days range 
 . dr: days range (could be "0" or range "2-4") 
 . ix_tf: index of time frame 
 . hrs: hours (could be given as hh:mm:ss) 
 . minimal time consider to run through logic is one second 
 
 <ELog Path="./" IsBranchTrough="true" prefx="eLog" suffx=".log"> 
  <logdays ix_dr="0" dr="0"><!-- definition for SUnday --> 
   <tf ix_tf="0" hrs="10"><!-- SUnday from 0 to 10 AM --> 
   <tf ix_tf="1" hrs="14"><!-- SUnday from 10+ to 24 AM --> 
  </logdays> 
  <logdays ix_dr="1" dr="1-5"><!-- definition for Monday through Friday --> 
   <tf ix_tf="0" hrs="7:30"><!-- Mo-Fr from 0 to 7:30 AM  --> 
   <tf ix_tf="1" hrs="7"><!-- Mo-Fr from 7:30+ AM to 0 to 2:30 PM --> 
   <tf ix_tf="2" hrs="4"><!-- Mo-Fr from 2:30+ PM to 0 to 6:30 PM --> 
. . .  
  </logdays> 
. . .  
 </ELog>  
*/ 
 
 
// __ OUTLINE OF/PSEUDO CODE 
class ELogDemo00{ 
 private String aPath;                // Root Path Directory for logging 
 private String aPrefx;               // Prefix 
 private String aPrefx;               // Suffix 
 private boolean IsBranchTrough; 
// __   
 private int[] iWDs;                  // Week Days  
 private int[][] iWDsTmSktxn;         // Week Days Time Sections 
// __   
 private int iIxCurDay;               // Index Of Current Day 
 private int iIxCurTmFrm;             // Index Of Current Time Frame  
 private long lLstCut;                // Last Cut 
// __  
 ELogDemo00(){ 
// __ read in XML Log descriptor file via JAXB to extract ELog attributes 
// __ sanitcy checks, then set the run-time fixed values 
  this.aPath = aPath; 
  this.aPath = aPrefx; 
  this.aPath = aPrefx; 
  this.IsBranchTrough = IsBranchTrough; 
// __ setting now 'logic-branching' values 
  long lNow = System.currentTimeMillis(); 
  iWDs = new int[]{0, 0, 0, 0, 0, 0, 0}; // default for all days the same 
// __ reading in values from XML file and doing checks ... 
  iWDsTmSktxn = new int[<NO logdays defs>][<NO time frames defs>]; 
// __  
  this.iIxCurDay = ._(lNow);    // Index Of Current Day Calendar Class ... 
  this.iIxCurTmFrm =  ._(lNow); // Index Of Current Time Frame depending on 
day and time right now  
  this.lLstCut = ._(lNow);      // value in seconds of last cut 
// __  
 } 
// __ passing the last update time from the session would be better 
 public boolean log(long lTimeStamp, String a2Log){ 
  int iSecs = ((int)(lTimeStamp - lLstCut)); iSecs =/1000; 
  if(iSecs > iWDsTmSktxn[iWDs[iIxCurDay]][iIxCurTmFrm]){ reset(); } 
  _.write(lTimeStamp, a2Log); 
 } 
// __ only stranded requests need a System.currentTimeMillis() call 
 public boolean log(String a2Log){ return(log(System.currentTimeMillis(), 
a2Log)); } 
  
// __ 
 private boolean synchronized reset(){ 
  boolean Is = true; 
  if(iIxCurTmFrm < (iWDsTmSktxn[iIxCurDay].length - 1)){ 
// __ if within the same day just index next time frame definition 
   lLstCut += (long)iWDsTmSktxn[iIxCurDay][iIxCurTmFrm];  
   ++iIxCurTmFrm; 
  } 
  else{ 
// __ next day  
   lLstCut = 0; 
   iIxCurTmFrm = 0; 
   if(iIxCurDay < (iWDsTmSktxn.length - 1)){ ++iIxCurDay; } 
   else{ 
// __ Sunday wiedermal    
    iIxCurDay = 0; 
   }  
  } 
// __ 
  if(IsBranchTrough){ Is = mkdir(); } 
// __ 
  return(Is);  
 } 
}  
 
// __  
 I also noticed a lot of code sections that were a little 'scary' to me (e.g., 
check out page 221) There are two types of coders those that dive head first 
into the swimming pool without first checking if it is full of water (and the 
depth of it!!!) and those that do the check first and only jumped in safely. I 
like very much the idea of coding around 'assertions'. 
 The principle of having one and only one 'return' statement out of a method I 
find very useful and even logical and nicely looking. 
 
 Designers and Javascript people code like this. I wonder what are the reasons 
for this coding style? 
 
 public ServletContext getServletContext(){ 
  if(parent = null) return(null); 
  else if(! (parent instanceof Context)) return(null); 
  else{ return(((Context)parent).getServletContext()); } 
 }  
 
 when this would express the same more clearly (I would say) 
 
 public ServletContext getServletContext(){ 
  Context Ctxt = null; 
// __ 
  if((parent != null) && (parent instanceof Context)){ 
    Ctxt = ((Context)parent).getServletContext()); 
  } 
// __ 
  return(Ctxt); 
 }  
 
 Thanks 
 Albretch  
 
 

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