Remy Maucherat <[EMAIL PROTECTED]> wrote:
I feel like starting working on the possible new codebase for Tomcat,
now that Tomcat 5 is more or less stabilized. I have a few obvious
items, but while a lot could be done to make the code more modern, it
wouldn't make Tomcat actually run better, so I favor changing things
only if it brings something very tangible.
Note: This time, I favor changing the API, as with TC 5, I think we got
as far as we could without.
Some of my first items would be:
- refactor the request and response API using concrete classes
(CoyoteRequest and CoyoteResponse) rather than interfaces, in order to
simplify the code and lower the amount of RTTI and casts
- the current valve design mirrors the filters, but is actually
different in what it can do (now that filters can work in request
dispatchers), so I don't see the point of using the same pattern
anymore; using the model from Tomcat pre-4.0 (yes, I know, it's old ;) )
would lower the number method calls and reduce significantly the stack trace
- more JMX, such as redoing the notification model (questionable, since
the gain isn't too evident)
- (definitely) flexible configuration persistence (instead of the hack
that is currently used ;) )
- I like the nested containers, and I think the server.xml structure is
ok: I don't quite see how to simplify that without taking away from the
functionality (Craig deserves some credit for the design, which aged
rather well)
- no non blocking IO for me, but introducing blocking NIO could be good
Have you looked at EmberIO for this? It might be possible to use it in a way that
doesn't break compliance. I started to look at it and thought it might be feasible.
Not sure yet, since I don't understand the code well.
peter
---------------------------------
Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2'
