cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk aphowto.xml
hgomez 2003/01/07 01:49:12 Modified:jk/xdocs/jk aphowto.xml Log: Add build notes for MacOS/X Revision ChangesPath 1.19 +22 -0 jakarta-tomcat-connectors/jk/xdocs/jk/aphowto.xml Index: aphowto.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/aphowto.xml,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- aphowto.xml 30 Dec 2002 14:16:54 - 1.18 +++ aphowto.xml 7 Jan 2003 09:49:12 - 1.19 @@ -863,6 +863,28 @@ /p /section +section name=Building mod_jk for Apache on MacOS/X +p +Mac OS X (10.2.x) build notes : +/p +p +Assuming that you are root : +/p +screen +noteFor Apache 1.3:/note +type./configure --with-apxs=/usr/sbin/apxs/type +typecd apache-1.3/type +typemake -f Makefile.apxs/type +typecp mod_jk.so /etc/libexec/httpd/type + +noteFor Apache 2.0:/note +type./configure --with-apxs=/usr/local/apache2/bin/apxs/type +note(you should point to the directory where you installed Apache 2.0)/note +typecd apache-2.0/type +typemake -f Makefile.apxs install/type +/screen +/section + section name=Getting mod_jk linked statically with Apache p mod_jk allows to install mod_jk in the Apache source tree to get a statically -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15819] - Duplicate context listener entries in server.xml when saving
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=15819. 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=15819 Duplicate context listener entries in server.xml when saving --- Additional Comments From [EMAIL PROTECTED] 2003-01-07 10:22 --- Yes - I have remove my DefaultContext and the problem no longer occurs. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] forward instead of redirect for welcome files
Matt Parker wrote: If you want to mirror what Apache HTTPD does: No slash present -- append slash (only!) and redirect Slash present -- internally forward to welcome-file page Well, here's the rub: - The new servlet spec clearly states that either /foo or /foo/ should return a welcome-file (if specified) Well, this is broken behavior. If no slash, then a redirect will be sent back to the client, otherwise, relative paths are not resolved correctly, with no way for the app writer to anticipate it. - Apache also has the problem with a relative link on a welcome file which has a directory specified in it However, I think that the patch benefits still outweigh its drawbacks: - it satisfies the new servlet spec - it circumvents the need for special processing and configuration when placed behind a proxy server (a farely common production practice). - it inherits a problem, but the problem is probably rare in practice, and will already have been avoided by Apache users since it's the same. i.e. i've never had a burning need to specify a welcome file or directory index that has a subdirectory in it _and_ has a relative link, so i can only guess that others either don't or already know to avoid it. What do y'all think? I vote +1 :) I'll vote the opposite ;-) People are used to the bahavior in 4.1. In 5.0, I plan to add the option for internal forwards in the new mapper I'll write. Note that internal forwards were used in early 4.0 releases, but went away as it got reported as a security issue (the security checks apply to the original URI, not the served welcome file). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] forward instead of redirect for welcome files
Matt Parker wrote: Here's the new version of the patch. the code to redirect if there is no trailing slash remains untouched, but it now forwards if there is a trailing slash. i've included more context to avoid potential confusion: I'll -1 this patch unless the new behavior is made optional (and default to the current behavior). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15834] New: - Version 2.0.2 von JK2 does not work in Win2k
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=15834. 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=15834 Version 2.0.2 von JK2 does not work in Win2k Summary: Version 2.0.2 von JK2 does not work in Win2k Product: Tomcat 4 Version: 4.1.18 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, I tried to set up Apache v 2.0.43 with Tomcat 2.1.18 wich worked fine. Than I wanted to clue them together using JK2 v 2.0.2, where I downloaded the binary from the main distribution site. I did as it was explained in the docs, wich is really easy, thanks for that. But it didnt work. I always got the error message, that it could not connect to tomcat. Then I tried JK2 v 2.0.1 and it worked at once. Thus, I would think that it is a bug in v 2.0.2. Thank you very much for providing this Apache-Tomcat connectivity. Yours Thomas Janke -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: where to download tomcat 4.1 nightly builds?
Thanks both, Kevin Jones Developmentor www.develop.com -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 06 January 2003 18:26 To: Tomcat Developers List Subject: Re: where to download tomcat 4.1 nightly builds? Petr Jiricka wrote: I was able to find them for Tomcat 5: http://jakarta.apache.org/builds/jakarta-tomcat/nightly-5/ but not for Tomcat 4.1. Speaking of 5.0, is it known when the next milestone/beta of Tomcat 5 will be released ? Is there any scheduled ? Features are being added, so it got delayed. Tomcat 5 is supposed to be very easy to build from CVS (http://jakarta.apache.org/tomcat/building.html), so IMO there's little point in having nightly builds. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [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: Unable to compile class for JSP
I've used 4.1.x and 4.0.x with JDK1.4 and JDK 1.4.1 and never had this problem. One thing you might want to check on windows is which JRE you are using. Sun install Java in two places, c:\j2sdk1.4.1 and c:\winnt\java (or something similar). By default the JRE is set in the registry to be c:\winnt\java and java.exe is copied to c:\winnt\system32. So unless you either choose not to install the JRE, or you delete java.exe from c:\winnt\system32 when you run java, the JRE picked up is the one installed into c:\winnt and this one doesn't have a tools.jar. Delete java.exe from c:\winnt\system32, set java_home to c:\j2sdk1.4.1 and add c:\j2sdk1.4.1\bin to your path, then try it again Kevin Jones Developmentor www.develop.com -Original Message- From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Costin Manolache Sent: 07 January 2003 00:53 To: [EMAIL PROTECTED] Subject: Re: Unable to compile class for JSP Jeanfrancois Arcand wrote: Hum...I don't have any problems under win2k using Sun JDK 1.4.1 (and I don't remember seeing that problem with 1.4). Have you try with 1.4.1? I will downgrade and see No, I'm just happy that I found the trick to make it work. ( I only tested tomcat4.1 with JDK1.4.0-b92 on w2k and xp ) Costin -- Jeanfrancois Costin Manolache wrote: Just had the same problem - it seems JDK1.4 on windows has an interesting behavior - it will not load javac from tools.jar unless it is included in endorsed. I'm not a big windows user - if someone could confirm, we need to change the scripts. I see this behavior with (at least) 1.4.0-b92. Costin Gary Pollreis wrote: will do - thanks for the heads up. -Original Message- From: Matt Parker [mailto:[EMAIL PROTECTED]] Sent: Monday, January 06, 2003 5:57 PM To: Tomcat Developers List Subject: Re: Unable to compile class for JSP you should post this to the tomcat-users list. this list is for issues related to development on the tomcat product. On Mon, 2003-01-06 at 16:48, Gary Pollreis wrote: I have just installed Tomcat 4.1.18 under Windows 2000 (using Java JDK 1.4.0). When I try to run the examples I get org.apache.jasper.JasperException: Unable to compile class for JSP . I have validated that my JAVA_HOME and CATALINA_HOME environment variables are correct. Any/all help would be appreciated. Thanks in advance. -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14261] - JNDI data source not configured correctly.
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=14261. 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=14261 JNDI data source not configured correctly. --- Additional Comments From [EMAIL PROTECTED] 2003-01-07 14:36 --- This bug seems to be due to the fact that the JNDI resource config is located in the GlobalNamingResources. When the data source config is put in the Context, it seems to work. I haven't had a chance to check the source code, but I suspect there is something amiss in the global resource configs. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] forward instead of redirect for welcome files
On Tue, 2003-01-07 at 04:40, Remy Maucherat wrote:
I'll -1 this patch unless the new behavior is made optional (and default
to the current behavior).
Remy
Okay, it's now an init param which defaults to false. Following are
DefaultServlet.java and web.xml patches.
--- DefaultServlet.java.orig2003-01-07 08:41:16.0 -0700
+++ DefaultServlet.java 2003-01-07 08:42:33.0 -0700
@@ -169,6 +169,10 @@
*/
protected String welcomes[] = new String[0];
+/**
+ * Should we redirect or forward for welcome files?
+ */
+protected boolean forwardWelcomeFiles = false;
/**
* MD5 message digest provider.
@@ -294,6 +298,13 @@
} catch (Throwable t) {
;
}
+try {
+value =
getServletConfig().getInitParameter(forwardWelcomeFiles);
+if (value != null)
+forwardWelcomeFiles = (new
Boolean(value)).booleanValue();
+} catch (Throwable t) {
+;
+}
// Sanity check on the specified buffer sizes
if (input 256)
@@ -957,11 +968,16 @@
if (welcomeFileInfo != null) {
String redirectPath = welcomeFileInfo.path;
String contextPath = request.getContextPath();
-if ((contextPath != null)
(!contextPath.equals(/))) {
+if ((contextPath != null) (!contextPath.equals(/))
(!forwardWelcomeFiles)) {
redirectPath = contextPath + redirectPath;
}
redirectPath = appendParameters(request, redirectPath);
-response.sendRedirect(redirectPath);
+if (forwardWelcomeFiles) {
+
request.getRequestDispatcher(redirectPath).forward(request, response);
+}
+else {
+ response.sendRedirect(redirectPath);
+}
return;
}
--- web.xml.orig2003-01-07 08:58:09.0 -0700
+++ web.xml 2003-01-07 08:50:13.0 -0700
@@ -39,6 +39,9 @@
!-- readonlyIs this context read only, so
HTTP --
!-- commands like PUT and DELETE
are --
!-- rejected?
[true] --
+
!-- --
+ !-- forwardWelcomeFiles Should welcome files be forwarded
instead --
+ !-- of being redirected?
[false] --
servlet
servlet-namedefault/servlet-name
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15845] New: - Memory Leak when compiling JSP
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=15845. 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=15845 Memory Leak when compiling JSP Summary: Memory Leak when compiling JSP Product: Tomcat 4 Version: 4.1.14 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] when accessing lots of uncompiled jsp pages Jasper leaks memory. I have found a temporary solution but am sure it is not good. if you always force the JspCompilationContext to use a new Compiler when getCompiler() is called the leak goes away. When profiling Jasper the problem was that the JspCompilationContext, JspServletWrapper, JspRuntimeContext, and the Compiler never got gced because they where never dereferenced. by forcing a new compiler each time it seems to solve this problem but not sure what others it could cause. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] forward instead of redirect for welcome files
On Tue, 2003-01-07 at 04:39, Remy Maucherat wrote: Matt Parker wrote: If you want to mirror what Apache HTTPD does: No slash present -- append slash (only!) and redirect Slash present -- internally forward to welcome-file page Well, here's the rub: - The new servlet spec clearly states that either /foo or /foo/ should return a welcome-file (if specified) Well, this is broken behavior. If no slash, then a redirect will be sent back to the client, otherwise, relative paths are not resolved correctly, with no way for the app writer to anticipate it. That's true. Although I think it would still satisfy the spec to redirect /foo to /foo/index.html, but would a redirect from /foo to /foo/, and then forward to /foo/index.html still satisfy it? Maybe I'm being too pedantic. The actual text reads: A request URI of /foo or /foo/ will be returned as /foo/index.html What do y'all think? I vote +1 :) I'll vote the opposite ;-) People are used to the bahavior in 4.1. In 5.0, I plan to add the option for internal forwards in the new mapper I'll write. Note that internal forwards were used in early 4.0 releases, but went away as it got reported as a security issue (the security checks apply to the original URI, not the served welcome file). Remy I hear ya. Didn't mean to be cute. Could the security check be applied after the welcome file was resolved? Or is that going to be done in your mapper? Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JK 1.2.2 need Windows binaries
I just take a look and see that jk 1.2.2 release miss a binary for Windows (Apache 1.3.x/2.0). Nacho ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13924] - error-page directive does not always work correctly
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=13924. 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=13924 error-page directive does not always work correctly --- Additional Comments From [EMAIL PROTECTED] 2003-01-07 17:55 --- This sounds a lot like what I reported a while back (not the wrapping thing, but the servlet vs. JSP thing): http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7371 There's another test case there. We are still using 4.0.1 so it still fails for me. I have no clue WHY it works when thrown from a JSP, but not from a servlet; it just doesnt :) Hell, I'd be happy to start looking at the Tomcat source if someone wants to shove me in the right direction. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jasper and big jsp files ( not working !! )
Hi all, I have a problem with both Jasper and Jasper2. If I have a huge piece of HTML inserted between two statements, the generated out.println() on the compiled code outputs just the first 8192 characters. I tried to play with the 'largefile' option in the /conf/web.xml: servlet servlet-namejsp/servlet-name servlet-classorg.apache.jasper.servlet.JspServlet/servlet-class init-param param-namelogVerbosityLevel/param-name param-valueWARNING/param-value /init-param init-param param-namelargefile/param-name param-valuetrue/param-value /init-param load-on-startup3/load-on-startup /servlet and it does not work either. I'm using Tomcat 4.1.18 with Jasper2. Thanks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15851] New: - Parser generates a NullPointerException for invalid use case of jsp:attribute instead of a useful message.
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=15851. 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=15851 Parser generates a NullPointerException for invalid use case of jsp:attribute instead of a useful message. Summary: Parser generates a NullPointerException for invalid use case of jsp:attribute instead of a useful message. Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Consider the following fragment which is supposed to generate a translation-time error: jsp:attribute jsp:attribute name=name someattr /jsp:attribute jsp:body someattrvalue /jsp:body /jsp:attribute According to the specification, if a jsp:attribute standard action is nested within another jsp:attribute standard action, a translation error must occur. In this case, a translation error does occur, but for the wrong reason. Here is the resulting cause: stacktrace java.lang.NullPointerException at org.apache.jasper.compiler.Parser.getAttributeBodyType(Parser.java:1736) at org.apache.jasper.compiler.Parser.parseNamedAttributes(Parser.java:1710) at org.apache.jasper.compiler.Parser.parseJspAttributeAndBody(Parser.java:1045) at org.apache.jasper.compiler.Parser.parseOptionalBody(Parser.java:1017) at org.apache.jasper.compiler.Parser.parseCustomTag(Parser.java:1313) at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1458) at org.apache.jasper.compiler.Parser.parse(Parser.java:164) /stacktrace -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
FW: documentation error
Not acked... FYI... Pier -- Forwarded Message From: Stoffer, Shawn D [EMAIL PROTECTED] Date: Tue, 7 Jan 2003 11:55:11 -0700 To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: documentation error I wished to point out that in the jakarta/tomcat documentation, there is an error. Under server configuration reference, Host (webapps\tomcat-docs\config\host.html), it shows, under the section heading request filters, an example of using the valve xml tag for the server.xml configuration file. Host name=localhost ... ... Valve className=org.apache.catalina.valves.RemoteHostValve allow=*.mycompany.com,www.yourcompany.com/ Valve className=org.apache.catalina.valves.RemoteAddrValve deny=192.168.1.*/ ... /Host The problem is in the regular expression, it should read: Host name=localhost ... ... Valve className=org.apache.catalina.valves.RemoteHostValve allow=\w*.mycompany.com,www.yourcompany.com/ Valve className=org.apache.catalina.valves.RemoteAddrValve deny=192.168.1.\d*/ ... /Host Without the '\w' and the '\d' the server will not start, as the regular expression engine will throw an exception. Excellent job, else, guys! Thanks, Shawn Stoffer Stoffer, Shawn D.vcf -- End of Forwarded Message Stoffer, Shawn D.vcf Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper and big jsp files ( not working !! )
Hi, i have reported this as a bug before, see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14359 for more details, but i have no real solution for this now. Is this also your problem? One workaround may be to split the jsp files and include the content by a jsp:include? Holger - Original Message - From: webmaster [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 07, 2003 7:38 PM Subject: Jasper and big jsp files ( not working !! ) Hi all, I have a problem with both Jasper and Jasper2. If I have a huge piece of HTML inserted between two statements, the generated out.println() on the compiled code outputs just the first 8192 characters. I tried to play with the 'largefile' option in the /conf/web.xml: servlet servlet-namejsp/servlet-name servlet-classorg.apache.jasper.servlet.JspServlet/servlet-class init-param param-namelogVerbosityLevel/param-name param-valueWARNING/param-value /init-param init-param param-namelargefile/param-name param-valuetrue/param-value /init-param load-on-startup3/load-on-startup /servlet and it does not work either. I'm using Tomcat 4.1.18 with Jasper2. Thanks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15854] New: - Unable to provide a qname attribute value to the name attribute of the jsp:attribute action.
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=15854. 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=15854 Unable to provide a qname attribute value to the name attribute of the jsp:attribute action. Summary: Unable to provide a qname attribute value to the name attribute of the jsp:attribute action. Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] According to table JSP.5-8, in particular the section regarding the 'name' attribute: The value of name can be a QName. If so, the prefix must match that of the action it applies to, So given the following: some:action jsp:attribute name=some:attributename attributevalue /jsp:attribute /some:action The following error is incorrectly returned: error /JspAttributeQNameTest1.jsp(9,0) According to the TLD attribute attributename is mandatory for tag action /error -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Error page declarations interacting with servlets
I first noticed about 10 months ago, when I filed bug 7371, that for some reason the error-page's that I declared in my web.xml were working fine from JSP's but not from servlets. That bug was closed, because it worked in the tests. Tomcat 4.0.1: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7371 Then someone posted something similar, about how when certain exceptions are thrown from servlets instead of JSP's, the Exception report is displayed instead of the error-page (this bug is still outstanding). This was filed for Tomcat 4.1.12: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13924 And as recently as December 14th there is evidence someone is having the same problem still, with Tomcat 4.0.4: http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg38168.html I am just trying to generate critical mass for hunting this down. I posted a test case on 7371, and there was also a test case posted on 13924. My test case works as expected in Resin but not in Tomcat 4.0.1 This is very problematic for us, as users of our system are seeing stacktraces instead of our custom error pages. Thanks for any assistance. John -- 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/runtime JspRuntimeLibrary.java
luehe 2003/01/07 12:47:27
Modified:jasper2/src/share/org/apache/jasper/runtime
JspRuntimeLibrary.java
Log:
Undid change that leveraged org.apache.jasper.compiler.ErrorDispatcher,
since this change would have required duplication of a lot of the class files
of jasper-compiler.jar in jasper-runtime.jar
Revision ChangesPath
1.14 +38 -31
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java
Index: JspRuntimeLibrary.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- JspRuntimeLibrary.java6 Jan 2003 18:57:15 - 1.13
+++ JspRuntimeLibrary.java7 Jan 2003 20:47:27 - 1.14
@@ -80,8 +80,8 @@
import javax.servlet.jsp.JspWriter;
import javax.servlet.jsp.tagext.BodyContent;
+import org.apache.jasper.Constants;
import org.apache.jasper.JasperException;
-import org.apache.jasper.compiler.ErrorDispatcher;
// for JSTL expression interpreter
import javax.servlet.jsp.PageContext;
@@ -100,12 +100,6 @@
*/
public class JspRuntimeLibrary {
-private static ErrorDispatcher err;
-
-static {
- err = new ErrorDispatcher();
-}
-
protected static class PrivilegedIntrospectHelper
implements PrivilegedExceptionAction {
@@ -288,7 +282,7 @@
t, propertyName, s);
}
} catch (Exception ex) {
-throw new JasperException (ex);
+throw new JasperException(ex);
}
}
// __end convertMethod
@@ -354,7 +348,9 @@
if ( method != null ) {
if (type.isArray()) {
if (request == null) {
-err.jspError(jsp.error.beans.setproperty.noindexset);
+ throw new JasperException(Constants.getString(
+jsp.error.beans.setproperty.noindexset,
+ new Object[] {}));
}
Class t = type.getComponentType();
String[] values = request.getParameterValues(param);
@@ -375,15 +371,18 @@
}
}
} catch (Exception ex) {
- throw new JasperException (ex);
+ throw new JasperException(ex);
}
if (!ignoreMethodNF (method == null)) {
if (type == null) {
-err.jspError(jsp.error.beans.noproperty,
- prop, bean.getClass().getName());
+ throw new JasperException(Constants.getString(
+jsp.error.beans.noproperty,
+ new Object[] { prop, bean.getClass().getName() }));
} else {
- err.jspError(jsp.error.beans.nomethod.setproperty,
- prop, type.getName(), bean.getClass().getName());
+ throw new JasperException(Constants.getString(
+jsp.error.beans.nomethod.setproperty,
+ new Object[] { prop, type.getName(),
+bean.getClass().getName() }));
}
}
}
@@ -611,8 +610,9 @@
// __begin lookupReadMethodMethod
public static Object handleGetProperty(Object o, String prop)
throws JasperException {
-if (o == null){
-err.jspError(jsp.error.beans.nullbean);
+if (o == null) {
+ throw new JasperException(Constants.getString(
+ jsp.error.beans.nullbean, new Object[] {}));
}
Object value = null;
try {
@@ -794,19 +794,23 @@
}
} else {
// just in case introspection silently fails.
-err.jspError(jsp.error.beans.nobeaninfo,
- beanClass.getName());
+throw new JasperException(Constants.getString(
+ jsp.error.beans.nobeaninfo,
+ new Object[] { beanClass.getName() }));
}
} catch (Exception ex) {
throw new JasperException (ex);
}
if (method == null) {
if (type == null) {
-err.jspError(jsp.error.beans.noproperty,
- prop, beanClass.getName());
+ throw new JasperException(Constants.getString(
+jsp.error.beans.noproperty,
+ new Object[] { prop, beanClass.getName() }));
} else {
-err.jspError(jsp.error.beans.nomethod.setproperty,
- prop, type.getName(),
Re: Jasper and big jsp files ( not working !! )
Hi, I guess my problem is a little bit different. I don't see the exception in the error log and when I put something like: % !-- here goes my code -- % html bodylots of html... more than 8192 charaters/body /html Jasper compiles the file and the out.println(html...) line is trimmed in 8192 characters... :(( On Tue, 7 Jan 2003 20:15:22 +0100, Holger Brozio [EMAIL PROTECTED] escreveu : De: Holger Brozio [EMAIL PROTECTED] Data: Tue, 7 Jan 2003 20:15:22 +0100 Para: Tomcat Developers List [EMAIL PROTECTED] Assunto: Re: Jasper and big jsp files ( not working !! ) Hi, i have reported this as a bug before, see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14359 for more details, but i have no real solution for this now. Is this also your problem? One workaround may be to split the jsp files and include the content by a jsp:include? Holger - Original Message - From: webmaster [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 07, 2003 7:38 PM Subject: Jasper and big jsp files ( not working !! ) Hi all, I have a problem with both Jasper and Jasper2. If I have a huge piece of HTML inserted between two statements, the generated out.println() on the compiled code outputs just the first 8192 characters. I tried to play with the 'largefile' option in the /conf/web.xml: servlet servlet-namejsp/servlet-name servlet-classorg.apache.jasper.servlet.JspServlet/servlet-class init-param param-namelogVerbosityLevel/param-name param-valueWARNING/param-value /init-param init-param param-namelargefile/param-name param-valuetrue/param-value /init-param load-on-startup3/load-on-startup /servlet and it does not work either. I'm using Tomcat 4.1.18 with Jasper2. Thanks -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mod_jk: feature disabling sticky sessions
Hello, will be in future added into mod_jk option to disable sticky sessions but with sessions working? Thank's a lot David Klimek -- http://www.sweb.cz/david.klimek -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15863] New: - An NPE occurs in Jasper2's parser when the body of jsp:attribute is empty.
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=15863. 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=15863 An NPE occurs in Jasper2's parser when the body of jsp:attribute is empty. Summary: An NPE occurs in Jasper2's parser when the body of jsp:attribute is empty. Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] According to the JSP 2.0 specicifcation, if the body of the jsp:attribute action is empty, it is the equivalent of specifying as the value of the attribute. When Jasper2 is provided such a scenario, an NPE occurs. Stacktrace below: stacktrace java.lang.NullPointerException at org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:825) at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1022) at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:1634) at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:1676) at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:1682) at org.apache.jasper.compiler.Node$Root.accept(Node.java:323) at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:1634) at org.apache.jasper.compiler.Validator.validate(Validator.java:1167) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:260) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:427) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:571) /stacktrace -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardServer.java
amyroh 2003/01/07 14:20:12 Modified:catalina/src/share/org/apache/catalina/core StandardServer.java Log: Fix bug 15819. Do not write out StandardDefaultContext Listener to server.xml. Revision ChangesPath 1.36 +5 -4 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardServer.java Index: StandardServer.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardServer.java,v retrieving revision 1.35 retrieving revision 1.36 diff -u -r1.35 -r1.36 --- StandardServer.java 6 Jan 2003 23:25:24 - 1.35 +++ StandardServer.java 7 Jan 2003 22:20:12 - 1.36 @@ -191,6 +191,7 @@ org.apache.catalina.authenticator.SSLAuthenticator, org.apache.catalina.core.NamingContextListener, org.apache.catalina.core.StandardContextValve, +org.apache.catalina.core.StandardDefaultContext, org.apache.catalina.core.StandardEngineValve, org.apache.catalina.core.StandardHostValve, org.apache.catalina.startup.ContextConfig, -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15872] New: - ContextManager: Error reading request, ignored - java.lang.ArrayIndexOutOfBoundsException
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=15872. 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=15872 ContextManager: Error reading request, ignored - java.lang.ArrayIndexOutOfBoundsException Summary: ContextManager: Error reading request, ignored - java.lang.ArrayIndexOutOfBoundsException Product: Tomcat 3 Version: 3.2.x Nightly Platform: Other OS/Version: Linux Status: NEW Severity: Blocker Priority: Other Component: Servlet AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Using Tomcat 3.2.4 (it is not a nightly build): Getting the following exception. It is blocking me for deveolping my application. Will be greateful if it is attended to urgently. Had a look at Bug #300, but there is no solution provided. Link mentioned (http://znutar.cortexity.com:/BugRatViewer/ShowReport/300 ) is also not working. Similar bug is Bug # 359, but no solution / workaround is given. 2003-01-08 20:18:39 - ContextManager: Error reading request, ignored - java.lang.ArrayIndexOutOfBoundsException at org.apache.tomcat.service.http.HttpRequestAdapter.parseHeaderFiled (HttpRequestAdapter.java:224) at org.apache.tomcat.service.http.HttpRequestAdapter.readHeaders (HttpRequestAdapter.java:205) at org.apache.tomcat.service.http.HttpRequestAdapter.readNextRequest (HttpRequestAdapter.java:140) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection (HttpConnectionHandler.java:198) at org.apache.tomcat.service.TcpWorkerThread.runIt (PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run (ThreadPool.java:501) at java.lang.Thread.run(Thread.java:479) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c
Glenn, On Mon, 06 Jan 2003 19:30:42 -0600, Glenn Nielsen [EMAIL PROTECTED] said: Thanks for reporting this. I have changed the code so that if there is no content only status codes = 400 are passed back through apache. The original patch was made so that when an error occurred at the Ajp13Processor layer it could propogated back to the browser correctly instead of a blank page being displayed. and it was a welcome fix (now, when Tomcat is being restarted, instead of the JSP being displayed as HTML, I can use a custom error page). Please test from a CVS build and let me know if this fixes the problem for you. I just updated mod_jk.c from CVS and the fix of only passing empty content errors = 400 seems to work in my quick testing. Thanks, Adi Aditya wrote: On 2 Jan 2003 12:58:58 -, [EMAIL PROTECTED] said: glenn 2003/01/02 04:58:58 Modified: jk/native/apache-1.3 mod_jk.c jk/native/apache-2.0 mod_jk.c Log: Make sure http errors are handled by Apache if not handled by Tomcat Revision Changes Path 1.34 +6 -1 jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c This fix seems to cause container form-based authentication to have problems - instead of the usual sequence of: 1) GET protected page - 302 to login page 2) GET login page - 200 retrieved 3) POST login page - 302 to protected page 4) GET protected page - 200 retrieved The *first* time I try to go to the protected page, instead of (4), I get: HTTP status 400 (invalid direct reference...) However, if I then try to get the protected page a *second* time, it works fine... reverting to a verison of mod_jk that does not include the below fix doesn't evidence this problem... Adi -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15819] - Duplicate context listener entries in server.xml when saving
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=15819. 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=15819 Duplicate context listener entries in server.xml when saving [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-01-07 23:45 --- Fixed. Should be available in the next release. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Iteration tags do not synchronize scripting variables after doStartTag
Dimitry: I still believe your patch is invalid, as it would amount to synchronizing AT_BEGIN and NESTED variables after calling doStartTag(). However, the spec explicitly mentions that for tag handlers implementing BodyTag, those variables must not be synchronized after doStartTag(), *only* after doInitBody(). When I run your example (without applying your patch), I get this result: doStartTag returns EVAL_BODY_INCLUDE null 2nd 3rd doStartTag returns EVAL_BODY_BUFFERED 1st 2nd 3rd The reason your are getting null in the case of doStartTag() returning EVAL_BODY_INCLUDE is that in this case, doInitBody() is not called, hence no synchronization. However, if doStartTag() returns EVAL_BODY_BUFFERED, doInitBody() is being called, and therefore synchronization does take place. Please let me know if you disagree. Jan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15863] - An NPE occurs in Jasper2's parser when the body of jsp:attribute is empty.
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=15863. 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=15863 An NPE occurs in Jasper2's parser when the body of jsp:attribute is empty. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15875] New: - Support global sharing of tag libraries
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=15875. 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=15875 Support global sharing of tag libraries Summary: Support global sharing of tag libraries Product: Tomcat 4 Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Being able to share a tag library globally for all the web applications running under Tomcat is something that is often desirable. Unfortunately, the way to do this currently in Tomcat is more complex than it should be. While the jar files associated with the taglibs to be shared can be shared in tomcat/shared/lib, the TLD mappings must be defined within the web.xml of every web application that wants to use that shared library. (defining the TLD mappings in tomcat/conf/web.xml does not currently work because Jasper only processes TLD mappings in the web.xml of the webapp) JSP 1.2 has simplified the use of tag libraries by supporting the auto discory of TLD mappings in jar files. One simply has to drop the tag-library's jar file at the proper location, and voila... the container will process any TLD contained in these jar files and record the proper mappings. It would really be nice if it were possible to do the same at the container (Tomcat) level. As suggested by Craig, this could be supported in the following way: Extend the search for TLDs inside a JAR file algorithm to work its way up the parent class loaders as well. That way, one can simply drop the jar files of tag libraries to be shared into tomcat/common/lib and they would be recognized without requiring any TLD mappings in any web.xml. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] Iteration tags do not synchronize scripting variables after doStartTag
Jan, I'm not agree. :) In accordance to spec JSP.10.2.2 (BodyTag): If EVAL_BODY_INCLUDE is returned, then evaluation happens as in IterationTag. The scripting variable synchronization is part of evaluation, isn't it? I think, if container doesn't synchronize scripting variables it explicitly conflicts with quoted requirement. On the other hand, if container synchronizes scripting variables after skipped invoke to doInitBody, it doesn't conflict with spec. Substantiation: Again JSP.10.2.2: If EVAL_BODY_INCLUDE is returned, setBodyContent() is not invoked, doInitBody() is not invoked, the body is evaluated and passed through to the current out, doAfterBody() is invoked and then, after zero or more iterations, doEndTag() is invoked. There is nothing about skipping variable synchronization. And JSP.10.5.9: The scope value for a variable implies what methods may affect its value and thus where synchronization is needed: - for NESTED, after doInitBody and doAfterBody for a tag handler implementing BodyTag, and after doStartTag otherwise. - for AT_BEGIN, after doInitBody, doAfterBody, and doEndTag for a tag handler implementing BodyTag, and doStartTag and doEndTag otherwise. There is nothing about synchronization *only* when doInitBody has *invoked*. I think it means the *state* not the action. When call to doInitBody skipped (doStartTag returned EVAL_BODY_INCLUDE) After doInitBody *state* comes just after doStartTag call. Dimitry -- P.S. Excuse me for my not ideal English. :( -Original Message- From: Jan Luehe [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 4:08 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PATCH] Iteration tags do not synchronize scripting variables after doStartTag Dimitry: I still believe your patch is invalid, as it would amount to synchronizing AT_BEGIN and NESTED variables after calling doStartTag(). However, the spec explicitly mentions that for tag handlers implementing BodyTag, those variables must not be synchronized after doStartTag(), *only* after doInitBody(). When I run your example (without applying your patch), I get this result: doStartTag returns EVAL_BODY_INCLUDE null 2nd 3rd doStartTag returns EVAL_BODY_BUFFERED 1st 2nd 3rd The reason your are getting null in the case of doStartTag() returning EVAL_BODY_INCLUDE is that in this case, doInitBody() is not called, hence no synchronization. However, if doStartTag() returns EVAL_BODY_BUFFERED, doInitBody() is being called, and therefore synchronization does take place. Please let me know if you disagree. Jan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13583] - Relative includes/forwards with ../s broken
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=13583. 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=13583 Relative includes/forwards with ../s broken --- Additional Comments From [EMAIL PROTECTED] 2003-01-08 03:26 --- I ran into the same problem and I wanted to mention that I tested this with 4.1.18 and its fixed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PROPOSAL] Tomcat doc organization
If you follow the tomcat-user list there are many questions that are asked which the reply could be RTFM. If the tomcat docs were organized in a way which made them easier to use this may reduce the number of RTFM type of questions. Proposed changes to doc organization: For each individual page generate a Printer Friendly version without the navigation menu. Provide a link on the menu to the printer friendly version. These can easily be generated from the existing xml files, I already have a minor change in tomcat-docs.xsl to support this. For the Config Reference and HOW-TO's provide a printer friendly version that includes all of those docs. This will make it easier for user's to print out a Tomcat manual. Where appropriate, add Table of Content sections at the top to make finding what you want and navigating within a single document easier. Regards, Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Tomcat doc organization
On Tue, 7 Jan 2003, Glenn Nielsen wrote: Date: Tue, 07 Jan 2003 21:35:12 -0600 From: Glenn Nielsen [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [PROPOSAL] Tomcat doc organization If you follow the tomcat-user list there are many questions that are asked which the reply could be RTFM. If the tomcat docs were organized in a way which made them easier to use this may reduce the number of RTFM type of questions. Proposed changes to doc organization: For each individual page generate a Printer Friendly version without the navigation menu. Provide a link on the menu to the printer friendly version. These can easily be generated from the existing xml files, I already have a minor change in tomcat-docs.xsl to support this. The docs generated by Maven and Forrest based builds do this already -- they declare a stylesheet for the print media that leaves off the navigation column when you print the document, without having to explicitly generate print-friendly versions. We could either import the relevant stylesheets, or convert the docco generation to use these existing packages. For the Config Reference and HOW-TO's provide a printer friendly version that includes all of those docs. This will make it easier for user's to print out a Tomcat manual. Shouldn't be too hard to accomplish with a document that just includes all the individual parts into a single resulting page. Where appropriate, add Table of Content sections at the top to make finding what you want and navigating within a single document easier. Oh, and generate an searchable index with Lucene ... :-) Regards, Glenn Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15879] New: - default tomcat homepage index.jsp says it's index.html
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=15879. 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=15879 default tomcat homepage index.jsp says it's index.html Summary: default tomcat homepage index.jsp says it's index.html Product: Tomcat 4 Version: 4.1.18 Platform: All URL: http://localhost:8080/index.jsp OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Installed Tomcat from tomcat-4.1.18.exe. The default tomcat homepage file resides at $CATALINA_HOME/webapps/ROOT/index.jsp. But, the text in that file mistakenly says it resides at $CATALINA_HOME/webapps/ROOT/index.html. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15880] New: - Why not support Chinese?
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=15880.
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=15880
Why not support Chinese?
Summary: Why not support Chinese?
Product: Tomcat 4
Version: 4.0.6 Final
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Minor
Priority: Other
Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Tomcat4.0.6+jdk1.3.02:
When I insert values into database,
if the values are Chinese.Tomcat will insert upside-down code.
such as £¿£¿£¿£¿¡¤£¿£¿,
Chinese cannot be inserted normally in JSP pages.
so I have to convert the code before i insert the String into database:
public String getStr(String str){
try{
if(str == null || str.length() == 0)
return str;
byte[] b = str.getBytes(ISO8859-1);
return new String(b);
}catch(Exception e){
System.err.println(e.toString());
}
return null;
}
I insert Chinese by other method normally.
Chinese can be displayed normally in JSP pages by TOMCAT.
But Resin web server has never the problem!!!
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core Constants.java
jfarcand2003/01/07 11:35:32 Modified:catalina/src/share/org/apache/catalina/core Constants.java Log: Put the proper spec version. Submitted by: Ryan Lubke Revision ChangesPath 1.2 +4 -4 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/Constants.java Index: Constants.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/Constants.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- Constants.java18 Jul 2002 16:48:06 - 1.1 +++ Constants.java7 Jan 2003 19:35:32 - 1.2 @@ -69,7 +69,7 @@ public static final String Package = org.apache.catalina.core; public static final int MAJOR_VERSION = 2; -public static final int MINOR_VERSION = 3; +public static final int MINOR_VERSION = 4; public static final String JSP_SERVLET_CLASS = org.apache.jasper.servlet.JspServlet; -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
