FYI. As Dmitri astutely points out below, there should be a "finally" in the
try/catch block in promptForInput method. What actually happened is that I
accidentally sent a "working copy" of the source file rather than
the "official" copy I had meant to send (that's what I get for leaving multip
pier01/08/05 20:07:06
Modified:webapp/lib pr_info.c wa_request.c
Log:
Avoid dumping request information back to the client in case of errors
and when looking the WebApp information page if we were not compiled with
DEBUG defined.
Revision ChangesPath
1.4 +3
pier01/08/05 19:47:21
Modified:webapp Makefile.in configure.in
webapp/lib .cvsignore pr_warp.h
Log:
Now WARP packet type signatures are held only in the Java source, and
are "copied over" to the C part during the execution of "configure"
Revision Changes
pier01/08/05 19:45:05
Modified:webapp/java Constants.java.in
Log:
Modified packet signatures for request handling request (in line with
request handling stages)
Revision ChangesPath
1.7 +2 -2 jakarta-tomcat-connectors/webapp/java/Constants.java.in
I
pier01/08/05 19:20:10
Modified:webapp/lib pr_warp_config.c
Log:
Analyze wether the Web-Application exists locally and can be accessed by
Apache. This will come handy when contexts will be shared between Apache
and Tomcat.
Revision ChangesPath
1.5 +23 -4
pier01/08/05 19:18:48
Modified:webapp/include wa.h
Log:
Include apr_file_info.h to start processing shared contexts between
Apache and Tomcat over WARP.
Revision ChangesPath
1.11 +2 -1 jakarta-tomcat-connectors/webapp/include/wa.h
Index: wa.h
=
pier01/08/05 19:17:39
Modified:webapp/java WarpPacket.java
Log:
Correctly handles transmission of NULL strings over WARP.
Revision ChangesPath
1.16 +1 -0 jakarta-tomcat-connectors/webapp/java/WarpPacket.java
Index: WarpPacket.java
===
Tomcat3.3 doesn't "expose" any sax parser ( or any of it's internal
objects ) to the application.
The app should be self-contained.
One solution is to copy jaxp.jar and crimson.jar from lib/container ( the
directory used for implementation-private libs ) into lib/apps ( all files
here will be s
pier01/08/05 16:59:34
Modified:webapp/apache-1.3 Makefile.in
Log:
Fix for bug # 2991 thanks to Fred Romelfanger <[EMAIL PROTECTED]>.
Revision ChangesPath
1.6 +3 -2 jakarta-tomcat-connectors/webapp/apache-1.3/Makefile.in
Index: Makefile.in
==
Attached is my generic utility which will allow for command-line interaction
with the user during Tomcat startup. I've named it "Feliner" because I'm so
witty. Even better, I've decided to name my proposed centralized "External
Resource Security" module "LitterBox", since it will be where Tomca
See the SAXEception.
I'm not sure if this is a bug in Tomcat or from something not configured properly or
maybe its normal behavior. Since I have only example war files from Tomcat and Struts
loaded I don't even
know where this action servlet is supposed to come from. I thought I would report
I've been trying out the 'in process' worker with TC3.2.3 and IIS. When
using a servlet that does a reasonable amount in its init() method, IIS
complains that the service did not respond in a timely fashion!
This obviously isn't a bug as such, but shouldn't the webapps be initialised
in a diff
pier01/08/05 12:59:48
Modified:webapp/java WarpPacket.java WarpResponse.java
Log:
Fix for BUG # 2990: Large files are not handled correctly.
Revision ChangesPath
1.15 +1 -1 jakarta-tomcat-connectors/webapp/java/WarpPacket.java
Index: WarpPacket.java
On Sun, 5 Aug 2001 10:48:31 -0700 (PDT), [EMAIL PROTECTED] wrote:
>> More generally, can anything from webl.xml be put in server.xml inside
>> a Context tag's scope?
>
>No, and that's premeditated :-)
Okay.
>Keep in mind server.xml ( and apps.xml ) is an ad-hoc format, and just one
>of the ways
Another small issue with watchdog (coming out of the JSP tests this time) is
that Apache always replies with HTTP/1.1 also to an HTTP/1.0 request For
example:
# telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.betaversion.org.
Escape character is '^]'.
GET / HTTP/1.0
HTTP/1.1 200 O
Time to go back to the old good java tutorial, I guess. Ever heard of
autoloading and threads? And, was it _that_ important to post it six times
or my mailbox went crazy?
Greetings, deacon Marcus
p.s. NTFG
p.s.2 Is there a way to moderate newcomers?
p.s.3 How often you get "method/class not foun
There's a small bug in the WatchDog GTest. Simply what it does is that it's
sending TWO Content-Length headers in the same request, and Apache correctly
translates those two headers into one single headers like:
Content-Length: ,
This small patch fixes the problem, but Tomcat 4.0 SHOULD thr
pier01/08/05 11:33:42
Modified:webapp/java WarpRequestHandler.java
Log:
Compliancy patch:
- Now values of URL-encoded sessions are correctly handled (Thanks to
Eryq <[EMAIL PROTECTED]> for reporting this bug.
- Locales are set correctly in the request object, parsing
On Sun, 5 Aug 2001, Randall Parker wrote:
> Costin,
>
> If one does define a context in apps-.xml can one sent
> context-param tags in it that are then accessible as part of that
> ServletContext?
>
> More generally, can anything from webl.xml be put in server.xml inside
> a Context tag's sco
Costin,
If one does define a context in apps-.xml can one sent context-param tags in it
that are then accessible as part of that ServletContext?
More generally, can anything from webl.xml be put in server.xml inside a Context tag's
scope?
See for example the context-param below where this
On Sun, 5 Aug 2001, Randall Parker wrote:
> So is there a way to turn off the creation of that automatic context?
Remove to disable all automatic contexts (
from webapps ).
Move the app out of webapps.
AutoDeploy takes all the files from the specified dir and add them.
> I'd also like a way
> So is there a way to turn off the creation of that automatic context?
>
> I'd also like a way to say "If a Context tag is defined then do not also
> generate an automatic context".
The name of the "path" attribute and the name of the dir in /webapps have to
be the same. You can rename one or t
On Sun, 5 Aug 2001 00:30:03 -0700 (PDT), [EMAIL PROTECTED] wrote:
>Hi Randall,
>
>I believe the behavior is correct - you have 2 contexts with the same
>docbase ( one defined in a config file, one automatically ).
So is there a way to turn off the creation of that automatic context?
I'd also l
Hi Randall,
I believe the behavior is correct - you have 2 contexts with the same
docbase ( one defined in a config file, one automatically ). They are
completely independent of each other ( you can look into work and you'll
see one work dir for each ). If you write a simple test servlet, you'll
24 matches
Mail list logo
