RE: Thread-safety
hi again! -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Monday, January 29, 2001 7:11 PM To: [EMAIL PROTECTED] Subject: Re: Thread-safety on 1/29/01 3:52 AM, "Klemme, Robert, myview" [EMAIL PROTECTED] wrote: i cannot believe that people at sun would risk these consequences, do they? LOL! That is the funniest thing I have read in a long time! :-) you're not saying i'm naive, are you? :-)) well, at least you had fun. :- People are not perfect and they make human errors. This is clearly one of them and is also in an area that is *very* difficult to get right. surely they are. but since everybody knows that optimizations are a difficult topic one should be cautious and evolve slowly. apart from that, even i - who had only a single lecture about compiler construction - did know this. so i would have expected people at sun to know it, too... well, but maybe again naive... regards robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Thread-safety
There are IMHO two reasons why these statements may be 'executed' out of order: 1. If the compiler (or the JVM executing the bytecode) can prove that the reordering won't have any effect *on the current thread* (in this case, the value is not referenced elsewhere *in the current thread*, then reordering is allowed (with some restrictions like those concerning the synchronized blocks). This makes sure that all assignments made by a thread will be seen in that order by *that* thread. If there are no restrictions within a certain amount of code, then the compiler/JVM is free to reorder those instructions to improve performance. 2. Even if the instructions are executed in order, the memory subsystem can flush the writes to main memory in another order than the process wrote them to the memory subsystem (again with certain restrictions). I think this case is even easier to visualise than the preceding one. If, in a multiprocessor system every write to a variable has to be accompanied by extensive communication between caches on all levels to make sure everything happens in order, there would be a serious performance hit. I'm not familiar with the architecture of current multiprocessor systems, but I'm pretty sure that the restrictions on the order of memory stores has been relaxed as well for the general case, but that they all have some way to garantee consistency when the need arises. Since the Java bytecode runs on an abstract machine, the designers of the language needed a system to have an abstract way of specifying this 'consistency' and they included it in the synchronized statement. To summarize: The designers of the JVM spec relaxed the requirements on order of execution to allow as much performance as possible while still guaranteeing the outcome of a program *if it is run in a single thread* (I believe the word is 'deterministic'). Whenever there's communication between threads, the programmer must be *very* careful to ensure that the state seen by one thread corresponds to the one written by another. AFAIK the only mechanism the Java language provides to ensure this is the use of synchronized blocks. Luc Vanlerberghe "Klemme, Robert, myview" wrote: thank you paul to point me at an omission. -Original Message- From: Paul Speed [mailto:[EMAIL PROTECTED]] Sent: Monday, January 29, 2001 11:54 AM To: [EMAIL PROTECTED] Subject: Re: Thread-safety [...] The problem is that the point of the code block is to be sure that the _jspx_init() method has been completed before proceeding. The problem is that _jspx_inited might appear to other threads to be set to true before the original thread has completed executing the _jspx_init() method (or at least before its changes are available to other threads). This means that the second thread would come through, see that _jspx_inited is true, and skip the synchronization block. That threads execution would then proceed thinking that everything has been initialized when it hasn't. ok, i see. thank you again for clarifying. do i now fully understand the issue: the problem at hand cannot easily be solved by assigning the flag from the return value of the init() method because of a combination of inlining and reordering which might again lead to a prior assignment. is that so? normally i would say that a code like "_jspx_inited = do_init();" may not be rearranged in a way that the assignment occurs prior to finishing of the method body (especially since there can be exceptions). i would guess that - by allowing this - a whole bunch of programs would run berserk or simply break... i cannot believe that people at sun would risk these consequences, do they? Check out the article that is referenced in other mail in this thread or hit JavaWorld and see the references section on the article about singletons. this one? http://www.javaworld.com/javaworld/jw-04-1999/jw-04-toolbox.html regards robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
4.0/4.1 merge
Howdy folks, I've been on the road for a few days. What's the status of the 4.0/4.1 merge? Are we ready for the new branch to work on session persistence stuff? Anything I can do to help things along if not? Kief - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Thread-safety
There are IMHO two reasons why these statements may be 'executed' out of order: Good explanation. AFAIK the only mechanism the Java language provides to ensure this is the use of synchronized blocks. One could also consider the volatile keyword in this category. But few JVMs implement volatile according to spec... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] Ajp13 dsp file revisited
This patch corrects the MS VC include directory in the new 3.3 directory structure: http://www.apache.org/~keith/jk/dsp.txt Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Thread-safety
hi! -Original Message- From: Luc Vanlerberghe [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 30, 2001 10:26 AM To: [EMAIL PROTECTED] Subject: Re: Thread-safety There are IMHO two reasons why these statements may be 'executed' out of order: [...] tis is all very reasonable. To summarize: The designers of the JVM spec relaxed the requirements on order of execution to allow as much performance as possible while still guaranteeing the outcome of a program *if it is run in a single thread* what irritates me here is the point that they should not have taken into consideration what happens to multithreaded programs. this is because as far as i understand support for multithreaded applications is one of the core features of the java language. (I believe the word is 'deterministic'). Whenever there's communication between threads, the programmer must be *very* careful to ensure that the state seen by one thread corresponds to the one written by another. AFAIK the only mechanism the Java language provides to ensure this is the use of synchronized blocks. ironically the optimization which was implemented for performance improvement does lead to a performance loss (because the locking of objects is costly) in another place. of course, overall this could still be an improvement - especially if most of the code executes "single threaded"... regards robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Thread-safety
"Klemme, Robert, myview" wrote: what irritates me here is the point that they should not have taken into consideration what happens to multithreaded programs. this is because as far as i understand support for multithreaded applications is one of the core features of the java language. Multithreading is a lot easier in Java than in any other language I know of and so is the synchronization between threads using 'synchronize' blocks. The danger lies in people trying to devise clever schemes to circumvent the costly locking of objects and not realising their code is not thread-safe because of that. If you take the conservative approach and synchronize whenever data is exchanged between threads you're safe. Anything else must be studied *very* carefully by someone with sufficient experience in the field. ironically the optimization which was implemented for performance improvement does lead to a performance loss (because the locking of objects is costly) in another place. of course, overall this could still be an improvement - especially if most of the code executes "single threaded"... If this optimization was not allowed, then the JVM would effectively be forced to synchronize on *every single access* to main memory. If you take into account that usually most of the useful stuff that a thread does (i.e.: handling some kind of request/method call/whatever) does not need synchronization since it stays in its own memory space (I mean, it uses objects or values that no other thread is modifying), the performance benefits can be enormous. Only when communicating other thread, you have to use the synchronized keyword to insert barriers for these optimizations... Luc Vanlerberghe "Klemme, Robert, myview" wrote: hi! -Original Message- From: Luc Vanlerberghe [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 30, 2001 10:26 AM To: [EMAIL PROTECTED] Subject: Re: Thread-safety There are IMHO two reasons why these statements may be 'executed' out of order: [...] tis is all very reasonable. To summarize: The designers of the JVM spec relaxed the requirements on order of execution to allow as much performance as possible while still guaranteeing the outcome of a program *if it is run in a single thread* what irritates me here is the point that they should not have taken into consideration what happens to multithreaded programs. this is because as far as i understand support for multithreaded applications is one of the core features of the java language. (I believe the word is 'deterministic'). Whenever there's communication between threads, the programmer must be *very* careful to ensure that the state seen by one thread corresponds to the one written by another. AFAIK the only mechanism the Java language provides to ensure this is the use of synchronized blocks. ironically the optimization which was implemented for performance improvement does lead to a performance loss (because the locking of objects is costly) in another place. of course, overall this could still be an improvement - especially if most of the code executes "single threaded"... regards robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: problem in using SecurityManager with tomcat
Look at tomcat.sh, the shell arg "-security" needs to be shifted out so it isn't
passed on as an option just before java org.apache.tomcat.startup.Tomcat is started.
BTW, this is fixed for the next Tomcat 3.2.x release.
Regards,
Glenn
Gauri Sukhatankar wrote:
Hi,
I am having problems in using the SecurityManager with tomcat 3.2.1.
There seems to be a bug or documention mismatch.
Please let me know if you have any ideas on fixing this:
I am using Tomcat 3.2.1 to run a servlet that acts as an RMI client.
Based on the documentation
(http://jakarta.apache.org/tomcat/jakarta-tomcat/src/doc/uguide/tomcat-security-
unix.html) I have done the following to allow for listen, accept, resolve socket
security permissions through my web application:
1. Edited server.xml to use Policy:
ContextInterceptor className="org.apache.tomcat.context.PolicyInterceptor" /
2. Edited tomcat.policy
3. Started tomcat with the "-security" option.
tomcat.sh start -security
Although the script "tomcat.sh" accepts the "-security" option, the class:
org.apache.tomcat.startup.Tomcat
exits with a Usage error :
Usage: java org.apache.tomcat.startup.Tomcat {options}
Options are:
-config file (or -f file) Use this file instead of server.xml
-help (or help)Show this usage report
-home dir (or -h dir) Use this directory as tomcat.home
-stop
On the other hand, if i don't use policy I get an access control exception with
this stack trace:
java.security.AccessControlException: access denied (java.net.SocketPermission
172.20.71.30:1099 connect,resolve)
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.fillInStackTrace(Compiled Code)
at java.lang.Throwable.init(Compiled Code)
at java.lang.Exception.init(Compiled Code)
at java.lang.RuntimeException.init(RuntimeException.java:47)
at java.lang.SecurityException.init(SecurityException.java:39)
at
java.security.AccessControlException.init(AccessControlException.java:57)
at java.security.AccessControlContext.checkPermission(Compiled Code)
at java.security.AccessController.checkPermission(Compiled Code)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkConnect(SecurityManager.java:1021)
at java.net.Socket.init(Socket.java:258)
at java.net.Socket.init(Socket.java:98)
at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFacto
ry.java:29)
at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(Compiled
Code)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:497)
at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:194)
at sun.rmi.transport.tcp.TCPChannel.newConnection(Compiled Code)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:322)
at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
at java.rmi.Naming.lookup(Naming.java:89)
at RMIServlet.connectToServer(RMIServlet.java:72)
at RMIServlet.init(RMIServlet.java:21)
at org.apache.tomcat.core.ServletWrapper.doInit(ServletWrapper.java:317)
at org.apache.tomcat.core.Handler.init(Handler.java:215)
at org.apache.tomcat.core.ServletWrapper.init(ServletWrapper.java:296)
at org.apache.tomcat.core.Handler.service(Handler.java:254)
at
org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797)
at
org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at
org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConne
ctionHandler.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(Thread.java:479)
Thanks in advance,
Gauri Sukhatankar
Sun Microsystems, Inc.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
larryi 01/01/30 06:50:18 Modified:.RELEASE-PLAN-3.3 Log: Move Milestone 1 back a week and fix Milestone 2 to be about midway between Milestone 1 and Beta 1. Fix some indentation. Revision ChangesPath 1.6 +5 -5 jakarta-tomcat/RELEASE-PLAN-3.3 Index: RELEASE-PLAN-3.3 === RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- RELEASE-PLAN-3.3 2001/01/23 20:45:07 1.5 +++ RELEASE-PLAN-3.3 2001/01/30 14:50:14 1.6 @@ -30,7 +30,7 @@ Tomcat 3.3 Milestone 1 Release: - Code Freeze/Tag Date: Feb 1, 2001 + Code Freeze/Tag Date: Feb 8, 2001 Release Manager:Larry Isaacs To help insure widespread testing, this build must include an acceptably @@ -57,16 +57,16 @@ Tomcat 3.3 Milestone 2 Release: - Code Freeze/Tag Date: Feb 8, 2001 + Code Freeze/Tag Date: March 1, 2001 Release Manager:Larry Isaacs This release is optional depending on the amount of bug fixing that - occurs since the milestone 1 release. The major goal of the week +occurs since the milestone 1 release. The major goal of the week following milestone 1 will be to identify what further work is needed based on the feedback. During this time it is hoped that there will be enough bug fixes and tests added to make this release worthwhile. - Should that not be the case, this release may be skipped since the - beta release is expected a week later. +Should that not be the case, this release may be skipped since the +beta release is expected a week later. Tomcat 3.3 Beta: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
larryi 01/01/30 08:03:12 Modified:.RELEASE-PLAN-3.3 Log: Final update. Modify to not promise to fix all bugs. Update Release Criteria 9 to better specify its scope. Revision ChangesPath 1.7 +6 -4 jakarta-tomcat/RELEASE-PLAN-3.3 Index: RELEASE-PLAN-3.3 === RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- RELEASE-PLAN-3.3 2001/01/30 14:50:14 1.6 +++ RELEASE-PLAN-3.3 2001/01/30 16:03:07 1.7 @@ -110,7 +110,7 @@ Any reported regression is a show-stopper and a release can't be made before it is resolved. -2. Open bugs should be resolved. +2. Open bugs should be fixed, if possible. 3. Tomcat 3.3 should be tested with existing, complex applications ( cocoon, bugrat, etc ). @@ -118,7 +118,7 @@ 4. Jasper must include bug fixes that were done in both 3.2.x and 4.0, and various enhancements that are deemed appropriate. -5. Bugs found after and during 3.2 release cycle should be fixed. +5. Bugs found after and during 3.2 release cycle should be fixed, if possible. 6. Full review of the code, making sure the modularity and extensibility goals have been achieved. @@ -129,8 +129,10 @@ 8. Ensure that the performance is (significantly) better than 3.2 -9. Ensure that Jasper is compatible ( as much as possible ) with the - version used in the proposed 4.0. +9. Ensure that Jasper is compatible (as much as possible) with the + version used in the proposed 4.0. This refers to behavior differences + outside of the JSP spec, which could create problems moving a + web application from Tomcat 3.3 to Tomcat 4.x. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] Tomcat 3.3 Release Plan
Tomcat 3.3 Release Plan Ballot: [X] +1I am in favor of this plan and will help [ ] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1I am against this plan being executed, and my reason is: Larry Isaacs P.S. Please refer to the original e-mail ballot for full details. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
Since characters in Java are UNICODE, what does this code do when it encounters a
character who's code point is greater than 0xFF?
My suggestion, is to first encode the path as a UTF-8 byte array, then encode the
bytes according to this algorithm
Tim
[EMAIL PROTECTED] wrote:
remm01/01/29 19:50:09
Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
Log:
- Will now encode all unsafe characters on the URL.
Revision ChangesPath
1.22 +84 -28
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
Index: DefaultServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- DefaultServlet.java 2001/01/25 05:45:40 1.21
+++ DefaultServlet.java 2001/01/30 03:50:08 1.22
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
1.21 2001/01/25 05:45:40 remm Exp $
- * $Revision: 1.21 $
- * $Date: 2001/01/25 05:45:40 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
1.22 2001/01/30 03:50:08 remm Exp $
+ * $Revision: 1.22 $
+ * $Date: 2001/01/30 03:50:08 $
*
*
*
@@ -76,6 +76,7 @@
import java.io.Reader;
import java.io.InputStreamReader;
import java.io.Writer;
+import java.io.OutputStreamWriter;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLEncoder;
@@ -87,6 +88,7 @@
import java.util.Locale;
import java.util.TimeZone;
import java.util.Hashtable;
+import java.util.BitSet;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.security.MessageDigest;
@@ -119,7 +121,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.21 $ $Date: 2001/01/25 05:45:40 $
+ * @version $Revision: 1.22 $ $Date: 2001/01/30 03:50:08 $
*/
public class DefaultServlet
@@ -219,6 +221,40 @@
StringManager.getManager(Constants.Package);
+/**
+ * Array containing the safe characters set.
+ */
+protected static BitSet safeCharacters;
+
+
+protected static final char[] hexadecimal =
+{'0', '1', '2', '3', '4', '5', '6', '7', '8', '9',
+ 'A', 'B', 'C', 'D', 'E', 'F'};
+
+
+// - Static Initializer
+
+
+static {
+ safeCharacters = new BitSet(256);
+ int i;
+ for (i = 'a'; i = 'z'; i++) {
+ safeCharacters.set(i);
+ }
+ for (i = 'A'; i = 'Z'; i++) {
+ safeCharacters.set(i);
+ }
+ for (i = '0'; i = '9'; i++) {
+ safeCharacters.set(i);
+ }
+ safeCharacters.set('-');
+ safeCharacters.set('_');
+ safeCharacters.set('.');
+ safeCharacters.set('*');
+ safeCharacters.set('/');
+}
+
+
// - Public Methods
@@ -853,7 +889,7 @@
replaceChar +
normalized.substring(index + 3);
}
-
+
// Normalize the slashes and add leading slash if necessary
if (normalized.indexOf('\\') = 0)
normalized = normalized.replace('\\', '/');
@@ -902,29 +938,49 @@
* @param path Path which has to be rewiten
*/
protected String rewriteUrl(String path) {
-
-String normalized = path;
-
- // Replace " " with "%20"
-while (true) {
- int index = normalized.indexOf(" ");
- if (index 0)
- break;
- normalized = normalized.substring(0, index) + "%20"
- + normalized.substring(index + 1);
- }
-
- // Replace "" with "%26"
-while (true) {
- int index = normalized.indexOf("");
- if (index 0)
- break;
- normalized = normalized.substring(0, index) + "%26"
- + normalized.substring(index + 1);
- }
-
-return normalized;
-
+
+/**
+ * Note: This code portion is very similar to URLEncoder.encode.
+ * Unfortunately, there is no way to specify to the URLEncoder which
+ * characters should be encoded. Here, ' ' should be encoded as "%20"
+ * and '/' shouldn't be encoded.
+ */
+
+ int maxBytesPerChar = 10;
+int caseDiff = ('a' - 'A');
+StringBuffer rewrittenPath =
RE: [VOTE] Tomcat 3.3 Release Plan
Tomcat 3.3 Release Plan Ballot: [X] +1I am in favor of this plan and will help [ ] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1I am against this plan being executed, and my reason is: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] Tomcat 3.3 Release Plan
Hola a todos: - Please return this portion with your vote - Tomcat 3.3 Release Plan Ballot: [X] +1 I am in favor of this plan and will help [ ] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1 I am against this plan being executed, and my reason is: - Saludos , Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] HTML cleanup typo fixes in tomcat-apache-howto.html
HTML cleanup typo fixes in tomcat-apache-howto.html [salt:tarball/jakarta-tomcat-3.2.1/doc] pepper% diff -u tomcat-apache-howto.html tomcat-apache-howto.html.patch --- tomcat-apache-howto.htmlTue Dec 12 16:36:55 2000 +++ tomcat-apache-howto.html.patch Tue Jan 30 11:50:57 2001 @@ -1,3 +1,4 @@ +!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" html head !-- $Id: tomcat-apache-howto.html,v 1.2.2.2 2000/10/05 06:37:52 larryi Exp $ -- @@ -141,19 +142,22 @@ h4a name="work_together"How will they work together?/a/h4 blockquote -p In a nutshell a web server is waiting for requests.nbsp; When these requests arrive the server does whatever is needed to +p In a nutshell a web server is waiting for requests.nbsp; When +these requests arrive the server does whatever is needed to serve the requests by providing the necessary content.nbsp; Adding Tomcat to the mix may somewhat change this behavior.nbsp; Now the web server needs to perform the following: ul li Before the first request can be served, Apache needs to load a web -server adapter (how Tomcat will communicate w/Apache) library and initialize it. /li - li When a request arrives, Apache needs to check and see if it belongs to a servlet, if so it needs to let the adapter + server adapter library (so Tomcat can communicate with Apache) + and initialize it. /li + li When a request arrives, Apache needs to check and see if it + belongs to a servlet; if so it needs to let the adapter take the request and handle it./li /ul pWe'd like Apache to handle our static content, such as -images and html documents, and to forward all requests for +images and HTML documents, and forward all requests for dynamic content to Tomcat.nbsp; More specifically, we need answers to the following questions:/p blockquote @@ -227,14 +231,18 @@ /p blockquote - p class="code"lt;servletbr - nbsp;nbsp;nbsp; lt;servlet-namegt;SlifkaWorldlt;/servlet-namebr - nbsp;nbsp;nbsp; lt;servlet-classgt;foo.bar.baz.SomeClasslt;/servlet-classbr - nbsp;nbsp;nbsp; lt;init-parambr - nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; lt;param-namegt;someParameterlt;/param-namegt;br - nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; lt;param-valuegt;A valuelt;/param-valuegt;br - nbsp;nbsp;nbsp; lt;/init-parambr -lt;/servlet + p class="code"lt;servletgt;br + nbsp;nbsp;nbsp; + lt;servlet-namegt;SlifkaWorldlt;/servlet-namegt;br + nbsp;nbsp;nbsp; + lt;servlet-classgt;foo.bar.baz.SomeClasslt;/servlet-classgt;br + nbsp;nbsp;nbsp; lt;init-paramgt;br + nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; + lt;param-namegt;someParameterlt;/param-namegt;br + nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; + lt;param-valuegt;A valuelt;/param-valuegt;br + nbsp;nbsp;nbsp; lt;/init-paramgt;br +lt;/servletgt; /p /blockquote @@ -327,13 +335,15 @@ blockquote p class="code"lt;!-- Apache AJP12 support. This is also used to shut down tomcat. - --br -lt;Connector className="org.apache.tomcat.service.PoolTcpConnector"br + --gt;br +lt;Connector +className="org.apache.tomcat.service.PoolTcpConnector"gt;br nbsp;nbsp;nbsp; lt;Parameter name="handler"br - nbsp;nbsp;nbsp;nbsp; value="org.apache.tomcat.service.connector.Ajp12ConnectionHandler"/br + nbsp;nbsp;nbsp;nbsp; + +value="org.apache.tomcat.service.connector.Ajp12ConnectionHandler"/gt;br nbsp;nbsp;nbsp; lt;Parameter name="port"br - nbsp;nbsp;nbsp;nbsp;nbsp;value="8007"/br -lt;/Connector/p + nbsp;nbsp;nbsp;nbsp;nbsp;value="8007"/gt;br +lt;/Connectorgt;/p /blockquote pTo ensure that it is indeed listening on that port, Telnet to it or @@ -541,7 +551,6 @@ blockquote pFor now, refer to the comments in the mod_jk.conf-auto file and a href="mod_jk-howto.html"mod_jk HOWTO/a for details./p -/p /blockquote h4a name="httpd_jserv"tomcat-apache.conf/a @@ -786,15 +795,15 @@ following snippet from server.xml in our AJP section:/p blockquote p class="code"lt;!-- Apache AJP12 support. This is also used to shut down tomcat. - --br + --lt;br lt;Connector className=quot;org.apache.tomcat.service.PoolTcpConnectorquot;gt;br nbsp;nbsp;nbsp; lt;Parameter name="handler"nbsp;br nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; - value="org.apache.tomcat.service.connector.Ajp12ConnectionHandler"/br + value="org.apache.tomcat.service.connector.Ajp12ConnectionHandler"/gt;br nbsp;nbsp;nbsp; lt;Parameter name="port"br
Re: [PATCH] HTML cleanup typo fixes in tomcat-ssl-howto.html
[Previous patch with this title was for the wrong file. Correct patch follows. --cp] HTML cleanup typo fixes in tomcat-ssl-howto.html [salt:tarball/jakarta-tomcat-3.2.1/doc] pepper% diff -u tomcat-ssl-howto.html tomcat-ssl-howto.html.patch --- tomcat-ssl-howto.html Tue Dec 12 16:36:22 2000 +++ tomcat-ssl-howto.html.patch Tue Jan 30 12:05:20 2001 @@ -1,3 +1,4 @@ +!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" html head !-- $Id $ -- @@ -45,41 +46,61 @@ /td /tr /table + h1Tomcat and SSL/h1 + pBy Gomez Henri ttlt;a href="mailto:[EMAIL PROTECTED]"[EMAIL PROTECTED]/agt;/tt/p + h2Table of Contents/h2 + ul lia href="#s2"Tomcat and SSL/a/li lia href="#s3"Building tomcat with SSL support/a/li lia href="#s4"Tomcat with Apache and mod_jk/a/li - lia href="#s5"SSL via apache/a/li - lia href="#s6"SSL direct/a/li + lia href="#s5"SSL via Apache/a/li + lia href="#s6"Direct SSL/a/li lia href="#s7"Credits/a/li /ul + hr + h2a name=s2Tomcat and SSL/a/h2 -pTomcat could use SSL directly (via an HTTP connector supporting SSL) or via - an Apache SSLified (a href="http://www.apachessl.org"Apache-SSL/a or apache-mod_ssl) + +pTomcat can use SSL directly (via an HTTP connector supporting SSL) or via + an SSL-capable Apache (a + href="http://www.apachessl.org"Apache-SSL/a or a + href="http://www.modssl.org"apache+mod_ssl/a) with the mod_jk connector./p + hr + h2a name=s3Building tomcat with SSL support/a/h2 -pIf you want to rebuild the tomcat with SSL, be carefull of your CLASSPATH. - I used to clear the CLASSPATH env var to avoid conflict in jar. A common case - of conflict is for XML parsers (xerces jaxp). tomcat need a recent XML parser - like Apache Group xerces 1.1.2 or Sun's jaxp 1.0.1./p -pAt build time, (via ant), tomcat will check for some libs and will then included - more or less options. It's the case of SSL support. If you have the JSSE 1.0.2 - jars in your CLASSPATH, tomcat will be built with SSL (SSLSocketFactory). tomcat - will use the JSSE jars (jcert.jar, jsse.jar, jnet.jar).This software COULDN'T - BE INCLUDED in tomcat. You'll have to go to a href="http://java.sun.com/products/jsse/%20"jsse - home page /aand download from there the domestic (US/Canada) or global archive. - Then copy the 3 jars in tomcat runtime classpath lib ($TOMCAT_HOME/lib)./p + +pIf you want to rebuild tomcat with SSL, be careful of your + CLASSPATH. I used to clear the CLASSPATH environment variable to avoid + conflict in jar. A common cause of conflict is XML parsers (xerces + amp; jaxp). Tomcat needs a recent XML parser like the Apache Group's + xerces 1.1.2 or Sun's jaxp 1.0.1./p +pAt build time, (via ant), tomcat will check for some libs and will + then include various options, possibly including SSL support. If you + have the JSSE 1.0.2 jars in your CLASSPATH, tomcat will be built with + SSL (SSLSocketFactory). Tomcat will use the JSSE jars (jcert.jar, + jsse.jar, jnet.jar). This software COULDN'T BE INCLUDED in tomcat. + You'll have to go to the a + href="http://java.sun.com/products/jsse/"jsse home page/a and + download the domestic (US/Canada) or global archive from there. Then + copy the 3 jars into tomcat's runtime classpath lib + ($TOMCAT_HOME/lib)./p + hr + h2a name=s4Tomcat with Apache and mod_jk/a/h2 -pIf you use Apache with SSL (apache-ssl or apache-mod_ssl), the apache connector - mod_jk will be able to forward to tomcat some SSL informations if JkExtractSSL - directive is present in your httpd.conf. /p -pInformations are :/p + +pIf you use Apache with SSL (Apache-SSL or apache+mod_ssl) and the + JkExtractSSL directive in httpd.conf, the apache connector + mod_jk will be able to pass some SSL information to tomcat./p +pThis information is:/p + table width="75%" border="1" tr tdHTTPS/td @@ -98,8 +119,10 @@ tdSSL Certificate of client/td /tr /table -pSince apache-ssl and apache-mod_ssl use differents env vars, you could adapt - SSL vars via the following JK vars /p + +pSince Apache-SSL and apache+mod_ssl use different environment variables, you + can set SSL variables from the following JK variables/p + ul liJkExtractSSL/li liJkHTTPSIndicator/li @@ -107,153 +130,182 @@ liJkCIPHERIndicator/li liJkCERTSIndicator: /li /ul -phere is an example of directive to include in httpd.conf for use with mod_ssl -/p -pfont face="Courier New, Courier, mono" size="-1"# Should mod_jk send SSL - information to Tomact (default is On)br - JkExtractSSL On br - # What is the indicator for SSL (default is HTTPS)br - JkHTTPSIndicator HTTPS br - # What is the indicator for SSL session (default is SSL_SESSION_ID) br - JkSESSIONIndicator SSL_SESSION_ID br - # What is the indicator for client SSL cipher suit (default is SSL_CIPHER) br - JkCIPHERIndicator SSL_CIPHER br - # What is the indicator for the client SSL certificated (default is SSL_CLIENT_CERT) - br - JkCERTSIndicator
[PATCH] for Bug Report 741 (security constraint match)
The new behavior is as following:
When defining a security constraint for "/foo/*",
matches resource "/foo" and "/foo/whatever" but not
"/foo.jsp"
Cheers,
Dimitris Dinodimos
__
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
Index: StaticInterceptor.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/request/Attic/StaticInterceptor.java,v
retrieving revision 1.7.2.6
diff -u -r1.7.2.6 StaticInterceptor.java
--- StaticInterceptor.java 2000/12/12 20:33:46 1.7.2.6
+++ StaticInterceptor.java 2001/01/29 20:11:10
@@ -485,6 +485,7 @@
if (! inInclude) {
res.setContentType("text/html");
+ res.setLocale(locale);
buf.append("html\r\n");
buf.append("head\r\n");
buf.append("title")
@@ -634,7 +635,7 @@
if (! inInclude) buf.append("/body/html\r\n");
- if( res.isUsingWriter() ) {
+ if( !res.isUsingStream() ) {
PrintWriter out=res.getWriter();
out.print(buf);
} else {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] for Bug Report 741 (security constraint match)
Oops. This is the correct patch file.
--- Dimitris Dinodimos [EMAIL PROTECTED] wrote:
The new behavior is as following:
When defining a security constraint for "/foo/*",
matches resource "/foo" and "/foo/whatever" but not
"/foo.jsp"
Cheers,
Dimitris Dinodimos
__
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
Index: AccessInterceptor.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/request/Attic/AccessInterceptor.java,v
retrieving revision 1.12.2.4
diff -u -r1.12.2.4 AccessInterceptor.java
--- AccessInterceptor.java 2000/08/24 21:50:51 1.12.2.4
+++ AccessInterceptor.java 2001/01/29 20:10:37
@@ -321,7 +321,9 @@
switch( ct.getMapType() ) {
case Container.PREFIX_MAP:
- return path.startsWith( ctPath.substring(0, ctPathL - 2 ));
+ if (path.equals( ctPath.substring(0, ctPathL - 2 )))
+ return true;
+ return path.startsWith( ctPath.substring(0, ctPathL - 1 ));
case Container.EXTENSION_MAP:
return ctPath.substring( 1 ).equals( URLUtil.getExtension( path ));
case Container.PATH_MAP:
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
Since characters in Java are UNICODE, what does this code do when it encounters a character who's code point is greater than 0xFF? My suggestion, is to first encode the path as a UTF-8 byte array, then encode the bytes according to this algorithm Yes, the writer should probably use the "UTF-8" encoding. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 3.3 Release Plan
Tomcat 3.3 Release Plan Ballot: [X] +1 I am in favor of this plan and will help [ ] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1 I am against this plan being executed, and my reason is: Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 3.3 Release Plan
on 1/30/01 8:13 AM, "Larry Isaacs" [EMAIL PROTECTED] wrote: - Please return this portion with your vote - Tomcat 3.3 Release Plan Ballot: [ ] +1 I am in favor of this plan and will help [ ] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [X] -1 I am against this plan being executed, and my reason is: No, I'm not trying to be difficult, I just want clarification. You just made a modification that says that you will not fix all of the known open issues before release. Does that also mean that you are going to commit to maintaining and supporting this software into the future and also apply patches that are sent in as well as do more releases? Am I just confused by what you changed? I will most likely change my -1 to a +1 when I get answers. thanks, -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 3.3 Release Plan
Tomcat 3.3 Release Plan Ballot: [ ] +1 I am in favor of this plan and will help [X] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1 I am against this plan being executed, and my reason is: Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: TC3.3 plan explanation, was ( [VOTE] Tomcat 3.3 Release Plan)
-Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 30, 2001 1:14 PM To: [EMAIL PROTECTED] Subject: Re: [VOTE] Tomcat 3.3 Release Plan on 1/30/01 8:13 AM, "Larry Isaacs" [EMAIL PROTECTED] wrote: - Please return this portion with your vote - Tomcat 3.3 Release Plan Ballot: [ ] +1 I am in favor of this plan and will help [ ] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [X] -1 I am against this plan being executed, and my reason is: No, I'm not trying to be difficult, I just want clarification. You just made a modification that says that you will not fix all of the known open issues before release. Does that also mean that you are going to commit to maintaining and supporting this software into the future and also apply patches that are sent in as well as do more releases? Am I just confused by what you changed? I will most likely change my -1 to a +1 when I get answers. Hi Jon, I changed the release plan to not promise that all bugs will be fixed as a requirement for release, since that isn't practical. Some of the open issues were open prior to the Tomcat 3.2 release. IMHO, if they weren't show stoppers for Tomcat 3.2, they shouldn't automatically be upgraded to show stoppers for Tomcat 3.3. Is my assumption that the commitment to do maintenance will apply in the release vote. This is only the vote on the plan, and a +1 here is only committing to help with the plan. Deciding whether Tomcat 3.3 has outstanding bugs that should prevent its release, IMHO, should also occur in the release vote. It would be very appropriate to offer a specific unfixed bug, or bugs, as a reason for a -1. Then those specific bugs could be addressed. It is the release vote that is going to be the key one for Tomcat 3.3, not this vote for the plan. If there are those who are, by their +1's to the plan, willing to try to bring Tomcat 3.3 to a point where a release vote can happen, then I think they should be able to try. I don't think we should have to establish the outcome of the release vote when trying to vote for the plan. Sound acceptable? Cheers, Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util RequestUtil.java
remm01/01/30 11:40:23
Modified:catalina/src/share/org/apache/catalina/util RequestUtil.java
Log:
- Add additional URLDecode methods, which allow to specify the character
encoding to use.
Revision ChangesPath
1.13 +75 -22
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.java
Index: RequestUtil.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- RequestUtil.java 2001/01/30 04:14:49 1.12
+++ RequestUtil.java 2001/01/30 19:40:19 1.13
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.java,v
1.12 2001/01/30 04:14:49 remm Exp $
- * $Revision: 1.12 $
- * $Date: 2001/01/30 04:14:49 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.java,v
1.13 2001/01/30 19:40:19 remm Exp $
+ * $Revision: 1.13 $
+ * $Date: 2001/01/30 19:40:19 $
*
*
*
@@ -78,7 +78,7 @@
*
* @author Craig R. McClanahan
* @author Tim Tye
- * @version $Revision: 1.12 $ $Date: 2001/01/30 04:14:49 $
+ * @version $Revision: 1.13 $ $Date: 2001/01/30 19:40:19 $
*/
public final class RequestUtil {
@@ -256,26 +256,79 @@
*/
public static String URLDecode(String str) {
- if (str != null) {
-int len = str.length();
-byte[] bytes = new byte[len];
-str.getBytes(0, len, bytes, 0);
-int ix = 0;
-int ox = 0;
-
-while (ix len) {
-byte b = bytes[ix++]; // Get byte to test
-if (b == '+') {
-b = (byte)' ';
-} else if (b == '%') {
-b = (byte) ((convertHexDigit(bytes[ix++]) 4)
-+ convertHexDigit(bytes[ix++]));
-}
-bytes[ox++] = b;
+return URLDecode(str, null);
+
+}
+
+
+/**
+ * Decode and return the specified URL-encoded String.
+ *
+ * @param str The url-encoded string
+ * @param enc The encoding to use; if null, the default encoding is used
+ * @exception IllegalArgumentException if a '%' character is not followed
+ * by a valid 2-digit hexadecimal number
+ */
+public static String URLDecode(String str, String enc) {
+
+if (str == null)
+return (null);
+
+int len = str.length();
+byte[] bytes = new byte[len];
+str.getBytes(0, len, bytes, 0);
+
+return URLDecode(bytes, enc);
+
+}
+
+
+/**
+ * Decode and return the specified URL-encoded byte array.
+ *
+ * @param bytes The url-encoded byte array
+ * @exception IllegalArgumentException if a '%' character is not followed
+ * by a valid 2-digit hexadecimal number
+ */
+public static String URLDecode(byte[] bytes) {
+return URLDecode(bytes, null);
+}
+
+
+/**
+ * Decode and return the specified URL-encoded byte array.
+ *
+ * @param bytes The url-encoded byte array
+ * @param enc The encoding to use; if null, the default encoding is used
+ * @exception IllegalArgumentException if a '%' character is not followed
+ * by a valid 2-digit hexadecimal number
+ */
+public static String URLDecode(byte[] bytes, String enc) {
+
+if (bytes == null)
+return (null);
+
+int len = bytes.length;
+int ix = 0;
+int ox = 0;
+while (ix len) {
+byte b = bytes[ix++]; // Get byte to test
+if (b == '+') {
+b = (byte)' ';
+} else if (b == '%') {
+b = (byte) ((convertHexDigit(bytes[ix++]) 4)
++ convertHexDigit(bytes[ix++]));
+}
+bytes[ox++] = b;
+}
+if (enc != null) {
+try {
+return new String(bytes, 0, ox, enc);
+} catch (Exception e) {
+e.printStackTrace();
}
-return new String(bytes, 0, ox);
}
-return null;
+return new String(bytes, 0, ox);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
remm01/01/30 11:41:54
Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
Log:
- Experimental patch : encode and decode the paths using UTF-8.
Revision ChangesPath
1.23 +17 -32
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
Index: DefaultServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- DefaultServlet.java 2001/01/30 03:50:08 1.22
+++ DefaultServlet.java 2001/01/30 19:41:50 1.23
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
1.22 2001/01/30 03:50:08 remm Exp $
- * $Revision: 1.22 $
- * $Date: 2001/01/30 03:50:08 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
1.23 2001/01/30 19:41:50 remm Exp $
+ * $Revision: 1.23 $
+ * $Date: 2001/01/30 19:41:50 $
*
*
*
@@ -113,6 +113,7 @@
import org.apache.catalina.Globals;
import org.apache.catalina.util.MD5Encoder;
import org.apache.catalina.util.StringManager;
+import org.apache.catalina.util.RequestUtil;
/**
@@ -121,7 +122,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.22 $ $Date: 2001/01/30 03:50:08 $
+ * @version $Revision: 1.23 $ $Date: 2001/01/30 19:41:50 $
*/
public class DefaultServlet
@@ -858,37 +859,15 @@
if (path == null)
return null;
- String normalized = path;
-
// Resolve encoded characters in the normalized path,
// which also handles encoded spaces so we can skip that later.
// Placed at the beginning of the chain so that encoded
// bad stuff(tm) can be caught by the later checks
- while (true) {
- int index = normalized.indexOf("%");
- if (index 0)
- break;
- char replaceChar;
- try {
- replaceChar = (char) (
- Short.parseShort(
- normalized.substring( index + 1, index + 3 ), 16
- )
- );
- } catch ( NumberFormatException nfe ) {
- return (null); // bad encoded characters in url
- }
- // check for control characters ( values 00-1f and 7f-9f),
- // return null if present. See:
- // http://www.unicode.org/charts/PDF/U.pdf
- // http://www.unicode.org/charts/PDF/U0080.pdf
- if ( Character.isISOControl( replaceChar ) ) {
- return (null);
- }
- normalized = normalized.substring(0, index) +
- replaceChar +
- normalized.substring(index + 3);
-}
+String normalized = path;
+if (normalized.indexOf('%') = 0)
+normalized = RequestUtil.URLDecode(normalized, "UTF-8");
+if (normalized == null)
+return (null);
// Normalize the slashes and add leading slash if necessary
if (normalized.indexOf('\\') = 0)
@@ -950,7 +929,13 @@
int caseDiff = ('a' - 'A');
StringBuffer rewrittenPath = new StringBuffer(path.length());
ByteArrayOutputStream buf = new ByteArrayOutputStream(maxBytesPerChar);
-OutputStreamWriter writer = new OutputStreamWriter(buf);
+OutputStreamWriter writer = null;
+try {
+writer = new OutputStreamWriter(buf, "UTF-8");
+} catch (Exception e) {
+e.printStackTrace();
+writer = new OutputStreamWriter(buf);
+}
for (int i = 0; i path.length(); i++) {
int c = (int) path.charAt(i);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 3.3 Release Plan
Tomcat 3.3 Release Plan Ballot: [X] +1 I am in favor of this plan and will help [ ] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1 I am against this plan being executed, and my reason is: Thanks -Ramesh.Mandava - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 3.3 Release Plan
Tomcat 3.3 Release Plan Ballot: [ ] +1I am in favor of this plan and will help [X] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1I am against this plan being executed, and my reason is: - -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: TC3.3 plan explanation, was ( [VOTE] Tomcat 3.3 Release Plan)
on 1/30/01 11:10 AM, "Larry Isaacs" [EMAIL PROTECTED] wrote: Hi Jon, I changed the release plan to not promise that all bugs will be fixed as a requirement for release, since that isn't practical. Some of the open issues were open prior to the Tomcat 3.2 release. IMHO, if they weren't show stoppers for Tomcat 3.2, they shouldn't automatically be upgraded to show stoppers for Tomcat 3.3. Is my assumption that the commitment to do maintenance will apply in the release vote. This is only the vote on the plan, and a +1 here is only committing to help with the plan. Deciding whether Tomcat 3.3 has outstanding bugs that should prevent its release, IMHO, should also occur in the release vote. It would be very appropriate to offer a specific unfixed bug, or bugs, as a reason for a -1. Then those specific bugs could be addressed. It is the release vote that is going to be the key one for Tomcat 3.3, not this vote for the plan. If there are those who are, by their +1's to the plan, willing to try to bring Tomcat 3.3 to a point where a release vote can happen, then I think they should be able to try. I don't think we should have to establish the outcome of the release vote when trying to vote for the plan. Sound acceptable? Cheers, Larry Larry, thanks for the excellent response. I think that I hear what you are saying. However, I still feel that it should be a goal of the release plan to attempt to specify which bugs will be closed before a release vote is made. That will solidify the ability to actually vote a -1 on the release if a particular bug is not fixed. In other words, I understand that you may not want to fix bugs that were open before 3.2 was released and were not closed after the release. How about this suggestion: Change the release plan to state: "All bugs that have been opened after the Tomcat 3.2.1 release will be closed before a 3.3 release is made." That would make me feel a lot more comfortable and would also set a nice precedent for not doing any more releases while we have bugs in an Open state. Note that you can still do a release with unresolved bugs...but someone should actually mark them as unresolved before a release. :-) thanks, -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Custom ObjectFactory w\ Tomcat 4.0beta1
I developed an JNDI ObjectFactory that is used to read User Objects from LDAP. When I run a test program and perform a lookup it works fine. But when I use it within Tomcat 4.0 it ignores the java.naming.factory.object and java.naming.factory.state attributes that I am setting when creating the InitialContext. Does anyone have any ideas why these attributes are getting ignored? Any help would be appreciated. Arthur This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co. Incorporated, its subsidiaries and affiliates. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugZilla is UP...
Thanks to Ignacio Ortega and Nick Baumann who did all the work, we finally have migrated all bugs for Tomcat 3.x to BugZilla. BugZilla is back up again at http://nagoya.apache.org/bugzilla/ and it works GREAT... Thank you again Ignacio for the great work, and sorry for the interruption of service yesterday :) :) :) Pier -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: TC3.3 plan explanation, was ( [VOTE] Tomcat 3.3 Release Plan)
-Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 30, 2001 3:33 PM To: [EMAIL PROTECTED] Subject: Re: TC3.3 plan explanation, was ( [VOTE] Tomcat 3.3 Release Plan) How about this suggestion: Change the release plan to state: "All bugs that have been opened after the Tomcat 3.2.1 release will be closed before a 3.3 release is made." I have no problem with what I perceive to be the intent of this statement. Given that we are, as of minutes ago, operating under BugZilla, would it be appropriate to substitute "resolved" for "closed". Since "resolved" includes "later" or "wontfix" as resolutions, we could use those if it isn't practical to fix before the release. A query on those resolutions would reveal what isn't being fixed, so a judgement could be made. Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: BugZilla is UP...
- Original Message - From: "Pier P. Fumagalli" [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, January 30, 2001 1:18 PM Subject: BugZilla is UP... Thanks to Ignacio Ortega and Nick Baumann who did all the work, we finally have migrated all bugs for Tomcat 3.x to BugZilla. BugZilla is back up again at http://nagoya.apache.org/bugzilla/ and it works GREAT... Thank you again Ignacio for the great work, and sorry for the interruption of service yesterday :) :) :) Thanks a lot to all who helped set it up. It works great indeed. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Custom ObjectFactory w\ Tomcat 4.0beta1
I developed an JNDI ObjectFactory that is used to read User Objects from LDAP. When I run a test program and perform a lookup it works fine. But when I use it within Tomcat 4.0 it ignores the java.naming.factory.object and java.naming.factory.state attributes that I am setting when creating the InitialContext. Does anyone have any ideas why these attributes are getting ignored? Any help would be appreciated. First of all, the object factories are not pluggable in b1 without modifying some code in the naming.factory package (although the modifications are quite simple). That has been added since then, and b2 will have pluggable factories. However, it will not use the standard mechanism for a variety of reasons (static mechanism - that's bad if like here you're supposed to have isolated independant contexts -, not flexible enough, classloading issues, ...). Instead, the reference is always processed through a set of proxy object factories. In b2, you can use the "factory" parameter to specify a custom store. This is done in server.xml like this : ResourceParams name="jdbc/MyDataSource" parameternamefactory/namevalueclassname.of.the.object.factory/value /parameter !-- Then add whatever other parameters your factory will need -- parameternameuser/namevaluesa/value/parameter parameternamepassword/namevalue/value/parameter parameternamedriverClassName/name valueorg.hsql.jdbcDriver/value/parameter parameternamedriverName/name valuejdbc:HypersonicSQL:database/value/parameter /ResourceParams Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Custom ObjectFactory w\ Tomcat 4.0beta1
Thanks for you quick response. It has though brought about more questions. For
example, if I had the following code
Hashtable env=new Hashtable();
env.put("java.naming.factory.initial","com.sun.jndi.ldap.LdapCtxFactory");
env.put("java.naming.factory.object","crmg.tailgun.jndi.UserFactory:crmg.sysadmin.jndi.AppFactory");
env.put("java.naming.factory.state","crmg.tailgun.jndi.UserFactory:crmg.sysadmin.jndi.AppFactory");
etc...
DirContext root=new InitialDirContext(env);
According to the JNDI spec the object and state factories from this environment
should be added to the application resource properties and the system properties
for this context. It should have no effect on any other contexts from any other
applications.
By not following this convention, it forces me to do things in a Tomcat specific
way.What are the issues that prevent Tomcat from following this convention?
Also, I took a look at org.apache.naming packages but I am unsure which classes
are affecting this?
Arthur
[EMAIL PROTECTED] on 01/30/2001 04:36:33 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: (bcc: Arthur T Smyles)
Subject: Re: Custom ObjectFactory w\ Tomcat 4.0beta1
I developed an JNDI ObjectFactory that is used to read User Objects from
LDAP.
When I run a test program and perform a lookup it works fine. But when I
use it
within Tomcat 4.0 it ignores the java.naming.factory.object and
java.naming.factory.state attributes that I am setting when creating the
InitialContext. Does anyone have any ideas why these attributes are
getting
ignored? Any help would be appreciated.
First of all, the object factories are not pluggable in b1 without modifying
some code in the naming.factory package (although the modifications are
quite simple). That has been added since then, and b2 will have pluggable
factories. However, it will not use the standard mechanism for a variety of
reasons (static mechanism - that's bad if like here you're supposed to have
isolated independant contexts -, not flexible enough, classloading issues,
...).
Instead, the reference is always processed through a set of proxy object
factories. In b2, you can use the "factory" parameter to specify a custom
store. This is done in server.xml like this :
ResourceParams name="jdbc/MyDataSource"
parameternamefactory/namevalueclassname.of.the.object.factory/value
/parameter
!-- Then add whatever other parameters your factory will
need --
parameternameuser/namevaluesa/value/parameter
parameternamepassword/namevalue/value/parameter
parameternamedriverClassName/name
valueorg.hsql.jdbcDriver/value/parameter
parameternamedriverName/name
valuejdbc:HypersonicSQL:database/value/parameter
/ResourceParams
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase Co. Incorporated, its
subsidiaries and affiliates.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Custom ObjectFactory w\ Tomcat 4.0beta1
Quoting Arthur T Smyles [EMAIL PROTECTED]:
Thanks for you quick response. It has though brought about more
questions. For
example, if I had the following code
Hashtable env=new Hashtable();
env.put("java.naming.factory.initial","com.sun.jndi.ldap.LdapCtxFactory");
env.put
("java.naming.factory.object","crmg.tailgun.jndi.UserFactory:crmg.sysadmin.jndi.
AppFactory");
env.put
("java.naming.factory.state","crmg.tailgun.jndi.UserFactory:crmg.sysadmin.jndi.A
ppFactory");
etc...
DirContext root=new InitialDirContext(env);
According to the JNDI spec the object and state factories from this
environment
should be added to the application resource properties and the system
properties
for this context. It should have no effect on any other contexts from
any other
applications.
By not following this convention, it forces me to do things in a Tomcat
specific
way.What are the issues that prevent Tomcat from following this
convention?
Also, I took a look at org.apache.naming packages but I am unsure which
classes
are affecting this?
Using this doesn't work right now, but perhaps it could be fixed.
I fail to see how it could be useful anyway, since whatever happens :
- the reference format is server specific (the attributes name in the reference
is not something which is portable from one server to another)
- the reference definition format (for exemple how to specify the JDBC driver,
etc) is server specific
So having the object factory definition server specific too doesn't look like
it's a big problem to me.
All the other open source JNDI implementation I've checked (Tyrex, jBoss,
OpenJMS) :
- specify the object factory when they bind the reference
- don't allow plugging external object factories
- have custom reference attribute names
So the Catalina naming package is more flexible overall (although like the
others, it's proprietary).
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 3.3 Release Plan
Larry, [X] +1I am in favor of this plan and will help [ ] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1I am against this plan being executed, and my reason is: Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Bug 448] New - Support for PROPPATCH in WebDAV Servlet BugRat Report#769
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=448 *** shadow/448 Tue Jan 30 17:09:57 2001 --- shadow/448.tmp.6489 Tue Jan 30 17:09:57 2001 *** *** 0 --- 1,19 + ++ + | Support for PROPPATCH in WebDAV Servlet BugRat Report#769 | + ++ + |Bug #: 448 Product: Tomcat 4| + | Status: RESOLVEDVersion: 4.0 Beta 1 | + | Resolution: WONTFIXPlatform: All | + | Severity: Normal OS/Version: All | + | Priority: High Component: Catalina| + ++ + | Assigned To: BugRatImport | + | Reported By: [EMAIL PROTECTED]| + | CC list: Cc: | + ++ + | URL: | + ++ + | DESCRIPTION | + The WebDAV servlet of the Catalina engine does not support the PROPPATCH operation. + So it is not possible to set "dead properties". + Future versions of the WebDAV Servlet should support operations on arbitrary +properties as suggested in the WebDAV specs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: TOMCAT + mod_jk or mod_webapp
Dan Milstein [EMAIL PROTECTED] wrote: Pier, Glad to hear that you're willing/interested in integrating the mod_webapp protocol into mod_jk. I don't know exactly how easy it would be, but I think it *would* be a big win (you'd get lots of tested C code, load balancing for free, easy upgrade path for users, etc). Heyhehyhey... Slow down... I said that I won't even THINK ABOUT IT until mid-march as I have to move to the other side of the planet, and want to have a quality release of mod_webapp before that :) :) :) But we can start talking about it after that :) I've recently discovered that I'll have a chunk of free time in March. I'll try to use some of that to document/explain what is going on in the mod_jk C code (which I am pretty close to understanding, currently). Maybe we can work together then to try to support the mod_webapp protocol with mod_jk. BTW, I do think the mod_jk C code, for all it's initially forbidding lack of comments, is actually very intelligently thought out. Well, I never understood how that thing works... You know, we old C farts are kinda stubborn. After my "kid" mod_jserv I stopped thinking in C, and so far it still didn't come back... Let's keep our eye on this going ahead. Let's talk about it after I move to London :) :) :) Pier -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: BugZilla is UP...
Remy Maucherat [EMAIL PROTECTED] wrote: - Original Message - From: "Pier P. Fumagalli" [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, January 30, 2001 1:18 PM Subject: BugZilla is UP... Thanks to Ignacio Ortega and Nick Baumann who did all the work, we finally have migrated all bugs for Tomcat 3.x to BugZilla. BugZilla is back up again at http://nagoya.apache.org/bugzilla/ and it works GREAT... Thank you again Ignacio for the great work, and sorry for the interruption of service yesterday :) :) :) Thanks a lot to all who helped set it up. It works great indeed. That was mainly Nacho... Kudos to his SQL expertise... :) Pier -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 3.3 Release Plan
Larry Isaacs [EMAIL PROTECTED] wrote: [ ] +1I am in favor of this plan and will help [ ] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1I am against this plan being executed, and my reason is: I'm completely neutral, you kids do whatever you want... Mostly because I'm so tired to talk about it... :( My vote is 0 Pier -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Bug 448] New - Support for PROPPATCH in WebDAV ServletBugRat Report#769
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=448 *** shadow/448Tue Jan 30 17:09:57 2001 --- shadow/448.tmp.6489Tue Jan 30 17:09:57 2001 Warp-OLA it WORKS :) :) :) Fuck yeah (sorry!)... Nacho, you're a GENIUS! Pier -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/generators ErrorHandler.java
larryi 01/01/30 17:56:46
Modified:src/share/org/apache/tomcat/modules/generators
ErrorHandler.java
Log:
Fix some nits.
Revision ChangesPath
1.5 +3 -0
jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/ErrorHandler.java
Index: ErrorHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/ErrorHandler.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ErrorHandler.java 2001/01/29 07:08:50 1.4
+++ ErrorHandler.java 2001/01/31 01:56:46 1.5
@@ -407,6 +407,7 @@
.append(sm.getString("defaulterrorpage.notfound404"))
.append("/h1\r\n");
buf.append(sm.getString("defaulterrorpage.originalrequest"))
+ .append(" ")
.append( requestURI )
.append("\r\n");
@@ -503,6 +504,7 @@
// More info - where it happended"
buf.append("h2")
.append(sm.getString("defaulterrorpage.location"))
+ .append(" ")
.append(req.requestURI().toString())
.append("/h2");
@@ -605,6 +607,7 @@
// More info - where it happended"
buf.append("h2")
.append(sm.getString("defaulterrorpage.location"))
+ .append(" ")
.append(req.requestURI().toString())
.append("/h2");
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/tests/webpages/WEB-INF test-tomcat.xml
larryi 01/01/30 18:05:55
Modified:src/tests/share/tests/jsp/Golden PrintWriterTest.txt
src/tests/webpages/WEB-INF test-tomcat.xml
Log:
Update PrintWriterTest test to use a responseMatchFile to verify that the
expected exception occurred.
Revision ChangesPath
1.2 +5 -2
jakarta-tomcat/src/tests/share/tests/jsp/Golden/PrintWriterTest.txt
Index: PrintWriterTest.txt
===
RCS file:
/home/cvs/jakarta-tomcat/src/tests/share/tests/jsp/Golden/PrintWriterTest.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- PrintWriterTest.txt 2000/01/18 00:02:29 1.1
+++ PrintWriterTest.txt 2001/01/31 02:05:54 1.2
@@ -1,2 +1,5 @@
-
-
+Included servlet error: 500
+java.lang.IllegalStateException: getOutputStream() has already been called
+!=
+PreInclude
+PostInclude
1.13 +2 -1 jakarta-tomcat/src/tests/webpages/WEB-INF/test-tomcat.xml
Index: test-tomcat.xml
===
RCS file: /home/cvs/jakarta-tomcat/src/tests/webpages/WEB-INF/test-tomcat.xml,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- test-tomcat.xml 2001/01/29 06:59:39 1.12
+++ test-tomcat.xml 2001/01/31 02:05:54 1.13
@@ -16,7 +16,7 @@
early tests.
--
- property name="revision" value="$Revision: 1.12 $" /
+ property name="revision" value="$Revision: 1.13 $" /
property name="host" value="127.0.0.1" /
property name="port" value="8080" /
property name="outputType" value="text" /
@@ -133,6 +133,7 @@
gtest description="PrintWriterTest"
request="GET /test/servlet/dispatch.PrintWriterTest1Servlet HTTP/1.0"
returnCode="${http.protocol} 500"
+ responseMatchFile="${gdir}/PrintWriterTest.txt"
/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 3.3 Release Plan
Tomcat 3.3 Release Plan Ballot: [X] +1I am in favor of this plan and will help [ ] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1I am against this plan being executed, and my reason is: -Dan -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PATCH: tagdependent tags should not parse content
I found the following message in the archives for tomcat-dev from Dec
1999. It appears to never have been introduced to the distribution or
to CVS or anything. Wondering what the status of a fix might be.
*
To: [EMAIL PROTECTED]
Subject: PATCH: tagdependent tags should not parse content
From: "Danno Ferrin" [EMAIL PROTECTED]
Date: Wed, 08 Dec 1999 18:19:24 -0700
The bodycontent=tagdependent should provide a literal copy of the tag
content. =JSP will handle JSP elements first, but tagdependent
shoudlnt.
Index: src/share/org/apache/jasper/compiler/Parser.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/jasper/compiler/Parser.java,v
retrieving revision 1.6
diff -C3 -r1.6 Parser.java
*** Parser.java 1999/11/08 03:14:27 1.6
--- Parser.java 1999/12/09 01:17:40
***
*** 752,758
String tagEnd = "/"+tag+"";
// Parse until the end of the tag body.
// Then skip the tag end...
! parser.parse(tagEnd);
reader.advance(tagEnd.length());
listener.handleTagEnd(bodyStart,
reader.mark(), prefix,
shortTagName, attrs,
tli, ti);
--- 752,764
String tagEnd = "/"+tag+"";
// Parse until the end of the tag body.
// Then skip the tag end...
! if
(bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_TAG_DEPENDENT))
! // accept no core elements for tag
dependent,
! // i.e. literal inclusion of the
content
! parser.parse(tagEnd, new Class[] {});
! else
! // it is JSP body content, so accept
all core elements
! parser.parse(tagEnd);
reader.advance(tagEnd.length());
listener.handleTagEnd(bodyStart,
reader.mark(), prefix,
shortTagName, attrs,
tli, ti);
--
Jeffrey Nikole Bonevich
Maxmillian Bonevich
Ann Arbor, Michigan
[EMAIL PROTECTED]
http://www.bonevich.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: PATCH: tagdependent tags should not parse content
BTW I forgot to mention that I tried applying this patch myself to the
Parser.java source code, without success - the patch as is does not
appear to resolve the issue.
Jeffrey Bonevich wrote:
I found the following message in the archives for tomcat-dev from Dec
1999. It appears to never have been introduced to the distribution or
to CVS or anything. Wondering what the status of a fix might be.
*
To: [EMAIL PROTECTED]
Subject: PATCH: tagdependent tags should not parse content
From: "Danno Ferrin" [EMAIL PROTECTED]
Date: Wed, 08 Dec 1999 18:19:24 -0700
The bodycontent=tagdependent should provide a literal copy of the tag
content. =JSP will handle JSP elements first, but tagdependent
shoudlnt.
Index: src/share/org/apache/jasper/compiler/Parser.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/jasper/compiler/Parser.java,v
retrieving revision 1.6
diff -C3 -r1.6 Parser.java
*** Parser.java 1999/11/08 03:14:27 1.6
--- Parser.java 1999/12/09 01:17:40
***
*** 752,758
String tagEnd = "/"+tag+"";
// Parse until the end of the tag body.
// Then skip the tag end...
! parser.parse(tagEnd);
reader.advance(tagEnd.length());
listener.handleTagEnd(bodyStart,
reader.mark(), prefix,
shortTagName, attrs,
tli, ti);
--- 752,764
String tagEnd = "/"+tag+"";
// Parse until the end of the tag body.
// Then skip the tag end...
! if
(bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_TAG_DEPENDENT))
! // accept no core elements for tag
dependent,
! // i.e. literal inclusion of the
content
! parser.parse(tagEnd, new Class[] {});
! else
! // it is JSP body content, so accept
all core elements
! parser.parse(tagEnd);
reader.advance(tagEnd.length());
listener.handleTagEnd(bodyStart,
reader.mark(), prefix,
shortTagName, attrs,
tli, ti);
--
Jeffrey Nikole Bonevich
Maxmillian Bonevich
Ann Arbor, Michigan
[EMAIL PROTECTED]
http://www.bonevich.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
--
Jeffrey Nikole Bonevich
Maxmillian Bonevich
Ann Arbor, Michigan
[EMAIL PROTECTED]
http://www.bonevich.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
config problem
I have successfully made a mod_jk.so and it works fine in my apache, I have a application called abc in my webapps dir. of tomcat. I can browse the application by http://www.mydomain.com/abc but I want to browse the abc application directly at http://www.mydomain.com . I tried to change the DocumentRoot of apache to /opt/tomat/webapps/abc but it fail. I have added the below code to httpd.conf Directory "/opt/tomcat/webapps/nsl" Options Indexes FollowSymLinks /Directory Location "/WEB-INF/" AllowOverride None deny from all /Location Location "/META-INF/" AllowOverride None deny from all /Location - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 3.3 Release Plan
Larry Isaacs wrote: [...] Tomcat 3.3 Release Plan Ballot: [ ] +1I am in favor of this plan and will help [X] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1I am against this plan being executed, and my reason is: Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
