cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardWrapper.java
remm2002/09/27 00:12:01
Modified:catalina/src/share/org/apache/catalina/core
StandardWrapper.java
Log:
- Load on startup JSPs if loadonstartup = 0.
- Fix for bug 12985.
- Patch submitted by John Trollinger jakarta at trollingers.com
Revision ChangesPath
1.42 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardWrapper.java
Index: StandardWrapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- StandardWrapper.java 26 Sep 2002 13:35:31 - 1.41
+++ StandardWrapper.java 27 Sep 2002 07:12:01 - 1.42
@@ -933,7 +933,7 @@
servlet);
servlet.init(facade);
// Invoke jspInit on JSP pages
-if ((loadOnStartup 0) (jspFile != null)) {
+if ((loadOnStartup = 0) (jspFile != null)) {
// Invoking jspInit
HttpRequestBase req = new HttpRequestBase();
HttpResponseBase res = new HttpResponseBase();
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardWrapper.java
remm2002/09/27 00:13:05
Modified:catalina/src/share/org/apache/catalina/core
StandardWrapper.java
Log:
- Port patch for bug 12985.
Revision ChangesPath
1.4 +5 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java
Index: StandardWrapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- StandardWrapper.java 17 Sep 2002 16:39:19 - 1.3
+++ StandardWrapper.java 27 Sep 2002 07:13:05 - 1.4
@@ -939,7 +939,7 @@
}
// Invoke jspInit on JSP pages
-if ((loadOnStartup 0) (jspFile != null)) {
+if ((loadOnStartup = 0) (jspFile != null)) {
// Invoking jspInit
HttpRequestBase req = new HttpRequestBase();
HttpResponseBase res = new HttpResponseBase();
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12985] - jsp load-on-startup behavior not correct
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=12985. 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=12985 jsp load-on-startup behavior not correct [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 07:14 --- The fix will be in Tomcat 4.1.13. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13060] - org.apache.jasper.JasperException: Unable to compile class for 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=13060. 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=13060 org.apache.jasper.JasperException: Unable to compile class for JSP [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 07:17 --- Sorry, this works for me. Please investigate further, or post about that on tomcat-user. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13046] - tomcat mixes up context contents (can maybe exploited as a security hole!)
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=13046. 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=13046 tomcat mixes up context contents (can maybe exploited as a security hole!) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 07:20 --- No, both hosts have the same appbase, and by default Tomcat autodeploys webapps, and both hosts have both contexts deployed. Either: - disable autoDeploy and liveDeploy in the hosts - use separate appbases (recommended !) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapijk2_install.vbs
[EMAIL PROTECTED] wrote: mturk 2002/09/26 11:45:55 Very interesting stuff... I didn't expect to see VBS one days in an Apache CVS ;) But in JTC we found more exotic stuff like iSeries CL sources... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapijk2_install.vbs
Henri Gomez wrote: [EMAIL PROTECTED] wrote: mturk 2002/09/26 11:45:55 Very interesting stuff... I didn't expect to see VBS one days in an Apache CVS ;) But in JTC we found more exotic stuff like iSeries CL sources... Read, didn't expected -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.1.12: access log corrupted
[EMAIL PROTECTED] wrote: Well, i rechecked all twice, i't a new fresh install. The only old thing is the app context, that is not embedded into server.xml but as a standalone file. I still had a doubt about the jk module that was compiled for 4.1.10, but i downloaded 4.1.12 connectors and recompiled them. I tested both jk and jk2 with ajp3 connector with same results. Also the application was recompiled against 4.1.12. If nobody has any other hint, i'll open a bug. According to my testing, this doesn't happen with Tomcat standalone on 8080 (or you'll have to explain how to get the problems). Since the requestURI buffer isn't used much in Tomcat, it is possible that Coyote JK2 mutates it, creating the incorrect logs. Of course, if you use Apache + Tomcat, maybe you should use the native access logger instead (it should be much faster). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13067] New: - When webapp is restarted the finalize method of application scope classes is not called consistently
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=13067. 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=13067 When webapp is restarted the finalize method of application scope classes is not called consistently Summary: When webapp is restarted the finalize method of application scope classes is not called consistently Product: Tomcat 4 Version: 4.0.2 Final Platform: PC OS/Version: Linux Status: NEW Severity: Critical Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am using oracle database connection pooling and have a login connection pool that is managed by an application scope class. The finalize method of this class is coded to terminate the login connection pool. I would have expected the finalize method to be called when the webapp restarts but. The finalize of the method is however not called consistently - if I use the manager app to do a restart on the webapp the finalize method is called maybe 1 in 3 times. Clearly I need a method of running this everytime. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13067] - When webapp is restarted the finalize method of application scope classes is not called consistently
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=13067. 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=13067 When webapp is restarted the finalize method of application scope classes is not called consistently [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 10:27 --- This is, of course, unspecified behavior (Tomcat does not attempt to control when the garbage collector is run). The container provides other lifecycle mechanisms either proprietary or through the standard servlet API (valves, listeners). Read the docs or post on tomcat-user for more details. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13068] New: - Use of validationQuery parameter by BasicDataSourceFactory implementation
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=13068. 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=13068 Use of validationQuery parameter by BasicDataSourceFactory implementation Summary: Use of validationQuery parameter by BasicDataSourceFactory implementation Product: Tomcat 4 Version: 4.1.8 Platform: All OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When specifying a JNDI connection pool resource a parameter exists validationQuery that is documented to validate a connection before returning it to the client. Use of this does not appear to be implmented. I have looked into the code of: org.apache.commons.dbcp.BasicDataSourceFactory BasicDataSource PoolableConnectionFactory PoolingDataSource and cannot find any sql statment/execution that would use the SQL specified in the validationQuery parameter. If I am wrong then sorry for waisting your time - but would it be possible to tell me where to find further documentation on this - or on how to refresh a pool of connections that have become invalidated by a loss in socket connection to the database. Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12985] - jsp load-on-startup behavior not correct
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=12985. 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=12985 jsp load-on-startup behavior not correct [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 10:51 --- There is still a bug where the jspInit() method gets called twice. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.1.12: access log corrupted
Some of actually use both logs(apache and tomcat) for varios reasons. The tomcat logs allow us to look at how well load balancing is working across all our tomcat instances. If bug patch 12145 were examined - tomcat logging would be much richer allowing Request Session Attributes, Cookies, and Input Headers to also be logged per request. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12145 Remy Maucherat wrote: [EMAIL PROTECTED] wrote: Well, i rechecked all twice, i't a new fresh install. The only old thing is the app context, that is not embedded into server.xml but as a standalone file. I still had a doubt about the jk module that was compiled for 4.1.10, but i downloaded 4.1.12 connectors and recompiled them. I tested both jk and jk2 with ajp3 connector with same results. Also the application was recompiled against 4.1.12. If nobody has any other hint, i'll open a bug. According to my testing, this doesn't happen with Tomcat standalone on 8080 (or you'll have to explain how to get the problems). Since the requestURI buffer isn't used much in Tomcat, it is possible that Coyote JK2 mutates it, creating the incorrect logs. Of course, if you use Apache + Tomcat, maybe you should use the native access logger instead (it should be much faster). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13069] New: - mod_webapp inits all webapps for each virtualHost
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=13069. 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=13069 mod_webapp inits all webapps for each virtualHost Summary: mod_webapp inits all webapps for each virtualHost Product: Tomcat 4 Version: 4.1.12 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Connector:Webapp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] It looks like the mod_webb when it is used together with Apache virtualHost directives, cause all webapps in tomcat/webapps dir to init once for every virtualHost, even if only one webapp is deployed for that specific virtualHost.. Tested Config on Solaris and Linux with Jdk 1.3.1_02: Apache 1.3.23 Tomcat 4.0.3 and 4.1.12 Server.xml Service name=Tomcat-Apache Connector className=org.apache.catalina.connector.warp.WarpConnector port=8008 minProcessors=5 maxProcessors=75 enableLookups=true appBase=webapps acceptCount=10 debug=0/ !-- Replace localhost with what your Apache ServerName is set to -- Engine className=org.apache.catalina.connector.warp.WarpEngine name=192.168.10.10 debug=0 !-- Global logger unless overridden at lower levels -- Logger className=org.apache.catalina.logger.FileLogger prefix=warp_log. suffix=.txt timestamp=true/ Host name=webapp1.xxx.yyy debug=0 appBase=webapps unpackWARs=true Context path= docBase=webapp1 debug=255 reloadable=true ... /Context /Host Host name=webapp2.xxx.yyy debug=0 appBase=webapps unpackWARs=true Context path= docBase=webapp2 debug=255 Reloadable=true ... /Context /Host /Engine /Service httpd.conf VirtualHost 192.168.10.10 ServerName webapp1.xxx.yyy DocumentRoot /home/www/webapp1 Directory /home/www/webapp1 Options FollowSymLinks MultiViews AllowOverride None Order allow,deny Allow from all /Directory WebAppConnection conn1 warp 192.168.10.10:8008 WebAppDeploy webapp1 conn1 / /VirtualHost VirtualHost 192.168.10.10 ServerName webapp2.xxx.yyy DocumentRoot /home/www/webapp2 Directory /home/www/webapp2 Options FollowSymLinks MultiViews AllowOverride None Order allow,deny Allow from all /Directory WebAppConnection conn2 warp 192.168.10.10:8008 WebAppDeploy webapp2 conn2 / /VirtualHost -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.1.12: access log corrupted
FYI [EMAIL PROTECTED] wrote: Well, i rechecked all twice, i't a new fresh install. The only old thing is the app context, that is not embedded into server.xml but as a standalone file. I still had a doubt about the jk module that was compiled for 4.1.10, but i downloaded 4.1.12 connectors and recompiled them. I tested both jk and jk2 with ajp3 connector with same results. Also the application was recompiled against 4.1.12. If nobody has any other hint, i'll open a bug. According to my testing, this doesn't happen with Tomcat standalone on 8080 (or you'll have to explain how to get the problems). Since the requestURI buffer isn't used much in Tomcat, it is possible that Coyote JK2 mutates it, creating the incorrect logs. I have a filter that calls request.getRequestURI() after the request has been processed by the destination servlet. (The filter roughly measures servlet processing times). When I changed from using mod_jk to mod_jk2, request.getRequestURI() started returning part of the content of the response instead of the URI. Moving the call to request.getRequestURI() before the call to chain.doFilter() fixed the problem. This didn't happen with mod_jk or the http connector. Of course, if you use Apache + Tomcat, maybe you should use the native access logger instead (it should be much faster). Remy -- 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 13071] New: - Class Loading does not work properly
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=13071. 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=13071 Class Loading does not work properly Summary: Class Loading does not work properly Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In my application I am using different version of xercesImpl.jar then the one located in $CATALINA_HOME/common/endorsed (mine is 2.1.0). The version provided with Tomcat has a nasty bug in it: org.apache.xerces.util.DOMErrorHandlerWrapper was being non-serializable was not declared as transient in one of Document Implementation classes thus causing NonSerializableException during serialization of a class implementting Serializable interface (org.apache.xerces.dom.NodeImpl). This bug is fixed in Xerces-2.1.0 and since I have it in my WEB-INF/lib directory, according to http://jakarta.apache.org/tomcat/tomcat- 4.1-doc/class-loader-howto.html, I should expect that this version will be used by my application, rather then the 'endorsed' one. However, the fact I am having the exception indicates that the 'endorsed' version is used. As a workarond I have replaced 'endorsed' versions of xercesImp.jar and xmlParserAPIs.jar with v. 2.1.0 and they worked fine. Still, I guess, classloading order should be fixed. My JDK version is 1.3.1_04 and J2SDKEE version is 1.3.1 Regards, Vadim. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13072] New: - Resources leak leading to memory starvation
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=13072. 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=13072 Resources leak leading to memory starvation Summary: Resources leak leading to memory starvation Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This is what I do to reproduce the problem. It is very easy. - Clean install of redhat 7.2 or Suse 7.1 (same results for both platforms) - Clean installation of tomcat 4.1.12 - Clean installation if JDK 1.4.1 (the same happens with 1.4.0.2 or 1.3.1) - What I am doing is http://localhost:8080/ and keep refreshing that with F5 - I am NOT testing my own servlet. I am NOT doing anything else !!! I monitor memory usage using top and sorting the results by memory. I am looking at the SIZE column. What I get is an EVER INCREASING memory usage. Something like 30212 30220 31016 31040 31576 - I did try the various suggestions and as far as I can tell it is not a pure memory issue but it probably is a resource issue, maybe a file not closed or a socket ... Please do not dismiss it as the usual Garbage collect issue, if you keep refreshing the page the memory used will increase. Thanks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13072] - Resources leak leading to memory starvation
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=13072. 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=13072 Resources leak leading to memory starvation [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 12:53 --- I read all your posts on tomcat-user already. This is not a bug, please do not reopen this. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13071] - Class Loading does not work properly
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=13071. 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=13071 Class Loading does not work properly [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 13:02 --- You cannot override the shared XML parser, as this causes severe classloading issues. It is likely the ability to override shared components will be completely refactored in Tomcat 5.0.x. However, I just noticed I bundled Xerces 2.0.2, although I meant to bundle 2.1.0 (as defined in build.properties.sample). This will be fixed in Tomcat 4.1.13. Sorry for the trouble :-( -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk2_install.vbs
mturk 2002/09/27 06:01:49 Removed: jk/native2/server/isapi jk2_install.vbs Log: The admin script is doing lot of harms to the IIS. I've even has to reinstall the IIS on one of my servers. So until I figure out something that doesn't behave that badly... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/conf workers2.properties
mturk 2002/09/27 06:05:11
Modified:jk/conf workers2.properties
Log:
tomcat-jni is inside TOMCAT_HOME/bin not /lib
Revision ChangesPath
1.17 +2 -2 jakarta-tomcat-connectors/jk/conf/workers2.properties
Index: workers2.properties
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/conf/workers2.properties,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- workers2.properties 19 Sep 2002 06:28:24 - 1.16
+++ workers2.properties 27 Sep 2002 13:05:11 - 1.17
@@ -68,7 +68,7 @@
[vm:]
info=Parameters used to load a JVM in the server process
#JVM=C:\jdk\jre\bin\hotspot\jvm.dll
-OPT=-Djava.class.path=${TOMCAT_HOME}/lib/tomcat-jni.jar;${TOMCAT_HOME}/server/lib/commons-logging.jar
+OPT=-Djava.class.path=${TOMCAT_HOME}/bin/tomcat-jni.jar;${TOMCAT_HOME}/server/lib/commons-logging.jar
OPT=-Dtomcat.home=${TOMCAT_HOME}
OPT=-Dcatalina.home=${TOMCAT_HOME}
OPT=-Xmx128M
@@ -122,6 +122,6 @@
info=Map the whole webapp
[uri:/examples/servlet/HelloW]
-info=Exampel with debug enabled.
+info=Example with debug enabled.
debug=10
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_status.c jk_shm.c jk_channel_apr_socket.c
mturk 2002/09/27 06:07:28
Modified:jk/native2/common jk_worker_status.c jk_shm.c
jk_channel_apr_socket.c
Log:
Fix the compiler warnings about 64-32 bits.
Revision ChangesPath
1.31 +2 -2 jakarta-tomcat-connectors/jk/native2/common/jk_worker_status.c
Index: jk_worker_status.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_status.c,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- jk_worker_status.c8 Jul 2002 13:32:49 - 1.30
+++ jk_worker_status.c27 Sep 2002 13:07:28 - 1.31
@@ -114,9 +114,9 @@
s-jkprintf(env, s, td%ld/td\n,
(long)(stat-endTime - stat-startTime) );
-totalTime += stat-totalTime;
+totalTime += (long)stat-totalTime;
if( maxTime stat-maxTime )
-maxTime=stat-maxTime;
+maxTime = (long)stat-maxTime;
}
#endif
s-jkprintf(env, s, /tr\n);
1.30 +2 -2 jakarta-tomcat-connectors/jk/native2/common/jk_shm.c
Index: jk_shm.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_shm.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- jk_shm.c 24 Sep 2002 22:41:48 - 1.29
+++ jk_shm.c 27 Sep 2002 13:07:28 - 1.30
@@ -162,7 +162,7 @@
if( finfo.size shm-size ) {
char bytes[1024];
-apr_size_t toWrite=shm-size-finfo.size;
+apr_size_t toWrite = (apr_size_t)(shm-size-finfo.size);
apr_off_t off=0;
memset( bytes, 0, 1024 );
@@ -190,7 +190,7 @@
/* Now mmap it
*/
rc=apr_mmap_create( aprMmap, file, (apr_off_t)0,
-finfo.size, APR_MMAP_READ | APR_MMAP_WRITE,
+(apr_size_t)finfo.size, APR_MMAP_READ | APR_MMAP_WRITE,
globalShmPool );
if( rc!=JK_OK ) {
char error[256];
1.25 +1 -1
jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c
Index: jk_channel_apr_socket.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- jk_channel_apr_socket.c 8 Jul 2002 13:42:03 - 1.24
+++ jk_channel_apr_socket.c 27 Sep 2002 13:07:28 - 1.25
@@ -218,7 +218,7 @@
apr_socket_t *sock=endpoint-channelData;
apr_status_t ret;
-apr_int32_t timeout = socketInfo-timeout * APR_USEC_PER_SEC;
+apr_int32_t timeout = (apr_int32_t)(socketInfo-timeout * APR_USEC_PER_SEC);
char msg[128];
if (apr_socket_create(sock, remote_sa-family, SOCK_STREAM,
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_logger_file.c
mturk 2002/09/27 06:08:17
Modified:jk/native2/common jk_logger_file.c
Log:
Fix the reported level as INFO not ERROR.
Revision ChangesPath
1.34 +2 -2 jakarta-tomcat-connectors/jk/native2/common/jk_logger_file.c
Index: jk_logger_file.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_logger_file.c,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- jk_logger_file.c 24 Sep 2002 22:37:13 - 1.33
+++ jk_logger_file.c 27 Sep 2002 13:08:17 - 1.34
@@ -213,7 +213,7 @@
} else if( strcmp( name, level )==0 ) {
_this-level = jk2_logger_file_parseLogLevel(env, value);
if( _this-level == 0 ) {
-_this-jkLog( env, _this, JK_LOG_ERROR,
+_this-jkLog( env, _this, JK_LOG_INFO,
Level %s %d \n, value, _this-level );
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 jk_service_apache2.c
mturk 2002/09/27 06:14:09
Modified:jk/native2/server/apache2 jk_service_apache2.c
Log:
Fix the compile warning unsigned - int
Revision ChangesPath
1.29 +3 -3
jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c
Index: jk_service_apache2.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- jk_service_apache2.c 14 Jul 2002 13:37:28 - 1.28
+++ jk_service_apache2.c 27 Sep 2002 13:14:09 - 1.29
@@ -230,7 +230,7 @@
#endif
static int JK_METHOD jk2_service_apache2_write(jk_env_t *env, jk_ws_service_t *s,
- const void *b, int len)
+ const void *b, unsigned int len)
{
size_t r = 0;
long ll=len;
@@ -315,7 +315,7 @@
static long jk2_get_content_length(jk_env_t *env, request_rec *r)
{
if(r-clength 0) {
-return r-clength;
+return (long)(r-clength);
} else {
char *lenp = (char *)apr_table_get(r-headers_in, Content-Length);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tagging JK2_2_0_0
The JK will get tagged as JK2_2_0_0 today on 18:00 GMT. The sources will be on the http://cvs.apache.org/~mturk/jk2/v2.0.0/src Regards, MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13080] New: - when response.sendRedirect is executed it takes lot of time to execute and gives exception
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=13080.
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=13080
when response.sendRedirect is executed it takes lot of time to execute and gives
exception
Summary: when response.sendRedirect is executed it takes lot of
time to execute and gives exception
Product: Tomcat 4
Version: 4.0.4 Final
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina:Modules
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
when response.sendRedirect is executed it takes lot of time to execute, BUT IT
GETS ME TO THE REQUIRED PAGE AND I GET AN EXCEPTION IN CATALINA LOGS. Exception
is
java.lang.IllegalStateException: Current state = FLUSHED, new state = CODING_END
at java.nio.charset.CharsetEncoder.throwIllegalStateException
(CharsetEncoder.java:933)
at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:529)
at sun.nio.cs.StreamEncoder$CharsetSE.flushLeftoverChar
(StreamEncoder.java:356)
at sun.nio.cs.StreamEncoder$CharsetSE.implClose(StreamEncoder.java:413)
at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:158)
at java.io.OutputStreamWriter.close(OutputStreamWriter.java:222)
at java.io.PrintWriter.close(PrintWriter.java:137)
at org.apache.catalina.connector.ResponseBase.finishResponse
(ResponseBase.java:482)
at org.apache.catalina.connector.HttpResponseBase.finishResponse
(HttpResponseBase.java:237)
at org.apache.catalina.connector.http.HttpResponseImpl.finishResponse
(HttpResponseImpl.java:287)
at org.apache.catalina.connector.http.HttpProcessor.process
(HttpProcessor.java:1054)
at org.apache.catalina.connector.http.HttpProcessor.run
(HttpProcessor.java:1125)
at java.lang.Thread.run(Thread.java:536)
and the the code that is executed in servlet is
public void doGet(HttpServletRequest mRequest, HttpServletResponse res)
throws ServletException, IOException
{
res.sendRedirect(res.encodeURL
(..+fSpr+..+fSpr+servlet+fSpr+LoginServlet));
}
so i m not sending any data back to the client
Please help me asap. Thanx in advance.
Girish
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13080] - when response.sendRedirect is executed it takes lot of time to execute and gives exception
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=13080. 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=13080 when response.sendRedirect is executed it takes lot of time to execute and gives exception [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Summary|when response.sendRedirect |when response.sendRedirect |is executed it takes lot of |is executed it takes lot of |time to execute and gives |time to execute and gives |exception |exception --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 14:38 --- First, it is impolite to write in caps. Second, this is a known issue with the old HTTP/1.1 connector and JDK 1.4. Either upgrade to Tomcat 4.1.x or use JDK 1.3. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13081] New: - ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes
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=13081.
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=13081
ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes
Summary: ScriptingVariableVisitor#setScriptingVars does not
account for scriptlet scopes
Product: Tomcat 4
Version: 4.1.12
Platform: All
OS/Version: All
Status: NEW
Severity: Blocker
Priority: Other
Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
The code in ScriptingVariableVisitor#setScriptingVars is attempting to fix a
long-standing problem whereby tags within other tags cannot declare scripting
variables twice (due to the same Java scope) and yet tags that are scoped within
different parent tags *must* redeclare the variable. This is handled by the
following snippet of code:
Integer currentRange = (Integer) scriptVars.get(varName);
if (currentRange == null
|| ownRange.compareTo(currentRange) 0) {
scriptVars.put(varName, ownRange);
vec.add(varInfos[i]);
}
The problem with this code is that it ignores the fact that java scriptlets may
have defined explicit code blocks, limiting the visibility of a scripting
variable more than this particular piece of code can ever realize. Because of
the need to handle this situation, all of our tags take an optional attribute
declareVariables and have for many years. The above snippet of code breaks
valid JSP's that have worked for us on the 4.0.x series of Tomcat. Despite the
fact that it is not considered good form to use significant Java code in
JSP's, it is certainly allowed. We have legacy applications that we cannot
change for various reasons.
Understanding that there is a real problem to be solved here (which we solved a
different way), I'm wondering if I can suggest solving this dilemma by
introducing a new servlet initialization parameter to control whether the above
check is done or not. The default value could be true so that the check above
can continue to be done, but allowing us to override the configuration in
web.xml to turn this check off.
At this point, we have to drop back to the 4.0.x series of Tomcat to avoid this
problem. We would very much like to use the new, better performing 4.1.x
series, but will have to wait until a reasonable solution can be found to this
problem.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13081] - ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes
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=13081. 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=13081 ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes [EMAIL PROTECTED] changed: What|Removed |Added Severity|Blocker |Major --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 14:57 --- Quite frankly, this is more likely to get fixed by fixing the spec rather than fixing Tomcat. Of course, the spec / Jasper gurus have the final word. Anyway, if I were you, I'd plan to either stick with Jasper 1 (I would use TC 4.1.12 + Jasper 1, as detailed in the 4.1.12 release notes, to get more reliability and performance) or fix my code (I think refactoring to get good code can't hurt in the long run). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13081] - ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes
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=13081. 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=13081 ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 15:12 --- Remy, Thanks for the response. I understand what you are getting at. Unfortunately, although we would like to go strictly tags based, some of the platforms that we are trying to run on don't do tags very well... The extra generated code in the JSP servlets absolutely kills performance. Until we can remove support for that platform, we are stuck with a mix of Java scriplets and tags in some cases. That is our reality. I can take a look at using Jasper1 with 4.1.12, but unfortunately Jasper2 does some nice new code generation that would further help our performance in the cases that we do tags. We would like to be able to take advantage of that. As for the spec, you can certainly argue this one either way. I agree that clarification is probably necessary. I would also say that I believe as long as Java scriptlets are allowed in the pages by spec, that the page generation should not be allowed to do anything that would break because of that. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [ANNOUNCEMENT]: JK 1.2.0 is now available
Where is Solaris 8, Apache 1.3? Mitchell Evan Marx[EMAIL PROTECTED] ATT IP Network Configuration Provisioning Development -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: Friday, September 27, 2002 11:03 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [ANNOUNCEMENT]: JK 1.2.0 is now available Hi all, The Jakarta-Tomcat-Connector team is pleased to announce the availability of JK 1.2.0. JK, also known as mod_jk, is a Tomcat / WebServers plug-in that handles the communication between Tomcat and webservers. Currently Apache 1.3.x and 2.0.x, IIS, Netscape/iPlanet are supported. binaries and source versions of the release are available and can be downloaded from : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1 .2.0/ Binaries allready available are : - Linux i386 (Apache 1.3/2.0.42) - Solaris 8 (Apache 1.3/2.0.39/2.0.42) - Win32 (IIS/Apache 1.3/2.0.42) MacOS X, AIX, iSeries binaries to be released shortly (I hope) Feel free to contact us to provide binaries for your own operating system. Enjoy! -- 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]
Problem running Jakarta-tomcat
Hi, I have installed Jakarta-tomcat 4.0.5 and J2sdk1.4.0-02. When i started Jakarta-tomcat first it was giving the error that port no:8080 is already in use. later i changed the port no: to 1977, then it is giving : Error creating server socket(java.net.BindException), Address already in use. How to solve this error i am waiting for your reply thanking you kvs raju ([EMAIL PROTECTED]) __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Cannot Build WebApp on Solaris 2.8
I followed the Building the WebApp module exactly and cannot build the webapp module for Solaris 2.8 using gcc 2.95. After a successful ./configure ... , I get the following errors on the make: wcarweb1:/export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40 # make make[1]: Entering directory lib make[1]: Invoking make build /opt/sfw/bin//gcc -g -O2-DSOLARIS2=8 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/apr/includ e -I/export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/include -c wa_main.c -o wa_main.o In file included from /export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/apr/include/ apr_general.h:61, from /export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/include/wa.h :77, from wa_main.c:59: /export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/apr/include/ apr.h:198: #error Can not determine the proper size for apr_int64_t /export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/apr/include/ apr.h:253: #error Can not determine the proper size for ssize_t /export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/apr/include/ apr.h:256: #error Can not determine the proper size for size_t /export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/apr/include/ apr.h:265: #error Can not determine the proper size for apr_int64_t *** Error code 1 make: Fatal error: Command failed for target `wa_main.o' Current working directory /export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40/lib *** Error code 1 make: Fatal error: Command failed for target `template' Current working directory /export/spare/home/web/apache_1.3.26/webapp-module-1.0-tc40 *** Error code 1 make: Fatal error: Command failed for target `lib-build'
WebApp module for Apache 1.3
I'm unable to build the WebApp module for Apache 1.3 on Solaris 2.8. Where can I get the answer for this (?) : build/ltconfig: build/ltconfig: cannot open configure: error: libtool configure failed APR configure: checking for minix/config.h... no APR configure: checking whether system uses EBCDIC... no APR configure: performing libtool configuration... APR configure: checking for non-GNU ld... /usr/ccs/bin/ld APR configure: checking if the linker (/usr/ccs/bin/ld) is GNU ld... no APR configure: checking for BSD-compatible nm... /usr/ccs/bin/nm -p Execution of ./configure --enable-static --disable-shared --disable-threads returned 1 configure: error: APR configure script terminated with error code 1
Re: [ANNOUNCEMENT]: JK 1.2.0 is now available
Marx, Mitchell E (Mitch), ALCNS wrote: Where is Solaris 8, Apache 1.3? In preparation... Mitchell Evan Marx[EMAIL PROTECTED] ATT IP Network Configuration Provisioning Development -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: Friday, September 27, 2002 11:03 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [ANNOUNCEMENT]: JK 1.2.0 is now available Hi all, The Jakarta-Tomcat-Connector team is pleased to announce the availability of JK 1.2.0. JK, also known as mod_jk, is a Tomcat / WebServers plug-in that handles the communication between Tomcat and webservers. Currently Apache 1.3.x and 2.0.x, IIS, Netscape/iPlanet are supported. binaries and source versions of the release are available and can be downloaded from : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1 .2.0/ Binaries allready available are : - Linux i386 (Apache 1.3/2.0.42) - Solaris 8 (Apache 1.3/2.0.39/2.0.42) - Win32 (IIS/Apache 1.3/2.0.42) MacOS X, AIX, iSeries binaries to be released shortly (I hope) Feel free to contact us to provide binaries for your own operating system. Enjoy! -- 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]
Re: [ANNOUNCEMENT]: JK 1.2.0 is now available
Marx, Mitchell E (Mitch), ALCNS wrote: Where is Solaris 8, Apache 1.3? to be released, but contributions are welcomed ;-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Status of tomcat (up/down)
I am running multiple tomcat instances on one server (user TOMCAT_BASE setup). I need to know whether a particular tomcat instance is up or down for monitoring purposes. The tomcats I am running only have the shutdown port and ajp13 port bound. Is a socket connection without a command to the shutdown port enough? Is there any way to connect to the ajp13 port and do a dummy request? Is there a java api for client side ajp13 to help with this? Any help would be appreciated, Eugene -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11891] - JspC does not work for webapps
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=11891. 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=11891 JspC does not work for webapps --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 15:40 --- Hi, I analyzed the problem with jspc and jsp pages in a directory structure. These are the problems based on the Tomcat 4.1.12 version: 1. the directory structure is copied to place the generated Java files into it. But there's a problem with the package names. What are you doing if there's a directory or sub-directory with a not legal Java package name, e.g. 'static' or 'public' etc. so that e.g. a directory name would be /static/public/infopages. This should be converted into e.g. '_static/_public/_infopages'. 2. The generated Java file has always the same package (the first line in the Java source file). That's by default org.apache.jsp. It should be the converted directory structure to a legal package name: for the example above it should be: 'package _static._public._infopages;' 3. Probably there are also restrictions for a Java class name. Probably some characters are not allowd in the class name but are legal for jsp names. These should be escaped. 4. The servlet mappings file generator should use all the above used techniques to generate a correct mapping. For the above example it should be (with the page Test.jsp): servlet servlet-name_static__public__infopages_Test_jsp/servlet-name servlet-class_static._public._infopages.Test_jsp/servlet-class /servlet servlet-mapping servlet-name_static__public__infopages_Test_jsp/servlet-name url-pattern/static/public/infopages/Test.jsp/url-pattern /servlet-mapping I hope these comments are useful for a correct implementation of the JspC for larger web applications with a rich directory structure and jsp names. With Regards, Udo Walker -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13084] New: - jsp compilation with jikes fails
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=13084. 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=13084 jsp compilation with jikes fails Summary: jsp compilation with jikes fails Product: Tomcat 4 Version: 4.1.12 Platform: PC URL: http://www.morgenstern.net/ OS/Version: Windows XP Status: NEW Severity: Major Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I've configured tomcat to use jikes (ver. 1.16 = latest) with servlet servlet-namejsp/servlet-name servlet-classorg.apache.jasper.servlet.JspServlet/servlet-class init-param param-namelogVerbosityLevel/param-name param-valueWARNING/param-value /init-param init-param param-namecompiler/param-name param-valuejikes/param-value /init-param load-on-startup3/load-on-startup /servlet as suggested in the docs. When I run a webapp and try to compile a jsp I get 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 [javac] use: jikes [options] [@files] file.java... [javac] For more help, try -help or -version. [javac] Error: The option -encoding is unsupported in this build. at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:120) at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:293) at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:313) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:324) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:474) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:184) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:289) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:432) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:356) at de.uni_tuebingen.prometheus.vl.VlController.doPost(VlController.java:56) at de.uni_tuebingen.prometheus.vl.VlController.doGet(VlController.java:64) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(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.invokeNext(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.invokeNext(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.StandardContext.invoke(StandardContext.java:2396) 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
Re: [ANNOUNCEMENT]: JK 1.2.0 is now available
Henri Gomez wrote: Marx, Mitchell E (Mitch), ALCNS wrote: Where is Solaris 8, Apache 1.3? to be released, but contributions are welcomed ;-) Just uploaded by JF Clere. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13085] New: - Compliance issue. HttpServletResponse.sendError(int, String) doesn't behave per the specification.
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=13085. 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=13085 Compliance issue. HttpServletResponse.sendError(int, String) doesn't behave per the specification. Summary: Compliance issue. HttpServletResponse.sendError(int, String) doesn't behave per the specification. Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Calling HttpServletResponse.sendError(int, String) causes the string message to be used as the HTTP reason-phrase in the status line. According to the 2.4 spec, the String argument should be present in the response body: cite Sends an error response to the client using the specified status clearing the buffer. The server defaults to creating the response to look like an HTML-formatted server error page containing the specified message, setting the content type to text/html, leaving cookies and other headers unmodified. If an error-page declaration has been made for the web application corresponding to the status code passed in, it will be served back in preference to the suggested msg parameter. /cite -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13089] New: - Coyote sources are missing from the source zip for Tomcat 4.1.12
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=13089. 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=13089 Coyote sources are missing from the source zip for Tomcat 4.1.12 Summary: Coyote sources are missing from the source zip for Tomcat 4.1.12 Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The summary says it all. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache13 jk_service_apache13.c
mturk 2002/09/27 10:49:01
Modified:jk/native2/server/apache13 jk_service_apache13.c
Log:
Fix the compile warning.
Revision ChangesPath
1.8 +1 -1
jakarta-tomcat-connectors/jk/native2/server/apache13/jk_service_apache13.c
Index: jk_service_apache13.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache13/jk_service_apache13.c,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- jk_service_apache13.c 20 Jun 2002 16:16:00 - 1.7
+++ jk_service_apache13.c 27 Sep 2002 17:49:01 - 1.8
@@ -207,7 +207,7 @@
#endif
static int JK_METHOD jk2_service_apache13_write(jk_env_t *env, jk_ws_service_t *s,
-const void *b, int len)
+const void *b, unsigned int len)
{
int rc;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi isapi.dsp
mturk 2002/09/27 10:59:53 Modified:jk/native2/server/isapi isapi.dsp Log: Fix the DLL Stactic MT Debug bild Revision ChangesPath 1.20 +1 -1 jakarta-tomcat-connectors/jk/native2/server/isapi/isapi.dsp Index: isapi.dsp === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/isapi.dsp,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- isapi.dsp 25 Sep 2002 07:37:54 - 1.19 +++ isapi.dsp 27 Sep 2002 17:59:53 - 1.20 @@ -99,7 +99,7 @@ # PROP Ignore_Export_Lib 0 # PROP Target_Dir # ADD BASE CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /I ..\..\include /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /I $(APACHE2_HOME)\include /I $(APACHE2_HOME)\os\win32 /D WIN32 /D _DEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D ISAPI_EXPORTS /D HAVE_JNI /D HAS_APR /FR /YX /FD /GZ /c -# ADD CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /I ..\..\include /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /I $(APACHE2_HOME)\include /I $(APACHE2_HOME)\os\win32 /D WIN32 /D _DEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D ISAPI_EXPORTS /D HAVE_JNI /D HAS_APR /D APR_DECLARE_STATIC /D APU_DECLARE_STATIC /FR /YX /FD /GZ /c +# ADD CPP /nologo /MDd /W3 /Gm /GX /ZI /Od /I ..\..\include /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /I $(APACHE2_HOME)\include /I $(APACHE2_HOME)\os\win32 /D WIN32 /D _DEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D ISAPI_EXPORTS /D HAVE_JNI /D HAS_APR /D APR_DECLARE_STATIC /D APU_DECLARE_STATIC /FR /YX /FD /GZ /c # ADD BASE MTL /nologo /D _DEBUG /mktyplib203 /win32 # ADD MTL /nologo /D _DEBUG /mktyplib203 /win32 # ADD BASE RSC /l 0x409 /d _DEBUG -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Could we improve on the connector (mod_jk) for ajp13?
Hi tomcat developers, I have had the chance to play with Tomcat 3 (TC3) and 4 (TC4) recently. I discovered a performance bottleneck that is quite small and should be non-obvious in a WAN. Nonetheless, I would like to raise this up and see if you folks have talked about this before (I only saw a couple of postings about this on the dev archive). If it is indeed something that can be improved, I can volunteer a patch. Summary: We have a very simple JSP app that is deployed on TC3, integrating with Apache, using either ajp12 or ajp13 protocol. When used with ajp13, we realized that the classic interaction between Nagle algorithm (on the TC3 side) and delayed ack (on the Apache side) results in 200ms delay per request-response loop on the Mac OS X platform. Detailed description: 1. The connector that we used is mod_jk, which is capable of ajp12 or ajp13. 2. When we use ajp12, the entire request-response loop takes about 1ms on a LAN. Using tcpdump on the traffic shows no obvious slow down. This is good. 3. Using the same hardware/software setup but just switching to the ajp13 protocol, each request-response is about 200ms. Mac OS X 10.2 (darwin), by default, turns on Nagle and set the delayed ack to be 200ms. So, intuitively, we know that it's probably due to that. 4. Indeed, analyzing the protocol at http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/common/AJPv13.html and the tcp dump confirms this. Experimentally, if I either turn off Nagle on the TC3 side or turn off delayed ack on the Apache, then performance is as good as ajp12. 5. So there are 2 potentially simple fix: a. We could turn off delayed ack on the Apache side but on darwin, there is no such socket level option. Hence, it will affect the entire machine. b. Turn off Nagle on the TC3 side, for ajp13. Analysis of the protocol shows that ajp13 first sends Headers (small load) back to Apache, followed by Body Chunk (big load) and then an End Response (small load). And for some reason, the Body Chunk is divided into chunks of 1032. I'll have to read the codes to understand why so. Conclusion: before I spend more effort into a solution , I would like to know if you developers has already a solution (but has not been committed since I didn't see it in TC4 yet) so that I don't duplicate effort. Is this something worth pursuing? Thanks much!!
DO NOT REPLY [Bug 13093] New: - Compliance Issue - NPE not thrown if a null reference is passed to PageContext.handlePageException(Exception) or PageContext.handlePageException(Throwable).
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=13093. 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=13093 Compliance Issue - NPE not thrown if a null reference is passed to PageContext.handlePageException(Exception) or PageContext.handlePageException(Throwable). Summary: Compliance Issue - NPE not thrown if a null reference is passed to PageContext.handlePageException(Exception) or PageContext.handlePageException(Throwable). 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] Javadocs for PageContext.handlePageException(Exception) and PageContext.handlePageException(Throwable) clearly state that a NullPointerException is to be thrown if a null reference is passed to these methods. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13094] New: - Compliance Issue - NPE not thrown if a null reference is passed to PageContext.handlePageException(Exception) or PageContext.handlePageException(Throwable).
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=13094. 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=13094 Compliance Issue - NPE not thrown if a null reference is passed to PageContext.handlePageException(Exception) or PageContext.handlePageException(Throwable). Summary: Compliance Issue - NPE not thrown if a null reference is passed to PageContext.handlePageException(Exception) or PageContext.handlePageException(Throwable). 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] Javadocs for PageContext.handlePageException(Exception) and PageContext.handlePageException(Throwable) clearly state that a NullPointerException is to be thrown if a null reference is passed to these methods. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13093] - Compliance Issue - NPE not thrown if a null reference is passed to PageContext.handlePageException(Exception) or PageContext.handlePageException(Throwable).
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=13093. 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=13093 Compliance Issue - NPE not thrown if a null reference is passed to PageContext.handlePageException(Exception) or PageContext.handlePageException(Throwable). [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 18:25 --- *** This bug has been marked as a duplicate of 13094 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13094] - Compliance Issue - NPE not thrown if a null reference is passed to PageContext.handlePageException(Exception) or PageContext.handlePageException(Throwable).
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=13094. 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=13094 Compliance Issue - NPE not thrown if a null reference is passed to PageContext.handlePageException(Exception) or PageContext.handlePageException(Throwable). --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 18:25 --- *** Bug 13093 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 12978] - Tomcat doesn't pick up error pages.
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=12978. 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=12978 Tomcat doesn't pick up error pages. --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 18:30 --- Created an attachment (id=3270) o.a.c.v.ErrorDispatcherValve patch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12978] - Tomcat doesn't pick up error pages.
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=12978. 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=12978 Tomcat doesn't pick up error pages. --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 18:33 --- This patch should fix your problems. the valve was never handling ServletException when looking for errorpages. see SRV.9.9.2 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs and 4.1
micael wrote: Amy, I am using jCVS. When I export and want to specify a tag, how is that done? I am asking for later. Do I do something in the arguments text box? I don't use jCVS so I don't know how. There should usually an option when you do checkout to specify a tag. You should refer to jCVS documentation. Amy At 01:52 PM 9/26/2002 -0700, you wrote: micael wrote: If I cvs to tomcat-4.0, am I going to get the latest of 4.1? Yes. If you checkout jakarta-tomcat-4.0 with no tag specified, you'll get the latest HEAD of 4.1. If not, how do I pick the branches off tomcat-4.0? You can use different tags to get certain releases of tomcat from cvs. For example, you'd use TOMCAT_4_1_12 tag to get the recent 4.1.12 release. Amy Micael --- This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any dislosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12978] - Tomcat doesn't pick up error pages.
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=12978. 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=12978 Tomcat doesn't pick up error pages. --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 18:42 --- Created an attachment (id=3271) o.a.c.v.ErrorDispatcherValve newer patch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12978] - Tomcat doesn't pick up error pages.
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=12978. 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=12978 Tomcat doesn't pick up error pages. --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 18:44 --- The second patch conforms to the spec.. the first still did things backwords.. quote The web application may have declared error pages using the exception-type element. In this case the container matches the exception type by comparing the exception thrown with the list of error-page definitions that use the exceptiontype element. A match results in the container returning the resource indicated in the location entry. The closest match in the class heirarchy wins. If no error-page declaration containing an exception-type fits using the class-heirarchy match, and the exception thrown is a ServletException or subclass thereof, the container extracts the wrapped exception, as defined by the ServletException.getRootCause method. A second pass is made over the error page declarations, again attempting the match against the error page declarations, but using the wrapped exception instead. /quote as you can see it needs to check for the ServletException first, and if a page is not found for them then it needs to check the root cause.. or atleast that is how I read it.. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12978] - Tomcat doesn't pick up error pages.
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=12978. 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=12978 Tomcat doesn't pick up error pages. --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 18:47 --- Created an attachment (id=3272) o.a.c.v.ErrorDispatcherValve even newer.. one of those days -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] 4.1.12 catalina.sh for cygwin
After 2 days of messing around with TC 4.1.12 on cygwin, I realized that the catalina.sh is broken. It does not convert the $CATALINE_TMPDIR environment-variable to a cygwin-path. This lead to these javax.servlet.ServletException: Exception processing JAR at resource path /WEB-INF/lib/some jar exception, which lead me into the complete wrong direction :-) Here's a patch for that (against the 4.1.12 RELEASE) --- catalina_orig.sh2002-09-23 11:23:00.0 +0200 +++ catalina.sh 2002-09-27 20:38:36.0 +0200 @@ -101,6 +101,7 @@ CATALINA_HOME=`cygpath --path --windows $CATALINA_HOME` CATALINA_BASE=`cygpath --path --windows $CATALINA_BASE` CLASSPATH=`cygpath --path --windows $CLASSPATH` + CATALINA_TMPDIR=`cygpath --path --windows $CATALINA_TMPDIR` JSSE_HOME=`cygpath --path --windows $JSSE_HOME` fi I hope I did it the right way. Peter -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13014] - OS/390/USS - Invalid url-pattern in servlet mapping
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=13014. 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=13014 OS/390/USS - Invalid url-pattern in servlet mapping --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 19:25 --- I replaced the XML parser with xercesImpl.jar from Xerces-Java 2.1.0. The problem remains. I installed v331 of tomcat today and it works after with the following files in EBCDIC : conf/tomcat.policy conf/jserv/tomcat.conf conf/jserv/tomcat.property -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13097] New: - org.apache.catalina.startup.Embedded.createConnector sets incorrect address
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=13097. 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=13097 org.apache.catalina.startup.Embedded.createConnector sets incorrect address Summary: org.apache.catalina.startup.Embedded.createConnector sets incorrect address Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] For applications which embed Tomcat using the Embedded class, the createConnector which worked previously (I last used it with Tomcat 4.0.1) now results in the following error: IntrospectionUtils: Unable to resolve host name:localhost/127.0.0.1. Upon examination of the code in Embedded, I find that the String value it is passing on the setProperty(address...) method is incorrect. It is using an implied toString method of an InetAddress object where it should be using the getHostName method. Eventually, an IntrospectionUtils setProperty for the underlying org.apache.coyote.http11.Http11Protocol object tries to reconstruct an InetAddress object using the value as a hostname. In the above example, localhost/127.0.0.1 is not a valid hostname, though localhost is. -- 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/resources messages.properties messages_ja.properties
luehe 2002/09/27 13:18:32
Modified:jasper2/src/share/org/apache/jasper/compiler
TagFileProcessor.java TagLibraryInfoImpl.java
jasper2/src/share/org/apache/jasper/resources
messages.properties messages_ja.properties
Log:
Let parse exception from packaged tag files propagate up
Revision ChangesPath
1.28 +4 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java
Index: TagFileProcessor.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- TagFileProcessor.java 12 Sep 2002 20:48:17 - 1.27
+++ TagFileProcessor.java 27 Sep 2002 20:18:31 - 1.28
@@ -193,13 +193,13 @@
// type is fixed to JspFragment and a translation error
// must occur if specified.
if (type != null) {
-err.jspError(jsp.error.fragmentwithtype);
+err.jspError(n, jsp.error.fragmentwithtype);
}
// rtexprvalue is fixed to true and a translation error
// must occur if specified.
rtexprvalue = true;
if( rtexprvalueString != null ) {
-err.jspError(jsp.error.frgmentwithrtexprvalue );
+err.jspError(n, jsp.error.frgmentwithrtexprvalue );
}
} else {
if (type == null)
1.15 +4 -7
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
Index: TagLibraryInfoImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- TagLibraryInfoImpl.java 28 Aug 2002 23:00:19 - 1.14
+++ TagLibraryInfoImpl.java 27 Sep 2002 20:18:32 - 1.15
@@ -226,10 +226,6 @@
// it to release the cached entry, so
// there's no way to redeploy from the same JAR file. Wierd.
} catch (Exception ex) {
- Constants.message(
-jsp.error.taglib.jarFileException,
- new Object[] {url.toString(), ex.getMessage()},
- Logger.ERROR);
if (stream != null) {
try {
stream.close();
@@ -240,6 +236,7 @@
jarFile.close();
} catch (Throwable t) {}
}
+ throw new JasperException(ex);
}
}
}
1.43 +1 -2
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
Index: messages.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- messages.properties 24 Sep 2002 21:24:58 - 1.42
+++ messages.properties 27 Sep 2002 20:18:32 - 1.43
@@ -253,7 +253,6 @@
#jspx.error.templateDataNotInJspCdata=Validation Error: Element lt;{0}gt; cannot
have template data. Template data must be encapsulated within a lt;jsp:cdatagt;
element. [JSP1.2 PFD section 5.1.9]\nTemplate data in error: {1}
jspx.error.templateDataNotInJspCdata=Validation Error: Element lt;{0}gt; cannot
have template data. Template data must be encapsulated within a lt;jsp:textgt;
element. [JSP1.2 PFD section 5.1.9]\nTemplate data in error: {1}
#Error while processing taglib jar file {0}: {1}
-jsp.error.taglib.jarFileException=
jsp.error.taglib.reserved.prefix=The taglib prefix {0} is reserved
jsp.error.invalid.javaEncoding=Invalid java encodings. Tried {0} and then {1}. Both
failed.
jsp.error.needAlternateJavaEncoding=Default java encoding {0} is invalid on your
java platform. An alternate can be specified via the 'javaEncoding' parameter of
JspServlet.
1.14 +1 -2
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_ja.properties
Index: messages_ja.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_ja.properties,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- messages_ja.properties24 Sep 2002 21:24:58 - 1.13
+++ messages_ja.properties27 Sep 2002 20:18:32 -
Ping: sources for jsp2el.jar !
It seems Justyna was the last person to access the file, and Remy was the first. If anyone knows where are the sources for that jar - please let me know. ( or just check them in ). -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[ANNOUNCEMENT]: JK 1.2.0 is now available
Hi all, The Jakarta-Tomcat-Connector team is pleased to announce the availability of JK 1.2.0. JK, also known as mod_jk, is a Tomcat / WebServers plug-in that handles the communication between Tomcat and webservers. Currently Apache 1.3.x and 2.0.x, IIS, Netscape/iPlanet are supported. binaries and source versions of the release are available and can be downloaded from : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/ Binaries allready available are : - Linux i386 (Apache 1.3/2.0.42) - Solaris 8 (Apache 1.3/2.0.39/2.0.42) - Win32 (IIS/Apache 1.3/2.0.42) MacOS X, AIX, iSeries binaries to be released shortly (I hope) Feel free to contact us to provide binaries for your own operating system. Enjoy! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JK2 2.0.0 Released as Beta
This is the first Beta relese of JK2 The JK2 should be considered initial-release quality code. It has not been subjected to the same stresses on its stability and security that the mod_jk releases have enjoyed, so there is a greater possibility of undiscovered vulnerabilities to stability or security. The newest JK2 is a rewrite of JK . The native part has been completly restructured and the configuration has been simplified a lot. Even if it works with Apache 1.3, JK2 has been developed with Apache 2.0 in mind, and thus is better suited for multi-threaded servers like IIS, NES/iPlanet. JK2 has a better separation between protocol and physical layer. As such JK2 support fast unix-socket, and could be extended to support others communications channels. Better it's suited for JNI and JDK 1.4 fast IO APIs You can find the sources and binaries at http://cvs.apache.org/~mturk/jk2 MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13000] - tag file handler generation with complex attributes
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=13000. 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=13000 tag file handler generation with complex attributes [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Critical -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13052] - SecurityManager + req.getParameter() = ParameterMap class loading NoClassDefFoundError exception
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=13052. 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=13052 SecurityManager + req.getParameter() = ParameterMap class loading NoClassDefFoundError exception [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 22:19 --- As I stated in the other bugzilla report, there is nothing in org.apache.catalina.util.* that is security sensitive. Fix your policy so that the correct defineClassInPackage Runitme permission is granted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13052] - SecurityManager + req.getParameter() = ParameterMap class loading NoClassDefFoundError exception
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=13052. 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=13052 SecurityManager + req.getParameter() = ParameterMap class loading NoClassDefFoundError exception [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13068] - Use of validationQuery parameter by BasicDataSourceFactory implementation
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=13068. 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=13068 Use of validationQuery parameter by BasicDataSourceFactory implementation [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 22:25 --- The validationQuery is used by the PoolableConectionFactory.validateObject() method in the code from CVS for the DBCP 1.0 release. Make sure you have the 1.0 release. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13068] - Use of validationQuery parameter by BasicDataSourceFactory implementation
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=13068. 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=13068 Use of validationQuery parameter by BasicDataSourceFactory implementation [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[patch] JNDIRealm and SSL
Hi! I have added the possibility to use SSL with the JNDIRealm in the file JNDIRealm.java.diff. This patch allows two more parameters to be set for the JNDIRealm. If they are not explicitly set the JNDIRealm will behave in the same way as before. I tried to document the changes (or additions) for the configuration in the realm.xml.diff. O, as a bonus I did remove some unused imports and a fixed a typo in the javadoc in JNDRealm. Regards, Fredrik Westermarck JNDIRealm.java.diff Description: Binary data realm.xml.diff Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13084] - jsp compilation with jikes fails
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=13084. 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=13084 jsp compilation with jikes fails [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 22:33 --- You need a version of jikes with support for encoding. If you execute the jikes compiler from a shell with -help and don't see the option -encoding then jikes isn't built with support for encoding. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13084] - jsp compilation with jikes fails
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=13084. 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=13084 jsp compilation with jikes fails [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 13084] - jsp compilation with jikes fails
Just out of curiosity, where would you obtain such a version? I tried jikes 1.16 (win32) from IBM. AFAIK this is the current version of jikes, and also the first version that supports assertions (-source 1.4). It doesn't list the -encoding option. Is -encoding a standard option for jikes? Sean Reilly Programmer, Point2 Technologies, Inc. (306) 955-1855 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, September 27, 2002 4:33 PM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 13084] - jsp compilation with jikes fails (snip) http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13084 jsp compilation with jikes fails [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 22:33 --- You need a version of jikes with support for encoding. If you execute the jikes compiler from a shell with -help and don't see the option -encoding then jikes isn't built with support for encoding. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Cannot Build WebApp on Solaris 2.8
On 27/9/02 0:22, Jay Ebert [EMAIL PROTECTED] wrote: I followed the Building the WebApp module exactly and cannot build the webapp module for Solaris 2.8 using gcc 2.95. After a successful ./configure ... , I get the following errors on the make: Use mod_jk -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tired...
Since I'm tired of you lot, I'm going to say goodbye and retire in lala-land http://www.psc.edu/science/tang.html... Have fun and try not to hit bugtrack too often! :-) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace
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=9931. 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=9931 Base64 decoder chokes on a whitespace [EMAIL PROTECTED] changed: What|Removed |Added URL||http://cvs.apache.org/viewcv ||s/xml- ||rpc/src/test/org/apache/xmlr ||pc/Base64Test.java?rev=1con ||tent-type=text/vnd.viewcvs- ||markup --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 23:43 --- Hmm. I just wrote a very simple test case for the Base64 implementation which Jon nabbed from Tomcat (I found the attached one a bit too abstract to follow easily). I was unable to reproduce the failure, even by appending whitespace to the end of the line (you can try it out yourself with `ant test`): http://cvs.apache.org/viewcvs/xml-rpc/src/test/org/apache/xmlrpc/Base64Test.java?rev=1content-type=text/vnd.viewcvs-markup Vjekoslav, can you tell me what the correct method of handling whitespace in base64-encoded data is? The closest thing that I found to a RFC on that is http://www.zvon.org/tmRFC/RFC3156/Output/chapter3.html -- it recommends stripping trailing whitespace. Is this what Apache's implementation should be doing? Or should it collapse all lines of base64-encoded data together, then decode that? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs jasper-howto.xml
glenn 2002/09/27 17:24:31 Modified:webapps/tomcat-docs jasper-howto.xml Log: Update docs for jikes Revision ChangesPath 1.3 +3 -1 jakarta-tomcat-4.0/webapps/tomcat-docs/jasper-howto.xml Index: jasper-howto.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/jasper-howto.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jasper-howto.xml 13 Sep 2002 11:51:30 - 1.2 +++ jasper-howto.xml 28 Sep 2002 00:24:31 - 1.3 @@ -166,7 +166,9 @@ a href=http://oss.software.ibm.com/developerworks/opensource/jikes/; Jikes/a to compile JSP pages: ul -liDownload and install jikes./li +liDownload and install jikes. jikes must support the -encoding option. +Execute codejikes -help/code to verify that it was built with support +for code-encoding/code./li liSet the init parameter codecompiler/code to codejikes/code./li liDefine the property code-Dbuild.compiler.emacs=true/code when starting Tomcat by adding it to your codeCATALINA_OPTS/code environment variable. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-site/xdocs bugreport.xml
glenn 2002/09/27 17:35:03 Modified:xdocsbugreport.xml Log: Add info on how to report a security bug Revision ChangesPath 1.3 +5 -0 jakarta-tomcat-site/xdocs/bugreport.xml Index: bugreport.xml === RCS file: /home/cvs/jakarta-tomcat-site/xdocs/bugreport.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- bugreport.xml 11 Apr 2002 01:47:29 - 1.2 +++ bugreport.xml 28 Sep 2002 00:35:03 - 1.3 @@ -15,6 +15,11 @@ who assist on a day to day basis resolving bug reports do this for a wide variety of reasons, and almost all of them do this on their own time./p +pIf you have a verified security bug to report please do not post it +to email lists or submit a bug report. Security bugs should be reported +privately by email to a href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/a. +/p + pMany bugs reported end up not being a bug in the Tomcat code, but are due to misconfiguration, problems caused by installed applications, the operating system, etc. -- 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 Parser.java
kinman 2002/09/27 17:46:28
Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java
Log:
- Fix 13058: Dynamic attributes specified in jsp:attribute body do not
take RT expressions.
Revision ChangesPath
1.32 +8 -5
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
Index: Parser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- Parser.java 12 Sep 2002 21:57:00 - 1.31
+++ Parser.java 28 Sep 2002 00:46:28 - 1.32
@@ -1715,8 +1715,8 @@
private String getAttributeBodyType(Node n, String name) {
if (n instanceof Node.CustomTag) {
- TagAttributeInfo[] tldAttrs =
- ((Node.CustomTag)n).getTagInfo().getAttributes();
+ TagInfo tagInfo = ((Node.CustomTag)n).getTagInfo();
+ TagAttributeInfo[] tldAttrs = tagInfo.getAttributes();
for (int i=0; itldAttrs.length; i++) {
if (name.equals(tldAttrs[i].getName())) {
if (tldAttrs[i].isFragment()) {
@@ -1726,6 +1726,9 @@
return TagInfo.BODY_CONTENT_JSP;
}
}
+ }
+ if (tagInfo.hasDynamicAttributes()) {
+ return TagInfo.BODY_CONTENT_JSP;
}
} else if (n instanceof Node.IncludeAction) {
if (page.equals(name)) {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13058] - Dynamic Attributes do not take in RT expressions
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=13058. 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=13058 Dynamic Attributes do not take in RT expressions [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 13107] New: - Wrong handling of % // some comment %some custom tag
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=13107. 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=13107 Wrong handling of % // some comment %some custom tag Summary: Wrong handling of % // some comment %some custom tag Product: Tomcat 4 Version: 4.1.12 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] After upgrading from 4.0.4 (cute version number for a webserver anyway :) I faced a compilation problem with the following code: % // some comment %own:mytag.../own:mytag The source generated looks like: // some comment if (_jspx_meth_own_mytag_2(pageContext)) which is wrong. As said before, this worked in 4.0.4. Rewriting the comment to /* some comment */ works, too. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 13084] - jsp compilation with jikes fails
I know that jikes on unix has support for the -encoding arg. I built it from source on Solaris. When I did the build jikes there were dependences for libs (dll) which supported unicode and internationalizaiton. Without these the version of jikes built did not support encodeing. I don't know where you would get a windows version with support for -encoding. Regards, Glenn Sean Reilly wrote: Just out of curiosity, where would you obtain such a version? I tried jikes 1.16 (win32) from IBM. AFAIK this is the current version of jikes, and also the first version that supports assertions (-source 1.4). It doesn't list the -encoding option. Is -encoding a standard option for jikes? Sean Reilly Programmer, Point2 Technologies, Inc. (306) 955-1855 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, September 27, 2002 4:33 PM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 13084] - jsp compilation with jikes fails (snip) http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13084 jsp compilation with jikes fails [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 22:33 --- You need a version of jikes with support for encoding. If you execute the jikes compiler from a shell with -help and don't see the option -encoding then jikes isn't built with support for encoding. -- 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]
fault-tolerance
Hi, i think i have a rather simple questions for the developers of tomcat. Let me give short explanation. I am working on a research topic, which is generic fault detection and tolerance for software architectures. i've picked apache as a sample of c/c++ program and tomcat as a java program. don't get me wrong: i did it because i beleave that these programs are well known, and developed professionaly, since i need fault statistics that are not obscured by simply omitting basic rules of software development. i studied the bug database for tomcat4 versions 4.0.x Final, with the assumption that these have been (fairly) stable versions. i omitted NEW and UNCONFIRMED bugs, as well as INVALID, WONTFIX, DUPLICATE, WORKSFORME. besides that, i ignored some IMHO rare plattforms like BeOS, OS/2, Netware, OS/400 and included only critical, major and normal bugs. i did that in the hope to get representative statistics about common software faults in a big, professionaly developed software product. if i did something wrong, please correct me. at the end i got 163 bugs. now the important stuff. after examining some of them, i noticed some amount of bugs (i.e. bugs #4930, #4047) causing unchecked exceptions, which strike all the way through the stack, ending in org.apache.catalina.connector.http.HttpProcessor.run() and then in java.lang.Thread.run(). in my understanding, this stops the affected thread and all functionality that was done by org.apache.catalina.connector.http.HttpProcessor.run() is unavailable now. what is tomcats reaction to this? does the program crash/freeze/hang whatever, or do these exceptions not affect the runime behaviour? or is only the active servlet affected? besides that, i wondered what are the effects of the bugs 3817, 4542, 5201, since the provided stack doesn't go up to java.lang.Thread.run(). thank you very much in advance, i really appreciate your answers because it doesnt help you developing tomcat in the first place, but just think that you are helping to research ways to prevent software from crashing at all! Kirill Koulechov -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs style.xsl.in
hgomez 2002/09/27 23:06:37
Modified:jk/xdocs style.xsl.in
Added: jk/xdocs/images mod_jk.jpg
Removed: jk/xdocs/images mod_jk.jpeg
Log:
Change from .jpeg to .jpg to avoid problem with misconfigured CVS
clients which broke the .jpeg in at least TC 4.1.12 release tarball
Revision ChangesPath
1.1 jakarta-tomcat-connectors/jk/xdocs/images/mod_jk.jpg
Binary file
1.14 +1 -1 jakarta-tomcat-connectors/jk/xdocs/style.xsl.in
Index: style.xsl.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/style.xsl.in,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- style.xsl.in 26 Sep 2002 12:50:49 - 1.13
+++ style.xsl.in 28 Sep 2002 06:06:37 - 1.14
@@ -102,7 +102,7 @@
img src={$images}/jakarta.gif border=0 width=270
height=75 align=left/
/td
td align=right
-img src={$images}/mod_jk.jpeg border=0 align=right/
+img src={$images}/mod_jk.jpg border=0 align=right/
/td
/tr
/table
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
