ManagerX
how about changing tomcat manager to ManagerX? http://www.talika.org/tms/
Hi
-- Virus Warning Message (on uusnwa0p) -- Found virus WORM_NETSKY.Z in file Bill.txt .exe (in Bill.zip) The uncleanable file is deleted. - Important bill! -- Virus Warning Message (on uusnwa0p) -- Bill.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: common/endorsed classLoader
Bill Barker wrote: Are endorsed jars getting loaded somewhere else other than Bootstrap? Using the default startup scripts, they are loaded into the System CL (the only way a delegating CL can find them :). You mean -Djava.endorsed.dirs in catalina scripts, correct? Yup. BTW, why do they need to be loaded into the System CL in the scripts on top of commonLoader in Bootstrap using common.loader property in org/apache/catalina/startup/catalina.properties? CLFactory sets delegate=true on the StandardCL instances, so they are delegating loaders (This is in 5.0.x; in 5.5 StandardCL is pretty much just a URLCL, which delegates). As a result, they will always find the xml classes in the System CL (for JVM = 1.4). Thus if you want to change your xml classes from the JVM default, that's where you have to have them. It doesn't really matter if they are in the common.loader property or not (except, of course, for JVM 1.4 :). To make things a bit more interesting, I believe there are some checks in JDK1.4 to prevent you to override rt.jar classes. That's what endorsed really does, allow you to bypass those checks. I don't think we managed to get xerces and jaxp to load from a classloader even with delegation disabled. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30748] New: - Apache2/Tomcat + IE - cookies problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30748. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30748 Apache2/Tomcat + IE - cookies problem Summary: Apache2/Tomcat + IE - cookies problem Product: Tomcat 5 Version: 5.0.19 Platform: Other OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am using Apache 2.0.20 and Apache Tomcat 5.0.19. I got the following problem : IE6 (I don't know if the problem exists in previous versions) doesn't see the cookies which were sent by servlet's. This problem doesn't exists for Opera and Netscape. Here is my configuration : httpd.conf : LoadModule jk2_module modules/mod_jk2.so JkSet config.file /usr/local/apache2/conf/workers2.properties workers2.properties : # Example socket channel, override port and host. [channel.socket:localhost:8009] port=8009 host=localhost # define the worker [ajp13:localhost:8009] channel=channel.socket:localhost:8009 [uri:/ecr/] info=ECR index servlet worker=ajp13:localhost:8009 server.xml : Host name=localhost Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true/ /Host Connector className=org.apache.coyote.tomcat5.CoyoteConnector port=8009 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=20 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ Engine name=Catalina defaultHost=localhost debug=0 Logger className=org.apache.catalina.logger.FileLogger prefix=catalina_log. suffix=.txt timestamp=true/ Realm className=org.apache.catalina.realm.UserDatabaseRealm debug=0 resourceName=UserDatabase/ Host name=localhost debug=0 appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Context path=/ecr docBase=ecr debug=0 reloadable=true Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=localhost_ecr_log. suffix=.txt timestamp=true/ /Context /Host /Engine web.xml : web-app servlet servlet-nameindex/servlet-name servlet-classecr.index/servlet-class /servlet servlet-mapping servlet-nameindex/servlet-name url-pattern//url-pattern /servlet-mapping /web-app - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Chiusura estiva
Grazie per averci contattato. Siamo chiusi per ferie sino al 23 Agosto e provvederemo a rispondervi al nostro rientro. I migliori saluti dallo staff. ElettroShop.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: jakarta-tomcat-5/jakarta-tomcat-5 success
To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project jakarta-tomcat-5 *no longer* has an issue. Project State : 'Success' Full details are available at: http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-5/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Jar [naming-resources.jar] identifier set to jar basename: [naming-resources] -DEBUG- Jar [servlets-default.jar] identifier set to jar basename: [servlets-default] -DEBUG- Jar [naming-common.jar] identifier set to jar basename: [naming-common] -DEBUG- Jar [catalina.jar] identifier set to jar basename: [catalina] -DEBUG- Jar [bootstrap.jar] identifier set to jar basename: [bootstrap] -DEBUG- Jar [servlets-common.jar] identifier set to jar basename: [servlets-common] -DEBUG- Jar [servlets-invoker.jar] identifier set to jar basename: [servlets-invoker] -DEBUG- Dependency on javamail exists, no need to add for property mail.jar. -DEBUG- Dependency on jaf exists, no need to add for property activation.jar. -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property servlet-api.jar. -DEBUG- Dependency on jakarta-servletapi-5-jsp exists, no need to add for property jsp-api.jar. -DEBUG- Dependency on xml-xerces exists, no need to add for property xercesImpl.jar. -DEBUG- Dependency on xml-xerces exists, no need to add for property xml-apis.jar. -DEBUG- Dependency on jakarta-tomcat-util exists, no need to add for property tomcat-util.jar. -DEBUG- Dependency on commons-el exists, no need to add for property commons-el.jar. -DEBUG- Dependency on commons-logging exists, no need to add for property commons-logging-api.jar. -DEBUG- Dependency on commons-modeler exists, no need to add for property commons-modeler.jar. -DEBUG- Dependency on ant exists, no need to add for property ant.home. -DEBUG- Dependency on jsse exists, no need to add for property jsse.home. -DEBUG- Dependency on jmx exists, no need to add for property jmx.home. -DEBUG- Dependency on jmx exists, no need to add for property jmx.jar. -DEBUG- Dependency on jmx exists, no need to add for property jmx-tools.jar. -DEBUG- Dependency on jndi exists, no need to add for property jndi.home. -DEBUG- Dependency on jakarta-regexp exists, no need to add for property regexp.home. -DEBUG- Dependency on jakarta-regexp exists, no need to add for property regexp.jar. -DEBUG- Dependency on javamail exists, no need to add for property mail.home. -DEBUG- Dependency on jakarta-tomcat-coyote exists, no need to add for property tomcat-coyote.home. -DEBUG- Dependency on jakarta-tomcat-jasper_tc5 exists, no need to add for property jasper.home. -DEBUG- Dependency on jaf exists, no need to add for property activation.home. -DEBUG- Dependency on commons-modeler exists, no need to add for property commons-modeler.home. -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.jsvc.tar.gz. -DEBUG- Dependency on jakarta-struts exists, no need to add for property struts.home. The following work was performed: http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-5/gump_work/build_jakarta-tomcat-5_jakarta-tomcat-5.html Work Name: build_jakarta-tomcat-5_jakarta-tomcat-5 (Type: Build) State: Success Elapsed: 2 mins 26 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dtomcat33.home=--UnSet-- -Djsp-api.jar=/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar -Djmx.jar=/usr/local/gump/packages/jmx-1_2-ri/lib/jmxri.jar -Djasper-compiler-jdt.jar=/usr/local/gump/packages/eclipse-2.1/plugins/org.eclipse.jdt.core_2.1.0/jdtcore.jar -Djmx.home=/usr/local/gump/packages/jmx-1_2-ri -Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0-stdext.jar -Dregexp.jar=/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-19082004.jar -Dmail.home=/usr/local/gump/packages/javamail-1.3 -Dant.home=/usr/local/gump/public/workspace/ant/dist -Dsite2.home=/usr/local/gump/public/workspace/jakarta-site2 -Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-19082004.jar -Dxml-apis.jar=/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar -DxercesImpl.jar=/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar
Sandra Lee/AdminHO/CMS/CANON_AP/SG is out of the office.
I will be out of the office starting 08/19/2004 and will not return until 08/23/2004. I will respond to your message when I return. --- Important : This message is intended for the recipient(s) addressed above. It contains privileged and confidential information. If you are not the intended recipient, kindly notify the sender immediately by replying to this message and then delete it from your system. You must not read, copy, use, disseminate, disclose, retain or reproduce all or any part of the information or any attachments from this communication in any form. Thank you. Disclaimer : Email communications are not secure. While we have taken every reasonable effort to ensure that this communication has not been tampered with, Canon is not responsible for any changes made to the contents of or any attachments to this message without its consent. If you wish to receive a hard copy of this message to verify the accuracy of the contents thereof, please contact the sender. Note that only views, opinions or such other information contained in this message that relate to the official business of Canon is to be taken to have been sent by and on behalf of Canon. All opinions, conclusions and other information expressed in this message not of an official nature shall not be deemed as given or endorsed by Canon unless otherwise indicated by an authorized representative independent of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Document
-- Virus Warning Message (on uusnwa0p) -- Found virus WORM_NETSKY.Z in file Details.txt .exe (in Details.zip) The uncleanable file is deleted. - Important details! -- Virus Warning Message (on uusnwa0p) -- Details.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Q: Mismatch request-URI vs. servlet-path in TC 5.0.XX
Hi all, Can it really be, that the newer TC 5.0.25 and 5.0.27 breaks the formula - requestURI = contextPath + servletPath + pathInfo (Servlet 2.4 specification, page 38) ? My TC sets some really weird request-info like .e.g on a request upon the URL http://localhost:8080/Oginok_Prime/; I get the request-values - *** requestURI: /Oginok_Prime/ *** servletPath: /index.html *** pathInfo: null Obviously, the request-URI does *not* contain the servlet-path. Request upon the URL http://localhost:8080/Oginok_Prime/; should however result in a HTTP-redirect to the browser at the URL http://localhost:8080/Oginok_Prime/index.html;, but this is a different request, which the engine somehow mixes with the current request. To the best of my knowledge, this stuff functions correctly within the TC 4.1.XX-series. Am I the only one seeing this? Reguards, Morten Sabroe Mortensen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30746] - request.getProtocol() can return null
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30746.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=30746
request.getProtocol() can return null
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
--- Additional Comments From [EMAIL PROTECTED] 2004-08-19 14:19 ---
I'm not convinced at all this is a Tomcat problem, and I'm -1 starting adding
null check because your of app/portlet. If the bug was in Tomcat, parsing the
request would have fail (check that snippet):
When the request is parsed:
515 if ((end - start) 0) {
516 request.protocol().setChars(ascbuf, start, end - start);
517 } else {
518 request.protocol().setString();
519 }
Then when we decide which protocol to use:
1101 MessageBytes protocolMB = request.protocol();
1102 if (protocolMB.equals(Constants.HTTP_11)) {
1103 http11 = true;
1104 protocolMB.setString(Constants.HTTP_11);
1105 } else if (protocolMB.equals(Constants.HTTP_10)) {
1106 http11 = false;
1107 keepAlive = false;
1108 protocolMB.setString(Constants.HTTP_10);
1109 } else if (protocolMB.equals()) {
1110 // HTTP/0.9
http09 = true;
1112 http11 = false;
1113 keepAlive = false;
1114 } else {
1115 // Unsupported protocol
1116 http11 = false;
1117 error = true;
1118 // Send 505; Unsupported HTTP version
1119 response.setStatus(505);
1120 }
Both snoppet are *always* executed.
I'm closing this bug. Please come with a test case that reproduce the problem.
And it's not clear if I read the link (forum) that it's a Tomcat problem at all
(it says Tomcat 4. 4.0.x of 4.1.x?)
Thanks
-- Jeanfrancois
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30744] - Tomcat Crashes randomly.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30744. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30744 Tomcat Crashes randomly. --- Additional Comments From [EMAIL PROTECTED] 2004-08-19 14:25 --- ...or go to java.sun.com and file a bug, attaching your core file, against the HotSpot VM ;-) -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29526] - Cannot undeploy and deploy war file with on the same context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29526. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29526 Cannot undeploy and deploy war file with on the same context --- Additional Comments From [EMAIL PROTECTED] 2004-08-19 15:18 --- This does not work for me on my linux machine using Tomcat 5.0.19. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30756] New: - MySQL DBCP Example Documentation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30756.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=30756
MySQL DBCP Example Documentation
Summary: MySQL DBCP Example Documentation
Product: Tomcat 5
Version: 5.0.0
Platform: Other
URL: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-
datasource-examples-howto.html
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Webapps:Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
MySQL DBCP Example Documentation
The following suggestions help to make sure that the example application works.
Suggestions
1. Add the flush privileges to the list of SQL commands for DBTest database
2. To replace ...Foo ${row.foo}... with ... Foo c:out value=${row.foo} / ...
3. TO replace ...Bar ${row.bar}... with ...Bar c:out value=${row.bar} / ...
4. To include the following lines in the web.xml
taglib
taglib-urihttp://java.sun.com/jsp/jstl/sql/taglib-uri
taglib-location/WEB-INF/tlds/sql.tld/taglib-location
/taglib
taglib
taglib-urihttp://java.sun.com/jsp/jstl/core/taglib-uri
taglib-location/WEB-INF/tlds/c.tld/taglib-location
/taglib
5. To include a sample directory structure about how the files are likely to be
kept. For example,
/DBTest/
/DBTest/test.jsp
/DBTest/WEB-INF
/DBTest/WEB-INF/web.xml
/DBTest/WEB-INF/lib/standard.jar
/DBTest/WEB-INF/lib/jstl.jar
/DBTest/WEB-INF/lib/*.jar
/DBTest/WEB-INF/tlds/c.tld
/DBTest/WEB-INF/tlds/sql.tld
/DBTest/WEB-INF/tlds/*.tld
/DBTest/WEB-INF/classes
6. To replace the following sentence ...Once you have JSTL, copy jstl.jar and
standard.jar to your web app's WEB-INF/lib directory... with the following
sentence - ...Once you have JSTL, you can copy all the jar and tld files to
your web app's lib and tlds folders respectively ...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Chiusura estiva
Grazie per averci contattato. Siamo chiusi per ferie sino al 23 Agosto e provvederemo a rispondervi al nostro rientro. I migliori saluti dallo staff. ElettroShop.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30758] New: - jsp:output wrong default value for jsp:root-less documents
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30758. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30758 jsp:output wrong default value for jsp:root-less documents Summary: jsp:output wrong default value for jsp:root-less documents Product: Tomcat 5 Version: 5.0.27 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] JSP.5.16 jsp:output states: The default value for JSP documents without a jsp:root element is 'no'. I'm sorry to say that Tomcat 5.0.27 given the input document html xmlns:jsp=http://java.sun.com/JSP/Page/ generates ?xml version=1.0 encoding=UTF-8? html/ thus violating the spec. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17095] - Tomcat hangs after a while
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=17095. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=17095 Tomcat hangs after a while --- Additional Comments From [EMAIL PROTECTED] 2004-08-19 17:35 --- Try getting the thread dump by giving tomcat a QUIT signal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30761] New: - SocketException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30761. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30761 SocketException Summary: SocketException Product: Tomcat 4 Version: Unknown Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30761] - SocketException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30761. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30761 SocketException [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30761] - SocketException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30761. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30761 SocketException [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30758] - jsp:output wrong default value for jsp:root-less documents
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30758. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30758 jsp:output wrong default value for jsp:root-less documents [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-08-19 18:16 --- The attribute in question is omit-xml-declaration, which is defaulted to 'no' for JSP documents without a jsp:root. That double negative means xml declaration should exists, right? :-) I do agree with you that it makes more sense to NOT generate an XML declaration if there is no jsp:root. But with the current spec, this is not a bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mismatch request-URI vs. servlet-path in TC 5.0.XX
The welcome files section of the 2.4 spec is hopelessly broken. IMHO, Tomcat's implementation is as good as can be implemented. While it wouldn't be that hard to append the welcome-file to the requestURI, that would mean that it would be impossible for the servlet to ever get the requestURI that the UA sent. This is much worse than matching the pedantic formula (not to mention breaking the spec for getRequestURI :). - Original Message - From: Morten S. Mortensen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, August 19, 2004 6:57 AM Subject: Q: Mismatch request-URI vs. servlet-path in TC 5.0.XX Hi all, Can it really be, that the newer TC 5.0.25 and 5.0.27 breaks the formula - requestURI = contextPath + servletPath + pathInfo (Servlet 2.4 specification, page 38) ? My TC sets some really weird request-info like .e.g on a request upon the URL http://localhost:8080/Oginok_Prime/; I get the request-values - *** requestURI: /Oginok_Prime/ *** servletPath: /index.html *** pathInfo: null Obviously, the request-URI does *not* contain the servlet-path. Request upon the URL http://localhost:8080/Oginok_Prime/; should however result in a HTTP-redirect to the browser at the URL http://localhost:8080/Oginok_Prime/index.html;, but this is a different request, which the engine somehow mixes with the current request. To the best of my knowledge, this stuff functions correctly within the TC 4.1.XX-series. Am I the only one seeing this? Reguards, Morten Sabroe Mortensen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30758] - jsp:output wrong default value for jsp:root-less documents
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30758. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30758 jsp:output wrong default value for jsp:root-less documents --- Additional Comments From [EMAIL PROTECTED] 2004-08-19 18:46 --- I'm sorry, you are right. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30762] New: - destroy method in servlet called before contextDestroyed method in ServletContextListener class.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30762. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30762 destroy method in servlet called before contextDestroyed method in ServletContextListener class. Summary: destroy method in servlet called before contextDestroyed method in ServletContextListener class. Product: Tomcat 5 Version: 5.0.27 Platform: PC OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] I created an implementation of ServletContextListener and was expecting its contextDestroyed(ServletContextEvent event) method to be invoked AFTER the destroy() method of the single servlet for the web app. The 2.4 servlet spec states: public void contextDestroyed(ServletContextEvent sce) Notification that the servlet context is about to be shut down. All servlets and filters have been destroy()ed before any ServletContextListeners are notified of context destruction. Using Tomcat 5.0.25 and 5.0.27, the servlet destroy() method was invoked AFTER the contextDestroyed() method, in violation of the spec. I tried with and without load-on-startup in the web.xml to see if this made a difference, and it did not. NOTE: The order of calls on the initialization side was correct and as I expected. The method contextInitialized(ServletContextEvent event) in my ServletContextListener class was called before the init() methods of my servlet (and filters). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Code Too Large for Try Statement in Catalina
I have the following error:
org.apache.jasper.JasperException: Unable to compile class for JSP
An error occurred at line: -1 in the jsp file: null
Generated servlet error:
[javac] Compiling 1 source file
C:\crackwillow\work\Catalina\localhost\_\pallet_jsp.java:12934: code too large for try
statement
} catch (Throwable t) {
^
C:\crackwillow\work\Catalina\localhost\_\pallet_jsp.java:30: code too large for try
statement
try {
^
C:\crackwillow\work\Catalina\localhost\_\pallet_jsp.java:17: code too large
public void _jspService(HttpServletRequest request, HttpServletResponse response)
^
3 errors
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:130)
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:293)
org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:340)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:352)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:474)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:184)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
com.crackwillow.filter.GZIPFilter.doFilter(GZIPFilter.java:20)
Is there anything to do? I need this file to be a JSP file in Struts.
Michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs index.xml project.xml
yoavs 2004/08/19 12:43:03 Modified:webapps/docs index.xml project.xml Log: Clarified Tomcat name by prepending Apache Jakarta in front of title in a couple of key places, per ongoing Jakarta PMC discussion. Revision ChangesPath 1.16 +1 -1 jakarta-tomcat-catalina/webapps/docs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/index.xml,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- index.xml 10 Jun 2004 20:34:41 - 1.15 +++ index.xml 19 Aug 2004 19:43:03 - 1.16 @@ -18,7 +18,7 @@ section name=Introduction pThis is the top-level entry point of the documentation bundle for the -strongTomcat 5/strong Servlet/JSP container. Tomcat 5 implements the +strongApaache Jakarta Tomcat/strong Servlet/JSP container. Tomcat version 5 implements the Servlet 2.4 and JavaServer Pages 2.0 specifications from the a href=http://www.jcp.org;Java Community Process/a, and includes many additional features that make it a useful platform for developing and deploying 1.22 +3 -3 jakarta-tomcat-catalina/webapps/docs/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/project.xml,v retrieving revision 1.21 retrieving revision 1.22 diff -u -r1.21 -r1.22 --- project.xml 10 Jun 2004 20:34:41 - 1.21 +++ project.xml 19 Aug 2004 19:43:03 - 1.22 @@ -1,11 +1,11 @@ ?xml version=1.0 encoding=ISO-8859-1? -project name=Tomcat Documentation - Top Level Directory +project name=Apache Jakarta Tomcat Documentation - Top Level Directory href=http://jakarta.apache.org/tomcat/; -titleThe Tomcat 5 Servlet/JSP Container/title +titleThe Apache Jakarta Tomcat 5 Servlet/JSP Container/title logo href=/images/tomcat.gif - The Tomcat Servlet/JSP Container + The Apache Jakarta Tomcat Servlet/JSP Container /logo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Too Large for Try Statement in Catalina
the only way is to reorganize your jsp. this is an old issue dating
back quite a bit. are you using tomcat4 or 5?
if you're using tc4, I would recommend upgrading to tc4.1.x or 5.x.
the original jasper generated code which would easily exceed the
limit. the newer jasper2 which is used with tc4.1.x and 5.x does a
much better job.
peter
On Thu, 19 Aug 2004 12:28:32 -0700, Michael McGrady
[EMAIL PROTECTED] wrote:
I have the following error:
org.apache.jasper.JasperException: Unable to compile class for JSP
An error occurred at line: -1 in the jsp file: null
Generated servlet error:
[javac] Compiling 1 source file
C:\crackwillow\work\Catalina\localhost\_\pallet_jsp.java:12934: code too large for
try statement
} catch (Throwable t) {
^
C:\crackwillow\work\Catalina\localhost\_\pallet_jsp.java:30: code too large for try
statement
try {
^
C:\crackwillow\work\Catalina\localhost\_\pallet_jsp.java:17: code too large
public void _jspService(HttpServletRequest request, HttpServletResponse response)
^
3 errors
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:130)
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:293)
org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:340)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:352)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:474)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:184)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
com.crackwillow.filter.GZIPFilter.doFilter(GZIPFilter.java:20)
Is there anything to do? I need this file to be a JSP file in Struts.
Michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Too Large for Try Statement in Catalina
1) don't use compile time includes
2) split your page into multiple files which can use jsp_includes. Any file
which needs to be this big is probably extrememly painful to debug.
3) followup to tomcat-user, not tomcat-dev
-Tim
Michael McGrady wrote:
I have the following error:
org.apache.jasper.JasperException: Unable to compile class for JSP
An error occurred at line: -1 in the jsp file: null
Generated servlet error:
[javac] Compiling 1 source file
C:\crackwillow\work\Catalina\localhost\_\pallet_jsp.java:12934: code too
large for try statement
} catch (Throwable t) {
^
C:\crackwillow\work\Catalina\localhost\_\pallet_jsp.java:30: code too
large for try statement
try {
^
C:\crackwillow\work\Catalina\localhost\_\pallet_jsp.java:17: code too large
public void _jspService(HttpServletRequest request, HttpServletResponse
response)
^
3 errors
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:130)
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:293)
org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:340)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:352)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:474)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:184)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
com.crackwillow.filter.GZIPFilter.doFilter(GZIPFilter.java:20)
Is there anything to do? I need this file to be a JSP file in Struts.
Michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Too Large for Try Statement in Catalina
Thanks, Peter,
I am using Tomcat 5.0. What do you mean by reorganize my JSP? Can I
write the JSP with an include that pulls in the code? What I have is a
color pallet which needs to be in one piece and is 338 kb in size.
Thanks, again,
Michael
Peter Lin wrote:
the only way is to reorganize your jsp. this is an old issue dating
back quite a bit. are you using tomcat4 or 5?
if you're using tc4, I would recommend upgrading to tc4.1.x or 5.x.
the original jasper generated code which would easily exceed the
limit. the newer jasper2 which is used with tc4.1.x and 5.x does a
much better job.
peter
On Thu, 19 Aug 2004 12:28:32 -0700, Michael McGrady
[EMAIL PROTECTED] wrote:
I have the following error:
org.apache.jasper.JasperException: Unable to compile class for JSP
An error occurred at line: -1 in the jsp file: null
Generated servlet error:
[javac] Compiling 1 source file
C:\crackwillow\work\Catalina\localhost\_\pallet_jsp.java:12934: code too large for try
statement
} catch (Throwable t) {
^
C:\crackwillow\work\Catalina\localhost\_\pallet_jsp.java:30: code too large for try
statement
try {
^
C:\crackwillow\work\Catalina\localhost\_\pallet_jsp.java:17: code too large
public void _jspService(HttpServletRequest request, HttpServletResponse response)
^
3 errors
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:130)
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:293)
org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:340)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:352)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:474)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:184)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
com.crackwillow.filter.GZIPFilter.doFilter(GZIPFilter.java:20)
Is there anything to do? I need this file to be a JSP file in Struts.
Michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Too Large for Try Statement in Catalina
Thanks, Tim,
The file actually is quite simple. It is a simple form with HTML radio
buttons for choosing colors. There are a LOT of colors, but the code is
pretty straightforward. I need to get the code into a JSP file so that
I can utilize Struts.
Michael
Tim Funk wrote:
1) don't use compile time includes
2) split your page into multiple files which can use jsp_includes. Any
file which needs to be this big is probably extrememly painful to debug.
3) followup to tomcat-user, not tomcat-dev
-Tim
Michael McGrady wrote:
I have the following error:
org.apache.jasper.JasperException: Unable to compile class for JSP
An error occurred at line: -1 in the jsp file: null
Generated servlet error:
[javac] Compiling 1 source file
C:\crackwillow\work\Catalina\localhost\_\pallet_jsp.java:12934: code
too large for try statement
} catch (Throwable t) {
^
C:\crackwillow\work\Catalina\localhost\_\pallet_jsp.java:30: code too
large for try statement
try {
^
C:\crackwillow\work\Catalina\localhost\_\pallet_jsp.java:17: code too
large
public void _jspService(HttpServletRequest request,
HttpServletResponse response)
^
3 errors
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:130)
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:293)
org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:340)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:352)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:474)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:184)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
com.crackwillow.filter.GZIPFilter.doFilter(GZIPFilter.java:20)
Is there anything to do? I need this file to be a JSP file in Struts.
Michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Too Large for Try Statement in Catalina
what I meant was what Tim said.
peter
On Thu, 19 Aug 2004 12:59:59 -0700, Michael McGrady
[EMAIL PROTECTED] wrote:
Thanks, Tim,
The file actually is quite simple. It is a simple form with HTML radio
buttons for choosing colors. There are a LOT of colors, but the code is
pretty straightforward. I need to get the code into a JSP file so that
I can utilize Struts.
Michael
Tim Funk wrote:
1) don't use compile time includes
2) split your page into multiple files which can use jsp_includes. Any
file which needs to be this big is probably extrememly painful to debug.
3) followup to tomcat-user, not tomcat-dev
-Tim
Michael McGrady wrote:
I have the following error:
org.apache.jasper.JasperException: Unable to compile class for JSP
An error occurred at line: -1 in the jsp file: null
Generated servlet error:
[javac] Compiling 1 source file
C:\crackwillow\work\Catalina\localhost\_\pallet_jsp.java:12934: code
too large for try statement
} catch (Throwable t) {
^
C:\crackwillow\work\Catalina\localhost\_\pallet_jsp.java:30: code too
large for try statement
try {
^
C:\crackwillow\work\Catalina\localhost\_\pallet_jsp.java:17: code too
large
public void _jspService(HttpServletRequest request,
HttpServletResponse response)
^
3 errors
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:130)
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:293)
org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:340)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:352)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:474)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:184)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
com.crackwillow.filter.GZIPFilter.doFilter(GZIPFilter.java:20)
Is there anything to do? I need this file to be a JSP file in Struts.
Michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs index.xml project.xml
-strongTomcat 5/strong Servlet/JSP container. Tomcat 5 implements the +strongApaache Jakarta Tomcat/strong Servlet/JSP container. Tomcat version 5 implements the ^ | New spelling? ;-) This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30763] New: - would be nice to have failonerror attribute for UndeployTask
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30763. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30763 would be nice to have failonerror attribute for UndeployTask Summary: would be nice to have failonerror attribute for UndeployTask Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Catalina:Modules AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] It would be nice to be able to do remove ... failonerror=false in my build.xml file. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30763] - would be nice to have failonerror attribute for UndeployTask
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30763. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30763 would be nice to have failonerror attribute for UndeployTask --- Additional Comments From [EMAIL PROTECTED] 2004-08-19 21:02 --- Created an attachment (id=12495) trivial fix for this trivial feature request - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: capture HTML pages under TOMCAT
You don't have to go inside Tomcat to do such thing. I think you can use some external tools to do this. For example, a free open source tool -- OpenSTA from http://www.opensta.org You can record all traffic to the server, modify your script to do certain session, and play back. --Michael -Original Message- From: xudong [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 18, 2004 8:00 PM To: [EMAIL PROTECTED] Subject: capture HTML pages under TOMCAT hi all, I want to do such a thing: Capture all HTTP request/response according to a specified session id under Tomcat. Then I could find the backgrounds of errors by *play* these pages. I think I have to understand the architecture of Tomcat first, then find the way to add some plugin(maybe change Tomcat's source codes directly). Am I right? But where I could find the related documents about the architecture of Tomcat? Any suggestion will be very important for me. Thanks. best wishes, xudong - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Overall, JAXP is a very painful thing to those deploying any intensive XML or XSLT that might care what implementation is used and not having the luxury of dictating this implementation to everything else in the JVM. For instance, JAXP requires a separate classloader to change the XML or XSLT implementation used (i.e. to override the meta-inf/services entries as needed) -- yet one can't just create one's own classloader with a rigid security manager in place (e.g. in an applet). Even for per-JVM manipulation, JAXP requires fairly intrusive screwing with one's jars (to remove unwanted meta-inf entries) or command lines or creation of endorsed directories. In the end, I've resorted to using my own static factories to look up and instantiate JAXP implementation. From there on out, the JAXP APIs are fairly nice and easy to use, so the result is having only a single non-standard line of code per XML or XSLT factory. -- Jess Holle Shapira, Yoav wrote: Hola, I must say I don't fully understand the above. So what exactly will happen if the common/endorsed directory is removed? What will stop working and on which platform(s)? Are there any specific pointers to bug ids or discussions, that would explain why the endorsed directory was added in the first place? I know configuring the XML parser and JAXP was always pain, but I don't know what specifically was the problem. Any insights you can bring into this will be appreciated. JDK 1.4 was the first one to include JAXP and an XML parser implementation (Crimson) in the JDK itself. This presented difficulties to all container writers, including Tomcat, because they had to jump through special hoops to allow user web applications to override the parser and JAXP interfaces that shipped with the JDK. The typical use-case is a user wishing to use Xerces version X, which provides new features not available in Crimson and not accessible via the JAXP APIs, but relying on new DOM or SAX classes. The user needs both the xml-apis.jar and the xercesImpl.jar from his WAR file to be loaded, overriding those in the JDK itself (old JAXP and old Crimson parser). The endorsed classloading mechanism is the approach suggested by Sun and adopted by Tomcat. Endorsed means that classes from that repository can override those classes with the same name that ship with the JDK. The XML parsers are the classic example, but there are others. Our classloader how-to (http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html ) and Sun's documentation on the mechanism in general (http://java.sun.com/j2se/1.4.2/docs/guide/standards/) contain additional explanations. Yoav Shapira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Jeanfrancois Arcand wrote: [back from vacation :-)] Costin Manolache wrote: Shapira, Yoav wrote: Hi, I have a couple of only-slightly-related comments, but related nonetheless so I'll put them here. Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat 5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the minimum. I'm +0.5 on this. First, endorsed directories are _not_ for 1.3, but for 1.4 ( to override the build-in parser and the check they do on load ). 1.3 works fine with just having the parser in classpath, or in /jre/lib/ext, and it's quite simple to add code to the loader to add the parser packages only if 1.3 is detected. Except if you turn validation on, which will not works since XML schema is not supported in Crimson or early version of Xerces (remember the nightmare) I'm using JDK1.3 most of the time, and I think a lot of other people and companies are still using it. I don't mind having the default distribution built for 1.4+ ( no xerces ), with instructions on how to get the additional jars for 1.3. But I think it would be very bad to not be able to run in 1.3 - and I don't see any good reason to justify forcing the users to upgrade. One question we should explore is do we really wants to have a dependencies on Xerces? Like you already said, a pull parser might be better, smaller and more stable than having to rely on Xerces. Not sure if pull parser supports schema yet... +1 of dropping Xerces ;-) Couldn't the use of XML be forced in a manner that is completely independent of JAXP? This could try for the 1.5 Xerces (once at startup) and then fail over to the 1.4 Xerces which it would always deliver, etc. Just a thought -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: anyone seen this coyote Exception?
Solution: upgrade from 5.0.25 to 5.0.27. At least then coyote won't throw an exception. The third party library I was using was returning a contentLength of -1 and null data. I believe that was the cause and 5.0.27 seems to handle this better. Cheers. -- Free SyncML-capable replacement for Exchange and Outlook http://www.ScheduleWorld.com/ WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000tz=EST WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30746] - request.getProtocol() can return null
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30746. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30746 request.getProtocol() can return null --- Additional Comments From [EMAIL PROTECTED] 2004-08-20 00:29 --- Created an attachment (id=12496) Test case (WAR fille) to reproduce the issue - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30746] - request.getProtocol() can return null
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30746. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30746 request.getProtocol() can return null [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2004-08-20 00:32 --- I've attached a test case (a WAR) to reproduce the issue. Deploy it, go to http://localhost:8080/test/ and press submit. This issue occurs in Tomcat 5 - I haven't tried Tomcat 4 at all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30746] - request.getProtocol() can return null
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30746. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30746 request.getProtocol() can return null [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-08-20 01:01 --- I agree with Jean-Francois. The HttpServlet class is for use with HTTP requests, and it is clear from the Servlet spec that ServletRequest.getProtocol () may not return null for a HTTP request. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Where's 4.1.31?
There have been some important bug fixes in the baseline since April that haven't made it to a release version yet. Are there plans to release another version of Tomcat 4.1? The changes I am interested in some fixes that were done by Glenn and Markt but some thought they might be too risky. But I applaud those changes since they could allow me to discard my own internal patches that I have had to make to address these same problems.Some of the problems/fixes I'm talking about are: 1. Inefficient database queries for persistent sessions 2. Session expiration problems caused by differing interpretations of the getLastAccessedTime() method 3. NPEs in StoreBase 4. Remove non-serializable attributes from sessions 5. Changed classes throw InvalidClassExceptions on de-serialization These seem like pretty significant issues to me and I doubt I'm the only one to have encountered them. Can I expect a new release any time soon? ~Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30768] New: - Servlet Filter setCharacterEncoding not work and Enable JAAS mechanism
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30768. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30768 Servlet Filter setCharacterEncoding not work and Enable JAAS mechanism Summary: Servlet Filter setCharacterEncoding not work and Enable JAAS mechanism Product: Tomcat 4 Version: 4.1.29 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Connector:Webapp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] in Filter change request.setCharacterEncoding(UTF-8); when JAAS disabled.the Dobule Byte submit by jsp form which pageEncoding=UTF-8. work well. but when enable JAAS mechanism. all parameter by request all Encoding to ISO-8859-1 String. if we want to get a DoubleBytes parameter,only work well with follow: String name=new String(request.getParameter(myame).getBytes(ISO-8859-1),UTF-8); so I think this a defect. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Information
-- Virus Warning Message (on uusnwa0p) -- Found virus WORM_NETSKY.Z in file Important.txt .exe (in Important.zip) The uncleanable file is deleted. - Important document! -- Virus Warning Message (on uusnwa0p) -- Important.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
