DO NOT REPLY [Bug 31722] - In JNI mode, POST is broken due to bodyMsg.getLen() == 0 not working properly

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31722

In JNI mode, POST is broken due to bodyMsg.getLen() == 0 not working properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-10-15 04:44 ---
Fixed now in the CVS.

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

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

[billbarker]

billbarker2004/10/14 21:42:25

  Modified:jk/java/org/apache/jk/common ChannelJni.java
  Log:
  Make the message properly empty for the first part of the POST body.
  
  This is a bit ugly, but then so is the rest of ChannelJni ;-).
  
  Fix for Bug #31722
  
  Revision  ChangesPath
  1.18  +2 -1  
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelJni.java
  
  Index: ChannelJni.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelJni.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- ChannelJni.java   31 May 2004 04:48:54 -  1.17
  +++ ChannelJni.java   15 Oct 2004 04:42:25 -  1.18
  @@ -71,7 +71,8 @@
   log.debug("No send() prior to receive(), no data buffer");
   // No sent() was done prior to receive.
   msg.reset();
  -return 0;
  +msg.end();
  +sentResponse = msg;
   }
   
   sentResponse.processHeader();
  
  
  

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

DO NOT REPLY [Bug 31725] - File.createTempFile() fails with FNFE because java.io.tmpdir does not exist

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31725

File.createTempFile() fails with FNFE because java.io.tmpdir does not exist

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|File.createTemporaryFile()  |File.createTempFile() fails
   |fails with FNFE because |with FNFE because
   |java.io.tmpdir does not |java.io.tmpdir does not
   |exist   |exist
Version|5.0.18  |5.0.19

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

DO NOT REPLY [Bug 31725] New: - File.createTemporaryFile() fails with FNFE because java.io.tmpdir does not exist

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31725

File.createTemporaryFile() fails with FNFE because java.io.tmpdir does not exist

   Summary: File.createTemporaryFile() fails with FNFE because
java.io.tmpdir does not exist
   Product: Tomcat 5
   Version: 5.0.18
  Platform: Macintosh
OS/Version: MacOS X
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I ran into File.createTemporaryFile() filaing with a FileNotFoundException in
Tomcat but not in standalone testing outside of a container.  The remedy,
apparently, is so ensure taht the directory specified by java.io.tmpdir actually
exists, and it would be nice if Tomcat did that instead of me having to...

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java

[Bill Barker]

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 14, 2004 5:00 PM
Subject: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core
ApplicationHttpResponse.java


> luehe   2004/10/14 17:00:35
>
>   Modified:catalina/src/share/org/apache/catalina/core
> ApplicationHttpResponse.java
>   Log:
>   Expose any errors on an included resource.
>
>   For example, a JSP with this include action:
> 
>   or
> 
>   where nonexistent[.jsp] does not exist, currently returns silently,
hiding the
>   fact that the resource to be included does not exist.
>
>   This patch returns a 404 with the name of the nonexistent resource.
>
>   Yes, SRV.8.3 ("The Include Method") mentions that
>
> "it [the target servlet] cannot set headers or call any method that
> affects the headers of the response. Any attempt to do so must be
> ignored."
>
>   but i don't think it is referring to the error case.

Actually, it has always been my impression that this *is* referring to the
error case.  I think that somebody should get a clarification before making
a change this drastic.  (By the way, this doesn't do anything since the
Response is still too smart to allow an included resource to call
sendError.)

In any case, it doesn't seem to be that useful, since in the case of
 it is way too late to do
a meaningful sendError.

>
>   Let me know if you see any problems.
>



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.

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

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

[luehe]

luehe   2004/10/14 17:18:35

  Modified:catalina/src/share/org/apache/catalina Globals.java
  Log:
  - Grouped javax.servlet.include.* and javax.servlet.forward.* attributes
  - Fixed description of javax.servlet.include.* attributes: They do not refer
to the properties of the original request, but to those of the included
request
  
  Revision  ChangesPath
  1.12  +50 -50
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Globals.java
  
  Index: Globals.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Globals.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- Globals.java  1 Sep 2004 18:33:32 -   1.11
  +++ Globals.java  15 Oct 2004 00:18:35 -  1.12
  @@ -88,22 +88,6 @@
   
   
   /**
  - * The request attribute under which the original context path is stored
  - * on an included dispatcher request.
  - */
  -public static final String INCLUDE_CONTEXT_PATH_ATTR =
  -"javax.servlet.include.context_path";
  -
  -
  -/**
  - * The request attribute under which the original context path is stored
  - * on an forwarded dispatcher request.
  - */
  -public static final String FORWARD_CONTEXT_PATH_ATTR =
  -"javax.servlet.forward.context_path";
  -
  -
  -/**
* The request attribute under which we forward a Java exception
* (as an object of type Throwable) to an error page.
*/
  @@ -186,43 +170,43 @@
   
   
   /**
  - * The request attribute under which the original path info is stored
  - * on an included dispatcher request.
  + * The request attribute under which the request URI of the included
  + * servlet is stored on an included dispatcher request.
*/
  -public static final String INCLUDE_PATH_INFO_ATTR =
  -"javax.servlet.include.path_info";
  -
  -
  +public static final String INCLUDE_REQUEST_URI_ATTR =
  +"javax.servlet.include.request_uri";
  +
  +
   /**
  - * The request attribute under which the original path info is stored
  - * on an forwarded dispatcher request.
  + * The request attribute under which the context path of the included
  + * servlet is stored on an included dispatcher request.
*/
  -public static final String FORWARD_PATH_INFO_ATTR =
  -"javax.servlet.forward.path_info";
  +public static final String INCLUDE_CONTEXT_PATH_ATTR =
  +"javax.servlet.include.context_path";
   
   
   /**
  - * The request attribute under which the original query string is stored
  - * on an included dispatcher request.
  + * The request attribute under which the path info of the included
  + * servlet is stored on an included dispatcher request.
*/
  -public static final String INCLUDE_QUERY_STRING_ATTR =
  -"javax.servlet.include.query_string";
  +public static final String INCLUDE_PATH_INFO_ATTR =
  +"javax.servlet.include.path_info";
  +
   
  -
   /**
  - * The request attribute under which the original query string is stored
  - * on an forwarded dispatcher request.
  + * The request attribute under which the servlet path of the included
  + * servlet is stored on an included dispatcher request.
*/
  -public static final String FORWARD_QUERY_STRING_ATTR =
  -"javax.servlet.forward.query_string";
  -
  -
  +public static final String INCLUDE_SERVLET_PATH_ATTR =
  +"javax.servlet.include.servlet_path";
  +
  +
   /**
  - * The request attribute under which the original request URI is stored
  - * on an included dispatcher request.
  + * The request attribute under which the query string of the included
  + * servlet is stored on an included dispatcher request.
*/
  -public static final String INCLUDE_REQUEST_URI_ATTR =
  -"javax.servlet.include.request_uri";
  +public static final String INCLUDE_QUERY_STRING_ATTR =
  +"javax.servlet.include.query_string";
   
   
   /**
  @@ -234,19 +218,19 @@
   
   
   /**
  - * The request attribute under which we forward a servlet name to
  - * an error page.
  + * The request attribute under which the original context path is stored
  + * on an forwarded dispatcher request.
*/
  -public static final String SERVLET_NAME_ATTR =
  -"javax.servlet.error.servlet_name";
  +public static final String FORWARD_CONTEXT_PATH_ATTR =
  +"javax.servlet.forward.context_path";
   
   
   /**
  - * The request attribute under which the original servlet path is stored
  - * on an included dispatcher request.
  + * The request attribute under which the original path info is stored
  + * on an forwarded dispatcher request.

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

[luehe]

luehe   2004/10/14 17:00:35

  Modified:catalina/src/share/org/apache/catalina/core
ApplicationHttpResponse.java
  Log:
  Expose any errors on an included resource.
  
  For example, a JSP with this include action:

  or

  where nonexistent[.jsp] does not exist, currently returns silently, hiding the
  fact that the resource to be included does not exist.
  
  This patch returns a 404 with the name of the nonexistent resource.
  
  Yes, SRV.8.3 ("The Include Method") mentions that
  
"it [the target servlet] cannot set headers or call any method that
affects the headers of the response. Any attempt to do so must be
ignored."
  
  but i don't think it is referring to the error case.
  
  Let me know if you see any problems.
  
  Revision  ChangesPath
  1.6   +1 -3  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpResponse.java
  
  Index: ApplicationHttpResponse.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpResponse.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- ApplicationHttpResponse.java  27 Feb 2004 14:58:42 -  1.5
  +++ ApplicationHttpResponse.java  15 Oct 2004 00:00:35 -  1.6
  @@ -237,7 +237,6 @@
*/
   public void sendError(int sc) throws IOException {
   
  -if (!included)
   ((HttpServletResponse) getResponse()).sendError(sc);
   
   }
  @@ -253,7 +252,6 @@
*/
   public void sendError(int sc, String msg) throws IOException {
   
  -if (!included)
   ((HttpServletResponse) getResponse()).sendError(sc, msg);
   
   }
  
  
  

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

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

[luehe]

luehe   2004/10/14 16:58:38

  Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
  Log:
  Expose any errors on an included resource.
  
  For example, a JSP with this include action:

  or

  where nonexistent[.jsp] does not exist, currently returns silently, hiding the
  fact that the resource to be included does not exist.
  
  This patch returns a 404 with the name of the nonexistent resource.
  
  Yes, SRV.8.3 ("The Include Method") mentions that
  
"it [the target servlet] cannot set headers or call any method that
affects the headers of the response. Any attempt to do so must be
ignored."
  
  but i don't think it is referring to the error case.
  
  Let me know if you see any problems.
  
  Revision  ChangesPath
  1.29  +22 -8 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
  
  Index: DefaultServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- DefaultServlet.java   19 Sep 2004 01:20:10 -  1.28
  +++ DefaultServlet.java   14 Oct 2004 23:58:38 -  1.29
  @@ -281,12 +281,12 @@
   protected String getRelativePath(HttpServletRequest request) {
   
   // Are we being processed by a RequestDispatcher.include()?
  -if (request.getAttribute("javax.servlet.include.request_uri")!=null) {
  -String result = (String)
  -request.getAttribute("javax.servlet.include.path_info");
  +if (request.getAttribute(Globals.INCLUDE_REQUEST_URI_ATTR) != null) {
  +String result = (String) request.getAttribute(
  +Globals.INCLUDE_PATH_INFO_ATTR);
   if (result == null)
  -result = (String)
  -request.getAttribute("javax.servlet.include.servlet_path");
  +result = (String) request.getAttribute(
  +Globals.INCLUDE_SERVLET_PATH_ATTR);
   if ((result == null) || (result.equals("")))
   result = "/";
   return (result);
  @@ -651,8 +651,15 @@
   CacheEntry cacheEntry = resources.lookupCache(path);
   
   if (!cacheEntry.exists) {
  +// Check if we're included so we can return the appropriate 
  +// missing resource name in the error
  +String requestUri = (String) request.getAttribute(
  +Globals.INCLUDE_REQUEST_URI_ATTR);
  +if (requestUri == null) {
  +requestUri = request.getRequestURI();
  +}
   response.sendError(HttpServletResponse.SC_NOT_FOUND,
  -   request.getRequestURI());
  +   requestUri);
   return;
   }
   
  @@ -660,8 +667,15 @@
   // ends with "/" or "\", return NOT FOUND
   if (cacheEntry.context == null) {
   if (path.endsWith("/") || (path.endsWith("\\"))) {
  +// Check if we're included so we can return the appropriate 
  +// missing resource name in the error
  +String requestUri = (String) request.getAttribute(
  +Globals.INCLUDE_REQUEST_URI_ATTR);
  +if (requestUri == null) {
  +requestUri = request.getRequestURI();
  +}
   response.sendError(HttpServletResponse.SC_NOT_FOUND,
  -   request.getRequestURI());
  +   requestUri);
   return;
   }
   }
  
  
  

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

DO NOT REPLY [Bug 29887] - Recursive Tag files modification check causes StackOverflowError

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=29887

Recursive Tag files modification check causes StackOverflowError





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 23:58 ---
There is still a problem with recompiling recursive tag file, but not with
Argen's test case from 31382.  The problem occurs only for indiret recursive tag
files (t.tag uses t2.tag which use t.tag), and it occurs not during dependency
checking, but in the JSP compilation itself.

This is now fixed in CVS.  Thanks for being persistent. :)

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

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

[kinman]

kinman  2004/10/14 16:54:01

  Modified:jasper2/src/share/org/apache/jasper/compiler Compiler.java
  Log:
  - Fix bugzilla 31382: Stack overflow when compiling recursive tag files.
  
  Revision  ChangesPath
  1.97  +23 -30
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java
  
  Index: Compiler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v
  retrieving revision 1.96
  retrieving revision 1.97
  diff -u -r1.96 -r1.97
  --- Compiler.java 5 Oct 2004 19:28:19 -   1.96
  +++ Compiler.java 14 Oct 2004 23:54:00 -  1.97
  @@ -326,7 +326,6 @@
*/
   public boolean isOutDated(boolean checkClass) {
   
  -boolean outDated = false;
   String jsp = ctxt.getJspFile();
   
   if ((jsw != null)
  @@ -362,31 +361,31 @@
   }
   
   if (!targetFile.exists()) {
  -outDated = true;
  -} else {
  -targetLastModified = targetFile.lastModified();
  -if (checkClass && jsw != null) {
  -jsw.setServletClassLastModifiedTime(targetLastModified);
  -}   
  -if (targetLastModified < jspRealLastModified) {
  -if( log.isDebugEnabled() ) {
  -log.debug("Compiler: outdated: " + targetFile + " " +
  -targetLastModified );
  -}
  -outDated = true;
  +return true;
  +}
  +
  +targetLastModified = targetFile.lastModified();
  +if (checkClass && jsw != null) {
  +jsw.setServletClassLastModifiedTime(targetLastModified);
  +}   
  +if (targetLastModified < jspRealLastModified) {
  +if( log.isDebugEnabled() ) {
  +log.debug("Compiler: outdated: " + targetFile + " " +
  +targetLastModified );
   }
  +return true;
   }
   
   // determine if source dependent files (e.g. includes using include
   // directives) have been changed.
   if( jsw==null ) {
  -return outDated;
  +return false;
   }
   jsw.setLastModificationTest(System.currentTimeMillis());
   
   List depends = jsw.getDependants();
   if (depends == null) {
  -return outDated;
  +return false;
   }
   
   Iterator it = depends.iterator();
  @@ -395,29 +394,23 @@
   try {
   URL includeUrl = ctxt.getResource(include);
   if (includeUrl == null) {
  -outDated = true;
  +return true;
   }
  -if (!outDated) {
   
  -URLConnection includeUconn = includeUrl.openConnection();
  -long includeLastModified = includeUconn.getLastModified();
  -includeUconn.getInputStream().close();
  -
  -if (includeLastModified > targetLastModified) {
  -outDated = true;
  -}
  -}
  -if (outDated) {
  -// Remove any potential Wrappers for tag files
  -ctxt.getRuntimeContext().removeWrapper(include);
  +URLConnection includeUconn = includeUrl.openConnection();
  +long includeLastModified = includeUconn.getLastModified();
  +includeUconn.getInputStream().close();
  +
  +if (includeLastModified > targetLastModified) {
  +return true;
   }
   } catch (Exception e) {
   e.printStackTrace();
  -outDated = true;
  +return true;
   }
   }
   
  -return outDated;
  +return false;
   
   }
   
  
  
  

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

DO NOT REPLY [Bug 31707] - HTMLManager App doesn't confirm before undeploying or stopping app.

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31707

HTMLManager App doesn't confirm before undeploying or stopping app.





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 23:30 ---
Who closes these?
The reporter?
or a committer?

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

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

[remm]

remm2004/10/14 15:53:14

  Modified:util/java/org/apache/tomcat/util/http ServerCookie.java
  Log:
  - Sync with Cookie, by adding ' ' as a special char. (bug 31090)
  - If a special char is present, the string will be quoted. If the client doesn't 
support it, too bad. No IAE will be thrown.
  
  Revision  ChangesPath
  1.7   +10 -15
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/ServerCookie.java
  
  Index: ServerCookie.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/ServerCookie.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- ServerCookie.java 17 Sep 2004 18:34:19 -  1.6
  +++ ServerCookie.java 14 Oct 2004 22:53:14 -  1.7
  @@ -128,7 +128,7 @@
   // from RFC 2068, token special case characters
   //
   // private static final String tspecials = "()<>@,;:\\\"/[]?={} \t";
  -private static final String tspecials = ",;";
  +private static final String tspecials = ",; ";
   
   /*
* Tests a string and returns true if the string counts as a
  @@ -272,20 +272,15 @@
   }
   
   public static void maybeQuote (int version, StringBuffer buf,
  -String value)
  -{
  - // special case - a \n or \r  shouldn't happen in any case
  - if ( isToken (value))
  -   buf.append (value);
  - else {
  - if(version==0)
  - throw new IllegalArgumentException( value );
  - else {
  - buf.append ('"');
  - buf.append (value);
  - buf.append ('"');
  - }
  - }
  +String value) {
  +// special case - a \n or \r  shouldn't happen in any case
  +if (isToken(value)) {
  +buf.append(value);
  +} else {
  +buf.append('"');
  +buf.append(value);
  +buf.append('"');
  +}
   }
   
   // log
  
  
  

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

Re: JK Todo v.2

[Remy Maucherat]

Mladen Turk wrote:
Hi all,
Seems that everyone agrees to keep the Apache 1.3
support, and to keep jk as 'stable'. Fine...
Also, JNI (like in JK2) is totally out, that's fine too.
But, I'm not in favor to put the jk in the maintaining
mode altogether. We can keep the jk stable, but that
doesn't mean that the development has to be stopped.
So I propose more pragmatic approach:
1. Documentation
Think no one objects :).
It would be good to separate the mod_jk 1.2.x docs, so that people are 
less confused over what they should use.

Overall, I think the mod_jk 1.2 docs are decent right now. The thing 
which could be explained better is the usage of local workers (I saw 
many cases where people put local workers everywhere since it looked ok, 
and then didn't understand why load balancing wasn't working).

2. Add unix sockets from jk2
3. Add thread pool for IIS from jk2
4. Add shared memory from jk2 (pre-apr)
All that will keep existing code intact regarding
stability.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31722] New: - In JNI mode, POST is broken due to bodyMsg.getLen() == 0 not working properly

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31722

In JNI mode, POST is broken due to bodyMsg.getLen() == 0 not working properly

   Summary: In JNI mode, POST is broken due to bodyMsg.getLen() == 0
not working properly
   Product: Tomcat 5
   Version: 5.0.24
  Platform: All
OS/Version: All
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Connector:AJP
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Subject: Re: if( bodyMsg.getLen() <= 4 )
Date: 10/14/04, 4:19 PM
From: Kurt Miller <[EMAIL PROTECTED]>
To: Tim Suh

Hi Tim,

From: Tim Suh
> JkInputStream.java contains
>
> if( bodyMsg.getLen() <= 4 )
>
> which was fixed to
>
> if( bodyMsg.getLen() == 0 )
>
> but isn't this incorrect ? MsgAjp.java reset() contains len = 4.
> How can getLen() ever become 0 ?

The line after reset calls receive:

   int err = mc.getSource().receive(bodyMsg, mc);

For sockets this calls ChannelSocket.receive and it calls
MsgAjp.processHeader() for bodyMsg. processHeader sets the
len to the length of the packet excluding the header. Unix Sockets
work the same way as ChannelSocket.

However, for jni this calls ChannelJni.receive and it does
not call MsgAjp.processHeader() for bodyMsg. len is
left a 4 and if( bodyMsg.getLen() == 0 ) doesn't detect
the fact it should return at the point.

> This is breaking jni POST by the way.

I see why now (see above). I'm thinking MsgAjp.reset should
set len = 0, but this needs a through review of all the uses of
MsgAjp to see the impact. An alternative solution would be
to add a method to MsgAjp that ChannelJni.receive could call
that sets len = 0.

> Not sure if you are monitoring this email address so my message
> above is very short. Let me know whether I need to report this to
> bugzilla. Thanks

Yes, please do open a bugzilla report and copy this full email into
it.

Thanks,
-Kurt

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

Re: java.io.tempdir Problems

[Michael McGrady]

I don't know if this is helpful or not, Martin, but if you attempt 
System.getenv("java.io.tempdir") [which is deprecated], you get as part 
of the error message
"getenv no longer supported, use properties and -D instead: 
java.io.tempdir".  Is that helpful?  Does the -D there mean as in 
-Djava.io.tempdir?

Michael
Martin Gainty wrote:
Good Afternoon Michael
Perusing the Manual for Jspc at
http://64.233.167.104/search?q=cache:pfbfEPvvvHUJ:www.gefionsoftware.com/Lit
eWebServer/lws-jsp/ReferenceManual.pdf+TOMCAT+java.io.tempDir+-Djava.io.temp
Dir&hl=en
formal syntax for the JSPC command
jspc [options] -webapp web-app-root-dir
Where option
-d output-dir specifies
The -d output-dir specification is the directory specified by the
java.io.tempdir system property
I see that there are 2 ways to specify java.io.tempdir System Property
Anyone else
The directory specified by the java.io.tempdirsystem property The directory
specified by the java.io.tempdirsystem property The directory specified by
the java.io.tempdirsystem property The directory specified by the
java.io.tempdir???
Martin
- Original Message -
From: "Michael McGrady" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, October 14, 2004 11:46 AM
Subject: Re: java.io.tempdir Problems
 

Martin,
Perhaps I should add, Martin, that if I set the environment variables
for java.io.tempdir and -Djava.io.tempdir in the application but not in
Tomcat startup, I don't have the problem.  I am a bit confused about
whether to use java.io.tempdir or -Djava.io.tempdir.  Can you explain a
bit about that?
Michael McGrady
Martin Gainty wrote:
   

Michael
createTempFile employs 3 steps algorithm to locate/create "tempDir"
1) Attempt to retrieve the value of "javax.servlet.context.tempdir" from
 

the
 

 ServletContext
2) If that's not found, attempt to retrieve the value of the
 

init-parameter
 

 "tempDir"
3) If that's not found, default to the system-wide temp directory
 

specified
 

 by the system property "java.io.tempdir"
A)what is the value of "javax.servlet.context.tempdir" from the
ServletContext?
B)what is the value of the init-parameter   "tempDir"?
Martin-
- Original Message -
From: "Michael McGrady" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, October 14, 2004 3:16 AM
Subject: java.io.tempdir Problems

 

I hope this is Tomcat related.  If not, please accept my apologies, and
give me direction.  I have removed from my Tomcat 5 (Struts 1.2 using a
custom taglib) service the java.io.tempdir setting because when I use
the following code:
   File file = new File(Classpath.WEB_INF +
   "resource"+ File.separator +
   "content_type"+ File.separator +
   "ttf" + File.separator +
physicalName);
   FileInputStream fontStream = new FileInputStream(file);
   Font font = Font.createFont(Font.TRUETYPE_FONT,fontStream);
   font = font.deriveFont(attributes);
   fontStream.close();
I get temp files of around 50 - 150 kilobytes each written to the temp
directory.  I requested assistance on Tomcat User without an answer.
Anyway, I assume that there may be a concurrency issue of somekind.  Is
that right?  Anyone with any assistance out there?
Michael McGrady
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

   

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


 

   

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

 


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

Re: java.io.tempdir Problems

[Michael McGrady]

Hi, Martin,
Did something not come through on this email?  I am not following this.
Martin Gainty wrote:
Good Afternoon Michael
Perusing the Manual for Jspc at
http://64.233.167.104/search?q=cache:pfbfEPvvvHUJ:www.gefionsoftware.com/Lit
eWebServer/lws-jsp/ReferenceManual.pdf+TOMCAT+java.io.tempDir+-Djava.io.temp
Dir&hl=en
formal syntax for the JSPC command
jspc [options] -webapp web-app-root-dir
Where option
-d output-dir specifies
The -d output-dir specification is the directory specified by the
java.io.tempdir system property
I see that there are 2 ways to specify java.io.tempdir System Property
Anyone else
The directory specified by the java.io.tempdirsystem property The directory
specified by the java.io.tempdirsystem property The directory specified by
the java.io.tempdirsystem property The directory specified by the
java.io.tempdir???
Martin
- Original Message -
From: "Michael McGrady" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, October 14, 2004 11:46 AM
Subject: Re: java.io.tempdir Problems
 

Martin,
Perhaps I should add, Martin, that if I set the environment variables
for java.io.tempdir and -Djava.io.tempdir in the application but not in
Tomcat startup, I don't have the problem.  I am a bit confused about
whether to use java.io.tempdir or -Djava.io.tempdir.  Can you explain a
bit about that?
Michael McGrady
Martin Gainty wrote:
   

Michael
createTempFile employs 3 steps algorithm to locate/create "tempDir"
1) Attempt to retrieve the value of "javax.servlet.context.tempdir" from
 

the
 

 ServletContext
2) If that's not found, attempt to retrieve the value of the
 

init-parameter
 

 "tempDir"
3) If that's not found, default to the system-wide temp directory
 

specified
 

 by the system property "java.io.tempdir"
A)what is the value of "javax.servlet.context.tempdir" from the
ServletContext?
B)what is the value of the init-parameter   "tempDir"?
Martin-
- Original Message -
From: "Michael McGrady" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, October 14, 2004 3:16 AM
Subject: java.io.tempdir Problems

 

I hope this is Tomcat related.  If not, please accept my apologies, and
give me direction.  I have removed from my Tomcat 5 (Struts 1.2 using a
custom taglib) service the java.io.tempdir setting because when I use
the following code:
   File file = new File(Classpath.WEB_INF +
   "resource"+ File.separator +
   "content_type"+ File.separator +
   "ttf" + File.separator +
physicalName);
   FileInputStream fontStream = new FileInputStream(file);
   Font font = Font.createFont(Font.TRUETYPE_FONT,fontStream);
   font = font.deriveFont(attributes);
   fontStream.close();
I get temp files of around 50 - 150 kilobytes each written to the temp
directory.  I requested assistance on Tomcat User without an answer.
Anyway, I assume that there may be a concurrency issue of somekind.  Is
that right?  Anyone with any assistance out there?
Michael McGrady
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

   

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


 

   

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

 


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

Where to place classes

[Chris Forbis]

I am having a problem as where to place classes.

I have a CustomJDBCRealm  (it extends JDBC realm)

I need this to be setup in the context of my application like any
other realm.  If I place my jar in server\lib it works.

BUT

If I do this the MyPrincipal object can not be refrenced from my web
application.

If I place this jar in my webapp lib or in the common\lib the realm
can not find JDBCRealm that is extends from on startup so it fails.

I am a little lost as to the correct place to put this...

I have a CustomJDBCRealm extends JDBCRealm  (it does an getEmailAddress)
I have an interface MyPrincipalInterface extends java.security.Principal
I have a class MyPrincipal implements MyPrincipalInterface

The JDBCRealm gived back a MyPrincipal for its principal...  and my
servlet code then does this to get at it

MyPrincipalInterface p =
(MyPrincipalInterface)httpServletRequest.getUserPrincipal();
String emailAddress = p.getEmailAddress();

As I see it that is all should work except the common\lib as I
understood it was suppose to work for ALL web applications as well as
ALL server side items, but ti does not seem to.

(For refrence most my test has come from the Tomcat Wiki at
http://wiki.apache.org/jakarta-tomcat/HowTo)

I am lost...

Thanks!

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

DO NOT REPLY [Bug 31090] - The session "disappears" when the context name contains the space character

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31090

The session "disappears" when the context name contains the space character





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 19:51 ---
It looks like the ServerCookie value is the one from jakarta-servletapi (aka 
servlet-2.2), and simply hasn't been updated.

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

DO NOT REPLY [Bug 31090] - The session "disappears" when the context name contains the space character

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31090

The session "disappears" when the context name contains the space character





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 19:43 ---
Ah, yes, I missed that "small" point. I thought I had a really good idea here ;)

BTW, can you explain the tspecials descrepancy between the two cookies classes
for the tspecial field ?

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

DO NOT REPLY [Bug 31090] - The session "disappears" when the context name contains the space character

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31090

The session "disappears" when the context name contains the space character





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 19:20 ---
IMHO, Remy's idea is best.  But it will throw an IAE since the session cookie 
is v0.  Probably we could just remove the version check in maybeQuote, since 
I'm guessing that most UAs probably support quoted values, even if they don't 
support all of RFC2019.

Using the JDK1.3 j.n.URLEncoder is going to cause more problems then it will 
ever solve, given that it uses the platform encoding (which is unlikely to be 
utf-8 :).  If you have to encode the path, use the UEncoder in the Response.

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

RE: UserTransaction not working in DefaultContext

[Shapira, Yoav]

Hi,
Does it work from a normal Context, not DefaultContext?

Yoav Shapira http://www.yoavshapira.com


>-Original Message-
>From: Ricardo Matinata [mailto:[EMAIL PROTECTED]
>Sent: Thursday, October 14, 2004 3:14 PM
>To: [EMAIL PROTECTED]
>Subject: UserTransaction not working in DefaultContext
>
>Hi,
>  As of tomcat-5.0.29, it is not possible to have a
>java:/comp/UserTransaction resource working if declared from a
>DefaultContext. (ie) :
>...
>
>type="javax.transaction.UserTransaction"/>
>
>
>factory
>
>org.objectweb.jotm.UserTransactionFactory
>
>
>jotm.timeout
>60
>
>
>
>...
>
>  
>   type="javax.transaction.UserTransaction"/>
>   
>
>.
>
>  As far as i have investigated the problem, DefaultContext resources
>are not avaliable as NamingResources when NamingContextListener
>creates the NamingContext for the Context
>(NamingContextListener.createNamingContext()). So at the moment
>NamingContext is created, the java:/comp/UserTransation resource is
>added with an empty TransactionRef object. Later, in the life cicle,
>when DefaultContext resources are added to the context, in this case a
>ResourceLink pointing to the UserTransaction  global resource, we get
>a NameAlreadyBoundException, so the previously registered
>TransactionRef object remains without config parameters.
>  The UserTransaction works fine if included in each application's own
>context.xml file.
>  So, as i haven't found any notes regarding this anywhere (manual,
>list and Bugzilla), it is (probably) an issue to be raised (or is it
>anticipated behaviour ?).
>
>Thanks.
>---
>Ricardo
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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

DO NOT REPLY [Bug 28331] - Unpredictable switch from UTF-8 to other encoding in Response

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=28331

Unpredictable switch from UTF-8 to other encoding in Response

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Minor   |Normal
 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 19:17 ---
Actually, I'm stupid, it's trivial, because I've already seen the bug. The
problem is that your Java2D stuff you're using has some threading weirdness. So
it accesses slightly asynchronously the response object, causing it to become
committed during the start of the processing of the next request. The issue
occurs when there are problems with the connection (IOE during rapid requests
from client disconnects). So you have a bad servlet, and your bug is INVALID.

Two solutions:
a) Write to a buffer first (ie, if something bad happens, no harm done, since
Java2D won't have any Tomcat object to mess with).
b) Run the security manager (so that the facade objects get discarded to protect
the integrity and isolation of requests). This will cause NPEs to be thrown
during each invalid access.

See, I told you it wouldn't be pretty for your issue ;)

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

UserTransaction not working in DefaultContext

[Ricardo Matinata]

Hi,
  As of tomcat-5.0.29, it is not possible to have a
java:/comp/UserTransaction resource working if declared from a
DefaultContext. (ie) :
...




factory
org.objectweb.jotm.UserTransactionFactory


jotm.timeout
60



...

  
   
   

.

  As far as i have investigated the problem, DefaultContext resources
are not avaliable as NamingResources when NamingContextListener
creates the NamingContext for the Context
(NamingContextListener.createNamingContext()). So at the moment 
NamingContext is created, the java:/comp/UserTransation resource is
added with an empty TransactionRef object. Later, in the life cicle,
when DefaultContext resources are added to the context, in this case a
ResourceLink pointing to the UserTransaction  global resource, we get
a NameAlreadyBoundException, so the previously registered
TransactionRef object remains without config parameters.
  The UserTransaction works fine if included in each application's own
context.xml file.
  So, as i haven't found any notes regarding this anywhere (manual,
list and Bugzilla), it is (probably) an issue to be raised (or is it
anticipated behaviour ?).

Thanks.
---
Ricardo

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

DO NOT REPLY [Bug 28331] - Unpredictable switch from UTF-8 to other encoding in Response

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=28331

Unpredictable switch from UTF-8 to other encoding in Response

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Critical|Minor



--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 19:00 ---
Right. And, unsurprisingly, this is a so specific case it is ridiculous. I
wonder what is causing this at this time, but all I know is that the evaluation
is going to cost me to spend a lot of time, and in the end isn't going to be
pretty for your issue.

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

DO NOT REPLY [Bug 28331] - Unpredictable switch from UTF-8 to other encoding in Response

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=28331

Unpredictable switch from UTF-8 to other encoding in Response

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 OS/Version|Windows NT/2K   |All
 Resolution|INVALID |
Version|5.0.16  |Unknown



--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 18:42 ---
I have attached three files which could help track this problem. There is simple
web application which one JSP page and servlet which generates simple picture.
Other two files are screenshots which demonstrate the problem.

To trigger this bug you have to run this app and refresh a couple of times JSP
page in Mozilla (or other browser). From time to time national letters will be
wrongly encoded (ISO-8859-1 instead of UTF-8). It is hard to tell how many times
you have to refresh the page for this error to occur, but eventually it will.

This error I encountered on Linux system (Fedora Core 1 and 2), with JDK 1.4.2
and JDK 5.0 and on any version of Tomcat 5 I have tested (even the new ones).

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

DO NOT REPLY [Bug 28331] - Unpredictable switch from UTF-8 to other encoding in Response

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=28331

Unpredictable switch from UTF-8 to other encoding in Response





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 18:35 ---
Created an attachment (id=13094)
Screenshot of bad execution of testweb application

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

Re: java.io.tempdir Problems

[Martin Gainty]

Good Afternoon Michael
Perusing the Manual for Jspc at
http://64.233.167.104/search?q=cache:pfbfEPvvvHUJ:www.gefionsoftware.com/Lit
eWebServer/lws-jsp/ReferenceManual.pdf+TOMCAT+java.io.tempDir+-Djava.io.temp
Dir&hl=en
formal syntax for the JSPC command
jspc [options] -webapp web-app-root-dir
Where option
-d output-dir specifies
The -d output-dir specification is the directory specified by the
java.io.tempdir system property
I see that there are 2 ways to specify java.io.tempdir System Property
Anyone else
The directory specified by the java.io.tempdirsystem property The directory
specified by the java.io.tempdirsystem property The directory specified by
the java.io.tempdirsystem property The directory specified by the
java.io.tempdir???
Martin
- Original Message -
From: "Michael McGrady" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, October 14, 2004 11:46 AM
Subject: Re: java.io.tempdir Problems


> Martin,
>
> Perhaps I should add, Martin, that if I set the environment variables
> for java.io.tempdir and -Djava.io.tempdir in the application but not in
> Tomcat startup, I don't have the problem.  I am a bit confused about
> whether to use java.io.tempdir or -Djava.io.tempdir.  Can you explain a
> bit about that?
>
> Michael McGrady
>
> Martin Gainty wrote:
>
> >Michael
> >createTempFile employs 3 steps algorithm to locate/create "tempDir"
> >1) Attempt to retrieve the value of "javax.servlet.context.tempdir" from
the
> >   ServletContext
> >2) If that's not found, attempt to retrieve the value of the
init-parameter
> >   "tempDir"
> >3) If that's not found, default to the system-wide temp directory
specified
> >   by the system property "java.io.tempdir"
> >A)what is the value of "javax.servlet.context.tempdir" from the
> >ServletContext?
> >B)what is the value of the init-parameter   "tempDir"?
> >Martin-
> >- Original Message -
> >From: "Michael McGrady" <[EMAIL PROTECTED]>
> >To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> >Sent: Thursday, October 14, 2004 3:16 AM
> >Subject: java.io.tempdir Problems
> >
> >
> >
> >
> >>I hope this is Tomcat related.  If not, please accept my apologies, and
> >>give me direction.  I have removed from my Tomcat 5 (Struts 1.2 using a
> >>custom taglib) service the java.io.tempdir setting because when I use
> >>the following code:
> >>
> >> File file = new File(Classpath.WEB_INF +
> >> "resource"+ File.separator +
> >> "content_type"+ File.separator +
> >> "ttf" + File.separator +
> >>  physicalName);
> >> FileInputStream fontStream = new FileInputStream(file);
> >> Font font = Font.createFont(Font.TRUETYPE_FONT,fontStream);
> >> font = font.deriveFont(attributes);
> >> fontStream.close();
> >>
> >>I get temp files of around 50 - 150 kilobytes each written to the temp
> >>directory.  I requested assistance on Tomcat User without an answer.
> >>
> >>Anyway, I assume that there may be a concurrency issue of somekind.  Is
> >>that right?  Anyone with any assistance out there?
> >>
> >>Michael McGrady
> >>
> >>
> >>-
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >>
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> >
> >
>
>

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

DO NOT REPLY [Bug 28331] - Unpredictable switch from UTF-8 to other encoding in Response

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=28331

Unpredictable switch from UTF-8 to other encoding in Response





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 18:33 ---
Created an attachment (id=13093)
Screenshot of good execution of testweb application

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

DO NOT REPLY [Bug 28331] - Unpredictable switch from UTF-8 to other encoding in Response

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=28331

Unpredictable switch from UTF-8 to other encoding in Response





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 18:32 ---
Created an attachment (id=13092)
Test WAR which can trigger this error

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

DO NOT REPLY [Bug 31090] - The session "disappears" when the context name contains the space character

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31090

The session "disappears" when the context name contains the space character





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 18:11 ---
Actually, I think cookies shouldn't be URL encoded. See the ServerCookie class,
and in particular the maybeQuote and isToken methods. Now ' ' isn't part of the
"special" list anymore, for some reason.

OTOH, the Cookie class from the servlet API includes:
private static final String tspecials = ",; ";

I think the bug will only need a change there.

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

Re: DO NOT REPLY [Bug 31090] -

[dlofgren]

Please be aware that my e-mail address has changed, effective immediately please send 
to [EMAIL PROTECTED]  Thank you.



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

DO NOT REPLY [Bug 31090] - The session "disappears" when the context name contains the space character

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31090

The session "disappears" when the context name contains the space character





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 18:02 ---
Maybe add a URL encoded path field on the Context. (URL encoding stuff all the
time is a bit expensive, and it could be needed)
I'll try it later today.

BTW, before making any changes: cookie values should be URL encoded then ? I
don't remember that, but maybe it's true. Can anyone confirm ?

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

Re: DO NOT REPLY [Bug 31090] -

[dlofgren]

Please be aware that my e-mail address has changed, effective immediately please send 
to [EMAIL PROTECTED]  Thank you.



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

DO NOT REPLY [Bug 31090] - The session "disappears" when the context name contains the space character

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31090

The session "disappears" when the context name contains the space character





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 18:00 ---
If characters other than spaces don't need to be considered, maybe use this
patch on 5.5x. and use the URLEncoder for the older release?

Note:  The Request class doesn't import URLEncoder yet so this means one more
object created for each request.  This needs to be added to the object creation
involved with pulling and replacing the "/".   Probably trivial but I know there
is a lot of effort being made to increase performance and it's a shame to add
more overhead just to support spaces in a context path.

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

DO NOT REPLY [Bug 31656] - Tomcat 5 should be updated to build with recent struts

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31656

Tomcat 5 should be updated to build with recent struts

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement



--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 17:39 ---
We've been building the admin webapp against Struts 1.1.  I'm changing this 
issue to an enhancement issue, and I'll look into the actual modifications 
needed to make it build under Struts 1.2.  If you have patches that will make 
struts 1.2 compilation work, please post them, and they'd be much appreciated.

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

DO NOT REPLY [Bug 31090] - The session "disappears" when the context name contains the space character

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31090

The session "disappears" when the context name contains the space character





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 17:39 ---
Ahh, good point.

I originally went with the URLEncoder but it was encoding the "/" at the
beginning.  

So, to go this route, I would either need to strip out the "/" before encoding or 
do a replace afterwards.

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

DO NOT REPLY [Bug 31645] - do not use external compiler unless a non-mainstream compiler is configured

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31645

do not use external compiler unless a non-mainstream compiler is configured

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 17:37 ---
I have one thought at this point: please don't use Bugzilla as a discussion 
forum.  Use the mailing list(s) to discuss possible enhancements, problems, 
issues, workarounds, etc.  If you have a concrete bug (reproducible, etc.), 
open a Bugzilla issue.  If you have a concrete enhancement, i.e. a .diff patch 
to current code, open a Bugzilla enhancement issue.  But don't just open 
Bugzilla issues asking for thoughts.  Thanks ;)

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

DO NOT REPLY [Bug 31720] - JNDI NamingContext is not thread safe

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31720

JNDI NamingContext is not thread safe





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 17:37 ---
You may want to submit this as a patch here
http://incubator.apache.org/directory/subprojects/directory-naming/index.html

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

DO NOT REPLY [Bug 31623] - [PATCH] setclasspath.sh script os400 problems

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31623

[PATCH] setclasspath.sh script os400 problems

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 17:35 ---
OK, done on both the Tomcat 5.0 and 5.5 branches.  Thank you for submitting 
this patch.

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

cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

[yoavs]

yoavs   2004/10/14 10:33:30

  Modified:catalina/src/bin Tag: TOMCAT_5_0 setclasspath.sh
   webapps/docs Tag: TOMCAT_5_0 changelog.xml
  Log:
  Bugzilla 31623
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.7.2.2   +3 -3  jakarta-tomcat-catalina/catalina/src/bin/setclasspath.sh
  
  Index: setclasspath.sh
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/setclasspath.sh,v
  retrieving revision 1.7.2.1
  retrieving revision 1.7.2.2
  diff -u -r1.7.2.1 -r1.7.2.2
  --- setclasspath.sh   21 Aug 2004 15:49:50 -  1.7.2.1
  +++ setclasspath.sh   14 Oct 2004 17:33:30 -  1.7.2.2
  @@ -10,7 +10,7 @@
 echo "This environment variable is needed to run this program"
 exit 1
   fi
  -if $os400; then
  +if [ "$os400" = "true" ]; then
 if [ ! -x "$JAVA_HOME"/bin/java -o ! -x "$JAVA_HOME"/bin/javac ]; then
   echo "The JAVA_HOME environment variable is not defined correctly"
   echo "This environment variable is needed to run this program"
  @@ -55,7 +55,7 @@
   
   # Set standard commands for invoking Java.
   _RUNJAVA="$JAVA_HOME"/bin/java
  -if [ $os400 = false ]; then
  +if [ "$os400" != "true" ]; then
 _RUNJDB="$JAVA_HOME"/bin/jdb
   fi
   _RUNJAVAC="$JAVA_HOME"/bin/javac
  
  
  
  No   revision
  No   revision
  1.70.2.53 +3 -0  jakarta-tomcat-catalina/webapps/docs/changelog.xml
  
  Index: changelog.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
  retrieving revision 1.70.2.52
  retrieving revision 1.70.2.53
  diff -u -r1.70.2.52 -r1.70.2.53
  --- changelog.xml 14 Oct 2004 17:26:48 -  1.70.2.52
  +++ changelog.xml 14 Oct 2004 17:33:30 -  1.70.2.53
  @@ -25,6 +25,9 @@
 
   31273: Add support for derefaliases in JNDIRealm. (markt)
 
  +  
  +31623: Better OS400 support in setclasspath.sh. (yoavs)
  +  
   
 
   
  
  
  

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

cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

[yoavs]

yoavs   2004/10/14 10:32:04

  Modified:catalina/src/bin setclasspath.sh
   webapps/docs changelog.xml
  Log:
  Bugzilla 31623
  
  Revision  ChangesPath
  1.9   +3 -3  jakarta-tomcat-catalina/catalina/src/bin/setclasspath.sh
  
  Index: setclasspath.sh
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/setclasspath.sh,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- setclasspath.sh   26 Jul 2004 22:01:19 -  1.8
  +++ setclasspath.sh   14 Oct 2004 17:32:04 -  1.9
  @@ -10,7 +10,7 @@
 echo "This environment variable is needed to run this program"
 exit 1
   fi
  -if $os400; then
  +if [ "$os400" = "true" ]; then
 if [ ! -x "$JAVA_HOME"/bin/java -o ! -x "$JAVA_HOME"/bin/javac ]; then
   echo "The JAVA_HOME environment variable is not defined correctly"
   echo "This environment variable is needed to run this program"
  @@ -55,7 +55,7 @@
   
   # Set standard commands for invoking Java.
   _RUNJAVA="$JAVA_HOME"/bin/java
  -if [ $os400 = false ]; then
  +if [ "$os400" != "true" ]; then
 _RUNJDB="$JAVA_HOME"/bin/jdb
   fi
   _RUNJAVAC="$JAVA_HOME"/bin/javac
  
  
  
  1.147 +3 -0  jakarta-tomcat-catalina/webapps/docs/changelog.xml
  
  Index: changelog.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
  retrieving revision 1.146
  retrieving revision 1.147
  diff -u -r1.146 -r1.147
  --- changelog.xml 14 Oct 2004 17:25:32 -  1.146
  +++ changelog.xml 14 Oct 2004 17:32:04 -  1.147
  @@ -43,6 +43,9 @@
 
   31273: Add support for derefaliases in JNDIRealm. (markt)
 
  +  
  +31623: Better OS400 support in setclasspath.sh. (yoavs)
  +  
   
 
   
  
  
  

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

DO NOT REPLY [Bug 31720] - JNDI NamingContext is not thread safe

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31720

JNDI NamingContext is not thread safe





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 17:33 ---
There are no needs for thread safety, as the ENC is read only (so if it's read
only, then there's no problem).

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

Re: 5.0.29 JSP compilation fails when using JDK 1.5.0

[Jess Holle]

Any chance of a 5.0.30 with this resolved in the near future?
[I take it you're back from vacation, Yoav, as I see CVS commit notices 
with your name on them.]

--
Jess Holle
Shapira, Yoav wrote:
Hi,
Thanks for spotting and reporting this issue.  While Tomcat 5.0.x
doesn't officially support J2SE 5.0, we don't want to make things worse
with new releases ;)  So my apologize for this issue.
I'm really busy today and tomorrow at work, and then I'm traveling this
weekend [it's a long holiday weekend in the US].  If someone could at
least post a .diff patch to fix this, I'd be grateful and I'll try to
commit it quickly.  If we wait for me, this issue might have to wait a
few days ;)
Thanks,
Yoav Shapira
Millennium Research Informatics
 

-Original Message-
From: Jess Holle [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 06, 2004 3:55 PM
To: Tomcat Developers List
Subject: 5.0.29 JSP compilation fails when using JDK 1.5.0
Tomcat 5.0.28 compiled JSP pages when run using JDK 1.5.0 just fine
(out-of-the-box). Also, 5.0.28 seems to work fine under JDK 1.5.0 in
general.
Tomcat 5.0.29 can no longer compile JSP pages when running under JDK
1.5.0! Given that 1.5.0 has been released and 5.0.28 works fine, I
believe this is a serious regression in 5.0.29 that should by itself
prevent it from getting a "stable" rating -- though I'd love to quickly
see a 5.0.30 including a fix for this :-)  [Tomcat 5.0.29 does seem to
work alright under 1.5.0 if you pre-compile all JSP pages via an Ant
project...]
Note that the startup environment, JSP pages, etc, are identical in
   

both
 

cases.  In both cases I use "catalina.50.bat start".  Also note that
   

the
 

JSP pages use no 1.5 features whatsoever -- I'm just trying to run with
JDK 1.5.0.  Also, both results hold both for "development" Jasper
settings (fork=false, development=true, reloading=true) and "production
Jasper settings (fork=true, development=false, reloading=false).
The symptom when this fails is the following console message:
  javac: target release 1.3 conflicts with default source release 1.5
I am *guessing* this may have something to do with the following change
log entry:
  30984 :
  Added compilerTargetVM option to Jasper. (yoavs)
--
Jess Holle
   



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

DO NOT REPLY [Bug 31720] - JNDI NamingContext is not thread safe

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31720

JNDI NamingContext is not thread safe





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 17:31 ---
We usually don't accept submissions like these, because they lead to bloat only 
to satisfy one user.  I haven't seen this request from other people on the 
mailing list, so I'll leave this issue for open for now and we'll see if it 
gets votes from others.  But don't hold your breath.

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

DO NOT REPLY [Bug 31707] - HTMLManager App doesn't confirm before undeploying or stopping app.

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31707

HTMLManager App doesn't confirm before undeploying or stopping app.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 17:29 ---
OK, fixed.  Thank you.

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

cvs commit: jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager HTMLManagerServlet.java

[yoavs]

yoavs   2004/10/14 10:26:48

  Modified:webapps/docs Tag: TOMCAT_5_0 changelog.xml
   webapps/manager/WEB-INF/classes/org/apache/catalina/manager
Tag: TOMCAT_5_0 HTMLManagerServlet.java
  Log:
  Bugzilla 31707
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.70.2.52 +3 -0  jakarta-tomcat-catalina/webapps/docs/changelog.xml
  
  Index: changelog.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
  retrieving revision 1.70.2.51
  retrieving revision 1.70.2.52
  diff -u -r1.70.2.51 -r1.70.2.52
  --- changelog.xml 10 Oct 2004 20:42:32 -  1.70.2.51
  +++ changelog.xml 14 Oct 2004 17:26:48 -  1.70.2.52
  @@ -45,6 +45,9 @@
   
 
   
  +  
  +31707: Broken JavaScript confirmation in HTML manager. (yoavs)
  +  
   
 
   
  
  
  
  No   revision
  No   revision
  1.12.2.3  +6 -6  
jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java
  
  Index: HTMLManagerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java,v
  retrieving revision 1.12.2.2
  retrieving revision 1.12.2.3
  diff -u -r1.12.2.2 -r1.12.2.3
  --- HTMLManagerServlet.java   17 Sep 2004 19:52:04 -  1.12.2.2
  +++ HTMLManagerServlet.java   14 Oct 2004 17:26:48 -  1.12.2.3
  @@ -593,9 +593,9 @@
   " \n" +
   "  \n" +
   "   {1} \n" +
  -"   {3} \n" +
  -"   {5} \n" +
  -"   {7} \n" +
  +"   {3} \n" +
  +"   {5} \n" +
  +"   {7} \n" +
   "  \n" +
   " \n" +
   "\n";
  @@ -603,10 +603,10 @@
   private static final String STOPPED_APPS_ROW_BUTTON_SECTION =
   " \n" +
   "  \n" +
  -"   {1} \n" +
  +"   {1} \n" +
   "   {3} \n" +
   "   {5} \n" +
  -"   {7} \n" +
  +"   {7} \n" +
   "  \n" +
   " \n" +
   "\n";
  
  
  

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

cvs commit: jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager HTMLManagerServlet.java

[yoavs]

yoavs   2004/10/14 10:25:32

  Modified:webapps/docs changelog.xml
   webapps/manager/WEB-INF/classes/org/apache/catalina/manager
HTMLManagerServlet.java
  Log:
  Bugzilla 31707
  
  Revision  ChangesPath
  1.146 +3 -0  jakarta-tomcat-catalina/webapps/docs/changelog.xml
  
  Index: changelog.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
  retrieving revision 1.145
  retrieving revision 1.146
  diff -u -r1.145 -r1.146
  --- changelog.xml 10 Oct 2004 20:43:49 -  1.145
  +++ changelog.xml 14 Oct 2004 17:25:32 -  1.146
  @@ -63,6 +63,9 @@
   
 
   
  +  
  +31707: Broken JavaScript confirmation in HTML manager. (yoavs)
  +  
   
 
   
  
  
  
  1.17  +6 -6  
jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java
  
  Index: HTMLManagerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- HTMLManagerServlet.java   23 Sep 2004 07:03:27 -  1.16
  +++ HTMLManagerServlet.java   14 Oct 2004 17:25:32 -  1.17
  @@ -571,9 +571,9 @@
   " \n" +
   "  \n" +
   "   {1} \n" +
  -"   {3} \n" +
  -"   {5} \n" +
  -"   {7} \n" +
  +"   {3} \n" +
  +"   {5} \n" +
  +"   {7} \n" +
   "  \n" +
   " \n" +
   "\n";
  @@ -581,10 +581,10 @@
   private static final String STOPPED_APPS_ROW_BUTTON_SECTION =
   " \n" +
   "  \n" +
  -"   {1} \n" +
  +"   {1} \n" +
   "   {3} \n" +
   "   {5} \n" +
  -"   {7} \n" +
  +"   {7} \n" +
   "  \n" +
   " \n" +
   "\n";
  
  
  

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

DO NOT REPLY [Bug 31720] - JNDI NamingContext is not thread safe

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31720

JNDI NamingContext is not thread safe





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 17:27 ---
We use this JNDI implementation in a different context, sort of like a 
indepedent module, not even in a web container. We would like to get thread 
safety out of the box. With this patch, thread safety can be enabled at will. 
It is off by default. So this is just an enhacement to your library that does 
not affect existing functionality by default. But for us, this will make our 
lifes easier (if accepted).

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

DO NOT REPLY [Bug 31090] - The session "disappears" when the context name contains the space character

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31090

The session "disappears" when the context name contains the space character





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 17:25 ---
Good investigation and finding, OK patch.  OK because replaceAll is in JDK 1.4, 
so I can use the patch as-is for Tomcat 5.5, but for Tomcat 5.0 we need the 
same thing in JDK 1.3-compatible format.  Maybe I'll just URLEncoder.encode the 
cookie's path?

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

DO NOT REPLY [Bug 29887] - Recursive Tag files modification check causes StackOverflowError

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=29887

Recursive Tag files modification check causes StackOverflowError

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 17:16 ---
*** Bug 31382 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 31382] - Stack overflow at JspServlet with self referencing JSP tag files.

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31382

Stack overflow at JspServlet with self referencing JSP tag files.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 17:16 ---
So if this is a duplicate of 29887, I'm marking it as such.  Reopen that one 
with your findings, as apparently this was fixed in 5.0.26 but your results 
show it's not really fixed, or is only partially fixed.  I'd like to keep the 
discussion in one Bugzilla item rather than two.

*** This bug has been marked as a duplicate of 29887 ***

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

DO NOT REPLY [Bug 31720] - JNDI NamingContext is not thread safe

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31720

JNDI NamingContext is not thread safe





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 17:14 ---
Why must it be thread-safe?  We can leave it up to the user web application to 
sync its own accesses to the naming context.  Is this thread safety requirement 
in the servlet spec?

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

DO NOT REPLY [Bug 31720] - JNDI NamingContext is not thread safe

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31720

JNDI NamingContext is not thread safe





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 17:03 ---
Created an attachment (id=13091)
Patch to enable SynchronizedContext wrapping

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

DO NOT REPLY [Bug 31720] - JNDI NamingContext is not thread safe

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31720

JNDI NamingContext is not thread safe





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 17:02 ---
Created an attachment (id=13090)
SynchronizedContext.java

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

DO NOT REPLY [Bug 31720] New: - JNDI NamingContext is not thread safe

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31720

JNDI NamingContext is not thread safe

   Summary: JNDI NamingContext is not thread safe
   Product: Tomcat 5
   Version: 5.0.0
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina:Modules
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


To make NamingContext thread safe, I created a synchronized context wrapper 
(SynchronizedContext) around an existing context. Then modified the code to 
wrap the NamingContext instances in SynchronizedContext if told to do so. By 
passing "org.apache.naming.synchronized" env property you can control if this 
synchronization wrapping is done or not.

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

JK Todo v.2

[Mladen Turk]

Hi all,
Seems that everyone agrees to keep the Apache 1.3
support, and to keep jk as 'stable'. Fine...
Also, JNI (like in JK2) is totally out, that's fine too.
But, I'm not in favor to put the jk in the maintaining
mode altogether. We can keep the jk stable, but that
doesn't mean that the development has to be stopped.
So I propose more pragmatic approach:
1. Documentation
Think no one objects :).
2. Add unix sockets from jk2
3. Add thread pool for IIS from jk2
4. Add shared memory from jk2 (pre-apr)
All that will keep existing code intact regarding
stability.
Any objections?
MT.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: How to get context realm from servlet and filter.

[Chris Forbis]

I seem to be having an issue :)

I tried the code you provided and did this.

I am getting a null pointer when I ask for service.  Also if I do
server.findServices() to get a list of all of them I get nothing back.
 This is from withing a Servlet to test getting these objects.

//See if we can get the container object
Server server = ServerFactory.getServer();
Service service = server.findService("Catalina");
//Next line gets NULL Pointer, because service is not found
Engine engine = (Engine) service.getContainer();
Host host = (Host) engine.findChild(engine.getDefaultHost());
Container[] containers = host.findChildren();
for (int i = 0; i < containers.length; i++) {
  Container container = containers[i];
  out.println(" >From: Chris Forbis [mailto:[EMAIL PROTECTED]
> >Sent: Thursday, October 14, 2004 11:02 AM
> >To: Tomcat Developers List
> >Subject: Re: How to get context realm from servlet and filter.
> >
> >Quick follow-up to your post.
> >
> >I understand what you are saying.  But I am not sure how to get access
> >to the Container, can you point me in the correct direction?
> >
> >Thanks!
> >
> >
> >On Thu, 14 Oct 2004 08:43:23 -0400, Shapira, Yoav
> <[EMAIL PROTECTED]>
> >wrote:
> >>
> >> Hi,
> >> A Realm is associated with a Container, not necessarily a Context, so
> >> the method is appropriately placed in the Container interface, a
> parent
> >> of the Context interface.  Obviously all this is not part of the
> Servlet
> >> API, so you'll have to write Tomcat-specific code to get it.
> >>
> >> Yoav Shapira http://www.yoavshapira.com
> >>
> >>
> >> >-Original Message-
> >> >From: Chris Forbis [mailto:[EMAIL PROTECTED]
> >> >Sent: Wednesday, October 13, 2004 6:24 PM
> >> >To: tomcat-dev
> >> >Subject: How to get context realm from servlet and filter.
> >> >
> >> >I am trying to get the current contexts realms from a servlet (and
> >> >maybe a filter).  I do not see a getContext().getRealm() method.  So
> I
> >> >am guessing there is another way to get to this, but I do not see
> it.
> >> >
> >> >Can any one provide some quick direction to me on this.  Thank you!
> >> >
> >> >Chris
> >> >
> >>
> >-
> >> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >> This e-mail, including any attachments, is a confidential business
> >communication, and may contain information that is confidential,
> >proprietary and/or privileged.  This e-mail is intended only for the
> >individual(s) to whom it is addressed, and may not be saved, copied,
> >printed, disclosed or used by anyone else.  If you are not the(an)
> intended
> >recipient, please immediately delete this e-mail from your computer
> system
> >and notify the sender.  Thank you.
> >>
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >-
> 
> 
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> 
> This e-mail, including any attachments, is a confidential business communication, 
> and may contain information that is confidential, proprietary and/or privileged.  
> This e-mail is intended only for the individual(s) to whom it is addressed, and may 
> not be saved, copied, printed, disclosed or used by anyone else.  If you are not 
> the(an) intended recipient, please immediately delete this e-mail from your computer 
> system and notify the sender.  Thank you.
> 
>

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

RE: Contributed Launchers in 5.0.29?

[Shapira, Yoav]

Hi,
We saw your reply a few days ago, there's no need to repost.  If someone
were interested and had time to act upon it, they'd have replied.  So
for now, please don't hold your breath.  You have your scripts already,
use them and be merry.  We're not stopping any progress on your work,
this is not a bug, and we might (or might not) add them to the Tomcat
distro when we have time.

Yoav Shapira http://www.yoavshapira.com


>-Original Message-
>From: Leslie Kishalmi [mailto:[EMAIL PROTECTED]
>Sent: Thursday, October 14, 2004 12:07 PM
>To: Tomcat Developers List
>Subject: Contributed Launchers in 5.0.29?
>
>Thanks for your quick reply!
>
>  Let see. Cant we create a contrib directory under bin (or under the
>catalina root itself) it would contain some readme which says these
>stuff are officially not supported. Then comes some subdirectories per
>OS and place the launchers there.
>For a normal user the name of "contrib" is enough to mark those stuff
>"AS IS" without official support.
>
>Leslie Kishalmi
>
>
>Shapira, Yoav wrote:
>
>>Hi,
>>We've seen your enhancement submission -- thank you for that.  We have
>>several others along the same lines, for different operating systems.
>>The question is where to put them such that it's clear to everyone we
>>don't support them.  I don't know the answer to that question, so I've
>>asked on this list, and apparently no one else knows or cares that
much.
>>So we're at a standstill.  Don't hold your breath ;)
>>
>>Yoav Shapira http://www.yoavshapira.com
>>
>>
>>
>>
>>>-Original Message-
>>>From: Leslie Kishalmi [mailto:[EMAIL PROTECTED]
>>>Sent: Tuesday, October 12, 2004 12:21 PM
>>>To: [EMAIL PROTECTED]
>>>Subject: OS/2 Launchers in 5.0.29?
>>>
>>>Dear all,
>>>
>>>I've filed http://issues.apache.org/bugzilla/show_bug.cgi?id=31361 ,
>>>asking for adding OS/2 launchers to the tomcat distribution nearly a
>>>month ago. I've also prepared the full set of launchers. I've seen
that
>>>5.0.29 is coming out. Can't add the OS/2 launchers to it. I'm know
that
>>>OS/2 is not officially supported by the TomCat team, but I would. It
>>>also would help to support NetBeans Web Development on OS/2. I also
>>>think those launchers won't break anything.
>>>
>>>Thanks,
>>>
>>>   Laszlo Kishalmi
>>>
>>>-
>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>>
>>
>>
>>This e-mail, including any attachments, is a confidential business
>communication, and may contain information that is confidential,
>proprietary and/or privileged.  This e-mail is intended only for the
>individual(s) to whom it is addressed, and may not be saved, copied,
>printed, disclosed or used by anyone else.  If you are not the(an)
intended
>recipient, please immediately delete this e-mail from your computer
system
>and notify the sender.  Thank you.
>>
>>
>>-
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>>
>>
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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

Contributed Launchers in 5.0.29?

[Leslie Kishalmi]

Thanks for your quick reply!
 Let see. Cant we create a contrib directory under bin (or under the
catalina root itself) it would contain some readme which says these
stuff are officially not supported. Then comes some subdirectories per
OS and place the launchers there.
For a normal user the name of "contrib" is enough to mark those stuff
"AS IS" without official support.
Leslie Kishalmi
Shapira, Yoav wrote:
Hi,
We've seen your enhancement submission -- thank you for that.  We have
several others along the same lines, for different operating systems.
The question is where to put them such that it's clear to everyone we
don't support them.  I don't know the answer to that question, so I've
asked on this list, and apparently no one else knows or cares that much.
So we're at a standstill.  Don't hold your breath ;)
Yoav Shapira http://www.yoavshapira.com
 

-Original Message-
From: Leslie Kishalmi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 12, 2004 12:21 PM
To: [EMAIL PROTECTED]
Subject: OS/2 Launchers in 5.0.29?
Dear all,
I've filed http://issues.apache.org/bugzilla/show_bug.cgi?id=31361 ,
asking for adding OS/2 launchers to the tomcat distribution nearly a
month ago. I've also prepared the full set of launchers. I've seen that
5.0.29 is coming out. Can't add the OS/2 launchers to it. I'm know that
OS/2 is not officially supported by the TomCat team, but I would. It
also would help to support NetBeans Web Development on OS/2. I also
think those launchers won't break anything.
Thanks,
  Laszlo Kishalmi
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 


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

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

RE: How to get context realm from servlet and filter.

[Shapira, Yoav]

Hola,

>Re. "There's almost no conceivable good use-case for needing the actual
>Realm object in your webapp.", here is one: We receive requests from a
>dumb Windows client application (no SOAP, simple stupid proprietary XML
>format in HTTP) that sends a uid/pwd somehwere inside the POST payload,
>not even as BASIC, and so have to validate that... how would you do
that?

Yeah, that's why I said "almost." ;)  There's always someone somewhere
with a legacy app with a proprietary protocol, and in those cases one
usually must take extra measures.  Yours seems like such a case.  I'm
well aware that it's impossible for any one person to preclude the
existence of any use-case given Tomcat's amazingly wide user base, and
that's why I included the "almost" in my assertion that you quote above
;)

Of course, depending on the amount of control you have, and/or your
requirements, one might argue that you time is better spent modifying
the Windows client app to use a standard authentication approach.  But
that's beyond the scope of this thread or this mailing list in general.

>On Tomcat however that JAAS approach is not so far possible. See also
my
>post yesterday "Authenticate against realm in web app: JAAS
>TomcatRealmProxyLoginModule? (WAS: The good way of making JAAS and
Realm
>authentication use the same back-end authentication system?)".

I didn't follow your thread yesterday.  But if you end up writing such a
module, I'd be very interested in seeing it, and of course with your
permission incorporating it into Tomcat.

Yoav



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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

Re: java.io.tempdir Problems

[Michael McGrady]

Martin,
Perhaps I should add, Martin, that if I set the environment variables 
for java.io.tempdir and -Djava.io.tempdir in the application but not in 
Tomcat startup, I don't have the problem.  I am a bit confused about 
whether to use java.io.tempdir or -Djava.io.tempdir.  Can you explain a 
bit about that?

Michael McGrady
Martin Gainty wrote:
Michael
createTempFile employs 3 steps algorithm to locate/create "tempDir"
1) Attempt to retrieve the value of "javax.servlet.context.tempdir" from the
  ServletContext
2) If that's not found, attempt to retrieve the value of the init-parameter
  "tempDir"
3) If that's not found, default to the system-wide temp directory specified
  by the system property "java.io.tempdir"
A)what is the value of "javax.servlet.context.tempdir" from the
ServletContext?
B)what is the value of the init-parameter   "tempDir"?
Martin-
- Original Message -
From: "Michael McGrady" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, October 14, 2004 3:16 AM
Subject: java.io.tempdir Problems
 

I hope this is Tomcat related.  If not, please accept my apologies, and
give me direction.  I have removed from my Tomcat 5 (Struts 1.2 using a
custom taglib) service the java.io.tempdir setting because when I use
the following code:
File file = new File(Classpath.WEB_INF +
"resource"+ File.separator +
"content_type"+ File.separator +
"ttf" + File.separator +
 physicalName);
FileInputStream fontStream = new FileInputStream(file);
Font font = Font.createFont(Font.TRUETYPE_FONT,fontStream);
font = font.deriveFont(attributes);
fontStream.close();
I get temp files of around 50 - 150 kilobytes each written to the temp
directory.  I requested assistance on Tomcat User without an answer.
Anyway, I assume that there may be a concurrency issue of somekind.  Is
that right?  Anyone with any assistance out there?
Michael McGrady
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   

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

 

Re: java.io.tempdir Problems

[Michael McGrady]

Martin Gainty wrote:
Michael
createTempFile employs 3 steps algorithm to locate/create "tempDir"
1) Attempt to retrieve the value of "javax.servlet.context.tempdir" from the
  ServletContext
2) If that's not found, attempt to retrieve the value of the init-parameter
  "tempDir"
3) If that's not found, default to the system-wide temp directory specified
  by the system property "java.io.tempdir"
A)what is the value of "javax.servlet.context.tempdir" from the
ServletContext?
B)what is the value of the init-parameter   "tempDir"?
Martin-
- Original Message -
From: "Michael McGrady" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, October 14, 2004 3:16 AM
Subject: java.io.tempdir Problems
 

I hope this is Tomcat related.  If not, please accept my apologies, and
give me direction.  I have removed from my Tomcat 5 (Struts 1.2 using a
custom taglib) service the java.io.tempdir setting because when I use
the following code:
File file = new File(Classpath.WEB_INF +
"resource"+ File.separator +
"content_type"+ File.separator +
"ttf" + File.separator +
 physicalName);
FileInputStream fontStream = new FileInputStream(file);
Font font = Font.createFont(Font.TRUETYPE_FONT,fontStream);
font = font.deriveFont(attributes);
fontStream.close();
I get temp files of around 50 - 150 kilobytes each written to the temp
directory.  I requested assistance on Tomcat User without an answer.
Anyway, I assume that there may be a concurrency issue of somekind.  Is
that right?  Anyone with any assistance out there?
Michael McGrady
Martin,
First, thanks for responding. 

Second, the entirety of the startup code setting my java.io.tempdir 
system property is after this note, but the value of the property is 
"%CATALINA_HOME%\temp.  The value of javax.servlet.context.tempdir is 
C:\crackwillow\work\Catalina\localhost\_ .  Following the knowledge I 
gleaned from your question and specifications, I reset things in a 
plugin, and I now have the values at runtime of:

javax.servlet.context.tempdir = C:\crackwillow\work\Catalina\localhost\_
-Djava.io.tempdir = C:/crackwillow/temp
java.io.tempdir = C:/crackwillow/temp
Prior to doing this, my values for both -Djava.io.tempdir and 
java.io.tempdir were null. 

I have kept the value of the java.io.tempdir in my  at 
C:/crackwillow/temp.  When I run the font program as previously 
indicated (see above), I still get the tmp files that do not go away.  
Their names are as follows: +~JF3174.tmp and they run consequtively. 

What do you think is up?
Michael McGrady
@echo off
if "%OS%" == "Windows_NT" setlocal
rem 
---
rem NT Service Install/Uninstall script
rem
rem Options
rem installInstall the service using Tomcat5 as service 
name.
remService is installed using default settings.
rem remove Remove the service from the System.
rem
rem name(optional) If the second argument is present it is 
considered
remto be new service 
name  
rem
rem $Id: service.bat,v 1.1 2003/12/27 18:56:58 mdsh Exp $
rem 
---

rem Guess CATALINA_HOME if not defined
set CURRENT_DIR=%cd%
if not "%CATALINA_HOME%" == "" goto gotHome
set CATALINA_HOME=%cd%
if exist "%CATALINA_HOME%\bin\tomcat.exe" goto okHome
rem CD to the upper dir
cd ..
set CATALINA_HOME=%cd%
:gotHome
if exist "%CATALINA_HOME%\bin\tomcat.exe" goto okHome
echo The tomcat.exe was not found...
echo The CATALINA_HOME environment variable is not defined correctly.
echo This environment variable is needed to run this program
goto end
:okHome
set EXECUTABLE="%CATALINA_HOME%\bin\tomcat.exe"
rem Set default Service name
set SERVICE_NAME=Tomcat5
if "%1" == "" goto displayUsage
if "%2" == "" goto setServiceName
set SERVICE_NAME=%2
:setServiceName
if %1 == install goto doInstall
if %1 == remove goto doRemove
echo Unknown parameter "%1"
:displayUsage
echo
echo Usage: service.bat install/remove [service_name]
goto end
:doRemove
rem Remove the service
%EXECUTABLE% //DS//%SERVICE_NAME%
echo The service '%SERVICE_NAME%' has been removed
goto end
:doInstall
rem Install the service
%EXECUTABLE% //IS//%SERVICE_NAME% --DisplayName "Apache Tomcat" 
--Description "Apache Tomcat Server - http://jakarta.apache.org/tomcat/";
%EXECUTABLE% //US//%SERVICE_NAME% --Install %EXECUTABLE%
%EXECUTABLE% //US//%SERVICE_NAME% --ImagePath 
"%JAVA_HOME%\lib\tools.jar;%CATALINA_HOME%\bin\bootstrap.jar"
%EXECUTABLE% //US//%SERVICE_NAME% --Java 
"%JAVA_HOME%\jre\bin\server\jvm.dll"
%EXECUTABLE% //US//%SERVICE_NAME% --StartupClass 
org.apache.catalina.startup.Bootstrap;main;start --ShutdownClass 
org.apache.catalina.startup.Bootstrap;main;stop --Startup auto
rem Set extra param

Re: How to get context realm from servlet and filter.

[Michael Vorburger]

Yoav,
Re. "There's almost no conceivable good use-case for needing the actual 
Realm object in your webapp.", here is one: We receive requests from a 
dumb Windows client application (no SOAP, simple stupid proprietary XML 
format in HTTP) that sends a uid/pwd somehwere inside the POST payload, 
not even as BASIC, and so have to validate that... how would you do that?

Agree that container-specific code should be avoided inside applications 
unless absolutely necessary - and on other containers that's easy, 
because you can use the JAAS API to authenticate uid/pwd from within a 
web application, e.g. both WebLogic or WebSphere have built-in JAAS 
LoginModule implementations which "forward" to whatever they call a realm.

On Tomcat however that JAAS approach is not so far possible. See also my 
post yesterday "Authenticate against realm in web app: JAAS 
TomcatRealmProxyLoginModule? (WAS: The good way of making JAAS and Realm 
authentication use the same back-end authentication system?)".

Thanks,
Michael
PS: Thanks for code snippet, we'll see if that helps us to write a 
better TomcatRealmProxyLoginModule, taking a context name as 
configuration parameter.


Shapira, Yoav wrote:
Hi,
I've posted this a number of times in the past on the list, so you can
STFA.  To summarize, you'd do something like this (most of these classes
are in the org.apache.catalina package):
Server server = ServerFactory.getServer();
Service service = server.findService("Catalina");
Engine engine = (Engine) service.getContainer();
Host host = (Host) engine.findChild(engine.getDefaultHost());
Context context = (Context) host.findChild("myContext");
Realm realm = context.getRealm();
I'm using the default service name of "Catalina" above: it should match
what's in your server.xml.  I'm also using "myContext" as a dummy:
obviously that should match your webapp name.  And finally, I'm getting
the Realm from the context, because that's what you asked for, but in
reality the Realm (or another realm) may be associated with the Host or
Engine as well.  So take the above code and modify it to your needs.
As always, I caution you and everyone else to not use Tomcat-specific
(or container-specific in general) code unless absolutely necessary.
Make your app as portable as possible.  There's almost no conceivable
good use-case for needing the actual Realm object in your webapp.
Yoav Shapira http://www.yoavshapira.com
 

-Original Message-
From: Chris Forbis [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 14, 2004 11:02 AM
To: Tomcat Developers List
Subject: Re: How to get context realm from servlet and filter.
Quick follow-up to your post.
I understand what you are saying.  But I am not sure how to get access
to the Container, can you point me in the correct direction?
Thanks!
On Thu, 14 Oct 2004 08:43:23 -0400, Shapira, Yoav
   

<[EMAIL PROTECTED]>
 

wrote:
   

Hi,
A Realm is associated with a Container, not necessarily a Context, so
the method is appropriately placed in the Container interface, a
 

parent
 

of the Context interface.  Obviously all this is not part of the
 

Servlet
 

API, so you'll have to write Tomcat-specific code to get it.
Yoav Shapira http://www.yoavshapira.com
 

-Original Message-
From: Chris Forbis [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 13, 2004 6:24 PM
To: tomcat-dev
Subject: How to get context realm from servlet and filter.
I am trying to get the current contexts realms from a servlet (and
maybe a filter).  I do not see a getContext().getRealm() method.  So
   

I
 

am guessing there is another way to get to this, but I do not see
   

it.
 

Can any one provide some quick direction to me on this.  Thank you!
Chris
   

-
   

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

This e-mail, including any attachments, is a confidential business
 

communication, and may contain information that is confidential,
proprietary and/or privileged.  This e-mail is intended only for the
individual(s) to whom it is addressed, and may not be saved, copied,
printed, disclosed or used by anyone else.  If you are not the(an)
   

intended
 

recipient, please immediately delete this e-mail from your computer
   

system
 

and notify the sender.  Thank you.
   


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

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



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
sav

RE: How to get context realm from servlet and filter.

[Shapira, Yoav]

Hi,
I've posted this a number of times in the past on the list, so you can
STFA.  To summarize, you'd do something like this (most of these classes
are in the org.apache.catalina package):

Server server = ServerFactory.getServer();
Service service = server.findService("Catalina");
Engine engine = (Engine) service.getContainer();
Host host = (Host) engine.findChild(engine.getDefaultHost());
Context context = (Context) host.findChild("myContext");
Realm realm = context.getRealm();

I'm using the default service name of "Catalina" above: it should match
what's in your server.xml.  I'm also using "myContext" as a dummy:
obviously that should match your webapp name.  And finally, I'm getting
the Realm from the context, because that's what you asked for, but in
reality the Realm (or another realm) may be associated with the Host or
Engine as well.  So take the above code and modify it to your needs.

As always, I caution you and everyone else to not use Tomcat-specific
(or container-specific in general) code unless absolutely necessary.
Make your app as portable as possible.  There's almost no conceivable
good use-case for needing the actual Realm object in your webapp.

Yoav Shapira http://www.yoavshapira.com


>-Original Message-
>From: Chris Forbis [mailto:[EMAIL PROTECTED]
>Sent: Thursday, October 14, 2004 11:02 AM
>To: Tomcat Developers List
>Subject: Re: How to get context realm from servlet and filter.
>
>Quick follow-up to your post.
>
>I understand what you are saying.  But I am not sure how to get access
>to the Container, can you point me in the correct direction?
>
>Thanks!
>
>
>On Thu, 14 Oct 2004 08:43:23 -0400, Shapira, Yoav
<[EMAIL PROTECTED]>
>wrote:
>>
>> Hi,
>> A Realm is associated with a Container, not necessarily a Context, so
>> the method is appropriately placed in the Container interface, a
parent
>> of the Context interface.  Obviously all this is not part of the
Servlet
>> API, so you'll have to write Tomcat-specific code to get it.
>>
>> Yoav Shapira http://www.yoavshapira.com
>>
>>
>> >-Original Message-
>> >From: Chris Forbis [mailto:[EMAIL PROTECTED]
>> >Sent: Wednesday, October 13, 2004 6:24 PM
>> >To: tomcat-dev
>> >Subject: How to get context realm from servlet and filter.
>> >
>> >I am trying to get the current contexts realms from a servlet (and
>> >maybe a filter).  I do not see a getContext().getRealm() method.  So
I
>> >am guessing there is another way to get to this, but I do not see
it.
>> >
>> >Can any one provide some quick direction to me on this.  Thank you!
>> >
>> >Chris
>> >
>>
>-
>> >To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>> This e-mail, including any attachments, is a confidential business
>communication, and may contain information that is confidential,
>proprietary and/or privileged.  This e-mail is intended only for the
>individual(s) to whom it is addressed, and may not be saved, copied,
>printed, disclosed or used by anyone else.  If you are not the(an)
intended
>recipient, please immediately delete this e-mail from your computer
system
>and notify the sender.  Thank you.
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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

Re: How to get context realm from servlet and filter.

[Chris Forbis]

Quick follow-up to your post.

I understand what you are saying.  But I am not sure how to get access
to the Container, can you point me in the correct direction?

Thanks!


On Thu, 14 Oct 2004 08:43:23 -0400, Shapira, Yoav <[EMAIL PROTECTED]> wrote:
> 
> Hi,
> A Realm is associated with a Container, not necessarily a Context, so
> the method is appropriately placed in the Container interface, a parent
> of the Context interface.  Obviously all this is not part of the Servlet
> API, so you'll have to write Tomcat-specific code to get it.
> 
> Yoav Shapira http://www.yoavshapira.com
> 
> 
> >-Original Message-
> >From: Chris Forbis [mailto:[EMAIL PROTECTED]
> >Sent: Wednesday, October 13, 2004 6:24 PM
> >To: tomcat-dev
> >Subject: How to get context realm from servlet and filter.
> >
> >I am trying to get the current contexts realms from a servlet (and
> >maybe a filter).  I do not see a getContext().getRealm() method.  So I
> >am guessing there is another way to get to this, but I do not see it.
> >
> >Can any one provide some quick direction to me on this.  Thank you!
> >
> >Chris
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> This e-mail, including any attachments, is a confidential business communication, 
> and may contain information that is confidential, proprietary and/or privileged.  
> This e-mail is intended only for the individual(s) to whom it is addressed, and may 
> not be saved, copied, printed, disclosed or used by anyone else.  If you are not 
> the(an) intended recipient, please immediately delete this e-mail from your computer 
> system and notify the sender.  Thank you.
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

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

cvs commit: jakarta-tomcat-site/xdocs-faq performance.xml

[yoavs]

yoavs   2004/10/14 06:30:14

  Modified:docs/faq performance.html
   docs/faq/printer performance.html
   xdocs-faq performance.xml
  Log:
  FAQ update.
  
  Revision  ChangesPath
  1.10  +104 -67   jakarta-tomcat-site/docs/faq/performance.html
  
  Index: performance.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/docs/faq/performance.html,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- performance.html  14 Sep 2004 00:04:44 -  1.9
  +++ performance.html  14 Oct 2004 13:30:14 -  1.10
  @@ -1,68 +1,105 @@
  -Tomcat FAQ - Performance and Monitoring

  -  dt { font-size : larger;  font-weight : bold }

  -  dd {padding-bottom : 10px;}

  -http://jakarta.apache.org/";>http://jakarta.apache.org//images/jakarta-logo.gif";>http://jakarta.apache.org/tomcat/";>LinksTomcat 
HomeFAQ 
HomeContentsBugsClass Not 
FoundConnectorsDatabaseDeploymenthttp://wiki.apache.org/jakarta-tomcat/HowTo";>How do ILinux / UnixLoggingOS/2, z/OSMemoryMetaMiscellaneousMonitoring / 
Performancehttp://wiki.apache.org/jakarta-tomcat/UsefulLinks";>Other 
ResourcesSecurityWhich VersionTomcat User 
Listhttp://wiki.apache.org/jakarta-tomcat/";>WikiWindowsTomcat 
FAQPerformance and Monitoringprint-friendlyversion

  -Preface

  -

  -  This is about Tomcat performance.

  -  

  -[thread]

  -http://marc.theaimsgroup.com/?t=10445538312&r=1&w=2";>

  -Tomcat Performance Concerns

  -

  -

  -[thread]

  -http://marc.theaimsgroup.com/?t=10359888531&r=1&w=2";>

  -How do I increase performance on Tomcat?

  -

  -

  -  

  -

  -  Other (non-exhaustive) notes:

  -  

  -   

  -Stress test your webapp. You can do this via

  -http://jakarta.apache.org/jmeter/";>JMeter,

  -http://www.joedog.org/siege/";>siege,

  -http://httpd.apache.org/test/flood/";>flood,

  -and other tools. Google is your friend.

  -

  -  Tweak your UNIX box! Look at ulimit and kernel parameters.

  -

  -  Bad design will hurt performance.

  -

  -  Look at http://java.quest.com/jprobe/jprobe.shtml";>JProbe,

  -  or http://www.borland.com/optimizeit/";>OptimizeIt, or other

  -  profiling tools. Lots of people recommend these tools.

  -  This is not an endorsement for them, I just

  -  notice other people like them.

  -

  -  

  -

  -

  -Questions

  - 

  -   

  -  Is Tomcat faster than serving static HTML pages than apache?

  -   

  - 

  -Answers

  -

  -  

  -

  -  Is Tomcat faster than serving static HTML pages than apache?

  -

  -  

  -  

  -Yes depending on how you tune it. And NO depending on how you tune it.

  -Anything less starts a religious war. We recommend performing your own

  -benchmarks and

  -http://marc.theaimsgroup.com/?l=tomcat-user&m=106036177509367&w=2";>

  -see for yourself.

  -  

  -

  -

  -Copyright © 1999-2003, Apache Software Foundation

  +Tomcat FAQ - Performance and Monitoring
  +  dt { font-size : larger;  font-weight : bold }
  +  dd {padding-bottom : 10px;}
  +http://jakarta.apache.org/";>http://jakarta.apache.org//images/jakarta-logo.gif";>http://jakarta.apache.org/tomcat/";>LinksTomcat 
HomeFAQ 
HomeContentsBugsClass Not 
FoundConnectorsDatabaseDeploymenthttp://wiki.apache.org/jakarta-tomcat/HowTo";>How do ILinux / UnixLoggingOS/2, z/OSMemoryMetaMiscellaneousMonitoring / 
Performancehttp://wiki.apache.org/jakarta-tomcat/UsefulLinks";>Other 
ResourcesSecurityWhich VersionTomcat User 
Listhttp://wiki.apache.org/jakarta-tomcat/";>WikiWindowsTomcat 
FAQPerformance and Monitoringprint-friendlyversion
  +Preface
  +
  +  This is about Tomcat performance.
  +  
  +[thread]
  +http://marc.theaimsgroup.com/?t=10445538312&r=1&w=2";>
  +Tomcat Performance Concerns
  +
  +
  +[thread]
  +http://marc.theaimsgroup.com/?t=10359888531&r=1&w=2";>
  +How do I increase performance on Tomcat?
  +
  +
  +  
  +
  +  Other (non-exhaustive) notes:
  +  
  +   
  +Stress test your webapp. You can do this via
  +http://jakarta.apache.org/jmeter/";>JMeter,
  +http://www.joedog.org/siege/";>siege,
  +http://httpd.apache.org/test/flood/";>flood,
  +and other tools. Google is your friend.
  +
  +  Tweak your UNIX box! Look at ulimit and kernel parameters.
  +
  +  Bad design will hurt performance.
  +
  +  Look at http://java.quest.com/jprobe/jprobe.shtml";>JProbe,
  +  or http://www.borland.com/optimizeit/";>OptimizeIt, or other
  +  profiling tools. Lots of people recommend these tools.
  +  This is not an endorsement for them, I just
  +  not

DO NOT REPLY [Bug 4690] - sessions not scoped according to spec section 7.3

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=4690

sessions not scoped according to spec section 7.3

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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

DO NOT REPLY [Bug 4690] - sessions not scoped according to spec section 7.3

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=4690

sessions not scoped according to spec section 7.3

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

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

DO NOT REPLY [Bug 4690] - sessions not scoped according to spec section 7.3

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=4690

sessions not scoped according to spec section 7.3

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 13:11 ---
This bug has been resolved through the patch referenced to below:

http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=80223

Anyone wanting to use this functionality must remember to set the
"emptySessionPath" attribute in their connector configuration.  An example is below.

 


Many thanks to the Tomcat team for working with us to find an acceptable
solution to all parties!

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

RE: How to get context realm from servlet and filter.

[Shapira, Yoav]

Hi,
A Realm is associated with a Container, not necessarily a Context, so
the method is appropriately placed in the Container interface, a parent
of the Context interface.  Obviously all this is not part of the Servlet
API, so you'll have to write Tomcat-specific code to get it.

Yoav Shapira http://www.yoavshapira.com


>-Original Message-
>From: Chris Forbis [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, October 13, 2004 6:24 PM
>To: tomcat-dev
>Subject: How to get context realm from servlet and filter.
>
>I am trying to get the current contexts realms from a servlet (and
>maybe a filter).  I do not see a getContext().getRealm() method.  So I
>am guessing there is another way to get to this, but I do not see it.
>
>Can any one provide some quick direction to me on this.  Thank you!
>
>Chris
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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

[OFF-TOPIC] RE: java.io.tempdir Problems

[Shapira, Yoav]

Hi,
Not a Tomcat issue.  Please mark continuing off-topic posts as such as
I've done in the subject of the message, or take them elsewhere
altogether.  Thanks,

Yoav Shapira http://www.yoavshapira.com


>-Original Message-
>From: Martin Gainty [mailto:[EMAIL PROTECTED]
>Sent: Thursday, October 14, 2004 8:15 AM
>To: Tomcat Developers List
>Subject: Re: java.io.tempdir Problems
>
>Michael
>createTempFile employs 3 steps algorithm to locate/create "tempDir"
>1) Attempt to retrieve the value of "javax.servlet.context.tempdir"
from
>the
>   ServletContext
>2) If that's not found, attempt to retrieve the value of the
init-parameter
>   "tempDir"
>3) If that's not found, default to the system-wide temp directory
specified
>   by the system property "java.io.tempdir"
>A)what is the value of "javax.servlet.context.tempdir" from the
>ServletContext?
>B)what is the value of the init-parameter   "tempDir"?
>Martin-
>- Original Message -
>From: "Michael McGrady" <[EMAIL PROTECTED]>
>To: "Tomcat Developers List" <[EMAIL PROTECTED]>
>Sent: Thursday, October 14, 2004 3:16 AM
>Subject: java.io.tempdir Problems
>
>
>> I hope this is Tomcat related.  If not, please accept my apologies,
and
>> give me direction.  I have removed from my Tomcat 5 (Struts 1.2 using
a
>> custom taglib) service the java.io.tempdir setting because when I use
>> the following code:
>>
>>  File file = new File(Classpath.WEB_INF +
>>  "resource"+ File.separator +
>>  "content_type"+ File.separator +
>>  "ttf" + File.separator +
>>   physicalName);
>>  FileInputStream fontStream = new FileInputStream(file);
>>  Font font = Font.createFont(Font.TRUETYPE_FONT,fontStream);
>>  font = font.deriveFont(attributes);
>>  fontStream.close();
>>
>> I get temp files of around 50 - 150 kilobytes each written to the
temp
>> directory.  I requested assistance on Tomcat User without an answer.
>>
>> Anyway, I assume that there may be a concurrency issue of somekind.
Is
>> that right?  Anyone with any assistance out there?
>>
>> Michael McGrady
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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

Re: java.io.tempdir Problems

[Martin Gainty]

Michael
createTempFile employs 3 steps algorithm to locate/create "tempDir"
1) Attempt to retrieve the value of "javax.servlet.context.tempdir" from the
   ServletContext
2) If that's not found, attempt to retrieve the value of the init-parameter
   "tempDir"
3) If that's not found, default to the system-wide temp directory specified
   by the system property "java.io.tempdir"
A)what is the value of "javax.servlet.context.tempdir" from the
ServletContext?
B)what is the value of the init-parameter   "tempDir"?
Martin-
- Original Message -
From: "Michael McGrady" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, October 14, 2004 3:16 AM
Subject: java.io.tempdir Problems


> I hope this is Tomcat related.  If not, please accept my apologies, and
> give me direction.  I have removed from my Tomcat 5 (Struts 1.2 using a
> custom taglib) service the java.io.tempdir setting because when I use
> the following code:
>
>  File file = new File(Classpath.WEB_INF +
>  "resource"+ File.separator +
>  "content_type"+ File.separator +
>  "ttf" + File.separator +
>   physicalName);
>  FileInputStream fontStream = new FileInputStream(file);
>  Font font = Font.createFont(Font.TRUETYPE_FONT,fontStream);
>  font = font.deriveFont(attributes);
>  fontStream.close();
>
> I get temp files of around 50 - 150 kilobytes each written to the temp
> directory.  I requested assistance on Tomcat User without an answer.
>
> Anyway, I assume that there may be a concurrency issue of somekind.  Is
> that right?  Anyone with any assistance out there?
>
> Michael McGrady
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=26372

java.lang.ThreadDeath when trying to reload an application





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 08:35 ---
I hope hot deployment and redeployment is a reality. However, there are issues
when the webapp tries to interact with some services which reside in the system
classloader (logging here). Packaging webapps a little differently could solve
the problems for now.

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

Document

[craig . mcclanahan]

--  Virus Warning Message (on uusnwa0p)

Found virus WORM_NETSKY.Z in file Bill.txt 
   
 .exe (in Bill.zip)
The file is deleted.

-
Important bill!


--  Virus Warning Message (on uusnwa0p)

Bill.zip is removed from here because it contains a virus.

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

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

[remm]

remm2004/10/14 01:14:47

  Modified:catalina/src/share/org/apache/catalina/servlets
CGIServlet.java
  Log:
  - Workaround for client socket exceptions occurring while running a CGI, which could 
cause the external process to hang.
  - Please test this (I didn't).
  
  Revision  ChangesPath
  1.27  +20 -11
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
  
  Index: CGIServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- CGIServlet.java   28 Sep 2004 22:13:31 -  1.26
  +++ CGIServlet.java   14 Oct 2004 08:14:47 -  1.27
  @@ -1806,13 +1806,22 @@
   (new InputStreamReader(proc.getInputStream()));
   
   char[] cBuf = new char[1024];
  -while ((bufRead = commandsStdOut.read(cBuf)) != -1) {
  -if (servletContainerStdout != null) {
  -if (debug >= 4) {
  -log("runCGI: write(\"" +
  -new String(cBuf, 0, bufRead) + "\")");
  +try {
  +while ((bufRead = commandsStdOut.read(cBuf)) != -1) {
  +if (servletContainerStdout != null) {
  +if (debug >= 4) {
  +log("runCGI: write(\"" +
  +new String(cBuf, 0, bufRead) + 
"\")");
  +}
  +servletContainerStdout.write(cBuf, 0, bufRead);
   }
  -servletContainerStdout.write(cBuf, 0, bufRead);
  +}
  +} finally {
  +// Attempt to consume any leftover byte if something 
bad happens,
  +// such as a socket disconnect on the servlet side; 
otherwise, the
  +// external process could hang
  +if (bufRead != -1) {
  +while ((bufRead = commandsStdOut.read(cBuf)) != -1) 
{}
   }
   }
   
  
  
  

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

DO NOT REPLY [Bug 31382] - Stack overflow at JspServlet with self referencing JSP tag files.

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31382

Stack overflow at JspServlet with self referencing JSP tag files.





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 08:15 ---
You're right, it won't. I didn't look at how Kin-Man actually fixed it in
5.0.26. Neither am I sure if I ever verified the fix or just kept working with
my rather naive patch. I just hoped he also covered the non-trivial case (e.g.
by keeping track of all the files already checked for a dependency in the
dependency check algorithm).

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

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

[remm]

remm2004/10/14 01:07:48

  Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
  Log:
  - Remove bad shutdown logic for ms strategy.
  
  Revision  ChangesPath
  1.42  +3 -7  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java
  
  Index: PoolTcpEndpoint.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java,v
  retrieving revision 1.41
  retrieving revision 1.42
  diff -u -r1.41 -r1.42
  --- PoolTcpEndpoint.java  5 Oct 2004 22:16:20 -   1.41
  +++ PoolTcpEndpoint.java  14 Oct 2004 08:07:48 -  1.42
  @@ -342,13 +342,14 @@
   if (running) {
   if (lf) {
   tp.shutdown();
  -} else {
  -threadStop();
   }
   running = false;
   if (serverSocket != null) {
   closeServerSocket();
   }
  +if (!lf) {
  +threadStop();
  +}
   }
   }
   
  @@ -668,11 +669,6 @@
* Stop the background processing thread.
*/
   private void threadStop() {
  -try {
  -threadSync.wait(5000);
  -} catch (InterruptedException e) {
  -;
  -}
   thread = null;
   }
   
  
  
  

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

DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=26372

java.lang.ThreadDeath when trying to reload an application





--- Additional Comments From [EMAIL PROTECTED]  2004-10-14 08:06 ---
sorry you thought it was a rant, it wasn't meant to come over like that :) i 
suppose because tomcat has a manager application and reloadable class facility, 
i assumed it should do that gracefully in all circumstances. it is true i don't 
fully appreciate all the issues with this feature so i suppose this is just an 
issue we have to workaround. In fact, the workaround has been listed here now.

It is also true that this is in our case was always related to a development 
instance. 

I am interested in your comment that reload of webapp is mostly trouble and 
limited in production environments though. My understanding was that if you 
want to make a build to production or a patch of some files, you would use ant 
or similar as we do here to reconstruct the WAR to deploy. Does this not 
require tomcat being able to reload? In fact, we tell the business the intranet 
will be down for 5 minutes and post a message page up for inbound requests. We 
stop tomcat, delete the old war and expanded war files and place the new war 
and startup tomcat again. We constantly get irked by the fact that if a bug is 
on production we have to wait until the evening to patch it whereas our ASP 
coutnerparts can so easily hot-patch. We also use JSP precompilation to improve 
performance so it's not so easy to patch JSPs either.

Anyways! Cheers

PS: this was not a rant ... just inquisitive ;)

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

AW: java.io.tempdir Problems

[S. Dierkes]

This is probably not a Tomcat problem, I got the same behaviour without
Tomcat in a java application and also with a webapp in BEA. The temporary
files are created by java itself (or more precise by some font handling in
java.awt). I found this behaviour on a Windows machine independent from the
tempdir settings, i.e. if not explicitly set, some automatic detected temp
dir was chosen - depending of windows version, resp. environment variable
settings (check your TEMP, TMP settings and under XP there is some directory
under the user's directory - can't remember). BTW, your lucky with only 50
kb, depending of font these could also be also several MB. Since we had some
other problems with java.awt.font, e.g. in headless environments we wrote a
lot of wrappers for several functions, so we came around this problem a
really hard way. Some suggestions
1. okay these files are temp files, so should go away if you shutdown clean,
but from my observations this doesn't happen all the time, but setting
System.runFinalizersOnExit improved this behaviour at our first tests, but
of course this may introduce other problems.
2. our first solution was cleaning up the directory manually on startup of
application, may be you can think of a similiar solution - even on a server
application. From our observations, if you reuse the font objects there is
only one temp file per font, so after all it's not a real problem if you
gather some temp files (unless you have thousands of fonts) and clean them
up on each server start.



-Ursprüngliche Nachricht-
Von: Michael McGrady [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 14. Oktober 2004 08:16
An: Tomcat Developers List
Betreff: java.io.tempdir Problems


I hope this is Tomcat related.  If not, please accept my apologies, and
give me direction.  I have removed from my Tomcat 5 (Struts 1.2 using a
custom taglib) service the java.io.tempdir setting because when I use
the following code:

 File file = new File(Classpath.WEB_INF +
 "resource"+ File.separator +
 "content_type"+ File.separator +
 "ttf" + File.separator +
  physicalName);
 FileInputStream fontStream = new FileInputStream(file);
 Font font = Font.createFont(Font.TRUETYPE_FONT,fontStream);
 font = font.deriveFont(attributes);
 fontStream.close();

I get temp files of around 50 - 150 kilobytes each written to the temp
directory.  I requested assistance on Tomcat User without an answer.

Anyway, I assume that there may be a concurrency issue of somekind.  Is
that right?  Anyone with any assistance out there?

Michael McGrady


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



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

cvs commit: jakarta-tomcat-5 build.xml

[remm]

remm2004/10/14 00:40:34

  Modified:.build.xml
  Log:
  - JK wants to copy coyote. This used to work fine, so it's fairly odd.
  
  Revision  ChangesPath
  1.219 +1 -0  jakarta-tomcat-5/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.218
  retrieving revision 1.219
  diff -u -r1.218 -r1.219
  --- build.xml 5 Oct 2004 14:01:57 -   1.218
  +++ build.xml 14 Oct 2004 07:40:34 -  1.219
  @@ -204,6 +204,7 @@
   
 
   
  +  
   

java.io.tempdir Problems

[Michael McGrady]

I hope this is Tomcat related.  If not, please accept my apologies, and 
give me direction.  I have removed from my Tomcat 5 (Struts 1.2 using a 
custom taglib) service the java.io.tempdir setting because when I use 
the following code:

File file = new File(Classpath.WEB_INF +
"resource"+ File.separator +
"content_type"+ File.separator +
"ttf" + File.separator +
 physicalName);
FileInputStream fontStream = new FileInputStream(file);
Font font = Font.createFont(Font.TRUETYPE_FONT,fontStream);
font = font.deriveFont(attributes);
fontStream.close();
I get temp files of around 50 - 150 kilobytes each written to the temp 
directory.  I requested assistance on Tomcat User without an answer. 

Anyway, I assume that there may be a concurrency issue of somekind.  Is 
that right?  Anyone with any assistance out there?

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