DO NOT REPLY [Bug 8969] New: - Manager - remove does not delete the webapps/application/ Dir

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8969.
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=8969

Manager - remove does not delete the webapps/application/ Dir

   Summary: Manager - remove does not delete the
webapps/application/ Dir
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In dependence on the Bugs ID6749 and ID6594 I've got the problem, that the 
manager command remove does not remove the application directory in the 
webapps-dir (inclusive all files in the directory).
I had just a short look at the Catalina-Sources and it seems, that remove 
only removes the application from the tomcat management (removes application-
key from a mangement HashMap). 
There is as well a method which could removes the hole directory but it seems 
this method isn't called (but there I'm not sure).

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




DO NOT REPLY [Bug 8971] New: - uses same compiled JSP scratch directory for two different apps

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8971.
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=8971

uses same compiled JSP scratch directory for two different apps

   Summary: uses same compiled JSP scratch directory for two
different apps
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have a configuration, in which i want to have to applications served by 
tomcat, one at http://myhost:8080 and one at http://myhost:8081, both as root 
context. I tried a configuration like this:

Server port=8005 shutdown=SHUTDOWN debug=0
  Service name=AdoraWeb
Connector className=org.apache.catalina.connector.http.HttpConnector
   port=8080 minProcessors=5 maxProcessors=75
   enableLookups=true
   acceptCount=10 debug=0 connectionTimeout=6/
Engine name=BC defaultHost=localhost debug=0
  Logger className=org.apache.catalina.logger.FileLogger
  prefix=AdoraWeb. suffix=.txt
  timestamp=true/
  Realm className=org.apache.catalina.realm.MemoryRealm /
  Host name=localhost debug=0 appBase=webapps unpackWARs=true
Valve className=org.apache.catalina.valves.AccessLogValve
 directory=logs  prefix=AdoraWeb_access_log. suffix=.txt
 pattern=common/
Logger className=org.apache.catalina.logger.FileLogger
 directory=logs  prefix=AdoraWeb_log. suffix=.txt
timestamp=true/
  Context path= docBase=D:\Java\projects\cvs\classes\web\adoraweb 
debug=0 /
  /Host
/Engine
  /Service
  Service name=EmmeLunga
Connector className=org.apache.catalina.connector.http.HttpConnector
   port=8081 minProcessors=5 maxProcessors=75
   enableLookups=true
   acceptCount=10 debug=0 connectionTimeout=6/
Engine name=ML defaultHost=localhost debug=0
  Logger className=org.apache.catalina.logger.FileLogger
  prefix=ML. suffix=.txt
  timestamp=true/
  Realm className=org.apache.catalina.realm.MemoryRealm /
  Host name=localhost debug=0 appBase=webapps unpackWARs=true
Valve className=org.apache.catalina.valves.AccessLogValve
 directory=logs  prefix=ML_access_log. suffix=.txt
 pattern=common/
Logger className=org.apache.catalina.logger.FileLogger
 directory=logs  prefix=ML_log. suffix=.txt
timestamp=true/
  Context path= docBase=D:\Java\projects\cvs\classes\web\bcml 
debug=0 /
  /Host
/Engine
  /Service
/Server

with an empty (!) webapps directory and the contexts pointing to two different 
applications, which uses jsp which may have the same names. What happens, is 
that tomcat creates in his work\localhost only one directory _ for the 
compiled jsp-servlets and uses this directory for both applications - which 
obviously won't work correctly. Maybe there is a different way to configure a 
scenario like this that i did not find out, but i would consider this to be a 
bug anyway, since tomcat seems to allow this kind of configuration.

Best regards,

Jens Stutte

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




DO NOT REPLY [Bug 8971] - uses same compiled JSP scratch directory for two different apps

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8971.
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=8971

uses same compiled JSP scratch directory for two different apps





--- Additional Comments From [EMAIL PROTECTED]  2002-05-10 10:32 ---
BTW: A (dirty) way to achieve, what i wanted, is to change the localhost in

Host name=localhost debug=0 appBase=webapps unpackWARs=true

of the second host into a real name or ip adress. In this way you can set up as 
many hosts as you have aliases for your machine in your DNS ;-)

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




DO NOT REPLY [Bug 8973] New: - request.getRequestDispatcher is returning a RequestDispatcher for the wrong context.

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8973.
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=8973

request.getRequestDispatcher is returning a RequestDispatcher for the wrong context.

   Summary: request.getRequestDispatcher is returning a
RequestDispatcher for the wrong context.
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Two contexts:
ContextA
ContextB

ContextA has ServletA
ContextB has ServletB

ServletA uses
getServletContext().getContext(/ContextB).getRequestDispatcher(/ServletB) to
include ServletB

1.ServletB does request.getRequestDispatcher(/foo) 
2.ServletB does getServletContext().getRequestDispatcher(/foo) 

1.This returns a request dispatcher from context A! [BUG]
2.This returna a request dispatcher from context B. [CORRECT]

Possible cause 1:  The context of the request is incorrectly contextA.

Possible cause 2:  The context of the request SHOULD be contextA, but it 
   should not be using its own context, but rather getting it
   from somewhere else.

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




DO NOT REPLY [Bug 8973] - request.getRequestDispatcher is returning a RequestDispatcher for the wrong context.

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8973.
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=8973

request.getRequestDispatcher is returning a RequestDispatcher for the wrong context.





--- Additional Comments From [EMAIL PROTECTED]  2002-05-10 12:15 ---
Created an attachment (id=1833)
Not sure if this is a bug

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




DO NOT REPLY [Bug 8976] New: - Form Authentication Gives invalid direct reference to form login page

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8976.
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=8976

Form Authentication Gives invalid direct reference to form login page

   Summary: Form Authentication Gives invalid direct reference to
form login page
   Product: Tomcat 4
   Version: Unknown
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


One of the issues I had was wanting my login page to be the first page 
people went to, but with the current FormAuthentication you get an error 
(invalid direct reference to form login page).

I have modified the FormAuthenication class so if someone posts to 
j_security_check from the login page (specified in the web.xml) it will 
authenticate and redirect them back to the login page.

I also added another feature where if a person also posts the parameter
 j_redirect_url to j_security_check it will forward them to that url (note: the 
j_redirect_url must be an absolute url reference).

The logic inside this class is fairly complicated because it deals with 
multiple requests and I think I did everything correctly. If someone wants 
to provide feedback that would be great. I can work on any bugs.

The actual code was sent to the maillist list under the subject
Form Authentication potential contribution

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




Thread issues

2002-05-10 Thread Keith Wannamaker

Hey folks,
There seems to be a threading issue introduced between
3.3 and current 3.3.2-dev head.  When running the code
under heavy load with four tcp endpoints (2 http10, ajp12,
ajp13) eventually one of the http connectors disappears
from thread dumps.  In going through diffs the most
significant change I see is Bill's change to the expirer,
but I'm not sure if that is related at all.  The purpose
of this note is to solicit ideas on debugging and to see
if anyone else has run into this behavior.

Thanks,
Keith


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




DO NOT REPLY [Bug 8976] - Form Authentication Gives invalid direct reference to form login page

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8976.
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=8976

Form Authentication Gives invalid direct reference to form login page





--- Additional Comments From [EMAIL PROTECTED]  2002-05-10 14:43 ---
Created an attachment (id=1835)
Potential Fix for this bug

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




DO NOT REPLY [Bug 8976] - Form Authentication Gives invalid direct reference to form login page

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8976.
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=8976

Form Authentication Gives invalid direct reference to form login page





--- Additional Comments From [EMAIL PROTECTED]  2002-05-10 15:04 ---
This is a good feature because TC 4.X has a lack in form auth redirection:

- How about session expired?
- How about direct login page access?
- etc

I think this is a good aproach for peter patch, so please, oh great TC gurus,
take it in consideration and let it checked before new release!!

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




GUMP (offtopic?)

2002-05-10 Thread gummi

I'm working on getting GUMP to work with my own projects,
and have had some difficulties with it.

I hope this isn't way off topic, but there doesn't seem to
be any community explicitly behind GUMP, and I thought this
mailing list was the closest match. Correct me if I'm
wrong, I can take this off-list if anyone is interested.

First of all, what version of GUMP is running at Jakarta?
The version straight from the CVS doesn't even run:
- gen.sh references the workspace XML file incorrectly
  when doing puball.sh (should be ../$SOURCE, not $SOURCE).
- update.sh simply exits without doing anything, haven't
  still figured out why.
- build.sh is generated with a scripting error, an extra fi
  is generated without a matching if.

There are no tags in the CVS, so this module is not under
strict version control. I'm willing to contribute into this
module, but would like to hear from anyone who has been
working on it regarding it's current status.

Maybe my config files are simply incorrect, causing all
these problems. In that case, any help you can provide would
be appreciated, and then I would gladly like to contribute
documentation describing how to get started using GUMP.
I based my config on the rubix.xml workspace.

I think a lot of groups are in a similar position as I am,
looking for an integration tool to work with CVS and ant.
Do you know of any other groups using GUMP?

Regards,
Gummi Haf

--
Gudmundur Hafsteinsson - [EMAIL PROTECTED]
Dimon Software - www.dimonsoftware.com

... 'cause that's what tiggers do the best! - Tigger
--




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




Re: GUMP (offtopic?)

2002-05-10 Thread Sam Ruby

Gudmundur Hafsteinsson wrote:

 I hope this isn't way off topic, but there doesn't seem to
 be any community explicitly behind GUMP, and I thought this
 mailing list was the closest match. Correct me if I'm
 wrong, I can take this off-list if anyone is interested.

The best mailing list for this discussion is alexandria-dev.  Take a look
at http://jakarta.apache.org/gump/ and follow the links for joining the
mailing lists.

 First of all, what version of GUMP is running at Jakarta?

The latest from cvs.

 The version straight from the CVS doesn't even run:
 - gen.sh references the workspace XML file incorrectly
   when doing puball.sh (should be ../$SOURCE, not $SOURCE).

Looks like a recent regression.

 - update.sh simply exits without doing anything, haven't
   still figured out why.
 - build.sh is generated with a scripting error, an extra fi
   is generated without a matching if.

I'm not sure what is going on.  I have gump running on one Linux box, two
Solaris boxes, and three Windows boxes.  Various other people have it
running on their machines.

Perhaps if you can provide a bit more information, we can track this down
together.

- Sam Ruby


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




cvs commit: jakarta-tomcat-connectors/webapp/lib pr_warp.c wa_request.c

2002-05-10 Thread jfclere

jfclere 02/05/10 08:30:17

  Modified:webapp/apache-1.3 mod_webapp.c
   webapp/apache-2.0 mod_webapp.c
   webapp/include wa_request.h
   webapp/lib pr_warp.c wa_request.c
  Log:
  Add modification of status line.
  
  Revision  ChangesPath
  1.34  +10 -1 jakarta-tomcat-connectors/webapp/apache-1.3/mod_webapp.c
  
  Index: mod_webapp.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/apache-1.3/mod_webapp.c,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- mod_webapp.c  3 May 2002 13:30:25 -   1.33
  +++ mod_webapp.c  10 May 2002 15:30:17 -  1.34
  @@ -57,7 +57,7 @@
   
   /**
* @author  Pier Fumagalli mailto:[EMAIL PROTECTED]
  - * @version $Id: mod_webapp.c,v 1.33 2002/05/03 13:30:25 pier Exp $
  + * @version $Id: mod_webapp.c,v 1.34 2002/05/10 15:30:17 jfclere Exp $
*/
   
   #include httpd.h
  @@ -297,6 +297,14 @@
   
   req-status=status;
   }
  +/* Set the HTTP status of the response. */
  +void wam_handler_setstatusline(wa_request *r, char * status) {
  +request_rec *req=(request_rec *)r-data;
  +
  +if (status !=NULL  status[0]!='\0')
  +req-status_line=apr_pstrdup(req-pool,status);
  +}
  +
   
   /* Set the MIME Content-Type of the response. */
   void wam_handler_setctype(wa_request *r, char *type) {
  @@ -374,6 +382,7 @@
   static wa_handler wam_handler = {
   wam_handler_log,
   wam_handler_setstatus,
  +wam_handler_setstatusline,
   wam_handler_setctype,
   wam_handler_setheader,
   wam_handler_commit,
  
  
  
  1.10  +11 -1 jakarta-tomcat-connectors/webapp/apache-2.0/mod_webapp.c
  
  Index: mod_webapp.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/apache-2.0/mod_webapp.c,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- mod_webapp.c  3 May 2002 13:30:25 -   1.9
  +++ mod_webapp.c  10 May 2002 15:30:17 -  1.10
  @@ -57,7 +57,7 @@
   
   /**
* @author  Pier Fumagalli mailto:[EMAIL PROTECTED]
  - * @version $Id: mod_webapp.c,v 1.9 2002/05/03 13:30:25 pier Exp $
  + * @version $Id: mod_webapp.c,v 1.10 2002/05/10 15:30:17 jfclere Exp $
*/
   
   #include httpd.h
  @@ -300,6 +300,15 @@
   req-status=status;
   }
   
  +/* Set the HTTP status of the response. */
  +void wam_handler_setstatusline(wa_request *r, char * status) {
  +request_rec *req=(request_rec *)r-data;
  +
  +if (status !=NULL  status[0]!='\0')
  +req-status_line=apr_pstrdup(req-pool,status);
  +}
  +
  +
   /* Set the MIME Content-Type of the response. */
   static void wam_handler_setctype(wa_request *r, char *type) {
   request_rec *req=(request_rec *)r-data;
  @@ -381,6 +390,7 @@
   static wa_handler wam_handler = {
   wam_handler_log,
   wam_handler_setstatus,
  +wam_handler_setstatusline,
   wam_handler_setctype,
   wam_handler_setheader,
   wam_handler_commit,
  
  
  
  1.11  +3 -1  jakarta-tomcat-connectors/webapp/include/wa_request.h
  
  Index: wa_request.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/include/wa_request.h,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- wa_request.h  1 Nov 2001 22:20:51 -   1.10
  +++ wa_request.h  10 May 2002 15:30:17 -  1.11
  @@ -58,7 +58,7 @@
   /**
* @package Request Handling
* @author  Pier Fumagalli mailto:[EMAIL PROTECTED]
  - * @version $Id: wa_request.h,v 1.10 2001/11/01 22:20:51 pier Exp $
  + * @version $Id: wa_request.h,v 1.11 2002/05/10 15:30:17 jfclere Exp $
*/
   #ifndef _WA_REQUEST_H_
   #define _WA_REQUEST_H_
  @@ -95,6 +95,7 @@
   struct wa_handler {
   void (*log)(wa_request *r, const char *file, const int line, char *msg);
   void (*setstatus)(wa_request *r, int status);
  +void (*setstatusline)(wa_request *r, char *status);
   void (*setctype)(wa_request *r, char *type);
   void (*setheader)(wa_request *r, char *name, char *value);
   void (*commit)(wa_request *r);
  @@ -188,6 +189,7 @@
   
   void wa_rlog(wa_request *r, const char *f, const int l, const char *fmt, ...);
   void wa_rsetstatus(wa_request *r, int status);
  +void wa_rsetstatusline(wa_request *r, char *status);
   void wa_rsetctype(wa_request *r, char *type);
   void wa_rsetheader(wa_request *r, char *name, char *value);
   void wa_rcommit(wa_request *r);
  
  
  
  1.22  +2 -1  jakarta-tomcat-connectors/webapp/lib/pr_warp.c
  
  Index: pr_warp.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/lib/pr_warp.c,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- 

Re: Prove me wrong - take this quiz

2002-05-10 Thread Steve McCarthy

Remy Maucherat wrote:

I do agree  ErrorReportValve has a bug and shouldn't touch the
response if 2xx status, but that's a different story.

Well, that's what I really care about.


Ok, so if I change  200 to  300 we'll all be friends, and everything
will be fine ?
That looks like a good deal.

Yes, good deal. Big thanks!  No hard feelings. :-)

You'll still have to fix your WebDAV servlet though.

BTW, did you try using the TC WebDAV servlet or Slide instead of writing
your own ?

Actually, this particular webapp is proxying HTTP traffic, and is not a 
dedicated WebDAV servlet.  We just ran into unexpected results when 
proxying traffic from a WebDAV source.  One of our developers lost his 
whole weekend tracking this down, and that's why I really didn't to let 
it go quietly.

Peace, love, and harmony,
-Steve




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




Re: Prove me wrong - take this quiz

2002-05-10 Thread jean-frederic clere

Pier Fumagalli wrote:
 Steve McCarthy [EMAIL PROTECTED] wrote:
 
 
Hi, Developers and Developer-ettes!

It is time for a fun quiz to test your knowledge of HTTP, Servlets, and
servlet behavior.  See if you can get them all right!  As a bonus, see if
you can guess how Tomcat handles these situations (as of 5/8/2002).
 
 
 Kewl, let's do this...
 
 
Section 1  - HTTP
-
Question 1

  HTTP 1.1 specification RFC 2616 defines 5 classes of status codes: 1xx,
  2xx, 3xx, 4xx, and 5xx.

  What do the 2xx codes signify?
 A.  Successful
 
 
 Hmm... A! 
 
 
Question 2

  What 2xx status codes are defined by RFC 2616?
 A. 200 - 206
 
 
 Hmm... A
 
 
Question 3

  If an HTTP application returns a 2xx code that is beyond the range of 2xx
  status codes, say 299, is it an error?
 A.  No, it is by definition a success.
 
 
 Hmm... A
 
 
Section 2 - Servlet Container behavior
--
  A servlet wants to write to the client.  It sets the status code to
  299.  It obtains a PrintWriter from the servlet container and writes to
  it.

Question 1
  Does servlet specification require you to call flush() to ensure that
  the client actually see the bytes?
 A. No, spec does not mandate this behavior for webapps.
 
 
 Hmm... A
 
 
Question 2
  Where in servlet spec (or RFC 2616, your choice) does it allow
  the container to replace the message body or content-type header  for an
  application that has set the status code to 2xx?
 A.  It doesn't.  It shouldn't.  That would be clearly wrong.
 
 
 Hmm... A
 
 
Question 3
  The servlet spec allows you to write to the output by either obtaining a
  Writer or an OutputStream from the container, but not both.

  Should servlet container behave differently if application writes to
  OutputStream instead of Writer?
 A.  No.  Behavior should be consistent.
 
 
 Hmm... A
 
 
Question 4
  When is it ever acceptable to replace the content-type and message body
  when servlet is returning a 2xx status code?
 A.  As a practical matter, it should never change the headers or body
 for any code less than 400.
 
 
 Hmm... A
 
 
Section 3 - Guess the output

The following code samples are assumed to be in a servlet's service()
method.

  Sample Code 1
  -
  response.setStatus(299);
  response.setContentType(application/x-pig-latin);
  response.getWriter().println(an-Cay ou-yay ead-ray is-thay?);

Question 1
  What should the client see in the Content-type header?
 A.  application/x-pig-latin
 
 
 Hmm... A
 
 
Question 2
  What should the client see in the message body?
 A. The string an-Cay ou-yay ead-ray is-thay?
 
 
 Hmm... A
 
 
  Sample Code 2
  -
  response.setStatus(299);
  response.setContentType(application/x-pig-latin);
  Writer w = response.getWriter();
  w.println(an-Cay ou-yay ead-ray is-thay?);
  w.flush();


Question 3
  What should the client see in the message body?
 A. The string an-Cay ou-yay ead-ray is-thay?
 
 
 Hmm... A
 
 
  Sample Code 3
  -
  response.setStatus(299);
  response.setContentType(application/x-pig-latin);
  response.getOutputStream().write(an-Cay ou-yay ead-ray
is-thay?.getBytes());

Question 4
  What should the client see in the message body?
 A. The string an-Cay ou-yay ead-ray is-thay?
 
 
 Hmm... A
 
 
ANSWERS:

Of course, these are loaded questions. :)  A is the correct answer to all
of the questions, and the last choice for each question describes current
Tomcat behavior.
 
 
 DOOH! So, I figured... Hmm... A. Hmm... A. Hmm... A. Hmm... A. Hmm... A.
 Hmm... A. Hmm... A. Hmm... A. Hmm... A. Hmm... A. Hmm... A.
 
 
I have been frustrated in multiple attempts to report this very glaring bug,
because the reviewer chooses to close the bugs, dismissing them out-of-hand
as invalid without addressing a single fact, without being able to muster
a technical argument to where I might be mistaken.
 
 
 Hmm... A. Ehgeehehehmmm... Sorry... No, yes, indeed, I followed a little bit
 the stuff on 8831, that has been closed _4_ times, and goddamit, you're
 absolutely right, and 8916 has been closes _3_ times... Making it 7 times
 when a bug was closed for (FWICS) no good reason...
 
 
I am pretty sure that I am solid on the specs, and would welcome
technical feedback, backed by relevent spec or RFC, to the contrary.
 
 
 Yes you are... But you're not the only one to think that Tomcat's HTTP
 behavior is less than compliant to the spec in more than one critical aspect
 (the last one was pointed out today by JF, for example)

Yep... Fixing TC breaks the watchdog test.
I should I fix TC and report a bug against watchdog?

 
 
plea Hoping for some help from committers who can see this behavior is
wrong and needs to be changed./plea
 
 
 I agree that a patch must be provided and something shall be done to address
 an utterly irresponsible and mischievous behavior of ErrorReportValve.
 
 
I can submit a patch 

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

2002-05-10 Thread remm

remm02/05/10 09:26:25

  Modified:.RELEASE-NOTES-4.1.txt
  Log:
  - Status update.
  
  Revision  ChangesPath
  1.4   +19 -5 jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt
  
  Index: RELEASE-NOTES-4.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- RELEASE-NOTES-4.1.txt 8 May 2002 18:36:45 -   1.3
  +++ RELEASE-NOTES-4.1.txt 10 May 2002 16:26:25 -  1.4
  @@ -3,7 +3,7 @@
   Release Notes
   =
   
  -$Id: RELEASE-NOTES-4.1.txt,v 1.3 2002/05/08 18:36:45 remm Exp $
  +$Id: RELEASE-NOTES-4.1.txt,v 1.4 2002/05/10 16:26:25 remm Exp $
   
   
   
  @@ -38,10 +38,6 @@
   Complete development of the initial version of the administration web
   application.
   
  -[4.1.2] Administration Webapp:
  -Fix problems with limiting the length of the driverClassName field, as
  -well as set default values.
  -
   
   -
   Catalina New Features:
  @@ -69,6 +65,13 @@
   Generic Bug Fixes:
   --
   
  +[4.1.2] Administration Webapp:
  +Fix problems with limiting the length of the driverClassName field, as
  +well as set default values, and add missing JNDI name field.
  +
  +[4.1.2] Administration Webapp:
  +Many cosmetic fixes.
  +
   
   --
   Catalina Bug Fixes:
  @@ -82,6 +85,13 @@
   JAR file which point to the JAR, intead of using a nested jar: URL.
   This change will affect security manager policy files.
   
  +[4.1.2] ErrorReportValve:
  +Made it so the valve will only generate status reports for status codes
  +over 300.
  +
  +[4.1.2] DbcpDataSourceFactory:
  +maxIdle attribute couldn't be set.
  +
   
   
   Jasper Bug Fixes:
  @@ -93,6 +103,10 @@
   This workaround for a JDK bug (BugParade Id: 4414162) introduces 
   a massive performance improvement when using pages containing 
   lots of tags.
  +
  +[4.1.2] Generator:
  +Fixes various problems introduced by the patch which removes 
  +the try/catch tag nesting.
   
   
   
  
  
  

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




DO NOT REPLY [Bug 6468] - content-type not set for errors

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6468.
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=6468

content-type not set for errors

[EMAIL PROTECTED] changed:

   What|Removed |Added

URL|http://localhost:8080/nocont|any with JSP-compilation
   |ext/|error
 Status|RESOLVED|REOPENED
  Component|Connector:HTTP/1.1  |Catalina
   |(deprecated)|
 Resolution|FIXED   |
Version|4.0.2 Final |4.0.3 Final



--- Additional Comments From [EMAIL PROTECTED]  2002-05-10 16:45 ---
This isn't fixed (or is broken again).in the ErrorReportValve.report(), the 
response.getReporter() is called, where from theflushBuffer() is 
called, which commits the response,and then back in the ErrorReportValve.report(), the 
setContentType(text/html)on the commited response is ignored.Cheers,Juraj

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




Re: Prove me wrong - take this quiz

2002-05-10 Thread Pier Fumagalli

jean-frederic clere [EMAIL PROTECTED] wrote:

 Yes you are... But you're not the only one to think that Tomcat's HTTP
 behavior is less than compliant to the spec in more than one critical aspect
 (the last one was pointed out today by JF, for example)
 
 Yep... Fixing TC breaks the watchdog test.
 I should I fix TC and report a bug against watchdog?

IMO, we should fix tomcat and report a bug against watchdog...

BTW, let's try to quote only the relevant part of messages...

Pier


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




DO NOT REPLY [Bug 6468] - content-type not set for errors

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6468.
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=6468

content-type not set for errors

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-05-10 17:06 ---
I don't know which version you tested against, and I don't really understand 
the report. 4.0.3 doesn't work. 4.0.4 and 4.1.x should work.

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




DO NOT REPLY [Bug 8982] New: - contentType in included file does not affect the parent

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8982.
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=8982

contentType in included file does not affect the parent

   Summary: contentType in included file does not affect the parent
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]



 I want to clarify the following scenario:

 I have two jsp's defined as follows

 includejsp.jsp:

 %@ page contentType=text/html; charset=euc-kr %

 br

 Result of includejsp.jsp

 br

 !-- Korean (1)*/--

 ÇÑ±Û Å×½ºÆ®

 br

 %= Test Include%

 br

 br

 ---

 and test.jsp defined as follows:

 %@ include file=./includejsp.jsp %

 br

 BR

 Result of test.jsp

 BR

 !-- Korean (2)*/--

 ÇÑ±Û Å×½ºÆ®

 BR

 Test Test!!!

 

 Should the  %@ page contentType=text/html; charset=euc-kr % in
 includejsp.jsp affect how the characters are translated during the gernation
 process in test.jsp?  In Tomcat 4.03, the korean string in test.jsp is
 translated in unicode and the one in includejsp.jsp is translated properly.

 Thanks for any comments, Jeff.


As the charset of the contentType or pageEncoding charset should affect
the translation of the whole translation unit, both including page and
included page (in the sense of include directive).

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




DO NOT REPLY [Bug 8982] - contentType in included file does not affect the parent

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8982.
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=8982

contentType in included file does not affect the parent

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-05-10 18:14 ---
Section 8.3 of the servlet spec forbids an included page from changing any 
headers.  In particular, it can't change content-type

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




DO NOT REPLY [Bug 8983] New: - Error parsing JSP with a % in a jsp:param value

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8983.
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=8983

Error parsing JSP with a % in a jsp:param value

   Summary: Error parsing JSP with a % in a jsp:param value
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


The JSP parser is incorrectly generating the list of request parameters when 
there is a percent sign in a jsp:param value. For example:

jsp:include page=/myservlet flush=true
jsp:param name=username value=user/
jsp:param name=password value=pass/
jsp:param name=width value=33%/
/jsp:include

The parameter list, requested in my servlet via req.getParameterNames(), 
contains gibberish values.  Since the spec states that value is of type CDATA, 
I'm assuming this is a bug:

!ELEMENT jsp:param EMPTY
!ATTLIST jsp:param
name CDATA #REQUIRED
value CDATA #REQUIRED


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




Re: Prove me wrong - take this quiz

2002-05-10 Thread Jon Scott Stevens

on 5/9/02 6:20 PM, Pier Fumagalli [EMAIL PROTECTED] wrote:

 1) Make sure my employer is happy not  running alpha software in production
 2) Feed and pet the cat
 3) Find girlfriend (yeah, right)
 4) Tease Jon
 5) Make mod_webapp happy
 6) try out tomcat 4.1

Woo hoo! I'm up to #4!

:-)

-jon


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




DO NOT REPLY [Bug 8983] - Error parsing JSP with a % in a jsp:param value

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8983.
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=8983

Error parsing JSP with a % in a jsp:param value

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-05-10 21:17 ---
The problem has nothing to do with whether value is a CDATA, but that when
passed to another page, needs to be URL encoded.

This is fixed in jasper2, which will be released as tomcat 4.1.x.

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




Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c

2002-05-10 Thread Mathias Herberts

[EMAIL PROTECTED] wrote:
 
 costin  02/05/09 14:06:48
 
   Modified:jk/native2/common jk_worker_lb.c
   Log:
   That's the big one.
 
   Please review !
 
   It changes the handling of lb_value to int. I also cleaned up the logic so
   it's easier ( I hope ) to understand what's happening. Levels replace
   the 'local worker', I thing I got the logic straight for those.
 
   I started to add a 'introspection' data, to validate and better report
   the config.
 
   We use one table per level. At the moment the maximum number of workers
   is hardcoded ( to 255 ), we could make it dynamic but that would make things
   pretty complex when we add workers dynamically ( it won't work without
   a CS or atomic operations )

Hi Costin,

I read your code throughly and found no problem in
get_most_suitable_worker, I think your approach to prioritizing workers
is the best. What bernd and I had done was mainly driven by the need to
have a frontal load balancer detect the failure of the local worker(s).
Since my last patch and having read yours I think I found a better way
to make the load balancer detect failures.

Configure all Apache instances so they see all Tomcat instances, assign
a higher priority to local workers on each Apache, therefore local
workers will be chosen first. On each Apache, the load balancing worker
is called lb. Another load balancing worker, balancing only the local
workers, is called hwlb. The hardware load balancer checks the health of
the Apache servers using a URI which is served by hwlb instead of lb,
therefore if there are no more local workers left alive, the requests
the hardware load balancer dispatches to the associated Apache before it
can detect the local workers failure will be rerouted to the other non
local workers and the client will only loose its session information,
she will not get any errors. When the hardware load balancer ends up
detecting the local workers failure (because the hwlb worker rejected
the request due to the lack of available worker), it will declare the
Apache inactive and will only use the other ones.

This setup solves my use cases at least, I don't know for Bernd's.

There remains a related problem in jk_requtil in
jk2_requtil_getCookieByName, as I mentioned several months ago on the
list, the cookie extraction does not work for cookies whose format
conforms to RFC 2169, that is the cookie value is enclosed in double
quotes. Such cookie format is used by lynx for example. I had submitted
a patch into the bug database but cannot find it anymore, I'll have to
look up my archives.

Good job on the lb worker Costin,

Mathias.

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




Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c

2002-05-10 Thread costinm

Hi Mathias,

Thanks for the review.

Few comments:

 Configure all Apache instances so they see all Tomcat instances, assign
 a higher priority to local workers on each Apache, therefore local

What you set is the 'level' ( or proximity, distance, etc ) - lower 
numbers mean closer ( and higher priority, local worker ). 

I still need to add and verify the setters and check the various cases.

 workers, is called hwlb. The hardware load balancer checks the health of
 the Apache servers using a URI which is served by hwlb instead of lb,

You may have noticed the 'jk_status' worker - it displays runtime 
informations ( still in progress - we need to agregate the statistics 
from all workers using shm, but the status of the workers should be fine ).

It can be easily extended ( or a similar handler added ) so it 
can generate info that can be 'consumed' by a front load balancer
or other tools. Like number of active workers and average response times.


I am also investigating how we can use the number of active connections
on each worker and the response times in the main lb, any idea would
be wellcome :-)


 This setup solves my use cases at least, I don't know for Bernd's.

Ok, but let me know if you find jk2 acceptable for your case and 
what is the minimal change to jk1 that we can do. I still have 
to merge your patches, I was waiting for more comments.

I don't think we can/should backport the new code, it's far too
much. 


 There remains a related problem in jk_requtil in
 jk2_requtil_getCookieByName, as I mentioned several months ago on the
 list, the cookie extraction does not work for cookies whose format
 conforms to RFC 2169, that is the cookie value is enclosed in double
 quotes. Such cookie format is used by lynx for example. I had submitted
 a patch into the bug database but cannot find it anymore, I'll have to
 look up my archives.

Please do, and send it to the list ( with PATCH ).

I would apreciate 2 patches, one for jk1 and one for jk2 ( if the problem 
is in both ).

Costin


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




DO NOT REPLY [Bug 5826] - JSPC not recompiling modified files

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5826.
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=5826

JSPC not recompiling modified files

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|tomcat- |[EMAIL PROTECTED]
   |[EMAIL PROTECTED]  |
 Status|REOPENED|NEW

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




DO NOT REPLY [Bug 8992] New: - IE6/XP: Limitation of POST Area within HTTP request?

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8992.
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=8992

IE6/XP: Limitation of POST Area within HTTP request?

   Summary: IE6/XP: Limitation of POST Area within HTTP request?
   Product: Tomcat 3
   Version: 3.3.1 Final
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


When I try to access the following JSP using Tomcat 3.3.1 using IE6 as a 
browser on Windows XP with all three components running on the same machine), I 
receive the following message:

The page cannot be displayed.

Alternatively, the browser will hang, awaiting a response from the server, but 
ultimately serving nothing.

This appears to related to a limitation to the POST area of the message.  This 
hypothesis was drawn for two reasons:
1. The error does not occur if only 27 hidden elements are displayed.
2. The name of the hidden element is changed to be something smaller (like T). 
[Then, as a result, it may be possible to increase the number of hidden 
elements.]

I have examined this problem changing:
1. Netscape 6.22, in place of IE6 (also IE5.5)
2. JRun 3.1, in place of Tomcat
3. Windows 2000, in place of Windows XP

If I substitute one element out of the IE6/XP/Tomcat combination, everything 
will work without failure.  I can submit the form over and over and over again 
without failing.  It is only the combination of IE6/XP/Tomcat (again, running 
locally) that produces this problem.  (I can use IE6 on WinXP to access this 
JSP on another machine running Tomcat, and the JSP will execute properly.)

I was hoping to use Tomcat 3.3.1, since Tomcat 4.x is still under production.

I would appreciate any assistance that can be provided in diagnosing this error.



Here is the JSP:

!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN

html
head
titleUntitled/title
/head

body
h1Financial Calculator/h1
form method=post action=Test.jsp name=TestForm id=TestForm
input type=hidden size=1 name=XXXType01 value=0
input type=hidden size=1 name=XXXType02 value=0
input type=hidden size=1 name=XXXType03 value=0
input type=hidden size=1 name=XXXType04 value=0
input type=hidden size=1 name=XXXType05 value=0
input type=hidden size=1 name=XXXType06 value=0
input type=hidden size=1 name=XXXType07 value=0
input type=hidden size=1 name=XXXType08 value=0
input type=hidden size=1 name=XXXType09 value=0
input type=hidden size=1 name=XXXType10 value=0
input type=hidden size=1 name=XXXType11 value=0
input type=hidden size=1 name=XXXType12 value=0
input type=hidden size=1 name=XXXType13 value=0
input type=hidden size=1 name=XXXType14 value=0
input type=hidden size=1 name=XXXType15 value=0
input type=hidden size=1 name=XXXType16 value=0
input type=hidden size=1 name=XXXType17 value=0
input type=hidden size=1 name=XXXType18 value=0
input type=hidden size=1 name=XXXType19 value=0
input type=hidden size=1 name=XXXType20 value=0
input type=hidden size=1 name=XXXType21 value=0
input type=hidden size=1 name=XXXType22 value=0
input type=hidden size=1 name=XXXType23 value=0
input type=hidden size=1 name=XXXType24 value=0
input type=hidden size=1 name=XXXType25 value=0
input type=hidden size=1 name=XXXType26 value=0
input type=hidden size=1 name=XXXType27 value=0
input type=hidden size=1 name=XXXType28 value=0
!--
input type=hidden size=1 name=XXXType29 value=0
input type=hidden size=1 name=XXXType30 value=0
input type=hidden size=1 name=XXXType31 value=0
input type=hidden size=1 name=XXXType32 value=0
input type=hidden size=1 name=XXXType33 value=0
input type=hidden size=1 name=XXXType34 value=0
input type=hidden size=1 name=XXXType35 value=0
input type=hidden size=1 name=XXXType36 value=0
input type=hidden size=1 name=XXXType37 value=0
input type=hidden size=1 name=XXXType38 value=0
input type=hidden size=1 name=XXXType39 value=0
input type=hidden size=1 name=XXXType40 value=0
input type=hidden size=1 name=XXXType41 value=0
input type=hidden size=1 name=XXXType42 value=0
input type=hidden size=1 name=XXXType43 value=0
input type=hidden size=1 name=XXXType44 value=0
input type=hidden size=1 name=XXXType45 value=0
input type=hidden size=1 name=XXXType46 value=0
input type=hidden size=1 

DO NOT REPLY [Bug 8994] New: - JSP's do not recompile

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8994.
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=8994

JSP's do not recompile

   Summary: JSP's do not recompile
   Product: Tomcat 4
   Version: Nightly Build
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


JSP's don't recompile when I change them under jakarta 4.1 nightly build that I 
pulled down a day or two ago. I can only get them to recompile if I tell the 
manager to reload them or use the ant reload task.

I tried doing the same thing with 4.0.3 and got it work.

I wasn't using Cygwin this time. :P

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




cvs commit: jakarta-tomcat-4.0/webapps/admin/valve accessLogValve.jsp remoteAddrValve.jsp remoteHostValve.jsp requestDumperValve.jsp singleSignOnValve.jsp valves.jsp

2002-05-10 Thread manveen

manveen 02/05/10 15:41:42

  Modified:webapps/admin blank.jsp error.jsp saved.jsp
   webapps/admin/connector connector.jsp connectors.jsp
   webapps/admin/context context.jsp contexts.jsp
   webapps/admin/host alias.jsp aliases.jsp host.jsp hosts.jsp
   webapps/admin/realm jdbcRealm.jsp jndiRealm.jsp
memoryRealm.jsp realms.jsp userDatabaseRealm.jsp
   webapps/admin/resources dataSource.jsp deleteDataSources.jsp
deleteEnvEntries.jsp deleteUserDatabases.jsp
envEntry.jsp listDataSources.jsp listEnvEntries.jsp
listUserDatabases.jsp userDatabase.jsp
   webapps/admin/server server.jsp
   webapps/admin/service service.jsp services.jsp
   webapps/admin/users deleteGroups.jsp deleteRoles.jsp
deleteUsers.jsp group.jsp listGroups.jsp
listRoles.jsp listUsers.jsp role.jsp user.jsp
   webapps/admin/valve accessLogValve.jsp remoteAddrValve.jsp
remoteHostValve.jsp requestDumperValve.jsp
singleSignOnValve.jsp valves.jsp
  Log:
  - fix for addHost and addConnector when the service name contains blanks and other 
special characters.
  
  - minor cosmetic change, added a background imange to all content pages.
  
  Revision  ChangesPath
  1.2   +1 -1  jakarta-tomcat-4.0/webapps/admin/blank.jsp
  
  Index: blank.jsp
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/blank.jsp,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- blank.jsp 6 Dec 2001 23:49:19 -   1.1
  +++ blank.jsp 10 May 2002 22:41:40 -  1.2
  @@ -13,7 +13,7 @@
   
   !-- Body --
   
  -body bgcolor=white
  +body bgcolor=white background=images/PaperTexture.gif
   
   /body
   
  
  
  
  1.6   +1 -1  jakarta-tomcat-4.0/webapps/admin/error.jsp
  
  Index: error.jsp
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/error.jsp,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- error.jsp 20 Nov 2001 13:57:44 -  1.5
  +++ error.jsp 10 May 2002 22:41:40 -  1.6
  @@ -13,7 +13,7 @@
   
   !-- Body --
   
  -body bgcolor=white
  +body bgcolor=white background=images/PaperTexture.gif
   
   center
   
  
  
  
  1.4   +1 -1  jakarta-tomcat-4.0/webapps/admin/saved.jsp
  
  Index: saved.jsp
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/saved.jsp,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- saved.jsp 24 Apr 2002 06:02:40 -  1.3
  +++ saved.jsp 10 May 2002 22:41:40 -  1.4
  @@ -7,7 +7,7 @@
   
   html:html locale=true
   
  -  body bgcolor=white
  +  body bgcolor=white background=images/PaperTexture.gif
   
   %-- Cause our tree control to refresh itself --%
   script language=JavaScript
  
  
  
  1.15  +1 -1  jakarta-tomcat-4.0/webapps/admin/connector/connector.jsp
  
  Index: connector.jsp
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/connector/connector.jsp,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- connector.jsp 3 May 2002 06:15:13 -   1.14
  +++ connector.jsp 10 May 2002 22:41:40 -  1.15
  @@ -11,7 +11,7 @@
   %@ include file=../users/header.jsp %
   
   !-- Body --
  -body bgcolor=white
  +body bgcolor=white background=../images/PaperTexture.gif
   
   !--Form --
   
  
  
  
  1.5   +1 -1  jakarta-tomcat-4.0/webapps/admin/connector/connectors.jsp
  
  Index: connectors.jsp
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/connector/connectors.jsp,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- connectors.jsp1 May 2002 02:37:22 -   1.4
  +++ connectors.jsp10 May 2002 22:41:40 -  1.5
  @@ -10,7 +10,7 @@
   %@ include file=../users/header.jsp %
   
   !-- Body --
  -body bgcolor=white
  +body bgcolor=white background=../images/PaperTexture.gif
   
   !--Form --
   
  
  
  
  1.7   +1 -1  jakarta-tomcat-4.0/webapps/admin/context/context.jsp
  
  Index: context.jsp
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/context/context.jsp,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- context.jsp   2 May 2002 18:16:10 -   1.6
  +++ context.jsp   10 May 2002 22:41:40 -  1.7
  @@ -10,7 +10,7 @@
   %@ include file=../users/header.jsp %
   
   

cvs commit: jakarta-tomcat-4.0/webapps/admin/images PaperTexture.gif

2002-05-10 Thread manveen

manveen 02/05/10 15:42:23

  Added:   webapps/admin/images PaperTexture.gif
  Log:
  *Background image for all content pages.
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-4.0/webapps/admin/images/PaperTexture.gif
  
Binary file
  
  

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




DO NOT REPLY [Bug 8719] - catalina.sh bug

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8719.
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=8719

catalina.sh bug

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX

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




DO NOT REPLY [Bug 8994] - JSP's do not recompile

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8994.
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=8994

JSP's do not recompile





--- Additional Comments From [EMAIL PROTECTED]  2002-05-10 22:50 ---
Jasper 2 is buggy these days after some big refactorings. You can use Jasper 1
from other Tomcat releases with Tomcat 4.1, without changing anything else (just
replace the two Jasper 2 JARs in common/lib with the two Jasper 1 JARs and
you're done).

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




[4.1] Add additional events

2002-05-10 Thread Remy Maucherat

I plan to add additional events to the components start and stop methods:
before_start, after_start, before_stop, after_stop. This has been suggested
and discussed a while ago, but never actually implemented.

Remy


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




DO NOT REPLY [Bug 8994] - JSP's do not recompile

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8994.
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=8994

JSP's do not recompile





--- Additional Comments From [EMAIL PROTECTED]  2002-05-10 22:53 ---
I also have observed similar things.  When I modified a jsp file and hit the
reload button, it didn't get recompiled; but if I waited long enough (5 or 10
minutes), then the background compilation picked it up, and quietly compiled it
for me.  That's nice.

The current behavior is probably OK for most users, but not for page aurhtors,
who want to test the page rightaway.  Jaspe2 should start compilation when a
explicit request to do so is made.

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




[Coyote] Coyote 1.0b9 release notice

2002-05-10 Thread Remy Maucherat

I plan to release Coyote 1.0b9 at the same time as Tomcat 4.0.4 Beta 3
(enough delays, I'm doing it later this afternoon, hopefully).

The idea is to have TC 4.0.4b3 be a last beta before final, and Coyote 1.0
would also be released at the same time. I don't know how much this is
compatible with whatever work still needs to be done in JK2. If it's not,
then Coyote 1.0 will be released later (but obviously, it needs to be before
a 4.1.x Stable release).

Remy


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




Re: [Coyote] Coyote 1.0b9 release notice

2002-05-10 Thread costinm

On Fri, 10 May 2002, Remy Maucherat wrote:

 The idea is to have TC 4.0.4b3 be a last beta before final, and Coyote 1.0
 would also be released at the same time. I don't know how much this is
 compatible with whatever work still needs to be done in JK2. If it's not,
 then Coyote 1.0 will be released later (but obviously, it needs to be before
 a 4.1.x Stable release).

I am just running load tests with jk2, there are few minor tweaks I'll 
commit - but everything looks fine.

The work on jk2 will continue - on the new features - but I think 
we are already functionaly equivalent with jk1, and that part is 
stable in both java and C.


Costin


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





cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c jk_service_iis.c

2002-05-10 Thread nacho

nacho   02/05/10 16:15:35

  Modified:jk/native2/server/isapi jk_isapi_plugin.c jk_service_iis.c
  Log:
  * JK2 isapi redirector is working!!
  
  Found the latest blocking bug, now needs extensive testing :)
  
  Revision  ChangesPath
  1.14  +9 -6  
jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c
  
  Index: jk_isapi_plugin.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- jk_isapi_plugin.c 4 May 2002 19:06:31 -   1.13
  +++ jk_isapi_plugin.c 10 May 2002 23:15:35 -  1.14
  @@ -60,7 +60,7 @@
* Author:  Gal Shachor [EMAIL PROTECTED]   *
* Author:  Larry Isaacs [EMAIL PROTECTED]   *
* Author:  Ignacio J. Ortega [EMAIL PROTECTED]   *
  - * Version: $Revision: 1.13 $   *
  + * Version: $Revision: 1.14 $   *
***/
   
   // This define is needed to include wincrypt,h, needed to get client certificates
  @@ -181,8 +181,8 @@
   DWORD dwNotificationType, 
   LPVOID pvNotification)
   {
  -jk_env_t *env; 
  -jk_uriEnv_t *uriEnv;
  +jk_env_t *env=NULL; 
  +jk_uriEnv_t *uriEnv=NULL;
   
   /* Initialise jk */
   if (is_inited  !is_mapread) {
  @@ -480,6 +480,12 @@
   
   if (JK_OK == worker-service(env, worker, s)){
   rc=HSE_STATUS_SUCCESS;
  +lpEcb-dwHttpStatusCode = HTTP_STATUS_OK;
  +env-l-jkLog(env, env-l,  JK_LOG_DEBUG, 
  +   HttpExtensionProc service() returned OK\n);
  +} else {
  +env-l-jkLog(env, env-l,  JK_LOG_DEBUG, 
  +   HttpExtensionProc service() Failed\n);
   }
   
   s-afterRequest(env, s);
  @@ -488,9 +494,6 @@
   
   rc1=worker-rPoolCache-put( env, worker-rPoolCache, rPool );
   
  -lpEcb-dwHttpStatusCode = HTTP_STATUS_OK;
  -env-l-jkLog(env, env-l,  JK_LOG_DEBUG, 
  -   HttpExtensionProc service() returned OK\n);
   } else {
   env-l-jkLog(env, env-l,  JK_LOG_ERROR, 
  HttpExtensionProc error, not initialized\n);
  
  
  
  1.15  +1 -0  
jakarta-tomcat-connectors/jk/native2/server/isapi/jk_service_iis.c
  
  Index: jk_service_iis.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/jk_service_iis.c,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- jk_service_iis.c  4 May 2002 19:06:31 -   1.14
  +++ jk_service_iis.c  10 May 2002 23:15:35 -  1.15
  @@ -143,6 +143,7 @@
   strcat(headers_str, s-headers_out-valueAt(env,s-headers_out,i));
   strcat(headers_str, crlf);
   }
  +strcat(headers_str, crlf);
   } else {
   headers_str = crlf;
   }
  
  
  

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




[JK2] The IIS Connector is ( more or less ) working!!

2002-05-10 Thread Ignacio J. Ortega

Good news, finally got the time to catch the last blocking bug in IIS
jk2 connector, well big words ;),  at least now we can issue tests to
discover new bugs :), isapi_redirector2.dll is mostly working !!  ;)

I will clean a bit the registry configs needed, right now the code gets
4 registry settings:  extension_uri, server_root,uri_select,
worker_file.

I think we can use server_root, and use relative paths from there from
the wk2.p file, and get rid of worker_file.

uri_select ? wk2.p let us specify the uri_select setting, so is needed
to have this in the registry?

Right now i'm trying some tests, later i will try  watchdog, to see what
happens, some ab.. :) and so on..

I will try to see if i can get JNI to work, it seems i need APR in IIS
too, right?

Costin, Can you summarize a bit, what i need to build and use to have
tc33  tc40 working with JNI?

Saludos ,
Ignacio J. Ortega

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




Re: [Coyote] Coyote 1.0b9 release notice

2002-05-10 Thread Jon Scott Stevens

on 5/10/02 3:57 PM, Remy Maucherat [EMAIL PROTECTED] wrote:

 I plan to release Coyote 1.0b9 at the same time as Tomcat 4.0.4 Beta 3
 (enough delays, I'm doing it later this afternoon, hopefully).
 
 The idea is to have TC 4.0.4b3 be a last beta before final, and Coyote 1.0
 would also be released at the same time. I don't know how much this is
 compatible with whatever work still needs to be done in JK2. If it's not,
 then Coyote 1.0 will be released later (but obviously, it needs to be before
 a 4.1.x Stable release).
 
 Remy

My only semi-major complaint about Coyote (and I told Remy about this in
person) is that the container now returns 503 errors until the servlet is
started. Before, it would block (not quickly return a 503) until the servlet
is finished starting.

Remy said it was a result of the new threading that Costin put into things.

That said, when the classloader is dumped and reloaded as a result of a
resource change, the container (properly) blocks until the servlet is
reloaded.

Now, why reloading behavior is different than startup behavior, I don't
know.

-jon


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




cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3 Tomcat3Adapter.java

2002-05-10 Thread costin

costin  02/05/10 16:30:18

  Modified:coyote/src/java/org/apache/coyote/tomcat3
Tomcat3Adapter.java
  Log:
  Set the note, otherwise the object is not reused.
  ( thanks OptimizeIt :-)
  
  Revision  ChangesPath
  1.3   +1 -0  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/Tomcat3Adapter.java
  
  Index: Tomcat3Adapter.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/Tomcat3Adapter.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- Tomcat3Adapter.java   9 Apr 2002 18:37:24 -   1.2
  +++ Tomcat3Adapter.java   10 May 2002 23:30:18 -  1.3
  @@ -107,6 +107,7 @@
   
   reqA.setCoyoteRequest(request);
   resA.setCoyoteResponse(response);
  +request.setNote( containerRequestNOTE, reqA );
   } else {
   resA=(Tomcat3Response)reqA.getResponse();
   }
  
  
  

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




cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http MimeHeaders.java

2002-05-10 Thread costin

costin  02/05/10 16:31:26

  Modified:util/java/org/apache/tomcat/util/http MimeHeaders.java
  Log:
  Just a change in the param name - it's 'len', not 'end'
  
  Revision  ChangesPath
  1.4   +4 -4  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/MimeHeaders.java
  
  Index: MimeHeaders.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/MimeHeaders.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- MimeHeaders.java  9 Mar 2002 18:54:28 -   1.3
  +++ MimeHeaders.java  10 May 2002 23:31:26 -  1.4
  @@ -281,19 +281,19 @@
The conversion to chars can be delayed until
encoding is known.
*/
  -public MessageBytes addValue(byte b[], int startN, int endN)
  +public MessageBytes addValue(byte b[], int startN, int len)
   {
MimeHeaderField mhf=createHeader();
  - mhf.getName().setBytes(b, startN, endN);
  + mhf.getName().setBytes(b, startN, len);
return mhf.getValue();
   }
   
   /** Create a new named header using translated char[].
*/
  -public MessageBytes addValue(char c[], int startN, int endN)
  +public MessageBytes addValue(char c[], int startN, int len)
   {
MimeHeaderField mhf=createHeader();
  - mhf.getName().setChars(c, startN, endN);
  + mhf.getName().setChars(c, startN, len);
return mhf.getValue();
   }
   
  
  
  

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




cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util IntrospectionUtils.java

2002-05-10 Thread costin

costin  02/05/10 16:32:14

  Modified:util/java/org/apache/tomcat/util IntrospectionUtils.java
  Log:
  Very strange, sometimes it's Boolean.
  
  Revision  ChangesPath
  1.3   +6 -2  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/IntrospectionUtils.java
  
  Index: IntrospectionUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/IntrospectionUtils.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- IntrospectionUtils.java   22 Mar 2002 04:12:01 -  1.2
  +++ IntrospectionUtils.java   10 May 2002 23:32:14 -  1.3
  @@ -349,6 +349,9 @@
setPropertyMethod.invoke( o, params );
}
   
  + } catch( IllegalArgumentException ex2 ) {
  +System.err.println(IAE  + o +   + name +   + value);
  +ex2.printStackTrace();
} catch( SecurityException ex1 ) {
if( dbg  0 )
d(SecurityException for  + o.getClass() +   +
  @@ -623,6 +626,7 @@
getOptions1, new Class[] {} )) {
args0=(String[])callMethod0( proxy, getOptions1);
}
  +
if( args0==null ) {
//args0=findVoidSetters(proxy.getClass());
args0=findBooleanSetters(proxy.getClass());
  @@ -706,10 +710,10 @@
for( int i=0; im.length; i++ ) {
if( m[i].getName().startsWith(set) 
m[i].getParameterTypes().length == 1 
  - boolean.equals( m[i].getParameterTypes()[0].getName()) ) {
  + boolean.equalsIgnoreCase( m[i].getParameterTypes()[0].getName()) ) {
String arg=m[i].getName().substring( 3 );
v.addElement( unCapitalize( arg ));
  - }
  + } 
}
String s[]=new String[v.size()];
for( int i=0; is.length; i++ ) {
  
  
  

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




cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/apr TomcatStarter.java

2002-05-10 Thread costin

costin  02/05/10 16:34:12

  Modified:jk/java/org/apache/jk/apr TomcatStarter.java
  Log:
  Sometimes BootstrapService is not compiled in.
  
  In 4.1 it requires daemon - that's a problem ( IMHO ), there are
  other uses of Service ( like embeding, etc ) and it shouldn't have
  this dep ( especially since it isn't 1.0 )
  
  For now we'll just use Bootstrap.
  
  Revision  ChangesPath
  1.7   +2 -1  
jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/TomcatStarter.java
  
  Index: TomcatStarter.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/TomcatStarter.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- TomcatStarter.java7 May 2002 20:33:00 -   1.6
  +++ TomcatStarter.java10 May 2002 23:34:12 -  1.7
  @@ -17,7 +17,8 @@
   String args[];
   
   public static String mainClasses[]={ org.apache.tomcat.startup.Main,
  - 
org.apache.catalina.startup.BootstrapService };
  + 
org.apache.catalina.startup.BootstrapService,
  + org.apache.catalina.startup.Bootstrap};
   
   // If someone has time - we can also guess the classpath and do other
   // fancy guessings.
  
  
  

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




Re: [JK2] The IIS Connector is ( more or less ) working!!

2002-05-10 Thread costinm

On Sat, 11 May 2002, Ignacio J. Ortega wrote:

 Costin, Can you summarize a bit, what i need to build and use to have
 tc33  tc40 working with JNI?

Not much - you do need APR, you should use the version that is bundled 
with  Apache2.0 ( the DLL and includes ). 

Then compile with HAVE_JNI enabled, check the config of [vm], [worker.jni]
and [channel.jni].

The [vm] objects deals with loading the VM - it needs classpath and all 
the params.

[worker.jni] will execute a class ( calling main() ), you can include as 
many as you want ( but of course you need TomcatStarter if you want to run 
a version of tomcat ). 

[channel.jni] will forward the requests. 

You'll probably need to fix AprImpl a bit, right now there is a mod_jk.so
hardcoded and probably few other things need to change to get it to work 
on windows. If you can wait till next week, I can help with this part.

One important piece ( not related directly with jni ) is the jk_shm object
and Shm on java side. Those will play an important role, and we need to 
get them working on windows. Shm is not a big problem, if we get into 
problems we can use JDK1.4's nio - i.e. no JNI is needed.



Costin





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




Re: [Coyote] Coyote 1.0b9 release notice

2002-05-10 Thread costinm

On Fri, 10 May 2002, Jon Scott Stevens wrote:

 My only semi-major complaint about Coyote (and I told Remy about this in
 person) is that the container now returns 503 errors until the servlet is
 started. Before, it would block (not quickly return a 503) until the servlet
 is finished starting.
 
 Remy said it was a result of the new threading that Costin put into things.

Well, it is a result of the new threading in the sense that now it is 
possible to not block. If you want to bock there - it is quite easy to 
code this :-)

I think returning 503 is a correct behavior too - it means 'resource 
temporary unavailable, try later' - which is exactly the case. Apache 
should return the same result if it can't connect to tomcat.

Costin


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




cvs commit: jakarta-tomcat-connectors/webapp/docs warp.xml style.xsl

2002-05-10 Thread jfclere

jfclere 02/05/10 16:44:50

  Modified:webapp/docs style.xsl
  Added:   webapp/docs warp.xml
  Log:
  Add protocol description.
  
  Revision  ChangesPath
  1.4   +41 -1 jakarta-tomcat-connectors/webapp/docs/style.xsl
  
  Index: style.xsl
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/docs/style.xsl,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- style.xsl 5 May 2002 03:30:42 -   1.3
  +++ style.xsl 10 May 2002 23:44:50 -  1.4
  @@ -239,7 +239,7 @@
 /xsl:template
   
 xsl:template match=p
  -p class=sectionxsl:apply-templates select=b|a|text()//p
  +p class=sectionxsl:apply-templates select=table|ul|b|a|text()//p
 /xsl:template
   
 xsl:template match=b
  @@ -249,6 +249,46 @@
 xsl:template match=br
   br/
 /xsl:template
  +
  +  !-- JFC added --
  +  xsl:template match=ul
  +ulxsl:apply-templates select=li//ul
  +  /xsl:template
  +
  +  xsl:template match=li
  +lixsl:apply-templates select=text()//li
  +  /xsl:template
  +
  +  xsl:template match=table
  +table border=1xsl:apply-templates select=tr//table
  +  /xsl:template
  +
  +  xsl:template match=tr
  +trxsl:apply-templates select=td|td15|td13|td6|td5|td3|td2//tr
  +  /xsl:template
  +
  +  xsl:template match=td
  +tdxsl:apply-templates select=b|a|text()//td
  +  /xsl:template
  +  xsl:template match=td15
  +td colspan=15xsl:apply-templates select=b|a|text()//td
  +  /xsl:template
  +  xsl:template match=td13
  +td colspan=13xsl:apply-templates select=b|a|text()//td
  +  /xsl:template
  +  xsl:template match=td6
  +td colspan=6xsl:apply-templates select=b|a|text()//td
  +  /xsl:template
  +  xsl:template match=td5
  +td colspan=5xsl:apply-templates select=b|a|text()//td
  +  /xsl:template
  +  xsl:template match=td3
  +td colspan=3xsl:apply-templates select=b|a|text()//td
  +  /xsl:template
  +  xsl:template match=td2
  +td colspan=2xsl:apply-templates select=b|a|text()//td
  +  /xsl:template
  +  !-- end JFC --
   
 xsl:template match=screen
   p class=screen
  
  
  
  1.1  jakarta-tomcat-connectors/webapp/docs/warp.xml
  
  Index: warp.xml
  ===
  ?xml version=1.0?
  
  document title=The WARP Protocol Version 1.0.2
description
  The WARP protocol element description. (1.0.2)
/description
  
section title=Data Packet Structure
  description
   General packet format.
  /description
  
  p
All data sent on the full duplex connection between the client and
server MUST follow this structure:
  /p
  p
  ul
  li
  Data is sent in packets formed by a header describing some info about the
  packet itself followed by a data length and data payload./li
  
  li
  All packets MUST follow big endian style (network order)./li
  
  li
  The packet header is always 24 bits long and follow this format:/li
  
  /ul
  ul
  li
  Octet 0 (8 bits) contains the packet type./li
  
  li
  Octets 1-2 (16 bits) set the length of the data payload carried by the
  packet itself in numbers octets and MAY be zero./li
  
  li
  If the length of the data payload is more than zero, octets from 3 to (length
  + 3) contain the payload data or content./li
  /ul
  
  /pp
  
  table
  
  tr
  td15
  WARP packet
  /td15
  /tr
  tr
  tdOctet/td
  
  td51/td5
  
  td32/td3
  
  td33/td3
  
  td34 .. (length+3)/td3
  /tr
  
  tr
  tdBits/td
  
  td0/td
  
  td1/td
  
  td../td
  
  td6/td
  
  td7/td
  
  td0/td
  
  td1/td
  
  td2../td2
  
  td14/td
  
  td15/td
  
  td0/td
  
  td1/td
  
  td../td
  /tr
  
  tr
  tdDescription/td
  
  td5Packet Type/td5
  
  td6Payload Length/td6
  
  td3Payload Data
  (Content)/td3
  /tr
  /table
  /p
  
  /section
  
  section title=Payload
description
Payload Structure
/description
  
  p
  The payload of a packet can be structured in two ways, depending on its
  type: the packet can either contain raw data (such as an HTTP request or
  response body) or a combination of numeric values and strings.
  /p
  pBy definition a numeric value is a 32 bit signed integer represented
  in network byte order (the value of 6 decimal would be represented as
   0110
  binary (110 preceeded by 29 zeroes).
  /ppA string is defined in the following way: the first two octets represent
  the string length as an unsigned 16 bits value. This value indicates the
  number of octets that compose the encoded string. The string is not NULL
  terminated and is encoded following the UTF-8 standard. For example the
  string fooBar would be represented as:
  /p
  p
  table
  tr
  td13
  String/td13
  /tr
  
  tr
  tdOctet/td
  
  td31/td3
  
  td32/td3
  
  td3/td
  
  td4/td
  
  td5/td
  
  td6/td
  
  td7/td
  
  td8/td
  /tr
  
  tr
  tdBits/td
  
  td0/td
  
  

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_registry.c

2002-05-10 Thread nacho

nacho   02/05/10 16:45:19

  Modified:jk/native2/common jk_registry.c
  Log:
  * More unix.sockets code ifdefed for Win32
  
  Revision  ChangesPath
  1.21  +6 -2  jakarta-tomcat-connectors/jk/native2/common/jk_registry.c
  
  Index: jk_registry.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_registry.c,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- jk_registry.c 9 May 2002 00:05:14 -   1.20
  +++ jk_registry.c 10 May 2002 23:45:18 -  1.21
  @@ -55,10 +55,12 @@
*   *
* = */
   
  +#include jk_global.h
  +
   #include jk_logger.h
   #include jk_pool.h
   #include jk_service.h
  -#include jk_env.h
  +#include jk_env.h 
   
   #ifdef HAS_APR
   #include apr.h
  @@ -69,7 +71,7 @@
   
   /***
* Description: Worker list*
  - * Version: $Revision: 1.20 $   *
  + * Version: $Revision: 1.21 $   *
***/
   
   /** Static declarations for all 'hardcoded' modules. This is a hack, 
  @@ -128,7 +130,9 @@
 env-registerFactory( env, run, jk2_worker_run_factory );
 env-registerFactory( env, worker.run, jk2_worker_run_factory );
   
  +#ifdef HAVE_UNIXSOCKETS
 env-registerFactory( env, channel.un, jk2_channel_un_factory );
  +#endif
   
   #ifdef HAS_APR
 env-registerFactory( env, channel.apr,
  
  
  

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




Re: [Coyote] Coyote 1.0b9 release notice

2002-05-10 Thread Jon Scott Stevens

on 5/10/02 4:42 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 Well, it is a result of the new threading in the sense that now it is
 possible to not block. If you want to bock there - it is quite easy to
 code this :-)
 
 I think returning 503 is a correct behavior too - it means 'resource
 temporary unavailable, try later' - which is exactly the case. Apache
 should return the same result if it can't connect to tomcat.
 
 Costin

Even if it is correct behavior in a technical sense, it isn't from a user
sense since users don't care or know what a 503 is.

Why not just block until the resource is available?

I personally consider this a bug since this is changed behavior from every
single previous release of Tomcat.

So, could you please code it up if it is easy?

-jon


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




cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common ChannelSocket.java

2002-05-10 Thread costin

costin  02/05/10 16:54:42

  Modified:jk/java/org/apache/jk/common ChannelSocket.java
  Log:
  Reduce the number of messages when the server dies ( or closes connections )
  
  Revision  ChangesPath
  1.12  +6 -3  
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java
  
  Index: ChannelSocket.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- ChannelSocket.java25 Apr 2002 23:13:24 -  1.11
  +++ ChannelSocket.java10 May 2002 23:54:42 -  1.12
  @@ -308,7 +308,7 @@
   
   if(rd  0) {
   // Most likely normal apache restart.
  -log.warn(Wrong message  + rd );
  +// log.warn(Wrong message  + rd );
   return rd;
   }
   
  @@ -378,7 +378,7 @@
   // This happens periodically, as apache restarts
   // periodically.
   // It should be more gracefull ! - another feature for Ajp14
  -log.warn( Read result -1, connection close by server );
  +// log.warn( server has closed the current connection (-1) );
   return -3;
   }
   
  @@ -418,7 +418,10 @@
   while( running ) {
   int status= this.receive( recv, ep );
   if( status = 0 ) {
  -log.warn(Invalid packet, closing connection );
  +if( status==-3)
  +log.warn( server has closed the current connection (-1) );
  +else 
  +log.warn(Closing ajp connection  + status );
   break;
   }
   
  
  
  

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




cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common HandlerRequest.java

2002-05-10 Thread costin

costin  02/05/10 16:56:49

  Modified:jk/java/org/apache/jk/common HandlerRequest.java
  Log:
  Few more optimizations ( again thanks to OptimizeIt ).
  
  Header processing is updated from the Ajp13 interceptor in 33 for
  less allocation ( 3-4 strings per req ), also few debugs need to check if debug is 
enabled.
  
  Revision  ChangesPath
  1.12  +14 -7 
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java
  
  Index: HandlerRequest.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- HandlerRequest.java   17 Apr 2002 22:38:42 -  1.11
  +++ HandlerRequest.java   10 May 2002 23:56:49 -  1.12
  @@ -329,7 +329,8 @@
   tmpMB=new MessageBytes();
   ep.setNote( tmpBufNote, tmpMB);
   }
  -log.debug( Handling  + type );
  +if( log.isDebugEnabled() )
  +log.debug( Handling  + type );
   
   switch( type ) {
   case JK_AJP13_FORWARD_REQUEST:
  @@ -352,7 +353,8 @@
 next.getClass().getName());
   
   int err= next.invoke( msg, ep );
  -log.debug( Invoke returned  + err );
  +if( log.isDebugEnabled() )
  +log.debug( Invoke returned  + err );
   return err;
   case JK_AJP13_SHUTDOWN:
   String epSecret=null;
  @@ -364,7 +366,8 @@
   
   if( requiredSecret != null 
   requiredSecret.equals( epSecret ) ) {
  -log.debug(Received wrong secret, no shutdown );
  +if( log.isDebugEnabled() )
  +log.debug(Received wrong secret, no shutdown );
   return ERROR;
   }
   
  @@ -591,6 +594,7 @@
   if(0xA000 == isc) {
   msg.getInt(); // To advance the read position
   hName = headerTransArray[hId - 1];
  +vMB=headers.addValue( hName );
   } else {
   // reset hId -- if the header currently being read
   // happens to be 7 or 8 bytes long, the code below
  @@ -600,19 +604,22 @@
   // behaviour.  see bug 5861 for more information.
   hId = -1;
   msg.getBytes( tmpMB );
  -hName=tmpMB.toString();
  +ByteChunk bc=tmpMB.getByteChunk();
  +//hName=tmpMB.toString();
  +//vMB=headers.addValue( hName );
  +vMB=headers.addValue( bc.getBuffer(),
  +  bc.getStart(), bc.getLength() );
   }
   
  -vMB=headers.addValue( hName );
   msg.getBytes(vMB);
   
   if (hId == SC_REQ_CONTENT_LENGTH ||
  -hName.equalsIgnoreCase(Content-Length)) {
  +tmpMB.equalsIgnoreCase(Content-Length)) {
   // just read the content-length header, so set it
   int contentLength = (vMB == null) ? -1 : vMB.getInt();
   req.setContentLength(contentLength);
   } else if (hId == SC_REQ_CONTENT_TYPE ||
  -   hName.equalsIgnoreCase(Content-Type)) {
  +   tmpMB.equalsIgnoreCase(Content-Type)) {
   // just read the content-type header, so set it
   ByteChunk bchunk = vMB.getByteChunk();
   req.contentType().setBytes(bchunk.getBytes(),
  
  
  

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




cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java

2002-05-10 Thread costin

costin  02/05/10 16:57:35

  Modified:jk/java/org/apache/jk/server JkCoyoteHandler.java
  Log:
  That's an important one - without it mod_jk1 will no recycle the connection.
  
  Revision  ChangesPath
  1.20  +1 -1  
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java
  
  Index: JkCoyoteHandler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- JkCoyoteHandler.java  9 May 2002 23:46:33 -   1.19
  +++ JkCoyoteHandler.java  10 May 2002 23:57:35 -  1.20
  @@ -297,7 +297,7 @@
   MsgAjp msg=(MsgAjp)ep.getNote( headersMsgNote );
   msg.reset();
   msg.appendByte( HandlerRequest.JK_AJP13_END_RESPONSE );
  -msg.appendInt( 1 );
  +msg.appendByte( 1 );
   
   ep.setType( JkHandler.HANDLE_SEND_PACKET );
   ep.getSource().invoke( msg, ep );
  
  
  

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




cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c

2002-05-10 Thread costin

costin  02/05/10 16:58:40

  Modified:jk/native/common jk_ajp_common.c
  Log:
  Add a debug message if the connection is not reused.
  
  Revision  ChangesPath
  1.25  +14 -11jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
  
  Index: jk_ajp_common.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- jk_ajp_common.c   13 Feb 2002 01:07:18 -  1.24
  +++ jk_ajp_common.c   10 May 2002 23:58:40 -  1.25
  @@ -59,7 +59,7 @@
* Description: common stuff for bi-directional protocols ajp13/ajp14. *
* Author:  Gal Shachor [EMAIL PROTECTED]   *
* Author:  Henri Gomez [EMAIL PROTECTED]   *
  - * Version: $Revision: 1.24 $   *
  + * Version: $Revision: 1.25 $   *
***/
   
   
  @@ -455,8 +455,9 @@
   }
   
   d-msg = (char *)jk_b_get_string(msg);
  -if (d-msg)
  +if (d-msg) {
   jk_xlate_from_ascii(d-msg, strlen(d-msg));
  +}
   
   jk_log(l, JK_LOG_DEBUG, ajp_unmarshal_response: status = %d\n, d-status);
   
  @@ -756,7 +757,7 @@
   static int ajp_read_into_msg_buff(ajp_endpoint_t  *ae,
 jk_ws_service_t *r,
 jk_msg_buf_t*msg,
  -  unsigned len,
  +  int len,
 jk_logger_t *l)
   {
   unsigned char *read_buf = jk_b_get_buff(msg);
  @@ -875,7 +876,7 @@
 * doing a read (not yet) 
 */
if (s-is_chunked || ae-left_bytes_to_send  0) {
  - unsigned len = ae-left_bytes_to_send;
  + int len = ae-left_bytes_to_send;
if (len  AJP13_MAX_SEND_BODY_SZ) 
len = AJP13_MAX_SEND_BODY_SZ;
if ((len = ajp_read_into_msg_buff(ae, s, op-post, len, l))  
0) {
  @@ -937,7 +938,7 @@
   
   case JK_AJP13_GET_BODY_CHUNK:
   {
  - unsigned len = (unsigned)jk_b_get_int(msg);
  + int len = (int)jk_b_get_int(msg);
   
   if(len  AJP13_MAX_SEND_BODY_SZ) {
   len = AJP13_MAX_SEND_BODY_SZ;
  @@ -963,13 +964,16 @@
   case JK_AJP13_END_RESPONSE:
   {
   ae-reuse = (int)jk_b_get_byte(msg);
  -
  -if((ae-reuse  0X01) != ae-reuse) {
  +
  +if( ! ae-reuse ) {
   /*
* Strange protocol error.
*/
  +jk_log(l, JK_LOG_DEBUG, Reuse: %d\n, ae-reuse );
   ae-reuse = JK_FALSE;
   }
  +/* Reuse in all cases */
  +ae-reuse = JK_TRUE;
   }
   return JK_AJP13_END_RESPONSE;
break;
  @@ -1304,8 +1308,6 @@
   int JK_METHOD ajp_done(jk_endpoint_t **e,
  jk_logger_t*l)
   {
  -jk_log(l, JK_LOG_DEBUG, Into jk_endpoint_t::done\n);
  -
   if (e  *e  (*e)-endpoint_private) {
   ajp_endpoint_t *p = (*e)-endpoint_private;
   int reuse_ep = p-reuse;
  @@ -1328,12 +1330,13 @@
   }
   JK_LEAVE_CS(w-cs, rc);
   if(i  w-ep_cache_sz) {
  -return JK_TRUE;
  +jk_log(l, JK_LOG_DEBUG, Into jk_endpoint_t::done, 
recycling connection\n);
  +return JK_TRUE;
   }
   }
   }
   }
  -
  +jk_log(l, JK_LOG_DEBUG, Into jk_endpoint_t::done, closing connection 
%d\n, reuse_ep);
   ajp_close_endpoint(p, l);
   *e = NULL;
   
  
  
  

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




Re: [4.1] Add additional events

2002-05-10 Thread Craig R. McClanahan



On Fri, 10 May 2002, Remy Maucherat wrote:

 Date: Fri, 10 May 2002 15:51:26 -0700
 From: Remy Maucherat [EMAIL PROTECTED]
 Reply-To: Tomcat Developers List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: [4.1] Add additional events

 I plan to add additional events to the components start and stop methods:
 before_start, after_start, before_stop, after_stop. This has been suggested
 and discussed a while ago, but never actually implemented.


Are you thinking about adding new method calls to the Lifecycle interface,
versus just some new event types?  If it's the former, a couple of
thoughts:

* The initialize() method was added to o.a.c.Connector, primarily
  to provide what I imagine you're thinking of as before_start --
  I'd suggest either using this name or migrating it to before_start.

* There are quite a number of places that components implementing
  Lifecycle are started and stopped dynamically -- dealing with
  them all is a non-trivial amount of editing (although the changes
  required are pretty straightforward).

Adding just the extra event notifications makes sense, and is somewhat
easier (although you still have to fire them from all the appropriate
places), but doesn't give you quite as much flexibility in managing things
since the listeners don't throw a checked exception.

 Remy


Craig


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




cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_apr_socket.c

2002-05-10 Thread costin

costin  02/05/10 17:02:00

  Modified:jk/native2/common jk_channel_apr_socket.c
  Log:
  remove the unix socket code, clean up - now it's apr socket only.
  
  Revision  ChangesPath
  1.15  +44 -182   
jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c
  
  Index: jk_channel_apr_socket.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- jk_channel_apr_socket.c   3 May 2002 22:12:17 -   1.14
  +++ jk_channel_apr_socket.c   11 May 2002 00:02:00 -  1.15
  @@ -56,17 +56,7 @@
* = */
   
   /**
  - * Channel using 'plain' TCP sockets or UNIX sockets.
  - * Based on jk_sockbuf. It uses a an APR-based mechanism.
  - * The UNIX sockets are not yet in APR (the code has to been written).
  - * 
  - * Properties:
  - *  - host/filename
  - *  - port
  - *  - ndelay (Where the hell we set it?)
  - *
  - * This channel should 'live' as much as the workerenv. It is stateless.
  - * It allocates memory for endpoint private data ( using endpoint's pool ).
  + * Channel using APR sockets.
*
* @author:  Gal Shachor [EMAIL PROTECTED]   
* @author: Costin Manolache
  @@ -87,18 +77,12 @@
   
   
   #define DEFAULT_HOST 127.0.0.1
  -#define TYPE_UNIX 1 /* to be move in APR. */
  -#define TYPE_NET  2 /* to be move in APR. */
   
   /** Information specific for the socket channel
*/
   struct jk_channel_apr_private {
   int ndelay;
   apr_sockaddr_t *addr;
  -#ifdef HAVE_UNIXSOCKETS
  -struct sockaddr_un unix_addr;
  -#endif
  -int type; /* AF_INET or AF_UNIX */
   char *host;
   short port;
   };
  @@ -106,11 +90,7 @@
   /** Informations for each connection
*/
   typedef struct jk_channel_apr_data {
  -int type; /* AF_INET or AF_UNIX */
   apr_socket_t *sock;
  -#ifdef HAVE_UNIXSOCKETS
  -int unixsock;
  -#endif
   } jk_channel_apr_data_t;
   
   typedef struct jk_channel_apr_private jk_channel_apr_private_t;
  @@ -144,9 +124,6 @@
   socketInfo-host=value;
   } else if( strcmp( port, name ) == 0 ) {
   socketInfo-port=atoi( value );
  -} else if( strcmp( file, name ) == 0 ) {
  -socketInfo-host=value;
  -socketInfo-type=AF_UNIX;
   } else {
if( ch-worker!=NULL ) {
   return ch-worker-mbean-setAttribute( env, ch-worker-mbean, name, 
valueP );
  @@ -159,28 +136,33 @@
   /** resolve the host IP ( jk_resolve ) and initialize the channel.
*/
   static int JK_METHOD jk2_channel_apr_init(jk_env_t *env,
  -  jk_channel_t *_this)
  +  jk_channel_t *ch)
   {
   jk_channel_apr_private_t *socketInfo=
  -(jk_channel_apr_private_t *)(_this-_privatePtr);
  +(jk_channel_apr_private_t *)(ch-_privatePtr);
   int rc;
   short port=socketInfo-port;
   
   if( socketInfo-host==NULL ) {
  -char *localName=_this-mbean-localName;
  -jk_config_t *cfg=_this-workerEnv-config;
  +char *localName=ch-mbean-localName;
  +jk_config_t *cfg=ch-workerEnv-config;
   
  -/* Set the 'name' property
  - */
  -localName = jk2_config_replaceProperties(env, cfg-map, cfg-map-pool, 
localName);
  +char *portIdx=strchr( localName, ':' );
   
  -/*   env-l-jkLog(env, env-l, JK_LOG_INFO, */
  -/* channelApr.init(): use name %s\n, localName ); */
  -
  -if (localName[0]=='/') {
  -_this-mbean-setAttribute( env, _this-mbean, file, localName );
  +if( portIdx==NULL || portIdx[1]=='\0' ) {
  +socketInfo-port=8009;
   } else {
  -_this-mbean-setAttribute( env, _this-mbean, host, localName );
  +portIdx++;
  +socketInfo-port=atoi( portIdx );
  +}
  +
  +if( socketInfo-host==NULL ) {
  +socketInfo-host=ch-mbean-pool-calloc( env, ch-mbean-pool, strlen( 
localName ) + 1 );
  +if( portIdx==NULL ) {
  +strcpy( socketInfo-host, localName );
  +} else {
  +strncpy( socketInfo-host, localName, portIdx-localName-1 );
  +}
   }
   }
   
  @@ -205,34 +187,14 @@
char *host, short port,
jk_channel_apr_private_t *rc)
   {
  -/*
  - * If the hostname is an absolut path, we want a UNIX socket.
  - * otherwise it is a TCP/IP socket.
  - */ 
  -/*env-l-jkLog(env, env-l, JK_LOG_ERROR, */
  -/*   jk2_channel_apr_resolve: %s %d\n, */
  -/*   

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_jni.c

2002-05-10 Thread costin

costin  02/05/10 17:02:53

  Modified:jk/native2/common jk_channel_jni.c
  Log:
  Display a small warning if getArray() doesn't pin, it's an indication
  of possible performance problems.
  
  Revision  ChangesPath
  1.17  +14 -4 jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c
  
  Index: jk_channel_jni.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- jk_channel_jni.c  10 May 2002 00:01:37 -  1.16
  +++ jk_channel_jni.c  11 May 2002 00:02:53 -  1.17
  @@ -317,7 +317,7 @@
   jbyte *nbuf;
   jbyteArray jbuf;
   int jlen;
  -jboolean iscommit=0;
  +jboolean iscopy=0;
   JNIEnv *jniEnv;
   jk_channel_jni_private_t *jniCh=_this-_privatePtr;
   jk_ch_jni_ep_private_t *epData=
  @@ -369,8 +369,15 @@
*  write method. XXX We could try 'pining' if the vm supports
*  it, this is a looong lived object.
*/
  -nbuf = (*jniEnv)-GetByteArrayElements(jniEnv, jbuf, iscommit);
  -
  +#ifdef JK_JNI_CRITICAL
  +nbuf = (*jniEnv)-GetPrimitiveArrayCritical(jniEnv, jbuf, iscopy);
  +#else
  +nbuf = (*jniEnv)-GetByteArrayElements(jniEnv, jbuf, iscopy);
  +#endif
  +if( iscopy )
  +env-l-jkLog(env, env-l, JK_LOG_INFO,
  +  channelJni.send() get java bytes iscopy %d\n, iscopy);
  +
   if(nbuf==NULL ) {
   env-l-jkLog(env, env-l, JK_LOG_ERROR,
 channelJni.send() Can't get java bytes);
  @@ -384,8 +391,11 @@
   
   memcpy( nbuf, b, len );
   
  +#ifdef JK_JNI_CRITICAL
  +(*jniEnv)-ReleasePrimitiveArrayCritical(jniEnv, jbuf, nbuf, 0);
  +#else
   (*jniEnv)-ReleaseByteArrayElements(jniEnv, jbuf, nbuf, 0);
  -
  +#endif
   if( _this-mbean-debug  0 )
   env-l-jkLog(env, env-l, JK_LOG_INFO,
 channel_jni.send() before send %p\n,
  
  
  

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




cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_ajp13.c

2002-05-10 Thread costin

costin  02/05/10 17:06:58

  Modified:jk/native2/common jk_worker_ajp13.c
  Log:
  Few ( bigger ) changes:
  
  - we no longer de-allocate the endpoint. The ep will store important statistics
  about request processing ( times, nr. of requests, etc ) - it's much better
  than the worker since an endpoint is active in a single thread, so we
  don't need atomic or syncs.
  
  - also check if we are connected ( right now we use sd, if it's 0 we
  assume it's not connected - we set it to -1 when we create the endpoint
  and after close, and set it to 0 if the channel doesn't do it - I could
  add a separate flag but I'm lazy today ).
  
  - few small fixes to make sure the endpoints are doing well.
  
  Revision  ChangesPath
  1.18  +75 -55jakarta-tomcat-connectors/jk/native2/common/jk_worker_ajp13.c
  
  Index: jk_worker_ajp13.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_ajp13.c,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- jk_worker_ajp13.c 9 May 2002 23:47:31 -   1.17
  +++ jk_worker_ajp13.c 11 May 2002 00:06:58 -  1.18
  @@ -166,8 +166,6 @@
   ajp14-route=value;
   } else if( strcmp( name, group )==0 ) {
   ajp14-groups-add( env, ajp14-groups, value, ajp14 );
  -} else if( strcmp( name, cachesize )==0 ) {
  -ajp14-cache_sz=atoi( value );
   } else if( strcmp( name, lb_factor )==0 ) {
   ajp14-lb_factor=atoi( value );
   } else if( strcmp( name, channel )==0 ) {
  @@ -220,10 +218,14 @@
   ae-reuse = JK_FALSE;
   if( ae-worker-channel != NULL )
   ae-worker-channel-close( env, ae-worker-channel, ae );
  +
   ae-cPool-reset( env, ae-cPool );
  -ae-cPool-close( env, ae-cPool );
  -ae-pool-reset( env, ae-pool );
  -ae-pool-close( env, ae-pool );
  +/* ae-cPool-close( env, ae-cPool ); */
  +
  +/* Don't touch the ae-pool, the object has important
  +   statistics */
  +/* ae-pool-reset( env, ae-pool ); */
  +/* ae-pool-close( env, ae-pool ); */
   }
   
   /** Connect a channel, implementing the logging protocol if ajp14
  @@ -252,6 +254,13 @@
   return JK_ERR;
   }
   
  +/* We just reconnected, reset error state
  + */
  +ae-worker-in_error_state=0;
  +
  +/** XXX use a 'connected' field */
  +if( ae-sd == -1 ) ae-sd=0;
  +
   /* Check if we must execute a logon after the physical connect */
   if (ae-worker-secret == NULL)
   return JK_OK;
  @@ -294,7 +303,7 @@
 jk_endpoint_t   *e )
   {
   int attempt;
  -int err;
  +int err=JK_OK;
   
   /*
* Try to send the request on a valid endpoint. If one endpoint
  @@ -306,11 +315,20 @@
   for(attempt = 0 ; attempt  JK_RETRIES ;attempt++) {
   jk_channel_t *channel= worker-channel;
   
  +if( e-sd == -1 ) {
  +err=jk2_worker_ajp14_connect(env, e);
  +if( err!=JK_OK ) {
  +env-l-jkLog(env, env-l, JK_LOG_ERROR,
  +  ajp14.service() failed to connect endpoint errno=%d 
%s\n,
  +  errno, strerror( errno ));
  +return err;
  +}
  +}
   /* e-request-dump(env, e-request, Before sending ); */
   err=e-worker-channel-send( env, e-worker-channel, e,
 e-request );
  -
  - if (err==JK_OK ) {
  +e-request-dump( env, e-request, Sent );
  +if (err==JK_OK ) {
   /* We sent the request, have valid endpoint */
   break;
   }
  @@ -323,11 +341,10 @@
   }
   
   env-l-jkLog(env, env-l, JK_LOG_ERROR,
  -ajp14.service() error sending, reconnect %s %s\n,
  -  e-worker-mbean-name, e-worker-channelName);
  +  ajp14.service() error sending, reconnect %s %d %d %s\n,
  +  e-worker-channelName, err, errno, strerror(errno));
   
   channel-close( env, channel, e );
  -
   err=jk2_worker_ajp14_connect(env, e); 
   
   if( err != JK_OK ) {
  @@ -386,10 +403,6 @@
  e-post );
   }
   
  -if( e-worker-mbean-debug  0 )
  -env-l-jkLog(env, env-l, JK_LOG_INFO,
  -  ajp14.service() processing callbacks %s\n, 
e-worker-channel-mbean-name);
  -
   err = e-worker-workerEnv-processCallbacks(env, e-worker-workerEnv,
e, s);
   
  @@ -515,31 +528,35 @@
   jk2_worker_ajp14_done(jk_env_t *env, jk_worker_t *we, jk_endpoint_t *e)
   {
   jk_worker_t *w;
  +int rc=JK_OK;
   
   w= e-worker;
   
   if( e-cPool != NULL ) 
   e-cPool-reset(env, e-cPool);
  -if (! 

cvs commit: jakarta-tomcat-connectors/jk/native2/jni jk_jni_aprImpl.c

2002-05-10 Thread costin

costin  02/05/10 17:07:26

  Modified:jk/native2/jni jk_jni_aprImpl.c
  Log:
  Similar warnings if the array is not pinned.
  
  Revision  ChangesPath
  1.17  +20 -11jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c
  
  Index: jk_jni_aprImpl.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- jk_jni_aprImpl.c  9 May 2002 23:47:32 -   1.16
  +++ jk_jni_aprImpl.c  11 May 2002 00:07:26 -  1.17
  @@ -436,18 +436,23 @@
   JNIEXPORT jint JNICALL 
   Java_org_apache_jk_apr_AprImpl_unRead(JNIEnv *jniEnv, jobject _jthis, 
 jlong poolJ, jlong unSocketJ,
  -  jbyteArray bufJ, jint from, jint cnt)
  +  jbyteArray jbuf, jint from, jint cnt)
   {
   apr_pool_t *pool=(apr_pool_t *)(void *)(long)poolJ;
   jbyte *nbuf;
   int rd;
  -jboolean iscommit;
  +jboolean iscopy;
   
  -nbuf = (*jniEnv)-GetByteArrayElements(jniEnv, bufJ, iscommit);
  +/* We can't use Critical with blocking ops. 
  + */
  +nbuf = (*jniEnv)-GetByteArrayElements(jniEnv, jbuf, iscopy);
   if( ! nbuf ) {
   return -1;
   }
   
  +if( iscopy==JNI_TRUE )
  +fprintf( stderr, aprImpl.unRead() get java bytes iscopy %d\n, iscopy);
  +
   while( 1 ) {
   /* Read */
   rd=read( (int)unSocketJ, nbuf + from, cnt );
  @@ -458,29 +463,29 @@
   } else {
   fprintf(stderr, Error reading %d %d %s\n,
   (int)unSocketJ, errno, strerror(errno));
  -(*jniEnv)-ReleaseByteArrayElements(jniEnv, bufJ, nbuf, 0);
  +(*jniEnv)-ReleaseByteArrayElements(jniEnv, jbuf, nbuf, 0);
   return -1;
   }
   }
   /* fprintf(stderr, Read %d from %d\n, */
   /* rd, unSocketJ); */
   
  -(*jniEnv)-ReleaseByteArrayElements(jniEnv, bufJ, nbuf, 0);
  +(*jniEnv)-ReleaseByteArrayElements(jniEnv, jbuf, nbuf, 0);
   return (jint)rd;
   }
   }
   
   JNIEXPORT jint JNICALL 
   Java_org_apache_jk_apr_AprImpl_unWrite(JNIEnv *jniEnv, jobject _jthis, 
  - jlong poolJ, jlong unSocketJ, jbyteArray bufJ, 
jint from, jint cnt)
  + jlong poolJ, jlong unSocketJ, jbyteArray jbuf, 
jint from, jint cnt)
   {
   apr_status_t status;
   apr_pool_t *pool=(apr_pool_t *)(void *)(long)poolJ;
   jbyte *nbuf;
   int rd;
  -jboolean iscommit;
  +jboolean iscopy;
   
  -nbuf = (*jniEnv)-GetByteArrayElements(jniEnv, bufJ, iscommit);
  +nbuf = (*jniEnv)-GetByteArrayElements(jniEnv, jbuf, iscopy);
   if( ! nbuf ) {
   return -1;
   }
  @@ -488,7 +493,7 @@
   /* write */
   write( (int) unSocketJ, nbuf + from, cnt );
   
  -(*jniEnv)-ReleaseByteArrayElements(jniEnv, bufJ, nbuf, 0);
  +(*jniEnv)-ReleaseByteArrayElements(jniEnv, jbuf, nbuf, 0);
   return (jint)rd;
   }
   
  @@ -707,7 +712,7 @@
   jk_endpoint_t *ep = compCtx-object;
   
   jbyte *nbuf;
  -jboolean iscommit;
  +jboolean iscopy;
   
   int cnt=0;
   jint rc = -1;
  @@ -715,7 +720,11 @@
   
   /*env-l-jkLog(env, env-l, JK_LOG_INFO,jkInvoke()\n); */
   
  -nbuf = (*jniEnv)-GetByteArrayElements(jniEnv, data, iscommit);
  +nbuf = (*jniEnv)-GetByteArrayElements(jniEnv, data, iscopy);
  +
  +if( iscopy )
  +env-l-jkLog(env, env-l, JK_LOG_INFO,
  +  aprImpl.jkInvoke() get java bytes iscopy %d\n, iscopy);
   
   if(nbuf==NULL) {
   env-l-jkLog(env, env-l, JK_LOG_ERROR, 
  
  
  

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




Re: [4.1] Add additional events

2002-05-10 Thread costinm


  I plan to add additional events to the components start and stop methods:
  before_start, after_start, before_stop, after_stop. This has been suggested
  and discussed a while ago, but never actually implemented.

Could you also add events for webapp add/remove/start/stop, and make sure
the events are propagated up to coyote ? 


Costin



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




Re: [4.1] Add additional events

2002-05-10 Thread Remy Maucherat

   I plan to add additional events to the components start and stop
methods:
   before_start, after_start, before_stop, after_stop. This has been
suggested
   and discussed a while ago, but never actually implemented.

 Could you also add events for webapp add/remove/start/stop, and make sure
 the events are propagated up to coyote ?

That's already there (more or less). You need to put a container listener on
the host and listen for Container.ADD_CHILD_EVENT (or REMOVE_CHILD_EVENT).

Remy


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




Re: [4.1] Add additional events

2002-05-10 Thread Remy Maucherat

 On Fri, 10 May 2002, Remy Maucherat wrote:

  Date: Fri, 10 May 2002 15:51:26 -0700
  From: Remy Maucherat [EMAIL PROTECTED]
  Reply-To: Tomcat Developers List [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Subject: [4.1] Add additional events
 
  I plan to add additional events to the components start and stop
methods:
  before_start, after_start, before_stop, after_stop. This has been
suggested
  and discussed a while ago, but never actually implemented.
 

 Are you thinking about adding new method calls to the Lifecycle interface,
 versus just some new event types?  If it's the former, a couple of
 thoughts:

I was only planning on new event types (4 of them, to be exact). I don't
remember who suggested that originally (maybe Bill). The two events used at
the moment (as well as their timing) will not be modified so that everything
remains backward compatible.

 * The initialize() method was added to o.a.c.Connector, primarily
   to provide what I imagine you're thinking of as before_start --
   I'd suggest either using this name or migrating it to before_start.

Actually, it was added to be able to call it through JNI, for the
port-80-without-root on unix.

 * There are quite a number of places that components implementing
   Lifecycle are started and stopped dynamically -- dealing with
   them all is a non-trivial amount of editing (although the changes
   required are pretty straightforward).

 Adding just the extra event notifications makes sense, and is somewhat
 easier (although you still have to fire them from all the appropriate
 places), but doesn't give you quite as much flexibility in managing things
 since the listeners don't throw a checked exception.

Adding the extra calls would break compatibility, and I don't think we
should do that.

Remy


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




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

2002-05-10 Thread manveen

manveen 02/05/10 17:39:48

  Modified:webapps/admin/service service.jsp
  Log:
  * Fix for validation messages not being shown on service page for create new service 
operation.
  
  Revision  ChangesPath
  1.17  +2 -1  jakarta-tomcat-4.0/webapps/admin/service/service.jsp
  
  Index: service.jsp
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/service/service.jsp,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- service.jsp   10 May 2002 22:41:41 -  1.16
  +++ service.jsp   11 May 2002 00:39:48 -  1.17
  @@ -24,9 +24,10 @@
  name=serviceForm property=objectName/
 bean:define id=thisServiceName type=java.lang.String
  name=serviceForm property=serviceName/
  -  html:hidden property=adminAction/
  +  html:hidden property=adminServiceName/
 html:hidden property=objectName/
 html:hidden property=engineObjectName/
  +  html:hidden property=adminAction/
 bean:define id=adminServiceName type=java.lang.String
  name=serviceForm property=adminServiceName/
   
  
  
  

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




DO NOT REPLY [Bug 8994] - JSP's do not recompile

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8994.
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=8994

JSP's do not recompile





--- Additional Comments From [EMAIL PROTECTED]  2002-05-11 01:01 ---
I didn't wait long enough then ;-)
Maybe we only need to make the check interval smaller then.

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




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

2002-05-10 Thread kinman

kinman  02/05/10 18:19:58

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
  Log:
  - Reverted to undo the last fix, as it fails on complicated tags.
  
  Revision  ChangesPath
  1.13  +6 -17 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- Generator.java9 May 2002 18:47:15 -   1.12
  +++ Generator.java11 May 2002 01:19:57 -  1.13
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
 1.12 2002/05/09 18:47:15 kinman Exp $
  - * $Revision: 1.12 $
  - * $Date: 2002/05/09 18:47:15 $
  + * $Header: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
 1.13 2002/05/11 01:19:57 kinman Exp $
  + * $Revision: 1.13 $
  + * $Date: 2002/05/11 01:19:57 $
*
* 
* 
  @@ -1070,10 +1070,6 @@
   out.print(tryBitVal.toString());
   out.println(););
   
  -out.printin(int ret = );
  -out.print(tagHandlerVar);
  -out.println(.doEndTag(););
  -
out.printin(if ();
out.print(tagEvalVar);
out.println( != javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE));
  @@ -1081,11 +1077,6 @@
out.printil(out = pageContext.popBody(););
out.popIndent();
   
  -out.printil(if (ret == 
javax.servlet.jsp.tagext.Tag.SKIP_PAGE));
  -out.pushIndent();
  -out.printil(return;);
  -out.popIndent();
  -
   finallies.beginPartMethod(tryBitVal.intValue());
   finallies.print(  if ();
   finallies.print(((Integer)tags.elementAt();
  @@ -1102,14 +1093,12 @@
out.printil(});
}
   
  -if (n.getBody() == null || !implementsBodyTag) {
  - out.printin(if ();
  - out.print(tagHandlerVar);
  - out.println(.doEndTag() == javax.servlet.jsp.tagext.Tag.SKIP_PAGE));
  - out.pushIndent();
  - out.printil(return;);
  - out.popIndent();
  -}
  + out.printin(if ();
  + out.print(tagHandlerVar);
  + out.println(.doEndTag() == javax.servlet.jsp.tagext.Tag.SKIP_PAGE));
  + out.pushIndent();
  + out.printil(return;);
  + out.popIndent();
   
// TryCatchFinally
if (implementsTryCatchFinally) {
  
  
  

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




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

2002-05-10 Thread remm

remm02/05/10 18:20:06

  Removed: catalina/src/share/org/apache/catalina/servlets Tag:
tomcat_40_branch SnoopAllServlet.java
  Log:
  - Port patch.
  - Remove SnoopAllServlet.

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




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

2002-05-10 Thread remm

remm02/05/10 18:20:15

  Modified:catalina Tag: tomcat_40_branch build.xml
  Log:
  - Port patch.
  - Remove SnoopAllServlet.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.60.2.12 +0 -7  jakarta-tomcat-4.0/catalina/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
  retrieving revision 1.60.2.11
  retrieving revision 1.60.2.12
  diff -u -r1.60.2.11 -r1.60.2.12
  --- build.xml 24 Mar 2002 06:37:10 -  1.60.2.11
  +++ build.xml 11 May 2002 01:20:14 -  1.60.2.12
  @@ -799,13 +799,6 @@
 /fileset
   /jar
   
  -!-- Servlets - Snoop Servlet --
  -jar jarfile=${catalina.deploy}/server/lib/servlets-snoop.jar
  -  fileset dir=${catalina.build}/server/classes
  -include name=org/apache/catalina/servlets/Snoop* /
  -  /fileset
  -/jar
  -
   !-- Servlets - SSI Servlet --
   jar jarfile=${catalina.deploy}/server/lib/servlets-ssi.renametojar
 fileset dir=${catalina.build}/server/classes
  
  
  

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




cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_requtil.c

2002-05-10 Thread nacho

nacho   02/05/10 18:20:44

  Modified:jk/native2/common jk_requtil.c
  Log:
  * Was not reading POST body, reversed a test, JK_OK is now false
  
  Revision  ChangesPath
  1.16  +1 -1  jakarta-tomcat-connectors/jk/native2/common/jk_requtil.c
  
  Index: jk_requtil.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_requtil.c,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- jk_requtil.c  9 May 2002 21:12:15 -   1.15
  +++ jk_requtil.c  11 May 2002 01:20:44 -  1.16
  @@ -436,7 +436,7 @@
   
   while(rdlen  padded_len) {
   unsigned this_time = 0;
  -if(!s-read(env, s, buf + rdlen, len - rdlen, this_time)) {
  +if(s-read(env, s, buf + rdlen, len - rdlen, this_time)) {
   return -1;
   }
   
  
  
  

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




[JK2] More news about IIS

2002-05-10 Thread Ignacio J. Ortega

jk2 IIS plugin isapi_redirector2.dll passes all watchdog but 1, and all
internals tests from tc33 but 1, the failure in watchdog is
GetMaxInactiveInterval_01Test, the one in the internals test, is bogus,
another test tied to Localized strings ( arghhh another one ), ;), so it
works and does very well under ab -n 1000 -c 40 ..

Saludos ,
Ignacio J. Ortega

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




DO NOT REPLY [Bug 8994] - JSP's do not recompile

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8994.
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=8994

JSP's do not recompile





--- Additional Comments From [EMAIL PROTECTED]  2002-05-11 01:39 ---
The default behaviour of jasper 2 is to recompile JSP pages in the background.
If you set the init parameter development=true it forces jasper 2 to do the
complete page outdated checks on each request instead of doing it in the
background.

Perhaps setting development=true should be the default setting in the
$TOMCAT_HOME/conf/web.xml.

Setting develoment=false could be done for production systems by the admin.

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




cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c

2002-05-10 Thread nacho

nacho   02/05/10 18:44:13

  Modified:jk/native2/server/isapi jk_isapi_plugin.c
  Log:
  * Fixed jkstatus, now works in IIS too
  
  Revision  ChangesPath
  1.15  +2 -1  
jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c
  
  Index: jk_isapi_plugin.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- jk_isapi_plugin.c 10 May 2002 23:15:35 -  1.14
  +++ jk_isapi_plugin.c 11 May 2002 01:44:13 -  1.15
  @@ -60,7 +60,7 @@
* Author:  Gal Shachor [EMAIL PROTECTED]   *
* Author:  Larry Isaacs [EMAIL PROTECTED]   *
* Author:  Ignacio J. Ortega [EMAIL PROTECTED]   *
  - * Version: $Revision: 1.14 $   *
  + * Version: $Revision: 1.15 $   *
***/
   
   // This define is needed to include wincrypt,h, needed to get client certificates
  @@ -474,6 +474,7 @@
   s-response_started = JK_FALSE;
   s-content_read = 0;
   s-ws_private = lpEcb;
  +s-workerEnv = workerEnv;
   
   /* Initialize the ws_service structure */
   s-init( env, s, worker, lpEcb );
  
  
  

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




cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.0.4.txt

2002-05-10 Thread remm

remm02/05/10 18:49:34

  Modified:.Tag: tomcat_40_branch RELEASE-NOTES-4.0.4.txt
  Log:
  - Status update.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.6   +15 -4 jakarta-tomcat-4.0/Attic/RELEASE-NOTES-4.0.4.txt
  
  Index: RELEASE-NOTES-4.0.4.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/Attic/RELEASE-NOTES-4.0.4.txt,v
  retrieving revision 1.1.2.5
  retrieving revision 1.1.2.6
  diff -u -r1.1.2.5 -r1.1.2.6
  --- RELEASE-NOTES-4.0.4.txt   29 Apr 2002 08:30:25 -  1.1.2.5
  +++ RELEASE-NOTES-4.0.4.txt   11 May 2002 01:49:34 -  1.1.2.6
  @@ -3,7 +3,7 @@
   Release Notes
   =
   
  -$Id: RELEASE-NOTES-4.0.4.txt,v 1.1.2.5 2002/04/29 08:30:25 remm Exp $
  +$Id: RELEASE-NOTES-4.0.4.txt,v 1.1.2.6 2002/05/11 01:49:34 remm Exp $
   
   
   
  @@ -44,6 +44,9 @@
This connector is disabled in the default configuration, but can be 
enabled by uncommenting an element in the server.xml configuration file.
   
  +[B3] Coyote:
  + Update to Coyote 1.0 Beta 9.
  +
   
   -
   Catalina New Features:
  @@ -82,9 +85,6 @@
   Generic Bug Fixes:
   --
   
  -[B3] Coyote:
  - Update to Coyote 1.0 Beta 5.
  -
   
   --
   Catalina Bug Fixes:
  @@ -141,6 +141,12 @@
   [B3] Coyote:
Implement getRemoteHost and getRemoteAddr.
   
  +[B3] ErrorReportValve:
  + Don't generate status reports for status codes below 300.
  +
  +[B3] SnoopAllServlet:
  + Remove servlet.
  +
   
   
   Jasper Bug Fixes:
  @@ -174,6 +180,7 @@
   [B1] 5422  HTTP Headers not being cleared after form authentication
   [B3] 5471  jspc -webapp option is broken due to namespace collisions
   [B1] 5647  AJP13 connector will not pass authentication requests
  +[B3] 5998  Exception hiding when a JspExceptioin is thrown by a tag
   [B1] 6090  Listener not instantiated in tld file
   [B1] 6201  ISO-8859-8-i  problem. (hebrew)
   [B1] 6221  Bug with jsp:plugin
  @@ -209,12 +216,16 @@
   [B2] 6982  Stop + start of the context makes weird things
   [B2] 7061  Servlet loaded TWICE on application startup?
   [B2] 7102  response.encodeURL() doesn't encode
  +[B3] 7124  MissingResourceException when translating an invalid setProperty tag
   [B2] 7171  FileStore directory must exists
   [B2] 7344  Tomcat appears to be case-sensitive with regard to the token Basic
  in Authorization request parameter
   [B3] 7488  JspC generates wrong package with -webapp on PC/DOS/NT/Win2k
   [B3] 7534  StackOverflowError in ChunkedOutputFilter.doWrite()
   [B3] 7170  JDBCStore doesn't work with Orcale 8.x
  +[B3] 7880  If a TLV flags flags an error during the translation phase, 
  +   a fatal translation error is not returned (HTTP 500)
  +[B3] 7993  parameters in jsp:plugin for jsp Document do not work
   [B3] 8092  Problems forwarding from an included servlet
   
   
  
  
  

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




cvs commit: jakarta-tomcat-4.0/lib commons-logging.jar tomcat-ajp.jar tomcat-coyote.jar tomcat-http11.jar tomcat-util.jar

2002-05-10 Thread remm

remm02/05/10 18:56:05

  Modified:lib  Tag: tomcat_40_branch commons-logging.jar
tomcat-ajp.jar tomcat-coyote.jar tomcat-http11.jar
tomcat-util.jar
  Log:
  - Update connector binaries.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.2   +73 -108   jakarta-tomcat-4.0/lib/Attic/commons-logging.jar
  
Binary file
  
  
  1.1.2.9   +70 -62jakarta-tomcat-4.0/lib/Attic/tomcat-ajp.jar
  
Binary file
  
  
  1.1.2.2   +170 -195  jakarta-tomcat-4.0/lib/Attic/tomcat-coyote.jar
  
Binary file
  
  
  1.1.2.2   +131 -116  jakarta-tomcat-4.0/lib/Attic/tomcat-http11.jar
  
Binary file
  
  
  1.1.2.8   +297 -167  jakarta-tomcat-4.0/lib/Attic/tomcat-util.jar
  
Binary file
  
  

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




cvs commit: jakarta-tomcat-4.0/webapps/ROOT index.html

2002-05-10 Thread remm

remm02/05/10 19:13:39

  Modified:webapps/ROOT Tag: tomcat_40_branch index.html
  Log:
  - Update version number.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.29.2.19 +1 -1  jakarta-tomcat-4.0/webapps/ROOT/Attic/index.html
  
  Index: index.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/ROOT/Attic/index.html,v
  retrieving revision 1.29.2.18
  retrieving revision 1.29.2.19
  diff -u -r1.29.2.18 -r1.29.2.19
  --- index.html26 Mar 2002 17:56:48 -  1.29.2.18
  +++ index.html11 May 2002 02:13:38 -  1.29.2.19
  @@ -44,7 +44,7 @@
   td align=left valign=top
   table
   trtd align=left valign=topbTomcat/b/td/tr
  -trtd align=left valign=topbVersion 4.0.4 Dev/b/td/tr
  +trtd align=left valign=topbVersion 4.0.4 Beta 
3/b/td/tr
   /table
   /td
   td align=righta href=http://jakarta.apache.org/;img 
src=jakarta-banner.gif height=100 width=350 border=0 alt=The Jakarta 
Project/a/td
  
  
  

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




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

2002-05-10 Thread remm

remm02/05/10 19:14:01

  Modified:catalina/src/share/org/apache/catalina Tag: tomcat_40_branch
Globals.java
  Log:
  - Update version number.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.39.2.20 +5 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java
  
  Index: Globals.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java,v
  retrieving revision 1.39.2.19
  retrieving revision 1.39.2.20
  diff -u -r1.39.2.19 -r1.39.2.20
  --- Globals.java  26 Mar 2002 17:56:48 -  1.39.2.19
  +++ Globals.java  11 May 2002 02:14:01 -  1.39.2.20
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java,v 
1.39.2.19 2002/03/26 17:56:48 remm Exp $
  - * $Revision: 1.39.2.19 $
  - * $Date: 2002/03/26 17:56:48 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java,v 
1.39.2.20 2002/05/11 02:14:01 remm Exp $
  + * $Revision: 1.39.2.20 $
  + * $Date: 2002/05/11 02:14:01 $
*
* 
*
  @@ -69,7 +69,7 @@
* Global constants that are applicable to multiple packages within Catalina.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.39.2.19 $ $Date: 2002/03/26 17:56:48 $
  + * @version $Revision: 1.39.2.20 $ $Date: 2002/05/11 02:14:01 $
*/
   
   public final class Globals {
  @@ -219,7 +219,7 @@
   /**
* The descriptive information about this server and version.
*/
  -public static final String SERVER_INFO = Apache Tomcat/4.0.4-dev;
  +public static final String SERVER_INFO = Apache Tomcat/4.0.4-b3;
   
   
   /**
  
  
  

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




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

2002-05-10 Thread remm

remm02/05/10 19:20:07

  Modified:catalina/src/share/org/apache/catalina Tag: tomcat_40_branch
Globals.java
  Log:
  - Revert version number.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.39.2.21 +5 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java
  
  Index: Globals.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java,v
  retrieving revision 1.39.2.20
  retrieving revision 1.39.2.21
  diff -u -r1.39.2.20 -r1.39.2.21
  --- Globals.java  11 May 2002 02:14:01 -  1.39.2.20
  +++ Globals.java  11 May 2002 02:20:07 -  1.39.2.21
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java,v 
1.39.2.20 2002/05/11 02:14:01 remm Exp $
  - * $Revision: 1.39.2.20 $
  - * $Date: 2002/05/11 02:14:01 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java,v 
1.39.2.21 2002/05/11 02:20:07 remm Exp $
  + * $Revision: 1.39.2.21 $
  + * $Date: 2002/05/11 02:20:07 $
*
* 
*
  @@ -69,7 +69,7 @@
* Global constants that are applicable to multiple packages within Catalina.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.39.2.20 $ $Date: 2002/05/11 02:14:01 $
  + * @version $Revision: 1.39.2.21 $ $Date: 2002/05/11 02:20:07 $
*/
   
   public final class Globals {
  @@ -219,7 +219,7 @@
   /**
* The descriptive information about this server and version.
*/
  -public static final String SERVER_INFO = Apache Tomcat/4.0.4-b3;
  +public static final String SERVER_INFO = Apache Tomcat/4.0.4-dev;
   
   
   /**
  
  
  

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




cvs commit: jakarta-tomcat-4.0/webapps/ROOT index.html

2002-05-10 Thread remm

remm02/05/10 19:20:38

  Modified:webapps/ROOT Tag: tomcat_40_branch index.html
  Log:
  - Revert version number.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.29.2.20 +1 -1  jakarta-tomcat-4.0/webapps/ROOT/Attic/index.html
  
  Index: index.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/ROOT/Attic/index.html,v
  retrieving revision 1.29.2.19
  retrieving revision 1.29.2.20
  diff -u -r1.29.2.19 -r1.29.2.20
  --- index.html11 May 2002 02:13:38 -  1.29.2.19
  +++ index.html11 May 2002 02:20:38 -  1.29.2.20
  @@ -44,7 +44,7 @@
   td align=left valign=top
   table
   trtd align=left valign=topbTomcat/b/td/tr
  -trtd align=left valign=topbVersion 4.0.4 Beta 
3/b/td/tr
  +trtd align=left valign=topbVersion 4.0.4 Dev/b/td/tr
   /table
   /td
   td align=righta href=http://jakarta.apache.org/;img 
src=jakarta-banner.gif height=100 width=350 border=0 alt=The Jakarta 
Project/a/td
  
  
  

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




Re: [4.1] Add additional events

2002-05-10 Thread costinm

On Fri, 10 May 2002, Remy Maucherat wrote:

I plan to add additional events to the components start and stop
 methods:
before_start, after_start, before_stop, after_stop. This has been
 suggested
and discussed a while ago, but never actually implemented.
 
  Could you also add events for webapp add/remove/start/stop, and make sure
  the events are propagated up to coyote ?
 
 That's already there (more or less). You need to put a container listener on
 the host and listen for Container.ADD_CHILD_EVENT (or REMOVE_CHILD_EVENT).

The problem is propagating it via Coyote actions to jk level. 

Costin


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




Re: [JK2] More news about IIS

2002-05-10 Thread costinm

On Sat, 11 May 2002, Ignacio J. Ortega wrote:

 jk2 IIS plugin isapi_redirector2.dll passes all watchdog but 1, and all
 internals tests from tc33 but 1, the failure in watchdog is
 GetMaxInactiveInterval_01Test, the one in the internals test, is bogus,
 another test tied to Localized strings ( arghhh another one ), ;), so it
 works and does very well under ab -n 1000 -c 40 ..

Great !


My tests have similar results with Apache2 on linux. Unfortunately
JNI with JDK1.4 is a bit more difficult than I expected - it didn't seem 
to find the JNI .so until I removed the 'endorsed libs' from 4.x
( 3.3 didn't have that and it worked fine ). I still have the problem
with a signal in JDK1.4/unix - but 1.3 seems fine in all combinations.
I haven't run the full watchdog - I'm just trying crazy combinations
( 3 VMs x 3 containers x 3 channels, but only one web server so far :-)

Costin


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




cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServletWrapper.java

2002-05-10 Thread remm

remm02/05/10 22:00:22

  Modified:jasper2/src/share/org/apache/jasper
EmbededServletOptions.java JspEngineContext.java
   jasper2/src/share/org/apache/jasper/servlet
JspServletWrapper.java
  Log:
  - AFAIK, the current code wasn't implementing reloading properly when
development = true.
  - This patch checks for an outdated JSP on every page access.
  - Defaults to development = true.
  - It could be a good idea to write some more visible docs on configuring
Jasper, and maybe add a page for configuring that and the default web.xml
in the admin webapp.
  
  Revision  ChangesPath
  1.4   +4 -4  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/EmbededServletOptions.java
  
  Index: EmbededServletOptions.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/EmbededServletOptions.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- EmbededServletOptions.java6 May 2002 04:33:15 -   1.3
  +++ EmbededServletOptions.java11 May 2002 05:00:21 -  1.4
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/EmbededServletOptions.java,v
 1.3 2002/05/06 04:33:15 glenn Exp $
  - * $Revision: 1.3 $
  - * $Date: 2002/05/06 04:33:15 $
  + * $Header: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/EmbededServletOptions.java,v
 1.4 2002/05/11 05:00:21 remm Exp $
  + * $Revision: 1.4 $
  + * $Date: 2002/05/11 05:00:21 $
*
* 
* 
  @@ -82,7 +82,7 @@
   /**
* Is Jasper being used in development mode?
*/
  -public boolean development = false;
  +public boolean development = true;
   
   /**
* Do you want to keep the generated Java files around?
  
  
  
  1.7   +4 -4  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspEngineContext.java
  
  Index: JspEngineContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspEngineContext.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- JspEngineContext.java 6 May 2002 04:33:15 -   1.6
  +++ JspEngineContext.java 11 May 2002 05:00:22 -  1.7
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspEngineContext.java,v
 1.6 2002/05/06 04:33:15 glenn Exp $
  - * $Revision: 1.6 $
  - * $Date: 2002/05/06 04:33:15 $
  + * $Header: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspEngineContext.java,v
 1.7 2002/05/11 05:00:22 remm Exp $
  + * $Revision: 1.7 $
  + * $Date: 2002/05/11 05:00:22 $
*
* 
* 
  @@ -365,7 +365,7 @@
   public Class load() throws JasperException, FileNotFoundException {
   
   try {
  -if (servletClass == null || options.getDevelopment()) {
  +if (servletClass == null  !options.getDevelopment()) {
   compile();
   }
   jspLoader = new JasperLoader
  
  
  
  1.4   +9 -3  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java
  
  Index: JspServletWrapper.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- JspServletWrapper.java6 May 2002 04:33:16 -   1.3
  +++ JspServletWrapper.java11 May 2002 05:00:22 -  1.4
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java,v
 1.3 2002/05/06 04:33:16 glenn Exp $
  - * $Revision: 1.3 $
  - * $Date: 2002/05/06 04:33:16 $
  + * $Header: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java,v
 1.4 2002/05/11 05:00:22 remm Exp $
  + * $Revision: 1.4 $
  + * $Date: 2002/05/11 05:00:22 $
*
* The Apache Software License, Version 1.1
*
  @@ -150,6 +150,12 @@
   response.sendError
   (HttpServletResponse.SC_SERVICE_UNAVAILABLE,
Constants.getString(jsp.error.unavailable));
  +}
  +
  +if (options.getDevelopment()) {
  +synchronized (this) {
  +ctxt.compile();
  +}
   }
   
   if (ctxt.isReload()) {
  
  
  

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

DO NOT REPLY [Bug 8994] - JSP's do not recompile

2002-05-10 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8994.
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=8994

JSP's do not recompile

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-05-11 05:02 ---
Actually, I think the case development = true is broken. I'm committing a patch 
to fix it.
The change also defaults to development mode so this bug won't become the 
most duped bug in BZ :)

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




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

2002-05-10 Thread billbarker

billbarker02/05/10 22:06:26

  Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
  Added:   catalina/src/share/org/apache/catalina/util IOTools.java
Strftime.java URLEncoder.java
  Log:
  Refactoring DefaultServlet to allow for common code with SSIServlet.
  
  As far as DefaultServlet, this is a pure re-factoring with no change to the code 
processed.  It should be a safe change.
  
  The new URLEncoder is very much like o.a.t.u.buf.UEncoder.  It might be good to 
merge the two, but by adding it for now, more people can review it.
  
  Submitted by: Dan Sandberg [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.55  +19 -89
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
  
  Index: DefaultServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
  retrieving revision 1.54
  retrieving revision 1.55
  diff -u -r1.54 -r1.55
  --- DefaultServlet.java   17 Apr 2002 05:49:59 -  1.54
  +++ DefaultServlet.java   11 May 2002 05:06:25 -  1.55
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
 1.54 2002/04/17 05:49:59 billbarker Exp $
  - * $Revision: 1.54 $
  - * $Date: 2002/04/17 05:49:59 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
 1.55 2002/05/11 05:06:25 billbarker Exp $
  + * $Revision: 1.55 $
  + * $Date: 2002/05/11 05:06:25 $
*
* 
*
  @@ -80,7 +80,6 @@
   import java.io.OutputStreamWriter;
   import java.net.MalformedURLException;
   import java.net.URL;
  -import java.net.URLEncoder;
   import java.sql.Timestamp;
   import java.util.Date;
   import java.util.Enumeration;
  @@ -89,7 +88,6 @@
   import java.util.Locale;
   import java.util.TimeZone;
   import java.util.Hashtable;
  -import java.util.BitSet;
   import java.text.ParseException;
   import java.text.SimpleDateFormat;
   import java.security.MessageDigest;
  @@ -117,6 +115,7 @@
   import org.apache.catalina.util.RequestUtil;
   import org.apache.catalina.util.ServerInfo;
   import org.apache.catalina.util.StringManager;
  +import org.apache.catalina.util.URLEncoder;
   
   
   /**
  @@ -125,7 +124,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.54 $ $Date: 2002/04/17 05:49:59 $
  + * @version $Revision: 1.55 $ $Date: 2002/05/11 05:06:25 $
*/
   
   public class DefaultServlet
  @@ -195,14 +194,27 @@
   
   protected final static TimeZone gmtZone = TimeZone.getTimeZone(GMT);
   
  +/**
  + * Array containing the safe characters set.
  + */
  +protected static URLEncoder urlEncoder;
  +
   
   /**
* GMT timezone - all HTTP dates are on GMT
*/
  +// - Static Initializer
   static {
   formats[0].setTimeZone(gmtZone);
   formats[1].setTimeZone(gmtZone);
   formats[2].setTimeZone(gmtZone);
  +
  +urlEncoder = new URLEncoder();
  +urlEncoder.addSafeCharacter('-');
  +urlEncoder.addSafeCharacter('_');
  +urlEncoder.addSafeCharacter('.');
  +urlEncoder.addSafeCharacter('*');
  +urlEncoder.addSafeCharacter('/');
   }
   
   
  @@ -226,45 +238,11 @@
   
   
   /**
  - * Array containing the safe characters set.
  - */
  -protected static BitSet safeCharacters;
  -
  -
  -protected static final char[] hexadecimal =
  -{'0', '1', '2', '3', '4', '5', '6', '7', '8', '9',
  - 'A', 'B', 'C', 'D', 'E', 'F'};
  -
  -
  -/**
* Size of file transfer buffer in bytes.
*/
   private static final int BUFFER_SIZE = 4096;
   
   
  -// - Static Initializer
  -
  -
  -static {
  -safeCharacters = new BitSet(256);
  -int i;
  -for (i = 'a'; i = 'z'; i++) {
  -safeCharacters.set(i);
  -}
  -for (i = 'A'; i = 'Z'; i++) {
  -safeCharacters.set(i);
  -}
  -for (i = '0'; i = '9'; i++) {
  -safeCharacters.set(i);
  -}
  -safeCharacters.set('-');
  -safeCharacters.set('_');
  -safeCharacters.set('.');
  -safeCharacters.set('*');
  -safeCharacters.set('/');
  -}
  -
  -
   // - Public Methods
   
   
  @@ -1016,55 +994,7 @@
* @param path Path which has to be rewiten
*/
   protected String rewriteUrl(String path) {
  -
  -/**
  - * Note: This code portion is very similar to 

cvs commit: jakarta-tomcat-4.0/catalina/src/conf web.xml

2002-05-10 Thread remm

remm02/05/10 22:08:49

  Modified:catalina/src/conf web.xml
  Log:
  - Add some info on the development flag.
  
  Revision  ChangesPath
  1.34  +3 -0  jakarta-tomcat-4.0/catalina/src/conf/web.xml
  
  Index: web.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- web.xml   29 Apr 2002 23:22:57 -  1.33
  +++ web.xml   11 May 2002 05:08:49 -  1.34
  @@ -124,6 +124,9 @@
 !--  --
 !--   reloading   Should Jasper check for modified JSPs?  [true] --
 !--  --
  +  !--   development Is Jasper used in development mode (will check --
  +  !--   for JSP modification on every access)?  [true] --
  +  !--  --
 !--   scratchdir  What scratch directory should we use when  --
 !--   compiling JSP pages?  [default work directory  --
 !--   for the current web application]   --
  
  
  

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




Re: SSI Servlet has big problems

2002-05-10 Thread Bill Barker

I've just checked in your patch to the CVS HEAD of tomcat-4.0.  You are
correct that it is a straight refactoring, with no change in functionality.

I'm willing to play code monkey (copy; Pier) for the SSI specific stuff.
Hopefully Amy is going to be willing to answer questions that I'll likely
have, but otherwise it will just take me a little longer.

You should continue to send patches to the tomcat-dev list, since I can't
always promise when I'll have available time.
- Original Message -
From: Dan Sandberg [EMAIL PROTECTED]
To: Bill Barker [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Remy Maucherat [EMAIL PROTECTED]
Sent: Friday, May 10, 2002 7:16 PM
Subject: Re: SSI Servlet has big problems


 Hi Bill.

 The patch I sent in already is just code refactoring ( not SSI specific
 ) and a few tiny utility classes ( also not SSI specific ).

 The next patch will be the SSI stuff, and is a complete rewrite.  The
 old stuff is so broken that even if my stuff has major bugs ( and I've
 tested it by comparing output to Apache SSI with a very complex test
 case ) it will still be an improvement.  So really, the commiter doesn't
 need to understand it per-se ( even though that would be easy--the code
 is quite clean now ) but rather to check that I haven't done anything
 malicious.

 Thanks,

 -Dan

 Bill Barker wrote:

 I really don't know the SSI stuff very well at all, so I'd prefer if
someone
 who knows it better.  Amy seems to be the only currently active committer
 who has spent time on it however.  If she really can't, then I'll take a
 crack at learning it.
 - Original Message -
 From: Dan Sandberg [EMAIL PROTECTED]
 To: Bill Barker [EMAIL PROTECTED]
 Sent: Friday, May 10, 2002 5:59 PM
 Subject: Re: SSI Servlet has big problems
 
 
 
 
 Hi Bill.
 
 Can you be my 'point-man' on the CVS submissions, or suggest someone
 else who might be willing to do the submissions?  It seems like asking
 for 'someone on the list to commit these changes' (as I did) will just
 result in everyone waiting for someone else to do it.
 
 I'd very much like to get the SSI changes into 4.1, as the existing code
 is extremely broken ( not thread-safe and broken anyway ).  The new code
 will fix bug Bug#6299 and Bug#5758, as well as adding new functionality.
 It also leaves the code much more readable and modular.
 
 I asked Remy the same thing two days ago but got no response.  Please
 let me know either way.
 
 Thanks!
 
 -Dan
 
 Bill Barker wrote:
 
 
 
 The standard way is to attach the output of cvs diff to an e-mail
 
 
 message
 
 
 with a subject beginning with the string [PATCH].  If you continue to
 
 
 make
 
 
 work for us enough by doing this, eventually someone will propose you
as
 
 
 a
 
 
 committer :-).
 - Original Message -
 From: Dan Sandberg [EMAIL PROTECTED]
 To: Tomcat Developers List [EMAIL PROTECTED]
 Sent: Wednesday, May 01, 2002 9:39 PM
 Subject: Re: SSI Servlet has big problems
 
 
 
 
 
 
 Remy Maucherat wrote:
 
 
 
 
 
 Implementing the SingleThreadedServlet interface will not help thi
 
 
 
 
 
 Are you sure ?
 (I didn't look at the code at all, so I'm just wondering)
 Otherwise, it would be a really cheap way to make it work.
 
 Thanks for looking into it anyway.
 
 
 
 
 
 
 Implementing SingleThreadedServlet doesn't mean only one thread will
be
 running the servlet at a time.  It means only one thread will be
running
 a given INSTANCE of the servlet.  So you could still have two threads
 running two different instances of the same servlet.  This will still
 get massively messed up with all the sharing of static variables.
 
 
 
 
 
 Are the two authors still mantaining this code?  Bip Thelin? Amy
Roh?
 
 
 
 
 
 
 Not really. I didn't hear about Bip for a while, and Amy has been
busy
 
 
 
 
 with
 
 
 
 
 other things.
 Usually an easy way to get commit access if you have time to dedicate
 
 
 to
 
 
 contributing is to take over the maintenance of some abandoned
 
 
 
 
 component(s).
 
 
 
 
 CGI also needs a maintainer, BTW.
 
 Remy
 
 
 
 
 
 I'll fix this problem, and I'll create a filter that does SSI on any
 output ( so that a JSP page can use SSI, for example ).  I don't have
 any interest in being a maintainer/having commit access, however.
 
 So what's the best way to give back my bug fixes/filter?
 
 Thanks for the response, btw.
 
 -Dan
 
 
 
 --
 To unsubscribe, e-mail:
 
 
 
 
 mailto:[EMAIL PROTECTED]
 
 
 
 
 For additional commands, e-mail:
 
 
 
 
 mailto:[EMAIL PROTECTED]
 
 
 
 
 --
 To unsubscribe, e-mail:
 
 
 mailto:[EMAIL PROTECTED]
 
 
 For additional commands, e-mail:
 
 
 mailto:[EMAIL PROTECTED]
 
 
 
 
 
 
 
 
 
 
 
 
 





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




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

2002-05-10 Thread billbarker

billbarker02/05/10 22:43:56

  Modified:catalina/src/share/org/apache/catalina/util Strftime.java
  Log:
  Fixing tabs.
  
  I've clearly got to review more carefully if I don't want Jon breathing down my 
neck. ;-)
  
  Revision  ChangesPath
  1.2   +81 -81
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/Strftime.java
  
  Index: Strftime.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/Strftime.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- Strftime.java 11 May 2002 05:06:25 -  1.1
  +++ Strftime.java 11 May 2002 05:43:56 -  1.2
  @@ -1,8 +1,8 @@
   /*
* Strftime.java
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/Strftime.java,v
 1.1 2002/05/11 05:06:25 billbarker Exp $
  - * $Revision: 1.1 $
  - * $Date: 2002/05/11 05:06:25 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/Strftime.java,v
 1.2 2002/05/11 05:43:56 billbarker Exp $
  + * $Revision: 1.2 $
  + * $Date: 2002/05/11 05:43:56 $
*
* 
*
  @@ -87,7 +87,7 @@
*
* @author Bip Thelin
* @author Dan Sandberg
  - * @version $Revision: 1.1 $, $Date: 2002/05/11 05:06:25 $
  + * @version $Revision: 1.2 $, $Date: 2002/05/11 05:43:56 $
*/
   public class Strftime {
   protected static Properties translate;
  @@ -104,8 +104,8 @@
   translate.put(B,);
   translate.put(c,EEE MMM d HH:mm:ss );
   
  - //There's no way to specify the century in SimpleDateFormat.  We don't want to 
hard-code
  - //20 since this could be wrong for the pre-2000 files.
  +//There's no way to specify the century in SimpleDateFormat.  We don't want 
to hard-code
  +//20 since this could be wrong for the pre-2000 files.
   //translate.put(C, 20);
   translate.put(d,dd);
   translate.put(D,MM/dd/yy);
  @@ -126,23 +126,23 @@
   translate.put(P,a);  //will show as pm instead of PM
   translate.put(r,hh:mm:ss a);
   translate.put(R,HH:mm);
  - //There's no way to specify this with SimpleDateFormat
  +//There's no way to specify this with SimpleDateFormat
   //translate.put(s,seconds since ecpoch);
   translate.put(S,ss);
   translate.put(t,\t);
   translate.put(T,HH:mm:ss);
  - //There's no way to specify this with SimpleDateFormat
  +//There's no way to specify this with SimpleDateFormat
   //translate.put(u,day of week ( 1-7 ));
   
  - //There's no way to specify this with SimpleDateFormat
  +//There's no way to specify this with SimpleDateFormat
   //translate.put(U,week in year with first sunday as first day...);
   
   translate.put(V,ww); //I'm not sure this is always exactly the same
   
  - //There's no way to specify this with SimpleDateFormat
  +//There's no way to specify this with SimpleDateFormat
   //translate.put(W,week in year with first monday as first day...);
   
  - //There's no way to specify this with SimpleDateFormat
  +//There's no way to specify this with SimpleDateFormat
   //translate.put(w,E);
   translate.put(X,HH:mm:ss);
   translate.put(x,MM/dd/yy);
  @@ -160,8 +160,8 @@
* @see #Strftime( String, Locale )
*/
   public Strftime( String origFormat ) {
  - String convertedFormat = convertDateFormat( origFormat );
  - simpleDateFormat = new SimpleDateFormat( convertedFormat );
  +String convertedFormat = convertDateFormat( origFormat );
  +simpleDateFormat = new SimpleDateFormat( convertedFormat );
   }
   
   /**
  @@ -171,8 +171,8 @@
* @param the locale to use for locale-specific conversions
*/
   public Strftime( String origFormat, Locale locale ) {
  - String convertedFormat = convertDateFormat( origFormat );
  - simpleDateFormat = new SimpleDateFormat( convertedFormat, locale );
  +String convertedFormat = convertDateFormat( origFormat );
  +simpleDateFormat = new SimpleDateFormat( convertedFormat, locale );
   }
   
   /**
  @@ -182,7 +182,7 @@
* @return the formatted date
*/
   public String format( Date date ) {
  - return simpleDateFormat.format( date );
  +return simpleDateFormat.format( date );
   }
   
   /**
  @@ -191,7 +191,7 @@
* @return the timezone
*/
   public TimeZone getTimeZone() {
  - return simpleDateFormat.getTimeZone();
  +return simpleDateFormat.getTimeZone();
   }
   
   /**
  @@ -200,7 +200,7 @@
* @see java.util.TimeZone#setTimeZone
*/
   public void setTimeZone( TimeZone timeZone ) {
  - 

Re: [4.1] Add additional events

2002-05-10 Thread Bill Barker


- Original Message -
From: [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Friday, May 10, 2002 9:07 PM
Subject: Re: [4.1] Add additional events


 On Fri, 10 May 2002, Remy Maucherat wrote:

 I plan to add additional events to the components start and stop
  methods:
 before_start, after_start, before_stop, after_stop. This has been
  suggested
 and discussed a while ago, but never actually implemented.
  
   Could you also add events for webapp add/remove/start/stop, and make
sure
   the events are propagated up to coyote ?
 
  That's already there (more or less). You need to put a container
listener on
  the host and listen for Container.ADD_CHILD_EVENT (or
REMOVE_CHILD_EVENT).

 The problem is propagating it via Coyote actions to jk level.


Presumably, you're transmitting it to Apache via Shm, so the Listener simple
needs an instanceof JkCoyoteHandler.  I agree with Remy that it is (more or
less) already there.

 Costin


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



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