date:20001114

Bug report #386 has just been filed.

You can view the report at the following URL:

REPORT #386 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment:
Release: 3.12
JVM Release: 1.3
Operating System: SUN
OS Release: 2.7
Platform: Solaris

Synopsis:
Communication Breakdown between Apache and Tomcat

Description:
I am running Tomcat 3.12 with ssl-aware Apache 1.3.12. We have compiled the
mod_jserv.so for Solaris. The application runs fine with 4-5 users, but when the user
base increase (to 20-25), the response of the system becomes very slow. Besides, we
get an error: BROKEN PIPE. I believe this is a problem of communication between apache
and tomcat.
Can anyone help us out to resolve this problem?

Thanks & Regards,
Sharad Kumar.

Title:
BugRat Report #
386

BugRat Report #
386

Project:
Tomcat

Release:
3.12

Category:
Bug Report

SubCategory:
New Bug Report

Class:
swbug

State:
received

Priority:
high

Severity:
critical

Confidence:
public

Submitter:
Sharad Kumar ( [EMAIL PROTECTED] )

Date Submitted:
Nov 15 2000, 01:44:37 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )

Synopsis:

Communication Breakdown between Apache and Tomcat

Environment: (jvm, os, osrel, platform)

1.3, SUN, 2.7, Solaris

Additional Environment Description:

ssl-aware Apache 1.3.12 with Tomcat 3.12 and Cocoon 1.8. The platform is Solaris, Sun Os: 2.7

Report Description:

I am running Tomcat 3.12 with ssl-aware Apache 1.3.12. We have compiled the mod_jserv.so for Solaris. The application runs fine with 4-5 users, but when the user base increase (to 20-25), the response of the system becomes very slow. Besides, we get an error: BROKEN PIPE. I believe this is a problem of communication between apache and tomcat.
Can anyone help us out to resolve this problem?

Thanks & Regards,
Sharad Kumar.

How To Reproduce:

null

Workaround:

null

View this report online...

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

Closing Bug Reports?


I tried to find a way to close the following Bug Report through the
admin interface, but no matter which option I choose I only get the
admin menu:

> Bug report #380 has just been filed.
> [...]
> Synopsis:
> Sessions don't work without cookies

If someone else has more BugRat karma than I do, please close this 
one since I have committed a solution to the tomcat_32 branch.

Hans
-- 
Hans Bergsten   [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com

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

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/session StandardSessionInterceptor.java

2000-11-14 Thread bergsten


bergsten00/11/14 20:19:20

  Modified:src/share/org/apache/tomcat/session Tag: tomcat_32
StandardSessionInterceptor.java
  Log:
  Fix to Bug Report #380
  
  Added code for setting the session in the Request for the case
  when the session ID is received as part of the URL.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.5.2.2   +14 -0 
jakarta-tomcat/src/share/org/apache/tomcat/session/StandardSessionInterceptor.java
  
  Index: StandardSessionInterceptor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/session/StandardSessionInterceptor.java,v
  retrieving revision 1.5.2.1
  retrieving revision 1.5.2.2
  diff -u -r1.5.2.1 -r1.5.2.2
  --- StandardSessionInterceptor.java   2000/11/11 02:07:02 1.5.2.1
  +++ StandardSessionInterceptor.java   2000/11/15 04:19:19 1.5.2.2
  @@ -85,6 +85,7 @@
* session stuff ( cookie, rewrite, etc)
*
* @author [EMAIL PROTECTED]
  + * @author [EMAIL PROTECTED] (fixed it so that URL session ID is used)
*/
   public final class StandardSessionInterceptor  extends BaseInterceptor {
   int manager_note;
  @@ -121,6 +122,19 @@
log( "Configuration error in StandardSessionInterceptor - no context " + 
request );
}
   
  +  // Added by Hans:
  +  // First check if we have a valid session ID from the URL, set by the 
SessionInterceptor,
  +  // and if so, set it as the request session. If we have also received a valid 
session ID
  +  // as a cookie, the next section of code will reset the session to the one 
matching the
  +  // ID found in the cookie.
  +  String requestedSessionID = request.getRequestedSessionId();
  +  if (requestedSessionID != null) {
  +  if (debug > 0) log("Found URL session ID: " + requestedSessionID);
  +  sess = sM.findSession(requestedSessionID);
  +  if (sess != null)
  +  if (debug > 0) log("The URL session ID is valid");
  +  request.setSession(sess);
  +  }
   
// PF, loop across all cookies named JSESSIONID checking to see if any of them 
are valid.
// There should in most cases be a maximum of 2, and normally there will only 
be one. The
  
  
  

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

Re: Mapping Requests to Servlets

2000-11-14 Thread Thom Park


I think you'll find what you're looking for in

 org.apache.tomcat/request/SimpleMapper1.java

though I must confess to being no expert ;-)

-T

Aron Kramlik wrote:

> Hi,
>
> Could someone point me to the class in Tomcat where
> the servlet mappings are implemented.  i.e. Chapter 10
> of the 2.2 spec "Mapping Requests to Servlets".  In
> particular I am looking for the implementation
> of the wildcard rules.
>
> Thanks,
>
> Aron.
>
> --
> Aron Kramlik.
> [EMAIL PROTECTED]
> Tenzing Communications Inc.
> www.tenzing.com
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


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

Mapping Requests to Servlets

2000-11-14 Thread Aron Kramlik


Hi,

Could someone point me to the class in Tomcat where
the servlet mappings are implemented.  i.e. Chapter 10
of the 2.2 spec "Mapping Requests to Servlets".  In
particular I am looking for the implementation
of the wildcard rules.

Thanks,

Aron.

--
Aron Kramlik.
[EMAIL PROTECTED]
Tenzing Communications Inc.
www.tenzing.com

 

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

cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime JspRuntimeLibrary.java

2000-11-14 Thread pierred


pierred 00/11/14 17:51:54

  Modified:src/share/org/apache/jasper/runtime Tag: tomcat_32
JspRuntimeLibrary.java
  Log:
  Bug fix: Conversion of String to boolean was erroneous
  Submitted by: Gareth Morgan <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.4.4.1   +4 -4  
jakarta-tomcat/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java
  
  Index: JspRuntimeLibrary.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v
  retrieving revision 1.4
  retrieving revision 1.4.4.1
  diff -u -r1.4 -r1.4.4.1
  --- JspRuntimeLibrary.java2000/03/28 04:29:49 1.4
  +++ JspRuntimeLibrary.java2000/11/15 01:51:54 1.4.4.1
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v 
1.4 2000/03/28 04:29:49 akv Exp $
  - * $Revision: 1.4 $
  - * $Date: 2000/03/28 04:29:49 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v 
1.4.4.1 2000/11/15 01:51:54 pierred Exp $
  + * $Revision: 1.4.4.1 $
  + * $Date: 2000/11/15 01:51:54 $
*
* 
* 
  @@ -323,7 +323,7 @@
} else if (t.equals(boolean.class)) {
boolean[] tmpval = new boolean[values.length];
for (int i = 0 ; i < values.length; i++)
  - tmpval[i] = Boolean.getBoolean (values[i]);
  + tmpval[i] = (Boolean.valueOf(values[i])).booleanValue();
method.invoke (bean, new Object[] {tmpval});
} else if (t.equals(short.class)) {
short[] tmpval = new short[values.length];
  
  
  

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

BugRat Report #355 was closed (apparently by: Remy Maucherat)


Report #355 was closed by Person #0

   Synopsis: java.net.SocketException ConnectionReset by peer

 (logged in as: Remy Maucherat)

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

Re: Ajpv13 protocol

2000-11-14 Thread kenneth topp



Is there a separate mod_jk list?

I've posted a severe bug for ajp13, and I would like to contribute, but I
don't see a TODO for mod_jk or much discussion on plans for mod_jk and
related containers.

Thanks for any information,

Kenneth Topp

On Tue, 14 Nov 2000 [EMAIL PROTECTED] wrote:

> > Is there a RFC on Ajp protocol? Or any documentation at all?
>
> No, there are just incremental enhancements and changes to Ajp11 - and I
> would say we might still have some changes and enhancements.
>
> ( there are additional messages that will probably be needed, the current
> stuff is stable and if it can be documented if anyone volunteers to do so,
> but there are few more things planed for ajp13 that are not yet
> implemented. ).
>
> Costin
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


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

BugRat Report #342 was closed (apparently by: Remy Maucherat)


Report #342 was closed by Person #0

   Synopsis: include $JAVA_HOME/bin when call java or jdb on catalina.sh

 (logged in as: Remy Maucherat)

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

BugRat Report #341 was closed (apparently by: Remy Maucherat)


Report #341 was closed by Person #0

   Synopsis: include $JAVA_HOME/bin when make a java call on catalina.sh

 (logged in as: Remy Maucherat)

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

BugRat Report #381 was closed (apparently by: Remy Maucherat)


Report #381 was closed by Person #0

   Synopsis: can no longer forward to j_security_check

 (logged in as: Remy Maucherat)

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

Re: SSL -keytool problem

2000-11-14 Thread Barbara Nelson


You need to use the keytool that comes with JDK 1.3.  The keytool in JDK
1.2.2 doesn't have support for RSA.

Barbara Nelson.


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

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


remm00/11/14 17:08:24

  Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
  Log:
  - DefaultServlet won't do anything on a POST.
  - Noticed a check was missing in If-None-Match header handling (* wildcard).
  
  Revision  ChangesPath
  1.15  +29 -30
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
  
  Index: DefaultServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- DefaultServlet.java   2000/11/10 18:33:48 1.14
  +++ DefaultServlet.java   2000/11/15 01:08:23 1.15
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
 1.14 2000/11/10 18:33:48 remm Exp $
  - * $Revision: 1.14 $
  - * $Date: 2000/11/10 18:33:48 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
 1.15 2000/11/15 01:08:23 remm Exp $
  + * $Revision: 1.15 $
  + * $Date: 2000/11/15 01:08:23 $
*
* 
*
  @@ -112,7 +112,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.14 $ $Date: 2000/11/10 18:33:48 $
  + * @version $Revision: 1.15 $ $Date: 2000/11/15 01:08:23 $
*/
   
   public class DefaultServlet
  @@ -452,9 +452,6 @@
   protected void doPost(HttpServletRequest request,
 HttpServletResponse response)
throws IOException, ServletException {
  -
  - doPut(request, response);
  -
   }
   
   
  @@ -627,10 +624,12 @@
   // Checking If-None-Match
   headerValue = request.getHeader("If-None-Match");
   if (headerValue != null) {
  -if (headerValue.indexOf("*") == -1) {
  +
  +boolean conditionSatisfied = false;
  +
  +if (!headerValue.equals("*")) {
   
   commaTokenizer = new StringTokenizer(headerValue, ",");
  -boolean conditionSatisfied = false;
   
   while (!conditionSatisfied && commaTokenizer.hasMoreTokens()) {
   String currentToken = commaTokenizer.nextToken();
  @@ -638,29 +637,28 @@
   conditionSatisfied = true;
   }
   
  -if (conditionSatisfied) {
  -
  -// For GET and HEAD, we should respond with 
  -// 304 Not Modified.
  -// For every other method, 412 Precondition Failed is sent
  -// back.
  -if ( ("GET".equals(request.getMethod()))
  - || ("HEAD".equals(request.getMethod())) ) {
  -response.sendError
  -(HttpServletResponse.SC_NOT_MODIFIED);
  -return false;
  -} else {
  -response.sendError
  -(HttpServletResponse.SC_PRECONDITION_FAILED);
  -return false;
  -}
  -}
  -
   } else {
  -if (resourceInfo.exists()) {
  -
  +conditionSatisfied = true;
  +}
  +
  +if (conditionSatisfied) {
  +
  +// For GET and HEAD, we should respond with 
  +// 304 Not Modified.
  +// For every other method, 412 Precondition Failed is sent
  +// back.
  +if ( ("GET".equals(request.getMethod()))
  + || ("HEAD".equals(request.getMethod())) ) {
  +response.sendError
  +(HttpServletResponse.SC_NOT_MODIFIED);
  +return false;
  +} else {
  +response.sendError
  +(HttpServletResponse.SC_PRECONDITION_FAILED);
  +return false;
   }
   }
  +
   }
   
   // Checking If-Unmodified-Since
  @@ -1280,8 +1278,9 @@
}
   
   // Checking If headers
  -if ( !checkIfHeaders(request, response, resourceInfo) )
  +if ( !checkIfHeaders(request, response, resourceInfo) ) {
   return;
  +}
   
   // Find content type.
   String contentType = 
  
  
  

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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java


remm00/11/14 16:52:51

  Modified:catalina/src/share/org/apache/catalina/core
ApplicationHttpRequest.java
  Log:
  - Fix POST parameters decoding : parameters on the URL are decoded
using RequestUtil.URLDecode instead of java.net.URLDecoder.decode
  
  Revision  ChangesPath
  1.2   +5 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java
  
  Index: ApplicationHttpRequest.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ApplicationHttpRequest.java   2000/08/23 01:07:11 1.1
  +++ ApplicationHttpRequest.java   2000/11/15 00:52:50 1.2
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java,v
 1.1 2000/08/23 01:07:11 craigmcc Exp $
  - * $Revision: 1.1 $
  - * $Date: 2000/08/23 01:07:11 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java,v
 1.2 2000/11/15 00:52:50 remm Exp $
  + * $Revision: 1.2 $
  + * $Date: 2000/11/15 00:52:50 $
*
* 
*
  @@ -92,7 +92,7 @@
* keep these two classes in synchronization when making changes!
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.1 $ $Date: 2000/08/23 01:07:11 $
  + * @version $Revision: 1.2 $ $Date: 2000/11/15 00:52:50 $
*/
   
   class ApplicationHttpRequest extends HttpServletRequestWrapper {
  @@ -450,7 +450,7 @@
return;
   
HashMap queryParameters = new HashMap();
  - RequestUtil.parseParameters(queryParameters, queryString);
  + RequestUtil.parseParameters(queryParameters, queryString, true);
synchronized (parameters) {
Iterator keys = parameters.keySet().iterator();
while (keys.hasNext()) {
  
  
  

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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util RequestUtil.java


remm00/11/14 16:52:45

  Modified:catalina/src/share/org/apache/catalina/util RequestUtil.java
  Log:
  - Fix POST parameters decoding : parameters on the URL are decoded
using RequestUtil.URLDecode instead of java.net.URLDecoder.decode
  
  Revision  ChangesPath
  1.9   +17 -7 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.java
  
  Index: RequestUtil.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- RequestUtil.java  2000/10/28 01:39:45 1.8
  +++ RequestUtil.java  2000/11/15 00:52:45 1.9
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.java,v
 1.8 2000/10/28 01:39:45 craigmcc Exp $
  - * $Revision: 1.8 $
  - * $Date: 2000/10/28 01:39:45 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.java,v
 1.9 2000/11/15 00:52:45 remm Exp $
  + * $Revision: 1.9 $
  + * $Date: 2000/11/15 00:52:45 $
*
* 
*
  @@ -79,7 +79,7 @@
* General purpose request parsing and encoding utility methods.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.8 $ $Date: 2000/10/28 01:39:45 $
  + * @version $Revision: 1.9 $ $Date: 2000/11/15 00:52:45 $
*/
   
   public final class RequestUtil {
  @@ -217,10 +217,12 @@
*
* @param map Map that accumulates the resulting parameters
* @param data Input string containing request parameters
  + * @param urlParameters true if we're parsing parameters on the URL
*
* @exception IllegalArgumentException if the data is malformed
*/
  -public static void parseParameters(Map map, String data) {
  +public static void parseParameters(Map map, String data, 
  +   boolean urlParameters) {
   
   if ((data == null) || (data.length() < 1))
return;
  @@ -260,14 +262,22 @@
   // Decode the name and value if required
   if ((name.indexOf('%') >= 0) || (name.indexOf('+') >= 0)) {
   try {
  -name = URLDecoder.decode(name);
  +if (urlParameters) {
  +name = URLDecode(name);
  +} else {
  +name = URLDecoder.decode(name);
  +}
   } catch (Throwable t) {
   ;
   }
   }
   if ((value.indexOf('%') >= 0) || (value.indexOf('+') >= 0)) {
   try {
  -value = URLDecoder.decode(value);
  +if (urlParameters) {
  +value = URLDecode(value);
  +} else {
  +value = URLDecoder.decode(value);
  +}
   } catch (Throwable t) {
   ;
   }
  
  
  

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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector HttpRequestBase.java


remm00/11/14 16:52:35

  Modified:catalina/src/share/org/apache/catalina/connector
HttpRequestBase.java
  Log:
  - Fix POST parameters decoding : parameters on the URL are decoded
using RequestUtil.URLDecode instead of java.net.URLDecoder.decode
  
  Revision  ChangesPath
  1.13  +9 -8  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java
  
  Index: HttpRequestBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- HttpRequestBase.java  2000/10/28 01:39:43 1.12
  +++ HttpRequestBase.java  2000/11/15 00:52:35 1.13
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java,v
 1.12 2000/10/28 01:39:43 craigmcc Exp $
  - * $Revision: 1.12 $
  - * $Date: 2000/10/28 01:39:43 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java,v
 1.13 2000/11/15 00:52:35 remm Exp $
  + * $Revision: 1.13 $
  + * $Date: 2000/11/15 00:52:35 $
*
* 
*
  @@ -98,7 +98,7 @@
* be implemented.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.12 $ $Date: 2000/10/28 01:39:43 $
  + * @version $Revision: 1.13 $ $Date: 2000/11/15 00:52:35 $
*/
   
   public class HttpRequestBase
  @@ -581,7 +581,7 @@
String queryString = getQueryString();
if ((queryString != null) && (queryString.length() > 0)) {
try {
  - RequestUtil.parseParameters(results, queryString);
  + RequestUtil.parseParameters(results, queryString, true);
} catch (Throwable t) {
;
}
  @@ -609,10 +609,11 @@
String data = null;
String encoding = getCharacterEncoding();
if (encoding == null)
  - RequestUtil.parseParameters(results, new String(buf));
  + RequestUtil.parseParameters
  +(results, new String(buf), false);
else
  - RequestUtil.parseParameters(results,
  - new String(buf, encoding));
  + RequestUtil.parseParameters
  +(results, new String(buf, encoding), false);
} catch (Throwable t) {
;
}
  
  
  

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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector RequestBase.java


remm00/11/14 16:46:41

  Modified:catalina/src/share/org/apache/catalina/connector
RequestBase.java
  Log:
  - Make sure the request bytes are always consumed.
  
  Revision  ChangesPath
  1.6   +9 -4  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/RequestBase.java
  
  Index: RequestBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/RequestBase.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- RequestBase.java  2000/10/13 05:27:33 1.5
  +++ RequestBase.java  2000/11/15 00:46:41 1.6
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/RequestBase.java,v
 1.5 2000/10/13 05:27:33 craigmcc Exp $
  - * $Revision: 1.5 $
  - * $Date: 2000/10/13 05:27:33 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/RequestBase.java,v
 1.6 2000/11/15 00:46:41 remm Exp $
  + * $Revision: 1.6 $
  + * $Date: 2000/11/15 00:46:41 $
*
* 
*
  @@ -97,7 +97,7 @@
* the connector-specific methods need to be implemented.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.5 $ $Date: 2000/10/13 05:27:33 $
  + * @version $Revision: 1.6 $ $Date: 2000/11/15 00:46:41 $
*/
   
   public abstract class RequestBase
  @@ -482,6 +482,11 @@
* @exception IOException if an input/output error occurs
*/
   public void finishRequest() throws IOException {
  +
  +// If neither a reader or an is have been opened, do it to consume
  +// request bytes, if any
  +if ((reader == null) && (stream == null))
  +getInputStream();
   
// If a Reader has been acquired, close it
if (reader != null) {
  
  
  

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

Re: Ajpv13 protocol


> Is there a RFC on Ajp protocol? Or any documentation at all?

No, there are just incremental enhancements and changes to Ajp11 - and I
would say we might still have some changes and enhancements. 

( there are additional messages that will probably be needed, the current
stuff is stable and if it can be documented if anyone volunteers to do so,
but there are few more things planed for ajp13 that are not yet
implemented. ).

Costin 


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

Re: *.apache.org traffic, configuration, etc

2000-11-14 Thread Roy Wilson


Thanks, Jon

Roy

>> Original Message <<

On 11/14/00, 4:21:49 PM, Jon Stevens <[EMAIL PROTECTED]> wrote regarding Re: 
*.apache.org traffic, configuration, etc:


> on 11/11/2000 5:10 PM, "Roy Wilson" <[EMAIL PROTECTED]> wrote:

> > You mentioned that you thought *.apache.org gets 2M hits per day. Is
> > there a (good?) source of info re: hardware/software/traffic information?

> Essentially, i think it is a piii 500mhz box, lots of disk space, i think
> around 500megs of ram and it is running FreeBSD.

> FreeBSD locus.apache.org 4.1-STABLE FreeBSD 4.1-STABLE #1: Fri Aug 25
> 02:56:11 PDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/locus
> i386

> primary software is apache and qmail/ezmlm

> -jon

> --
> http://scarab.tigris.org/| http://noodle.tigris.org/
> http://java.apache.org/  | http://java.apache.org/turbine/
> http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
> http://www.collab.net/   | http://www.sourcexchange.com/



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

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

Re: [TC 3.2b7 PATCH] Sessions without cookies [Was: Re: BugRat Report#380 has been filed.]


Hi Hans,

The patch is great, +1 from me. ( it's the way the code was supposed to
work - if you look back 2-3 revisions for that file you'll find very
similar code ). It seems the patch for "multiple session cookies" broke
this part - it's great that we fix it back.

For 3.3 we should probably move the code that extracts the session id from
cookies back to the request/SessionInterceptor ( and rename it
SessionIdInterceptor ).

Costin


>   // First check if we have a valid session ID from the URL, set 
>   // by the SessionInterceptor, and if so, set it as the request 
>   // session. If we have also received a valid session ID
>   // as a cookie, the next section of code will reset the session 
>   // to the one matching the ID found in the cookie.
>   String requestedSessionID = request.getRequestedSessionId();
>   if (requestedSessionID != null) {
>   System.out.println("Found a requested session ID: " +
> requestedSessionID);
>   sess = sM.findSession(requestedSessionID);
>   if (sess != null)
>  System.out.println("Found a requested session ID");
>   request.setSession(sess);
>   }
> 
>   // The current cookie checking code comes here
>   ...
> 
> Hans
> 


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

Client certificates in Tomcat 3.2beta7

2000-11-14 Thread Barbara Nelson


I am testing Tomcat standalone with client authentication on, and getting
some odd results.  It works fine if client authentication is not turned on
(for both IE and Netscape browsers).  If I turn on client authentication,
Netscape claims that I do not have a personal certificate, and IE asks me to
choose from an empty list of certificates.  If I go via Apache/SSL, and
redirect to Tomcat, it works fine.  Netscape lets me choose the certificate,
IE shows the certificate in the list, and I can see the certificate in the
SnoopServlet output.

Any ideas on the problem with the certificate request when I use Tomcat
standalone?  Is there some configuration to indicate the type of certificate
the server is requesting?  I am using a self-signed certificate, generated
via keytool, on the server.  In the browser, I have a verisign personal
certificate.

Many thanks,
Barbara Nelson.



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

Re: Building nsapi_redirector

2000-11-14 Thread Barbara Nelson


I think the problem is that the project file has carriage-returns only at
the end of each line, rather than CRLF.  You can verify this by opening the
project file in notepad.  Instead of looking like 'normal' text, it is all
on one line.  If you delete the CRs, and insert your own CRLF in notepad,
then you should be able to build the project.

Could someone fix the project files before final release, so that they don't
require manual editing?

Thanks,
Barbara Nelson.



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

Re: Tomcat 4.0 -- JSP XML representation problems

2000-11-14 Thread Pierre Delisle


Boyd,

> I cannot really use the XML representation, because the  tag
> doesn't work with current Tomcat-4.0-devel. I get classCastExceptions if
> I try to use this tag.

But you could still use  for your CDATA.
 should be in tomcat-4.0 befroe the end of the week.

> ps: I can see that ultimately, we'll have a clean xml rep of jsp, using
> the xml namespaces etc. But at the moment it's a mess...

With the community contributing constructive feedback, tests, code, patches, comments, 
etc, 
it will definitely get there faster...

-- Pierre

Boyd Waters wrote:
> 
> Howdy...
> 
> Tomcat 4.0 attempts to conform to the JSP 1.2 spec.
> 
> JSP 1.2 specifies an XML representation for JSP pages. One is supposedly
> able to use the original syntax, or the new XML rep, but one CANNOT
> inter-mingle XML and the original syntax in the 1.2 spec.
> 
> People, this is *awful*. All of my stuff breaks.
> 
> For example:
> 
> This version of the table was created by treating the nested content
> as
> the XML document (simulating the case where the JSP page itself would be
> rendering XML output), but using an external XSL stylesheet.
> 
> 
> 
> 
>   
> John
> Doe
> 800-555-1212
>   
>   
> Jane
> Smith
> 888-555-1212
>   
>   
> George
> Taylor
> 555-555-1212
>   
> 
> 
> 
> 
> -
> 
> This code cannot be incorporated into an "original-style" JSP page
> because its got XML in it. You have to go to the fully blown-out XML
> representation.
> 
> I cannot really use the XML representation, because the  tag
> doesn't work with current Tomcat-4.0-devel. I get classCastExceptions if
> I try to use this tag.
> 
> It's actually worse than this, because my site uses XHTML -- the HTML
> pages are XML documents. I need Tomcat to emit XML, *INCLUDING* the
> DOCTYPE declaration.
> 
> So by way of winding down this rant, has anyone been able to use the XSL
> taglib with Tomcat 4.0? Or any XML at all?
> 
> -- boyd
> 
> ps: I can see that ultimately, we'll have a clean xml rep of jsp, using
> the xml namespaces etc. But at the moment it's a mess...
> 
> -
> Boyd Waters  [EMAIL PROTECTED]
> National Radio Astronomy Observatory  http://www.nrao.edu
> PO Box 0 Socorro, NM 87801   505.835.7346
> 
> http://www.zocalo.net/~waters
> [EMAIL PROTECTED]
> -
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

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

BugRat Report #385 has been filed.

Bug report #385 has just been filed.

You can view the report at the following URL:

REPORT #385 Details.

Project: Catalina
Category: Feature Requests
SubCategory: New Feature
Class: support
State: received
Priority: medium
Severity: serious
Confidence: public
Environment:
Release: M4
JVM Release: 1.3
Operating System: Windows NT
OS Release: 2000
Platform: Intel

Synopsis:
How to Specify Work and Log directories

Description:
How can one override the location of the log and work directories? I tried to
override the work dir and did not work. I could not find a way to overrid the log
directory. Can someone include a sample in the server.xml file as part of M5?

Title:
BugRat Report #
385

BugRat Report #
385

Project:
Catalina

Release:
M4

Category:
Feature Requests

SubCategory:
New Feature

Class:
support

State:
received

Priority:
medium

Severity:
serious

Confidence:
public

Submitter:
Mayank Shah ( [EMAIL PROTECTED] )

Date Submitted:
Nov 14 2000, 05:14:57 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )

Synopsis:

How to Specify Work and Log directories

Environment: (jvm, os, osrel, platform)

1.3, Windows NT, 2000, Intel

Additional Environment Description:

Report Description:

How can one override the location of the log and work directories? I tried to override the work dir and did not work. I could not find a way to overrid the log directory. Can someone include a sample in the server.xml file as part of M5?

View this report online...

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

Re: [PATCH] JspRuntimeLibrary boolean bug

2000-11-14 Thread Pierre Delisle


Gareth,

Thanks for the patch. I've committed it to 4.0, and will wait for feedback
from Craig to see if it can be committed to 3.2b7.

-- Pierre

Gareth Morgan wrote:
> 
> This file seems to use the wrong method of String->Boolean conversion,
> resuting in an always false result.
> - Could someone review and submit this, if oppropriate? I don't have access.
> 
> This diff is against jakarta-tomcat-3.2-b7
> 
> share\org\apache\jasper\runtime\JspRuntimeLibrary.java
> 
> 326c326
> <   tmpval[i] = Boolean.getBoolean (values[i]);
> ---
> >   tmpval[i] = ( Boolean.valueOf(values[i])
> ).booleanValue();
> 
> Gareth Morgan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

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

cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime JspRuntimeLibrary.java

2000-11-14 Thread pierred


pierred 00/11/14 14:06:22

  Modified:jasper/src/share/org/apache/jasper/runtime
JspRuntimeLibrary.java
  Log:
  Bug fix: conversion of String to boolean was erroneous
  Submitted by: Gareth Morgan <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.3   +4 -4  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java
  
  Index: JspRuntimeLibrary.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- JspRuntimeLibrary.java2000/09/26 00:47:56 1.2
  +++ JspRuntimeLibrary.java2000/11/14 22:06:22 1.3
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v
 1.2 2000/09/26 00:47:56 pierred Exp $
  - * $Revision: 1.2 $
  - * $Date: 2000/09/26 00:47:56 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v
 1.3 2000/11/14 22:06:22 pierred Exp $
  + * $Revision: 1.3 $
  + * $Date: 2000/11/14 22:06:22 $
*
* 
* 
  @@ -343,7 +343,7 @@
} else if (t.equals(boolean.class)) {
boolean[] tmpval = new boolean[values.length];
for (int i = 0 ; i < values.length; i++)
  - tmpval[i] = Boolean.getBoolean (values[i]);
  + tmpval[i] = (Boolean.valueOf(values[i])).booleanValue();
method.invoke (bean, new Object[] {tmpval});
} else if (t.equals(short.class)) {
short[] tmpval = new short[values.length];
  
  
  

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

[TC 3.2b7 PATCH] Sessions without cookies [Was: Re: BugRat Report #380 has been filed.]

BugRat Mail System wrote:
> 
> Bug report #380 has just been filed.
> [...]
> Environment:
>Release: 3.2 Beta 7
>JVM Release: 1.3
>Operating System: Linux/NT
>OS Release: 2.2.16/4
>Platform: any
> 
> Synopsis:
> Sessions don't work without cookies
> 
> Description:
> If Cookies are turned off in a browser the
>  session-management by url-rewriting does not work.
> This bug was introduced by 3.2 beta6 and is still around
>  in beta7

Adding this to StandardSessionInterceptor seems to fix the problem.
I would appreciate if someone who has worked with the session
tracking stuff before can review this patch before I commit it to
the tomcat_32 branch. I really don't want to introduce new bugs in
3.2 this close to the release, but I feel this bug must be fixed.

  // First check if we have a valid session ID from the URL, set 
  // by the SessionInterceptor, and if so, set it as the request 
  // session. If we have also received a valid session ID
  // as a cookie, the next section of code will reset the session 
  // to the one matching the ID found in the cookie.
  String requestedSessionID = request.getRequestedSessionId();
  if (requestedSessionID != null) {
  System.out.println("Found a requested session ID: " +
requestedSessionID);
  sess = sM.findSession(requestedSessionID);
  if (sess != null)
 System.out.println("Found a requested session ID");
  request.setSession(sess);
  }

  // The current cookie checking code comes here
  ...

Hans
-- 
Hans Bergsten   [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com

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

Ajpv13 protocol

2000-11-14 Thread Sam Wang

Title: Ajpv13 protocol





Is there a RFC on Ajp protocol? Or any documentation at all?


-Sam

Re: BugRat Report #380 has been filed.


[EMAIL PROTECTED] wrote:
> 
> > I started to look at this one, and noticed that there are two interceptors
> > that deal with sessions:
> > * SessionInterceptor, seems to deal with session IDs in the URL but
> >   doesn't care about cookies. This one is invoked first.
> > * StandardSessionInterceptor, seems to deal with session IDs received
> >   as cookies but doesn't care about session IDs in the URL.
> >
> > Before I start hacking here, can someone tell me why there are two
> > interceptors and what the intention with the two are?
> 
> The intention was to separate the module that extract the session id from
> a request from the module that provides the storage of session data.
> 
> StandardSessionInterceptor was the original module, resulted from
> refactoring of session-related code.
> 
> AFAIK ( or at least the intention was ) that StandardSessionInterceptor
> shouldn't deal in any way with finding the session id - it'll just store,
> find and create HttpSession and session attributes.
> 
> The SessionInterceptor is ( possibly one of the ) modules that extract the
> session ID - it should be possible to add a SSLSessionIdInterceptor that
> implements SSL-based sessions, etc.
> 
> The names are really bad - I know. StandardSessionInterceptor should be
> called "SimpleSessionStorageInterceptor" and the other one
> "StandardSessionIdInterceptor". I guess it's too late to change it.
> 
> For 3.3 we can spend more time improving the interceptors.

Okay, thanks for the info. I have found a fix to the problem that I'll
post for review to the list in a second. If no one objects before tonight
I'm going to commit it to the tomcat_32 branch.

Hans
-- 
Hans Bergsten   [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com

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

Re: [BUG] j_security_check forward no longer working

2000-11-14 Thread Craig R. McClanahan

Barry Dunne wrote:

> Hi,
>
> I need to trap the username and password entered by the user when accessing
> a secured web page, this is so that I can use this information when
> connecting to an external system in a servlet.
>
> The method I used was to have form based authentication but with the action
> posting to a jsp rather than j_security_check, the jsp then stores the
> username/password in the session and forwards the info on to
> j_security_check.
>
> This works perfectly with tomcat 3.2 beta 4, but tomcat 4 milestone 4 throws
> an exception and creates a blank file called j_security_check in the login
> directory.
>
> I am running on redhat linux 7 with sun jdk 1.3.
>
> The attached war file is the files I am using and the text file shows the
> different output when run in v3.2 and v4.
>
> Thanks,
> Barry.
>

Tomcat 4.0 should not throw an exception, but neither should it accept a form-based
login unless the action is "j_security_check".  See the Servlet 2.3 Spec (PFD),
Section 12.5.3.1, p. 78.

There's a similar section in the 2.2 spec that relates to Tomcat 3.2.  Therefore,
if Tomcat 3.2 is accepting your credentials when you post *to* a JSP page, as
opposed to j_security_check, it is broken.

The whole idea of form-based login is that, after you have successfully
authenticated, you are returned to the page you originally asked for.  The user
experience should feel very similar to what happens with BASIC authentication --
the server pauses and asks for your username and password, but then proceeds to
give you the page you asked for if you have successfully authenticated.  Therefore,
it doesn't really make any sense to talk about posting form based login criteria
*to* a JSP page.

On the other hand, it's perfectly reasonable to post *from* a JSP page -- that is
what the example application does.  It declares a JSP page as it's
.

Craig McClanahan

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

[BUG] j_security_check forward no longer working

2000-11-14 Thread Barry Dunne


Hi,

I need to trap the username and password entered by the user when accessing 
a secured web page, this is so that I can use this information when 
connecting to an external system in a servlet.

The method I used was to have form based authentication but with the action 
posting to a jsp rather than j_security_check, the jsp then stores the 
username/password in the session and forwards the info on to 
j_security_check.

This works perfectly with tomcat 3.2 beta 4, but tomcat 4 milestone 4 throws 
an exception and creates a blank file called j_security_check in the login 
directory.

I am running on redhat linux 7 with sun jdk 1.3.

The attached war file is the files I am using and the text file shows the 
different output when run in v3.2 and v4.

Thanks,
Barry.
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

 securitytest.war

Output with tomcat 3.2 beta 4:

User: tomcat
Password: tomcat



Output with tomcat 4 milestone 4:

A Servlet Exception Has Occurred
Exception Report:
javax.servlet.ServletException: Servlet.service() for servlet default threw 
exception
at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:537)
at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:292)
at 
org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:431)
at 
login._0002flogin_0002fsecurity_0005fcheck_0002ejspsecurity_0005fcheck_jsp_32._jspService(_0002flogin_0002fsecurity_0005fcheck_0002ejspsecurity_0005fcheck_jsp_32.java:102)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:181)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:317)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:396)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:180)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:255)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:165)
at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:443)
at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
at 
org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:242)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975)
at 
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:1876)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:343)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:159)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at 
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:785)
at 
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:902)
at java.lang.Thread.run(Thread.java:484)

Root Cause:
java.lang.NullPointerException
at 
org.apache.catalina.resources.FileResources.setResource(FileResources.java:586)
at 
org.apache.catalina.servlets.DefaultServlet.doPut(DefaultServlet.java:401)
at 
org.apache.catalina.servlets.DefaultServlet.doPost(DefaultServlet.java:365)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:517)
at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:292)
at 
org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:431)
at 
login._0002flogin_0002fsecurity_0005fcheck_0002ejspsecurity_0005fcheck_jsp_32._jspService(_0002flogin_0002fsecurity_0005fcheck_0002ejspsecurity_0005fcheck_jsp_32.java:102)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 
org.apache.jasper.servlet.JspServlet$JspServletWr

[PATCH] JspRuntimeLibrary boolean bug

2000-11-14 Thread Gareth Morgan


This file seems to use the wrong method of String->Boolean conversion,
resuting in an always false result.
- Could someone review and submit this, if oppropriate? I don't have access.

This diff is against jakarta-tomcat-3.2-b7

share\org\apache\jasper\runtime\JspRuntimeLibrary.java

326c326
<   tmpval[i] = Boolean.getBoolean (values[i]);
---
>   tmpval[i] = ( Boolean.valueOf(values[i])
).booleanValue();   


Gareth Morgan

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

Bug-Report

2000-11-14 Thread Granzer Andreas ARC


I'am using Tomcat 3.2  beta 7 

I am getting a "not found"-Response when posting a quite
large file to a servlet (file upload with a filve about 30 Meg)

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

Tomcat 4.0 -- JSP XML representation problems

2000-11-14 Thread Boyd Waters


Howdy...

Tomcat 4.0 attempts to conform to the JSP 1.2 spec.

JSP 1.2 specifies an XML representation for JSP pages. One is supposedly
able to use the original syntax, or the new XML rep, but one CANNOT
inter-mingle XML and the original syntax in the 1.2 spec.

People, this is *awful*. All of my stuff breaks.

For example:

This version of the table was created by treating the nested content
as
the XML document (simulating the case where the JSP page itself would be
rendering XML output), but using an external XSL stylesheet.




  
John
Doe
800-555-1212
  
  
Jane
Smith
888-555-1212
  
  
George
Taylor
555-555-1212
  




-

This code cannot be incorporated into an "original-style" JSP page
because its got XML in it. You have to go to the fully blown-out XML
representation.

I cannot really use the XML representation, because the  tag
doesn't work with current Tomcat-4.0-devel. I get classCastExceptions if
I try to use this tag.

It's actually worse than this, because my site uses XHTML -- the HTML
pages are XML documents. I need Tomcat to emit XML, *INCLUDING* the
DOCTYPE declaration.


So by way of winding down this rant, has anyone been able to use the XSL
taglib with Tomcat 4.0? Or any XML at all?

-- boyd

ps: I can see that ultimately, we'll have a clean xml rep of jsp, using
the xml namespaces etc. But at the moment it's a mess...

-
Boyd Waters  [EMAIL PROTECTED]
National Radio Astronomy Observatory  http://www.nrao.edu
PO Box 0 Socorro, NM 87801   505.835.7346

http://www.zocalo.net/~waters
[EMAIL PROTECTED]
-

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

Re: Make rant

2000-11-14 Thread Matthew Dornquast


Hi Roy!

>> If someone can provide a link to something like "Make for Dummies" I'd
appreciate it.

You betcha, and fyi-- this format is VERY similar to the make file Nick
Bauman, myself and others use at our place of employment.  (Some might say
better!?)

At the very least, it's well documented.

http://geosoft.no/javamake.html

enjoy.

-Matthew

PS>I've been resisting the temptation to get involved on the ant rant
thread, but this link might suggest I'm a Make fan.

PPS> I'm not.



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

Re: TC4-M4: Bug while loading jars?

2000-11-14 Thread Craig R. McClanahan

James Cook wrote:

> Is it considered a bug that any jars loaded by Tomcat 4 (whether from
> WEB-INF/lib, or /lib) must have a manifest file? I'm not sure why
> this restriction is in place.
>

Tomcat 4.0 is supposed to check manifest files for external dependencies if they
do exist, but it's not supposed to require them.  I will look into that.

>
> jim
>

Craig

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

Re: *.apache.org traffic, configuration, etc

2000-11-14 Thread Jon Stevens


on 11/11/2000 5:10 PM, "Roy Wilson" <[EMAIL PROTECTED]> wrote:

> You mentioned that you thought *.apache.org gets 2M hits per day. Is
> there a (good?) source of info re: hardware/software/traffic information?

Essentially, i think it is a piii 500mhz box, lots of disk space, i think
around 500megs of ram and it is running FreeBSD.

FreeBSD locus.apache.org 4.1-STABLE FreeBSD 4.1-STABLE #1: Fri Aug 25
02:56:11 PDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/locus
i386

primary software is apache and qmail/ezmlm

-jon

-- 
http://scarab.tigris.org/| http://noodle.tigris.org/
http://java.apache.org/  | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/   | http://www.sourcexchange.com/



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

Re: BugRat Report #380 has been filed.


> As close as I can tell, SessionInterceptor needs to be called first to
> parse the url sessionid out of the URL before it can be context mapped. 
> StandardSessionInterceptor lets you work with the sessions once you know
> which context the request is going to.  I've done some work in there,
> but I won't claim to know the original motivation for seperating them
> other than what is listed above.

The motivation was simple: there are many ways to encode the ID in a
request ( cookies, rewriting, SSL - plus special cases if the real server
decodes the session, like in load-balancing cases ).

There are many ways to store the sessions ( the simple hashtables we use
in StandardSI, database, session migration, etc ).

I thought it's better to separate the 2 problems and use 2 different
modules.

The storage module doesn't try to extract the session ID using
cookies/rewriting/etc - that means someone can add a new sessionId
decoding module without changing the storage module, and someone can write
a new storage module without worry about session id encoding.

Costin


> 
> It might be possible to check the URL based session IDs in the same
> place as we check multiple cookies to find a valid one.
> 
> Paul
> 
> Hans Bergsten wrote:
> > 
> > BugRat Mail System wrote:
> > >
> > > Bug report #380 has just been filed.
> > > [...]
> > > Environment:
> > >Release: 3.2 Beta 7
> > >JVM Release: 1.3
> > >Operating System: Linux/NT
> > >OS Release: 2.2.16/4
> > >Platform: any
> > >
> > > Synopsis:
> > > Sessions don't work without cookies
> > >
> > > Description:
> > > If Cookies are turned off in a browser the
> > >  session-management by url-rewriting does not work.
> > > This bug was introduced by 3.2 beta6 and is still around
> > >  in beta7
> > 
> > This is serious enough to warrant a fix before 3.2 goes final, IMHO.
> > It used to work in 3.1 and the earlier 3.2 betas so it's a regression
> > bug.
> > 
> > I started to look at this one, and noticed that there are two interceptors
> > that deal with sessions:
> > * SessionInterceptor, seems to deal with session IDs in the URL but
> >   doesn't care about cookies. This one is invoked first.
> > * StandardSessionInterceptor, seems to deal with session IDs received
> >   as cookies but doesn't care about session IDs in the URL.
> > 
> > Before I start hacking here, can someone tell me why there are two
> > interceptors and what the intention with the two are?
> > 
> > Hans
> > --
> > Hans Bergsten   [EMAIL PROTECTED]
> > Gefion Software http://www.gefionsoftware.com
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


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

Re: BugRat Report #380 has been filed.


> I started to look at this one, and noticed that there are two interceptors
> that deal with sessions:
> * SessionInterceptor, seems to deal with session IDs in the URL but
>   doesn't care about cookies. This one is invoked first.
> * StandardSessionInterceptor, seems to deal with session IDs received
>   as cookies but doesn't care about session IDs in the URL.
> 
> Before I start hacking here, can someone tell me why there are two
> interceptors and what the intention with the two are?

The intention was to separate the module that extract the session id from
a request from the module that provides the storage of session data.

StandardSessionInterceptor was the original module, resulted from
refactoring of session-related code.

AFAIK ( or at least the intention was ) that StandardSessionInterceptor
shouldn't deal in any way with finding the session id - it'll just store,
find and create HttpSession and session attributes.

The SessionInterceptor is ( possibly one of the ) modules that extract the
session ID - it should be possible to add a SSLSessionIdInterceptor that
implements SSL-based sessions, etc. 

The names are really bad - I know. StandardSessionInterceptor should be
called "SimpleSessionStorageInterceptor" and the other one
"StandardSessionIdInterceptor". I guess it's too late to change it.

For 3.3 we can spend more time improving the interceptors.

Costin

  


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

Re: Patch for bug report #362 (and a patch for a logging error)

2000-11-14 Thread Pierre Delisle


Serge,

> > The way I got this to work was to overload the setter method to take both a
> > String and an Object... this got it working through Jasper Servlet but not
> > jspc.  I don't know if that's a violation of the spec or the way to handle
> > this issue.

Tried to make this work under 3.2b7, and it always does return the
proper exception. Please send a sample test case so I can debug.

-- Pierre


When I try yo

"Craig R. McClanahan" wrote:
> 
> Serge Knystautas wrote:
> 
> > [snip]
> > The way I got this to work was to overload the setter method to take both a
> > String and an Object... this got it working through Jasper Servlet but not
> > jspc.  I don't know if that's a violation of the spec or the way to handle
> > this issue.
> 
> Yep, it is, and again this is made explicit in JSP 1.2 :-(.
> 
> I was trying something similar (overloaded setters) originally with Struts, and
> it went down in flames on most servlet containers because many of them just use
> the standard JavaBeans introspector -- and the introspector returns a property
> setter only if there is a single method.  On one of the other containers, you'd
> start getting compiler errors like "this is a read-only property" because the
> introspector returned neither setter.
> 
> >  Anyway, seems that if spec compliance is an issue, we should
> > have Tomcat 3.2 be uniform in both jspc and the Jasper Servlet.
> 
> That is *definitely* true.  Unfortunately, I'm not the person most versed with
> the JSP compiler.  Pierre Delisle is, and he will also be back on Monday.
> 
> >  I looked
> > through the code some and didn't understand why it would compile from the
> > Jasper Servlet but not jspc (before my patch), but that's what's happening
> > for me with Tomcat 3.2b6.
> >
> 
> I will look at this as well, and see if anything obvious stands out.
> 
> >
> > Serge Knystautas
> > Loki Technologies
> > http://www.lokitech.com/
> >
> 
> Craig
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

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

Re: BugRat Report #380 has been filed.

2000-11-14 Thread Paul Frieden


As close as I can tell, SessionInterceptor needs to be called first to
parse the url sessionid out of the URL before it can be context mapped. 
StandardSessionInterceptor lets you work with the sessions once you know
which context the request is going to.  I've done some work in there,
but I won't claim to know the original motivation for seperating them
other than what is listed above.

It might be possible to check the URL based session IDs in the same
place as we check multiple cookies to find a valid one.

Paul

Hans Bergsten wrote:
> 
> BugRat Mail System wrote:
> >
> > Bug report #380 has just been filed.
> > [...]
> > Environment:
> >Release: 3.2 Beta 7
> >JVM Release: 1.3
> >Operating System: Linux/NT
> >OS Release: 2.2.16/4
> >Platform: any
> >
> > Synopsis:
> > Sessions don't work without cookies
> >
> > Description:
> > If Cookies are turned off in a browser the
> >  session-management by url-rewriting does not work.
> > This bug was introduced by 3.2 beta6 and is still around
> >  in beta7
> 
> This is serious enough to warrant a fix before 3.2 goes final, IMHO.
> It used to work in 3.1 and the earlier 3.2 betas so it's a regression
> bug.
> 
> I started to look at this one, and noticed that there are two interceptors
> that deal with sessions:
> * SessionInterceptor, seems to deal with session IDs in the URL but
>   doesn't care about cookies. This one is invoked first.
> * StandardSessionInterceptor, seems to deal with session IDs received
>   as cookies but doesn't care about session IDs in the URL.
> 
> Before I start hacking here, can someone tell me why there are two
> interceptors and what the intention with the two are?
> 
> Hans
> --
> Hans Bergsten   [EMAIL PROTECTED]
> Gefion Software http://www.gefionsoftware.com
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

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

Re: BugRat Report #380 has been filed.

BugRat Mail System wrote:
> 
> Bug report #380 has just been filed.
> [...]
> Environment:
>Release: 3.2 Beta 7
>JVM Release: 1.3
>Operating System: Linux/NT
>OS Release: 2.2.16/4
>Platform: any
> 
> Synopsis:
> Sessions don't work without cookies
> 
> Description:
> If Cookies are turned off in a browser the
>  session-management by url-rewriting does not work.
> This bug was introduced by 3.2 beta6 and is still around
>  in beta7

This is serious enough to warrant a fix before 3.2 goes final, IMHO.
It used to work in 3.1 and the earlier 3.2 betas so it's a regression
bug.

I started to look at this one, and noticed that there are two interceptors
that deal with sessions:
* SessionInterceptor, seems to deal with session IDs in the URL but
  doesn't care about cookies. This one is invoked first.
* StandardSessionInterceptor, seems to deal with session IDs received
  as cookies but doesn't care about session IDs in the URL.

Before I start hacking here, can someone tell me why there are two
interceptors and what the intention with the two are?

Hans
-- 
Hans Bergsten   [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com

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

BugRat Report #382 has been filed.

Bug report #382 has just been filed.

You can view the report at the following URL:

REPORT #382 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment:
Release: 3.1
JVM Release: 1.2.2
Operating System: AIX
OS Release: 4.3.3
Platform: RS/6000 (M80)

Synopsis:
Tomcat stops after socket exception

Description:
In my current project I have a servlets which redirects requests to Tomcat/Jasper for
chaching purposes. If a page hasn't changed, the page will be delivered directly from
the servlet's cache instead of the JSP page. While working with Tomcat/Jasper on AIX I
encountered the following problem:
If I view a page with IE 5.0, press CTRL+F5 (reload all) and hold down these keys, IE
obviously send out many requests which in turn causes the JVM to throw a
SocketException in
serverSocket.accept(). Tomcat catches this exception and sets running to false which
kills Tomcat. If you comment out the line which stops Tomcat, everything is fine.

hope this helps
matthias

Title:
BugRat Report #
382

BugRat Report #
382

Project:
Tomcat

Release:
3.1

Category:
Bug Report

SubCategory:
New Bug Report

Class:
swbug

State:
received

Priority:
high

Severity:
critical

Confidence:
public

Submitter:
Matthias Schoger ( [EMAIL PROTECTED] )

Date Submitted:
Nov 14 2000, 11:33:59 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )

Synopsis:

Tomcat stops after socket exception

Environment: (jvm, os, osrel, platform)

1.2.2, AIX, 4.3.3, RS/6000 (M80)

Additional Environment Description:

Report Description:

In my current project I have a servlets which redirects requests to Tomcat/Jasper for chaching purposes. If a page hasn't changed, the page will be delivered directly from the servlet's cache instead of the JSP page. While working with Tomcat/Jasper on AIX I encountered the following problem:
If I view a page with IE 5.0, press CTRL+F5 (reload all) and hold down these keys, IE obviously send out many requests which in turn causes the JVM to throw a SocketException in
serverSocket.accept(). Tomcat catches this exception and sets running to false which kills Tomcat. If you comment out the line which stops Tomcat, everything is fine.

hope this helps
matthias

Workaround:

null

View this report online...

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

RE: tomcat 4.0 m4: bug while submitting UTF-8 data to JSP page

2000-11-14 Thread Christian Mallwitz


Hi,

BTW I've checked this with both JDK 1.2.2 and 1.3.0 on W2K.

Bye
Christian
-- 
Christian Mallwitz INTERSHOP Communications Germany
Senior Software Engineerphone: +49 3641 894 334


> -Original Message-
> From: Christian Mallwitz [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 13, 2000 18:23
> To: [EMAIL PROTECTED]
> Subject: tomcat 4.0 m4: bug while submitting UTF-8 data to JSP page
> 
> 
> Hi,
> 
> I have a JSP file (see attachment) which lets you submit text 
> in UTF-8 to
> the same JSP file. For this to work the JSP file contains code for
> converting the submitted text from Unicode to UTF-8. 
> 
> I run some test to submit the Euro symbol. In Unicode this is 
> code point
> 0x20ac and in UTF-8 it is 0xE2 0x82 0xAC (3 bytes). It works 
> for all servlet
> engines I know of incl. Tomcat up to 3.2 beta 6 but not for 
> Tomcat 4.0m4
> 
> if you have an URL like http://host/post.jsp?text=%E2%82%AC I 
> expect the
> following output:
> 
> text [as text]   = â'¬
> text [as hex]= 0xe2 0x82 0xac 
> text [corrected] = EUR
> 
> but I get
> 
> text [as text]   = â'¬
> text [as hex]= 0xe2 0x201a 0xac 
> text [corrected] = 
> 
> Note the second hex code. Interestingly 0x201a is a Unicode code point
> containing a , character but I'm clueless how Tomcat got there ...
> 
> Bye
> Christian
> PS: I have attached a JSP file for more multibyte samples ...
> -- 
> Christian Mallwitz INTERSHOP Communications Germany
> Senior Software Engineerphone: +49 3641 894 334

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

BugRat Report #381 has been filed.

Bug report #381 has just been filed.

You can view the report at the following URL:

REPORT #381 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: medium
Severity: serious
Confidence: public
Environment:
Release: tomcat 4m4
JVM Release: sun jdk1.3
Operating System: linus
OS Release: redhat 7
Platform: i386

Synopsis:
can no longer forward to j_security_check

Description:
In tomcat 3.2 beta 4 (don't know about others) you could create a form based login
which posted to a jsp instead of j_security_check.

This allowed the jsp to store the username and password in the session and then
forward the info on to j_security_check.

This is required in order to use the username/password to connect to an external
system from within a servlet.

With Tomcat 4 milestone 4 this same method causes an exception when the jsp:forward
occurs. It also creates an empty file in the login directory.

Title:
BugRat Report #
381

BugRat Report #
381

Project:
Tomcat

Release:
tomcat 4m4

Category:
Bug Report

SubCategory:
New Bug Report

Class:
swbug

State:
received

Priority:
medium

Severity:
serious

Confidence:
public

Submitter:
Barry Dunne ( [EMAIL PROTECTED] )

Date Submitted:
Nov 14 2000, 09:28:31 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )

Synopsis:

can no longer forward to j_security_check

Environment: (jvm, os, osrel, platform)

sun jdk1.3, linus, redhat 7, i386

Additional Environment Description:

Report Description:

In tomcat 3.2 beta 4 (don't know about others) you could create a form based login which posted to a jsp instead of j_security_check.

This allowed the jsp to store the username and password in the session and then forward the info on to j_security_check.

This is required in order to use the username/password to connect to an external system from within a servlet.

With Tomcat 4 milestone 4 this same method causes an exception when the jsp:forward occurs. It also creates an empty file in the login directory.

How To Reproduce:

null

Workaround:

null

View this report online...

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

cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_nwmain.c

2000-11-14 Thread larryi


larryi  00/11/14 06:20:13

  Added:   src/native/mod_jk/common jk_nwmain.c
  Log:
  Porting file from tomcat_32.
  
  Submitted by: Mike Anderson
  
  Revision  ChangesPath
  1.1  jakarta-tomcat/src/native/mod_jk/common/jk_nwmain.c
  
  Index: jk_nwmain.c
  ===
  #ifdef NETWARE
  /*
   * NATIVE_MAIN
   */
  
  /*
   * INCLUDES
   */
  
  #include 
  #include 
  #include 
  
  NETDB_DEFINE_CONTEXT
  
  /*
   * main ()
   *
   * Main entry point -- don't do much more than I've provided
   *
   * Entry:
   *
   * Exit:
   *Nothing
   */
  
  void main ()
  {
 ExitThread (TSR_THREAD, 0);
  }
  #endif
  
  
  

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

ftp task in ant

2000-11-14 Thread Damian Gołda


I'm trying to use ftp task in my build.xml (Ant 1.2 release).

But I have problems with it.
First, I've got:

Could not create task of type: ftp because I can't find it in the list of
task class definitions.  Common solutions are: 1 execute bin/bootstrap. 2
use taskdef to declare your task. 3 add the task to defaults.properties

So I've added following line to my build.xml:



And i've got another error:

java.lang.NoClassDefFoundError: com/oroinc/net/ftp/FTPClient
at org.apache.tools.ant.taskdefs.optional.FTP.execute(FTP.java)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:122)
at org.apache.tools.ant.Target.execute(Target.java, Compiled Code)
at org.apache.tools.ant.Project.runTarget(Project.java:818)
at org.apache.tools.ant.Project.executeTarget(Project.java, Compiled
Code)
at org.apache.tools.ant.Project.executeTargets(Project.java,
Compiled Code)
at org.apache.tools.ant.Main.runBuild(Main.java, Compiled Code)
at org.apache.tools.ant.Main.main(Main.java:149)

There is not com.oroinc.* package in jars in ant's lib dir.

The question is:
What am I doing wrong? From where can I get com/oroinc/net/ftp/FTPClient
class?

Any help would be appreciated.
---
Damian Golda

[EMAIL PROTECTED]


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

BugRat Report #380 has been filed.