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
+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:
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]
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
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
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 (
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
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
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
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
[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
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
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
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
+++
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
[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
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
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
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
I've been trying to find in the source if something like this is
supported:
Ajp13Connector max_threads=50
max_spare_threads=10
min_spare_thread=5
port=8009
address=127.0.0.1/
in Tomcat 3.3, rather then Parameter name=... syntax
Larry Isaacs wrote:
Hi Bojan,
The user's guide still has a lot of content that is out of date.
You cite one of the sections that I haven't updated yet.
The reading of server.xml is controlled by ServerXmlReader.java
found in tomcat/modules/config. See the setBackward() method
at the
Larry Isaacs wrote:
Hope this helps,
Larry
OOPS. Trigger happy! Take 2 :-)
Bojan
--- /home/groups/devel/jakarta/jakarta-tomcat/src/doc/tomcat-ug.htmlSat Aug 18
11:25:01 2001
+++ tomcat-ug.html Fri Aug 24 23:19:05 2001
@@ -1313,24 +1313,14 @@
td bgcolor=#c0c0c0
pre
GOMEZ Henri wrote:
Hi to all,
I'm back from hollidays :(
Welcome back! Hope you had a good one...
After finally getting over the 'graceful restart' issues...
Could you developp it more please ?
This is related to the previous thread Problem with mod_jk 1.2.0
(latest CVS snapshot)
GOMEZ Henri wrote:
mod_jk in JTC is an evolution of mod_jk in CVS. Some refactoring
was done to share code between ajp13 and ajp14.
If this is not a known thing, I can send some more data...
Yes, please, strace could help in that case.
OK. I'll run up a few examples and send you
I guess most people would like to run Tomcat with server HotSpot if
there is one. Can we do something like this (just to save most people a
bit of configuration file editing, environment variable setting and the
like):
--- tomcat.sh Wed Jul 18 07:24:49 2001
+++ /usr/local/tomcat/bin/tomcat.sh
After finally getting over the 'graceful restart' issues...
Is this for some reason a 'forbidden' combination? I've observed some
really strange stuff going on with this combo - parameters don't get
passed correctly, even session stuff tends to be screwed (ie. same
session data appears in two
Craig R. McClanahan wrote:
With this patch, you would not be able to run Tomcat *without* HotSpot as
long as it existed -- which would often be useful in a debugging
situation.
You can tell Tomcat to start with this variable, without modifying the
startup scripts, by setting TOMCAT_OPTS
jean-frederic clere wrote:
Bojan Smojver wrote:
Bojan Smojver wrote:
Unfortunately, the problem is still there... Let me run gdb on the thing
again and then I'll send you the backtrace.
Bojan
Slighty different problem this time, but along the lines of the previous
one
Remy Maucherat wrote:
Oh, ok.
It doesn't happen with NT/2k, right ?
Just as a curiosity, try this one on your W2K (I was told it works on NT
as well):
1. Open a command prompt.
2. Run a command, that runs for a little while (e.g. ping -t some host).
3. Press F7 and ENTER repeatedly and
jean-frederic clere wrote:
Bojan Smojver wrote:
Bojan Smojver wrote:
Unfortunately, the problem is still there... Let me run gdb on the thing
again and then I'll send you the backtrace.
Bojan
Slighty different problem this time, but along the lines of the previous
one
I know, I know, RTFCF...
Bojan
Curtis Dougherty wrote:
yes...
-Original Message-
From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 03, 2001 8:04 PM
To: Tomcat Dev List
Subject: Binding to a single IP
I've asked this question over on the Tomcat user list
When I switched my projects from JSP to Velocity, I did it more for:
- simplicity of the language (VTL)
- taking away (from web designers) the power to write/execute Java
directly
but if it's fast as well, even better :-)
Bojan
PS. It does take longer to get the first page. Velocity has to
jean-frederic clere wrote:
Bojan Smojver wrote:
jean-frederic clere wrote:
Bojan Smojver wrote:
Don't want to be a pain in the back side... but (there is always at
least one of those :-), is anyone checking this one out?
I had a peek into the code and that NULL
Just a little trivial problem with the new source: it doesn't build
because file common/jk_uri_worker_map.c has an unintentional comment end
(the * after apache) in line 312:
* I have fixed jk_mount_context() in apache*/mod_jk.c so we should
The comment actually ends in line 314.
Bojan
Bojan
Unfortunately, the problem is still there... Let me run gdb on the thing
again and then I'll send you the backtrace.
Bojan
jean-frederic clere wrote:
Clere Jean-Frederic FSC EP LP COM 5 wrote:
Bojan Smojver wrote:
jean-frederic clere wrote:
Bojan Smojver wrote
Bojan Smojver wrote:
Unfortunately, the problem is still there... Let me run gdb on the thing
again and then I'll send you the backtrace.
Bojan
Slighty different problem this time, but along the lines of the previous
one:
--
Program received
=min_spare_threads
value=10/
/Connector
--
Obviously, this is for my ajp13 connector, but I believe it would work the
same for the HttpConnectionHandler.
Hope this helps.
--jeff
- Original Message -
From: Bojan Smojver [EMAIL PROTECTED
the
same for the HttpConnectionHandler.
Hope this helps.
--jeff
- Original Message -
From: Bojan Smojver [EMAIL PROTECTED]
To: Tomcat Dev List [EMAIL PROTECTED]
Sent: Friday, August 03, 2001 6:04 PM
Subject: Binding to a single IP
I've asked this question over on the Tomcat user
uri_worker_map_add. If that thing
gets blown away (or isn't redone) when Apache gracefully restarts...
Bojan
Bojan Smojver wrote:
GOMEZ Henri wrote:
Just realised that the core I have was compiled without -g option. VERY
useful. I also wanted to replicate the core dump with the
httpd
GOMEZ Henri wrote:
Just realised that the core I have was compiled without -g option. VERY
useful. I also wanted to replicate the core dump with the
httpd that was
compiled with -g, but that didn't work. Now I'm starting to think that
the core file I had was a result of a different crash
GOMEZ Henri wrote:
Just realised that the core I have was compiled without -g option. VERY
useful. I also wanted to replicate the core dump with the
httpd that was
compiled with -g, but that didn't work. Now I'm starting to think that
the core file I had was a result of a different crash
The announcement reads:
The new class loader scheme in this release ignores your CLASSPATH
setting. Instead, you may add needed jars to Tomcat's lib/apps,
lib/common, and lib/container directories. See the readme file
in Tomcat's doc directory for details.
Also supported are two System
GOMEZ Henri wrote:
Ask to Apache specialist in new-http list, may be JF Clere could
forward your question to them ?
I'll subscribe to the list and try to find out how it's done. Then
(hopefully) I'll be able to send over something you can work with.
Bojan
jean-frederic clere wrote:
GOMEZ Henri wrote:
Just realised that the core I have was compiled without -g option. VERY
useful. I also wanted to replicate the core dump with the
httpd that was
compiled with -g, but that didn't work.
What did not work? -It does not core any more?
GOMEZ Henri wrote:
Good information, and could send us a strace ?
This may sound strange to all you Apache experts, but how do I do that?
How do I run strace on a detached process?
strace httpd -f (follow forks)
Thanks for the tip. The log file (bziped) is attached.
Bojan
jean-frederic clere wrote:
Bojan Smojver wrote:
GOMEZ Henri wrote:
Good information, and could send us a strace ?
This may sound strange to all you Apache experts, but how do I do that?
How do I run strace on a detached process?
strace httpd -f (follow forks
GOMEZ Henri wrote:
Good information, and could send us a strace ?
This may sound strange to all you Apache experts, but how
do I do that?
How do I run strace on a detached process?
strace httpd -f (follow forks)
Thanks for the tip. The log file (bziped) is attached.
I
GOMEZ Henri wrote:
Now I have some new info here. After recompiling everything clean, I've
taken out PHP altogether. So it's not part of the equation. It is
sufficient to compile mod_jk in and use static pages only (ie. no
JSP's/VM at all). If you gracefully restart the server a
number of
GOMEZ Henri wrote:
I still have to distribute this DSO version of Apache and mod_jk to some
slower machines to see if that makes any difference at all. The machine
that didn't produce any errors is a 1 GHz Athlon, so timing issues could
have been resolved by brute force, who knows...
GOMEZ Henri wrote:
Just did a DSO version and couldn't replicate the problem (BTW, I've
recompiled/statically linked Apache and mod_jk again since then and the
problem was still there). So, maybe it has to do with statically linking
Apache after all...
Strange problem. What's the
Bojan Smojver wrote:
As for DSO, I'll have to work on that, so probably some time tomorrow
(Sydney time).
Just did a DSO version and couldn't replicate the problem (BTW, I've
recompiled/statically linked Apache and mod_jk again since then and the
problem was still there). So, maybe it has
GOMEZ Henri wrote:
Just did a DSO version and couldn't replicate the problem (BTW, I've
recompiled/statically linked Apache and mod_jk again since then and the
problem was still there). So, maybe it has to do with statically linking
Apache after all...
Strange problem. What's the
OOPS! Sorry :-(
jk.conf (called from httpd.conf)
-
###
# Apache JK Configuration
File#
###
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
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
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
[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
[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
201 - 300 of 309 matches
Mail list logo
