RE: [ANNOUNCEMENT] Tomcat 3.3.1 Final Released
Second release of RPM uploaded to match update in source tarball. http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.3.1/rpms/ tomcat3-3.3.1-2.src.rpm tomcat3-3.3.1-2.noarch.rpm tomcat3-javadoc-3.3.1-2.noarch.rpm tomcat3-webapps-3.3.1-2.noarch.rpm also added latest IBM SDK 1.3.1 detection in /usr/bin/dtomcat3 script. IBM SDK 1.3.1 for ia32 live in /opt/IBMJava2-131/ Regards - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7564] New: - Avoid hardcoding the default deployment descriptor location
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7564. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7564 Avoid hardcoding the default deployment descriptor location Summary: Avoid hardcoding the default deployment descriptor location Product: Tomcat 4 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] o.a.c.startup.ContextConfig reads the default deployment descriptor from the location contained in the static final variable o.a.c.startup.Constants.defaultWebXml (prefixing this with the value of CATALINA_HOME). This value is currently hardcoded to conf/web.xml Products that embed the Catalina engine (using Embedded's API) may have a different directory structure and it would be nice to be able to programmatically specify the location of the default deployment descriptor rather than having to change the value of the Constants.defaultWebXml variable. e.g. StandardContext context = new StandardContext(); ... ... ContextConfig config = new ContextConfig(); config.setDefaultWebXml(/mywebserver/config/default-web.xml); ((Lifecycle) context).addLifecycleListener(config); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] - Make default deployment descriptor file location configurable
This is a patch for RFE# 7564. It allows one to specify/override the
location of the default deployment descriptor. Currently, this is hardcoded
to 'conf/web.xml' in o.a.c.startup.Constants.java
Products that embed the Catalina engine (using Embedded's API) may have a
different directory structure and this patch allows one to programmatically
specify the location of the default deployment descriptor rather than having
to change the value of o.a.c.startup.Constants.defaultWebXml.
e.g.
StandardContext context = new StandardContext();
...
...
ContextConfig config = new ContextConfig();
config.setDefaultWebXml(/webserver1/config/default-web.xml);
((Lifecycle) context).addLifecycleListener(config);
Cheers,
Arvind
Index: ContextConfig.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.60
diff -u -r1.60 ContextConfig.java
--- ContextConfig.java 14 Mar 2002 23:58:35 - 1.60
+++ ContextConfig.java 28 Mar 2002 09:28:12 -
@@ -168,6 +168,12 @@
/**
+ * The default deployment descriptor location.
+ */
+private String defaultWebXml = Constants.DefaultWebXml;
+
+
+/**
* The string resources for this package.
*/
private static final StringManager sm =
@@ -213,6 +219,28 @@
}
+/**
+ * Return the location of the default deployment descriptor
+ */
+public String getDefaultWebXml() {
+
+return (this.defaultWebXml);
+
+}
+
+
+/**
+ * Set the location of the default deployment descriptor
+ *
+ * @param path Absolute/relative path to the 'default' web.xml
+ */
+public void setDefaultWebXml(String path) {
+
+this.defaultWebXml = path;
+
+}
+
+
// - Public Methods
@@ -480,10 +508,10 @@
private void defaultConfig() {
// Open the default web.xml file, if it exists
-File file = new File(Constants.DefaultWebXml);
+File file = new File(this.defaultWebXml);
if (!file.isAbsolute())
file = new File(System.getProperty(catalina.base),
-Constants.DefaultWebXml);
+this.defaultWebXml);
FileInputStream stream = null;
try {
stream = new FileInputStream(file.getCanonicalPath());
Index: ContextConfig.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.60
diff -u -r1.60 ContextConfig.java
--- ContextConfig.java 14 Mar 2002 23:58:35 - 1.60
+++ ContextConfig.java 28 Mar 2002 09:28:12 -
@@ -168,6 +168,12 @@
/**
+ * The default deployment descriptor location.
+ */
+private String defaultWebXml = Constants.DefaultWebXml;
+
+
+/**
* The string resources for this package.
*/
private static final StringManager sm =
@@ -213,6 +219,28 @@
}
+/**
+ * Return the location of the default deployment descriptor
+ */
+public String getDefaultWebXml() {
+
+return (this.defaultWebXml);
+
+}
+
+
+/**
+ * Set the location of the default deployment descriptor
+ *
+ * @param path Absolute/relative path to the 'default' web.xml
+ */
+public void setDefaultWebXml(String path) {
+
+this.defaultWebXml = path;
+
+}
+
+
// - Public Methods
@@ -480,10 +508,10 @@
private void defaultConfig() {
// Open the default web.xml file, if it exists
-File file = new File(Constants.DefaultWebXml);
+File file = new File(this.defaultWebXml);
if (!file.isAbsolute())
file = new File(System.getProperty(catalina.base),
-Constants.DefaultWebXml);
+this.defaultWebXml);
FileInputStream stream = null;
try {
stream = new FileInputStream(file.getCanonicalPath());
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7567] New: - Tar file failed to untar.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7567. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7567 Tar file failed to untar. Summary: Tar file failed to untar. Product: Tomcat 4 Version: Nightly Build Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Installable Packages AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The tar file did not untar. It gave directory checksum errors and stopped. Both for NIGHTLY build as well as 4.0.3 release build. I used the regular version, not the LE version -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: tag pooling question
As a quick note, I did some Jasper profiling on a previous project (it was Jasper from 3.1, running inside weblogic 5.1). The single biggest runtime cost, was all the calls to Introspector.getBeanInfo(). I created a cache of these using a similar technique to FastHashMap in commons collections (in Fast mode), and lowered the runtime costs significantly (for the calls i looked at say, 60%! (I think)). It was a trivial fix for the large benefit. Introspector does all the work every time, and instantiates a new BeanInfo for each call. Also, the cache only needs to expand to contain all the tag classes - a fairly small, finite set. I didn't submit it before, as it was at the time of Jasper4 / tag pooling being touted and thought the heavy runtime reflection stuff would be obsolete soon... -Original Message- From: costinm Sent: 27 March 2002 22:54 To: tomcat-dev; Kin-Man.Chung Cc: costinm Subject: Re: tag pooling question On Wed, 27 Mar 2002, Kin-Man Chung wrote: Pulling codes out of iteration tag bodies is very high on my list of optimizations that I wnat to do. I don't think we can do much about general scriplets that contain loops, though. But before we start on jasper optimization work, we'll need benchmarks and performance analysers. I have learnt from experience that performance improvement often comes from surprising places, and that optimizations done at the wrong time and place often do more harm than good. Benchmarks would give us some real metric for us to measure our optimization work, and analyzing tools would let us identify hot spots that need to be improved. I'd appreciate comments, suggestions, and pointers on these two subjects. I'd also appreciate if anyone can donate some real life applications that I can use for benchmarking jasper performance. The most usefull tools are OptimizeIt and ab. Simple pages would help much better then complex pages - first find out what's the overhead of executin a simple JSP page, with no tags, compare it with the equivalent servlet ( HelloWorld ), and find out what's wrong. Then use a simple hello world Tag, compare it with the equivalent servlet ( or JSP not using tags ), and find what's wrong. Same for a simple iteration tag, compared with a scriptlet If you solve those simple problems, and get the tag version in a reasonable limit, I think we'll all be very happy ( 30% slower would be acceptable for me, even 1/2 the speed of the equivalent scriptlet ). Going after 'real life applications' when the simple hello world tag, or a simple empty jsp page has a clear performance penalty would be a waste of time. ( all that with a reasonable load - I sugest 80 concurent requests ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7506] - Reading InputStream returned in the following senario quick fails under TC4.0.3 but work under TC3.3a
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7506. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7506 Reading InputStream returned in the following senario quick fails under TC4.0.3 but work under TC3.3a --- Additional Comments From [EMAIL PROTECTED] 2002-03-28 11:21 --- The JVM I am using is: Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. C:\java -version java version 1.4.0 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92) Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode) It is the latest JVM as far as I know. is there something else I can try? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Mod_jk v/s mod_webapp
David Graff [EMAIL PROTECTED] wrote: mod_webapp (from what I can tell) was supposed to be a completely new implemenation of this functionality with improvements here and there as far as application deployment etc. FWIW, mod_webapp works perfectly for what concerns my needs, and all the documentation required to install it is in the distribution, on http://nagoya.apache.org/~pier/ Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Mod_jk v/s mod_webapp
Pier, Thanks for the pointer on that documentation. I was wondering where the Javadoc style comments were being used at. I still don't think the question was really answered though as to the motivation of mod_webapp versus mod_jk/mod_jk2 development? Are there any goals that have been made available to the public so that we understand what the spawned these two different integration modules? Thanks. -dave - Original Message - From: Pier Fumagalli [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, March 28, 2002 06:37 Subject: Re: Mod_jk v/s mod_webapp David Graff [EMAIL PROTECTED] wrote: mod_webapp (from what I can tell) was supposed to be a completely new implemenation of this functionality with improvements here and there as far as application deployment etc. FWIW, mod_webapp works perfectly for what concerns my needs, and all the documentation required to install it is in the distribution, on http://nagoya.apache.org/~pier/ Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Mod_jk v/s mod_webapp
David Graff [EMAIL PROTECTED] wrote: Thanks for the pointer on that documentation. I was wondering where the Javadoc style comments were being used at. You welcome... I still don't think the question was really answered though as to the motivation of mod_webapp versus mod_jk/mod_jk2 development? Are there any goals that have been made available to the public so that we understand what the spawned these two different integration modules? Motivation? I don't like mod_jk, I wanted to use APR as a portable runtime for an Apache 1.3 module, I believe that the WARP protocol with built-in support for auto-deployment and web-application configuration is the way to go (rather than using mod_rewrite rules all the way around), and because I don't like Costin :) :) :) :) 1.2.3. (BTW, all those goals passed over on this mailing list in the past 2/3 years, check the archives...) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7571] - DataInputStream readLong() Problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7571. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7571 DataInputStream readLong() Problem [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |tomcat- ||[EMAIL PROTECTED] Component|Content-type|Connector:JK/AJP Product|Apache httpd-1.3|Tomcat 4 Summary|DataInputStream readLong() |DataInputStream readLong() |Problem |Problem Version|1.3.24 |4.0.3 Final --- Additional Comments From [EMAIL PROTECTED] 2002-03-28 13:02 --- This is clearly a Tomcat problem and not an HTTP Server problem. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Mod_jk v/s mod_webapp
Maybe I've not kept up on the docs enough but ... I do think this thread, highlights a general confusion around tomcat. Over the last couple of years, there have been many mod_jk/jk2/webapp/warp/?? implementations, ajp versions etc, and even when the discussions are on the list, it's still hard to be able to say (for lowly thread lurkers/tomcat users like myself), tomcat X.x can use mod_??, on ajp?.? because they provide xyz.. It would be nice to have a page in the docs, on the general tomcat site, that gives a summary of what each native connector does in terms of features, config, performance, load balancing, web servers supported, whether still in development etc. -Original Message- From: pier Sent: 28 March 2002 12:52 To: tomcat-dev Cc: pier Subject: Re: Mod_jk v/s mod_webapp David Graff [EMAIL PROTECTED] wrote: Thanks for the pointer on that documentation. I was wondering where the Javadoc style comments were being used at. You welcome... I still don't think the question was really answered though as to the motivation of mod_webapp versus mod_jk/mod_jk2 development? Are there any goals that have been made available to the public so that we understand what the spawned these two different integration modules? Motivation? I don't like mod_jk, I wanted to use APR as a portable runtime for an Apache 1.3 module, I believe that the WARP protocol with built-in support for auto-deployment and web-application configuration is the way to go (rather than using mod_rewrite rules all the way around), and because I don't like Costin :) :) :) :) 1.2.3. (BTW, all those goals passed over on this mailing list in the past 2/3 years, check the archives...) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7359] - Classloader problems with RMI
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7359. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7359 Classloader problems with RMI --- Additional Comments From [EMAIL PROTECTED] 2002-03-28 13:48 --- I'm seeing the same problem on W2K with 4.0.3 final. The following happens in an internal Jini thread when trying to establish a link to a newly discovered registrar: java.lang.ClassNotFoundException: com.sun.jini.reggie.RegistrarProxy at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:297) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:195) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:354) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:132) at sun.rmi.server.MarshalInputStream.resolveClass (MarshalInputStream.java:143) at java.io.ObjectInputStream.inputClassDescriptor (ObjectInputStream.java:918) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at java.rmi.MarshalledObject.get(MarshalledObject.java:138) at net.jini.discovery.IncomingUnicastResponse.init (IncomingUnicastResponse.java:78) at net.jini.discovery.LookupDiscovery$UnicastDiscoverer.run (LookupDiscovery.java:322) The RegistrarProxy object is served by a RMI server with a valid HTTP codebase pointing to Sun's out-of-the-box reggie-dl.jar. This setup works fine with my other standalone apps. The same code for my servlet used to work just fine in v4.0... Just for the heck of it, I tried granting AllPermission to everybody with no results. I too would suspect a problem with the class loaders... So far, my only good workaround is to revert to 4.0. I tried also deploying the downloaded jars locally, but this kind of defeats the purpose... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7575] New: - Throwing UnavailableException in JSP's init disables JSP servlet
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7575. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7575 Throwing UnavailableException in JSP's init disables JSP servlet Summary: Throwing UnavailableException in JSP's init disables JSP servlet Product: Tomcat 4 Version: 4.0.3 Final Platform: Alpha OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have several JSP pages that define their own init() method in order to setup JDBC resources. If the resource is unavailable, the method throws UnavailableException. Servlet specification states that throwing that exception will mark that servlet as unavailable. In my case it markes the JSP-handler servlet as unavailable, so all JSP pages become unavailable. In my oppinion, this should have disabled just the temporary servlet created to handle requests to that JSP page. Nixie. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7578] New: - Signed jars loses their certificates when in /WEB-INF/lib
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7578. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7578 Signed jars loses their certificates when in /WEB-INF/lib Summary: Signed jars loses their certificates when in /WEB- INF/lib Product: Tomcat 4 Version: 4.0.3 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Minor Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This stops me from doing funky things with policies and perfoming some integrity checks... Steps to reproduce: 1. Sign a jar 2. Put it in /WEB-INF/lib of some webapp 3. Grant permission java.lang.RuntimePermission getProtectionDomain to everyone in 'catalina.policy'. 4. Execute the following in a servlet, JSP, etc: java.security.cert.Certificate[] jarSigners = ClassInJar.class.getProtectionDomain().getCodeSource().getCertificates (); if ( jarSigners == null ) System.out.println( Houston, we've got a problem... ); else System.out.println( All's well... ); An interesting workaround is that if you move the jar to /common/lib, you get an all's well message. I can work with this for the moment, but I'd prefer my webapps to be self-contained... (This also happens in TC4.0) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler CharDataGenerator.java
larryi 02/03/28 06:57:13
Modified:jasper/src/share/org/apache/jasper/compiler Tag:
tomcat_40_branch CharDataGenerator.java
Log:
Port fix from Tomcat 3.3 for preserving '\r' line terminators.
Revision ChangesPath
No revision
No revision
1.3.2.1 +6 -5
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/CharDataGenerator.java
Index: CharDataGenerator.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/CharDataGenerator.java,v
retrieving revision 1.3
retrieving revision 1.3.2.1
diff -u -r1.3 -r1.3.2.1
--- CharDataGenerator.java13 Jul 2001 19:17:07 - 1.3
+++ CharDataGenerator.java28 Mar 2002 14:57:12 - 1.3.2.1
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/CharDataGenerator.java,v
1.3 2001/07/13 19:17:07 remm Exp $
- * $Revision: 1.3 $
- * $Date: 2001/07/13 19:17:07 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/CharDataGenerator.java,v
1.3.2.1 2002/03/28 14:57:12 larryi Exp $
+ * $Revision: 1.3.2.1 $
+ * $Date: 2002/03/28 14:57:12 $
*
*
*
@@ -108,7 +108,8 @@
sb.append();
break;
case '\r':
- continue;
+ sb.append(\\r);
+ break;
/*
case '\'':
sb.append('\\');
@@ -116,7 +117,7 @@
break;
*/
case '\n':
- sb.append(\\r\\n);
+ sb.append(\\n);
break;
case '\t':
sb.append(\\t);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler CharDataGenerator.java
larryi 02/03/28 06:57:52
Modified:jasper/src/share/org/apache/jasper/compiler
CharDataGenerator.java
Log:
Port fix from Tomcat 3.3 for preserving '\r' line terminators.
Revision ChangesPath
1.4 +6 -5
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/CharDataGenerator.java
Index: CharDataGenerator.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/CharDataGenerator.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- CharDataGenerator.java13 Jul 2001 19:17:07 - 1.3
+++ CharDataGenerator.java28 Mar 2002 14:57:52 - 1.4
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/CharDataGenerator.java,v
1.3 2001/07/13 19:17:07 remm Exp $
- * $Revision: 1.3 $
- * $Date: 2001/07/13 19:17:07 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/CharDataGenerator.java,v
1.4 2002/03/28 14:57:52 larryi Exp $
+ * $Revision: 1.4 $
+ * $Date: 2002/03/28 14:57:52 $
*
*
*
@@ -108,7 +108,8 @@
sb.append();
break;
case '\r':
- continue;
+ sb.append(\\r);
+ break;
/*
case '\'':
sb.append('\\');
@@ -116,7 +117,7 @@
break;
*/
case '\n':
- sb.append(\\r\\n);
+ sb.append(\\n);
break;
case '\t':
sb.append(\\t);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.0.4.txt
larryi 02/03/28 06:58:18 Modified:.Tag: tomcat_40_branch RELEASE-NOTES-4.0.4.txt Log: Document update to Jasper. Revision ChangesPath No revision No revision 1.1.2.2 +5 -1 jakarta-tomcat-4.0/Attic/RELEASE-NOTES-4.0.4.txt Index: RELEASE-NOTES-4.0.4.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/Attic/RELEASE-NOTES-4.0.4.txt,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- RELEASE-NOTES-4.0.4.txt 28 Mar 2002 02:57:29 - 1.1.2.1 +++ RELEASE-NOTES-4.0.4.txt 28 Mar 2002 14:58:18 - 1.1.2.2 @@ -3,7 +3,7 @@ Release Notes = -$Id: RELEASE-NOTES-4.0.4.txt,v 1.1.2.1 2002/03/28 02:57:29 remm Exp $ +$Id: RELEASE-NOTES-4.0.4.txt,v 1.1.2.2 2002/03/28 14:58:18 larryi Exp $ @@ -135,6 +135,10 @@ [B1] Script: Fix problem with the Windows script for JSPC, which could cause JARs to not be included in the classpath. + +[B3] CharDataGenerator: + Fixed a bug where '\r' line terminators were not being preserved as + required by the spec. - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1-dev.txt
larryi 02/03/28 06:58:33 Modified:.RELEASE-NOTES-4.1-dev.txt Log: Document update to Jasper. Revision ChangesPath 1.4 +3 -1 jakarta-tomcat-4.0/RELEASE-NOTES-4.1-dev.txt Index: RELEASE-NOTES-4.1-dev.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1-dev.txt,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- RELEASE-NOTES-4.1-dev.txt 28 Feb 2002 17:20:56 - 1.3 +++ RELEASE-NOTES-4.1-dev.txt 28 Mar 2002 14:58:33 - 1.4 @@ -3,7 +3,7 @@ Release Notes = -$Id: RELEASE-NOTES-4.1-dev.txt,v 1.3 2002/02/28 17:20:56 glenn Exp $ +$Id: RELEASE-NOTES-4.1-dev.txt,v 1.4 2002/03/28 14:58:33 larryi Exp $ @@ -79,6 +79,8 @@ Jasper Bug Fixes: +CharDataGenerator: Fixed a bug where '\r' line terminators were not being + preserved as required by the spec. - Webapps Bug Fixes: -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7567] - Tar file failed to untar.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7567. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7567 Tar file failed to untar. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-03-28 15:36 --- Use GNU TAR. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Mod_jk v/s mod_webapp
We will create really soon webpages for jakarta-tomcat-connectors projects which will cover that. stay tuned - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 28, 2002 2:11 PM To: [EMAIL PROTECTED] Subject: RE: Mod_jk v/s mod_webapp Maybe I've not kept up on the docs enough but ... I do think this thread, highlights a general confusion around tomcat. Over the last couple of years, there have been many mod_jk/jk2/webapp/warp/?? implementations, ajp versions etc, and even when the discussions are on the list, it's still hard to be able to say (for lowly thread lurkers/tomcat users like myself), tomcat X.x can use mod_??, on ajp?.? because they provide xyz.. It would be nice to have a page in the docs, on the general tomcat site, that gives a summary of what each native connector does in terms of features, config, performance, load balancing, web servers supported, whether still in development etc. -Original Message- From: pier Sent: 28 March 2002 12:52 To: tomcat-dev Cc: pier Subject: Re: Mod_jk v/s mod_webapp David Graff [EMAIL PROTECTED] wrote: Thanks for the pointer on that documentation. I was wondering where the Javadoc style comments were being used at. You welcome... I still don't think the question was really answered though as to the motivation of mod_webapp versus mod_jk/mod_jk2 development? Are there any goals that have been made available to the public so that we understand what the spawned these two different integration modules? Motivation? I don't like mod_jk, I wanted to use APR as a portable runtime for an Apache 1.3 module, I believe that the WARP protocol with built-in support for auto-deployment and web-application configuration is the way to go (rather than using mod_rewrite rules all the way around), and because I don't like Costin :) :) :) :) 1.2.3. (BTW, all those goals passed over on this mailing list in the past 2/3 years, check the archives...) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tag pooling question
I'm actually performing a series of benchmarks that are close to what you describe, though the pages are complex, in that JSTL is used to markup logic. the test pages are highly dynamic and use includes extensively to break pieces into logical chunks. once I am done I will post the results. peter lin [EMAIL PROTECTED] wrote: The most usefull tools are OptimizeIt and ab. Simple pages would help much better then complex pages - first find out what's the overhead of executin a simple JSP page, with no tags, compare it with the equivalent servlet ( HelloWorld ), and find out what's wrong. Then use a simple hello world Tag, compare it with the equivalent servlet ( or JSP not using tags ), and find what's wrong. Same for a simple iteration tag, compared with a scriptlet If you solve those simple problems, and get the tag version in a reasonable limit, I think we'll all be very happy ( 30% slower would be acceptable for me, even 1/2 the speed of the equivalent scriptlet ). Going after 'real life applications' when the simple hello world tag, or a simple empty jsp page has a clear performance penalty would be a waste of time. ( all that with a reasonable load - I sugest 80 concurent requests ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2 - Imported sources
kinman 02/03/28 10:46:21 Log: - Create subproject jasper2, a JSP compiler for tomcat 4.x Status: Vendor Tag: jasper Release Tags: next N jakarta-tomcat-jasper/jasper2/build.xml N jakarta-tomcat-jasper/jasper2/README.txt N jakarta-tomcat-jasper/jasper2/BUILDING.txt N jakarta-tomcat-jasper/jasper2/doc/jspc.html N jakarta-tomcat-jasper/jasper2/src/bin/jasper.bat N jakarta-tomcat-jasper/jasper2/src/bin/jasper.sh N jakarta-tomcat-jasper/jasper2/src/bin/jspc.bat N jakarta-tomcat-jasper/jasper2/src/bin/jspc.sh N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/CommandLineContext.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/Constants.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/EmbededServletOptions.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JasperError.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JasperException.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspEngineContext.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/Options.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/.#JspDocumentParser.java.1.9 N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/CommandLineCompiler.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/CompileException.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Dumper.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JavaCompiler.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JikesJavaCompiler.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspCompiler.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/.#Compiler.java.1.6 N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspReader.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspUtil.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/KjcJavaCompiler.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Mangler.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Mark.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/.#Node.java.1.23 N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageDataImpl.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ParseException.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ParserController.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ServletWriter.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/SunJavaCompiler.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagConstants.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/.#Generator.java.1.10 N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TldLocationsCache.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/.#Node.java.1.14 N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/BeanRepository.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/.#JspDocumentParser.java.1.22 N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/DefaultErrorHandler.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/.#Generator.java.1.17 N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ErrorDispatcher.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ErrorHandler.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JavacErrorDetail.java N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/.#Parser.java.1.18 N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/.#Validator.java.1.2 N jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageInfo.java N
RE: Mod_jk v/s mod_webapp
On Thu, 28 Mar 2002 [EMAIL PROTECTED] wrote: Maybe I've not kept up on the docs enough but ... I do think this thread, highlights a general confusion around tomcat. Over the last couple of years, there have been many mod_jk/jk2/webapp/warp/?? implementations, ajp versions etc, and even when the discussions are on the list, it's still hard to be able to say (for lowly thread lurkers/tomcat users like myself), tomcat X.x can use mod_??, on ajp?.? because they provide xyz.. The problem is I have no time and I'm not good at writing docs. Mod_jk works on all web servers and with all tomcat versions. Mod_jk2 will do the same. The core of the confusion is the distinction between protocol, API, implementation. A protocol is something like IIOP, RPC, HTTP. The API is a set of functions - for forwarding the request, getting response, config, auth, etc. Mod_jk is an implementation that supports multiple communication protocols and multiple APIs. Different versions of tomcat also support multiple protocols and APIs. There are 4 protocols we use: - ajp12 ( in tomcat3.x, jserv ) - ajp13 ( in tomcat3.x, tomcat4.x ) - jni ( in tomcat3.x - and 4.x as soon as jk2 is ready ) - WARP ( in tomcat4.x ) There are several APIs: - request forwarding APIs - usually one method signature for each protocol - configuration methods - in warp and what used to be called ajp14 ( very confusing, since it was a set of new methods implemented with ajp13 protocol ) - auth, shutdown, etc - again 2 or 3 if you count the 4.0 shutdown protocol. And several implementations of those protocols: - mod_jserv implements ajp12 - mod_jk implements ajp12, ajp13, jni - mod_jk2 implements ajp13 ( and one of my goals for a future version is to implement one 'real' protocol - a minimal subset of RPC/XDR or IIOP or similar ) ( with jni replaced with ajp13 - and multiple channels - tcp, unix, jni ) - mod_webapp implements WARP - tomcat3.x implements ajp12, ajp13, jni - tomcat4.x - ajp13, WARP And several implementations of the APIs ( similar matrix ). The basic request forwarding APIs used in jk is common to all servers and should be fully interoperable. Extended APIs ( config, etc) are supported only in new versions of tomcat/jk. Load balancing is one extra feature in mod_jk and mod_jserv, on top of the forwarding API. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler .#Compiler.java.1.11 .#Compiler.java.1.6 .#Generator.java.1.10 .#Generator.java.1.17 .#Generator.java.1.4 .#Generator.java.1.8 .#JspDocumentParser.java.1.22 .#JspDocumentParser.java.1.9 .#Node.java.1.14 .#Node.java.1.23 .#Parser.java.1.18 .#Validator.java.1.2
kinman 02/03/28 10:57:36 Removed: jasper2/src/share/org/apache/jasper/compiler .#Compiler.java.1.11 .#Compiler.java.1.6 .#Generator.java.1.10 .#Generator.java.1.17 .#Generator.java.1.4 .#Generator.java.1.8 .#JspDocumentParser.java.1.22 .#JspDocumentParser.java.1.9 .#Node.java.1.14 .#Node.java.1.23 .#Parser.java.1.18 .#Validator.java.1.2 Log: - Removed useless files imported by mistake. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tag pooling question
What you said about using simple pages and comparing their performance with their servlet equivalents makes a lot of sense and it's obvious that that needs to be done in any optimization work. However, real life applications benchmarks are also useful for other purposes. They can be used for measuring the overall effectiveness of optimizations: how effective the individual optimizations are, and how they interact with each other. It also would let us find out what optimizations are important in practice, not just in small test cases. I'd use these benchmarks for measuring the progress on optimization works, and as an early warning that certain optimizations are not useful or even harmful. - Kin-man Date: Wed, 27 Mar 2002 14:54:10 -0800 (PST) From: [EMAIL PROTECTED] Subject: Re: tag pooling question X-X-Sender: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED], Kin-Man Chung [EMAIL PROTECTED] MIME-version: 1.0 X-Authentication-warning: dyn-181.sfo.covalent.net: costinm owned process doing -bs On Wed, 27 Mar 2002, Kin-Man Chung wrote: Pulling codes out of iteration tag bodies is very high on my list of optimizations that I wnat to do. I don't think we can do much about general scriplets that contain loops, though. But before we start on jasper optimization work, we'll need benchmarks and performance analysers. I have learnt from experience that performance improvement often comes from surprising places, and that optimizations done at the wrong time and place often do more harm than good. Benchmarks would give us some real metric for us to measure our optimization work, and analyzing tools would let us identify hot spots that need to be improved. I'd appreciate comments, suggestions, and pointers on these two subjects. I'd also appreciate if anyone can donate some real life applications that I can use for benchmarking jasper performance. The most usefull tools are OptimizeIt and ab. Simple pages would help much better then complex pages - first find out what's the overhead of executin a simple JSP page, with no tags, compare it with the equivalent servlet ( HelloWorld ), and find out what's wrong. Then use a simple hello world Tag, compare it with the equivalent servlet ( or JSP not using tags ), and find what's wrong. Same for a simple iteration tag, compared with a scriptlet If you solve those simple problems, and get the tag version in a reasonable limit, I think we'll all be very happy ( 30% slower would be acceptable for me, even 1/2 the speed of the equivalent scriptlet ). Going after 'real life applications' when the simple hello world tag, or a simple empty jsp page has a clear performance penalty would be a waste of time. ( all that with a reasonable load - I sugest 80 concurent requests ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
kinman 02/03/28 11:43:08
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
- Apply the fix by [EMAIL PROTECTED]
Revision ChangesPath
1.2 +8 -11
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Generator.java28 Mar 2002 18:46:17 - 1.1
+++ Generator.java28 Mar 2002 19:43:08 - 1.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
1.1 2002/03/28 18:46:17 kinman Exp $
- * $Revision: 1.1 $
- * $Date: 2002/03/28 18:46:17 $
+ * $Header:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
1.2 2002/03/28 19:43:08 kinman Exp $
+ * $Revision: 1.2 $
+ * $Date: 2002/03/28 19:43:08 $
*
*
*
@@ -842,18 +842,16 @@
--count;
switch(ch) {
case '':
- sb.append('\\');
- sb.append('\');
+ sb.append('\\').append('\');
break;
case '\\':
- sb.append('\\');
- sb.append('\\');
+ sb.append('\\').append('\\');
break;
case '\r':
+ sb.append('\\').append('r');
break;
case '\n':
- sb.append('\\');
- sb.append('n');
+ sb.append('\\').append('n');
if (breakAtLF || count 0) {
// Generate an out.write() when see a '\n' in template
@@ -865,8 +863,7 @@
}
break;
case '\t': // Not sure we need this
- sb.append('\\');
- sb.append('t');
+ sb.append('\\').append('t');
break;
default:
sb.append(ch);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Problem with forward() and setCharacterEncoding
Hi, My situation is the following: I have to servlets, let's call them Forwarder and Test. I send requests (both GET and POST) to the Forwarder servlet which uses request.getRequestDispatcher to forward it to the Test servlet. I'm using Tomcat 4.0.3, but 4.0.4 produced the same. The problem is the following: when the Test servlet receives the request in doGet or doPost, or even in service(), the parameters are already parsed according to the ISO-8859-1 character encoding. This makes impossible to specify the character encoding with request.setCharacterEncoding() in the Test servlet. Actually I can't tell where is it implemented exactly, because the source code is too big for me, but I read the Servlet specification and probably I know why this happens and what may be a workaround for it. The Servlet API 2.3 Specification says on page 56: Parameters specified in the query string used to create the RequestDispatcher take precedence over other parameters of the same name passed to the included servlet. The parameters associated with a RequestDispatcher are scoped to apply only for the duration of the include or forward call. So when forwarding to a path /servlet/Test?id=5678 the original id parameter is overwritten with value 1234, if, for example the original request was /servlet/Forwarder?id=1234. I guess this overwriting is made by parsing the parameters in the original request and parsing the parameters in the path specified for the Dispatcher and after that they are merged. But at this point, the original parameters are encoded with ISO-8859-1, and I'm loosing valuable accented characters... Moreover, even posted parameters are parsed, although the specification is not clear about it, but on page 58 (SRV.8.4.1) it says The request dispatching mechanism is responsible for aggregating query string parameters when forwarding or including requests. IMHO this means only query strings should be merged, but posted data not. Additionally the ServletInputStream is completely read (0 bytes can be read from it) in the Test servlet, so I even can't reparse the parameters. My suggestion is that neither path nor the original query string should be URLDecoded. Only those parts should be overwritten in the original query string in which the parameter name equals to any in the path string. Parameter parsing should be done in Test servlet, not in Forwarder servlet. Best wishes, Daniel Marczisovszky -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7598] New: - Inconsistent files available for download for Tomcat 4.0, 4.0.1, . . .
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7598. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7598 Inconsistent files available for download for Tomcat 4.0, 4.0.1, . . . Summary: Inconsistent files available for download for Tomcat 4.0, 4.0.1, . . . Product: Tomcat 4 Version: 4.0.3 Final Platform: All URL: http://jakarta.apache.org/builds/jakarta-tomcat- 4.0/release/v4.0.2/bin/ OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am a long-time (1.5 years+) Tomcat 3 user and am installing (building from src) 4.0.3 for the first time on Mandrake 8.2. This is a clean install of Mdk 8.2, done this p.m. followed by clean installs of Java 1.3.1_03 and ant 1.4.4. I will follow this with installs of Cocoon anything else I can think of. The install/build instructions call for the item: jakarta-servletapi-4.tar.gz from the Tomcat download site. This file ain't there for 4.0.3 or 4.0.2 and I'm not sure about 4.0.1. I did find it under 4.0 final but I had to look under some rocks to get that. In my travels I noticed that the Connectors are not consistently available across the multiple releases that are out there. It sure would be nice if someone fixed this so that you used the same build script more than once. Thanx a bunch. Love the product(s). Yer stuff is one reason that Java is growing so well. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7600] New: - JBuilder .war files don't load in 4.0.2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7600. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7600 JBuilder .war files don't load in 4.0.2 Summary: JBuilder .war files don't load in 4.0.2 Product: Tomcat 4 Version: 4.0.2 Final Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Connector:Webapp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Taking a JBuilder6 built war archive from 4.0.1 to 4.0.2 broke my app with Missing application web.xml comparing the archives with jar -tf archive.war I found that the JBuilder wars don't have an entry for the directory. jar produces: WEB-INF/ WEB-INF/web.xml JBuilder Produces: WEB-INF/web.xml Cheers Sean -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7600] - JBuilder .war files don't load in 4.0.2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7600. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7600 JBuilder .war files don't load in 4.0.2 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-03-29 03:23 --- I found this same problem about a month ago with a different tool and committed the fix to the HEAD branch. So, you should see it in the latest nightly build. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Mod_jk v/s mod_webapp
On Fri, 2002-03-29 at 00:10, [EMAIL PROTECTED] wrote: I do think this thread, highlights a general confusion around tomcat. Over the last couple of years, there have been many mod_jk/jk2/webapp/warp/?? implementations, ajp versions etc, and even when the discussions are on the list, it's still hard to be able to say (for lowly thread lurkers/tomcat users like myself), tomcat X.x can use mod_??, on ajp?.? because they provide xyz.. Cannot speak about TC 4, since I don't use it, but TC 3.3 clearly states here http://jakarta.apache.org/tomcat/tomcat-3.3-doc/index.html how it's done and with what (using either (now deprecated) mod_jserv or properly with mod_jk). The reasons behind mod_jk are also clearly stated in the 'Why mod_jk?' section. The rest is 'advanced topics' and is more developer stuff then user stuff, so it is not in the documentation. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
