Re: [PROPOSAL AJP14] AJP13 Evolution
GOMEZ Henri wrote: 1) We've talked about specifying a response packet to indicate that the engine (or the web server) doesn't recognize a packet sent over. This would allow us much more flexiblity to add packet types to ajpv14, without having to make ajpv15,16, etc. +1 In other words - both ends should deal with unknown packets - maybe by sending back an UNIMPLEMENTED message. Since AJP indicate size we could deal with unknow packets. But if we negociate at startup the common protocol level, we must avoid that situation. I like the idea of reject cmd, +1 2) What about specifying a separate, out of band control socket connection? If the web server opened up two connections, 1 for data, one for control, then we could have much better communication from the engine to the server (if it was shutting down contexts, for example). We could also have a heartbeat without interfering with the data channel. I'm not sure - but I can see some benefits. Right now we have (almost) bidirectional communication - the protocol is based on message passing, and sort of token-based: each side sends a message, then waits for a message. The main reason for that is the single-threaded web server. ( Apache1.3, maybe other servers ). It is a bit difficult to deal with 2 connections in a single threaded env ( while keeping the code as simple as possible ). My feeling is that for most needs of a servlet container we can deal with the single socket protocol. I don't know any (major) use case or feature of tomcat that would require the second socket. Argh, all the subtility is here. Basically even if ajp13 is a bidirectional protocol, it's a request/reply protocol since it's how a web server function : 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE 2) WAIT FOR RESPONSE 3) GET RESPONSE AND FORWARD TO WEB-SERVER. We could have a second socket for control but : 1) How did we share it in forked (apache 1.3) env ? = shared memory = MM or APR APR of course: MM is included in it. 2) Ditto in a threaded architecture (Apache 2.0) at least in MPM mode (a forked child which will in turn thread child), but again how did we info we other forked. Also doubling the socket, will double the descriptors open and will be a problem under heavy load. In an HTTP architecture we need again to mix data (tons of messages) with control (very low traffic). And so we need to read for possible message at some time. 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE 2) WAIT FOR END OF PREVIOUS REPLY AND EVENTUALLY ADMIN MESSAGE 3) GET ADMIN MESSAGE and evnetually RESPONSE 4) GET RESPONSE AND FORWARD TO WEB-SERVER. The admin message could be send() in socket at any time and will be handled when a request will came Apjp13 requests are not multiplexed, so we need more that one connection. How could we decide on which connection we send the admin message? Otherwise we will the send the same data more than once. What happends when the configuration is changed more than once and no request happend in the meantime... We could get a wrong configuration...
Roles / Login / j_security check
Hi, apologies as this is a bit of a cross-post from tomcat-user last week (was getting no responses from there). I need to work out what's going on re: roles and login. I'm observing some unexpected behaviour in Tomcat (3.2.1) in conjuction with roles. This is the situation: (web.xml is at the bottom) two roles: Customer Gold Customer a user: Joe Bloggs Joe is a Customer but not a Gold Customer This is what I observe: 1) new browser (not logged in) browse to /control/CustomerSecurePage 2) browser is redirected to /login.jsp 3) Joe logs in and is redirected to /control/CustomerSecurePage 4) browse to /control/GoldSecurePage 5) browser redirected to /control/loginerror 6) Joe is now logged out, any subsequent attempts to browse to a page secured by the customer role results in a redirection to the login page. Is this correct behaviour? I would have expected an attempt to access to the gold url to have denied access but not to have logged the user out! Unless I can resolve this I'm going to have to abandon using tomcat to manage access to restricted content. This is not something I want to do. I've tried working through the source but got lost. Thanks in advance, Nathan this is the relevant section of web.xml: security-constraint web-resource-collection web-resource-nameMySecureBit0/web-resource-name descriptionno description/description url-pattern/control/GoldSecurePage/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint descriptionno description/description role-namegold/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameMySecureBit1/web-resource-name descriptionno description/description url-pattern/control/CustomerSecurePage/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint descriptionno description/description role-namecustomer/role-name /auth-constraint /security-constraint login-config auth-methodFORM/auth-method realm-nameTheGiftStore/realm-name form-login-config form-login-page/login.jsp/form-login-page form-error-page/control/loginerror/form-error-page /form-login-config /login-config security-role descriptionthe customer role/description role-namecustomer/role-name /security-role security-role descriptionthe gold customer role/description role-namegold/role-name /security-role
PLease UnSubscribe me from all your email.
Please UNSUBSCRIBE, REMOVE MY EMAIL ADDRESS FROM ALL TOMCAT MAIL SYSTEMS. [EMAIL PROTECTED] Thanks.
Re: [PROPOSAL/VOTE] Tomcat 4.0 Beta 4 Release
+1 Craig R. McClanahan typed the following on 07:21 PM 5/7/2001 -0700 Now that the Proposed Final Draft 2 versions of the Servlet 2.3 and JSP 1.2 specs have been published (with Tomcat 4.0 updated to support the latest changes), and a ton of bug fixes have been made, I would like to propose that we create a Tomcat 4.0 Beta 4 release as follows: Release Manager: Craig McClanahan Code Freeze: Thursday, May 10, 2001 at 05:00pm Pacific Time See the file RELEASE-NOTES-4.0-B4.txt for a reasonably up-to-date list of the changes to date. This document will be updated with any additional changes that are made, plus a list of known outstanding issues. Between now and the code freeze, I'd like us to focus on fixing outstanding bugs and catching the configuration documentation up to date. I'm OK with continuing work on the new distributed session stuff in the mean time (as long as it is not enabled in the default configuration), but please hold off on making substantive changes in the core container until after the Beta 4 release.
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http10 HttpConnector.java HttpRequestImpl.java
[EMAIL PROTECTED] typed the following on 03:37 AM 5/8/2001 + Make it possible to disable DNS lookups of the remote host name, for Tomcat used stand-alone, even when the web app calls request.getRemoteHost(). Lookups are enabled by default -- disable them by modifying the Connector ... disableLookups .../ attribute. I think it would be better to have DNS lookups _disabled_ by default (doesn't Apache httpd do this?). If someone really needs to get the hostname for their app, they can take the trouble to enable it, but the out of the box experience for Tomcat shouldn't be pig-slow for a probably unnecessary feature. IMHO of course. ;-) Kief
RE: Tomcat 3.2.2 beta 4
That has fixed that problem. I can now run under Wjview (the M$ VM). I have just found another problem though. This is not a new problem with 3.2.2. We have just started using the O'Reily HttpMessage code to send a Post message to a servlet from another servlet (in the same virtual machine). The Stream within the POST contains a Vector of Serializable objects. The POST works as expected, no problems, but when shutting down Tomcat we get the following stack trace and the process never finishes. This is using TC3.2.2b4 with Apache 1.3.17 (I will try 1.3.19). java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleError(ContextManager.java:1160) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:800) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:484) 2001-03-08 11:17:32 - Ctx( ): 404 R( /spweb/servlet/StaffPlannerServlet) null 2001-03-08 11:17:32 - Ctx( ): Exception in: R( /spweb/servlet/StaffPlannerServlet) - java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1058) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:775) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:484) I will write a little sample program if you think it is worthwhile and post it to the group. Dave. [EMAIL PROTECTED] From: Marc Saegesser [EMAIL PROTECTED] To: Dave Oxley [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Mon, 7 May 2001 08:37:20 -0500 Dave, Thanks, let me know how it works. This is the final show stopper for the Tomcat 3.2.2 release so once I know its been fixed I can start the final release process. -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Friday, May 04, 2001 12:54 PM To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Will test it on Saturday. Dave. From: Marc Saegesser [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Thu, 3 May 2001 16:39:35 -0500 Dave, A fix for this has been committed. If you can build from source to test this that's great. I've also attached a JAR file with the latest Tomcat build. Just drop the webserver.jar file into your $TOMCAT_HOME/lib directory and start Tomcat. Thanks. -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 01, 2001 3:14 PM To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Glad I mentioned it now. I didn't think about the fact it might be a 1.1 thing. We've had so many problems with the M$ VM that I just jumped to conclusions!! The sooner we dump it the better. :) Dave [EMAIL PROTECTED] From: Marc Saegesser [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 1 May 2001 14:17:13 -0500 Bloody hell. I was just about to launch into a wonderful tirade about why we shouldn't have change Tomcat just to work around some buggy compiler from Microsoft when I realized the real problem isn't what you think it is. The problem isn't the definition of the inner class, but the use of the PrivilegedAction interface. This interface didn't appear until JDK1.2 and my guess is that your using JDK1.1. Tomcat 3.2.x, because it implements the Servlet 1.1 specification must maintain compatibility with JDK1.1 so this is a real Tomcat bug and it will need to be fixed before releasing Tomcat 3.2.2. Glenn, can you take a look at this? -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 01, 2001 12:32 PM To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 I posted this before but got no response. The change to SessionUtil.java 1.5.2.2 to 1.5.2.3 (3.2.1-3.2.2b1) has caused the Microsoft Virtual Machine to fall over when running Tomcat. The M$ VM does not like internal classes defined within methods (I think this is the problem) and
RE: Tomcat 3.2.2 beta 4
Some further info on this problem. It works fine with TC3.2.1 with AJP12. TC3.2.1 goes into an infinite loop using 100% processor with AJP13. TC3.2.2b4 gives the stack trace with AJP13 but does not infinite loop like TC3.2.1. I have tried with Apache 1.3.19, but it made no difference. I have tried this with Java 1.3.0_01 and 1.3.0_02 with the same results. I am running Windows 2000. I will write a test servlet a bit later on. Dave. [EMAIL PROTECTED] From: Dave Oxley [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 08 May 2001 12:07:44 +0100 I have just found another problem though. This is not a new problem with 3.2.2. We have just started using the O'Reily HttpMessage code to send a Post message to a servlet from another servlet (in the same virtual machine). The Stream within the POST contains a Vector of Serializable objects. The POST works as expected, no problems, but when shutting down Tomcat we get the following stack trace and the process never finishes. This is using TC3.2.2b4 with Apache 1.3.17 (I will try 1.3.19). java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleError(ContextManager.java:1160) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:800) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:484) 2001-03-08 11:17:32 - Ctx( ): 404 R( /spweb/servlet/StaffPlannerServlet) null 2001-03-08 11:17:32 - Ctx( ): Exception in: R( /spweb/servlet/StaffPlannerServlet) - java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1058) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:775) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:484) I will write a little sample program if you think it is worthwhile and post it to the group. Dave. [EMAIL PROTECTED] _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Re: load-on-startup / classloader bug??
doh! not only did i not mention which version i'm using, i also mispoke... mondays... so, i'm using the latest tomcat 4.0 out of cvs (co'd this morning). also, it's in the servlet init method, *not* it's service method where the thread is created. when i get some time, i'm going to try and recreate this in a small example that i can post. -kevin. kevin seguin wrote: i have a servlet that creates a thread in it's service method. this thread basically does a bunch of initialization stuff. when i add a load-on-startup element for this servlet in web.xml, it reports a NoClassDefFoundError on a class in the same package as the servlet. i have not seen this problem with any other load-on-startup servlets. the only difference is that this servlet kicks off a new thread. ideas? is this a bug, or just bad programming on my part (well, not really my part, but that's another story...)? i started to look through the startup/loader/class loader, but quickly got overwhelmed :) With the current code it will fail indeed. so, is this considered a bug in tc 4.0b4? is it something you plan on fixing? is it something i could fix myself? i'm trying to migrate to tc 4 (from tc 3.x) so i'd like to know whether or not this will be fixed so i can decide what to do about servlets that have this problem. if it's fixable, i'll either wait for the fix or do it myself. if it's a big deal to fix, i'll have to look into reworking my servlets. just looking for some expert advice here. i'm not too familiar with the catalina internals. thanks.
RE: [PROPOSAL/VOTE] Tomcat 4.0 Beta 4 Release
+0 I *will* get 3.2.2 out the door one of these days and then I hope to have the time to help out with 4.x. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 9:22 PM To: [EMAIL PROTECTED] Subject: [PROPOSAL/VOTE] Tomcat 4.0 Beta 4 Release Now that the Proposed Final Draft 2 versions of the Servlet 2.3 and JSP 1.2 specs have been published (with Tomcat 4.0 updated to support the latest changes), and a ton of bug fixes have been made, I would like to propose that we create a Tomcat 4.0 Beta 4 release as follows: Release Manager: Craig McClanahan Code Freeze: Thursday, May 10, 2001 at 05:00pm Pacific Time See the file RELEASE-NOTES-4.0-B4.txt for a reasonably up-to-date list of the changes to date. This document will be updated with any additional changes that are made, plus a list of known outstanding issues. Between now and the code freeze, I'd like us to focus on fixing outstanding bugs and catching the configuration documentation up to date. I'm OK with continuing work on the new distributed session stuff in the mean time (as long as it is not enabled in the default configuration), but please hold off on making substantive changes in the core container until after the Beta 4 release. Comments? Votes? The usual rules apply: [ ] +1 = I agree with this proposal and will support it [ ] +0 = I agree with this proposal, but do not have time to support it [ ] -0 = I do not agree with this proposal, but don't want to try to block it [ ] -1 = I do not agree with this proposal (requires reasons) Craig
RE: Tomcat 3.2.2 beta 4
Dave, Does it work OK with 3.2.2b4 and AJP12? -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 08, 2001 7:15 AM To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Some further info on this problem. It works fine with TC3.2.1 with AJP12. TC3.2.1 goes into an infinite loop using 100% processor with AJP13. TC3.2.2b4 gives the stack trace with AJP13 but does not infinite loop like TC3.2.1. I have tried with Apache 1.3.19, but it made no difference. I have tried this with Java 1.3.0_01 and 1.3.0_02 with the same results. I am running Windows 2000. I will write a test servlet a bit later on. Dave. [EMAIL PROTECTED] From: Dave Oxley [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 08 May 2001 12:07:44 +0100 I have just found another problem though. This is not a new problem with 3.2.2. We have just started using the O'Reily HttpMessage code to send a Post message to a servlet from another servlet (in the same virtual machine). The Stream within the POST contains a Vector of Serializable objects. The POST works as expected, no problems, but when shutting down Tomcat we get the following stack trace and the process never finishes. This is using TC3.2.2b4 with Apache 1.3.17 (I will try 1.3.19). java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleError(ContextManager. java:1160) at org.apache.tomcat.core.ContextManager.internalService(ContextMana ger.java:800) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.proces sConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool. java:501) at java.lang.Thread.run(Thread.java:484) 2001-03-08 11:17:32 - Ctx( ): 404 R( /spweb/servlet/StaffPlannerServlet) null 2001-03-08 11:17:32 - Ctx( ): Exception in: R( /spweb/servlet/StaffPlannerServlet) - java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager .java:1058) at org.apache.tomcat.core.ContextManager.internalService(ContextMana ger.java:775) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.proces sConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool. java:501) at java.lang.Thread.run(Thread.java:484) I will write a little sample program if you think it is worthwhile and post it to the group. Dave. [EMAIL PROTECTED] _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
[PATCH] bugs 412 and 112 for TC3.3
112 is really simple. Just a check if the TOMCAT_HOME should be '..' after checking for '.' 412 is almost as straightforward. It's a bug in JspC, where CommandLineContext is handed a URI with '\' s in the jspFile. Defensively, I've added a replace in CommandLineContext's constructor. Alternatively, it could be done by the caller. Arguably, it would make more sense in the caller, as a URI should never have a separator other than '/'. In the course of these, I had to deal with a couple other regressions in JspC. Firstly, it won't run, out of the box. JspC doesn't set up any classloaders, and hence does not know about any of the jars other than the boostrap ones. Adding the classloaders to JspC is a bunch of work, so I just added a CLASSPATH for the JSPC target in tomcat.bat. I also added setlocal at the top of the batch file, to keep the environment variables from leaking out when the script crashed. Also an endlocal so that tomcat env would still work. JspC also wasn't logging anything. I added some code to set up the JASPER_LOG logger. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. bug412.patch
RE: Tomcat 3.2.2 beta 4
Just tried it and yes: TC3.2.2b4 with AJP12 does work. Dave. [EMAIL PROTECTED] From: Marc Saegesser [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 8 May 2001 08:44:03 -0500 Dave, Does it work OK with 3.2.2b4 and AJP12? -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 08, 2001 7:15 AM To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Some further info on this problem. It works fine with TC3.2.1 with AJP12. TC3.2.1 goes into an infinite loop using 100% processor with AJP13. TC3.2.2b4 gives the stack trace with AJP13 but does not infinite loop like TC3.2.1. I have tried with Apache 1.3.19, but it made no difference. I have tried this with Java 1.3.0_01 and 1.3.0_02 with the same results. I am running Windows 2000. I will write a test servlet a bit later on. Dave. [EMAIL PROTECTED] From: Dave Oxley [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 08 May 2001 12:07:44 +0100 I have just found another problem though. This is not a new problem with 3.2.2. We have just started using the O'Reily HttpMessage code to send a Post message to a servlet from another servlet (in the same virtual machine). The Stream within the POST contains a Vector of Serializable objects. The POST works as expected, no problems, but when shutting down Tomcat we get the following stack trace and the process never finishes. This is using TC3.2.2b4 with Apache 1.3.17 (I will try 1.3.19). java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleError(ContextManager. java:1160) at org.apache.tomcat.core.ContextManager.internalService(ContextMana ger.java:800) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.proces sConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool. java:501) at java.lang.Thread.run(Thread.java:484) 2001-03-08 11:17:32 - Ctx( ): 404 R( /spweb/servlet/StaffPlannerServlet) null 2001-03-08 11:17:32 - Ctx( ): Exception in: R( /spweb/servlet/StaffPlannerServlet) - java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager .java:1058) at org.apache.tomcat.core.ContextManager.internalService(ContextMana ger.java:775) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.proces sConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool. java:501) at java.lang.Thread.run(Thread.java:484) I will write a little sample program if you think it is worthwhile and post it to the group. Dave. [EMAIL PROTECTED] _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
RE: [PROPOSAL AJP14] AJP13 Evolution
Why not just handle each connection as if it is a connection from a different server, logging in each time. Are ajp13 requests serialized? ajp13 only connects to TC once to the port set in the config, right? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of jean-frederic clere Sent: Tuesday, May 08, 2001 5:19 AM To: [EMAIL PROTECTED] Subject: Re: [PROPOSAL AJP14] AJP13 Evolution Apjp13 requests are not multiplexed, so we need more that one connection. How could we decide on which connection we send the admin message? Otherwise we will the send the same data more than once.
Re: [PROPOSAL AJP14] AJP13 Evolution
I think Costin has summed up the situation very well, in terms of the control/data issue. As the person who originally suggested thinking about a separate data channel, I am now strongly leaning away from that. The various complicated threading/process issues are not worth the grief. The only thing we really lose is the ability for the servlet engine to send a message to TC in between requests. And the main messages, as I see it, are: a) the entire engine is shutting down b) certain contexts are shutting down c) certain contexts are now live Henri, you're trying to cover that via the AJP_STATUS cmd, which the engine writes to the socket at the end of a request-handling cycle but which the web server only reads when it next goes to send a request over. Unless I misunderstand, the main reason for that delay is so that if the engine shuts down, and the socket dies, the web server will find out immediately (rather than sending across a request and only finding out on the subsequent read). [Socket trivia -- will this written-but-unread data cause any trouble during the TC shutdown process?] That part makes sense. However, you're also suggesting using that status command to send over config information via AJP_CONTEXT_(DOWN|UP|OK). I *do* like the idea of the engine sending over some control information at the end of every request-handling cycle, but I have two suggestions: 1) Don't use APR or OS-specific functions to see if there is more data. Instead, make a normal ajp13-style packet with a type of ajp_status_cmd, a length and a payload. That way you can fit arbitrarily large data (large numbers of changed contexts or config information, for example), and take advantage of the current ajp13 packet-handling functions. Conceivably, you could even set it up so that mod_jk could accept those packets *during* request handling, as well as at the end. BTW, currently, ajp13 sends over a single byte of status, which determines whether or not the connection should be reused. We'd basically just be expanding that. I like that idea a lot. 2) Have the web server read that config data immediately, but always have an extra dummy byte (or whatever) of padding at the end which the server can hold off on reading until the next request. That way, config information will flow up into the web server as soon as possible, and the logic will be much simpler (e.g. you won't get a situation where the server is about to forward a request and only then reads the config info which tells it that it can't forward that request). Then we just have to set up the Java code so that the context change information can get passed into an ajp13 thread which is servicing requests (so that it can tack it onto the end of the request cycle). Questions: what if multiple instances of Apache are forwarding requests to a single TC instance? How can TC know that? It has a single master socket, and then it hands off live sockets to individual threads, which hang onto them over many requests. If some of those threads are serving Apache 1, and some are serving Apache 2, then we have to make sure that the context change info goes into one thread from each group. And then on the Apache side, we have to bubble that config information up so that all the separate child processes change their config setup. (Is this true? Does Apache work differently than this somehow?) That sounds complicated. How is this handled in mod_webapp? Anyone? -Dan [EMAIL PROTECTED] wrote: Argh, all the subtility is here. Basically even if ajp13 is a bidirectional protocol, it's a request/reply protocol since it's how a web server function : 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE 2) WAIT FOR RESPONSE 3) GET RESPONSE AND FORWARD TO WEB-SERVER. Well, I see it a bit different :-) 1. Apache sends a message to tomcat with the original request ( or part of it ! - for example it can send only some headers that are commonly used ), then start waiting. 2. Tomcat receives the message, start processing. When he needs something from apache ( like sendHead or get info or auth or admin commands ) it sends a message, then start waiting. 3. That goes on, with a message acting as a token. At any time one side is listening, and the other ( who reveived the last message ) has the control. In a way it's like a single virtual thread of execution, with the apache thread and tomcat thread passing control via messages. Now, I know this sounds complicated - but it's a good solution with very little overhead. This is not a general RPC protocol, but something specialized for tomcat, and it works very well with single-threaded processes. Even in Apache2.0 - creating threads for each tomcat callback and using additional sockets is significant overhead given the time constraints. The problem is that the admin commands can be passed only on certain moments: - when apache connects for the first time (
Re: Tomcat 3.2.2 beta 4 - AJP14 continuation
On Mon, May 07, 2001 at 11:49:25PM +0200, GOMEZ Henri wrote: Should it become default? I hope the answer is yes:) It also has another value: inet is not a well-known parameter. Having it in default server.xml along with a little comment about what it does may compensate for the lack of proper documentation:) +1 for the addition in server.xml (Marc, Larry ?) Thanks! I don't really understand why Ajp protocol should handle shutdown command at all. I agree that there may be a need for some kind of servlet that handles this operation but WHY THROUGH Ajp protocol??? Adding shutdown in ajp14 will help a web admin to build a control deck to shutdown from ONE POINT some or all of its Tomcat. Correct me if I'm wrong, but it's possible to do the same thing with admin servlet. Besides, it seems to me that most of the time sys admin wants not to shutdown servers permanently but rather update class files or JSPs or reconfigure them and then restart. I think that having admin servlet that supports all (or some of) this things will ease this task a lot. Also it'll make Ajp protocol a tiny bit simpler which is always a good thing Here is one possible use case I've come up with: Sys admin has a script that executes rsync to update all the load-balanced TC machines. He than executes another script that sends HTTP restart command to all the TC's. Restart can be accomplished as following: In JVM: System.exit(EXIT_RESTART); // EXIT_RESTART !=0 :) In tomcat.sh: loop while exit code == EXIT_RESTART; Some people (including myself) like doing configuration manually in [skpd] I'm like you and do by hand all my configuration, and set my JkMount in VirtualHost. But many starting users will like the autoconf features. Note that JkMount could still be used and JkAutoMount is then mandatory... Don't get me wrong:) I'm not against JkAutoMount - it's cool. What I'm trying to say is: To address this group of people I'd suggest splitting distribution into pure java Tomcat part + extensions. This way only NECESSARY files will make their way to conf directory. If someone is (for example) interested in running stand-alone TC - he only downloads pure java part. If he needs to hook it into some Web server like Apache or IIS - he downloads apache extensions or IIS extensions, etc. Some people would prefer to use some UI tool to [skpd] Some Admin Servlet could do the job My point exactly:) 2) changed shutdown code to make it work correctly if inet parameter is used. Thanks to (re)send the code to list. Do you want me to send it again? 4) modified tomcat.sh file in bin to redirect stdoutstderr to a log file (people complained about not seeing System.out.println() stuff) Done by the official Tomcat RPM which modify tomcat.sh to feed /var/log/tomcat.log Not everyone uses Linux:) Not everyone uses RPM:) I use linux for developiment (but I prefer getting TC as *.tgz), our production systems are running Solaris. I'd still suggest to modify tomcat.sh (don't make this fix RPM-only). There is another cross-platform way of doing the same: System.setOut(errorLogStream); System.setErr(errorLogStream); 5) modified default load balancing behavior to make use of wireless device's global id (I'm not giving details on this one because it's specific to what we are doing and probably useless for others. But I'm not hiding it:) I can describe it if anyone is interested). Please. I realize I must'nt be too stupid since we have done many common things :) I would suggest it if it wasn't:))) I'm not proud of it:) It's a hack and I know about it's problems and limitations. That being said - here is what it does: Problem: We are doing wireless ad serving. One of the business rules says that we should support static URL to ad server. Ad server serves multiple ads - hence we need to remember what we've served to whom. It can't be part of the URL (it's static) and it can't be cookie (not all the wireless browsers have it). Solution: We are trying to use device's Global Id (part of the request on most of the devices) as SessionId. The TC java code has been modified accordingly and LB code has been modified to route based on Global Id ( session stickiness ). This solution doesn't address fail over issue properly. A better one would be to have persistent sessions (keep them in Data Base or something ...) but it would cost more. We've made similar modifications to JServ and it's been up for some time. Recently we decided to switch to TC because it supports newer API and is being developed/supported. I reimplemented modifications in TC as well although it hasn't been tested yet. As I said - it's not an elegant solution and If the requirement to have this feature turns out to be not important - we'll get rid of this hack:) Sorry for the long E-Mail:) Hope you've read it:) I read all of it. Hope to read you soon. I'm glad you did:) -- oo Andrey oo
[PATCH] Abount bug#1281
Hi, Bug#1281 was marked RESOLEVED FIXED, but this bug hasn't be fixed in Tomcat 3.2.2b4 yet. I think that the following patches should be applied to fix this problem if build.bat will not be removed in Tomcat 3.2.2 release. Yoshiyuki Karezaki --- jakarta-servletapi-3.2.2b4-src/build.bat.orig Tue May 8 23:58:28 2001 +++ jakarta-servletapi-3.2.2b4-src/build.batTue May 8 23:58:54 2001 @@ -13,7 +13,7 @@ :noclasspath set _CLASSPATH= -set CLASSPATH=%ANT_HOME%\lib\ant.jar;%JAVA_HOME/lib/tools.jar +set CLASSPATH=%ANT_HOME%\lib\ant.jar;%JAVA_HOME%/lib/tools.jar goto next :next --- jakarta-tomcat-3.2.2b4-src/build.bat.orig Fri Aug 25 06:34:18 2000 +++ jakarta-tomcat-3.2.2b4-src/build.batTue May 8 23:59:23 2001 @@ -21,7 +21,7 @@ :noclasspath set _CLASSPATH= -set CLASSPATH=%ANT_HOME%\lib\ant.jar;%SERVLETAPI_HOME%\lib\servlet.jar;..\jakarta-tools\moo.jar +set +CLASSPATH=%ANT_HOME%\lib\ant.jar;%SERVLETAPI_HOME%\lib\servlet.jar;..\jakarta-tools\moo.jar;%JAVA_HOME%\lib\tools.jar goto next :next @@ -37,4 +37,4 @@ set _SERVLETAPIHOME= set ANT_HOME=%_ANTHOME% set _ANTHOME=
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http10 HttpConnector.java HttpRequestImpl.java
On Tue, 8 May 2001, Kief Morris wrote: [EMAIL PROTECTED] typed the following on 03:37 AM 5/8/2001 + Make it possible to disable DNS lookups of the remote host name, for Tomcat used stand-alone, even when the web app calls request.getRemoteHost(). Lookups are enabled by default -- disable them by modifying the Connector ... disableLookups .../ attribute. I think it would be better to have DNS lookups _disabled_ by default (doesn't Apache httpd do this?). If someone really needs to get the hostname for their app, they can take the trouble to enable it, but the out of the box experience for Tomcat shouldn't be pig-slow for a probably unnecessary feature. IMHO of course. ;-) I can see your point (having been brow-beaten in a discussion on this topic late last night :-). However, the counter-arguments are: * Changing it to disabled by default would change behavior versus current Tomcats (of all generations), and possibly break apps that depend on host lookups. * Newbie servlet developers expect the API calls to work the way that the name implies - disabled by default would lead to lots of questions. I added a note in the default server.xml file with regards to potential performance impacts. Kief Craig
Re: [PROPOSAL/VOTE] Tomcat 4.0 Beta 4 Release
Craig R. McClanahan wrote: Now that the Proposed Final Draft 2 versions of the Servlet 2.3 and JSP 1.2 specs have been published (with Tomcat 4.0 updated to support the latest changes), and a ton of bug fixes have been made, I would like to propose that we create a Tomcat 4.0 Beta 4 release as follows: Release Manager: Craig McClanahan Code Freeze: Thursday, May 10, 2001 at 05:00pm Pacific Time See the file RELEASE-NOTES-4.0-B4.txt for a reasonably up-to-date list of the changes to date. This document will be updated with any additional changes that are made, plus a list of known outstanding issues. Between now and the code freeze, I'd like us to focus on fixing outstanding bugs and catching the configuration documentation up to date. I'm OK with continuing work on the new distributed session stuff in the mean time (as long as it is not enabled in the default configuration), but please hold off on making substantive changes in the core container until after the Beta 4 release. Comments? Votes? The usual rules apply: [ ] +1 = I agree with this proposal and will support it [ ] +0 = I agree with this proposal, but do not have time to support it [ ] -0 = I do not agree with this proposal, but don't want to try to block it [ ] -1 = I do not agree with this proposal (requires reasons) Craig +1 ..bip
Re: [PROPOSAL AJP14] AJP13 Evolution
On Tue, 8 May 2001, Dan Milstein wrote: The only thing we really lose is the ability for the servlet engine to send a message to TC in between requests. And the main messages, as I see it, are: a) the entire engine is shutting down b) certain contexts are shutting down c) certain contexts are now live All of those are low-frequency events, equivalent with a configuration change in the web server ( like you edit the apache.conf and add a new virtual host, same thing for NES or IIS ). All servers have mechanisms to deal with such things - like a signal or some other thing, and that can be abstracted. ( in fact, this shouldn't even be part of mod_jk - but a different component ) For multithreaded servers ( or multi-process servers that maintain a communication chain between servers - like the scoreboard ) this can also be implemented as a normal server module, that would handle a special request, and tomcat can do a simple reconfigure request using HTTP. Yet another solution: mod_jk can send a ping ( let's say after every 100 requests - or before the first request if a certain timeout ). There are many solutions for this - without adding complexity to the common case. [Socket trivia -- will this written-but-unread data cause any trouble during the TC shutdown process?] Just an exception ( unless you read before closing the socket ), and of course only on some platforms ( that implement corectly the TCP spec ). That part makes sense. However, you're also suggesting using that status command to send over config information via AJP_CONTEXT_(DOWN|UP|OK). I *do* like the idea of the engine sending over some control information at the end of every request-handling cycle, but I have two suggestions: Let's first solve the first 90% of the problem: tomcat sending config at the beginning. That resolves most of the configuration problems ( most users will not have to touch any server config files ). The other 10% ( contexts added/removed/changed at runtime ) is identical with the problem of web server config changed - we shouldn't try to be smarter than the server ( for now ). Just using the normal server restart should be enough and clean. With Apache2.0 and most multithreaded servers we can do a normal HTTP request from tomcat to apache and make a config change ( the config can be changed at runtime ), with apache1.3 there is no better solution than a restart ( if we want to let apache do the mappings - the mapping tree is created at startup time AFAIK ). BTW, currently, ajp13 sends over a single byte of status, which determines whether or not the connection should be reused. We'd basically just be expanding that. I like that idea a lot. +1 (so that it can tack it onto the end of the request cycle). Questions: what if multiple instances of Apache are forwarding requests to a single TC instance? How can TC know that? It has a single master socket, and then it hands off live sockets to individual threads, which hang onto them over many requests. If some of those threads are serving Apache 1, and some are serving Apache 2, then we have to make sure that the context change info goes into one thread from each group. And then on the Apache side, we have to bubble that config information up so that all the separate child processes change their config setup. (Is this true? Does Apache work differently than this somehow?) On connection open we need to pass some more info, and we'll have to save and organize this information. But I think this is orthogonal on the communication problem. For Apache1.3 we could use a signal or the scoreboard to signal to all processes. Costin
Re: Tomcat 3.2.2 beta 4 - AJP14 continuation
On Tue, 8 May 2001, Andrey Kartashov wrote: What I'm trying to say is: To address this group of people I'd suggest splitting distribution into pure java Tomcat part + extensions. This way only NECESSARY files will make their way to conf directory. If someone is (for example) interested in running stand-alone TC - he only downloads pure java part. If he needs to hook it into some Web server like Apache or IIS - he downloads apache extensions or IIS extensions, etc. +1 on the idea - but for 3.2.2 it's out of question, and for 3.3 someone has to do it - and closing bugs has bigger priority. If this is an itch for you, and you want to propose something ( and write some code ) - we're listening :-) I think Henri is also considering spliting the distribution in base tomcat, web applications. The connectors are already in a separate RPM. BTW, I like very much the idea of keeping the WARs ( examples, admin, etc) in separate distribution files. It was on the goals list to produce a minimal container, that implements the servlet API and nothing else, and separate the features. That didn't happen so far. Costin Some people would prefer to use some UI tool to [skpd] Some Admin Servlet could do the job My point exactly:) 2) changed shutdown code to make it work correctly if inet parameter is used. Thanks to (re)send the code to list. Do you want me to send it again? 4) modified tomcat.sh file in bin to redirect stdoutstderr to a log file (people complained about not seeing System.out.println() stuff) Done by the official Tomcat RPM which modify tomcat.sh to feed /var/log/tomcat.log Not everyone uses Linux:) Not everyone uses RPM:) I use linux for developiment (but I prefer getting TC as *.tgz), our production systems are running Solaris. I'd still suggest to modify tomcat.sh (don't make this fix RPM-only). There is another cross-platform way of doing the same: System.setOut(errorLogStream); System.setErr(errorLogStream); 5) modified default load balancing behavior to make use of wireless device's global id (I'm not giving details on this one because it's specific to what we are doing and probably useless for others. But I'm not hiding it:) I can describe it if anyone is interested). Please. I realize I must'nt be too stupid since we have done many common things :) I would suggest it if it wasn't:))) I'm not proud of it:) It's a hack and I know about it's problems and limitations. That being said - here is what it does: Problem: We are doing wireless ad serving. One of the business rules says that we should support static URL to ad server. Ad server serves multiple ads - hence we need to remember what we've served to whom. It can't be part of the URL (it's static) and it can't be cookie (not all the wireless browsers have it). Solution: We are trying to use device's Global Id (part of the request on most of the devices) as SessionId. The TC java code has been modified accordingly and LB code has been modified to route based on Global Id ( session stickiness ). This solution doesn't address fail over issue properly. A better one would be to have persistent sessions (keep them in Data Base or something ...) but it would cost more. We've made similar modifications to JServ and it's been up for some time. Recently we decided to switch to TC because it supports newer API and is being developed/supported. I reimplemented modifications in TC as well although it hasn't been tested yet. As I said - it's not an elegant solution and If the requirement to have this feature turns out to be not important - we'll get rid of this hack:) Sorry for the long E-Mail:) Hope you've read it:) I read all of it. Hope to read you soon. I'm glad you did:)
Re: [PROPOSAL AJP14] AJP13 Evolution
ajp13 reuses connections, but, in general for each worker there will be a pool of connections between the web server and the servlet engine. That way it can handle multiple requests concurrently, but still save on the socket creation time (since connections are reused for many requests). So deciding which connection to send the admin messages on is, in fact, important. Not only do we have to watch out for resending data, but we also have to make sure we send data to all the participating web servers (multiple Apaches can talk to one TC, and, if they do so, they can all hit the same port, in which case some ajp13 threads are talking to one, some to another). Maybe we should tag the TC-Apache admin messages with an id -- that way we could just send them out on all conections, and the various Apache children would make sure they only react to a given message once (possibly communicating w/ each other via shared memory). This will make the problem of informing all participating Apache instances go away, and we may need to play some shared memory games in any event, to make sure that all the Apache procs are brought up to date. -Dan Mike Braden wrote: Why not just handle each connection as if it is a connection from a different server, logging in each time. Are ajp13 requests serialized? ajp13 only connects to TC once to the port set in the config, right? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of jean-frederic clere Sent: Tuesday, May 08, 2001 5:19 AM To: [EMAIL PROTECTED] Subject: Re: [PROPOSAL AJP14] AJP13 Evolution Apjp13 requests are not multiplexed, so we need more that one connection. How could we decide on which connection we send the admin message? Otherwise we will the send the same data more than once. -- Dan Milstein // [EMAIL PROTECTED]
[GUMP] Build Failure - Tomcat 3.x
This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/2001-05-08/jakarta-tomcat.html Buildfile: build.xml detect: msg.jdk12: [echo] Detected JDK1.2 msg.jsse: [echo] Detected JSSE init: prepare: [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/src [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/native [copy] Copying 10 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [copy] Copying 19 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf [copy] Copied 1 empty directory to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf [copy] Copying 42 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc [copy] Copied 1 empty directory to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc [copy] Copying 89 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/native [copy] Copied 13 empty directories to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/native [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat [copy] Copying 7 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [copy] Could not find file /home/rubys/jakarta/jakarta-ant/dist/lib/jaxp.jar to copy. BUILD FAILED /home/rubys/jakarta/jakarta-tomcat/build.xml:117: Could not find file /home/rubys/jakarta/jakarta-ant/dist/lib/jaxp.jar to copy. Total time: 7 seconds
RE: [PROPOSAL/VOTE] Tomcat 4.0 Beta 4 Release
+0 Larry -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 10:22 PM To: [EMAIL PROTECTED] Subject: [PROPOSAL/VOTE] Tomcat 4.0 Beta 4 Release Now that the Proposed Final Draft 2 versions of the Servlet 2.3 and JSP 1.2 specs have been published (with Tomcat 4.0 updated to support the latest changes), and a ton of bug fixes have been made, I would like to propose that we create a Tomcat 4.0 Beta 4 release as follows: Release Manager: Craig McClanahan Code Freeze: Thursday, May 10, 2001 at 05:00pm Pacific Time See the file RELEASE-NOTES-4.0-B4.txt for a reasonably up-to-date list of the changes to date. This document will be updated with any additional changes that are made, plus a list of known outstanding issues. Between now and the code freeze, I'd like us to focus on fixing outstanding bugs and catching the configuration documentation up to date. I'm OK with continuing work on the new distributed session stuff in the mean time (as long as it is not enabled in the default configuration), but please hold off on making substantive changes in the core container until after the Beta 4 release. Comments? Votes? The usual rules apply: [ ] +1 = I agree with this proposal and will support it [ ] +0 = I agree with this proposal, but do not have time to support it [ ] -0 = I do not agree with this proposal, but don't want to try to block it [ ] -1 = I do not agree with this proposal (requires reasons) Craig
Re: [PROPOSAL/VOTE] Tomcat 4.0 Beta 4 Release
Craig R. McClanahan at [EMAIL PROTECTED] wrote: Now that the Proposed Final Draft 2 versions of the Servlet 2.3 and JSP 1.2 specs have been published (with Tomcat 4.0 updated to support the latest changes), and a ton of bug fixes have been made, I would like to propose that we create a Tomcat 4.0 Beta 4 release as follows: Release Manager: Craig McClanahan Code Freeze: Thursday, May 10, 2001 at 05:00pm Pacific Time +1 with full web connection support... Pier
cvs commit: jakarta-tomcat-4.0/tester/src/bin tester.xml
craigmcc01/05/08 11:36:27
Modified:tester/src/bin tester.xml
Log:
Make more strings configurable for testing behind a proxy server.
Revision ChangesPath
1.40 +20 -29jakarta-tomcat-4.0/tester/src/bin/tester.xml
Index: tester.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- tester.xml2001/05/03 23:06:28 1.39
+++ tester.xml2001/05/08 18:36:22 1.40
@@ -8,8 +8,10 @@
!-- property name=protocol value=HTTP/1.0/ --
property name=protocol value=/ !-- Use HttpURLConnection --
property name=context.path value=/tester/
+ property name=examples.path value=/examples/
property name=golden.pathvalue=${context.path}/golden/
property name=manager.path value=/manager/
+ property name=reload.pathvalue=/tester/
taskdef name=tester classname=org.apache.tester.TestClient/
@@ -27,12 +29,12 @@
!-- Should be able to use relative path to document root --
tester host=${host} port=${port} protocol=${protocol}
- request=/examples/.. debug=${debug}
+ request=${examples.path}/.. debug=${debug}
status=302/
!-- Should not be able to use relative path above document root --
tester host=${host} port=${port} protocol=${protocol}
- request=/examples/../.. debug=${debug}
+ request=${examples.path}/../.. debug=${debug}
status=404/
!-- Should be able to successfully retrieve a golden file --
@@ -92,57 +94,46 @@
!-- Should be able to execute the Date example --
touch file=${catalina.home}/webapps/examples/jsp/dates/date.jsp/
tester host=${host} port=${port} protocol=${protocol}
- request=/examples/jsp/dates/date.jsp debug=${debug}
+ request=${examples.path}/jsp/dates/date.jsp debug=${debug}
status=200/
!-- Should not be able to view the source of the Date example --
touch file=${catalina.home}/webapps/examples/jsp/dates/date.jsp/
tester host=${host} port=${port} protocol=${protocol}
- request=/examples/jsp/dates/date.Jsp debug=${debug}
+ request=${examples.path}/jsp/dates/date.Jsp debug=${debug}
status=404/
!-- Should not be able to view the source of the Date example --
touch file=${catalina.home}/webapps/examples/jsp/dates/date.jsp/
tester host=${host} port=${port} protocol=${protocol}
- request=/examples/jsp/dates/Date.jsp debug=${debug}
+ request=${examples.path}/jsp/dates/Date.jsp debug=${debug}
status=404/
!-- Should not be able to view the source of the Date example --
touch file=${catalina.home}/webapps/examples/jsp/dates/date.jsp/
tester host=${host} port=${port} protocol=${protocol}
- request=/examples/jsp/Dates/date.jsp debug=${debug}
+ request=${examples.path}/jsp/Dates/date.jsp debug=${debug}
status=404/
!-- Should not be able to view the source of the Date example --
touch file=${catalina.home}/webapps/examples/jsp/dates/date.jsp/
tester host=${host} port=${port} protocol=${protocol}
- request=/examples/Jsp/dates/date.jsp debug=${debug}
+ request=${examples.path}/Jsp/dates/date.jsp debug=${debug}
status=404/
-!-- Should not be able to view the source of the Date example --
-touch file=${catalina.home}/webapps/examples/jsp/dates/date.jsp/
-tester host=${host} port=${port} protocol=${protocol}
- request=/Examples/jsp/dates/date.jsp debug=${debug}
- status=404/
-
!-- Should be able to execute the HelloWorld servlet example --
tester host=${host} port=${port} protocol=${protocol}
- request=/examples/servlet/HelloWorldExample debug=${debug}
+ request=${examples.path}/servlet/HelloWorldExample debug=${debug}
status=200/
!-- Should not be able to execute HelloWorld with different cases --
-tester host=${host} port=${port} protocol=${protocol}
- request=/examples/servlet/helloWorldExample debug=${debug}
- status=404/
-
-!-- Should not be able to execute HelloWorld with different cases --
tester host=${host} port=${port} protocol=${protocol}
- request=/examples/Servlet/HelloWorldExample debug=${debug}
+ request=${examples.path}/servlet/helloWorldExample debug=${debug}
status=404/
!-- Should not be able to execute HelloWorld with different cases --
tester host=${host} port=${port} protocol=${protocol}
- request=/Examples/servlet/HelloWorldExample debug=${debug}
+ request=${examples.path}/Servlet/HelloWorldExample
RE: Tomcat 3.2.2 beta 4
Spent all day investigating this, and I can't track down the problem. I've written an example class that does servlet to serlvet POST's but I can't make it error with the same problem. I think there must be something more complicated going on. I don't think this should hold up the release of TC3.2.2(if it was) as it is not a new bug introduced since TC3.2.1. I will continue to investigate. Dave [EMAIL PROTECTED] From: Dave Oxley [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 08 May 2001 15:27:04 +0100 Just tried it and yes: TC3.2.2b4 with AJP12 does work. Dave. [EMAIL PROTECTED] From: Marc Saegesser [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 8 May 2001 08:44:03 -0500 Dave, Does it work OK with 3.2.2b4 and AJP12? -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 08, 2001 7:15 AM To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Some further info on this problem. It works fine with TC3.2.1 with AJP12. TC3.2.1 goes into an infinite loop using 100% processor with AJP13. TC3.2.2b4 gives the stack trace with AJP13 but does not infinite loop like TC3.2.1. I have tried with Apache 1.3.19, but it made no difference. I have tried this with Java 1.3.0_01 and 1.3.0_02 with the same results. I am running Windows 2000. I will write a test servlet a bit later on. Dave. [EMAIL PROTECTED] From: Dave Oxley [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 08 May 2001 12:07:44 +0100 I have just found another problem though. This is not a new problem with 3.2.2. We have just started using the O'Reily HttpMessage code to send a Post message to a servlet from another servlet (in the same virtual machine). The Stream within the POST contains a Vector of Serializable objects. The POST works as expected, no problems, but when shutting down Tomcat we get the following stack trace and the process never finishes. This is using TC3.2.2b4 with Apache 1.3.17 (I will try 1.3.19). java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleError(ContextManager. java:1160) at org.apache.tomcat.core.ContextManager.internalService(ContextMana ger.java:800) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.proces sConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool. java:501) at java.lang.Thread.run(Thread.java:484) 2001-03-08 11:17:32 - Ctx( ): 404 R( /spweb/servlet/StaffPlannerServlet) null 2001-03-08 11:17:32 - Ctx( ): Exception in: R( /spweb/servlet/StaffPlannerServlet) - java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager .java:1058) at org.apache.tomcat.core.ContextManager.internalService(ContextMana ger.java:775) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.proces sConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool. java:501) at java.lang.Thread.run(Thread.java:484) I will write a little sample program if you think it is worthwhile and post it to the group. Dave. [EMAIL PROTECTED] _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
FW: Handler Thread Problem
Kevin, I wanted to take the timeout to thanks you for your help with solving this problem. I had been trying for several weeks to resolve this. YOUR the MAN The information you gave me was the clue I needed to fix this problem. It's working perfectly!! Again Thank you. -Ben
Re: [PROPOSAL/VOTE] Tomcat 4.0 Beta 4 Release
+1 I am currently trying to track down a problem related to use of the SecurityManager with jndi named class/jar files in a web app under MS Window systems. It works fine under Unix. Regards, Glenn Craig R. McClanahan wrote: Now that the Proposed Final Draft 2 versions of the Servlet 2.3 and JSP 1.2 specs have been published (with Tomcat 4.0 updated to support the latest changes), and a ton of bug fixes have been made, I would like to propose that we create a Tomcat 4.0 Beta 4 release as follows: Release Manager: Craig McClanahan Code Freeze: Thursday, May 10, 2001 at 05:00pm Pacific Time See the file RELEASE-NOTES-4.0-B4.txt for a reasonably up-to-date list of the changes to date. This document will be updated with any additional changes that are made, plus a list of known outstanding issues. Between now and the code freeze, I'd like us to focus on fixing outstanding bugs and catching the configuration documentation up to date. I'm OK with continuing work on the new distributed session stuff in the mean time (as long as it is not enabled in the default configuration), but please hold off on making substantive changes in the core container until after the Beta 4 release. Comments? Votes? The usual rules apply: [ ] +1 = I agree with this proposal and will support it [ ] +0 = I agree with this proposal, but do not have time to support it [ ] -0 = I do not agree with this proposal, but don't want to try to block it [ ] -1 = I do not agree with this proposal (requires reasons) Craig -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
RE: Tomcat 3.2.2 beta 4
Dave, Thanks for looking at this. If you do come up with a small example that demonstrates the problem let me know. -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 08, 2001 2:16 PM To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Spent all day investigating this, and I can't track down the problem. I've written an example class that does servlet to serlvet POST's but I can't make it error with the same problem. I think there must be something more complicated going on. I don't think this should hold up the release of TC3.2.2(if it was) as it is not a new bug introduced since TC3.2.1. I will continue to investigate. Dave [EMAIL PROTECTED] From: Dave Oxley [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 08 May 2001 15:27:04 +0100 Just tried it and yes: TC3.2.2b4 with AJP12 does work. Dave. [EMAIL PROTECTED] From: Marc Saegesser [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 8 May 2001 08:44:03 -0500 Dave, Does it work OK with 3.2.2b4 and AJP12? -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 08, 2001 7:15 AM To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Some further info on this problem. It works fine with TC3.2.1 with AJP12. TC3.2.1 goes into an infinite loop using 100% processor with AJP13. TC3.2.2b4 gives the stack trace with AJP13 but does not infinite loop like TC3.2.1. I have tried with Apache 1.3.19, but it made no difference. I have tried this with Java 1.3.0_01 and 1.3.0_02 with the same results. I am running Windows 2000. I will write a test servlet a bit later on. Dave. [EMAIL PROTECTED] From: Dave Oxley [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 08 May 2001 12:07:44 +0100 I have just found another problem though. This is not a new problem with 3.2.2. We have just started using the O'Reily HttpMessage code to send a Post message to a servlet from another servlet (in the same virtual machine). The Stream within the POST contains a Vector of Serializable objects. The POST works as expected, no problems, but when shutting down Tomcat we get the following stack trace and the process never finishes. This is using TC3.2.2b4 with Apache 1.3.17 (I will try 1.3.19). java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleError(ContextManager. java:1160) at org.apache.tomcat.core.ContextManager.internalService(ContextMana ger.java:800) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.proces sConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool. java:501) at java.lang.Thread.run(Thread.java:484) 2001-03-08 11:17:32 - Ctx( ): 404 R( /spweb/servlet/StaffPlannerServlet) null 2001-03-08 11:17:32 - Ctx( ): Exception in: R( /spweb/servlet/StaffPlannerServlet) - java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager .java:1058) at org.apache.tomcat.core.ContextManager.internalService(ContextMana ger.java:775) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.proces sConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool. java:501) at java.lang.Thread.run(Thread.java:484) I will write a little sample program if you think it is worthwhile and post it to the group. Dave. [EMAIL PROTECTED] _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Authenticators.properties ContextConfig.java
craigmcc01/05/08 14:22:40
Modified:catalina/src/share/org/apache/catalina/deploy
LoginConfig.java
catalina/src/share/org/apache/catalina/startup
Authenticators.properties ContextConfig.java
Added: catalina/src/share/org/apache/catalina/authenticator
NonLoginAuthenticator.java
Log:
If the only security constraint defined for a web application imposes only
limits not related to authentication (such as only a user-data-constraint),
install a special Authenticator that imposes the remaining constraints.
Previously, these constraints were being ignored unless there was a
login-config element defined.
Submitted by: QingQing Ouyang [EMAIL PROTECTED]
Revision ChangesPath
1.1
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/NonLoginAuthenticator.java
Index: NonLoginAuthenticator.java
===
/*
* $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/NonLoginAuthenticator.java,v
1.1 2001/05/08 21:22:29 craigmcc Exp $
* $Revision: 1.1 $
* $Date: 2001/05/08 21:22:29 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*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, Tomcat, 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 Group.
*
* 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
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.catalina.authenticator;
import java.io.IOException;
import java.security.Principal;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.catalina.HttpRequest;
import org.apache.catalina.HttpResponse;
import org.apache.catalina.Realm;
import org.apache.catalina.Session;
import org.apache.catalina.deploy.LoginConfig;
/**
* An bAuthenticator/b and bValve/b implementation that checks
* only security constraints not involving user authentication.
*
* @author Craig R. McClanahan
* @version $Revision: 1.1 $ $Date: 2001/05/08 21:22:29 $
*/
public final class NonLoginAuthenticator
extends AuthenticatorBase {
// - Instance Variables
/**
* Descriptive information about this
problems running a servlet that uses core catalina classes
Hello, I am sorry to bother you. But I am trying to write a servlet that uses some core apache classes and I have problems running it. - If I use a war archive, tomcat does not find the tomcat classes/servlet classes when it starts the servlet. (ClassNoDefFound error). If I then add the catalina.jar and servlet.jar to the classpath, I have a conflict between classes loaded dynamically by tomcat and classes in the classpath. (More precisely I have an object whose class is ServletWrapper but is not an instance of ServletWrapper. This is because (I guess) the object is created by the Tomcat classloader and it is compared with an instance of the classpath objects), - If I put the jar file in the common/lib directory, it finds the servlet classes but not the tomcat classes. - If I put the jar file in server/lib directory, it does not load my servlet. The only way I can make it work is to put it in the catalina.jar file. But that is not nice at all. Could someone help me with this? Thank you. Fabien Le Floc'h P.S.: I was wondering if it was user or developer oriented... As I want to use core Tomcat classes I thought it was developer but maybe I am wrong. Then I apologize.
RE: [PROPOSAL AJP14] AJP13 Evolution
1) How did we share it in forked (apache 1.3) env ? = shared memory = MM or APR APR of course: MM is included in it. But APR is only available in Apache 2.0, what about Apache 1.3, NES and IIS ? And MM is still only for Unix OS 2) Ditto in a threaded architecture (Apache 2.0) at least in MPM mode (a forked child which will in turn thread child), but again how did we info we other forked. Also doubling the socket, will double the descriptors open and will be a problem under heavy load. In an HTTP architecture we need again to mix data (tons of messages) with control (very low traffic). And so we need to read for possible message at some time. 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE 2) WAIT FOR END OF PREVIOUS REPLY AND EVENTUALLY ADMIN MESSAGE 3) GET ADMIN MESSAGE and evnetually RESPONSE 4) GET RESPONSE AND FORWARD TO WEB-SERVER. The admin message could be send() in socket at any time and will be handled when a request will came Apjp13 requests are not multiplexed, so we need more that one connection. How could we decide on which connection we send the admin message? Otherwise we will the send the same data more than once. The admin response could be sent on EACH AJP13 connections, and it will be web-server task to discard allready received admin message... What happends when the configuration is changed more than once and no request happend in the meantime... We could get a wrong configuration... If we have a DOWN event and then a UP event, the servlet engine send a DOWN message and then a UP message. The web-servlet will have to read ALL ADMIN messages and process the whole block...
RE: [PROPOSAL AJP14] AJP13 Evolution
1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE 2) WAIT FOR RESPONSE 3) GET RESPONSE AND FORWARD TO WEB-SERVER. Well, I see it a bit different :-) 1. Apache sends a message to tomcat with the original request ( or part of it ! - for example it can send only some headers that are commonly used ), then start waiting. 2. Tomcat receives the message, start processing. When he needs something from apache ( like sendHead or get info or auth or admin commands ) it sends a message, then start waiting. 3. That goes on, with a message acting as a token. At any time one side is listening, and the other ( who reveived the last message ) has the control. In a way it's like a single virtual thread of execution, with the apache thread and tomcat thread passing control via messages. Now, I know this sounds complicated - but it's a good solution with very little overhead. This is not a general RPC protocol, but something specialized for tomcat, and it works very well with single-threaded processes. The only reserve will be about speed. Won't these write() and read() make web-server too slow. But that's interesting and will need testing in real condition. AJP14 could test these experimental schemas. Even in Apache2.0 - creating threads for each tomcat callback and using additional sockets is significant overhead given the time constraints. The problem is that the admin commands can be passed only on certain moments: - when apache connects for the first time ( the socket will be kept open ) - when apache sends a request I think that should be enough for what we need - if we make it more complex we may add too much overhead. ( and we may not be able to have good support for Apache1.3 ) More overhead will make ajp14 slower than ajp13, or even ajp12 and that's not the goal since admin message are only 1% of the real traffic
Bad link to tomcat 3.2.2beta3 on tomcat site
The link on the below page is to Tomcat 3.2.2 beta 3 instead of beta 4, beta 3 doesn't exist on the server. http://jakarta.apache.org/site/binindex.html Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
RE: [PROPOSAL AJP14] AJP13 Evolution
ajp13 reuses connections, but, in general for each worker there will be a pool of connections between the web server and the servlet engine. That way it can handle multiple requests concurrently, but still save on the socket creation time (since connections are reused for many requests). So deciding which connection to send the admin messages on is, in fact, important. Not only do we have to watch out for resending data, but we also have to make sure we send data to all the participating web servers (multiple Apaches can talk to one TC, and, if they do so, they can all hit the same port, in which case some ajp13 threads are talking to one, some to another). Each AJP14 thread in Tomcat must send admin messages. It will be the task of web-server to remove duplicate messages. Maybe we should tag the TC-Apache admin messages with an id -- that way we could just send them out on all conections, and the various Apache children would make sure they only react to a given message once (possibly communicating w/ each other via shared memory). This will make the problem of informing all participating Apache instances go away, and we may need to play some shared memory games in any event, to make sure that all the Apache procs are brought up to date. +1 for the ID of admin messages, which make the removing easier. shared memory will make mod_jk port on differents web-server/OS more harder, and we might introduce here the use of APR. But there is APR specialists around !=) -Dan Mike Braden wrote: Why not just handle each connection as if it is a connection from a different server, logging in each time. Are ajp13 requests serialized? ajp13 only connects to TC once to the port set in the config, right? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of jean-frederic clere Sent: Tuesday, May 08, 2001 5:19 AM To: [EMAIL PROTECTED] Subject: Re: [PROPOSAL AJP14] AJP13 Evolution Apjp13 requests are not multiplexed, so we need more that one connection. How could we decide on which connection we send the admin message? Otherwise we will the send the same data more than once. -- Dan Milstein // [EMAIL PROTECTED]
RE: Tomcat 3.2.2 beta 4
Could you try with the mod_jk from TC 3.3 cvs ? Could you also send a small servlet for test purpose ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Tomcat 3.2.2 : RE : cvs commit: jakarta-tomcat/src/doc readme
Hi Marc, Could you clarify the getRemoteHost in readme := === 7. FIXES AND ENHANCEMENTS IN UPDATES @@ -318,6 +332,8 @@ - HttpServletRequest.encodeURL() now properly encodes URLs that contain an anchor but no query string. (#1182) - Error pages now work in virtual hosts. + - ServletRequest.getRemoteHost() now returns the remote IP address + if the remote host name isn't known. (#208) = === 7. FIXES AND ENHANCEMENTS IN UPDATES @@ -318,6 +332,8 @@ - HttpServletRequest.encodeURL() now properly encodes URLs that contain an anchor but no query string. (#1182) - Error pages now work in virtual hosts. + - ServletRequest.getRemoteHost() now returns the remote IP address + if the remote host name has not been resolved by web-server. (#208) Regards
RE: New CVS Repositories
Thanks - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 08, 2001 4:14 AM To: [EMAIL PROTECTED] Subject: New CVS Repositories Per our discussion today, I have created two new CVS repositories associated with the Tomcat subproject: jakarta-tomcat-connectorsFor development of web connectors for various versions of Tomcat. jakarta-tomcat-jasperFor development of a next generation Jasper (JSP) implementation. As with the other repositories that are part of Tomcat, all Tomcat committers have commit access to these new repositories automatically. Craig
RE: [PROPOSAL AJP14] AJP13 Evolution
Many users have asked for more web-server env vars they like to use also in Tomcat. May be something to add to AJP14 will be the ability to define a list of env vars to be forwarded to Tomcat, the same way the SSL web-server vars are defined : # What is the indicator for SSL session (default is SSL_SESSION_ID) JkSESSIONIndicator SSL_SESSION_ID # What is the indicator for client SSL cipher suit (default is SSL_CIPHER) JkCIPHERIndicator SSL_CIPHER # What is the indicator for the client SSL certificated (default is SSL_CLIENT_CERT) JkCERTSIndicator SSL_CLIENT_CERT May be with the directive JkEnvVars MYVAR1 MYVAR2 MYVAR3 MYVAR4... The traffic will be more important but these informations will be usefull for some... What about that ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: [PROPOSAL AJP14] AJP13 Evolution
On Wed, 9 May 2001, GOMEZ Henri wrote: May be with the directive JkEnvVars MYVAR1 MYVAR2 MYVAR3 MYVAR4... The traffic will be more important but these informations will be usefull for some... What about that ? +1 to add this to a TODO list, but low priority :-) Let's first get the auto configuration to work, as this seem the most requested feature, then we can add other callbacks and features. ( I do have few features I will need for some extra optimizations on tomcat, but again - it's low priority compared with getting things rolling and improving the config ). Costin
RE: Class Loader Problem?
Hello, I still have not figured this out, but have some more information. If anyone can give me some tips on what to look into, I would be very grateful. OS: Solaris 2.6 JDK: 1.3.0 I have gone so far as completely removing VCALookup.class from my classes directory and I still get the same Exception. I also tried instantiating the class from a different file (first line of my doGet()) and still get the same Exception. I copied a known good class (my servlet class), renamed it to VCALookup.class, same Exception. So, it's not the class's problem. Any ideas? TIA --Tonnis -Original Message- From: Wildeboer, Tonnis Sent: Tuesday, May 01, 2001 7:20 PM To: '[EMAIL PROTECTED]' Subject: Class Loader Problem? I am using Tomcat 3.2.1 and getting the Exception printed below for a class file (VCALookup.class) that I KNOW is not malformed (since the class loads and runs fine under Weblogic 4.0.4). The Exception appears to occur during the loading of another class (VCATemplate) that in turn accesses VCALookup. The loading of that class (VCATemplate) is happening when one of its static methods is being called by MediatorAgent.printTemplateResponse(). All my classes were compiled with the -g flag. Also, Tomcat is being run without any security manager or policy and auto-reloading has been turned off. The Weblogic deployment is using security -- would that matter...? (I'll work on using security next...) Any help would be greatly appreciated. --Tonnis __ Tonnis Wildeboer [EMAIL PROTECTED] Stack print follows: 2001-05-01 04:19:15 - Ctx( ): Exception in: R( + /csp + /+cfi/login) - java.lang.ClassFormatError: VCALookup (Truncated class file) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass0(Compiled Code) at java.lang.ClassLoader.defineClass(Compiled Code) at java.security.SecureClassLoader.defineClass(Compiled Code) at java.net.URLClassLoader.defineClass(Compiled Code) at java.net.URLClassLoader.access$1(Compiled Code) at java.net.URLClassLoader$1.run(Compiled Code) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessController.doPrivileged(Compiled Code) at java.net.URLClassLoader.findClass(Compiled Code) at java.lang.ClassLoader.loadClass(Compiled Code) at sun.misc.Launcher$AppClassLoader.loadClass(Compiled Code) at java.lang.ClassLoader.loadClass(Compiled Code) at org.apache.tomcat.loader.AdaptiveClassLoader.loadClass(Compiled Code) at java.lang.ClassLoader.loadClass(Compiled Code) at java.lang.ClassLoader.loadClassInternal(Compiled Code) at MediatorAgent.printTemplateResponse(Compiled Code) at MediatorAgent.printResponse(MediatorAgent.java:606) at MainVCAServlet.doGeneral(Compiled Code) at MainVCAServlet.doGet(MainVCAServlet.java:196) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:79 7) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC onnectionHandler.java:210) at org.apache.tomcat.service.TcpWorkerThread.runIt(Compiled Code) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(Compiled Code) at java.lang.Thread.run(Compiled Code)
RE: [PROPOSAL/VOTE] Tomcat 4.0 Beta 4 Release
On Tue, 8 May 2001, GOMEZ Henri wrote: +0 but with RPM packaging ;) And source packages, right Henri? :-) They will be there at the same time as the binaries this time. Craig
Re: Class Loader Problem?
Wildeboer, Tonnis wrote: [...] I have gone so far as completely removing VCALookup.class from my classes directory and I still get the same Exception. I also tried instantiating the class from a different file (first line of my doGet()) and still get the same Exception. I copied a known good class (my servlet class), renamed it to VCALookup.class, same Exception. Ok, this is what the Javadocs say about java.lang.ClassFormatError. snip Thrown when the Java Virtual Machine attempts to read a class file and determines that the file is malformed or otherwise cannot be interpreted as a class file. /snip I interpret this as that the classloader are _finding_ the class but has problems loading it. What is this file/class? Something you copied from somewhere? Could it be that you are missing an inline class for VCALookup? i.e. VCALookup$inlineclass.class I would think that there's something wrong with the VCALookup class, if it couldn't find the file you wou'd have gotten a ClassNotFoundException. Is VCALookup refering to any other classed that you've missed to bring to your Tomcat env? 2001-05-01 04:19:15 - Ctx( ): Exception in: R( + /csp + /+cfi/login) - java.lang.ClassFormatError: VCALookup (Truncated class file) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass0(Compiled Code) at java.lang.ClassLoader.defineClass(Compiled Code) at java.security.SecureClassLoader.defineClass(Compiled Code) at java.net.URLClassLoader.defineClass(Compiled Code) at java.net.URLClassLoader.access$1(Compiled Code) at java.net.URLClassLoader$1.run(Compiled Code) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessController.doPrivileged(Compiled Code) at java.net.URLClassLoader.findClass(Compiled Code) at java.lang.ClassLoader.loadClass(Compiled Code) at sun.misc.Launcher$AppClassLoader.loadClass(Compiled Code) at java.lang.ClassLoader.loadClass(Compiled Code) at org.apache.tomcat.loader.AdaptiveClassLoader.loadClass(Compiled Code) at java.lang.ClassLoader.loadClass(Compiled Code) at java.lang.ClassLoader.loadClassInternal(Compiled Code) at MediatorAgent.printTemplateResponse(Compiled Code) at MediatorAgent.printResponse(MediatorAgent.java:606) at MainVCAServlet.doGeneral(Compiled Code) at MainVCAServlet.doGet(MainVCAServlet.java:196) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:79 7) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC onnectionHandler.java:210) at org.apache.tomcat.service.TcpWorkerThread.runIt(Compiled Code) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(Compiled Code) at java.lang.Thread.run(Compiled Code) Sorry I can't help you more. ..bip
RE: [PROPOSAL AJP14] AJP13 Evolution
Just as a note, if you want AJP14 to be usable in a Servlet 2.3 environment, you *must* expose the cipher suite and key size (which might be implied from the cipher suite name) to Tomcat, because Tomcat must in turn expose them as request attributes to servlets processing SSL requests. In addition, if there is a client certificate included with the request, it also needs to be exposed, but I believe that is already being done, isn't it? Craig On Wed, 9 May 2001, GOMEZ Henri wrote: Many users have asked for more web-server env vars they like to use also in Tomcat. May be something to add to AJP14 will be the ability to define a list of env vars to be forwarded to Tomcat, the same way the SSL web-server vars are defined : # What is the indicator for SSL session (default is SSL_SESSION_ID) JkSESSIONIndicator SSL_SESSION_ID # What is the indicator for client SSL cipher suit (default is SSL_CIPHER) JkCIPHERIndicator SSL_CIPHER # What is the indicator for the client SSL certificated (default is SSL_CLIENT_CERT) JkCERTSIndicator SSL_CLIENT_CERT May be with the directive JkEnvVars MYVAR1 MYVAR2 MYVAR3 MYVAR4... The traffic will be more important but these informations will be usefull for some... What about that ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: problems running a servlet that uses core catalina classes
In Tomcat 4 the core catalina classes in servlet/lib/catalina.jar are hidden from servlets. A servlet should use the standard Servlet 2.3 classes to access public information for the request. Your servlet would not be portable across differenct servlet containers if you used internal servlet container classes. In addition, making those interal tomcat classes visible to web applications could allow the security of the servlet container and web applications to be compromised. Regards, Glenn Fabien Le Floc'h wrote: Hello, I am sorry to bother you. But I am trying to write a servlet that uses some core apache classes and I have problems running it. - If I use a war archive, tomcat does not find the tomcat classes/servlet classes when it starts the servlet. (ClassNoDefFound error). If I then add the catalina.jar and servlet.jar to the classpath, I have a conflict between classes loaded dynamically by tomcat and classes in the classpath. (More precisely I have an object whose class is ServletWrapper but is not an instance of ServletWrapper. This is because (I guess) the object is created by the Tomcat classloader and it is compared with an instance of the classpath objects), - If I put the jar file in the common/lib directory, it finds the servlet classes but not the tomcat classes. - If I put the jar file in server/lib directory, it does not load my servlet. The only way I can make it work is to put it in the catalina.jar file. But that is not nice at all. Could someone help me with this? Thank you. Fabien Le Floc'h P.S.: I was wondering if it was user or developer oriented... As I want to use core Tomcat classes I thought it was developer but maybe I am wrong. Then I apologize. -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
RE: Tomcat 3.2.2 beta 4
I will try with that mod_jk and will send the test servlet as soon as I can write a simple one that breaks. :) Dave [EMAIL PROTECTED] From: GOMEZ Henri [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Wed, 9 May 2001 00:21:30 +0200 Could you try with the mod_jk from TC 3.3 cvs ? Could you also send a small servlet for test purpose ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
RE: Class Loader Problem?
Well, I considered all those things and finally, I did the only thing you can do when things get this weird: I did a completely clean checkout and rebuild of everything and of course... problem solved. Guess I'll never know what was really happening, but the experience (and solution) is a lesson in itself... Thanks for your reply. --Tonnis -Original Message- From: Bip Thelin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 08, 2001 4:48 PM To: [EMAIL PROTECTED] Subject: Re: Class Loader Problem? Wildeboer, Tonnis wrote: [...] I have gone so far as completely removing VCALookup.class from my classes directory and I still get the same Exception. I also tried instantiating the class from a different file (first line of my doGet()) and still get the same Exception. I copied a known good class (my servlet class), renamed it to VCALookup.class, same Exception. Ok, this is what the Javadocs say about java.lang.ClassFormatError. snip Thrown when the Java Virtual Machine attempts to read a class file and determines that the file is malformed or otherwise cannot be interpreted as a class file. /snip I interpret this as that the classloader are _finding_ the class but has problems loading it. What is this file/class? Something you copied from somewhere? Could it be that you are missing an inline class for VCALookup? i.e. VCALookup$inlineclass.class I would think that there's something wrong with the VCALookup class, if it couldn't find the file you wou'd have gotten a ClassNotFoundException. Is VCALookup refering to any other classed that you've missed to bring to your Tomcat env? 2001-05-01 04:19:15 - Ctx( ): Exception in: R( + /csp + /+cfi/login) - java.lang.ClassFormatError: VCALookup (Truncated class file) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass0(Compiled Code) at java.lang.ClassLoader.defineClass(Compiled Code) at java.security.SecureClassLoader.defineClass(Compiled Code) at java.net.URLClassLoader.defineClass(Compiled Code) at java.net.URLClassLoader.access$1(Compiled Code) at java.net.URLClassLoader$1.run(Compiled Code) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessController.doPrivileged(Compiled Code) at java.net.URLClassLoader.findClass(Compiled Code) at java.lang.ClassLoader.loadClass(Compiled Code) at sun.misc.Launcher$AppClassLoader.loadClass(Compiled Code) at java.lang.ClassLoader.loadClass(Compiled Code) at org.apache.tomcat.loader.AdaptiveClassLoader.loadClass(Compiled Code) at java.lang.ClassLoader.loadClass(Compiled Code) at java.lang.ClassLoader.loadClassInternal(Compiled Code) at MediatorAgent.printTemplateResponse(Compiled Code) at MediatorAgent.printResponse(MediatorAgent.java:606) at MainVCAServlet.doGeneral(Compiled Code) at MainVCAServlet.doGet(MainVCAServlet.java:196) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:79 7) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC onnectionHandler.java:210) at org.apache.tomcat.service.TcpWorkerThread.runIt(Compiled Code) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(Compiled Code) at java.lang.Thread.run(Compiled Code) Sorry I can't help you more. ..bip
Getting values of Local Environment Variables in Servlets using Tomcat3.2.1 ?
We are having problems getting the values the local CGI environment variables in our servlets using Tomcat3.2. It works fine with Jserv and the we are able to export these variables using Jserv. But we are not able to do that with Tomcat3.2.1. These variables are being set by authentication system and we are able to retrieve them through simple cgi/perl script as well. We are able to get the values of these variables in Jserv using --- Object attrsObj = req.getAttribute(org.apache.jserv.attribute_names); Is theresome equivalent method or some other way of getting local environment variables in Tomat3.2.1 by changing either the source code or configuration files ? Kashyap Vaswani Software Developer, Academic Computing Department, Stanford University.
Re: [PROPOSAL AJP14] AJP13 Evolution
on 5/8/01 3:00 PM, GOMEZ Henri [EMAIL PROTECTED] wrote: But APR is only available in Apache 2.0, what about Apache 1.3, NES and IIS ? That isn't true. http://Apr.apache.org/ APR is just a library. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html
Re: Bad link to tomcat 3.2.2beta3 on tomcat site
on 5/8/01 3:15 PM, Glenn Nielsen [EMAIL PROTECTED] wrote: The link on the below page is to Tomcat 3.2.2 beta 3 instead of beta 4, beta 3 doesn't exist on the server. http://jakarta.apache.org/site/binindex.html Thank you for asking for permission to commit to the jakarta-site2 module. You can now fix it yourself. If you need help understanding things, RTM: http://jakarta.apache.org/site/jakarta-site2.html :-) -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html
RE: Bad link to tomcat 3.2.2beta3 on tomcat site
Fixed now. I apparently goofed when I updated the files and only got the generated binindex.html file checked in and missed the binindex.xml file. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Glenn Nielsen Sent: Tuesday, May 08, 2001 5:16 PM To: [EMAIL PROTECTED] Subject: Bad link to tomcat 3.2.2beta3 on tomcat site The link on the below page is to Tomcat 3.2.2 beta 3 instead of beta 4, beta 3 doesn't exist on the server. http://jakarta.apache.org/site/binindex.html Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: JSP quoting and escape conventions
% out.println(testing %\); %
doesn't work...
I think this is a bug in Tomcat. - Use The Source, Luke!
The following code is from Tomcat 3.2. Seems to be from late Nov/early Dec 2000.
From org.apache.jasper.compiler.JspUtil.java:
public static char[] removeQuotes(char []chars) {
CharArrayWriter caw = new CharArrayWriter();
for (int i = 0; i chars.length; i++) {
/**/if (chars[i] == '%' chars[i+1] == '\\'
/**/chars[i+2] == '\\' chars[i+3] == '') {
caw.write('%');
caw.write('');
i = i + 3;
}
else caw.write(chars[i]);
}
return caw.toCharArray();
}
The two lines marked with /**/ mean that writing
% out.println(testing %\\); %
works and prints:
testing %
This differs from the spec.
(Besides, trying to parse
% // this will fail: %\\%
will throw an ArrayIndexOutOfBoundsException.)
Cheers,
Jona.
-
From http://www2.real-time.com/pipermail/tomcat-users/2001-February/023848.html
:
-
Craig, I know you're the man, but it seems that the JSP Spec 1.1 says that
the JSP compiler should translate a %\ into % and keep going looking for a
% just to that his example would work.
Section 2.4 Quoting and Escape Conventions seems to me to say that in the
example he lists (here it is again :)
% String foo = testing %\; %
should be allowable and that the JSP compiler should generate a line like :
String foo = testing %;
While I agree that
String foo = testing %\;
is invalid java code, it is the JSP compilers responsibility to convert the
JSP escape sequence.
Thanks,
Paul
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 21, 2001 3:26 PM
To: [EMAIL PROTECTED]
Subject: Re: JSP quoting and escape conventions
William Au wrote:
Yes, I see what you mean. I guess it is a matter of what happen first.
If the escape happens first, then the JSP
% String foo = testing %\; %
would be translate to the following java code
String foo = testing %;
Then it would be valid java code.
However, it seems to me in Tomcat, the translation happens first so the
following
invalid java code is generated:
String foo = testing %\;
What is happening first is what *has* to happen first -- the JSP parser
sees the
%\ but recognizes (correctly) that this is not the end of the
scriptlet. This
is exactly in accordance to the spec.
Therefore, all of the text between the % and the % is passed
through to the
language compiler for the scripting language (Java in this case),
uninterpreted
by the JSP page compiler. The uninterpreted code is not valid Java
syntax, and
therefore violates the JSP specification -- just the same as if you
forgot a
quote around the string literal, or omitted a required semicolon, or
made some
other error in Java syntax.
Bill
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
