RE: Ideas for future versions of Tomcat (a bit controversial mayb e)?

[GOMEZ Henri <hg...@slib.fr>]

Good stuff Chris.

I forwarded to tomcat-dev, where evolutions of Tomcat
are discussed...

-
Henri Gomez                 ___[_]____
EMAIL : hgomez@slib.fr        (. .)                     
PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-----Original Message-----
>From: chris brown [mailto:dev@reflexe.fr]
>Sent: Monday, October 01, 2001 10:54 AM
>To: tomcat-user@jakarta.apache.org
>Subject: Ideas for future versions of Tomcat (a bit controversial
>maybe)?
>
>
>Hello,
>
>I've been trying out JDK 1.4 quite a lot, and like it a lot!  I was
>wondering, given that Tomcat is a "reference implementation" of the
>Servlet/JSP APIs, if it would be a good idea to become a very 
>good example
>of certain new APIs as well.
>
>I've suggested a while back that the "New scalable I/O" 
>channels could be
>used to boost performance.  Since then, I've seen other 
>opportunities for
>increasing effeciency, simplifying code, etc.  For example, instead of
>maintaining and downloading APIs for logging, it might be 
>better to depend
>upon the newer logging APIs.  The same thing could be said of certain
>example applications (such as making Struts use the 
>java.util.regex package
>instead of an external regular expression package -- but then, 
>that's going
>a bit OT as there's a list for Struts too...!).  Perhaps also the
>configuration could be stored using the preferences API, but I 
>don't see so
>many benefits with a change of this type.
>
>Obviously, this would limit the accessibility of any such 
>future version
>Tomcat to users of JDK 1.4, but I don't think that's a major 
>problem in the
>majority of deployment situations (I'm guessing here, but I 
>suspect it's
>quite likely to be true).  Nevertheless, I think it would be a 
>good step
>forward.
>
>-Chris
>

followsoftlinks

[Bob Kersten <bo...@fellownet.org>]

Hi,

I've installed Tomcat on FreeBSD using Apache to serve the static HTML
files and it seems to work all fine. I've replaced the directory ROOT in
the /webapps/ directory with a softlink to the Apache's root dir and that
also seems to work. I have to create a contect for each directory in this
root directory in order for the WEB-INF directory to be recognized by
Tomcat and added to the tomcat-apache.conf. Isn't there a directive such
as "followsymlinks" in apache so that Tomcat searches the entire path in
the rootdir for directorys and WEB-INF stuff?

Thnx in advance,
 Bob.

Re: Ideas for future versions of Tomcat (a bit controversial maybe)?

[chris brown <de...@reflexe.fr>]

Thanks.

I'm aware of the tomcat-dev list, but posted it into the user list as such a
change would have a big impact on users.  Should get a wider range of
comments and ideas this way...

-Chris

----- Original Message -----
From: "GOMEZ Henri" <hg...@slib.fr>
To: <to...@jakarta.apache.org>
Sent: Monday, October 01, 2001 11:03 AM
Subject: RE: Ideas for future versions of Tomcat (a bit controversial
maybe)?


> Good stuff Chris.
>
> I forwarded to tomcat-dev, where evolutions of Tomcat
> are discussed...
>
> -
> Henri Gomez                 ___[_]____
> EMAIL : hgomez@slib.fr        (. .)
> PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>
>
>
> >-----Original Message-----
> >From: chris brown [mailto:dev@reflexe.fr]
> >Sent: Monday, October 01, 2001 10:54 AM
> >To: tomcat-user@jakarta.apache.org
> >Subject: Ideas for future versions of Tomcat (a bit controversial
> >maybe)?
> >
> >
> >Hello,
> >
> >I've been trying out JDK 1.4 quite a lot, and like it a lot!  I was
> >wondering, given that Tomcat is a "reference implementation" of the
> >Servlet/JSP APIs, if it would be a good idea to become a very
> >good example
> >of certain new APIs as well.
> >
> >I've suggested a while back that the "New scalable I/O"
> >channels could be
> >used to boost performance.  Since then, I've seen other
> >opportunities for
> >increasing effeciency, simplifying code, etc.  For example, instead of
> >maintaining and downloading APIs for logging, it might be
> >better to depend
> >upon the newer logging APIs.  The same thing could be said of certain
> >example applications (such as making Struts use the
> >java.util.regex package
> >instead of an external regular expression package -- but then,
> >that's going
> >a bit OT as there's a list for Struts too...!).  Perhaps also the
> >configuration could be stored using the preferences API, but I
> >don't see so
> >many benefits with a change of this type.
> >
> >Obviously, this would limit the accessibility of any such
> >future version
> >Tomcat to users of JDK 1.4, but I don't think that's a major
> >problem in the
> >majority of deployment situations (I'm guessing here, but I
> >suspect it's
> >quite likely to be true).  Nevertheless, I think it would be a
> >good step
> >forward.
> >
> >-Chris
> >