Re: Minimal server.xml

[Bob Herrmann]

I am +1 on this as well.

Again, I recommend removing the Logging tag.  Tomcat's ability to log to
many different places (Rolling logs for each web applications, etc...)
is a good thing for an enterprise product, but most newbies just want to
see the stack trace that corresponds with an error page they just saw. 
Without any Logging tags, all messages go to catalina.out just like the
start up message says.

Cheers,
-bob

On Wed, 2003-12-03 at 07:43, Remy Maucherat wrote:
> Dan Johnsson wrote:
> > +1
> > 
> > I would even suggest distribute something like this as the ordinary 
> > server.xml, and rename the other as server-examples.xml.
> > 
> > Why? I do most of my tomcat-work with "initial" users, i e either 
> > students taking classes or people doing their first installation. They 
> > are not helped by the "rich" server.xml as they do not yet grasp all the 
> > concepts. To them it would be a lot better to start with a small 
> > server.xml and then add features as they understand them.
> > 
> > And the power-users? Well, they usually think the server.xml is 
> > cluttered with all those examples they already understand.
> > 
> > So examples are great, but I think they should be elsewhere than in the 
> > production config file.
> 
> This does sound like vallid points.
> 
> However, we would have to add an AJP connector to the mix so that the 
> "minimal" config is out of the box compatible with the current default 
> config.
> We would need a realm as well.
> 
> Rémy
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Minimal server.xml

[Bob Herrmann]

Sounds like a good idea to me.  I would recommend removing the "Logger"
and just letting the output go into catalina.out

-bob

On Tue, 2003-12-02 at 12:18, Shapira, Yoav wrote:
> Hi,
> IMHO the server.xml that comes with tomcat by default
> ($CATALINA_HOME/conf/server.xml) is nice in that it provides many
> comments and examples.  But I think power users would appreciate a
> minimal version as well, so I've created one, as shown below.  Should we
> distribute something like this, perhaps as
> $CATALINA_HOME/conf/server-minimal.xml?
> 
> 
>   
> maxThreads="150" minSpareThreads="1" maxSpareThreads="75"
>enableLookups="false" redirectPort="8443"
> acceptCount="100"
>debug="0" connectionTimeout="2" 
>disableUploadTimeout="true" />
> 
> 
>  prefix="catalina_log." suffix=".txt"
>   timestamp="true"/>
> 
>   unpackWARs="true" autoDeploy="true"
>xmlValidation="false" xmlNamespaceAware="false">
>   directory="logs"  prefix="localhost_log." suffix=".txt"
> timestamp="true"/>
> 
>   
> 
> 
> 
>   
> 
> 
> 
> 
> Yoav Shapira
> Millennium ChemInformatics
> 
> 
> 
> 
> 
> This e-mail, including any attachments, is a confidential business communication, 
> and may contain information that is confidential, proprietary and/or privileged.  
> This e-mail is intended only for the individual(s) to whom it is addressed, and may 
> not be saved, copied, printed, disclosed or used by anyone else.  If you are not 
> the(an) intended recipient, please immediately delete this e-mail from your computer 
> system and notify the sender.  Thank you.
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] New committer: Mark Thomas

[Bob Herrmann]

Sure,
+1

> Hi,
>
> I'd like to nominate Mark Thomas as a Tomcat committer. He has
> contibuted a significant amount of fixes already, and does what nobody
> else does: roam Bugzila to fix older issues and cleanup the database. He
>  has special interest in the WebDAV code, which currently has no
> maintainer.
>
> He has my +1.
>
> Rémy
>
>
>
> - To
> unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is exact flow explained anywhere ?

[Bob Herrmann]

No, I don't think there is any such documentation of Tomcat's exact
flow.  It would be handy to have somethat describes Tomcat's "Process of
getting into the stead state."   And something that describes the
"Process of handling an incoming request."  but as far as I know, these
things are locked up in peoples heads.

The best guide is the website's docs.  And knowing that the server.xml
is really Tomcat's back bone.  It describes which implementations get
hooked together at start up time.  

Cheers,
-bob

On Wed, 2003-11-19 at 06:07, Akhilesh Suresh Shirbhate wrote:
> Hi guys,
> 
> I am into hacking the Tomcat code recently. I have read most of the 
> code but I am not able to figure out where exactly is the Manager 
> (ManagerBase or StandardManager) comes into picture in the whole flow.
> Is there a proper document which actually explains what exactly happens
> when a request comes to Coyote and is then forwarded to the container thru 
> many phases like the EngineMapper, etc. Thanx in advance for the help to 
> be recieved.
> 
> Regards,
> Akhilesh.
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New to dev list

[Bob Herrmann]

On Thu, 2003-10-23 at 11:37, [EMAIL PROTECTED] wrote:
> Thanks, Bob. The presentation is good. Does Tomcat have design document? So I can 
> dig deeper to source code level.

I don't believe that it does.   This does seem to be a deficiency.  The
phrase "Use the Source Luke", springs to mind...  You can also peruse
the "documentation" section of the Tomcat site and pick up some things.

http://jakarta.apache.org/tomcat/

Perhaps a simple description of how Tomcat gets up and going will help.

The highly abridged version of things goes like this;

1. Some one starts the JavaVM with a bunch of options (usually via the
"startup" script.)

2. A bootstrap thing starts figuring out where things are and loading
some initial classes

3. The bootstrapper uses  the "Digester" to 'execute' the server.xml and
web.xml files.What is important to understand here is; Tomcat is a
collection of interfaces with some handy "Standard implementations." 
When the default server.xml is used, a bunch of 'Standard
implementations' are wired together and started (using some Lifecycle
interfaces to ensure everything starts in the right order.)   

So basically, Tomcat is a loose connection of components that implement
interfaces for "Connections to the Network, Session handling, Logging,
Valves, etc.."  You can implement your own versions or use the standard
versions.  To use your own, you only need to put the classes in the
"server/classes" directory and modify the server.xml to use your own
implementation.

Thus understanding how Tomcat works is broken down into understanding
the individual pieces and their interfaces (or contracts) 

Hopefully this helps.

Cheers,
-bob

> 
> > 
> > From: Bob Herrmann <[EMAIL PROTECTED]>
> > Date: 2003/10/23 Thu AM 01:18:12 EDT
> > To: Tomcat Developers List <[EMAIL PROTECTED]>
> > Subject: Re: new to dev list
> > 
> > Jamesmyang3 writes:
> > > I am new to this development list. I download tomcat source
> > > code and try to compile and run it. Can anyone provide me
> > > some information on how Tomcat is designed? 
> > 
> > The best I could ever find is a PDF of a presentation that
> > Craig McClanahan made back in June of 2000.  Look for "Tomcat Servlet"
> > in this page;
> > 
> > http://servlet.java.sun.com/javaone/conf/bofs/1290/google-sf2001.jsp
> > 
> > The pdf is free, but they seem to want to charge for the audio.
> > 
> > Cheers,
> > -bob
> > 
> > 
> > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> 
> 1
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: new to dev list

[Bob Herrmann]

Jamesmyang3 writes:
> I am new to this development list. I download tomcat source
> code and try to compile and run it. Can anyone provide me
> some information on how Tomcat is designed? 

The best I could ever find is a PDF of a presentation that
Craig McClanahan made back in June of 2000.  Look for "Tomcat Servlet"
in this page;

http://servlet.java.sun.com/javaone/conf/bofs/1290/google-sf2001.jsp

The pdf is free, but they seem to want to charge for the audio.

Cheers,
-bob





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Client-cert authentication.

[Bob Herrmann]

On Wed, 2002-11-06 at 10:55, Moisés Serrano Martínez wrote:
> Thanks a lot Bob and Jean-frederic for the response but I´m afraid I don´t
> understand clearly the solution:


As I understand it, Tomcat uses a keystore and a truststore.

Tomcat uses the keystore to answer the client's "who are you?" question.
The answer (Who is this Tomcat server) is retrieved from the keystore. 
(I am a trusted Tomcat server for Acme corp, my certificate is signed by
some central authority.)

The truststore is used when Tomcat wants to verify who the client is,
"Do I trust this client?" (Should this client really be allowed to
access this site?)  Tomcat only asks this, or verifies the client, if
the Connector has clientauth=true  **OR**  if a resource is marked up in
the web.xml as requiring CLIENT-CERT

The keystore can be set in the server.xml.  The truststore must be set
using the JDK's property files or via an environment variable (like I
mentioned in my earlier email.)  This is a tad kludgy because verifying
the certs of the client seem to be fairly rare in practice.  (I imagine
this is because verifying the client certs is something B2B requires and
not so much needed by the casual JSP developer.)

Cheers,
-bob



> 
> As far as I know,  when I configure the server.xml of the Tomcat/conf
> directory in order to use the keystore where I´ve imported the trusted certs
> of the chain
> I thought I was saying tomcat that the keystore for the authentication was
> that, and it wasn´t necesary to configure another trusted keystore.
> 
>  clientAuth="false" keystoreFile="C:\Documents and
> Settings\mserrano\.jbuilder4\Claves\CA_almacen\ca\server.keystore"
> keystorePass="396947j" protocol="TLS" algorithm="SunX509"
> keystoreType="JKS"/>
> 
> Is necesary to configure both keystores?
> Thanks again, and sorry for my question if it´s something clear for
> everyone.
> 
> - Original Message -
> From: "Bob Herrmann" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> Sent: Tuesday, November 05, 2002 9:58 PM
> Subject: Re: Client-cert authentication.
> 
> 
> >
> > As someone else already pointed out, you need to configure the trust
> > stores (Which tell tomcat what clients to trust.) You can do that by
> > changing some config files, or like this on the command line (with
> > redhat)
> >
> > export CATALINA_OPTS="-Djavax.net.ssl.trustStore=/home/bob/cacerts.jks
> > -Djavax.net.ssl.trustStorePassword=changeit"
> >
> > Cheers,
> > -bob
> >
> >
> >
> > export CATALINA
> > -Djavax.net.ssl.trustStore=/home/bob/issues/ssl/cacerts.jks
> > -Djavax.net.ssl.trustStorePassword=changeit
> >
> > On Tue, 2002-11-05 at 11:35, Moisés Serrano Martínez wrote:
> > > I´ve a small (or big) problem configuring Tomcat 4.1.12.
> > >
> > > Does anyone know how to configure the client side of the matter?
> > >
> > > What I have done is :
> > >
> > > 1) Create a selfsigned certificate (master certificate).
> > > 2) With the master create another one intemediate for localhost (signed
> with the private key of the master one)
> > > - Import the chain into a keystore: server.keystore ( the master
> and localhost, this last one with the private key)
> > > 3) With the localhost certificate create a user certificate (signed with
> the private key of localhost).
> > > - Import the user certificate into the server.keystore.
> > > 4) Import the chain into a keystore: server.keystore
> > >-  At  this point all must be ok because the server
> authentication works perfectly, when a client try to connect to localhost.
> > > 5) Configure the server.xml:
> > > - Define a SSL Coyote HTTP/1.1 Connector on port 8443:
> > >
> > >  className="org.apache.coyote.tomcat4.CoyoteConnector" port="8443"
> minProcessors="5" maxProcessors="75" enableLookups="true" acceptCount="10"
> debug="3" scheme="https" secure="true" useURIValidationHack="false">
> > >
> > > - Locate the keystore inside the factory,
> CoyoteServerSocketFactory, with clientAuth="false".
> > >  className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory"
> clientAuth="false" keystoreFile="C:\Documents and
> Settings\mserrano\.jbuilder4\Claves\CA_almacen\ca\server.keystore"
> keystorePass="396947j" protocol="TLS&qu

Re: cvs commit:jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/coreStandardWrapper.java

[Bob Herrmann]

On Wed, 2002-11-06 at 06:55, Tim Funk wrote:
> In case you weren't joking ...
> 
> It can easily break compatibility if someone introduces a new class with 
> the same class name as another class in a different package.


IMHO, the more important reason to not use "import xx.*" is because it
is harder for a developer to figure out where a class is coming from... 
So I see it as a code readability issue.

Cheers,
-bob

> 
> ex:
> import foo.*; /* has class A */
> import bar.*; /* has class B */
> 
> class Foo {
>  A a;
>  B b;
> }
> 
> Imagine time going by and another developer creates another class called 
> A in the bar package. The code above will not recompile because of the 
> abiguous class name.
> 
> -Tim
> 
> 
> Costin Manolache wrote:
> > BTW - what's evil in import * ? I never understood.
> > 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Client-cert and POST

[Bob Herrmann]

I have been snooping around this problem with client-cert and POSTs for
quite a while now.  I have a patch that fixes it, but I really don't
like my own work.

This topic has raised it's ugly head a few times already here on
Tomcat-dev, but allow me to restate it (yet again... hopefully with more
clarity)

Clients can POST data to Tomcat.  They can do this on a secure socket. 
Tomcat can be configured to protect resources from the client based on
the clients Certificates.  So, a client can be POSTing data to a secure
resource and tomcat may not yet have gotten the Certificates it needs. 
HERE IS WHERE STUFF GETS TRICKY (could I be wrong?) The certificate
exchange can only happen once the POST data is removed from the socket. 
I talked with someone who implemented an SSL stack and he said that this
is the way the protocol is.  Boo.   So in order to support work
correctly, Tomcat must hold onto this POST until it is done, then
certify the client, then proceed or bail.  Messy messy.

I tweaked Tomcat5 Coyote to do this.  

It works by changing CoyoteRequest to change the InputStream to a
Buffered InputStream when a POST and an SSL Certrequest happen.

What do you think?

Cheers,
-bob


Index: CoyoteRequest.java
===
RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java,v
retrieving revision 1.6
diff -u -r1.6 CoyoteRequest.java
--- CoyoteRequest.java	18 Oct 2002 21:37:08 -	1.6
+++ CoyoteRequest.java	5 Nov 2002 21:25:45 -
@@ -377,7 +377,10 @@
 pathInfo = null;
 servletPath = null;
 reader = null;
-inputStream.recycle();
+if (inputStream instanceof CoyoteBufferedInputStream )
+inputStream = new CoyoteInputStream();
+else
+inputStream.recycle();
 userPrincipal = null;
 sessionParsed = false;
 authorization = null;
@@ -783,6 +786,22 @@
 return attr;
 // XXX Should move to Globals
 if(Constants.SSL_CERTIFICATE_ATTR.equals(name)) {
+if ( "POST".equalsIgnoreCase(getMethod()) ){
+String contentType = getContentType();
+if (contentType == null)
+contentType = "";
+int semicolon = contentType.indexOf(';');
+if (semicolon >= 0) {
+contentType = contentType.substring(0, semicolon).trim();
+} else {
+contentType = contentType.trim();
+}
+
+if (("application/x-www-form-urlencoded".equals(contentType)))
+parseRequestParameters();
+else
+inputStream = new CoyoteBufferedInputStream( this );
+}
 coyoteRequest.action(ActionCode.ACTION_REQ_SSL_CERTIFICATE, null);
 attr = getAttribute(Globals.CERTIFICATES_ATTR);
 if(attr != null)

/*
 * 
 * 
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 1999 The Apache Software Foundation.  All rights 
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer. 
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The end-user documentation included with the redistribution, if
 *any, must include the following acknowlegement:  
 *   "This product includes software developed by the 
 *Apache Software Foundation (http://www.apache.org/)."
 *Alternately, this acknowlegement may appear in the software itself,
 *if and wherever such third-party acknowlegements normally appear.
 *
 * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
 *Foundation" must not be used to endorse or promote products derived
 *from this software without prior written permission. For written 
 *permission, please contact [EMAIL PROTECTED]
 *
 * 5. Products derived from this software may not be called "Apache"
 *nor may "Apache" appear in their names without prior written
 *permission of the Apache Group.
 *
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT O

Re: Client-cert authentication.

[Bob Herrmann]

at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:543)
> at org.apache.coyote.Response.action(Response.java:216)
> at 
>org.apache.coyote.tomcat4.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:314)
> at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:221)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:405)
> at 
>org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:380)
> at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:508)
> at 
>org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:533)
> at java.lang.Thread.run(Thread.java:484)
> [WARN] Http11Processor - -Exception getting SSL attributes  
>
> javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
> at 
>com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificateChain(DashoA6275)
> at 
>org.apache.tomcat.util.net.JSSESupport.getPeerCertificateChain(JSSESupport.java:118)
> at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:567)
> at org.apache.coyote.Request.action(Request.java:367)
> at 
>org.apache.coyote.tomcat4.CoyoteRequest.getAttribute(CoyoteRequest.java:797)
> at 
>org.apache.coyote.tomcat4.CoyoteRequestFacade.getAttribute(CoyoteRequestFacade.java:141)
> at 
>org.apache.catalina.authenticator.SSLAuthenticator.authenticate(SSLAuthenticator.java:154)
> at 
>org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
> at 
>org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
> at 
>org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
> at 
>org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
> at 
>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2396)
> at 
>org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
> at 
>org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
> at 
>org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
> at 
>org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
> at 
>org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
> at 
>org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
> at 
>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at 
>org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
> at 
>org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
> at 
>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:405)
> at 
>org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:380)
> at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:508)
> at 
>org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:533)
> at java.lang.Thread.run(Thread.java:484)
> [WARN] Http11Processor - -Exception getting SSL Cert 
>
> 
> 
> 
> 
> Please  I´ve been trying to solve this problem for days and I am desperate. 
> 
> Thanks a lot in advance.
> 
> Moises
-- 
Bob Herrmann <[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>

Re: [5.0] New build documentation, docs online

[Bob Herrmann]

On Mon, 2002-10-28 at 05:07, Remy Maucherat wrote:
> New Tomcat 5.0 docs online (linked from the main Tomcat page):
> http://jakarta.apache.org/tomcat/tomcat-5.0-doc/index.html
> 
> New building documentation:
> http://jakarta.apache.org/tomcat/tomcat-5.0-doc/BUILDING.txt
> 
> Comments ?

Humm...  I used JDK1.4.x and I have clean built several times, but I
never had to download Xerces.  Does JDK1.4 or ant include Xerces or
something?  I think the Xerces step maybe optional with JDK1.4.

Cheers,
-bob 


> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [5.0] New build documentation, docs online

[Bob Herrmann]

On Mon, 2002-10-28 at 07:04, IAS wrote:
> There were actually several stops due to the internet disconnection, and
> I failed because of javamail's absence, which build.xml didn't check
> out. 

Yea, the SendMail... example always busts on when I compile also.  I
always do this (reflexively),

echo>/home/bobh/t5/jakarta-servletapi-5/jsr152/examples/WEB-INF/classes/SendMailServlet.java

Then everything compiles fine.  There really should be a check for this
in the servletapi build.xml  I should submit a patch... 

Cheers,
-bob

> I put javamail configuration to build.properties like this:
> # - Java Mail, version 1.2 or later -
> mail.home=${base.path}/javamail-1.3
> mail.lib=${mail.home}
> mail.jar=${mail.lib}/mailapi.jar
> With the above addition, I also copied a javamail jar to javamail-1.3
> directory. After this treatment, I succeeded in building Tomcat 5.
> 
> As of its running, the document (running.txt) says it requires JDK 1.2
> or later. I tested webapps/ROOT/index.jsp with the following
> modification:
> (the number in left-side is line number for convenience of
> presentation.)
> 0 :  http://www.w3.org/TR/REC-html40/strict.dtd";>
> 1 : <%
> 2 :   out.printlx("aa");
> 3 : %>
> ...
> 
> The invocation of this page resulted in the below:
> org.apache.jasper.JasperException: Unable to compile class for JSP
> 
> An error occurred at line: 1 in the jsp file: /index.jsp
>---
> ...
> \build\work\Standalone\localhost\_\index_jsp.java:51: cannot resolve
> symbol
> symbol  : method printlx (java.lang.String)
> location: class javax.servlet.jsp.JspWriter
>   out.printlx("aa");
>^
> 1 error
> 
> The exact line causing an error in JSP is 2, and it is not compliant
> with JSP 2.0's debugging support. Moreover,
> 0 :  http://www.w3.org/TR/REC-html40/strict.dtd";>
> 1 : <%
> 2 :   out.println("aa");
> 3 :   out.printlx("aa");
> 4 : %>
> ...
> also displayed the same result in terms of JSP line:
> An error occurred at line: 1 in the jsp file: /index.jsp
> ...
> \build\work\Standalone\localhost\_\index_jsp.java:52: cannot resolve
> symbol
> symbol  : method printlx (java.lang.String)
> location: class javax.servlet.jsp.JspWriter
>   out.printlx("aa");
>^
> 1 error
> 
> In this case, the error line of the jsp file is 3. I guess Tomcat
> 5(Jasper 2) may not implement debugging support specified in JSP 2.0
> spec. I'd like to know whether it is possible to do so without JDK
> 1.4(Merlin's JPDA-level support) and how the discussion on this issue
> with JSR-152 EG is going.
> 
> Thanks for your great work again.
> 
> IAS
> 
> Independent Java Technology Evangelist
> http://www.iasandcb.pe.kr
> 
> Jakarta Seoul Project Coordinator
> http://jakarta.apache-korea.org
> 
> > -Original Message-
> > From: Remy Maucherat [mailto:remm@;apache.org]
> > Sent: Monday, October 28, 2002 7:08 PM
> > To: Tomcat Developers List
> > Subject: [5.0] New build documentation, docs online
> > 
> > New Tomcat 5.0 docs online (linked from the main Tomcat page):
> > http://jakarta.apache.org/tomcat/tomcat-5.0-doc/index.html
> > 
> > New building documentation:
> > http://jakarta.apache.org/tomcat/tomcat-5.0-doc/BUILDING.txt
> > 
> > Comments ?
> > 
> > Remy
> > 
> > 
> > --
> > To unsubscribe, e-mail:    > [EMAIL PROTECTED]>
> > For additional commands, e-mail:  > [EMAIL PROTECTED]>
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New Committer John Turner

[Bob Herrmann]

Mladen's word is enough for me.

+1 for John Turner

Cheers,
-bob

On Fri, 2002-10-18 at 15:11, Mladen Turk wrote:
> Hi,
> 
> I'd like to propose John Turner [Jturner at AAS.com]
> as a new Tomcat committer.  
> 
> He does a great job in helping people on tomcat-users list, and he is
> willing to help us writing docs, testing, etc.
> 
> 
> MT.
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
-- 
Bob Herrmann <[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>

Re: security

[Bob Herrmann]

On Wed, 2002-10-16 at 17:12, Costin Manolache wrote:
> Bob Herrmann wrote:
> 
> > 
> > Looking into the Tomcat jars, I noticed the package "org.apache.jk"
> > isn't blocked... so even with the Security Manager running, I think I am
> > able to get catalina to load "arbitrary classes" like this,
> > 
> > <%
> >org.apache.jk.apr.TomcatStarter.mainClasses = new String[]{
> > "someClass" };
> > 
> >org.apache.jk.apr.TomcatStarter.main(new String[0]);
> > %>
> > 
> > So, My question is, should we "block" access to package "org.apache.jk"
> > from webapps?
> 
> Bob,
> 
> This won't change the security rules or context in any way. If you 
> are able to create 'someClass', you can call it directly. If
> you call it via TomcatStarter - there is no difference as long
> as no doPriviledged block is reached ( since the security context
> is the intersection of all callers - and this call is originated
> from user code ).

I am a tad fuzzy on this security stuff... but if the "system class
loader" is (or a higher privileged class loader has loaded the
TomcatStarter class), then wont the "Class.forName()" that it does
bypass the possible webapp restriction on class loading... (for example
the webapp classloader restricts accessing org.apache.catalina.*)

> 
> I also think jk is loaded in the server loader - so it shouldn't be
> visible.

My jsp page compiles and seems to invoke the TomcatStarter

> 
> 
> Please, lets wait few more days for commiter list creation and use it 
> for this kind of discussions. If this would be a real exploit, it would be
> much better to have the information public _after_ a fix is commited.

ok.

Cheers,
-bob

> We can forward all the mails to tomcat-dev with a small delay and
> nothing will be lost. If a problem is real, we can fix it first
> and then bounce the message. If not - we can just bounce them
> after we find it is harmless.
> 
> -- 
> Costin
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

security

[Bob Herrmann]

Looking into the Tomcat jars, I noticed the package "org.apache.jk"
isn't blocked... so even with the Security Manager running, I think I am
able to get catalina to load "arbitrary classes" like this,

<%
   org.apache.jk.apr.TomcatStarter.mainClasses = new String[]{
"someClass" };

   org.apache.jk.apr.TomcatStarter.main(new String[0]);
%>

So, My question is, should we "block" access to package "org.apache.jk"
from webapps?

Cheers,
-bob





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5] Security Audit: fluf found

[Bob Herrmann]

I found this extra bit of fluf, can someone (with jakarta-servletapi
Karma) commit this?

Cheers,
-bob







Index: jsr154/src/share/javax/servlet/http/HttpUtils.java
===
RCS file: /home/cvs/jakarta-servletapi-5/jsr154/src/share/javax/servlet/http/HttpUtils.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 HttpUtils.java
--- jsr154/src/share/javax/servlet/http/HttpUtils.java	13 Aug 2002 16:21:45 -	1.1.1.1
+++ jsr154/src/share/javax/servlet/http/HttpUtils.java	15 Oct 2002 21:30:54 -
@@ -83,7 +83,6 @@
 private static ResourceBundle lStrings =
 	ResourceBundle.getBundle(LSTRING_FILE);
 
-static Hashtable nullHashtable = new Hashtable();
 
 
 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] 5.0.0 milestione released

[Bob Herrmann]

On Tue, 2002-10-15 at 03:12, Remy Maucherat wrote:
> As voted, I have packaged a first milestone of Tomcat 5.
> 
> http://jakarta.apache.org/builds/jakarta-tomcat/milestone/v5.0.0/
> 
> Note: I put it in the jakarta-tomcat folder. I don't see a point of 
> using the version number in the folder name (and I didn't have write 
> access to jakarta-tomcat-5 anyway; +1 for removing it).

Humm.  Should there be a "nightly-5" directory in this dir

   http://jakarta.apache.org/builds/jakarta-tomcat/

?

Cheers,
-bob



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: SSL client auth in Tomcat 4.0

[Bob Herrmann]

I have gotten clientAuth=true working with Tomcat 5.

It is important to get the trusted certificates properly defined.  

I did this,

export
CATALINA_OPTS="-Djavax.net.ssl.trustStore=/home/bob/issues/ssl/cacerts.jks 
-Djavax.net.ssl.trustStorePassword=changeit"

And sometimes defined this to get extra info.
#  -Djavax.net.debug=ssl,handshake,data,trustmanager"

Cheers,
-bob


On Mon, 2002-10-14 at 20:13, Steven Bradley wrote:
> I'm using Tomcat 4.0 standalone on Windows 2000 and am having trouble 
> getting SSL client authentication working (getting SSL server auth working 
> was a snap).  Here's what I've done so far:
> 
> * created a self-signed client cert using openSSL (key usage includes 
> digital signature)
> * imported client cert (and private key) into Internet Explorer (by way of 
> a PKCS#12 file)
> * imported the Tomcat JKS file with the client certificate
> * configure tomcat server.xml file as follows:
> 
>   port="443"
> minProcessors="5"
> maxProcessors="75"
> enableLookups="true"
>  acceptCount="10"
>  debug="0"
>  scheme="https"
>  secure="true">
>clientAuth="true"
>  keystoreFile="conf/server.keystore"
>  keystorePass ="password"
> protocol="TLS"/>
>  
> 
> * stop/start tomcat
> * point IE browser to https://localhost/index.html
> 
> What IE tells me is that the page can't be displayed (after some 
> handshaking attempts).  Unfortunately, there is no log info generated (even 
> if I increase the debug param in the  element).
> 
> Any clues as to what I may be doing wrong?  Has ANYONE been able to get SSL 
> client authentication working with Tomcat 4.0 standalone (Catalina).
> 
> Thanks in advance
> -- Steven
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5] Nightly builds started

[Bob Herrmann]

I started nightly builds on nagoya.apache.org,  the builds
are available here,

   http://jakarta.apache.org/builds/jakarta-tomcat-5/nightly/


Cheers,
-bob



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Proposal] Security Audit

[Bob Herrmann]

FYI, Just to start off, I am going to review these classes.  If
someone else also reviews them, thats probably a good thing...

# classes, package name

17 o.a.c.deploy
9  o.a.c.users
44 o.a.c.*
34 o.a.jk.*
15 j.s.http

Briefly, I am going to look for
 - How/if a ClassLoader is used
 - privilege blocks (are they small, use trusted values)
 - look for non-final static variables (can they be abused)
 - can methods/fields be made private?
 - are mutable objects returned to caller (especially arrays)
   think about returning clones
 - non final equals/hashcode methods? (accessing sensitive stuff?)
 - Serializable (exposes private stuff?)

Does anyone publish a security checklist list like this?

Blah Blah,
-bob


On Tue, 2002-10-08 at 16:36, Jean-Francois Arcand wrote:
> Hi,
> 
> I'm looking to do a Security Audit on the current Tomcat 5.0 codebase. I 
> would like to collect as more as information as where you think I should 
> look at (code, security hole, etc.). I'm planning to do the audit using 
> the default SecurityManager. Rigth now, I have started looking at:
> 
> - doPrivilege blocks. Are they small enough? Can they be reduced?
> - JSP generated code. Are they secure? Can a malicious app uses the code 
> to access o.a.catalina code?
> - Is catalina.policy restricted enough?
> - Is our Classloader secure?
> 
> Any direction/ideas/recommendations will be appreciated.
> 
> Thanks,
> 
> -- Jeanfrancois
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
Bob Herrmann <[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [Proposal] Security Audit

[Bob Herrmann]

I can't think of anything more boring and tedious (bug fixing?) but I am
willing to help.  Maybe we should divide up the classes.  

Cheers,
-bob

On Tue, 2002-10-08 at 16:36, Jean-Francois Arcand wrote:
> Hi,
> 
> I'm looking to do a Security Audit on the current Tomcat 5.0 codebase. I 
> would like to collect as more as information as where you think I should 
> look at (code, security hole, etc.). I'm planning to do the audit using 
> the default SecurityManager. Rigth now, I have started looking at:
> 
> - doPrivilege blocks. Are they small enough? Can they be reduced?
> - JSP generated code. Are they secure? Can a malicious app uses the code 
> to access o.a.catalina code?
> - Is catalina.policy restricted enough?
> - Is our Classloader secure?
> 
> Any direction/ideas/recommendations will be appreciated.
> 
> Thanks,
> 
> -- Jeanfrancois
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
Bob Herrmann <[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

[PATCH] SSLSocket, CLIENT-AUTH, and JDK1.4

[Bob Herrmann]

Before I commit this diff, I would like some eyes. This fixes a problem
with JSSE doing request for CERTS on an already established SSL Socket.

I am concerned that this change may not pass the sniff test as I check a
System.getProperty("java.vm").startsWith("1.4") to see if the extra
jiggle is needed on the SSLSocket - but my instincts tell me that is
colorfully kludgey.  Ideas?  

Index: util/java/org/apache/tomcat/util/net/jsse/JSSESupport.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSESupport.java,v
retrieving revision 1.1
diff -u -r1.1 JSSESupport.java
--- util/java/org/apache/tomcat/util/net/jsse/JSSESupport.java  4 Oct
2002 20:03:10 - 1.1
+++ util/java/org/apache/tomcat/util/net/jsse/JSSESupport.java  7 Oct
2002 20:15:14 -
@@ -66,6 +66,8 @@
 import java.security.cert.CertificateFactory;
 import javax.net.ssl.SSLSession;
 import javax.net.ssl.SSLSocket;
+import javax.net.ssl.HandshakeCompletedListener;
+import javax.net.ssl.HandshakeCompletedEvent;
 import java.security.cert.CertificateFactory;
 import javax.security.cert.X509Certificate;
 
@@ -127,6 +129,9 @@
session.invalidate();
ssl.setNeedClientAuth(true);
ssl.startHandshake();
+   if ( System.getProperty("java.version").startsWith("1.4") ){
+   synchronousHandshake(ssl);
+   }
session = ssl.getSession();
jsseCerts = session.getPeerCertificateChain();
if(jsseCerts == null)
@@ -198,5 +203,44 @@
 }
 return buf.toString();
 }
+
+/**
+ * JSSE in JDK 1.4 has an issue that requires us to do a read() to
+ * get the client-cert.  As suggested by Andreas Sterbenz
+ */
+private static void synchronousHandshake(SSLSocket socket) 
+throws IOException {
+InputStream in = socket.getInputStream();
+int oldTimeout = socket.getSoTimeout();
+socket.setSoTimeout(100);
+Listener listener = new Listener();
+socket.addHandshakeCompletedListener(listener);
+byte[] b = new byte[0];
+socket.startHandshake();
+int maxTries = 50; // 50 * 100 = example 5 second rehandshake
timeout
+for (int i = 0; i < maxTries; i++) {
+try {
+int x = in.read(b);
+} catch (SocketTimeoutException e) {
+// ignore
+}
+if (listener.completed) {
+break;
+}
+}
+socket.removeHandshakeCompletedListener(listener);
+socket.setSoTimeout(oldTimeout);
+if (listener.completed == false) {
+throw new SocketTimeoutException("SSL Cert handshake
timeout");
+}
+}
+
+private static class Listener implements HandshakeCompletedListener
{
+volatile boolean completed = false;
+public void handshakeCompleted(HandshakeCompletedEvent event) {
+completed = true;
+}
+}
+
 }





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-5 gump.xml

[Bob Herrmann]

Oops.  Sorry.  Thanks. 

On Fri, 2002-10-04 at 18:11, [EMAIL PROTECTED] wrote:
> costin  2002/10/04 15:11:21
> 
>   Modified:.gump.xml
>   Log:
>   I think this is the correct syntax.
>   
>   Revision  ChangesPath
>   1.11  +1 -1  jakarta-tomcat-5/gump.xml
>   
>   Index: gump.xml
>   ===
>   RCS file: /home/cvs/jakarta-tomcat-5/gump.xml,v
>   retrieving revision 1.10
>   retrieving revision 1.11
>   diff -u -r1.10 -r1.11
>   --- gump.xml4 Oct 2002 18:36:54 -   1.10
>   +++ gump.xml4 Oct 2002 22:11:20 -   1.11
>   @@ -12,7 +12,7 @@
>
>
>  
>   -
>   +
>  
>  
>  
>   
>   
>   
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
Bob Herrmann <[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: please show me how to download the DBCP API jar file

[Bob Herrmann]

Look here, 

http://jakarta.apache.org/builds/jakarta-commons/release/commons-dbcp/v1.0/



On Thu, 2002-10-03 at 17:44, Shih, John wrote:
> Dear Sir,
> 
> I like to use DBCP to connect to Oracle JDBC driver.
> 
> Would you please show me how to download the DBCP API jar file? So I can put
> it into
> $CATALINA_HOME/common/lib
> 
> DBCP uses the Jakarta-Commons Database Connection Pool. It relies on number
> of Jakarta-Commons componenets: 
> Jakarta-Commons DBCP 1.0 
> Jakarta-Commons Collections 2.0 
> Jakarta-Commons Pool 1.0 
> 
> 
> Thanks for your help
> 
> John Shih
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

SSL Client-Auth

[Bob Herrmann]

Hi.  I have been looking into a problem with Tomcat5, ClientAuth=false,
and JSSE in JDK1.4 and it seems like the JSSE has a problem.

Namely if you build an SSL socket, then later decide you need to
exchange certs with the client (ie. CLIENT-CERT), then the 

SSlSocket.startHandshake()

method is called.  Unfortunately this method is asynchronous, and waits
for a read() or write() to occur before it does it's work.  TC5
processes requests kinda like this; a Request comes in, TC5 checks to
see if the Resource is protected, then a negotiation may start.  However
JSSE won't initiate a cert exchange unless a Read() or a Write() happens
on the socket, but TC5 doesn't have anything it wants to write or read
when the 'startHandshake()' is called 

I have been playing around with using a sendRedirect() back to the same
page, but boy does that seem messy.

Any ideas?
-bob

P.S. I tweaked the JSSE sample programs to demonstrate the problem
outside of Tomcat.  If anyone wants a copy - just ask.





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] [VOTE] Removal of the LE distribution

[Bob Herrmann]

On Thu, 2002-10-03 at 13:24, Remy Maucherat wrote: 
> 
> +1 [X] Yes, remove the LE distribution
> -1 [ ] No, keep both distributions
> 

simpler is better.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Need some clarifications

[Bob Herrmann]

On Wed, 2002-10-02 at 09:38, Christian Gross wrote:
> Hi
> 
> So I worked myself through the various CVS sources and have a couple of 
> "official" position questions to ask.
> 
> The CVS projects jakarta-tomcat-catalina and jakarta-tomcat-jasper, will be 
> forming the Tomcat 5 work?

Yup.

> The CVS project jakarta-tomcat-4.0 is the 4.x branch?

yes.  I think the 4.0 is tagged in there, but the HEAD is 4.1

> The CVS project jakarta-tomcat is anything before 4.0

yup.

> The CVS project jakarta-tomcat-5.0 does nothing??

It is "jakarta-tomcat-5", not "5.0" and it is used to pull together the
other bits to make Tomcat5.

If you want to build  TC5, just use the attached build.xml and type
"ant"

Cheers,
-bob


> 
> Thanks, for any help
> 
> 
> Christian Gross
> Software Engineering Consultant
> http://www.devspace.com
> North America: 1-450-675-4208
> Europe +41.1.701.1166
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
Bob Herrmann <[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [VOTE] [5.0] Milestones

[Bob Herrmann]

> 
> [X] +1 Yes, start releasing milestones
> [ ] -1 No, because:
> 
> 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability

[Bob Herrmann]

With power comes responsibility.

<% System.exit(1) %>

-bob

P.S. Yea, I know the SecurityManager can catch this, if enabled.

On Wed, 2002-09-25 at 21:22, Bojan Smojver wrote:
> Quoting Costin Manolache <[EMAIL PROTECTED]>:
> 
> > And Velocity does have a mailing list where all this can be discussed.
> > 
> > This is tomcat-dev - for servlet and jsp development.
> > 
> > If you have any ideas on how to improve jasper - great, but please don't
> > waste our time with off topic subjects. Comments and sugestions on JSP spec 
> > can be addressed to the feedback address from Sun, we just implement it.
> > 
> > ( and BTW, nobody forces you to use any java inside the JSP if you don't
> > want to, or any of the features that are specific to jsps. )
> 
> All right then, let's talk about JSP's. If I host my clients' JSP's on my server
> and a web designer puts this in (BTW, he wasn't forced, he simply decided he
> wanted to do it):
> 
> ---
> Hashtable strings = new Hashtable();
> int i=0;
> while (true)
> {
> strings.put ("dead"+i, new StringBuffer(99));
> }
> ---
> 
> What would happen to my Tomcat? I think this is called OutOfMemoryError and it
> would affect every single web application running in that instance of Tomcat,
> possibly owned by some other clients of mine. Completely unacceptable...
> 
> Web applications are collection programs and other stuff, for instance web
> pages. However, web pages should not be programs because they are (usually)
> maintained by non-programmers. The fact that you know what you're doing doesn't
> exuse the shortcomings of the technology.
> 
> Bojan
> 
> -----
> This mail sent through IMP: http://horde.org/imp/
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
Bob Herrmann <[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: cvs commit:jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/netJSSESocketFactory.java

[Bob Herrmann]

Humm...  When I set SSL connector with  clientAuth="true", Tomcat 5
gives me this,

Handshake failed javax.net.ssl.SSLHandshakeException:
javax.net.ssl.SSLProtocolException: handshake alert:  no_certificate



On Thu, 2002-09-19 at 01:09, [EMAIL PROTECTED] wrote:
> billbarker2002/09/18 22:09:28
> 
>   Modified:util/java/org/apache/tomcat/util/net JSSESocketFactory.java
>   Log:
>   Fix problem with JSSE not honoring "clientauth".
>   
>   Now there should be now reason for anyone to believe that CertificatesValve should 
>be used ever with the CoyoteConnector. :-)
>   
>   Revision  ChangesPath
>   1.3   +16 -2 
>jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/JSSESocketFactory.java
>   
>   Index: JSSESocketFactory.java
>   ===
>   RCS file: 
>/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/JSSESocketFactory.java,v
>   retrieving revision 1.2
>   retrieving revision 1.3
>   diff -u -r1.2 -r1.3
>   --- JSSESocketFactory.java  18 Sep 2002 15:10:04 -  1.2
>   +++ JSSESocketFactory.java  19 Sep 2002 05:09:28 -  1.3
>   @@ -161,7 +161,18 @@
>
>   //determine whether we want client authentication
>   // the presence of the attribute enables client auth
>   -   clientAuth = null != (String)attributes.get("clientauth");
>   +   String clientAuthStr=(String)attributes.get("clientauth");
>   +   if(clientAuthStr != null){
>   +   if(clientAuthStr.equals("true")){
>   +   clientAuth=true;
>   +   } else if(clientAuthStr.equals("false")) {
>   +   clientAuth=false;
>   +   } else {
>   +   throw new IOException("Invalid value '" +
>   + clientAuthStr + 
>   + "' for 'clientauth' parameter:");
>   +   }
>   +   }
>
>   String keyPass=(String)attributes.get("keypass");
>   if( keyPass==null) keyPass=defaultKeyPass;
>   @@ -224,11 +235,14 @@
>public Socket acceptSocket(ServerSocket socket)
>   throws IOException
>{
>   +   SSLSocket asock = null;
>   try {
>   -   return socket.accept();
>   +asock = (SSLSocket)socket.accept();
>   +asock.setNeedClientAuth(clientAuth);
>   } catch (SSLException e){
> throw new SocketException("SSL handshake error" + e.toString());
>   }
>   +   return asock;
>}
> 
>/** Set server socket properties ( accepted cipher suites, etc)
>   
>   
>   
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.java

[Bob Herrmann]

On Wed, 2002-09-18 at 13:58, Remy Maucherat wrote:
> Remy Maucherat wrote:
> > [EMAIL PROTECTED] wrote:
> > 
> >> bobh2002/09/18 09:44:35
> >>
> >>   Modified:.gump.xml
> >>coyote/src/java/org/apache/coyote Request.java
> >>http11/src/java/org/apache/coyote/http11
> >> Http11Processor.java
> >>   Log:
> >>   - This associates the socket with the Request.  This is so the
> >>   CertificatesValve.verify() can tell where (which socket) the Request
> >>   is comeing from.  Without this association, CertificatesValve.verify()
> >>   returns with no SSL Handshake.
> >>   - this change is in part based on feed back from; Vivek N. Yingxian
> >>   Wang (JSSE), Craig M., Qingqing Ouyang
> > 
> > 
> > -1 (ie, revert this).
> > 
> > The socket should already have been associated with the request, but as 
> > a note. It is available, and accessible.
> 
> Ok, I checked it, and the socket os not currently associated with the 
> request (I thought it was). OTOH, you shouldn't add a field for socket 
> in the request (native webservers don't have the notion of a Java 
> socket). Instead, use one of the notes.

Ok, 
  - change Http11Processor to use a note
  - change Request.java to it's original form
  - change the CertificatesValve.verify()

Does that sound about right?

Cheers,
-bob

> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
-- 
Cheers,
-bob


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit:jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startupCatalina.java

[Bob Herrmann]

Yea, I changed references of "log.log" to "log.info"
-bob

On Tue, 2002-09-10 at 19:19, Dave wrote:
> This commit has stopped Tomcat compiling. There is no log method in
> org.apache.commons.logging.Log.
> 
>  
> 
> Dave
> 
-- 
Cheers,
-bob


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Form auth status not persisted between tomcat reloads

[Bob Herrmann]

Humm.  To be 'logged in' is to have a 'principal'
StandardSession.java declares it's principal like this

 /**
 * The authenticated Principal associated with this session, if any.
 * IMPLEMENTATION NOTE:  This object is not saved and
 * restored across session serializations!
 */
 private transient Principal principal = null;


I don't know of any effort to change this behavior in Tomcat.

Cheers
-bob

On Tue, 2002-09-10 at 17:54, Kristoffer Michael wrote:
> 
> If a user is logged in (by using FORM auth), and tomcat is restarted,
> the "logged in" status for the user is forgotten, even though the
> session and session attributes are remembered.
> Apparently the status is not stored in the session (but in a HttpRequest note)?
> 
> Is this a "feature", or is there going to be work on it in the future?
> 
> BTW, using SSO cookies doesn't seem to help (don't know if this is related).
> 
> -km
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
-- 
Cheers,
-bob


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-catalina build.xml gump.xml

[Bob Herrmann]

Picky picky.

On Tue, 2002-09-10 at 12:07, Stefan Bodewig wrote:
> On 10 Sep 2002, <[EMAIL PROTECTED]> wrote:
> 
> > + 
> 
> I don't think this is going to work on my machine (no user bob here 8-).
> 
> You probably want to do something like
> 
>reference="home"/>
> 
> Same for catalina-home.
> 
> Stefan
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
-- 
Cheers,
-bob


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Volunteering

[Bob Herrmann]

On Wed, 2002-09-04 at 10:00, Shapira, Yoav wrote:
> Hi everyone
> I'd like to volunteer to help with tomcat ;)  I've been using it for a
> while, read the Apache guidelines, looked at the source code a bit, and
> been developing in Java for a few years.  
> 
> >From Remy's message, it sounds like maybe more people are needed to help
> with the admin webapp?  I'll be glad to help there, as well as wherever
> else I can / you need me to help ;)

You can always go through the bug list and start fixing bugs.

Try using Tomcat, when you find something that really annoys you about
it see if you can figure out a way to fix (improve it.)  

Cheers
-bob




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5] logout() and Basic Authentication

[Bob Herrmann]

Hi, The Servlet 2.4 spec includes HttpSession.logout(). 

My question is, how should Tomcat handle a logout() when the webapp is
using "Basic Authentication" ?

Basic Authentication is described in http://www.ietf.org/rfc/rfc2617.txt
Chapter 2.

My assertion is: Once a remote user has logged in once using Basic
Authentication, there is no way to log them out. (In most cases, they
need to close their browser to effect a logout.)  When receiving a
request, Tomcat cannot tell if a user was asked to login or not. A page
load and a login are identical.

Some have suggested attempting "tricking" the remote user into relogging
in by re-challenging the user.  The problem with this approach is that
the protocol doesn't allow us to differentiate between a request that is
coming from a "newly challenged" client or "challenged previously"
client.  

Some have suggested sending a cookie along with the challenge and using
them together to authenticate the re-login.  This might work.  It 
depends on whether the browser accepts the cookie right away or not.  If
the cookie is accepted immediately by the browser and the user ignores
the login dialog (or dismisses it) the new cookie could be set. This
would put us back at being unable to identify if a request is a
"relogin" or a "page load."

My current plan is to;

1. verify that the "new coookie" approach doesn't work
2. dig up some history on why "Basic Authentication" is so broken (early
protocol addition?)
3. suggest a language change to the Servlet 2.4 spec. something like
adding to the logout() section, "If the container is authenticating
using Basic Authentication (thus the authentication state is stored on
the browser), logout() must only invalidate the user's session (or if
using SingleSignOn, all the users sessions.) "

Cheers,
-bob




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5] [GUMP-PATCH] Make Tomcat 5 descriptor work (hopefully)

[Bob Herrmann]

On Tue, 2002-09-03 at 02:53, Stefan Bodewig wrote:
> On 02 Sep 2002, Bob Herrmann <[EMAIL PROTECTED]> wrote:
> 
> > I started playing with Gump with the hopes of getting TC5 to build,
> > but I am totally clueless.
> 
> Let's see whether I can help.
> 
> > I was playing with Gump last week then got interrupted by bug fixes.
> > (I created/checked-in TC5's gump.xml and I also created a gump3.xml
> > in the top of the jakarta-tomcat-jasper) I will resume toying with
> > it tomorrow (Monday.)
> 
> Maybe it would be easier to start with a descriptor in Gump's CVS
> repository (tell us what is needed as dependencies, which Ant target
> to call and which jars are created) and move it to Tomcat as soon as
> it starts to work?
> 
> > In the meantime, I checked in your changes.
> 
> Unfortunately I missed to references to the not existing servletapi-5
> project, please apply the patch below as well.  I've tested it locally
> and this will at least try to build Tomcat 5 (but fail miserably).

ok, your changes to your changes have been checked in.

> > I expect Gump TC5 builds will be broken for a few more days.
> 
> As long as it doesn't affect the other builds - you'll get the nagging
> emails ;-).

Cool.  I am starting to understand more about Gump.  TC5 knows about all
it's dependencies (see the "download" target in TC5's build.xml), it
would be nice if TC5's build.xml could be transformed into a module
description. (So there aren't two sets of instructions for building TC5)
Anyway, When adding a new project to Gump, do you recommend building the
gump universe to test things out?  The gump universe has a lot of
dependencies (ie.
http://jakarta.apache.org/builds/gump/latest/packages.html )  I have
started downloading and installing them...  alas this makes jumping into
gump a bit difficult... to bad gump doesnt have a "download" target to
fetch all the "/opt" things that it requires

Cheers,
-bob


> 
> Thanks
> 
> Stefan
> 
> Index: gump.xml
> ===
> RCS file: /home/cvspublic/jakarta-tomcat-5/gump.xml,v
> retrieving revision 1.2
> diff -u -r1.2 gump.xml
> --- gump.xml  2 Sep 2002 23:38:29 -   1.2
> +++ gump.xml  3 Sep 2002 06:43:16 -
> @@ -36,8 +36,9 @@
>
>
>
> -  
> -  
> +   +  project="jakarta-servletapi-5-servlet"/>
> +  
>
>
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
Cheers,
-bob


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

[5] Re: [GUMP-PATCH] Make Tomcat 5 descriptor work (hopefully)

[Bob Herrmann]

Hi Stefan.  I started playing with Gump with the hopes of getting TC5 to
build, but I am totally clueless.   I was playing with Gump last week
then got interrupted by bug fixes.  (I created/checked-in TC5's gump.xml
and I also created a gump3.xml in the top of the jakarta-tomcat-jasper) 
I will resume toying with it tomorrow (Monday.)   In the meantime, I
checked in your changes.  I am still learning Gump stuff, so I expect
Gump TC5 builds will be broken for a few more days.

Cheers,
-bob

On Mon, 2002-09-02 at 11:58, Stefan Bodewig wrote:
> You may have noticed that Gump has prereq failures for
> jakarta-tomcat-coyote, the reason is that tomcat-catalina is defined
> twice (in both tomcat descriptors) and the one in tomcat-5 is unusable
> as there is no servletapi-5 project.
> 
> I've added a descriptor for the servletapi-5 module holding two
> projects to Gump and with the patch below, it should be picked up so
> that we can start to get off the ground.
> 
> Cheers
> 
> Stefan
> 
> Index: gump.xml
> ===
> RCS file: /home/cvspublic/jakarta-tomcat-5/gump.xml,v
> retrieving revision 1.1
> diff -u -r1.1 gump.xml
> --- gump.xml  28 Aug 2002 15:49:06 -  1.1
> +++ gump.xml  2 Sep 2002 15:56:27 -
> @@ -7,42 +7,11 @@
>  
>
>
> -  
> -
> -  
> -  
> -   -runtime="true"/>
> -   -runtime="true"/>
> -   -runtime="true"/>
> -   -runtime="true" id="all"/>
> -   -runtime="true" id="api"/>
> -   -reference="jarpath" id="regexp" project="jakarta-regexp"/>
> -   -project="jakarta-tomcat-connectors"/>
> -
> -
> -
> -
> -
> -
> -
> -
> -
> -  
> -  
>
>  org.apache.catalina
>  
>  
>
> -   -reference="home" project="jakarta-servletapi-5"/>
>
>
> @@ -97,7 +66,8 @@
>  
>  
>  
> -
> +
> +
>  
>  
>  
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
-- 
Cheers,
-bob


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: jakarta-servleapi-5

[Bob Herrmann]

I agree! access to changing the examples is hindered.  Perhaps we should
take a vote like this?

[ ] Create new jakarta-servletjsp-examples

[ ] Move examples into another exiting repository [?fill this in?]

[ ] Change access to jakarta-servletapi-5 to allow all tomcat committers

[ ] Leave it all alone

Cheers,
-bob


On Fri, 2002-08-30 at 18:07, Ignacio J. Ortega wrote:
> Is needed any process to get to committer access j-s-5? votes or
> whatever ?
> 
> If the tomcat people is going to maintain the examples inside there, i
> think is obvious we need commit access there.. if not i vote to move the
> examples where mere mortal committers can alleviate the pains of his
> users.. :)
> 
> Thanks..
> 
> Saludos ,
> Ignacio J. Ortega
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
-- 
Cheers,
-bob


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5] Session.logout()

[Bob Herrmann]

The JSP spec 2.4 gives us Session.logout(), what do we do when using
Basic authentication?  Once challenged, the web browser keeps passing
the user/pass (right?) so any ideas about how to get the browser to
re-challenge the end user? (change the domain?)


Cheers,
-bob


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5] Examples

[Bob Herrmann]

It's nice to see the examples are back in TC5. I am glad they are in the
jakarta-servletapi-5 repository - except that repository has very
restricted access ...  so fixing or adding examples is going to require
Patchs, nagging, etc...  comments?

-bob





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

session timeout

[Bob Herrmann]

Setting the "maxInactiveInterval" in server.xml is pointless because it
is overwritten by the webapp's "web.xml" or "conf/web.xml", should I
remove it from the manager.xml documentation, like the patch below?

Comments?
-bob


Index: manager.xml
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/webapps/docs/config/manager.xml,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 manager.xml
--- manager.xml 18 Jul 2002 16:48:37 -  1.1.1.1
+++ manager.xml 27 Aug 2002 17:31:22 -
@@ -57,17 +57,6 @@
 deployment descriptor (/WEB-INF/web.xml).
   
 
-  
-The default maximum inactive interval (in minutes) for
Sessions
-created by this Manager.  If not specified, the default value
is
-sixty (60) minutes.
-
-NOTE - The value for this property is
inherited
-automatically if you specify a

-element in the web application deployment descriptor
-(/WEB-INF/web.xml).
-  
-
 
 
   





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5.0] Welcome Files

[Bob Herrmann]

I have been looking into the Servlet 2.4 section 9.10 Welcome files
stuff.  In a nutshell, the spec now allows servlets to be welcome
files.  The can either be an 'exact match' or a 'prefix match.'

I implemented changes to StandardContextWrapper to bring Tomcat into
compliance.  I think it is pretty messy, but then again Welcome Files
are messy (per earlier posts.)

What do you think?   (The patch is for discussion purposes and contains
a lot of logging)

Cheers,
-bob





Index: core/StandardContextMapper.java
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContextMapper.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 StandardContextMapper.java
--- core/StandardContextMapper.java	18 Jul 2002 16:48:11 -	1.1.1.1
+++ core/StandardContextMapper.java	21 Aug 2002 22:45:02 -
@@ -65,15 +65,20 @@
 package org.apache.catalina.core;
 
 
+import javax.naming.directory.DirContext;
+import javax.naming.InitialContext;
+import javax.naming.NamingException;
 import javax.servlet.http.HttpServletRequest;
 import org.apache.catalina.Container;
 import org.apache.catalina.Context;
+import org.apache.catalina.Globals;
 import org.apache.catalina.HttpRequest;
 import org.apache.catalina.Mapper;
 import org.apache.catalina.Request;
 import org.apache.catalina.Wrapper;
 import org.apache.catalina.util.RequestUtil;
 import org.apache.catalina.util.StringManager;
+import org.apache.naming.resources.Resource;
 
 
 /**
@@ -272,6 +277,15 @@
 if (wrapper != null) {
 servletPath = relativeURI;
 pathInfo = null;
+		
+if ( relativeURI.endsWith("/") ) {
+WelcomeURIProcessing wfp = new WelcomeURIProcessing( relativeURI );
+if ( wfp.mapsToServlet ){
+wrapper = wfp.wrapper;
+servletPath = wfp.servletPath;
+pathInfo = wfp.pathInfo;
+}
+}
 }
 }
 
@@ -290,5 +304,126 @@
 
 }
 
+
+//  Private Methods
+
+
+/**
+ * This helper class is used as part of an attempt to satisfy
+ * Servlet 2.4 spec, section 9.10.  Section 9.10 now allows a
+ * welcome file to map to a servlet
+ **/
+private class WelcomeURIProcessing {
+boolean mapsToServlet = false;
+
+Wrapper wrapper = null;
+String  servletPath = null;
+String  pathInfo = null;
+
+WelcomeURIProcessing (String relativeURI ) {
+mapsToServlet = search(relativeURI);
+}
+
+boolean search(String relativeURI) {
+DirContext resources = getResources();
+
+String[] welcomes = context.findWelcomeFiles();
+
+for(int i=0;i

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [OFF-Topic] CVS problems

[Bob Herrmann]

Any ideas?  Well, I fooled around with trying to get pserver to tunnel
using ssh for a few hours and didnt get it to work. (stock RedHat 7.3) I
finally just went with the 

export CVS_RSH=ssh

technique and gave up on tunneling.  So it creates a new connection
everytime instead of using an existing tunnel.  Seems like the buildup,
tear down are pretty fast.

Cheers,
-bob


On Wed, 2002-08-21 at 14:09, Jean-Francois.Arcand wrote:
> Hi,
> 
> I'm trying to update my workspace using /home/cvs but I'm always 
> receiving the following error:
> 
> (1) ssh -l jfarcand -L 2401:localhost:2401 cvs.apache.org
> 
> (2) cvs :pserver:jfarcand@localhost:/home/cvs/ checkout jakarta-servletapi-5
> ? jakarta-servletapi-5/jsr152/src/share/dtd/.new.web-jsptaglibrary_1_2.dtd
> cvs server: Updating jakarta-servletapi-5
> cvs server: Updating jakarta-servletapi-5/jsr152
> cvs server: Updating jakarta-servletapi-5/jsr152/src
> cvs server: Updating jakarta-servletapi-5/jsr152/src/etc
> cvs server: Updating jakarta-servletapi-5/jsr152/src/share
> cvs server: Updating jakarta-servletapi-5/jsr152/src/share/dtd
> U jakarta-servletapi-5/jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd
> cvs [checkout aborted]: end of file from server (consult above messages 
> if any)
> 
> Any ideas? I'm on win2k using MKS
> 
> Thanks,
> 
> -- Jeanfrancois
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: getting patches commited

[Bob Herrmann]

On Wed, 2002-08-21 at 11:28, John Trollinger wrote:
> If I add a patch to a bug does the patch still have to be submitted as a
> patch (via the [patch] subject line) to get into committers hands?

No, but posting to the tomcat-dev list is more visible.  Your subject
line is pretty important also.  Committers tend to be busy and only look
at stuff that they are familure with and understand... Getting stuff
committed relies a bit on selling the issue to someone who can take the
time to understand the problem, the solution and has the time to apply
the fix. 

Cheers,
-bob



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: VOTE: Restoring Tomcat examples: Which workspace?

[Bob Herrmann]

On Tue, 2002-08-20 at 11:42, Remy Maucherat wrote:
> Mark Roth wrote:
> > It would be great to restore the examples (both JSP and Servlet) so that
> > they are deployed on startup and so they are easily accessible.  In the
> > current build they are broken links.
> > 
> > I also would like to commit a number of additional JSP examples that
> > illustrate the new features in JSP 2.0.
> > 
> > The default web application that is deployed on startup currently lives
> > in the catalina workspace.  I have no problems keeping it there, but
> > before committing such a change I wanted to take a vote on where we
> > think the examples should live.
> > 
> > Vote:
> > 
> > [ ] A. jakarta-tomcat-catalina
> > [ ] B. jakarta-tomcat-jasper
> > [ ] C. jakarta-tomcat-5
> 
> The examples are portable and independent of Tomcat, so I want them to 
> go into jakarta-servletapi-5. I posted some time ago about that, and I 
> was planning to do it.
> 
> Remy

jakarta-servletapi-5 sounds much better than A, B, or C.


Cheers,
-bob


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: VOTE: Restoring Tomcat examples: Which workspace?

[Bob Herrmann]

Humm.  Are the examples Tomcat specific or should they work in any
JSP2.0 and Servlet 2.4 container?  If they are "generic" then perhaps
keeping them separate would encourage their reuse with other JSP/Servlet
projects.   Shouldn't every jsp server have a decent Snoop.jsp ?

Cheers,
-bob

On Mon, 2002-08-19 at 16:47, Mark Roth wrote:
> It would be great to restore the examples (both JSP and Servlet) so that
> they are deployed on startup and so they are easily accessible.  In the
> current build they are broken links.
> 
> I also would like to commit a number of additional JSP examples that
> illustrate the new features in JSP 2.0.
> 
> The default web application that is deployed on startup currently lives
> in the catalina workspace.  I have no problems keeping it there, but
> before committing such a change I wanted to take a vote on where we
> think the examples should live.
> 
> Vote:
> 
> [ ] A. jakarta-tomcat-catalina
> [ ] B. jakarta-tomcat-jasper
> [ ] C. jakarta-tomcat-5
> 
> --
> Mark Roth, Java Software
> Co-Specification Lead for JSP 2.0
> Sun Microsystems, Inc.
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
-- 
Cheers,
-bob


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] [PROPOSAL] Refactored mapper

[Bob Herrmann]

On Thu, 2002-08-15 at 18:38, Patrick Luby wrote:
> Remy and Costin,
> 
> I found the following draft wording that is being considered for the
> Servlet 2.4 spec. The exact wording may change, but the context should
> stay the same. Are there any unimplementable pieces in this proposed
> wording:
> 
> The wording in the 4th paragraph in section 9.10 of the Servlet 2.4 spec
> may change to:
> 
>The web server must append each welcome file in the order
>specified in the deployment descriptor to the partial request and
>check whether a [static] resource [or servlet] in the WAR is
>mapped to that request URI. The web container must send the
>request to the first resource in the WAR that matches [in the
>order of 1. a static resource, 2. a servlet that matches
>exactly, 3. a servlet that matches according to the path
>mapping rule].
> 
> Patrick

Humm... how does this help?  

First, note that the "extension mapping" is not mentioned, so things
like *.jsp, *.boo are not relevant to welcome files.  

Consider this,

  
BooServlet 
/boo/* 
  

  
FooServlet 
/boo/foo/* 
  

  
ExServlet 
exactMatch 
  
 
  
index.html 
/boo/AlwaysGoesHere 
/boo/foo/NeverGetsHere 
exactMatch 
index.jsp  
  
 

Somewhat confused (typical),
Bob


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] [PROPOSAL] Refactored mapper

[Bob Herrmann]

On Thu, 2002-08-15 at 15:37, Remy Maucherat wrote: 
[...] 
> Yes, but welcome files for non physical resources cannot be implemented 
> (since you have no way of asking a servlet if it can or cannot process a 
> resource).
> I'll implement something which works and which is very close to what the 
> spec requires.
> 
> Again, I have sent many messages to the spec leads about this issue 
> without any result, so I give up ...

I don't completely understand the issue(s), but consider this, 

 
   BooServlet 
   /*.boo 
 

 
   index.jsp 
   index.boo 
 

Is the problem that by the time the 'welcome file logic' gets a chance
to handle the request, the logic that would have been able to pass this
request off to a servlet is way too far up the call stack?It is
almost like the DefaultServlet would need to open a connection to the
loopback and check each "welcome file" URI to find one that gets to
something useful (this is just a mental exercise, don't get excited I
wouldn't think of implementing this.)

Cheers,
-bob




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-catalina/catalina build.xml

[Bob Herrmann]

On Thu, 2002-08-15 at 00:05, Steve Downey wrote:
> (jta.present == true) and (full.dist=true or tyrex.present)

Yea, your right.  I will change that to,

(full.dist==true) or ( jta.present == true and tyrex.present)

Does that sound ok?

Cheers,
-bob

> 
> If I'm reading this correctly, this won't build the Tyrex dependant components 
> if jta is not present, EVEN IF full.dist is requested. That means you can set 
> full.dist on and NOT get a full dist.
> 
> If full.dist is set true, then the build should fail if some component is 
> missing. At least it's that way for all other components.
> 
> On Wednesday 14 August 2002 05:39 pm, [EMAIL PROTECTED] wrote:
> > bobh2002/08/14 14:39:42
> >
> >   Modified:catalina build.xml
> >   Log:
> >   make Tyrex only compile if JTA is present (this was breaking my build.)
> >
> >   Revision  ChangesPath
> >   1.16  +7 -4  jakarta-tomcat-catalina/catalina/build.xml
> >
> >   Index: build.xml
> >   ===
> >   RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/build.xml,v
> >   retrieving revision 1.15
> >   retrieving revision 1.16
> >   diff -u -r1.15 -r1.16
> >   --- build.xml 13 Aug 2002 16:26:11 -  1.15
> >   +++ build.xml 14 Aug 2002 21:39:42 -  1.16
> >   @@ -348,10 +348,13 @@
> >
> >
> >
> >   -  
> >   -
> >   -
> >   -  
> >   +  
> >   +
> >   +
> >   +   
> >   +   
> >   +
> >   +  
> >
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
-- 
Cheers,
-bob


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New committer: Jean-Francois Arcand

[Bob Herrmann]

+1 !

On Tue, 2002-08-13 at 16:29, Patrick Luby wrote:
> I would like to propose that we add Jean-François Arcand as a Tomcat 
> committer. I believe he has submitted enough patches to show that he 
> will be a positive contributor to Tomcat 5.
> 
> Thanks,
> 
> Patrick
> 
> -- 
> 
> Patrick Luby Email: [EMAIL PROTECTED]
> Sun Microsystems Phone: 408-276-7471
> 901 San Antonio Road, USCA14-303
> Palo Alto, CA 94303-4900
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
-- 
Cheers,
-bob


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5] [PATCH] HttpSession.logout()

[Bob Herrmann]

This patch causes logout() and invalidate() to do the Servlet spec 2.4
"right thing."  I implemented it using the Data field of SessionEvent to
distinguish between logout/invalidate.

Can someone apply this?  THANKS.

Cheers,
-bob

On Sat, 2002-08-10 at 23:02, Bob Herrmann wrote:
> The servlet 2.4 spec adds a new method, "HttpSession.logout()";
> 
> How do we implement this?
> 
> For the non-single signon case, "logout()" is identical to
> "invalidate()"
> 
> For single signon, Tomcat currently uses a "single signon valve" which
> listens for "Session Destroy" events.  When a "Session Destroy" happens,
> all sessions are removed.  A "Session Destroy" happens now when either
> invalidate() or logout() happens.  For logout, everything is fine, for
> invalidate() - only the session for the current web app should be
> removed.
> 
> So, when a session logout() or invalidate() is called, what should
> happen?  A "Session Destroy" with extra data indicating a logout or
> invalidate occured?  Or should a new session event be created to
> indicate a "logout" is happening?
> 
> comments/ideas?
> 
> Cheers,
> -bob
> 
> 
> 
> 
> 
> -- 
> Cheers,
> -bob
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



Index: authenticator/SingleSignOn.java
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SingleSignOn.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 SingleSignOn.java
--- authenticator/SingleSignOn.java	18 Jul 2002 16:48:03 -	1.1.1.1
+++ authenticator/SingleSignOn.java	12 Aug 2002 18:34:52 -
@@ -293,6 +293,7 @@
 Session session = event.getSession();
 if (debug >= 1)
 log("Process session destroyed on " + session);
+
 String ssoId = null;
 synchronized (reverse) {
 ssoId = (String) reverse.get(session);
@@ -300,8 +301,22 @@
 if (ssoId == null)
 return;
 
-// Deregister this single session id, invalidating associated sessions
-deregister(ssoId);
+if ( event.getData() != null 
+ && "logout".equals( event.getData().toString() )) {
+
+log("X logout event on " + ssoId);
+
+// logout of all applications
+deregister(ssoId);
+
+} else {
+
+log("X invalidate of just one session " + ssoId + " " + session);
+
+// invalidate just one session
+deregister(ssoId, session);
+
+}
 
 }
 
@@ -442,6 +457,35 @@
 
 }
 
+/**
+ * Deregister the specified session.  If it is the last session,
+ * then also get rid of the single sign on identifier
+ *
+ * @param ssoId Single sign on identifier
+ * @param session Session to be deregistered
+ */
+private void deregister(String ssoId, Session session) {
+
+synchronized (reverse) {
+reverse.remove(session);
+}
+
+SingleSignOnEntry sso = lookup(ssoId);
+if ( sso == null )
+return;
+
+sso.removeSession( session );
+
+// see if we are the last session, if so blow away ssoId
+Session sessions[] = sso.findSessions();
+if ( sessions == null || sessions.length == 0 ) {
+synchronized (cache) {
+sso = (SingleSignOnEntry) cache.remove(ssoId);
+}
+}
+
+}
+
 
 /**
  * Deregister the specified single sign on identifier, and invalidate
@@ -449,7 +493,7 @@
  *
  * @param ssoId Single sign on identifier to deregister
  */
-void deregister(String ssoId) {
+private void deregister(String ssoId) {
 
 if (debug >= 1)
 log("Deregistering sso id '" + ssoId + "'");
@@ -459,6 +503,7 @@
 synchronized (cache) {
 sso = (SingleSignOnEntry) cache.remove(ssoId);
 }
+
 if (sso == null)
 return;
 
@@ -601,6 +646,16 @@
 results[sessions.length] = session;
 sessions = results;
 session.addSessionListener(sso);
+}
+
+public synchronized void removeSession(Session session) {
+Session[] nsessions = new Session[sessions.length - 1];
+for (int i = 0, j = 0; i < sessions.length; i++) {
+if (session == sessions[i])
+continue;
+nsessions[j++] = sessions[i];
+}
+sessions = nsessions;
 }
 
 public synchronized Session[] findSessions() {
Index: session/StandardSession.java
===

Re: [5.0] Build notes

[Bob Herrmann]

On Sun, 2002-08-11 at 11:25, Jayson Falkner wrote:
> I have been using the same thing. The only downside is the download 
> time, but, IMO it would be great to have this included and encouraged 
> for use with the Tomcat 5 build file.
> 
> Way to go Bob!

Thanks, although I just cut/pasted Ian Darwin's example.

It builds tomcat5 pretty well, but I would really like it if it also did
these things,

 - building "dist", start tomcat up
 - download and run watchdog and generate a report
 - If the report fails, then send an email to people who committed in
past 24 hours
 - run automatically every 24 hours.

Sort of a mini-gump.

Cheers,
-bob


> 
> Jayson Falkner
> [EMAIL PROTECTED]
> 
> Bob Herrmann wrote:
> > Yea, I liked your script, this one builds Tomcat 5.
> > 
> > BUILDING.TXT could almost just say "All you need is JDK1.4 and Ant1.5
> > then just type 'ant' and a working Tomcat 5 development tree is built.
> > (If you are behind a firewall, you may need to adjust proxy settings.)"
> > 
> > This should be cross platform (haven't tested it on Win32.)
> > 
> > Cheers,
> > -bob
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  >value=":pserver:[EMAIL PROTECTED]:/home/cvspublic"/>
> > 
> > 
> > 
> > 
> > 
> >  
> >  
> > 
> > 
> > 
> > 
> >  > cvsRoot="${cvsroot}"
> > dest="${apache.dir}"
> > />
> >  > cvsRoot="${cvsroot}"
> > dest="${apache.dir}"
> > />
> >  > cvsRoot="${cvsroot}"
> > dest="${apache.dir}"
> > />
> >  > cvsRoot="${cvsroot}"
> > dest="${apache.dir}"
> > />
> >  > cvsRoot="${cvsroot}"
> > dest="${apache.dir}"
> > />
> >  > cvsRoot="${cvsroot}"
> > dest="${apache.dir}"
> > />
> > 
> > 
> > 
> > 
> > 
> >  >  file="${base.path}/LICENSE" />
> > 
> >  >  target="download" />
> > 
> >  >  target="dist" />
> > 
> > 
> > 
> > 
> > 
> > On Tue, 2002-08-06 at 13:43, Ian Darwin wrote:
> > 
> >>On August 6, 2002 01:01 pm, you wrote:
> >>
> >>>The main thing missing is a target which sets up the CVS repositories,
> >>>so it's quite close to what we have now. Problem is, I'm not too happy
> >>>at the idea of doing that automatically.
> >>
> >>Trivial to do with Ant, but I agree, it's risky to automate this. OTOH if
> >>it's well documented what it's doing, people should be OK with it.
> >>
> >>Ian
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> >>value=":pserver:[EMAIL PROTECTED]:/home/cvspublic"/>
> >>
> >>
> >>
> >> 
> >>
> >>
> >>
> >>
> >> >>cvsRoot="${cvs.root}"
> >>dest="${apache.dir}"
> >>/>
> >> >>cvsRoot="${cvs.root}"
> >>dest="${apache.dir}"
> >>/>
> >> >>cvsRoot="${cvs.root}"
> >>dest="${apache.dir}"
> >>/>
> >>
> >>
> >>
> >>--
> >>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> >>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> > 
> > 
> > 
> > 
> > --
> > To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> > 
> > 
> > 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
Cheers,
-bob


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

[5] new method, HttpSession.logout()

[Bob Herrmann]

The servlet 2.4 spec adds a new method, "HttpSession.logout()";

How do we implement this?

For the non-single signon case, "logout()" is identical to
"invalidate()"

For single signon, Tomcat currently uses a "single signon valve" which
listens for "Session Destroy" events.  When a "Session Destroy" happens,
all sessions are removed.  A "Session Destroy" happens now when either
invalidate() or logout() happens.  For logout, everything is fine, for
invalidate() - only the session for the current web app should be
removed.

So, when a session logout() or invalidate() is called, what should
happen?  A "Session Destroy" with extra data indicating a logout or
invalidate occured?  Or should a new session event be created to
indicate a "logout" is happening?

comments/ideas?

Cheers,
-bob





-- 
Cheers,
-bob


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Build notes

[Bob Herrmann]

Yea, I liked your script, this one builds Tomcat 5.

BUILDING.TXT could almost just say "All you need is JDK1.4 and Ant1.5
then just type 'ant' and a working Tomcat 5 development tree is built.
(If you are behind a firewall, you may need to adjust proxy settings.)"

This should be cross platform (haven't tested it on Win32.)

Cheers,
-bob














 
 

























On Tue, 2002-08-06 at 13:43, Ian Darwin wrote:
> On August 6, 2002 01:01 pm, you wrote:
> > The main thing missing is a target which sets up the CVS repositories,
> > so it's quite close to what we have now. Problem is, I'm not too happy
> > at the idea of doing that automatically.
> 
> Trivial to do with Ant, but I agree, it's risky to automate this. OTOH if
> it's well documented what it's doing, people should be OK with it.
> 
> Ian
> 
> 
> 
>   
> 
>   
>   
>  value=":pserver:[EMAIL PROTECTED]:/home/cvspublic"/>
> 
>   
>   
>
>   
> 
>   
> 
>  cvsRoot="${cvs.root}"
>   dest="${apache.dir}"
>   />
>  cvsRoot="${cvs.root}"
>   dest="${apache.dir}"
>   />
>  cvsRoot="${cvs.root}"
>   dest="${apache.dir}"
>   />
>   
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5][PATCH] tomcat5.coyote not getting compiled

[Bob Herrmann]

A change made last night to coyote/build.xml stopped the tomcat5
directory of coyote from building.  This change fixes this.  (Thanks to
Ryan Lubke for pointing this out.)

Cheers,
-bob



Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/coyote/build.xml,v
retrieving revision 1.12
diff -u -r1.12 build.xml
--- build.xml	9 Aug 2002 12:55:01 -	1.12
+++ build.xml	9 Aug 2002 15:46:59 -
@@ -241,7 +241,7 @@
   
 
   
 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5.0] [PATCH] I18N, CharsetMapper, DeploymentDescriptor

[Bob Herrmann]

In the Servlet 2.4 spec section 5.4 on i18n, the deployment descriptor
gets new stuff for mapping locale to character encoding. The spec says,

[Servlet 2.4, Section 5.4] "[...] The setLocale method also sets charset
component in Content-Type with an encoding information which can be
obtained from the locale-encoding-mapping element in the deployment
descriptor, if present. For example, to map a locale to the specific
encoding, the syntax of locale-encoding-mapping would be:

   

 ja
 ISO-2022-JP


" 

To implement this, I did this,

1. I added some lines to the digester to push the local and encoding
info into the Context 

2. I changed the Context to push the mapping into the CharsetMapper
class 

3. Changed the CharsetMapper class so it can accept new mappings 

4. changed CoyoteResponse.setLocale() so it consults CharsetMapper and
sets the mapped encoding

What do people think? (I used some long method names on Context and
CharsetMapper to make it clear that the information is coming from the
Deployment Descriptor.)  Can someone review and patch this?

Cheers,
-bob




Index: coyote/src/java/org/apache/coyote/Response.java
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java,v
retrieving revision 1.12
diff -u -r1.12 Response.java
--- coyote/src/java/org/apache/coyote/Response.java	1 Aug 2002 17:20:36 -	1.12
+++ coyote/src/java/org/apache/coyote/Response.java	8 Aug 2002 19:13:47 -
@@ -455,8 +455,6 @@
 if (isCommitted())
 return;
 
-characterEncoding = charset;
-
 String type = this.contentType;
 int start = type.indexOf("charset=");
 if ( start != -1 ) {
@@ -468,8 +466,11 @@
 type = type.substring(0,start+8)
 +charset;
 this.contentType = type;
-
+} else {
+type += "charset=" + charset;
 }
+setContentType( type );
+
 }
 
 public String getCharacterEncoding() {
Index: coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java,v
retrieving revision 1.2
diff -u -r1.2 CoyoteResponse.java
--- coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java	8 Aug 2002 04:08:41 -	1.2
+++ coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java	8 Aug 2002 19:13:49 -
@@ -753,6 +753,12 @@
 
 coyoteResponse.setLocale(locale);
 
+CharsetMapper cm = context.getCharsetMapper();
+String charset = cm.getCharset( locale );
+
+if ( charset != null )
+setCharacterEncoding( charset);
+
 }
 
 


Index: catalina/src/share/org/apache/catalina/Context.java
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Context.java,v
retrieving revision 1.2
diff -u -r1.2 Context.java
--- catalina/src/share/org/apache/catalina/Context.java	2 Aug 2002 01:37:42 -	1.2
+++ catalina/src/share/org/apache/catalina/Context.java	8 Aug 2002 21:22:46 -
@@ -481,6 +481,15 @@
 
 
 /**
+ * Add a Locale Encoding Mapping (see Sec 5.4 of Servlet spec 2.4)
+ *
+ * @param locale locale to map an encoding for
+ * @param encoding encoding to be used for a give locale
+ */
+public void addLocaleEncodingMappingParameter(String locale, String encoding);
+
+
+/**
  * Add a local EJB resource reference for this web application.
  *
  * @param ejb New local EJB resource reference
Index: catalina/src/share/org/apache/catalina/core/StandardContext.java
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.2
diff -u -r1.2 StandardContext.java
--- catalina/src/share/org/apache/catalina/core/StandardContext.java	2 Aug 2002 01:37:43 -	1.2
+++ catalina/src/share/org/apache/catalina/core/StandardContext.java	8 Aug 2002 21:22:53 -
@@ -1508,6 +1508,17 @@
 
 
 /**
+ * Add a Locale Encoding Mapping (see Sec 5.4 of Servlet spec 2.4)
+ *
+ * @param locale locale to map an encoding for
+ * @param encoding encoding to be used for a give locale
+ */
+public void addLocaleEncodingMappingParameter(String locale, String encoding){
+getCharsetMapper().addCharsetMappingFromDeploymentDescriptor(locale, encoding);
+}
+
+
+/**
  * Add a local EJB resource reference for this web application.
  *
  * @param ejb New EJB resource reference
Index: catalina/src/share/org/apache/catalina/startup/WebRuleSet.java
===

[5.0] Build notes

[Bob Herrmann]

Hi.  Just thought I would share the steps I followed to "Build tomcat 5"
on a RedHat 7.2 box.  The box is net connected via DSL.

I had already downloaded JDK1.4 and Ant1.5

$ mkdir tc5
$ cd tc5
$ export JAVA_HOME=/usr/java/j2sdk1.4.0
$ export PATH=$JAVA_HOME/bin:$PATH:/home/bob/tc5/jakarta-ant-1.5/bin
$ cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login
$ cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic checkout
jakarta-tomcat-5 jakarta-tomcat-connectors jakarta-tomcat-jasper
jakarta-servletapi-5 jakarta-tomcat-catalina
$ cd jakarta-tomcat-5
$ sed -e
's/^base.path=\/usr\/local$/base.path=\/home\/test\/tc5\/dependson/'
build.properties.default > t
$ mv t build.properties.default 
$ mkdir /home/bob/tc5/dependson
$ echo >  /home/bob/tc5/dependson/LICENSE
$ ant download
$ ant dist
$ dist/bin/startup.sh 
$ tail /home/bob/tc5/jakarta-tomcat-5/dist/logs/catalina.out


Cheers,
-bob


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5] New Coyote Branch

[Bob Herrmann]

So to ensure I understand, the "New Coyote Branch" means

Adding to repository "jakarta-tomcat-connectors" a directory;

  coyote/src/java/org/apache/coyote5/

which initially is a copy of 

  coyote/src/java/org/apache/coyote4/

and in coyote5 the Request and Response classes implement the interfaces
in "jakarta-servletapi-5" and build.xml conditionally compiles the right
thing and some factory somewhere knows which classes to switch in? (When
being used at runtime by tomcat 5.)

I am looking to add methods login(Username,Password), login(X590Cert..),
logout() to the Request class (and jakarta-serveletapi-5) as per the
Serlvet 2.4 working groups latest recommendation.  I will also move the
"setCharacterEncoding()" and "getContentType()" to the tomcat5 (and out
of tomcat4) if I understand this all correctly.

Cheers,
-bob




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH] [5.0] servletapi5, connectors, catalina

[Bob Herrmann]

Hi. The Servlet 2.4 spec says that ServletResponse now gets two more
methods, (from sections 5.4, 14.2.22) Namely;

String getContentType();
void   setCharacterEncoding(String charset) 

To implement this, I patched 3 repositories jakarta-servletapi-5,
jakarta-tomcat-connectors, jakarta-tomcat-catalina

I tested the "connectors" patch against 4.0 and my changes don't seem to
break 4.0 (and so dont require messing with forking connectors.)

Cheers,
-bob

P.S. The servletapi is still sprinkled with tabs.  I tried to preserve
the current tabbing (and not change all to spaces per jakarta rule(?))







? apipatch.txt
Index: src/share/javax/servlet/ServletResponse.java
===
RCS file: 
/home/cvspublic/jakarta-servletapi-5/src/share/javax/servlet/ServletResponse.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 ServletResponse.java
--- src/share/javax/servlet/ServletResponse.java16 Jul 2002 16:38:40 - 
 1.1.1.1
+++ src/share/javax/servlet/ServletResponse.java1 Aug 2002 16:03:09 -
@@ -122,6 +122,16 @@
   
 public String getCharacterEncoding();
 
+/**
+ * Overrides the name of the character encoding used in the body
+ * of the request. This method must be called prior to reading
+ * request parameters or reading input using getReader().
+ *
+ * @param charset String containing the name of the chararacter encoding.
+ *
+ */
+  
+public void setCharacterEncoding(String charset);
 
 
 /**
@@ -223,6 +233,24 @@
  */
 
 public void setContentType(String type);
+
+/**
+ * Returns the MIME type of the body of the request, or null if
+ * the type is not known. For HTTP servlets, same as the value of
+ * the CGI variable CONTENT_TYPE.
+ *
+ * @return a String containing the name of the MIME type of the
+ * request, or null if the type is not known
+ * 
+ *  The content type may include the type of character
+ * encoding used, for example, text/html; charset=ISO-8859-4.
+ *
+ * @see#getOutputStream
+ * @see#getWriter
+ *
+ */
+
+public String getContentType();
 
 
 /**
Index: src/share/javax/servlet/ServletResponseWrapper.java
===
RCS file: 
/home/cvspublic/jakarta-servletapi-5/src/share/javax/servlet/ServletResponseWrapper.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 ServletResponseWrapper.java
--- src/share/javax/servlet/ServletResponseWrapper.java 16 Jul 2002 16:38:40 - 
 1.1.1.1
+++ src/share/javax/servlet/ServletResponseWrapper.java 1 Aug 2002 16:03:10 -
@@ -74,7 +74,7 @@
  * 
  * @author Various
  * @version$Version$
-  * @since v 2.3
+ * @since  v 2.3
  *
  * @seejavax.servlet.ServletResponse
  *
@@ -117,16 +117,25 @@
this.response = response;
}
 
- /**
- * The default behavior of this method is to return getCharacterEncoding()
+/**
+ * The default behavior of this method is to call setCharacterEncoding(String 
+charset)
  * on the wrapped response object.
  */
 
+public void setCharacterEncoding(String charset) {
+   this.response.setCharacterEncoding(charset);
+}
+
+/**
+ * The default behavior of this method is to return getCharacterEncoding()
+ * on the wrapped response object.
+ */
 
 public String getCharacterEncoding() {
return this.response.getCharacterEncoding();
}
 
+
  /**
  * The default behavior of this method is to return getOutputStream()
  * on the wrapped response object.
@@ -162,6 +171,15 @@
 
 public void setContentType(String type) {
this.response.setContentType(type);
+}
+
+/**
+ * The default behavior of this method is to return getContentType()
+ * on the wrapped response object.
+ */
+
+public String getContentType() {
+   return this.response.getContentType();
 }
 
 /**
Index: src/share/javax/servlet/http/HttpServlet.java
===
RCS file: 
/home/cvspublic/jakarta-servletapi-5/src/share/javax/servlet/http/HttpServlet.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 HttpServlet.java
--- src/share/javax/servlet/http/HttpServlet.java   16 Jul 2002 16:38:40 - 
 1.1.1.1
+++ src/share/javax/servlet/http/HttpServlet.java   1 Aug 2002 16:03:12 -
@@ -890,8 +890,14 @@
didSetContentLength = true;
 }
 
+public void setCharacterEncoding(String charset)
+  { resp.setCharacterEncoding(charset); }
+
 public void setContentType(String type)
   { resp.setContentType(type); }
+
+public String getContentType()
+  { return resp.getContentType(); }
 
 public ServletOutputStream getOutputStream() throws IOException
   { return noBody; }


Ind

[PATCH] [5.0] jakarta-servletapi-5

[Bob Herrmann]

The 2.4 Servlet spec adds a new constant. See section 15.1.5 in the June
24th public draft. 

Cheers,
-bob

 



Index: src/share/javax/servlet/http/HttpServletResponse.java
===
RCS file: /home/cvspublic/jakarta-servletapi-5/src/share/javax/servlet/http/HttpServletResponse.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 HttpServletResponse.java
--- src/share/javax/servlet/http/HttpServletResponse.java	16 Jul 2002 16:38:41 -	1.1.1.1
+++ src/share/javax/servlet/http/HttpServletResponse.java	31 Jul 2002 14:07:12 -
@@ -445,9 +445,24 @@
  * Status code (302) indicating that the resource has temporarily
  * moved to another location, but that future references should
  * still use the original URI to access the resource.
+ *
+ * This definition is being retained for backwards compatibility.
+ * SC_FOUND is now the preferred definition.
  */
 
 public static final int SC_MOVED_TEMPORARILY = 302;
+
+/**
+* Status code (302) indicating that the resource reside
+* temporarily under a different URI. Since the redirection might
+* be altered on occasion, the client should continue to use the
+* Request-URI for future requests.(HTTP/1.1) To represent the
+* status code (302), it is recommended to use this variable.
+*
+*/
+
+public static final int SC_FOUND = 302;
+
 
 /**
  * Status code (303) indicating that the response to the request



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH] 5.0 jakarta-tomcat-5 building

[Bob Herrmann]

I had a near flawless build experience building tomcat 5.0.

I only had to reverse the "digester" and "commons-logging" in build.xml
This is because the "digester" now depends on "commons-logging"

Can someone please patch this in?  Thanks.

Cheers,
-bob

P.S. Should patch files be attached as mime-attachments?

P.P.S. Does my subject line correctly direct this message? 
   (Is there supposed to be a [5.0] first or [PATCH] or...)


Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-5/build.xml,v
retrieving revision 1.12
diff -u -r1.12 build.xml
--- build.xml   30 Jul 2002 22:13:49 -  1.12
+++ build.xml   31 Jul 2002 02:26:50 -
@@ -480,16 +480,6 @@
   
 
 
-
-  
-  
-  
-
-
-
 

Re: updated architecture document

[Bob Herrmann]

I found this useful, 

ABSTRACT:  This session covers the history of the Tomcat servlet
container, an open source project administered by the Apache Software
Foundation. The architecture and features of Tomcat 4.x are highlighted,
and plans for future development are discussed.

http://servlet.java.sun.com/javaone/conf/sessions/1287/0-sf2001.jsp

Cheers,
-bob


On Tue, 2002-07-30 at 14:29, Zhenxin wang wrote:
> Is there an updated architecture document (or a set of documents) that explains the 
>architecture of Tomcat 4? I only found some that seems to be out of dated. 
> 
> Thanks!
> 
> --Zhenxin Wang
> DoCoMo Labs USA



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] mbean-names [logging]

[Bob Herrmann]

On Mon, 2002-07-29 at 23:04, [EMAIL PROTECTED] wrote:
> On 29 Jul 2002, Bob Herrmann wrote:
> 
> > 
> > > Same should happen for Log, assuming we get the commons-logging
> > > to support JMX and add a wrapper for JDK1.4 ( for log4j
> > > we should just use their mbean ). I assume we all agree on
> > > moving to commons-logging as API, and keeping the old Logging
> > > interface only for backward compat. 
> > 
> > I just reviewed the tomcat 5.0 proposal, and I didn't notice anything
> > about logging changing in 5.0
> > 
> > Just so I understand this, the current use of  element
> > "will/should/encouraged to" disappear in 5.0 and instead modules will
> > directly call the commons-logging interface?   So if I want to log a
> > particular context/webapp or Host or Engine, I will have to figure out
> > what "domain" it logged to and get the underlying logging system (log4j,
> > JDK1.4, logkit) to filter out the webapp/Host/Engine I am interested in?
> 
> This has been discussed separately, and AFAIK nobody objected to the
> idea of using commons-logging in 5.0. It was proposed and accepted
> officially for jk and coyote, and even if no formal vote was made
> for 5.0 and jasper2 I assume it'll get a majority.
> 
> The  element and interfaces will not disapear - it'll remain
> for backward compat, just like the realm stuff. I assume the attributes
> will be passed to the commons-logging impl.


Just so I get an idea of the scale of changes.. Tomcat has a lot of code
that uses a pattern like this;

private void log(String message) {
Logger logger = null;
if (container != null)
logger = container.getLogger();
if (logger != null) {
logger.log(getName() + "[" + container.getName() + "]: "
   + message);
} else {
String containerName = null;
if (container != null)
containerName = container.getName();

System.out.println(getName() + "[" + containerName
   + "]: " + message);
}
}

Would the 5.0 logging look more like this ?? ( I am just changing the
System.out calls to instead defer to a commons-logging logger. )

private void log(String message) {
Logger logger = null;

if (container != null)
logger = container.getLogger();

if (logger != null) {
logger.log(getName() + "[" + container.getName() + "]: "
   + message);
} else {
String containerName = null;
if (container != null)
containerName = container.getName();

//import org.apache.commons.logging.Log;
//import org.apache.commons.logging.LogFactory;

Log log = LogFactory.getLog( containerName );

log.info( getName() + "[" + containerName
   + "]: " + message);
}
}

(Note that commons-logging is going to record the log method (and not
the caller's) method in the logging output)


> 
> My understanding is that we'll gradually start using commons-logging
> inside tomcat/jasper. So all components will use commons-logging, 
> and we'll have a mechanism to configure it per/webapplication ( or
> host, engine ). Ceki already has some support in log4j to support
> this, and we can try to do something similar in the jdk1.4 wrapper. 
> 
> The details for configuration are not yet clear - it depends a lot
> on the overal scheme and I assume on what we do for users, since the
> problem is very similar.

ok.

> 
> I like Craig's proposal for separate Users - and the Log can work the
> same. If you have ideas/sugestions about how to manage the loggers - 
> please post them. 5.0 is still at an early stage, but those things
> should be discussed sooner rather than later.
> 
> Of course, that's my understanding - I may be wrong.
>
>
> Costin




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [5.0] mbean-names

[Bob Herrmann]

> Same should happen for Log, assuming we get the commons-logging
> to support JMX and add a wrapper for JDK1.4 ( for log4j
> we should just use their mbean ). I assume we all agree on
> moving to commons-logging as API, and keeping the old Logging
> interface only for backward compat. 

I just reviewed the tomcat 5.0 proposal, and I didn't notice anything
about logging changing in 5.0

Just so I understand this, the current use of  element
"will/should/encouraged to" disappear in 5.0 and instead modules will
directly call the commons-logging interface?   So if I want to log a
particular context/webapp or Host or Engine, I will have to figure out
what "domain" it logged to and get the underlying logging system (log4j,
JDK1.4, logkit) to filter out the webapp/Host/Engine I am interested in?

Cheers,
-bob


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [logging] Redirecting System.out to JDK1.4 Logging for tomcat

[Bob Herrmann]

On Thu, 2002-07-25 at 07:13, Remy Maucherat wrote:
> Bob Herrmann wrote:
> > I don't know if anyone else will find this interesting, but I wrote a
> > class which redirects System.Out to JDK1.4 Logging.  It is Tomcat 
> > aware and unrolls the stack in a way useful for Tomcat.  This might be
> > useful if you are embedding Tomcat.
> > 
> > I changed catalina.sh to start my class, it then invokes Bootstrap.
> > 
> > Any comments?
> 
> AFAIK, Glenn used the Jasper sys.out redirector (and put it in 
> j-t-c/util) to do that. It doesn't redirect everything, but I believe it 
> redirects everything significant.
> 
> The advantages are:
> - It then redirects to one of the Catalina loggers
> - It doesn't depend on JDK 1.4

True.  My approach is tuned for 2 things,
 - utilizing JDK 1.4 logging 
 - unrolling the Tomcat stack in a way to get to "interesting bits of
stack"

You are right that this isn't something everyone would want.  If you are
trying to get Tomcat to log though JDK 1.4, then my approach might be
useful.  

The stack unrolling is helpful, IMHO, because it helps to identify which
class and method called the logger.  

I would like to have used commons-logging to get to JDK1.4's backend. 
Alas commons-logging doesn't support arbitrary stack unrolling
methods... And Tomcat has a lot of log wrappers

$ cd jakarta-tomcat-4.0
$ grep -i 'log(' `find . -name *.java `|grep void|cut -f1
-d:|sort|uniq|wc -l
 65

To migrate to commons-logging, it looks like at least 65 classes need to
be adjusted.  I presume this will take awhile.  Using my approach is a
quick stop gap.   Perhaps Tomcat 5 will embrace the migration to
commons-logging.

Cheers,
-bob

Related Thread:
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg28257.html



> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

[logging] Redirecting System.out to JDK1.4 Logging for tomcat

[Bob Herrmann]

I don't know if anyone else will find this interesting, but I wrote a
class which redirects System.Out to JDK1.4 Logging.  It is Tomcat 
aware and unrolls the stack in a way useful for Tomcat.  This might be
useful if you are embedding Tomcat.

I changed catalina.sh to start my class, it then invokes Bootstrap.

Any comments?

Cheers,
-bob







? patch.txt
? catalina/src/share/org/apache/catalina/startup/Tomcat2Jdk14Log.java
Index: catalina/build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.124
diff -r1.124 build.xml
1073a1074
> 
Index: catalina/src/bin/catalina.sh
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/bin/catalina.sh,v
retrieving revision 1.31
diff -r1.31 catalina.sh
209c209
<   org.apache.catalina.startup.Bootstrap "$@" start \
---
>   org.apache.catalina.startup.Tomcat2Jdk14Log "$@" start \




package org.apache.catalina.startup;

import java.io.OutputStream;
import java.io.IOException;
import java.io.PrintStream;

import java.util.logging.Level;
import java.util.logging.Logger;

/* This class takes StandardOut and redirects it to the Jdk1.4 Logger.
 * It attempts to walk the stack in a way that is meaningful for Tomcat
 */

public class Tomcat2Jdk14Log extends OutputStream {

public static void main(String args[]) {
	PrintStream ps = ( new PrintStream( new Tomcat2Jdk14Log("SysOut", Level.INFO ) ) ); 
	System.setOut( ps );

	ps = (new PrintStream( new Tomcat2Jdk14Log("SysErr", Level.WARNING ) ) );
	// Humm... this causes an exception to start to be printed..
	//perhaps a re-entrant issue?
	//System.setErr(ps);

	// just passing through
	Bootstrap.main(args);
}

private StringBuffer sb = new StringBuffer();
private Level level;
private Logger jlog;

// some platforms use 1 char for newline, others use 2
private int preNewlineChar = -1;
private int newlineChar;

private Tomcat2Jdk14Log( String logName, Level level ){
	this.level = level;
	jlog = Logger.getLogger(logName);

String newline = System.getProperty( "line.separator" );
if ( newline.length() == 2 ) {
preNewlineChar = newline.charAt(0);
newlineChar = newline.charAt(1);
} else {
newlineChar = newline.charAt(0);
}
}


// should this be syncronized?
public void write(int x) throws java.io.IOException {
if ( x != newlineChar ) {
sb.append( (char)x );
	return;
}

	// deal with Windows/Unix newline stuff
	if ( preNewlineChar != -1
	 && sb.length() > 1 
	 && sb.charAt( sb.length() -1 ) == preNewlineChar) {
	sb.deleteCharAt( sb.length() -1 );
	}

	// get stack trace.  This is quite slow.  If method/classnames
	// arent needed this should be turned off
	StackTraceElement locations[] = new Throwable().getStackTrace();

	String cname="unknown";
	String method="unknown";
	boolean foundLogger = false;
	String myClassName = this.getClass().getName();

	// Stratagy for finding an "Interesting" tomcat stackframe
	for (int i=3;i< locations.length;i++ ) {
	StackTraceElement caller=locations[i];

	cname=caller.getClassName();
	if ( !foundLogger ){
		// PHASE I: find the tomcat logger (we assume different platforms might
		// have different levels of stack... so we whirl through until we see
		// something we recognize. )
		if ( !cname.equals( "org.apache.tomcat.util.log.SystemLogHandler" ))
		continue;
		foundLogger = true;
		continue;
	}

	method=caller.getMethodName();
	// PHASE II: get rid of wrappers on top of the wrapper
	if ( method.equals("log") || method.equals("internalLog") )
		continue;

	// add line # for fun.
	method += ":"+caller.getLineNumber();
	break;
	}

	jlog.logp( level, cname, method, sb.toString() );

	sb = new StringBuffer(200);
}


}



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [logging] Better support for stack walking

[Bob Herrmann]

Hi.  This patch to commons logging allow you to specify which methods
in the call stack are uninteresting when using the JDK1.4 Logger. In
Tomcat this seems to be all methods named "log" and "internalLog."  This
is based on Costin's idea of uninteresting classes, but seems to work
better for method names (in Tomcat anyway.)

It is something of a back door.  It is primarily for projects that
are in the process of converting to using commons-logging.

You use it like this,

LogFactory.getFactory().setAttribute(
   "commons-logging.wrapperMethods",
   "log,internalLog" );

Log log = LogFactory.getLog( "Logger'sName" );

log.info("Hello World");
 

Is this an acceptable change to commons-logging ?

Cheers,
-bob

P.S. this patch is updated from the one posted to tomcat-dev



On Tue, 2002-07-23 at 15:03, Bob Herrmann wrote:
> On Mon, 2002-07-22 at 14:18, [EMAIL PROTECTED] wrote:
> > 
> > I think there is a simpler solution for this class of problems, and 
> > that would also work with log4j and doesn't require _any_ API
change.
> > ( only changes to the adapter implementations )
> > 
> > Any 'wrapper' will use:
> >   factory=LogFactory.getFactory();
> >
> >   factory.setAttribute( "commons-logging.wrapperClass", 
> > "[CLASSNAME-OF-WRAPPER]");
> >   factory.getLog(), etc.
> 



On Tue, 2002-07-23 at 15:46, [EMAIL PROTECTED] wrote:
> > 1.  For Log4J at least, the wrapper class is 'given' to the logger 
> > implementation via a constructor argument.
> 
> No, it is passed on each call. Log4j is the easiest, it has all the 
> support we need. 
> 
> > 1.a.  Log.setLogWrapper/setAttribute isn't enough.  Putting aside 
> > design/style arguments, it's to late.  Granted this COULD be worked around 
> 
> The only reason for setAttribute on Log is that if we set the
> wrapper on the factory, this will be 'global'. In tomcat we have 
> 2-3 wrappers that are used - and if each will use commons-logging
> we'll need to do some tricks.
> 
> > 2.  In an environment where we have multiple components using 
> > commons-logging, some may wrap - others may not.  A Factory.setAttribute 
> > is dangerous here (it's potentially 'global' across multiple components). 
> > Note also the the attributes are (pre-)loaded out of a properties file.
> 
> I agree.
> 
> 
> > 3.  We need an analogous method (setWrapper or setAttribute) for the 
> > Discovery mechanism.  A requirement for 'setWrapper' would seem to be 
> > fairly specific to logging, it doesn't appear to be generally useful in a 
> > 'discovery' tool.
> 
> I don't think so - this is very specific to logging, it has 
> nothing to do with discovery.
> 
> 
> > (2) is a strong vote for 'LogFactory.getInstance(Class wrapper, 
> > [String|Class] cat)', in addition to the current 'getInstance' methods - 
> > and a vote against a 'setAttribute' in a singleton (global) Factory.
> 
> I think setAttribute on Log would solve (2).
> 
> Costin
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



Index: src/java/org/apache/commons/logging/impl/Jdk14Logger.java
===
RCS file: /home/cvspublic/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Jdk14Logger.java,v
retrieving revision 1.4
diff -u -r1.4 Jdk14Logger.java
--- src/java/org/apache/commons/logging/impl/Jdk14Logger.java	17 Jul 2002 16:42:40 -	1.4
+++ src/java/org/apache/commons/logging/impl/Jdk14Logger.java	23 Jul 2002 20:49:11 -
@@ -65,8 +65,11 @@
 
 import java.util.logging.Level;
 import java.util.logging.Logger;
+import java.util.Hashtable;
+import java.util.StringTokenizer;
 
 import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
 
 
 /**
@@ -95,6 +98,14 @@
 
 logger = Logger.getLogger(name);
 
+String wrapperMethods = (String) LogFactory.getFactory().getAttribute("commons-logging.wrapperMethods");
+if ( wrapperMethods != null ){
+StringTokenizer st = new StringTokenizer(wrapperMethods,",");
+while (st.hasMoreTokens()) {
+wrapperMethodsHash.put( st.nextToken(), "F" );
+}
+}
+
 }
 
 
@@ -106,6 +117,11 @@
  */
 protected Logger logger = null;
 
+/**
+ * The methods that we ignore in the stack trace
+ */
+private Hashtable 

[logging] [PATCH] JDK 1.4 Logging

[Bob Herrmann]

On Tue, 2002-07-23 at 15:03, Bob Herrmann wrote:
> On Mon, 2002-07-22 at 14:18, [EMAIL PROTECTED] wrote:
> > 
> > I think there is a simpler solution for this class of problems, and 
> > that would also work with log4j and doesn't require _any_ API change.
> > ( only changes to the adapter implementations )
> > 
> > Any 'wrapper' will use:
> >   factory=LogFactory.getFactory();
> >
> >   factory.setAttribute( "commons-logging.wrapperClass", 
> > "[CLASSNAME-OF-WRAPPER]");
> >   factory.getLog(), etc.
> 

Hi.  This patch to commons logging allow you to specify which methods
in the call stack are uninteresting when using the JDK1.4 Logger. In
Tomcat this seems to be all methods named "log" and "internalLog."  This
is based on Costin's idea of uninteresting classes, but seems to work
better for method names (in Tomcat anyway.)

It is something of a back door.  It is primarily for projects that
are in the process of converting to using commons-logging.

Is this an acceptable change to commons-logging ?

Cheers,
-bob

P.S. this patch is updated from the one posted to tomcat-dev



Index: src/java/org/apache/commons/logging/impl/Jdk14Logger.java
===
RCS file: /home/cvspublic/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Jdk14Logger.java,v
retrieving revision 1.4
diff -u -r1.4 Jdk14Logger.java
--- src/java/org/apache/commons/logging/impl/Jdk14Logger.java	17 Jul 2002 16:42:40 -	1.4
+++ src/java/org/apache/commons/logging/impl/Jdk14Logger.java	23 Jul 2002 20:49:11 -
@@ -65,8 +65,11 @@
 
 import java.util.logging.Level;
 import java.util.logging.Logger;
+import java.util.Hashtable;
+import java.util.StringTokenizer;
 
 import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
 
 
 /**
@@ -95,6 +98,14 @@
 
 logger = Logger.getLogger(name);
 
+String wrapperMethods = (String) LogFactory.getFactory().getAttribute("commons-logging.wrapperMethods");
+if ( wrapperMethods != null ){
+StringTokenizer st = new StringTokenizer(wrapperMethods,",");
+while (st.hasMoreTokens()) {
+wrapperMethodsHash.put( st.nextToken(), "F" );
+}
+}
+
 }
 
 
@@ -106,6 +117,11 @@
  */
 protected Logger logger = null;
 
+/**
+ * The methods that we ignore in the stack trace
+ */
+private Hashtable wrapperMethodsHash = new Hashtable();
+
 
 // - Public Methods
 
@@ -116,10 +132,17 @@
 // Caller will be the third element
 String cname="unknown";
 String method="unknown";
-if( locations!=null && locations.length >2 ) {
-StackTraceElement caller=locations[2];
-cname=caller.getClassName();
-method=caller.getMethodName();
+if( locations!=null && locations.length>2 ) {
+StackTraceElement caller=null;
+for (int stackLevel=2;stackLevel

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

[PATCH] Re: JDK 1.4 Logging

[Bob Herrmann]

On Mon, 2002-07-22 at 14:18, [EMAIL PROTECTED] wrote:
> 
> I think there is a simpler solution for this class of problems, and 
> that would also work with log4j and doesn't require _any_ API change.
> ( only changes to the adapter implementations )
> 
> Any 'wrapper' will use:
>   factory=LogFactory.getFactory();
>
>   factory.setAttribute( "commons-logging.wrapperClass", 
> "[CLASSNAME-OF-WRAPPER]");
>   factory.getLog(), etc.

Ok, I experimented some with this.  I found that the "wrapperMethod"
(namely looking for method names "log()" and "internalLog()") are more
effective than a classname for identifying "uninteresting" stack frames.

Seems Tomcat has 71 classes with a method named "log()" and often
logs messages from within the class itself.

The attached "patch.txt is the Change to commons.

The CommonsLogger.java is a new tomcat logger that sends output
to the commons-logger.

Does this look good?

Cheers,
-bob



> 
> The classname of wrapper will be passed to the impl..
> 
>  - for log4j - this just gets passed further, since log4j already supports 
> this feature.
>  - for jdk1.4 or other loggers who don't support wrapping - there is 
> already code in Jdk14Logger that walks the stack trace. Curently it
> uses a hard-coded '2 levels up', but it can use the wrapperClass
>  and walk up to find it.
> 
> 
> Costin
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 



/*
 * $Header: $
 * $Revision: $
 * $Date: $
 *
 * 
 *
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 1999 The Apache Software Foundation.  All rights
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The end-user documentation included with the redistribution, if
 *any, must include the following acknowlegement:
 *   "This product includes software developed by the
 *Apache Software Foundation (http://www.apache.org/)."
 *Alternately, this acknowlegement may appear in the software itself,
 *if and wherever such third-party acknowlegements normally appear.
 *
 * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
 *Foundation" must not be used to endorse or promote products derived
 *from this software without prior written permission. For written
 *permission, please contact [EMAIL PROTECTED]
 *
 * 5. Products derived from this software may not be called "Apache"
 *nor may "Apache" appear in their names without prior written
 *permission of the Apache Group.
 *
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
 * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 * 
 *
 * This software consists of voluntary contributions made by many
 * individuals on behalf of the Apache Software Foundation.  For more
 * information on the Apache Software Foundation, please see
 * .
 *
 * [Additional notices, if required by prior licensing conditions]
 *
 */


package org.apache.catalina.logger;

import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.LifecycleException;
import org.apache.catalina.LifecycleListener;
import org.apache.catalina.util.LifecycleSupport;
import org.apache.catalina.util.StringManager;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

/**
 * Implementation of Logger that appends log messages to the
 * Commons logger 
 *
 * @version $Revision: $ $Date: $
 */

public class CommonsLogger
extends LoggerBase
implements Lifecycle {


// - Instance Variables


/**
 * The descriptive information abou

Re: JDK 1.4 Logging

[Bob Herrmann]

On Mon, 2002-07-22 at 14:18, [EMAIL PROTECTED] wrote:
>...
> I think there is a simpler solution for this class of problems, and 
> that would also work with log4j and doesn't require _any_ API change.
> ( only changes to the adapter implementations )
> 
> Any 'wrapper' will use:
>   factory=LogFactory.getFactory();
>
>   factory.setAttribute( "commons-logging.wrapperClass", 
> "[CLASSNAME-OF-WRAPPER]");
>   factory.getLog(), etc.
> 
> The classname of wrapper will be passed to the impl..
> 
>  - for log4j - this just gets passed further, since log4j already supports 
> this feature.
>  - for jdk1.4 or other loggers who don't support wrapping - there is 
> already code in Jdk14Logger that walks the stack trace. Curently it
> uses a hard-coded '2 levels up', but it can use the wrapperClass
>  and walk up to find it.

That is an interesting idea, although in my particular case, I walk
the stack a variable amount. Namely if the stack has method "log()" or
method "internalLog()" I keep unrolling the stack - this may not be
a great idea - but it gives good stack traces without changing
other parts of tomcat.

If a webapp wants to use its own logger wrapper, and the factory
has a single attribute - would there be a conflict here?

-bob





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: JDK 1.4 Logging

[Bob Herrmann]

On Mon, 2002-07-22 at 13:00, [EMAIL PROTECTED] wrote:
> I'm close to -1 on this patch.
> 
> I think the right long-term solution is to use commons-logging in
> all tomcat and jasper, and stop defining our interfaces.
> 
> I am +1 on fixing commons-logger, this will probably be
> usefull for other packages that switch to commons-logger.

I agree.  I originally implemented a commons-logger logger, but
the result wasn't very satisfying.  Mostly when the commons-logger
uses JDK1.4 it always shows my logger's class and method name.

This could be fixed by adding these methods to Log of commons-logger

 void trace(Object msg, Throwable thr, String className, String method);
 void debug(Object msg, Throwable thr, String className, String method);
 void info(Object msg, Throwable thr, String className, String method);
 void warn(Object msg, Throwable thr, String className, String method);
 void error(Object msg, Throwable thr, String className, String method);
 void fatal(Object msg, Throwable thr, String className, String method);

Although, the bigger problem is all the Loggers have unique features
and trying to squeeze them through the commons-logger API is going to
result in impedance mismatch.  Not sure what to do about this.

I can take stab at this little change (although it means touching
just about every class in commons-logging.)  Is it worth it?  Votes?

Cheers,
-bob




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: JDK 1.4 Logging

[Bob Herrmann]

On Mon, 2002-07-22 at 12:37, Remy Maucherat wrote:
> 
> Assuming people actually like the JDK 1.4 logger and think it's useful, 
> I like that solution better (there are flags, use them).

The JDK Logger is pretty cool. Although the default output is pretty
plain. I use it with my own formatter. My formatter is tweaked for
Tomcat - so it condenses some information and colorizes some
information.

This is a sample of its output,

http://hue.jadn.com:81/~bob/xdmp.png

My formatter is attached. It assumes an Xterm window sized to 175 or so.

Cheers,
-bob





package com.jadn;

import java.util.logging.Formatter;
import java.util.logging.Level;
import java.util.logging.LogRecord;
import java.util.Date;
import java.sql.Timestamp;

/*

 designed for a XTERM window of withd 175 (or so)


 INSTALL
 compile it
 jar it (ie. jar cf jadn.jar com/jadn/XTermFormatter.class)
 install it (cp jadn.jar $JAVA_HOME/jre/lib/ext/jadn.jar

 edit $JAVA_HOME/jre/lib/logging.properties  and comment out the SimpleFormatter
and add this one in,

#java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
java.util.logging.ConsoleHandler.formatter = com.jadn.XTermFormatter

 enjoy
*/

public class XTermFormatter extends Formatter {
/*
	  0	Black
	  1	Red
	  2	Green
	  3	Yellow
	  4	Blue
	  5	Magenta
	  6	Cyan
	  7	White
*/

// colors foreground/background (for xterm)
private static final String RESET = "\033[0m"; 
private static final String BOLD  = "\033[1m";

private static final String BLACK_WHITE  = "\033[30;47m";
private static final String RED_WHITE= "\033[31;47m";
private static final String GREEN_WHITE  = "\033[32;47m";
private static final String YELLOW_WHITE = "\033[33;47m";
private static final String BLUE_WHITE   = "\033[34;47m";
private static final String PINK_WHITE   = "\033[35;47m";
private static final String LTGREEN_WHITE= "\033[36;47m";

public synchronized String format(LogRecord lr){
	StringBuffer sb = new StringBuffer();


	// --  LOG: LEVEL

	Level level = lr.getLevel();
	if ( level == level.SEVERE )
	sb.append( RED_WHITE );
	else if ( level == level.WARNING )
	sb.append( YELLOW_WHITE );
	else if ( level == level.INFO )
	sb.append( BOLD+GREEN_WHITE );
	else if ( level == level.CONFIG )
	sb.append( PINK_WHITE );
	else if ( level == level.FINE )
	sb.append( BLUE_WHITE );
	else 
	sb.append( BLACK_WHITE );

	fill( sb, level.toString(), 5 );
	sb.append( RESET );
	sb.append( " " );


	// --  LOG: TIME STAMP 

Timestamp ts = new Timestamp(lr.getMillis());
	// -mm-dd hh:mm:ss.f
	// 0123456789012345678
	//   1
sb.append( ts.toString().substring(11, 19) );



	// --  LOG: LOGGER DOMAIN (or name of logger)

	sb.append( " " );
	sb.append( PINK_WHITE );
	String lgName = lr.getLoggerName();
	if ( lgName.length()>15){
	sb.append( ">" );
	sb.append( lgName.substring(lgName.length()-14) );
	} else {
	fill(sb, lgName, 15);
	}
	sb.append( RESET );
	sb.append( " " );


	// --  LOG: SOURCE CLASS AND METHOD

	String cname = shorten(lr.getSourceClassName());

	int lastDot = cname.lastIndexOf('.');
	if ( lastDot == -1 ){
	cname=BLUE_WHITE+cname+RESET;
	} else {
	cname=cname.substring(0,lastDot)+BLUE_WHITE+cname.substring(lastDot)+RESET;
	}
	cname += "." + lr.getSourceMethodName();

	fill( sb, cname, 60 );
	sb.append( " " );



	// --  LOG: MESSAGE AND EXCEPTION

	sb.append( lr.getMessage() );
	if (lr.getThrown() != null ){
	sb.append( " " );
	sb.append( lr.getThrown() );
	}

sb.append("\n");
	return sb.toString();
}


// try and shorten known names
private String shorten(String cname){
	if ( cname.startsWith( "org.apache.catalina" ) )
	cname = "o.a.c"+cname.substring("org.apache.catalina".length());
	if ( cname.startsWith( "org.apache" ) )
	cname = "o.a"+cname.substring("org.apache".length());
	return cname;
}


// fill with spaces until supplied string reaches requested minLen 
// (longer strings are passed through without being chopped)
private void fill( StringBuffer sb, String toAdd, int minLen ){
	sb.append(toAdd);
	int fillTo = minLen - toAdd.length();
	while (fillTo-->0 )
	sb.append(" ");
}

}




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: JDK 1.4 Logging

[Bob Herrmann]

Humm...  How about this instead (not that I am lazy)?

$ cvs diff -u catalina/build.xml
Index: catalina/build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.124
diff -u -r1.124 build.xml
--- catalina/build.xml  29 Jun 2002 01:00:04 -  1.124
+++ catalina/build.xml  22 Jul 2002 16:31:07 -
@@ -801,6 +801,8 @@
unless="jdk.1.3.present"/>
   
+  
   
Bob,
> 
> This is a useful piece of code. However, your patch can't go into Tomcat 
> as it will only compile with JDK 1.4. The standard builds of Tomcat that 
> are downloadable from the jakarta.apache.org are built using JDK 1.3 and 
> should be run without crashing Tomcat on JDK 1.2.
> 
> So, if you would like this in Tomcat (and I think it would be a nice 
> optional logger implementation), I think that you need to do the following:
> 
> 1. Remove all of the following import statements and replace them with
> reflection calls so that the JDK 1.3 compiler can compile this class:
> 
> import java.util.logging.Logger;
> import java.util.logging.Level;
> import java.util.logging.Formatter;
> import java.util.logging.Handler;
> import java.util.logging.LogRecord;
> 
> 2. Catch any ClassNotFound and MethodNotFound exceptions that will occur
> when the code is run on JDK 1.2 or 1.3.
> 
> Patrick
> 
> 
> 
> 
> Bob Herrmann wrote:
> > Hi.  I am trying to get Tomcat to log to JDK1.4's logging.
> > 
> > I tried implementing a "o.a.c.logging.Logger" subclass that forwarded
> > calls to commons-logging Log.  This was unsatisfying because the
> > commons-logger unrolls the stack and logs the "class.method" of my
> > logger, not my logger's caller. 
> > 
> > I was tempted to change the commons-logger to allow for specifying
> > a class and method on all its methods, but that would be a large
> > change the commons-logger (involving changes and decisions about
> > how this new information should be pushed down and handled with
> > the other loggers it supports.)  There is also some issues mapping
> > tomcat verbosity levels, to common-logger log levels and then to JDK
> > Logger levels.
> > 
> > So I punted and implemented the code below.  It is a
> > "o.a.c.logging.Logger" which writes directly to JDK 1.4 Logging.
> > It allowed me to unroll the stack in a way that fits well with
> > tomcat (ignoring stack frames calling with method log() or method
> > internalLog() which are uninteresting.)  And allowed me to map
> > verbosity to JDK Levels.
> > 
> > Cheers,
> > -bob
> > 
> > 
> > 
> > 
> > 
> > 
> > /*
> >  * $Header: $
> >  * $Revision: $
> >  * $Date: $
> >  *
> >  * 
> >  *
> >  * The Apache Software License, Version 1.1
> >  *
> >  * Copyright (c) 1999 The Apache Software Foundation.  All rights
> >  * reserved.
> >  *
> >  * Redistribution and use in source and binary forms, with or without
> >  * modification, are permitted provided that the following conditions
> >  * are met:
> >  *
> >  * 1. Redistributions of source code must retain the above copyright
> >  *notice, this list of conditions and the following disclaimer.
> >  *
> >  * 2. Redistributions in binary form must reproduce the above copyright
> >  *notice, this list of conditions and the following disclaimer in
> >  *the documentation and/or other materials provided with the
> >  *distribution.
> >  *
> >  * 3. The end-user documentation included with the redistribution, if
> >  *any, must include the following acknowlegement:
> >  *   "This product includes software developed by the
> >  *Apache Software Foundation (http://www.apache.org/)."
> >  *Alternately, this acknowlegement may appear in the software itself,
> >  *if and wherever such third-party acknowlegements normally appear.
> >  *
> >  * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
> >  *Foundation" must not be used to endorse or promote products derived
> >  *from this software without prior written permission. For written
> >  *permission, please contact [EMAIL PROTECTED]
> >  *
> >  * 5. Products derived from this software may not be called "Apache"
> >  *nor

RE: JDK 1.4 Logging

[Bob Herrmann]

On Mon, 2002-07-22 at 12:12, David Oxley wrote:
> Why does Tomcat not use Log4j for its logging?

Some parts of Tomcat do use Log4j, other parts do not.  I think
this is because different people have just chosen whatever
they felt was handy.   Tomcat doesn't yet have a unified logging
strategy.  I originally tried to use "commons-logging" as my
back-end and it can be configured to use Log4j, but as I described -
the result was unsatisfying.

Read this earlier thread on this topic,

 http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg28257.html


Cheers,
-bob

> 
> Dave.
> 
> > -Original Message-
> > From: Bob Herrmann [mailto:[EMAIL PROTECTED]]
> > Sent: 22 July 2002 15:51
> > To: Tomcat Developers List
> > Subject: JDK 1.4 Logging
> > 
> > 
> > Hi.  I am trying to get Tomcat to log to JDK1.4's logging.
> > 
> > I tried implementing a "o.a.c.logging.Logger" subclass that forwarded
> > calls to commons-logging Log.  This was unsatisfying because the
> > commons-logger unrolls the stack and logs the "class.method" of my
> > logger, not my logger's caller.
> > 
> > I was tempted to change the commons-logger to allow for specifying
> > a class and method on all its methods, but that would be a large
> > change the commons-logger (involving changes and decisions about
> > how this new information should be pushed down and handled with
> > the other loggers it supports.)  There is also some issues mapping
> > tomcat verbosity levels, to common-logger log levels and then to JDK
> > Logger levels.
> > 
> > So I punted and implemented the code below.  It is a
> > "o.a.c.logging.Logger" which writes directly to JDK 1.4 Logging.
> > It allowed me to unroll the stack in a way that fits well with
> > tomcat (ignoring stack frames calling with method log() or method
> > internalLog() which are uninteresting.)  And allowed me to map
> > verbosity to JDK Levels.
> > 
> > Cheers,
> > -bob
> > 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

JDK 1.4 Logging

[Bob Herrmann]

Hi.  I am trying to get Tomcat to log to JDK1.4's logging.

I tried implementing a "o.a.c.logging.Logger" subclass that forwarded
calls to commons-logging Log.  This was unsatisfying because the
commons-logger unrolls the stack and logs the "class.method" of my
logger, not my logger's caller. 

I was tempted to change the commons-logger to allow for specifying
a class and method on all its methods, but that would be a large
change the commons-logger (involving changes and decisions about
how this new information should be pushed down and handled with
the other loggers it supports.)  There is also some issues mapping
tomcat verbosity levels, to common-logger log levels and then to JDK
Logger levels.

So I punted and implemented the code below.  It is a
"o.a.c.logging.Logger" which writes directly to JDK 1.4 Logging.
It allowed me to unroll the stack in a way that fits well with
tomcat (ignoring stack frames calling with method log() or method
internalLog() which are uninteresting.)  And allowed me to map
verbosity to JDK Levels.

Cheers,
-bob




/*
 * $Header: $
 * $Revision: $
 * $Date: $
 *
 * 
 *
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 1999 The Apache Software Foundation.  All rights
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The end-user documentation included with the redistribution, if
 *any, must include the following acknowlegement:
 *   "This product includes software developed by the
 *Apache Software Foundation (http://www.apache.org/)."
 *Alternately, this acknowlegement may appear in the software itself,
 *if and wherever such third-party acknowlegements normally appear.
 *
 * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
 *Foundation" must not be used to endorse or promote products derived
 *from this software without prior written permission. For written
 *permission, please contact [EMAIL PROTECTED]
 *
 * 5. Products derived from this software may not be called "Apache"
 *nor may "Apache" appear in their names without prior written
 *permission of the Apache Group.
 *
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
 * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 * 
 *
 * This software consists of voluntary contributions made by many
 * individuals on behalf of the Apache Software Foundation.  For more
 * information on the Apache Software Foundation, please see
 * .
 *
 * [Additional notices, if required by prior licensing conditions]
 *
 */


package org.apache.catalina.logger;

import java.sql.Timestamp;

import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.LifecycleException;
import org.apache.catalina.LifecycleListener;
import org.apache.catalina.util.LifecycleSupport;
import org.apache.catalina.util.StringManager;

import java.util.logging.Logger;
import java.util.logging.Level;
import java.util.logging.Formatter;
import java.util.logging.Handler;
import java.util.logging.LogRecord;


/**
 * Implementation of Logger that sends log messages to the
 * Jdk logger 
 *
 * @version $Revision: $ $Date: $
 */

public class JdkLogger
extends LoggerBase
implements Lifecycle {


// - Instance Variables


/**
 * The descriptive information about this implementation.
 */
protected static final String info =
"org.apache.catalina.logger.JdkLogger/1.0";

/**
 * The lifecycle event support for this component.
 */
protected LifecycleSupport lifecycle = new LifecycleSupport(this);

/**
 * The string manager for this package.
 */
pr

Doc fix "manager.xml"

[Bob Herrmann]

This patch makes the documentation reflect 4.1.x's behavior. Namely,
the only way to set the session timeout is via the webapp's web.xml
or the system wide web.xml  (also see bug 7613)

Cheers,
-bob

Index: manager.xml
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/webapps/tomcat-docs/config/manager.xml,v
retrieving revision 1.2
diff -u -r1.2 manager.xml
--- manager.xml 26 Sep 2001 01:38:08 -  1.2
+++ manager.xml 8 Jul 2002 13:38:27 -
@@ -62,10 +62,14 @@
 created by this Manager.  If not specified, the default value
is
 sixty (60) minutes.
 
-NOTE - The value for this property is
inherited
-automatically if you specify a

-element in the web application deployment descriptor
-(/WEB-INF/web.xml).
+NOTE - The value for this property is set
+automatically.  if you specify a
+ element in the web
+application deployment descriptor
+(/WEB-INF/web.xml), it is used, otherwise the
+system wide default from
+$TOMCAT_HOME/conf/web.xml is used.
+
   
 
 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Apache Tomcat 5.0 Proposal

[Bob Herrmann]

On Tue, 2002-07-02 at 19:57, Remy Maucherat wrote:
> After trying to address the concerns raised by the proposal draft, I 
> would like to call for a vote on it, now that the discussions have died 
> down.
> 
> 
> [X] +1 I support the proposal, and will help implement it
> [ ] +0 I support the proposal
> [ ] -0 I do not support the proposal
> [ ] -1 I am against the proposal being implemented, because:

Willing to help in any way I can.

Cheers,
-bob




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: SessionTimeout Problem

[Bob Herrmann]

This is an update to my earlier email.

Problem:  setting session timeouts in 4.1.x's server.xml is pointless.

Why: setting the Manager's attribute "maxInactiveInterval" or
Contexts's attribute "sessionTimeout" is pointless because they get
overwritten by the session timeout in the web.xml or if a web.xml is
not present or the timeout is not defined, the 30 minute default value
is taken from the config/web.xml defaults file.


Solution:  Not sure...  perhaps one of these...

1.  Remove the attributes from Manager and Context.  And update
the doc.

2.  Remove the default value of 30 from the config/web.xml and
update the doc for Manager to mention it can be overridden by
the web.xml

Ideas?

Cheers,
-bob


> Problem: setting the "maxInactiveInterval" on the Manager tag
> doesn't work.  
> 
> Why, well the problem is that two objects think they own the same
> information.  Namely, the Context and the session Manager both claim to
> own the SessionTimeout.
> 
> Each object has these properties.
> 
> Manager.maxInactiveInterval is the session timeout in "seconds"
> 
> Context.sessionTimeout is timeout in "minutes"
> 
> 
> The digester creates a Manager (and may correctly set it's
> maxInactiveInterval) and then binds it to a Container (Context.)  The
> Context overwrites the Manager's maxInactiveInterval with it's own
> sessionTimeout.  
> 
> Once bound to a container, the Manager watches the sessionTimeout
> property changes and adjusts its own maxInactiveInterval value to
> track it (Useful when the web.xml is processed and the digester updates
> the Context's sessionTimeout)
> 
> Not sure how to correctly proceed.  The Manager isn't bound to 
> a container when it's maxInactiveInterval is set by the digester,
> so it cant tell the Context to use its value. 
> 
> Any ideas?
> 
> Cheers
> -bob
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 

Cheers,
-bob

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

SessionTimeout Problem

[Bob Herrmann]

Problem: setting the "maxInactiveInterval" on the Manager tag
doesn't work.  

Why, well the problem is that two objects think they own the same
information.  Namely, the Context and the session Manager both claim to
own the SessionTimeout.

Each object has these properties.

Manager.maxInactiveInterval is the session timeout in "seconds"

Context.sessionTimeout is timeout in "minutes"


The digester creates a Manager (and may correctly set it's
maxInactiveInterval) and then binds it to a Container (Context.)  The
Context overwrites the Manager's maxInactiveInterval with it's own
sessionTimeout.  

Once bound to a container, the Manager watches the sessionTimeout
property changes and adjusts its own maxInactiveInterval value to
track it (Useful when the web.xml is processed and the digester updates
the Context's sessionTimeout)

Not sure how to correctly proceed.  The Manager isn't bound to 
a container when it's maxInactiveInterval is set by the digester,
so it cant tell the Context to use its value. 

Any ideas?

Cheers
-bob



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: JDBCStore implementation

[Bob Herrmann]

> Hi Bob,
> 
> Thanks for your answer!
> 
> Well, I agree that the refered field in the database would fit perfectly 
> in the case of having more than one instance of Tomcat handling requests, 
> but why can't it be used for the "local" session handling as well?
>
> 
> About what you wrote: "Once a session is marked invalid, my understanding 
> is that it only exists for the remaining scope of the page that marked it 
> invalid.". In my case I am not invalidating the session in any page, the 
> session is timed out by tomcat. And I had a simple test page in an 
> environment with a timeout for the session set to a low value (3 minutes). 

ok... a session is said to be "invalid" when marked invalid (by
calling session.invalidate() ) by a Servlet or JSP page.  When a
session is expired, it is also marked invalid, but it is immediately
removed from being accessible.  So the only time your code should be
able to manipulate a Session it should be in the valid state unless
your code explicitly marks it as invalid.

So writting an expired/invalidated session to the store would be
pointless because it is just about to be thrown away.  

> If I follow what tomcat is doing, these are the steps:
> 
> 1 - The session is backed up to the database (I set the value maxIdleBackup="10") 
>after nearly 10 seconds of inactivity.
> 2 - In my jsp page I check the methods session.isNew() = false, 
>request.isRequestedSessionIdValid() = true. This would be the expected 
> behavior.
> 3 - After the session is timed out by tomcat (I simply take no action 
> during 3 minutes), it is removed from the database.
> 4 - I try again to acess the same JSP page and the methods return session.isNew() = 
>true and request.isRequestedSessionIdValid() = false. 
> This would also be ok except for the fact that I have a NEW value for the 
> sessionID.

Yea, this seems correct.  Your old session times out after 3 minutes
and is disposed.  Your browswer then connects and is assigned a new
sesstion.  The old session was marked invalid for probably a few
miliseconds and then disposed of (or recycled.)

> With this behavior it is impossible to find out if I have a new
> session or an expired one. Maybe I am missing something here, but my
> idea was to redirect the user to a page telling him something like:
> "hi my friend, please login again because your session has
> expired". With the current implementation I am finding no solution
> to this.

You have a new session.  because request.isRequestedSessionIdValid() =
false, you know an older session is no longer available.   

To detect and handle a new/previously logged in user, You could do
something like this on your page,

if (session.isNew() && request.isRequestedSessionIdValid() == false ) {
response.sendRedirect("/relogin.jsp");
}

You should also do something to ensures your session (new or
otherwise) is cooked the way you want it, like
 
if( session.getAttribute("username") == null) { 
reponse.sendRedirect("/pleaseLogin.jsp");
}


or some such.

Cheers,
-bob

> Cheers,
> Daniel
> 
> 
> 
> 
> 
> [EMAIL PROTECTED]
> 24.06.2002 18:17
> Please respond to "Tomcat Developers List"
> 
>  
> To: [EMAIL PROTECTED]
> cc: 
> Subject:Re: JDBCStore implementation
> 
> 
> 
> 
> 
> 
> > Hello everyone,
> > 
> > I am writing about an issue on invalidation of sessions.
> > In the current implementation, a session is deleted from the Database 
> when 
> > it is invalidated. Is this really the behavior expected?
> 
> I have been looking over the code some, and I think that behavior is
> correct.  I think the DB schema was written with the thinking that
> that field may some day be useful when more than one instance of
> Tomcat is handling requests. 
> 
> > I mean, if there is an attribute to specify if a session is valid or 
> not, 
> > a session that is invalidated should have this attribute reset instead 
> of 
> > being deleted, isn't it? If this is not true, it is not possible to see 
> > difference between a session that is not valid anymore and a new one.
> 
> Once a session is marked invalid, my understanding is that it only
> exists for the remaining scope of the page that marked it invalid.
> 
> I think if you have a page with 2 frames in it, and one of the 
> frames marks the session as invalid, the other frame might get;
> 
>   * a valid session until it is marked invalid by the other page
>  or
>   * a new session
> 
> depending on the race condition of the browser and webserver loading
> both frames.
> 
> Cheers,
> -bob
> 
> 
> > Can anyone tell me something about the plans for the implementation of 
> > this feature?
> > 
> > Cheers,
> > Daniel
> > 
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> > 
> 
> Cheers,
> -bob
> 
> --
> To unsubscribe, e-mail:   
> 

Re: [PROPOSAL] When Session Max reached, throw out oldest session

[Bob Herrmann]

On Thu, 2002-06-13 at 03:43, Kief Morris wrote:
> [EMAIL PROTECTED] typed the following on 05:22 PM 6/12/2002 -0400
> >PROPOSAL:  When Session Max reached, throw out oldest session
> ...
> >1. When the maximum number of sessions is reached, change
> >StandardManager from throwing an IllegalStateException exception, to
> >expiring the Least Recently Used (LRUMap) session.
> 
> I'm not 100% comfortable with this, if a server sets the max sessions
> too low and gets a lot of activity, the behavior will be confusing - users
> will unexpectedly lose logins or whatever their session data is, and it
> might be taken for a bug by the administrator. I guess I'll be happy as 
> long as we log a warning when sessions are thrown out due to max 
> sessions being exceeded.

Good idea, I will be sure to log the expiration event, and I will also
ensure that the admin documentation is updated to explain this behavior.

Cheers,
-bob


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Releases + Jasper 1 removal from HEAD

[Bob Herrmann]

On Wed, 2002-06-05 at 21:30, Remy Maucherat wrote:
> 1) I plan to release a new version of Coyote to pick up the fixes to Tomcat
> 3.3 (it looks like I'll pick up some JMX features at the same time ;-)). 1.0
> RC 3.

> 2) I also plan to (finally) tag 4.0.4 Stable later this evening or tomorrow.
> Does anyone have some more last minute changes that should go in ?
> (hopefully not :))

> 3) We could consider removing the Jasper 1 sources from the HEAD branch of
> jakarta-tomcat-4.0. Jasper 1 is obsolete, and is not included in the Tomcat
> 4.1.x distributions.

+1

Good idea, I was building 4.1.x with Jasper 1 for a few days without
realizing I needed to explicitly point it to Jasper 2.

Cheers
[EMAIL PROTECTED]




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

FYI: Building tomcat on SunOS 5.8 (RESEND)

[Bob Herrmann]

Just for the record, here are the steps I used over the past 2 days to
successfully build tomcat on a fresh SunOS 5.8 machine.

1. get J2SE 1.4
2. get ant 5.1Beta1 (grab zip format as SunOS tar is broken)
3. get a "cvs" binary for Sparc
4. configure "cvs" to access cvs.apache.org (I had to tunnel using ssh)
5. use cvs to pull down "jakarta-tomcat-4.0"
6. use cvs to pull down "jakarta-tomcat-connector"
7. use "ant download" to get other needed bits
- mkdir /usr/local; chmod a+wr /usr/local
- in the jakarta-tomcat-4.0/ dir, copy "build.properties.sample" to
  "build.properties" and enable proxy access (behind firewall here)
- do "ant download" to automatically grab needed packages into 
/usr/local
8. edit "jakarta-tomcat-4.0/build.xml" and add in this property

9. edit "jakarta-tomcat-4.0/build.xml" and
remove the "commons-dbcp" section, it doesnt seem to be compiling.
10. ant

BUILD SUCCESSFUL

Cheers,
[EMAIL PROTECTED]



--
To unsubscribe, e-mail:   
For additional commands, e-mail: