cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt
remm2003/01/15 00:22:17 Modified:.RELEASE-NOTES-4.1.txt Log: - Status update. Revision ChangesPath 1.49 +5 -1 jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt Index: RELEASE-NOTES-4.1.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v retrieving revision 1.48 retrieving revision 1.49 diff -u -r1.48 -r1.49 --- RELEASE-NOTES-4.1.txt 14 Jan 2003 12:59:02 - 1.48 +++ RELEASE-NOTES-4.1.txt 15 Jan 2003 08:22:17 - 1.49 @@ -1029,6 +1029,10 @@ Remove custom flushing, which caused client disconnects to log stack traces with Jasper. +[4.1.19] #15105 + PageContextImpl: + pushBody()/popBody() error on tomcat 4.1.X. + KNOWN ISSUES IN THIS RELEASE: -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15774] - tomcat5 shared/lib behavior different than that of tomcat4.1.x
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=15774. 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=15774 tomcat5 shared/lib behavior different than that of tomcat4.1.x [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-01-15 08:28 --- This should work off CATALINA_BASE by default again now. You may also configure the CL using conf/catalina.properties (so don't complain). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Fwd: Tomcat IRC link bout to be broken]
FYI : ---BeginMessage--- As you may or may not know openprojects.net was bought by freenode.net. Therefore the server address you want has changed to: irc://irc.freenode.net/#tomcat Thanks, Nick aka Hellaenergy ;) ---End Message--- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16102] New: - The method HttpServlet.getLastModified() can't be overrided in the 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=16102. 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=16102 The method HttpServlet.getLastModified() can't be overrided in the JSP Summary: The method HttpServlet.getLastModified() can't be overrided in the JSP Product: Tomcat 4 Version: 4.1.12 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] The problem is that a JSP can't be cached on the client side, because the method: protected long getLastModified(HttpServletRequest request); is invoked from the HttpServlet.service(HttpServletRequest req, HttpServletResponse res) method, but org.apache.jasper.runtime.HttpJspBase override this method without any support for caching. I think, that a good way is to call an abstract void _jspService method from the general doGet and doPost methods in HttpJspBase. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-site/xdocs irc.xml
remm2003/01/15 03:58:12 Modified:xdocsirc.xml Log: - Link update. Revision ChangesPath 1.4 +1 -1 jakarta-tomcat-site/xdocs/irc.xml Index: irc.xml === RCS file: /home/cvs/jakarta-tomcat-site/xdocs/irc.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- irc.xml 4 Apr 2002 05:20:23 - 1.3 +++ irc.xml 15 Jan 2003 11:58:12 - 1.4 @@ -13,7 +13,7 @@ pAn IRC channel dedicated to Tomcat exists on OpenProjects./p pcode#tomcat/code at codeirc.us.openprojects.net/code. -Click a href=irc://irc.us.openprojects.net/tomcathere/a to connect to the +Click a href=irc://irc.freenode.net/#tomcathere/a to connect to the channel using Mozilla./p /section -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-site/docs irc.html
remm2003/01/15 04:00:01 Modified:docs irc.html Log: - Link update. Revision ChangesPath 1.11 +1 -1 jakarta-tomcat-site/docs/irc.html Index: irc.html === RCS file: /home/cvs/jakarta-tomcat-site/docs/irc.html,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- irc.html 17 Dec 2002 16:40:23 - 1.10 +++ irc.html 15 Jan 2003 12:00:01 - 1.11 @@ -121,7 +121,7 @@ blockquote pAn IRC channel dedicated to Tomcat exists on OpenProjects./p pcode#tomcat/code at codeirc.us.openprojects.net/code. -Click a href=irc://irc.us.openprojects.net/tomcathere/a to connect to the +Click a href=irc://irc.freenode.net/#tomcathere/a to connect to the channel using Mozilla./p /blockquote /p -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/ROOT index.jsp
remm2003/01/15 04:02:28 Modified:webapps/ROOT index.jsp Log: - Link update. Revision ChangesPath 1.8 +1 -1 jakarta-tomcat-4.0/webapps/ROOT/index.jsp Index: index.jsp === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/ROOT/index.jsp,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- index.jsp 8 Nov 2002 14:33:20 - 1.7 +++ index.jsp 15 Jan 2003 12:02:28 - 1.8 @@ -98,7 +98,7 @@ a href=http://jakarta.apache.org/tomcat/bugreport.html;Bug Database/abr a href=http://www.mail-archive.com/tomcat-user%40jakarta.apache.org/;Users Mailing List/abr a href=http://www.mail-archive.com/tomcat-dev%40jakarta.apache.org/;Developers Mailing List/abr -a href=irc://irc.us.openprojects.net/tomcatIRC/abr +a href=irc://irc.freenode.net/#tomcatIRC/abr nbsp; /td /tr -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16106] - IllegalAccessException at next startup after Webapps:Aministration
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=16106. 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=16106 IllegalAccessException at next startup after Webapps:Aministration --- Additional Comments From [EMAIL PROTECTED] 2003-01-15 12:45 --- Created an attachment (id=4428) Zip file with .profile, conf log files. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat connector (isapi_redirect)
Hi All, I'm adding some custom logic to the isapi_redirect filter but I can't seem to get the project to compile. I'm running DevStudio 6.0. I'm getting errors about SF_NOTIFY_AUTH_COMPLETE and such (basically all the new ISA server stuff)... I can't see what I'm missing / any ISA SDK toolkit to download. Any ideas where I'm going wrong (old header files? need DevStudio .NET?) etc. etc. ?? Michael Evans Visa International EU Tel: 020 7995 5438 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
How do I create a new bean or servlet? (what do I need to change in the XML files?)
Hi, I'm trying to create a servlet and can't get it to run. I have the .class file (say HelloWorld.class) under (%TOMCAT_HOME%\webapps\test\WEB-INF\classes\). Is there anything I need to add to the web.xml file? If there is, can anyone point me to the proper documentation of deploying servlets and beans? Thanks, Tammer Salem
Tomcat 4.1.19 Alpha released
Tomcat 4.1.19 Alpha is now available for testing. Changes over Tomcat 4.1.18 include: - Refactored manager and deployer - Fix for a SSL related bug - Jasper will now launch javac in a separate JVM, in order to avoid problems such as memory leaks and file locking - New printer frindly documentation - Support for HTTP/1.1 compression in order to save bandwidth - Fix for HTTP/1.0 keep alive support (now compatible with ab which should generate more accurate benchmark results) - More robust server socket restart code in the event of a critical failure - Fix administration webapp commit changes The release notes include the full list of changes. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.19-alpha/ Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat connector (isapi_redirect)
I've figured out what was missing... If anyone else needs to recompile isapi_redirect.dll then look at the README file and download the latest Windows/IIS SDK. -Original Message- From: Evans, Michael [mailto:[EMAIL PROTECTED]] Sent: 15 January 2003 13:50 To: '[EMAIL PROTECTED]' Subject: Tomcat connector (isapi_redirect) Hi All, I'm adding some custom logic to the isapi_redirect filter but I can't seem to get the project to compile. I'm running DevStudio 6.0. I'm getting errors about SF_NOTIFY_AUTH_COMPLETE and such (basically all the new ISA server stuff)... I can't see what I'm missing / any ISA SDK toolkit to download. Any ideas where I'm going wrong (old header files? need DevStudio .NET?) etc. etc. ?? Michael Evans Visa International EU Tel: 020 7995 5438 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteConnector.java
remm2003/01/15 07:15:13
Modified:coyote/src/java/org/apache/coyote/tomcat4
CoyoteConnector.java
Log:
- Add accessor for the protocol handler.
Revision ChangesPath
1.21 +14 -4
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteConnector.java
Index: CoyoteConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteConnector.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- CoyoteConnector.java 23 Dec 2002 01:32:24 - 1.20
+++ CoyoteConnector.java 15 Jan 2003 15:15:13 - 1.21
@@ -694,6 +694,16 @@
/**
+ * Return the protocol handler associated with the connector.
+ */
+public ProtocolHandler getProtocolHandler() {
+
+return (this.protocolHandler);
+
+}
+
+
+/**
* Return the proxy server name for this Connector.
*/
public String getProxyName() {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Do Servlets and Filters in separate contexts share a single JVM instance?
Hello, I am trying to know how Tomcat (4.1.12) handles the creation of each servlet and/or filter in different contexts. (I haven't noticed this within the documentation, but maybe I've just missed it.) As far as I can tell from the archives, it seems that each application context is loaded by a distinct class loader, but I would still like some further information. Is each servlet and/or filter context running within its own JVM instance? or within its own Process (as in java.lang.Runtime.exec)? In other words, do all servlets and filter contexts share the same JVM instance or are they separated somehow? If they are kept separate, how (generally speaking) is that being achieved? I ask this question from the standpoint of how a servlet/filter gone amuck might impact other non-related servlets and filters living in different contexts within the Tomcat container. If a servlet (say) decides to chew up all of its available memory, will that choke the memory for the rest of the servlets and filters in other contexts running on the server? or will that only impact the rogue servlet itself? Specifically, I'm considering using a Filter to hand off the Input and Output Streams of a request to a relatively large Object the Filter will have instantiated. This Object is not a servlet, but a multi-threaded Jini Service. Since there will be more than a few of these Filter-to-Jini Service bridges running within the Tomcat container, I'd like to know whether or not they will be in their own JVM instance. (If not, I suspect I may not want to do this.) Thank you for your time. -John R. Lorenti -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Do Servlets and Filters in separate contexts share a single JVM instance?
Howdy, First off, the general questions, then your specific design issue: servlet and/or filter context running within its own JVM instance? or within its own Process (as in java.lang.Runtime.exec)? In other words, do all servlets and filter contexts share the same JVM instance or are they separated somehow? - An instance of tomcat corresponds to a single JVM instance. - Each context has its own classloader within the JVM instance. See the servlet spec for classloading requirements and tomcat's classloader how-to page for details. If they are kept separate, how (generally speaking) is that being achieved? The servlet specification defines what servlet and filters can do with each other, e.g. request forwarding or inclusion, and what's kept separate, e.g. classes in the webapp's WEB-INF/lib directory. To see how tomcat specifically implements this, you will need to look through the tomcat source. The package org.apache.catalina[] is a good place to start. However, be very careful when relying on server-specific features/implementation. Your best bet as far as portability, including portability to future versions of tomcat, is to stick to the servlet specification. contexts within the Tomcat container. If a servlet (say) decides to chew up all of its available memory, will that choke the memory for the rest of the servlets and filters in other contexts running on the server? or will that only impact the rogue servlet itself? It will impacts all the contexts, ultimately causing a java.lang.OutOfMemoryError that will necessitate you to restart the server. Specifically, I'm considering using a Filter to hand off the Input and Output Streams of a request to a relatively large Object the Filter will have instantiated. This Object is not a servlet, but a multi-threaded Jini Service. Since there will be more than a few of these Filter-to-Jini Service bridges running within the Tomcat container, I'd like to know whether or not they will be in their own JVM instance. (If not, I suspect I may not want to do this.) Is it your own jinni service that you wrote, or a 3rd party? In either case, you want to ensure they can't consume all that memory. This can be exceedingly difficult. Another way to go is to determine that maximum size of this Object that you're willing to handle. This depends on how much memory you can allocate to the JVM. You may have to limit user inputs, and/or validate that the user's request won't result in an oversize object, before handing the streams over to this service. Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] jakarta-servletapi-5
Small patch to fix some javadocs. Modified File: jsr152/src/share/javax/servlet/jsp/tagext/BodyTag.java - Mark Index: jsr152/src/share/javax/servlet/jsp/tagext/BodyTag.java === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/BodyTag.java,v retrieving revision 1.4 diff -u -r1.4 BodyTag.java --- jsr152/src/share/javax/servlet/jsp/tagext/BodyTag.java 18 Dec 2002 18:35:37 - 1.4 +++ jsr152/src/share/javax/servlet/jsp/tagext/BodyTag.java 15 Jan 2003 16:32:54 +- @@ -96,11 +96,12 @@ * object, where the JSP Page implementation object will place the * evaluation (and reevaluation, if appropriate) of the body. The setter * method (setBodyContent) will only be invoked if doStartTag() returns - * EVAL_BODY_BUFFERED and the corresponding action element is not empty. + * EVAL_BODY_BUFFERED and the corresponding action element does not have + * an empty body. * * pBMethods/B * p In addition to the setter method for the bodyContent property, there - * is a new action methods: doInitBody(), which is invoked right after + * is a new action method: doInitBody(), which is invoked right after * setBodyContent() and before the body evaluation. This method is only * invoked if doStartTag() returns EVAL_BODY_BUFFERED. * -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16113] New: - removing then replacing a jsp page continues to give a 404
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=16113. 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=16113 removing then replacing a jsp page continues to give a 404 Summary: removing then replacing a jsp page continues to give a 404 Product: Tomcat 4 Version: 4.1.18 Platform: Other OS/Version: All Status: NEW Severity: Blocker Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi guys. I've got what appears to be a bona fide error in tomcat's jsp servlet or one of its friends. The steps to reproduce the problem are: 1. start tomcat-4.1.18 with a webapp containing a foo.jsp page 2. hit the foo.jsp url and see the page 3. remove foo.jsp from the webapp 4. reload the foo.jsp url until you finally get a 404 (why does this take several tries?) 5. replace the foo.jsp file in the webapp 6. note that hitting the foo.jsp url will forever give you a 404 until you restart tomcat -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-site/xdocs irc.xml
remm2003/01/15 08:46:01 Modified:docs irc.html xdocsirc.xml Log: - Link update (again). Revision ChangesPath 1.12 +1 -1 jakarta-tomcat-site/docs/irc.html Index: irc.html === RCS file: /home/cvs/jakarta-tomcat-site/docs/irc.html,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- irc.html 15 Jan 2003 12:00:01 - 1.11 +++ irc.html 15 Jan 2003 16:46:01 - 1.12 @@ -120,7 +120,7 @@ trtd blockquote pAn IRC channel dedicated to Tomcat exists on OpenProjects./p -pcode#tomcat/code at codeirc.us.openprojects.net/code. +pcode#tomcat/code at codeirc.freenode.net/code. Click a href=irc://irc.freenode.net/#tomcathere/a to connect to the channel using Mozilla./p /blockquote 1.5 +1 -1 jakarta-tomcat-site/xdocs/irc.xml Index: irc.xml === RCS file: /home/cvs/jakarta-tomcat-site/xdocs/irc.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- irc.xml 15 Jan 2003 11:58:12 - 1.4 +++ irc.xml 15 Jan 2003 16:46:01 - 1.5 @@ -12,7 +12,7 @@ pAn IRC channel dedicated to Tomcat exists on OpenProjects./p -pcode#tomcat/code at codeirc.us.openprojects.net/code. +pcode#tomcat/code at codeirc.freenode.net/code. Click a href=irc://irc.freenode.net/#tomcathere/a to connect to the channel using Mozilla./p -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16114] New: - custom tag output is not flushed then not writed to jsp output
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=16114. 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=16114 custom tag output is not flushed then not writed to jsp output Summary: custom tag output is not flushed then not writed to jsp output Product: Tomcat 4 Version: 4.1.18 Platform: All OS/Version: All Status: NEW Severity: Critical Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] On a jsp like: ---a.jsp lt;html . . . . lt;MyCustomTags:myFirstTag . / . . . . lt;/body lt;/html The problem is that if miFirstTag does an output to the jsp output (writing to pageContext.getOut() on handler of type Tag or writing to getPreviousOut() on handler of type BodyTag) it does not appears on a.jsp (or only appears part of all the content that has been writen on the custom tag). I have seen that the output is not flushed when the custom tag handler finishes. On previous 4.1.x (at least on 4.1.12) versions it worked fine. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16113] - removing then replacing a jsp page continues to give a 404
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=16113. 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=16113 removing then replacing a jsp page continues to give a 404 [EMAIL PROTECTED] changed: What|Removed |Added Severity|Blocker |Normal --- Additional Comments From [EMAIL PROTECTED] 2003-01-15 16:54 --- I can reproduce it. It doesn't happen with non-JSPs, such as images, so it shouldn't be a cache bug. BTW, the (small) delay is there because there's a cache. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16116] New: - ResourceLink does not work within DefaultContext
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=16116.
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=16116
ResourceLink does not work within DefaultContext
Summary: ResourceLink does not work within DefaultContext
Product: Tomcat 4
Version: 4.1.19
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina:Modules
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Given the (condensed) server.xml snippet:
Server port=8005 shutdown=SHUTDOWN debug=0
GlobalNamingResources
Environment name=simpleValue type=java.lang.Integer value=30/
/GlobalNamingResources
Service name=Tomcat-Standalone
Engine name=Standalone defaultHost=localhost debug=0
DefaultContext
ResourceLink name=defaultSimpleValue
global=simpleValue
type=java.lang.Integer/
/DefaultContext
...
With a test JSP:
%@ page contentType=text/plain
import=java.io.*,javax.naming.* %
%
Context ctx = null;
try {
ctx = new InitialContext();
Integer defaultSimpleValue =
(Integer)ctx.lookup(java:comp/env/defaultSimpleValue);
out.println(defaultSimpleValue = + defaultSimpleValue);
} catch (Exception exc) {
exc.printStackTrace(new PrintWriter(out));
} finally {
if (ctx != null) {
try {
ctx.close();
} catch (NamingException exc) {
exc.printStackTrace(new PrintWriter(out));
}
}
}
%
Results in:
javax.naming.NameNotFoundException: Name defaultSimpleValue is not bound in this
Context
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15406] - error-page responses are sent with wrong status code!
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=15406. 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=15406 error-page responses are sent with wrong status code! [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-01-15 17:15 --- craig insists that the current behavior is correct, that it's the responsibility of the referred resource to set the response code. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13692] - request.getCharacterEncoding() is NULL
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=13692. 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=13692 request.getCharacterEncoding() is NULL [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Blocker Status|ASSIGNED|NEW Priority|Medium |High -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15774] - tomcat5 shared/lib behavior different than that of tomcat4.1.x
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=15774. 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=15774 tomcat5 shared/lib behavior different than that of tomcat4.1.x --- Additional Comments From [EMAIL PROTECTED] 2003-01-15 18:13 --- Thanks Remy, No complaints here. I had no idea it was setable in catalina.propeties as that didn't exist in Tomcat-4.x.x. Without default behavior being the same as Tomcat-4.1.x, though, I think that would be an issue for those counting on the behavior and not having the proper info on how to get the desired behavior. This just makes the default config of Tomcat-5 simpler. Again, thanks for making the change and pointing out where I can change it myself. Jake -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16127] New: - Seems to be a problem doing a static include of content when using a different charset.
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=16127. 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=16127 Seems to be a problem doing a static include of content when using a different charset. Summary: Seems to be a problem doing a static include of content when using a different charset. 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 JSP.4.1 of the 2.0 specificiation, Files included using the include directive are read using the character encoding of the including page. For my case, I have a JSP Document encoded in UTF-16BE (the JSP Document also sets the response content type to text/plain; charset=ISO-8859-1. The document uses an include directive to include another text document also encoded in UTF-16BE. Reviewing the result of the page, I can see that the included content is still in UTF-16BE instead of ISO-8859-1 (note, I can leave off the contentType attribute of the page directive so that the response is text/xml with a charset of UTF-8, but it makes no difference). Here is the calling JSP Document: - ?xml version=1.0 encoding=UTF-16BE? root xmlns:jsp=http://java.sun.com/JSP/Page; jsp:directive.page contentType=text/plain; charset=ISO-8859-1 / jsp:directive.include file=inclusion_utf-16BE.txt / /root - The included text file contains (encoded in UTF-16BE): includedIncluded Content/included The result that I'm seeing looks something like: ?xml version=1.0 encoding=ISO-8859-1? root xmlns:jsp=http://java.sun.com/JSP/Page;^@^@i^@n^@c^@l^@u^@d^@e^@d^@^@I^@n^@c^@l^@u^@d^@e^@d^@ ^@C^@o^@n^@t^@e^@n^@t^@^@/^@i^@n^@c^@l^@u^@d^@e^@d^@^@ /root This was working in previous builds. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16129] New: - A translation-time error is not raised when the value of the page directives pageEncoding attribute fails to match that of the xml prolog of the JSP document.
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=16129. 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=16129 A translation-time error is not raised when the value of the page directives pageEncoding attribute fails to match that of the xml prolog of the JSP document. Summary: A translation-time error is not raised when the value of the page directives pageEncoding attribute fails to match that of the xml prolog of the JSP document. 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] A translation error is not generated when Jasper is presented the following: ?xml version=1.0 encoding=UTF-8? root jsp:directive.page xmlns:jsp=http://java.sun.com/JSP/Page; pageEncoding=ISO-8859-1 / /root JSP.4.1 states the following for JSP documents: It is a translation-time error to name different encodings in two or more of the following: the XML prolog of a JSP page, the pageEncoding attribute of the page directive of the JSP page, and in a JSP configuration element whose URL pattern matches the page. This worked as expected in previous builds. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16044] - problems with gifs and jpegs - HTML are ok
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=16044. 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=16044 problems with gifs and jpegs - HTML are ok [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Blocker Priority|Other |High -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Add customizable date format for access log filename
Much of the access log filename can be customized in the Valve
declaration using prefix and suffix, but the date format used for
the filename is hardcoded in the Valve code.
Here's a patch that allows the date format to be specified in
the Valve definition alongside prefix and suffix.
If this patch is accepted, I can put together another patch for
the admin webapp.
See patch below.
Mike Heinrichs
Index: AccessLogValve.java
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/AccessLogValve.java,v
retrieving revision 1.15
diff -u -r1.15 AccessLogValve.java
--- AccessLogValve.java 22 Nov 2002 20:27:12 - 1.15
+++ AccessLogValve.java 15 Jan 2003 19:19:32 -
@@ -325,6 +325,11 @@
private long rotationLastChecked = 0L;
+/**
+ * The access log filename date format
+ */
+private String dateFormat = -MM-dd;
+
// - Properties
@@ -443,6 +448,28 @@
/**
+ * Return the date format string used for access log filenames
+ */
+public String getDateFormat() {
+
+return (dateFormat);
+
+}
+
+
+/**
+ * Set the date format string used for access log filenames
+ *
+ * @param dateFormat The new date format
+ */
+public void setDateFormat(String dateFormat) {
+
+this.dateFormat = dateFormat;
+
+}
+
+
+/**
* Return the log file suffix.
*/
public String getSuffix() {
@@ -1024,7 +1051,7 @@
if (timeZone.length() 5)
timeZone = timeZone.substring(0, 1) + 0 +
timeZone.substring(1, timeZone.length());
-dateFormatter = new SimpleDateFormat(-MM-dd);
+dateFormatter = new SimpleDateFormat(this.dateFormat);
dateFormatter.setTimeZone(tz);
dayFormatter = new SimpleDateFormat(dd);
dayFormatter.setTimeZone(tz);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16044] - problems with gifs and jpegs - HTML are ok
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=16044. 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=16044 problems with gifs and jpegs - HTML are ok [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-01-15 19:59 --- So you are having incredible problems that nobody else is experiencing. I think posting on tomcat-user would be a better choice to try to debug it a little bit. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15774] - tomcat5 shared/lib behavior different than that of tomcat4.1.x
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=15774. 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=15774 tomcat5 shared/lib behavior different than that of tomcat4.1.x --- Additional Comments From [EMAIL PROTECTED] 2003-01-15 20:00 --- Actually, the classloading scheme may undergo a radical change by the time Tomcat 5 gets released. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Urgent: Tomcat dies with socket exceptions !
Sylvain Beaumont wrote: Hi, We developped a GIS server, in which a embedded Tomcat serves JSP / Servlet requests. Since we upgraded Tomcat 3.x with 4.1.x (currently 4.1.12), Tomcat dies with a SocketException. Here is the exception: java.net.SocketException: Connection reset by peer: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.coyote.http11.InternalOutputBuffer$OutputStreamOutputBuffer.d oWrite(InternalOutputBuffer.java:652) at org.apache.coyote.http11.filters.IdentityOutputFilter.doWrite(IdentityOu tputFilter.java:160) at org.apache.coyote.http11.InternalOutputBuffer.doWrite(InternalOutputBuff er.java:523) at org.apache.coyote.Response.doWrite(Response.java:513) at org.apache.coyote.tomcat4.OutputBuffer.realWriteBytes(OutputBuffer.java: 380) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:360) at org.apache.coyote.tomcat4.OutputBuffer.writeBytes(OutputBuffer.java:413) at org.apache.coyote.tomcat4.OutputBuffer.write(OutputBuffer.java:394) at org.apache.coyote.tomcat4.CoyoteOutputStream.write(CoyoteOutputStream.ja va:110) I started my server in debug mode (-debug + jdb) and I reproduce the problem twice. Here is the stack trace of a Tomcat thread trying to serve a page: [1] java.net.SocketInputStream.socketRead0 (native method) [2] java.net.SocketInputStream.read (SocketInputStream.java:129) [3] org.apache.coyote.http11.InternalInputBuffer.fill (InternalInputBuffer.java:767) [4] org.apache.coyote.http11.InternalInputBuffer.parseRequestLine (InternalInputBuffer.java:428) [5] org.apache.coyote.http11.Http11Processor.process (Http11Processor.java:382) [6] org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC onnection (Http11Protocol.java:380) [7] org.apache.tomcat.util.net.TcpWorkerThread.runIt (PoolTcpEndpoint.java:508) [8] org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:533) [9] java.lang.Thread.run (Thread.java:536) Our demo server (Linux, 1.4.1), which in not under heavy loads ( 100 requests / day), hangs every week. It also happened on 3 development PC (Win XP, 1.4.1) after a couple of hours of tests. - It is not related to SSL problems reported lately - It doesn't seem to be related to database access: - it happened on simple JSP pages displaying live memory data (no DB access) - the same setup was working using Tomcat 3.x (not sure about 4.0.x) Any ideas / suggestions would be appreciated, Please post this on tomcat-user. Other than I have to take your word that Tomcat is hanging, the traces look normal. The first stack trace would happen with a client disconnect (but is not logged anymore in 4.1.18). As for the thread stack, it is typical of a connection being persisted. There was a bug with that before 4.1.18, as the socket timeout was incorrectly set. You should upgrade to 4.1.18 or 4.1.19. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Add customizable date format for access log filename
I see a problem with this with respect to log rotation. The way things
work now, on every request tomcat checks to see if the log needs
rotated. (It actually checks at most, once a second).
The way it determines to rotate the log is via the date format. Since
the date format is hardcoded to contain just the day information - this
is ok. But if a user defines a log date format containing the second (or
even worse, the millisecond), then the logs would rotate every second.
Which some may consider a feature :)
-Tim
Michael Heinrichs wrote:
Much of the access log filename can be customized in the Valve
declaration using prefix and suffix, but the date format used for
the filename is hardcoded in the Valve code.
Here's a patch that allows the date format to be specified in
the Valve definition alongside prefix and suffix.
If this patch is accepted, I can put together another patch for
the admin webapp.
See patch below.
Mike Heinrichs
Index: AccessLogValve.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/AccessLogValve.java,v
retrieving revision 1.15
diff -u -r1.15 AccessLogValve.java
--- AccessLogValve.java22 Nov 2002 20:27:12 -1.15
+++ AccessLogValve.java15 Jan 2003 19:19:32 -
@@ -325,6 +325,11 @@
private long rotationLastChecked = 0L;
+/**
+ * The access log filename date format
+ */
+private String dateFormat = -MM-dd;
+
// -
Properties
@@ -443,6 +448,28 @@
/**
+ * Return the date format string used for access log filenames
+ */
+public String getDateFormat() {
+
+return (dateFormat);
+
+}
+
+
+/**
+ * Set the date format string used for access log filenames
+ *
+ * @param dateFormat The new date format
+ */
+public void setDateFormat(String dateFormat) {
+
+this.dateFormat = dateFormat;
+
+}
+
+
+/**
* Return the log file suffix.
*/
public String getSuffix() {
@@ -1024,7 +1051,7 @@
if (timeZone.length() 5)
timeZone = timeZone.substring(0, 1) + 0 +
timeZone.substring(1, timeZone.length());
-dateFormatter = new SimpleDateFormat(-MM-dd);
+dateFormatter = new SimpleDateFormat(this.dateFormat);
dateFormatter.setTimeZone(tz);
dayFormatter = new SimpleDateFormat(dd);
dayFormatter.setTimeZone(tz);
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Add customizable date format for access log filename
I see your point. I can see how some might want that feature (hourly
log rotation?), but maybe log rotation intervals and date format should
be separate concerns. In my case, someone handling our logs prefers
'.MM.dd' to '-MM-dd', so I simply wanted date format control.
Maybe if the attribute were named something like
'logRotationDateFormat', no one could complain when they put
milliseconds in their format :-)
Mike
Tim Funk wrote:
I see a problem with this with respect to log rotation. The way things
work now, on every request tomcat checks to see if the log needs
rotated. (It actually checks at most, once a second).
The way it determines to rotate the log is via the date format. Since
the date format is hardcoded to contain just the day information -
this is ok. But if a user defines a log date format containing the
second (or even worse, the millisecond), then the logs would rotate
every second. Which some may consider a feature :)
-Tim
Michael Heinrichs wrote:
Much of the access log filename can be customized in the Valve
declaration using prefix and suffix, but the date format used for
the filename is hardcoded in the Valve code.
Here's a patch that allows the date format to be specified in
the Valve definition alongside prefix and suffix.
If this patch is accepted, I can put together another patch for
the admin webapp.
See patch below.
Mike Heinrichs
Index: AccessLogValve.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/AccessLogValve.java,v
retrieving revision 1.15
diff -u -r1.15 AccessLogValve.java
--- AccessLogValve.java22 Nov 2002 20:27:12 -1.15
+++ AccessLogValve.java15 Jan 2003 19:19:32 -
@@ -325,6 +325,11 @@
private long rotationLastChecked = 0L;
+/**
+ * The access log filename date format
+ */
+private String dateFormat = -MM-dd;
+
// -
Properties
@@ -443,6 +448,28 @@
/**
+ * Return the date format string used for access log filenames
+ */
+public String getDateFormat() {
+
+return (dateFormat);
+
+}
+
+
+/**
+ * Set the date format string used for access log filenames
+ *
+ * @param dateFormat The new date format
+ */
+public void setDateFormat(String dateFormat) {
+
+this.dateFormat = dateFormat;
+
+}
+
+
+/**
* Return the log file suffix.
*/
public String getSuffix() {
@@ -1024,7 +1051,7 @@
if (timeZone.length() 5)
timeZone = timeZone.substring(0, 1) + 0 +
timeZone.substring(1, timeZone.length());
-dateFormatter = new SimpleDateFormat(-MM-dd);
+dateFormatter = new SimpleDateFormat(this.dateFormat);
dateFormatter.setTimeZone(tz);
dayFormatter = new SimpleDateFormat(dd);
dayFormatter.setTimeZone(tz);
--
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]
DO NOT REPLY [Bug 16144] New: - NullPointerException in JDBCRealm when password is null
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=16144. 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=16144 NullPointerException in JDBCRealm when password is null Summary: NullPointerException in JDBCRealm when password is null Product: Tomcat 4 Version: 4.1.18 Platform: PC OS/Version: Linux Status: NEW Severity: Minor Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] My setup: Tomcat 4.1.18 running behind Apache 2.0.40.8 (RedHat 8.0). I use SSL on Apache and use CoyoteConnector and mod_jk to connect httpd and tomcat. I use basic authentication on tomcat. I use Oracle 9.2 for my authentication db. This setup works great, except I found one scenario where the JDBCRealm causes a null pointer exception during Basic Authentication: The user's password is password in the database. If the user leaves the password empty in the Basic Authentication Dialog (in IE or Netscape), nothing is returned and the following exception occurs: Ajp13Processor[8090][1] process: invoke java.lang.NullPointerException at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:447) at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:394) at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:161) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: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.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:509) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:458) at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:551) at java.lang.Thread.run(Thread.java:536) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15961] - getBodyContent() is not returning null when the action has only jsp:attribute actions within the body.
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=15961. 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=15961 getBodyContent() is not returning null when the action has only jsp:attribute actions within the body. [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
luehe 2003/01/15 14:46:29
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
Fixed 15961 (getBodyContent() is not returning null when the action
has only jsp:attribute actions within the body) for simple tag handlers
Revision ChangesPath
1.148 +12 -10
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.147
retrieving revision 1.148
diff -u -r1.147 -r1.148
--- Generator.java11 Jan 2003 00:52:14 - 1.147
+++ Generator.java15 Jan 2003 22:46:29 - 1.148
@@ -1756,13 +1756,15 @@
}
public void visit(Node.JspBody n) throws JasperException {
- if (isSimpleTagHandler) {
- out.printin(simpleTagHandlerVar);
- out.print(.setJspBody();
- generateJspFragment(n, simpleTagHandlerVar);
- out.println(););
- } else {
- visitBody(n);
+ if (n.getBody() != null) {
+ if (isSimpleTagHandler) {
+ out.printin(simpleTagHandlerVar);
+ out.print(.setJspBody();
+ generateJspFragment(n, simpleTagHandlerVar);
+ out.println(););
+ } else {
+ visitBody(n);
+ }
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 15961] - getBodyContent() is not returning null when the action has only jsp:attribute actions within the body.
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 5:42 PM Subject: DO NOT REPLY [Bug 15961] - getBodyContent() is not returning null when the action has only jsp:attribute actions within the body. 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=15961. 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=15961 getBodyContent() is not returning null when the action has only jsp:attribute actions within the body. [EMAIL PROTECTED] changed: What|Removed |Added -- -- Status|REOPENED|RESOLVED Resolution||FIXED -- 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]
Urgent: Tomcat dies with socket exceptions !
Hi, We developped a GIS server, in which a embedded Tomcat serves JSP / Servlet requests. Since we upgraded Tomcat 3.x with 4.1.x (currently 4.1.12), Tomcat dies with a SocketException. Here is the exception: java.net.SocketException: Connection reset by peer: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.coyote.http11.InternalOutputBuffer$OutputStreamOutputBuffer.d oWrite(InternalOutputBuffer.java:652) at org.apache.coyote.http11.filters.IdentityOutputFilter.doWrite(IdentityOu tputFilter.java:160) at org.apache.coyote.http11.InternalOutputBuffer.doWrite(InternalOutputBuff er.java:523) at org.apache.coyote.Response.doWrite(Response.java:513) at org.apache.coyote.tomcat4.OutputBuffer.realWriteBytes(OutputBuffer.java: 380) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:360) at org.apache.coyote.tomcat4.OutputBuffer.writeBytes(OutputBuffer.java:413) at org.apache.coyote.tomcat4.OutputBuffer.write(OutputBuffer.java:394) at org.apache.coyote.tomcat4.CoyoteOutputStream.write(CoyoteOutputStream.ja va:110) I started my server in debug mode (-debug + jdb) and I reproduce the problem twice. Here is the stack trace of a Tomcat thread trying to serve a page: [1] java.net.SocketInputStream.socketRead0 (native method) [2] java.net.SocketInputStream.read (SocketInputStream.java:129) [3] org.apache.coyote.http11.InternalInputBuffer.fill (InternalInputBuffer.java:767) [4] org.apache.coyote.http11.InternalInputBuffer.parseRequestLine (InternalInputBuffer.java:428) [5] org.apache.coyote.http11.Http11Processor.process (Http11Processor.java:382) [6] org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC onnection (Http11Protocol.java:380) [7] org.apache.tomcat.util.net.TcpWorkerThread.runIt (PoolTcpEndpoint.java:508) [8] org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:533) [9] java.lang.Thread.run (Thread.java:536) Our demo server (Linux, 1.4.1), which in not under heavy loads ( 100 requests / day), hangs every week. It also happened on 3 development PC (Win XP, 1.4.1) after a couple of hours of tests. - It is not related to SSL problems reported lately - It doesn't seem to be related to database access: - it happened on simple JSP pages displaying live memory data (no DB access) - the same setup was working using Tomcat 3.x (not sure about 4.0.x) Any ideas / suggestions would be appreciated, thank you, Sylvain -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16146] New: - POST request with invalid Content-Length 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=16146.
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=16146
POST request with invalid Content-Length header
Summary: POST request with invalid Content-Length header
Product: Tomcat 4
Version: 4.0 Beta 1
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: Major
Priority: Other
Component: Connector:Coyote HTTP/1.1
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
IE sends a negative number (the signed integer wraps) for Content-Length sizes
greater than 2147483647 bytes. Reuslting in the following error:
SEVERE: Error reading request, ignored
java.lang.NumberFormatException
at org.apache.tomcat.util.buf.Ascii.parseInt(Ascii.java:188)
at org.apache.tomcat.util.buf.ByteChunk.getInt(ByteChunk.java:439)
at org.apache.tomcat.util.buf.MessageBytes.getInt
(MessageBytes.java:629)
at org.apache.coyote.Request.getContentLength(Request.java:314)
at org.apache.coyote.http11.Http11Processor.prepareRequest
(Http11Processor.java:747)
at org.apache.coyote.http11.Http11Processor.process
(Http11Processor.java:424)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnecti
on(Http11Protocol.java:386)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:534)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:530)
at java.lang.Thread.run(Thread.java:536)
CODE:
public int getContentLength() {
if( contentLength -1 ) return contentLength;
MessageBytes clB = headers.getValue(content-length);
contentLength = (clB == null || clB.isNull()) ? -1 : clB.getInt();
available = contentLength;
return contentLength;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16146] - POST request with invalid Content-Length 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=16146. 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=16146 POST request with invalid Content-Length header [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Summary|POST request with invalid |POST request with invalid |Content-Length header |Content-Length header --- Additional Comments From [EMAIL PROTECTED] 2003-01-16 00:06 --- And the problem is ? It is a totally invalid request, and if it doesn't cause any problem other than causing a stack trace to end up in the logs, then it's fine. Note than 4G content-length will not be handled correctly by Tomcat in many circumstances. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16146] - POST request with invalid Content-Length 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=16146. 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=16146 POST request with invalid Content-Length header [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2003-01-16 00:21 --- IE is sending a big negative number. The request aborts and a server error is displayed. All I'm asking is that you check for the negative and do what ever you are doing for the case where null is passed instead of throwing an exception and presenting the sever error page. This will hopefully allow the file to be uploaded without causing the server error. The 4GB limit is fine but, what I have here is a 2GB limit beacuse the signed integer wraps. This new imposed limit can be removed if you simply compensate for the invalid negative number. Yes, the message is technically invalid due to the incorrect negative content length, but we program to save ourselves from stupidity all the time. Will you please simply check for a negative and treat it like the null case or ignore the parameter if a negative is presented? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16150] New: - IllegalStateException with Tomcat3.2.3 and JRE1.4.0_01
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=16150. 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=16150 IllegalStateException with Tomcat3.2.3 and JRE1.4.0_01 Summary: IllegalStateException with Tomcat3.2.3 and JRE1.4.0_01 Product: Tomcat 3 Version: 3.2.3 Final Platform: PC OS/Version: Other Status: NEW Severity: Blocker Priority: Other Component: Connectors AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The scenario is that I have a servlet/JSP which can be accessed by a link on a page, while this JSP/Servlet is being loaded(which might be a couple of seconds), if I access another link on the page or if I close the browser. I see the Tomcat service go into a loop. Following are the traces from Tomcat 2003-01-13 02:21:02 - Ctx( /webdialer ): IOException in: R( /webdialer + /jsp/CallFailed.jsp + null) Connection reset by peer: socket write error 2003-01-13 02:21:02 - Ctx( /webdialer ): IllegalStateException in: R ( /webdialer + /jsp/CallFailed.jsp + null) Current state = FLUSHED, new state = CODING_END 2003-01-13 02:21:02 - Ctx( /webdialer ): IllegalStateException in: R ( /webdialer + /jsp/CallFailed.jsp + null) Current state = FLUSHED, new state = CODING 2003-01-13 02:21:02 - Ctx( /webdialer ): IllegalStateException in: R ( /webdialer + /jsp/CallFailed.jsp + null) Current state = FLUSHED, new state = CODING The last two error messages are repeating a couple of thousand times, during which the Tomcat service takes up 100% CPU and if you repeat this scenario a couple of times the service just dies. Interestingly, it is NOT an issue when we use JRE1.3.x. The same problem has been reported at multiple discussion groups, e.g., http://forum.java.sun.com/thread.jsp?thread=325460forum=31message=1328411 However, I did not see a solution to this problem. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16150] - IllegalStateException with Tomcat3.2.3 and JRE1.4.0_01
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=16150. 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=16150 IllegalStateException with Tomcat3.2.3 and JRE1.4.0_01 [EMAIL PROTECTED] changed: What|Removed |Added Priority|Other |High -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16150] - IllegalStateException with Tomcat3.2.3 and JRE1.4.0_01
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=16150. 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=16150 IllegalStateException with Tomcat3.2.3 and JRE1.4.0_01 [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Other |Windows NT/2K -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext BodyTag.java
kinman 2003/01/15 17:37:04 Modified:jsr152/src/share/javax/servlet/jsp/tagext BodyTag.java Log: - Patch by Mark Roth: fix some javadocs Revision ChangesPath 1.5 +3 -2 jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/BodyTag.java Index: BodyTag.java === RCS file: /home/cvs/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/BodyTag.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- BodyTag.java 18 Dec 2002 18:35:37 - 1.4 +++ BodyTag.java 16 Jan 2003 01:37:04 - 1.5 @@ -96,11 +96,12 @@ * object, where the JSP Page implementation object will place the * evaluation (and reevaluation, if appropriate) of the body. The setter * method (setBodyContent) will only be invoked if doStartTag() returns - * EVAL_BODY_BUFFERED and the corresponding action element is not empty. + * EVAL_BODY_BUFFERED and the corresponding action element does not have + * an empty body. * * pBMethods/B * p In addition to the setter method for the bodyContent property, there - * is a new action methods: doInitBody(), which is invoked right after + * is a new action method: doInitBody(), which is invoked right after * setBodyContent() and before the body evaluation. This method is only * invoked if doStartTag() returns EVAL_BODY_BUFFERED. * -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16150] - IllegalStateException with Tomcat3.2.3 and JRE1.4.0_01
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=16150. 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=16150 IllegalStateException with Tomcat3.2.3 and JRE1.4.0_01 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-01-16 02:03 --- *** This bug has been marked as a duplicate of 10047 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10047] - IllegalStateException and Browser back button
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=10047. 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=10047 IllegalStateException and Browser back button [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-01-16 02:03 --- *** Bug 16150 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16152] New: - problems using new versions
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=16152. 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=16152 problems using new versions Summary: problems using new versions Product: Tomcat 4 Version: 4.1.18 Platform: Sun OS/Version: Windows NT/2K Status: NEW Severity: Blocker Priority: Other Component: Servlets:WebDAV AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, I was using window 98, jdk 1.3.1, Tomcat 3.2, JDOM 8 beta version, Struts architecture. but now I changed it to windows 2000, jdk 1.4.1, Tomcat 4.1.18, JDOM 8 beta version. I kept/deployed my all old file, after successful instalation of tomcat 4.1.18. It then started giving error in some .tld files that info tag is not allowed, i removed all info tags from the error .tld files. Now i am getting error, as per file attached herewith. Please help me to resolve this problem. regards erroe page - HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: org/jdom/input/SAXBuilder at org.apache.jasper.servlet.JspServletWrapper.service (JspServletWrapper.java:248) at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:643) at org.apache.catalina.authenticator.AuthenticatorBase.invoke (AuthenticatorBase.java:493) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java: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.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke (ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service (CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process (Http11Processor.java:432) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnectio n(Http11Protocol.java:386) at org.apache.tomcat.util.net.TcpWorkerThread.runIt (PoolTcpEndpoint.java:534) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:530) at java.lang.Thread.run(Thread.java:536) root cause javax.servlet.ServletException: org/jdom/input/SAXBuilder at
DO NOT REPLY [Bug 16129] - A translation-time error is not raised when the value of the page directives pageEncoding attribute fails to match that of the xml prolog of the JSP document.
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=16129. 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=16129 A translation-time error is not raised when the value of the page directives pageEncoding attribute fails to match that of the xml prolog of the JSP document. [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 16152] - problems using new versions
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=16152. 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=16152 problems using new versions --- Additional Comments From [EMAIL PROTECTED] 2003-01-16 02:34 --- Created an attachment (id=4457) copy of the error page -- 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/xmlparser XercesEncodingDetector.java
luehe 2003/01/15 18:32:56
Modified:jasper2/src/share/org/apache/jasper/xmlparser
XercesEncodingDetector.java
Log:
Fixed 16129: A translation-time error is not raised when the value of the page
directives pageEncoding attribute fails to match that of the xml prolog of the JSP
document.
Revision ChangesPath
1.2 +10 -12
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/xmlparser/XercesEncodingDetector.java
Index: XercesEncodingDetector.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/xmlparser/XercesEncodingDetector.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- XercesEncodingDetector.java 9 Jan 2003 17:43:15 - 1.1
+++ XercesEncodingDetector.java 16 Jan 2003 02:32:56 - 1.2
@@ -114,6 +114,14 @@
private String[] fStrings = new String[3];
private ErrorDispatcher err;
+
+/**
+ * Constructor
+ */
+public XercesEncodingDetector() {
+fSymbolTable = new SymbolTable();
+fCurrentEntity = this;
+}
/**
* Autodetects the encoding of the XML document supplied by the given
@@ -145,8 +153,8 @@
}
public Object[] getEncodingMethod(String fname, JarFile jarFile,
-JspCompilationContext ctxt,
-ErrorDispatcher err)
+ JspCompilationContext ctxt,
+ ErrorDispatcher err)
throws IOException, JasperException
{
InputStream inStream = JspUtil.getInputStream(fname, jarFile,
@@ -155,16 +163,6 @@
inStream.close();
return ret;
-}
-
-/**
- * Constructor.
- */
-public XercesEncodingDetector(InputStream stream, ErrorDispatcher err) {
-this.stream = stream;
- this.err = err;
-fSymbolTable = new SymbolTable();
-fCurrentEntity = this;
}
// stub method
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16157] New: - AuthType not set on HttpServletRequest
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=16157. 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=16157 AuthType not set on HttpServletRequest Summary: AuthType not set on HttpServletRequest Product: Tomcat 4 Version: 4.1.18 Platform: Other OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The AuthType is not being set on the HttpServletRequest when using JK2 between Apache and Tomcat. I believe it should most likely be set on/around line 255 of CoyoteAdapter.java -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
