DO NOT REPLY [Bug 7826] New: - ManagerServlet response is garbled
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=7826. 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=7826 ManagerServlet response is garbled Summary: ManagerServlet response is garbled Product: Tomcat 4 Version: 4.0.4 Beta 2 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In Japanese environment, ManagerServlet responses garbled message when access management URL. (eg. http://localhost:8080/manager/list) The reason of this problem is ManagerServlet reesponse isnot set charset in contentType. If following patch applied to org/apache/catalina/servlets/ManagerServlet.jar, this problem is fixed: --- ManagerServlet.java.origWed Mar 27 03:12:46 2002 +++ ManagerServlet.java Mon Apr 8 15:37:50 2002 @@ -267,7 +267,7 @@ String war = request.getParameter(war); // Prepare our output writer to generate the response message -response.setContentType(text/plain); +response.setContentType(text/plain; charset=UTF-8); PrintWriter writer = response.getWriter(); // Process the requested command -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7827] New: - catalina.sh can't work in Cygwin environment
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=7827. 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=7827 catalina.sh can't work in Cygwin environment Summary: catalina.sh can't work in Cygwin environment Product: Tomcat 4 Version: 4.0.4 Beta 2 Platform: PC OS/Version: Windows 9x Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In Cygwin environment, catalina.sh cannot work. This reason is that CATALINA_BASE and CATALINA_TMPDIR isnot set appropriately for cygwin. If following patch applied to catalina.sh, this problem is fixed: --- catalina.sh.origWed Mar 27 03:12:50 2002 +++ catalina.sh Thu Apr 4 15:08:26 2002 @@ -64,7 +64,9 @@ # For Cygwin, ensure paths are in UNIX format before anything is touched if $cygwin; then [ -n $JAVA_HOME ] JAVA_HOME=`cygpath --unix $JAVA_HOME` + [ -n $CATALINA_BASE ] CATALINA_BASE=`cygpath --unix $CATALINA_BASE` [ -n $CATALINA_HOME ] CATALINA_HOME=`cygpath --unix $CATALINA_HOME` + [ -n $CATALINA_TMPDIR ] CATALINA_TMPDIR=`cygpath --unix $CATALINA_TMPDIR` [ -n $CLASSPATH ] CLASSPATH=`cygpath --path --unix $CLASSPATH` [ -n $JSSE_HOME ] JSSE_HOME=`cygpath --path --unix $JSSE_HOME` fi @@ -97,7 +99,9 @@ # For Cygwin, switch paths to Windows format before running java if $cygwin; then JAVA_HOME=`cygpath --path --windows $JAVA_HOME` + CATALINA_BASE=`cygpath --path --windows $CATALINA_BASE` CATALINA_HOME=`cygpath --path --windows $CATALINA_HOME` + CATALINA_TMPDIR=`cygpath --path --windows $CATALINA_TMPDIR` CLASSPATH=`cygpath --path --windows $CLASSPATH` JSSE_HOME=`cygpath --path --windows $JSSE_HOME` fi -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Apache 2.0.35 and mod_jk 1.2.0
I'll build rpm for Apache 2.0.35 and see if I've got the same problem - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Monday, April 08, 2002 7:14 AM To: Tomcat Dev List Subject: Apache 2.0.35 and mod_jk 1.2.0 I'm playing with Apache 2.0.35 and mod_jk 1.2.0 (from CVS) and I've encountered some weird behaviour in regards to DirectoryIndex directive of Apache. It seems that all *.jsp/*.vm (and whatever other extensions are mapped to Tomcat through mod_jk) have stopped working as default indexes for directories. This is what happens if one request the file /index.vm is requested: - [Mon Apr 08 14:49:01 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_t::map_uri_to_worker [Mon Apr 08 14:49:01 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI '/index.vm' [Mon Apr 08 14:49:01 2002] [jk_uri_worker_map.c (529)]: jk_uri_worker_map_t::map_uri_to_worker, Found a suffix match ajp13 - *.vm [Mon Apr 08 14:49:01 2002] [mod_jk.c (1223)]: Into handler r-proxyreq=0 r-handler=jakarta-servlet r-notes=136294352 worker=ajp13 [Mon Apr 08 14:49:01 2002] [jk_worker.c (132)]: Into wc_get_worker_for_name ajp13 [Mon Apr 08 14:49:01 2002] [jk_worker.c (136)]: wc_get_worker_for_name, done found a worker [Mon Apr 08 14:49:01 2002] [mod_jk.c (437)]: agsp=80 agsn=www.makita.dev hostn=www.makita.dev shostn=www.makita.dev cbsport=80 sport=0 [Mon Apr 08 14:49:01 2002] [jk_ajp_common.c (1352)]: Into jk_worker_t::get_endpoint - which is all nice and dandy. However, when the / is requested, it looks a bit different: - [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_ t::map_uri_to_worker [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI ' /' [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (570)]: jk_uri_worker_map_t::ma p_uri_to_worker, done without a match [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_ t::map_uri_to_worker [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI ' /index.shtml' [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (570)]: jk_uri_worker_map_t::ma p_uri_to_worker, done without a match [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_ t::map_uri_to_worker [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI ' /index.html' [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (570)]: jk_uri_worker_map_t::ma p_uri_to_worker, done without a match [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_ t::map_uri_to_worker [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI ' /index.jsp' [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (529)]: jk_uri_worker_map_t::map_uri_to_worker, Found a suffix match ajp13 - *.jsp [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_ t::map_uri_to_worker [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI ' /index.vm' [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (529)]: jk_uri_worker_map_t::map_uri_to_worker, Found a suffix match ajp13 - *.vm [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_ t::map_uri_to_worker [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI ' /index.php' [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (570)]: jk_uri_worker_map_t::ma p_uri_to_worker, done without a match [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_ t::map_uri_to_worker [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI ' /index.php3' [Mon Apr 08 14:49:40 2002] [jk_uri_worker_map.c (570)]: jk_uri_worker_map_t::ma p_uri_to_worker, done without a match - which all comes from here (defined in server config section of Apache 2.0): - IfModule mod_dir.c DirectoryIndex index.shtml index.html index.jsp index.vm index.php index.php /IfModule - However, /index.vm (which exists and works fine when called explicity), never gets called by mod_jk although the match for it is found (i.e. the *.vm match). I must be doing something silly... Apache is statically linked, if that makes any difference. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7759] - Reload an existing Application : KO
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=7759. 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=7759 Reload an existing Application : KO [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-04-08 08:38 --- I think there is a misunderstanding with my problem : It is not my application which fork new threads but Tomcat. My application is deployed with a file web.xml in which I precise, for each servlet, the attribute load-on-startup. My application is composed with 18 servlets. So, when I start Tomcat, 18 threads are created by Tomcat (one thread per servlet). I touch one servlet code, re-compile, re-deploy my application and then reload via the manager. 18 new threads are created BY TOMCAT (corresponding to the servlets) but the 18 old threads are still active. So, my application doesn't fork anything but TOMCAT FORK NEW THREADS for servlets. So it is the responsability of the container to cleanup its resources. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7829] New: - On redirect and close: Cannot find message associated with key 'responseStream.suspended'
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=7829.
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=7829
On redirect and close: Cannot find message associated with key
'responseStream.suspended'
Summary: On redirect and close: Cannot find message associated
with key 'responseStream.suspended'
Product: Tomcat 4
Version: 4.0.3 Final
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
[TC4.0.3, Jre 1.4.0, Linux 7.2]
If you after a redirect try to close the output stream as in:
try {
// Getting encoding
String encoding = res.getCharacterEncoding();
// Setting content type
res.setContentType(text/html; charset= + encoding);
// Getting the OutputStream (just to be able to close it)
OutputStream out = res.getOutputStream();
// Sending the redirect
res.sendRedirect(Configuration.getDEFAULT_MAINPAGE());
// close output stream
out.close();
}
catch (IOException e) {
throw new ServerException(Got IOException while trying to redirect
user to [+Configuration.getDEFAULT_MAINPAGE()+]., e);
}
You get weird errors. On 4.0.1, I had to do this to be sure that the client
exited, a load tester package (loadsim, Java stuff, based on some Apache stuff,
using java.net.HttpConnection or whatever it's called) I used didn't let go
(but the web browsers did) unless I did this.
Doing this with 4.0.3 on Sun's JRE 1.4.0 I get this error:
[Nested Exception] this: com.corelets.api.ServerException: Got IOException while
trying to redirect user to [Renderer]., nested: java.io.IOException: Cannot find
message associated with key 'responseStream.suspended'
at com.corelets.servlets.Parameters.doCCSGet(Parameters.java:146)
at com.corelets.servlets.CCSServlet.callServiceMethod(CCSServlet.java:698)
This is the nested exception:
java.io.IOException: Cannot find message associated with key
'responseStream.suspended'
at
org.apache.catalina.connector.http.HttpResponseStream.close(HttpResponseStream.java:202)
at com.corelets.servlets.Parameters.doCCSGet(Parameters.java:143)
at com.corelets.servlets.CCSServlet.callServiceMethod(CCSServlet.java:698)
at com.corelets.servlets.CCSServlet.showAppropriatePage(CCSServlet.java:581)
at com.corelets.servlets.CCSServlet.process2(CCSServlet.java:413)
at com.corelets.servlets.CCSServlet.process(CCSServlet.java:300)
at com.corelets.servlets.CCSServlet.doGet(CCSServlet.java:177)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
..
Closing that stream is probably wrong, but the error wasn't exactly clear about
it. And the way it works have changed...
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
make path relative to server root in mod_jk2
Hi,
I have played a little with mod_jk2 and I have missed a feature: To get a path
relative to the server root.
For example in jk_workerEnv.c:
+++
if( configFile == NULL ) {
wEnv-config-setPropertyString( env, wEnv-config,
config.file,
conf/jk2.properties );
}
+++
It would be nice to have /usr/local/apache/conf/jk2.properties when httpd is
configured to be in /usr/local/apache (instead of /conf/jk2.properties in the
son processes...).
My first idea is to add makeRoot() in jk_ws_service_t. But I have the problem
that apache needs a pool (not a jk_pool) to call ap_server_root_relative().
Where could I get the pool?
Cheers
Jean-frederic
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Apache 2.0.35 and mod_jk 1.2.0
On Mon, 2002-04-08 at 18:12, GOMEZ Henri wrote: I'll build rpm for Apache 2.0.35 and see if I've got the same problem Thanks! Bojan PS. BTW, this was on RedHat, so it'll be the proper test. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: make path relative to server root in mod_jk2
Hi JF It would be nice to have /usr/local/apache/conf/jk2.properties when httpd is configured to be in /usr/local/apache (instead of /conf/jk2.properties in the son processes...). My first idea is to add makeRoot() in jk_ws_service_t. But I have the problem that apache needs a pool (not a jk_pool) to call ap_server_root_relative(). Where could I get the pool? Why not just use a char * which will be initialised by mod_jk for AP1.3/2.0 and later for IIS/iPlanet ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: make path relative to server root in mod_jk2
GOMEZ Henri wrote: Hi JF It would be nice to have /usr/local/apache/conf/jk2.properties when httpd is configured to be in /usr/local/apache (instead of /conf/jk2.properties in the son processes...). My first idea is to add makeRoot() in jk_ws_service_t. But I have the problem that apache needs a pool (not a jk_pool) to call ap_server_root_relative(). Where could I get the pool? Why not just use a char * which will be initialised by mod_jk for AP1.3/2.0 and later for IIS/iPlanet ;) Ok... But where should we stored it? Like a property server.root in jk_workerEnv_t? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7827] - catalina.sh can't work in Cygwin environment
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=7827. 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=7827 catalina.sh can't work in Cygwin environment [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-04-08 09:56 --- I find it counter productive to put tons of hacks in the Unix scripts just to support Cygwin. The .bat works perfectly well when run from Cygwin, so please use it to run Tomcat. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7829] - On redirect and close: Cannot find message associated with key 'responseStream.suspended'
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=7829. 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=7829 On redirect and close: Cannot find message associated with key 'responseStream.suspended' [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Minor --- Additional Comments From [EMAIL PROTECTED] 2002-04-08 10:02 --- After the redirect, the response is finished, so your stream is invalid (that's why you get the exception). The message string has been forgotten, apparently. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7759] - Reload an existing Application : KO
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=7759. 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=7759 Reload an existing Application : KO [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-04-08 10:07 --- Tomcat does not fork a thread to run a load-on-startup servlet. Instead, all of them are run in sequence by the thread responsible for initializing the host. Tomcat DOES NOT associate one thread per servlet or something like that. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: make path relative to server root in mod_jk2
Why not just use a char * which will be initialised by mod_jk for AP1.3/2.0 and later for IIS/iPlanet ;) Ok... But where should we stored it? Like a property server.root in jk_workerEnv_t? Yes -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7831] New: - [PATCH] JNDIRealm does not work with CLIENT-CERT auth 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=7831. 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=7831 [PATCH] JNDIRealm does not work with CLIENT-CERT auth method Summary: [PATCH] JNDIRealm does not work with CLIENT-CERT auth method Product: Tomcat 4 Version: Nightly Build Platform: All OS/Version: All Status: UNCONFIRMED Severity: Normal Priority: Other Component: Catalina:Modules AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Similar to bug 4352, which details the same problem for JDBCRealm. When authenticating the user with certificates, authenticate(X509Certificate certs[]) in org.apache.catalina.realm.RealmBase calls getPrincipal(). This method is supposed to find the user and their roles from the realm. Unfortunately, getPrincipal() in org.apache.catalina.realm.JNDIRealm always returns null and so authentication always fails. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7831] - [PATCH] JNDIRealm does not work with CLIENT-CERT auth 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=7831. 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=7831 [PATCH] JNDIRealm does not work with CLIENT-CERT auth method --- Additional Comments From [EMAIL PROTECTED] 2002-04-08 12:10 --- Created an attachment (id=1499) JNDIRealm patch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7831] - [PATCH] JNDIRealm does not work with CLIENT-CERT auth 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=7831. 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=7831 [PATCH] JNDIRealm does not work with CLIENT-CERT auth method --- Additional Comments From [EMAIL PROTECTED] 2002-04-08 12:15 --- I think/hope the only contentious issue in the patch is: return (new GenericPrincipal(this, username, null , roles)) Javadoc for GenericPrincipal describes the password string as 'Credentials used to authenticate this user'. I set it to null rather than trying finding to it from the realm because this is not necessarily what the user may have provided for authentication, e.g the user didn't provide a password in the CLIENT-CERT case. This probably doesn't make much difference from trying to get it from the realm but I think it preserves the semantics better. Have I misunderstood? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[GUMP] Build Failure - Tomcat 3.x
This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/2002-04-08/jakarta-tomcat.html Buildfile: build.xml detect: msg.jdk12: [echo] Detected JDK1.2 msg.jsse: [echo] Detected JSSE msg.puretls: msg.commons-dbcp: init: prepare.dirs: [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf/auto [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/apps [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/logs [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/webapps [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/modules [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/native [copy] Copying 10 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [copy] Copying 18 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf [copy] Copying 44 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc [copy] Copying 85 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/native [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/apps [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common prepare.jaxp101: include.jaxp: [echo] Including jaxp.jar [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container prepare.jaxp11: [echo] Installing JAXP-1.1 [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container prepare.xerces: prepare.jaxp: prepare.http11: prepare: tomcat_util: [javac] Compiling 46 source files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [javac] /home/rubys/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/util/hooks/Hooks.java:65: cannot resolve symbol [javac] symbol : class IntrospectionUtils [javac] location: package util [javac] import org.apache.tomcat.util.IntrospectionUtils; [javac] ^ [javac] /home/rubys/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/util/io/FileUtil.java:70: package org.apache.tomcat.util.log does not exist [javac] import org.apache.tomcat.util.log.*; [javac] ^ [javac] /home/rubys/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/util/io/FileUtil.java:131: cannot resolve symbol [javac] symbol : class Log [javac] location: class org.apache.tomcat.util.io.FileUtil [javac] static Log loghelper = Log.getLog(tc/FileUtil, FileUtil); [javac]^ [javac] /home/rubys/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/util/qlog/LogDaemon.java:65: cannot resolve symbol [javac] symbol : class SimplePool [javac] location: package collections [javac] import org.apache.tomcat.util.collections.SimplePool; [javac] ^ [javac] /home/rubys/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/util/qlog/LogDaemon.java:66: cannot resolve symbol [javac] symbol : class Queue [javac] location: package collections [javac] import org.apache.tomcat.util.collections.Queue; [javac] ^ [javac] /home/rubys/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/util/qlog/LogDaemon.java:75: cannot resolve symbol [javac] symbol : class Queue [javac] location: class org.apache.tomcat.util.qlog.LogDaemon [javac] private Queue logQueue = null; [javac] ^ [javac]
DO NOT REPLY [Bug 7759] - Reload an existing Application : KO
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=7759. 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=7759 Reload an existing Application : KO [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-04-08 13:34 --- Even if Tomcat does not fork a thread to run a load-on-startup servlet or something like that, after the reload of my application, the command ps -eaf|grep java give 18 more processes like this: /usr/share/jdk1.3.1_02/bin/i386/native_threads/java -Djava.security.policy==/usr/local/tomcat/conf/tomcat.policy -Dtomcat.home=/usr/local/tomcat org.apache.tomcat.startup.Main start If I repeat the operation, there are more and more processes. So, I don't know what is the solution but there is a problem UNresolved. note : there is the same problem in Tomcat3.3.1 (referenced in bug 7026) and Larry Isaacs agree with me. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
apr pools in mod_webapp
Hi, Sorry if this is a little off-topic I'm presentently trying to modifiy the mod_webapp source so that concurrent warp requests can be supported on NT. To do this, I'm implementing a pool of sockets per warp connection and each time a warp request is made a socket is acquired from the pool, used and then returned. This insures that only a single request is active on a socket at a time and so far the prototype I have is working and seems to address the problem. I've had a look at the apr documentation but it is pretty brief. I'm trying to get a proper understanding of how exactly the apr pool a.d.t. behaves and how memory is cleaned up with it. My understanding (so far) is that an apr pool essentially makes memory cleanup a bit easier by cleaning up all datastructures associated with it when it is destroyed. This removes the need to cleanup all datastructures individually and makes memory leaks less likely. As far as I can see the only way to cleanup a data structure associated with a pool is to free the entire pool. Is this correct? In this way, the pool does not behave like many common pool implementations which have alloc() and free() methods and are basically there to prevent memory allocation routine overhead. If anyone could fill me in on more details or point me to some documentation, that would be great! Thanks Simon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7759] - Reload an existing Application : KO
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=7759. 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=7759 Reload an existing Application : KO [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-04-08 14:01 --- He asked for a test case; he wasn't confirming the problem or anything. I went on and tested it with the examples webapp (made all servlets load-on- startup, and then touch things), and no threads were forked. Also, given that the implementation of TC 4 and TC 3 are completely different (except for Jasper), there is very little chance for such a huge identical bug to show up. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7690] - org.apache.coyote.tomcat4.CoyoteConnector logs all remote IP addresses as 127.0.0.1
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=7690. 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=7690 org.apache.coyote.tomcat4.CoyoteConnector logs all remote IP addresses as 127.0.0.1 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-04-08 14:22 --- It is fixed in Coyote 1.0 beta 5. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apr pools in mod_webapp
[EMAIL PROTECTED] wrote:
Hi,
Sorry if this is a little off-topic
That is not off-topic!
I'm presentently trying to modifiy the mod_webapp source so that concurrent
warp requests can be supported on NT. To do this, I'm implementing a pool
of sockets per warp connection and each time a warp request is made a socket
is acquired from the pool, used and then returned. This insures that only a
single request is active on a socket at a time and so far the prototype I
have is working and seems to address the problem.
Great! Could you send a diff -u of your changes?
I've had a look at the apr documentation but it is pretty brief. I'm trying
to get a proper understanding of how exactly the apr pool a.d.t. behaves and
how memory is cleaned up with it.
My understanding (so far) is that an apr pool essentially makes memory
cleanup a bit easier by cleaning up all datastructures associated with it
when it is destroyed. This removes the need to cleanup all datastructures
individually and makes memory leaks less likely. As far as I can see the
only way to cleanup a data structure associated with a pool is to free the
entire pool. Is this correct? In this way, the pool does not behave like
many common pool implementations which have alloc() and free() methods and
are basically there to prevent memory allocation routine overhead.
The best place to look is the APR sources.
The pools are a tree structure that allows easy cleanups.
For example if you allocate something in the request pool you are sure that the
memory is recycled at the end of the request.
Typicaly use it:
int toto(apr_pool_t p)
{
apr_pool_t *sp;
apr_pool_create(sp, p);
while (not finished) {
apr_pool_clear(sp); // the pool.
... // do what what you need with the sp pool.
}
apr_pool_destroy(sp); // free the memory.
}
The module that calls toto() could decide whether it needs to clean the pool or
not. Cleaning the p pool cleans the sp pool.
If anyone could fill me in on more details or point me to some
documentation, that would be great!
Thanks Simon
-- To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED] For additional commands,
e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apr pools in mod_webapp
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: My understanding (so far) is that an apr pool essentially makes memory cleanup a bit easier by cleaning up all datastructures associated with it when it is destroyed. This removes the need to cleanup all datastructures individually and makes memory leaks less likely. As far as I can see the only way to cleanup a data structure associated with a pool is to free the entire pool. Is this correct? Yessir, very In this way, the pool does not behave like many common pool implementations which have alloc() and free() methods and are basically there to prevent memory allocation routine overhead. Correct... If anyone could fill me in on more details or point me to some documentation, that would be great! You're pretty much right... Anyhow, pointer: a pool of sockets is different from an APR memory pool... You can _tie_ those two to provide a cleanup of sockets when the pool gets destroyed (then basically when everything goes down), but mostly, all the socketpool code needs to be written... And be sure to use the new locking mechanism in APR (threadproc locking, not apr_lock)... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7026] - AutoDeploy works bad
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=7026. 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=7026 AutoDeploy works bad --- Additional Comments From [EMAIL PROTECTED] 2002-04-08 15:38 --- SORRY : my test case was false : when I said the old native_threads java are still here and new ones are created it was not a problem with Tomcat BUT with my application : at the init of my servlet, I create a poolManager (which implements Runnable) but I never destroy it. So, when I reload my application, new poolManagers are created!! I have updated my application and I don't have this problem anymore :-) Sorry for the disturbance. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7759] - Reload an existing Application : KO
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=7759. 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=7759 Reload an existing Application : KO --- Additional Comments From [EMAIL PROTECTED] 2002-04-08 15:41 --- SORRY : you were right because my test case was false : when I said new native threads have been created it was not a problem with Tomcat BUT with my application : at the init of my servlet, I create a poolManager (which implements Runnable) but I never destroy it. So, when I reload my application, new poolManagers are created!! I have updated my application and I don't have this problem anymore :-) Sorry for the disturbance. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7026] - AutoDeploy works bad
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=7026. 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=7026 AutoDeploy works bad [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: make path relative to server root in mod_jk2
GOMEZ Henri wrote: Why not just use a char * which will be initialised by mod_jk for AP1.3/2.0 and later for IIS/iPlanet ;) Ok... But where should we stored it? Like a property server.root in jk_workerEnv_t? Yes Storing it in jk_config but how to get it back? Will not it be more easy to add a char* server_root to jk_workerEnv_t? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: make path relative to server root in mod_jk2
Ok... But where should we stored it? Like a property server.root in jk_workerEnv_t? Yes Storing it in jk_config but how to get it back? Will not it be more easy to add a char* server_root to jk_workerEnv_t? The simpler, the better. Not that I proposed initially something like this ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: make path relative to server root in mod_jk2
On Mon, 8 Apr 2002, jean-frederic clere wrote: It would be nice to have /usr/local/apache/conf/jk2.properties when httpd is configured to be in /usr/local/apache (instead of /conf/jk2.properties in the son processes...). My first idea is to add makeRoot() in jk_ws_service_t. But I have the problem that apache needs a pool (not a jk_pool) to call ap_server_root_relative(). Where could I get the pool? First, if you look in apache2/mod_jk.c, you'll find a serverRoot variable we set at init time ( with ap_server_root ). That is supposed to be used to resolve relative paths. Right now $(serverRoot)/conf/jk2.properties should work, and in time we can change all code that uses paths to check if it's relative and do it automatically. Personally I would like 'full paths', using a base variable - it's much easier to read/understand, but both should work. For the second question, if 'apr pools' are used to implement the jk_pool interface ( i.e. you are in apache2 env ) you can get the reference to the 'native' pool using jk_pool-_private; ( we probably need a way to detect this is indeed an apr_pool - like a 'type' in the jk_pool ). Eventually we'll have a jk_pool implemented on top of apache1.3 pools ( to get this working on apache1.3 ), and other servers don't need it. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: make path relative to server root in mod_jk2
On Mon, 8 Apr 2002 [EMAIL PROTECTED] wrote: My first idea is to add makeRoot() in jk_ws_service_t. But I have the problem that apache needs a pool (not a jk_pool) to call ap_server_root_relative(). Where could I get the pool? Actually, that would be a good idea too ( adding another method in jk_ws_service_t ). The server adapter should know how to do it and it is also supposed to be able to store references to server_rec (or other server specific data ). For pool - again, if a 'native pool' is used, the server adapter will store in in the private field of jk_pool, and if the 'base impl' of jk_pool is used - the adapter can still access server private data. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/manager/WEB-INF web.xml
craigmcc02/04/08 10:46:08
Modified:catalina/src/share/org/apache/catalina/servlets
LocalStrings.properties ManagerServlet.java
webapps/manager manager.xml
webapps/manager/WEB-INF web.xml
Log:
Implement a lookup mechanism to enumerate the security roles (and corresponding
descriptions) defined in the user database. This will be useful, for example,
in deployment tools that wish to create security-role-ref elements in the
web.xml file that link role names used in the web application to those that are
actually defined in the container.
Revision ChangesPath
1.15 +3 -0
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/LocalStrings.properties
Index: LocalStrings.properties
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/LocalStrings.properties,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- LocalStrings.properties 12 Mar 2002 21:14:15 - 1.14
+++ LocalStrings.properties 8 Apr 2002 17:46:08 - 1.15
@@ -34,6 +34,7 @@
managerServlet.removed=OK - Removed application at context path {0}
managerServlet.resourcesAll=OK - Listed global resources of all types
managerServlet.resourcesType=OK - Listed global resources of type {0}
+managerServlet.rolesList=OK - Listed security roles
managerServlet.sessiondefaultmax=Default maximum session inactive interval {0}
minutes
managerServlet.sessiontimeout={0} minutes:{1} sessions
managerServlet.sessions=OK - Session information for application at context path {0}
@@ -42,6 +43,8 @@
managerServlet.stopped=OK - Stopped application at context path {0}
managerServlet.undeployed=OK - Undeployed application at context path {0}
managerServlet.unknownCommand=FAIL - Unknown command {0}
+managerServlet.userDatabaseError=FAIL - Cannot resolve user database reference
+managerServlet.userDatabaseMissing=FAIL - No user database is available
webdavservlet.jaxpfailed=JAXP initialization failed
directory.filename=Filename
directory.lastModified=Last Modified
1.19 +63 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java
Index: ManagerServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- ManagerServlet.java 13 Mar 2002 01:26:49 - 1.18
+++ ManagerServlet.java 8 Apr 2002 17:46:08 - 1.19
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
1.18 2002/03/13 01:26:49 craigmcc Exp $
- * $Revision: 1.18 $
- * $Date: 2002/03/13 01:26:49 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
1.19 2002/04/08 17:46:08 craigmcc Exp $
+ * $Revision: 1.19 $
+ * $Date: 2002/04/08 17:46:08 $
*
*
*
@@ -73,8 +73,11 @@
import java.io.PrintWriter;
import java.net.URL;
import java.util.Enumeration;
+import java.util.Iterator;
+import javax.naming.InitialContext;
import javax.naming.NameClassPair;
import javax.naming.NamingEnumeration;
+import javax.naming.NamingException;
import javax.naming.directory.DirContext;
import javax.servlet.ServletException;
import javax.servlet.ServletInputStream;
@@ -88,9 +91,11 @@
import org.apache.catalina.Deployer;
import org.apache.catalina.Globals;
import org.apache.catalina.Host;
+import org.apache.catalina.Role;
import org.apache.catalina.Server;
import org.apache.catalina.ServerFactory;
import org.apache.catalina.Session;
+import org.apache.catalina.UserDatabase;
import org.apache.catalina.Wrapper;
import org.apache.catalina.core.StandardServer;
import org.apache.catalina.util.StringManager;
@@ -137,6 +142,9 @@
* lib/resources?type=/b - Enumerate the available global JNDI
* resources, optionally limited to those of the specified type
* (fully qualified Java class name), if available./li
+ * lib/roles/b - Enumerate the available security role names and
+ * descriptions from the user database connected to the codeusers/code
+ * resource reference.
* lib/sessions?path=/xxx/b - List session information about the web
* application attached to context path code/xxx/code for this
* virtual host./li
@@ -188,7 +196,7 @@
* /ul
*
* @author Craig R. McClanahan
- * @version $Revision: 1.18 $ $Date: 2002/03/13 01:26:49 $
+ * @version $Revision: 1.19 $ $Date: 2002/04/08
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs manager-howto.xml
craigmcc02/04/08 11:02:07 Modified:webapps/tomcat-docs manager-howto.xml Log: Update the Manager HOW-TO docs for the new /roles command. Revision ChangesPath 1.13 +55 -0 jakarta-tomcat-4.0/webapps/tomcat-docs/manager-howto.xml Index: manager-howto.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/manager-howto.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- manager-howto.xml 14 Mar 2002 22:20:18 - 1.12 +++ manager-howto.xml 8 Apr 2002 18:02:07 - 1.13 @@ -39,6 +39,7 @@ liList the available global JNDI resources, for use in deployment tools that are preparing codelt;ResourceLinkgt;/code elements nested in a codelt;Contextgt;/code deployment description./li +liList the available security roles defined in the user database./li liRemove an installed web application./li liStart a stopped application (thus making it available again)./li liStop an existing application (so that it becomes unavailable), but @@ -487,6 +488,60 @@ /subsection + + +subsection name=List Available Security Roles + +source +http://localhost:8080/manager/roles +/source + +pList the security role names (and corresponding descriptions) that are +available in the codeorg.apache.catalina.UserDatabase/code resource that +is linked to the codeusers/code resource reference in the web.xml file +for the Manager web application. This would typically be used, for example, +by a deployment tool that wanted to create +codelt;security-role-refgt;/code elements to map security role names +used in a web application to the role names actually defined within the +container./p + +pBy default, the codeusers/code resource reference is pointed at the +global codeUserDatabase/code resource. If you choose to utilize a +different user database per virtual host, you should modify the +codelt;ResourceLinkgt;/code element in the default +codemanager.xml/code context configuration file to point at the global +user database resource for this virtual host./p + +pWhen this command is executed, the first line of the response will be:/p +pre + OK - Listed security roles +/pre +pfollowed by one line for each security role. Each line is composed of +fields delimited by colon characters (:) as follows:/p +ul +liemSecurity Role Name/em - A security role name that is known to Tomcat +in the user database./li +liemDescription/em - Description of this security role (useful in +creating user interfaces for selecting roles./li +/ul + +pIf an error occurs, the response will start with codeFAIL/code and +include an error message. Possible causes for problems include:/p +ul +liemCannot resolve user database reference/em - A JNDI error prevented +the successful lookup of the codeorg.apache.catalina.UserDatabase/code +resource. Check the Tomcat log files for a stack trace associated with +this error./li +liemNo user database is available/em - You have not configured a resource +reference for the codeusers/code resource that points at an +appropriate user database instance. Check your codemanager.xml/code +file and ensure that you have created an appropriate +codelt;ResourceLinkgt;/code or +codelt;ResourceParamsgt;/code element for this resource./li +/ul + +/subsection + subsection name=Session Statistics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_pool_apr.c
costin 02/04/08 11:47:53 Added: jk/native2/common jk_pool_apr.c Removed: jk/native2/server/apache2 jk_pool_apr.c Log: Moved jk_pool_apr to common - it's not specific to apache2 ( but can be used with any other server, if apr is enabled ). If a server has 'native' pool, it should be used. If not, we should use apr if possible. If APR is not available - fallback to the old implementation. Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/native2/common/jk_pool_apr.c Index: jk_pool_apr.c === /* = * * * * The Apache Software License, Version 1.1 * * * * Copyright (c) 1999-2001 The Apache Software Foundation. * * All rights reserved.* * * * = * * * * Redistribution and use in source and binary forms, with or without modi- * * fication, are permitted provided that the following conditions are met: * * * * 1. Redistributions of source code must retain the above copyright notice * *notice, this list of conditions and the following disclaimer. * * * * 2. Redistributions in binary form must reproduce the above copyright * *notice, this list of conditions and the following disclaimer in the * *documentation and/or other materials provided with the distribution. * * * * 3. The end-user documentation included with the redistribution, if any, * *must include the following acknowlegement: * * * * This product includes software developed by the Apache Software * *Foundation http://www.apache.org/. * * * *Alternately, this acknowlegement may appear in the software itself, if * *and wherever such third-party acknowlegements normally appear. * * * * 4. The names The Jakarta Project, Jk, and Apache Software * *Foundation must not be used to endorse or promote products derived * *from this software without prior written permission. For written * *permission, please contact [EMAIL PROTECTED].* * * * 5. Products derived from this software may not be called Apache nor may * *Apache appear in their names without prior written permission of the * *Apache Software Foundation.* * * * THIS SOFTWARE IS PROVIDED AS IS AND ANY EXPRESSED OR IMPLIED WARRANTIES * * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY * * AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL * * THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY * * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN * * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * * POSSIBILITY OF SUCH DAMAGE. * * * * = * * * * This software consists of voluntary contributions made by many indivi- * * duals on behalf of the Apache Software Foundation. For more information * * on the Apache Software Foundation, please see http://www.apache.org/. * *
cvs commit: jakarta-tomcat-connectors/jk/native2/jni jk_jni_aprImpl.c
costin 02/04/08 12:17:35 Modified:jk/native2/jni jk_jni_aprImpl.c Added: jk/native2/common jk_shm.c Log: Initial ( and mostly untested ) shared memory code. It'll work only if APR is enabled ( like all 'advanced' features ). I also added some minimal code to support it from the java side - it's based on the rough 'long as void *' representation - not supposed to be visible from the user side, just to keep the C code simple while doing the data abstraction in java. As you may notice, there's no object interface yet - I'm still exploring how to implement this on top of 1.4 nio ( or something that is close as interface - obviously requiring 1.4 to use shmem and APR is not the best option :-) In any case, the goal is to have at least worker status exposed in a shared memory segment and java access to it. Long term this will be used for configuring multi-process servers ( i.e. apache ). Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/native2/common/jk_shm.c Index: jk_shm.c === /* = * * * * The Apache Software License, Version 1.1 * * * * Copyright (c) 1999-2001 The Apache Software Foundation. * * All rights reserved.* * * * = * * * * Redistribution and use in source and binary forms, with or without modi- * * fication, are permitted provided that the following conditions are met: * * * * 1. Redistributions of source code must retain the above copyright notice * *notice, this list of conditions and the following disclaimer. * * * * 2. Redistributions in binary form must reproduce the above copyright * *notice, this list of conditions and the following disclaimer in the * *documentation and/or other materials provided with the distribution. * * * * 3. The end-user documentation included with the redistribution, if any, * *must include the following acknowlegement: * * * * This product includes software developed by the Apache Software * *Foundation http://www.apache.org/. * * * *Alternately, this acknowlegement may appear in the software itself, if * *and wherever such third-party acknowlegements normally appear. * * * * 4. The names The Jakarta Project, Jk, and Apache Software * *Foundation must not be used to endorse or promote products derived * *from this software without prior written permission. For written * *permission, please contact [EMAIL PROTECTED].* * * * 5. Products derived from this software may not be called Apache nor may * *Apache appear in their names without prior written permission of the * *Apache Software Foundation.* * * * THIS SOFTWARE IS PROVIDED AS IS AND ANY EXPRESSED OR IMPLIED WARRANTIES * * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY * * AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL * * THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY * * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN * * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * * POSSIBILITY OF SUCH DAMAGE.
cvs commit: jakarta-tomcat build.xml
costin 02/04/08 12:44:28
Modified:.build.xml
Log:
Few simplifications:
- use the binary version of common-logging. It is trivial to override this
to build-from-source version ( for Gump ), but new users should have minimal
pain.
- call ant in j-t-c/util, don't assume j-t-c will be built first.
This preserves the original behavior ( checkout / build - no extra rules )
( I hope :-), except you must check out both j-t and j-t-c
Revision ChangesPath
1.167 +24 -11jakarta-tomcat/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat/build.xml,v
retrieving revision 1.166
retrieving revision 1.167
diff -u -r1.166 -r1.167
--- build.xml 8 Apr 2002 01:56:50 - 1.166
+++ build.xml 8 Apr 2002 19:44:28 - 1.167
@@ -79,12 +79,19 @@
property name=jtc.http11.home location=${jakarta-tomcat-connectors}/http11/
property name=jtc.http11.lib location=${jtc.http11.home}/build/lib/
+ !-- A binary copy of commons-logging.jar is checked in j-t-c.
+ It can be overriden by gump or if you want to build jakarta-commons --
+ !--
property name=commons-logging.home
location=${jakarta-commons}/logging/
property name=commons-logging.lib
location=${commons-logging.home}/dist/
property name=commons-logging.jar
location=${commons-logging.lib}/commons-logging.jar/
+ --
+
+ property name=commons-logging.jar
+location=${jakarta-tomcat-connectors}/lib/commons-logging.jar/
!-- Binaries checked in ( servlet.jar is not likely to change,
the 2.2 spec is final --
@@ -246,9 +253,6 @@
copy tofile=${tomcat.build}/lib/common/servlet.jar
file=${servlet22.jar}/
-copy tofile=${tomcat.build}/lib/common/tomcat-util.jar
- file=${tomcat-util.jar}/
-
fixcrlf srcdir=${tomcat.build}/bin includes=**/*.sh eol=lf/
fixcrlf srcdir=${tomcat.build}/bin includes=**/*.bat eol=crlf/
@@ -262,6 +266,8 @@
!-- Local Tomcat utilities --
target name=tomcat_util depends=prepare
+ant dir=${jakarta-tomcat-connectors}/util /
+
javac destdir=${tomcat.build}/classes
debug=${debug}
optimize=${optimize}
@@ -285,16 +291,23 @@
/fileset
/copy
-jar jarfile=${tomcat.build}/lib/common/core_util.jar
- basedir=${tomcat.build}/classes
- include name=org/apache/tomcat/util/hooks/**/
- include name=org/apache/tomcat/util/log/**/
+jar jarfile=${tomcat.build}/lib/common/core_util.jar
+ fileset dir=${tomcat.build}/classes
+ include name=org/apache/tomcat/util/hooks/**/
+ /fileset
+ fileset dir=${jakarta-tomcat-connectors}/util/build/classes
+ include name=org/apache/tomcat/util/log/**/
+ /fileset
/jar
-jar jarfile=${tomcat.build}/lib/container/tomcat_util.jar
- basedir=${tomcat.build}/classes
- include name=org/apache/tomcat/util/**/
- exclude name=org/apache/tomcat/util/test/**/
+jar jarfile=${tomcat.build}/lib/container/tomcat_util.jar
+ fileset dir=${tomcat.build}/classes
+include name=org/apache/tomcat/util/**/
+exclude name=org/apache/tomcat/util/test/**/
+ /fileset
+ fileset dir=${jakarta-tomcat-connectors}/util/build/classes
+include name=org/apache/tomcat/util/**/
+ /fileset
/jar
/target
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7850] New: - Can not access env-entries by using JNDI when Tomcat de-serializes sesssions
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=7850. 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=7850 Can not access env-entries by using JNDI when Tomcat de-serializes sesssions Summary: Can not access env-entries by using JNDI when Tomcat de- serializes sesssions Product: Tomcat 4 Version: 4.0.3 Final Platform: PC URL: http://http:// OS/Version: Linux Status: NEW Severity: Critical Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] SORRY !!! - I resend the bug report. The previous bug report had a bug. I wanted to say: lookup throws an exception, instead ·of lookup returns null. * Short description - When sessions are de-serialized (from SESSIONS.ser), *just in that moment*, it is not possible to access env-entries by using JNDI (lookup throws an exception). * Full description My web application (distributable) inserts a serializable object of type X in the user session. The corresponding class (X) has a static block which initializes a static attribute by reading an env-entry (using JNDI). Of course, I know that static attributes are not saved for a serializable class. In a normal scenario, all works fine. OK ? For the explanation, assume that there is only one active session. If I stop Tomcat (shutdown.sh), the object in the session is serialized and stored in $TOMCAT_HOME/work/localhost/MyWebApplication/SESSIONS.ser. If now I start Tomcat again (startup.sh), Tomcat de-serializes the object from SESSIONS.ser. Just before the de-serialization occurs, the class loader loads the class X (still not loaded at this moment), and the static block is executed. The static block tries to read an env-entry, and the lookup operation throws an exception (it should return an String). In other words, when Tomcat starts and re-creates sessions from SESSIONS.ser, *just in that moment*, env-entries are still not initialized. If now I invalidate the session and reload the web application (with the Tomcat manager application), all works fine (the static block is executed again the first time the class is referenced, and accesses env-entries without problems). I have checked this scenario inserting System.out.println's in the static block and having a look at catalina.log. Note that this explanation has nothing to do with the use of static block. This error would still occur if I redefine serialization for class X, by redefining readObject, and try to access env-entries from it. Summing up, the problem is that env-entries are not initialized when de-serialization of sessions occur. If you are curious why I use a static block in class X, which initializes a static attribute, the reason it is that this block initializes a configuration parameter which is the same for all instances. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JNI in j-t-c/native/jk
Hola a todos: Finally Bug#2342 got to itch me :)), i'm almost done against j-t-c/native/jk code (tested in 5.0, i need some 4.0 testers, any volunteers?) , but to my surprise one the features that we make heavy use of, JNI connector, does not work with j-t-c against 3.3.X , anyone has tested this lately? or knows or imagines why JNI does not work in j-t-c/jk? i can easily make the fix against 3.3 main trunk if needed, Larry? it's that ok for you? Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7850] - Can not access env-entries by using JNDI when Tomcat de-serializes sesssions
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=7850. 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=7850 Can not access env-entries by using JNDI when Tomcat de-serializes sesssions [EMAIL PROTECTED] changed: What|Removed |Added URL|http://http:// | Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-04-08 20:23 --- The ENC is created after starting the manager, so it doesn't work. This won't be fixed in 4.0.x, and may be fixed in 4.1. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat build.xml
costin 02/04/08 13:00:37
Modified:.build.xml
Log:
Forgot one jar, resources.
XXX Must fix the bugs that prevent putting the whole tomcat_util.jar in common,
check that all utils are 'safe', and move them. Same for common-logging.
Revision ChangesPath
1.168 +11 -0 jakarta-tomcat/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat/build.xml,v
retrieving revision 1.167
retrieving revision 1.168
diff -u -r1.167 -r1.168
--- build.xml 8 Apr 2002 19:44:28 - 1.167
+++ build.xml 8 Apr 2002 20:00:37 - 1.168
@@ -300,6 +300,17 @@
/fileset
/jar
+jar jarfile=${tomcat.build}/lib/common/connector_util.jar
+ fileset dir=${jakarta-tomcat-connectors}/util/build/classes
+include name=org/apache/tomcat/util/collections/**/
+include name=org/apache/tomcat/util/http/**/
+include name=org/apache/tomcat/util/buf/**/
+include name=org/apache/tomcat/util/res/**/
+!-- All resource must go to common, bug in StringManager/ResourceBundle --
+include name=org/apache/tomcat/util/**/*.properties/
+ /fileset
+/jar
+
jar jarfile=${tomcat.build}/lib/container/tomcat_util.jar
fileset dir=${tomcat.build}/classes
include name=org/apache/tomcat/util/**/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat build.xml
Hi Costin,
I'm curious as to the reason to have connectors_util.jar instead
of just using the tomcat-utils.jar built by j-t-c/util?
Cheers,
Larry
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Mon 4/8/2002 4:00 PM
To: [EMAIL PROTECTED]
Cc:
Subject: cvs commit: jakarta-tomcat build.xml
costin 02/04/08 13:00:37
Modified:.build.xml
Log:
Forgot one jar, resources.
XXX Must fix the bugs that prevent putting the whole tomcat_util.jar in common,
check that all utils are 'safe', and move them. Same for common-logging.
Revision ChangesPath
1.168 +11 -0 jakarta-tomcat/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat/build.xml,v
retrieving revision 1.167
retrieving revision 1.168
diff -u -r1.167 -r1.168
--- build.xml 8 Apr 2002 19:44:28 - 1.167
+++ build.xml 8 Apr 2002 20:00:37 - 1.168
@@ -300,6 +300,17 @@
/fileset
/jar
+jar jarfile=${tomcat.build}/lib/common/connector_util.jar
+ fileset dir=${jakarta-tomcat-connectors}/util/build/classes
+include name=org/apache/tomcat/util/collections/**/
+include name=org/apache/tomcat/util/http/**/
+include name=org/apache/tomcat/util/buf/**/
+include name=org/apache/tomcat/util/res/**/
+!-- All resource must go to common, bug in StringManager/ResourceBundle
--
+include name=org/apache/tomcat/util/**/*.properties/
+ /fileset
+/jar
+
jar jarfile=${tomcat.build}/lib/container/tomcat_util.jar
fileset dir=${tomcat.build}/classes
include name=org/apache/tomcat/util/**/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
msg24657/bin0.bin
Description: application/ms-tnef
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7852] New: - Closing connections on error causes problems
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=7852.
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=7852
Closing connections on error causes problems
Summary: Closing connections on error causes problems
Product: Tomcat 4
Version: 4.0.3 Final
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Connector:HTTP/1.1 (deprecated)
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I'm not sure why the code works this way, but I believe it's wrong. On
line 279 of org.apache.catalina.connector.http.HttpResponseImpl.java,
the following code is found:
if (getStatus() HttpServletResponse.SC_BAD_REQUEST) {
if ((!isStreamInitialized()) (getContentLength() == -1)
(getStatus() = 200)
(getStatus() != SC_NOT_MODIFIED)
(getStatus() != SC_NO_CONTENT))
setContentLength(0);
} else {
setHeader(Connection, close);
}
This means that any time there's a 4xx or 5xx, the connection is closed.
This seems to be strange behavior, since the HTTP/1.1 spec states:
Persistent HTTP connections have a number of advantages: ... errors can
be reported without the penalty of closing the TCP connection.
Tomcat's behavior isn't technically illegal, but it's a violation of the
intent of the specification.
My small company has an application that occasionally needs to act as a
communications proxy. We've found that the code above makes it
impossible to complete an NT authentication because Tomcat closes the
connection for a 401. I'm sure some will be happy enough to mumble
about Microsoft. :(
Anyway, we've had enough luck changing SC_BAD_REQUEST to
SC_INTERNAL_SERVER_ERROR. I suspect that the best behavior would be to
remove the if and the else clause altogether.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JNI in j-t-c/native/jk
My assumption was that future native work would be only in j-t-c. Once I found time to do my own testing to try to verify there aren't any regressions, I was going to start removing native code from j-t. Is this still a good idea? Cheers, Larry -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] Sent: Mon 4/8/2002 4:20 PM To: 'tomcat-dev' Cc: Subject: JNI in j-t-c/native/jk Hola a todos: Finally Bug#2342 got to itch me :)), i'm almost done against j-t-c/native/jk code (tested in 5.0, i need some 4.0 testers, any volunteers?) , but to my surprise one the features that we make heavy use of, JNI connector, does not work with j-t-c against 3.3.X , anyone has tested this lately? or knows or imagines why JNI does not work in j-t-c/jk? i can easily make the fix against 3.3 main trunk if needed, Larry? it's that ok for you? Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] msg24659/bin0.bin Description: application/ms-tnef -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7852] - Closing connections on error causes problems
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=7852. 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=7852 Closing connections on error causes problems [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-04-08 20:52 --- Closing the connection for whatever reason is always valid in HTTP/1.1, esp when announcing that you'll be doing so. For example, some HTTP/1.1 always add the connection: close header in the response. So it does not violate any intent, and is perfectly legal. You should never rely on the connection being persisted for any operation (or this makes your client app non-HTTP compliant). If you hack the code there, it WILL create problems, and make Tomcat generate non-compliant HTTP responses (yes, the code is there for a reason). Coyote does not suffer from the limitations of the old HTTP connector, and is able to always persist the connection. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat build.xml
On Mon, 8 Apr 2002, Larry Isaacs wrote: Hi Costin, I'm curious as to the reason to have connectors_util.jar instead of just using the tomcat-utils.jar built by j-t-c/util? We have 2 'sets' of utils - one in j-t-c/util, one in j-t. We also have 2 lib dirs - lib/common and lib/container. The way we used to split the utils - we put minimal stuff in common, and that was core_utils and connector_utils. That's how 3.3.0/3.3.1 are doing it. I'm +1 to change to a single tomcat-util.jar in common, but that requires few fixes in xml-mapper ( actually in startup, to make xml-mapper find the thread loader pointing to container ). It also requires another review of the utils/ from security point of view - whatever is in common must be safe, since it'll be exposed to untrusted apps. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Validator.java
kinman 02/04/08 14:47:30
Modified:jasper2/src/share/org/apache/jasper/compiler Validator.java
Log:
- Make sure that visiBody is called for nodes that may have a body.
Revision ChangesPath
1.2 +10 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java
Index: Validator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Validator.java28 Mar 2002 18:46:17 - 1.1
+++ Validator.java8 Apr 2002 21:47:30 - 1.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java,v
1.1 2002/03/28 18:46:17 kinman Exp $
- * $Revision: 1.1 $
- * $Date: 2002/03/28 18:46:17 $
+ * $Header:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java,v
1.2 2002/04/08 21:47:30 kinman Exp $
+ * $Revision: 1.2 $
+ * $Date: 2002/04/08 21:47:30 $
*
*
*
@@ -310,6 +310,7 @@
public void visit(Node.IncludeDirective n) throws JasperException {
JspUtil.checkAttributes(Include directive, n.getAttributes(),
includeDirectiveAttrs, n.getStart(), err);
+ visitBody(n);
}
public void visit(Node.TaglibDirective n) throws JasperException {
@@ -329,6 +330,7 @@
includeActionAttrs, n.getStart(), err);
n.setPage(getJspAttribute(page, n.getAttributeValue(page),
n.isXmlSyntax()));
+ visitBody(n);
};
public void visit(Node.ForwardAction n) throws JasperException {
@@ -336,6 +338,7 @@
forwardActionAttrs, n.getStart(), err);
n.setPage(getJspAttribute(page, n.getAttributeValue(page),
n.isXmlSyntax()));
+ visitBody(n);
}
public void visit(Node.GetProperty n) throws JasperException {
@@ -400,6 +403,8 @@
beanInfo.addApplicationBean(name,className);
} else
err.jspError(n, jsp.error.useBean.badScope);
+
+ visitBody(n);
}
public void visit(Node.PlugIn n) throws JasperException {
@@ -413,6 +418,8 @@
err.jspError(n, jsp.error.plugin.badtype);
if (n.getAttributeValue(code) == null)
err.jspError(n, jsp.error.plugin.nocode);
+
+ visitBody(n);
}
public void visit(Node.CustomTag n) throws JasperException {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Request.java
remm02/04/08 15:03:09 Modified:coyote/src/java/org/apache/coyote Request.java Log: - It seems that remoteHost and remoteAddr shouldn't be recycled after each request, as the connection may last for more than one request/response (and it would be the responsability of the protocol handler to set the value whenever necessary). Revision ChangesPath 1.11 +4 -4 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java Index: Request.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- Request.java 6 Apr 2002 17:57:35 - 1.10 +++ Request.java 8 Apr 2002 22:03:08 - 1.11 @@ -463,8 +463,8 @@ queryMB.recycle(); methodMB.recycle(); protoMB.recycle(); - remoteAddrMB.recycle(); - remoteHostMB.recycle(); + //remoteAddrMB.recycle(); + //remoteHostMB.recycle(); // XXX Do we need such defaults ? schemeMB.setString(http); @@ -472,8 +472,8 @@ uriMB.setString(/); queryMB.setString(); protoMB.setString(HTTP/1.0); -remoteAddrMB.setString(127.0.0.1); -remoteHostMB.setString(localhost); +//remoteAddrMB.setString(127.0.0.1); +//remoteHostMB.setString(localhost); instanceId.recycle(); remoteUser.recycle(); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/handler TcHandlerCtx.java
remm02/04/08 15:29:14
Modified:util/java/org/apache/tomcat/util/handler TcHandlerCtx.java
Log:
- Add type attribute to the handler context (as an int).
Revision ChangesPath
1.2 +32 -1
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/handler/TcHandlerCtx.java
Index: TcHandlerCtx.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/handler/TcHandlerCtx.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TcHandlerCtx.java 4 Apr 2002 21:59:13 - 1.1
+++ TcHandlerCtx.java 8 Apr 2002 22:29:14 - 1.2
@@ -72,20 +72,51 @@
* @author Costin Manolache
*/
public class TcHandlerCtx {
+
+
+private int type = 0;
+
+/**
+ * Get the type of the handler context.
+ */
+public final int getType() {
+return type;
+}
+
+/**
+ * Set the type of the handler context.
+ */
+public final void setType( int type ) {
+this.type = type;
+}
+
+
// XXX Make it configurable ( at startup, since runtime change will require
sync )
-private Object notes[]=new Object[32];
+private Object notes[] = new Object[32];
+/**
+ * Get a note associated with this hanlder context.
+ */
public final Object getNote( int id ) {
return notes[id];
}
+/**
+ * Associate a note with this hanlder context.
+ */
public final void setNote( int id, Object o ) {
notes[id]=o;
}
+
+/**
+ * Recycle the hanlder context.
+ */
public void recycle() {
+type = 0;
for( int i=0; inotes.length; i++ ) {
notes[i]=null;
}
}
+
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote ActionCode.java
costin 02/04/08 15:46:58 Modified:coyote/src/java/org/apache/coyote ActionCode.java Log: Add the 2 callbacks that are typically needed - one to compute the remote host and the other for ssl attributes. Both are expensive and should be done on-demand Revision ChangesPath 1.5 +6 -2 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java Index: ActionCode.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- ActionCode.java 5 Apr 2002 05:36:32 - 1.4 +++ ActionCode.java 8 Apr 2002 22:46:58 - 1.5 @@ -90,9 +90,13 @@ public static final ActionCode ACTION_STOP = new ActionCode(); -/** Compute request attribute +/** Callback for lazy evaluation - extract the remote host address */ -public static final ActionCode ACTION_REQ_ATTRIBUTE = new ActionCode(); +public static final ActionCode ACTION_REQ_HOST_ATTRIBUTE = new ActionCode(); + +/** Callback for lazy evaluation - extract the SSL-related attributes + */ +public static final ActionCode ACTION_REQ_SSL_ATTRIBUTE = new ActionCode(); // --- Constructors -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Constants.java InputBuffer.java OutputBuffer.java
costin 02/04/08 15:49:52 Modified:coyote/src/java/org/apache/coyote Constants.java InputBuffer.java OutputBuffer.java Log: Increase the number of notes per request/response. Add some comments on Output/InputBuffer. There are 2 problems: - they are not stateless ( the param is just a buffer, no way to extract the response, etc). - it would be much cleaner ( IMHO ) and consistent with the rest of the code to use the hook mechanism - with 1 action for input and one for output. ( this would also eliminate naming conflicts with the 'real' OutputBuffer and simplify the code ) Revision ChangesPath 1.2 +1 -1 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Constants.java Index: Constants.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Constants.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- Constants.java14 Jun 2001 01:07:56 - 1.1 +++ Constants.java8 Apr 2002 22:49:52 - 1.2 @@ -83,7 +83,7 @@ public static final Locale DEFAULT_LOCALE = new Locale(LOCALE_DEFAULT, ); -public static final int MAX_NOTES = 10; +public static final int MAX_NOTES = 32; } 1.3 +4 -0 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/InputBuffer.java Index: InputBuffer.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/InputBuffer.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- InputBuffer.java 17 Sep 2001 05:28:52 - 1.2 +++ InputBuffer.java 8 Apr 2002 22:49:52 - 1.3 @@ -63,6 +63,10 @@ import org.apache.tomcat.util.buf.ByteChunk; +// XXX For consistency, this should be replaced with an action/hook - like all other +// callbacks from coyote to the protocol layer + + /** * Input buffer. * 1.4 +3 -0 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/OutputBuffer.java Index: OutputBuffer.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/OutputBuffer.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- OutputBuffer.java 17 Sep 2001 05:28:52 - 1.3 +++ OutputBuffer.java 8 Apr 2002 22:49:52 - 1.4 @@ -63,6 +63,9 @@ import org.apache.tomcat.util.buf.ByteChunk; +// XXX For consistency, this should be replaced with an action/hook - like all other +// callbacks from coyote to the protocol layer + /** * Output buffer. * -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Request.java Response.java
costin 02/04/08 15:56:22
Modified:coyote/src/java/org/apache/coyote Request.java Response.java
Log:
Allow Request to send callbacks - for lazy-evaluated attributes, and hopefully
to request more data.
Pass the Response/Request as the second param to Action - this allows
stateless implementation of the hooks ( all this will be much cleaner when/if
we move to generic Ctx ).
Revision ChangesPath
1.12 +14 -0
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java
Index: Request.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- Request.java 8 Apr 2002 22:03:08 - 1.11
+++ Request.java 8 Apr 2002 22:56:22 - 1.12
@@ -183,6 +183,7 @@
private Hashtable attributes=new Hashtable();
private Response response;
+private ActionHook hook;
// - Properties
@@ -354,8 +355,21 @@
public void setResponse( Response response ) {
this.response=response;
+response.setRequest( this );
}
+public void action(ActionCode actionCode, Object param) {
+if( hook==null response!=null )
+hook=response.getHook();
+
+if (hook != null) {
+if( param==null )
+hook.action(actionCode, this);
+else
+hook.action(actionCode, param);
+}
+}
+
// Cookies
1.9 +16 -4
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java
Index: Response.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- Response.java 15 Mar 2002 19:07:35 - 1.8
+++ Response.java 8 Apr 2002 22:56:22 - 1.9
@@ -155,9 +155,17 @@
*/
protected String errorURI = null;
+protected Request req;
// - Properties
+public Request getRequest() {
+return req;
+}
+
+public void setRequest( Request req ) {
+this.req=req;
+}
public OutputBuffer getOutputBuffer() {
return outputBuffer;
@@ -202,7 +210,10 @@
public void action(ActionCode actionCode, Object param) {
if (hook != null) {
-hook.action(actionCode, param);
+if( param==null )
+hook.action(actionCode, this);
+else
+hook.action(actionCode, param);
}
}
@@ -317,17 +328,17 @@
throw new IllegalStateException();
}
-action(ActionCode.ACTION_RESET, null);
+action(ActionCode.ACTION_RESET, this);
}
public void finish() throws IOException {
-action(ActionCode.ACTION_CLOSE, null);
+action(ActionCode.ACTION_CLOSE, this);
}
public void acknowledge() throws IOException {
-action(ActionCode.ACTION_ACK, null);
+action(ActionCode.ACTION_ACK, this);
}
@@ -392,6 +403,7 @@
* interceptors to fix headers.
*/
public void sendHeaders() throws IOException {
+// XXX This code doesn't send any notification :-)
commited = true;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3 Tomcat3Request.java
costin 02/04/08 15:57:36
Modified:coyote/src/java/org/apache/coyote/tomcat3
Tomcat3Request.java
Log:
Pass the request for lazy attributes to the protocol.
That's used for stuff that is not allways needed ( remote host ) and expensive
to compute.
Revision ChangesPath
1.3 +7 -10
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/Tomcat3Request.java
Index: Tomcat3Request.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/Tomcat3Request.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Tomcat3Request.java 5 Apr 2002 22:17:49 - 1.2
+++ Tomcat3Request.java 8 Apr 2002 22:57:36 - 1.3
@@ -73,6 +73,7 @@
import org.apache.tomcat.util.log.*;
import org.apache.tomcat.util.compat.*;
import org.apache.coyote.Adapter;
+import org.apache.coyote.ActionCode;
import org.apache.coyote.Processor;
/** The Request to connect with Coyote.
@@ -196,24 +197,20 @@
// override special methods
public MessageBytes remoteAddr() {
-
-// XXX Call back the protocol layer - lazy evaluation.
-// if( remoteAddrMB.isNull() ) {
-// remoteAddrMB.setString(socket.getInetAddress().getHostAddress());
-// }
+ if( remoteAddrMB.isNull() ) {
+ coyoteRequest.action( ActionCode.ACTION_REQ_HOST_ATTRIBUTE, coyoteRequest
);
+ }
return remoteAddrMB;
}
public MessageBytes remoteHost() {
-// if( remoteHostMB.isNull() ) {
-// remoteHostMB.setString( socket.getInetAddress().getHostName() );
-// }
+ if( remoteAddrMB.isNull() ) {
+ coyoteRequest.action( ActionCode.ACTION_REQ_HOST_ATTRIBUTE, coyoteRequest
);
+ }
return remoteHostMB;
}
public String getLocalHost() {
-// InetAddress localAddress = socket.getLocalAddress();
-// localHost = localAddress.getHostName();
return localHost;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common HandlerRequest.java
costin 02/04/08 15:58:40
Modified:jk/java/org/apache/jk/common HandlerRequest.java
Log:
Associate the Request/Response with each other
Revision ChangesPath
1.10 +2 -0
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java
Index: HandlerRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- HandlerRequest.java 4 Apr 2002 19:00:09 - 1.9
+++ HandlerRequest.java 8 Apr 2002 22:58:40 - 1.10
@@ -396,6 +396,8 @@
Request req=(Request)ep.getRequest();
if( req==null ) {
req=new Request();
+Response res=new Response();
+req.setResponse(res);
ep.setRequest( req );
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Constants.java InputBuffer.java OutputBuffer.java
costin 02/04/08 15:49:52 Modified:coyote/src/java/org/apache/coyote Constants.java InputBuffer.java OutputBuffer.java Log: Increase the number of notes per request/response. Add some comments on Output/InputBuffer. There are 2 problems: - they are not stateless ( the param is just a buffer, no way to extract the response, etc). - it would be much cleaner ( IMHO ) and consistent with the rest of the code to use the hook mechanism - with 1 action for input and one for output. ( this would also eliminate naming conflicts with the 'real' OutputBuffer and simplify the code ) I'd like those two to stay the way they are. They're not related to the hooks or actions. I/O should be handled as a special case IMO; faster + simpler. (could you remove the comments ?) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java
costin 02/04/08 15:59:37
Modified:jk/java/org/apache/jk/server JkCoyoteHandler.java
Log:
More impl.
Now it kind-of-works ( something is broken in headers, but close )
Revision ChangesPath
1.4 +142 -14
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java
Index: JkCoyoteHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- JkCoyoteHandler.java 6 Apr 2002 17:02:47 - 1.3
+++ JkCoyoteHandler.java 8 Apr 2002 22:59:37 - 1.4
@@ -76,15 +76,24 @@
/** Plugs Jk2 into Coyote
*/
-public class JkCoyoteHandler extends JkHandler implements ProtocolHandler,
ActionHook
+public class JkCoyoteHandler extends JkHandler implements
+ProtocolHandler, ActionHook
{
+protected static org.apache.commons.logging.Log log
+= org.apache.commons.logging.LogFactory.getLog(JkCoyoteHandler.class);
+int headersMsgNote;
+int c2bConvertersNote;
+int utfC2bNote;
+int obNote;
+int epNote;
+
Adapter adapter;
protected JkMain jkMain=new JkMain();
/** Pass config info
*/
public void setAttribute( String name, Object value ) {
-System.out.println(Set attribute + name + + value );
+log.info(setAttribute + name + + value );
}
public Object getAttribute( String name ) {
@@ -114,6 +123,14 @@
try {
jkMain.init();
jkMain.start();
+
+log.info(Jk2 started );
+
+headersMsgNote=wEnv.getNoteId( WorkerEnv.ENDPOINT_NOTE, headerMsg );
+utfC2bNote=wEnv.getNoteId( WorkerEnv.ENDPOINT_NOTE, utfC2B );
+epNote=wEnv.getNoteId( WorkerEnv.ENDPOINT_NOTE, ep );
+obNote=wEnv.getNoteId( WorkerEnv.ENDPOINT_NOTE, coyoteBuffer );
+
} catch( Exception ex ) {
ex.printStackTrace();
}
@@ -122,16 +139,71 @@
public void destroy() {
// jkMain.stop();
}
+// OutputBuffer implementation
+static class JkCoyoteBuffers implements org.apache.coyote.OutputBuffer,
+org.apache.coyote.InputBuffer
+{
+int epNote;
+int headersMsgNote;
+org.apache.coyote.Response res;
+
+void setResponse( org.apache.coyote.Response res ) {
+this.res=res;
+}
+
+public int doWrite(ByteChunk chunk)
+throws IOException
+{
+if( log.isInfoEnabled() )
+log.info(doWrite );
+MsgContext ep=(MsgContext)res.getNote( epNote );
+
+MsgAjp msg=(MsgAjp)ep.getNote( headersMsgNote );
+msg.reset();
+msg.appendByte( HandlerRequest.JK_AJP13_SEND_BODY_CHUNK);
+msg.appendBytes( chunk.getBytes(), chunk.getOffset(), chunk.getLength()
);
+ep.getChannel().send( msg, ep );
+
+return 0;
+}
+
+public int doRead(ByteChunk chunk)
+throws IOException
+{
+if( log.isInfoEnabled() )
+log.info(doRead );
+return 0;
+}
+}
+// Jk handler implementation
// Jk Handler mehod
public int invoke( Msg msg, MsgContext ep )
throws IOException
{
-System.out.println(XXX Invoke );
org.apache.coyote.Request req=(org.apache.coyote.Request)ep.getRequest();
org.apache.coyote.Response res=req.getResponse();
res.setHook( this );
+
+JkCoyoteBuffers ob=(JkCoyoteBuffers)res.getNote( obNote );
+if( ob == null ) {
+// Buffers not initialized yet
+// Workaround - IB, OB require state.
+ob=new JkCoyoteBuffers();
+ob.epNote=epNote;
+ob.headersMsgNote=headersMsgNote;
+ob.setResponse(res);
+res.setOutputBuffer( ob );
+req.setInputBuffer( ob );
+
+Msg msg2=new MsgAjp();
+ep.setNote( headersMsgNote, msg );
+
+res.setNote( obNote, ob );
+}
+res.setNote( epNote, ep );
+
try {
adapter.service( req, res );
} catch( Exception ex ) {
@@ -140,18 +212,74 @@
return OK;
}
+// Coyote Action implementation
+
public void action(ActionCode actionCode, Object param) {
-System.out.println(XXX Action + actionCode +
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Response.java
costin 02/04/08 16:07:11
Modified:coyote/src/java/org/apache/coyote Response.java
Log:
sendHeaders() must send the notification - that's what the javadoc says :-)
Now jk adapter works fine.
Revision ChangesPath
1.10 +1 -1
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java
Index: Response.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- Response.java 8 Apr 2002 22:56:22 - 1.9
+++ Response.java 8 Apr 2002 23:07:11 - 1.10
@@ -403,7 +403,7 @@
* interceptors to fix headers.
*/
public void sendHeaders() throws IOException {
-// XXX This code doesn't send any notification :-)
+action(ActionCode.ACTION_COMMIT, this);
commited = true;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyoteConstants.java InputBuffer.java OutputBuffer.java
On Mon, 8 Apr 2002, Remy Maucherat wrote: I'd like those two to stay the way they are. They're not related to the hooks or actions. I/O should be handled as a special case IMO; faster + simpler. (could you remove the comments ?) Ok, but at least add a second parameter ( Request, Response, etc ) to allow stateless implementation. Implementing input/output as a regular callback from coyote to the protocol impl. is IMO cleaner and is not much slower. I'm fine with them as special case if you want it this way. But can we at least add the extra param ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3 CoyoteInterceptor2.java Tomcat3Request.java
costin 02/04/08 16:47:04
Modified:coyote/src/java/org/apache/coyote/tomcat3
CoyoteInterceptor2.java Tomcat3Request.java
Log:
Add the callback for SSL info
Revision ChangesPath
1.3 +26 -0
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/CoyoteInterceptor2.java
Index: CoyoteInterceptor2.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/CoyoteInterceptor2.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- CoyoteInterceptor2.java 5 Apr 2002 22:17:49 - 1.2
+++ CoyoteInterceptor2.java 8 Apr 2002 23:47:04 - 1.3
@@ -202,5 +202,31 @@
}
return 0;
}
+
+
+/**
+ getInfo calls for SSL data
+
+ @return the requested data
+*/
+public Object getInfo( Context ctx, org.apache.tomcat.core.Request request,
+ int id, String key ) {
+
+Tomcat3Request httpReq;
+
+try {
+httpReq=(Tomcat3Request)request;
+} catch (ClassCastException e){
+return null;
+}
+
+if(key!=null httpReq!=null ){
+// XXX Should use MsgContext, pass the attribute we need.
+// This will extract both
+httpReq.getCoyoteRequest().action( ActionCode.ACTION_REQ_SSL_ATTRIBUTE,
+ httpReq.getCoyoteRequest() );
+}
+return super.getInfo(ctx,request,id,key);
+}
}
1.4 +4 -0
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/Tomcat3Request.java
Index: Tomcat3Request.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/Tomcat3Request.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- Tomcat3Request.java 8 Apr 2002 22:57:36 - 1.3
+++ Tomcat3Request.java 8 Apr 2002 23:47:04 - 1.4
@@ -116,6 +116,10 @@
end=-1;
}
+public org.apache.coyote.Request getCoyoteRequest() {
+return coyoteRequest;
+}
+
/** Attach the Coyote Request to this Request.
* This is currently set pre-request to allow copying the request
* attributes to the Tomcat attributes.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
costin 02/04/08 16:48:22
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
Add support for the delayed-evaluation of ssl and remote host attributes.
( incomplete )
Revision ChangesPath
1.15 +34 -12
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Index: Http11Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- Http11Processor.java 5 Apr 2002 17:48:26 - 1.14
+++ Http11Processor.java 8 Apr 2002 23:48:22 - 1.15
@@ -64,12 +64,14 @@
import java.io.InputStream;
import java.io.IOException;
import java.io.OutputStream;
+import java.net.Socket;
import org.apache.tomcat.util.buf.ByteChunk;
import org.apache.tomcat.util.buf.MessageBytes;
import org.apache.tomcat.util.http.FastHttpDateFormat;
import org.apache.tomcat.util.http.MimeHeaders;
import org.apache.tomcat.util.buf.HexUtils;
+import org.apache.tomcat.util.net.SSLSupport;
import org.apache.coyote.ActionHook;
import org.apache.coyote.ActionCode;
@@ -206,6 +208,11 @@
*/
protected int maxKeepAliveRequests=-1;
+
+/** SSL support, socket - this is statefull anyway */
+protected SSLSupport sslSupport;
+protected Socket socket;
+
// - Public Methods
@@ -283,6 +290,16 @@
return maxKeepAliveRequests;
}
+public void setSSLSupport( SSLSupport sslSupport ) {
+this.sslSupport=sslSupport;
+}
+
+public void setSocket( Socket socket )
+throws IOException
+{
+this.socket=socket;
+}
+
/**
* Process pipelined HTTP requests using the specified input and output
* streams.
@@ -372,6 +389,8 @@
inputBuffer.recycle();
outputBuffer.recycle();
+// Recycle ssl info
+sslSupport=null;
}
@@ -455,19 +474,22 @@
started = false;
-} else if (actionCode == ActionCode.ACTION_REQ_ATTRIBUTE ) {
+} else if (actionCode == ActionCode.ACTION_REQ_SSL_ATTRIBUTE ) {
+Request req=(Request)param;
+try {
+if( sslSupport != null ) {
+// if(key.equals(javax.servlet.request.cipher_suite))
+//sslSupport.getCipherSuite();
+// if(key.equals(javax.servlet.request.X509Certificate))
+//sslSupport.getPeerCertificateChain();
+}
+} catch (Exception e){
+//log(Exception getting SSL attribute + key,e,Log.WARNING);
+}
+} else if (actionCode == ActionCode.ACTION_REQ_HOST_ATTRIBUTE ) {
+Request req=(Request)param;
-// XXX Will be fixed if we replace ActionCode/Action with TcHandler,
-// the context can be used to pass and return information
-// try {
-// if(key.equals(javax.servlet.request.cipher_suite))
-// return httpReq.sslSupport.getCipherSuite();
-// if(key.equals(javax.servlet.request.X509Certificate))
-// return httpReq.sslSupport.getPeerCertificateChain();
-// } catch (Exception e){
-// log.warn(Exception getting SSL attribute + key,e);
-// return null;
-// }
+
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Protocol.java
costin 02/04/08 16:49:18
Modified:http11/src/java/org/apache/coyote/http11 Http11Protocol.java
Log:
Set the SSLSupport and socket into the processor, so it can use them in the
hook
Revision ChangesPath
1.4 +12 -30
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java
Index: Http11Protocol.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- Http11Protocol.java 7 Apr 2002 21:11:33 - 1.3
+++ Http11Protocol.java 8 Apr 2002 23:49:18 - 1.4
@@ -147,7 +147,7 @@
// Properties
protected PoolTcpEndpoint ep=new PoolTcpEndpoint();
-boolean secure;
+protected boolean secure;
protected ServerSocketFactory socketFactory;
protected SSLImplementation sslImplementation;
@@ -299,9 +299,9 @@
public void processConnection(TcpConnection connection, Object thData[]) {
Socket socket=null;
-Processor processor=null;
+Http11Processor processor=null;
try {
-processor=(Processor)thData[1];
+processor=(Http11Processor)thData[1];
if (processor instanceof ActionHook) {
((ActionHook) processor).action(ActionCode.ACTION_START, null);
@@ -312,35 +312,17 @@
InputStream in = socket.getInputStream();
OutputStream out = socket.getOutputStream();
-// XXX Should be a request note
-//reqA.setSocket(socket);
-//if( secure ) {
-// Load up the SSLSupport class
-// if(sslImplementation != null)
- //sslSupport = sslImplementation.getSSLSupport(socket);
-// }
-
-// boolean secure=false;
-// SSLImplementation sslImplementation=null;
-// SSLSupport sslSupport=null;
-
-// if( secure ) {
-// reqA.scheme().setString( https );
-
-// // Load up the SSLSupport class
-// if(sslImplementation != null)
-// reqA.setSSLSupport(sslSupport);
-// }
-
+if( proto.secure ) {
+SSLSupport sslSupport=null;
+if(proto.sslImplementation != null)
+sslSupport = proto.sslImplementation.getSSLSupport(socket);
+processor.setSSLSupport(sslSupport);
+} else {
+processor.setSSLSupport( null );
+}
+processor.setSocket( socket );
processor.process(in, out);
-
-// Recycle reqA notes
-// secure = false;
-// sslImplementation=null;
-// sslSupport=null;
-
-
// If unread input arrives after the shutdownInput() call
// below and before or during the socket.close(), an error
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote InputBuffer.java OutputBuffer.java
costin 02/04/08 16:46:32 Modified:coyote/src/java/org/apache/coyote InputBuffer.java OutputBuffer.java Log: Revert the comment Revision ChangesPath 1.4 +0 -3 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/InputBuffer.java Index: InputBuffer.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/InputBuffer.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- InputBuffer.java 8 Apr 2002 22:49:52 - 1.3 +++ InputBuffer.java 8 Apr 2002 23:46:32 - 1.4 @@ -63,9 +63,6 @@ import org.apache.tomcat.util.buf.ByteChunk; -// XXX For consistency, this should be replaced with an action/hook - like all other -// callbacks from coyote to the protocol layer - /** * Input buffer. 1.5 +0 -2 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/OutputBuffer.java Index: OutputBuffer.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/OutputBuffer.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- OutputBuffer.java 8 Apr 2002 22:49:52 - 1.4 +++ OutputBuffer.java 8 Apr 2002 23:46:32 - 1.5 @@ -63,8 +63,6 @@ import org.apache.tomcat.util.buf.ByteChunk; -// XXX For consistency, this should be replaced with an action/hook - like all other -// callbacks from coyote to the protocol layer /** * Output buffer. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin/valve - New directory
manveen 02/04/08 17:06:11 jakarta-tomcat-4.0/webapps/admin/valve - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin/valve accessLogValve.jsp
manveen 02/04/08 17:06:45
Added: webapps/admin/valve accessLogValve.jsp
Log:
Added JSP For Access Log Valve.
Revision ChangesPath
1.1 jakarta-tomcat-4.0/webapps/admin/valve/accessLogValve.jsp
Index: accessLogValve.jsp
===
!-- Standard Struts Entries --
%@ page language=java import=java.net.URLEncoder %
%@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean %
%@ taglib uri=/WEB-INF/struts-html.tld prefix=html %
%@ taglib uri=/WEB-INF/controls.tld prefix=controls %
%@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic %
html:html locale=true
%@ include file=../users/header.jsp %
!-- Body --
body bgcolor=white
!--Form --
html:errors/
html:form method=POST action=/SaveAccessLogValve
bean:define id=thisObjectName type=java.lang.String
name=accessLogValveForm property=objectName/
html:hidden property=adminAction/
html:hidden property=parentObjectName/
html:hidden property=objectName/
table width=100% border=0 cellspacing=0 cellpadding=0
tr bgcolor=7171A5
td width=81%
div class=page-title-text align=left
logic:equal name=accessLogValveForm property=adminAction
value=Create
bean:message key=actions.valves.create/
/logic:equal
logic:equal name=accessLogValveForm property=adminAction value=Edit
bean:message key=actions.valves.edit/
/logic:equal
/div
/td
td width=19%
div align=right
controls:actions
controls:action selected=true bean:message
key=actions.available.actions/ /controls:action
controls:action - /controls:action
logic:notEqual name=accessLogValveForm property=adminAction
value=Create
%--
controls:action url='%= /DeleteValve.do?select= +
URLEncoder.encode(thisObjectName) %'
bean:message key=actions.valves.delete/
/controls:action
--%
/logic:notEqual
/controls:actions
/div
/td
/tr
/table
%@ include file=../buttons.jsp %
br
%-- Access Log Properties --%
table border=0 cellspacing=0 cellpadding=0 width=100%
tr td div class=table-title-text
bean:message key=valve.access.properties/
/div /td /tr
/table
table class=back-table border=0 cellspacing=0 cellpadding=0 width=100%
tr
td
controls:table tableStyle=front-table lineStyle=line-row
controls:row header=true
labelStyle=table-header-text dataStyle=table-header-text
controls:labelbean:message key=service.property//controls:label
controls:databean:message key=service.value//controls:data
/controls:row
controls:row labelStyle=table-label-text dataStyle=table-normal-text
controls:labelbean:message key=valve.class/:/controls:label
controls:data
logic:equal name=accessLogValveForm property=adminAction
value=Create
html:select property=valveType
onchange=IA_jumpMenu('self',this)
bean:define id=valveTypeVals name=accessLogValveForm
property=valveTypeVals/
html:options collection=valveTypeVals property=value
labelProperty=label/
/html:select
/logic:equal
logic:equal name=accessLogValveForm property=adminAction
value=Edit
bean:write name=accessLogValveForm property=valveType
scope=session/
/logic:equal
/controls:data
/controls:row
controls:row labelStyle=table-label-text dataStyle=table-normal-text
controls:labelbean:message key=server.debuglevel/:/controls:label
controls:data
html:select property=debugLvl
bean:define id=debugLvlVals name=accessLogValveForm
property=debugLvlVals/
html:options collection=debugLvlVals property=value
labelProperty=label/
/html:select
/controls:data
/controls:row
controls:row labelStyle=table-label-text dataStyle=table-normal-text
controls:labelbean:message key=logger.directory/:/controls:label
controls:data
html:text property=directory size=30/
/controls:data
/controls:row
controls:row labelStyle=table-label-text dataStyle=table-normal-text
controls:labelbean:message key=valve.pattern/:/controls:label
controls:data
RE: cvs commit: jakarta-tomcat build.xml
It's not so much having one util jar, but understanding the differences between jakarta-tomcat-connectors' tomcat-util.jar and connectors_util.jar. If they are the same, then I would prefer to use a single name. Cheers, Larry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Mon 4/8/2002 6:37 PM To: Tomcat Developers List Cc: Subject: RE: cvs commit: jakarta-tomcat build.xml On Mon, 8 Apr 2002, Larry Isaacs wrote: Hi Costin, I'm curious as to the reason to have connectors_util.jar instead of just using the tomcat-utils.jar built by j-t-c/util? We have 2 'sets' of utils - one in j-t-c/util, one in j-t. We also have 2 lib dirs - lib/common and lib/container. The way we used to split the utils - we put minimal stuff in common, and that was core_utils and connector_utils. That's how 3.3.0/3.3.1 are doing it. I'm +1 to change to a single tomcat-util.jar in common, but that requires few fixes in xml-mapper ( actually in startup, to make xml-mapper find the thread loader pointing to container ). It also requires another review of the utils/ from security point of view - whatever is in common must be safe, since it'll be exposed to untrusted apps. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] msg24681/bin0.bin Description: application/ms-tnef -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
