cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler JasperMangler.java

[costin]

costin  01/01/27 21:54:35

  Added:   src/share/org/apache/jasper JasperEngineContext.java
JasperOptionsImpl.java
   src/share/org/apache/jasper/compiler JasperMangler.java
  Log:
  JspInterceptor: adding support for all options supported by Jasper.
  
  This is a slightly bigger change - the Mangler, Options and EngineContext
  are moved out of JspInterceptor ( to respect the organization of
  jasper and CommandLineCompiler ).
  
  ( they were developed with JspInterceptor as an experimental way to
  speed up jsp execution - probably at the beggining of tomcat3.2 development,
  now the code is stable, there is no reason to play with the jasper liaison )
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat/src/share/org/apache/jasper/JasperEngineContext.java
  
  Index: JasperEngineContext.java
  ===
  /*
   * 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
   * .
   *
   */ 
  package org.apache.jasper;
  
  import javax.servlet.*;
  import javax.servlet.http.*;
  import org.apache.jasper.compiler.JspReader;
  import org.apache.jasper.compiler.ServletWriter;
  import org.apache.jasper.compiler.Compiler;
  
  import java.util.*;
  import java.io.*;
  import java.net.*;
  
  import org.apache.jasper.JspCompilationContext;
  
  /** Alternative implementation of JspCompilationContext ( in addition
  to the servlet and standalone ). Used by JspInterceptor - but
  it's in no way specific to tomcat.
  */
  public class JasperEngineContext implements JspCompilationContext {
  JspReader reader;
  ServletWriter writer;
  ServletContext context;
  ClassLoader loader;
  boolean isErrPage;
  String jspFile;
  String servletClassName;
  String servletPackageName;
  String servletJavaFileName;
  String contentType;
  Options options;
  
  String cpath;// for compiling JSPs.
  ServletContext sctx;
  String outputDir;
  
  public JasperEngineContext()
  {
  }
  
  public void setClassPath( String s ) {
cpath=s;
  }
  
  /**
   * The classpath that is passed off to the Java compiler. 
   */
  public String getClassPath() {
return cpath;
  }
  
  /**
   * Get the input reader for the JSP text. 
  

Re: Tomcat 4 CVS running a web app from a war file

[Remy Maucherat]

> Remy Maucherat wrote:
>
> Then those jar files and class files need to be in a directory that won't
possibly
> conflict with jasper if a user has a directory named "classes" in the root
of
> their context which contains JSP's.  Please use WEB-INF/lib and
WEB-INF/classes
> in the work dir context directory.

Good idea. Ok, I'll do that.

> > > Which takes precedence, the shadowed war file in
work/localhost/examples ?
> > > or the unarchived copy in webapps/examples?
> > >
> > > What is the expected behaviour of this feature if you drop a war file
in
> > > a webapp directory?  What if you update a war file?
> >
> > Note: Jasper is temporarily broken when running from a WAR.
>
> Ok, its broke.  But how is this supposed to work?  Inquiring minds want to
know.

Ok, here's the full story.
Up until very recently, ServletContext.getRealPath() was returning fake
paths when running from a WAR. Now, it's returning null (which is the
correct value according to the servlet spec). The problem is that Jasper
still has some parts which are written with the filesystem in mind, and it
doesn't expect to get a null value. So you get a NPE in the Parser.

Remy


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

Re: Tomcat 4 CVS running a web app from a war file

[Glenn Nielsen]

Remy Maucherat wrote:
> 
> > I updated Tomcat 4 which has the new code that allows running directly
> > from a WAR file.  A few comments about this.
> >
> > I will refer to the 'examples' context in my comments.
> >
> > The directory 'work/localhost/examples/classes is created for
> > the contents of 'webapps/examples/WEB-INF/classes.
> >
> > First, what if there were a directory named 'webapps/examples/classes'
> > which contained JSP pages, wouldn't this conflict with where you put
> > the WEB-INF classes?  Wouldn't it be better to put them
> > in work/localhost/examples/WEB-INF/classes ?
> >
> > Second, if a WAR is already unarchived in the webapp directory,
> > i.e. both examples.war and examples/ exists, why is the
> > 'work/localhost/examples/classes' directory created?
> 
> All this is created fro Jasper. The compiler (javac) needs to have real
> class files and real JARs on the HD. These files are *not* used for anything
> else.
> No classloading or resource loading occurs from there, so it won't conflict
> with other stuff in the webapp.
> 

Then those jar files and class files need to be in a directory that won't possibly
conflict with jasper if a user has a directory named "classes" in the root of
their context which contains JSP's.  Please use WEB-INF/lib and WEB-INF/classes
in the work dir context directory.

> > Which takes precedence, the shadowed war file in work/localhost/examples ?
> > or the unarchived copy in webapps/examples?
> >
> > What is the expected behaviour of this feature if you drop a war file in
> > a webapp directory?  What if you update a war file?
> 
> Note: Jasper is temporarily broken when running from a WAR.
> 


Ok, its broke.  But how is this supposed to work?  Inquiring minds want to know.

Thanks,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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

Re: Tomcat 4 CVS running a web app from a war file

[Remy Maucherat]

> I updated Tomcat 4 which has the new code that allows running directly
> from a WAR file.  A few comments about this.
>
> I will refer to the 'examples' context in my comments.
>
> The directory 'work/localhost/examples/classes is created for
> the contents of 'webapps/examples/WEB-INF/classes.
>
> First, what if there were a directory named 'webapps/examples/classes'
> which contained JSP pages, wouldn't this conflict with where you put
> the WEB-INF classes?  Wouldn't it be better to put them
> in work/localhost/examples/WEB-INF/classes ?
>
> Second, if a WAR is already unarchived in the webapp directory,
> i.e. both examples.war and examples/ exists, why is the
> 'work/localhost/examples/classes' directory created?

All this is created fro Jasper. The compiler (javac) needs to have real
class files and real JARs on the HD. These files are *not* used for anything
else.
No classloading or resource loading occurs from there, so it won't conflict
with other stuff in the webapp.

> Which takes precedence, the shadowed war file in work/localhost/examples ?
> or the unarchived copy in webapps/examples?
>
> What is the expected behaviour of this feature if you drop a war file in
> a webapp directory?  What if you update a war file?

Note: Jasper is temporarily broken when running from a WAR.

Remy


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

Tomcat 4 CVS running a web app from a war file

[Glenn Nielsen]

I updated Tomcat 4 which has the new code that allows running directly
from a WAR file.  A few comments about this.

I will refer to the 'examples' context in my comments.

The directory 'work/localhost/examples/classes is created for
the contents of 'webapps/examples/WEB-INF/classes.

First, what if there were a directory named 'webapps/examples/classes'
which contained JSP pages, wouldn't this conflict with where you put
the WEB-INF classes?  Wouldn't it be better to put them
in work/localhost/examples/WEB-INF/classes ?

Second, if a WAR is already unarchived in the webapp directory,
i.e. both examples.war and examples/ exists, why is the 
'work/localhost/examples/classes' directory created?

Which takes precedence, the shadowed war file in work/localhost/examples ?
or the unarchived copy in webapps/examples?

What is the expected behaviour of this feature if you drop a war file in
a webapp directory?  What if you update a war file?

Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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

RE: Thread-safety

[cmanolache]

> > Bruce Eckel on his book "Thinking in Java" states that a simple
> > method call (no parameters) takes 5.9 units of time while a
> > synchronized method call takes 570. OTOH, object creation takes
> > 980 which makes it an even worse alternative.
> 
> Normally I would say that numbers such as these should be taken with a
> grain of salt.  For example, object creation has side effects that will
> affect the times of subsequent garbage collections; and synchronization can
> affect the performance of other threads.
> 
> However, if a synchronized method call takes on the order of the time of an
> object creation (which makes sense as object creation is likely
> synchronized itself), then I would be inclined to say that this overhead is
> quite small compared to the overall processing of an HTTP request as such
> involves the creation of a quite large number of objects.  So, if a
> relatively small number of these operations were done per request, then the
> right course of action would be to replace the code with the safest,
> simplest, and most maintainable alternative, namely a simple
> synchronization block without the outer if statement.

Well, I would disagree with this. First, processing an HTTP requests
doesn't require "creation of a quite large number of objects" - 3.x is
down to almost 6 objects, and that's only because I didn't had the time to
finish ( and 6 is not a big number - it used to be >50 ). IMHO it's a
matter of weeks to get this down to 1 ( the Socket object - not a problem 
in ajp13, only in standalone mode ).

You are right - object creation and GC both require synchronization. 

( BTW, since we are talking about sync - there are quite a few tricks in
ThreadPool and the server design to minimize the number of syncs per
request )

Costin


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

Apache JServ Status

[Arne Bromann]

I get internal server error if i modify and apply the status of an
ApJServHost to take it away from the balancing. The jserv and tomcat
configuration works. But i can not shutdown any host.

Can i use mod_jserv for this or must i use mod_jk?

I use TC 3.2.1 and JServ 1.1.2.

Arne
Germany

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

getPathInfo problem in servlet

[Stephen Wong]

I am new to tomcat.

I use tomcat3.2.1 binary version to install  tomcat and
found the request.getPathInfo() always return null, no
matter it is in JSP or servlet.  I simply add a line in
the HelloWorldExample.java and it print null.   I read
from the past mail-archives that it is normal in jsp but
not in servlet.  What is the problem?

I use redhat 6.2.

STephen

Problem with Tomcat Version 3.2.1

[mvibhas]

Hi,

There seems to be a problem with the zip file for Tomcat 3.2.1 available at
the jakarta.apache.org. It doesn't contain the file xml.jar because of
which an exception is thrown and the server doesn't start. I tried putting
the 3.1 xml.jar file in the lib directory but still some exception was
being thrown. Can somebody please help in this regard.

Also, the website says that thread pooling can be used with ver3.1 and 3.2.
However, the tomcat.properties file for both these versions disables thread
pooling by default and recommends against deploying the same for production
use. Please clarify whether thread pooling should be used or not.

With warm regards,
   Vibhas

Vibhas Muthu
   Quality
   IBM Global Services India
   Golden Enclave, Airport Road
   Bangalore-560017, INDIA
   Tel: 91-80-5262355 Extn 2151
Email: [EMAIL PROTECTED]



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

Successful configuring of tomcat 3.2.1 with apache 1.3.9

[Manish Saxena]

Daer Sir,

This is in reference to the documentation regarding configuring apache 1.3.9 
and tomcat3.0. The above matter is highly appreciable and  i have tested the 
above configuration succesfully.

This is to inform you the other configuration which i have tested 
independently i.e. tomcat3.2.1 with apache1.3.9. The httpd.conf from the 
apache directory is included along with this communication.

Please do respond back for updating and suggestions.

Regards
Manish Saxena
Application Developer
GroupWare, New Delhi, India

#
# Based upon the NCSA server configuration files originally by Rob McCool.
#
# This is the main Apache server configuration file.  It contains the
# configuration directives that give the server its instructions.
# See http://www.apache.org/docs/> for detailed information about
# the directives.
#
# Do NOT simply read the instructions in here without understanding
# what they do.  They're here only as hints or reminders.  If you are unsure
# consult the online docs. You have been warned.
#
# After this file is processed, the server will look for and process
# C:/Program Files/Apache Group/Apache/conf/srm.conf and then C:/Program 
Files/Apache Group/Apache/conf/access.conf
# unless you have overridden these with ResourceConfig and/or
# AccessConfig directives here.
#
# The configuration directives are grouped into three basic sections:
#  1. Directives that control the operation of the Apache server process as 
a
# whole (the 'global environment').
#  2. Directives that define the parameters of the 'main' or 'default' 
server,
# which responds to requests that aren't handled by a virtual host.
# These directives also provide default values for the settings
# of all virtual hosts.
#  3. Settings for virtual hosts, which allow Web requests to be sent to
# different IP addresses or hostnames and have them handled by the
# same Apache server process.
#
# Configuration and logfile names: If the filenames you specify for many
# of the server's control files begin with "/" (or "drive:/" for Win32), the
# server will use that explicit path.  If the filenames do *not* begin
# with "/", the value of ServerRoot is prepended -- so "logs/foo.log"
# with ServerRoot set to "/usr/local/apache" will be interpreted by the
# server as "/usr/local/apache/logs/foo.log".
#
# NOTE: Where filenames are specified, you must use forward slashes
# instead of backslashes (e.g., "c:/apache" instead of "c:\apache").
# If a drive letter is omitted, the drive on which Apache.exe is located
# will be used by default.  It is recommended that you always supply
# an explicit drive letter in absolute paths, however, to avoid
# confusion.
#

### Section 1: Global Environment
#
# The directives in this section affect the overall operation of Apache,
# such as the number of concurrent requests it can handle or where it
# can find its configuration files.
#

#
# ServerType is either inetd, or standalone.  Inetd mode is only supported 
on
# Unix platforms.
#
ServerType standalone

#
# ServerRoot: The top of the directory tree under which the server's
# configuration, error, and log files are kept.
#
# Do NOT add a slash at the end of the directory path.
#
ServerRoot "C:/Program Files/Apache Group/Apache"

#
# PidFile: The file in which the server should record its process
# identification number when it starts.
#
PidFile logs/httpd.pid

#
# ScoreBoardFile: File used to store internal server process information.
# Not all architectures require this.  But if yours does (you'll know 
because
# this file will be  created when you run Apache) then you *must* ensure 
that
# no two invocations of Apache share the same scoreboard file.
#
ScoreBoardFile logs/apache_status

#
# In the standard configuration, the server will process httpd.conf,
# srm.conf, and access.conf in that order.  The latter two files are
# now distributed empty, as it is recommended that all directives
# be kept in a single file for simplicity.  The commented-out values
# below are the built-in defaults.  You can have the server ignore
# these files altogether by using "/dev/null" (for Unix) or
# "nul" (for Win32) for the arguments to the directives.
#
#ResourceConfig conf/srm.conf
#AccessConfig conf/access.conf

#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 300

#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive On

#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We reccomend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests 100

#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 15

#
# Apache on Win32 always creates one child process to handle requests.  If 
it
# dies, another child process is created automatica

FW: BugRat Report #418 - Problem with include directive

[Lan Jiang]

Title: FW: BugRat Report #418 - Problem with include directive





 <> 
Hi, there,


I download the Tomcat 3.2.1 on Window2000. I want to use its JSPC compiler to compiler some JSP files.


I have c:\test\boo\foo1.jsp and c:\test\boo\foo2.jsp. foo1.jsp use JSP include directive
<%@include file="foo2.jsp" %>
When I enter c:\test directory and use JSPC to compile "jspc -webapp .", it tells me 'Bad file argument to include'. But if I change the include directive to <%@include file="/boo/foo2.jsp" %>, it will compile correctly. 

I find this bug in the bug database. It seems the same. However, it says it is closed. I want to verify if the fix is in the build 3.2.1. 

Thanks.


Lan


-Original Message-
From: BugRat Mail System
To: Adam Rabung; Lan Jiang
Sent: 1/26/01 10:26 PM
Subject: BugRat Report #418 - Problem with include directive


- Sender's Comment -
Tomcat JSPC bug
- End Of Sender's Comment ---
Report URL: 


Report #418 Details


Project: Jasper
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: closed
Priority: high
Severity: critical
Confidence: public
Environment: 
   Release: version released with TomCat3.2b
   JVM Release: 1.2.2
   Operating System: nt
   OS Release: 4
   Platform: Intel P3


Synopsis: 
Problem with include directive


Description:
<%@ include file="../../library.jsp"   %>


gives the following error message


'Bad file argument to include'


when compiled from the command line but NOT when served as a JSP page
under TomCat3.2beta7.


The command line used to compile the JSP page is given in the 'How to
Reproduce'.
 <> 



Title: 
BugRat Report #
418





BugRat Report #
418




Project:
Jasper


Release:
version released with TomCat3.2b




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
closed




Priority:
high


Severity:
critical




Confidence:
public





Submitter:
Christopher Kirk ( [EMAIL PROTECTED] )

Date Submitted:
Nov 21 2000, 03:41:38 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

Problem with include directive


 Environment: (jvm, os, osrel, platform)

1.2.2, nt, 4, Intel P3



Additional Environment Description:





Report Description:

<%@ include file="../../library.jsp"   %>

gives the following error message

'Bad file argument to include'

when compiled from the command line but NOT when served as a JSP page under TomCat3.2beta7.

The command line used to compile the JSP page is given in the 'How to Reproduce'.



How To Reproduce:





Workaround:





View this Report online...






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

cvs commit: jakarta-tomcat STATUS.html

[larryi]

larryi  01/01/27 10:42:26

  Modified:.STATUS.html
  Log:
  Add usability enhancements action item offered by Costin.
  
  Revision  ChangesPath
  1.11  +10 -1 jakarta-tomcat/STATUS.html
  
  Index: STATUS.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/STATUS.html,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- STATUS.html   2001/01/24 03:56:06 1.10
  +++ STATUS.html   2001/01/27 18:42:26 1.11
  @@ -133,6 +133,15 @@
   left out of the classpath.
   mailto:[EMAIL PROTECTED]">Costin Manolache
 
  +  
  +High
  +3.3b1
  +Add usability enhancements. This would include making Tomcat easier to
  +configure, providing better error messages, and adding more documentation
  +on module options.  Also, try to update /admin to provide better
  +monitoring of the running Tomcat.
  +mailto:[EMAIL PROTECTED]">Costin Manolache
  +  
   
   
   
  @@ -547,7 +556,7 @@
   
   
   
  -$Id: STATUS.html,v 1.10 2001/01/24 03:56:06 larryi Exp $
  +$Id: STATUS.html,v 1.11 2001/01/27 18:42:26 larryi Exp $
   
   
   
  
  
  

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

cvs commit: jakarta-tomcat/src/tests/webpages/WEB-INF test-tomcat.xml

[larryi]

larryi  01/01/27 10:41:05

  Modified:src/tests/webpages/WEB-INF test-tomcat.xml
  Log:
  Add revision property.
  
  Revision  ChangesPath
  1.9   +2 -1  jakarta-tomcat/src/tests/webpages/WEB-INF/test-tomcat.xml
  
  Index: test-tomcat.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/tests/webpages/WEB-INF/test-tomcat.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- test-tomcat.xml   2001/01/27 00:59:20 1.8
  +++ test-tomcat.xml   2001/01/27 18:41:05 1.9
  @@ -15,7 +15,8 @@
   "main" or "apache" targets, tomcat may not start fast enough to avoid 
failing some of the
   early tests.
   -->
  -  
  +
  +   



  
  
  

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

cvs commit: jakarta-tomcat/src/admin/test test.jsp

[larryi]

larryi  01/01/27 10:39:33

  Modified:src/admin/WEB-INF/classes/tadm GTestTEI.java GTestTag.java
   src/admin/test test.jsp
  Log:
  Update GTestTag to add a gtestTestRevision attribute that retrieves the
  "revision" property from the test file, if present.  If not present, it is defaulted
  to "Revision: Unknown".
  
  Add a line like the following as a global property to the test file to set the
  revision:
  
   
  
  Handling is provided to remove the '$' characters if the CVS key substitution
  $Revsion$ is used.
  
  Updated test.jsp to display the revision.
  
  Revision  ChangesPath
  1.3   +3 -0  jakarta-tomcat/src/admin/WEB-INF/classes/tadm/GTestTEI.java
  
  Index: GTestTEI.java
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/admin/WEB-INF/classes/tadm/GTestTEI.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- GTestTEI.java 2001/01/21 20:10:38 1.2
  +++ GTestTEI.java 2001/01/27 18:39:33 1.3
  @@ -20,6 +20,9 @@
   
   public VariableInfo[] getVariableInfo(TagData data) {
return (new VariableInfo[] {
  + new VariableInfo("gtestTestRevision",
  +  "java.lang.String",
  +  true,  VariableInfo.AT_BEGIN),
new VariableInfo("gtestTestResults",
 "java.util.Vector",
 true,  VariableInfo.AT_BEGIN),
  
  
  
  1.7   +13 -0 jakarta-tomcat/src/admin/WEB-INF/classes/tadm/GTestTag.java
  
  Index: GTestTag.java
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/admin/WEB-INF/classes/tadm/GTestTag.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- GTestTag.java 2001/01/22 16:42:05 1.6
  +++ GTestTag.java 2001/01/27 18:39:33 1.7
  @@ -18,6 +18,7 @@
*/
   public class GTestTag extends TagSupport {
   PageContext pageContext;
  +String revision;
   
   public GTestTag() {}
   
  @@ -37,6 +38,8 @@

runTest( base );
   
  + pageContext.setAttribute("gtestTestRevision",
  +  revision);
pageContext.setAttribute("gtestTestResults",
 GTest.getTestResults());
pageContext.setAttribute("gtestTestFailures",
  @@ -145,6 +148,16 @@
project.setUserProperty( "wgdir", base + "/Golden");

ProjectHelper.configureProject( project, testFile );
  +
  + // try to get revision if present
  + revision = project.getProperty( "revision" );
  + if (revision  == null)
  + revision  = "Revision: Unknown";
  + else {
  + // clean up a little in case CVS $Revision: 1.7 $ used
  + revision  = revision .replace('$',' ');
  + revision .trim();
  + }

Vector targets=new Vector();
if( target==null ) target="client";
  
  
  
  1.6   +2 -0  jakarta-tomcat/src/admin/test/test.jsp
  
  Index: test.jsp
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/admin/test/test.jsp,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- test.jsp  2001/01/24 01:47:24 1.5
  +++ test.jsp  2001/01/27 18:39:33 1.6
  @@ -54,6 +54,8 @@
  // it's done ), use 'html' for "interactive" results
   %>
   
  +Test <%= gtestTestRevision %>
  +
   <% //  Failures  %>
   FAILED Tests
   
  
  
  

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

[PATCH] ajp13 Apache autoconfig fix

[Keith Wannamaker]

This is a patch against cvs head to autogenerate ajpv13
support for Apache, if the ajpv13 module has been loaded.
Also, update server.xml to show ajpv13 support.

http://www.apache.org/~keith/jk/config.txt

Keith


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

RE: Thread-safety

[Sam Ruby]

Paulo Gaspar wrote:
>
> Bruce Eckel on his book "Thinking in Java" states that a simple
> method call (no parameters) takes 5.9 units of time while a
> synchronized method call takes 570. OTOH, object creation takes
> 980 which makes it an even worse alternative.

Normally I would say that numbers such as these should be taken with a
grain of salt.  For example, object creation has side effects that will
affect the times of subsequent garbage collections; and synchronization can
affect the performance of other threads.

However, if a synchronized method call takes on the order of the time of an
object creation (which makes sense as object creation is likely
synchronized itself), then I would be inclined to say that this overhead is
quite small compared to the overall processing of an HTTP request as such
involves the creation of a quite large number of objects.  So, if a
relatively small number of these operations were done per request, then the
right course of action would be to replace the code with the safest,
simplest, and most maintainable alternative, namely a simple
synchronization block without the outer if statement.

I'm convinced.

- Sam Ruby


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

Re: SSL Session problem with URL Rewriting

[Mathias Bachner]

On Fri, 26 Jan 2001, Craig R. McClanahan wrote:

> Matthias, I just checked in a change to do exactly this, which will show up in
> tonight's nightly build of Tomcat 4.0.  Could you please try it and ensure that
> it fixes your problem?
Tried it. All works fine now. The SessionID gets proberly added for SSL
and non-SSL sessions. 

Thanks for fast fixing.

Mathias Bachner



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

Re: Thread-safety

[Sam Ruby]

I got this as a private reply, but I believe that it is of general
interest.

- Sam Ruby


Brian Goetz <[EMAIL PROTECTED]> on 01/27/2001 07:40:54 AM

To:   Sam Ruby/Raleigh/IBM@IBMUS
cc:
Subject:  Re: Thread-safety



> Hmm.  Obviously this subject is much more subtle that I expected.  Thanks
> for the clarification, and in particular, the patient way in which you
> presented it.

Sam, I think the suggestions you present are moving in the right
direction.  Synchronization is expensive, so if you can avoid it on
the critical path, that's a throughput win.  One way to do that is as
you suggest, move your initializations into static initializers if you
can.  This works in a lot of cases.  Creating the objects before the
thread also works.  In most cases, there's a way to avoid the
problematic lazy initialization without too much fuss.

I'm not really following the thread too carefully, but Jon asked me to
comment since he knows that this is an area where I had something to
contribute.  Feel free to copy me on your messages or ask questions.

I'll send you a reference to my JavaWorld article on the subject when
it has gone through editorial review.

> I presume that synchronization is a relatively expensive operation,

Unfortunately so.  Newer JVMs are better, but still its a big overhead.

> Anybody have any hard data on the validity of the presumptions above?

I think there's some hard data on this in Dov Bulka's performance
book.  Probably done with Java 1.2; 1.3 might be better.  You can
recompile his tests on your system and gather your own data.

Its late, so that's all for now.




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

RE: Thread-safety

[Paulo Gaspar]

Bruce Eckel on his book "Thinking in Java" states that a simple method call
(no parameters) takes 5.9 units of time while a synchronized method call
takes
570. OTOH, object creation takes 980 which makes it an even worse
alternative.

(The used time unit is the time spent to perform a local assignment.)

The book can be found on line (pdf format) from:
  http://www.bruceeckel.com/

You can find this data on a table in "Apendix D: Performance".


Have fun,
Paulo Gaspar

> -Original Message-
> From: Sam Ruby [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 27, 2001 13:17
>
> ...
>
> If it turns out that either of those two assertions are false (in
> particular if it turns out that the overhead of a synchronize is
> negligible
> compared to the overhead of the processing of a request), then we might as
> well do the simple and clean thing and remove the unsafe if checks.
>
> ...
>
> Anybody have any hard data on the validity of the presumptions above?
>
> - Sam Ruby


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

Re: Thread-safety

[Sam Ruby]

Brian Goetz wrote:
>
> This statement is true, but very easy to misinterpret; be careful.
> You can't use this to make an end-run around the problem in the
> general case.  If jspx_init() creates any objects, you've gotta
> synchronize, plain and simple.  If jspx_init() calculates
> multiple primitive values, which can obtained through any other
> means than its return value, you've gotta synchronize.

Hmm.  Obviously this subject is much more subtle that I expected.  Thanks
for the clarification, and in particular, the patient way in which you
presented it.

Can we back up for a moment?

I presume that synchronization is a relatively expensive operation,
particularly on a high end, multiprocessor box?  I also presume that the
throughput in terms of requests per second that a given servlet engine
processes is an important measure.

If it turns out that either of those two assertions are false (in
particular if it turns out that the overhead of a synchronize is negligible
compared to the overhead of the processing of a request), then we might as
well do the simple and clean thing and remove the unsafe if checks.

Otherwise, it behooves us to look for alternatives.  One suggested by the
web page is to put the code into a static initializer for a class as this
apparently is guaranteed to be safe.

If for some reason this turns out to be impractical, then another obvious
solution would be to move all initialization to the point in the program
prior to where any threads are created.  Might break some architectural
boundaries, but with enough inventive people around, this can perhaps be
isolated and encapsulated appropriately.

Anybody have any hard data on the validity of the presumptions above?

- Sam Ruby


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