RE: Could you give some help for me (about mod_jk for solaris 9)
This worked for me on Solaris 8 this evening:
Make sure you have properly compiled and installed Apache 2.x and Tomcat 4.1.24.
We'll call these installation directories apache2.home and tomcat4.home.
Also make sure you have recent versions of m4, automake, and autoconf installed from
www.sunfreeware.com.
Set the environment variable M4 to the location of your GNU m4 executable.
For example in bash: export M4=/usr/local/bin/m4
Download jakarta-tomcat-connectors-jk-1.2.4-src.tar.gz from
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.4/src/
and extract it to some directory, well call it jk.build.
cd ${jk.build}/jk/native
execute buildconf.sh
execute ./configure --with-apxs=${apache2.home}/bin/apxs
execute make
Locate mod_jk.so from the ${jk.build}/jk/native/apache-2.0 directory and copy it to
your ${apache.home}/modules directory. Just add the line
LoadModule jk_module ${apache.home}/modules/mod_jk.so
to your ${apache.home}/httpd.conf file and follow the configuration instructions for
httpd.conf and workers.properties given at
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.4/doc/.
Good luck!
Jamey
-Original Message-
From: David Choi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2003 2:40 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Could you give some help for me (about mod_jk for solaris 9)
I have got your E-mai from some forum for tomcat
I am from south korea, and study about JSP and SUN OS.
First, Sorry for my poor english~
I am wondering where and how I can get the mod_jk.so (the
apache module) for connecting tomcat with apache
before, I found jakarta project FTP site but there was not
module(mod_jk.so) for solaris 9(some module for solaris 8 had some
error)
So many time I tried to make mod_jk.so from source file
(jakarta_tomcat_connector 4.1.24) but I couldn't
Actually, I would like to connect tomcat 4.1.24 with apache 2.X on the
solaris 9 platform.
Please help me now~
Thanks for your time and efforts~
From YH.Choi
South Korea
Wishing you all the success in this business, we hope our transaction
makes much better world than before.
We thank you for your time and efforts
Warm regards,
David Choi
Marketing Manager
SP KOREA Co.,LTD (Tel 82-53-588-0318, Cel 82-16-9775-3900, Fax
82-53-588-0319)
http://www.sp-korea.com http://www.sp-korea.com
http://www.kacci.net
http://www.korea.com
http://movie.korea.com/koreamovie/result.asp?genre=1m_id=5725
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Could you give some help for me (about mod_jk for solaris 9)
P.S. To the developers. I can build with both ant and with configure for both jk
using the 1.2.4 download and jk2 using the 2.0.2 download. While this doesn't make me
a rocket scientist, these do seem to be troublesome tasks for many users who are new
to the program.
To get the ant to work I had to add a jk/jkant directory copied from CVS and make some
small modifications to the build.xml files as for jk solaris is omitted in a couple of
places. It seems as though it would be pretty easy to just include jk/jkant in the
mod_jk and mod_jk2 releases going forward and to fix the minor solaris bugs in the
mod_jk build.xml to allow users to just use ant going forward. I'm happy to document
this build process or all of the above build processes and put them somewhere in CVS
is someone wants to point me to the right location. I'll also happily provide the two
lines to be added in the mod_jk build.xml to allow for solaris to work correctly (at
least 2.8).
Feedback?
Thanks!
Jamey
James Courtney
InPhonic, Inc.
-Original Message-
From: James Courtney
Sent: Wednesday, July 09, 2003 11:33 PM
To: Tomcat Developers List
Cc: [EMAIL PROTECTED]
Subject: RE: Could you give some help for me (about mod_jk for solaris 9)
This worked for me on Solaris 8 this evening:
Make sure you have properly compiled and installed Apache 2.x and Tomcat 4.1.24.
We'll call these installation directories apache2.home and tomcat4.home.
Also make sure you have recent versions of m4, automake, and autoconf installed from
www.sunfreeware.com.
Set the environment variable M4 to the location of your GNU m4 executable.
For example in bash: export M4=/usr/local/bin/m4
Download jakarta-tomcat-connectors-jk-1.2.4-src.tar.gz from
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.4/src/
and extract it to some directory, well call it jk.build.
cd ${jk.build}/jk/native
execute buildconf.sh
execute ./configure --with-apxs=${apache2.home}/bin/apxs
execute make
Locate mod_jk.so from the ${jk.build}/jk/native/apache-2.0 directory and copy it to
your ${apache.home}/modules directory. Just add the line
LoadModule jk_module ${apache.home}/modules/mod_jk.so
to your ${apache.home}/httpd.conf file and follow the configuration instructions for
httpd.conf and workers.properties given at
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.4/doc/.
Good luck!
Jamey
-Original Message-
From: David Choi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2003 2:40 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Could you give some help for me (about mod_jk for solaris 9)
I have got your E-mai from some forum for tomcat
I am from south korea, and study about JSP and SUN OS.
First, Sorry for my poor english~
I am wondering where and how I can get the mod_jk.so (the
apache module) for connecting tomcat with apache
before, I found jakarta project FTP site but there was not
module(mod_jk.so) for solaris 9(some module for solaris 8 had some
error)
So many time I tried to make mod_jk.so from source file
(jakarta_tomcat_connector 4.1.24) but I couldn't
Actually, I would like to connect tomcat 4.1.24 with apache 2.X on the
solaris 9 platform.
Please help me now~
Thanks for your time and efforts~
From YH.Choi
South Korea
Wishing you all the success in this business, we hope our transaction
makes much better world than before.
We thank you for your time and efforts
Warm regards,
David Choi
Marketing Manager
SP KOREA Co.,LTD (Tel 82-53-588-0318, Cel 82-16-9775-3900, Fax
82-53-588-0319)
http://www.sp-korea.com http://www.sp-korea.com
http://www.kacci.net
http://www.korea.com
http://movie.korea.com/koreamovie/result.asp?genre=1m_id=5725
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Soft termination: a demonstration
Greetings -- As I announces about a week ago, as a part of my research, I have developed a mechanism for terminating individual Tomcat webapps (at the context level) called soft termination. For your further enjoyment, I've taken the liberty of setting up a demo install of my soft termination system. The demo install is at: http://puppet.cs.rice.edu:8080/ In particular, the following URL runs an infinite loop that prints the current time each second (note it does this with a while(true) and no sleeps): http://puppet.cs.rice.edu:8080/examples/servlet/ExceptionExample And this URL prints the current system status of the machine in question (updated once per second): http://www.cs.rice.edu/~arudys/loadavg.html Every 10 seconds, termination of the examples webapp is triggered. Note that it is triggered by updating the modification date of the ExceptionExample.class file (forcing a reload which terminates the old webapp) and not from within Tomcat. Once again, links for downloading the code and to the journal article describing soft termination can be found off this site: http://www.cs.rice.edu/~arudys/software/#softterm And feel free to badger me with any questions you see fit. Enjoy. Be nice. Algis Rudys -- Algis RudysRice University [EMAIL PROTECTED]Computer Science Heart has nothing to do with it anymore. It's all in the caffeine. -- Frank Pembleton, _Homicide_ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.25] Tag today
Remy, I just discovered a nasty synchronization bottlneck in org.apache.catalina.logger.FileLogger in its use of java.sql.Timestamp. The actual synchronization bottleneck is in java.util.Date which java.sql.Timestamp extends. I am pretty sure I have found a work around to avoid the synchronization. The work around will involve use of a static instance of the default TimeZone (TimeZone.getDefault() has a synchronization bottleneck) and replacement of java.sql.Timestamp with a java.util.Calendar object with is thread local. It may take me a few days before I can get this in place and do benchmark comparisons vs the current code. I found this when debugging scalability problems on a production Tomcat. Many of the threads were in a bottleneck trying to instantiate or use a java.util.Date object. The worst offender was having the MySQL JDBC driver return a Date object for a DATE, TIME, or TIMESTAMP field. I found this to be a significant performance issue on a production system. I would like to delay the Tomcat 4.1.25 release until it can be resolved. Of course there are other places in Tomcat and supporting libraries where java.util.Date is used and where there may be a benefit to optimizing out the synchronization bottleneck of java.util.Date. Such as Jasper. This also applies to any classes which extend java.util.Date such as java.sql.Time and java.sql.Timestamp. BTW, I looked at the source for java 1.4.1 and the synchronization bottleneck in java.util.TimeZone and java.utilDate still exist. Regards, Glenn Remy Maucherat wrote: As discussed earlier, I plan to tag 4.1.25 later today. Note: I haven't ported the JSP/JSPC package path fixes, as I consider them risky. I plan to port them later on, but it would be very good to have this build rated as stable, without further delays, as there are a couple of important fixes in it. Note 2: Given that my release computer is dead (but will be back from the dead in some form maybe, given its HD should still work), there could be packaging mistakes (in which case, let me know, and I will just replace the bins with new ones). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.25] Tag today
Remy, It can wait, go ahead with the release. But the FileLogger's use of java.sql.Timestamp is a bottleneck, I have the thread dump stack traces to prove that it is. Right now the biggest problem I have with Tomcat scaling is with this type of synchronization bottleneck. I have thread dump stack traces where two thirds of the threads are waiting on the same synchronization bottleneck related to use of one or more of the following classes: java.util.Date java.util.TimcZone.getDefault() java.util.Calendar.getInstance() java.text.SimpleDateFormat java.sql.Date java.sql.Time java.sql.Timestamp They all hit the same synchronization bottleneck. And I have multiple code bases that have to go through this bottleneck; Tomcats FileLogger which gets used a great deal for the Connector log when Tomcat is heavily loaded, the MySQL Connector/J JDBC driver, and I have customer web application code which hits this also. Due to scaling problems I setup a second app server and load balancing. It still did not scale well because of the above synchronization bottleneck. Both app servers became overloaded due to this bottleneck. I now think the best solution might be a commons project to provide alternate solutions for the above date related classes designed so that this synchronization bottleneck is avoided. Regards, Glenn Remy Maucherat wrote: Glenn, What you've posted does not make much sense to me: logging is not a per request event, or at least it should not, so I don't see any bottleneck in a normal situation where logged events are relatively rare. The change is too big to be included at the last minute in 4.1.25, which is meant to fix two security issues primarily, and must be voted stable. As a result, there will not be any more delays in this tag (which should have happened yesterday, but unfortunately, my DSL decided to die on me late in the evening as I was putting together the changelog). This is a good optimization overall, that can be done in a few components (like the access log), but there's simply no incentive to push back a release for it. I'll have all the time I want for Tomcat starting next week, so I can start doing more frequent TC 4 releases, instead of focusing the small amount of time I have on TC 5 :-D Additionally, there is no critical path component in Tomcat which needs to be optimized for Date processing (and esp not Jasper, except in dev mode). I did that long ago. Rémy __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21456] New: - logs/context lost when restarting Context
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=21456.
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=21456
logs/context lost when restarting Context
Summary: logs/context lost when restarting Context
Product: Tomcat 3
Version: 3.3.1 Final
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Normal
Priority: Other
Component: Webapps
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hi,
When I restart a context (remove then add) with the admin webapp, I lose my
servlet logs.
I have a file apps-myAppli.xml with this content :
?xml version=1.0 encoding=ISO-8859-1?
Server
Host name=myAppli
Context path= docBase=/usr/webapps/myAppli
LogSetter name=myAppli_log
path=logs/myAppli_servlet-${MMdd-HH:mm}.log
verbosityLevel=DEBUG
servletLogger=true/
/Context
/Host
/Server
For example, when I start tomcat, my logFile myAppli_servlet-20030709-10:23.log
is created and I see my logs in it.
But, 2 minutes later, I restart my context and :
- the logFile myAppli_servlet-20030709-10:25.log is not created
- and there's no more servlet logs
It seems that the ContextManager, when it removes a context, remove this context
and all its interceptors,
But when it add a context, it only add the context ...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18219] - Can't compile JSP 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=18219. 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=18219 Can't compile JSP pages --- Additional Comments From [EMAIL PROTECTED] 2003-07-10 10:39 --- I'm going to try to make a case for reopening this bug. I just lost 2 days to this problem, so I'm hoping a minor change to the installation program (or documentation, at least) could prevent the same fate for others. From what I can determine, if you're going to run Tomcat 5.0.3 as a Windows Service, there are no environment variables required whatsoever, nor any PATH changes, except for one small catch: you must have JAVA_HOME defined *during* the Tomcat installation (and only then) if you want your JSP pages to compile. You don't need it defined /after/ installation, and you don't need it defined for anything else I've been using for development or production Java tools in the past 7 years. In fact, after installation, you don't need anything added to your PATH at all, and you don't need CATALINA_HOME, ANT_HOME, nor JAVA_HOME defined. Why have this extra little gotcha in there when Tomcat already knows quite well where the JDK is installed from the Registry settings? Furthermore, the recovery is a bit tough to figure out -- you have to actually uninstall Tomcat, define JAVA_HOME, and then re-install Tomcat. Then you can undefine JAVA_HOME and you're set. Most of my time lost was because I thought I could recover by simply defining JAVA_HOME and restarting the Tomcat service. I didn't imagine that this environment variable was absolutely critical during the installation itself. The rest of the time lost was spent trying all the combinations of the other environment variables, none of which are required nor helped. So if the bug won't be reopened, can this message: Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath. Perhaps JAVA_HOME does not point to the JDK be changed to the following instead? Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath. Perhaps you need to define JAVA_HOME and reinstall Tomcat. Or at least put a big warning in the future Tomcat 5.0 Setup page that says it's critical for JAVA_HOME to be defined *during* installation when you plan to run Tomcat 5.0.3 as a Windows Service, but no such Java/Tomcat/Ant environment variables or PATH changes are required afterwards. Thanks, John Neffenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BUG (IMPORTANT): AJP12 hangs in certain conditions
Hi Costin and tomcat developers! I found this bug in Tomcat Mailing List Archive from Date: Mon, 24 Jul 2000 10:25:13 -0700. We are experiencing similar problem in our application. We are using IIS and Tomcat3.2.3 After some days of load IIS-tomcat redirection stops response since IIS standalone continue working ,port 8007 (port of AJP12) response fine and tomcat direct port (8080) as well. Ones this happens no request can't be done through IIS to tomcat until restart of Tomcat. It seems like some problem in AJP12 tomcat implementation. Your mail was in about two year ago, but any way is this solved? At least in one of following Tomcat versions? Alona Samardin Topaz App. Core Team Phone:2554 --- Mercury Interactive Israel This email has been scanned for all viruses. Mercury Interactive Corporation Optimizing Business Processes to Maximize Business Results http://www.merc-int.com
WAR files with Tomcat 4.0 problem...
Hello, I have a .war file in my webapps directory and it does not get expanded when Tomcat 4.0 starts up. I am getting the error java.lang.IllegalArgumentException: Document base /install/jakarta-tomcat-4.0/webapps/soap does not exist or is not a readable directory but there is a soap.war file in /install/jakarta-tomcat-4.0/webapps I have also enabled unpackWARs Engine name=Standalone defaultHost=localhost debug=0 autoDeploy=true unpackWARs=true . . . . !-- Define the default virtual host -- Host name=localhost debug=0 appBase=webapps autoDeploy=true unpackWARs=true . . . !-- Replace localhost with what your Apache ServerName is set to -- Engine className=org.apache.catalina.connector.warp.WarpEngine name=Apache debug=0 appBase=webapps autoDeploy=true unpackWARs=true everywhere in server.xml Regards Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problems with TC5 and persistent sessions.
I am running TC 5.0.3 .. When I stop and restart the server standard manager tries to load any sessions that have been previously persisted. TC seems to do this outside of the context of the webapps as the webapps do not appear to be loaded until after this occurs. As you can see in the trace back below TC can't load the session. I assume this is because the object to be de-serialized class is contained in a jar in a webapp that has not yet been loaded. So .. my questions are .. What is the 'spec' on the re-loading of sessions that are persisted and the serializable classes contained in that session? Does the spec say where these classes should be placed? Is this just a hole in the spec or TC somewhere? Thanks in advance for any help on this issue. Len Jul 9, 2003 1:52:53 PM org.apache.commons.modeler.modules.MbeansDescriptorsDOMSource execute INFO: Reading descriptors ( dom ) 297 Jul 9, 2003 1:52:53 PM org.apache.commons.modeler.modules.MbeansDescriptorsDOMSource execute INFO: Reading descriptors ( dom ) 16 Jul 9, 2003 1:52:53 PM org.apache.commons.modeler.modules.MbeansDescriptorsDOMSource execute INFO: Reading descriptors ( dom ) 31 Jul 9, 2003 1:52:54 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on port 8080 Jul 9, 2003 1:52:54 PM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 2484 ms Jul 9, 2003 1:52:54 PM org.apache.catalina.core.StandardService start INFO: Starting service Catalina Jul 9, 2003 1:52:54 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.0.3 Jul 9, 2003 1:52:54 PM org.apache.commons.modeler.modules.MbeansDescriptorsDOMSource execute INFO: Reading descriptors ( dom ) 16 Jul 9, 2003 1:52:54 PM org.apache.commons.modeler.modules.MbeansDescriptorsDOMSource execute INFO: Reading descriptors ( dom ) 94 Jul 9, 2003 1:52:55 PM org.apache.commons.modeler.modules.MbeansDescriptorsDOMSource execute INFO: Reading descriptors ( dom ) 0 Jul 9, 2003 1:52:55 PM org.apache.commons.modeler.modules.MbeansDescriptorsDOMSource execute INFO: Reading descriptors ( dom ) 31 Jul 9, 2003 1:52:56 PM org.apache.catalina.session.StandardManager doLoad SEVERE: ClassNotFoundException while loading persisted sessions: java.lang.ClassNotFoundException: [Lcom.eloquent.ecs.EKey; java.lang.ClassNotFoundException: [Lcom.eloquent.ecs.EKey; at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav a:1378) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav a:1225) at org.apache.catalina.util.CustomObjectInputStream.resolveClass(CustomObjectIn putStream.java:119) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435) at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1560) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1271) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324) at org.apache.catalina.session.StandardSession.readObject(StandardSession.java: 1395) at org.apache.catalina.session.StandardSession.readObjectData(StandardSession.j ava:889) at org.apache.catalina.session.StandardManager.doLoad(StandardManager.java:451) at org.apache.catalina.session.StandardManager.load(StandardManager.java:377) at org.apache.catalina.session.StandardManager.start(StandardManager.java:692) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4057) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1127) at org.apache.catalina.core.StandardHost.start(StandardHost.java:795) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1127) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:502) at org.apache.catalina.core.StandardService.start(StandardService.java:519) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2312) at org.apache.catalina.startup.Catalina.start(Catalina.java:577) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:297) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:394) Jul 9, 2003 1:52:56 PM org.apache.catalina.session.StandardManager start SEVERE: Exception loading sessions from persistent storage java.lang.ClassNotFoundException: [Lcom.eloquent.ecs.EKey; at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav a:1378) at
Re: [4.1.25] Tag today
Glenn, What you've posted does not make much sense to me: logging is not a per request event, or at least it should not, so I don't see any bottleneck in a normal situation where logged events are relatively rare. The change is too big to be included at the last minute in 4.1.25, which is meant to fix two security issues primarily, and must be voted stable. As a result, there will not be any more delays in this tag (which should have happened yesterday, but unfortunately, my DSL decided to die on me late in the evening as I was putting together the changelog). This is a good optimization overall, that can be done in a few components (like the access log), but there's simply no incentive to push back a release for it. I'll have all the time I want for Tomcat starting next week, so I can start doing more frequent TC 4 releases, instead of focusing the small amount of time I have on TC 5 :-D Additionally, there is no critical path component in Tomcat which needs to be optimized for Date processing (and esp not Jasper, except in dev mode). I did that long ago. Rémy __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18219] - Can't compile JSP 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=18219. 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=18219 Can't compile JSP pages --- Additional Comments From [EMAIL PROTECTED] 2003-07-10 11:45 --- Do not reopen it, a better error message is now displayed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WAR files with Tomcat 4.0 problem...
Silly question Does the user running tomcat have write permissions in the webapps directory ? David Jack Byrne [EMAIL PROTECTED]To: [EMAIL PROTECTED] cc: Subject: WAR files with Tomcat 4.0 problem... 09/07/2003 17:24 Please respond to Tomcat Developers List Hello, I have a .war file in my webapps directory and it does not get expanded when Tomcat 4.0 starts up. I am getting the error java.lang.IllegalArgumentException: Document base /install/jakarta-tomcat-4.0/webapps/soap does not exist or is not a readable directory but there is a soap.war file in /install/jakarta-tomcat-4.0/webapps I have also enabled unpackWARs Engine name=Standalone defaultHost=localhost debug=0 autoDeploy=true unpackWARs=true . . . . !-- Define the default virtual host -- Host name=localhost debug=0 appBase=webapps autoDeploy=true unpackWARs=true . . . !-- Replace localhost with what your Apache ServerName is set to -- Engine className=org.apache.catalina.connector.warp.WarpEngine name=Apache debug=0 appBase=webapps autoDeploy=true unpackWARs=true everywhere in server.xml Regards Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP] Build timed out - jk2
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-07-10/jakarta-tomcat-jk-native2.html
Buildfile: build.xml
init.taskdef:
guess.os:
[echo] build.properties i386.Linux
[echo] Linux:true Win32:${win32} Netware:${netware} Solaris:${solaris}
HPUX:${hpux}
init.win32.properties:
init.win32.mc:
init.win32:
init.netware:
init.os:
guess.server:
[echo] Apache2 /usr/local/apache2 true
[echo] Apache13 /usr true
[echo] IIS ${iis.home} ${iis.detect}
[echo] Iplanet ${iplanet.home} ${iplanet.detect}
[echo] AOLserver ${aolserver.home} ${aolserver.detect}
[echo] JNI true
init:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk2
apache20:
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk2/apache2
[so] Compiling 42 out of 42
Compiling
/home/rubys/jakarta/jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c
/home/rubys/bin/timeout: timed out
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21468] New: - Xcheck:jni option incompatible with Tomcat
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=21468. 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=21468 Xcheck:jni option incompatible with Tomcat Summary: Xcheck:jni option incompatible with Tomcat Product: Tomcat 4 Version: 4.1.24 Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When started with CATALINA_OPTS=-Xcheck:jni, the Tomcat Server fails with the following log message in catalina.out (everything works fine when this option is not used) : 10-Jul-2003 15:46:30 org.apache.commons.modeler.Registry loadRegistry INFO: Loading registry information 10-Jul-2003 15:46:30 org.apache.commons.modeler.Registry getRegistry INFO: Creating new Registry instance 10-Jul-2003 15:46:31 org.apache.commons.modeler.Registry getServer INFO: Creating MBeanServer 10-Jul-2003 15:46:33 org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on port 8080 Starting service Tomcat-Standalone Apache Tomcat/4.1.24 FATAL ERROR in native method: JNI received a class argument that is not a class at java.lang.Class.isAssignableFrom(Native Method) at org.apache.commons.digester.CallMethodRule.end(CallMethodRule.java:448) at org.apache.commons.digester.Rule.end(Rule.java:276) at org.apache.commons.digester.Digester.endElement(Digester.java:1064) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.endNamespaceScope(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.endElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(Digester.java:1543) at org.apache.catalina.startup.ContextConfig.defaultConfig(ContextConfig.java:548) - locked f107a9d8 (a org.apache.commons.digester.Digester) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:638) - locked f1092150 (a org.apache.catalina.startup.ContextConfig) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3567) - locked f108c6f0 (a org.apache.catalina.core.StandardContext) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) - locked f107aeb8 (a org.apache.catalina.core.StandardHost) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) - locked f107aeb8 (a org.apache.catalina.core.StandardHost) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) - locked f10587e0 (a org.apache.catalina.core.StandardEngine) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) - locked f10587e0 (a org.apache.catalina.core.StandardEngine) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2190) - locked f1093ab0 (a [Lorg.apache.catalina.Service;) at org.apache.catalina.startup.Catalina.start(Catalina.java:512) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java CoyoteRequest.java
luehe 2003/07/10 08:51:40
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteConnector.java CoyoteRequest.java
Log:
Consider CoyoteConnector's bufferSize property when creating CoyoteRequest objects
Revision ChangesPath
1.10 +3 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteConnector.java
Index: CoyoteConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteConnector.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- CoyoteConnector.java 22 May 2003 03:43:37 - 1.9
+++ CoyoteConnector.java 10 Jul 2003 15:51:39 - 1.10
@@ -143,7 +143,7 @@
/**
* The input buffer size we should create on input streams.
*/
-private int bufferSize = 2048;
+private int bufferSize = InputBuffer.DEFAULT_BUFFER_SIZE;
/**
@@ -1122,7 +1122,7 @@
*/
public Request createRequest() {
-CoyoteRequest request = new CoyoteRequest();
+CoyoteRequest request = new CoyoteRequest(getBufferSize());
request.setConnector(this);
return (request);
1.10 +13 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java
Index: CoyoteRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- CoyoteRequest.java6 Jun 2003 19:04:50 - 1.9
+++ CoyoteRequest.java10 Jul 2003 15:51:39 - 1.10
@@ -252,7 +252,7 @@
/**
* The associated input buffer.
*/
-protected InputBuffer inputBuffer = new InputBuffer();
+protected InputBuffer inputBuffer;
/**
@@ -394,6 +394,14 @@
// - Public Methods
+/**
+ * Constructor
+ *
+ * @param inBufSize The input buffer size
+ */
+public CoyoteRequest(int inBufSize) {
+ inputBuffer = new InputBuffer(inBufSize);
+}
/**
* Release all object references, and initialize instance variables, in
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21472] New: - JDBCRealm: Auth ok but Not Authorized
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=21472. 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=21472 JDBCRealm: Auth ok but Not Authorized Summary: JDBCRealm: Auth ok but Not Authorized Product: Tomcat 3 Version: 3.3.1 Final Platform: PC OS/Version: Linux Status: NEW Severity: Blocker Priority: Other Component: Config AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello, I want to use a JDBCRealm with the admin webapp : in the debug of JDBCRealm it says 'JDBCRealm: Auth ok, user=toto' but the window Authentication required doesn't want to let me enter ... (so I push cancel and I have the message Not Authorized. So this functionnality really works or it is a configuration problem ? My apps-admin.xml : ?xml version=1.0 encoding=ISO-8859-1? webapps Context path=/admin docBase=webapps/admin reloadable=true trusted=true JDBCRealm debug=99 driverName=org.gjt.mm.mysql.Driver connectionURL=jdbc:mysql://localhost/User connectionName=adminTomcat connectionPassword=adminTomcat userTable=user userNameCol=user_name userCredCol=user_pass userRoleTable=user_roles roleNameCol=role_name digest=No / /Context /webapps My mysql User base : mysql select * from user; +---+---+ | user_name | user_pass | +---+---+ | toto | passtoto | | titi | passtiti | | tutu | passtutu | +---+---+ 3 rows in set (0.01 sec) mysql select * from role; +--+ | role_name| +--+ | role1| | tomcat | | tomcat_admin | +--+ 3 rows in set (0.00 sec) mysql select * from user_roles; +--+---+ | user_name| role_name | +--+---+ | role1| tutu | | tomcat | tutu | | tomcat_admin | titi | | tomcat_admin | toto | +--+---+ 4 rows in set (0.00 sec) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0] [PROPOSAL] Make output buffer size limit configurable
Currently, the limit up to which the size of an
org.apache.coyote.tomcat5.OutputBuffer may grow is identical to the
original buffer size:
public OutputBuffer(int size) {
bb = new ByteChunk(size);
bb.setLimit(size);
...
cb = new CharChunk(size);
cb.setLimit(size);
}
As a result of this, if the response does not fit in the output
buffer, the buffer is flushed, and the response does no longer include
a Content-Length header. Instead, it includes a Transfer-Encoding
header whose value is chunked:
Transfer-Encoding: chunked
It may be useful (e.g., for some benchmarks such as TPC-W) to be able
to configure a connector such that the buffer size of its responses
grows infinitely, in which case the above setLimit calls would not
occur and the response would always include a Content-Length header,
no matter how big.
I am proposing a CoyoteConnector attribute outLimited (I am open to
other naming suggestions), whose possible values may be TRUE (default)
or FALSE: if TRUE, the output buffer size limit is set to the output
buffer size (current behaviour), and if FALSE, an output buffer may
grow infinitely.
Comments?
Jan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.x] Next release
Hello, About the 4.1.25 tagging which is taking place. What is going to be the status of http gzip compression in 4.1.25? See bug 18073. Or will there follow a 4.1.26-BETA in the near future with some enhanced functionality? Greetings, Ronald. On Wednesday 02 April 2003 11:37, Remy Maucherat wrote: Hi, As far as I am concerned, the focus for the next stable 4.1.x release will be on small fixes. I do not want to introduce new features or changes which would affect Tomcat's behavior. I think the ETA for that next stable release could be within one to two months. So I would need to compile a list of issues which should be fixed in the next release. As a starting point: - Fix HTTP compression check (I think a small refactoring is needed to make the feature cleaner). - Fix FORM processing for more complex requests (bug 10229). - Error message when the Java compiler is not found by Ant (if this is fixable; Costin ?). - Double wrapping of session objects. I'm waiting for some input to fill up the list. Note that for low priority bugs, a patch will be required. The patch would need to: - have a low impact - be of good quality (no performance/scalability impact, clean code) Thanks, Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DOC PATCH webapps/tomcat-docs/config/valve.xml] Documentation for rotatable
The attribute of 'rotatable' for Valve appears to be missing. The following patch fixes that. Feel free to change wording. -- Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DOC PATCH webapps/tomcat-docs/config/valve.xml] Documentation fo r rotatable
The patch seems to be missing, and I attached it, but got lost somewhere. Now with my luck, this patch will get wrapped. In any case, at least the issue of this attribute missing from the documentation has been made aware. Index: webapps/tomcat-docs/config/valve.xml === RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/tomcat-docs/config/valve.xml,v retrieving revision 1.8 diff -u -r1.8 valve.xml --- webapps/tomcat-docs/config/valve.xml12 Jan 2003 17:26:48 - 1.8 +++ webapps/tomcat-docs/config/valve.xml10 Jul 2003 20:52:00 - @@ -92,6 +92,13 @@ codefalse/code to skip this lookup, and report the remote IP address instead./p /attribute + + attribute name=rotatable required=false +pSet to codetrue/code to rotate the logs once a day. This +will add a date to the end of file's name for each day. Set to +codefalse/code to not rotate each log. The default value is +true. + /attribute attribute name=suffix required=false pThe suffix added to the end of each log file's name. If not -Original Message- From: Shatzer, Larry [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 1:57 PM To: '[EMAIL PROTECTED]' Subject: [DOC PATCH webapps/tomcat-docs/config/valve.xml] Documentation fo r rotatable The attribute of 'rotatable' for Valve appears to be missing. The following patch fixes that. Feel free to change wording. -- Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.25] Tag today
Glenn, This is quite interesting. How many concurrent threads need to be running before this bottleneck starts to become a significant issue? Does a simple test case which simply starts up a number of threads which all use one of the classes shown below display the problem nicely? I'd guess that one workaround would be to start up multiple instances of Tomcat on a single server (which it appears you have already tried) and make sure you have enough memory for all of them. -Dave On Thu, Jul 10, 2003 at 03:27:19AM -0500, Glenn Nielsen wrote: Remy, It can wait, go ahead with the release. But the FileLogger's use of java.sql.Timestamp is a bottleneck, I have the thread dump stack traces to prove that it is. Right now the biggest problem I have with Tomcat scaling is with this type of synchronization bottleneck. I have thread dump stack traces where two thirds of the threads are waiting on the same synchronization bottleneck related to use of one or more of the following classes: java.util.Date java.util.TimcZone.getDefault() java.util.Calendar.getInstance() java.text.SimpleDateFormat java.sql.Date java.sql.Time java.sql.Timestamp They all hit the same synchronization bottleneck. And I have multiple code bases that have to go through this bottleneck; Tomcats FileLogger which gets used a great deal for the Connector log when Tomcat is heavily loaded, the MySQL Connector/J JDBC driver, and I have customer web application code which hits this also. Due to scaling problems I setup a second app server and load balancing. It still did not scale well because of the above synchronization bottleneck. Both app servers became overloaded due to this bottleneck. I now think the best solution might be a commons project to provide alternate solutions for the above date related classes designed so that this synchronization bottleneck is avoided. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5CoyoteConnector.java CoyoteRequest.java
[EMAIL PROTECTED] wrote: luehe 2003/07/10 08:51:40 Modified:catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java CoyoteRequest.java Log: Consider CoyoteConnector's bufferSize property when creating CoyoteRequest objects Why break the no arg constructor design ? The buffer size should be set to the default of the servlet API, and the buffer will just have to grow a few times, so there's no performance impact. Is there a real justification for this change ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Jan Luehe wrote:
Currently, the limit up to which the size of an
org.apache.coyote.tomcat5.OutputBuffer may grow is identical to the
original buffer size:
public OutputBuffer(int size) {
bb = new ByteChunk(size);
bb.setLimit(size);
...
cb = new CharChunk(size);
cb.setLimit(size);
}
As a result of this, if the response does not fit in the output
buffer, the buffer is flushed, and the response does no longer include
a Content-Length header. Instead, it includes a Transfer-Encoding
header whose value is chunked:
Transfer-Encoding: chunked
It may be useful (e.g., for some benchmarks such as TPC-W) to be able
to configure a connector such that the buffer size of its responses
grows infinitely, in which case the above setLimit calls would not
occur and the response would always include a Content-Length header,
no matter how big.
I am proposing a CoyoteConnector attribute outLimited (I am open to
other naming suggestions), whose possible values may be TRUE (default)
or FALSE: if TRUE, the output buffer size limit is set to the output
buffer size (current behaviour), and if FALSE, an output buffer may
grow infinitely.
Comments?
-1. The performance impact of chunking on the server side is zero. If
you client bench program is dumb and its performance degrades with
chunking, fine, but please keep this optimization for SunOne ;-) Your
change basically does an automatic DoS condition on the server (simply
request a big file and boom).
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
java Date related classes synchronization bottlenecks
David Rees wrote:
Glenn,
This is quite interesting. How many concurrent threads need to be
running before this bottleneck starts to become a significant issue?
The worst case we have seen so far is when a JDBC query was made which
returned 100's of result sets where one of the fields was of type
DATE, TIME, or DATESTAMP. A java.sql.(Date|Time|Timestamp) would get
created for each row in the result as you iterated over it. This was
with the MySQL Connector/J JDBC driver, other JDBC drivers might perform
better.
It doesn't take too many conncurrent requests doing this before the app
server starts bogging down. Especially when there are other things using
Date related classes like web application code and Loggers.
Here is an example of what happens with the org.apache.catalina.logger.FileLogger:
public void log(String msg) {
// Construct the timestamp we will use, if requested
Timestamp ts = new Timestamp(System.currentTimeMillis());
String tsString = ts.toString().substring(0, 19);
String tsDate = tsString.substring(0, 10);
...
}
Now use jar to unarchive the src.jar file in your java SDK.
Take a look at the java.sql.Timestamp.toString() method which the FileLogger
above uses.
Each of the six get methods used in Timestamp.toString() trigger one or two
synchronizationsin in the underlying java.util.Date object. Each of those get
methods end up calling a synchronized block on a static object in java.util.Date
and a call to the static synchronized TimeZone.getDefault() method,
or one to two calls to the static synchronized TimeZone.getDefault() method.
So when the FileLogger logs it ends up hitting a synchronized block a minimum of
six times, but usually twelve times.
To verify this look at the source for java.util.Date.getField().
And there are many other synchronization bottlenecks in the following Date
related classes:
java.util.Calendar.getInstance()
java.util.Date
java.util.TimeZone.getDefault()
java.sql.Date
java.sql.Time
java.sql.Timestamp
Does a simple test case which simply starts up a number of threads which
all use one of the classes shown below display the problem nicely?
I am sure it would, I haven't had time to write one up yet.
Regards,
Glenn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt
remm2003/07/10 15:59:28 Modified:.RELEASE-NOTES-4.1.txt Log: - Update release notes for 4.1.25, and tagging. Revision ChangesPath 1.75 +65 -6 jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt Index: RELEASE-NOTES-4.1.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v retrieving revision 1.74 retrieving revision 1.75 diff -u -r1.74 -r1.75 --- RELEASE-NOTES-4.1.txt 6 Jul 2003 06:37:16 - 1.74 +++ RELEASE-NOTES-4.1.txt 10 Jul 2003 22:59:28 - 1.75 @@ -65,7 +65,6 @@ [4.1.19] Administration Webapp: Complete the accessibility requirements to pass section 508. - - Catalina New Features: - @@ -130,6 +129,11 @@ [4.1.20] GlobalResourcesLifecycleListener: Allow the listener to be associated with a Service. +[4.1.25] ExtendedAccessLogValve: + An implementation of the W3c Extended Log File Format. See + http://www.w3.org/TR/WD-logfile.html for more information + about the format. + --- Jasper New Features: @@ -734,6 +738,33 @@ [4.1.25] #9851 Improve Digest Authentication compatibility +[4.1.25] #20380 + AccessLogValve incorrectly calculates timezone. + +[4.1.25] #16374 + AccessLogValve Date in file name configurable. + +[4.1.25] #16400 + AccessLogValve Allow logging to be conditional. + +[4.1.25] AccessLogValve Add %D, %T for time to serve request. + +[4.1.25] StandardContext: + Fix listener shutdown order for JNDI access. + +[4.1.25] StandardContext: + Return facaded context. + +[4.1.25] StandardWrapper: + Fix SingleThreadModel NPE after a reload. + +[4.1.25] WebappClassLoader: + Display more debugging when a CL stopped error occurs. + +[4.1.25] StandardSession: + Clone enumerated list to allow mutating. + + Coyote Bug Fixes: @@ -912,6 +943,9 @@ CoyoteResponse: Fix value of the committed flag after the response is finished. +[4.1.25] Shell scripts: + Add support for OS/400. + [4.1.25] JkHandler: Fix decoding of SSL CLIENT-CERTs passed from Apache/IIS/iPlanet. @@ -919,18 +953,33 @@ Fix potential path-traversal problem in mappings. [4.1.25] JSSE SSL: - Re-factor to remove dependencies on Sun classes when using a 1.4.x JVM. - It should now be possible to set up a SSL Connector with any vendors - 1.4.x JVM, without having to install Sun's JSSE 1.0.x. + Re-factor to remove dependencies on Sun classes when using a 1.4.x + JVM. It should now be possible to set up a SSL Connector + with any vendors 1.4.x JVM, without having to install + Sun's JSSE 1.0.x. [4.1.25] PureTLS SSL: Fix problems with getting the CLIENT-CERT. +[4.1.25] CoyoteConnector: + Disable server socket timeout by default, to minimize the amount of + generated garbage, especially in SSL mode. + [4.1.25] #21219 Http11Processor: Drop the client connection (nicely, if possible, rudely if not) in the event of a serious protocol error. - + +[4.1.25] CoyoteRequestFacade: + Fix double facading of the request object. + +[4.1.25] HandlerRequest: + Fix incorrect recycling of SSL certificates in JK 2. + +[4.1.25] Http11Processor: + Catch exceptions which could occur in prepareRequest. + + Jasper Bug Fixes: @@ -1237,6 +1286,16 @@ [4.1.24] JspC: Set the thread context class loader to the specified classpath. + +[4.1.25] #18314 + PageDataImpl: + Multiple declarations of same taglib cause exception during + validation. + +[4.1.25] #18496 + Parser: + Special characters not escaped in Unterminated ... tag + error message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5CoyoteConnector.java CoyoteRequest.java
Remy, luehe 2003/07/10 08:51:40 Modified:catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java CoyoteRequest.java Log: Consider CoyoteConnector's bufferSize property when creating CoyoteRequest objects Why break the no arg constructor design ? The buffer size should be set to the default of the servlet API, and the buffer will just have to grow a few times, so there's no performance impact. Is there a real justification for this change ? The only reason for this change is that I don't see where the connector's 'bufferSize' property is currently being used. If it's not used at all, we may want to start using it or remove it altogether. Do you agree? Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21482] New: - jikes cannot compile JSP page importing anything from javax.crypto package (in Java 1.4.x)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21482. 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=21482 jikes cannot compile JSP page importing anything from javax.crypto package (in Java 1.4.x) Summary: jikes cannot compile JSP page importing anything from javax.crypto package (in Java 1.4.x) Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Simple JSP page: %@ page import=javax.crypto.Cipher % html body Hello there. /body /html If you are using javac, it works fine. But if you set your jsp compiler to jikes, it will fail: /home/kylev/perforce/thirdparty/apache/jakarta-tomcat-4.1.24/work/Standalone/localhost/_/testjce_jsp.java:7:8:7:26: Semantic Error: The import javax/crypto/Cipher is not valid, since it does not name a type in a package. This is probably owing to the classpath being generated lacking the jce.jar (which sits along side rt.jar). Interestingly, the classpath does include sunjce_provider.jar, the old com.sun.java.crypto package. Not sure if this might be an ant problem. (Jikes Compiler - Version 1.18 - 21 November 2002) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java CoyoteConnector.java
luehe 2003/07/10 16:30:50
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java CoyoteConnector.java
Log:
Backed out earlier change
Revision ChangesPath
1.11 +5 -14
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java
Index: CoyoteRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- CoyoteRequest.java10 Jul 2003 15:51:39 - 1.10
+++ CoyoteRequest.java10 Jul 2003 23:30:49 - 1.11
@@ -252,7 +252,7 @@
/**
* The associated input buffer.
*/
-protected InputBuffer inputBuffer;
+protected InputBuffer inputBuffer = new InputBuffer();
/**
@@ -393,15 +393,6 @@
protected Log log=null;
// - Public Methods
-
-/**
- * Constructor
- *
- * @param inBufSize The input buffer size
- */
-public CoyoteRequest(int inBufSize) {
- inputBuffer = new InputBuffer(inBufSize);
-}
/**
* Release all object references, and initialize instance variables, in
1.11 +3 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteConnector.java
Index: CoyoteConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteConnector.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- CoyoteConnector.java 10 Jul 2003 15:51:39 - 1.10
+++ CoyoteConnector.java 10 Jul 2003 23:30:49 - 1.11
@@ -143,7 +143,7 @@
/**
* The input buffer size we should create on input streams.
*/
-private int bufferSize = InputBuffer.DEFAULT_BUFFER_SIZE;
+private int bufferSize = 2048;
/**
@@ -1122,7 +1122,7 @@
*/
public Request createRequest() {
-CoyoteRequest request = new CoyoteRequest(getBufferSize());
+CoyoteRequest request = new CoyoteRequest();
request.setConnector(this);
return (request);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5CoyoteConnector.java CoyoteRequest.java
Jan Luehe wrote: Remy, luehe 2003/07/10 08:51:40 Modified:catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java CoyoteRequest.java Log: Consider CoyoteConnector's bufferSize property when creating CoyoteRequest objects Why break the no arg constructor design ? The buffer size should be set to the default of the servlet API, and the buffer will just have to grow a few times, so there's no performance impact. Is there a real justification for this change ? The only reason for this change is that I don't see where the connector's 'bufferSize' property is currently being used. If it's not used at all, we may want to start using it or remove it altogether. Do you agree? Well, yes. The default buffer size is forced by the servlet API, and then it can be changed with setBufferSize. If something is not used, then it would seem it can be removed. Maybe it was a parameter which existed in the old connector ... Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Soft termination: a demonstration
Algis Rudys wrote: Greetings -- As I announces about a week ago, as a part of my research, I have developed a mechanism for terminating individual Tomcat webapps (at the context level) called soft termination. For your further enjoyment, I've taken the liberty of setting up a demo install of my soft termination system. The demo install is at: http://puppet.cs.rice.edu:8080/ In particular, the following URL runs an infinite loop that prints the current time each second (note it does this with a while(true) and no sleeps): http://puppet.cs.rice.edu:8080/examples/servlet/ExceptionExample And this URL prints the current system status of the machine in question (updated once per second): http://www.cs.rice.edu/~arudys/loadavg.html Every 10 seconds, termination of the examples webapp is triggered. Note that it is triggered by updating the modification date of the ExceptionExample.class file (forcing a reload which terminates the old webapp) and not from within Tomcat. Once again, links for downloading the code and to the journal article describing soft termination can be found off this site: http://www.cs.rice.edu/~arudys/software/#softterm And feel free to badger me with any questions you see fit. Enjoy. Be nice. Ok, that sounds cool :) That kind of tech could add extra robustness to TC. Right now, I don't quite undestand how it works, though :-P I'll try to look at it next week. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Buggy mod_jk2 AJP 13 communications?
Henri, thanks a million for your help. I think I'll try out jk2 2.0.2 and while that's being tested work out jk 1.2.4 as a fall back. Do you have any thoughts on the use of the channel socket options nodelay, timeout, and keepalive. I'm also thinking that having the connectionTimeout set to 0 or -1 (infinite) for my JK2 CoyoteConnector is not good either because if something get's wedged the server never drops the socket. It would be great to see some additional documentation on these use of these options. Interestingly Nagle is defaulted to off (nodelay on) in the Java side of the connectors in Tomcat 4.1.24 (see ChannelSocket.java) and turned on (nodelay off) by default in the Apache (see jk_channel_socket.c). According to Stevens UNIX Network Programming Volume 1, Second Edition, Nagle is on by default in Unix systems. Anyones input on the use of these options would be great. Thanks! Jamey James Courtney InPhonic, Inc. -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 1:30 AM To: Tomcat Developers List Subject: Re: Buggy mod_jk2 AJP 13 communications? James Courtney a écrit : Developers, Forgive the post to the developer list but I honestly feel that my question(s) are detailed enought to be of interest to the development community for Tomcat and have thus far remained largely unaddressed by the tomcat-user community. Please also forgive the length of the email but as a developer I try to provide any and all information that I've gathered to give anyone willing to help me as much relevant information as possible. Please keep in mind while reading and formulating your answer(s) that I really don't have the luxury of taking wild stabs in the dark with this as it's a current production problem for us. I need to know the best course of action to take to correct our systems to provide reliable service to our users. We recently launched our application running on 2 Tomcat 4.1.24/JDK1.4.1/Sun 2.8/Sparc machines load balanced by an Apache 2.0.45/Sun2.8/Sparc machine using mod_jk2. Throughout testing (including some basic load testing) we experienced very good behavior from our cluster and are in general very pleased with the performance over our previous system of Apache 1.3.19/Tomcat 3.2.2/mod_jk. We built our mod_jk2 Apache module using the 4.1.24 Tomcat-Connectors source release provided with the Tomcat 4.1.24 release. This seems to be slightly more recent than the last public release of mod_jk2 which I think was 2.0.2 according to CVS and what I've read. Our problem is that we notice intermittent and not infrequent lapses in our application. These appear as very slow performance or complete lack of connectivity to the Apache server but each of the Tomcat servers is functioning normally when we connect directly to those. Apache serves no contect, static or dynamic, and everything is pushed to the Tomcat servers as the bulk of our page content is dynamic and we decided to keep the config simple at the expense of a little network performance on what static content we have. It's about the peak time of day for us and we have 50-60 active TCP connections from our Apache server to EACH Tomcat server, all in the ESTABLISHED state according to netstat. We have an additional 220 or so TCP connections from the internet to our Apache server of which about 30 are ESTABLISHED, about 20 are FIN_WAIT (and FIN_WAIT_2), and about 170 are TIME_WAIT. Assuming ajp13 works like HTTP1.1 this all makes sense as the Apache would keep sockets open to the Tomcats and internet users opening and closing connections and browsers to the Apache would probably create a pattern like that above. I've attached several of our config files for your reference: 1) httpd.conf (for Apache or course) 2) workers2.properties (for mod_jk2 of course) 3) server.xml (from one Tomcat, both are indentical with exception of jvmRoute) 4) jk2.properties (Still don't know the point of this but here it is) 3) apache.info (a dump using httpd -V) I have several general questions which I feel can only be answered by those fairly familiar with the mod_jk/jk2 code. 1) Which is the preferred connector at this time in terms of reliability and scalability. mod_jk is the preferred in term of reliability since it's older and more tested, but jk2 is the future. 2) What is the preferred version/release of that connector. mod_jk 1.2.5 should be release soon. 3) Should both the java and c/apache side of the connector be built and installed together onto Tomcat 4.1.24 for compatibility or is the c/apache side alone sufficient to work reliably with the CoyoteConnector/JkCoyoteHandler packaged with the 4.1.24 build? mod_jk should be built from jakarta-tomcat-connectors release. 4) Does Apache mod_jk(2) pool a set of connections to Tomcat not to exceed the maxProcessors
Tomcat session replication using javagroups.. free dinner in BNE for the best helper :)
I am going crazy... I have two 4.1 tomcat's set up like thus: Logger className=org.apache.catalina.logger.FileLogger prefix=localhost_reptest_log. suffix=.txt timestamp=true/ Valve className=org.apache.catalina.session.ReplicationValve filter=.*\.gif;.*\.jpg;.*\.jpeg;.*\.js debug=10/ Manager className=org.apache.catalina.session.InMemoryReplicationManager debug=10 printToScreen=true saveOnRestart=false maxActiveSessions=-1 minIdleSwap=-1 maxIdleSwap=-1 maxIdleBackup=-1 pathnam=null pathname= printSessionInfo=true checkInterval=10 expireSessionsOnShutdown=false serviceclass=org.apache.catalina.cluster.mcast.McastService mcastAddr=192.168.2.22 crap=228.1.2.3 mcastPort=45566 mcastFrequency=500 mcastDropTime=5000 tcpListenAddress=auto tcpListenPort=4002 tcpSelectorTimeout=100 tcpThreadCount=2 useDirtyFlag=true /Manager I have changed useDirtyFlag and the mcastAddr... but not much has changed (in the way of errors)... I have these jar's included in /server/lib: javagroups-all.jar, tomcat-replication.jar, tomcat-javagroups.jar This is what happens when I try to use the replicator: == /usr/local/tomcat2/logs/catalina_log.2003-07-11.txt == 2003-07-11 10:02:59 Ajp13Processor[12009][4] process: invoke java.lang.NoSuchMethodError: org.apache.catalina.session.InMemoryReplicationManager.requestCompleted(Ljava/lang/String;)V at org.apache.catalina.session.ReplicationValve.invoke(ReplicationValve.java:210) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:458) at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:551) at java.lang.Thread.run(Thread.java:536) == /usr/local/tomcat2/logs/localhost_reptest_log.2003-07-11.txt == 2003-07-11 10:02:59 StandardWrapperValve[invoker]: Servlet.service() for servlet invoker threw exception javax.servlet.ServletException: Invoker service() exception at org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:524) at org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:180) 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.access$000(ApplicationFilterChain.java:98) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:176) at
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java CoyoteServerSocketFactory.java mbeans-descriptors.xml
luehe 2003/07/10 18:04:43
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteConnector.java CoyoteServerSocketFactory.java
mbeans-descriptors.xml
Log:
Added support for enabling subset of supported SSL cipher suites (based on earlier
proposal)
Revision ChangesPath
1.12 +34 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteConnector.java
Index: CoyoteConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteConnector.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- CoyoteConnector.java 10 Jul 2003 23:30:49 - 1.11
+++ CoyoteConnector.java 11 Jul 2003 01:04:43 - 1.12
@@ -1294,6 +1294,8 @@
IntrospectionUtils.setProperty(protocolHandler,
sSLImplementation,
ssf.getSSLImplementation());
+IntrospectionUtils.setProperty(protocolHandler, ciphers,
+ ssf.getCiphers());
} else {
IntrospectionUtils.setProperty(protocolHandler, secure,
+ false);
@@ -1461,7 +1463,6 @@
return null;
}
-
/**
* Set keystorePass
*/
@@ -1472,6 +1473,38 @@
((CoyoteServerSocketFactory)factory).setKeystorePass(keystorePass);
}
}
+
+/**
+ * Gets the list of SSL cipher suites that are to be enabled
+ *
+ * @return Comma-separated list of SSL cipher suites, or null if all
+ * cipher suites supported by the underlying SSL implementation are being
+ * enabled
+ */
+public String getCiphers() {
+ServerSocketFactory factory = getFactory();
+if (factory instanceof CoyoteServerSocketFactory) {
+return ((CoyoteServerSocketFactory)factory).getCiphers();
+}
+return null;
+}
+
+/**
+ * Sets the SSL cipher suites that are to be enabled.
+ *
+ * Only those SSL cipher suites that are actually supported by
+ * the underlying SSL implementation will be enabled.
+ *
+ * @param ciphers Comma-separated list of SSL cipher suites
+ */
+public void setCiphers(String ciphers) {
+setProperty(ciphers, ciphers);
+ServerSocketFactory factory = getFactory();
+if (factory instanceof CoyoteServerSocketFactory) {
+((CoyoteServerSocketFactory)factory).setCiphers(ciphers);
+}
+}
+
// JMX registration
protected String domain;
1.2 +108 -36
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteServerSocketFactory.java
Index: CoyoteServerSocketFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteServerSocketFactory.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- CoyoteServerSocketFactory.java19 Apr 2003 18:49:10 - 1.1
+++ CoyoteServerSocketFactory.java11 Jul 2003 01:04:43 - 1.2
@@ -102,48 +102,73 @@
public class CoyoteServerSocketFactory
implements org.apache.catalina.net.ServerSocketFactory {
+private String algorithm = null;
+private boolean clientAuth = false;
+private String keystoreFile =
+System.getProperty(user.home) + File.separator + .keystore;
+private String randomFile =
+System.getProperty(user.home) + File.separator + random.pem;
+private String rootFile =
+System.getProperty(user.home) + File.separator + root.pem;
+private String keystorePass = changeit;
+private String keystoreType = JKS;
+private String protocol = TLS;
+private String sslImplementation = null;
+private String cipherSuites;
// - Properties
-
/**
- * Certificate encoding algorithm to be used.
+ * Gets the certificate encoding algorithm to be used.
+ *
+ * @return Certificate encoding algorithm
*/
-private String algorithm = null;
-
public String getAlgorithm() {
return (this.algorithm);
}
+/**
+ * Sets the certificate encoding algorithm to be used.
+ *
+ * @param algorithm Certificate encoding algorithm
+ */
public void setAlgorithm(String algorithm) {
this.algorithm = algorithm;
}
-
/**
- * Should we require client
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse JSSE14SocketFactory.java JSSESocketFactory.java
luehe 2003/07/10 18:04:54
Modified:util/java/org/apache/tomcat/util/net/jsse
JSSE14SocketFactory.java JSSESocketFactory.java
Log:
Added support for enabling subset of supported SSL cipher suites (based on earlier
proposal)
Revision ChangesPath
1.3 +29 -60
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE14SocketFactory.java
Index: JSSE14SocketFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE14SocketFactory.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JSSE14SocketFactory.java 15 Mar 2003 07:00:07 - 1.2
+++ JSSE14SocketFactory.java 11 Jul 2003 01:04:54 - 1.3
@@ -60,10 +60,8 @@
import java.io.*;
import java.net.*;
-
import java.security.KeyStore;
-
-import java.security.Security;
+import java.security.SecureRandom;
import javax.net.ServerSocketFactory;
import javax.net.ssl.SSLServerSocket;
import javax.net.ssl.SSLSocket;
@@ -99,82 +97,53 @@
super();
}
-// Internal methods
-/** Read the keystore, init the SSL socket factory
+/**
+ * Reads the keystore and initializes the SSL socket factory.
*/
-void initProxy() throws IOException {
+void init() throws IOException {
try {
-// Please don't change the name of the attribute - other
-// software may depend on it ( j2ee for sure )
-String keystoreFile=(String)attributes.get(keystore);
-if( keystoreFile==null) keystoreFile=defaultKeystoreFile;
-
-keystoreType=(String)attributes.get(keystoreType);
-if( keystoreType==null) keystoreType=defaultKeystoreType;
-
-//determine whether we want client authentication
-// the presence of the attribute enables client auth
-String clientAuthStr=(String)attributes.get(clientauth);
-if(clientAuthStr != null){
-if(clientAuthStr.equals(true)){
-clientAuth=true;
-} else if(clientAuthStr.equals(false)) {
-clientAuth=false;
-} else {
-throw new IOException(Invalid value ' +
- clientAuthStr +
- ' for 'clientauth' parameter:);
-}
-}
-
-String keyPass=(String)attributes.get(keypass);
-if( keyPass==null) keyPass=defaultKeyPass;
+ String clientAuthStr = (String)attributes.get(clientauth);
+ if (clientAuthStr != null){
+ clientAuth = Boolean.valueOf(clientAuthStr).booleanValue();
+ }
-String keystorePass=(String)attributes.get(keystorePass);
-if( keystorePass==null) keystorePass=keyPass;
-
-//protocol for the SSL ie - TLS, SSL v3 etc.
+ // SSL protocol variant (e.g., TLS, SSL v3, etc.)
String protocol = (String)attributes.get(protocol);
-if(protocol == null) protocol = defaultProtocol;
-
-//Algorithm used to encode the certificate ie - SunX509
+if (protocol == null) protocol = defaultProtocol;
+
+ // Certificate encoding algorithm (e.g., SunX509)
String algorithm = (String)attributes.get(algorithm);
-if(algorithm == null) algorithm = defaultAlgorithm;
-
-// You can't use ssl without a server certificate.
-// Create a KeyStore ( to get server certs )
-KeyStore kstore = initKeyStore( keystoreFile, keystorePass );
-
-SSLContext context = SSLContext.getInstance(protocol); //SSL
+if (algorithm == null) algorithm = defaultAlgorithm;
-// Key manager will extract the server key
+// Set up KeyManager, which will extract server key
KeyManagerFactory kmf = KeyManagerFactory.getInstance(algorithm);
-kmf.init( kstore, keyPass.toCharArray());
+ String keystoreType = (String)attributes.get(keystoreType);
+ if (keystoreType == null)
+ keystoreType = defaultKeystoreType;
+ String keystorePass = getKeystorePassword();
+kmf.init(getKeystore(keystoreType, keystorePass),
+ keystorePass.toCharArray());
-// set up TrustManager
+// Set up TrustManager
TrustManager[] tm = null;
-String trustStoreFile = System.getProperty(javax.net.ssl.trustStore);
-String trustStorePassword =
-
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Protocol.java
luehe 2003/07/10 18:06:04
Modified:http11/src/java/org/apache/coyote/http11 Http11Protocol.java
Log:
Added support for enabling subset of supported SSL cipher suites (based on earlier
proposal)
Revision ChangesPath
1.30 +4 -0
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java
Index: Http11Protocol.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- Http11Protocol.java 13 Jun 2003 05:14:50 - 1.29
+++ Http11Protocol.java 11 Jul 2003 01:06:04 - 1.30
@@ -352,6 +352,10 @@
setAttribute(secure, + b);
}
+public void setCiphers(String ciphers) {
+setAttribute(ciphers, ciphers);
+}
+
/** Set the maximum number of Keep-Alive requests that we will honor.
*/
public void setMaxKeepAliveRequests(int mkar) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime ServletResponseWrapperInclude.java JspRuntimeLibrary.java
luehe 2003/07/10 18:27:46
Modified:jasper2/src/share/org/apache/jasper/runtime
ServletResponseWrapperInclude.java
JspRuntimeLibrary.java
Log:
Partial fix for Bugzilla 21440 (jsp:include whose target performs a 'forward'
does not behave as expected)
Revision ChangesPath
1.3 +32 -24
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/ServletResponseWrapperInclude.java
Index: ServletResponseWrapperInclude.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/ServletResponseWrapperInclude.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ServletResponseWrapperInclude.java27 Aug 2002 22:24:42 - 1.2
+++ ServletResponseWrapperInclude.java11 Jul 2003 01:27:46 - 1.3
@@ -64,49 +64,57 @@
import java.lang.IllegalStateException;
import java.io.Writer;
import java.io.PrintWriter;
+import java.io.IOException;
import javax.servlet.*;
import javax.servlet.http.*;
-import javax.servlet.jsp.*;
+import javax.servlet.jsp.JspWriter;
/**
- * ServletResponseWrapper used for the JSP 'include' action.
+ * ServletResponseWrapper used by the JSP 'include' action.
*
- * This 'wrapped' response object is passed as the second argument
- * to the internal RequestDispatcher.include(). It channels
- * all output text into the current Writer.
+ * This wrapper response object is passed to RequestDispatcher.include(), so
+ * that the output of the included resource is appended to that of the
+ * including page.
*
* @author Pierre Delisle
*/
-public class ServletResponseWrapperInclude
-extends HttpServletResponseWrapper
-{
+public class ServletResponseWrapperInclude extends HttpServletResponseWrapper {
+
/**
- * The PrintWriter writes all output to the Writer of the
- * including page.
+ * PrintWriter which appends to the JspWriter of the including page.
*/
-PrintWriter printWriter;
+private PrintWriter printWriter;
+
+private JspWriter jspWriter;
public ServletResponseWrapperInclude(ServletResponse response,
- Writer writer)
-{
+ JspWriter jspWriter) {
super((HttpServletResponse)response);
- this.printWriter = new PrintWriter(writer);
+ this.printWriter = new PrintWriter(jspWriter);
+ this.jspWriter = jspWriter;
}
/**
- * Returns a wrapper around the Writer of the including page.
+ * Returns a wrapper around the JspWriter of the including page.
*/
-public java.io.PrintWriter getWriter()
- throws java.io.IOException
-{
+public PrintWriter getWriter() throws IOException {
return printWriter;
}
-public ServletOutputStream getOutputStream()
- throws java.io.IOException
-{
+public ServletOutputStream getOutputStream() throws IOException {
throw new IllegalStateException();
+}
+
+/**
+ * Clears the output buffer of the JspWriter associated with the including
+ * page.
+ */
+public void resetBuffer() {
+ try {
+ jspWriter.clearBuffer();
+ } catch (IOException ioe) {
+ }
}
}
1.23 +4 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java
Index: JspRuntimeLibrary.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- JspRuntimeLibrary.java13 May 2003 19:36:37 - 1.22
+++ JspRuntimeLibrary.java11 Jul 2003 01:27:46 - 1.23
@@ -984,7 +984,7 @@
public static void include(ServletRequest request,
ServletResponse response,
String relativePath,
- Writer out,
+ JspWriter out,
boolean flush)
throws IOException, ServletException {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime PageContextImpl.java
luehe 2003/07/10 18:29:14
Modified:jasper2/src/share/org/apache/jasper/runtime
PageContextImpl.java
Log:
cleanup
Revision ChangesPath
1.50 +4 -16
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java
Index: PageContextImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java,v
retrieving revision 1.49
retrieving revision 1.50
diff -u -r1.49 -r1.50
--- PageContextImpl.java 17 May 2003 00:14:10 - 1.49
+++ PageContextImpl.java 11 Jul 2003 01:29:14 - 1.50
@@ -205,15 +205,12 @@
// initialize the initial out ...
depth = -1;
if (this.baseOut == null) {
-this.baseOut = _createOut(bufferSize, autoFlush);
+this.baseOut = new JspWriterImpl(response, bufferSize, autoFlush);
} else {
this.baseOut.init(response, bufferSize, autoFlush);
}
this.out = baseOut;
- if (this.out == null)
- throw new IllegalStateException(failed initialize JspWriter);
-
// register names/values as per spec
setAttribute(OUT, this.out);
setAttribute(REQUEST, request);
@@ -768,13 +765,4 @@
return retValue;
}
-private JspWriterImpl _createOut(int bufferSize, boolean autoFlush)
-throws IOException {
-try {
-return new JspWriterImpl(response, bufferSize, autoFlush);
-} catch( Throwable t ) {
-log.warn(creating out, t);
-return null;
-}
-}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: java Date related classes synchronization bottlenecks
On Thu, Jul 10, 2003 at 05:46:06PM -0500, Glenn Nielsen wrote:
Now use jar to unarchive the src.jar file in your java SDK.
Take a look at the java.sql.Timestamp.toString() method which the FileLogger
above uses.
To verify this look at the source for java.util.Date.getField().
Yes, that looks bad (looking at 1.4.2 src)! It appears that avoiding calls to the
Timestamp.toString() is really to be avoided if possible.
And there are many other synchronization bottlenecks in the following Date
related classes:
java.util.Calendar.getInstance()
java.util.Date
java.util.TimeZone.getDefault()
java.sql.Date
java.sql.Time
java.sql.Timestamp
I took a look at some of these, these don't appear to be as bad as the
Timestamp.toString().
I did a quick google of Date performance issues and didn't find
anything. Is this a well known bottleneck in multi-threaded
applications?
Does a simple test case which simply starts up a number of threads which
all use one of the classes shown below display the problem nicely?
I am sure it would, I haven't had time to write one up yet.
I wrote a simple multithreaded program which makes calls to
Timestamp.toString() and varied the number of threads running and the
number of calls. On a single CPU system (a Duron 600), scaling from
1-20 threads performed as I expected, with the 20 thread iteration
taking only slightly longer than the single thread iteration.
However, when running this on a dual-cpu system (PIII 500), going from
1 to 2 treads took over twice as long for the same overall number of
calls to Timestamp.toString(). From 4-20 threads overall time
slightly increased most likely due to the overhead of scheduling
multiple threads.
You must be running on a multiple-CPU system as it doesn't appear to be
a bottle-neck (except for the fact that it's a slow operation) on a
single-cpu machine and only one multi-cpu machines.
Given that this is the case, a temporary fix in your case would be to
run as many Tomcat's as you have processors on that particular machine
(assuming you have enough memory)
-Dave
import java.sql.*;
import java.util.*;
public class TestDatePerf
extends Thread
{
int iterations;
Timestamp date = null;
public TestDatePerf(int iterations) {
this.iterations = iterations;
date = new Timestamp(System.currentTimeMillis());
}
public void run() {
for (int i = 0; i iterations; i++) {
date.toString();
}
}
public static void main(String args[]) {
for (int i = 0; i Integer.parseInt(args[0]); i++) {
TestDatePerf tdp = new TestDatePerf(Integer.parseInt(args[1]));
tdp.start();
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
FAQ - committed changes - please update site
I just committed a mass update. But given the way diff works on the rendered HTML files - the email barfed and returned to me. Can someone update the tomcat site? Attached is the summary of the FAQ changes. funkman 2003/07/10 18:57:40 Modified:docs/faq bugs.html classnotfound.html connectors.html database.html index.html memory.html meta.html misc.html performance.html security.html tomcatuser.html unix.html version.html windows.html docs/faq/printer bugs.html connectors.html database.html index.html memory.html meta.html misc.html performance.html security.html tomcatuser.html unix.html version.html xdocs-faq bugs.xml connectors.xml database.xml index.xml memory.xml meta.xml misc.xml performance.xml project.xml security.xml tomcatuser.xml unix.xml version.xml Removed: docs/faq howto.html links.html docs/faq/printer howto.html links.html xdocs-faq howto.xml links.xml Log: - Lots of spelling fixes - Delete howto and link to wiki - Delete resources / other links and linked to wiki - connectors.xml - At boot, is order of start up (Apache vs Tomcat) important? - memory.xml - Why do I get OutOfMemoryError errors? - How much memory is tomcat/webapp/??? using? - misc.xml - Why do I get java.lang.IllegalStateException? - question to answer link fixes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/puretls PureTLSSocketFactory.java
billbarker2003/07/10 21:09:43
Modified:util/java/org/apache/tomcat/util/net/puretls
PureTLSSocketFactory.java
Log:
Adding support for specifying CipherSuites to PureTLS.
Thanks to Jan for doing the hard part ;-).
Revision ChangesPath
1.4 +62 -3
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/puretls/PureTLSSocketFactory.java
Index: PureTLSSocketFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/puretls/PureTLSSocketFactory.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- PureTLSSocketFactory.java 16 Jun 2003 02:45:56 - 1.3
+++ PureTLSSocketFactory.java 11 Jul 2003 04:09:43 - 1.4
@@ -61,6 +61,7 @@
import java.io.*;
import java.net.*;
+import java.util.*;
import COM.claymoresystems.ptls.*;
import COM.claymoresystems.cert.*;
@@ -173,14 +174,72 @@
SSLPolicyInt policy=new SSLPolicyInt();
policy.requireClientAuth(clientAuth);
- policy.handshakeOnConnect(false);
- policy.waitOnClose(false);
- tmpContext.setPolicy(policy);
+policy.handshakeOnConnect(false);
+policy.waitOnClose(false);
+short [] enabledCiphers = getEnabledCiphers(policy.getCipherSuites());
+if( enabledCiphers != null ) {
+policy.setCipherSuites(enabledCiphers);
+}
+tmpContext.setPolicy(policy);
context=tmpContext;
} catch (Exception e){
logger.info(Error initializing SocketFactory,e);
throw new IOException(e.getMessage());
}
+}
+
+/*
+ * Determines the SSL cipher suites to be enabled.
+ *
+ * @return Array of SSL cipher suites to be enabled, or null if the
+ * cipherSuites property was not specified (meaning that all supported
+ * cipher suites are to be enabled)
+ */
+private short [] getEnabledCiphers(short [] supportedCiphers) {
+
+short [] enabledCiphers = null;
+
+String attrValue = (String)attributes.get(ciphers);
+if (attrValue != null) {
+Vector vec = null;
+int fromIndex = 0;
+int index = attrValue.indexOf(',', fromIndex);
+while (index != -1) {
+String cipher = attrValue.substring(fromIndex, index).trim();
+int cipherValue = SSLPolicyInt.getCipherSuiteNumber(cipher);
+/*
+ * Check to see if the requested cipher is among the supported
+ * ciphers, i.e., may be enabled
+ */
+if( cipherValue = 0) {
+for (int i=0; supportedCiphers != null
+ isupportedCiphers.length; i++) {
+
+if (cipherValue == supportedCiphers[i]) {
+if (vec == null) {
+vec = new Vector();
+}
+vec.addElement(new Integer(cipherValue));
+break;
+}
+}
+}
+fromIndex = index+1;
+index = attrValue.indexOf(',', fromIndex);
+}
+
+if (vec != null) {
+int nCipher = vec.size();
+enabledCiphers = new short[nCipher];
+for(int i=0; i nCipher; i++) {
+Integer value = (Integer)vec.elementAt(i);
+enabledCiphers[i] = value.shortValue();
+}
+}
+}
+
+return enabledCiphers;
+
}
public Socket acceptSocket(ServerSocket socket)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21472] - JDBCRealm: Auth ok but Not Authorized
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=21472. 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=21472 JDBCRealm: Auth ok but Not Authorized [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-07-11 04:36 --- From what you have posted, you have the user_name and role_name columns swapped. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21456] - logs/context lost when restarting Context
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=21456. 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=21456 logs/context lost when restarting Context [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement --- Additional Comments From [EMAIL PROTECTED] 2003-07-11 04:47 --- I agree that the admin webapp should check for changes in the apps- context.xml file. However most of the functionality you want is available from the (new) 'reload' option. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
question on dynamically loaded realms
Sorry if this question should not posted on this list. This is just a question about the design of TC on how to handle different realms. I'm looking at the way realms are handled in TC. I'd like to know why realms have to be registered (for lack of better word) with MBeanFactory, and have to be manually created in there? By looking at the way this is done it can be easily factored out into deployment descriptor files. That way, customized realms (which are still derived from RealmBase as they are right now) can be added much more easily. Is there any plan for this? Developer comments please? rgds csp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RFC] Handling the '*' URL
This is really a Request-For-Comments, I'm not proposing anything. I'm looking into resolving Bug #21454. At the moment, requests for e.g: OPTIONS * HTTP/1.1 TRACE * HTTP/1.1 get properly handled by TC 5 (thanks to Keith's patch), buy passing them to DefaultServlet. However, the '*' URL is really a HTTP Protocol URL, so it seems to me that it really should be handled by the Connector instead of the Servlet. On the other hand, we have access to the rich Servlet-API implementations (Ok, so I don't in 3.3-land, but I can fake it ;-). So my problem is that I can't see the correct route to go here. Opinions? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
