Help me...
I'm use Linux Read Hat 9.0 Include Apache 2.0 Server, Java 1.4.0.03, ant 1.5.3-1, Tomcat 4.1.24, I'm downloaded jakarta-tomcat-connectors-jk2-2.0.2-src.tar and mod_jk2-2.0.43.so, but I'm not build jakarta-tomcat-connectors-jk2-2.0.2-src and I'm not install Mod_jk2 the communication between Tomcat and Apache. __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2 README.txt
jfclere 2003/09/16 00:38:51 Modified:jk/native2 README.txt Log: remove \r. Revision ChangesPath 1.4 +13 -13jakarta-tomcat-connectors/jk/native2/README.txt Index: README.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/README.txt,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- README.txt6 Oct 2002 07:50:32 - 1.3 +++ README.txt16 Sep 2003 07:38:51 - 1.4 @@ -1,21 +1,21 @@ README for JK2 -- -JK2 is a refactoring of JK and is much more powerfull. Even if it works with -Apache 1.3, JK2 has been developed with Apache 2.0 in mind, and is better suited -for multi-threaded servers like IIS, NES/iPlanet. It can also be embeded in +JK2 is a refactoring of JK and is much more powerfull. Even if it works with +Apache 1.3, JK2 has been developed with Apache 2.0 in mind, and is better suited +for multi-threaded servers like IIS, NES/iPlanet. It can also be embeded in other applications and used from java. -JK2 improves the modularity and has a better separation between protocol and -physical layer. As such JK2 support fast unix-socket, and could be extended to -support others communications channels. It is better suited for JNI and may use -(in a future version) JDK 1.4 NIO. There is additional support for monitoring, -similar with JMX in java. A module similar with mod_status is provided, and -additional adapters can be used to interface and provide status and runtime -configuration. The configuration has been changed to follow the component -models. Multiple configuration sources can be supported ( in additon to file ) -providing better integration with the embeding application. The config layer -uses the management layer APIs and it can support persistence for changes done +JK2 improves the modularity and has a better separation between protocol and +physical layer. As such JK2 support fast unix-socket, and could be extended to +support others communications channels. It is better suited for JNI and may use +(in a future version) JDK 1.4 NIO. There is additional support for monitoring, +similar with JMX in java. A module similar with mod_status is provided, and +additional adapters can be used to interface and provide status and runtime +configuration. The configuration has been changed to follow the component +models. Multiple configuration sources can be supported ( in additon to file ) +providing better integration with the embeding application. The config layer +uses the management layer APIs and it can support persistence for changes done via runtime configuration. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk2 on aix - Urgent
Ajay Arora wrote: Greetings, I was installing mod_jk2 to interact between apache 2 and tomcat 1.4. I was not able to build the module. It says jni_md.h is missing. I am having java1.3.1 and I do not have include directory with it. Have you try to comment out the #include jni_md.h? Are you sure you need jni? Can somebody will help mw with it. Can anybody has compiled mod_jk2 for aix 5.1 or can any body provide me the include directory. Ajay _ Attention NRIs! Banking worries? http://server1.msn.co.in/msnspecials/nriservices/index.asp Get smart tips. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23190] New: - JNDIRealm doesn't escape search filters
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=23190. 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=23190 JNDIRealm doesn't escape search filters Summary: JNDIRealm doesn't escape search filters Product: Tomcat 4 Version: 4.1.27 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If the DN, which will be inserted into the search filter (for example DN of user in group search), contains a back slash character, the search won't work. This back slash character must be escaped according RFC2254. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23105] - JkMount overrides Alias
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=23105. 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=23105 JkMount overrides Alias --- Additional Comments From [EMAIL PROTECTED] 2003-09-16 12:42 --- Could you try with : JkMount /*.jsp atomcatserver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23192] New: - getRemoteUser() returns null with Authorization header
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=23192. 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=23192 getRemoteUser() returns null with Authorization header Summary: getRemoteUser() returns null with Authorization header Product: Tomcat 4 Version: 4.1.27 Platform: PC URL: http://localhost:8080/examples/jsp/snp/snoop.jsp OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Even though the browser sends Authorization header in the request it is apparantly not processed and the username is not set in the request WHEN the url is not one of the protected urls in the web.xml. What this means is that it is impossible to have application specific security managment in your code, for example using setStatus(HttpServletResponse.SC_UNAUTHORIZED) in servlet code. I am using Java v1.4.2_01 and Internet Explorer v6.0.2800.1106 Steps to reproduce: 1) Install Tomcat 4.1.27-LE 1) Change to BASIC authentication in web.xml in the examples webapplication. 2) add /jsp/snp to protected urls in security-constraint section. 3) Open browser and go to the page: http://localhost:8080/examples/jsp/snp/snoop.jsp log in as tomcat/tomcat, the page return you as user tomcat, ok so far. 4) Stop tomcat and remove the /jsp/snp as a protected url. Start tomcat again 5) Refresh the page in the browser, remote user is now null. If you monitor the communications between the server and browser you will see that the browser sends the Authorization header in the second request, but getRemoteUser still returns null. Here is the request and response: GET /examples/jsp/snp/snoop.jsp HTTP/1.1 Accept: */* Accept-Language: is Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; T312461) Host: localhost Connection: Keep-Alive Cache-Control: no-cache Cookie: JSESSIONID=9A0358D041949A450A3E87DE750D8EC1 Authorization: Basic dG9tY2F0OnRvbWNhdA== HTTP/1.1 200 OK Content-Type: text/html;charset=ISO-8859-1 Content-Length: 745 Date: Tue, 16 Sep 2003 11:47:16 GMT Server: Apache Coyote/1.0 html !-- Copyright (c) 1999 The Apache Software Foundation. All rights reserved. -- body bgcolor=white h1 Request Information /h1 font size=4 JSP Request Method: GET br Request URI: /examples/jsp/snp/snoop.jsp br Request Protocol: HTTP/1.1 br Servlet path: /jsp/snp/snoop.jsp br Path info: null br Query string: null br Content length: -1 br Content type: null br Server name: localhost br Server port: 80 br Remote user: null br Remote address: 127.0.0.1 br Remote host: 127.0.0.1 br Authorization scheme: null br Locale: is hr The browser you are using is Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; T312461) hr /font /body /html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jk, directoindex and friends
I've got the following configuration Apache 2.0.47/jk 1.2.4 : VirtualHost * ServerAdmin [EMAIL PROTECTED] DirectoryIndex index.html index.php index.jsp DocumentRoot /var/www/lxmlrpc ServerName lxmlrpc ErrorLog logs/lxmlrpc-error_log CustomLog logs/lxmlrpc-access_log common AddType application/x-httpd-php .php .php4 .php3 .phtml AddType application/x-httpd-php-source .phps Alias /test /var/www/test JkMount /*.jsp tomcat1 JkOptions +ForwardDirectories /VirtualHost Apache forward request to tomcat for URL : http://lxmlrpc/test/index.jsp But only if Apache find a file /var/www/test/index.jsp Did I miss something or should we add a flag to avoid such test, since when using Apache and Tomcat on remote systems I don't want Apache to have dummy 'index.jsp'. I've got the same request for config like this : VirtualHost * ServerAdmin [EMAIL PROTECTED] DirectoryIndex index.html index.php index.jsp DocumentRoot /var/www/lxmlrpc ServerName lxmlrpc ErrorLog logs/lxmlrpc-error_log CustomLog logs/lxmlrpc-access_log common AddType application/x-httpd-php .php .php4 .php3 .phtml AddType application/x-httpd-php-source .phps JkMount /test/*.jsp tomcat1 JkOptions +ForwardDirectories /VirtualHost Comments welcomed ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat within custom application
Hi, I am wondering how I can run the Tomcat JSP/Servlet container within another process, which is not a HTTP server but a custom Java application. This is to mean that I have some JSP or Servlets for example. I need to run them on a client machine (Windows NT/UNIX platform), which doesn't have a web server or the standalone Tomcat container installed. I do not want to install that either. I just want to launch the Tomcat container as one thread within one custom Java application while some other threads will do other unrelated work. The purpose is to deploy the Servlets or JSP making the Tomcat container transparent to the client. Thanks in advance. Xtremebytes Webmaster
Re: Tomcat within custom application
Xtremebytes Webmaster a écrit : Hi, I am wondering how I can run the Tomcat JSP/Servlet container within another process, which is not a HTTP server but a custom Java application. This is to mean that I have some JSP or Servlets for example. I need to run them on a client machine (Windows NT/UNIX platform), which doesn't have a web server or the standalone Tomcat container installed. I do not want to install that either. I just want to launch the Tomcat container as one thread within one custom Java application while some other threads will do other unrelated work. The purpose is to deploy the Servlets or JSP making the Tomcat container transparent to the client. Do you want tomcat handle some HTTP requests ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat within custom application
Howdy, You use Embedded: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/catalina/docs/api/org/ap ache/catalina/startup/Embedded.html Yoav Shapira Millennium ChemInformatics -Original Message- From: Xtremebytes Webmaster [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 16, 2003 10:12 AM To: [EMAIL PROTECTED] Subject: Tomcat within custom application Hi, I am wondering how I can run the Tomcat JSP/Servlet container within another process, which is not a HTTP server but a custom Java application. This is to mean that I have some JSP or Servlets for example. I need to run them on a client machine (Windows NT/UNIX platform), which doesn't have a web server or the standalone Tomcat container installed. I do not want to install that either. I just want to launch the Tomcat container as one thread within one custom Java application while some other threads will do other unrelated work. The purpose is to deploy the Servlets or JSP making the Tomcat container transparent to the client. Thanks in advance. Xtremebytes Webmaster This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat within custom application
Xtremebytes Webmaster wrote: I am wondering how I can run the Tomcat JSP/Servlet container within another process, which is not a HTTP server but a custom Java application. This is to mean that I have some JSP or Servlets for example. I need to run them on a client machine (Windows NT/UNIX platform), which doesn't have a web server or the standalone Tomcat container installed. I do not want to install that either. I just want to launch the Tomcat container as one thread within one custom Java application while some other threads will do other unrelated work. The purpose is to deploy the Servlets or JSP making the Tomcat container transparent to the client. You can look at the Tomcat 5 embedded distribution (basically, you get an Ant script replacing server.xml). The included example Ant script just makes some basic JMX calls to create an embedded Tomcat, so you don't have to use Ant (but, for an example, it's obviously easier to understand and more readable) or have any dependencies on the Tomcat APIs. The old Tomcat 4.x Embedded class is also supported (except it has been rewritten to use the standard behavior rather than being a special case). I believe some real docs on embedding would be useful, including: - embedding Coyote - embedding Tomcat using Embedded - embedding Tomcat with JMX Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] 5.0.12 stability rating
ballot [ ] Alpha [ ] Beta /ballot pleaAs usual, please vote :)/plea Add comments if needed. 5.0.12 is similar to 5.0.11, with changes focusing on the Coyote connector (addition of buffering at the socket layer for significantly improved network efficiency, and two important bugfixes to the thread pool and socket handling code). Please check it for regressions. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23195] New: - Problem with JSTL fmt tags and the response encoding
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=23195. 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=23195 Problem with JSTL fmt tags and the response encoding Summary: Problem with JSTL fmt tags and the response encoding Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When I used any JSTL fmt tag that sets the response locale, tomcat according to the standard changes the response encoding to support the locale (the encoding is read from file CharsetMapperDefault.properties). The problem is that the file contains only the ISO-8859-* encodings and tomcat changed my encoding (UTF-8) that also support my language to ISO-8859-2, instead of leave it unchanged, then appered problem with the form encoding, because I expected UTF-8 and not ISO-859-2. Why tomcat changes repsponse encoding that supports the locale set by JSTL fmt tag? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager StatusManagerServlet.java StatusTransformer.java
remm2003/09/16 08:36:07
Modified:webapps/manager/WEB-INF/classes/org/apache/catalina/manager
StatusManagerServlet.java StatusTransformer.java
Log:
- Tab cleanup.
- We're not in the HD buisness, so a KB is 1024 bytes, and a MB is 1024 KB :)
- Fix formatting errors for MB sizes.
Revision ChangesPath
1.12 +24 -22
jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/StatusManagerServlet.java
Index: StatusManagerServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/StatusManagerServlet.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- StatusManagerServlet.java 4 Sep 2003 14:22:18 - 1.11
+++ StatusManagerServlet.java 16 Sep 2003 15:36:07 - 1.12
@@ -259,7 +259,7 @@
(request.getPathInfo().equals(/all))) {
completeStatus = true;
}
- // use StatusTransformer to output status
+// use StatusTransformer to output status
StatusTransformer.writeHeader(writer,mode);
// Body Header Section
@@ -270,7 +270,7 @@
} else {
args[1] = sm.getString(statusServlet.title);
}
- // use StatusTransformer to output status
+// use StatusTransformer to output status
StatusTransformer.writeBody(writer,args,mode);
// Manager Section
@@ -295,11 +295,11 @@
(request.getContextPath() + /status/all);
args[8] = sm.getString(statusServlet.complete);
}
- // use StatusTransformer to output status
+// use StatusTransformer to output status
StatusTransformer.writeManager(writer,args,mode);
// Server Header Section
- args = new Object[7];
+args = new Object[7];
args[0] = sm.getString(htmlManagerServlet.serverTitle);
args[1] = sm.getString(htmlManagerServlet.serverVersion);
args[2] = sm.getString(htmlManagerServlet.serverJVMVersion);
@@ -307,7 +307,7 @@
args[4] = sm.getString(htmlManagerServlet.serverOSName);
args[5] = sm.getString(htmlManagerServlet.serverOSVersion);
args[6] = sm.getString(htmlManagerServlet.serverOSArch);
- // use StatusTransformer to output status
+// use StatusTransformer to output status
StatusTransformer.writePageHeading(writer,args,mode);
// Server Row Section
@@ -318,38 +318,40 @@
args[3] = System.getProperty(os.name);
args[4] = System.getProperty(os.version);
args[5] = System.getProperty(os.arch);
- // use StatusTransformer to output status
-StatusTransformer.writeServerInfo(writer,args,mode);
+// use StatusTransformer to output status
+StatusTransformer.writeServerInfo(writer, args, mode);
try {
// Display virtual machine statistics
-// writeVMState(writer);
StatusTransformer.writeVMState(writer,mode);
Enumeration enum = threadPools.elements();
while (enum.hasMoreElements()) {
ObjectName objectName = (ObjectName) enum.nextElement();
String name = objectName.getKeyProperty(name);
- // use StatusTransformer to output status
-StatusTransformer.writeConnectorState(writer,objectName,
- name,mBeanServer,globalRequestProcessors,
- requestProcessors,mode);
+// use StatusTransformer to output status
+StatusTransformer.writeConnectorState
+(writer, objectName,
+ name, mBeanServer, globalRequestProcessors,
+ requestProcessors, mode);
}
if ((request.getPathInfo() != null)
(request.getPathInfo().equals(/all))) {
-// Warning: slow
- // use StatusTransformer to output status
-StatusTransformer.writeDetailedState(writer,mBeanServer,mode);
+// Note: Retrieving the full status is much slower
+// use StatusTransformer to output status
+StatusTransformer.writeDetailedState
+(writer, mBeanServer, mode);
}
} catch (Exception e) {
-e.printStackTrace();
+throw new ServletException(e);
}
- // use StatusTransformer to output status
- StatusTransformer.writeFooter(writer,mode);
+// use StatusTransformer to output status
+
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
Date: Mon, 15 Sep 2003 22:57:32 -0700
From: Eric Carmichael [EMAIL PROTECTED]
Subject: Re: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources
messages.properties
X-Originating-IP: [64.203.49.21]
To: Tomcat Developers List [EMAIL PROTECTED]
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Priority: 3
X-MSMail-priority: Normal
X-Originating-Email: [EMAIL PROTECTED]
X-OriginalArrivalTime: 16 Sep 2003 05:57:41.0966 (UTC)
FILETIME=[7112DEE0:01C37C17]
But this also shows that tight coupling between Generator and SmapUtil is
flagile and error prone. I think it would be a better design if we
decouple these two modules somehow. We could create additional data
structure that captures the mapping info for template texts, with
Generator
its producer and SmapUtil its comsumer. What do you think? I'll
think about this more.
I thought about this a bit when I was copying the line feed logic from
Generator.java to SmapUtil.java to fix the line mappings for template text
nodes, because I didn't like duplicating code, but I didn't see an
alternative except to move the SMAPping into Generator. How would your
producer/consumer approach differ from that? If a data structure that
captures mapping info is what's needed, we already have SmapStratum
performing that function, so I don't see much difference between having
Generator produce a new mapping info data structure and just having
Generator produce the SMAP directly.
I think keeping an array (in the Template node) of the source line that
corresponds to each of the Java line we generate is probably enough. I'll
commit some codes today and you'll see what I mean.
There are reasons for not doing SMAP generation in Generator. Generator is
already the biggest module in Jasper, and I'd like not to make it any more
complicated. Also, some codes are generated out of order, in buffers that
got appended at the end of generating the main method, so that the mappings
cannot be determined when codes are generated.
SMAP generation is one of the area that does not got enough test and use.
You seem to be one of the few who actually look at it. Are you doing anything
with it?
-Kin-man
BTW, the reason for if (textSize = 3) is for performance optimization.
out.write('\n') should be faster than out.write(\n) so it's OK that
you move into the if (ctxt.getOptions().genStringAsCharArray()) block,
for now; but it should really be applied in all cases. Maybe we can
write all out.write()'s in a single line, so that the mapping is not
changed? Or we can revisit this later.
Yeah, I didn't know if putting if (textSize = 3) outside the if
(ctxt.getOptions().genStringAsCharArray()) block was intentional or not,
which is why I was hesitant to commit my fix. Thanks for clarifying. I
don't have a problem changing the SMAPs as long as we don't break them, so
do whatever you think best on the Generator side, and I'll just try to make
sure to check for SMAP regressions before the next release.
Eric
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
Kin-Man Chung wrote: I think keeping an array (in the Template node) of the source line that corresponds to each of the Java line we generate is probably enough. I'll commit some codes today and you'll see what I mean. There are reasons for not doing SMAP generation in Generator. Generator is already the biggest module in Jasper, and I'd like not to make it any more complicated. Also, some codes are generated out of order, in buffers that got appended at the end of generating the main method, so that the mappings cannot be determined when codes are generated. SMAP generation is one of the area that does not got enough test and use. You seem to be one of the few who actually look at it. Are you doing anything with it? Given the number of bug reports which have been filed against that single feature, I can assert this is not the case. You should rewrite your sentence as SMAP generation is one of the area that does not get enough test and use among Tomcat committers ;-) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java Node.java SmapStratum.java SmapUtil.java
kinman 2003/09/16 10:46:44
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Node.java SmapStratum.java SmapUtil.java
Log:
- For template texts that generate multiple Java lines, addidtional mapping
informantion are kept in the TemplateText node, to aide SMAP generation.
Revision ChangesPath
1.208 +23 -14
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.207
retrieving revision 1.208
diff -u -r1.207 -r1.208
--- Generator.java15 Sep 2003 13:43:54 - 1.207
+++ Generator.java16 Sep 2003 17:46:43 - 1.208
@@ -1867,21 +1867,25 @@
return;
}
-if (ctxt.getOptions().genStringAsCharArray()) {
-if (textSize = 3) {
- // Spcial case small text strings
- n.setBeginJavaLine(out.getJavaLine());
- out.printil(out.write( + quote(text.charAt(0)) + ););
- if (textSize 1) {
- out.printil(out.write( + quote(text.charAt(1)) + ););
+if (textSize = 3) {
+ // Special case small text strings
+ n.setBeginJavaLine(out.getJavaLine());
+ int lineInc = 0;
+ for (int i = 0; i textSize; i++) {
+ char ch = text.charAt(i);
+ out.printil(out.write( + quote(ch) + ););
+ if (i 0) {
+ n.addSmap(lineInc);
}
- if (textSize 2) {
- out.printil(out.write( + quote(text.charAt(2)) + ););
+ if (ch == '\n') {
+ lineInc++;
}
- n.setEndJavaLine(out.getJavaLine());
- return;
}
+ n.setEndJavaLine(out.getJavaLine());
+ return;
+ }
+if (ctxt.getOptions().genStringAsCharArray()) {
// Generate Strings as char arrays, for performance
ServletWriter caOut;
if (charArrayBuffer == null) {
@@ -1915,6 +1919,7 @@
StringBuffer sb = new StringBuffer(out.write(\);
int initLength = sb.length();
int count = JspUtil.CHUNKSIZE;
+int srcLine = 0; // relative to starting srouce line
for (int i = 0; i text.length(); i++) {
char ch = text.charAt(i);
--count;
@@ -1930,6 +1935,7 @@
break;
case '\n' :
sb.append('\\').append('n');
+srcLine++;
if (breakAtLF || count 0) {
// Generate an out.write() when see a '\n' in template
@@ -1940,6 +1946,9 @@
}
sb.setLength(initLength);
count = JspUtil.CHUNKSIZE;
+
+// add a Smap for this line
+n.addSmap(srcLine);
}
break;
case '\t' : // Not sure we need this
1.77 +24 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java
Index: Node.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java,v
retrieving revision 1.76
retrieving revision 1.77
diff -u -r1.76 -r1.77
--- Node.java 2 Sep 2003 21:39:59 - 1.76
+++ Node.java 16 Sep 2003 17:46:43 - 1.77
@@ -63,6 +63,7 @@
import java.util.Iterator;
import java.util.List;
import java.util.Vector;
+import java.util.ArrayList;
import javax.servlet.jsp.tagext.BodyTag;
import javax.servlet.jsp.tagext.DynamicAttributes;
@@ -1921,6 +1922,8 @@
*/
public static class TemplateText extends Node {
+private ArrayList extraSmap = null;
+
public TemplateText(String text, Mark start, Node parent) {
super(null, null, text, start, parent);
}
@@ -1957,13 +1960,30 @@
public boolean isAllSpace() {
boolean isAllSpace = true;
for (int i=0; itext.length(); i++) {
- if (!Character.isSpace(text.charAt(i))) {
+ if (!Character.isWhitespace(text.charAt(i))) {
isAllSpace = false;
break;
}
}
return isAllSpace;
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
I know, I know. I plead guilty as charged. :-) Unfortunately, not having a debugger that uses SMP, it is hard to automate SMAP testing. You pretty much has to manually eyeball the files to verify its correctness. I think netbeans is planning to use tomcat 5 for its next major, so we'll expect more use there. -Kin-man Date: Tue, 16 Sep 2003 19:46:19 +0200 From: Remy Maucherat [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties To: Tomcat Developers List [EMAIL PROTECTED] Kin-Man Chung wrote: I think keeping an array (in the Template node) of the source line that corresponds to each of the Java line we generate is probably enough. I'll commit some codes today and you'll see what I mean. There are reasons for not doing SMAP generation in Generator. Generator is already the biggest module in Jasper, and I'd like not to make it any more complicated. Also, some codes are generated out of order, in buffers that got appended at the end of generating the main method, so that the mappings cannot be determined when codes are generated. SMAP generation is one of the area that does not got enough test and use. You seem to be one of the few who actually look at it. Are you doing anything with it? Given the number of bug reports which have been filed against that single feature, I can assert this is not the case. You should rewrite your sentence as SMAP generation is one of the area that does not get enough test and use among Tomcat committers ;-) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java
luehe 2003/09/16 11:56:35
Modified:catalina/src/share/org/apache/catalina/core
ApplicationHttpRequest.java
Log:
Fixed Bugtraq 4923455 (Sessions created in the target webapp of a cross-context are
invalid)
Revision ChangesPath
1.13 +5 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java
Index: ApplicationHttpRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- ApplicationHttpRequest.java 31 Aug 2003 21:08:55 - 1.12
+++ ApplicationHttpRequest.java 16 Sep 2003 18:56:35 - 1.13
@@ -545,6 +545,7 @@
if (localSession == null) {
localSession = context.getManager().createEmptySession();
localSession.setId(other.getId());
+localSession.setValid(true);
}
session = localSession.getSession();
return session;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13430] - WWW-Authenticate Header Is Not Sent
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=13430. 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=13430 WWW-Authenticate Header Is Not Sent --- Additional Comments From [EMAIL PROTECTED] 2003-09-16 19:12 --- We were able to solve this in our local applications by turning the 401.html page into a 401.jsp and adding the following code: response.setHeader(WWW-Authenticate, BASIC realm=\myrealm\); This caused the browser to once again display the authentication dialog. If the user presses cancel, or fails login multiple times, the browser gives up on the dialog and displays the underlying HTML in the 401.jsp file. If they succeed in authenticating, they are directed to the originally requested page. IMO, the ability to *entirely* override the authentication process is a valuable tool, but the way it was specified in web.xml is very confusing. What we are doing here is entirely delegating the authentication to an external JSP or servlet. This is a great tool, because it allows you to make dynamic decisions that you can't do inside of web.xml. For example, you could send a WWW-Authenticate: BASIC to most systems, but if the request matches a certain pattern or if it comes from a specified IP, etc, you could instead send a WWW-Authetnicate: Digest; or perhaps you could send a redirect to force SSL. Anyhow, it's a nice tool to be able to extend the functionality here. The problem is that the way the user above stumbled across this (and the way I stumbled across it, too) is by having a preexisting login-config to use BASIC auth, and then later added the 401.html page. My intent here was to display a link that allows the user to reset his or her password and have it emailed back to the email associated with their account. I was *very* confused when adding the error-page mapping completely disabled my login-config. Perhaps there is a better way to document this functionality? It seems to me that this is a reasonably common desire among developers: To use BASIC auth but to still provide user friendly tools when the user fails authentication. My recommendation is that this bug be marked WONTFIX, but that the documentation be updated to explain it more clearly. Implementing Juan's patch would take away the ability to delegate the whole authentication process to another JSP, which would be a loss. I just wish it were easier to understand... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Request Dispatcher error handling implementation in Tomcat
Please excuse the cross post to tomcat user mailing list. I am trying to understand the request dispatchers error handling behavior and want to know if Tomcat is implementing the specification correctly. My application uses a controller servlet to dispatch requests to a view servlet in another web app. Both web applications are deployed in an EAR file running on Jboss-3.2.1-Tomcat-4.1.24. Dispatching code: String view = request.getParameter(view); RequestDisptcher dispatcher = this.getServletContext().getContext(/view).getRequestDispatcher(/servlet + view); If the URL given to the request dispatcher does not exist then the server 404 error page is displayed. I have tried to customize this error page firstly by defining an error page in the web.xml file of the Controller webapp. My custom page is displayed when attempting to visit non existent URLs under the controller context but is not displayed when the request is dispatched to the view context. I then also all updated the view webapp with it's own error pages and tested these in the same manner. Again although the page is displayed when visiting the URL directly it is not displayed when the request is dispatched. e.g. http://mydomain/controller/nosuchfile.jsp (displays custom 404 error page) http://mydomain/controller?view=nosuchfile.jsp (displays default 404 error page) http://mydomain/view/nosuchfile.jsp (displays custom error page) Finally I have tried to change the server error page by defining an error page in the server web.xml file by adding: error-page error-code404/error-code location/controller/jsp/404.jsp/location /error-page This did not work and the default error pages are still displayed. SRV.8.5 in the servlet 2.3 specification states: If the servlet that is the target of a request dispatcher throws a runtime exception or a checked exception of type ServletException or IOException, it should be propagated to the calling servlet. All other exceptions should be wrapped as ServletExceptions and the root cause of the exception set to the original exception before being propagated. This suggests to me that the error page associated with the calling webapp would be displayed if an error occurs in the target servlet. Is this correct or have I misunderstood: SRV.9.9.2 Error Pages The error page mechanism described does not intervene when errors occur in servlets invoked using the RequestDispatcher. In this way, a servlet using the RequestDispatcher to call another servlet has the opportunity to handle errors generated in the servlet it calls. Any help would be most appreciated. Cheers Hoos. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13430] - WWW-Authenticate Header Is Not Sent
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=13430. 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=13430 WWW-Authenticate Header Is Not Sent --- Additional Comments From [EMAIL PROTECTED] 2003-09-16 19:44 --- That workaround is easy for BASIC authentication but I'm using DIGEST and generating the WWW-Authenticate header is not trivial. And don't forget you can always forward or redirect to do custom authentication with either a JSP or a servlet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23203] New: - [PATCH] Documentation Update
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=23203. 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=23203 [PATCH] Documentation Update Summary: [PATCH] Documentation Update Product: Tomcat 4 Version: Unknown Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Sun's JDK was renamed to the J2SE SDK some time ago (http://servlet.java.sun.com/help/download#113, FAQ #7, part 2)--this updates the Running.txt file to specify that the J2SE SDK, and not the JDK, needs to be downloaded. (Reduces confusion over whether the SDK or just the JRE need be downloaded.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23203] - [PATCH] Documentation Update
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=23203. 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=23203 [PATCH] Documentation Update --- Additional Comments From [EMAIL PROTECTED] 2003-09-16 20:39 --- Created an attachment (id=8248) patch to running.txt (in root directory of jakarta-tomcat-4.0) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23204] New: - JVM Crash in Coyote HTTP Connector
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=23204. 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=23204 JVM Crash in Coyote HTTP Connector Summary: JVM Crash in Coyote HTTP Connector Product: Tomcat 4 Version: 4.1.27 Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We switched a large application from the Catalina HttpConnector to the CoyoteConnector over the weekend. Since then, we've had 3 JVM crashes, one with no stack trace, the other two with the following info: Unexpected Signal : 11 occurred at PC=0xFE1A1F4C Function=[Unknown. Nearest: JVM_GetCPClassNameUTF+0xFA70] Library=/usr/local/j2sdk1.4.1_03/jre/lib/sparc/server/libjvm.so Current Java thread: at org.apache.coyote.http11.InternalOutputBuffer.endRequest(InternalOutp utBuffer.java:379) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java: 536) at org.apache.coyote.Response.action(Response.java:222) at org.apache.coyote.Response.finish(Response.java:343) at org.apache.coyote.tomcat4.OutputBuffer.close(OutputBuffer.java:326) at org.apache.coyote.tomcat4.CoyoteWriter.close(CoyoteWriter.java:132) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationD ispatcher.java:453) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDis patcher.java:356) at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor. java:1069) at org.apache.struts.action.RequestProcessor.processForwardConfig(Reques tProcessor.java:455) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.ja va:279) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:148 0) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:506) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:193) at com.nmatrix.webapp.filter.LoggingFilter.doFilter(LoggingFilter.java:1 10) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex t.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav a:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex t.invokeNext(StandardPipeline.java:643) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica torBase.java:550) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex t.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav a:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java: 2415) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j ava:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex t.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatche rValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex t.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex t.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav a:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex t.invokeNext(StandardPipeline.java:643)
DO NOT REPLY [Bug 23204] - JVM Crash in Coyote HTTP Connector
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=23204. 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=23204 JVM Crash in Coyote HTTP Connector [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-09-16 21:29 --- [Be warned, this may sound harsh but is not meant to be] The Coyote connectors are pure java code. If the JVM crashes (core dump) then the JVM is faulty. According to your OS vendor, make sure you have the correct JDK version patch level as well as appropriate OS patches. Sun's bug parade is also very helpful in situations like this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23204] - JVM Crash in Coyote HTTP Connector
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=23204. 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=23204 JVM Crash in Coyote HTTP Connector --- Additional Comments From [EMAIL PROTECTED] 2003-09-16 21:36 --- Especially, make sure you have all kernel patches applied when running under Solaris, as it is vital for JVM stability (and there are quite a few of them, even for Solaris 9). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18967] - NullPointerException instead of error message when running JspC
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=18967. 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=18967 NullPointerException instead of error message when running JspC --- Additional Comments From [EMAIL PROTECTED] 2003-09-16 22:11 --- I also have had issues with this bug - it is very difficult to fix a problem without the error message! I fixed it in my copy by modifying the interface to Compiler to pass all the generate phases through the compile() method, which I modified to take a parameter specifying generation type. This is probably not a solution in general due to the public interface change. However, the creation of the ErrorReporter needs to be done so that it is available no matter which method is called. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Do not email me. Remove me.
Do not email me. Remove me.
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, September 16, 2003 11:56 AM
Subject: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core
ApplicationHttpRequest.java
luehe 2003/09/16 11:56:35
Modified:catalina/src/share/org/apache/catalina/core
ApplicationHttpRequest.java
Log:
Fixed Bugtraq 4923455 (Sessions created in the target webapp of a
cross-context are invalid)
Revision ChangesPath
1.13 +5 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/Applicat
ionHttpRequest.java
Index: ApplicationHttpRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/cor
e/ApplicationHttpRequest.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- ApplicationHttpRequest.java 31 Aug 2003 21:08:55 - 1.12
+++ ApplicationHttpRequest.java 16 Sep 2003 18:56:35 - 1.13
@@ -545,6 +545,7 @@
if (localSession == null) {
localSession =
context.getManager().createEmptySession();
localSession.setId(other.getId());
+localSession.setValid(true);
}
session = localSession.getSession();
return session;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Do not email me. Remove me.
Do not email me. Remove me from your mail list.
IMPORTANT:
Please make sure to provide previous correspondences with www.cmttrading.com
so we may better assist you with your inquiries.
Be sure to check out our new Car Audio Superstore at www.gotcmt.com.
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, September 16, 2003 10:46 AM
Subject: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler
Generator.java Node.java SmapStratum.java SmapUtil.java
kinman 2003/09/16 10:46:44
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Node.java SmapStratum.java SmapUtil.java
Log:
- For template texts that generate multiple Java lines, addidtional
mapping
informantion are kept in the TemplateText node, to aide SMAP
generation.
Revision ChangesPath
1.208 +23 -14
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.207
retrieving revision 1.208
diff -u -r1.207 -r1.208
--- Generator.java 15 Sep 2003 13:43:54 - 1.207
+++ Generator.java 16 Sep 2003 17:46:43 - 1.208
@@ -1867,21 +1867,25 @@
return;
}
-if (ctxt.getOptions().genStringAsCharArray()) {
-if (textSize = 3) {
- // Spcial case small text strings
- n.setBeginJavaLine(out.getJavaLine());
- out.printil(out.write( + quote(text.charAt(0)) +
););
- if (textSize 1) {
- out.printil(out.write( + quote(text.charAt(1))
+ ););
+if (textSize = 3) {
+ // Special case small text strings
+ n.setBeginJavaLine(out.getJavaLine());
+ int lineInc = 0;
+ for (int i = 0; i textSize; i++) {
+ char ch = text.charAt(i);
+ out.printil(out.write( + quote(ch) + ););
+ if (i 0) {
+ n.addSmap(lineInc);
}
- if (textSize 2) {
- out.printil(out.write( + quote(text.charAt(2))
+ ););
+ if (ch == '\n') {
+ lineInc++;
}
- n.setEndJavaLine(out.getJavaLine());
- return;
}
+ n.setEndJavaLine(out.getJavaLine());
+ return;
+ }
+if (ctxt.getOptions().genStringAsCharArray()) {
// Generate Strings as char arrays, for performance
ServletWriter caOut;
if (charArrayBuffer == null) {
@@ -1915,6 +1919,7 @@
StringBuffer sb = new StringBuffer(out.write(\);
int initLength = sb.length();
int count = JspUtil.CHUNKSIZE;
+int srcLine = 0; // relative to starting srouce line
for (int i = 0; i text.length(); i++) {
char ch = text.charAt(i);
--count;
@@ -1930,6 +1935,7 @@
break;
case '\n' :
sb.append('\\').append('n');
+srcLine++;
if (breakAtLF || count 0) {
// Generate an out.write() when see a '\n'
in template
@@ -1940,6 +1946,9 @@
}
sb.setLength(initLength);
count = JspUtil.CHUNKSIZE;
+
+// add a Smap for this line
+n.addSmap(srcLine);
}
break;
case '\t' : // Not sure we need this
1.77 +24 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java
Index: Node.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler
/Node.java,v
retrieving revision 1.76
retrieving revision 1.77
diff -u -r1.76 -r1.77
--- Node.java 2 Sep 2003 21:39:59 - 1.76
+++ Node.java 16 Sep 2003 17:46:43 - 1.77
@@ -63,6 +63,7 @@
import java.util.Iterator;
import java.util.List;
import java.util.Vector;
+import java.util.ArrayList;
import javax.servlet.jsp.tagext.BodyTag;
import javax.servlet.jsp.tagext.DynamicAttributes;
@@ -1921,6 +1922,8 @@
*/
public static class TemplateText extends Node {
+private ArrayList
Do not email me. Remove me from your mail list.
Do not email me. Remove me from your mail list. IMPORTANT: Please make sure to provide previous correspondences with www.cmttrading.com so we may better assist you with your inquiries. Be sure to check out our new Car Audio Superstore at www.gotcmt.com. - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, September 16, 2003 10:46 AM Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties Kin-Man Chung wrote: I think keeping an array (in the Template node) of the source line that corresponds to each of the Java line we generate is probably enough. I'll commit some codes today and you'll see what I mean. There are reasons for not doing SMAP generation in Generator. Generator is already the biggest module in Jasper, and I'd like not to make it any more complicated. Also, some codes are generated out of order, in buffers that got appended at the end of generating the main method, so that the mappings cannot be determined when codes are generated. SMAP generation is one of the area that does not got enough test and use. You seem to be one of the few who actually look at it. Are you doing anything with it? Given the number of bug reports which have been filed against that single feature, I can assert this is not the case. You should rewrite your sentence as SMAP generation is one of the area that does not get enough test and use among Tomcat committers ;-) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Do not email me. Remove me from your mail list.
Do not email me. Remove me from your mail list.
IMPORTANT:
Please make sure to provide previous correspondences with www.cmttrading.com
so we may better assist you with your inquiries.
Be sure to check out our new Car Audio Superstore at www.gotcmt.com.
- Original Message -
From: Kin-Man Chung [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, September 16, 2003 10:34 AM
Subject: Re: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources
messages.properties
Date: Mon, 15 Sep 2003 22:57:32 -0700
From: Eric Carmichael [EMAIL PROTECTED]
Subject: Re: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources
messages.properties
X-Originating-IP: [64.203.49.21]
To: Tomcat Developers List [EMAIL PROTECTED]
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Priority: 3
X-MSMail-priority: Normal
X-Originating-Email: [EMAIL PROTECTED]
X-OriginalArrivalTime: 16 Sep 2003 05:57:41.0966 (UTC)
FILETIME=[7112DEE0:01C37C17]
But this also shows that tight coupling between Generator and SmapUtil
is
flagile and error prone. I think it would be a better design if we
decouple these two modules somehow. We could create additional data
structure that captures the mapping info for template texts, with
Generator
its producer and SmapUtil its comsumer. What do you think? I'll
think about this more.
I thought about this a bit when I was copying the line feed logic from
Generator.java to SmapUtil.java to fix the line mappings for template
text
nodes, because I didn't like duplicating code, but I didn't see an
alternative except to move the SMAPping into Generator. How would your
producer/consumer approach differ from that? If a data structure that
captures mapping info is what's needed, we already have SmapStratum
performing that function, so I don't see much difference between having
Generator produce a new mapping info data structure and just having
Generator produce the SMAP directly.
I think keeping an array (in the Template node) of the source line that
corresponds to each of the Java line we generate is probably enough. I'll
commit some codes today and you'll see what I mean.
There are reasons for not doing SMAP generation in Generator. Generator
is
already the biggest module in Jasper, and I'd like not to make it any more
complicated. Also, some codes are generated out of order, in buffers that
got appended at the end of generating the main method, so that the
mappings
cannot be determined when codes are generated.
SMAP generation is one of the area that does not got enough test and use.
You seem to be one of the few who actually look at it. Are you doing
anything
with it?
-Kin-man
BTW, the reason for if (textSize = 3) is for performance
optimization.
out.write('\n') should be faster than out.write(\n) so it's OK
that
you move into the if (ctxt.getOptions().genStringAsCharArray())
block,
for now; but it should really be applied in all cases. Maybe we can
write all out.write()'s in a single line, so that the mapping is not
changed? Or we can revisit this later.
Yeah, I didn't know if putting if (textSize = 3) outside the if
(ctxt.getOptions().genStringAsCharArray()) block was intentional or
not,
which is why I was hesitant to commit my fix. Thanks for clarifying. I
don't have a problem changing the SMAPs as long as we don't break them,
so
do whatever you think best on the Generator side, and I'll just try to
make
sure to check for SMAP regressions before the next release.
Eric
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Do not email me. Remove me from your mail list.
Do not email me. Remove me from your mail list. - Original Message - From: Kin-Man Chung [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 16, 2003 11:01 AM Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties I know, I know. I plead guilty as charged. :-) Unfortunately, not having a debugger that uses SMP, it is hard to automate SMAP testing. You pretty much has to manually eyeball the files to verify its correctness. I think netbeans is planning to use tomcat 5 for its next major, so we'll expect more use there. -Kin-man Date: Tue, 16 Sep 2003 19:46:19 +0200 From: Remy Maucherat [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties To: Tomcat Developers List [EMAIL PROTECTED] Kin-Man Chung wrote: I think keeping an array (in the Template node) of the source line that corresponds to each of the Java line we generate is probably enough. I'll commit some codes today and you'll see what I mean. There are reasons for not doing SMAP generation in Generator. Generator is already the biggest module in Jasper, and I'd like not to make it any more complicated. Also, some codes are generated out of order, in buffers that got appended at the end of generating the main method, so that the mappings cannot be determined when codes are generated. SMAP generation is one of the area that does not got enough test and use. You seem to be one of the few who actually look at it. Are you doing anything with it? Given the number of bug reports which have been filed against that single feature, I can assert this is not the case. You should rewrite your sentence as SMAP generation is one of the area that does not get enough test and use among Tomcat committers ;-) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Do not email me. Remove me.
On Tue, 16 Sep 2003, www.cmttrading.com wrote: Date: Tue, 16 Sep 2003 16:01:27 -0700 From: www.cmttrading.com [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Do not email me. Remove me. Do not email me. Remove me. Handled. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
SMAP generation is one of the area that does not got enough test and use. You seem to be one of the few who actually look at it. Are you doing anything with it? Nope. Just trying to make myself useful. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
Unfortunately, not having a debugger that uses SMP, it is hard to automate SMAP testing. You pretty much has to manually eyeball the files to verify its correctness. I think netbeans is planning to use tomcat 5 for its next major, so we'll expect more use there. In the wake of Bugzilla #22277, I wrote some tests that compare the HTML and SMAP produced by various JSPs to a previously established baseline (like I believe ant run-tester does with HTML). Great for picking up on regressions (that's how I caught the small text string problem), but of course the disadvantage is that they also complain about perfectly valid changes, and manually eyeballing the files is the only way to tell the difference. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
