Re: [MY_OPINION] Tomcat 3.x

2000-12-18 Thread Costin Manolache

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.

2000-12-18 Thread BugRat Mail System

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

2000-12-18 Thread Hanusch, Hartwig

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)

2000-12-18 Thread jerome . camilleri



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.

2000-12-18 Thread BugRat Mail System

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

2000-12-18 Thread Nacho

I definitely agree with Henry  Costin... 


Saludos ,
Ignacio J. Ortega





Re: jsp - html speedup

2000-12-18 Thread Pierre Delisle


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

2000-12-18 Thread kelfen

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

2000-12-18 Thread Robert Oschwald




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

2000-12-18 Thread GOMEZ Henri

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

2000-12-18 Thread GOMEZ Henri

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)

2000-12-18 Thread Nacho

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)

2000-12-18 Thread shai

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)

2000-12-18 Thread Alexandre Augusto Drummond Barroso

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!

2000-12-18 Thread Hanusch, Hartwig

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

2000-12-18 Thread jerome . camilleri



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

2000-12-18 Thread Jonathan Pierce

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.

2000-12-18 Thread BugRat Mail System

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

2000-12-18 Thread Costin Manolache

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

2000-12-18 Thread Paul Frieden

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

2000-12-18 Thread Remy Maucherat

 * 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

2000-12-18 Thread rbb


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!!!!

2000-12-18 Thread Tom Reilly


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

2000-12-18 Thread Stefán F. Stefánsson

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

2000-12-18 Thread Craig R. McClanahan


[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

2000-12-18 Thread Jon Stevens

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.

2000-12-18 Thread BugRat Mail System

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

2000-12-18 Thread Costin Manolache

 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

2000-12-18 Thread Costin Manolache


 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

2000-12-18 Thread Jon Stevens

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

2000-12-18 Thread David Rees

 -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

2000-12-18 Thread Craig R. McClanahan

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!!!!

2000-12-18 Thread Miles Sabin

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

2000-12-18 Thread Nacho

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

2000-12-18 Thread Jon Stevens

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.

2000-12-18 Thread BugRat Mail System

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

2000-12-18 Thread David Rees

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

2000-12-18 Thread Craig R. McClanahan

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

2000-12-18 Thread David Rees

 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

2000-12-18 Thread Jon Stevens

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

2000-12-18 Thread Jon Stevens

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

2000-12-18 Thread Jon Stevens

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

2000-12-18 Thread James Cook

- 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

2000-12-18 Thread Jon Stevens

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

2000-12-18 Thread David Rees

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

2000-12-18 Thread Aaron Mulder

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

2000-12-18 Thread Jon Stevens

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

2000-12-18 Thread Craig R. McClanahan

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

2000-12-18 Thread Craig R. McClanahan

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. :-)

2000-12-18 Thread Craig R. McClanahan


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

2000-12-18 Thread kenneth topp


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

2000-12-18 Thread Craig R. McClanahan

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

2000-12-18 Thread Nick Bauman

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

2000-12-18 Thread craigmcc

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

2000-12-18 Thread Glenn Nielsen

+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

2000-12-18 Thread Glenn Nielsen

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  |  */   |
--