Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <40C9E2EC.1000206@apache.org>
Date: Fri, 11 Jun 2004 18:50:52 +0200
From: Remy Maucherat <remm@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7) Gecko/20040608
MIME-Version: 1.0
To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
Subject: [5.next] Summary
References: <CIEPIAPFGBKPEBHPGDJJOEGPGMAA.devlists@hanik.com>
 <40B9EDC6.3070002@apache.org>
In-Reply-To: <40B9EDC6.3070002@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

- Move to concrete classes for request/response, and remove all of the
RTTI done in Catalina's pipeline
- Use Tomcat 4.0 beta valve pattern
- Redo logging using commons-logging, and remove Logger
- "Fork" commons-digester, to remove what we don't need (many fancy 
features provided by beanutils, and in the process remove dependencies 
on beanutils and collections)
- Attempt to redo a bit the deployer:
   * remove the CL code which is there to avoid JAR locking (or at least
allow disabling this feature for non-Windows OSes)
   * move processing of context.xml to ContextConfig (at the expense of
being able to specify the context class, which will move to an attribute
on the Host), as I realize it is important to get context level
configurability without adding too much complexity in the embedding
application
- Use the webapp CL as the main CL (without the locking tricks it is 
likely faster than the regular CL)
- And the ongoing: allow all config/management through JMX (actually, we
could consider going to a JMX config format)
- Use any means necessary (hehe) so that Filip refactors the clutering
module, and extend the regular Catalina objects, for easier maintenance
- Remove anything useless (spring cleaning time), such as configuration
options, container listeners (to be replaced with JMX notifications 
where it matters), etc
- Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX 
and JMX remote, etc)

Overall, the throughtput of Tomcat should go up about 5-10% with those 
changes, as most significant optimizations are already done.

I don't think any of these items will take too long to implement. I'm 
away next week, so I'll start the week after.
Some of this could eventually be backported to 5.0.x :)

R�my


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