search engine?

2001-01-02 Thread hsiehLingGhan 



Hi,
 
Does tomcat-apache provide site search 
functionality? If not, should i use applet plug-in that acts as a search engine? 

Please consult. Thanks.
 
Hsieh Ling

Re: classreloading and 4.x

2001-01-02 Thread Craig R. McClanahan 

Jon Stevens wrote:

> on 1/2/2001 10:15 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
> wrote:
>
> > 's OK -- you will thank me the first time you need to update a deployed app on
> > a
> > production server without taking down Catalina :-).
>
> eh?
>

If you install the manager webapp (and set up an appropriate username),
reload-on-command will work for you even on a production server where you don't turn
on "autoreload".

>
> > There is none, and cannot be (for the same reason you cannot write a complete
> > DTD
> > for Ant) -- the set of elements, and the attributes supported by a particular
> > element, are extensible.
> >
> > There is the beginnings of documentation for all of the available options --
> > mostly
> > up to date but not complete yet -- at the following location in the source
> > tree:
> >
> > catalina/docs/config/index.html
>
> Yea, believe it or not, I actually had checked there first, but just didn't
> see it. :-(
>

Amazing ... someone who actually looks at the docs first!!!   :-)

Oh well, getting this stuff up to date is one of my major goals during the beta
cycle -- the code is solid enough that there shouldn't be all that many bugs to fix.

>
> > For anyone who cannot figure out how to get the build to work :-) there is
> > always
> > the nightly binary distributions:
> >
> > http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/
> >
> > Tonight's post (at around 5am Pacific time) will include the fix.
>
> Yea, I was hoping I didn't have to stay up till 5am to get it. :-)
>

You've got mail.

>
> -jon
>

Craig



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

Re: classreloading and 4.x

2001-01-02 Thread Jon Stevens 

on 1/2/2001 10:15 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
wrote:

> 's OK -- you will thank me the first time you need to update a deployed app on
> a
> production server without taking down Catalina :-).

eh?

> There is none, and cannot be (for the same reason you cannot write a complete
> DTD
> for Ant) -- the set of elements, and the attributes supported by a particular
> element, are extensible.
> 
> There is the beginnings of documentation for all of the available options --
> mostly
> up to date but not complete yet -- at the following location in the source
> tree:
> 
> catalina/docs/config/index.html

Yea, believe it or not, I actually had checked there first, but just didn't
see it. :-(

> For anyone who cannot figure out how to get the build to work :-) there is
> always
> the nightly binary distributions:
> 
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/
> 
> Tonight's post (at around 5am Pacific time) will include the fix.

Yea, I was hoping I didn't have to stay up till 5am to get it. :-)

-jon


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

Re: classreloading and 4.x

2001-01-02 Thread Craig R. McClanahan 

Jon Stevens wrote:

> on 1/2/2001 6:22 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
> wrote:
>
> > I just tried this again (against current CVS code) with Vincent's original
> > test
> > cases and it works fine for me.  I can send you the test suite if you like, to
> > verify that it works/doesn't work in your environment.
> >
> > One issue that might cause this appearance is if you don't wait long enough.
> > By
> > default, Tomcat 4.0 checks for classfile changes every 15 seconds, if
> > reloadable
> > is set to true.  You can change this as follows:
> >
> > 
> > 
> > 
> >
> > As an alternative (and this works even on apps that you have not defined as
> > "reloadable" in server.xml), consider this strategy:
> >
> > * Install the "manager" webapp that comes with Tomcat if not
> > present already.
> >
> > * Create a user with role "manager" in server/tomcat-users.xml
> > (actual username and password are arbitrary).
> >
> > * Whenever you want to restart Scarab, issue an HTTP request to:
> > http://localhost:8080/manager/reload?path=/xxx
> > where /xxx is the context path (empty string for the root webapp).
> >
> > * You will need to log on (BASIC authentication) the first time you
> > do this, with the username/password you created above.
>
> Na. That is annoying. :-) I would rather just have this check turned down to
> something like 3 seconds. I didn't realize that there is a Loader
> checkInterval setting.
>

's OK -- you will thank me the first time you need to update a deployed app on a
production server without taking down Catalina :-).

>
> BTW, where is the DTD for the server.xml file? There isn't one defined at
> the top of the file.
>

There is none, and cannot be (for the same reason you cannot write a complete DTD
for Ant) -- the set of elements, and the attributes supported by a particular
element, are extensible.

There is the beginnings of documentation for all of the available options -- mostly
up to date but not complete yet -- at the following location in the source tree:

catalina/docs/config/index.html


>
> > NOTE:  In reviewing the code, it looks like this won't handle the root webapp
> > correctly until I do a quick bugfix, but the basic principle applies.
>
> Can you email me privately a copy of the fixed server.jar file as I can't
> build Tomcat yet. :-)
>

The patch is in CVS now.  I will send you the test suite I use, and the most recent
"catalina.jar" -- the file of interest is
"org/apache/catalina/servlets/ManagerServlet.class".

For anyone who cannot figure out how to get the build to work :-) there is always
the nightly binary distributions:

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

Tonight's post (at around 5am Pacific time) will include the fix.

>
> thanks,
>
> -jon
>

Craig


>
> --
> Honk if you love peace and quiet.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]


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

Re: cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml

2001-01-02 Thread Jon Stevens 

on 1/2/2001 10:08 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
wrote:

> That's why the values stored in the HashMap are ArrayLists of all the values
> received for that header name, as the JavaDoc comment immediately above this
> line points out :-).

doh!

-jon


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

Re: cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml

2001-01-02 Thread Craig R. McClanahan 

Jon Stevens wrote:

> on 1/2/2001 9:50 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> > +protected HashMap saveHeaders = new HashMap();
>
> What if there is more than one header?
>
> Set-Cookie:
>

That's why the values stored in the HashMap are ArrayLists of all the values
received for that header name, as the JavaDoc comment immediately above this
line points out :-).

>
> -jon
>

Craig


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


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

Re: cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml

2001-01-02 Thread Jon Stevens 

on 1/2/2001 9:50 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> +protected HashMap saveHeaders = new HashMap();

What if there is more than one header?

Set-Cookie:

-jon


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

cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml

2001-01-02 Thread craigmcc 

craigmcc01/01/02 21:50:46

  Modified:tester/src/bin tester.xml
   tester/src/tester/org/apache/tester TestClient.java
   tester/web/WEB-INF web.xml
  Added:   tester/src/tester/org/apache/tester SetLocale01.java
  Log:
  Refactor TestClient so that common validation logic is shared.  Also, add
  the missing logic to validate the output headers.
  
  Add a positive test for ServletResponse.setLocale() since the current
  Watchdog 4.0 version of this test is broken.
  
  Revision  ChangesPath
  1.6   +11 -1 jakarta-tomcat-4.0/tester/src/bin/tester.xml
  
  Index: tester.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- tester.xml2001/01/03 02:46:07 1.5
  +++ tester.xml2001/01/03 05:50:45 1.6
  @@ -188,9 +188,19 @@
request="${context.path}/SetBufferSize01"
 outContent="SetBufferSize01 PASSED"/>
   
  -
  +
  +
  +
  +
   
   
 
  
  
  
  1.4   +188 -35   
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/TestClient.java
  
  Index: TestClient.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/TestClient.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- TestClient.java   2000/12/26 18:57:44 1.3
  +++ TestClient.java   2001/01/03 05:50:45 1.4
  @@ -67,6 +67,9 @@
   import java.net.HttpURLConnection;
   import java.net.Socket;
   import java.net.URL;
  +import java.util.ArrayList;
  +import java.util.HashMap;
  +import java.util.Iterator;
   import org.apache.tools.ant.BuildException;
   import org.apache.tools.ant.Task;
   
  @@ -112,12 +115,23 @@
* 
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.3 $ $Date: 2000/12/26 18:57:44 $
  + * @version $Revision: 1.4 $ $Date: 2001/01/03 05:50:45 $
*/
   
   public class TestClient extends Task {
   
   
  +// - Instance Variables
  +
  +
  +/**
  + * The saved headers we received in our response.  The key is the header
  + * name (converted to lower case), and the value is an ArrayList of the
  + * string value(s) received for that header.
  + */
  +protected HashMap saveHeaders = new HashMap();
  +
  +
   // - Properties
   
   
  @@ -304,6 +318,7 @@
*/
   public void execute() throws BuildException {
   
  +saveHeaders.clear();
   if ((protocol == null) || (protocol.length() == 0))
   executeHttp();
   else
  @@ -400,36 +415,45 @@
   }
   
   // Dump out the response stuff
  -if (debug >= 1) {
  +if (debug >= 1)
   System.out.println("RESP: " + conn.getResponseCode() + " " +
  conn.getResponseMessage());
  -for (int i = 0; i < 1000; i++) {
  -String name = conn.getHeaderFieldKey(i);
  -String value = conn.getHeaderField(i);
  -if ((name == null) || (value == null))
  -break;
  +for (int i = 1; i < 1000; i++) {
  +String name = conn.getHeaderFieldKey(i);
  +String value = conn.getHeaderField(i);
  +if ((name == null) || (value == null))
  +break;
  +if (debug >= 1)
   System.out.println("HEAD: " + name + ": " + value);
  -}
  +save(name, value);
  +}
  +if (debug >= 1) {
   System.out.println("DATA: " + outData);
   if (outText.length() > 2)
   System.out.println("TEXT: " + outText);
   }
   
   // Validate the response against our criteria
  -if (status != conn.getResponseCode()) {
  -success = false;
  -result = "Expected status=" + status + ", got status=" +
  -conn.getResponseCode();
  -} else if ((message != null) &&
  -   !message.equals(conn.getResponseMessage())) {
  -success = false;
  -result = "Expected message='" + message + "', got message='" +
  -conn.getResponseMessage() + "'";
  -} else if ((outContent != null) &&
  -   !outData.startsWith(outContent)) {
  -success = false;
  -result = outData;
  +if (success) {
  +result = validateStatus(conn.getResponseCode());
  +if (result != null)
  +succes

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util CharsetMapperDefault.properties

2001-01-02 Thread craigmcc 

craigmcc01/01/02 21:39:54

  Added:   catalina/src/share/org/apache/catalina/util
CharsetMapperDefault.properties
  Log:
  Add a missing properties file that would, among other things, cause
  ServletResponse.setLocale() to throw a NullPointerException.
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/CharsetMapperDefault.properties
  
  Index: CharsetMapperDefault.properties
  ===
  ar=ISO-8859-6
  be=ISO-8859-5
  bg=ISO-8859-5
  ca=ISO-8859-1
  cs=ISO-8859-2
  da=ISO-8859-1
  de=ISO-8859-1
  el=ISO-8859-7
  en=ISO-8859-1
  es=ISO-8859-1
  et=ISO-8859-1
  fi=ISO-8859-1
  fr=ISO-8859-1
  hr=ISO-8859-2
  hu=ISO-8859-2
  is=ISO-8859-1
  it=ISO-8859-1
  iw=ISO-8859-8
  ja=Shift_JIS
  ko=EUC-KR
  lt=ISO-8859-2
  lv=ISO-8859-2
  mk=ISO-8859-5
  nl=ISO-8859-1
  no=ISO-8859-1
  pl=ISO-8859-2
  pt=ISO-8859-1
  ro=ISO-8859-2
  ru=ISO-8859-5
  sh=ISO-8859-5
  sk=ISO-8859-2
  sl=ISO-8859-2
  sq=ISO-8859-2
  sr=ISO-8859-5
  sv=ISO-8859-1
  tr=ISO-8859-9
  uk=ISO-8859-5
  zh=GB2312
  zh_TW=Big5
  
  
  

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

Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories

2001-01-02 Thread Remy Maucherat 

> Now that we've all recovered from New Years (and watched Oregon State
teach
> Notre Dame a few things about football -- go Beavers! :-), it's time to
lay out
> the next steps in Tomcat 4.0's lifetime.  Here's what I propose:
>
>
>
> (1) Tomcat 4.0 Beta 1
>
> The code for Tomcat 4.0 has proven to be quite solid and reasonably bug
free
> (except for the new web connector -- see below), so it's time to start
doing
> beta cycles to increase the exposure and testing it receives.  I would
like us
> to move quickly towards a "release quality" build, and therefore propose
to
> create Tomcat 4.0 Beta 1 on Friday 5, 2001 -- after having a chance to
integrate
> a few more bug fixes for issues that were reported in the last couple of
weeks.

I have 4 items on my list :
- I don't like the getReporter() call. I think it should return the normal
stream, instead of creating a new one.
- Problems with setStatus() and error page generation (that's linked to the
item above).
- Enhance URL encoding according to a patch which was submitted a few days
ago.
- Stalled processors if client abruptely disconnects.

> The web connector code is much less tested than the standalonie connector,
so I
> propose that we highlight the fact that this portion of Tomcat 4.0 is
still
> alpha quality.  The build process has been organized so that we can create
two
> files (mod_webapp.so and warp.jar) and publish updates separately, if
needed,
> without doing a complete release.  This will help us isolate and fix such
> problems more quickly.
>
> The existing "jakarta-tomcat-4.0" repository will be branched with label
> "tomcat_40_branch", and each 4.0.x beta and release will receive a label
such as
> "tomcat_40_b1".  The "main" branch of this repository will be active for
bug
> fixes on 4.0, while major new development will shift to the 4.1 repository
> described below.

+1.

> (2) Tomcat 4.1 Repository
>
> As we approach a release quality build for Tomcat 4.0, it is also time to
split
> the development of major new functionality (such as the distributed
session
> management currently under discussion) into a development process that
does not
> destabilize the 4.0 release code.  We can do this with a branch or a new
> repository.  After thinking about the relative merits of this for a bit,
and
> consulting with others who have managed similar evoluations, I think a new
> repository is the way to go.
>
> Therefore, I propose to create a new "jakarta-tomcat-4.1" repository on
Friday
> as well, based originally on the code that is marked for Tomcat 4.0 beta
1.
> Because this code is just another portion of the overall code base for
Tomcat,
> all existing Tomcat committers will have write access to it (just as they
do
> with "jakarta-tomcat" and "jakarta-tomcat-4.0" today) -- no extra
committer
> votes are required.
>
> NOTE:  Pending this change, I would ask that we *not* commit changes to
the 4.0
> repository for new features that will appear in 4.1, until *after* the
split.
>
> At the same time, I will modify the build processes that create nightly
> distributions of Tomcat to create a build of the most recent 4.0 tree and
the
> most recent 4.1 tree, so that people interested in either version can
follow
> along as they prefer.

I think I like having a new repository a bit better.

> (3) New "jakarta-servletapi-4.0" CVS Repository
>
> Consistent with the suggested approach for separate Tomcat repositories
for each
> major version, I suggest that we also split the repository for the servlet
2.3 /
> JSP 1.2 API classes.  Currently, this code is in a branch
(SERVET_23_JSP_12) of
> the "jakarta-servletapi" repository, which makes life tougher on build
scripts
> than is necessary.
>
> Therefore, I propose that we also create a new repository for these API
classes
> (the "4.0" part of the number matching the Tomcat major version number),
with
> these classes pulled out of the "jakarta-servletapi" repository -- which
will
> remain the current code base for servlet 2.2 / JSP 1.1.

+1.

Remy


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

Phone dialin for meeting

2001-01-02 Thread Jim Driscoll 

James Duncan Davidson wrote:

> Yep. It will be an open meeting. Phone dialups are going to be investigated.

A number will be available for dialup.

It may not be toll-free however :-(  I'm looking into it.  

Can I have a show of hands (PRIVATELY! TO MY PERSONAL EMAIL NOT THE
LIST! Don't want Duncan on my case) of how many people will be attending
via phone.

Remember - send a *I will be dialing in* message to
[EMAIL PROTECTED] 
NOT tomcat-dev.

Jim

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

Re: classreloading and 4.x

2001-01-02 Thread Jon Stevens 

on 1/2/2001 6:22 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
wrote:

> I just tried this again (against current CVS code) with Vincent's original
> test
> cases and it works fine for me.  I can send you the test suite if you like, to
> verify that it works/doesn't work in your environment.
> 
> One issue that might cause this appearance is if you don't wait long enough.
> By
> default, Tomcat 4.0 checks for classfile changes every 15 seconds, if
> reloadable
> is set to true.  You can change this as follows:
> 
> 
> 
> 
> 
> As an alternative (and this works even on apps that you have not defined as
> "reloadable" in server.xml), consider this strategy:
> 
> * Install the "manager" webapp that comes with Tomcat if not
> present already.
> 
> * Create a user with role "manager" in server/tomcat-users.xml
> (actual username and password are arbitrary).
> 
> * Whenever you want to restart Scarab, issue an HTTP request to:
> http://localhost:8080/manager/reload?path=/xxx
> where /xxx is the context path (empty string for the root webapp).
> 
> * You will need to log on (BASIC authentication) the first time you
> do this, with the username/password you created above.

Na. That is annoying. :-) I would rather just have this check turned down to
something like 3 seconds. I didn't realize that there is a Loader
checkInterval setting.

BTW, where is the DTD for the server.xml file? There isn't one defined at
the top of the file.

> NOTE:  In reviewing the code, it looks like this won't handle the root webapp
> correctly until I do a quick bugfix, but the basic principle applies.

Can you email me privately a copy of the fixed server.jar file as I can't
build Tomcat yet. :-)

thanks,

-jon

-- 
Honk if you love peace and quiet.


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

cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml

2001-01-02 Thread craigmcc 

craigmcc01/01/02 18:46:08

  Modified:tester/src/bin tester.xml
   tester/web/WEB-INF web.xml
  Added:   tester/src/tester/org/apache/tester Reset01.java
  Log:
  Add a positive test for ServletResponse.reset() since the current watchdog
  4.0 test for this is broken.
  
  Revision  ChangesPath
  1.5   +8 -0  jakarta-tomcat-4.0/tester/src/bin/tester.xml
  
  Index: tester.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- tester.xml2000/12/26 18:57:43 1.4
  +++ tester.xml2001/01/03 02:46:07 1.5
  @@ -177,6 +177,14 @@
   
   
   
  +
  +
  +
  +
   
  
  
  
  1.1  
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Reset01.java
  
  Index: Reset01.java
  ===
  /* = *
   *   *
   * The Apache Software License,  Version 1.1 *
   *   *
   * Copyright (c) 1999, 2000  The Apache Software Foundation. *
   *   All rights reserved.*
   *   *
   * = *
   *   *
   * Redistribution and use in source and binary forms,  with or without modi- *
   * fication, are permitted provided that the following conditions are met:   *
   *   *
   * 1. Redistributions of source code  must retain the above copyright notice *
   *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 ."  *
   *   *
   *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 Software Foundation.*
   *   *
   * 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.   *
   *   *
   * =

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets ManagerServlet.java

2001-01-02 Thread craigmcc 

craigmcc01/01/02 18:20:46

  Modified:catalina/src/share/org/apache/catalina/servlets
ManagerServlet.java
  Log:
  Support management of the ROOT web application (i.e. the one mapped to an
  empty string as the context path).
  
  Revision  ChangesPath
  1.3   +10 -7 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java
  
  Index: ManagerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- ManagerServlet.java   2000/10/05 02:30:22 1.2
  +++ ManagerServlet.java   2001/01/03 02:20:46 1.3
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
 1.2 2000/10/05 02:30:22 craigmcc Exp $
  - * $Revision: 1.2 $
  - * $Date: 2000/10/05 02:30:22 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
 1.3 2001/01/03 02:20:46 craigmcc Exp $
  + * $Revision: 1.3 $
  + * $Date: 2001/01/03 02:20:46 $
*
* 
*
  @@ -123,7 +123,7 @@
* 
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.2 $ $Date: 2000/10/05 02:30:22 $
  + * @version $Revision: 1.3 $ $Date: 2001/01/03 02:20:46 $
*/
   
   public final class ManagerServlet
  @@ -273,7 +273,8 @@
log("deploy: Deploying web application at '" + path +
"' from '" + war + "'");
   
  -if ((path == null) || !path.startsWith("/")) {
  +if ((path == null) ||
  +(!path.startsWith("/") && !path.equals(""))) {
   writer.println(sm.getString("managerServlet.invalidPath", path));
   return;
   }
  @@ -332,7 +333,8 @@
   if (debug >= 1)
log("restart: Reloading web application at '" + path + "'");
   
  -if ((path == null) || !path.startsWith("/")) {
  +if ((path == null) ||
  +(!path.startsWith("/") && !path.equals(""))) {
   writer.println(sm.getString("managerServlet.invalidPath", path));
   return;
   }
  @@ -365,7 +367,8 @@
   if (debug >= 1)
log("undeploy: Undeploying web application at '" + path + "'");
   
  -if ((path == null) || !path.startsWith("/")) {
  +if ((path == null) ||
  +(!path.startsWith("/") && !path.equals(""))) {
   writer.println(sm.getString("managerServlet.invalidPath", path));
   return;
   }
  
  
  

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

Re: classreloading and 4.x

2001-01-02 Thread Craig R. McClanahan 

Jon Stevens wrote:

> Ok, I have this in my server.xml:
>
> 
>
> Yet when I change a class in my WEB-INF/classes directory, it doesn't get
> reloaded. Any ideas?
>

I just tried this again (against current CVS code) with Vincent's original test
cases and it works fine for me.  I can send you the test suite if you like, to
verify that it works/doesn't work in your environment.

One issue that might cause this appearance is if you don't wait long enough.  By
default, Tomcat 4.0 checks for classfile changes every 15 seconds, if reloadable
is set to true.  You can change this as follows:





As an alternative (and this works even on apps that you have not defined as
"reloadable" in server.xml), consider this strategy:

* Install the "manager" webapp that comes with Tomcat if not
  present already.

* Create a user with role "manager" in server/tomcat-users.xml
  (actual username and password are arbitrary).

* Whenever you want to restart Scarab, issue an HTTP request to:
http://localhost:8080/manager/reload?path=/xxx
  where /xxx is the context path (empty string for the root webapp).

* You will need to log on (BASIC authentication) the first time you
  do this, with the username/password you created above.

NOTE:  In reviewing the code, it looks like this won't handle the root webapp
correctly until I do a quick bugfix, but the basic principle applies.

>
> -jon

Craig

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

gracefull shutdown/removal of worker from load balance...

2001-01-02 Thread Michael Kuz 
Title: gracefull shutdown/removal of worker from load balance...





Hello all,
How do I remove a worker from the load balancer without killing its current sessions?


i.e.: I don't want any new sessions created on that worker, and the existing sessions must be allowed to expire 'naturally'

(I can't just delete the entry from the balanced_workers property of the load balancer or current/established sessions get killed/ are not redirected to the

proper worker) 


Our setup: We've got multiple Apache web servers behind LVS with multiple TC(3.2) boxes behind the web servers... 


Thanks in advance





Michael R. Kuz
Developer
Service Intelligence
(403) 261-5000 ext. 363
[EMAIL PROTECTED]

classreloading and 4.x

2001-01-02 Thread Jon Stevens 

Ok, I have this in my server.xml:



Yet when I change a class in my WEB-INF/classes directory, it doesn't get
reloaded. Any ideas?

-jon


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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session StandardSession.java

2001-01-02 Thread craigmcc 

craigmcc01/01/02 16:17:09

  Modified:catalina/src/share/org/apache/catalina/core
ApplicationContext.java
   catalina/src/share/org/apache/catalina/session
StandardSession.java
  Log:
  Do not fire "attributeRemoved" application events when the app tries to
  remove session or servlet context attributes that do not exist.
  
  PR: BugRat Bug Report #681.
  Submitted by: Ramesh Mandava <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.9   +12 -7 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java
  
  Index: ApplicationContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- ApplicationContext.java   2000/11/03 00:21:15 1.8
  +++ ApplicationContext.java   2001/01/03 00:17:06 1.9
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
 1.8 2000/11/03 00:21:15 craigmcc Exp $
  - * $Revision: 1.8 $
  - * $Date: 2000/11/03 00:21:15 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
 1.9 2001/01/03 00:17:06 craigmcc Exp $
  + * $Revision: 1.9 $
  + * $Date: 2001/01/03 00:17:06 $
*
* 
*
  @@ -100,7 +100,7 @@
* associated with each instance of StandardContext.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.8 $ $Date: 2000/11/03 00:21:15 $
  + * @version $Revision: 1.9 $ $Date: 2001/01/03 00:17:06 $
*/
   
   public final class ApplicationContext
  @@ -572,15 +572,20 @@
   public void removeAttribute(String name) {
   
   Object value = null;
  +boolean found = false;
   
// Remove the specified attribute
synchronized (attributes) {
  - value = attributes.get(name);
  - attributes.remove(name);
  +found = attributes.containsKey(name);
  +if (found) {
  +value = attributes.get(name);
  +attributes.remove(name);
  +} else {
  +return;
  +}
}
   
// Notify interested application event listeners
  - // FIXME - Assumes we notify even if the attribute was not there?
Object listeners[] = context.getApplicationListeners();
if ((listeners == null) || (listeners.length == 0))
return;
  
  
  
  1.9   +12 -7 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java
  
  Index: StandardSession.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- StandardSession.java  2000/11/03 00:21:17 1.8
  +++ StandardSession.java  2001/01/03 00:17:08 1.9
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
 1.8 2000/11/03 00:21:17 craigmcc Exp $
  - * $Revision: 1.8 $
  - * $Date: 2000/11/03 00:21:17 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
 1.9 2001/01/03 00:17:08 craigmcc Exp $
  + * $Revision: 1.9 $
  + * $Date: 2001/01/03 00:17:08 $
*
* 
*
  @@ -109,7 +109,7 @@
* @author Craig R. McClanahan
* @author Sean Legassick
* @author mailto:[EMAIL PROTECTED]">Jon S. Stevens
  - * @version $Revision: 1.8 $ $Date: 2000/11/03 00:21:17 $
  + * @version $Revision: 1.9 $ $Date: 2001/01/03 00:17:08 $
*/
   
   final class StandardSession
  @@ -853,9 +853,15 @@
   
// Remove this attribute from our collection
Object value = null;
  +boolean found = false;
synchronized (attributes) {
  - value = attributes.get(name);
  - attributes.remove(name);
  +found = attributes.containsKey(name);
  +if (found) {
  +value = attributes.get(name);
  +attributes.remove(name);
  +} else {
  +return;
  +}
}
   
// Call the valueUnbound() method if necessary
  @@ -866,7 +872,6 @@
((HttpSessionBindingListener) value).valueUnbound(event);
   
// Notify interested application event listeners
  - // FIXME - Assumes we notify even if the attribute was not there?
StandardContext context = (StandardContext) manager.getContainer();
Object listeners[] = context.getApplicationListeners(

Re: BugRat Report #690 has been filed.

2001-01-02 Thread Glenn Nielsen 

This isn't a Tomcat bug, its the way security works (whether correct or not).
Perhaps this should be sent in as a Java bug report to Sun.

This is documented in tomcat-security.html, you have to comment out
the line:

package.access=sun.

in your $JAVA_HOME/jre/lib/security/java.security file.


BugRat Mail System wrote:
> 
> Bug report #690 has just been filed.
> 
> You can view the report at the following URL:
> 
>
> 
> REPORT #690 Details.
> 
> Project: Tomcat
> Category: Bug Report
> SubCategory: New Bug Report
> Class: swbug
> State: received
> Priority: high
> Severity: serious
> Confidence: public
> Environment:
>Release: Tomcat 3.2.1
>JVM Release: 1.2.2
>Operating System: Windows 2000 Pro
>OS Release: ?
>Platform: Intel
> 
> Synopsis:
> jsp compliation error
> 
> Description:
> The default javasoft/JRE/1.2/lib/security/java.security file restricts use of the 
>sun. packages.
> 
> Both Tomcat and EmbededTomcat fail with the following error:
> 
> Unable to compile class for JSP
> java.security.AccessControlException: access denied (java.lang.RuntimePermission 
>accessClassInPackage.sun.tools.java
> 
> Adding the following to the default tomcat.policy file does not correct the error:
> 
> grant {
>   permission java.lang.RuntimePermission "accessClassInPackage.sun.tools.java";
> };
> 
>   
>--
>  Name: Report-690.html
>Report-690.html   Type: Hypertext Markup Language (text/html)
>  Encoding: 7bit
>   Description: DataSource attachment 'Report-690.html'
> 
>Part 1.3Type: Plain Text (text/plain)

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

binding to a specific ip doesn't work as exspected

2001-01-02 Thread Thomas Butter 

Binding tomcat to a IP that is not an IP of the hostname fails, because 
it is checked in org.apache.catalina.connector.HttpConnector.open().

I don't think that this makes any sense. In a virtual host enviroment 
the hostname doesn't need to have A RRs for all IPs.

A simple fix would be to exchange the open() function with this code:

   /**
* Open and return the server socket for this Connector.  If an IP
* address has been specified, the socket will be opened only on that
* address; otherwise it will be opened on all addresses.
*
* @exception IOException if an input/output error occurs
*/ 
   private ServerSocket open() throws IOException {
  
   // Acquire the server socket factory for this Connector
   ServerSocketFactory factory = getFactory();

   // If no address is specified, open a connection on all addresses
   if (address == null) {
   log(sm.getString("httpConnector.allAddresses")); 
   return (factory.createSocket(port, acceptCount));
   }

   // Open InetAddress a server socket on the specified address
   // Simply get the InetAddress for the address
is=InetAddress.getByName(address);
log(sm.getString("httpConnector.anAddress", address));
return (factory.createSocket(port, acceptCount,is));
}


The error check you used before should not be necessary because the 
ServerSocket constructor should throw a IOException if you use a 
non-local-interface.


Thomas Butter


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

BugRat Report #691 has been filed.

2001-01-02 Thread BugRat Mail System 

Bug report #691 has just been filed.

You can view the report at the following URL:

   

REPORT #691 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment: 
   Release: 3.2.1
   JVM Release: 1.2.2
   Operating System: Windows 2000 Pro
   OS Release: ?
   Platform: Intel

Synopsis: 
Removing contexts from EmbededTomcat causes cpu util to go to 100%

Description:
Collection c = m_contexts.values();
for (Iterator x = c.iterator(); x.hasNext();)
  m_server.removeContext((ServletContext) x.next());

If a request is sent to a "removed" context, the jvm process uses 100% of the cpu, and 
the process must be killed.  The browser does not timeout.  Additional requests also 
hang.

Title: 
BugRat Report #
691





BugRat Report #
691




Project:
Tomcat


Release:
3.2.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
critical




Confidence:
public





Submitter:
Chris McClelen ( [EMAIL PROTECTED] )

Date Submitted:
Jan 2 2001, 05:24:55 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

Removing contexts from EmbededTomcat causes cpu util to go to 100%


 Environment: (jvm, os, osrel, platform)

1.2.2, Windows 2000 Pro, ?, Intel



Additional Environment Description:





Report Description:

Collection c = m_contexts.values();
for (Iterator x = c.iterator(); x.hasNext();)
  m_server.removeContext((ServletContext) x.next());

If a request is sent to a "removed" context, the jvm process uses 100% of the cpu, and the process must be killed.  The browser does not timeout.  Additional requests also hang.



Workaround:

null



View this report online...






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

BugRat Report #690 has been filed.

2001-01-02 Thread BugRat Mail System 

Bug report #690 has just been filed.

You can view the report at the following URL:

   

REPORT #690 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: serious
Confidence: public
Environment: 
   Release: Tomcat 3.2.1
   JVM Release: 1.2.2
   Operating System: Windows 2000 Pro
   OS Release: ?
   Platform: Intel

Synopsis: 
jsp compliation error

Description:
The default javasoft/JRE/1.2/lib/security/java.security file restricts use of the sun. 
packages.

Both Tomcat and EmbededTomcat fail with the following error:

Unable to compile class for JSP
java.security.AccessControlException: access denied (java.lang.RuntimePermission 
accessClassInPackage.sun.tools.java 

Adding the following to the default tomcat.policy file does not correct the error:

grant {
  permission java.lang.RuntimePermission "accessClassInPackage.sun.tools.java";
};



Title: 
BugRat Report #
690





BugRat Report #
690




Project:
Tomcat


Release:
Tomcat 3.2.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
serious




Confidence:
public





Submitter:
Chris McClelen ( [EMAIL PROTECTED] )

Date Submitted:
Jan 2 2001, 05:14:51 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

jsp compliation error


 Environment: (jvm, os, osrel, platform)

1.2.2, Windows 2000 Pro, ?, Intel



Additional Environment Description:





Report Description:

The default javasoft/JRE/1.2/lib/security/java.security file restricts use of the sun. packages.

Both Tomcat and EmbededTomcat fail with the following error:

Unable to compile class for JSP
java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.sun.tools.java 

Adding the following to the default tomcat.policy file does not correct the error:

grant {
  permission java.lang.RuntimePermission "accessClassInPackage.sun.tools.java";
};





How To Reproduce:

null



Workaround:

null



View this report online...






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

Re: Authorization on Linux

2001-01-02 Thread Aaron Knauf 

I would go one further and advise against using the system user accounts for web user authentication.  Even if you are using SSL to encrypt traffic, it is easy to brute force a web password because the web server typically allows unlimited retries without locking the account, or delaying and in some configurations may not even log the attempts.

Another advantage to using an alternative user accounts database is that you don't have to give every web user access to all of the other facilities on your web server.  (If the user account doesn't exist, no-one can log in with it.)

Apache provides modules for authenticating against all sorts of other user accounts.  Perhaps you could try to hook in to one of these.

---
Aaron Knauf
Implementation Consultant
Genie Systems Ltd
Auckland, New Zealand
Ph. +64-9-573 3310 x812, email: [EMAIL PROTECTED]
http://www.geniesystems.com







"Craig R. McClanahan" <[EMAIL PROTECTED]>
03/01/2001 11:08
Please respond to tomcat-dev

        
        To:        [EMAIL PROTECTED], [EMAIL PROTECTED]
        cc:        
        Subject:        Re: Authorization on Linux


Mikael Pahmp wrote:

> I'm using Tomcat with Apache on a RedHat 6.2 Linux. I use the form-based login mechanism and want to authorize the user logins against the users/groups that are already defined in Linux. It seems to be possible by implementing an Interceptor.

It is certainily feasible to do this with a request interceptor (Tomcat 3.x) or
valve (Tomcat 4.x).  You would need to provide a custom implementation (you can
use the existing JDBCRealm implementation as a model) and configure Tomcat to
use it
in the server.xml file.

One very important thing you should consider before doing so, however, is the
way that usernames and passwords get communicated when using HTTP authentication
methods.  If you use BASIC or FORM-BASED authentication, your username and
password are
essentially passed as clear-text.  Therefore, if I can snoop the network
connection, I can now attack your server with a known-good username and password
-- *not* something you really want to have happen.

Moral of the story -- if you are in an environment where your network
connections are subject to snooping, use SSL, or DIGEST-mode authentication.
This is a good general principle even if your usernames and passwords relate
only to the webapp
you are running, but are even more important when exposure could increase
security risks on your entire server.

>
> Has anyone already done this and is willing to share his work?
>
> Otherwise, tips for how to do it is appreciated.
>
> /Mikael
>

Craig

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

Re: Authorization on Linux

2001-01-02 Thread Craig R. McClanahan 

Mikael Pahmp wrote:

> I'm using Tomcat with Apache on a RedHat 6.2 Linux. I use the form-based login 
>mechanism and want to authorize the user logins against the users/groups that are 
>already defined in Linux. It seems to be possible by implementing an Interceptor.

It is certainily feasible to do this with a request interceptor (Tomcat 3.x) or
valve (Tomcat 4.x).  You would need to provide a custom implementation (you can
use the existing JDBCRealm implementation as a model) and configure Tomcat to
use it
in the server.xml file.

One very important thing you should consider before doing so, however, is the
way that usernames and passwords get communicated when using HTTP authentication
methods.  If you use BASIC or FORM-BASED authentication, your username and
password are
essentially passed as clear-text.  Therefore, if I can snoop the network
connection, I can now attack your server with a known-good username and password
-- *not* something you really want to have happen.

Moral of the story -- if you are in an environment where your network
connections are subject to snooping, use SSL, or DIGEST-mode authentication. 
This is a good general principle even if your usernames and passwords relate
only to the webapp
you are running, but are even more important when exposure could increase
security risks on your entire server.

>
> Has anyone already done this and is willing to share his work?
>
> Otherwise, tips for how to do it is appreciated.
>
> /Mikael
>

Craig

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

BugRat Report #644 was closed (apparently by: Marc Saegesser)

2001-01-02 Thread BugRat Mail System 

Report #644 was closed by Person #0

   Synopsis: HttpSession.getId() causes null pointer exception

 (logged in as: Marc Saegesser)

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

BugRat Report #689 has been filed.

2001-01-02 Thread BugRat Mail System 

Bug report #689 has just been filed.

You can view the report at the following URL:

   

REPORT #689 Details.

Project: Servlet API
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: serious
Confidence: public
Environment: 
   Release: 3.2
   JVM Release: all
   Operating System: all
   OS Release: all
   Platform: all

Synopsis: 
Character encoding in request.getParameter()

Description:
Browsers use the character encoding of the form page
when send back the form data to the server.
Jakarta-servlet 3.2 with tomcat 3.2.1 does not
handle it properly. 
The getParameter() servlet API
function fails when the parameter encoding is
not the default ISO-8859-1.



Title: 
BugRat Report #
689





BugRat Report #
689




Project:
Servlet API


Release:
3.2




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
serious




Confidence:
public





Submitter:
_Anonymous ( [EMAIL PROTECTED] )

Date Submitted:
Jan 2 2001, 02:19:39 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

Character encoding in request.getParameter()


 Environment: (jvm, os, osrel, platform)

all, all, all, all



Additional Environment Description:





Report Description:

Browsers use the character encoding of the form page
when send back the form data to the server.
Jakarta-servlet 3.2 with tomcat 3.2.1 does not
handle it properly. 
The getParameter() servlet API
function fails when the parameter encoding is
not the default ISO-8859-1.





How To Reproduce:

null



Workaround:

null



View this report online...






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

BugRat Report #688 has been filed.

2001-01-02 Thread BugRat Mail System 

Bug report #688 has just been filed.

You can view the report at the following URL:

   

REPORT #688 Details.

Project: Catalina
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: serious
Confidence: public
Environment: 
   Release: M5
   JVM Release: 1.3
   Operating System: Windows NT
   OS Release: 2000
   Platform: intel

Synopsis: 
Classes not in WEB-INF/classes not recognized as a Servlet (followup to Bug 604)

Description:
In my web site, I do not put classes in WEB-INF/classes directory.  My servlet 
implementation classes that are not in this directory but in the class path were 
accepted and undestood to be valid javax.servlet.Servlet classes with M4, but M5 has 
broken this.  With M5 if my servlet classes are not in this directory but the class is 
in the classepath, the class does get instantiated but the casting to Servlet (in side 
core/StandardWrapper.java line 738-40) fails.

Title: 
BugRat Report #
688





BugRat Report #
688




Project:
Catalina


Release:
M5




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
serious




Confidence:
public





Submitter:
Mayank Shah ( [EMAIL PROTECTED] )

Date Submitted:
Jan 2 2001, 01:49:20 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

Classes not in WEB-INF/classes not recognized as a Servlet (followup to Bug 604)


 Environment: (jvm, os, osrel, platform)

1.3, Windows NT, 2000, intel



Additional Environment Description:





Report Description:

In my web site, I do not put classes in WEB-INF/classes directory.  My servlet implementation classes that are not in this directory but in the class path were accepted and undestood to be valid javax.servlet.Servlet classes with M4, but M5 has broken this.  With M5 if my servlet classes are not in this directory but the class is in the classepath, the class does get instantiated but the casting to Servlet (in side core/StandardWrapper.java line 738-40) fails.



How To Reproduce:

null



View this report online...






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

Re: The significance of root context

2001-01-02 Thread Shawn McMurdo 


Did you see my patch submitted to the list on 2000 Dec 23?
I think it addresses this problem.
Shawn
David Soroko wrote:
 Thanks --

David Soroko
mailto:[EMAIL PROTECTED]
http://www.geocities.com/SiliconValley/Campus/1628/
Manna Inc.

 

-Original
Message-
From: Thom Park [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 02,
2001 1:42 AM
To: [EMAIL PROTECTED]
Subject: Re: The significance
of root context
 
This is a known bug in tomcat and is documented in the release notes -
I got bit by this one as well ;-)
-T.
David Soroko wrote:

I am trying to understand the significance of the "root"
context in TC 3.2.
It seems that when no root context is defined i.e. when
nothing is mapped to "" path and
an unavailable resource is requested by a client, tomcat
takes up 100% CPU time and does not let go.
Must I always map some directory to the root context?
 
 
Steps to reproduce behavior in the standard TC 3.2 distribution:
* In server.xml comment out

(this has the effect that the webapps/ROOT is not mapped
to "").
* Start TC
* Connect to http://localhost:8080
Note: the same behavior can be seen if webapps/ROOT is
removed.
 
 
 
--

David Soroko
mailto:[EMAIL PROTECTED]
http://www.geocities.com/SiliconValley/Campus/1628/
Manna Inc.




--
Shawn McMurdo 
mailto:[EMAIL PROTECTED]
Lutris Technologies    http://www.lutris.com
Enhydra.Org   
http://www.enhydra.org
 

Authorization on Linux

2001-01-02 Thread Mikael Pahmp 

I'm using Tomcat with Apache on a RedHat 6.2 Linux. I use the form-based login 
mechanism and want to authorize the user logins against the users/groups that are 
already defined in Linux. It seems to be possible by implementing an Interceptor.

Has anyone already done this and is willing to share his work?

Otherwise, tips for how to do it is appreciated.

/Mikael

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

unable to install tomcat 3.1.1 on Solaris Intel

2001-01-02 Thread Kodali Anil 

Hi,

FYI, for whom it may concern,
I am currently trying to download the tomcat build 3.0 package for
Solaris Intel

# uncompress -c  jakarta-tomcat-3.1.1.tar.Z| tar xvf -
I get corruption errors upon trying to uncompress the Z file.
what should i do to intall tomcat on solaris x86
l.
Thanks,

Kodali Anil
Software Engineer
VisualSoft Techonologies Limited



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

[VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories

2001-01-02 Thread Craig R. McClanahan 

Now that we've all recovered from New Years (and watched Oregon State teach
Notre Dame a few things about football -- go Beavers! :-), it's time to lay out
the next steps in Tomcat 4.0's lifetime.  Here's what I propose:



(1) Tomcat 4.0 Beta 1

The code for Tomcat 4.0 has proven to be quite solid and reasonably bug free
(except for the new web connector -- see below), so it's time to start doing
beta cycles to increase the exposure and testing it receives.  I would like us
to move quickly towards a "release quality" build, and therefore propose to
create Tomcat 4.0 Beta 1 on Friday 5, 2001 -- after having a chance to integrate
a few more bug fixes for issues that were reported in the last couple of weeks.

The web connector code is much less tested than the standalonie connector, so I
propose that we highlight the fact that this portion of Tomcat 4.0 is still
alpha quality.  The build process has been organized so that we can create two
files (mod_webapp.so and warp.jar) and publish updates separately, if needed,
without doing a complete release.  This will help us isolate and fix such
problems more quickly.

The existing "jakarta-tomcat-4.0" repository will be branched with label
"tomcat_40_branch", and each 4.0.x beta and release will receive a label such as
"tomcat_40_b1".  The "main" branch of this repository will be active for bug
fixes on 4.0, while major new development will shift to the 4.1 repository
described below.



(2) Tomcat 4.1 Repository

As we approach a release quality build for Tomcat 4.0, it is also time to split
the development of major new functionality (such as the distributed session
management currently under discussion) into a development process that does not
destabilize the 4.0 release code.  We can do this with a branch or a new
repository.  After thinking about the relative merits of this for a bit, and
consulting with others who have managed similar evoluations, I think a new
repository is the way to go.

Therefore, I propose to create a new "jakarta-tomcat-4.1" repository on Friday
as well, based originally on the code that is marked for Tomcat 4.0 beta 1.
Because this code is just another portion of the overall code base for Tomcat,
all existing Tomcat committers will have write access to it (just as they do
with "jakarta-tomcat" and "jakarta-tomcat-4.0" today) -- no extra committer
votes are required.

NOTE:  Pending this change, I would ask that we *not* commit changes to the 4.0
repository for new features that will appear in 4.1, until *after* the split.

At the same time, I will modify the build processes that create nightly
distributions of Tomcat to create a build of the most recent 4.0 tree and the
most recent 4.1 tree, so that people interested in either version can follow
along as they prefer.



(3) New "jakarta-servletapi-4.0" CVS Repository

Consistent with the suggested approach for separate Tomcat repositories for each
major version, I suggest that we also split the repository for the servlet 2.3 /
JSP 1.2 API classes.  Currently, this code is in a branch (SERVET_23_JSP_12) of
the "jakarta-servletapi" repository, which makes life tougher on build scripts
than is necessary.

Therefore, I propose that we also create a new repository for these API classes
(the "4.0" part of the number matching the Tomcat major version number), with
these classes pulled out of the "jakarta-servletapi" repository -- which will
remain the current code base for servlet 2.2 / JSP 1.1.



Votes please?

Craig McClanahan




Votes please?




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

Thanks (was Re: TC3.x - status)

2001-01-02 Thread Paul Libbrecht 

Thanks,

Yes, real thanks for Tomcat, it does help our project a lot and was 
prbably one of the main tool we're using that encouraged us to go in 
the open-source spirit.

We are making a mathematical learning system called activemath (see 
www.mathweb.org/activemath) and are close to release. We are happily 
using tomcat as the only web and servlet engine, the jakart license 
provides us a worry-free environnement allowing us to concentrate on 
more math and learning oriented features.

It will be time one day we contribute to Tomcat, for sure... actually 
all my frustrations of web.xml were a lack of logging with them (this 
was fixed in 3.2 I think) and another we had suspected to be a real 
bug (an applet finally querying to load classes from another server) 
which  I believe is was, after all, a class-missing dumb problem. 
Those two contributions to Tomcat would have been... well... this 
should have turned to documentation.

So thanks again, this is a great tool and advances a fair amount the 
web-world and the freely-accessible knowledge philosophy.

Paul

PS: this class-missing problem turning out to be a security exception 
is a real problem (this was with NS4) and should be in some FAQ if 
there's any one day: an applet tries to load a class from the 
official source, not finding it tries some other stuffs... including 
the sun.* packages or (it happened to us) follows the link in the 
content delivered by the servlet (which happens to be in another 
package). Verbose class-loading is THE solution here.


At 23:38 -0800 01/01/01, [EMAIL PROTECTED] wrote:
>
>I hope our ( those who contributed time to tomcat3 ) work on tomcat helps
>you,
>Costin
>

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

BugRat Report #687 has been filed.

2001-01-02 Thread BugRat Mail System 

Bug report #687 has just been filed.

You can view the report at the following URL:

   

REPORT #687 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: medium
Severity: non-critical
Confidence: public
Environment: 
   Release: 3.2
   JVM Release: 1.3
   Operating System: nt 2000
   OS Release: 2000
   Platform: intel

Synopsis: 
classname null

Description:
Error: 500
Location: /dex/
Internal Servlet Error:

java.lang.IllegalStateException: Can't happen - classname is null, who added this ?
at org.apache.tomcat.core.ServletWrapper.loadServlet(ServletWrapper.java:261)
at org.apache.tomcat.core.ServletWrapper.init(ServletWrapper.java:289)
at org.apache.tomcat.core.Handler.service(Handler.java:254)
at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at 
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797)
at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at 
org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210)
at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
at java.lang.Thread.run(Thread.java:484)



Title: 
BugRat Report #
687





BugRat Report #
687




Project:
Tomcat


Release:
3.2




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
medium


Severity:
non-critical




Confidence:
public





Submitter:
_Anonymous ( [EMAIL PROTECTED] )

Date Submitted:
Jan 2 2001, 10:26:27 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

classname null


 Environment: (jvm, os, osrel, platform)

1.3, nt 2000, 2000, intel



Additional Environment Description:





Report Description:

Error: 500
Location: /dex/
Internal Servlet Error:

java.lang.IllegalStateException: Can't happen - classname is null, who added this ?
	at org.apache.tomcat.core.ServletWrapper.loadServlet(ServletWrapper.java:261)
	at org.apache.tomcat.core.ServletWrapper.init(ServletWrapper.java:289)
	at org.apache.tomcat.core.Handler.service(Handler.java:254)
	at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
	at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797)
	at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
	at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210)
	at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
	at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
	at java.lang.Thread.run(Thread.java:484)





View this report online...






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

RE: The significance of root context

2001-01-02 Thread David Soroko 



Thanks
 
--David 
Sorokomailto:[EMAIL PROTECTED]http://www.geocities.com/SiliconValley/Campus/1628/Manna 
Inc.  

  -Original Message-From: Thom Park 
  [mailto:[EMAIL PROTECTED]]Sent: Tuesday, January 02, 2001 1:42 
  AMTo: [EMAIL PROTECTED]Subject: Re: The 
  significance of root contextThis is a known bug in tomcat 
  and is documented in the release notes - I got bit by this one as well ;-) 
  -T. 
  David Soroko wrote: 
  
I am trying to understand the significance of the "root" 
context in TC 3.2. 
It seems that when no root context is defined i.e. when 
nothing is mapped to "" path and an unavailable 
resource is requested by a client, tomcat takes up 100% CPU time and does 
not let go. 
Must I always map some directory to the root 
context?     
Steps to reproduce behavior in the standard TC 3.2 
distribution: 
* In server.xml comment out  
(this has the effect that the webapps/ROOT is not mapped to 
""). 
* Start TC 
* Connect to http://localhost:8080 
Note: the same behavior can be seen if webapps/ROOT is 
removed.       
-- 
 
David Soroko mailto:[EMAIL PROTECTED] 
http://www.geocities.com/SiliconValley/Campus/1628/ 
Manna Inc.

BugRat Report #685 has been filed.

2001-01-02 Thread BugRat Mail System 

Bug report #685 has just been filed.

You can view the report at the following URL:

   

REPORT #685 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment: 
   Release: 4.0M5
   JVM Release: 1.3_01
   Operating System: Linux
   OS Release: 2.2
   Platform: x86

Synopsis: 
stalled processors

Description:
After running for some time tomcat can't process any more request because all 
processors are used.

I think the problem occurs when in every thread occured a SocketException in 
HttpProcessor.parse.

2001-01-02 12:36:01 HttpProcessor[80][13] process.parse
java.net.SocketException: Connection reset by peer: Connection reset by peer
at java.net.SocketInputStream.socketRead(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:86)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:186)
at java.io.BufferedInputStream.read(BufferedInputStream.java:204)
at 
org.apache.catalina.connector.http.SocketInputStream.readRequestLine(SocketInputStream.java:168)
at 
org.apache.catalina.connector.http.HttpProcessor.parseRequest(HttpProcessor.java:635)
at 
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:779)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:890)
at java.lang.Thread.run(Thread.java:484)


Title: 
BugRat Report #
685





BugRat Report #
685




Project:
Tomcat


Release:
4.0M5




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
critical




Confidence:
public





Submitter:
Thomas Butter ( [EMAIL PROTECTED] )

Date Submitted:
Jan 2 2001, 04:37:18 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

stalled processors


 Environment: (jvm, os, osrel, platform)

1.3_01, Linux, 2.2, x86



Additional Environment Description:





Report Description:

After running for some time tomcat can't process any more request because all processors are used.

I think the problem occurs when in every thread occured a SocketException in HttpProcessor.parse.

2001-01-02 12:36:01 HttpProcessor[80][13] process.parse
java.net.SocketException: Connection reset by peer: Connection reset by peer
at java.net.SocketInputStream.socketRead(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:86)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:186)
at java.io.BufferedInputStream.read(BufferedInputStream.java:204)
at org.apache.catalina.connector.http.SocketInputStream.readRequestLine(SocketInputStream.java:168)
at org.apache.catalina.connector.http.HttpProcessor.parseRequest(HttpProcessor.java:635)
at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:779)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:890)
at java.lang.Thread.run(Thread.java:484)




Workaround:

null



View this report online...






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