I've posted a few messages about this to Tomcat User list, but since
this is really development related, I'm posting this one here.
Basically, mod_webapp packaged with Tomcat 4.0 b2 and b3 doesn't
compile, so I switched back to the version from b1. I've noticed a few
things:
- I'm confused as
Beauty.
I'm actually playing with 3.3 as well, because some of the features I
like (eg. realm per host) are there as well.
Bojan
Dan Milstein wrote:
I can't speak to mod_webapp, but a mod_jk response:
- I understand the need for the TCP connections to be persistent in
mod_jk and
I think there is a bug in AccessInterceptor.java, line 488, which only
shows when cookies are turned off in server.xml file with:
SessionId cookiesFirst="false" noCookies="true" /
The problem is related to the fact that at the time of 'if', the
req.getSessionIdSource() returns null and the test
The digest should be called on credentials, not on what's picked up from
the database. That would already be digested. Here is the patch for
JDBCRealm.java:
---
jakarta-tomcat-3.3-src-original/src/share/org/apache/tomcat/modules/aaa/JDBC
Realm.java Wed Feb 28 06:10:16 2001
+++
[EMAIL PROTECTED] wrote:
The patch allows systems that have /dev/random to use it instead of the
slower Random. Instead of checking for OS==linux ( as in submited patch )
we use an option of the module.
Cool.
The code if the option "useDevRandom" is not set is the same as before.
Forgot to ask, would you be interested in instructions/simple shell
script for building mod_jk as a statically linked Apache module?
Bojan
Dan Milstein wrote:
I can't speak to mod_webapp, but a mod_jk response:
- I understand the need for the TCP connections to be persistent in
mod_jk
No worries. It's purely selfish ;-) I kind of need JDBCRealm to work
with encrypted password and per virtual host, so that's why Tomcat
3.3...
I would just like someone from a certain software company to join this
mailing list to see how fast the bugs are fixed in open source. I've
already
I'm not sure if this is something I'm doing... Anyway, latest Tomcat 3.3
from CVS gives me this:
2001-04-10 20:23:06 - JspFactoryImpl: Exception initializing page
context - java.lang.NullPointerException
at java.util.Hashtable.remove(Hashtable.java:421)
at
[EMAIL PROTECTED] wrote:
Given that tomcat should run for days or weeks at a time, I don't think
you want to keep /dev/random open. There maybe other processes that also
need random data during that time.
Are you really sure that other processes are unable to use /dev/random
while Tomcat is
[EMAIL PROTECTED] wrote:
SessionIdGenerator useDevRandom="true"/
Thanks. I figured it out after I asked that silly question. It must have
been the most brain dead question you had to answer in a while, I guess.
A good read of server.xml will get you a long way these days ;-)
Note that the
I was tossing this idea around as well after I couldn't get mod_webapp
to work successfully with Tomcat 4.
Tomcat might be good for HTTP but it's probably faster to employ mod_ssl
to do HTTPS.
In the proxy setup like that, what would happen to the SSL connections?
Would Tomcat have to do that
MessageBytes that are actually a string, so that toString() from it
returns something meaningful.
Bojan
Bojan Smojver wrote:
I'm not sure if this is something I'm doing... Anyway, latest Tomcat 3.3
from CVS gives me this:
2001-04-10 20:23:06 - JspFactoryImpl: Exception initializing page
, and probably it would be simpler if you
could add few println() and check if SessionIdGenerator got called and why
is it not generating the random id.
Costin
On Wed, 11 Apr 2001, Bojan Smojver wrote:
I went a bit further with debugging and it seems that getNewSession()
method
e).
Mel
--- Bojan Smojver [EMAIL PROTECTED] wrote:
I'm not sure if this is something I'm doing...
Anyway, latest Tomcat 3.3
from CVS gives me this:
2001-04-10 20:23:06 - JspFactoryImpl: Exception
initializing page
context - java.lang.NullPointerException
at
java.util.Hashta
another note, you might want to mention in mod_jk documentation
that a mount like this has to exist:
JkMount /login/j_security_check ajp13
or j_security_check won't work from Apache. That's provided your login
and error pages live in /login directory.
Bojan
Bojan Smojver wrote:
I had a brief
[EMAIL PROTECTED] wrote:
As pointed out by someone else, at some point on a system that is not
busy processes will hang on /dev/random waiting for their next chance to
catch some randomness generated by things like mouse moves. And if you
are on a server, the mouse may never move. There will
Doug Barnes wrote:
The answer to these arguments are: use /dev/urandom, not
/dev/random. It's going to do as good or better than anything
you're going to seed with /dev/random, and IT WILL NOT BLOCK.
I may be wrong (I'm just starting to poke around in related
code) but it doesn't look
Doug Barnes wrote:
You only have so much entropy that's available on a given machine at a
given time. From the same manpage, you can see that if you have access
to more entropy than /dev/random knows about normally, you can write it
back to /dev/random (they give an example) but at the end
Don't know if the patch for this was missed (since it was buried into a
long e-mail), you guys didn't like it or just didn't have time to
implement. Anyway, I'm doing it clean in this e-mail. Thanks to Doug
Barnes who explained the issues of random number generation...
Here is the patch (I had
[EMAIL PROTECTED] wrote:
You may file a feature request on bugzilla, attach you patch - this way
it'll be recorded.
Done.
Or send few more patches ( there are many open bugs, most of them are
easy to solve but require time to test and reproduce ), and you'll be
able to check in the patch
Since I was playing with distributing all my apps in jars...
In method dependency() of that class, there is a section for jars. It
goes something like this:
if( jar.equals( res.getProtocol() )) {
String fileN=res.getFile();
int
[EMAIL PROTECTED] wrote:
Sorry, I had a lot on my had in the last days.
Bojan - if you want to send a patch, it would be great. If not - I can fix
the bug ( but I would prefer you to send a patch - who knows, maybe later
you'll send another one, the first is allways harder :-)
Costin
Bojan Smojver wrote:
[EMAIL PROTECTED] wrote:
Sorry, I had a lot on my had in the last days.
Bojan - if you want to send a patch, it would be great. If not - I can fix
the bug ( but I would prefer you to send a patch - who knows, maybe later
you'll send another one, the first
I've notice that the most recent Ajp13Interceptor prints something like
this into log files:
--
Ajp13Request: Read:
Craig R. McClanahan wrote:
Christopher Cain has raised some concerns (both in private email and
publicly on this list) regarding the initialization of pseudo random
number generators (PRNGs) used to calculate session id values. We need to
have a quick discussion about this, to determine
Just reformatting the e-mail to look like an actual patch. Sorry for not
following the conventions earlier.
Bojan
---
/home/groups/devel/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/util/depend/DependClassLoader.java
Tue Sep 11 17:42:11 2001
+++
);
- if( debug 0 ) log( Jar dep +f );
+ // Bojan Smojver [EMAIL PROTECTED]: remove jar:
+ if( fileN.startsWith( jar: ))
+ fileN=fileN.substring( 4 );
I think this should actually be file: and then the next line should
have '5', instead of '4'. Yes
If debugging is enabled and sw is null, it blows up (NPE). Patch
follows.
Bojan
---
/home/groups/devel/jakarta/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/ServletHandler.java
Mon Jul 23 09:00:00 2001
+++ jakarta-tomcat/src/facade22/org/apache/tomcat/facade/ServletHandler.javaFri
I'm playing with Classloader issues in Tomcat 3.3 (but from what I hear
it's not much different in TC 4) and the whole thing behaves really,
really strange. This is what I can observe, with automatic reloading
enabled:
- a jar file in WEB-INF/lib will be picked up with no issues the very
first
Remy Maucherat wrote:
My environment is JDK 1.3.1_01, Linux. In some other discussions, people
from TC 4 team mentioned that there are similar problems on Windows too.
TC 4 uses a 100% custom URLClassLoader clone, and it accesses the JARs
directly (using JarFile objects). I'm really
[EMAIL PROTECTED] wrote:
On Sat, 15 Sep 2001, Bojan Smojver wrote:
Remy Maucherat wrote:
TC 4 uses a 100% custom URLClassLoader clone, and it accesses the JARs
directly (using JarFile objects). I'm really careful about properly closing
these objects when the CL is dumped when
[EMAIL PROTECTED] wrote:
On Sat, 15 Sep 2001, Bojan Smojver wrote:
- if the jar file is changed, the application will reload (due to some
recent fixes there in DependClassLoader), but some resources might not
get loaded properly (for instance a properties file from within that
jar
Hi Pier,
I can see by the number of recent commits that you are very busy with
mod_webapp. Can you tell me if the new stuff will include support for
mod_webapp with a statically linked Apache of is it still DSO only?
Bojan
Pier Fumagalli wrote:
Bojan Smojver [EMAIL PROTECTED] wrote:
Hi Pier,
I can see by the number of recent commits that you are very busy with
mod_webapp. Can you tell me if the new stuff will include support for
mod_webapp with a statically linked Apache of is it still DSO only
Pier Fumagalli wrote:
Bojan Smojver [EMAIL PROTECTED] wrote:
Pier Fumagalli wrote:
Bojan Smojver [EMAIL PROTECTED] wrote:
Hi Pier,
I can see by the number of recent commits that you are very busy with
mod_webapp. Can you tell me if the new stuff will include support
After digging some more into the code of it, I've realized that the
readFully() method is really hard to understand. So, unless there are
some substantial performance gains in the existing approach, maybe we
should go with something a bit simpler.
And just as a side note, you've probably noticed
[EMAIL PROTECTED] wrote:
Hi Bojan,
First, you're a commiter now, feel free to fix anything you see
broken :-)
Didn't know it was official. Thanks!
Regarding this particular fix - it will not have a big performance
impact ( except for loading .class files, which happen once ).
However
Mike Anderson wrote:
+1
Keep up the good work Bojan!
[EMAIL PROTECTED] 09/17/01 05:43AM
I would like to propose Bojan Smojver as a committer.
He has supplied a number of patches as well as done
useful testing. I think he would make good addition
to the Jakarta team.
Vote
This version should be more efficient and cleaner too.
Will do the old code with comments too.
Bojan
---
/home/groups/devel/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/util/depend/DependClassLoader.java
Mon Sep 17 11:51:16 2001
+++
Here is commented and slightly reworked readFully(). It should do
(hopefully) the same thing as the old one but (hopefully again) with a
bit more fluff for the uninitiated like me.
Do you guys think that this method can be put into some sort of
'utility' package? It seems like something
Just playing with Form authentication in TC 3.3. Have two Velocity pages
that are doing the authentication with a JDBC Realm (for that context
only). When Tomcat starts, all is fine. I get authenticated (or not)
depending on username/password combination I supply. Subsequent visits
to the same
Bojan Smojver wrote:
Just playing with Form authentication in TC 3.3. Have two Velocity pages
that are doing the authentication with a JDBC Realm (for that context
only). When Tomcat starts, all is fine. I get authenticated (or not)
depending on username/password combination I supply
[EMAIL PROTECTED] wrote:
Hi Bojan,
A simpler solution is to fix ReloadInterceptor - and save the current list
of interceptors before removing the context, then add all per/context
interceptors after the context is added back ( those having getContext()
!= null ).
OK. I'll look into
[EMAIL PROTECTED] wrote:
My understanding is that ContextXmlReader actually produces 'fresh'
instances every time.
True. Do you think it would be better ( or simpler ) to just change
ContextXmlReader to create a new set of per/context interceptors ?
My thinking was that the
This seems to do the trick. I've tested it with the JDBCRealm
interceptor and it behaves normally (ie. JDBCRealm gets hooked back in
and it actually works after the application reload).
Any feedback before this gets committed is welcome (as in: I'd rather
not screw up TC 3.3 RC with my first
[EMAIL PROTECTED] wrote:
Hi Bojan,
+1 - looks very good, it'll be a great 'first commit'.
( 'normal' case with only global modules is not affected in any way, and
for local modules it'll do the right thing, and update the context ).
Thanks. Wouldn't be able to do any of it without your
[EMAIL PROTECTED] wrote:
On Tue, 25 Sep 2001, Bojan Smojver wrote:
I've read the thread about tabs/spaces/indentiation in Tomcat code and
it seems that at least TC 4 people are going with 4 spaces instead of
tabs (judging by comments from Craig).
Does that apply to TC 3.3 as well
I've committed a patch to the repository today, expecting an automatic
e-mail to the tomcat-dev list when the commit happens. But it never did,
although the commit went through OK.
After searching the CVS manual for clues, I bumped into -i option for
modules, but that seems like an admin/setup
Morrison, John wrote:
The cvs list is moderated. It takes a little time the first time ;) Don't
worry, it'll get there.
He, he, good one ;-)
Bojan
Unless this is now implemented automatically in mod_jk, I think it would
be worth mentioning in mod_jk HOWTO about the need to JKMount
j_security_check when form authentication is used in applications.
I think I should be able to fake a paragraph about it (with examples).
Bojan
of the
defined mappings (including j_security_check for form auth contexts).
- Original Message -
From: Bojan Smojver [EMAIL PROTECTED]
To: Tomcat Dev List [EMAIL PROTECTED]
Sent: Tuesday, September 25, 2001 5:34 PM
Subject: TC 3.3 + mod_jk + j_security_check
Unless this is now
to specify the directories where
various files go (e.g. mod_jk.so), but I don't remember them off the top of
my head.
- Original Message -
From: Bojan Smojver [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, September 25, 2001 7:51 PM
Subject: Re: TC 3.3 + mod_jk
Keith Wannamaker wrote:
0x3b = ';'. Ignacio is right, SessionID doesn't remove the id
because it is not expecting ; to be encoded. So now it shows
up in the URI and has the side effect of breaking sessions
that depend on url rewriting. But, the spec does say the URL
should be encoded,
[EMAIL PROTECTED] wrote:
On Wed, 26 Sep 2001, Keith Wannamaker wrote:
0x3b = ';'. Ignacio is right, SessionID doesn't remove the id
because it is not expecting ; to be encoded. So now it shows
up in the URI and has the side effect of breaking sessions
that depend on url rewriting.
[EMAIL PROTECTED] wrote:
Having a stable core is essential for module development and for enhancing
the current set of modules. Even if there are many improvements we can add
to 3.3, I believe the benefit of keeping 3.3 stable is far bigger.
Just to confirm this point, I've been running 3.3
Bill Barker wrote:
While pooling was a very nice feature of JServe (which I have personally
taken advantage of in the past), the operative word in the spec is may.
The 3.x and 4.0 implementations are entirely within their rights within the
spec to simply synchronize.
In other words, this
Christopher Cain wrote:
Quoting [EMAIL PROTECTED]:
On Mon, 1 Oct 2001, Aaron Bannert wrote:
What are the main advantages to using an in-process VM as opposed
to an out-of-process VM bridged over some form of IPC (like
mod_webapp/mod_jk/mod_jserv)?
Well, using in-process VM (
I have done this with TC 3.3, Apache 1.3.20 + mod_jk and my own form
based authentication:
Pages:
/login/login.vm -- login page
/login/error.vm -- error page
/login/index.vm -- default index page
If someone goes to /login/login.vm directly and gets authenticated, the
page /login/index.vm gets
Bojan Smojver wrote:
I have done this with TC 3.3, Apache 1.3.20 + mod_jk and my own form
based authentication:
Just to clarify here, 'my own' means in my own app, not something I've
coded separately from TC.
Bojan
Bojan Smojver wrote:
[EMAIL PROTECTED] wrote:
I don't think I can do this alone ( if it sounded like I volunteer to fix
it - well, I need help ).
- Test.
I'm one of those overly brave and too stupid that put CVS versions of
software in production environment. Promise to give
Jan Grant wrote:
actually, I was more concerned with exposing implementation mechanisms
in URIs; and future-proofing so that when index.jsp becomes
index.csharpsp in the future (only kidding...) I'm not left with an
unmanageable mess.
He, he, good one!
:-))
Bojan
Tested briefly against mod_jk 1.1.0 and mod_jk 1.2.0... Everything seems
to be chugging along quite fine.
Bojan
Schreibman, David wrote:
I'm submitting this with mixed feelings since the recent discussion has
shown strong opinions about the utility of the SingleThreadModel.
STM as a concept has so many flaws that I tend to side with Jon (ie. it
should be dropped from the spec). Personally, I was
Just for fun I did this to exercise mod_jk/TC 3.3 combination:
---
ab -c 1 -n 1000 http://some/velocity/page.vm
---
This goes OK on both 1.1.0 and 1.2.0, although some requests aren't
served (probably because no more
Try: http://jakarta.apache.org/site/mail2.html
Bojan
Sai Sekhar wrote:
Unsubscribe
Bojan Smojver wrote:
This goes OK on both 1.1.0 and 1.2.0, although some requests aren't
served (probably because no more threads are available in ajp13
connector - I run a max of 50).
Has probably very little to do with it. I tried more threads, but some
requests still fail according to ab
Bojan Smojver wrote:
Bojan Smojver wrote:
This goes OK on both 1.1.0 and 1.2.0, although some requests aren't
served (probably because no more threads are available in ajp13
connector - I run a max of 50).
Has probably very little to do with it. I tried more threads, but some
[EMAIL PROTECTED] wrote:
I think ( or guess ) that ab is checking the length of the first request,
and if following requests have different lengths it assumes it's a
failure.
Could you check if your page returns the same thing ? Very strange..
I ran the thing with -v 99 and it shows only
Bojan Smojver wrote:
Since I can control the headers from my servlet, let my try with
Content-length. Fingers crossed...
If think this can actually qualify as a bug in ab - even when I set
Content-Length header, it still says that that there are length
failures. Since jsessionid can sometimes
jean-frederic clere wrote:
And in mod_jk.log file is there something?
Mostly something like this:
-
[Fri Oct 05 17:07:55 2001] [jk_ajp_common.c (914)]: Error
ajp_process_callback - write failed
[Fri Oct 05 17:07:55 2001]
+1
Bojan
PS. What's the world coming to these days - a guy from Sun has to ask
approval to become a Tomcat committer ;-)
Christopher Cain wrote:
I would like to nominate Patrick Luby [EMAIL PROTECTED] for committer
status. His recent contributions include several security-manager-related
I have subscribed myself to Tomcat User list a few days back with the
intention to help a few people on it (given my +1 on TC 3.3 final). I
have to say that the amount of e-mails and sometimes the superficial
nature of them prevented me from actually doing any useful work. Don't
know about the
Craig R. McClanahan wrote:
On Fri, 19 Oct 2001, Bojan Smojver wrote:
Date: Fri, 19 Oct 2001 08:59:27 +1000
From: Bojan Smojver [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Tomcat Dev List [EMAIL PROTECTED]
Subject: Mailing list proposal
I have subscribed myself to Tomcat
Craig R. McClanahan wrote:
On Fri, 19 Oct 2001, Bojan Smojver wrote:
Most of this has come from my totally different experience with Velocity
User mailing list. There are fewer messages and fewer developers
answering questions, but most of the time users get a good response
jean-frederic clere wrote:
Bojan Smojver wrote:
I have subscribed myself to Tomcat User list a few days back with the
intention to help a few people on it (given my +1 on TC 3.3 final). I
have to say that the amount of e-mails and sometimes the superficial
nature of them prevented me
jean-frederic clere wrote:
Yes, Bugzilla asks the right questions... So a form like the Bugzilla one that
mails to the user list (of course telling that you have to subscribe to the list
otherwise you question will be ignored).
Since they'd have to login to use the form (just like on
Lee Bruce wrote:
hi ,
I installed Tomcat 4.0 at windows 2000 workstation version . The problem is
: I don't know if the workstation version is enough , should I use server
edition ? Do I need IIS ?
I think you should be able to run it even on Win 9x (from posts on this
list - don't
Do you think that it would be smart and/or desirable to 'enforce' the
check for all people that use sessions with SSL? In other words, if you
have a TC session, and you're running things over SSL, we enforce the TC
session ID and SSL session ID match.
If there are security experts out there
Quoting Pier Fumagalli [EMAIL PROTECTED]:
Bill Barker at [EMAIL PROTECTED] wrote:
I know that Jon has already pointed out that Sun is going to sue the
3.x
branch out of Jakarta in five months,
I don't think Jon said that, and as a Sun employee I can guarantee
that
Tomcat 3.x remains
Quoting Pier Fumagalli [EMAIL PROTECTED]:
And in case I don't see you, good afternoon, good evening and good
bye...
Pier, my apologies for the Sun related e-mail on the list today. If I only knew,
I would never have sent it.
:-((
I wish you all the best in your future undertakings and I
I've seen some issues similar to those. Sometimes (I could not establish
the pattern for now), this is what appears in TC 3.3 logs:
---
2001-10-29 16:35:51 - ContextManager: Removing context www.dev.dev:/ROOT
2001-10-29 16:35:51 - Ctx() : Remove mapping
I have been trying to convince Sun people that 1.3.1 and 1.3.1_01
HotSpot has problems on Linux, but they wouldn't buy it.
My suggestion is: use IBM's JDK 1.3.0. It is faster and more stable then
Sun's.
Bojan
Eddie Ruvinsky wrote:
Hi all,
Would anyone happen to know the fix to this?
Pier Fumagalli wrote:
Bojan Smojver at [EMAIL PROTECTED] wrote:
I have been trying to convince Sun people that 1.3.1 and 1.3.1_01
HotSpot has problems on Linux, but they wouldn't buy it.
My suggestion is: use IBM's JDK 1.3.0. It is faster and more stable then
Sun's.
My suggestion
Weiqi Gao wrote:
Pier Fumagalli wrote:
Bojan Smojver at [EMAIL PROTECTED] wrote:
I have been trying to convince Sun people that 1.3.1 and 1.3.1_01
HotSpot has problems on Linux, but they wouldn't buy it.
My suggestion is: use IBM's JDK 1.3.0. It is faster and more stable
I've noticed that on the main TC page of Jakarta site, TC 3.2.x is
still listed as production quality release, although we all know that
3.3 is far superior in almost any respect. That's for Servlet API 2.2
and JSP 1.1, of course.
Any objections if I change this?
Bojan
--
To unsubscribe,
Silly to ask, but I'll do it anyway... in which CVS repository are the
files that appear on Tomcat section of Jakarta site? I've checked out
jakarta-site2, but it's not there.
Bojan
Bill Barker wrote:
No objection here.
- Original Message -
From: Bojan Smojver [EMAIL PROTECTED
Thanks. Didn't actually pay attention to that part. Fixing now...
BTW, do you think it would be better if the order of described releases
is changed? In other words, Tomcat 3.3/4.0 first and then others.
Bojan
Bill Barker wrote:
You forgot to remove the is in beta testing from the 3.3
Bill Barker wrote:
It works for me, and if it just involves swapping 3.2 and 3.3 I don't see a
problem (or, at least you'll win the vote). Personally I wouldn't try to
move the 4.0 without first posting a [VOTE] (although since you're moving it
up, it will likely win).
OOPS! Will have to
Tomcat web page (http://jakarta.apache.org/tomcat/) currently lists the
releases in the order from the oldest to the newest in the description
section.
I propose those are listed in the more natural order, from the newest to
the oldest (i.e. TC 4.0.x, TC 3.3, TC 3.2.x, TC 3.1.x)
Vote to change
Bojan Smojver wrote:
Vote to change the order of releases on the Tomcat web page:
[X] +1. I agree with the proposal and I will help support it.
[ ] +0. I agree with the proposal but I will not be able support it.
[ ] -0. I don't agree with the proposal but I won't stop it.
[ ] -1. I
Endre Stølsvik wrote:
On Mon, 19 Nov 2001, Bojan Smojver wrote:
| Tomcat web page (http://jakarta.apache.org/tomcat/) currently lists the
| releases in the order from the oldest to the newest in the description
| section.
|
| I propose those are listed in the more natural order, from
-
From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 19, 2001 12:18 AM
To: Tomcat Dev List
Subject: [VOTE] Change the order of releases mentioned on the TC web
page
Tomcat web page (http://jakarta.apache.org/tomcat/) currently lists the
releases in the order from
Bojan Smojver wrote:
Tomcat web page (http://jakarta.apache.org/tomcat/) currently lists the
releases in the order from the oldest to the newest in the description
section.
I propose those are listed in the more natural order, from the newest to
the oldest (i.e. TC 4.0.x, TC 3.3, TC 3.2
Two questions:
- does anyone have experience with removing the JSP part from TC (i.e.
make TC 3.3 a servlet container only)?
- would something like that actually break any licensing agreements with
Sun?
Bojan
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands,
Bill Barker wrote:
Commenting out JspInterceptor effectively removes JSP support. Now you
either need to define a *.jsp mapping in your web.xml, or hack
WebXmlReader (line 67 of Final) so that it doesn't add a default *.jsp
mapping.
Thanks.
Bojan
--
To unsubscribe, e-mail:
T. Kandasamy wrote:
Hi
In our organization, we are trying to put the tomcat 3.3 in the production
environment. I wish to see
some performance test results of the tomcat. Is it highly stable?. If any is
using the tomcat in the
production/ live server, please share your experinces with
T. Kandasamy wrote:
Hi Bojan:
Thanks for your kind reply. How about the stability of the tomcat i.e.if the
number of concurrent increases. whether the tomcat will be stable? or
getting
crashed. Please let me know, do you use tomcat in the production server?
I do, but my servers are not
Thanks Bill and sorry for my laziness... Servlet only people like myself
will be happier now :-)
Bojan
[EMAIL PROTECTED] wrote:
billbarker01/11/28 19:06:05
Modified:src/facade22/org/apache/tomcat/facade JspInterceptor.java
WebXmlReader.java
Log:
Bill Barker wrote:
I've checked in a change to move setting the default mapping to
JspInterceptor. Now, all Bojan needs to do is to comment out JspInterceptor
in server.xml and all of his *.jsp files will be served as regular text
files.
Again, thanks for this. It makes JSP and Servlet
+1
Bojan
Amy Roh wrote:
As Bill Barker suggested, I would like to propose Jazmin Jonson as a new
committer.
She has contributed a numerous patches to Tomcat4 admin application.
Votes please?
Amy Roh
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands,
1 - 100 of 309 matches
Mail list logo
