Re: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5390

2001-12-25 Thread Bill Barker 

I've changed the (new) StreamHandlerFactory to punt on "jar" protocols.  If
you can build from source, I can tell you how to disable it altogether.  You
might want to try the 12/26 nightly.  Personally, I can't see this doing
anything but shortening the stack trace.  But then again, I can't see how
the inclusion/exclusion of Http10Interceptor can make any difference either.

I'm including the developer list in the reply, in the hopes that someone
else can spot what I'm missing.
- Original Message -
From: <[EMAIL PROTECTED]>
To: "Bill Barker" <[EMAIL PROTECTED]>
Sent: Monday, December 24, 2001 8:13 PM
Subject: Re: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5390


> Hi Bill,
>
> Gee, it's xmas eve and we're pounding on the keyboard.  Hahaha - or should
I
> say Hohoho.
>
> I attached the log -- it's the whole thing because it's just one url
> request -- xxx.jsp and every error that went with it until I received a
> blank screen response.  At the end, tomcat is dead.  It will not serve any
> more requests.
>
> Let me tell you where I am.  I do have a work around although I cannot
> explain why it works!
> 1. I started tomcat using a console with the http10 connector.  Everything
> worked fine using this connector.
> 2. I then started up the web server and everything went fine using the
ajp12
> and ajp13 connectors.
> 3. I then removed the http10 connector still using the web server ajp12/13
> connectors and IT BLEW UP.
> 4. I put back the http10 connector back in and only used the ajp12/13
(step
> 2) and it works great.
> 5. I brought tomcat up as a service and only used the ajp12/13 and it
works
> great as long as the http10 connector is enabled.
>
> I repeated these steps for a few hours to make sure everything was
> reproducible.  It was.
>
> I put this fix in (enabled the http10 connector on localhost so internet
> folks can't use it) on my second test server and it also ran fine.  I'm
now
> doing a stress test on it now for a few hours to make sure everything's
cool
> before I roll it on the prod server.  I'm sure it's going to fly.
>
> If you can figure this one out, send me your mailing address and I'll send
> you some hawaiian chocolate macadamia nuts.  Aah, send me your mailing
> address anyway and I'll send you some munchies.  You've been a real pal.
> Merry xmas.
>
> Aloha my friend and thanks for your help,
> Mike
>
>
> - Original Message -
> From: "Bill Barker" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, December 24, 2001 5:33 PM
> Subject: Re: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5390
>
>
> It's likely that I'll only be interested in the lines below the presumably
> 1000 lines that start java.util.zip, but you can send me the whole log if
> you like.  Of course, gzipped is better.
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, December 24, 2001 2:48 PM
> Subject: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5390
>
>
> > Yes, it's normal thru the 404 except the 404 never get's returned on the
> > response.  Instead that monster stack overflow takes over and tomcat
goes
> > dead (a blank response is sent to the browser).  If you'd like to see
the
> > full 1040+ lines of exception code associated with the log snippet I
> posted
> > to bugz, I'll be happy to email it to you.  This big exception occurs
> after
> > I type in xxx.jsp after a fresh restart of tomcat.  I'm not sure if it
was
> > cool to post that much stuff to bugz or to continue this discussion as a
> > thread.  The problem is consistent.  As soon as I take out the web.xml
> > entries for the jsp, everything runs normal.  I'll scale down my test
env
> to
> > tomcat standalone and retest.  I've already got the code running on my
> > production server and I'm afraid someone is going to try that jsp
> > load-onstartup and blow my jvm/tomcat system for my other server users.
> >
> > I'm in the office now and successfully reproduced the same error on a
> second
> > tomcat server using the code based from the 12/20 nightly build.
Anyway,
> do
> > you want me to send the big log to you or post it to bugz?
> >
> > Thanks for all your help and merry xmas.
> > Regards,
> > Mike
> >
> >
> > --- Additional Comments From [EMAIL PROTECTED]  2001-12-24
> > 14:03 ---
> > Everything up to the "Status code:404" line is normal, and AFAIK none of
> the
> > changes to the App-Classloader should be able to cause this.  If you can
> add
> > the log as an attachment, I might be able to track something down, but
> since
> > my
> > simple attempt to reproduce failed to fail I don't have enough info to
go
> > on.
> >
> > If you have your own 404 handler, you might also want to check there
> > (although
> > I can't see how to write one buggy enough to blow up here :).
> >
>
>


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

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/net StreamHandlerFactory.java

2001-12-25 Thread billbarker 

billbarker01/12/25 21:25:30

  Modified:src/share/org/apache/tomcat/util/net
StreamHandlerFactory.java
  Log:
  It seems that some JVMs handle "jar" specially, so decline if the protocol is "jar"
  
  Revision  ChangesPath
  1.5   +3 -0  
jakarta-tomcat/src/share/org/apache/tomcat/util/net/StreamHandlerFactory.java
  
  Index: StreamHandlerFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/net/StreamHandlerFactory.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- StreamHandlerFactory.java 2001/11/18 05:56:02 1.4
  +++ StreamHandlerFactory.java 2001/12/26 05:25:30 1.5
  @@ -86,12 +86,15 @@
   /** Create a URLStreamHandler for this protocol.
*  This factory differs from the default in that
*  
  + *  If the protocol is jar, we decline
*  We load classes from the ContextClassLoader
*  If no handler is defined, we return a connection-less
*   URLStreamHandler that allows parsing
*  
*/
   public  URLStreamHandler createURLStreamHandler(String protoS) {
  + if("jar".equalsIgnoreCase(protoS))
  + return null;
if(protocolString != System.getProperty(SYS_PROTOCOLS))
loadProtocols();
ClassLoader acl = jdk11Compat.getContextClassLoader();
  
  
  

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

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

2001-12-25 Thread glenn 

glenn   01/12/25 18:20:35

  Modified:catalina build.xml
  Log:
  I tested using the DbcpDataSourceFactory and it failed to
  work due to three different commons jar files being located
  in server/lib instead of common/lib.
  
  Changed the build so that commons-dbcp.jar, commons-pool.jar,
  and commons-collections.jar are located in common/lib.
  
  After relocating the above jar files, the DbcpDataSourceFactory
  worked fine and the application which used it appeared to have
  less latency when accessing the db. :-)
  
  Revision  ChangesPath
  1.92  +4 -4  jakarta-tomcat-4.0/catalina/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
  retrieving revision 1.91
  retrieving revision 1.92
  diff -u -r1.91 -r1.92
  --- build.xml 2001/12/26 01:22:10 1.91
  +++ build.xml 2001/12/26 02:20:34 1.92
  @@ -531,7 +531,7 @@
   
 
 
  -
  +
 
 
   
  @@ -567,7 +567,7 @@
   
 
 
  -
  +
 
 
   
  @@ -598,6 +598,8 @@
   
   
   
  +
   
   
   
  @@ -609,8 +611,6 @@
   
   
  -
   
   
  
  
  

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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory ResourceFactory.java

2001-12-25 Thread glenn 

glenn   01/12/25 18:15:43

  Modified:catalina/src/share/org/apache/naming/factory
ResourceFactory.java
  Log:
  Forgot to cast a Throwable when rethrowing
  
  Revision  ChangesPath
  1.6   +5 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/ResourceFactory.java
  
  Index: ResourceFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/ResourceFactory.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- ResourceFactory.java  2001/12/26 01:22:10 1.5
  +++ ResourceFactory.java  2001/12/26 02:15:43 1.6
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/ResourceFactory.java,v
 1.5 2001/12/26 01:22:10 glenn Exp $
  - * $Revision: 1.5 $
  - * $Date: 2001/12/26 01:22:10 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/ResourceFactory.java,v
 1.6 2001/12/26 02:15:43 glenn Exp $
  + * $Revision: 1.6 $
  + * $Date: 2001/12/26 02:15:43 $
*
* 
*
  @@ -77,7 +77,7 @@
* Object factory for Resources.
* 
* @author Remy Maucherat
  - * @version $Revision: 1.5 $ $Date: 2001/12/26 01:22:10 $
  + * @version $Revision: 1.6 $ $Date: 2001/12/26 02:15:43 $
*/
   
   public class ResourceFactory
  @@ -142,7 +142,7 @@
   factory = (ObjectFactory) factoryClass.newInstance();
   } catch(Throwable t) {
   if( t instanceof NamingException)
  -throw t;
  +throw (NamingException)t;
   throw new NamingException(
   "Could not create resource factory instance, " +
   t.getMessage());
  
  
  

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

cvs commit: jakarta-tomcat-4.0 tomcat.nsi

2001-12-25 Thread glenn 

glenn   01/12/25 17:23:49

  Modified:.tomcat.nsi
  Log:
  JVM Temporary Directory (java.io.tmpdir property) security patch
  
  
  The java.io.File.createTempFile() methods use the property
  java.io.tmpdir for the location of the directory where the JVM
  places temporary files.  If this property doesn't exist,
  /tmp or /var/tmp gets used on unix systems or c:\\temp on WIN32 systems.
  
  This default directory is the same directory that all applications
  can use for temporary files.  Sharing the same system temporary
  directory between Tomcat and other applications could be a security
  risk if sensitive data is stored there by other applications.
  
  If you run Tomcat with the SecurityManager enabled you would have to
  grant Tomcat a FilePermission with read, write, and delete for the
  temporary directory.
  
  This series of patches enables the use of a temporary directory
  located at $CATALINA_BASE/temp so that Tomcat's use of the temporary
  directory is isolated from the rest of the system.
  
  Revision  ChangesPath
  1.24  +3 -1  jakarta-tomcat-4.0/tomcat.nsi
  
  Index: tomcat.nsi
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/tomcat.nsi,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- tomcat.nsi2001/12/19 17:53:33 1.23
  +++ tomcat.nsi2001/12/26 01:23:49 1.24
  @@ -1,6 +1,6 @@
   
   ; Tomcat 4 script for Nullsoft Installer
  -; $Id: tomcat.nsi,v 1.23 2001/12/19 17:53:33 remm Exp $
  +; $Id: tomcat.nsi,v 1.24 2001/12/26 01:23:49 glenn Exp $
   
   Name "apache-tomcat-4.1"
   Caption "Apache Tomcat 4.1"
  @@ -46,6 +46,7 @@
 File /r logs
 File /r server
 File /r work
  +  File /r temp
 SetOutPath $INSTDIR\webapps
 File webapps\*.xml
 File /r webapps\ROOT
  @@ -335,6 +336,7 @@
 RMDir /r "$INSTDIR\webapps\webdav"
 RMDir "$INSTDIR\webapps"
 RMDir /r "$INSTDIR\work"
  +  RMDir /r "$INSTDIR\temp"
 RMDir /r "$INSTDIR\src"
 RMDir "$INSTDIR"
   
  
  
  

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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory DbcpDataSourceFactory.java ResourceFactory.java

2001-12-25 Thread glenn 

glenn   01/12/25 17:22:10

  Modified:catalina build.xml
   catalina/src/bin catalina.bat catalina.sh
   catalina/src/share/org/apache/catalina/startup Catalina.java
   catalina/src/share/org/apache/naming/factory
DbcpDataSourceFactory.java ResourceFactory.java
  Log:

cvs commit: jakarta-tomcat-4.0 build.xml

2001-12-25 Thread glenn 

glenn   01/12/25 17:21:51

  Modified:.build.xml
  Log:

cvs commit: jakarta-tomcat-4.0 README.txt RUNNING.txt

2001-12-25 Thread glenn 

glenn   01/12/25 17:21:24

  Modified:.README.txt RUNNING.txt
  Log:
  JVM Temporary Directory (java.io.tmpdir property) security patch
  
  
  The java.io.File.createTempFile() methods use the property
  java.io.tmpdir for the location of the directory where the JVM
  places temporary files.  If this property doesn't exist,
  /tmp or /var/tmp gets used on unix systems or c:\\temp on WIN32 systems.
  
  This default directory is the same directory that all applications
  can use for temporary files.  Sharing the same system temporary
  directory between Tomcat and other applications could be a security
  risk if sensitive data is stored there by other applications.
  
  If you run Tomcat with the SecurityManager enabled you would have to
  grant Tomcat a FilePermission with read, write, and delete for the
  temporary directory.
  
  This series of patches enables the use of a temporary directory
  located at $CATALINA_BASE/temp so that Tomcat's use of the temporary
  directory is isolated from the rest of the system.
  
  Revision  ChangesPath
  1.19  +3 -1  jakarta-tomcat-4.0/README.txt
  
  Index: README.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/README.txt,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- README.txt2001/11/19 14:36:58 1.18
  +++ README.txt2001/12/26 01:21:23 1.19
  @@ -1,4 +1,4 @@
  -$Id: README.txt,v 1.18 2001/11/19 14:36:58 glenn Exp $
  +$Id: README.txt,v 1.19 2001/12/26 01:21:23 glenn Exp $
   
  The Tomcat 4.0 Servlet/JSP Container
  
  @@ -31,6 +31,8 @@
 included with Tomcat 4.0
 work/   Scratch directory used by Tomcat for holding
 temporary files and directories
  +  temp/   Directory used by JVM for temporary files
  +  (java.io.tmpdir)
   
   If you wish to build the Tomcat server from a source distribution,
   please consult the documentation in "BUILDING.txt".
  
  
  
  1.4   +3 -1  jakarta-tomcat-4.0/RUNNING.txt
  
  Index: RUNNING.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/RUNNING.txt,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- RUNNING.txt   2001/12/01 07:35:46 1.3
  +++ RUNNING.txt   2001/12/26 01:21:24 1.4
  @@ -1,4 +1,4 @@
  -$Id: RUNNING.txt,v 1.3 2001/12/01 07:35:46 remm Exp $
  +$Id: RUNNING.txt,v 1.4 2001/12/26 01:21:24 glenn Exp $
   
   
  Running The Tomcat 4.0 Servlet/JSP Container
  @@ -120,6 +120,8 @@
   * webapps - Automatically loaded web applications
   
   * work - Temporary working directories for web applications
  +
  +* temp - Directory used by the JVM for temporary files (java.io.tmpdir)
   
   If you do not set CATALINA_BASE to an explicit value, it will be initialized
   to the same value as is set for CATALINA_HOME (which means that the same
  
  
  

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

cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1-dev.txt

2001-12-25 Thread glenn 

glenn   01/12/25 17:20:30

  Added:   .RELEASE-NOTES-4.1-dev.txt
  Log:
  About time for RELEASE-NOTES for 4.1-dev
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-4.0/RELEASE-NOTES-4.1-dev.txt
  
  Index: RELEASE-NOTES-4.1-dev.txt
  ===
   Apache Tomcat Version 4.1-dev
   =
  Release Notes
  =
  
  $Id: RELEASE-NOTES-4.1-dev.txt,v 1.1 2001/12/26 01:20:30 glenn Exp $
  
  
  
  INTRODUCTION:
  
  
  
  This document describes the changes that have been made in the current
  development version of Apache Tomcat, relative to the Tomcat 4.0 release.
  The release notes for all prior releases of Tomcat 4.0 are also included, for
  your reference.
  
  Bug reports should be entered at the bug reporting system for
  Jakarta projects at:
  
  http://nagoya.apache.org/bugzilla/
  
  Please report bugs and feature requests under product name "Tomcat 4".
  
  
  
  
  NEW FEATURES:
  
  
  
  
  General New Features:
  
  
  
  -
  Catalina New Features:
  -
  
  
  ---
  Jasper New Features:
  ---
  
  
  
  Webapps New Features:
  
  
  
  ==
  BUG FIXES AND IMPROVEMENTS:
  ==
  
  
  --
  Generic Bug Fixes:
  --
  
  
  --
  Catalina Bug Fixes:
  --
  
  
  
  Jasper Bug Fixes:
  
  
  
  -
  Webapps Bug Fixes:
  -
  
  
  --
  Security Bug Fixes:
  --
  
  When starting Tomcat the environment variable CATALINA_TMPDIR
  is used to define the system property java.io.tmpdir.  By
  default java.io.tmpdir is set to CATALINA_BASE/temp.  This
  isolates Tomcat's use of a temporary directory from other
  applicatons on the same computer system.
  
  
  KNOWN ISSUES IN THIS RELEASE:
  
  
  
  -
  Tomcat 4.0 and Apache:
  -
  
  The binary distribution for Tomcat 4.0 includes the most recent stable version
  of the WARP connector, which is the Tomcat component that talks to mod_webapp
  inside Apache 1.3.  The current state of this support is summarized as follows:
  
  * The mod_webapp connector is configured based on the contents of the
web.xml file for your web application.  See the documentation included
with the connector for configuration requirements.
  
  * The version of the connector to be published with Tomcat 4.0 final has
the following known issues:
  
  http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3509
  
  http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3534
  
These problems will be addressed in a future release of the connector.
  
  
  -
  Tomcat 4.0 and JNI Based Applications:
  -
  
  Applications that require native libraries must ensure that the libraries have
  been loaded prior to use.  Typically, this is done with a call like:
  
static {
  System.loadLibrary("path-to-library-file");
}
  
  in some class.  However, the application must also ensure that the library is
  not loaded more than once.  If the above code were placed in a class inside
  the web application (i.e. under /WEB-INF/classes or /WEB-INF/lib), and the
  application were reloaded, the loadLibrary() call would be attempted a second
  time.
  
  To avoid this problem, place classes that load native libraries outside of the
  web application, and ensure that the loadLibrary() call is executed only once
  during the lifetime of a particular JVM.
  
  
  --
  Tomcat 4.0 Standard APIs Available:
  --
  
  A standard installation of Tomcat 4 makes all of the following APIs available
  for use by web applications (by placing them in "common/lib" or "lib"):
  * activation.jar (Java Activation Framework)
  * crimson.jar (Unsealed version of JAXP/1.1 parser)
  * jaxp.jar (Unsealed version of JAXP/1.1 API classes)
  * jdbc2_0-stdext.jar (JDBC 2.0 Optional Package, javax.sql.*)
  * jndi.jar (JNDI 1.2 base API classes)
  * jta-spec1_0_1 (Java Transacation APIs)
  * ldap.jar (JNDI LDAP provider required by JNDIRealm)
  * mail.jar (JavaMail 1.2)
  * servlet.jar (Servlet 2.3 and JSP 1.2 APIs)
  * tyrex-0.9.7.0.jar (Tyrex XA-compatible data source from tyrex.exolab.org)
  
  You can make additional APIs available to all of your web applications by
  putting unpacked classes into a "classes" directory (not created by default),
  or by pla

Tomcat fails to start...

2001-12-25 Thread Jack Lauman 

Tomcat 4.x (CVS 12-25-2001) fails to start.

I'm using the following configuration:

RedHat 7.0 (glibc 2.2.4-18.7.0.3)
jdk1.3.1_02
commons-utils-1.1
commons-collections-1.0
commons-digester-1.1.1
commons-dbcp-20011222
commons-modeler-20011222
commons-pool-20011222
crimson-1.1.3
xerces-1.4.4

I got the following error when executing $CATALINA_HOME/bin/startup.sh
and would appreciate any assistance in resolving it.

Thanks,

Jack

End event threw exception
java.lang.ClassNotFoundException:
org.apache.catalina.ServerSocketFactory
at
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:992)
at
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:857)
at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:155)
at org.apache.commons.digester.Digester.endElement(Digester.java:757)
at org.apache.xerces.parsers.SAXParser.endElement(SAXParser.java:1403)
at
org.apache.xerces.validators.common.XMLValidator.callEndElement(XMLValidator.java:1550)
at
org.apache.xerces.framework.XMLDocumentScanner.scanElement(XMLDocumentScanner.java:1809)
at
org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1182)
at
org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381)
at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1098)
at org.apache.commons.digester.Digester.parse(Digester.java:1170)
at org.apache.catalina.startup.Catalina.start(Catalina.java:444)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:399)
at org.apache.catalina.startup.Catalina.process(Catalina.java:178)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:246)
Catalina.start: java.lang.ClassNotFoundException:
org.apache.catalina.ServerSocketFactory
java.lang.ClassNotFoundException:
org.apache.catalina.ServerSocketFactory
at
org.apache.commons.digester.Digester.createSAXException(Digester.java:1763)
at
org.apache.commons.digester.Digester.createSAXException(Digester.java:1785)
at org.apache.commons.digester.Digester.endElement(Digester.java:760)
at org.apache.xerces.parsers.SAXParser.endElement(SAXParser.java:1403)
at
org.apache.xerces.validators.common.XMLValidator.callEndElement(XMLValidator.java:1550)
at
org.apache.xerces.framework.XMLDocumentScanner.scanElement(XMLDocumentScanner.java:1809)
at
org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1182)
at
org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381)
at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1098)
at org.apache.commons.digester.Digester.parse(Digester.java:1170)
at org.apache.catalina.startup.Catalina.start(Catalina.java:444)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:399)
at org.apache.catalina.startup.Catalina.process(Catalina.java:178)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:246)

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

Re: [PATCH] [3.3] etomcat target

2001-12-25 Thread Denis Balazuc 


- Original Message -
From: "Jeff Turner" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 26, 2001 1:10 AM
Subject: [PATCH] [3.3] etomcat target


> Hi,
>
> On the 17th, Costin added an 'etomcat' target:
>
> > Added a target to build 'embeded' style tomcat, i.e. a single jar
containing
> > everything ( no more lib/container, etc ). It is self-runnable and
should start
> > tomcat with the defaults settings ( no server.xml, etc ) using the
current dir
> > as base.  Just add webapps and shake.
>
> > This is nice for people who just need a simple jar with no strings
attached (
> > configs, dir structure, etc ).
>
> It looked pretty broken when I tried it. The attached patch gets it
> compiled, I can now successfully start it by typing 'java
> -Dtomcat.home=... -jar webserver.jar'.
>
> The changes are:
>  - Declare dep on target that creates build/classes
>  - Change nonexistent ${servlet.jar} to ${servlet22.jar}
>  - Exclude all *SSL*, *JSSE*, *TLS* java files unless jsse.present. The
>the previous approach of explicitly naming each class was not robust
>enough. I found fully 9 other classes that weren't being excluded.
>  - Add the missing manifest.webserver, which I *guessed* should invoke
>EmbededTomcat with the classpath crimson.jar and servlet22.jar
>  - Minor javadoc fixes in EmbededTomcat.java.
>
>
> Incidentally, any tips on classloaders and EmbededTomcat? Everything
> starts fine, but my servlet can't see any classes in WEB-INF/lib
> *unless* I explicitly use the context classloader. Oh well, that's for
> another mail.
>
> Thanks,
>
> --Jeff
>






> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:



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

[PATCH] [3.3] etomcat target

2001-12-25 Thread Jeff Turner 

Hi,

On the 17th, Costin added an 'etomcat' target:

> Added a target to build 'embeded' style tomcat, i.e. a single jar containing
> everything ( no more lib/container, etc ). It is self-runnable and should start
> tomcat with the defaults settings ( no server.xml, etc ) using the current dir
> as base.  Just add webapps and shake.

> This is nice for people who just need a simple jar with no strings attached (
> configs, dir structure, etc ).

It looked pretty broken when I tried it. The attached patch gets it
compiled, I can now successfully start it by typing 'java
-Dtomcat.home=... -jar webserver.jar'.

The changes are:
 - Declare dep on target that creates build/classes
 - Change nonexistent ${servlet.jar} to ${servlet22.jar}
 - Exclude all *SSL*, *JSSE*, *TLS* java files unless jsse.present. The
   the previous approach of explicitly naming each class was not robust
   enough. I found fully 9 other classes that weren't being excluded.
 - Add the missing manifest.webserver, which I *guessed* should invoke
   EmbededTomcat with the classpath crimson.jar and servlet22.jar
 - Minor javadoc fixes in EmbededTomcat.java.


Incidentally, any tips on classloaders and EmbededTomcat? Everything
starts fine, but my servlet can't see any classes in WEB-INF/lib
*unless* I explicitly use the context classloader. Oh well, that's for
another mail.

Thanks,

--Jeff


? .bash_history
? .cvsrc
? .projrc
? .viminfo
? .vimrc
? etomcat.patch
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat/build.xml,v
retrieving revision 1.162
diff -u -r1.162 build.xml
--- build.xml   2001/12/17 05:31:45 1.162
+++ build.xml   2001/12/25 14:00:15
@@ -598,7 +598,7 @@
 
   
 
-  
+  
 
 
 
-
+
   
   
-  
-  
-  
-  
-  
+ 
   
   
+   unless="jdk12.present"/>
   
-  
-  
 
 
@@ -657,7 +651,7 @@
 
 
 
-
+
 
 This class is designed as a java bean, where you set different properties,
  *  then call methods to perform actions. The main method is "execute", that
- *  will start tomcat. Few other methods allow to perform different other tasks.
+ *  will start tomcat. Few other methods allow to perform different other
+ *  tasks.
  *
- *  EmbededTomcat is usable as an "ant" task as well, using the TaskAdapter.
- *  ( see sample - TODO XXX ).
+ *  EmbededTomcat is usable as an "ant" task as well, using the TaskAdapter.
+ *  ( see sample - TODO XXX ).
  * 
- *  Adding tomcat to your application:
+ *  Adding tomcat to your application:
  * 
- *  - Create a java class that will act as adapter and start tomcat ( and
+ *  
+ *Create a java class that will act as adapter and start tomcat ( and
  *hold your customization code ). The class and all the files in
  *TOMCAT_HOME/lib/common must be available in the class loader.
  *lib/container and lib/apps should  _not_ be visible, EmbededTomcat
  *will handle that. All the application files you want visible from 
  *tomcat must be included as well.
- *ADVANCED1. Completely separated classloader
+ *ADVANCED1. Completely separated classloader
  *
- *  - In your adapter, create an instance of EmbededTomcat.
+ *In your adapter, create an instance of EmbededTomcat.
  * 
- *  - set properties you want to customize. 
+ *set properties you want to customize.
  *  
- *  - add all interceptors including your application-specific. That includes
- *   the connector modules ( shortcuts are provided for common sets of
- *   modules and for common connector configuration ).
+ *add all interceptors including your application-specific. That
+ *includes the connector modules ( shortcuts are provided for common sets of
+ *modules and for common connector configuration ).
  *
- *  - add the root context ( required ) and any other contexts you want.
+ *add the root context ( required ) and any other contexts you want.
  *More context can be added at runtime. You can also use existing
- *configuration modules that automatically add/deploy Contexts. 
+ *configuration modules that automatically add/deploy Contexts.
  *
- *  -  call start(). Tomcat will initialize and start. The method returns
- * when everything is ready.
+ *call start(). Tomcat will initialize and start. The method returns
+ *when everything is ready.
  * 
- *  -  You can add/remove contexts at runtime.
+ *You can add/remove contexts at runtime.
  *
- *  -  call stop(). Tomcat will clean up all resources and shutdown ( clean 
- * shutdown ). All common modules have been tested and shouldn't leave
- * any garbage, however it is possible that user code will leave threads
- * or other garbage ( i.e. not clean on destroy ). If tomcat is run in
- * a sandbox, this shouldn't be a problem ( as untrusted servlets can't
- * create threads ). It is your responsiblit

Apache Test

2001-12-25 Thread willy wang 

When I try to test Apache Tomcat,an error message occurs

HTTP Status 404(The requested resource (/demo/demo.jsp) is not available.)

How to create the demo.jsp?I just created a notepad text file and named it 
demo.jsp.


William

_
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com


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