tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject [5.0] Commons dependencies
Date Tue, 03 Jun 2003 14:32:02 GMT
Tomcat 5.0.x, like many other major Jakarta projects, depends on a lot 
of stuff from the Commons. Most of those are in a stable state, but a 
few are either in between two stable releases, or not yet released.

Here's the list of the components which will need to be released as 
stable before Tomcat 5.0 gets stable. I'm associating a proposed "owner" 
for the component, based on past interactions with the components.

- el: Core JSP 2.0 feature; this is a critical component, and needs to 
get released simultaneaously with Tomcat 5; I think a RM is needed for 
that component [Kin-Man, Jan, Craig ?]

- modeler: Basis for Tomcat 5 JMX features, with a lot of new 
impressively efficient functionality since release 1.0; again, a 
critical component [Costin (do you have enough time to continue being 
the RM of that component ?)]

- daemon: Home of Mladen's procrun, a very promising exe wrapper for 
Java programs on Windows; this also contains a Unix wrapper for Java 
programs; the Unix wrapper could be advertised as "the" recommended 
solution to run Tomcat on 80 on Unix, and included as source with 
Tomcat's binary d/l; this component is currently in the sandbox, and 
would need to be either moved ASAP to commons proper, or be migrated to 
j-t-c (if thought to be too Tomcat specific to exist in the commons); a 
RM will be needed [Mladen, Jean-Frederic]

- dbcp: There are some BZ issues related to DBCP, so if there's a new 
DBCP release (I've seen some Struts 1.1 related activity), we'll need to 
include it [Glenn]

- fileupload: Used by the HTML manager to upload the webapp to be 
deployed; 1.0 RC 1 is soon to be released, with an API breakage 
(deprecated method removal between beta releases (TM)); 1.0 is supposed 
to occur before Struts 1.1 [Glenn]

I think that's it for now.

About the daemon Unix wrapper: there was some proprietary interfaces 
defined in there. It was agreed some time ago to use reflection instead 
of these interfaces; looking at the native code, the interfaces are 
still being used. Could that be fixed ?

Comments ?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message