DO NOT REPLY [Bug 4096] - Ajp13 connector does not handle sticky sessions

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Ajp13 connector does not handle sticky sessions

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2002-02-16 07:05 ---
This has been addressed in Tomcat 4.0.2 b2 or later.

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

DO NOT REPLY [Bug 4096] - Ajp13 connector does not handle sticky sessions

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Ajp13 connector does not handle sticky sessions

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|LATER   |



--- Additional Comments From [EMAIL PROTECTED]  2002-02-16 07:04 ---
Reopen.

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

DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Automatic deployment of war files does not work properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Critical|Enhancement
   Priority|Other   |Medium
Version|4.0.1 Final |4.0.2 Final



--- Additional Comments From [EMAIL PROTECTED]  2002-02-16 07:04 ---
As I stated quite a few times, this "bug" will not be fixed.
If you are not satisfied with the current behavior, the best way to fix it is to
submit a patch, and we'll consider it for inclusion.

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

DO NOT REPLY [Bug 6497] - webapp/support/install.sh: bad interpreter: Permission denied

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

webapp/support/install.sh: bad interpreter: Permission denied

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-02-16 07:00 ---
That has been fixed a few hours ago in the script used to generate the tgz.
All the .sh in the package now have 755.

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

DO NOT REPLY [Bug 6499] New: - problem uploading files using com.oreilly.servlet.MultpartRequest

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

problem uploading files using com.oreilly.servlet.MultpartRequest

   Summary: problem uploading files using
com.oreilly.servlet.MultpartRequest
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Major
  Priority: Other
 Component: Webapp Connector
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


There seems to be an intermittent problem with uploading files when using the 
warp connector.  I wrote a simple servlet using Jason Hunter's 
com.oreilly.servlet.MultipartRequest to allow file uploads using https.  My 
tests were with a small jar file and it seemed to work fine.  Then when I 
started testing with larger files, an excel spreadsheet and a pdf file, the 
servlet began to throw an IOException - unexpected end of part.  I tried 
running the servlet standalone and the files uploads fine.  This is why I 
suspect that the problem is with the warp connector.

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

DO NOT REPLY [Bug 6498] New: - URL Redirection is broken

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

URL Redirection is broken

   Summary: URL Redirection is broken
   Product: Tomcat 4
   Version: 4.0.2 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Webapp Connector
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Szenario:

1) Apache in an intranet used as virtual host e.g. apaci.intra.netz:80
2) as you can guess apaci.intra.netz is known in the intranet (has its 
   own DNS), only
3) tests from internet is allowed via an ssh gateway only, so
   ssh -f -x -L 8080:apaci:80 ssh.gate.way

Now, accessing http://localhost:8080/webapp-info or /examples/index.html
seems to work perfect, but accessing http://localhost:8080/examples/servlets/
does not, since the  HTTP_HOST is rewritten to SERVER_NAME which is IMHO wrong.

E.g.: A request to http://localhost:8080/examples/servlets/ returns

HTTP/1.1 302 Found
Date: Sat, 16 Feb 2002 03:55:26 GMT
Server: Apache/1.3.20 (Unix)
Content-Type: text/html
Location: http://apaci.intra.netz/examples/servlets/index.html
Transfer-Encoding: chunked


but should return:

HTTP/1.1 302 Found
Date: Sat, 16 Feb 2002 03:55:26 GMT
Server: Apache/1.3.20 (Unix)
Content-Type: text/html
Location: http://localhost:8080/examples/servlets/index.html
Transfer-Encoding: chunked

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

DO NOT REPLY [Bug 6497] New: - webapp/support/install.sh: bad interpreter: Permission denied

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

webapp/support/install.sh: bad interpreter: Permission denied

   Summary: webapp/support/install.sh: bad interpreter: Permission
denied
   Product: Tomcat 4
   Version: 4.0.2 Final
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Webapp Connector
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


1) tar xzf jakarta-tomcat-connectors-4.0.2-01-src.tar.gz; cd webapp
2) sh support/buildconf.sh
3) configure
4) make
 is broken because support/install.sh has 0644 permission, only
:
...
/export/scratch/tmp/jakarta-tomcat-connectors-4.0.2-01-src/webapp/apr/libtool:
/export/scratch/tmp/jakarta-tomcat-connectors-4.0.2-01-src/webapp/support/install.sh:
bad interpreter: Permission denied
make[2]: ***
[/export/scratch/tmp/jakarta-tomcat-connectors-4.0.2-01-src/webapp/lib/libwebapp.a]
Error 126
make[2]: Leaving directory
`/export/scratch/tmp/jakarta-tomcat-connectors-4.0.2-01-src/webapp/lib'
make[1]: Exiting directory "lib"
make[1]: *** [template] Error 2
...

So including it with permission 0755 in the archive or appliying the following
patch would be nice:


--- webapp/support/buildconf.sh.origWed Feb 13 18:53:58 2002
+++ webapp/support/buildconf.sh Sat Feb 16 05:49:41 2002
@@ -83,6 +83,14 @@
 echo "Then remember to run ./configure script including the command line"
 echo "option \"--with-apr=[path to APR sources]\""
 fi
+
+EXECS="support/install.sh support/mkinstalldirs.sh"
+for f in $EXECS; do
+   if [ ! -x $f ]; then
+   chmod a+x $f
+   fi
+done
+
 echo "--- Creating WebApp \"configure\" script"
 echo "Creating configure ..."
 autoconf

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

DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Automatic deployment of war files does not work properly





--- Additional Comments From [EMAIL PROTECTED]  2002-02-16 03:21 ---
[Note that this is still the behaviour in 4.0.2].

I must concur with the reporter.  The documentation at tomcat-
docs/config/host.html leads one to believe that the auto-deployment of the 
application is orthogonal to the automatic creation of the  if it is 
not supplied. 

A work-around we have experimented with is to choose a path that is different 
from the docBase (given that documents.war is in the webapps directory):

At first this seems to work but there are two problems
1. This actually deploys as two applications, each using the same docBase.  
Once at /docs and the other at /documents.
2. There is a race condition.  If the “/doc” context is started before the 
documents.war is deployed it will not be found until tomcat is restarted.

It does not seem unreasonable to want to have a war file auto deploy and 
specify a  in the server.xml file.  I may have an application for 
which I wish to create files in the applications docBase and want to add 
parameters to the  (e.g. .

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

DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Automatic deployment of war files does not work properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]

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

[FAQ] jGuru FAQ Update

[Alex Chaffee]

jGuru maintains FAQs and Forums on Servlets, JSP, and Tomcat (as well as
many other Java topics).  Here is an automated update on recent postings to
Tomcat-related FAQs.  Please direct flames and feedback to [EMAIL PROTECTED] .

 - Alex


++ Servlets FAQ: http://www.jguru.com/faq/Servlets

How can a servlet refresh automatically if some new data has entered the database?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=759758

How can I send user authentication information while making URLConnection?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=759689

Can I have some simple code for my own connection pooling class?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=759672

Using WebLogic 6.1, why can't I load a servlet from a JAR file in my /WEB-INF/lib 
directory?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=759427

What's the initial user name and password for Jakarta Tomcat 4's admin tool?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=757542

Why can't I upload image files using com.oreilly.servlet.multipart.FilePart?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=757536

++ Tomcat FAQ: http://www.jguru.com/faq/Tomcat

What's the initial user name and password for Jakarta Tomcat 4's admin tool?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=757542

Why can't I upload image files using com.oreilly.servlet.multipart.FilePart?
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=757536

Tomcat 4.0.x "Class org.apache.jsp.{Class} not found.
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=753900

Fatal error: The encoding "Cp1252" is not supported.
http://www.jguru.com/misc/faqtrampoline.jsp?src=notify&EID=753194


You can shut email notification off at the FAQ home
page(s) or:

  http://www.jguru.com/guru/notifyprefs.jsp



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

DO NOT REPLY [Bug 6480] - HttpServletRequest.getPathTranslated() returns different results on repeated actions

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

HttpServletRequest.getPathTranslated() returns different results on repeated actions

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-02-16 01:13 ---
For HEAD branch, fixed in nightly build 20020216.

For 4.0.x branch, will be fixed in 4.0.3.


NOTE 1:  It is the *second* value that is correct, not the first, because the 
value is interpreted as relative to the current context.  It's the same value 
you will receive if you use a  to access the servlet, and call 
getPathInfo() and getPathTranslated() from within it.

NOTE 2:  Using file I/O to access static resources within a web application is 
not portable to environments where a web application is run directly from a WAR 
file (in this case, there is no file path at all).  You should consider using 
ServletContext.getResource() or ServletContext.getResourceAsStream() instead.

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

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

[craigmcc]

craigmcc02/02/15 17:09:51

  Modified:catalina/src/share/org/apache/catalina/servlets Tag:
tomcat_40_branch InvokerHttpRequest.java
InvokerServlet.java
  Log:
  Port fix for 6480.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.3.2.1   +34 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerHttpRequest.java
  
  Index: InvokerHttpRequest.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerHttpRequest.java,v
  retrieving revision 1.3
  retrieving revision 1.3.2.1
  diff -u -r1.3 -r1.3.2.1
  --- InvokerHttpRequest.java   22 Jul 2001 20:25:11 -  1.3
  +++ InvokerHttpRequest.java   16 Feb 2002 01:09:51 -  1.3.2.1
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerHttpRequest.java,v
 1.3 2001/07/22 20:25:11 pier Exp $
  - * $Revision: 1.3 $
  - * $Date: 2001/07/22 20:25:11 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerHttpRequest.java,v
 1.3.2.1 2002/02/16 01:09:51 craigmcc Exp $
  + * $Revision: 1.3.2.1 $
  + * $Date: 2002/02/16 01:09:51 $
*
* 
*
  @@ -88,7 +88,7 @@
* to the servlet, because a new servlet mapping will have been created.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.3 $ $Date: 2001/07/22 20:25:11 $
  + * @version $Revision: 1.3.2.1 $ $Date: 2002/02/16 01:09:51 $
*/
   
   class InvokerHttpRequest extends HttpServletRequestWrapper {
  @@ -106,6 +106,7 @@
   
   super(request);
   this.pathInfo = request.getPathInfo();
  +this.pathTranslated = request.getPathTranslated();
   this.requestURI = request.getRequestURI();
   this.servletPath = request.getServletPath();
   
  @@ -129,6 +130,12 @@
   
   
   /**
  + * The translated path information for this request.
  + */
  +protected String pathTranslated = null;
  +
  +
  +/**
* The request URI for this request.
*/
   protected String requestURI = null;
  @@ -161,6 +168,17 @@
   
   
   /**
  + * Override the getPathTranslated() method of the
  + * wrapped request.
  + */
  +public String getPathTranslated() {
  +
  +return (this.pathTranslated);
  +
  +}
  +
  +
  +/**
* Override the getRequestURI() method of the wrapped request.
*/
   public String getRequestURI() {
  @@ -203,6 +221,18 @@
   void setPathInfo(String pathInfo) {
   
   this.pathInfo = pathInfo;
  +
  +}
  +
  +
  +/**
  + * Set the translated path info for this request.
  + *
  + * @param pathTranslated The new translated path info
  + */
  +void setPathTranslated(String pathTranslated) {
  +
  +this.pathTranslated = pathTranslated;
   
   }
   
  
  
  
  1.13.2.2  +10 -6 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java
  
  Index: InvokerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java,v
  retrieving revision 1.13.2.1
  retrieving revision 1.13.2.2
  diff -u -r1.13.2.1 -r1.13.2.2
  --- InvokerServlet.java   22 Sep 2001 04:15:13 -  1.13.2.1
  +++ InvokerServlet.java   16 Feb 2002 01:09:51 -  1.13.2.2
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java,v
 1.13.2.1 2001/09/22 04:15:13 remm Exp $
  - * $Revision: 1.13.2.1 $
  - * $Date: 2001/09/22 04:15:13 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java,v
 1.13.2.2 2002/02/16 01:09:51 craigmcc Exp $
  + * $Revision: 1.13.2.2 $
  + * $Date: 2002/02/16 01:09:51 $
*
* 
*
  @@ -87,7 +87,7 @@
* in the web application deployment descriptor.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.13.2.1 $ $Date: 2001/09/22 04:15:13 $
  + * @version $Revision: 1.13.2.2 $ $Date: 2002/02/16 01:09:51 $
*/
   
   public final class InvokerServlet
  @@ -383,10 +383,14 @@
   sb.append("/");
   sb.append(servletClass);
   wrequest.setServletPath(sb.toString());
  -if ((pathInfo == null) || (pathInfo.length() < 1))
  +if ((pathInfo == null) || (pathInfo.length() < 1)) {
   wrequest.setPathInfo(null);
  -else
  +wrequest.setPathTranslated(null);
  +} else {
   wrequest.setPathInfo(pathInfo);
  +w

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

[craigmcc]

craigmcc02/02/15 17:07:11

  Modified:catalina/src/share/org/apache/catalina/servlets
InvokerHttpRequest.java InvokerServlet.java
  Log:
  Wrap the getPathTranslated() method of the wrapped request used the first
  time a particular servlet is invoked, so that it returns the correct value
  on the first call.  It already returned the correct value on all subsequent
  calls, which bypass the invoker.
  
  PR: Bugzilla #6480
  Submitted by: Amar Mattey <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.4   +34 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerHttpRequest.java
  
  Index: InvokerHttpRequest.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerHttpRequest.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- InvokerHttpRequest.java   22 Jul 2001 20:25:11 -  1.3
  +++ InvokerHttpRequest.java   16 Feb 2002 01:07:11 -  1.4
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerHttpRequest.java,v
 1.3 2001/07/22 20:25:11 pier Exp $
  - * $Revision: 1.3 $
  - * $Date: 2001/07/22 20:25:11 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerHttpRequest.java,v
 1.4 2002/02/16 01:07:11 craigmcc Exp $
  + * $Revision: 1.4 $
  + * $Date: 2002/02/16 01:07:11 $
*
* 
*
  @@ -88,7 +88,7 @@
* to the servlet, because a new servlet mapping will have been created.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.3 $ $Date: 2001/07/22 20:25:11 $
  + * @version $Revision: 1.4 $ $Date: 2002/02/16 01:07:11 $
*/
   
   class InvokerHttpRequest extends HttpServletRequestWrapper {
  @@ -106,6 +106,7 @@
   
   super(request);
   this.pathInfo = request.getPathInfo();
  +this.pathTranslated = request.getPathTranslated();
   this.requestURI = request.getRequestURI();
   this.servletPath = request.getServletPath();
   
  @@ -129,6 +130,12 @@
   
   
   /**
  + * The translated path information for this request.
  + */
  +protected String pathTranslated = null;
  +
  +
  +/**
* The request URI for this request.
*/
   protected String requestURI = null;
  @@ -161,6 +168,17 @@
   
   
   /**
  + * Override the getPathTranslated() method of the
  + * wrapped request.
  + */
  +public String getPathTranslated() {
  +
  +return (this.pathTranslated);
  +
  +}
  +
  +
  +/**
* Override the getRequestURI() method of the wrapped request.
*/
   public String getRequestURI() {
  @@ -203,6 +221,18 @@
   void setPathInfo(String pathInfo) {
   
   this.pathInfo = pathInfo;
  +
  +}
  +
  +
  +/**
  + * Set the translated path info for this request.
  + *
  + * @param pathTranslated The new translated path info
  + */
  +void setPathTranslated(String pathTranslated) {
  +
  +this.pathTranslated = pathTranslated;
   
   }
   
  
  
  
  1.15  +10 -6 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java
  
  Index: InvokerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- InvokerServlet.java   20 Sep 2001 23:34:42 -  1.14
  +++ InvokerServlet.java   16 Feb 2002 01:07:11 -  1.15
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java,v
 1.14 2001/09/20 23:34:42 remm Exp $
  - * $Revision: 1.14 $
  - * $Date: 2001/09/20 23:34:42 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java,v
 1.15 2002/02/16 01:07:11 craigmcc Exp $
  + * $Revision: 1.15 $
  + * $Date: 2002/02/16 01:07:11 $
*
* 
*
  @@ -87,7 +87,7 @@
* in the web application deployment descriptor.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.14 $ $Date: 2001/09/20 23:34:42 $
  + * @version $Revision: 1.15 $ $Date: 2002/02/16 01:07:11 $
*/
   
   public final class InvokerServlet
  @@ -384,10 +384,14 @@
   sb.append("/");
   sb.append(servletClass);
   wrequest.setServletPath(sb.toString());
  -if ((pathInfo == null) || (pathInfo.length() < 1))
  +if ((pathInfo == null) || (pathInfo.length() < 1)) {
   wrequest.setPathInfo(null);
  -else
  +  

Re: Re[2]: cvs commit: jakarta-tomcat-connectors/jk/java/org/apa

[Remy Maucherat]

> Ok, I understand now.
>
> I tested the case through the connector where you do want tomcat
authentication
> and the user principal is always set to null and everything worked fine
with the
> /examples/jsp/security/protected/index.html example. I was able to login
and
> logout as expected and see the user principal.
>
> Thanks for being so thorough.

No problem.

> Also, when I looked today at the nightly builds for 4.0.2, I noticed that
the
> tomcat-ajp.jar file had been broken up into multiple jar files. The build
of
> tomcat-jk.jar from 2:42AM last night did not include the changes you
checked in
> yesterday. When do the connector libraries used in tomcat 4.0.2 nightly
builds
> get rebuilt?

The nightlies are for the HEAD branch, not the 4.0 branch.

In the HEAD:
- tomcat-jk.jar is JK 1.x; that's equivalent to the current tomcat-ajp.jar
- tomcat-jk2.jar is JK 2.x
The two are independent.

I guess tonight's nightly should pick up the changes.

Remy


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

DO NOT REPLY [Bug 4954] - When specifying CATALINA_BASE explicitly, that dir has to have "shared/lib/jasper-*.jar" in it

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

When specifying CATALINA_BASE explicitly, that dir has to have 
"shared/lib/jasper-*.jar" in it





--- Additional Comments From [EMAIL PROTECTED]  2002-02-15 23:53 ---
We could indeed consider moving Jasper to common/lib.
Craig: Any comments on this ?

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

DO NOT REPLY [Bug 6235] - tomcat4-4.0.1-1 rpm has wrong owner for /var/tomcat4/webapps

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

tomcat4-4.0.1-1 rpm has wrong owner for /var/tomcat4/webapps

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Unknown |Installable Packages



--- Additional Comments From [EMAIL PROTECTED]  2002-02-15 23:33 ---
Recategorize. You should test to see if that's still the case in 4.0.2.

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

Re[2]: cvs commit: jakarta-tomcat-connectors/jk/java/org/apa

[Jonathan Pierce]

Ok, I understand now.

I tested the case through the connector where you do want tomcat authentication
and the user principal is always set to null and everything worked fine with the
/examples/jsp/security/protected/index.html example. I was able to login and
logout as expected and see the user principal.

Thanks for being so thorough.

Also, when I looked today at the nightly builds for 4.0.2, I noticed that the
tomcat-ajp.jar file had been broken up into multiple jar files. The build of
tomcat-jk.jar from 2:42AM last night did not include the changes you checked in
yesterday. When do the connector libraries used in tomcat 4.0.2 nightly builds
get rebuilt?

Jonathan

Reply Separator
Subject:Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache
Author: "Tomcat Developers List" <[EMAIL PROTECTED]>
Date:   2/15/2002 3:07 PM

> I don't understand what you mean here. If you want tomcat to authenticate,
and
> the userid is passed in, your code doesn't call setUserPrincipal.

If you want Tomcat to authenticate, you set 'tomcatAuthentication' to true
(that's the default), in which case the connector will always set the user
pricipal to null, regardless of what was set by the connector.

> When the userid passed in is the empty string (not null) and you don't
want
> Tomcat authentication, your code will set the user principal to an
> Ajp13Principal wrapping the empty string and Tomcat will generate the
access
> denied (403) error when the user hits the page through the connector since
the
> user principal will not be null, but will also be an invalid empty string
> userid.

If you don't want Tomcat to authenticate, you set 'tomcatAuthentication' to
false, and the fact of whether or not the pricipal is valid is irrelevant,
since Tomcat is never supposed to authenticate in the first place.

Note the (ajp.remoteUser() != null) which prevents calling toString on the
possibly null field.

I think I implemented what Nacho recommended (and which seems more
consistent).

Remy


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



This email and any files transmitted with it are for the named person's use
only.  It may contain confidential, proprietary or legally privileged
information.  No confidentiality or privilege is waived or lost by any
mistransmission.  If you receive this message in error, please immediately
delete it and all copies of it from your system, destroy any hard copies
of it and notify the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.

This email message has been swept by a virus software product for the
presence of computer viruses.
*

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

DO NOT REPLY [Bug 5736] - Error page exception stored under wrong Attribute

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Error page exception stored under wrong Attribute

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-02-15 23:28 ---
The exception is passed in attribute "javax.servlet.jsp.jspException" only
in the following circumstances (and Tomcat does this correctly):
* The exception occurred on a JSP page
* This JSP page declared an "errorPage" handler in the <%@ page %>
  directive
* You are looking for the exception in the JSP page or servlet pointed
  at by the errorPage handler

In all other circumstances, exceptions thrown by JSP pages or servlets are 
handled according to the standard servlet specification requirements, which 
includes passing the exception to resources declared with  handlers 
in the web.xml file as attribute "javax.servlet.error.exception".

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

cvs commit: jakarta-tomcat-4.0 OUTSTANDING-BUGS-4.0.3.txt RELEASE-NOTES-4.0.3-B1.txt

[remm]

remm02/02/15 15:21:07

  Modified:.Tag: tomcat_40_branch OUTSTANDING-BUGS-4.0.3.txt
RELEASE-NOTES-4.0.3-B1.txt
  Log:
  - Update bug status.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.6   +1 -2  jakarta-tomcat-4.0/Attic/OUTSTANDING-BUGS-4.0.3.txt
  
  Index: OUTSTANDING-BUGS-4.0.3.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/Attic/OUTSTANDING-BUGS-4.0.3.txt,v
  retrieving revision 1.1.2.5
  retrieving revision 1.1.2.6
  diff -u -r1.1.2.5 -r1.1.2.6
  --- OUTSTANDING-BUGS-4.0.3.txt15 Feb 2002 19:16:19 -  1.1.2.5
  +++ OUTSTANDING-BUGS-4.0.3.txt15 Feb 2002 23:21:07 -  1.1.2.6
  @@ -28,10 +28,9 @@
   5976catalina   Tomcat 4.0.2B2 + Security Manager + JSSE don't work together
   6036webapp Problems with URI mapping
   6068jk AJP13 "bad read", IOException
  -6331catalina   Cannot add more than one cookie
  +6331jk Cannot add more than one cookie
   6376jasper Improper import statement is generated when JSP page 
  extends a custom class without package prefix
  -6411catalina   HttpSession.isNew() always returns false
   6420jk Loadbalancer mod_jk from 4.02 not working with TC 3.3
   6432jasper Jasper should validate that an XML-view of a JSP page 
  conforms as much as possible based on the DTD supplied 
  
  
  
  1.1.2.5   +2 -1  jakarta-tomcat-4.0/Attic/RELEASE-NOTES-4.0.3-B1.txt
  
  Index: RELEASE-NOTES-4.0.3-B1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/Attic/RELEASE-NOTES-4.0.3-B1.txt,v
  retrieving revision 1.1.2.4
  retrieving revision 1.1.2.5
  diff -u -r1.1.2.4 -r1.1.2.5
  --- RELEASE-NOTES-4.0.3-B1.txt15 Feb 2002 19:16:19 -  1.1.2.4
  +++ RELEASE-NOTES-4.0.3-B1.txt15 Feb 2002 23:21:07 -  1.1.2.5
  @@ -3,7 +3,7 @@
   Release Notes
   =
   
  -$Id: RELEASE-NOTES-4.0.3-B1.txt,v 1.1.2.4 2002/02/15 19:16:19 remm Exp $
  +$Id: RELEASE-NOTES-4.0.3-B1.txt,v 1.1.2.5 2002/02/15 23:21:07 remm Exp $
   
   
   
  @@ -93,6 +93,7 @@
   --
   
   3770  HttpSessionListener.sessionCreated() called twice for each session
  +5422  HTTP Headers not being cleared after form authentication
   5647  AJP13 connector will not pass authentication requests
   6374  Class not found for: org/w3c/dom/range/Range
   6396  LoggerBase class is package not public
  
  
  

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

DO NOT REPLY [Bug 6331] - Cannot add more than one cookie

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Cannot add more than one cookie





--- Additional Comments From [EMAIL PROTECTED]  2002-02-15 23:17 ---
Looking back at the bug report ...
The Server: Microsoft-IIS/5.0 could hint that you're using AJP 1.3 + Tomcat.
I've missed it, but that's the kind of thing you aboslutely must specify in a
bug report, as the bug doesn't happen in standalone.
If that's the case, reopen the bug and set 'AJP/JK' as the component.

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

DO NOT REPLY [Bug 5706] - Redirect to default host

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Redirect to default host

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-02-15 23:13 ---
Changing this would break the existing configuration of everyone who uses the 
default settings, because a request to "http://foo:8080"; (where "foo" is not a 
known hostname) would get redirected to "http://localhost:8080";.  This redirect 
is only valid if your browser is on the same server that Tomcat is running on.

If you don't want the automatic handling of the default host capability, you can 
turn it off by removing the defaultHost attribute from the  element.  
Then, Tomcat will return a "bad request" status for unknown hosts.

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

Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Request.java

[Remy Maucherat]

> I don't understand what you mean here. If you want tomcat to authenticate,
and
> the userid is passed in, your code doesn't call setUserPrincipal.

If you want Tomcat to authenticate, you set 'tomcatAuthentication' to true
(that's the default), in which case the connector will always set the user
pricipal to null, regardless of what was set by the connector.

> When the userid passed in is the empty string (not null) and you don't
want
> Tomcat authentication, your code will set the user principal to an
> Ajp13Principal wrapping the empty string and Tomcat will generate the
access
> denied (403) error when the user hits the page through the connector since
the
> user principal will not be null, but will also be an invalid empty string
> userid.

If you don't want Tomcat to authenticate, you set 'tomcatAuthentication' to
false, and the fact of whether or not the pricipal is valid is irrelevant,
since Tomcat is never supposed to authenticate in the first place.

Note the (ajp.remoteUser() != null) which prevents calling toString on the
possibly null field.

I think I implemented what Nacho recommended (and which seems more
consistent).

Remy


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

DO NOT REPLY [Bug 5422] - HTTP Headers not being cleared after form authentication

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

HTTP Headers not being cleared after form authentication

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-02-15 23:06 ---
For HEAD branch, fixed in nightly build 20020216.

For 4.0.x branch, will be fixed in 4.0.3.

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

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

[craigmcc]

craigmcc02/02/15 15:05:36

  Modified:catalina/src/share/org/apache/catalina/connector/http Tag:
tomcat_40_branch HttpRequestImpl.java
  Log:
  Port the fix for 5422.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.11.2.1  +14 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpRequestImpl.java
  
  Index: HttpRequestImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpRequestImpl.java,v
  retrieving revision 1.11
  retrieving revision 1.11.2.1
  diff -u -r1.11 -r1.11.2.1
  --- HttpRequestImpl.java  22 Jul 2001 20:25:07 -  1.11
  +++ HttpRequestImpl.java  15 Feb 2002 23:05:36 -  1.11.2.1
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpRequestImpl.java,v
 1.11 2001/07/22 20:25:07 pier Exp $
  - * $Revision: 1.11 $
  - * $Date: 2001/07/22 20:25:07 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpRequestImpl.java,v
 1.11.2.1 2002/02/15 23:05:36 craigmcc Exp $
  + * $Revision: 1.11.2.1 $
  + * $Date: 2002/02/15 23:05:36 $
*
* 
*
  @@ -81,7 +81,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.11 $ $Date: 2001/07/22 20:25:07 $
  + * @version $Revision: 1.11.2.1 $ $Date: 2002/02/15 23:05:36 $
*/
   
   final class HttpRequestImpl
  @@ -262,6 +262,16 @@
   headerPool = newHeaderPool;
   }
   headerPool[nextHeader++] = new HttpHeader(name, value);
  +
  +}
  +
  +
  +/**
  + * Clear the collection of Headers associated with this Request.
  + */
  +public void clearHeaders() {
  +
  +nextHeader = 0;
   
   }
   
  
  
  

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

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

[craigmcc]

craigmcc02/02/15 15:03:42

  Modified:catalina/src/share/org/apache/catalina/connector/http
HttpRequestImpl.java
  Log:
  Implement clearHeaders() in the HttpRequest implementation class that is
  actually used by the HTTP/1.1 connector.  This fixes #5422, where the
  headers were doubled up on the request after a successful form-based login,
  because calling request.clearHeaders() had no functional impact.
  
  PR: Bugzilla #5422
  Submitted by: Ben Walding <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.12  +14 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpRequestImpl.java
  
  Index: HttpRequestImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpRequestImpl.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- HttpRequestImpl.java  22 Jul 2001 20:25:07 -  1.11
  +++ HttpRequestImpl.java  15 Feb 2002 23:03:42 -  1.12
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpRequestImpl.java,v
 1.11 2001/07/22 20:25:07 pier Exp $
  - * $Revision: 1.11 $
  - * $Date: 2001/07/22 20:25:07 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpRequestImpl.java,v
 1.12 2002/02/15 23:03:42 craigmcc Exp $
  + * $Revision: 1.12 $
  + * $Date: 2002/02/15 23:03:42 $
*
* 
*
  @@ -81,7 +81,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.11 $ $Date: 2001/07/22 20:25:07 $
  + * @version $Revision: 1.12 $ $Date: 2002/02/15 23:03:42 $
*/
   
   final class HttpRequestImpl
  @@ -262,6 +262,16 @@
   headerPool = newHeaderPool;
   }
   headerPool[nextHeader++] = new HttpHeader(name, value);
  +
  +}
  +
  +
  +/**
  + * Clear the collection of Headers associated with this Request.
  + */
  +public void clearHeaders() {
  +
  +nextHeader = 0;
   
   }
   
  
  
  

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

Re[2]:cvs commit: jakarta-tomcat-connectors/jk/java/org/apac

[Jonathan Pierce]

>>No, I did it on purpose.
>>It's a lot better to have the user set the behavior of the connector here.

I don't understand what you mean here. If you want tomcat to authenticate, and
the userid is passed in, your code doesn't call setUserPrincipal.

When the userid passed in is the empty string (not null) and you don't want
Tomcat authentication, your code will set the user principal to an
Ajp13Principal wrapping the empty string and Tomcat will generate the access
denied (403) error when the user hits the page through the connector since the
user principal will not be null, but will also be an invalid empty string
userid.

Did you test this code with the connector?

//if ((!(((Ajp13Connector) connector).getTomcatAuthentication())) 
 //&& (ajp.remoteUser() != null)) {
 //setUserPrincipal(new
//Ajp13Principal(ajp.remoteUser().toString()));
//   } else {
 //  setUserPrincipal(null);
 //  }




Reply Separator
Subject:Re:cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/
Author: "Tomcat Developers List" <[EMAIL PROTECTED]>
Date:   2/15/2002 2:20 PM

> It looks like you accidently removed the empty string check needed here
for
> ajp.RemoteUser ().
> ajp.RemoteUser () should probably also be checked whether it is null
before
> calling toString.

No, I did it on purpose.
It's a lot better to have the user set the behavior of the connector here.
Since you want TC to authenticate the users, you don't have to do anything.
OTOH, if you want the native webserver to authenticate, you should set the
'tomcatAuthentication' attribute to 'false' on the Connector element.

As pointed out by Nacho, it makes the connector predictable.

Also, the check for ajp.remoteUser() being equal to null is there (but
obviously, it's only needed when 'tomcatAuthentication' is false).

Remy


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



This email and any files transmitted with it are for the named person's use
only.  It may contain confidential, proprietary or legally privileged
information.  No confidentiality or privilege is waived or lost by any
mistransmission.  If you receive this message in error, please immediately
delete it and all copies of it from your system, destroy any hard copies
of it and notify the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.

This email message has been swept by a virus software product for the
presence of computer viruses.
*

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

cvs commit: jakarta-tomcat-4.0/webapps/admin/service service.jsp

[manveen]

manveen 02/02/15 13:04:37

  Modified:webapps/admin/WEB-INF struts-config.xml
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin
ApplicationResources_en.properties
ApplicationResources_es.properties
TomcatTreeBuilder.java
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/host
SetUpDeleteHostAction.java
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/service
AddServiceAction.java
   webapps/admin/service service.jsp
  Added:   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/host
AddHostAction.java AddHostForm.java
SetUpAddHostAction.java
   webapps/admin/host addHost.jsp
  Log:
  Added functionality to add hosts from the admin tool.
  Made necessary changes to properties file and struts-config.xml
  
  Revision  ChangesPath
  1.32  +23 -0 jakarta-tomcat-4.0/webapps/admin/WEB-INF/struts-config.xml
  
  Index: struts-config.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/struts-config.xml,v
  retrieving revision 1.31
  retrieving revision 1.32
  diff -u -r1.31 -r1.32
  --- struts-config.xml 14 Feb 2002 20:37:21 -  1.31
  +++ struts-config.xml 15 Feb 2002 21:04:37 -  1.32
  @@ -39,6 +39,10 @@
   
   
  +
  +
  +
   
   
  @@ -144,6 +148,10 @@
   
  +
  +

   
   
  +
  +
  +
  +
   
   
   
  +
  +
  +
  +
   
   
   
  
  
  
  1.28  +2 -0  
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_en.properties
  
  Index: ApplicationResources_en.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_en.properties,v
  retrieving revision 1.27
  retrieving revision 1.28
  diff -u -r1.27 -r1.28
  --- ApplicationResources_en.properties12 Feb 2002 06:10:41 -  1.27
  +++ ApplicationResources_en.properties15 Feb 2002 21:04:37 -  1.28
  @@ -55,6 +55,7 @@
   error.proxyPortText.format=Proxy Port Number not a valid integer!
   error.proxyPortText.range=Proxy Port Number seems out of range. Valid range is 
1-65535. 
   error.hostName.required=Hostname is required
  +error.hostName.exists=Hostname already exists
   error.appBase.required=Application Base is required
   service.name=Name
   service.engine.props=Engine properties
  @@ -158,6 +159,7 @@
   actions.delete=Delete
   error.defaultHost.required=Default Hostname required
   error.serviceName.required=Service Name required
  +error.serviceName.exists=Service Name already exists
   actions.thisrealm.delete=Delete this User Realm
   realm.driver=Database Driver
   realm.passwd=Database Password
  
  
  
  1.27  +2 -0  
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_es.properties
  
  Index: ApplicationResources_es.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_es.properties,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- ApplicationResources_es.properties12 Feb 2002 06:10:41 -  1.26
  +++ ApplicationResources_es.properties15 Feb 2002 21:04:37 -  1.27
  @@ -55,6 +55,7 @@
   error.proxyPortText.format=Numero del puerto del proxy es un numero entero no 
valido!
   error.proxyPortText.range=El numero del puerto del proxy esta fuera de rango. 
El rango valido es 1-65535.
   error.hostName.required=Se requiere el hostname
  +error.hostName.exists=El hostname ya existe
   error.appBase.required=Se requiere la base de la aplicacion
   service.name=Nombre
   service.engine.props=Propiedades del motor
  @@ -158,6 +159,7 @@
   actions.delete=Delete
   error.defaultHost.required=Default Hostname requerido
   error.serviceName.required=Service name requerido
  +error.serviceName.exists=El ServiceName ya existe.
   actions.thisrealm.delete=Suprima Este User Realm
   realm.driver=Database Driver
   realm.passwd=Database Password
  
  
  
  1.16  +4 -5  
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TomcatTreeBuilder.java
  
  Index: TomcatTreeBuilder.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TomcatTreeBuilder.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- TomcatTreeBuilder.java13 Feb 2002 22:30:20 -  1.15
  +++ Tomca

Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4Ajp13Connector.java Ajp13Request.java

[costinm]

On 15 Feb 2002 [EMAIL PROTECTED] wrote:

> remm02/02/15 13:13:19
> 
>   Modified:jk/java/org/apache/ajp/tomcat4 Ajp13Connector.java
> Ajp13Request.java
>   Log:
>   - Add a 'tomcatAuthentication' flag, which defaults to true.
>   - If the flag is true, Tomcat is 100% responsible of the authentication. If false,
> the user authenticated by the native webserver will be used.
>   - This new flag will be added in the docs, after reviewing.
>   - I didn't know I would end up contributing stuff to JK ;-)

Now we just need to get you involved in jk2, and maybe in the native
 code :-)


Costin
 



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

DO NOT REPLY [Bug 6494] - Tomcat 4.0.2 could not start from W2k service after adding webapps conf

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Tomcat 4.0.2 could not start from W2k service after adding webapps conf

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Blocker |Major
  Component|Webapps |Catalina



--- Additional Comments From [EMAIL PROTECTED]  2002-02-15 22:24 ---
I'm using the service on a daily basis, so I'd say it works for me.
You should include the error messages you're getting (from the logs).
Also, did you try without the JDBC realm ?

Note: If the logs are empty, then it's a VM crash on startup, in which case the
bug is INVALID (as it's a JVM bug, not a Tomcat bug).

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

Re:cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/

[Remy Maucherat]

> It looks like you accidently removed the empty string check needed here
for
> ajp.RemoteUser ().
> ajp.RemoteUser () should probably also be checked whether it is null
before
> calling toString.

No, I did it on purpose.
It's a lot better to have the user set the behavior of the connector here.
Since you want TC to authenticate the users, you don't have to do anything.
OTOH, if you want the native webserver to authenticate, you should set the
'tomcatAuthentication' attribute to 'false' on the Connector element.

As pointed out by Nacho, it makes the connector predictable.

Also, the check for ajp.remoteUser() being equal to null is there (but
obviously, it's only needed when 'tomcatAuthentication' is false).

Remy


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

Re: {PATCH] Enhanced JNDI realm

[Craig R. McClanahan]

John,

Sorry it took so long to respond to this ... life has been busier than I
would have believed possible.

I've reviewed the patch, and the changes seem reasonable.  Can you do me a
favor, though, and send me a complete updated version of JNDIRealm.java?
For changes this big, I get a little gunshy about merging diffs.

Thanks,
Craig

On Fri, 1 Feb 2002, John Holman wrote:

> Date: Fri, 01 Feb 2002 21:56:44 +
> From: John Holman <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: {PATCH] Enhanced JNDI realm
>
> Craig
>
> I've attached a patch to enhance the current JNDI realm implementation.
> This includes three features that have been requested a number of times and
> appear in the draft functional specification:
>
> ** the realm can authenticate by binding to the directory as the user. This
> mode of operation is usually to be preferred unless HTTP digest
> authentication is required. The realm will automatically authenticate in
> this way if the "userPassword" configuration attribute is not specified.
> The "connectionName" and "connectPassword" properties are used
> when searching the directory or retrieving role information. In this mode,
> anonymous authentication is often sufficient, in which case these need not
> be specified.
>
> ** the realm can search the directory for the user's entry. It will do this
> if the "userPattern" configuration attribute is not specified.
>
> Three new configuration parameters control the search for the user's
> directory entry:
>
> userSearch - a pattern specifying the LDAP search filter for selecting
> users. Use {0} to substitute in the username.
>
> userBase - the base element for user searches. If not specified the top
> level element in the directory context will be used.
>
> useSubtree - set to true if you want user searches to search subtrees of
> the element selected by userBase. The default value of false causes only
> the top level element to be searched.
>
>
> ** the realm can combine roles held as the values of an attribute in the
> user's entry with those retrieved from a search for roles. The search for
> roles takes place as before. If the roleSearch configuration attribute is
> not specified the realm will look only in the user's entry for roles.
>
> This feature uses one new configuration attribute:
>
> userRoleName - the name of an attribute in the user's entry containing the
> names of roles. If not specified the directory is searched for roles as before.
>
> Note that the new configuration interface is backwards compatible with the
> current JNDIRealm. For existing users the realm will behave just as it did
> before - no configuration changes are required. The existing documentation
> is still accurate about the subset of functionality it describes.
>
> Here is a sample realm configuration that demonstrates all three new
> features. It is assumed that an anonymous bind is sufficient to search the
> directory for the user
> and retrieve the role information. The user is found by searching the
> directory and authenticated by binding to the directory with the
> credentials presented by the user. Role names are contained both in the
> "memberOf" attribute of the user's own directory entry and in the "cn"
> attribute of group entries to which the user belongs
>
>  debug="99"
> connectionURL="ldap://localhost:389";
> userBase="ou=people,dc=mycompany,dc=com"
> userSearch="(uid={0})"
> userRoleName="memberOf"
> roleSearch="(uniqueMember={0})"
> roleBase="ou=groups,dc=mycompany,dc=com"
> roleName="cn"
> roleSubtree="true"
>/>
>
>
>
> I've not addressed issues of connection management etc in this patch,
> though there is certainly room for improvement (context pooling etc). In a
> previous message you mentioned leveraging the "global JNDI resources"
> capabilities for that, and Tony Danbura has also expressed an interest in
> this area. However the enhancements in this patch are independent of that
> issue, and should not complicate it. In particular, note that the "bind
> mode" functionality is implemented in a way that still uses a single
> directory context that can be returned to the pool. This is achieved by
> changing the security environment of the context before and after binding,
> rather than creating a different context for the bind. With an LDAP v3
> server this should be an efficient approach since the underlying connection
> to the directory server does not change. An LDAP v2 server must create a
> new connection for each bind operation, so context pooling will not be so
> effective, but that does not affect the logic.
>
> I'd be very grateful if you would take a look at this patch and hopefully
> submit it. If it is accepted I promise I'll update the documentation to
> cover the new features!
>
> Thanks, John.
>
>
>
>
>
>
>
>
>


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

Re:cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/

[Jonathan Pierce]

It looks like you accidently removed the empty string check needed here for
ajp.RemoteUser ().
ajp.RemoteUser () should probably also be checked whether it is null before
calling toString.


//if ((!(((Ajp13Connector) connector).getTomcatAuthentication())) 
 //&& (ajp.remoteUser() != null)) {
 //setUserPrincipal(new
//Ajp13Principal(ajp.remoteUser().toString()));
//   } else {
 //  setUserPrincipal(null);
 //  }

should be:

Ajp13Principal theUserPrincipal = null;
if ((Ajp13Connector) connector).getTomcatAuthentication())
{   
MessageBytes theRemoteUser = ajp.remoteUser ();
if (theRemoteUser != null)
{
String theRemoteUserName = theRemoteUser.toString ();
if (! theRemoteUserName.equals (""))
{
theUserPrincipal = new Ajp13Principal (theRemoteUserName);
}
}
}
setUserPrincipal(theUserPrincipal);

Jonathan


Reply Separator
Subject:cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp
Author: "Tomcat Developers List" <[EMAIL PROTECTED]>
Date:   2/15/2002 9:13 PM

remm02/02/15 13:13:19

  Modified:jk/java/org/apache/ajp/tomcat4 Ajp13Connector.java
Ajp13Request.java
  Log:
  - Add a 'tomcatAuthentication' flag, which defaults to true.
  - If the flag is true, Tomcat is 100% responsible of the authentication. If
false,
the user authenticated by the native webserver will be used.
  - This new flag will be added in the docs, after reviewing.
  - I didn't know I would end up contributing stuff to JK ;-)
  
  Revision  ChangesPath
  1.13  +31 -4
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Connector.java
  
  Index: Ajp13Connector.java
  ===
  RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Connecto
r.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- Ajp13Connector.java   7 Feb 2002 00:44:40 -   1.12
  +++ Ajp13Connector.java   15 Feb 2002 21:13:19 -  1.13
  @@ -1,7 +1,7 @@
   /*
  - * $Header:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Connecto
r.java,v 1.12 2002/02/07 00:44:40 costin Exp $
  - * $Revision: 1.12 $
  - * $Date: 2002/02/07 00:44:40 $
  + * $Header:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Connecto
r.java,v 1.13 2002/02/15 21:13:19 remm Exp $
  + * $Revision: 1.13 $
  + * $Date: 2002/02/15 21:13:19 $
*
* 
*
  @@ -93,7 +93,7 @@
* Implementation of an Ajp13 connector.
*
* @author Kevin Seguin
  - * @version $Revision: 1.12 $ $Date: 2002/02/07 00:44:40 $
  + * @version $Revision: 1.13 $ $Date: 2002/02/15 21:13:19 $
*/
   
   
  @@ -273,6 +273,14 @@
   
   private String secret = null;
   
  +
  +/**
  + * Tomcat authentication flag. If true, the authnetication is done by
  + * Tomcat, otherwise, it is done by the native webserver.
  + */
  +private boolean tomcatAuthentication = true;
  +
  +
   // -
Properties
   
   
  @@ -623,6 +631,7 @@
   
   }
   
  +
   /**
* Returns the Service with which we are associated.
*/
  @@ -630,12 +639,30 @@
return service;
   }
   
  +
   /**
* Set the Service with which we are associated.
*/
   public void setService(Service service) {
this.service = service;
   }
  +
  +
  +/**
  + * Get the value of the tomcatAuthentication flag.
  + */
  +public boolean getTomcatAuthentication() {
  +return tomcatAuthentication;
  +}
  +
  +
  +/**
  + * Set the value of the tomcatAuthentication flag.
  + */
  +public void setTomcatAuthentication(boolean tomcatAuthentication) {
  +this.tomcatAuthentication = tomcatAuthentication;
  +}
  +
   
   // - Public
Methods
   
  
  
  
  1.8   +3 -3 
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Request.java
  
  Index: Ajp13Request.java
  ===
  RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Request.
java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- Ajp13Request.java 15 Feb 2002 00:54:43 -  1.7
  +++ Ajp13Request.java 15 Feb 2002 21:13:19 -  1.8
  @@ -112,9 +112,9 @@
   setServerName(ajp.serverName().toString());
   setServerPort(ajp.getServerPort());
   
  -String remoteUser = ajp.remoteUser().toString();
  -if ((remoteUser != null) && (!(remoteUser.equals("" {
  -setUserP

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Connector.java Ajp13Request.java

[remm]

remm02/02/15 13:13:19

  Modified:jk/java/org/apache/ajp/tomcat4 Ajp13Connector.java
Ajp13Request.java
  Log:
  - Add a 'tomcatAuthentication' flag, which defaults to true.
  - If the flag is true, Tomcat is 100% responsible of the authentication. If false,
the user authenticated by the native webserver will be used.
  - This new flag will be added in the docs, after reviewing.
  - I didn't know I would end up contributing stuff to JK ;-)
  
  Revision  ChangesPath
  1.13  +31 -4 
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Connector.java
  
  Index: Ajp13Connector.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Connector.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- Ajp13Connector.java   7 Feb 2002 00:44:40 -   1.12
  +++ Ajp13Connector.java   15 Feb 2002 21:13:19 -  1.13
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Connector.java,v
 1.12 2002/02/07 00:44:40 costin Exp $
  - * $Revision: 1.12 $
  - * $Date: 2002/02/07 00:44:40 $
  + * $Header: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Connector.java,v
 1.13 2002/02/15 21:13:19 remm Exp $
  + * $Revision: 1.13 $
  + * $Date: 2002/02/15 21:13:19 $
*
* 
*
  @@ -93,7 +93,7 @@
* Implementation of an Ajp13 connector.
*
* @author Kevin Seguin
  - * @version $Revision: 1.12 $ $Date: 2002/02/07 00:44:40 $
  + * @version $Revision: 1.13 $ $Date: 2002/02/15 21:13:19 $
*/
   
   
  @@ -273,6 +273,14 @@
   
   private String secret = null;
   
  +
  +/**
  + * Tomcat authentication flag. If true, the authnetication is done by
  + * Tomcat, otherwise, it is done by the native webserver.
  + */
  +private boolean tomcatAuthentication = true;
  +
  +
   // - Properties
   
   
  @@ -623,6 +631,7 @@
   
   }
   
  +
   /**
* Returns the Service with which we are associated.
*/
  @@ -630,12 +639,30 @@
return service;
   }
   
  +
   /**
* Set the Service with which we are associated.
*/
   public void setService(Service service) {
this.service = service;
   }
  +
  +
  +/**
  + * Get the value of the tomcatAuthentication flag.
  + */
  +public boolean getTomcatAuthentication() {
  +return tomcatAuthentication;
  +}
  +
  +
  +/**
  + * Set the value of the tomcatAuthentication flag.
  + */
  +public void setTomcatAuthentication(boolean tomcatAuthentication) {
  +this.tomcatAuthentication = tomcatAuthentication;
  +}
  +
   
   // - Public Methods
   
  
  
  
  1.8   +3 -3  
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Request.java
  
  Index: Ajp13Request.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Request.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- Ajp13Request.java 15 Feb 2002 00:54:43 -  1.7
  +++ Ajp13Request.java 15 Feb 2002 21:13:19 -  1.8
  @@ -112,9 +112,9 @@
   setServerName(ajp.serverName().toString());
   setServerPort(ajp.getServerPort());
   
  -String remoteUser = ajp.remoteUser().toString();
  -if ((remoteUser != null) && (!(remoteUser.equals("" {
  -setUserPrincipal(new Ajp13Principal(remoteUser));
  +if ((!(((Ajp13Connector) connector).getTomcatAuthentication())) 
  +&& (ajp.remoteUser() != null)) {
  +setUserPrincipal(new Ajp13Principal(ajp.remoteUser().toString()));
   } else {
   setUserPrincipal(null);
   }
  
  
  

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

DO NOT REPLY [Bug 6494] New: - Tomcat 4.0.2 could not start from W2k service after adding webapps conf

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Tomcat 4.0.2 could not start from W2k service after adding webapps conf

   Summary: Tomcat 4.0.2 could not start from W2k service after
adding webapps conf
   Product: Tomcat 4
   Version: 4.0.2 Final
  Platform: PC
   URL: http://pc47094.utdallas.edu:8080/ResearchDB/
OS/Version: Windows NT/2K
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Webapps
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,

Tomcat works well from the W2k service; it can be automatically started. But 
after putting follow code into the $catalina_home\conf\server.xml, it could not 
be started from the service. However, it can ba started by executing 
startup.bat command from MS-DOS ($catalina_home\bin). Here is the code which 
was added into the "Host" tag:



  



The startup.bat is:

@echo off
rem ---
rem startup.bat - Start Script for the CATALINA Server
rem
rem $Id: startup.bat,v 1.3.4.1 2001/10/12 16:48:57 remm Exp $
rem ---
set _CATALINA_HOME=%CATALINA_HOME%
if not "%CATALINA_HOME%" == "" goto gotHome
set CATALINA_HOME=.
if exist "%CATALINA_HOME%\bin\catalina.bat" goto gotHome
set CATALINA_HOME=..
if exist "%CATALINA_HOME%\bin\catalina.bat" goto gotHome
echo Unable to determine the value of CATALINA_HOME
goto cleanup
:gotHome
"%CATALINA_HOME%\bin\catalina" start %1 %2 %3 %4 %5 %6 %7 %8 %9
:cleanup
set CATALINA_HOME=%_CATALINA_HOME%
set _CATALINA_HOME=


My application ResearchDB was put into the directory ResearchDB under 
$catalina_home\webapps.

Thank you.

Dayong Zhang

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

cvs commit: jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/service AddServiceAction.java AddServiceForm.java

[manveen]

manveen 02/02/15 01:40:39

  Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin/service
AddServiceAction.java AddServiceForm.java
  Log:
  Cleaned up validation code and creation and addition of a new service.
  
  Revision  ChangesPath
  1.2   +111 -55   
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/service/AddServiceAction.java
  
  Index: AddServiceAction.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/service/AddServiceAction.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- AddServiceAction.java 4 Feb 2002 17:59:19 -   1.1
  +++ AddServiceAction.java 15 Feb 2002 09:40:39 -  1.2
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/service/AddServiceAction.java,v
 1.1 2002/02/04 17:59:19 manveen Exp $
  - * $Revision: 1.1 $
  - * $Date: 2002/02/04 17:59:19 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/service/AddServiceAction.java,v
 1.2 2002/02/15 09:40:39 manveen Exp $
  + * $Revision: 1.2 $
  + * $Date: 2002/02/15 09:40:39 $
*
* 
*
  @@ -63,7 +63,9 @@
   
   import java.util.Iterator;
   import java.io.IOException;
  +import java.util.Locale;
   import javax.servlet.ServletException;
  +import javax.servlet.http.HttpSession;
   import javax.servlet.http.HttpServletRequest;
   import javax.servlet.http.HttpServletResponse;
   import org.apache.struts.action.Action;
  @@ -75,7 +77,6 @@
   import javax.management.MBeanServer;
   import javax.management.MBeanServerFactory;
   import javax.management.QueryExp;
  -import javax.management.Query;
   import javax.management.ObjectInstance;
   import javax.management.ObjectName;
   import javax.management.JMException;
  @@ -89,12 +90,13 @@
* add service actions.
*
* @author Manveen Kaur
  - * @version $Revision: 1.1 $ $Date: 2002/02/04 17:59:19 $
  + * @version $Revision: 1.2 $ $Date: 2002/02/15 09:40:39 $
*/
   
   public final class AddServiceAction extends Action {
   
   private static MBeanServer mBServer = null;
  +private static MessageResources resources = null;
   
   // - Public Methods
   
  @@ -120,80 +122,134 @@
   HttpServletResponse response)
   throws IOException, ServletException {
   
  -try{
  -
  -// front end validation and checking.
  -// ===
  -MessageResources messages = getResources();
  -
  -// Validate the request parameters specified by the user
  -ActionErrors errors = new ActionErrors();
  -
  -// Report any errors we have discovered back to the original form
  -if (!errors.empty()) {
  -saveErrors(request, errors);
  -return (new ActionForward(mapping.getInput()));
  -}
  -
  -if(mBServer == null) {
  -ApplicationServlet servlet = (ApplicationServlet)getServlet();
  -mBServer = servlet.getServer();
  -}
  +// Look up the components we will be using as needed
  +if (mBServer == null) {
  +mBServer = ((ApplicationServlet) getServlet()).getServer();
  +}
  +if (resources == null) {
  +resources = getServlet().getResources();
  +}
  +HttpSession session = request.getSession();
  +Locale locale = (Locale) session.getAttribute(Action.LOCALE_KEY);
  +
  +// Validate the request parameters specified by the user
  +ActionErrors errors = new ActionErrors();
  +
  +// Report any errors we have discovered back to the original form
  +if (!errors.empty()) {
  +saveErrors(request, errors);
  +return (new ActionForward(mapping.getInput()));
  +}
  +
  +String serviceName = request.getParameter("serviceName");
  +String engineName = request.getParameter("engineName");
  +String debugLvlText = request.getParameter("debugLvl");
  +String defaultHost = request.getParameter("defaultHost");
  +
  +ObjectInstance mBeanFactory = null;
  +
  +// unique mBean name of the new service that is created.
  +String newService = null;
  +
  +// Get hold of the parent server.
  +ObjectName server = null;
  +try {
  +Iterator serverItr =
  +mBServer.queryMBeans(new ObjectName(TomcatTreeBuilder.SERVER_TYPE +
  + 

Re: BUG 5722 : Forward to page display a blank page

[Bill Barker]

In fact, I'd almost 'fixed' this before going back and re-reading the
servlet spec.  I just can't find enough wiggle room in section 8.1 (of
either 2.2 or 2.3) to allow this.  If anyone else can find a way to
interpret the spec differently, I'd be more than happy to change this for
RC1.

The difference in the examples is that "doNotExist.jsp" has a servlet (sort
of :), whereas "/doNotExist/" has no handler.
- Original Message -
From: "Thomas Colin de Verdiere" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, February 15, 2002 2:30 AM
Subject: BUG 5722 : Forward to page display a blank page


> Sorry to bother you, i'd like to comment on bug 5722.
>
> I tried to forward to page that do not exist :
> doNotExist
>
> 
> 
> 
> this displays a blank page
>
> i tried to forward to a page that do not exist with extension :
> 
> 
> 
> this displays a 404 error page.
> i was expecting that a page with no extension would display a 404 page.
>
> Thanks
>
> Thomas Colin de Verdière
>
> -
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> .
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> INSERTED IN THE BUG DATABASE.
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5722
>
> Forward to a page that have no extension displays a blank page
>
> [EMAIL PROTECTED] changed:
>
> What|Removed |Added
> --
--
>   Status|REOPENED|RESOLVED
>   Resolution||INVALID
>
>
>
> --- Additional Comments From [EMAIL PROTECTED] 2002-02-14
> 19:00 ---
> Section 8.1 of the servlet spec requires that the RequestDispatcher
returns
> the content of the path.  If it's not there, it has no content.
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

form based login+jdbc realm+url session tracking=broken login

[cam]

_

I'm wondering if there are any developers who have seen this bug...

Under Tcat 4.x on a form-based login site with jdbcrealms, if you

have a user which doesn't have per-session cookies enabled

(so that he/she is using url session tracking)

Tomcat has this strange behavior where it sends the user

to the j_security_check page three times before letting them in



I submitted the bug as:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6281



Have any active developers seen this problem?

The problem does not occur when I switch to memory-based realms,

so it appears to be a jdbcrealm specific issue.



If anyone has any ideas on things I should look for in the

jdbcrealm implementation, I would appreciate any hints

on trying to fix this.



Thanks,

Cameron Elliott

cvs commit: jakarta-tomcat-4.0 OUTSTANDING-BUGS-4.0.3.txt RELEASE-NOTES-4.0.3-B1.txt

[remm]

remm02/02/15 11:16:19

  Modified:.Tag: tomcat_40_branch OUTSTANDING-BUGS-4.0.3.txt
RELEASE-NOTES-4.0.3-B1.txt
  Log:
  - Update bug status.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.5   +5 -2  jakarta-tomcat-4.0/Attic/OUTSTANDING-BUGS-4.0.3.txt
  
  Index: OUTSTANDING-BUGS-4.0.3.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/Attic/OUTSTANDING-BUGS-4.0.3.txt,v
  retrieving revision 1.1.2.4
  retrieving revision 1.1.2.5
  diff -u -r1.1.2.4 -r1.1.2.5
  --- OUTSTANDING-BUGS-4.0.3.txt14 Feb 2002 17:32:25 -  1.1.2.4
  +++ OUTSTANDING-BUGS-4.0.3.txt15 Feb 2002 19:16:19 -  1.1.2.5
  @@ -14,18 +14,20 @@
  is 0 with Apache WebApp module
   5040webaap EOFException when talking from applet to servlet 
  via mod_webapp
  +5229catalina   Session cannot unbind if using DistributedManager
   5402webapp WarpConnection raise IOException in a Clustered 
  Solaris environment
  +5507catalina   Swapping sessions causes exceptions and it doesn't work 
  +   with FileStore
   5704servlets   CgiServlet corrupting images?
   5735catalina   HTTP connector running out of processors under heavy load
   5759servlets   CGI servlet mapping by extension *.cgi does not work
   5795catalina   Catalina Shutdown relies on localhost causing problems 
   5827catalina   DataInputStream.readInt returns wrong values
   5899servlets   HTTP POST parameters ignored in CGIServlet.java
  -5976catalina   Spaces should be allowed in Servlet Context paths
  +5976catalina   Tomcat 4.0.2B2 + Security Manager + JSSE don't work together
   6036webapp Problems with URI mapping
   6068jk AJP13 "bad read", IOException
  -6219jk FORM authentication does not work when using AJP connector
   6331catalina   Cannot add more than one cookie
   6376jasper Improper import statement is generated when JSP page 
  extends a custom class without package prefix
  @@ -36,6 +38,7 @@
  in JSP.B of the JSP 1.2 specification
   6443jasper Jasper doesn't follow the spec in regards to the xml-view 
  of a JSP page and whitespace handling semantics
  +6457jk mod_jk causes segmentation fault with JkLogLevel != debug
   6464jasper Jspc generates bad package names on Windows NT
   
   
  
  
  
  1.1.2.4   +3 -1  jakarta-tomcat-4.0/Attic/RELEASE-NOTES-4.0.3-B1.txt
  
  Index: RELEASE-NOTES-4.0.3-B1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/Attic/RELEASE-NOTES-4.0.3-B1.txt,v
  retrieving revision 1.1.2.3
  retrieving revision 1.1.2.4
  diff -u -r1.1.2.3 -r1.1.2.4
  --- RELEASE-NOTES-4.0.3-B1.txt14 Feb 2002 17:32:25 -  1.1.2.3
  +++ RELEASE-NOTES-4.0.3-B1.txt15 Feb 2002 19:16:19 -  1.1.2.4
  @@ -3,7 +3,7 @@
   Release Notes
   =
   
  -$Id: RELEASE-NOTES-4.0.3-B1.txt,v 1.1.2.3 2002/02/14 17:32:25 remm Exp $
  +$Id: RELEASE-NOTES-4.0.3-B1.txt,v 1.1.2.4 2002/02/15 19:16:19 remm Exp $
   
   
   
  @@ -92,6 +92,8 @@
   Bugzilla Bugs Resolved:
   --
   
  +3770  HttpSessionListener.sessionCreated() called twice for each session
  +5647  AJP13 connector will not pass authentication requests
   6374  Class not found for: org/w3c/dom/range/Range
   6396  LoggerBase class is package not public
   6406  All classes in $CATALINA_HOME/classes become invisible 
  
  
  

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

DO NOT REPLY [Bug 5827] - DataInputStream.readInt returns wrong values

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

DataInputStream.readInt returns wrong values

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Critical

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

DO NOT REPLY [Bug 6487] - tarball jakarta-tomcat-connectors-4.0.2-01-src.tar.gz problem

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

tarball jakarta-tomcat-connectors-4.0.2-01-src.tar.gz problem

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-02-15 17:50 ---
Fixed.

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

cvs commit: jakarta-tomcat-4.0 build.xml

[remm]

remm02/02/15 09:50:43

  Modified:.build.xml
  Log:
  - Set the scripts in j-t-c to 755.
  - Note: When adding new scripts, or renaming them, they should be added there too.
  
  Revision  ChangesPath
  1.61  +22 -0 jakarta-tomcat-4.0/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/build.xml,v
  retrieving revision 1.60
  retrieving revision 1.61
  diff -u -r1.60 -r1.61
  --- build.xml 12 Feb 2002 17:34:15 -  1.60
  +++ build.xml 15 Feb 2002 17:50:43 -  1.61
  @@ -392,8 +392,30 @@
   
   
  +  
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +  
 
   
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
 
   
   
  
  
  

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

Updated Fix for AJP13 Connector Authentication Bug !!!

[Jonathan Pierce]

I looked over the patch I supplied yesterday and realized that this original
line (String remoteUser = ajp.remoteUser().toString();) could cause a null
pointer exception if the ajp.remoteUser() returns null. Since the original code
checked for null, it is probably safer to check for null on ajp.remoteUser ()
before calling toString just in case the RemoteUser is supplied as null.

Please replace the patch I supplied yesterday with the following code to support
this possibility. I've tested this updated version and it works as well.

In org.apache.ajp.tomcat4.Ajp13Request.setAjpRequest 
Replace from line 115:

//String remoteUser = ajp.remoteUser().toString();
//if ((remoteUser != null) && (! remoteUser.equals ("")))
//{
//setUserPrincipal(new Ajp13Principal(remoteUser));
//}
 //   else
//{
// setUserPrincipal(null);
//}

Ajp13Principal theUserPrincipal = null;
MessageBytes theRemoteUser = ajp.remoteUser ();
if (theRemoteUser != null)
{
String theRemoteUserName = theRemoteUser.toString ();
if (! theRemoteUserName.equals (""))
{
theUserPrincipal = new Ajp13Principal (theRemoteUserName);
}
}
setUserPrincipal(theUserPrincipal);


Here is an explanation of the rational behind the patch:

The request is providing and empty string for the remote user parameter rather
than null. The unpatched code was setting the user principal to a non-null empty
user instead of null. Subsequent code calling getUserPrincipal assumed that a
user had already been authenticated when the non-null getUserPrincipal value was
seen, and denied access to the empty user. The patched code treats a specified
user of "" the same as an unspecified user header of null, and stores the user
principal in the request to null when the supplied userid is empty or null, and
to a valid Ajp13Principal  when the userid is non-null, non-empty.

Jonathan

Reply Separator
Subject:Fix for AJP13 Connector Authentication Bug !!!
Author: "Tomcat Developers List" <[EMAIL PROTECTED]>
Date:   2/14/2002 7:39 PM


I've confirmed the fix for the AJP13 Connector / Authentication problem in
4.0.2.
This solves high priority bugs 5647 and 6219.

Please have one of the committers confirm the fix and check it in to cvs. 

The issue was reported in Bug 6219.

I tested the following modification and it seems to resolve the problem.

The problem is in org.apache.ajp.tomcat4.Ajp13Request.setAjpRequest The fix is
below:
Replace from line 115:

// String remoteUser = ajp.remoteUser().toString();
 // if(remoteUser != null)
 //   setUserPrincipal(new Ajp13Principal(remoteUser));

String remoteUser = ajp.remoteUser().toString();
if ((remoteUser != null) && (! remoteUser.equals ("")))
{
setUserPrincipal(new Ajp13Principal(remoteUser));
}
else
{
 setUserPrincipal(null);
}

After making this modification, I am able to successfully serve the protected
example url through the IIS connector and get properly challenged by the login
screen and am able to login and logout as expected.

http://localhost/examples/jsp/security/protected/index.jsp

-Jonathan


This email and any files transmitted with it are for the named person's use
only.  It may contain confidential, proprietary or legally privileged
information.  No confidentiality or privilege is waived or lost by any
mistransmission.  If you receive this message in error, please immediately
delete it and all copies of it from your system, destroy any hard copies
of it and notify the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.

This email message has been swept by a virus software product for the
presence of computer viruses.
*

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



This email and any files transmitted with it are for the named person's use
only.  It may contain confidential, proprietary or legally privileged
information.  No confidentiality or privilege is waived or lost by any
mistransmission.  If you receive this message in error, please immediately
delete it and all copies of it from your system, destroy any hard copies
of it and notify the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.

This email message has been swept by a virus software product for the
presence of computer viruses.
*

--
To unsubscribe, e-mail:   

DO NOT REPLY [Bug 6486] - Documentation error for RPM install

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Documentation error for RPM install

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Unknown |Installable Packages

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

Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Request.java

[Remy Maucherat]

> Quoting myself ( sorry )
>
> > the connector element in server.xml to that point in code,
> > and check it,
> > in case true simply dont use connector auth and do the reverse if
> > false..
>
> A last detail, to be fully backward compatible with tc3.3 ( and i think
> fully compliant with the spec ) this must default to NOT use HTTP server
> auth and only honor TC own's..

I think I get it. What's the property name I should be using (so that I
don't confuse users too much) ?

Remy


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

DO NOT REPLY [Bug 6411] - HttpSession.isNew() always returns false

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

HttpSession.isNew() always returns false

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2002-02-15 17:19 ---
Please submit a test case. I think I followed your instructions to the letter,
and couldn't reproduce the bug, so WORKSFORME is the right resolution. You
should try with 4.0.2 (bugs filed against older versions, and which have been
fixed since then will obviously be closed).

To test it, I simply modified the SessionExample, and added some traces (plus a
call to isNew, obviously), and made sue the first request the servlet got was a
POST.

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

RE: Rename jK2 to mod_jk2 ?

[GOMEZ Henri]

>> No change in CVS tree, just in source to avoid conflict 
>> between mod_jk(s) even if one is a jk_module and the
>> other jk2_module 
>> 
>> Rigth now, I'll wait for JTC developpers 'green ligth' to
>> do the changes in JTC native2 ONLY :)
>
>Green light from me. It's an excelent idea.
>
>Now a small problem - what about directives ? I don't think 
>you can have the same name in 2 modules ( I'm talking about
>httpd.conf ). 

Exact

>If we run them in parallel, it's a great pretext to use the
>new config style for native2 ( with Location, JkSet, Webapp, etc ).

+1, new JK, new config style 

>"JkSet foo bar" is equivalent with foo=bar in workers.properties.
>All jk2 settings can be done in either workers.properties or
>httpd.conf ( or both ). 
>
>The JkWebapp in a  context allows setting per webapp 
>properties,
>like 
>  JkWebapp worker ajp13
>
>JkMount is not needed in jk2 - Location is the recomended way to 
>mount ( it integrates with the native apache mapper ), and IIS-style
>urimap.properties should be the second mechanism ( if the internal
>jk mapper is used ).
>
>I think it's a good idea to use the new 'style' for jk2. When it's 
>ready, we can add back the jk1-style directives for backward 
>compatibility, but as long as jk1 is used in parallel it'll
>provide backward compat by itself.

Yep.

I'm starting looking where to apply changes :)

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

RE: Rename jK2 to mod_jk2 ?

[costinm]

On Fri, 15 Feb 2002, GOMEZ Henri wrote:

> >I agree with changing the names of non-statics in native2,
> >but need more time to think about changing dir names. There
> >are build files, cvs history, habbits that will change as well.
> 
> No change in CVS tree, just in source to avoid conflict 
> between mod_jk(s) even if one is a jk_module and the
> other jk2_module 
> 
> Rigth now, I'll wait for JTC developpers 'green ligth' to
> do the changes in JTC native2 ONLY :)

Green light from me. It's an excelent idea.

Now a small problem - what about directives ? I don't think 
you can have the same name in 2 modules ( I'm talking about
httpd.conf ). 

If we run them in parallel, it's a great pretext to use the
new config style for native2 ( with Location, JkSet, Webapp, etc ).

"JkSet foo bar" is equivalent with foo=bar in workers.properties.
All jk2 settings can be done in either workers.properties or
httpd.conf ( or both ). 

The JkWebapp in a  context allows setting per webapp properties,
like 
  JkWebapp worker ajp13

JkMount is not needed in jk2 - Location is the recomended way to 
mount ( it integrates with the native apache mapper ), and IIS-style
urimap.properties should be the second mechanism ( if the internal
jk mapper is used ).

I think it's a good idea to use the new 'style' for jk2. When it's 
ready, we can add back the jk1-style directives for backward 
compatibility, but as long as jk1 is used in parallel it'll
provide backward compat by itself.

Costin


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

DO NOT REPLY [Bug 6411] - HttpSession.isNew() always returns false

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

HttpSession.isNew() always returns false

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |
Version|4.0.2 Final |4.0.1 Final



--- Additional Comments From [EMAIL PROTECTED]  2002-02-15 16:57 ---
The Session example (nor does any other example) that I have does not call the 
isNew() method ever. I should have mentioned this before - the session 
behaviour that I get is good, except that the isNew() method always returns 
false!!

One correction - the version of Tomcat that I have is 4.0.1 that ships with 
RedHat Linux 7.2 and not 4.0.2 (sorry about that).

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

RE: Rename jK2 to mod_jk2 ?

[GOMEZ Henri]

>> What about renaming native2 (jk2) in JTC to mod_jk2
>> and jk2_module ?
>
>+1 if you talk about the binary. -0 if you talk about directory/file
>names. 

No only source/binary, without touching anything in CVS layout.

>> It will be need to rename all non static references,
>> variables functions, but I could do that, by suffixing
>> with jk2_ :
>
>If you want, you can go ahead with that ( but in time I would
>still like to continue to organize the code with fewer
>globals and more objects )

+1 for more globals 
 
>> And to be consistent, it could be nice to suffix the native,
>> original mod_jk, with jk_ 
> 
>> If you agree, I could do this quickly, but JTC developpers
>> shouldn't do updates for 1-3 hours...
>
>I agree with changing the names of non-statics in native2,
>but need more time to think about changing dir names. There
>are build files, cvs history, habbits that will change as well.

No change in CVS tree, just in source to avoid conflict 
between mod_jk(s) even if one is a jk_module and the
other jk2_module 

Rigth now, I'll wait for JTC developpers 'green ligth' to
do the changes in JTC native2 ONLY :)

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

jk2 status

[costinm]

I haven't done any commit in the last few weeks, that's because
I'm strugling with the config/autoconfig refactoring ( and I had
a lot of non-tomcat work to do ).

I think the java side is in a pretty good shape. I decided to
give up refactoring the config stuff for the first release,
so I'll check in the config interceptors from 3.3 ( and update
the 4.0 valves ), and hopefully in few weeks be ready for a
beta that can be used as a direct replacement for Ajp13Interceptor
and the ajp connector in 4.0. 

It'll just be faster, cleaner and maybe a bit easier to set
up - no new features should be expected ( even if the code
is there, the goal is to be able to replace the old java
code with something as stable ). 
We can mark the new stuff as 'experimental' for brave 
users, or just wait for the jk2.1 release.

We need to reach agreement on the jk config stuff - do
we want to keep the old setting style in server.xml
and interceptors.xml ? Are we comfortable with using 
web.xml ( with the gain of possibly using admin tools,
a well documented and familiar dtd, etc ) ? Would
it be better to use workers.properties style, and be
consistent with the C side ? All 3 ? 

For autoconf, the old code will be used, but in future
I would like to move it to a separate package. 

I strongly believe that the autoconfig should be integrated
in an admin tool - we can't require people to start
tomcat before apache ( especially in Jni mode :-), and 
it's tricky to make it work in an lb env.
Ajp14-style has similar problems ( tomcat must be running ),
and it's pretty hard to do it right for complex deployments.

So I would change this into a set of config utils, independent
of jk, maybe even use ant as a driver ( and combine it with
the deploy tool, etc). 

I would also reorganize the generator in 2 parts - one
would generate Apache/IIS/NES 'generic' config ( LoadModule,
Ports, options ). And one would generate a config 
fragment out of web.xml ( for each app ). When a new app
is deployed or a change happens, the deploy tool would
call the config module and maybe a server-speciic module
to do soft restart or on-the-fly reloading of mappings.

This keeps jk simple and adds much more flexibility. 

But it depends on your aproval and commits - as we know,
config is the biggest problem for users, and we'll need 
a lot of work here.

Costin
P.S. It's a long mail, today the train to SF is slower than
 usual :-)

 


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

Re: Java home autodiscovery add-on

[Patrick Luby]

Henri,

GOMEZ Henri wrote:

> Yes bin/setclasspath.sh does many things and could be used.
> 
> My advice it that the name is too generic and should be renamed
> when you install TC 3.x/4.x in a FHS way, ie execs in
> /usr/bin, datas in /var/tomcat4 or /usr/share/tomcat4.
> 
> May be renamed to setcatalinacp.sh ?

I must admit that have all these *.sh files hanging around in the bin directory
annoys even me even though I created them. I have been thinking about (but never
enough time to implement) getting rid of these scripts entirely and replacing
them with a small Java class that does the following:

- The standard scripts, e.g.  catalina.sh consist only of:

  Resolve true location of $0 (existing code already does this)
  Find java (almost any will do for this script)
  java -classpath `basedir "$0"` \
org.apache.catalina.launcher.Launch "${@}"

- This new "Launch" class then can parse both the command line arguments and
  a new properties file (e.g. conf/tomcat.properties) to figure out all of the
  stuff that is currently in the scripts as environment variables (e.g.
  classpath, JAVA_HOME, CATALINA_OPTS, System properties, etc. After parsing
  all the command line arguments and properties (which are currently done by
  the scripts), this "Launch" class would fork another Java process with the
  real $JAVA_HOME that the user has configured with all of the applicable
  classpath, System properties, and command line arguments.

So what advantage is there to this? Although there is no change in the
functionality of the scripts, it would solve some of the following problems:

1. Windows has many problems in its handling of environment variables such as
   %0 is always meaningful, some versions don't allow an '=' in an environment
   variable value (particularly vexing for Java programs), some versions have
   limited environment space, the 'for' command cannot handle paths with spaces
   in them, etc. Using the above method, I have made the "Launch" do the work
   that the script is doing now.

   Since Java has not problems with the above when values are put in properties
   file, a lot of these Windows problems go away. More important, we would now
   have a _platform_independent_ way to configure settings for Tomcat since
   Java properties don't require quoting or other items that are different on
   Windows and Unix (even paths can be represented in a platform independent
   manner if we so choose).

2. If implemented properly, the "Launch" class can use any Java found in your
   path to bootstrap itself (OK, I will need at least Java 1.1). I can use a
   JRE or JDK. Since "Launch.class" would invoke the real Java that I want to
   use based on a property in the "conf/tomcat" properties file, this means
   that we can bootstrap ourselves enough to:
   - Provide more meaningful error messages than we can do with shell script
 "if" and "echo" statements, particularly on Windows
   - Provide (someday) localized error messages
   - Use your Java searching algorithm for the "Find a java" part of each
 script. This will allow us to bootstrap Java without causing changes to
 which Java Tomcat actually runs with (i.e. Christopher's concern).

3. Last, but not least, make the launching of Tomcat completely independent
   of the user's environment variables. The 2 big advantages that I see are:
   - System integration is easier where environment variables are difficult
 to use (e.g. you can put an icon in the Windows
 Start->Programs menus, you can start Tomcat from /etc/inittab, you
 can make Tomcat an NT service, etc.)
   - On Windows, we can log stdout and stderr to a log file (like it already
 does on Unix) instead of printing the output to a MS-DOS window (it is
 difficult to redirect stderr in Windows batch scripts) 

Is something worth pursuing for Tomcat 4? I am willing to volunteer the effort.
Especially since it will make the Windows startup more in line with the Unix
startup. For the record, I prefer Unix (any flavor) over Windows. However, I
realize that making Tomcat work reliably on Windows is important as there are a
lot of Windows users of Tomcat out there.

> 
> Excellent information that -Djava.endorsed.dirs. Could you give us an
> example of it if for example we want to use xerces-2.0.0 and xalan-2.3.0
> with Sun JDK 1.4.0-rc1 ?
> 

In theory, with the current -Djava.endorsed.dirs setting, you could drop your
favorite xerces and xalan jars in common/endorsed (HEAD branch) or common/lib
(4.0.2 branch) and Tomcat will use those. Of course, you need to remove any
existing conflicting jars from those locations first and Tomcat may have
problems with some XML parser versions (i.e. bugs in Tomcat or the XML parser).

Patrick

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

-- 
_
Patrick Luby  E

Re: Rename jK2 to mod_jk2 ?

[costinm]

On Fri, 15 Feb 2002, GOMEZ Henri wrote:

> What about renaming native2 (jk2) in JTC to mod_jk2
> and jk2_module ?

+1 if you talk about the binary. -0 if you talk about directory/file
names. 

In mod_jk2 we already removed a lot of 'public' symbols that could
conflict if both modules are loaded. Instead of doing a mechanical
replace, I would do it gradually, and maybe finish the 'virtualization'
of jk2.

I think the effects are very good, it improves code readability and
extensibility. What I'm talking about is using JNI-style ( or
module style ), with structures and funcion pointer. 
( ok, that's kind-of OO programming in C, but OO is not that bad :-)

> It will allow us to install both modules at the same 
> times and test original mod_jk and new mod_jk.

That's a very good idea, it allows us to ship both
and have a 'backup' plan if something doesn't work.


> It will be need to rename all non static references,
> variables functions, but I could do that, by suffixing
> with jk2_ :

If you want, you can go ahead with that ( but in time I would
still like to continue to organize the code with fewer
globals and more objects )


> And to be consistent, it could be nice to suffix the native,
> original mod_jk, with jk_ 
 
> If you agree, I could do this quickly, but JTC developpers
> shouldn't do updates for 1-3 hours...

I agree with changing the names of non-statics in native2,
but need more time to think about changing dir names. There
are build files, cvs history, habbits that will change as well.


Costin


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

Re: Java home autodiscovery add-on

[Christopher K. St. John]

GOMEZ Henri wrote:
> 
> Did you take a look at my scripts ?
> 

 I thought I did, although I concentrated on the proposed
changes to catalina.sh.


> This config stuff came from discution on this this list with
> Keith Irwin and Nicolas Mailhot :)
> 

 It looks like I missed some background discussion, but the
tomcat-dev archives at metronet appear to be out of date,
and google didn't turn up anything. If this has all been
gone over in detail before, then a pointer to a copy of the
thread in the archives would probably shut me up.

 I was assuming:

 - An rpm installation would set up a series of scripts in
   the appropriate LSB-compliant directories. One of those
   scripts would be tomcat4. A user wanting to start Catalina
   would run tomcat4 (or put it in their rc directories to be
   started automatically) 

 - A non-rpm installation would still be started by running
   bin/catalina.sh, just like before. This would be typical
   of a developer just getting started with Tomcat.


> So experienced and beginner will JUST have to :
> 
> - Comment JAVA_HOME="/opt/IBMJava2-13" in config file
>   for auto-exploration
> 
> - Set JAVA_HOME in config file to specify WHICH JVM they
>   want to be used with Tomcat3 (and since TC 4 use another
>   config file, it could be used at the same time with the
>   same or a different JVM).
> 

 But that's only if you're running using a full-on RPM based
installation?

 I doesn't really matter, though. My objection is based on
the "principle of least suprise", which in this case means
that an installation that works should not suddenly stop
working because of an unrelated change to another part of
the system.

 If the answer is "it's unwise to run with auto-discovery
turned on", then why have it at all? Systems that need to
run totally without configuration (from a cdrom?) would
presumably need custom configuration scripts in any case.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

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

RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Request.java

[Ignacio J. Ortega]

Quoting myself ( sorry )

> the connector element in server.xml to that point in code, 
> and check it,
> in case true simply dont use connector auth and do the reverse if
> false..

A last detail, to be fully backward compatible with tc3.3 ( and i think
fully compliant with the spec ) this must default to NOT use HTTP server
auth and only honor TC own's..

Saludos ,
Ignacio J. Ortega


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

[RPMANN] Tomcat 3.3.1-b1/4.0.2 updated & connectors created

[GOMEZ Henri]

Hi,

A quick note to say that the Tomcat 3.3.1-b1 
and Tomcat 4.0.2 have been upgraded to RPM release 2

TC 3.3.1-B1

http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.3.1-b1/rpms/

TC 4.0.2 + CONNECTORS

http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.2/rpms/


The newly created tomcat-connectors rpm cover today :

mod_jk  for Apache 1.3 (1.3.22/mod_ssl 2.8.5)
mod_jk  for Apache 2.0 (2.0.28beta)
mod_jk2 for Apache 2.0 (2.0.28beta) (new mod_jk version)

Still no luck with mod_webapp due to problems with APR.

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

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

RE: Java home autodiscovery add-on

[GOMEZ Henri]

Christopher,

Did you take a look at my scripts ?

tomcat3 starter :

#!/bin/sh
#
# Wrapper script for Tomcat, to be sure it will allways
# be run with correct user profile (tomcat by default)
#
# derived from stuff in tomcat.init
#
# Gomez Henri <[EMAIL PROTECTED]>
# Keith Irwin <[EMAIL PROTECTED]>
# Nicolas Mailhot <[EMAIL PROTECTED]>
#

# Get Tomcat config

TOMCAT_CFG="/etc/tomcat3/conf/tomcat3.conf"

[ -r "$TOMCAT_CFG" ] && . "${TOMCAT_CFG}"

# Path to the tomcat launch script
TOMCAT_SCRIPT=/usr/bin/dtomcat3

..

I exec config file if it exist (/etc/tomcat3/conf/tomcat3.conf)
which is turn set the env vars :

tomcat3.conf file 

# tomcat /etc/rc.d script example configuration file
# Use with version 1.07 of the scripts or later

# Where your java installation lives
# JAVA_HOME=/usr/java/jdk
JAVA_HOME="/opt/IBMJava2-13"

# You can pass some parameters to java
# here if you wish to
#JAVACMD="$JAVA_HOME/bin/java -Xminf0.1 -Xmaxf0.3"

# Where your tomcat installation lives
# That change from previous RPM where TOMCAT_HOME 
# used to be /var/tomcat.
# Now /var/tomcat will be the base for webapps only
TOMCAT_HOME="/etc/tomcat3"

# Where our webapps/libs are now installed.
TOMCAT_INSTALL="/var/tomcat3"

# What user should run tomcat
TOMCAT_USER="tomcat3"

# You can change your tomcat locale here
#LANG=en_US

# If you wish to further customize your tomcat environment,
# put your own definitions here
# (i.e. LD_LIBRARY_PATH for some jdbc drivers)
# Just do not forget to export them :)

So experienced and beginner will JUST have to :

- Comment JAVA_HOME="/opt/IBMJava2-13" in config file
  for auto-exploration

- Set JAVA_HOME in config file to specify WHICH JVM they 
  want to be used with Tomcat3 (and since TC 4 use another
  config file, it could be used at the same time with the
  same or a different JVM).

Best of both worlds

This config stuff came from discution on this this list with
Keith Irwin and Nicolas Mailhot :)






-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

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

RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Request.java

[Ignacio J. Ortega]

> De: Remy Maucherat [mailto:[EMAIL PROTECTED]]
> Enviado el: viernes 15 de febrero de 2002 2:53


> I don't quite understand, as the patch only add filtering out an empty
> string, right ?
> Or did I miss something ?
> 

Well the problem is that under a connector ( at least under jk+ajp ) you
need to configure the passing of HTTP server auth info to tc or not,
with the patch supplied by Jonathan Pierce ( althought it works in most
cases ) , you lose this control, it's difficult to assure if a newly
installed TC under jk will have auth working or not, and which one will
be used ( the HTTP server or TC ).

You can have varying behaviours on TC dependending on external configs.

1) if you doesnt care about the HTTPServer auth nor you have cofingured
in you own, tc auth will be used.

2) If you have HTTPServer auth working but it's not configured in a way
compatible with tc ( Same users in TC and HTTPServer) , you will have
failing examples in tc, ever.

3) 


and so on..


> In any case, I just applied the patch as it looked ok to me. 
> If the patch is
> bad, revert it.
> 

It's not bad at all, but makes tc auth under a connector unpredictable..

Sorry for having only words, but i dont have the time to dig in the
jtc-ajp-4.0 code right now, but is simply a matter of pass an attribute
( "tomcatAuthentication" to be backwards compatible with tc3.3 ) used in
the connector element in server.xml to that point in code, and check it,
in case true simply dont use connector auth and do the reverse if
false..

> Remy
> 
> 


Saludos ,
Ignacio J. Ortega


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

RE: Java home autodiscovery add-on

[GOMEZ Henri]

>In Tomcat 4.0.2 and later, the above code would, I believe, 
>fit into the
>bin/setclasspath.sh script. This script, which already checks that your
>$JAVA_HOME contains a java, javac, and jdb command, would extend that
>functionality. BTW, setclasspath.sh is source by all the 
>executable Unix scripts
>(e.g. catalina.sh, jasper.sh, etc.).

Yes bin/setclasspath.sh does many things and could be used.

My advice it that the name is too generic and should be renamed 
when you install TC 3.x/4.x in a FHS way, ie execs in
/usr/bin, datas in /var/tomcat4 or /usr/share/tomcat4.

May be renamed to setcatalinacp.sh ?


>Something that the Tomcat 3.3 developers may want to take a look at in
>setclasspath.sh is the setting of $JAVA_ENDORSED_DIRS 
>environment variable. This
>variable is used to construct a "-Djava.endorsed.dirs=" 
>argument when
>invoking Java in each of teh executable Unix scripts (Windows 
>does the same in
>setclasspath.bat). This property provides the ability for 
>Tomcat to override the
>default parser and other special classes that are bundled with 
>JDK 1.4 with the
>classes that are bundled with Tomcat. This eliminates the need 
>for users to need
>to copy jar files into their JDK's lib/endorsed directory 
>(which would affect
>all other Java applications).

Excellent information that -Djava.endorsed.dirs. Could you give us an
example of it if for example we want to use xerces-2.0.0 and xalan-2.3.0
with Sun JDK 1.4.0-rc1 ?

>> # If you wish to further customize your tomcat environment,
>> # put your own definitions here
>> # (i.e. LD_LIBRARY_PATH for some jdbc drivers)
>> # Just do not forget to export them :)
>>
>
>Many may not know this, but the above configuration file 
>already exists in
>Tomcat 4.0.2 and later. The configuration files are:
>
>   Windows:  bin/setenv.bat
>   Unix: bin/setenv.sh
>
>These files, by default, do not exist. However, if the user 
>creates the above
>file, they can override any environment variables that they like.

Ditto this file should be renamed (see upper) to maybe setcatalinaenv.sh ?

>Something that the Tomcat 3.3 developers may want to take a 
>look at is that each
>Unix script in Tomcat 4.0.2 and later now resolves 
>CATALINA_HOME independently
>of the user's environment. This even works if the user invokes 
>a softlink to the
>script (pretty handy if you want to put a softlink to 
>startup.sh and shutdown.sh
>in /usr/bin on your system). This, and putting "JAVA_HOME=path>" in the
>setenv.sh file, allows you to run Tomcat 4.0.2 or later from 
>an /etc/rc.d or
>/etc/inittab entry.

In my RPM, I use another way for both TC 3.3/4.0.2 by using
the config file which is more in spirit of Apache httpd.conf ;)

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

Re: Java home autodiscovery add-on

[Christopher K. St. John]

GOMEZ Henri wrote:
> 
> >> What about adding this part in tomcat.sh (TC 3.3) and
> >> catalina.sh/jasper.sh to help them discover JAVA_HOME on
> >> at least Linux systems ?
> >
> > If someone forgets to set JAVA_HOME and has multiple JDK's
> >installed, they could get a suprise. 
>
> That's why you could still tune the JAVA_HOME is tomcat_cfg
> which is read at start of script (not shown here).
> 

 You're presumably trying to reduce configuration problems
for beginners, but trying to find JAVA_HOME automatically
is likely to increase overall confusion.

 Current situation: beginner (or forgetful expert) doesn't
have JAVA_HOME set, trys to start catalina, gets an error
message, sets JAVA_HOME, everything is fine.

 New situation: beginner (or forgetful expert) doesn't 
have JAVA_HOME set, trys to start catalina, and catalina
starts. Either:

  1) You got lucky, the script found the right JDK, 
  the code runs for the moment, and the user thinks
  everything is ok. Until they install another JDK and
  suddenly catalina stops working. The user is confused.

  2) You don't get lucky, the script finds and silently
  runs with the wrong JDK, and the user is confused.

 As I said, I ran into this problem with a ./configure
script that was too smart for its own good. It caused
more problems than it fixed.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

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

RE: Java home autodiscovery add-on

[GOMEZ Henri]

>> What about adding this part in tomcat.sh (TC 3.3) and
>> catalina.sh/jasper.sh to help them discover JAVA_HOME on
>> at least Linux systems ?
>> 
>
> If someone forgets to set JAVA_HOME and has multiple JDK's
>installed, they could get a suprise. I suspect most non-beginners
>would rather see an error message than be suprised. I ran into
>this problem with a configure script that tried to be too smart
>about finding a JDK to use.

That's why you could still tune the JAVA_HOME is tomcat_cfg
which is read at start of script (not shown here).

Here is the CURRENT tomcat3, tomcat4, jasper4 shells
used in my RPMs together with the corresponding conf file 






jasper4
Description: jasper4


tomcat3
Description: tomcat3


tomcat4
Description: tomcat4


tomcat3.conf
Description: tomcat3.conf


tomcat4.conf
Description: tomcat4.conf

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

Re: Java home autodiscovery add-on

[Patrick Luby]

Henri,

GOMEZ Henri wrote:
> 
> What about adding this part in tomcat.sh (TC 3.3) and
> catalina.sh/jasper.sh to help them discover JAVA_HOME on
> at least Linux systems ?
> 
> +if [ -z "$JAVA_HOME" ]; then
> +# Search for java in PATH
> +JAVA=`which java`
> +if [ -z "$JAVA" ] ; then
> +JAVA_BINDIR=`dirname ${JAVA}`
> +JAVA_HOME="${JAVA_BINDIR}/.."
> +fi
> +# Default clean JAVA_HOME
> +[ -z "$JAVA_HOME"  -a -d "/usr/lib/java" ] &&  JAVA_HOME="/usr/lib/java"
> +# Default IBM JAVA_HOME
> +[ -z "$JAVA_HOME"  -a -d "/opt/IBMJava2-13" ] &&  JAVA_HOME="/opt/IBMJava2-13"
> +# Another solution
> +[ -z "$JAVA_HOME"  -a -d "/usr/java/jdk" ] &&  JAVA_HOME="/usr/java/jdk"
> +# madeinlinux JAVA_HOME
> +[ -z "$JAVA_HOME" -a -d "/usr/local/jdk1.2.2" ] && 
>JAVA_HOME="/usr/local/jdk1.2.2"
> +# Kondara JAVA_HOME
> +[ -z "$JAVA_HOME"  -a -d "/usr/lib/java/jdk1.2.2" ] && 
>JAVA_HOME="/usr/lib/java/jdk1.2.2"
> +# Other commonly found JAVA_HOMEs
> +[ -z "$JAVA_HOME"  -a -d "/usr/jdk1.2" ] && JAVA_HOME="/usr/jdk1.2"
> +# Default Caldera JAVA_HOME
> +[ -z "$JAVA_HOME"  -a -d "/opt/java-1.3" ] && JAVA_HOME="/opt/java-1.3"
> +# Add other locations here
> +if [ -z "$JAVA_HOME" ]; then
> +echo "No JAVA_HOME specified in ${TOMCAT_CFG} and no java found, exiting..."
> +exit 1
> +  fi
>

In Tomcat 4.0.2 and later, the above code would, I believe, fit into the
bin/setclasspath.sh script. This script, which already checks that your
$JAVA_HOME contains a java, javac, and jdb command, would extend that
functionality. BTW, setclasspath.sh is source by all the executable Unix scripts
(e.g. catalina.sh, jasper.sh, etc.).

Something that the Tomcat 3.3 developers may want to take a look at in
setclasspath.sh is the setting of $JAVA_ENDORSED_DIRS environment variable. This
variable is used to construct a "-Djava.endorsed.dirs=" argument when
invoking Java in each of teh executable Unix scripts (Windows does the same in
setclasspath.bat). This property provides the ability for Tomcat to override the
default parser and other special classes that are bundled with JDK 1.4 with the
classes that are bundled with Tomcat. This eliminates the need for users to need
to copy jar files into their JDK's lib/endorsed directory (which would affect
all other Java applications).
 
> 
> => TC 4.0.2 conf :
> 
> # tomcat /etc/rc.d script example configuration file
> # Use with version 1.07 of the scripts or later
> 
> # Where your java installation lives
> # JAVA_HOME=/usr/java/jdk
> JAVA_HOME="/opt/IBMJava2-13"
> 
> # You can pass some parameters to java
> # here if you wish to
> #JAVACMD="$JAVA_HOME/bin/java -Xminf0.1 -Xmaxf0.3"
> 
> # Where your tomcat installation lives
> # That change from previous RPM where TOMCAT_HOME
> # used to be /var/tomcat.
> # Now /var/tomcat will be the base for webapps only
> CATALINA_HOME="@@@TCHOME@@@"
> JASPER_HOME="@@@TCHOME@@@"
> CATALINA_TMPDIR="@@@TCHOME@@@/temp"
> 
> # What user should run tomcat
> TOMCAT_USER="tomcat4"
> 
> # You can change your tomcat locale here
> #LANG=en_US
> 
> # If you wish to further customize your tomcat environment,
> # put your own definitions here
> # (i.e. LD_LIBRARY_PATH for some jdbc drivers)
> # Just do not forget to export them :)
>

Many may not know this, but the above configuration file already exists in
Tomcat 4.0.2 and later. The configuration files are:

   Windows:  bin/setenv.bat
   Unix: bin/setenv.sh

These files, by default, do not exist. However, if the user creates the above
file, they can override any environment variables that they like.

Something that the Tomcat 3.3 developers may want to take a look at is that each
Unix script in Tomcat 4.0.2 and later now resolves CATALINA_HOME independently
of the user's environment. This even works if the user invokes a softlink to the
script (pretty handy if you want to put a softlink to startup.sh and shutdown.sh
in /usr/bin on your system). This, and putting "JAVA_HOME=" in the
setenv.sh file, allows you to run Tomcat 4.0.2 or later from an /etc/rc.d or
/etc/inittab entry.

I have found a way to do this on Windows NT, 2000, and XP, but I have not had
enough time to refine it enough so that it won't break Windows 95, 98, and ME.

Patrick

-- 
_
Patrick Luby  Email: [EMAIL PROTECTED]
Sun Microsystems  Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_

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

RE: jakarta-tomcat-connectors

[GOMEZ Henri]

>-Original Message-
>From: Jarecsni János [mailto:[EMAIL PROTECTED]]
>Sent: Friday, February 15, 2002 4:02 PM
>To: Tomcat-Dev
>Subject: jakarta-tomcat-connectors
>
>
>Hi,
>
>I'd like to build TC40x. Where can I download 
>jakarata-tomcat-connectors?
>The building.txt says one should download it.


You should go to :

http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.2/src/


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

jakarta-tomcat-connectors

[Jarecsni János]

Hi,

I'd like to build TC40x. Where can I download jakarata-tomcat-connectors?
The building.txt says one should download it.

Thanks
János

--
Jarecsni, János
MORGAN HILL CONSULTING, Internet Applications Unit
mailto:[EMAIL PROTECTED]
http://morganhillconsulting.hu/ :: Phone+Fax: + 36 1 484 0392


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

RE: Rename jK2 to mod_jk2 ?

[GOMEZ Henri]

>If we consider native2 as a remplacement for the native of 
>mod_jk, no. That is
>just a new version.
>If you thing of easy testing may be... I have libjk.so from 
>native and mod_jk.so
>from native2 and I stop/start Apache for testing both.

The idea is that native2 will replace more or less quickly
the good old mod_jk and it will be better (IMO) to start 
called mod_jk with a new name, maybe mod_jk2.

And some people may want to test BOTH at the same time,
so the need to rename :

mod_jk.so to mod_jk2.so
mod_jk.c  to mod_jk2.c
jk_module to jk2_module
and the jk2_ prefix to avoid problems with non-static refs.

Also it will help us do stuff like :


...



...


This dual config could help us determine problems by having
one virtual server test against a Tomcat using mod_jk/ajp13
and another virtual testing against the same Tomcat using
mod_jk2/ajp13-ajp14

PS: Yes the commit will be important

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

Re: Retry: PureTLS/Cryptix RPM at Apache ????

[Eric Rescorla]

jean-frederic clere <[EMAIL PROTECTED]> writes:
> > Starting from Tomcat 3.3.1-B1 we could use this stuff
> > to have a 100% OSS Java SSL solution and good alternative
> > to JSSE
> 
> Next step Tomcat 4.0.3?
Yes, I think so. I've been pretty swamped so I haven't had
time to move the 3.3. patches over to 4.0. If someone else
wants to do it, I'll be happy to advise. Otherwise I'll shoot
for sometime in March.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/

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

Re: Retry: PureTLS/Cryptix RPM at Apache ????

[Eric Rescorla]

Nick Betteridge <[EMAIL PROTECTED]> writes:
> JXTA holds puretls and cryptix jars on jxta.org - so it shouldn't be a
> problem on jakarta.
> 
> Incidently, tls is not ssl, although there are many similarities.
TLS is not SSL, but pretty much every implementation that supports
both (most do) uses the same abstraction for both with a control
flag to indicate which ones to support.

> Just one question - are tls socket factories available for tomcat?
Yes. The PureTLS and JSSE socket factories support SSLv3 and TLS.

-Ekr


-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/

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

Re: Java home autodiscovery add-on

[Christopher K. St. John]

GOMEZ Henri wrote:
> 
> What about adding this part in tomcat.sh (TC 3.3) and
> catalina.sh/jasper.sh to help them discover JAVA_HOME on
> at least Linux systems ?
> 

 If someone forgets to set JAVA_HOME and has multiple JDK's
installed, they could get a suprise. I suspect most non-beginners
would rather see an error message than be suprised. I ran into
this problem with a configure script that tried to be too smart
about finding a JDK to use.

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

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

DO NOT REPLY [Bug 6488] - Error: 304. Apparent bug in default ErrorHandler code.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Error: 304. Apparent bug in default ErrorHandler code.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED



--- Additional Comments From [EMAIL PROTECTED]  2002-02-15 13:45 ---
I just checked, this bug indeed does not appear in 3.3.1-b1. Thanks.

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

setting the path in the session cookie (Tomcat 402b)

[Jarecsni János]

Hi,

I've found the code segment in question:

[share]org.apache.catalina.connector.HttpResponseBase line 642 and
following:

// Add the session ID cookie if necessary
HttpServletRequest hreq = (HttpServletRequest) request.getRequest();
HttpSession session = hreq.getSession(false);

if ((session != null) && session.isNew() && (getContext() != null)
&& getContext().getCookies()) {
Cookie cookie = new Cookie(Globals.SESSION_COOKIE_NAME,
   session.getId());
cookie.setMaxAge(-1);
String contextPath = null;
if (context != null)
contextPath = context.getPath();
if ((contextPath != null) && (contextPath.length() > 0))
cookie.setPath(contextPath);
else
cookie.setPath("/");
if (hreq.isSecure())
cookie.setSecure(true);
addCookie(cookie);
}

I'll try to patch it... :) How to do it canonically?
BTW.: I downloaded the source and tried to build it with ant (ant deploy in
the catalina dir) but build failed with some silly error message complaining
about a file. Tracking down the problem it turned out that some environment
variables are unset (required libraries, etc.).

Is there a short intro describing how to set up the development environment?

TIA!


János

--
Jarecsni, János
MORGAN HILL CONSULTING, Internet Applications Unit
mailto:[EMAIL PROTECTED]
http://morganhillconsulting.hu/ :: Phone+Fax: + 36 1 484 0392

|-Original Message-
|From: Jarecsni János [mailto:[EMAIL PROTECTED]]
|Sent: Friday, February 15, 2002 1:57 PM
|To: Tomcat Developers List
|Subject: RE: setting the path in the session cookie (Tomcat 402b)
|
|
|Hi, Jean-Frederic,
|
|one more addition:
|
|This works fine:
|
|   RewriteRule ^/istore/something(.*) http://mydomain/istore$1 [P]
|
|Cookies work to (because the "/istore" will be present in both the
|original and the proxied url). You can then use:
|http://mydomain/istore/something/aServlet (which eventually will
|end at http://mydomain/istore/aServlet
|
|
|I want this to work:
|
|RewriteRule !^/istore(.*) - [C]
|RewriteRule (.*) http://mydomain/istore$1 [P]
|
|So any URL not containing the "/istore" prefix should be rewritten
|by prepending "/istore". Then you can use URLs like:
|http://mydomain/anything. This is what you normally do with
|Apache-served sites. I don't want to see no application context in
|my urls basically.
|
|Hope you get what I try to express!
|
|Cheers,
|János (=Jean in Hungarian :)
|
|--
|Jarecsni, János
|MORGAN HILL CONSULTING, Internet Applications Unit
|mailto:[EMAIL PROTECTED]
|http://morganhillconsulting.hu/ :: Phone+Fax: + 36 1 484 0392
|
||-Original Message-
||From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
||Behalf Of jean-frederic clere
||Sent: Friday, February 15, 2002 12:51 PM
||To: Tomcat Developers List
||Subject: Re: setting the path in the session cookie (Tomcat 402b)
||
||
||Jarecsni János wrote:
||>
||> Hi,
||>
||> well a short explanation follows then.
||>
||> Since we want to alias our dynamic resources (which are to be served by
||> Tomcat+JBoss) in Apache we have to use mod_rewrite and mod_proxy.
||
||Why are you not using mod_jk or mod_webapp?
||
||> We need
||> the proxy because the rewritten urls don't get sent to tomcat,
||Apache treats
||> them as files. If we proxy those rewritten urls back to the same virtual
||> host, they get sent to tomcat.
||>
||> The only problem is that the webcontext is hardwired in the
||session cookie
||> by Tomcat. And since the webcontext must be rewritten for the
||whole thing to
||> work too, session cookies don't work anymore (the client doesn't
||send them
||> back because of the different path).
||>
||> The Sun RI sets the session cookie path to "/". That would work in our
||> situation too.
||>
||> Can I hope some sort of a remedy of this problem in a short
|time, what do
||> you think?
||>
||> Cheers & thanks.
||> János
||>
||> --
||> Jarecsni, János
||> MORGAN HILL CONSULTING, Internet Applications Unit
||> mailto:[EMAIL PROTECTED]
||> http://morganhillconsulting.hu/ :: Phone+Fax: + 36 1 484 0392
||>
||> |-Original Message-
||> |From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
||> |Behalf Of jean-frederic clere
||> |Sent: Friday, February 15, 2002 12:16 PM
||> |To: Tomcat Developers List
||> |Subject: Re: setting the path in the session cookie (Tomcat 402b)
||> |
||> |
||> |Jarecsni János wrote:
||> |>
||> |> Hi,
||> |>
||> |> it seems that tomcat uses the "/contextname" path when creating
||> |the cookie
||> |> for the JSESSIONID. Since we use Apache in front of Tomcat and we use
||> |> mod_rewrite with mod_proxy to provide aliasing of dynamic Java
||> |resources, it
||> |> is not working for us.
||> |
||> |You should explain a little more why you have to that (like you
||> |have done it in
||> |httpd-dev list).
||> |
||> |>
|

DO NOT REPLY [Bug 6488] - Error: 304. Apparent bug in default ErrorHandler code.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Error: 304. Apparent bug in default ErrorHandler code.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-02-15 13:22 ---
Please give Tomcat 3.3.1 Beta 1 a try.  I believe it contains a fix for this.

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

DO NOT REPLY [Bug 6488] New: - Error: 304. Apparent bug in default ErrorHandler code.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Error: 304. Apparent bug in default ErrorHandler code.

   Summary: Error: 304. Apparent bug in default ErrorHandler code.
   Product: Tomcat 3
   Version: 3.3 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Servlet
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I just stumbled upon a show-stopper problem with Tomcat 3.3a and Apache
mod_jk. When refreshing JSPs that referenced static resources (i.e. a CSS
stylesheet or images), from time to time junk would appear at the top
of the page, saying "Error: 304... Location: ". The said
static resources would not load and the browser would appear to hang
indefinitely.

I tracked the problem to the method StatusHandler.doService
defined in share/org/apache/tomcat/modules/generators/ErrorHandler.java
When the 304 (Not Modified) condition is encountered, this method 
generates a message body with the above mentioned "junk" and returns
it to mod_jk.

RFC 2068 states:

   "If the client has performed a conditional GET request and access is
   allowed, but the document has not been modified, the server SHOULD
   respond with this status code. The response MUST NOT contain a
   message-body."

Replacing Tomcat's vanilla ErrorHandler with my own clone with the
whole message body generating block omitted if sc == 304 eliminated
the problem.

Interestingly, the bug could only be demonstrated with mod_jk + Tomcat,
but not when I was using Tomcat alone as a web server.

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

RE: setting the path in the session cookie (Tomcat 402b)

[Jarecsni János]

Hi, Jean-Frederic,

one more addition:

This works fine:

RewriteRule ^/istore/something(.*) http://mydomain/istore$1 [P]

Cookies work to (because the "/istore" will be present in both the original
and the proxied url). You can then use:
http://mydomain/istore/something/aServlet (which eventually will end at
http://mydomain/istore/aServlet


I want this to work:

RewriteRule !^/istore(.*) - [C]
RewriteRule (.*) http://mydomain/istore$1 [P]

So any URL not containing the "/istore" prefix should be rewritten by
prepending "/istore". Then you can use URLs like: http://mydomain/anything.
This is what you normally do with Apache-served sites. I don't want to see
no application context in my urls basically.

Hope you get what I try to express!

Cheers,
János (=Jean in Hungarian :)

--
Jarecsni, János
MORGAN HILL CONSULTING, Internet Applications Unit
mailto:[EMAIL PROTECTED]
http://morganhillconsulting.hu/ :: Phone+Fax: + 36 1 484 0392

|-Original Message-
|From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
|Behalf Of jean-frederic clere
|Sent: Friday, February 15, 2002 12:51 PM
|To: Tomcat Developers List
|Subject: Re: setting the path in the session cookie (Tomcat 402b)
|
|
|Jarecsni János wrote:
|>
|> Hi,
|>
|> well a short explanation follows then.
|>
|> Since we want to alias our dynamic resources (which are to be served by
|> Tomcat+JBoss) in Apache we have to use mod_rewrite and mod_proxy.
|
|Why are you not using mod_jk or mod_webapp?
|
|> We need
|> the proxy because the rewritten urls don't get sent to tomcat,
|Apache treats
|> them as files. If we proxy those rewritten urls back to the same virtual
|> host, they get sent to tomcat.
|>
|> The only problem is that the webcontext is hardwired in the
|session cookie
|> by Tomcat. And since the webcontext must be rewritten for the
|whole thing to
|> work too, session cookies don't work anymore (the client doesn't
|send them
|> back because of the different path).
|>
|> The Sun RI sets the session cookie path to "/". That would work in our
|> situation too.
|>
|> Can I hope some sort of a remedy of this problem in a short time, what do
|> you think?
|>
|> Cheers & thanks.
|> János
|>
|> --
|> Jarecsni, János
|> MORGAN HILL CONSULTING, Internet Applications Unit
|> mailto:[EMAIL PROTECTED]
|> http://morganhillconsulting.hu/ :: Phone+Fax: + 36 1 484 0392
|>
|> |-Original Message-
|> |From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
|> |Behalf Of jean-frederic clere
|> |Sent: Friday, February 15, 2002 12:16 PM
|> |To: Tomcat Developers List
|> |Subject: Re: setting the path in the session cookie (Tomcat 402b)
|> |
|> |
|> |Jarecsni János wrote:
|> |>
|> |> Hi,
|> |>
|> |> it seems that tomcat uses the "/contextname" path when creating
|> |the cookie
|> |> for the JSESSIONID. Since we use Apache in front of Tomcat and we use
|> |> mod_rewrite with mod_proxy to provide aliasing of dynamic Java
|> |resources, it
|> |> is not working for us.
|> |
|> |You should explain a little more why you have to that (like you
|> |have done it in
|> |httpd-dev list).
|> |
|> |>
|> |> We would like to be able to configure this path.
|> |>
|> |> Thanks in advance
|> |> János
|> |>
|> |> --
|> |> Jarecsni, János
|> |> MORGAN HILL CONSULTING, Internet Applications Unit
|> |> mailto:[EMAIL PROTECTED]
|> |> http://morganhillconsulting.hu/ :: Phone+Fax: + 36 1 484 0392
|> |>
|> |> --
|> |> To unsubscribe, e-mail:
|> |
|> |> For
|> |additional commands, e-mail: 
|> |
|> |--
|> |To unsubscribe, e-mail:
|> |
|> |For additional
|> |commands, e-mail: 
|> |
|> |
|>
|> --
|> To unsubscribe, e-mail:
|
|> For
|additional commands, e-mail: 
|
|--
|To unsubscribe, e-mail:
|
|For additional
|commands, e-mail: 
|
|


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

DO NOT REPLY [Bug 6487] New: - tarball jakarta-tomcat-connectors-4.0.2-01-src.tar.gz problem

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

tarball jakarta-tomcat-connectors-4.0.2-01-src.tar.gz problem

   Summary: tarball jakarta-tomcat-connectors-4.0.2-01-src.tar.gz
problem
   Product: Tomcat 4
   Version: 4.0.2 Final
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapp Connector
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


mod_webapp build failed because chmod a+x webapp/support/install.sh is not
executable.
Work-around:
chmod a+x webapp/support/install.sh

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

RE: setting the path in the session cookie (Tomcat 402b)

[Jarecsni János]

Hi Jean-Frederic,

I definitely use it! :) I use mod_jk. I have the appropriate JkMount
settings included in httpd.conf. Everything works fine. It is the _aliasing_
that cannot be done.

so I can do
http://apache.virtual.host/jbossapplicationcontext/something?someparameter

what I cannot do is:

http://apache.virtual.host/somethingelse

As I've told before, rewriting works fine in Apache, except that a rewritten
request does not get passed to Tomcat (no matter mod_jk is there and
working). That's why I use another round: I proxy the request (the rewritten
one) to the same vhost again. And as you expect it, it finally gets to
tomcat. Is that clear?

The only problem now is the session cookie. Tomcat hardwires the app
context. And that's what doesn't work with proxying. So: I need to be able
to define what path to set the session cookie to.

That's all there is to it :)

Cheers,
János


--
Jarecsni, János
MORGAN HILL CONSULTING, Internet Applications Unit
mailto:[EMAIL PROTECTED]
http://morganhillconsulting.hu/ :: Phone+Fax: + 36 1 484 0392

|
|Why are you not using mod_jk or mod_webapp?
|


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

DO NOT REPLY [Bug 6486] New: - Documentation error for RPM install

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Documentation error for RPM install

   Summary: Documentation error for RPM install
   Product: Tomcat 4
   Version: 4.0.2 Final
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Major
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If you install tomcat4-4.0.2-1.noarch.rpm, the instructions in the
RUNNING.TXT file are incorrect (startup.sh does not exist). It needs
to reference the created /etc/rc.d/rc*.d/S80tomcat4 script (which
doesn't appear to work anyway, but that's another problem).

///Peter

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

DO NOT REPLY [Bug 6485] New: - m4 prints error message when configuring mod_webapp

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

m4 prints error message when configuring mod_webapp

   Summary: m4 prints error message when configuring mod_webapp
   Product: Tomcat 4
   Version: 4.0.2 Final
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Webapp Connector
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


-- Running the "buildconf" script for APR
buildconf: checking installation...
buildconf: autoconf version 2.52 (ok)
buildconf: libtool version 1.4.2 (ok)
Copying libtool helper files ...
Creating include/arch/unix/apr_private.h.in ...
Creating configure ...
--- Creating WebApp "configure" script
Creating configure ...
/usr/bin/m4: configure.in: 142: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 307: Non-numeric argument to built-in `divert'
--- All done
aplocal.m4 use internal unsupported autoconf AC_DIVERT_PUSH macro.
you should ignore these error messages

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

Re: Retry: PureTLS/Cryptix RPM at Apache ????

[Nick Betteridge]

GOMEZ Henri wrote:
> 
> >JXTA holds puretls and cryptix jars on jxta.org - so it shouldn't be a
> >problem on jakarta.
> >
> >Incidently, tls is not ssl, although there are many similarities.
> >
> >Just one question - are tls socket factories available for tomcat?
> 
> You means TLSSocket instead of SSLSocket ?

Uhm  sounds like it! - I'm familiar with Catalina but not any of the
3.x code. It would be nice to have it in 4.x

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

RE: Retry: PureTLS/Cryptix RPM at Apache ????

[GOMEZ Henri]

>JXTA holds puretls and cryptix jars on jxta.org - so it shouldn't be a
>problem on jakarta.
>
>Incidently, tls is not ssl, although there are many similarities.
>
>Just one question - are tls socket factories available for tomcat?

You means TLSSocket instead of SSLSocket ?

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

Re: setting the path in the session cookie (Tomcat 402b)

[jean-frederic clere]

Jarecsni János wrote:
> 
> Hi,
> 
> well a short explanation follows then.
> 
> Since we want to alias our dynamic resources (which are to be served by
> Tomcat+JBoss) in Apache we have to use mod_rewrite and mod_proxy.

Why are you not using mod_jk or mod_webapp?

> We need
> the proxy because the rewritten urls don't get sent to tomcat, Apache treats
> them as files. If we proxy those rewritten urls back to the same virtual
> host, they get sent to tomcat.
> 
> The only problem is that the webcontext is hardwired in the session cookie
> by Tomcat. And since the webcontext must be rewritten for the whole thing to
> work too, session cookies don't work anymore (the client doesn't send them
> back because of the different path).
> 
> The Sun RI sets the session cookie path to "/". That would work in our
> situation too.
> 
> Can I hope some sort of a remedy of this problem in a short time, what do
> you think?
> 
> Cheers & thanks.
> János
> 
> --
> Jarecsni, János
> MORGAN HILL CONSULTING, Internet Applications Unit
> mailto:[EMAIL PROTECTED]
> http://morganhillconsulting.hu/ :: Phone+Fax: + 36 1 484 0392
> 
> |-Original Message-
> |From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> |Behalf Of jean-frederic clere
> |Sent: Friday, February 15, 2002 12:16 PM
> |To: Tomcat Developers List
> |Subject: Re: setting the path in the session cookie (Tomcat 402b)
> |
> |
> |Jarecsni János wrote:
> |>
> |> Hi,
> |>
> |> it seems that tomcat uses the "/contextname" path when creating
> |the cookie
> |> for the JSESSIONID. Since we use Apache in front of Tomcat and we use
> |> mod_rewrite with mod_proxy to provide aliasing of dynamic Java
> |resources, it
> |> is not working for us.
> |
> |You should explain a little more why you have to that (like you
> |have done it in
> |httpd-dev list).
> |
> |>
> |> We would like to be able to configure this path.
> |>
> |> Thanks in advance
> |> János
> |>
> |> --
> |> Jarecsni, János
> |> MORGAN HILL CONSULTING, Internet Applications Unit
> |> mailto:[EMAIL PROTECTED]
> |> http://morganhillconsulting.hu/ :: Phone+Fax: + 36 1 484 0392
> |>
> |> --
> |> To unsubscribe, e-mail:
> |
> |> For
> |additional commands, e-mail: 
> |
> |--
> |To unsubscribe, e-mail:
> |
> |For additional
> |commands, e-mail: 
> |
> |
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

RE: setting the path in the session cookie (Tomcat 402b)

[Jarecsni János]

Hi,

well a short explanation follows then.

Since we want to alias our dynamic resources (which are to be served by
Tomcat+JBoss) in Apache we have to use mod_rewrite and mod_proxy. We need
the proxy because the rewritten urls don't get sent to tomcat, Apache treats
them as files. If we proxy those rewritten urls back to the same virtual
host, they get sent to tomcat.

The only problem is that the webcontext is hardwired in the session cookie
by Tomcat. And since the webcontext must be rewritten for the whole thing to
work too, session cookies don't work anymore (the client doesn't send them
back because of the different path).

The Sun RI sets the session cookie path to "/". That would work in our
situation too.

Can I hope some sort of a remedy of this problem in a short time, what do
you think?

Cheers & thanks.
János


--
Jarecsni, János
MORGAN HILL CONSULTING, Internet Applications Unit
mailto:[EMAIL PROTECTED]
http://morganhillconsulting.hu/ :: Phone+Fax: + 36 1 484 0392

|-Original Message-
|From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
|Behalf Of jean-frederic clere
|Sent: Friday, February 15, 2002 12:16 PM
|To: Tomcat Developers List
|Subject: Re: setting the path in the session cookie (Tomcat 402b)
|
|
|Jarecsni János wrote:
|>
|> Hi,
|>
|> it seems that tomcat uses the "/contextname" path when creating
|the cookie
|> for the JSESSIONID. Since we use Apache in front of Tomcat and we use
|> mod_rewrite with mod_proxy to provide aliasing of dynamic Java
|resources, it
|> is not working for us.
|
|You should explain a little more why you have to that (like you
|have done it in
|httpd-dev list).
|
|>
|> We would like to be able to configure this path.
|>
|> Thanks in advance
|> János
|>
|> --
|> Jarecsni, János
|> MORGAN HILL CONSULTING, Internet Applications Unit
|> mailto:[EMAIL PROTECTED]
|> http://morganhillconsulting.hu/ :: Phone+Fax: + 36 1 484 0392
|>
|> --
|> To unsubscribe, e-mail:
|
|> For
|additional commands, e-mail: 
|
|--
|To unsubscribe, e-mail:
|
|For additional
|commands, e-mail: 
|
|


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

Re: setting the path in the session cookie (Tomcat 402b)

[jean-frederic clere]

Jarecsni János wrote:
> 
> Hi,
> 
> it seems that tomcat uses the "/contextname" path when creating the cookie
> for the JSESSIONID. Since we use Apache in front of Tomcat and we use
> mod_rewrite with mod_proxy to provide aliasing of dynamic Java resources, it
> is not working for us.

You should explain a little more why you have to that (like you have done it in
httpd-dev list).

> 
> We would like to be able to configure this path.
> 
> Thanks in advance
> János
> 
> --
> Jarecsni, János
> MORGAN HILL CONSULTING, Internet Applications Unit
> mailto:[EMAIL PROTECTED]
> http://morganhillconsulting.hu/ :: Phone+Fax: + 36 1 484 0392
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

Re: Retry: PureTLS/Cryptix RPM at Apache ????

[Nick Betteridge]

JXTA holds puretls and cryptix jars on jxta.org - so it shouldn't be a
problem on jakarta.

Incidently, tls is not ssl, although there are many similarities.

Just one question - are tls socket factories available for tomcat?


GOMEZ Henri wrote:
> 
> I still didn't receive replies on the hosting of
> PureTLS/Cryptix stuff on Apache.org ?
> 
> Should I ask to Cryptix.org & PureTLS, to
> host the rpms for Cryptix and PureTLS ?
> 
> Starting from Tomcat 3.3.1-B1 we could use this stuff
> to have a 100% OSS Java SSL solution and good alternative
> to JSSE
> 
> -
> Henri Gomez ___[_]
> EMAIL : [EMAIL PROTECTED](. .)
> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
> 
> >>> TC 4.0.2 rpms are available at :
> >>
> >>The new RPM packaging looks much cleaner, and this time it should be
> >>compliant with the official standard, right ?
> >
> >Yes, and I hope to see other jakarta/xml projects use these kind of
> >packaging.
> >
> >BTW, openjmx RPM is ready, and also puretls, cryptix, cryptix-asn1
> >which could be used now on Tomcat 3.3.1-dev.
> >
> >Question :
> >
> >Could we host these CRYPTO rpms at apache.org since they give
> >users a 100% OSS SSL implementation for TC 3.3 now and may be
> >soon TC 4.0 ?
> >
> >PureTLS and Cryptix are both BSD so licence is not a problem.
> >
> >If it's impossible to host these files on apache.org, could
> >cryptix.org and rtfm.com hosts them ?
> >
> >Regards

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

Re: Retry: PureTLS/Cryptix RPM at Apache ????

[jean-frederic clere]

GOMEZ Henri wrote:
> 
> I still didn't receive replies on the hosting of
> PureTLS/Cryptix stuff on Apache.org ?
> 
> Should I ask to Cryptix.org & PureTLS, to
> host the rpms for Cryptix and PureTLS ?

That makes sense.

> 
> Starting from Tomcat 3.3.1-B1 we could use this stuff
> to have a 100% OSS Java SSL solution and good alternative
> to JSSE

Next step Tomcat 4.0.3?

> 
> -
> Henri Gomez ___[_]
> EMAIL : [EMAIL PROTECTED](. .)
> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
> 
> >-Original Message-
> >From: GOMEZ Henri
> >Sent: Wednesday, February 13, 2002 1:23 AM
> >To: Tomcat Developers List
> >Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> >Subject: PureTLS/Cryptix RPM at Apache - WAS: Tomcat 4.0.2 Final RPM
> >available
> >
> >
> >>> TC 4.0.2 rpms are available at :
> >>
> >>The new RPM packaging looks much cleaner, and this time it should be
> >>compliant with the official standard, right ?
> >
> >Yes, and I hope to see other jakarta/xml projects use these kind of
> >packaging.
> >
> >BTW, openjmx RPM is ready, and also puretls, cryptix, cryptix-asn1
> >which could be used now on Tomcat 3.3.1-dev.
> >
> >Question :
> >
> >Could we host these CRYPTO rpms at apache.org since they give
> >users a 100% OSS SSL implementation for TC 3.3 now and may be
> >soon TC 4.0 ?
> >
> >PureTLS and Cryptix are both BSD so licence is not a problem.
> >
> >If it's impossible to host these files on apache.org, could
> >cryptix.org and rtfm.com hosts them ?
> >
> >Regards
> >
> >--
> >To unsubscribe, e-mail:
> >
> >For additional commands, e-mail:
> >
> >
> >
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

Re: Rename jK2 to mod_jk2 ?

[jean-frederic clere]

GOMEZ Henri wrote:
> 
> What about renaming native2 (jk2) in JTC to mod_jk2
> and jk2_module ?

If we consider native2 as a remplacement for the native of mod_jk, no. That is
just a new version.
If you thing of easy testing may be... I have libjk.so from native and mod_jk.so
from native2 and I stop/start Apache for testing both.

> 
> It will allow us to install both modules at the same
> times and test original mod_jk and new mod_jk.
> 
> It will be need to rename all non static references,
> variables functions, but I could do that, by suffixing
> with jk2_ :
> 
> And to be consistent, it could be nice to suffix the native,
> original mod_jk, with jk_
> 
> If you agree, I could do this quickly, but JTC developpers
> shouldn't do updates for 1-3 hours...

And that will be a big commit ;-)

> 
> Regards
> 
> -
> Henri Gomez ___[_]
> EMAIL : [EMAIL PROTECTED](. .)
> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

Re: How to APR for JTC ? WAS: Native Connector Builds - When?

[jean-frederic clere]

GOMEZ Henri wrote:
> 
> I've done a RPM for tomcat-connectors which include :
> 
> mod_jk  for Apache 1.3
> mod_jk  for Apache 2.0
> mod_jk2 for Apache 2.0
> 
> I still can't build mod_webapp since the APR_DIR/APR_VARS
> are mandatory and I want/need to use instead APR_INCLUDE
> and APR_LIBS.
> 
> Today you have 2 choices to have APR :
> 
> 1) Get an APR tarball (tagged against latest Apache 2.0),
>built in on your system (alone without Apache 2.0).
>You get the shared libs in /usr/lib/libapr.so and includes in
>/usr/include/apr/

I am thinking of adding a tarball containing the APR tagged for APACHE-2.0.32
for this.
The APR way to do the thing seems to release the APR sources in the
jakarta-tomcat-connectors-4.0.2-01-src.* files.
But I prefer a tarball in our Jakarta tree: we could update it more easy.

> 
> 2) You build the latest Apache 2.0 Beta28 (didn't try the
>latest alpha), and you could have APR still as shared libs
>in /usr/lib/ and includes in /usr/include/apache2 for example
> 
> In both case we need to be able to build mod_webapp for 1.3/2.0
> against theses libs and includes. Ditto for jk2 for Apache 1.3...
> 
> Could somebody take a look at configure.in and update it to
> make APR_DIR/APR_VARS optionals ?

That is no possible...

> 
> Or may be convert jkant/build.xml to mod_webapp since jk2 works
> great in this configuration :

That is a good idea.

> 
> Here is part of my RPM spec file :
> 
> cd util
> ant
> cd ../webapp
> 
> # build webapp for Apache 1.3
> %if %{buildwa13}
> %endif
> 
> # build webapp for Apache 2.0
> %if %{buildwa20}
> %endif
> 
> cd ../jk
> 
> # build jkant
> ant -Dservlet.jar=%{tomcat4dir}/common/lib/servlet.jar 
>-Djunit.jar=%{javadir}/junit.jar -Dtomcat33.home=%{tomcat3dir} 
>-Dtomcat40.home=%{tomcat4dir} -Dapache13.home=/usr -Dapache2.home=/usr
> 
> cd native
> 
> # build jk for Apache 1.3
> %if %{buildjk13}
> ant -Dapxs13=/usr/sbin/apxs -Dapache13.home=/usr -Dapache13.include=%{ap13incdir}
> %endif
> 
> # build jk for Apache 2.0
> %if %{buildjk20}
> ant -Dapxs20=/usr/sbin/apxs2 -Dapache2.home=/usr -Dapache2.include=%{ap20incdir}
> %endif
> 
> cd ../native2
> 
> # build jk2 for Apache 1.3
> %if %{buildjk213}
> ant -Dapxs13=/usr/sbin/apxs -Dapache13.home=/usr -Dapache13.include=%{ap13incdir}
> %endif
> 
> # build jk2 for Apache 2.0
> %if %{buildjk220}
> ant -Dapxs20=/usr/sbin/apxs2 -Dapache2.home=/usr -Dapache2.include=%{ap20incdir} 
>-Dapr.include=%{ap20incdir}
> %endif
> 
> cd ..
> 
> -
> Henri Gomez ___[_]
> EMAIL : [EMAIL PROTECTED](. .)
> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

RE: Native Connector problems

[GOMEZ Henri]

>Nice... But the tarballs should be redone, should n't they?
>Then how to know that a 4.0.2 tarballs (connectors) is a good one?
>I would have retagged jakarta-tomcat-connectors as 
>tomcat_402_01 and will
>rebuild the tarballs as jakarta-tomcat-connectors-4.0.2-01-src.*
>
>Any comments?

It seems you do that ;)

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

Retry: PureTLS/Cryptix RPM at Apache ????

[GOMEZ Henri]

I still didn't receive replies on the hosting of
PureTLS/Cryptix stuff on Apache.org ?

Should I ask to Cryptix.org & PureTLS, to
host the rpms for Cryptix and PureTLS ?

Starting from Tomcat 3.3.1-B1 we could use this stuff 
to have a 100% OSS Java SSL solution and good alternative
to JSSE


-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: GOMEZ Henri 
>Sent: Wednesday, February 13, 2002 1:23 AM
>To: Tomcat Developers List
>Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: PureTLS/Cryptix RPM at Apache - WAS: Tomcat 4.0.2 Final RPM
>available
>
>
>>> TC 4.0.2 rpms are available at :
>>
>>The new RPM packaging looks much cleaner, and this time it should be
>>compliant with the official standard, right ?
>
>Yes, and I hope to see other jakarta/xml projects use these kind of
>packaging.
>
>BTW, openjmx RPM is ready, and also puretls, cryptix, cryptix-asn1
>which could be used now on Tomcat 3.3.1-dev.
>
>Question :
>
>Could we host these CRYPTO rpms at apache.org since they give
>users a 100% OSS SSL implementation for TC 3.3 now and may be
>soon TC 4.0 ?
>
>PureTLS and Cryptix are both BSD so licence is not a problem.
>
>If it's impossible to host these files on apache.org, could
>cryptix.org and rtfm.com hosts them ?
>
>Regards
>
>--
>To unsubscribe, e-mail:   
>
>For additional commands, e-mail: 
>
>
>

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

setting the path in the session cookie (Tomcat 402b)

[Jarecsni János]

Hi,

it seems that tomcat uses the "/contextname" path when creating the cookie
for the JSESSIONID. Since we use Apache in front of Tomcat and we use
mod_rewrite with mod_proxy to provide aliasing of dynamic Java resources, it
is not working for us.

We would like to be able to configure this path.

Thanks in advance
János

--
Jarecsni, János
MORGAN HILL CONSULTING, Internet Applications Unit
mailto:[EMAIL PROTECTED]
http://morganhillconsulting.hu/ :: Phone+Fax: + 36 1 484 0392


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

BUG 5722 : Forward to page display a blank page

[Thomas Colin de Verdiere]

Sorry to bother you, i'd like to comment on bug 5722.

I tried to forward to page that do not exist :
doNotExist




this displays a blank page

i tried to forward to a page that do not exist with extension :



this displays a 404 error page.
i was expecting that a page with no extension would display a 404 page.

Thanks

Thomas Colin de Verdière

-
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.

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

Forward to a page that have no extension displays a blank page

[EMAIL PROTECTED] changed:

What|Removed |Added

  Status|REOPENED|RESOLVED
  Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED] 2002-02-14 
19:00 ---
Section 8.1 of the servlet spec requires that the RequestDispatcher returns
the content of the path.  If it's not there, it has no content.






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

Rename jK2 to mod_jk2 ?

[GOMEZ Henri]

What about renaming native2 (jk2) in JTC to mod_jk2
and jk2_module ?

It will allow us to install both modules at the same 
times and test original mod_jk and new mod_jk.

It will be need to rename all non static references,
variables functions, but I could do that, by suffixing
with jk2_ :

And to be consistent, it could be nice to suffix the native,
original mod_jk, with jk_ 

If you agree, I could do this quickly, but JTC developpers
shouldn't do updates for 1-3 hours...

Regards

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

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

Java home autodiscovery add-on

[GOMEZ Henri]

What about adding this part in tomcat.sh (TC 3.3) and
catalina.sh/jasper.sh to help them discover JAVA_HOME on 
at least Linux systems ?

+if [ -z "$JAVA_HOME" ]; then
+# Search for java in PATH
+JAVA=`which java`
+if [ -z "$JAVA" ] ; then
+JAVA_BINDIR=`dirname ${JAVA}`
+JAVA_HOME="${JAVA_BINDIR}/.."
+fi
+# Default clean JAVA_HOME
+[ -z "$JAVA_HOME"  -a -d "/usr/lib/java" ] &&  JAVA_HOME="/usr/lib/java"
+# Default IBM JAVA_HOME
+[ -z "$JAVA_HOME"  -a -d "/opt/IBMJava2-13" ] &&  JAVA_HOME="/opt/IBMJava2-13"
+# Another solution
+[ -z "$JAVA_HOME"  -a -d "/usr/java/jdk" ] &&  JAVA_HOME="/usr/java/jdk"
+# madeinlinux JAVA_HOME
+[ -z "$JAVA_HOME" -a -d "/usr/local/jdk1.2.2" ] && JAVA_HOME="/usr/local/jdk1.2.2"
+# Kondara JAVA_HOME
+[ -z "$JAVA_HOME"  -a -d "/usr/lib/java/jdk1.2.2" ] && 
+JAVA_HOME="/usr/lib/java/jdk1.2.2"
+# Other commonly found JAVA_HOMEs
+[ -z "$JAVA_HOME"  -a -d "/usr/jdk1.2" ] && JAVA_HOME="/usr/jdk1.2"
+# Default Caldera JAVA_HOME
+[ -z "$JAVA_HOME"  -a -d "/opt/java-1.3" ] && JAVA_HOME="/opt/java-1.3"
+# Add other locations here
+if [ -z "$JAVA_HOME" ]; then
+echo "No JAVA_HOME specified in ${TOMCAT_CFG} and no java found, exiting..."
+exit 1
+  fi

the ${TOMCAT_CFG} is a config file (shell) which allow you to setup 
TC 3.3/4.0.2 runtime, and could be also added to CVS :

=> TC 3.3 conf :

# tomcat /etc/rc.d script example configuration file
# Use with version 1.07 of the scripts or later

# Where your java installation lives
# JAVA_HOME=/usr/java/jdk
JAVA_HOME="/opt/IBMJava2-13"

# You can pass some parameters to java
# here if you wish to
#JAVACMD="$JAVA_HOME/bin/java -Xminf0.1 -Xmaxf0.3"

# Where your tomcat installation lives
# That change from previous RPM where TOMCAT_HOME 
# used to be /var/tomcat.
# Now /var/tomcat will be the base for webapps only
TOMCAT_HOME="@@@TCHOME@@@"

# Where our webapps/libs are now installed.
TOMCAT_INSTALL="@@@TCINST@@@"

# What user should run tomcat
TOMCAT_USER="tomcat3"

# You can change your tomcat locale here
#LANG=en_US

# If you wish to further customize your tomcat environment,
# put your own definitions here
# (i.e. LD_LIBRARY_PATH for some jdbc drivers)
# Just do not forget to export them :)


=> TC 4.0.2 conf :

# tomcat /etc/rc.d script example configuration file
# Use with version 1.07 of the scripts or later

# Where your java installation lives
# JAVA_HOME=/usr/java/jdk
JAVA_HOME="/opt/IBMJava2-13"

# You can pass some parameters to java
# here if you wish to
#JAVACMD="$JAVA_HOME/bin/java -Xminf0.1 -Xmaxf0.3"

# Where your tomcat installation lives
# That change from previous RPM where TOMCAT_HOME 
# used to be /var/tomcat.
# Now /var/tomcat will be the base for webapps only
CATALINA_HOME="@@@TCHOME@@@"
JASPER_HOME="@@@TCHOME@@@"
CATALINA_TMPDIR="@@@TCHOME@@@/temp"

# What user should run tomcat
TOMCAT_USER="tomcat4"

# You can change your tomcat locale here
#LANG=en_US

# If you wish to further customize your tomcat environment,
# put your own definitions here
# (i.e. LD_LIBRARY_PATH for some jdbc drivers)
# Just do not forget to export them :)


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

How to APR for JTC ? WAS: Native Connector Builds - When?

[GOMEZ Henri]

I've done a RPM for tomcat-connectors which include :

mod_jk  for Apache 1.3
mod_jk  for Apache 2.0
mod_jk2 for Apache 2.0

I still can't build mod_webapp since the APR_DIR/APR_VARS 
are mandatory and I want/need to use instead APR_INCLUDE
and APR_LIBS.

Today you have 2 choices to have APR :

1) Get an APR tarball (tagged against latest Apache 2.0),
   built in on your system (alone without Apache 2.0).
   You get the shared libs in /usr/lib/libapr.so and includes in
   /usr/include/apr/ 

2) You build the latest Apache 2.0 Beta28 (didn't try the 
   latest alpha), and you could have APR still as shared libs 
   in /usr/lib/ and includes in /usr/include/apache2 for example

In both case we need to be able to build mod_webapp for 1.3/2.0
against theses libs and includes. Ditto for jk2 for Apache 1.3...

Could somebody take a look at configure.in and update it to 
make APR_DIR/APR_VARS optionals ?

Or may be convert jkant/build.xml to mod_webapp since jk2 works
great in this configuration :

Here is part of my RPM spec file :

cd util
ant
cd ../webapp

# build webapp for Apache 1.3
%if %{buildwa13}
%endif

# build webapp for Apache 2.0
%if %{buildwa20}
%endif

cd ../jk

# build jkant
ant -Dservlet.jar=%{tomcat4dir}/common/lib/servlet.jar 
-Djunit.jar=%{javadir}/junit.jar -Dtomcat33.home=%{tomcat3dir} 
-Dtomcat40.home=%{tomcat4dir} -Dapache13.home=/usr -Dapache2.home=/usr

cd native

# build jk for Apache 1.3
%if %{buildjk13}
ant -Dapxs13=/usr/sbin/apxs -Dapache13.home=/usr -Dapache13.include=%{ap13incdir}
%endif

# build jk for Apache 2.0
%if %{buildjk20}
ant -Dapxs20=/usr/sbin/apxs2 -Dapache2.home=/usr -Dapache2.include=%{ap20incdir}
%endif

cd ../native2

# build jk2 for Apache 1.3
%if %{buildjk213} 
ant -Dapxs13=/usr/sbin/apxs -Dapache13.home=/usr -Dapache13.include=%{ap13incdir}
%endif

# build jk2 for Apache 2.0
%if %{buildjk220}
ant -Dapxs20=/usr/sbin/apxs2 -Dapache2.home=/usr -Dapache2.include=%{ap20incdir} 
-Dapr.include=%{ap20incdir}
%endif

cd ..


-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

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

DO NOT REPLY [Bug 6201] - ISO-8859-8-i problem. (hebrew)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

ISO-8859-8-i  problem. (hebrew)





--- Additional Comments From [EMAIL PROTECTED]  2002-02-15 08:59 
---
Have you tried with the one of the encoding that are listed on the following
page?
http://java.sun.com/products//jdk/1.1/docs/guide/intl/encoding.doc.html 
Like: ISO8859_8 (I have no ideas what the -i stands for).

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