diff for jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java. This got line
wrapped :( I did this because when I put in my a mistyped class name, I
would just get an error page saying:
org.apache.jasper.JasperException:
... which wasn't too helpful. Unfortunately at the moment I c
Craig R. McClanahan wrote:
I don't see a problem with that, but I've stopped using "reloadable" at
all for my development -- reload-on-demand (via the manager webapp) is a
much more effective strategy IMHO. And "reloadable" shouldn't be used on
a production server anyway.
Is there a way to
How come jk doesn't have a CHANGES or HISTORY file?
Glenn Nielsen wrote:
The thread safe bug found in jk_resolve.c has been fixed.
I have generated another mod_jk 1.2.5 test source distribution,
it can be found at:
http://cvs.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz
Please
Glenn Nielsen wrote:
The thread safe bug found in jk_resolve.c has been fixed.
I have generated another mod_jk 1.2.5 test source distribution,
it can be found at:
http://cvs.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz
BTW That files doesn't have a configure, I had to generate
Glenn Nielsen wrote:
No problems have been reported since the last test source distribution
of mod_jk 1.2.5 was made available for testing July 26.
Please vote on a release of mod_jk 1.2.5:
[ ] +1 release, and I will help build binaries for _ os/web server
[ ] +0 ok to release
[ ] -0 relea
./configure -with-apxs=/usr/local/apache2/bin/apxsGlenn Nielsen wrote:
As part of the mod_jk 1.2.5 release I promised to move the JTC download to
BTW you forgot to generate a configure file for the release, users will have to run
buildconf.sh
--
Take bugs 30551 and 30552. One is reported under Tomcat 5, one under
Tomcat 4.
When a user goes to report a bug he has to first search existing
bugs. Right now you would have to search under multiple Project
entries, and you would have no way of limiting your search by release
number since
Jess Holle wrote:
The offer to do this is great, but I am more than a little curious:
Why would anyone bother with a 4.1.x upgrade at this point? 5.0.27 is
faster, more stable, etc, at this point as best I can tell.
Because the 5.0 branch has a memory leak I haven't been able to pin
down, so I
I don't know why you want to get rid of endorsed. Sure java 5.0 will
have an up to date xerces, but it will get out of date in the future, so
you might as well keep the endorsed directory.
Amy Roh wrote:
+1
I'd like to add startup scripts that don't use endorsed so that tomcat
5.0.28 can be run
Could someone please explain why this is 5.5 and not 5.1?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
The release notes say:
Redhat Linux 9.0 users should use the following setting to avoid
stability problems:
export LD_ASSUME_KERNEL=2.4.1
This simple shell script can tell you if you are running redhat 9:
if [ -f /etc/redhat-release ] && grep -q Shrike /etc/redhat-release ; then
ech
Shapira, Yoav wrote:
Hi,
-1. The ASSUME_KERNEL is a suggestion meant at more advanced users and
should not be imposed on everyone using RH9 by default.
Yoav Shapira
Millennium Research Informatics
-Original Message-----
From: Joseph Shraibman [mailto:[EMAIL PROTECTED]
Sent: Wednesday, Septembe
12 matches
Mail list logo
