RE: [VOTE] New Committer: Bip Thelin
+1 - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Kief Morris [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 22, 2001 11:22 AM To: [EMAIL PROTECTED] Subject: [VOTE] New Committer: Bip Thelin I would like to propose Bip Thelin as a new committer. He has made a number of contributions of patches over the past several months, including SSI and JDBCRealm, and most recently, is doing solid work on session persistence. Kief
RE: [PATCH] mod_jk timestamp and process id logging
Timestamp is already present in CVS. Did others modules add the pid ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Pogo Com [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 22, 2001 7:10 PM To: [EMAIL PROTECTED] Subject: [PATCH] mod_jk timestamp and process id logging 2) I suggest adding a timestamp to mod_jk-logging in jk_util.c. Logging without a timestamp is not very useful. (change 1 line, add 2 lines) Yes, this is a must-have... the other thing that is really useful is the Apache child process id. That way if one process gets stuck, you can get the id from the Apache mod_status, and grep the mod_jk.log for that pid to see where it is. Attached is another version of the patch that adds both, relative to 3.3-m2. This was the only way that I could figure out that Tomcat didn't have enough threads in its thread pool for my Apache config! Bill __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: [VOTE] New Committer: Bip Thelin
+1 Mel --- Remy Maucherat [EMAIL PROTECTED] wrote: - Original Message - From: Kief Morris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, April 22, 2001 2:22 AM Subject: [VOTE] New Committer: Bip Thelin I would like to propose Bip Thelin as a new committer. He has made a number of contributions of patches over the past several months, including SSI and JDBCRealm, and most recently, is doing solid work on session persistence. +1. Remy __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
RE: [3.3] Release request
As a RPM packager I'd like ALSO having .tar.gz archive URL access like : http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.3-m2/src/jakarta- tomcat-version-src.tar.gz It's the case for 3.2.x but not each time in 4.0/3.3. It allow RPM/DEBIAN? packagers all the version archives under the same sub-dirs (ie /usr/src/redhat/SOURCES. Having the untarred datas under jakarta-tomcat-version-src (Jon), but I'll be for using jakarta-tomcat-version (ant, oro, regexp, Apache HTTPD server, ) Minor request: When you guys make releases of 3.3, could you please tar them up so that the untared directory name is jakarta-tomcat-3.3-VERSION instead of just plain old tomcat? :-) For example, if the .tar.gz is called: jakarta-tomcat-3.3-m2.tar.gz the directory that would end up creating should be called jakarta-tomcat-3.3-m2, not tomcat. Thanks! -jon
RE: Patch suggestions mod_jk/ajp13
Hi Rainer, Thanks for the patches : I participated in the mod_jk fdatasync discussion on Friday. I have 4 more mod_jk/ajp13 patches on my personal wishlist. Since nobody object, I removed the fdatasync from log :) The first three (these are mod_jk patches) apply to 3.2.2 as well as to 3.3-milestone2. The fourth (which is the tomcat ajp13 patch) is already fixed in 3.3, but not in 3.2.2. Could you use next time, diff -Nru, since it's much more easy to see the differences... I describe the four and add some diff-output for 3.2.2-beta2. I'm not an experienced Java/C-developper, so do not blindly use the code, although all patches are very small. 1) In jk_ajp12_worker.c the HTTP return reason phrase (the text that belongs to the numeric status, like OK for 200) is not handled correct. If the phrase consists of more than one token, like Not Found, only the first token is read from tomcat and returned to the client. (change two lines, add 5 lines) Seems good to me 2) I suggest adding a timestamp to mod_jk-logging in jk_util.c. Logging without a timestamp is not very useful. (change 1 line, add 2 lines) Allready present in tomcat 3.3 CVS 3) I think in jk_uri_worker_map.c is a little bug. For me it loggs (very rarely) NULL parameters and looking at the code I can see, that the two places are exactly those, where the code does not return before the log statement, even if it succesfully completes the call. All other places where NULL parameters could be logged first try to do something successful, if yes return, if no do logging. So I think one gets the logging although it should not have happened. (delete 4 lines, change 3 lines, add 1 line) Never saw these NULL that but I cleanup a little jk_uri_worker_map 4) In Ajp13ConnectorResponse.java the http reason phrase is missing in the returned status line. The change that has been done to tomcat 3.3 milestone 2, and maybe could be added to 3.2.2 also. (change 1 line) Maybe some of these could go into 3.2.2 or 3.3? 3.2.x tree is closed and only bug fixes will be included. All majors updates to mod_jk must be in 3.3 tree !!!
RE: Access log files in the style of Apache
+1 for 3.3. Since it's not a bug fixes, we may never see that in 3.2.2 or 3.2.3... - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] Sent: Monday, April 23, 2001 12:44 PM To: '[EMAIL PROTECTED]' Subject: RE: Access log files in the style of Apache Hola a Todos, Costin, Jochen: +1 for 3.3, +1 for checking the code in for 3.2 ( but not enable it be default ) - it can't hurt in any way code stability. ( but it's Marc's call ) +1 to add it to 3.3 release +1 and to provide it disabled for upcoming 3.2.3, if MArc agrees.. Saludos , Ignacio J. Ortega
Project NoN Functional (TOMCAT 4.x)
Respected Sir We the Group of S/w People are into development of Pure IntranetJava solutions for Different WEB Containers / RDBMS on Different Platform factors.Untill Version of TOMCAT 3.2 ,Our project Bundle worked with out any problems. On release of 4.x Ourgroup tends to move into latest version (fromTOMCAT 3.2 to 4.X ),foundsever problems with installation of our bundled S/w package. Also TOMCAT 4.x refuses to serve the Client with non of the pages except for the LOG on SCREEN. Our S/w bundel is arranged under TOMCAT 3.x as in fasion given below. webapps I I_ eHRIS I I_ _ jsp ( all JSP files) (creates implecit sessions) I I_ _ images (allImages) I I_ _ CSS (all CSS files ) I I_ _ WEB -INF I I_ _ LIB ( ALL 3rd party JDBC TYPE IV DRIVERS) I I_ _ _CLASSES I I_ _ SYNTAXPROJ I I_ _ SYNCONN (classes which performs JDBC connetions ,thread pools, ect) I I_ _ SYBUSOBJ ( classes for creation of Busobjs) I I_ _ SYDATABASE I I_ _ SYNQUERY ( class files for Query) I I_ _ SYNUPINST( class files for Update / Insert) The Main features of our S/w Bundle are. Our Intranet S/w makes use of Implecit sessions created inside the JSP Pages to TRACK and Forward relevent Info in and out of Application. We also have an JDBC ENGINE which does all the connection/Tx/RX 0f Data between the JSP to JAVA CLASS files and RDBMS ones. working platform = windows NT / LINUX working RDBMS = MSACCESS / MYSQL / ORACLE / MSSQL HELP requested in areas. ??? 1) I have also Attached a copy of Error sayingVector Object used to create sessions not avaliable " Please have a look and reply on 2) Also with existing bundle on TOMCAT 3.x Could any of u people explain to me in simple steps to Configure with APACHE (anexample would give correct pichure ) 3) Creation os SSI for the existing bundle os S/w (both TOMCAT / APACHE configuration ) email[EMAIL PROTECTED] [EMAIL PROTECTED], [EMAIL PROTECTED] So in this situation Please Adviseus how to port our S/w Bundel to new TOMCAT 4.x with out major changes applicable into our bundle. Thanx in advance N.S.Karthik Title: Tomcat Exception Report A Servlet Exception Has Occurred org.apache.jasper.JasperException: Unable to compile class for JSPD:\java\jakarta-tomcat-4.0-b3\bin\..\work\localhost\eHRIS\jsp\jsp\CompleteValidation1_jsp.java:109: Class org.apache.jsp.Vector not found. Vector val = sc.setVector(usn); ^ 1 error at org.apache.jasper.compiler.Compiler.compile(Compiler.java:277) at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:501) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary(JspServlet.java:175) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:187) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:357) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:431) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:191) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:255) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:225) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:469) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:446) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:162) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.valves.RequestDumperValve.invoke(RequestDumperValve.java:219) at
Re: Project NoN Functional (TOMCAT 4.x)
On Mon, 23 Apr 2001, Karthik wrote: Respected Sir We the Group of S/w People are into development of Pure Intranet Java solutions for Different WEB Containers / RDBMS on Different Platform factors. Untill Version of TOMCAT 3.2 ,Our project Bundle worked with out any problems. On release of 4.x Our group tends to move into latest version (from TOMCAT 3.2 to 4.X ),found sever problems with installation of our bundled S/w package. Also TOMCAT 4.x refuses to serve the Client with non of the pages except for the LOG on SCREEN. First, this is a user problem and should be reported on the TOMCAT-USER list. The TOMCAT-DEV list is for discussions of the development of Tomcat. Second, the problem you are having is that you are trying to use a Vector without including the following at the top of your page: %@ page import=java.util.Vector % The reason this works under Tomcat 3.2 is that Tomcat 3.2 violates the JSP specification and creates implicit imports for a number of packages (including java.util.*). Tomcat 4.0 follows the spec, and only imports the following: java.lang.* javax.servlet.* javax.servlet.jsp.* javax.servlet.http.* For more information, see the JSP Specification, Section 2.7.1.1 (p. 45), available at: http://java.sun.com/products/jsp/download.html Craig McClanahan
RE: Bugs 500
On Mon, 23 Apr 2001, Steve Downey wrote: 360 and 412 look like they might cause me some headaches. Are you -1 on fixing them, or -0? That is, should I bother or not? I'm +1 on fixing them - the list reflects what I think whould have high priority ( i.e. things fixed in 3.2 but not 3.3, spec issues, stability, etc). Sorry for not explaining the list - I'm trying to extract the bugs that I believe are the most important for 3.3. We can't fix absolutely all the bugs, but we must be comfortable with the later bugs and avoid surprises. Larry - it would be nice to check in a release notes file with a list of the bugs that we think will remain open ( and maybe workarounds if possible ). Costin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 22, 2001 2:25 PM To: [EMAIL PROTECTED] Subject: Bugs 500 Hi, I finished reviewing bugs marked as LATER with ID500. There are 5 bugs that we should fix for 3.3: 345 - Date header 348 - Security roles 375 - // security checking - revert to paranoid path checks 454 - mod_jk spawning (hunged ) apache processes when tomcat is down ( maybe later - tomcat should be running or be restart ) 486 - rusian in jsp @include There are 8 jasper bugs I think we should leave open, I wouldn't change jasper before refactoring: 75 - translation time attrs 105 - custom tag attrs 143 - tag handlers 360 - jsp:include expressions 366 - doAfterBody if no body 376 - Jsp error messages in some cases ( no setter ) 387 - special tokens in tag name ( extend to jsp files ) 412 - JSPC and \ paths ( it may be easy to fix ) 4 bugs are fixed in 3.3, we should close them: 149 - log, fixed 295 - config generation, fixed 296 - can't happen, fixed 485 - cookies, fixed Also, 4 bugs I don't think we'll cover in 3.3: 166 - spaces on nt ( has workarounds ) 962 - redirect sys out, err; config in server.xml, rotate ( RFE ) 471 - mod_jk and spaces in dir name on windows ( has workarounds ) 112 - BAT script on windows - bin/ as default Costin This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: Bugs 500
Larry - it would be nice to check in a release notes file with a list of the bugs that we think will remain open ( and maybe workarounds if possible ). Sorry I have been mostly offline for several weeks. I'll try to get back online this week. I'll review the current state of bugs for Tomcat 3.3 and check in a release notes file. Larry
RE: [PATCH] mod_jk timestamp and process id logging
Regarding logging the Apache child process id in mod_jk.log: Timestamp is already present in CVS. Did others modules add the pid ? I am not sure, but the process id makes debugging a problem with an individual Apache child much simpler, because it directs you to the events of interest. Without the process id, you have to use timestamps, which are significantly less accurate. Bill __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
RE: Access log files in the style of Apache
I'm just getting ready to call a vote for the final release of Tomcat 3.2.2. I'm not comfortable adding anything like this so late in the release cycle. Once 3.2.2 is out then development will be opened up for potential 3.2.3 stuff and this might reasonably be add then. It isn't an architectural feature change so I wouldn't have any problems with it going into 3.2.x, just not right now. -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, April 23, 2001 6:41 AM To: [EMAIL PROTECTED] Subject: RE: Access log files in the style of Apache +1 for 3.3. Since it's not a bug fixes, we may never see that in 3.2.2 or 3.2.3... - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] Sent: Monday, April 23, 2001 12:44 PM To: '[EMAIL PROTECTED]' Subject: RE: Access log files in the style of Apache Hola a Todos, Costin, Jochen: +1 for 3.3, +1 for checking the code in for 3.2 ( but not enable it be default ) - it can't hurt in any way code stability. ( but it's Marc's call ) +1 to add it to 3.3 release +1 and to provide it disabled for upcoming 3.2.3, if MArc agrees.. Saludos , Ignacio J. Ortega
cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime BodyContentImpl.java
marcsaeg01/04/23 12:00:26
Modified:src/share/org/apache/jasper/runtime Tag: tomcat_32
BodyContentImpl.java
Log:
Fixing buffer size calculation. The last commit attempted to improve
performace by doubling the buffer size when reallocating. Unfortunately
I messed up applying the patch and got the bufferSize variable out of
sync with the actual size of the buffer.
PR: 1271
Revision ChangesPath
No revision
No revision
1.6.6.4 +4 -3
jakarta-tomcat/src/share/org/apache/jasper/runtime/BodyContentImpl.java
Index: BodyContentImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/BodyContentImpl.java,v
retrieving revision 1.6.6.3
retrieving revision 1.6.6.4
diff -u -r1.6.6.3 -r1.6.6.4
--- BodyContentImpl.java 2001/03/09 23:31:54 1.6.6.3
+++ BodyContentImpl.java 2001/04/23 19:00:20 1.6.6.4
@@ -111,9 +111,10 @@
//XXX Should it be multiple of DEFAULT_BUFFER_SIZE??
- if (len = Constants.DEFAULT_BUFFER_SIZE) {
- tmp = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
- bufferSize = bufferSize * 2;
+int newBufferSize = bufferSize * 2;
+if (len = newBufferSize) {
+ bufferSize = newBufferSize;
+ tmp = new char [bufferSize];
} else {
tmp = new char [bufferSize + len];
bufferSize += len;
Logger.java -- TC 3.2.1/3.2.2b3
I noticed when looking through my log files that the default timestamp format for logging is based on a 12-hour clock, as opposed to a 24-hour clock. I would meekly suggest changing this by changing Line 416 of Logger.java in TC 3.2.1/3.2.2b3 from: protected String timestampFormat = "-MM-dd hh:mm:ss"; to: protected String timestampFormat = "-MM-dd HH:mm:ss"; I know it's configurable in the server.xml file, but I thought it would be nice to change the default. The other option would be to add the AM/PM designator to the current format: protected String timestampFormat = "-MM-dd hh:mm:ss a"; Thanks, --jeff
RE: [PATCH] mod_jk timestamp and process id logging
Let me clarify. Did other apache modules add the pid() in their logs ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, April 23, 2001 12:34 PM To: [EMAIL PROTECTED] Subject: RE: [PATCH] mod_jk timestamp and process id logging Timestamp is already present in CVS. Did others modules add the pid ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Pogo Com [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 22, 2001 7:10 PM To: [EMAIL PROTECTED] Subject: [PATCH] mod_jk timestamp and process id logging 2) I suggest adding a timestamp to mod_jk-logging in jk_util.c. Logging without a timestamp is not very useful. (change 1 line, add 2 lines) Yes, this is a must-have... the other thing that is really useful is the Apache child process id. That way if one process gets stuck, you can get the id from the Apache mod_status, and grep the mod_jk.log for that pid to see where it is. Attached is another version of the patch that adds both, relative to 3.3-m2. This was the only way that I could figure out that Tomcat didn't have enough threads in its thread pool for my Apache config! Bill __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
RE: Store Proposal
What about having the session store stuff used also in Tomcat 3.2 / 3.3 . It seems to be a fine candidate to jakarta-commons ... - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Bip Thelin [mailto:[EMAIL PROTECTED]] Sent: Friday, April 20, 2001 9:02 PM To: [EMAIL PROTECTED] Subject: Store Proposal We've had some issues with the background threads, expiration and stuff so I migrated some of the common stuff into a StoreBase and had JDBCStore and FileStore extend it and have the opportunity to implement it's own processexpires and some other methods. The code is attatched. I've also implemented an extended table for JDBCStore, there still remains some work on using the extended fields when checking expiration and loading I'll have that done soon. This is what a table for JDBCStore now should look like: TABLE [tomcat$sessions] ( [id] [varchar] (100) NOT NULL , [data] [varbinary] (1000) NULL , [valid] [char] (1) NOT NULL , [maxinactive] [int] NOT NULL , [lastaccess] [numeric](18, 0) NULL ) Here's how you can configure the table and column names: !--Store className=org.apache.catalina.session.JDBCStore driverName=SQLDriver connectionURL=jdbc:protocol://server?user=;password= sessionTable=tomcat$sessions sessionIdCol=id sessionDataCol=data sessionValidCol=valid sessionMaxInactiveCol=maxinactive sessionLastAccessedCol=lastaccess debug=99/-- ..bip
RE: Store Proposal
On Mon, 23 Apr 2001, GOMEZ Henri wrote: What about having the session store stuff used also in Tomcat 3.2 / 3.3 . 3.2 is in maintenance mode, and should stay that way. It doesn't need persistent sessions at all. 3.3 wants to maintain JDK 1.1 compatibility -- at least that's the last I heard; maybe attitudes are changing. 4.0 is not constrained by this, because the servlet 2.3 spec mandates a Java2 minimum platform. I don't see any reason to restrict development on the 4.0 track (for session stores or anything else) for backwards compatibility. Besides, I can *guarantee* you that Costin won't like several aspects of the org.apache.catalina.Store interface, because it has dependencies on the other Catalina internal interfaces :-). It seems to be a fine candidate to jakarta-commons ... Feel free to propose something. You're going to have a very hard time, though, overcoming the fundamentally different architectural world views on which the 3.3 and 4.0 designs are based. I'm not planning to invest any of my own time in worrying about 3.x compatibility. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 Craig
RE: Store Proposal
On Mon, 23 Apr 2001, Craig R. McClanahan wrote: 3.3 wants to maintain JDK 1.1 compatibility -- at least that's the last I heard; maybe attitudes are changing. My attitude is changing indeed - I would like to propose J2ME compatibility for tomcat 3.3 :-) ( the only problem is one class that is required by servlet API but not present in J2ME - i.e. Principal, everything else is easy - at least with the foundation profile ) That doesn't mean 3.3 _modules_ are restricted in any way to JDK1.1. Tomcat has already at least 2 modules that are JDK1.2 compatible. The restriction ( the way I understand it at least ) is that tomcat4 should provide a (basic) servlet container that will work on JDK1.1, and that means the 5-6 classes in tomcat.core, plus 10 utils need to remain compatible with JDK1.1. It also means that new functionality ( like a session store or a new connector ) need to be added in new modules ( but there are many other reasons for that - stability of the code, etc). 4.0 is not constrained by this, because the servlet 2.3 spec mandates a Java2 minimum platform. I don't see any reason to restrict development on the 4.0 track (for session stores or anything else) for backwards compatibility. Well, I would say tomcat 3 is not constrained to much by this either. The constraint in 3.3 is that we want to keep the code stable and release it, and all that it means is that new functionality should be developed as separate modules with minimal changes in the main tree. I have few modules in work ( at prototype stage ), jasper will probably be a big one, I hope mod_jk+webapp will be another one. Besides, I can *guarantee* you that Costin won't like several aspects of the org.apache.catalina.Store interface, because it has dependencies on the other Catalina internal interfaces :-). You know me very well :-) Yes, I think the session manager should be a separate module, with minimal dependencies on other components. I also think that mod_jk should be a separate module, that will work with any container that provides an adapter ( and not only 3.3 or 4.0 btw ). ( and this has nothing to do with 3.3/4.0 architecure - but with beeing able to manage the complexity ). You're going to have a very hard time, though, overcoming the fundamentally different architectural world views on which the 3.3 and 4.0 designs are based. As long as the session manager is not very dependent on the internal architecture - it should be fine, and work not only in 3.3 or 4.0. There are many good ways to process a request - and the session manager ( or jasper, or the connector ) shouldn't care about that. Costin
RE: Store Proposal
Typos... That doesn't mean 3.3 _modules_ are restricted in any way to JDK1.1. Tomcat has already at least 2 modules that are JDK1.2 compatible. Are using JDK1.2 specific features. The restriction ( the way I understand it at least ) is that tomcat4 should provide a (basic) servlet container that will work on JDK1.1, and tomcat3.3 :-) Costin
Re: Solaris Sparc Performance Problem
Anne Dirkse wrote: Douglas -- I am experiencing the exact same set of problems, except that I'm just beginning to experience them, so I haven't done any real testing to get to the specifics of what is going on and the exact performance difference that I am experiencing between Solaris and Linux, however, there is a noticable slowness even with a single connected client. My setup is: * Solaris 8 * All machines also on same 100MB Ethernet * Standalone Tomcat * Using our company's Sparc boxes (500Mhz Sparc) -- only have tried these * No performance difference amongst browsers (IE5, Netscape 4.7) * Tried JDK 1.2.2 and 1.3, no difference * Patched Solaris as recommended for Java setup, no difference By any chance, have you tried hitting the system from another Solaris box? There is a TCP/IP stack mis-match problem (due to Win32 having a less sophisticated implementation) that can cause an idle of up to 0.5 seconds. From http://www.sun.com/sun-on-net/performance/tcp.slowstart.html: Only configurations with clients that use a simplistic delayed ACK implementation, e.g. Windows/NT, will exhibit the idle time problem when talking to a Solaris server. They recommend doing the following as root to patch this for Win32 clients: # ndd -set /dev/tcp tcp_slow_start_initial 2 Give this a shot and let us know if it clears up your problem. --kd
ServerSocket not being closed properly.
At 7:06 PM -0500 04/23/2001, Marc Saegesser wrote:
I was just about to call the vote for the final release of Tomcat 3.2.2
...
While you're at it, could you ensure that tomcat closes its server
socket instead of relying on the system to do it when the VM exits?
This is a long-standing problem that interferes with running tomcat
inside IBM's VisualAge, or (equivalently) building java GUIs for
starting and stopping the server.
Here's what I've been using in a GUI for starting and stopping tomcat.
private void doStart(String[] args)
{
org.apache.tomcat.startup.Tomcat.main(args);
}
private void doStop()
{
String[] stopArgs = new String[] { -stop };
org.apache.tomcat.startup.Tomcat.main(stopArgs);
}
The buttons work the first time they're used. The start buttons fails
the second times (either by the same GUI or by any other means during
the same VisualAge session) because the server socket is still being
held open by the lack of an explicit close. The only way I've found
to clear the problem is to exit VisualAge altogether; a SLOOO
process.
I've seen the same problem in my own applications. The fix was to be
SURE that the ServerSocket is closed EXPLICITLY rather than leaving
it to the operating system to do when the process exits.
This session console log may help locate the problem.
2001-04-24 08:51:00 - ContextManager: Adding context Ctx( /examples )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /admin )
2001-04-24 08:51:01 - Ctx( /svlt ): Set debug to 9
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /svlt )
Starting tomcat. Check logs/tomcat.log for error messages
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /test )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /digiprop )
2001-04-24 08:51:02 - Ctx( /svlt ): XmlReader - init /svlt /digiprop
2001-04-24 08:51:02 - Ctx( /svlt ): Reading /digiprop/WEB-INF/web.xml
2001-04-24 08:51:02 - Ctx( /svlt ): Loading -2147483646 jsp
2001-04-24 08:51:02 - Ctx( /svlt ): Loading 1 flush
2001-04-24 08:51:03 - Ctx( /svlt ): Loading 1 page
2001-04-24 08:51:03 - Ctx( /svlt ): Loading 1 login
FATAL:java.net.SocketException: Address already in use
java.net.SocketException: Address already in use
java.lang.Throwable(java.lang.String)
java.lang.Exception(java.lang.String)
java.io.IOException(java.lang.String)
java.net.SocketException(java.lang.String)
void java.net.PlainSocketImpl.socketBind(java.net.InetAddress, int)
void java.net.PlainSocketImpl.bind(java.net.InetAddress, int)
java.net.ServerSocket(int, int, java.net.InetAddress)
java.net.ServerSocket(int, int)
java.net.ServerSocket
org.apache.tomcat.net.DefaultServerSocketFactory.createSocket(int,
int)
void org.apache.tomcat.service.PoolTcpEndpoint.startEndpoint()
void org.apache.tomcat.service.PoolTcpConnector.start()
void org.apache.tomcat.core.ContextManager.start()
void org.apache.tomcat.startup.Tomcat.execute(java.lang.String [])
void org.apache.tomcat.startup.Tomcat.main(java.lang.String [])
void digiprop.site.TomcatView.doStart()
void digiprop.site.TomcatView.connEtoC2(java.awt.event.ActionEvent)
void
digiprop.site.TomcatView$IvjEventHandler.actionPerformed(java.awt.event.ActionEvent)
void java.awt.Button.processActionEvent(java.awt.event.ActionEvent)
void java.awt.Button.processEvent(java.awt.AWTEvent)
void java.awt.Component.dispatchEventImpl(java.awt.AWTEvent)
void java.awt.Component.dispatchEvent(java.awt.AWTEvent)
void java.awt.EventDispatchThread.run()
--
---
Brad Cox, Ph.D.; [EMAIL PROTECTED]
Phone: 703 361 4751 Cell: 703 919-9623
http://virtualschool.edu
RE: ServerSocket not being closed properly.
In my experience (having started/stopped Tomcat engine programatically via
ContextManager API in a loop 100s of times), server socket is always closed
correctly. And looking at 3.2.2 beta 3 source code, both PoolTcpEndpoint and
SimpleTcpEndpoint close the server socket during shutdownEndpoint().
BTW, doesn't your doStop() below kill the VM because there is a
System.exit() in Ajp12ConnectionHandler shutdown?
-arun
ps: Each invocation leaves some threads running, which is bug 1418
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1418), resolved for 3.3
(not 3.2.2). There is also some memory leak which I haven't had a chance to
track down, yet.
-Original Message-
From: Brad Cox PhD [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 23, 2001 6:04 PM
To: [EMAIL PROTECTED]
Subject: ServerSocket not being closed properly.
At 7:06 PM -0500 04/23/2001, Marc Saegesser wrote:
I was just about to call the vote for the final release of
Tomcat 3.2.2
...
While you're at it, could you ensure that tomcat closes its server
socket instead of relying on the system to do it when the VM exits?
This is a long-standing problem that interferes with running tomcat
inside IBM's VisualAge, or (equivalently) building java GUIs for
starting and stopping the server.
Here's what I've been using in a GUI for starting and stopping tomcat.
private void doStart(String[] args)
{
org.apache.tomcat.startup.Tomcat.main(args);
}
private void doStop()
{
String[] stopArgs = new String[] { -stop };
org.apache.tomcat.startup.Tomcat.main(stopArgs);
}
The buttons work the first time they're used. The start buttons fails
the second times (either by the same GUI or by any other means during
the same VisualAge session) because the server socket is still being
held open by the lack of an explicit close. The only way I've found
to clear the problem is to exit VisualAge altogether; a SLOOO
process.
I've seen the same problem in my own applications. The fix was to be
SURE that the ServerSocket is closed EXPLICITLY rather than leaving
it to the operating system to do when the process exits.
This session console log may help locate the problem.
2001-04-24 08:51:00 - ContextManager: Adding context Ctx( /examples )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /admin )
2001-04-24 08:51:01 - Ctx( /svlt ): Set debug to 9
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /svlt )
Starting tomcat. Check logs/tomcat.log for error messages
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /test )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /digiprop )
2001-04-24 08:51:02 - Ctx( /svlt ): XmlReader - init /svlt /digiprop
2001-04-24 08:51:02 - Ctx( /svlt ): Reading /digiprop/WEB-INF/web.xml
2001-04-24 08:51:02 - Ctx( /svlt ): Loading -2147483646 jsp
2001-04-24 08:51:02 - Ctx( /svlt ): Loading 1 flush
2001-04-24 08:51:03 - Ctx( /svlt ): Loading 1 page
2001-04-24 08:51:03 - Ctx( /svlt ): Loading 1 login
FATAL:java.net.SocketException: Address already in use
java.net.SocketException: Address already in use
java.lang.Throwable(java.lang.String)
java.lang.Exception(java.lang.String)
java.io.IOException(java.lang.String)
java.net.SocketException(java.lang.String)
void
java.net.PlainSocketImpl.socketBind(java.net.InetAddress, int)
void java.net.PlainSocketImpl.bind(java.net.InetAddress, int)
java.net.ServerSocket(int, int, java.net.InetAddress)
java.net.ServerSocket(int, int)
java.net.ServerSocket
org.apache.tomcat.net.DefaultServerSocketFactory.createSocket(int,
int)
void org.apache.tomcat.service.PoolTcpEndpoint.startEndpoint()
void org.apache.tomcat.service.PoolTcpConnector.start()
void org.apache.tomcat.core.ContextManager.start()
void
org.apache.tomcat.startup.Tomcat.execute(java.lang.String [])
void org.apache.tomcat.startup.Tomcat.main(java.lang.String [])
void digiprop.site.TomcatView.doStart()
void
digiprop.site.TomcatView.connEtoC2(java.awt.event.ActionEvent)
void
digiprop.site.TomcatView$IvjEventHandler.actionPerformed(java.
awt.event.ActionEvent)
void
java.awt.Button.processActionEvent(java.awt.event.ActionEvent)
void java.awt.Button.processEvent(java.awt.AWTEvent)
void java.awt.Component.dispatchEventImpl(java.awt.AWTEvent)
void java.awt.Component.dispatchEvent(java.awt.AWTEvent)
void java.awt.EventDispatchThread.run()
--
---
Brad Cox, Ph.D.; [EMAIL PROTECTED]
Phone: 703 361 4751 Cell: 703 919-9623
http://virtualschool.edu
Re: ServerSocket not being closed properly.
Fixed for 3.3, I'm not sure it's very easy for 3.2.2.
The threads are waiting in accept, so one solution is to set stopped and
make a dummy connection. The problem is that there are few places that
need to be fixed to support stop/start ( another bug was that logger and
session expirer threads don't stop ). It may be a bit too much for 3.2.2,
but probably can be done for an eventual 3.2.3 if it's important.
Costin
On Mon, 23 Apr 2001, Brad Cox PhD wrote:
At 7:06 PM -0500 04/23/2001, Marc Saegesser wrote:
I was just about to call the vote for the final release of Tomcat 3.2.2
...
While you're at it, could you ensure that tomcat closes its server
socket instead of relying on the system to do it when the VM exits?
This is a long-standing problem that interferes with running tomcat
inside IBM's VisualAge, or (equivalently) building java GUIs for
starting and stopping the server.
Here's what I've been using in a GUI for starting and stopping tomcat.
private void doStart(String[] args)
{
org.apache.tomcat.startup.Tomcat.main(args);
}
private void doStop()
{
String[] stopArgs = new String[] { -stop };
org.apache.tomcat.startup.Tomcat.main(stopArgs);
}
The buttons work the first time they're used. The start buttons fails
the second times (either by the same GUI or by any other means during
the same VisualAge session) because the server socket is still being
held open by the lack of an explicit close. The only way I've found
to clear the problem is to exit VisualAge altogether; a SLOOO
process.
I've seen the same problem in my own applications. The fix was to be
SURE that the ServerSocket is closed EXPLICITLY rather than leaving
it to the operating system to do when the process exits.
This session console log may help locate the problem.
2001-04-24 08:51:00 - ContextManager: Adding context Ctx( /examples )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /admin )
2001-04-24 08:51:01 - Ctx( /svlt ): Set debug to 9
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /svlt )
Starting tomcat. Check logs/tomcat.log for error messages
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /test )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /digiprop )
2001-04-24 08:51:02 - Ctx( /svlt ): XmlReader - init /svlt /digiprop
2001-04-24 08:51:02 - Ctx( /svlt ): Reading /digiprop/WEB-INF/web.xml
2001-04-24 08:51:02 - Ctx( /svlt ): Loading -2147483646 jsp
2001-04-24 08:51:02 - Ctx( /svlt ): Loading 1 flush
2001-04-24 08:51:03 - Ctx( /svlt ): Loading 1 page
2001-04-24 08:51:03 - Ctx( /svlt ): Loading 1 login
FATAL:java.net.SocketException: Address already in use
java.net.SocketException: Address already in use
java.lang.Throwable(java.lang.String)
java.lang.Exception(java.lang.String)
java.io.IOException(java.lang.String)
java.net.SocketException(java.lang.String)
void java.net.PlainSocketImpl.socketBind(java.net.InetAddress, int)
void java.net.PlainSocketImpl.bind(java.net.InetAddress, int)
java.net.ServerSocket(int, int, java.net.InetAddress)
java.net.ServerSocket(int, int)
java.net.ServerSocket
org.apache.tomcat.net.DefaultServerSocketFactory.createSocket(int,
int)
void org.apache.tomcat.service.PoolTcpEndpoint.startEndpoint()
void org.apache.tomcat.service.PoolTcpConnector.start()
void org.apache.tomcat.core.ContextManager.start()
void org.apache.tomcat.startup.Tomcat.execute(java.lang.String [])
void org.apache.tomcat.startup.Tomcat.main(java.lang.String [])
void digiprop.site.TomcatView.doStart()
void digiprop.site.TomcatView.connEtoC2(java.awt.event.ActionEvent)
void
digiprop.site.TomcatView$IvjEventHandler.actionPerformed(java.awt.event.ActionEvent)
void java.awt.Button.processActionEvent(java.awt.event.ActionEvent)
void java.awt.Button.processEvent(java.awt.AWTEvent)
void java.awt.Component.dispatchEventImpl(java.awt.AWTEvent)
void java.awt.Component.dispatchEvent(java.awt.AWTEvent)
void java.awt.EventDispatchThread.run()
RE: Store Proposal
On Mon, 23 Apr 2001, Craig R. McClanahan wrote: Yes, I think the session manager should be a separate module, with minimal dependencies on other components. Given that the 4.0 architecture exists, works fine, lasts a long time, ... what you'd want, then, is for the existing Catalina architecture to fundamentally change in order to share this component. I don't see any benefit (to Tomcat 4.0) by making that change at this point in time. Well, for tomcat4.0 probably not ( stability is more important than almost anything else ), but 4.0 will no be (probably) the last tomcat. More dependencies on internal details - the harder it is to evolve, harder it is to split the work, or to get more people involved. So I would say maximizing the modularity is good for tomcat, even if not particulary for 4.0. * You're going to have significant functional and lifecycle dependencies even if you don't have direct API dependencies -- modules and adpaters try to hide some of this but it doesn't go away. The goal is not to eliminate API dependencies - but to reduce the coupling between components. A session mananger needs to be integrated with a container - but what it expects and what it provide should be clearly defined. With a good design it may even be possible to make it usable as a user-space program ( or in an arbitrary container ). Given the complexity of a good store I think it would be a good thing. * Making a session store (or a session manager, or a ...) shareable implies that the world wants more than one Tomcat in the long run. If they don't, then why bother? Having an adapter just adds a layer of abstraction, with no benefits (see below re: complexity). In the long run is very likely there will be more than one tomcat - this is an open source project, and revolutions are possible at any time. Even without revolutions, most software tends to evolve - tomcat4.1 or 5.0 might not have the same internal architecture with 4.0. I also think that mod_jk should be a separate module, that will work with any container that provides an adapter ( and not only 3.3 or 4.0 btw ). The C side of the connector could be shared, and perhaps low-level protocols pieces of the Java side. Above that, and the Java side has to make lots of assumptions about the internals of the container you are talking to. Well, let's not argue about this yet - probably very soon we'll have some real code we can discuss, and I think clean separation between container and connector is not that difficult. But, of course, one has to wonder if we really want to carry forward the single component that causes 90% of the user complaints and bug reports, and is difficult for even experienced folks to configure ... That's exactly the reason ! This kind of code takes a lot of time to stabilize and mature - there are so many small things that need to be taken into account. Think about IIS/NES/Apache1.3/Apache2.0/AOLServer, about Windows, Mac, Netware, Unixes, about static vs. dynamic builds, about all the load balancing problems. And then you have the integration - authentication, etc - some people are happy with forwarding all requests and let tomcat authenticate, but some have existing infrastructure and need to tune to their needs. I personally think this kind of things take a lot of time and effort to mature and stabilize - mod_jk is close to 1 year old, and the most used components ( ajp12, apache connector ) are almost there. Probaby it'll be another year before JNI and the ajp14 will get similar amount of testing. ( and this has nothing to do with 3.3/4.0 architecure - but with beeing able to manage the complexity ). If we were writing in C, I'd agree whole-heartedly with your approach. But we're not. Java provides other ways to manage complexity. Well, I'm a bit more pesimistic. I've spent (too much) time with tomcat3.0 and I've worked with Apache's C - I don't think the language can do all the magic ( even if java provides better ways ) Featurism is a hard disease, and java is not imune to that - systems do get more and more complex, and the only cure is good modularity. I'm personally planning to focus on enhancing persistent session support, distributed servers, and so on, for Tomcat 4. Ripping apart something that already works in order to make it meet your definition of shareable doesn't help me accomplish that goal. :-) Well, I'll focus on improving the modularity of 3.3 ( yes, I'm still not happy, I still thing it can be improved - mostly the ProfileLoader module and the config modules), and when the session manager is stable enough I can volunteer to refactor it as a 3.3 module. Costin
RE: ServerSocket not being closed properly.
At 6:37 PM -0700 04/23/2001, Arun Katkere wrote:
In my experience (having started/stopped Tomcat engine programatically via
ContextManager API in a loop 100s of times), server socket is always closed
correctly. And looking at 3.2.2 beta 3 source code, both PoolTcpEndpoint and
SimpleTcpEndpoint close the server socket during shutdownEndpoint().
Could you provide sample code? Better yet, an explanation for the
symptoms I provided? I'm inferring the cause but the symptoms are
100% rock solid.
BTW, doesn't your doStop() below kill the VM because there is a
System.exit() in Ajp12ConnectionHandler shutdown?
It does kill the GUI, but System.exit() doesn't kill VisualAge.
Hadnn't dug into this gui problem because the gui is useless after
doStop anyway.
ps: Each invocation leaves some threads running, which is bug 1418
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1418), resolved for 3.3
(not 3.2.2). There is also some memory leak which I haven't had a chance to
track down, yet.
-Original Message-
From: Brad Cox PhD [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 23, 2001 6:04 PM
To: [EMAIL PROTECTED]
Subject: ServerSocket not being closed properly.
At 7:06 PM -0500 04/23/2001, Marc Saegesser wrote:
I was just about to call the vote for the final release of
Tomcat 3.2.2
...
While you're at it, could you ensure that tomcat closes its server
socket instead of relying on the system to do it when the VM exits?
This is a long-standing problem that interferes with running tomcat
inside IBM's VisualAge, or (equivalently) building java GUIs for
starting and stopping the server.
Here's what I've been using in a GUI for starting and stopping tomcat.
private void doStart(String[] args)
{
org.apache.tomcat.startup.Tomcat.main(args);
}
private void doStop()
{
String[] stopArgs = new String[] { -stop };
org.apache.tomcat.startup.Tomcat.main(stopArgs);
}
The buttons work the first time they're used. The start buttons fails
the second times (either by the same GUI or by any other means during
the same VisualAge session) because the server socket is still being
held open by the lack of an explicit close. The only way I've found
to clear the problem is to exit VisualAge altogether; a SLOOO
process.
I've seen the same problem in my own applications. The fix was to be
SURE that the ServerSocket is closed EXPLICITLY rather than leaving
it to the operating system to do when the process exits.
This session console log may help locate the problem.
2001-04-24 08:51:00 - ContextManager: Adding context Ctx( /examples )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /admin )
2001-04-24 08:51:01 - Ctx( /svlt ): Set debug to 9
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /svlt )
Starting tomcat. Check logs/tomcat.log for error messages
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /test )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /digiprop )
2001-04-24 08:51:02 - Ctx( /svlt ): XmlReader - init /svlt /digiprop
2001-04-24 08:51:02 - Ctx( /svlt ): Reading /digiprop/WEB-INF/web.xml
2001-04-24 08:51:02 - Ctx( /svlt ): Loading -2147483646 jsp
2001-04-24 08:51:02 - Ctx( /svlt ): Loading 1 flush
2001-04-24 08:51:03 - Ctx( /svlt ): Loading 1 page
2001-04-24 08:51:03 - Ctx( /svlt ): Loading 1 login
FATAL:java.net.SocketException: Address already in use
java.net.SocketException: Address already in use
java.lang.Throwable(java.lang.String)
java.lang.Exception(java.lang.String)
java.io.IOException(java.lang.String)
java.net.SocketException(java.lang.String)
void
java.net.PlainSocketImpl.socketBind(java.net.InetAddress, int)
void java.net.PlainSocketImpl.bind(java.net.InetAddress, int)
java.net.ServerSocket(int, int, java.net.InetAddress)
java.net.ServerSocket(int, int)
java.net.ServerSocket
org.apache.tomcat.net.DefaultServerSocketFactory.createSocket(int,
int)
void org.apache.tomcat.service.PoolTcpEndpoint.startEndpoint()
void org.apache.tomcat.service.PoolTcpConnector.start()
void org.apache.tomcat.core.ContextManager.start()
void
org.apache.tomcat.startup.Tomcat.execute(java.lang.String [])
void org.apache.tomcat.startup.Tomcat.main(java.lang.String [])
void digiprop.site.TomcatView.doStart()
void
digiprop.site.TomcatView.connEtoC2(java.awt.event.ActionEvent)
void
digiprop.site.TomcatView$IvjEventHandler.actionPerformed(java.
awt.event.ActionEvent)
void
java.awt.Button.processActionEvent(java.awt.event.ActionEvent)
void java.awt.Button.processEvent(java.awt.AWTEvent)
void java.awt.Component.dispatchEventImpl(java.awt.AWTEvent)
void java.awt.Component.dispatchEvent(java.awt.AWTEvent)
void java.awt.EventDispatchThread.run()
--
---
Brad
RE: [PATCH] mod_jk timestamp and process id logging
We could add the getpid() but what about Apache 2.0 in MPM mode (threaded) ? The getpid() isn't going to be very helpful in that case, but at least it doesn't hurt. Is there some other notion like a thread id that would be applicable to the multithreaded Apache case? Bill __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Servlet bug??
I have tested this problem on both tomcat-3.2.2 and tomcat-4.0-b3.
Here is a jsp that works just fine.
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
%@ page language=java session=true %
%@ page import=java.io.*,java.util.* %
html
head
titleTest/title
/head
body bgcolor=white
h1Test/h1
%
Properties props = new Properties();
InputStream is = null;
try {
is = getServletContext().getResourceAsStream(/WEB-INF/easMail.properties);
} catch ( Exception ex ) {
out.print(ResourceAsStream problem: + ex.getMessage());
}
try {
props.load(is);
} catch ( java.io.IOException e ) {
out.print(Can't load the properties file);
}
for (Enumeration e = props.propertyNames(); e.hasMoreElements();) {
String pn = (String)e.nextElement();
out.print(pn + : + props.getProperty(pn) + br);
}
%
hr
addressa href=mailto:[EMAIL PROTECTED];Earl Stutes/a/address
!-- Created: Mon Apr 16 15:34:31 PDT 2001 --
!-- hhmts start --
Last modified: Mon Apr 23 18:29:11 PDT 2001
!-- hhmts end --
/body
/html
Here is its output
Test
mail.imap.socketFactory.class: javax.net.ssl.SSLSocketFactory
mail.transport.protocol: smtp
mail.imap.socketFactory.port: 993
mail.imap.socketFactory.fallback: false
mail.store.protocol: imap
Here is a snippet of code from my servlet.
line #
124 private void doTask() throws ServletException,IOException,
125 EasMailException {
126 ssn = request.getSession(true);
127 String task = request.getParameter(task);
128 InputStream is = null;
129 try {
130is =
getServletContext().getResourceAsStream(/WEB-INF/easMail.Properties);
131 }
catch (Exception ex) {
request.setAttribute(javax.servlet.jsp.jspException, ex);
svcxt.getRequestDispatcher(/Error.jsp).forward(request, response);
}
try {
props.load(is);
}
catch (Exception ex) {
throw new ServletException( can't find properties file: +
ex.getMessage());
}
Here is the results from running the servlet.
Error Encountered.
java.lang.NullPointerException
java.lang.NullPointerException
at javax.servlet.GenericServlet.getServletContext(GenericServlet.java:205)
at easMail.easMailServlet.doTask(easMailServlet.java:130)
at easMail.easMailServlet.doPost(easMailServlet.java:96)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
What is wrong with this picture? Originally I had the code inside my
init() method, but moved it down in the main body of the class to see
if I was doing something wrong in the init() code.
Thanks
=eas=
[Patch] Tomcat 3.2.2
Gentlefolk,
on the Apache side we ran into a headache on Win2K. Windows services introduced
a SHUTDOWN event with a new signal. Unfortuantely, they did _not_ continue to
support the STOP event from NT. This patch teaches the jk_nt_service to solicit
and respect the SHUTDOWN event as well as the old STOP event.
Your,
Bill
Index: src/native/mod_jk/nt_service/jk_nt_service.c
===
RCS file: /home/cvspublic/jakarta-tomcat/src/native/mod_jk/nt_service/jk_nt_service.c,v
retrieving revision 1.2
diff -u -r1.2 jk_nt_service.c
--- src/native/mod_jk/nt_service/jk_nt_service.c 2000/11/19 04:15:13 1.2
+++ src/native/mod_jk/nt_service/jk_nt_service.c 2001/04/24 04:33:25
@@ -248,6 +248,7 @@
/*
* Stop the service.
*/
+case SERVICE_CONTROL_SHUTDOWN:
case SERVICE_CONTROL_STOP:
ssStatus.dwCurrentState = SERVICE_STOP_PENDING;
stop_jk_service();
@@ -281,7 +282,8 @@
if(dwCurrentState == SERVICE_START_PENDING) {
ssStatus.dwControlsAccepted = 0;
} else {
-ssStatus.dwControlsAccepted = SERVICE_ACCEPT_STOP;
+ssStatus.dwControlsAccepted = SERVICE_ACCEPT_STOP
+| SERVICE_ACCEPT_SHUTDOWN;
}
ssStatus.dwCurrentState = dwCurrentState;
RE: [VOTE] New Committer: Bip Thelin
+1 Larry -Original Message- From: Kief Morris [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 22, 2001 5:22 AM To: [EMAIL PROTECTED] Subject: [VOTE] New Committer: Bip Thelin I would like to propose Bip Thelin as a new committer. He has made a number of contributions of patches over the past several months, including SSI and JDBCRealm, and most recently, is doing solid work on session persistence. Kief
