Re: [MY_OPINION] Tomcat 3.x
Hi Jon, First, I want to thank you for the advices and your mail - even if I don't like what you say I do believe that your mail have some good things for me. It really scares me that you are the only person (as far as I can tell) that is seriously interested in ? maintaining and developing Tomcat 3.x into the future. Well, at least it's good that there's at least one person maintaining and developing it - it's a pretty good product, it'll be scarry if everyone would abandon it to do other things. I have no plans on "developing tomcat3.x into the future" - all I want is finish what I started and I couldn't do in 3.2 timeframe - in terms of performance, refactoring, modularity, security. I don't see any need to go beyond 3.3 - and I said many times I'll stop doing any major changes in the core after 3.3 is done. I'll just fix bugs and develop modules - most of them in my private, non-apache space ( I'm talking about the servlet 2.3 implementation ). If you look at the code ( and any developer should do that before arguing one thing or another ), 3.3 is much cleaner and faster than 3.2 and it's finishing up what was started. I would like to thank you for making me "the only person" maintaining tomcat3.x, but I can't take the credit for that - all I'm doing is improving great code developed by other smart people, and even more importantly finishing up what they've started. As for the future - in many open source projects good code does have a future - I hope the same will happen with tomcat. It is not good to have the entire rest of the core developers work on Tomcat 4.x and having you sit here and say that you are going to work towards back porting everything that the Tomcat 4.x people come up with on your own. Well, I don't see anything wrong in reusing good ideas from tomcat4.x in 3.x - it's in fact the first time I hear anyone saying it's bad. It was one of the goals of tomcat3.x to be modular and allow people to add extensions without affecting the core - and almost all of 4.x can be back ported as tomcat3.x modules. If someone is doing that - people who use tomcat 3 will benefit, and that's good. Talk about a complete duplication of effort by only a single individual. That's a great compliment for the design of tomcat3 ( unfortunately I can't take too much credit for this either ) - if only a single individual can do that it proves ( again ) that tomcat 3 is a great servlet container and gives me reason to keep working. I can't even understand someone wanting to base their work on Tomcat 3.x when all of the core developer support (ie: more than just one person) is going towards Tomcat 4.x. Better design :-) ? Continuity ? I *personally* think that you should either drop your Tomcat 3.x development and work towards making Tomcat 4.0 have all the features and benefits that you want to see in Tomcat 3.x (and thus show that we I think tomcat 3.x has most of the features that I wanted - I would be happy to see 4.0 using the same patterns and design that allow high performance, but I don't have the time or wish to do it again. are all working together instead of this constant fork within the overall Tomcat project) or It's funny you're telling this as if I'm doing something wrong or forking - I strongly agree that forking is bad, and so far I did all I could to avoid forks ( i.e. I stoped developing the Servlet2.3 module as part of tomcat3.3, etc). simply fork what you are doing into another project that is hosted somewhere else. It's the second time an Apache member is asking me to go somewhere else. Believe me, right now it's my biggest wish - I've had more than enough ! In fact, I'm pretty strongly -1 on Tomcat 3.3. If anything it would need to be suggested as Tomcat 5.0 because as far as I can tell, we have already come to the conclusion that Catalina will be Tomcat 4.0. When 3.3 will be ready you are free to vote whatever you want - I just hope your vote will be based on the quality of the code and not political interests. What I'm most concerned with here is the overall Tomcat project goals and seeing you duplicating work and effort is really not making me happy. Reuse != duplication You should be into lobbying people to work with you...not as a "damn you all, I'm going to do what I want regardless of what you say" type of attitude. I know some people prefer the "do what we tell you to do or go away " or "we know what is better " attitude. I don't want to defend myself , and I'll take it as a compliment - I think it's great to be able to think for yourself and be able to work when there's an awful lot of pressure to go away. As for lobbying - thanks for the advice, I think I did quite a bit of lobby in the last year and I a tiny bit of contribution in getting people get involved in tomcat. This is because you will never get any other core developer support behind you for Tomcat 5.0 regardless of how good
BugRat Report #608 has been filed.
Bug report #608 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/608 REPORT #608 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: non-critical Confidence: public Environment: Release: 3.2 JVM Release: 1.2.2 Operating System: NT + Linux OS Release: NT 4, SUSE Linux 6.3 Platform: Intel Synopsis: error-page does not function properly Description: The error-page statement in Web.xml does not function, if the error-page is something else than a *.jsp file. Title: BugRat Report # 608 BugRat Report # 608 Project: Tomcat Release: 3.2 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: non-critical Confidence: public Submitter: Thomas Amrhein ([EMAIL PROTECTED]) Date Submitted: Dec 18 2000, 02:21:16 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: error-page does not function properly Environment: (jvm, os, osrel, platform) 1.2.2, NT + Linux, NT 4, SUSE Linux 6.3, Intel Additional Environment Description: Report Description: The error-page statement in Web.xml does not function, if the error-page is something else than a *.jsp file. How To Reproduce: null Workaround: null View this report online...
error in session management when using apache/tomcat 3.2.1 Release
Hi everybody, i posted a few times earlier ... but now i hope that found the source of the error (till yet without solution). I am using a servlet which calls itself from the get to the post method. A user is identified via sesion (quite usual i think) When using tomcat via 8080 port everything works fine, but when using apache, tomcat looses the proper session (or gets a session for itself for the get and for the post). Any ideas? Cheers Hartwig
RE:RE: Réf. : RE: X509 client certificate (Mr. McClanahan, please take alook at this)
Excuse for my determination but my problem was not solve... After change my serveur.xml to clientAuth=true like Craig R. McClanahan said, I fall again on my first exception when I try to extract the certificate request because object associate with ùrequest attributes nameés 'javax.servlet.request.X509Certificate' aren't of well-known type java.security.cert.X509Certificate but [Ljava.security.cert.X509Certificate;@13a66f ! My snoop servlet give me this fragment information : Request attributes: filters.ExampleFilter.SERVLET_MAPPED = InvokerFilter(ApplicationFilterConfig[name=Servlet Mapped Filter, filterClass=filters.ExampleFilter]) javax.servlet.request.key-size = 40 javax.servlet.request.X509Certificate = [Ljava.security.cert.X509Certificate;@13a66f filters.ExampleFilter.PATH_MAPPED = InvokerFilter(ApplicationFilterConfig[name=Path Mapped Filter, filterClass=filters.ExampleFilter]) javax.servlet.request.cipher-suite = SSL_RSA_EXPORT_WITH_RC4_40_MD5 and my catalina server crash on exception when I try to cast this strange objet to java.security.cert.X509Certificate Exception dans le traitement de la requête sécurisée : java.lang.ClassCastException: [Ljava.security.cert.X509Certificate; at SnoopServlet.doGet(SnoopServlet.java:68) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp Any idea? Best regards Jérôme
BugRat Report #610 has been filed.
Bug report #610 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/610 REPORT #610 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.2.1 JVM Release: 1.2.2 Operating System: winnt OS Release: 4 sp 5 Platform: intel Synopsis: Not handled 'IllegalArgumentException' in org.apache.tomcat.util.RequestUtil Description: java.lang.IllegalArgumentException: Cookie name Discard is a reserved token at javax.servlet.http.Cookie.init(Cookie.java:185) at org.apache.tomcat.util.RequestUtil.processCookies(RequestUtil.java, Compiled Code) at org.apache.tomcat.core.RequestImpl.getCookies(RequestImpl.java, Compiled Code) at org.apache.tomcat.request.SessionInterceptor.requestMap(SessionInterceptor.java, Compiled Code) at org.apache.tomcat.core.ContextManager.processRequest(ContextManager.java, Compiled Code) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:552) at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection(Ajp12ConnectionHandler.java:156) at org.apache.tomcat.service.TcpConnectionThread.run(SimpleTcpEndpoint.java:338) at java.lang.Thread.run(Thread.java:479) Title: BugRat Report # 610 BugRat Report # 610 Project: Tomcat Release: 3.2.1 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: Janos Kovac ([EMAIL PROTECTED]) Date Submitted: Dec 18 2000, 04:28:19 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Not handled 'IllegalArgumentException' in org.apache.tomcat.util.RequestUtil Environment: (jvm, os, osrel, platform) 1.2.2, winnt, 4 sp 5, intel Additional Environment Description: Report Description: java.lang.IllegalArgumentException: Cookie name Discard is a reserved token at javax.servlet.http.Cookie.(Cookie.java:185) at org.apache.tomcat.util.RequestUtil.processCookies(RequestUtil.java, Compiled Code) at org.apache.tomcat.core.RequestImpl.getCookies(RequestImpl.java, Compiled Code) at org.apache.tomcat.request.SessionInterceptor.requestMap(SessionInterceptor.java, Compiled Code) at org.apache.tomcat.core.ContextManager.processRequest(ContextManager.java, Compiled Code) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:552) at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection(Ajp12ConnectionHandler.java:156) at org.apache.tomcat.service.TcpConnectionThread.run(SimpleTcpEndpoint.java:338) at java.lang.Thread.run(Thread.java:479) How To Reproduce: null Workaround: null View this report online...
RE: [MY_OPINION] Tomcat 3.x
I definitely agree with Henry Costin... Saludos , Ignacio J. Ortega
Re: jsp - html speedup
cga wrote: Hi there, I was thinking "There is a way to speed up jps". I mean if I take out white spaces and other unnecesary text out of the html part of a jsp, the server will send less bytes to the browser so it will be faster. I am pretending to do a Reader that takes out that unnecesary chars. I know Java, but few jakarta. So, the first time, when the server reads the jsp to make the code, it also takes out those unnecesary spaces (and comments). Is there something like this already done? Not that I know of. If I do it, will someone help me to integrate? I'm sure that someone in the community will be more than happy to help. If you have a proposal with more specifics, you should also get valuable feedback from other people. By the way, it should be configurable. I mean, someone should use it only if he wants to. And if there is a bug the makes that a particular page not to be shown properly, to disable it for that page. Makes sense. Thanks in advance, Carlos Gaston Alvarez Well, thanks to you for your interest in contributing to the source code! -- Pierre
about the socket error
tomcat-dev,hi! I have the tomcat is version 3.1 with own webserver,with the request 'rise,we can find the socket error and stop automic when want to restart tomcat,it can not restart,we should restart the computer and then we can start the tomcat again.I hear that should modify the HttpResponseAdapter.java.Can you tell me the reason,and how to patch it.thanks error:java.net.SocketException: Connection reset by peer: socket write kelfen [EMAIL PROTECTED]
TOMCAT 3.2.1 STANDALONE AND SSL: Error reading request
Hi, sorry for my mail into this group, but the user group seems to be dead since the 19th of November and we got an urgent SSL problem: I'm currently stuck with my SSL enabling of tomcat 3.2 with a weird error message. As soon as I try to access SSL secured content, the following error occurs: 2000-12-15 05:23:51 - ContextManager: Error reading request R( /) 4002000-12-15 05:23:51 - Ctx( ): 400 R( /) null2000-12-15 05:23:51 - Ctx( ): Handler null null2000-12-15 05:23:51 - Ctx( ): IOException in: R( /) Socket closed 2000-12-15 05:10:57 - Ctx( ): IOException in: R( /) Socket closed After a while, the following exception is thrown: at java.io.IOException.init(IOException.java:49) at javax.net.ssl.SSLException.init([DashoPro-V1.2-120198]) at java.io.BufferedInputStream.fill(BufferedInputStream.java:192) at javax.servlet.ServletInputStream.readLine(ServletInputStream.java:138) at org.apache.tomcat.service.http.HttpRequestAdapter.readNextRequest(HttpRequestAdapter.java:129) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:195) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) at java.lang.Thread.run(Thread.java:498) I've compiled tomcat 3.2 with SSL support (SSLSocketFactory was compiled successfully) as described in the Tomcal-SSL-Howto document. Also, I've changed my jdk-1.3 (IBM) jre java.security file as described. I had a problem adding my CERT to the keystore, where keytool always complained that the public keys are different between the stored and given key. I worked that around by deleting the keystore and let keytool create it during the CERT import. That worked (But I'm not sure that RSA is enabled when using that way). The system is SuSE Linux 7.0, jdk: SUN 1.2.2, JSSE 1.0 Has anyone an idea what the problem is? Is this caused by a keystore problem reading my CERT or is there any hint you can give me? Thanks in advance! Robert
TC 4.0 m5 and mod_warp
Hi, Just tested TC 4.0 m5 and mod_warp from my RPMs. In my httpd.conf : ... IfDefine SSL LoadModule ssl_module lib/apache/libssl.so /IfDefine LoadModule perl_modulelib/apache/libperl.so LoadModule dav_module lib/apache/libdav.so LoadModule webapp_modulelib/apache/mod_webapp.so ... IfDefine SSL AddModule mod_ssl.c /IfDefine AddModule mod_perl.c AddModule mod_dav.c AddModule mod_webapp.c IfModule mod_dav.c DAVLockDB /var/run/DAVLock DAVMinTimeOut 600 /IfModule ... IfModule mod_webapp.c WebAppConnection warpConnection warp localhost:8008 WebAppMount examples warpConnection /examples/ /IfModule ... Some examples works like : HelloWorldExample, RequestInfoExample, RequestHeaderExample. Others didn't works as necessary : RequestParamExample CookieExample Others make TC failed : SessionExample = [org.apache.catalina.connector.warp.WarpRequestHandler]Request Header Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* [org.apache.catalina.connector.warp.WarpRequestHandler]Request Header Accept-Encoding: gzip, deflate [org.apache.catalina.connector.warp.WarpRequestHandler]Request Header Accept-Language: fr [org.apache.catalina.connector.warp.WarpRequestHandler]Request Header Connection: Keep-Alive [org.apache.catalina.connector.warp.WarpRequestHandler]Request Header Content-Length: 26 [org.apache.catalina.connector.warp.WarpRequestHandler]Request Header Content-Type: application/x-www-form-urlencoded [org.apache.catalina.connector.warp.WarpRequestHandler]Request Header Cookie: JSESSIONID=822298D7B315C0035492046654A7B4A2 [org.apache.catalina.connector.warp.WarpRequestHandler]Request Header Host: hgo1.cs [org.apache.catalina.connector.warp.WarpRequestHandler]Request Header Referer: http://localhost/examples/servlet/SessionExample [org.apache.catalina.connector.warp.WarpRequestHandler]Request Header User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) [org.apache.catalina.connector.warp.WarpRequestHandler]Invoking request [org.apache.catalina.connector.warp.WarpRequestHandler]End of request [org.apache.catalina.connector.warp.WarpRequestHandler]Thread exited Something with cookie support ? PS: The mod_warp is the one from today CVS...
RE: TC 4.0 m5 and mod_warp
Just to continue : The jsession is written on URL : http://localhost/examples/servlet/SessionExample;jsessionid=B0B0D1E98495F533 D57255B4F1952436
RE: [PATCH] Saving sessions across tomcat instances (#1)
Hola Shai: IMHO your patch very interesting, i want use it on my own ( prior to commit it after a review by people ).. In mean time, please send patches as attached files, not embedded in a message, and another silly advice, please please dont send messages in HTML, for the people that have big screens ( as i ) sending html results on a lot of glass to add to my glasses :-) Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: lunes 18 de diciembre de 2000 10:28 Para: [EMAIL PROTECTED] Asunto: [PATCH] Saving sessions across tomcat instances (#1) Hi all, As discussed, attached first patch to allow tomcat share session information across processes. This patch enable context to specify (by adding serialize="true") that it want to save/reload session information while restarting and going down. The session information will be stored and reloaded for temp files located at bin directory. Index: src/share/org/apache/tomcat/core/Context.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/core/Context. java,v retrieving revision 1.100.2.4 diff -w -u -r1.100.2.4 Context.java --- src/share/org/apache/tomcat/core/Context.java 2000/11/18 00:09:42 1.100.2.4 +++ src/share/org/apache/tomcat/core/Context.java 2000/12/18 07:11:01 @@ -97,6 +97,7 @@ * @author [EMAIL PROTECTED] * @author Gal Shachor [EMAIL PROTECTED] * @author Arieh Markel [[EMAIL PROTECTED]] + * @author Shai Fultheim [[EMAIL PROTECTED]] */ public class Context { private static StringManager sm =StringManager.getManager("org.apache.tomcat.core"); @@ -114,6 +115,7 @@ private boolean crossContext = true; private ServletLoader servletL; boolean reloadable=true; // XXX change default to false after testing + private boolean serialize = false; // Don't save session info across run. private Hashtable attributes = new Hashtable(); @@ -281,6 +283,19 @@ return reloadable; } + // -- Serializeable ? -- + public void setSerialize( String s ) { + serialize=new Boolean( s ).booleanValue(); + } + + public void setSerialize( boolean b ) { + serialize=b; + } + + public boolean getSerialize() { + return serialize; + } + // Web.xml properties public Enumeration getWelcomeFiles() { Index: src/share/org/apache/tomcat/session/StandardManager.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/session/Attic /StandardManager.java,v retrieving revision 1.11.2.1 diff -w -u -r1.11.2.1 StandardManager.java --- src/share/org/apache/tomcat/session/StandardManager.java 2000/11/18 01:33:59 1.11.2.1 +++ src/share/org/apache/tomcat/session/StandardManager.java 2000/12/18 07:11:09 @@ -64,14 +64,14 @@ package org.apache.tomcat.session; -import java.io.IOException; +import java.io.*; import java.util.Enumeration; import java.util.Hashtable; import java.util.Vector; import javax.servlet.http.Cookie; import javax.servlet.http.HttpSession; import org.apache.tomcat.util.*; -import org.apache.tomcat.core.Request; +import org.apache.tomcat.core.*; /** * Standard implementation of the bManager/b interface that provides @@ -83,7 +83,7 @@ * code * lt;Manager className="org.apache.tomcat.session.StandardManager" * checkInterval="60" maxActiveSessions="-1" - * maxInactiveInterval="-1" / + * maxInactiveInterval="-1" serialize="true"/ * /code * where you can adjust the following parameters, with default values * in square brackets: @@ -97,6 +97,8 @@ * a session, or -1 for no limit. This value should be overridden from * the default session timeout specified in the web application deployment * descriptor, if any. [-1] + * libserialize/b - Allow tomcat save and reload session information + * from file over system startup. [false] * /ul * * @author Craig R. McClanahan @@ -162,9 +164,15 @@ */ private String threadName = "StandardManager"; + /** + * Contain owner's context object + */ + private Context ctx = null; + // - Constructor - public StandardManager() { + public StandardManager(Context ctx) { + this.ctx = ctx; } // - Properties @@ -378,6 +386,14 @@ session.setMaxInactiveInterval(this.maxInactiveInterval); session.setId(SessionUtil.generateSessionId(jsIdent)); + if (ctx.getDebug() 10) { + HttpSession Sessions[] = findSessions(); + ctx.log(ctx.toString() + " Sessions: " + Sessions.length); + for(int i=0; iSessions.length; i++) { + ctx.log(" " + i + ": " + Sessions[i].getId()); + } + } + return (session); } @@ -398,7 +414,39 @@ public void start() { // Start the background reaper thread threadStart(); + + if (ctx.getSerialize()) { + FileInputStream Stream = null; + try { + Stream = new FileInputStream(getFileName()); +
RE: [PATCH] Saving sessions across tomcat instances (#1)
Agree. How do I configure wincvs to give me file with differences. How do I configure wincvs to do diff -u ? (default is -w) ? --Shai -Original Message- From: Nacho [mailto:[EMAIL PROTECTED]] Sent: Monday, December 18, 2000 16:48 To: 'tomcat-dev' Subject: RE: [PATCH] Saving sessions across tomcat instances (#1) Hola Shai: IMHO your patch very interesting, i want use it on my own ( prior to commit it after a review by people ).. In mean time, please send patches as attached files, not embedded in a message, and another silly advice, please please dont send messages in HTML, for the people that have big screens ( as i ) sending html results on a lot of glass to add to my glasses :-) Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: lunes 18 de diciembre de 2000 10:28 Para: [EMAIL PROTECTED] Asunto: [PATCH] Saving sessions across tomcat instances (#1) Hi all, As discussed, attached first patch to allow tomcat share session information across processes. This patch enable context to specify (by adding serialize="true") that it want to save/reload session information while restarting and going down. The session information will be stored and reloaded for temp files located at bin directory. Index: src/share/org/apache/tomcat/core/Context.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/core/Context. java,v retrieving revision 1.100.2.4 diff -w -u -r1.100.2.4 Context.java --- src/share/org/apache/tomcat/core/Context.java 2000/11/18 00:09:42 1.100.2.4 +++ src/share/org/apache/tomcat/core/Context.java 2000/12/18 07:11:01 @@ -97,6 +97,7 @@ * @author [EMAIL PROTECTED] * @author Gal Shachor [EMAIL PROTECTED] * @author Arieh Markel [[EMAIL PROTECTED]] + * @author Shai Fultheim [[EMAIL PROTECTED]] */ public class Context { private static StringManager sm =StringManager.getManager("org.apache.tomcat.core"); @@ -114,6 +115,7 @@ private boolean crossContext = true; private ServletLoader servletL; boolean reloadable=true; // XXX change default to false after testing + private boolean serialize = false; // Don't save session info across run. private Hashtable attributes = new Hashtable(); @@ -281,6 +283,19 @@ return reloadable; } + // -- Serializeable ? -- + public void setSerialize( String s ) { + serialize=new Boolean( s ).booleanValue(); + } + + public void setSerialize( boolean b ) { + serialize=b; + } + + public boolean getSerialize() { + return serialize; + } + // Web.xml properties public Enumeration getWelcomeFiles() { Index: src/share/org/apache/tomcat/session/StandardManager.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/session/Attic /StandardManager.java,v retrieving revision 1.11.2.1 diff -w -u -r1.11.2.1 StandardManager.java --- src/share/org/apache/tomcat/session/StandardManager.java 2000/11/18 01:33:59 1.11.2.1 +++ src/share/org/apache/tomcat/session/StandardManager.java 2000/12/18 07:11:09 @@ -64,14 +64,14 @@ package org.apache.tomcat.session; -import java.io.IOException; +import java.io.*; import java.util.Enumeration; import java.util.Hashtable; import java.util.Vector; import javax.servlet.http.Cookie; import javax.servlet.http.HttpSession; import org.apache.tomcat.util.*; -import org.apache.tomcat.core.Request; +import org.apache.tomcat.core.*; /** * Standard implementation of the bManager/b interface that provides @@ -83,7 +83,7 @@ * code * lt;Manager className="org.apache.tomcat.session.StandardManager" * checkInterval="60" maxActiveSessions="-1" - * maxInactiveInterval="-1" / + * maxInactiveInterval="-1" serialize="true"/ * /code * where you can adjust the following parameters, with default values * in square brackets: @@ -97,6 +97,8 @@ * a session, or -1 for no limit. This value should be overridden from * the default session timeout specified in the web application deployment * descriptor, if any. [-1] + * libserialize/b - Allow tomcat save and reload session information + * from file over system startup. [false] * /ul * * @author Craig R. McClanahan @@ -162,9 +164,15 @@ */ private String threadName = "StandardManager"; + /** + * Contain owner's context object + */ + private Context ctx = null; + // - Constructor - public StandardManager() { + public StandardManager(Context ctx) { + this.ctx = ctx; } // - Properties @@ -378,6 +386,14 @@ session.setMaxInactiveInterval(this.maxInactiveInterval); session.setId(SessionUtil.generateSessionId(jsIdent)); + if (ctx.getDebug() 10) { + HttpSession Sessions[] = findSessions(); + ctx.log(ctx.toString() + " Sessions: " + Sessions.length); + for(int i=0;
Re:X509 client certificate (please take a look at this)
I tried as Jerome Camilleri did and I can say that it doesn't work. I also tried to use java.security.cert.X509Certificate but it returns a null reference!:( In fact it's not requesting any certificate from my browser. (I'm using Netscape 4.73 and 6.0). TIA, Alexandre. On Mon, 18 Dec 2000 11:03:48 +0100 [EMAIL PROTECTED] wrote: Excuse for my determination but my problem was not solve... After change my serveur.xml to clientAuth="true" like Craig R. McClanahan said, I fall again on my first exception when I try to extract the certificate request because object associate with ùrequest attributes nameés 'javax.servlet.request.X509Certificate' aren't of well-known type java.security.cert.X509Certificate but [Ljava.security.cert.X509Certificate;@13a66f ! My snoop servlet give me this fragment information : Request attributes: filters.ExampleFilter.SERVLET_MAPPED = InvokerFilter(ApplicationFilterConfig[name=Servlet Mapped Filter, filterClass=filters.ExampleFilter]) javax.servlet.request.key-size = 40 javax.servlet.request.X509Certificate = [Ljava.security.cert.X509Certificate;@13a66f filters.ExampleFilter.PATH_MAPPED = InvokerFilter(ApplicationFilterConfig[name=Path Mapped Filter, filterClass=filters.ExampleFilter]) javax.servlet.request.cipher-suite = SSL_RSA_EXPORT_WITH_RC4_40_MD5 and my catalina server crash on exception when I try to cast this strange objet to java.security.cert.X509Certificate Exception dans le traitement de la requête sécurisée : java.lang.ClassCastException: [Ljava.security.cert.X509Certificate; at SnoopServlet.doGet(SnoopServlet.java:68) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp Any idea? Best regards Jérôme
Apache/Tomcat 3.2.1 session error - help!
Hi, i still have my problem using tomcat 3.2.1 (release) with apache. Sessions are mixed up when calling the same servlet but using get/post method (get calls post and the other way around). Problem only arises when using tomcat with apache - not when using tomcat standalone. Any hints? Cheers Hartwig
stupid question on array return by javax.servlet.request.X509Certificateattribute
Why the attribute 'javax.servlet.request.X509Certificate' return an array of X509Certificate. I don't understand how it's possible because when my client choose an certificate, he chooses only one... For my test array contain always one element... so is it an specification to anticipate the future ? Best Regards The type is javax.servlet.request.X509Certificate[] ?? ie an array not a single instance.. [EMAIL PROTECTED] on 18/12/2000 05:03:48 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Ken X Horn) Subject: RE:RE: Réf. : RE: X509 client certificate (Mr. McClanahan, please take a look at this) Excuse for my determination but my problem was not solve... After change my serveur.xml to clientAuth=true like Craig R. McClanahan said, I fall again on my first exception when I try to extract the certificate request because object associate with ùrequest attributes nameés 'javax.servlet.request.X509Certificate' aren't of well-known type java.security.cert.X509Certificate but [Ljava.security.cert.X509Certificate;@13a66f ! My snoop servlet give me this fragment information : Request attributes: filters.ExampleFilter.SERVLET_MAPPED = InvokerFilter(ApplicationFilterConfig[name=Servlet Mapped Filter, filterClass=filters.ExampleFilter]) javax.servlet.request.key-size = 40 javax.servlet.request.X509Certificate = [Ljava.security.cert.X509Certificate;@13a66f filters.ExampleFilter.PATH_MAPPED = InvokerFilter(ApplicationFilterConfig[name=Path Mapped Filter, filterClass=filters.ExampleFilter]) javax.servlet.request.cipher-suite = SSL_RSA_EXPORT_WITH_RC4_40_MD5 and my catalina server crash on exception when I try to cast this strange objet to java.security.cert.X509Certificate Exception dans le traitement de la requête sécurisée : java.lang.ClassCastException: [Ljava.security.cert.X509Certificate; at SnoopServlet.doGet(SnoopServlet.java:68) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp Any idea? Best regards Jérôme Jérôme
Re:Enterprise Tomcat
I am using Tomcat as the enterprise servlet container in production for our B2B E-Commerce servlet and several intranet applications at Joseph E. Seagram Sons, Inc. I'm using the ISAPI filter and an SSL connection to IIS. The URL is only for our distributors to use, but you can hit the login servlet page to see the servlet running at: http://www.custserv.seagram.com/ Jonathan Reply Separator Subject:Enterprise Tomcat Author: [EMAIL PROTECTED] Date: 12/8/00 11:41 AM Hello all, Does anyone know of Corperate (Fortune 500) companies using Tomcat as their enterprise servlet container? Anything like that at all? Links would be great. We (tech types) want to use it, but have to prove mgmt. that it's in use in the big companies. (Our mandate is no unproven technologies) Don't flame me, that's not my definition of proven technology... I've been trying to find _anything_ about Tomcat and enterprise usage and am having no luck. What percentage of core coders on TC are from Sun? (guesses?) I think this would argue my case... Any help is appreciated. Cheers, mk Michael R. Kuz Developer Service Intelligence (403) 261-5000 ext. 363 [EMAIL PROTECTED] !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" HTML HEAD META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1" META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12" TITLEEnterprise Tomcat /TITLE /HEAD BODY PFONT SIZE=2 FACE="Arial"Hello all, /FONT /P PFONT SIZE=2 FACE="Courier New"Does anyone know of Corperate (Fortune 500) companies using Tomcat as their enterprise servlet container? /FONT BRFONT SIZE=2 FACE="Courier New"Anything like that at all? Links would be great./FONT /P PFONT SIZE=2 FACE="Courier New"We (tech types) want to use it, but have to prove mgmt. that it's in use in the big companies./FONT /P PFONT SIZE=2 FACE="Courier New"(Our mandate is no unproven technologies)/FONT BRFONT SIZE=2 FACE="Courier New"Don't flame me, that's not my definition of proven technology.../FONT /P PFONT SIZE=2 FACE="Courier New"I've been trying to find _anything_ about Tomcat and enterprise usage and am having no luck./FONT /P PFONT SIZE=2 FACE="Courier New"What percentage of core coders on TC are from Sun? (guesses?) I think this would argue my case.../FONT /P PFONT SIZE=2 FACE="Courier New"Any help is appreciated./FONT BRFONT SIZE=2 FACE="Courier New"Cheers,/FONT BRFONT SIZE=2 FACE="Courier New"mk/FONT /P BR BR PFONT SIZE=2 FACE="Arial"Michael R. Kuz/FONT BRFONT SIZE=2 FACE="Arial"Developer/FONT BRFONT SIZE=2 FACE="Arial"Service Intelligence/FONT BRFONT SIZE=2 FACE="Arial"(403) 261-5000 ext. 363/FONT BRFONT SIZE=2 FACE="Arial"[EMAIL PROTECTED]/FONT /P BR /BODY /HTML
BugRat Report #613 has been filed.
Bug report #613 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/613 REPORT #613 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: Tomcat 4.0 JVM Release: 1.3 Operating System: Win2K OS Release: SP1 Platform: intel Synopsis: lossing connection on POST Description: The server is dropping me whenever I do a POST with an enctype='multipart/form-data'. I'm not having the problem when running under JWS2.0!! Anyone seen this...or is there a know fix that I'm not aware of!!?? Thanks in advance -mt Title: BugRat Report # 613 BugRat Report # 613 Project: Tomcat Release: Tomcat 4.0 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: mike toffolo ([EMAIL PROTECTED]) Date Submitted: Dec 18 2000, 10:28:51 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: lossing connection on POST Environment: (jvm, os, osrel, platform) 1.3, Win2K, SP1, intel Additional Environment Description: Report Description: The server is dropping me whenever I do a POST with an enctype='multipart/form-data'. I'm not having the problem when running under JWS2.0!! Anyone seen this...or is there a know fix that I'm not aware of!!?? Thanks in advance -mt View this report online...
Re: Apache 2.0
Hi, I am able to compile Apache2.0, and I updated mod_jk for the modified functions in 2.0 - it now compiles. I'm pretty confident we can have it running in few days - it did worked before and it works fine with other multithreaded servers. As you can see, most of the code in mod_jk is indpendent of server architecture. The only obstacles are the ammount of work I have for this week ( on my job ) and the fact that I may need to upgrade my OS to run Apache2.0. Right now it compiles but crashes on startup, and I traced it to the mm module and scoreboard ( that's before adding mod_jk). I tried various options on mm ( including FILE ) but it still crashes - so I'll have to try with a different glibc, as that is the problem I presume. ( I have a RedHat 6.2 with a lot of updates, like glibc 2.1.95 ). Please let me know what's the schedule you have in mind for upgrading. Costin __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
Re: [MY_OPINION] Tomcat 3.x
Not everybody is in a position to throw away their investment in the 3.x series just yet. While its fun to try the latest and greatest, not everybody can do that. Craig, is java.sun.com running on Tomcat 4.0? Jon, is www.apache.org running Apache 2.0 yet? When do you think they will be ready to run those packages? While this may be a "reference implementation," it is still being used in production environments. Production environments have very different requirements than development environments. Does Tomcat 3.x have bugs? Absolutely. But we've found those bugs in our QA environment, identified them, and worked around them as needed. Tomcat 4.0 will have a whole new set of bugs that we will need to spend time working around. We're still running our sites on 3.1, because we haven't had time to re-do the verification work with 3.2 yet. I'm just saying that while Tomcat 4.0 may have the most perfect design, it is un-proven in production environments. Tomcat 3.x has been proven for our application. We need to continue the 3.x tree at least until 4.0 is proven as ready. That takes time. 3.x has been brewing for a very long time. There have been lots of changes, but more has stayed the same than has changed. Tomcat 4.0 is almost entirely new code. We need something we can count on for production. Tomcat 4.0 isn't there yet. I also think that its appalling that people should tell Costin to go away. The Apache project should be very very thankful that they have somebody around to maintain the code that others have abandoned. Where would we be if the latest stable version of Apache was 1.3.0, and all the other developers had run off to work on 2.0? If that had happened, the Apache project would have been dismissed by everybody as a toy, and Apache wouldn't be in the position it is in today. Paul Frieden PS: www.apache.org runs Apache 1.3.15-dev, and java.sun.com runs Apache 1.3.3. GOMEZ Henri wrote: It really scares me that you are the only person (as far as I can tell) that is seriously interested in maintaining and developing Tomcat 3.x into the future. It is not good to have the entire rest of the core developers work on Tomcat 4.x and having you sit here and say that you are going to work towards back porting everything that the Tomcat 4.x people come up with on your own. Talk about a complete duplication of effort by only a single individual. * Costin is not alone on the TC 3.3 tree. You could see there is contributions 3.3 from Larry, Nacho and Dan. I can't even understand someone wanting to base their work on Tomcat 3.x when all of the core developer support (ie: more than just one person) is going towards Tomcat 4.x. * Hey, don't forget that tomcat 3.x is now the only real running distribution. Me and others see TC 4.0 as an experimental product, a way to test and validate the servlet 2.3 and JSP 1.2 API. I *personally* think that you should either drop your Tomcat 3.x development and work towards making Tomcat 4.0 have all the features and benefits that you want to see in Tomcat 3.x (and thus show that we are all working together instead of this constant fork within the overall Tomcat project) or simply fork what you are doing into another project that is hosted somewhere else. * The good point with TC 4.0 are all the good things inside (JMX, JAXP 1.0/1.1) The bad point on TC 4.0 are all these good things (JMX, JAXP 1.0/1.1). You have seens the thread on '[PROPOSAL] building is easy'. We need too many things now to build TC 4.0. Also even if TC 4.0 is an OpenSource projects, too many of the required packages are not 'Open Sourced' or not easily exportable. Also many peoples want to have a fast servlet engine with a low memory profile. I saw TC 4.0 to be much hungry. In fact, I'm pretty strongly -1 on Tomcat 3.3. If anything it would need to be suggested as Tomcat 5.0 because as far as I can tell, we have already come to the conclusion that Catalina will be Tomcat 4.0. * Why not consider TC 3.3 as a light servlet engine ? It make sense since many sites will not need all the stuff inside TC 4.0. I hope that Apache Group will not forget that many of the web sites which run it's httpd servlet are personal computers and not clusters of Ghz CPUs and Gb of RAM. Don't take what I said as me kicking you out or killing things or anything even remotely personal. What I'm most concerned with here is the overall Tomcat project goals and seeing you duplicating work and effort is really not making me happy. Sure, you could say that the goals might be flawed in your opinion, which is perfectly valid, but the fact of the matter is that the rest of the people on the project are working towards making Tomcat 4.0 the future. * I don't saw that as a duplicate effort. TC 3.3 is the continuation of 3.x tree. TC 4.0 is much more ambitiuous and nice for the next future but the
Re: [MY_OPINION] Tomcat 3.x
* The good point with TC 4.0 are all the good things inside (JMX, JAXP 1.0/1.1) The bad point on TC 4.0 are all these good things (JMX, JAXP 1.0/1.1). You have seens the thread on '[PROPOSAL] building is easy'. We need too many things now to build TC 4.0. You need JAXP, JSSE and JMX. - The JMX components are NOT used at runtime except if you run TC4 through JMX. - JAXP, well, most Jakarta projects require it already. - JSSE is required just to compile the secure SSLServerSocketFactory (whaich was taken from the 3.2 tree) and that's it. I don't see any fancy features here, or anything too unusual, except that some of these things (like JSSE) should have conditional switches. Also even if TC 4.0 is an OpenSource projects, too many of the required packages are not 'Open Sourced' or not easily exportable. Also many peoples want to have a fast servlet engine with a low memory profile. I saw TC 4.0 to be much hungry. From my experience, it looks we're talking 20% more here (or 2-3M), which doesn't seem that much to me. Apparently, we're creating more objects than TC3 in the core. * Why not consider TC 3.3 as a light servlet engine ? It make sense since many sites will not need all the stuff inside TC 4.0. I fail to see to which part of TC4 it does apply. * I don't saw that as a duplicate effort. TC 3.3 is the continuation of 3.x tree. TC 4.0 is much more ambitiuous and nice for the next future but the present now is Apache JServ, Tomcat 3.1 and some Tomcat 3.2. We need to have a continuation effort on existing software for present hardware. I don't agree. TC3.3 is a rewrite of TC3.2, with all of the TC4 "fancy features" (and some more). AFAIK, there is no plan to get rid of / stop maitaining TC 3.2, and actually it's Craig who handles the 3.2 releases and maintenance releases (like 3.2.1), not Costin. One thing that Craig did with 4.0 that was the right thing to do was to lobby the core developers into working on his vision of the future, where your "attitude" has been to simply continue working on your vision no matter what everyone else is doing. * That's may be the core of the problem. Craig has been just to good in lobbying. There is not too much core developpers now in TC 3.3. Another problem is that the majority of TC 4.0 developpers are Sun employees. Many could see TC 4.0 as a Sun projects with externals contributions and bugs reports. Please remember the discussions on Xerces list against IBMers and Suners about Spinaker and Xerces 2.0 As far as I know, nearly of the core TC devs are / were Sun people anyway, so actually it's Sun vs Sun. The danger now is that Apache Group seems to loose its heart. As far as I'm concerned, TC3.x is THE Sun project. It was developed internally at Sun, and then released as OSS to the Apache group. Up until 3.1, it was developed by Sun people. TC4 has been designed and developed by Craig, who was one of the original of JServ. I started contributing to TC4 earlier this year, and I've recently joined Sun (1 month ago), but that's more because of personal problems with my previous employer (Exoffice / Intalio) than anything else. Majors software companies are flying and provide their software under the Apache Umbrella. Must we wait now for a Microsoft arrival with a .NET or C# contribution to Apache Group ? Did the operating system of Apache systems is still FreeBSD ? Please wake-up all and see that Costin may be one of the latest BSDers out of there. An excellent developper but a poor politic. All of us, have just too many politics in real life, so let it outside Apache wall. Let Costin and others continue their work on TC 3.3, 3.4, 3.5. Just saw TC 3.3 and successor as a lightweight alternative to the more ambitious TC 4.0. Jakarta must be able to answer to user with low cost system. And please don't forget that Apache has made it's reputation on a fast http server running nicely on a 386 with 12m RAM. Neither TC3 nor TC4 would run fine on that, I'm afraid. Remy
Re: Apache 2.0
Wow. That was fast. I am in the middle of compiling Apache 2.0 on locus so that we can run it with locus's config file on port 8080. I expect we will release the alpha on Friday unless something goes wrong, Once I have Apache running on port 8080 on locus, we can work on getting mod_jk installed in it as well. Ryan On Mon, 18 Dec 2000, Costin Manolache wrote: Hi, I am able to compile Apache2.0, and I updated mod_jk for the modified functions in 2.0 - it now compiles. I'm pretty confident we can have it running in few days - it did worked before and it works fine with other multithreaded servers. As you can see, most of the code in mod_jk is indpendent of server architecture. The only obstacles are the ammount of work I have for this week ( on my job ) and the fact that I may need to upgrade my OS to run Apache2.0. Right now it compiles but crashes on startup, and I traced it to the mm module and scoreboard ( that's before adding mod_jk). I tried various options on mm ( including FILE ) but it still crashes - so I'll have to try with a different glibc, as that is the problem I presume. ( I have a RedHat 6.2 with a lot of updates, like glibc 2.1.95 ). Please let me know what's the schedule you have in mind for upgrading. Costin __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: WML Generation from JSP broken!!!!
Works for me. Every mime-type usually lays claim to a default suffix or two and we should definitely pick one and say that there is an implicit mapping for that prefix. So if I name my pages jspx then I don't have to worry about setting any mappings to get a JSP container to interpret the page as a JSP page written in XML. We should also do this for regular old JSP itself. So here's my proposal: JSP 1.2 engines have mime type mappings like so (or something like this): *.jsp - application/jsp *.jspx - application/jsp-xml And documents of type application/jsp and application/jspx (or whatever names we decide on) are handled appropriately by default without any special web.xml constructs. This will also enable one to author a mime-type based servlet filter that can operate on JSP pages in a standard way. Miles Sabin [EMAIL PROTECTED] writes: Tom Reilly wrote, It seems to me there are a couple solutions: 1) look for jsp:root 2) use DOCTYPE 3) based it on file extension I don't like 1 because it adds overhead to the translation process, and you have to deal with cases like: %-- jsp:root --% I don't like 2 because if your JSP page is generating XML and you want to output a DOCTYPE then you have a collision. So that leaves 3 which I like the best. A good standard default would be "jspx". Of course most app servers allow this to be customized. I also like this because then different filters can be assigned to JSP pages written in XML and plain old JSP pages. Yes and no. I agree that it'd be a mistake to handle this by inspecting the contents of the document, but I don't think file extensions are quite the right way to go. We should do it based on MIME type, and allow servers to use their existing file extension to MIME type mapping mechanisms to do the rest. What is the mime type for an XML-syntax JSP doc? application/jsp+xml or text/jsp+xml would seem to be the most likely candidates ... presumably they'd need to be registered. Cheers, Miles -- Miles Sabin InterX Internet Systems Architect5/6 Glenthorne Mews +44 (0)20 8817 4030 London, W6 0LJ, England [EMAIL PROTECTED] http://www.interx.com/ -- Tom Reilly Allaire Corp. http://www.allaire.com
RE: stupid question on array return by javax.servlet.request.X509Certificateattribute
The idea (I think) is to have the certificate chain in there. Your client certificate is signed by some authority which may, in turn, be signed by someone else and so on... So you could get your client certificate as the first element, the one who signed his certificate as the second and so on. Regards, Stefan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 18. desember 2000 16:16 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: stupid question on array return by javax.servlet.request.X509Certificateattribute Why the attribute 'javax.servlet.request.X509Certificate' return an array of X509Certificate. I don't understand how it's possible because when my client choose an certificate, he chooses only one... For my test array contain always one element... so is it an specification to anticipate the future ? Best Regards The type is javax.servlet.request.X509Certificate[] ?? ie an array not a single instance.. [EMAIL PROTECTED] on 18/12/2000 05:03:48 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Ken X Horn) Subject: RE:RE: Réf. : RE: X509 client certificate (Mr. McClanahan, please take a look at this) Excuse for my determination but my problem was not solve... After change my serveur.xml to clientAuth="true" like Craig R. McClanahan said, I fall again on my first exception when I try to extract the certificate request because object associate with ùrequest attributes nameés 'javax.servlet.request.X509Certificate' aren't of well-known type java.security.cert.X509Certificate but [Ljava.security.cert.X509Certificate;@13a66f ! My snoop servlet give me this fragment information : Request attributes: filters.ExampleFilter.SERVLET_MAPPED = InvokerFilter(ApplicationFilterConfig[name=Servlet Mapped Filter, filterClass=filters.ExampleFilter]) javax.servlet.request.key-size = 40 javax.servlet.request.X509Certificate = [Ljava.security.cert.X509Certificate;@13a66f filters.ExampleFilter.PATH_MAPPED = InvokerFilter(ApplicationFilterConfig[name=Path Mapped Filter, filterClass=filters.ExampleFilter]) javax.servlet.request.cipher-suite = SSL_RSA_EXPORT_WITH_RC4_40_MD5 and my catalina server crash on exception when I try to cast this strange objet to java.security.cert.X509Certificate Exception dans le traitement de la requête sécurisée : java.lang.ClassCastException: [Ljava.security.cert.X509Certificate; at SnoopServlet.doGet(SnoopServlet.java:68) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp. ... Any idea? Best regards Jérôme Jérôme
Re: stupid question on array return by javax.servlet.request.X509Certificateattribute
[EMAIL PROTECTED] wrote: Why the attribute 'javax.servlet.request.X509Certificate' return an array of X509Certificate. I don't understand how it's possible because when my client choose an certificate, he chooses only one... For my test array contain always one element... so is it an specification to anticipate the future ? The first element in the returned array will be the client certificate itself. However, if you acquired that certificate from a Certificate Authority (CA), the second element will be the certificate of the CA who vouches for the authenticity of the client certificate. If that CA is vouched for by someone else, ... the chain continues. That is why you need an array. Best Regards >>The type is javax.servlet.request.X509Certificate[] ?? ie an array not a >>single instance.. Craig McClanahan
Re: [MY_OPINION] Tomcat 3.x
on 12/18/2000 10:01 AM, "Greg Bailey" [EMAIL PROTECTED] wrote: As a use of Tomcat 3.1 on several production machines, may I say "thanks" also to Costin and everyone else who supports 3.1 (and 3.1.1, 3.2, 3.2.1, etc.) We are in no position to jump to 4.0 just because its trendy and has more "development activity"... Thanks again, -Greg Bailey I wish people would pay more attention to what the overall issues are instead of focusing on entirely the wrong things. That isn't what I was saying at all. The issue is the idea of a 3.3 and I'm not saying to "jump" to 4.0. Please look at all the information available to you about what is happening before commenting again. thanks, -jon
BugRat Report #614 has been filed.
Bug report #614 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/614 REPORT #614 Details. Project: Tomcat Category: Feature Requests SubCategory: New Feature Class: swbug State: received Priority: low Severity: non-critical Confidence: public Environment: Release: 3.2.1 JVM Release: 1.3 Operating System: win OS Release: 4 Platform: PC Synopsis: servlet-mapping Description: web.xml ! servlet-mapping servlet-namejsp/servlet-name url-pattern*.asx/url-pattern /servlet-mapping dosen't work can't execute the .asx (for exp.) Title: BugRat Report # 614 BugRat Report # 614 Project: Tomcat Release: 3.2.1 Category: Feature Requests SubCategory: New Feature Class: swbug State: received Priority: low Severity: non-critical Confidence: public Submitter: _Anonymous ([EMAIL PROTECTED]) Date Submitted: Dec 18 2000, 01:01:44 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: servlet-mapping Environment: (jvm, os, osrel, platform) 1.3, win, 4, PC Additional Environment Description: Report Description: web.xml ! jsp *.asx dosen't work can't execute the .asx (for exp.) How To Reproduce: null View this report online...
Re: [MY_OPINION] Tomcat 3.x
I don't agree. TC3.3 is a rewrite of TC3.2, with all of the TC4 "fancy features" (and some more). 3.3 is not a "rewrite" of 3.2 - some code was moved for better organization and modularity, and we finished a number of optimizations that were started during 3.2 development. Yes, a lot of code was rewriten ( cookies is a good example ) - but that's just a normal evolution of 3.2 - and the same happened after 3.1. Regarding the "fancy features" - 3.3 allows people to add any feature as a module, but the "core" is much simpler and feature-free than 3.2 ( or 4.0 ). In fact one of the goals of 3.3 refactoring was to make sure that all the "features" are modules ( examples: error handling, class loader hierarchy, jsp integration, servlet facade, etc ) AFAIK, there is no plan to get rid of / stop maitaining TC 3.2, and actually it's Craig who handles the 3.2 releases and maintenance releases (like 3.2.1), not Costin. Well, I must agree that this is a nice "political" spin. It seems suddenly the evolution of 3.2 to 3.3 ( identical with the evolution of 3.1 to 3.2 BTW) turns to be a "rewrite" or "fork" or "revolution". And 3.2.1 becomes the "evolution path" of 3.2. It also seems that improvements on 3.3 are "bad" because they take away resources from 4.0, and features that are ok to 4.0 are "featurism" if implemented as tomcat3.3 modules. I'm very happy to see Craig doing maintenance releases of 3.2 until 3.3 is ready ( and I hope that will happen in few months ). Please don't tell me that Craig is going to do major performance improvments in 3.2.2, or rewrite the cookie handling ( to corectly implement the specs), etc - so far it seems that he's ( rightly ) integrating bug fixes - that's what should happen on any maintainance release. ( and of course, he keeps forgeting the rules about release branches - that a patch in the release branch should be merged into the development branch ) It's a huge difference between maintaining a release and continuing ( and finishing ) development. Tomcat 3.2 is much better than 3.1 because of active development, and 3.3 will be better than 3.2.x because of the same reason - things that can't be done in 3.2.x ( and it doesn't seem to happen anyway ) As I said earlier, the reason we need 3.3 is that 3.2 has unfinished areas - the core refactoring started after 3.1 is the most important, performance is another ( and that's easy to check by comparing 3.3 with 3.2 as performance or by reading the core package ). Because of the available resources we choosed not to do maintainance releases of 3.1 unless a major bug/security issue is found, but try to have a major release (3.2) in a reasonable time. I think the same should happen with 3.3, and I'm working as hard as possible ( given the little free time I have ) to finish 3.3 development in a short time ( again - few months ). BTW, if I remember corectly the rules for tomcat developlment, after a feature freeze leading to a release, "development continues into the main branch, with only bug fixes going into the release branch". That's what I'm doing - continuing the development of tomcat3 into the main branch. The bug fixes that go into the release branch are great, but please stop spining that into something else. Costin __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
Re: [MY_OPINION] Tomcat 3.x
I wish people would pay more attention to what the overall issues are instead of focusing on entirely the wrong things. +1 on this The issue is the idea of a 3.3 and I'm not saying to "jump" to 4.0. I don't see how did you created a "3.3" issue - tomcat3.x development continues as it did before, and I don't remember 3.2 beeing an "issue" or anyone saying that 3.2 shouldn't have been developed. ( well, I remember something about that - but it seems that those who believed that were very wrong ) In fact, 3.3 doesn't even exist - when the development on the main branch of tomcat 3 will reach a stable state we can discuss about 3.3 , and you can argue that it's better or worse than 3.2 and we should ( or should not ) release it. Until that happens, TC3.3 refers to the version that is developmed out of tomcat 3 main branch - and you are welcomed to comment on any development that takes place and send your feedback about any commit. Those are the only real issues so far - if you are interested in 3.x future. Please look at all the information available to you about what is happening before commenting again. +1 again, jon Costin __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
Re: [MY_OPINION] Tomcat 3.x
on 12/18/2000 11:27 AM, "Costin Manolache" [EMAIL PROTECTED] wrote: In fact, 3.3 doesn't even exist - when the development on the main branch of tomcat 3 will reach a stable state we can discuss about 3.3 , and you can argue that it's better or worse than 3.2 and we should ( or should not ) release it. Until that happens, TC3.3 refers to the version that is developmed out of tomcat 3 main branch - and you are welcomed to comment on any development that takes place and send your feedback about any commit. Those are the only real issues so far - if you are interested in 3.x future. Right, but you are discussing 3.3 as being the future when you don't even know that is going to exist. That is wrong. Should I quote you? Costin said: Since I believe in a different future and direction, I'll spend the time to make mod_jk and tomcat3.2 ( and the future 3.3 ) work with Apache2.0. I'm +1 on 3.2.x continuing for however long we need it to in bug fix/minor enhancement mode. This should clear up Greg's posting confusion. As I said earlier, I would be strongly -1 on a 3.3. I'm +1 on Catalina becoming 4.0 and -1 on 3.x HEAD becoming 4.0. I'm +1 on considering what you are working on in the 3.x HEAD as becoming 4.5 or 5.0. In other words, I really want to see Catalina have a chance in the real world as a 4.0 release. If it does good, then I will vote strongly to follow that path for a while. If it does really badly, then I will evaluate 3.x HEAD again and consider that for a future direction. thanks, -jon -- Honk if you love peace and quiet.
RE: [MY_OPINION] Tomcat 3.x
-Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] on 12/18/2000 10:01 AM, "Greg Bailey" [EMAIL PROTECTED] wrote: As a use of Tomcat 3.1 on several production machines, may I say "thanks" also to Costin and everyone else who supports 3.1 (and 3.1.1, 3.2, 3.2.1, etc.) We are in no position to jump to 4.0 just because its trendy and has more "development activity"... Thanks again, -Greg Bailey I wish people would pay more attention to what the overall issues are instead of focusing on entirely the wrong things. That isn't what I was saying at all. The issue is the idea of a 3.3 and I'm not saying to "jump" to 4.0. Please look at all the information available to you about what is happening before commenting again. It really is part of the same issue. Because Greg is not willing to jump to 4.0, the idea of continuing development on the 3.x branch (work towards 3.3) is welcome and reassuring. There will likely be some issues with porting applications to 4.0 which can't be easily resolved. I see no problems with Costin (and others) continuing work on the 3.3 release, especially considering his recent comments about doing development on Tomcat with the Apache group: Costin said (quoting Jon): simply fork what you are doing into another project that is hosted somewhere else. It's the second time an Apache member is asking me to go somewhere else. Believe me, right now it's my biggest wish - I've had more than enough ! The way I see it, having Costin stopping work on the 3.x tree won't free up any substantial amount of resources for the 4.x tree. Costin doesn't seem to be planning on any future development on Tomcat after 3.3 is done! Either way, what does it matter if Costin is doing development work on the 3.x tree under Apache or under his own project? Frankly, I am disappointed in the development process of Tomcat. I posted a simple documentation patch (See bug report 528) two weeks ago for the FAQ included with the Tomcat 3.x and posted a couple messages about it. I haven't heard a thing about it and saw the release of 3.2.1 come and go without the documentation fix. -Dave
Re: [MY_OPINION] Tomcat 3.x
David Rees wrote: Frankly, I am disappointed in the development process of Tomcat. I posted a simple documentation patch (See bug report 528) two weeks ago for the FAQ included with the Tomcat 3.x and posted a couple messages about it. I haven't heard a thing about it and saw the release of 3.2.1 come and go without the documentation fix. The reason this occurred is that a significant security bug was found, warranting an *immediate* 3.2.1 release that bypassed the usual testing cycle that a beta should go through. This wasn't the only thing that didn't make it -- but security issues are serious and need to be dealt with. Normal processing of bug fixes and patches on the "tomcat_32" tree is now feasible for a 3.2.2 release. Hint: I am not the only committer on this project -- others are welcome to help integrate changes too. -Dave Craig
RE: WML Generation from JSP broken!!!!
Tom Reilly wrote, So here's my proposal: JSP 1.2 engines have mime type mappings like so (or something like this): *.jsp - application/jsp *.jspx - application/jsp-xml And documents of type application/jsp and application/jspx (or whatever names we decide on) are handled appropriately by default without any special web.xml constructs. This will also enable one to author a mime-type based servlet filter that can operate on JSP pages in a standard way. That sounds good to me ... One qualification: the current proposal on the table for XML MIME types is to use a '+xml' suffix (there are various complicated reasons why '+' is preferable to '-'). See, http://www.imc.org/draft-murata-xml So the XML JSP type ought to be, 'application/jsp+xml'. Cheers, Miles -- Miles Sabin InterX Internet Systems Architect5/6 Glenthorne Mews +44 (0)20 8817 4030 London, W6 0LJ, England [EMAIL PROTECTED] http://www.interx.com/
RE: [MY_OPINION] Tomcat 3.x
Jon ha escrito: Please look at all the information available to you about what is happening before commenting again. To give people a chance to get a personal opinion let's go to the REAL start of this thread, a interesting exercise ( at least for me ) http://marc.theaimsgroup.com/?l=tomcat-devm=86951938807358w=2 Have good trip into the past!!! ( almost exactly 1 year ago ) a quote from James D Davidson: " Given that this is a voluteer org, I think that we need to allow the revolutionaries to work on their stuff and let the evolutionaries work on their things and come up with a balance to let everyone work in the way in which they are comfortable. After all, it's stoopid to lock people out of doing what they want to since they are giving of their time and talent for free. " How can we reach the "balance" between TC3.3 TC4.0? Saludos , Ignacio J. Ortega
Re: [MY_OPINION] Tomcat 3.x
on 12/18/2000 11:47 AM, "David Rees" [EMAIL PROTECTED] wrote: It really is part of the same issue. Because Greg is not willing to jump to 4.0, the idea of continuing development on the 3.x branch (work towards 3.3) is welcome and reassuring. There will likely be some issues with porting applications to 4.0 which can't be easily resolved. There are no issues with porting to 4.0. I just took an app developed on 3.x and moved it to 4.0 without any problems. I see no problems with Costin (and others) continuing work on the 3.3 release, especially considering his recent comments about doing development on Tomcat with the Apache group: Costin said (quoting Jon): simply fork what you are doing into another project that is hosted somewhere else. It's the second time an Apache member is asking me to go somewhere else. Believe me, right now it's my biggest wish - I've had more than enough ! The way I see it, having Costin stopping work on the 3.x tree won't free up any substantial amount of resources for the 4.x tree. Costin doesn't seem to be planning on any future development on Tomcat after 3.3 is done! Ok, so great...3.3 is done and Costin disappears. What happens then? I wait around for someone else to pick up the effort while everyone else is working on and using 4.0? Either way, what does it matter if Costin is doing development work on the 3.x tree under Apache or under his own project? Because of the split of resources. Frankly, I am disappointed in the development process of Tomcat. I posted a simple documentation patch (See bug report 528) two weeks ago for the FAQ included with the Tomcat 3.x and posted a couple messages about it. I haven't heard a thing about it and saw the release of 3.2.1 come and go without the documentation fix. HELLO! DUHH! I think it is so funny that you mention this. Lets see, I see Craig and Remy constantly adding patches to Tomcat 4.0 as soon as they come in, but because we have this split of effort working on two tree's, your patches probably have gotten overlooked because people were way to busy working on the fact that we have a forked development tree. My point is that it is way to confusing for a volunteer organization to support this split tree like this and it needs to stop! Lastly, to add one more bit to the fire...Sun's position appears to follow Craig's at this point since he is the lead engineer on the J2EE Servlet Engine. What would you rather go with? The Engine that is part of J2EE or the engine that is a fork and worked on after work hours by essentially one guy? thanks, -jon -- Honk if you love peace and quiet.
BugRat Report #615 has been filed.
Bug report #615 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/615 REPORT #615 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Environment: Release: 3.2 JVM Release: IBM JDK 1.3 Operating System: Linux OS Release: Suse 6.4 Platform: Intel x86 Synopsis: Tomcat 3.2 reports 404 when submitting a jsp Description: I coded a jsp page (VirtualShop.jsp) like this: ... form method="post" action="ShoppingServlet?action=start" bCatalog Item:/b select name="catalogitem" % (java code) ... the servlet "ShoppingServlet.java" manages the doPost method and the extra information too (action=start). I'm using the MVC pattern: ... public void doPost(... ... String qs=req.getQueryString(); Hashtable qht=HttpUtils.parseQueryString(qs); ... req.getParameter("quantity"); ... Jsp and Servlet seem to work well standalone and together if i don't use any extra information (ex.: action=start). When there are some extra informations, Tomcat reports 404: It looks for the calling jsp page instead of the servlet "ShoppingServlet.class". Title: BugRat Report # 615 BugRat Report # 615 Project: Tomcat Release: 3.2 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Submitter: Gian Marco de Grimani ([EMAIL PROTECTED]) Date Submitted: Dec 18 2000, 02:17:00 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Tomcat 3.2 reports 404 when submitting a jsp Environment: (jvm, os, osrel, platform) IBM JDK 1.3, Linux, Suse 6.4, Intel x86 Additional Environment Description: Report Description: I coded a jsp page (VirtualShop.jsp) like this: ... Catalog Item: <% (java code) ... the servlet "ShoppingServlet.java" manages the doPost method and the extra information too (action=start). I'm using the MVC pattern: ... public void doPost(... ... String qs=req.getQueryString(); Hashtable qht=HttpUtils.parseQueryString(qs); ... req.getParameter("quantity"); ... Jsp and Servlet seem to work well standalone and together if i don't use any extra information (ex.: action=start). When there are some extra informations, Tomcat reports 404: It looks for the calling jsp page instead of the servlet "ShoppingServlet.class". View this report online...
RE: [MY_OPINION] Tomcat 3.x
Hi Craig, -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Frankly, I am disappointed in the development process of Tomcat. I posted a simple documentation patch (See bug report 528) two weeks ago for the FAQ included with the Tomcat 3.x and posted a couple messages about it. I haven't heard a thing about it and saw the release of 3.2.1 come and go without the documentation fix. The reason this occurred is that a significant security bug was found, warranting an *immediate* 3.2.1 release that bypassed the usual testing cycle that a beta should go through. This wasn't the only thing that didn't make it -- but security issues are serious and need to be dealt with. I understand why it didn't get through when I re-mentioned it right before the release, that is completely understandable. The problem as I see it is that the bug report was in BugRat for a week (in addition to a normal post to tomcat-dev) before Tomcat 3.2.1 was released; plenty of time IMHO for such a simple documentation patch to be committed. Normal processing of bug fixes and patches on the "tomcat_32" tree is now feasible for a 3.2.2 release. Hint: I am not the only committer on this project -- others are welcome to help integrate changes too. Right, I'm not about you specifically, Craig (I think you're doing good work on the 4.x tree and are usually very responsive on the tomcat-user/dev lists), but I really would have expected one of the committers to pick up the patch. I would just hate to see someone else pound their head against a wall for a few hours because of incorrect documentation. Anyway, slightly off-subject now. I'm curious to hear your reply to Jon's post. -Dave
Re: [MY_OPINION] Tomcat 3.x
Paul Frieden wrote: Not everybody is in a position to throw away their investment in the 3.x series just yet. Absolutely true. That's why I went back and did 3.2, because I totally understand this reasoning. Some people can't even get off 3.1 yet, because Costin changed so much in 3.2 :-). That's why I went back and did a 3.1.1 release for the security fixes there, along with a 3.2.1 fix for the current version. But that's not the real concern of this mail thread. The issue for TOMCAT-DEV is where should the Tomcat *developers* be spending the bulk of their time. While its fun to try the latest and greatest, not everybody can do that. Craig, is java.sun.com running on Tomcat 4.0? Not yet, although the static part of the java.sun.com site isn't really the target for a servlet container -- the various back-end application systems is where you will see it before the home page. Jon, is www.apache.org running Apache 2.0 yet? When do you think they will be ready to run those packages? Pretty soon. While this may be a "reference implementation," it is still being used in production environments. Production environments have very different requirements than development environments. Does Tomcat 3.x have bugs? Absolutely. But we've found those bugs in our QA environment, identified them, and worked around them as needed. Tomcat 4.0 will have a whole new set of bugs that we will need to spend time working around. We're still running our sites on 3.1, because we haven't had time to re-do the verification work with 3.2 yet. I'm just saying that while Tomcat 4.0 may have the most perfect design, it is un-proven in production environments. Tomcat 3.x has been proven for our application. Well, 3.1 has proven itself for you. You will find 3.2 has it's own flock of different bugs too. Same for "3.3" -- on the insides, each of these versions has had significant changes. We need to continue the 3.x tree at least until 4.0 is proven as ready. That takes time. 3.x has been brewing for a very long time. There have been lots of changes, but more has stayed the same than has changed. Tomcat 4.0 is almost entirely new code. We need something we can count on for production. Tomcat 4.0 isn't there yet. Anyone who's seen my posts over the last year knows that I recommend Tomcat 3.x (current released version, nowdays 3.2 series) for production use. Tomcat 4.0 is currently alpha code (although just about to start a beta cycle). The question at hand, though, relates to future significant enhancements (as opposed to just bug fixes, which I'm still willing to integrate in 3.2.x). You would find 3.2--3.3 to be just as in need of revalidation as 3.2--4.0, because it's not just a simple maintanenance fix to 3.2. Now, do we split the community's attention by devoting substantial development efforts to two tracks simultaneously, or do we focus most of the "big improvements" effort in one direction and do the required maintenance on the current production release? Because this is a volunteer organization, people can certainly choose to work on what they want -- but how are you going to feel if you spend a lot of time working on "3.3" but the TOMCAT-DEV community decides not to release it (given the proposed timing, it risks becoming irrelevant no matter how good or bad it might be)? Costin has stated several times that he prefers not to work on 4.0. That's his choice. For him, and the other folks that want to work on the "3.3" code base (I'm using quotes because there has been no formal discussion or vote on a plan to create it yet), they are free to do what they want with the code -- but if they want to release the finished work as "Tomcat", they've got to sell the TOMCAT-DEV community (i.e. the committers who have voting rights) on that plan. I also think that its appalling that people should tell Costin to go away. The Apache project should be very very thankful that they have somebody around to maintain the code that others have abandoned. Where would we be if the latest stable version of Apache was 1.3.0, and all the other developers had run off to work on 2.0? If that had happened, the Apache project would have been dismissed by everybody as a toy, and Apache wouldn't be in the position it is in today. Costin is to be thanked for all the efforts he has put in to get Tomcat from where it was at contribution time (October 99) into something that was usable. His efforts to improve performance along the way have proven to be quite successful as well. But, prospective "3.3" users should also be aware ... this time, if it ever did get released, I'm not going to be there to clean up Costin's bugs (as I had to do on both 3.1 and 3.2). I've got better things to do. By the way, Tomcat 4.0 will be the web container in the next release of the Java2 Enterprise Edition (J2EE) reference implementation. As such, it is receiving the benefit of extensive testing within
RE: [MY_OPINION] Tomcat 3.x
From: Jon Stevens [mailto:[EMAIL PROTECTED]] There are no issues with porting to 4.0. I just took an app developed on 3.x and moved it to 4.0 without any problems. Maybe for your app it ported over, but for others (specifically those working with XML and parsers other than the one bundled with Tomcat 4.x) do have problems with it. Realistically I expect most applications to port over without any changes, but I expect a handful to experience some problem related to this. Ok, so great...3.3 is done and Costin disappears. What happens then? I wait around for someone else to pick up the effort while everyone else is working on and using 4.0? No, Costin specifically said he'd be continuing maintenance and bug fixes on the 3.x tree after his refactoring is done. (Sorry, don't have his quote handy) Frankly, I am disappointed in the development process of Tomcat. I posted a simple documentation patch (See bug report 528) two weeks ago for the FAQ included with the Tomcat 3.x and posted a couple messages about it. I haven't heard a thing about it and saw the release of 3.2.1 come and go without the documentation fix. HELLO! DUHH! I think it is so funny that you mention this. Lets see, I see Craig and Remy constantly adding patches to Tomcat 4.0 as soon as they come in, but because we have this split of effort working on two tree's, your patches probably have gotten overlooked because people were way to busy working on the fact that we have a forked development tree. My point is that it is way to confusing for a volunteer organization to support this split tree like this and it needs to stop! Alright, you got me on this one. :-) Although I might point out that there seems to be at least one full time paid employee on the project. :-) -Dave
Re: [MY_OPINION] Tomcat 3.x
on 12/18/2000 12:40 PM, "David Rees" [EMAIL PROTECTED] wrote: Although I might point out that there seems to be at least one full time paid employee on the project. :-) -Dave Costin is not paid to work on this project. -jon
Re: [MY_OPINION] Tomcat 3.x
on 12/18/2000 12:20 AM, "Costin Manolache" [EMAIL PROTECTED] wrote: I don't see any need to go beyond 3.3 - and I said many times I'll stop doing any major changes in the core after 3.3 is done. I'll just fix bugs and develop modules - most of them in my private, non-apache space ( I'm talking about the servlet 2.3 implementation ). Ok, so you are going to stop at 3.3 and then what? Abandon things? Hope that others pick things up? Move to Catalina? What are you going to do? As for the future - in many open source projects good code does have a future - I hope the same will happen with tomcat. Tomcat 3.x or 4.x? That is the confusion that needs to be cleared up. Well, I don't see anything wrong in reusing good ideas from tomcat4.x in 3.x - it's in fact the first time I hear anyone saying it's bad. The point being that you are duplicating effort. The code is already in the future version and now you are back porting it to the past. Why is that good? It was one of the goals of tomcat3.x to be modular and allow people to add extensions without affecting the core - and almost all of 4.x can be back ported as tomcat3.x modules. Why is that effort good if people will be moving to 4.x anyway? If someone is doing that - people who use tomcat 3 will benefit, and that's good. When the future is 4.x? That's a great compliment for the design of tomcat3 ( unfortunately I can't take too much credit for this either ) - if only a single individual can do that it proves ( again ) that tomcat 3 is a great servlet container and gives me reason to keep working. Sure, it is good. I'm not doubting that fact. The reality though is that we are moving away from Tomcat 3.x to 4.x. Better design :-) ? Continuity ? In your opinion. I think tomcat 3.x has most of the features that I wanted - I would be happy to see 4.0 using the same patterns and design that allow high performance, but I don't have the time or wish to do it again. That you wanted. What about what other people want? What about what is good for the overall project? Your thinking is very singular. It's funny you're telling this as if I'm doing something wrong or forking - I strongly agree that forking is bad, and so far I did all I could to avoid forks ( i.e. I stoped developing the Servlet2.3 module as part of tomcat3.3, etc). Forking isn't bad. I never said that! In fact, I strongly believe in the ability to fork. Hell, look at the mess that I went through with Velocity! simply fork what you are doing into another project that is hosted somewhere else. It's the second time an Apache member is asking me to go somewhere else. Believe me, right now it's my biggest wish - I've had more than enough ! I will repeat myself again, since you didn't get it the first time. Sigh. My point being that having two tree's is to much for this project and as far as I can tell, this project has already decided that the current future path is 4.0 NOT 3.3. When 3.3 will be ready you are free to vote whatever you want - I just hope your vote will be based on the quality of the code and not political interests. Actually, it has nothing to do with either. Since I'm not involved with Sun's political crap, I don't care about political interests. I am also not as concerned with quality of the code because that can always be improved on, however, that is very important. What I'm most concerned with is things that are important to the overall project like: x Core Developer support x Ability to read the code x Documentation x Support for the latest standards What I'm most concerned with here is the overall Tomcat project goals and seeing you duplicating work and effort is really not making me happy. Reuse != duplication It is when you have to spend time back porting that code instead of committing David Rees's documentation patches. I know some people prefer the "do what we tell you to do or go away " or "we know what is better " attitude. That is complete bullshit Costin if you are implying that I am giving you that type of attitude. My original email made it CLEAR that that was not the case. Go back and read it again. I don't want to defend myself , and I'll take it as a compliment - I think it's great to be able to think for yourself and be able to work when there's an awful lot of pressure to go away. The pressure is to either ask you to fork or to work towards what the project as a whole is currently working on. I don't think that that is a bad thing because it helps keep the overall project working together instead of this split that you like to continually draw on the project. It appears to me that you simply care about yourself and not about the overall project. That is bad IMHO. My goal is to finish tomcat3.x - after I'm done with that I'll continue to support it, but I'll stay far away from any future development or 5.0 - again, I've had enough. That convinces me even stronger to not follow down
example case of my hell
Ok, so the primary developer of 3.x disappears and now I'm the one that gets stuck answering the tech support emails and can't even give a good answer? No way am I going to support any decision towards that. I don't think that very many of you realize the amount of privately send support email that I get on a daily basis for this stuff. It is around 20-30 email's day. -jon -- To: [EMAIL PROTECTED] Hello Jon, When trying to edit the adminContext in Tomcat 3.2.1 a message box appears asking for an Admin username and password. This didn't appear on version 3.1.1. I've scoured the available documentation to find it but failed. I need to add new contexts. Sorry if this has been covered somewhere else.
Re: [MY_OPINION] Tomcat 3.x
- Original Message - From: "Jon Stevens" [EMAIL PROTECTED] callous rant snipped I think Jon is going for the record to see how many developers and people of good conscience he can alienate. Costin, I appreciate all of the hard work you have done on the Tomcat project. You were pivotal in cleaning up a rat's nest of spaghetti that Sun dumped (graciously donated) on the group. I like Tomcat 4's design better, but it wasn't burdened with the luxury of legacy! Jon will be quick to add that he also appreciates the hard work, as he has done so often between derisions. Jon, maybe it's not the message but the tact. My personal impression of you is in the toilet now. Not that you care. jim
Re: [MY_OPINION] Tomcat 3.x
on 12/18/2000 1:36 PM, "James Cook" [EMAIL PROTECTED] wrote: I think Jon is going for the record to see how many developers and people of good conscience he can alienate. I thank you for your opinion. I'm sorry if people feel alienated as that isn't my intention. Costin, I appreciate all of the hard work you have done on the Tomcat project. You were pivotal in cleaning up a rat's nest of spaghetti that Sun dumped (graciously donated) on the group. Yea, luckily though Sun was smart enough to hire Craig. :-) I like Tomcat 4's design better, but it wasn't burdened with the luxury of legacy! Of course not. That is why I'm suggesting to move away from it for the future and opening the discussion of that now. Would you rather that we continue to follow down this path of split trees forever? Would you rather that all of our users are consistently confused? Jon will be quick to add that he also appreciates the hard work, as he has done so often between derisions. Jon, maybe it's not the message but the tact. My personal impression of you is in the toilet now. Not that you care. I have learned long and hard over the years that you just can't please everyone. It is a sad thing indeed. It is amazing to me how you guys can just sit back and actually think that what Costin is doing to the overall project and the users is a good thing! :-( So, given that no one else has an opinion about things until someone like me brings it up, I guess I'm always made out to be the bad guy. I can live with that simply because a year from now, we will have an even better product and even better project and this whole silly miff won't even matter to the people who are most interested in this software...the users. p.s. One thing that you are all not remembering or even realize is that Catalina was originally going to be JServ 2.0. If Sun had never given us the source code to Tomcat, then you would have been using Catalina anyway. thanks, -jon
RE: [MY_OPINION] Tomcat 3.x
Hi Jon, From: Jon Stevens [mailto:[EMAIL PROTECTED]] Of course not. That is why I'm suggesting to move away from it for the future and opening the discussion of that now. Would you rather that we continue to follow down this path of split trees forever? Would you rather that all of our users are consistently confused? I have learned long and hard over the years that you just can't please everyone. It is a sad thing indeed. It is amazing to me how you guys can just sit back and actually think that what Costin is doing to the overall project and the users is a good thing! :-( Another 2 cents from me... :-) Based upon your arguments I do agree that focusing development work on the 4.x tree is the way to go. After reading your message on "example case of my hell", I can see why you're keen on keeping the Tomcat tree in one piece. (Although you didn't quote the best example, as the problem that user was experiencing with the /admin context was part of tightening up the security holes in Tomcat, users are now forced to supply a username/password to gain access to the /admin context. Didn't Craig mention that in the release notes?) From my perspective, development (besides bug fixes) on the 3.x branch only makes sense as long as the 4.x branch isn't stable. But seeing as the 4.x branch is approaching beta-release phase, I would agree that the time to stop enhancements to the 3.x tree is rapidly approaching if not past already. As for what to do with the work done on the "3.3" release (which looks like it may be ready around the same time as the 4.0 release), forking it does not seem like a bad idea if only to save developers the support headaches. I'm sure that the committers will make the appropriate decision. -Dave
Re: [MY_OPINION] Tomcat 3.x
On Mon, 18 Dec 2000, Henri Gomez wrote: The users will decide. Be fair, let them evaluate TC 3.3. Speaking as a user, this doesn't make sense. It's fine to compare two different products, but it doesn't make any sense to compare two different versions of the same product that are undergoing simultaneous release cycles. Especially when you ask the list which you should be looking at, and you get one answer: "V3.3 because the architecture is better and V4 is an unstable rewrite," followed immediately by "V4 because the architecture is better and V3.3 is an unstable rewrite." The immediate reaction to which is, "if the *developers* can't even figure it out, I'm going elsewhere." I'm not saying you should cut off all 3.3 development, I just think it should fork and use a name other than "Tomcat". Maybe "xTomcat". :) Aaron
Re: OpenEJB
on 12/18/2000 1:18 PM, "dferugson" [EMAIL PROTECTED] wrote: Anybody know if tomcat is headed in the direction of being a full ejb app server? No, it isn't. www.ejboss.org is the right thing that you want and has integration with Tomcat. -jon -- Honk if you love peace and quiet.
Re: [MY_OPINION] Tomcat 3.x
David Rees wrote: Hi Craig, -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Frankly, I am disappointed in the development process of Tomcat. I posted a simple documentation patch (See bug report 528) two weeks ago for the FAQ included with the Tomcat 3.x and posted a couple messages about it. I haven't heard a thing about it and saw the release of 3.2.1 come and go without the documentation fix. The reason this occurred is that a significant security bug was found, warranting an *immediate* 3.2.1 release that bypassed the usual testing cycle that a beta should go through. This wasn't the only thing that didn't make it -- but security issues are serious and need to be dealt with. I understand why it didn't get through when I re-mentioned it right before the release, that is completely understandable. The problem as I see it is that the bug report was in BugRat for a week (in addition to a normal post to tomcat-dev) before Tomcat 3.2.1 was released; plenty of time IMHO for such a simple documentation patch to be committed. I'm glad you understood. A week would be plenty of time, except that: * All the active committers are spending most of their time on "3.3" or 4.0, not on 3.2. * I personally had some Sun deadlines (which required changes to the 4.0 code) totally blown away by the need to do the security updates, and I'm not caught up yet. (To their credit, Sun recognized the priority issues involved in security fixes.) Of course, these problems are fixable if we had more committers ... especially ones interested in applying bug fixes to the current production release to keep it stable and appropriate for production deployments. (NOTE: Anyone who receives committer status gets commit access on all branches of all the project's CVS repositories.) Normal processing of bug fixes and patches on the "tomcat_32" tree is now feasible for a 3.2.2 release. Hint: I am not the only committer on this project -- others are welcome to help integrate changes too. Right, I'm not about you specifically, Craig (I think you're doing good work on the 4.x tree and are usually very responsive on the tomcat-user/dev lists), but I really would have expected one of the committers to pick up the patch. I would just hate to see someone else pound their head against a wall for a few hours because of incorrect documentation. Anyway, slightly off-subject now. I'm curious to hear your reply to Jon's post. -Dave Craig
Re: [MY_OPINION] Tomcat 3.x
Henri Gomez wrote: [snip] Tomcat 3.x or 4.x? That is the confusion that needs to be cleared up. The confusion will exist also for Apache 1.3 / 2.0. And this one will be much more important. It's actually pretty clear in the web server case. The active development is happening on 2.0, and nobody's trying to create Apache 1.4. Craig
Re: Yogi (Berra, not Bear): It's deja vu all over again. :-)
Roy Wilson wrote: It's odd that Nacho suggested that a look at the thread he posted might be worthwhile. I've been lurking on this list for about 6 months (with an occasional attempt to contribute) and it seems like the TC3.x vs TC4 struggle is like a forest fire that keeps getting almost put out and then starts up again. Some issues are similar and some aren't. As a result, a day or two I asked Bill Middleton if I could get bulk access to the archives and do some semi-serious searching. He said that as far as he's concerned, the archive belongs to the developers, so I should post to the list and see if anyone has any heartburn. Does anyone? If I don't hear anything for a week, I'll assume it's a non-issue. You mean bulk access to the TOMCAT-DEV archives? Go for it ... anything posted here was *meant* to be seen by the Tomcat development community (including those interested in Tomcat's future as well as committers). Roy -- Roy Wilson E-mail: [EMAIL PROTECTED] Craig >> Original Message On 12/18/00, 3:10:06 PM, Nacho [EMAIL PROTECTED]> wrote regarding RE [MY_OPINION] Tomcat 3.x@2: > Jon ha escrito: > > Please look at all the information available to you about > > what is happening > > before commenting again. > To give people a chance to get a personal opinion let's go to the REAL > start of this thread, a interesting exercise ( at least for me ) > http://marc.theaimsgroup.com/?l=tomcat-devm=86951938807358w=2 > Have good trip into the past!!! ( almost exactly 1 year ago ) > a quote from James D Davidson: > " > Given that this is a voluteer org, I think that we need to allow the > revolutionaries to work on their stuff and let the evolutionaries work > on > their things and come up with a balance to let everyone work in the way > in > which they are comfortable. After all, it's stoopid to lock people out > of > doing what they want to since they are giving of their time and talent > for > free. > " > How can we reach the "balance" between TC3.3 TC4.0? > Saludos , > Ignacio J. Ortega
Re: [MY_OPINION] Tomcat 3.x
Hello, (another user here) If the difference were spoken as tc 3.x follows servlet 2.2/jsp 1.1 where tc 4.x follows servlet2.3/jsp 1.2, then it's a clear difference that I can appreciate, and even base decisions on. I decided to follow 3.2, as I felt that it was getting the most exercise then jserv, and other branches. So far, I haven't been too disappointed with my decision (although the mod_* situation isn't pleasant to sort out). I would, of course, prefer one kickass roadmap that has amazing developers focusing on non-duplicating efforts, _but_ I can easily appreciate a 3.x/4.x roadmap if it was followed up with, for example, the standards difference that I mentioned above. (Another technical split one could make is the release of jdk support, etc.). Of course, if there isn't a difference that makes sense to user, then I fallback to Aaron's thoughts. Thanks, Kenneth Topp On Mon, 18 Dec 2000, Aaron Mulder wrote: On Mon, 18 Dec 2000, Henri Gomez wrote: The users will decide. Be fair, let them evaluate TC 3.3. Speaking as a user, this doesn't make sense. It's fine to compare two different products, but it doesn't make any sense to compare two different versions of the same product that are undergoing simultaneous release cycles. Especially when you ask the list which you should be looking at, and you get one answer: "V3.3 because the architecture is better and V4 is an unstable rewrite," followed immediately by "V4 because the architecture is better and V3.3 is an unstable rewrite." The immediate reaction to which is, "if the *developers* can't even figure it out, I'm going elsewhere." I'm not saying you should cut off all 3.3 development, I just think it should fork and use a name other than "Tomcat". Maybe "xTomcat". :) Aaron
Re: [MY_OPINION] Tomcat 3.x
kenneth topp wrote: Hello, (another user here) If the difference were spoken as tc 3.x follows servlet 2.2/jsp 1.1 where tc 4.x follows servlet2.3/jsp 1.2, then it's a clear difference that I can appreciate, and even base decisions on. For any previous version change in the servlet api (2.0-2.1, 2.1-2.2), I would agree this makes a lot of difference. Each of these new versions had pretty significant impact on apps developed to the previous specs. With 2.3, the changes are evolutionary additions. However, there is also a new mandate -- a 2.3 servlet container is *required* to accept and run 2.2-based web apps. Therefore, it's relevant to evaluate a 2.3-based server, even if all you want to do is run your existing apps. (This applies to all 2.3 containers, not just Tomcat 4.0.) I decided to follow 3.2, as I felt that it was getting the most exercise then jserv, and other branches. So far, I haven't been too disappointed with my decision (although the mod_* situation isn't pleasant to sort out). 3.2 is the only rational choice for production apps at the moment. That will change pretty soon. I would, of course, prefer one kickass roadmap that has amazing developers focusing on non-duplicating efforts, _but_ I can easily appreciate a 3.x/4.x roadmap if it was followed up with, for example, the standards difference that I mentioned above. (Another technical split one could make is the release of jdk support, etc.). JDK support is actually a useful criteria in this case. Servlet 2.3 mandates a Java2 platform (which Tomcat 4.0 takes advantage of by using lots of JDK 1.2 or later classes). If you are running on a JDK 1.1 platform, Tomcat 4.0 (or any other Servlet 2.3 container) is not an option for you unless/until you upgrade. Of course, if there isn't a difference that makes sense to user, then I fallback to Aaron's thoughts. Thanks, Kenneth Topp Craig McClanahan
Re: [MY_OPINION] Tomcat 3.x
On Mon, 18 Dec 2000, Jon Stevens wrote: p.s. One thing that you are all not remembering or even realize is that Catalina was originally going to be JServ 2.0. If Sun had never given us the source code to Tomcat, then you would have been using Catalina anyway. I hope EVERYONE takes what Jon (oddly, so offhandedly) put in the PS to heart right now. This, gentlemen, is the record of history; and as far as I'm concerned, the final word on this thread. Look at the bugs in BugRat. The ones coming in for 4.0 are getting linked, documented and closed faster than the ones coming in for 3.x. The bugs for 4.0 are fewer than the ones coming in for 3.x. Shit, I think we've even got some 3.0's in there that haven't been dealt with! As far as those of you committing to the 3.x branch today, think about this: Your efforts are sorely needed in the 4.0 tree, right here, right now, today. I have read the code in the 3.x tree. It's shaping up nicely, true, but after reading 3.1 for about 2 days, I got so depressed about the project I thought I was going to blow my head off. To find even where the request comes in I found I had to grep for a "ServerSocket" and drill from there! When I look at 4.0, I can actually READ that code and understand it. There's a lot more to writing code whose source was meant to be publically consumed that is not evident in the writing of the 3.x tree. In short, 4.0 is the right code for the right project at the right time. -jon -- Nicolaus Bauman (The guy who runs BugRat for Jakarta)
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Embedded.java
craigmcc00/12/18 19:23:12 Modified:catalina/src/share/org/apache/catalina Engine.java catalina/src/share/org/apache/catalina/startup Embedded.java Log: Enhance the example main() method in the Embedded class so that it will actually run. The "/examples" webapp does not work without a Realm defined. Add get/setDefaultHost() to the Engine interface, not just the StandardEngine implementation class. Revision ChangesPath 1.2 +21 -4 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Engine.java Index: Engine.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Engine.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- Engine.java 2000/08/11 05:24:06 1.1 +++ Engine.java 2000/12/19 03:23:11 1.2 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Engine.java,v 1.1 2000/08/11 05:24:06 craigmcc Exp $ - * $Revision: 1.1 $ - * $Date: 2000/08/11 05:24:06 $ + * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Engine.java,v 1.2 2000/12/19 03:23:11 craigmcc Exp $ + * $Revision: 1.2 $ + * $Date: 2000/12/19 03:23:11 $ * * * @@ -88,10 +88,27 @@ * should throw codeIllegalArgumentException/code. * * @author Craig R. McClanahan - * @version $Revision: 1.1 $ $Date: 2000/08/11 05:24:06 $ + * @version $Revision: 1.2 $ $Date: 2000/12/19 03:23:11 $ */ public interface Engine extends Container { + + +// - Properties + + +/** + * Return the default hostname for this Engine. + */ +public String getDefaultHost(); + + +/** + * Set the default hostname for this Engine. + * + * @param defaultHost The new default host + */ +public void setDefaultHost(String defaultHost); // - Public Methods 1.7 +8 -5 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Embedded.java Index: Embedded.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Embedded.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- Embedded.java 2000/12/14 22:32:19 1.6 +++ Embedded.java 2000/12/19 03:23:12 1.7 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Embedded.java,v 1.6 2000/12/14 22:32:19 craigmcc Exp $ - * $Revision: 1.6 $ - * $Date: 2000/12/14 22:32:19 $ + * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Embedded.java,v 1.7 2000/12/19 03:23:12 craigmcc Exp $ + * $Revision: 1.7 $ + * $Date: 2000/12/19 03:23:12 $ * * * @@ -90,6 +90,7 @@ import org.apache.catalina.logger.FileLogger; import org.apache.catalina.logger.SystemOutLogger; import org.apache.catalina.net.SSLServerSocketFactory; +import org.apache.catalina.realm.MemoryRealm; import org.apache.catalina.util.LifecycleSupport; import org.apache.catalina.util.StringManager; @@ -147,7 +148,7 @@ * /pre * * @author Craig R. McClanahan - * @version $Revision: 1.6 $ $Date: 2000/12/14 22:32:19 $ + * @version $Revision: 1.7 $ $Date: 2000/12/19 03:23:12 $ */ public class Embedded implements Lifecycle { @@ -999,7 +1000,8 @@ */ public static void main(String args[]) { - Embedded embedded = new Embedded(); + Embedded embedded = new Embedded(new SystemOutLogger(), + new MemoryRealm()); embedded.setDebug(5); embedded.setLogger(new SystemOutLogger()); String home = System.getProperty("catalina.home"); @@ -1017,6 +1019,7 @@ // that simulates a portion of the one configured in server.xml // by default Engine engine = embedded.createEngine(); + engine.setDefaultHost("localhost"); Host host = embedded.createHost("localhost", home + "/webapps"); engine.addChild(host);
Re: VOTE: new commiter: Petr Jiricka
+1 Costin Manolache wrote: Hi again. Please vote for adding Petr Jiricka ( [EMAIL PROTECTED] ) to the list of official commiters. He fixed a big number of bugs in JSP and contributed many ideas in this area - including debugging, etc. He has my +1 Costin ( I still use xemacs :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: FreeBSD jdk 1.2.2 alpha and Tomcat
I also use FreeBSD and jdk1.2.2 at home (an early version of the hand built port). It works just fine for Tomcat RD at home, don't know about production. And I also have heard about GUI problems. Edward Wolpert wrote: I've got FBSD at home, and been trying to test the 1.2.2 port myself. Currently, the FreeBSD port of Java 1.2.2 is only alpha quality. It seems like it's still slow going. (Mostly, problems seem to be on the GUI end, but there needs to be more thread work done, IMO) Also, There is no Java 1.2 package for FreeBSD yet that can be distributed it can only be built from the patches. Jim Driscoll wrote: Jim Wise wrote: I currently maintain the Tomcat (and JServ, and Cocoon) package distributions for the NetBSD operating system. While we certainly hope to benefit from BSDI's actions as a go-between for Sun and the BSD community, people wishing to distribute JVM's for a number of other OS environments are still stuck with 1.1.8. Hi. I'm new here, so please forgive me if this has been covered before, but what OS's, specifically, do you mean with this? I had thought that most either had 1.2, or were on the cusp (it's arguable that NetBSD could even be considered "on the cusp", as the port from FreeBSD to NetBSD shouldn't be a big deal). Just interested in an actual list. -- Virtually, Edward Wolpert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --