Does this only occur when connecting directly to Tomcat or is it also an
issue when going through Apache and mod_jk?
Richard Mixon wrote:
OK - yes, it was lack of sleep that was causing the problem to not appear, I
was starting Tomcat 5.5.9 instead of 5.5.12, sorry :(
The problem is still
I'm wondering whether any issue that exists is Tomcat-wide or specific
to the HTTP connector (or to the new AJP-based connectors for that matter).
To unsubscribe, e-mail: [EMAIL
How does one enable 1.5 source features in post 5.5.9 Tomcats?
I know how you can do it with the latest 5.0 sources (i.e. with Ant JSP
compilation) but I'm still at 5.5.9 and wondering how this is controlled
Nikola Milutinovic wrote:
requests to *.jsp counterparts.
That seems cleanest in that you don't have to retrain IDE's or anything
else to treate .asp as .jsp.
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Don't use isapi_redirector2 -- development on it has ceased and it is
Instead use the latest isapi_redirect.
charles doweary wrote:
From: charles doweary [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Tomcat 5.5 and IIS 6.0 connecter problem.
The servlet spec says this data is local to a given JVM.
I suppose a servlet engine could expand beyond the spec, but I'd be
surprised if Tomcat did here.
Joakim Ahlén wrote:
We have a cluster of two tomcat 5.5.9-machines using session replication.
However, we also have data in application
really good case for a logout is where you have a shared
computer with many different users coming and going -- and all using a
single guest account on the client itself rather than separate
logins. In this case a logoff button that closed down the browser
would not be a half bad idea :-)
P.S. Freeing one's *session* on leaving works with any type of
authentication and makes sense in many cases -- it's just harder to
communicate this concept to the user...
Jess Holle wrote:
In most applications this is one of those *perceived* problems that
corporate users get uptight about
Considering there are a number of issues with it (that I provided
patches for a while back that were not accepted) I'd say it should be.
Also session passivation and activation listeners are not called...
Ron Crayton wrote:
The documentation for the PersistentManager has contained the following
Somewhere one does cross the hazy Heisenberg uncertainty principal line,
i.e. noticeably impacting performance by trying to hard to measure
On Apr 5, 2005 2:20 PM, Tony Tomcat [EMAIL PROTECTED] wrote:
I started writing
From: Jess Holle [mailto:[EMAIL PROTECTED]
Sent: Monday, March 21, 2005 7:42 PM
To: Tomcat Users List
Subject: Re: CERT Vulnerability Note VU#204710 on Tomcat 3.x
This vulnerability note has to be amongst the most vague and
least informative I've ever seen. It says
Isn't a firewall what you really want/need, i.e. to disallow connections
to port 8009 except when they come from your IIS server?
VAN DER MARLIERE FREDERIC wrote:
In fact, what I really want is to prevent any other IIS or Apache to connect
to my 8009 connector port, for my IIS machine is used
of these variations.
On the other hand, any production installation should block
communication on the AJP 12 or AJP13 port except where it is coming from
Apache. This completely addresses the vulnerability irrespective of
[EMAIL PROTECTED] wrote:
CERT released a vulnerability note
Bill Barker wrote:
Jess Holle [EMAIL PROTECTED] wrote in message
This vulnerability note has to be amongst the most vague and least
informative I've ever seen. It says that Tomcat 3.x and AJP12 has an
issue and that the issue is not present in Tomcat 5.
static/classloader-based LoggerRepository, and this keeps Tomcat's logs
using their own LoggerRepository and a separate logging configuration.
I'm still not to where I want to be with this, but it's a far cry from
the out-of-the-box mess that occurs with log4j and commons-logging.
LoggerRepository -- which would be fine if these loggers were not shared
with other web apps.
What's the solution here? Do I have to put log4j into Tomcat's lib
directories to force it to use its own centralized log4j? Is that the
Can anyone shed any light as to when Tomcat 3.3 will actually be released
(i.e. as a non-beta release)?
What are the open/known issues?
[I checked CVS, dev-mailing list, and Bugzilla to no avail.]
A better question is why Tomcat 3.3 which has the critical classloader
separation feature as well as performance improvements over 3.2.1 has not
yet been released.
As the previous message said, many of us have to use released software
purely text-based configuration capability, and that doesn't mean 'regedit',
like Apache to simplify automated configuration.]
From: Curtis Dougherty [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 01, 2001 1:31 PM
To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED
What is the expected time of arrival / release of Tomcat 3.3???
It's been at the same milestone seemingly for aeons while Tomcat 4.0
continues to show more obvious (to those not doing lots of CVS snooping)
signs of progress. Problem is we need 3.3 ASAP whereas 4.0 is "out there".
Still, there *are* algorithms which should be threaded and EJB shouldn't
make it a supreme pain to do this!
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 09, 2001 2:51 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Mail list logo