DO NOT REPLY [Bug 20850] - POST is not defined in RFC 2068 and is not supported by the Servlet API
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20850. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20850 POST is not defined in RFC 2068 and is not supported by the Servlet API --- Additional Comments From [EMAIL PROTECTED] 2003-06-18 06:29 --- If you notice the response: HTTP Status 501 - Method ? ????amp;_?Z?O??4??m??f ?L???Xe9??g?? You'd see that the problem was that Tomcat didn't interpret the method name right (the binary content of your request was apparently read instead, hence the garbage). My opinion right now is that your request (or only some of them) is not valid. At least you'll have to produce a valid request example if you want to keep the bug open (or of course, you can investigate and try to see what's wrong). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 20850] - POST is not defined in RFC 2068 and is not supported by the Servlet API
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 11:29 PM Subject: DO NOT REPLY [Bug 20850] - POST is not defined in RFC 2068 and is not supported by the Servlet API DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20850. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20850 POST is not defined in RFC 2068 and is not supported by the Servlet API --- Additional Comments From [EMAIL PROTECTED] 2003-06-18 06:29 --- If you notice the response: HTTP Status 501 - Method ? ????amp;_?Z?O??4??m??f ?L???Xe9??g?? You'd see that the problem was that Tomcat didn't interpret the method name right (the binary content of your request was apparently read instead, hence the garbage). My opinion right now is that your request (or only some of them) is not valid. At least you'll have to produce a valid request example if you want to keep the bug open (or of course, you can investigate and try to see what's wrong). I don't think that you've really read the stack-trace. This is happening well into the Servlet.service method, so Coyote has obviously read the method fine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 20850] - POST is not defined in RFC 2068and is not supported by the Servlet API
Bill Barker wrote: I don't think that you've really read the stack-trace. This is happening well into the Servlet.service method, so Coyote has obviously read the method fine. Hmmm, I don't think so: service does the request name dispatching. And the status returned is 501, not 500. The read timeout may not occur on the same request. All in all, I'll leave to the reporter that he's sending valid requests. I think the report is bogus :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 20850] - POST is not defined in RFC 2068and is not supported by the Servlet API
Just as an idea of sb that does not know nearly anything about tomcat internals. May it be a question about request pipelining? Something about overwriting a buffer that is needed later, or some similar issue... HTH, Antonio Fiol Remy Maucherat wrote: Bill Barker wrote: I don't think that you've really read the stack-trace. This is happening well into the Servlet.service method, so Coyote has obviously read the method fine. Hmmm, I don't think so: service does the request name dispatching. And the status returned is 501, not 500. The read timeout may not occur on the same request. All in all, I'll leave to the reporter that he's sending valid requests. I think the report is bogus :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 20850] - POST is not defined in RFC 2068 and is not supported by the Servlet API
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 11:47 PM Subject: Re: DO NOT REPLY [Bug 20850] - POST is not defined in RFC 2068 and is not supported by the Servlet API Bill Barker wrote: I don't think that you've really read the stack-trace. This is happening well into the Servlet.service method, so Coyote has obviously read the method fine. Hmmm, I don't think so: service does the request name dispatching. And the status returned is 501, not 500. The read timeout may not occur on the same request. All in all, I'll leave to the reporter that he's sending valid requests. I think the report is bogus :) Without more details from the reporter, I certainly wasn't going to investigate it further :). At first glance, it just looked to me like one of the (few) cases where disableUploadTimeout should be false. However, I can't explain why this should give a 501 instead of a 500. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20853] New: - JSP responds to TRACE method in the same way as to GET method.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20853. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20853 JSP responds to TRACE method in the same way as to GET method. Summary: JSP responds to TRACE method in the same way as to GET method. Product: Tomcat 3 Version: 3.3.1 Final Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When you send a request for JSP like: TRACE /index.jsp HTTP/1.0 Then the tomcat responds in just the same way as to GET method. The web server should responds the entire request message sent from the client encaplulated in the body whose content type is message/http, according to RFC2616. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20853] - JSP responds to TRACE method in the same way as to GET method.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20853. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20853 JSP responds to TRACE method in the same way as to GET method. --- Additional Comments From [EMAIL PROTECTED] 2003-06-18 07:32 --- This one is somewhat problematical with the spec. The JSP-1.1 Spec strongly suggests that the _jspservice method should be invoked from the Servlet.service method (which would forbid the container to support HEAD/TRACE/etc). While I think about it, I'm going to leave this open. However, I don't really see that much room in the spec for creative interpretations. The likely result of this bug is INVALID. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.3] Tag soon, 5.0 release plan
Remy Maucherat wrote: Shapira, Yoav wrote: Howdy, complete. What's missing is better docs, and lots of tweaks and fixes. I'd like to help with the docs. Can you prioritize what docs you think need work (or need to be written from scratch)? I actually have tomcat commit access already, so there should be no delay like with commons-modeler ;( Sure. Well, I was thinking writing new docs on setup and run would be useful. It's not only the basics. It should talk about using commons-daemon to run on Unix, and other stuff. Other docs about the new features are welcome also: - new monitoring features (JMX, how to use MC4J with TC, etc) Remmy, recently you wrote that it would be nice to ship with JMX 1.2 + a JSR 160 implementation if possible. Do you think it will be possible to get this from MX4J? Or is it possible to use JMX1.2 RI + JSR160 RI (when it will be finalized)? Radim - updates for the deployer tweaks and improvements - etc I think any useful docs will help, so feel free to contribute whatever you'd like ;-) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20853] - JSP responds to TRACE method in the same way as to GET method.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20853. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20853 JSP responds to TRACE method in the same way as to GET method. --- Additional Comments From [EMAIL PROTECTED] 2003-06-18 07:39 --- I forgot to mention that you are free to use the [EMAIL PROTECTED] extend=com.myfirm.mypackage.MyJspPage % which extends HttpServlet. This is what I'm currently using. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20859] New: - Double '=' in cataline.sh. (-Djava.securty.policy==$CATA...)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20859. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20859 Double '=' in cataline.sh. (-Djava.securty.policy==$CATA...) Summary: Double '=' in cataline.sh. (- Djava.securty.policy==$CATA...) Product: Tomcat 4 Version: 4.1.24 Platform: All OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In catalina.sh this line is wrong: -Djava.security.policy==$CATALINA_BASE/conf/catalina.policy There is a double '='. This line occurs several times. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20859] - Double '=' in cataline.sh. (-Djava.securty.policy==$CATA...)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20859. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20859 Double '=' in cataline.sh. (-Djava.securty.policy==$CATA...) --- Additional Comments From [EMAIL PROTECTED] 2003-06-18 09:39 --- Created an attachment (id=6867) Fix for double '='. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20859] - Double '=' in cataline.sh. (-Djava.securty.policy==$CATA...)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20859. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20859 Double '=' in cataline.sh. (-Djava.securty.policy==$CATA...) [EMAIL PROTECTED] changed: What|Removed |Added Keywords||PatchAvailable --- Additional Comments From [EMAIL PROTECTED] 2003-06-18 09:40 --- Added a fix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20860] New: - JDBCRealm looses database connection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20860. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20860 JDBCRealm looses database connection Summary: JDBCRealm looses database connection Product: Tomcat 4 Version: 4.1.24 Platform: All OS/Version: All Status: NEW Severity: Critical Priority: Other Component: Catalina:Modules AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If JDBCRealm runs for a while it looses its connection. I found a little bug and made a patch. I will attach it here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20860] - JDBCRealm looses database connection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20860. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20860 JDBCRealm looses database connection --- Additional Comments From [EMAIL PROTECTED] 2003-06-18 10:10 --- Created an attachment (id=6868) Add isClosed() check. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20860] - JDBCRealm looses database connection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20860. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20860 JDBCRealm looses database connection [EMAIL PROTECTED] changed: What|Removed |Added Keywords||PatchAvailable - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
a question about web service
Dear all: I user JWSDP(JAVA Web Service Development Pack)with tomcat to develop web service. I encounter a difficult problem. # Web Service provider) All things go well #Client Side)= the program to call web service. I write a client side program to call web service method. When I use ant to run it,every thing is correct,but I write a jsp/servlet page to call the program,the method always return null. I don't konw what happened ? There is no error in compile,I just can't invoke web service method by servlet. [WEB--INF] ¢u¢wclasses ¢x ¢|¢wAuthenticate.class =my servlet progrqam ¢x ¢u¢wlib |__ssloss-client.jar = generate by ant jar-client
[GUMP] Build Failure - jakarta-tomcat-5
This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2003-06-18/jakarta-tomcat-5.html Buildfile: build.xml prepare-release: [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0 [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0/bin [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0/src init: [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build/classes [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build/server/lib [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib deploy-static: [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/server/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/server/lib BUILD FAILED /home/rubys/jakarta/jakarta-tomcat-5/build.xml:154: Warning: Could not find file /usr/local/commons-daemon/bin/jsvc.tar.gz to copy. Total time: 2 seconds - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5 examples webapp
Howdy, I just checked out jakarta-tomcat-5 from CVS, looking for the examples webapp. I can't find it -- am I being blind? (It's happened before ;)) I'd like to add ServletRequestListener, ServletRequestAttributeListener examples. I have them ready to commit but was surprised to not find the examples webapp in the jakarta-tomcat-5 module... Yoav Shapira = Yoav Shapira [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DataSource realm, apply fix for 16316 bug, still not working ?
You need to configure the datasource you're using for authentication in GlobalNamingResources section of server.xml, not in your application context. -Original Message- Basicaly my own Realm implementation is copy/paste DataSourceRealm, I just changed preparedRoles and preparedCredentials in start() and also modified hasRole(Principal principal, String role) for my needs, but exception that I get is when opening DataSource which is defined in Context, it seemes that Context is not started yet when opening DB connection from Realm ? -- Nicholas Sushkin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5 examples webapp
They are in jakarta-servletapi-5 -Tim Yoav Shapira wrote: Howdy, I just checked out jakarta-tomcat-5 from CVS, looking for the examples webapp. I can't find it -- am I being blind? (It's happened before ;)) I'd like to add ServletRequestListener, ServletRequestAttributeListener examples. I have them ready to commit but was surprised to not find the examples webapp in the jakarta-tomcat-5 module... Yoav Shapira = Yoav Shapira [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20850] - POST is not defined in RFC 2068 and is not supported by the Servlet API
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20850. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20850 POST is not defined in RFC 2068 and is not supported by the Servlet API [EMAIL PROTECTED] changed: What|Removed |Added Severity|Critical|Minor --- Additional Comments From [EMAIL PROTECTED] 2003-06-18 11:42 --- aaargh - my bad, I was calling HttpEndRequest after the data POST but BEFORE receiving the tomcat response for the post! still doesnt explain why it works sometimes, very reliably in some cases. data was already sent prior to the HttpEndRequest, and the servlet doPOST method already well under way so I dont understand how this can be a misinterpretation of what method to call. an unexpected situation serverside I agree, perhaps now it can be handled a bit better anyway. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache 2 and mod_jk and mod_dir doesn't works
Hi to all, DirectoryIndex doesn't works anymore with mod_jk (1.2.4) and mod_dir from Apache 2.0.46. I set the JkOptions +ForwardDirectories in a VirtualHost config. I could see that in jk_translate uri_map is called and find the correct worker, but jk_handler is never called and as such the URI is not forward to tomcat. In my httpd.conf I set : DirectoryIndex index.jsp What could be broken - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] fix type mismatch in apache-2.0/mod_jk.c
3rd parm to apr_file_write() should be apr_size_t, not unsigned
Index: jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.76
diff -u -r1.76 mod_jk.c
--- jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c 16 May 2003 00:36:18
- 1.76
+++ jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c 18 Jun 2003 12:39:39
-
@@ -2032,7 +2032,7 @@
(l-level = level || level == JK_LOG_REQUEST_LEVEL)
l-logger_private what) {
unsigned sz = strlen(what);
-unsigned wrote = sz;
+apr_size_t wrote = sz;
char error[256];
if(sz) {
apr_status_t status;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] make sure mod_jk for Apache 2 is linked like apxs would havedone it
This fixes mod_jk segfaults when gcc is used to build mod_jk with gcc on
AIX. Currently, the -brtl ld flag is missing. Linking with apxs takes
care of that and, in general, can clear up other differences.
According to the comment, apxs wasn't used because it compiles all files
every time, but passing in .lo files instead of .c files will do the
right thing and keep some unnecessary details out of the mod_jk build.
Also added was a comment to mention why repeatedly running make will
keep attempting to create mod_jk (unsucessfully).
Index: jakarta-tomcat-connectors/jk/native/apache-2.0/Makefile.in
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/native/apache-2.0/Makefile.in,v
retrieving revision 1.15
diff -u -r1.15 Makefile.in
--- jakarta-tomcat-connectors/jk/native/apache-2.0/Makefile.in 9 Sep 2002 15:35:49
- 1.15
+++ jakarta-tomcat-connectors/jk/native/apache-2.0/Makefile.in 18 Jun 2003 12:40:03
-
@@ -59,11 +59,13 @@
@echo
Dynamic .so file
-# APXS will compile every file, this is derived from apxs
+# use APXS to link since it includes any special ldflags
mod_jk.la: mod_jk.lo $(APACHE_OBJECTS)
- $(LIBTOOL) --mode=link ${COMPILE} -o $@ -module -rpath ${libexecdir}
-avoid-version mod_jk.lo $(APACHE_OBJECTS)
+ $(APXS) -o $@ mod_jk.lo $(APACHE_OBJECTS)
+# this doesn't work on every platform, since libtool sometimes
+# will install foo.la as libfoo.so or libfoo.dl
mod_jk.so: mod_jk.la
$(LIBTOOL) --mode=install cp $ `pwd`/$@
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] make sure mod_jk for Apache 2 is linked like apxs wouldhave done it
Jeff Trawick wrote:
This fixes mod_jk segfaults when gcc is used to build mod_jk with gcc on
AIX. Currently, the -brtl ld flag is missing. Linking with apxs takes
care of that and, in general, can clear up other differences.
According to the comment, apxs wasn't used because it compiles all files
every time, but passing in .lo files instead of .c files will do the
right thing and keep some unnecessary details out of the mod_jk build.
Also added was a comment to mention why repeatedly running make will
keep attempting to create mod_jk (unsucessfully).
Thanks Jeff,
Still happy to see one of the Apache 2.0 main developpers fixing taking
care of our little module ;)
BTW, I've got a fix for the mod_dir problem with mod_jk and like to see
your comment about it ...
--- apache-2.0/mod_jk.c.old Wed Jun 18 14:54:46 2003
+++ apache-2.0/mod_jk.c Wed Jun 18 14:55:56 2003
@@ -2271,8 +2271,11 @@
apr_table_setn(r-notes, JK_WORKER_ID, worker);
/* This could be a sub-request, possibly from mod_dir */
-if(r-main)
+if(r-main) {
+r-main-handler=apr_pstrdup(r-pool,JK_HANDLER);
+r-main-uri=apr_pstrdup(r-pool,r-uri);
apr_table_setn(r-main-notes, JK_WORKER_ID, worker);
+}
return OK;
} else if(conf-alias_dir != NULL) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache 2 and mod_jk and mod_dir doesn't works
Henri Gomez wrote: Hi to all, DirectoryIndex doesn't works anymore with mod_jk (1.2.4) and mod_dir from Apache 2.0.46. I set the JkOptions +ForwardDirectories in a VirtualHost config. I could see that in jk_translate uri_map is called and find the correct worker, but jk_handler is never called and as such the URI is not forward to tomcat. In my httpd.conf I set : DirectoryIndex index.jsp Ok, I found a possible fix, see my previous mail to Jeff Trawick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
hgomez 2003/06/18 06:13:17
Modified:jk/native/apache-2.0 mod_jk.c
Log:
3rd parm to apr_file_write() should be apr_size_t, not unsigned.
Provided by Jeff Trawick
Revision ChangesPath
1.77 +2 -2 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.76
retrieving revision 1.77
diff -u -r1.76 -r1.77
--- mod_jk.c 16 May 2003 00:36:18 - 1.76
+++ mod_jk.c 18 Jun 2003 13:13:16 - 1.77
@@ -2032,7 +2032,7 @@
(l-level = level || level == JK_LOG_REQUEST_LEVEL)
l-logger_private what) {
unsigned sz = strlen(what);
-unsigned wrote = sz;
+apr_size_t wrote = sz;
char error[256];
if(sz) {
apr_status_t status;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
hgomez 2003/06/18 06:17:18
Modified:jk/native/apache-2.0 mod_jk.c
Log:
Fix for mod_dir/mod_jk, now the DirectoryIndex directive will be correctly handled
and forwarded
Revision ChangesPath
1.78 +6 -2 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.77
retrieving revision 1.78
diff -u -r1.77 -r1.78
--- mod_jk.c 18 Jun 2003 13:13:16 - 1.77
+++ mod_jk.c 18 Jun 2003 13:17:17 - 1.78
@@ -2271,8 +2271,12 @@
apr_table_setn(r-notes, JK_WORKER_ID, worker);
/* This could be a sub-request, possibly from mod_dir */
-if(r-main)
+/* Also set the HANDLER and uri for subrequest */
+if(r-main) {
+r-main-handler=apr_pstrdup(r-pool,JK_HANDLER);
+r-main-uri=apr_pstrdup(r-pool,r-uri);
apr_table_setn(r-main-notes, JK_WORKER_ID, worker);
+}
return OK;
} else if(conf-alias_dir != NULL) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Request inclusion of new Valve
I have developed a number of Tomcat applications. In most of them I do my own user authentication via some web-form page. While this works great, I would like to have the username included in the access log. I've written a very simple valve that takes the Principal from the current session and sets it as the User Principal for the HTTP Request. This way, the user name will be saved with the access log record. I would like to know if it could be added as a standard valve in a future release. Thanks David R Robison Open Roads Consulting, Inc. http://www.openroadsconsulting.com ?xml version=1.0? !DOCTYPE mbeans-descriptors PUBLIC -//Apache Software Foundation//DTD Model MBeans Configuration File http://jakarta.apache.org/commons/dtds/mbeans-descriptors.dtd; !-- Descriptions of JMX MBeans for ORCI $Id: orci-mbean-descriptors.xml,v 1.1 2003/06/17 19:32:51 drrobison Exp $ -- mbeans-descriptors mbean name=SessionPrincipalValve className=org.apache.catalina.mbeans.ClassNameMBean description=Valve that retrieves the Principal from a session attribute domain=Catalina group=Valve type=com.orci.tomcat.SessionPrincipalValve attribute name=className description=Fully qualified class name of the managed object type=java.lang.String writeable=false/ attribute name=debug description=The debugging detail level for this component type=int/ attribute name=sessionAttribute description=The session attribute containing the principal type=java.lang.String writeable=false/ /mbean /mbeans-descriptors - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache 2 and mod_jk and mod_dir doesn't works
Argh, that config option didn't get tested with the mod_dir/mod_alias change. With that bug fix, and the others recently submitted it looks like we will need to do another mod_jk 1.2 release in the next month. I can act as release manager again. Regards, Glenn Henri Gomez wrote: Henri Gomez wrote: Hi to all, DirectoryIndex doesn't works anymore with mod_jk (1.2.4) and mod_dir from Apache 2.0.46. I set the JkOptions +ForwardDirectories in a VirtualHost config. I could see that in jk_translate uri_map is called and find the correct worker, but jk_handler is never called and as such the URI is not forward to tomcat. In my httpd.conf I set : DirectoryIndex index.jsp Ok, I found a possible fix, see my previous mail to Jeff Trawick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20816] - Realm Authentication does not restore Original POST request.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20816. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20816 Realm Authentication does not restore Original POST request. [EMAIL PROTECTED] changed: What|Removed |Added Severity|Critical|Blocker Priority|Other |High - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache 2 and mod_jk and mod_dir doesn't works
Glenn Nielsen wrote: Argh, that config option didn't get tested with the mod_dir/mod_alias change. Happy to help ;-) With that bug fix, and the others recently submitted it looks like we will need to do another mod_jk 1.2 release in the next month. Could we have a quick release, I need this one in production as soon as possible and my boss don't like to much CVS HEAD code on prod servers ;) I can act as release manager again. You've got my +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
hgomez 2003/06/18 08:48:15
Modified:jk/native/apache-2.0 mod_jk.c
Log:
Use the subreq pool
Provided by Jeff Trawick
Revision ChangesPath
1.79 +3 -3 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.78
retrieving revision 1.79
diff -u -r1.78 -r1.79
--- mod_jk.c 18 Jun 2003 13:17:17 - 1.78
+++ mod_jk.c 18 Jun 2003 15:48:14 - 1.79
@@ -2273,8 +2273,8 @@
/* This could be a sub-request, possibly from mod_dir */
/* Also set the HANDLER and uri for subrequest */
if(r-main) {
-r-main-handler=apr_pstrdup(r-pool,JK_HANDLER);
-r-main-uri=apr_pstrdup(r-pool,r-uri);
+r-main-handler=apr_pstrdup(r-main-pool,JK_HANDLER);
+r-main-uri=apr_pstrdup(r-main-pool,r-uri);
apr_table_setn(r-main-notes, JK_WORKER_ID, worker);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Apache 2 and mod_jk and mod_dir doesn't works
Glenn Nielsen wrote With that bug fix, and the others recently submitted it looks like we will need to do another mod_jk 1.2 release in the next month. I can act as release manager again. Cool, but why to wait for the next mont? Can we do it now? I have the build environment set up an ready, but who knows what will happen next month? We may even get to war with the Klingons ;). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache 2 and mod_jk and mod_dir doesn't works
Henri Gomez wrote: Glenn Nielsen wrote: Argh, that config option didn't get tested with the mod_dir/mod_alias change. Happy to help ;-) With that bug fix, and the others recently submitted it looks like we will need to do another mod_jk 1.2 release in the next month. Could we have a quick release, I need this one in production as soon as possible and my boss don't like to much CVS HEAD code on prod servers ;) Sure, I'm up for another quick release. We will need to make sure the 3-4 recent patches get committed and tested first. Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19701] - array of custom class cannot be serialized in session persistance
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19701. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19701 array of custom class cannot be serialized in session persistance --- Additional Comments From [EMAIL PROTECTED] 2003-06-18 18:22 --- Hey guys, is this being looked into at all? Is more info needed? Or am I doing something wrong and this really isn't a bug at all - in which case can someone point me in the right direction please? Thanks Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20885] New: - contradiction in doc w.r.t. manager app reload command
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20885. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20885 contradiction in doc w.r.t. manager app reload command Summary: contradiction in doc w.r.t. manager app reload command Product: Tomcat 4 Version: 4.1.24 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Webapps:Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The build.xml.txt file included in the 4.1.24 distribution contains the following statment: !-- The reload target tells the specified Tomcat 4 installation to dynamically reload this web application, to reflect changes in the underlying classes or the web.xml deployment descriptor. -- However, the Manager-App HOW-TO Guide says: NOTE: The /WEB-INF/web.xml web application configuration file is not reread on a reload. If you have made changes to your web.xml file you must stop then start the web application. These two statements contradict one another w.r.t. how reload handles changes in the web.xml file. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20886] New: - web.xml: servlet param: fork==true results in no BuildException being thrown
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20886. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20886 web.xml: servlet param: fork==true results in no BuildException being thrown Summary: web.xml: servlet param: fork==true results in no BuildException being thrown Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Linux Kernel: 2.4 java version 1.4.1_03 in /usr/local/tomcat/conf/web.xml you use the default (fork=true) setting, then you don't get any BuildException from the compile phase and you only get an Internal Error 500 org.apache.jasper.JasperException: Unable to compile class for JSP at org.apache.jasper.JspCompilationContext.load(JspCompilationContext.java:500) at org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:150) which comes from the fact that it couldn't find a .class file. you don't get the nice compiler error showing you where the problem in your code was. if you have in your /usr/local/tomcat/conf/web.xml the following: servlet servlet-namejsp/servlet-name servlet-classorg.apache.jasper.servlet.JspServlet/servlet-class init-param param-namelogVerbosityLevel/param-name param-valueINFORMATION/param-value /init-param init-param!-- VERY IMPORTANT set to false otherwise, no compile errs -- param-namefork/param-name param-valuefalse/param-value /init-param load-on-startup3/load-on-startup /servlet Note that this does not seem to be a problem on windows boxes, nor on vanilla Redhat 7.2 platforms. It only seems to happen on our systems which have a Redhat 7.0 base with a new kernel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/conf web.xml
remm2003/06/18 13:50:27 Modified:catalina/src/conf web.xml Log: - Fork set to true is a good production setting in many cases, but it suffers (according to user reports) from problems on Windows (which I have witnessed), so it is not a very good default value. - Note: This *might* be caused by Ant bugs, but I'm not too sure about that. Revision ChangesPath 1.20 +4 -0 jakarta-tomcat-catalina/catalina/src/conf/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/web.xml,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- web.xml 17 Jun 2003 01:31:11 - 1.19 +++ web.xml 18 Jun 2003 20:50:27 - 1.20 @@ -183,6 +183,10 @@ param-namelogVerbosityLevel/param-name param-valueWARNING/param-value /init-param +init-param +param-namefork/param-name +param-valuefalse/param-value +/init-param load-on-startup3/load-on-startup /servlet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/conf web.xml
remm2003/06/18 13:52:54 Modified:catalina/src/conf web.xml Log: - Fork set to true is a good production setting in many cases, but it suffers (according to user reports) from problems on Windows (which I have witnessed), so it is not a very good default value. - Note: This *might* be caused by Ant bugs, but I'm not too sure about that. - Port patch. Revision ChangesPath 1.50 +4 -0 jakarta-tomcat-4.0/catalina/src/conf/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v retrieving revision 1.49 retrieving revision 1.50 diff -u -r1.49 -r1.50 --- web.xml 8 Jun 2003 18:20:36 - 1.49 +++ web.xml 18 Jun 2003 20:52:54 - 1.50 @@ -159,6 +159,10 @@ param-namelogVerbosityLevel/param-name param-valueWARNING/param-value /init-param +init-param +param-namefork/param-name +param-valuefalse/param-value +/init-param load-on-startup3/load-on-startup /servlet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20894] New: - body-content value of JSP should be error if SimpleTag
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20894. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20894 body-content value of JSP should be error if SimpleTag Summary: body-content value of JSP should be error if SimpleTag Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] According to JSP 2.0 PFD3, JSP.7.1.5, The body of a Simple Tag, if present, is translated into a JSP Fragment and passed to the setJspBody method. According to JSP 2.0 PFD3, JSP.7.1.6, A translation error must occur if a piece of JSP code that is to be translated into a JSP Fragment contains scriptlets or scriptlet expressions. There is nothing that explicitly requires that a body-content of JSP in the TLD for a SimpleTag must produce an error. However, this is technically invalid, and the JSP 2.0 specification will now say that it such a TLD will be considered invalid. It would be very helpful for tag library developers if Tomcat can flag such an error right away and indicate that the TLD is invalid for that reason. This can take the form of a translation error, for example. This would be symmetrical with the current treatment of body-content=JSP in Tag Files (which is currently explicitly required to produce a translation error). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Question about session
Hello All, I have used %@ page session=false % to set the page not to join session, but when I use HttpSession session = request.getSession(false) to get session, I still can get the session that created before. Do you think it is a correct status? Why? Thanks. %@ page session=false % % HttpSession session = request.getSession(false); % Regards, Xiaojing - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about session
- Original Message - From: Cui Xiaojing-a13339 [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 7:38 PM Subject: Question about session Hello All, I have used %@ page session=false % to set the page not to join session, but when I use HttpSession session = request.getSession(false) to get session, I still can get the session that created before. Do you think it is a correct status? Why? Thanks. Yes, this is the correct status. If you want to know why, either read the JSP spec, or ask the question on the tomcat-users list. %@ page session=false % % HttpSession session = request.getSession(false); % Regards, Xiaojing - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
