DO NOT REPLY [Bug 25819] - java.lang.NoClassDefFoundError: org/apache/tomcat/util/buf/C2BConverter

[bugzilla]

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

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

java.lang.NoClassDefFoundError: org/apache/tomcat/util/buf/C2BConverter





--- Additional Comments From [EMAIL PROTECTED]  2004-01-06 04:41 ---
Based on the description of the bug, I believe that the patch I've checked in 
will fix the problem.  However, it will be a couple of days before I can free 
up a server to test Tomcat 5/Apache, so I can't really test it.  

I'd appreciate it if someone could test the Nightly so I could know if I could 
mark this as FIXED.

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

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

[billbarker]

billbarker2004/01/05 20:27:34

  Modified:catalina/src/share/org/apache/catalina/security
SecurityClassLoad.java
  Log:
  Adding classes for Coyote-Jk.
  
  This addresses Bug #25819.
  
  Reported By: Dario Bonino [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.12  +13 -4 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityClassLoad.java
  
  Index: SecurityClassLoad.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityClassLoad.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- SecurityClassLoad.java31 Oct 2003 01:30:01 -  1.11
  +++ SecurityClassLoad.java6 Jan 2004 04:27:34 -   1.12
  @@ -90,6 +90,7 @@
   loadJavaxPackage(loader);
   loadCoyotePackage(loader);
   loadHttp11Package(loader);
  +loadJkPackage(loader);
   }
   
   
  @@ -239,6 +240,14 @@
   loader.loadClass
   (basePackage +
"CoyoteResponse$3");
  +}
  +
  +private final static void loadJkPackage(ClassLoader loader)
  +throws Exception {
  +String basePackage = "org.apache.tomcat.util.";
  +loader.loadClass
  +(basePackage +
  + "buff.C2BConverter");
   }
   
   }
  
  
  

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

cvs commit: jakarta-tomcat-4.0/tester/src/tester/org/apache/tester ErrorPage04.java

[larryi]

larryi  2004/01/05 18:21:29

  Modified:tester/src/tester/org/apache/tester ErrorPage04.java
  Log:
  Port some changes to tester from Tomcat 5. These changes currently leave
  just two failures.
  
  1. The access to "/examples/.." fails the first time tester is run since starting
  Tomcat by returning 200.  Subsequent runs of tester return the expected
  302.
  
  2. For the JspDoc1.jsp test, Jasper condenses "" to  within
   tags, instead of preserving whitespace.  Don't know how easy
  it would be to port changes from Jasper HEAD.  This commit includes
  updating the JspDoc1.txt golden file to that found in the Tomcat 5 tester.
  I believe this should be the expected result for JSP 1.2 too.
  
  Revision  ChangesPath
  1.4   +7 -18 
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/ErrorPage04.java
  
  Index: ErrorPage04.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/ErrorPage04.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ErrorPage04.java  26 Apr 2001 16:39:13 -  1.3
  +++ ErrorPage04.java  6 Jan 2004 02:21:29 -   1.4
  @@ -82,33 +82,22 @@
   
   // Accumulate all the reasons this request might fail
   ServletException exception = null;
  -Throwable rootCause = null;
   StringBuffer sb = new StringBuffer();
   Object value = null;
   
   value = request.getAttribute("javax.servlet.error.exception");
   if (value == null)
   sb.append(" exception is missing/");
  -else if (!(value instanceof javax.servlet.ServletException)) {
  +else if (!(value instanceof org.apache.tester.TesterException)) {
   sb.append(" exception class is ");
   sb.append(value.getClass().getName());
   sb.append("/");
   } else {
  -exception = (ServletException) value;
  -rootCause = exception.getRootCause();
  -if (rootCause == null) {
  -sb.append(" rootCause is missing/");
  -} else if (!(rootCause instanceof TesterException)) {
  -sb.append(" rootCause is ");
  -sb.append(rootCause.getClass().getName());
  +TesterException te = (TesterException) value;
  +if (!"ErrorPage03 Threw Exception".equals(te.getMessage())) {
  +sb.append(" exception message is ");
  +sb.append(te.getMessage());
   sb.append("/");
  -} else {
  -TesterException te = (TesterException) rootCause;
  -if (!"ErrorPage03 Threw Exception".equals(te.getMessage())) {
  -sb.append(" exception message is ");
  -sb.append(te.getMessage());
  -sb.append("/");
  -}
   }
   }
   
  @@ -121,7 +110,7 @@
   sb.append("/");
   } else {
   Class clazz = (Class) value;
  -if (!"javax.servlet.ServletException".equals(clazz.getName())) {
  +if (!"org.apache.tester.TesterException".equals(clazz.getName())) {
   sb.append(" exception_type class is ");
   sb.append(clazz.getName());
   sb.append("/");
  
  
  

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

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteAdapter.java CoyoteRequest.java

[larryi]

larryi  2004/01/05 18:06:26

  Modified:coyote/src/java/org/apache/coyote/tomcat4 CoyoteAdapter.java
CoyoteRequest.java
  Log:
  Port convertURI() method so URIEncoding setting has the desired effect.
  
  Revision  ChangesPath
  1.25  +62 -6 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java
  
  Index: CoyoteAdapter.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- CoyoteAdapter.java11 Dec 2003 21:35:24 -  1.24
  +++ CoyoteAdapter.java6 Jan 2004 02:06:26 -   1.25
  @@ -68,6 +68,7 @@
   import javax.servlet.http.Cookie;
   import javax.servlet.http.HttpServletRequest;
   
  +import org.apache.tomcat.util.buf.B2CConverter;
   import org.apache.tomcat.util.buf.ByteChunk;
   import org.apache.tomcat.util.buf.CharChunk;
   import org.apache.tomcat.util.buf.MessageBytes;
  @@ -220,7 +221,7 @@
*/
   protected void postParseRequest(Request req, CoyoteRequest request,
   Response res, CoyoteResponse response)
  -throws IOException {
  +throws Exception {
   // XXX the processor needs to set a correct scheme and port prior to this 
point, 
   // in ajp13 protocols dont make sense to get the port from the connector..
   // XXX the processor may have set a correct scheme and port prior to this 
point, 
  @@ -268,7 +269,6 @@
   res.setMessage("Invalid URI");
   throw ioe;
   }
  -req.decodedURI().setEncoding("UTF-8");
   
   // Normalize decoded URI
   if (!normalize(req.decodedURI())) {
  @@ -277,6 +277,9 @@
   throw new IOException("Invalid URI");
   }
   
  +// URI character decoding
  +convertURI(req.decodedURI(), request);
  +
   // Parse session Id
   parseSessionId(req, request);
   
  @@ -293,6 +296,7 @@
   // Redoing the URI decoding
   req.decodedURI().duplicate(req.requestURI());
   req.getURLDecoder().convert(req.decodedURI(), true);
  +convertURI(req.decodedURI(), request);
   }
   }
   
  @@ -512,6 +516,58 @@
   
   // Return the normalized path that we have completed
   return (normalized);
  +
  +}
  +
  +
  +/**
  + * Character conversion of the URI.
  + */
  +protected void convertURI(MessageBytes uri, CoyoteRequest request) 
  +throws Exception {
  +
  +ByteChunk bc = uri.getByteChunk();
  +CharChunk cc = uri.getCharChunk();
  +cc.allocate(bc.getLength(), -1);
  +
  +String enc = connector.getURIEncoding();
  +if (enc != null) {
  +B2CConverter conv = request.getURIConverter();
  +try {
  +if (conv == null) {
  +conv = new B2CConverter(enc);
  +request.setURIConverter(conv);
  +} else {
  +conv.recycle();
  +}
  +} catch (IOException e) {
  +// Ignore
  +log("Invalid URI encoding; using HTTP default", e);
  +connector.setURIEncoding(null);
  +}
  +if (conv != null) {
  +try {
  +conv.convert(bc, cc);
  +uri.setChars(cc.getBuffer(), cc.getStart(), 
  + cc.getLength());
  +return;
  +} catch (IOException e) {
  +if (debug >= 1) {
  +log("Invalid URI character encoding; trying ascii", e);
  +}
  +cc.recycle();
  +}
  +}
  +}
  +
  +// Default encoding: fast conversion
  +byte[] bbuf = bc.getBuffer();
  +char[] cbuf = cc.getBuffer();
  +int start = bc.getStart();
  +for (int i = 0; i < bc.getLength(); i++) {
  +cbuf[i] = (char) (bbuf[i + start] & 0xff);
  +}
  +uri.setChars(cbuf, 0, bc.getLength());
   
   }
   
  
  
  
  1.36  +27 -4 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteRequest.java
  
  Index: CoyoteRequest.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteRequest.java,v
  retrieving revision 1.35
  retrieving revision 1.36
  diff -u -r1.35 -r1.36
  --- CoyoteRequest.java12 Dec 2003 02:44:34 -  1.35
  +++ CoyoteRequest.java6 Jan 2004 02:06:26 -   1.36
  @@ -110,6 +110,7 @@
   import org.apache.cat

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

[mmanders]

mmanders2004/01/05 14:42:03

  Modified:jk/native/common jk_ajp_common.c
  Log:
  Updated to build properly for NetWare with recent socket additions.
  
  Revision  ChangesPath
  1.43  +4 -1  jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
  
  Index: jk_ajp_common.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
  retrieving revision 1.42
  retrieving revision 1.43
  diff -u -r1.42 -r1.43
  --- jk_ajp_common.c   5 Nov 2003 09:15:39 -   1.42
  +++ jk_ajp_common.c   5 Jan 2004 22:42:03 -   1.43
  @@ -72,6 +72,9 @@
   #ifdef AS400
   #include "util_ebcdic.h"
   #endif
  +#if defined(NETWARE) && defined(__NOVELL_LIBC__)
  +#include "novsock2.h"
  +#endif
   
   
   const char *response_trans_headers[] = {
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native/common jk_global.h

[mmanders]

mmanders2004/01/05 14:41:53

  Modified:jk/native/common jk_global.h
  Log:
  Updated to build properly for NetWare with recent socket additions.
  
  Revision  ChangesPath
  1.26  +7 -2  jakarta-tomcat-connectors/jk/native/common/jk_global.h
  
  Index: jk_global.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_global.h,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- jk_global.h   5 Nov 2003 09:15:39 -   1.25
  +++ jk_global.h   5 Jan 2004 22:41:53 -   1.26
  @@ -90,8 +90,13 @@
   #include 
   #else
   #include 
  +#if defined(NETWARE) && defined(__NOVELL_LIBC__)
  +#include "novsock2.h"
  +#define __sys_socket_h__
  +#define __netdb_h__
  +#define __netinet_in_h__
  +#endif
   #include 
  -
   #include 
   #include 
   #ifndef NETWARE
  
  
  

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

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

[mmanders]

mmanders2004/01/05 14:37:48

  Modified:jk/native/common jk_connect.c
  Log:
  Added check for AF_INET (IPV4) type address from APR (when used).
  
  Revision  ChangesPath
  1.16  +14 -28jakarta-tomcat-connectors/jk/native/common/jk_connect.c
  
  Index: jk_connect.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- jk_connect.c  5 Nov 2003 09:15:39 -   1.15
  +++ jk_connect.c  5 Jan 2004 22:37:48 -   1.16
  @@ -66,35 +66,9 @@
*/
   
   
  -#if defined(NETWARE) && defined(__NOVELL_LIBC__)
  -/* Since we want to use WinSock functionality here, don't allow the 
  - * non-winsock headers 
  - */
  -#define __sys_types_h__
  -#define __sys_socket_h__
  -#define __netdb_h__
  -#define __netinet_in_h__
  -#define __arpa_inet_h__
  -#define __sys_timeval_h__
  -#endif
  -
   #include "jk_connect.h"
   #include "jk_util.h"
   
  -#if defined(NETWARE) && defined(__NOVELL_LIBC__)
  -/* Now remove the defines so that including the WinSock headers won't cause 
  - * complaining
  - */
  -#undef __sys_types_h__
  -#undef __sys_socket_h__
  -#undef __netdb_h__
  -#undef __netinet_in_h__
  -#undef __arpa_inet_h__
  -#undef __sys_timeval_h__
  -
  -#include 
  -#endif
  -
   #ifdef HAVE_APR
   #include "apr_network_io.h"
   #include "apr_errno.h"
  @@ -138,7 +112,7 @@
   
   #ifdef HAVE_APR
   apr_pool_t *context;
  -apr_sockaddr_t *remote_sa;
  +apr_sockaddr_t *remote_sa, *temp_sa;
   char *remote_ipaddr;
   
   /* May be we could avoid to recreate it each time ? */
  @@ -147,6 +121,18 @@
   
   if (apr_sockaddr_info_get(&remote_sa, host, APR_UNSPEC, (apr_port_t)port, 
0, context)
   != APR_SUCCESS) 
  +return JK_FALSE;
  +
  +/* Since we are only handling AF_INET (IPV4) address (in_addr_t) */
  +/* make sure we find one of those.   */
  +temp_sa = remote_sa;
  +while ((NULL != temp_sa) && (AF_INET != temp_sa->family))
  +temp_sa = temp_sa->next;
  +
  +/* if temp_sa is set, we have a valid address otherwise, just return */
  +if (NULL != temp_sa)
  +remote_sa = temp_sa;
  +else
   return JK_FALSE;
   
   apr_sockaddr_ip_get(&remote_ipaddr, remote_sa);
  
  
  

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

DO NOT REPLY [Bug 25908] - JCA Support would be very useful

[bugzilla]

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

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

JCA Support would be very useful





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 22:37 ---
To clarify my previous comment, this seems like a good open-source project to be
developed on top of, but separate from, the rest of Tomcat.

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

DO NOT REPLY [Bug 25908] - JCA Support would be very useful

[bugzilla]

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

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

JCA Support would be very useful





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 22:36 ---
This would seem like a good pluggable Tomcat module project...

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

DO NOT REPLY [Bug 25908] - JCA Support would be very useful

[bugzilla]

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

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

JCA Support would be very useful

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 21:31 ---
Sorry, for the time being, Tomcat will only add support for web tier related JSRs.
You can maybe integrate the provider you need using JNDI.

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

DO NOT REPLY [Bug 25838] - tomcat-jk.jar is missing all ajp classess

[bugzilla]

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

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

tomcat-jk.jar is missing all ajp classess

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 21:28 ---
The classes have been moved to the org.apache.jk.config package, and are now
bundled, thanks to Bill.

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

DO NOT REPLY [Bug 18273] - Need complete environment in CGI

[bugzilla]

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

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

Need complete environment in CGI





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 21:06 ---
There are three approaches to take:
1) pass on no environment variables (current behavior);
2) pass on a safe, simple set of environment variables a la "cron" or "smrsh";
3) pass on the env variables in an aribitrary (system- and jvm-specific way).

FWIW, the CGI "spec" at http://cgi-spec.golux.com/cgi-120-00a.html does not
specify that the environment variables used to invoke the CGI "container" MUST
or even SHOULD be passed on to the CGI script.  Hence the current behavior.

However, I agree that in many circumstances behavior #3 can be useful.  The
proposed patch is workable but results in one additional process invocation per
CGI invokation.  I believe a optimistic, caching approach would be more
preferable.  Can you suggest the behavior / implementation of such an approach?
  The cache settings/behavior should be simple & predictable (cached once per
CGIServlet static initialization?).  I would be happy to support an
implementation along those lines.

If there are any other developers with an opinion as to how this sort of thing
should be handled in Tomcat, please weigh in (I am just the CGI servlet developer).

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

Re: [PATCH] Bugzilla Bug #19998 fix to CGIServlet handling of PATH_INFO

[Martin Dengler]

On Mon, 2004-01-05 at 20:25, Martin Dengler wrote:
> Hello
> 
> This one-line patch fixes Bugzilla bug # 19998.  The patch was suggested
> by Jim Clark (in the bug report) and Doug Sauder (most recently).

[snip]

On Mon, 2004-01-05 at 20:40, [EMAIL PROTECTED] wrote: 
> yoavs   2004/01/05 12:40:22
> 
>   Modified:catalina/src/share/org/apache/catalina/servlets
> CGIServlet.java
>   Log:
>   Changed StringTokenizer creation to fix bug 19998.
>   

[snip]

Thank you.

Martin


signature.asc
Description: This is a digitally signed message part

RE: [PATCH] Bugzilla Bug #19998 fix to CGIServlet handling of PATH_INFO

[Shapira, Yoav]

Howdy,
OK, patch applied, bug marked as fixed.  I made sure it still builds,
but didn't test CGI servlet beyond that.

Yoav Shapira
Millennium ChemInformatics


>-Original Message-
>From: Martin Dengler [mailto:[EMAIL PROTECTED]
>Sent: Monday, January 05, 2004 3:25 PM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: [PATCH] Bugzilla Bug #19998 fix to CGIServlet handling of
>PATH_INFO
>
>Hello
>
>This one-line patch fixes Bugzilla bug # 19998.  The patch was
suggested
>by Jim Clark (in the bug report) and Doug Sauder (most recently).
>
>I am the original author of CGIServlet
>(jakarta-tomcat-
>catalina/catalina/src/share/org/apache/catalina/servlets/CGIServlet.jav
a)
>and support the application of this patch.
>
>Martin
>
>---
>Index: catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
>===
>RCS file:
>/home/cvspublic/jakarta-tomcat-
>catalina/catalina/src/share/org/apache/catalina/servlets/CGIServlet.jav
a,v
>retrieving revision 1.10
>diff -u -r1.10 CGIServlet.java
>--- catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
>13 Dec 2003 22:49:30 -  1.10
>+++ catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
>5 Jan 2004 20:23:39 -
>@@ -898,7 +898,7 @@
>
> File currentLocation = new File(webAppRootDir);
> StringTokenizer dirWalker =
>-new StringTokenizer(pathInfo, File.separator);
>+new StringTokenizer(pathInfo, "/");
> if (debug >= 3) {
> log("findCGI: currentLoc=" + currentLocation);
> }




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 19998] - CGIServlet doesn't resolve PATH_INFO correctly

[bugzilla]

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

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

CGIServlet doesn't resolve PATH_INFO correctly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 20:41 ---
Applied patch as suggested by Martin Dengler below:
Hello

This one-line patch fixes Bugzilla bug # 19998.  The patch was suggested
by Jim Clark (in the bug report) and Doug Sauder (most recently).

I am the original author of CGIServlet
(jakarta-tomcat-
catalina/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java) and 
support the application of this patch.

Martin

---
Index: catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-
catalina/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
retrieving revision 1.10
diff -u -r1.10 CGIServlet.java
--- catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
13 Dec 2003 22:49:30 -  1.10
+++ catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
5 Jan 2004 20:23:39 -
@@ -898,7 +898,7 @@
  
 File currentLocation = new File(webAppRootDir);
 StringTokenizer dirWalker =
-new StringTokenizer(pathInfo, File.separator);
+new StringTokenizer(pathInfo, "/");
 if (debug >= 3) {
 log("findCGI: currentLoc=" + currentLocation);
 }

-
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

[yoavs]

yoavs   2004/01/05 12:40:22

  Modified:catalina/src/share/org/apache/catalina/servlets
CGIServlet.java
  Log:
  Changed StringTokenizer creation to fix bug 19998.
  
  Revision  ChangesPath
  1.11  +8 -8  
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.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- CGIServlet.java   13 Dec 2003 22:49:30 -  1.10
  +++ CGIServlet.java   5 Jan 2004 20:40:22 -   1.11
  @@ -898,7 +898,7 @@
   
   File currentLocation = new File(webAppRootDir);
   StringTokenizer dirWalker =
  -new StringTokenizer(pathInfo, File.separator);
  +new StringTokenizer(pathInfo, "/");
   if (debug >= 3) {
   log("findCGI: currentLoc=" + currentLocation);
   }
  
  
  

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

DO NOT REPLY [Bug 25787] - adding <%@ attribute name="xxx" fragment="true" %> won't be declared

[bugzilla]

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

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

adding <%@ attribute name="xxx" fragment="true" %> won't be declared





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 20:30 ---
Really, Remy.  :-)

TC5 uses the same mechanism for tracking depdendencies on (statically) included
files, tag files, and tld's.  It would be very inconvenient during development
to have to redeploy the webapp every time an included file or a tagfile is
modified.

The dependencies are considered only when a JSP page is referenced and we are
deciding whether the page needs to be recompiled, so when development is false,
they are totally out of the picture.  At least I hope they are.  ;)

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

[PATCH] Bugzilla Bug #19998 fix to CGIServlet handling of PATH_INFO

[Martin Dengler]

Hello

This one-line patch fixes Bugzilla bug # 19998.  The patch was suggested
by Jim Clark (in the bug report) and Doug Sauder (most recently).

I am the original author of CGIServlet
(jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java)
 and support the application of this patch.

Martin

---
Index: catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
retrieving revision 1.10
diff -u -r1.10 CGIServlet.java
--- catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
13 Dec 2003 22:49:30 -  1.10
+++ catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
5 Jan 2004 20:23:39 -
@@ -898,7 +898,7 @@
  
 File currentLocation = new File(webAppRootDir);
 StringTokenizer dirWalker =
-new StringTokenizer(pathInfo, File.separator);
+new StringTokenizer(pathInfo, "/");
 if (debug >= 3) {
 log("findCGI: currentLoc=" + currentLocation);
 }



signature.asc
Description: This is a digitally signed message part

DO NOT REPLY [Bug 19998] - CGIServlet doesn't resolve PATH_INFO correctly

[bugzilla]

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

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

CGIServlet doesn't resolve PATH_INFO correctly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 20:21 ---
As the original developer, I will submit a patch based on this recommendation.

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

DO NOT REPLY [Bug 25841] - Tomcat/JK thread starvation

[bugzilla]

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

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

Tomcat/JK thread starvation

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 20:16 ---
There is a 1 <-> mapping between apache httpd processes and tomcat Processors.
Once an httpd process has had to forward a request to Tomcat the connection
it establishes to Tomcat is maintained until that httpd process dies, even
if that httpd process never has to forward another request to Tomcat.

So if apache is serving alot of normal http request which don't require Tomcat
you end up with a large number of idle connections to Tomcat which use Processors.

If you are running on unix and can use Apache 2 with the threaded worker MPM I
recommend upgrading to that.  This configuration makes much more efficient use
of the connections between Tomcat and apache because multiple request handling
threads in apache can share the same pool of connections to Tomcat.

The stack trace you show just indicates that most of your AJP Processors are
idle.

This is not a bug.

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

RE: [PATCH]Virtual Host Choice on HTML Manager

[Shapira, Yoav]

Howdy,
I too have a security problem with this patch as-is.  This is why we have extension in 
java and support for it in tomcat ;)

Yoav Shapira
Millennium ChemInformatics


>-Original Message-
>From: Remy Maucherat [mailto:[EMAIL PROTECTED]
>Sent: Monday, January 05, 2004 2:57 PM
>To: Tomcat Developers List
>Subject: Re: [PATCH]Virtual Host Choice on HTML Manager
>
>Glenn Nielsen wrote:
>> This breaks security for virtual hosting by allowing anyone who can
>> authenticate to use the manager to manage all virtual hosts.
>> Though this may be easier for you it prevents me from administering
>> a Tomcat server where multiple virtual hosta are managed by different
>> customers.
>>
>> Therfor I am -1 for applying this patch.
>>
>> An acceptable patch would be to extend the existing manager class with
>> a new class which implements this "feature".  Then those administering
>> Tomcat can choose which version of the manager they want to install.
>
>I agree with this.
>Is one manager per vhost really too much to ask ? (since different
>principals will be needed in many situations)
>
>There are a use cases for the feature, of course, so I'm ok with having
>an extension class that could replace the default manager servlet.
>
>Rémy
>
>
>
>-
>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: [PATCH]Virtual Host Choice on HTML Manager

[Remy Maucherat]

Glenn Nielsen wrote:
This breaks security for virtual hosting by allowing anyone who can
authenticate to use the manager to manage all virtual hosts.
Though this may be easier for you it prevents me from administering
a Tomcat server where multiple virtual hosta are managed by different
customers.
Therfor I am -1 for applying this patch.

An acceptable patch would be to extend the existing manager class with
a new class which implements this "feature".  Then those administering
Tomcat can choose which version of the manager they want to install.
I agree with this.
Is one manager per vhost really too much to ask ? (since different 
principals will be needed in many situations)

There are a use cases for the feature, of course, so I'm ok with having 
an extension class that could replace the default manager servlet.

Rémy



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

RE: [PATCH]Virtual Host Choice on HTML Manager

[Angus Mezick]

YAH!!!  I too greatly appreciate this patch!  I actually went the other
way and created one manager that shows ALL of the virtual hosts within a
tomcat.
--Angus

> -Original Message-
> From: George Sexton [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, January 04, 2004 12:00 PM
> To: 'Tomcat Developers List'
> Subject: RE: [PATCH]Virtual Host Choice on HTML Manager
> 
> 
> Cool. I hope it is accepted. I run a lot of virtual hosts and it would
> be nice to have this.
> 
> -Original Message-
> From: TANAKA Yoshihiro [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, January 04, 2004 9:11 AM
> To: [EMAIL PROTECTED]
> Subject: [PATCH]Virtual Host Choice on HTML Manager
> 
> 
> Hi, Happy New Year!
> I wrote patches that allow to choose any virtual host of Tomcat
> when you operate HTML Manager, Manager Servlet, and Deployer.
> I put patches and screen shots on:
> http://www.ytp.ne.jp/tech/tomcat/manager/index.html
> 
> I hope committers would try and apply the patches. It's my pleasure
> to debug, if any.
> 
> Regards.
> 

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

DO NOT REPLY [Bug 25787] - adding <%@ attribute name="xxx" fragment="true" %> won't be declared

[bugzilla]

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

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

adding <%@ attribute name="xxx" fragment="true" %> won't be declared





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 19:51 ---
Really ?
Since the tag is a webapp wide resource, I would have thought a restart of the
webapp would be needed (and desired for performance reasons).
If I put "development" to "false", are those checks still made ? Hopefully not
;-) (of course, it's still much better to precompile)

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

Re: [PATCH]Virtual Host Choice on HTML Manager

[Glenn Nielsen]

On Mon, Jan 05, 2004 at 01:11:12AM +0900, TANAKA Yoshihiro wrote:
> Hi, Happy New Year!
> I wrote patches that allow to choose any virtual host of Tomcat
> when you operate HTML Manager, Manager Servlet, and Deployer.
> I put patches and screen shots on:
> http://www.ytp.ne.jp/tech/tomcat/manager/index.html
> 
> I hope committers would try and apply the patches. It's my pleasure
> to debug, if any.

This breaks security for virtual hosting by allowing anyone who can
authenticate to use the manager to manage all virtual hosts.
Though this may be easier for you it prevents me from administering
a Tomcat server where multiple virtual hosta are managed by different
customers.

Therfor I am -1 for applying this patch.

An acceptable patch would be to extend the existing manager class with
a new class which implements this "feature".  Then those administering
Tomcat can choose which version of the manager they want to install.

Regards,

Glenn

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

DO NOT REPLY [Bug 25787] - adding <%@ attribute name="xxx" fragment="true" %> won't be declared

[bugzilla]

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

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

adding <%@ attribute name="xxx" fragment="true" %> won't be declared





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 19:45 ---
This actually works for me.

In Tomcat 5, any changes in a tagfile will trigger a recompilation of all the
.jsp pages that reference it, as well as the tagfile itself, so I don't see why
you need to restart TC.  Please include a test case if you still have problems.

Note also that the addition of <%@ attribute name="xxx" fragment="true" %> to
the tag file will not have any effect on the generated .class file, unless the
fragment is also used in the tagfile, with an . 
This is just an optimization.

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

Re: Bug 23929: ServletRequest.setCharacterEncoding()

[Remy Maucherat]

Jess Holle wrote:
Remy Maucherat wrote:

This is a good question -- but one which only applies to POST.  My bug 
case was explictly with GET.

If there is an entity body encoding specified in the request, then I am 
not sure which should override.  If there is not, then I would presume 
setCharacterEncoding() should win out.  If the only issue is when these 
differ, then I believe that site designers should simply ensure they don't.
I think you should read the HTTP RFC. content-type does not apply to the 
URI or the HTTP header. The fact that setCharacterEncoding would apply 
to (part of) the URI and/or the header violates the RFC on URIs.

Anyway, to put it simply: in the next release, add 
useBodyEncodingForURI="true" on the connector, and you're done.
Please don't complain that it won't do what you want before trying it.
You can also use the URIEncoding attribute to specify the path encoding.

Rémy



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

Re: Bug 23929: ServletRequest.setCharacterEncoding()

[Jess Holle]

Remy Maucherat wrote:

Jess Holle wrote:

Remy Maucherat wrote:

For example:
remm2003/12/10 14:26:28
  Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteConnector.java CoyoteRequest.java
mbeans-descriptors.xml
  Log:
  - Add a flag to allow using the encoding specified in the 
contentType for
the URI paramters. This is disabled by default, not compliant 
with the standards,
but present for compatibility.
But as per my previous message I /cannot /change this on a connector 
basis.  I /must /make this determination on a per-request basis -- 
/and the servlet spec specifically allows me to do this via the 
setCharacterEncoding() API as I read it/.
The content-type header and your setCharacterEncoding call both 
control the request entity body character encoding. So if using the 
entity body encoding *also* for URI parameters, what would you think 
it would do ?
This is a good question -- but one which only applies to POST.  My bug 
case was explictly with GET.

If there is an entity body encoding specified in the request, then I am 
not sure which should override.  If there is not, then I would presume 
setCharacterEncoding() should win out.  If the only issue is when these 
differ, then I believe that site designers should simply ensure they don't.

There's a query page in BZ, also, and as I said, many threads on 
tomcat-dev (use the archives).
I queried both at some length -- especially BZ.  I'll query the 
tomcat-dev archives further, but again a simple synopsis of how 
Tomcat's behavior satisfies the spec and is thus not a bug attached 
to the bug would save everyone a lot of trouble in cases like this.  
In other words, where a bug that from all indications appears to be a 
spec violation is closed as "INVALID" an explanation attached to the 
bug itself would be a *very* good idea.
Sorry, I'm not a broken record, and I will not go on repeating the 
same stuff over and over 20 times.
Just once on the one of the bug reports in the duplicate chain would 
suffice.  [At least in my handling of our internal bug system it is 
common place to copy/paste the final status from e-mail threads and/or 
lists into the bugs attachments when closing the bug.]

--
Jess Holle


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

Re: Bug 23929: ServletRequest.setCharacterEncoding()

[Remy Maucherat]

Jess Holle wrote:
Remy Maucherat wrote:
For example:
remm2003/12/10 14:26:28
  Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteConnector.java CoyoteRequest.java
mbeans-descriptors.xml
  Log:
  - Add a flag to allow using the encoding specified in the 
contentType for
the URI paramters. This is disabled by default, not compliant with 
the standards,
but present for compatibility.
But as per my previous message I /cannot /change this on a connector 
basis.  I /must /make this determination on a per-request basis -- /and 
the servlet spec specifically allows me to do this via the 
setCharacterEncoding() API as I read it/.
The content-type header and your setCharacterEncoding call both control 
the request entity body character encoding. So if using the entity body 
encoding *also* for URI parameters, what would you think it would do ?

There's a query page in BZ, also, and as I said, many threads on 
tomcat-dev (use the archives).
I queried both at some length -- especially BZ.  I'll query the 
tomcat-dev archives further, but again a simple synopsis of how Tomcat's 
behavior satisfies the spec and is thus not a bug attached to the bug 
would save everyone a lot of trouble in cases like this.  In other 
words, where a bug that from all indications appears to be a spec 
violation is closed as "INVALID" an explanation attached to the bug 
itself would be a *very* good idea.
Sorry, I'm not a broken record, and I will not go on repeating the same 
stuff over and over 20 times.

Rémy

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

DO NOT REPLY [Bug 25908] New: - JCA Support would be very useful

[bugzilla]

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

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

JCA Support would be very useful

   Summary: JCA Support would be very useful
   Product: Tomcat 5
   Version: Unknown
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


JCA support would be very useful to users that want to use JDO with Tomcat. 
Many JDO implementations come with a resource adaptor. Currently developers 
have to go to a full J2EE implementation like JBoss or worse WebSphere to be 
able to use the adaptor.

The Tomcat community already recognizes that relational database connection 
pooling is very useful by providing JDBC connection pooling. More and more 
applications will be developed using JDO that don't need a full blown J2EE 
stack (part of the reason we are using JDO is to avoid CMP with all of the 
baggage we don't need), just a bit of JCA support. Container managed 
transactions wouldn't need to be implemented, developers just need a way to get 
ahold of a correctly configured PersistenceManager.

Since there are already resource adaptors to provided connectivity to JDBC 
datasources, adding JCA support could also create a unified way to get a 
connetion to any datasource in Tomcat.

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

Re: Bug 23929: ServletRequest.setCharacterEncoding()

[Jess Holle]

Remy Maucherat wrote:

Jess Holle wrote:

- There's big threads, commit messages (incl recent ones), and bugs 
on this issue. How about reading that before writing an email about 
how bad things are.


I did search the archives for such threads before even filing my 
duplicate bug, so apparently my searching is inept.  I'll look again, 
but pointers would be appreciated.


For example:
remm2003/12/10 14:26:28
  Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteConnector.java CoyoteRequest.java
mbeans-descriptors.xml
  Log:
  - Add a flag to allow using the encoding specified in the 
contentType for
the URI paramters. This is disabled by default, not compliant with 
the standards,
but present for compatibility.
But as per my previous message I /cannot /change this on a connector 
basis.  I /must /make this determination on a per-request basis -- /and 
the servlet spec specifically allows me to do this via the 
setCharacterEncoding() API as I read it/.

There's a query page in BZ, also, and as I said, many threads on 
tomcat-dev (use the archives).
I queried both at some length -- especially BZ.  I'll query the 
tomcat-dev archives further, but again a simple synopsis of how Tomcat's 
behavior satisfies the spec and is thus not a bug attached to the bug 
would save everyone a lot of trouble in cases like this.  In other 
words, where a bug that from all indications appears to be a spec 
violation is closed as "INVALID" an explanation attached to the bug 
itself would be a *very* good idea.

--
Jess Holle

Re: Bug 23929: ServletRequest.setCharacterEncoding()

[Remy Maucherat]

Jess Holle wrote:
- There's big threads, commit messages (incl recent ones), and bugs on 
this issue. How about reading that before writing an email about how 
bad things are.


I did search the archives for such threads before even filing my 
duplicate bug, so apparently my searching is inept.  I'll look again, 
but pointers would be appreciated.
For example:
remm2003/12/10 14:26:28
  Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteConnector.java CoyoteRequest.java
mbeans-descriptors.xml
  Log:
  - Add a flag to allow using the encoding specified in the contentType for
the URI paramters. This is disabled by default, not compliant with 
the standards,
but present for compatibility.

There's a query page in BZ, also, and as I said, many threads on 
tomcat-dev (use the archives).

Rémy



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

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

[remm]

remm2004/01/05 08:33:38

  Modified:catalina/src/share/org/apache/catalina/users
MemoryUserDatabase.java
  Log:
  - Revert patch.
  - Bug 25822 will not be addressed, since it cannot be resolved without adding
significant complexity.
  
  Revision  ChangesPath
  1.4   +0 -18 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/users/MemoryUserDatabase.java
  
  Index: MemoryUserDatabase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/users/MemoryUserDatabase.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- MemoryUserDatabase.java   5 Jan 2004 15:04:14 -   1.3
  +++ MemoryUserDatabase.java   5 Jan 2004 16:33:37 -   1.4
  @@ -138,12 +138,6 @@
   
   
   /**
  - * Was the database modified ?
  - */
  -private boolean modified = false;
  -
  -
  -/**
* The relative (to catalina.base) or absolute pathname to
* the XML file in which we will save our persistent information.
*/
  @@ -293,7 +287,6 @@
   synchronized (groups) {
   groups.put(group.getGroupname(), group);
   }
  -modified = true;
   return (group);
   
   }
  @@ -311,7 +304,6 @@
   synchronized (roles) {
   roles.put(role.getRolename(), role);
   }
  -modified = true;
   return (role);
   
   }
  @@ -331,7 +323,6 @@
   synchronized (users) {
   users.put(user.getUsername(), user);
   }
  -modified = true;
   return (user);
   
   }
  @@ -435,7 +426,6 @@
   
   }
   }
  -modified = false;
   
   }
   
  @@ -455,7 +445,6 @@
   }
   groups.remove(group.getGroupname());
   }
  -modified = true;
   
   }
   
  @@ -480,7 +469,6 @@
   }
   roles.remove(role.getRolename());
   }
  -modified = true;
   
   }
   
  @@ -495,7 +483,6 @@
   synchronized (users) {
   users.remove(user.getUsername());
   }
  -modified = true;
   
   }
   
  @@ -507,11 +494,6 @@
* @exception Exception if any exception is thrown during saving
*/
   public void save() throws Exception {
  -
  -if (!modified) {
  -return;
  -}
  -modified = false;
   
   // Write out contents to a temporary file
   File fileNew = new File(pathnameNew);
  
  
  

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

DO NOT REPLY [Bug 25822] - tomcat shouldn't write tomcat-users.xml at startup

[bugzilla]

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

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

tomcat shouldn't write tomcat-users.xml at startup





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 16:28 ---
If you only modify an existing user, the change isn't detected and won't be
saved unless you add/remove another user.

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

DO NOT REPLY [Bug 25822] - tomcat shouldn't write tomcat-users.xml at startup

[bugzilla]

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

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

tomcat shouldn't write tomcat-users.xml at startup





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 16:21 ---
Your first patch works fine (at least it does what I wanted): the users are no
longer saved on startup, while updates using the admin webapp cause the file to
be saved.

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

DO NOT REPLY [Bug 25822] - tomcat shouldn't write tomcat-users.xml at startup

[bugzilla]

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

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

tomcat shouldn't write tomcat-users.xml at startup





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 16:19 ---
My first patch doesn't work since it doesn't detect user modification.
My second remove the first patch and implements the following :
- use a temporary file for write instead of conf/tomcat-users.xml.new
- check wether conf/tomcat-users.xml is writable (if it exists)
- rename the temporary files to conf/tomcat-users.xml
It removes the need to write in the directory.

By the way the old code had a very little bug :

File fileOld = new File(pathnameNew);
if (!fileOld.isAbsolute()) {
fileOld =
new File(System.getProperty("catalina.base"), pathnameOld);
}

when I expected 

File fileOld = new File(pathnameOld);
if (!fileOld.isAbsolute()) {
fileOld =
new File(System.getProperty("catalina.base"), pathnameOld);
}

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

Re: Bug 23929: ServletRequest.setCharacterEncoding()

[Jess Holle]

Remy Maucherat wrote:

Jess Holle wrote:

Remmy, et al:

The API is *not* optional.  It is a required part of the servlet spec.
Great. I didn't know that ;-)

How about:
- Not CCing me. I'm subscribed to tomcat-dev already. thanks.
Sorry.

- There's big threads, commit messages (incl recent ones), and bugs on 
this issue. How about reading that before writing an email about how 
bad things are.
I did search the archives for such threads before even filing my 
duplicate bug, so apparently my searching is inept.  I'll look again, 
but pointers would be appreciated.

BTW, there's no bug.
It would be nice if the bug comments described why it is not a bug.  I 
understand Bugzilla is not a discussion forum, but it would really help 
future reporters of an issue not to resurrect old issues if the bug 
comments contained a final summary as to why the bug was closed as 
"INVALID".

Did I and the other reporter mis-use the API?  The API presumably must 
work, so how are we misuing it so that it does not?  If it does not 
work, then how does this meet the spec?

--
Jess Holle


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

DO NOT REPLY [Bug 25822] - tomcat shouldn't write tomcat-users.xml at startup

[bugzilla]

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

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

tomcat shouldn't write tomcat-users.xml at startup





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 16:08 ---
Sorry, but I'm not interested. Either something simple works (like your first
patch), or it doesn't. If it doesn't then since the "issue" is not significant,
then the patch will be reverted.

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

DO NOT REPLY [Bug 25822] - tomcat shouldn't write tomcat-users.xml at startup

[bugzilla]

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

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

tomcat shouldn't write tomcat-users.xml at startup





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 16:02 ---
My previous patch wasn't able to detect any user modification.
Since it seems to have been applied to cvs, here is a patch that remove it and
uses another method.
Like discussed before, it uses a temporary file to save the file before
overwriting the file in conf directory.
With this patch, write permission is only necessary for the file
tomcat-users.xml and not for the entire directory.

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

Re: Bug 23929: ServletRequest.setCharacterEncoding()

[Remy Maucherat]

Jess Holle wrote:

Remmy, et al:

The API is *not* optional.  It is a required part of the servlet spec.
Great. I didn't know that ;-)

How about:
- Not CCing me. I'm subscribed to tomcat-dev already. thanks.
- There's big threads, commit messages (incl recent ones), and bugs on 
this issue. How about reading that before writing an email about how bad 
things are.

BTW, there's no bug.

Rémy

It works just great in Tomcat 4.1 and is not an acceptable regression in 
Tomcat 5.  I am thus one step away from re-opening this bug 
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23929)

I cannot use the encoding setting on the connector as the standard 
handling of servlet parameters is ISO-8859-1 decoding unless 
setCharacterEncoding() is used to specify something else.  All of our 
other code thus follows this standard carefully (and works across all 
servlet engines tested).  [This includes handling multi-byte data in 
servlet parameters.]  This does require some careful shuffling to 
workaround the fact that the wrong encoding was used by the servlet 
engine and to use the correct one (UTF-8 in most, but not all, cases).

We do, however, have some code which leverages this new API to 
setCharacterEncoding("UTF-8") -- which is, in fact, very nice to have.  
I can see that it can be obnoxious for implementation -- but users of 
the API do not and should not care.

Tomcat 5 has a lot of promising things over Tomcat 4.1 -- don't let spec 
non-compliance force those who are forced to care about rigorous i18n to 
tell our customers to use Tomcat 4.1 or pay for a commercial servlet 
engine if they want later spec compliance.

--
Jess Holle


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

DO NOT REPLY [Bug 25903] New: - taglib error with setter not found is too poor

[bugzilla]

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

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

taglib error with setter not found is too poor

   Summary: taglib error with setter not found is too poor
   Product: Tomcat 4
   Version: 4.1.24
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Here´s a patch to solve it.

  Regards,
  Edson

--- Generator.java  2004-01-05 13:29:33.543612800 -0300
+++ blah.java   2004-01-05 13:26:00.36708 -0300
@@ -1747,11 +1747,20 @@
if (attrValue == null) {
continue;
}
+
+   StringBuffer sbMsg = null;
String attrName = attrs[i].getName();
Method m = handlerInfo.getSetterMethod(attrName);
if (m == null) {
-   err.jspError(n, "jsp.error.unable.to_find_method",
-attrName);
+   sbMsg = new StringBuffer( );
+   sbMsg.append( "jsp.error in [ " );
+   sbMsg.append( handlerInfo.getTagHandlerClass( ).
getName( ));
+   sbMsg.append( " ], unable.to_find_method " );
+
+   err.jspError(
+   n,
+   sbMsg.toString( ),
+   attrName);
}

Class c[] = m.getParameterTypes();

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

DO NOT REPLY [Bug 25822] - tomcat shouldn't write tomcat-users.xml at startup

[bugzilla]

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

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

tomcat shouldn't write tomcat-users.xml at startup

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 15:59 ---
-1 for your revised patch, sorry. Please do not reopen the bug.
If you do not agree, write your own custom realm, or use the older memory realm.

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

DO NOT REPLY [Bug 25822] - tomcat shouldn't write tomcat-users.xml at startup

[bugzilla]

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

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

tomcat shouldn't write tomcat-users.xml at startup





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 15:56 ---
Created an attachment (id=9814)
replacement for previous buggy patch

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

Bug 23929: ServletRequest.setCharacterEncoding()

[Jess Holle]

Remmy, et al:

The API is *not* optional.  It is a required part of the servlet spec.

It works just great in Tomcat 4.1 and is not an acceptable regression in 
Tomcat 5.  I am thus one step away from re-opening this bug 
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23929)

I cannot use the encoding setting on the connector as the standard 
handling of servlet parameters is ISO-8859-1 decoding unless 
setCharacterEncoding() is used to specify something else.  All of our 
other code thus follows this standard carefully (and works across all 
servlet engines tested).  [This includes handling multi-byte data in 
servlet parameters.]  This does require some careful shuffling to 
workaround the fact that the wrong encoding was used by the servlet 
engine and to use the correct one (UTF-8 in most, but not all, cases).

We do, however, have some code which leverages this new API to 
setCharacterEncoding("UTF-8") -- which is, in fact, very nice to have.  
I can see that it can be obnoxious for implementation -- but users of 
the API do not and should not care.

Tomcat 5 has a lot of promising things over Tomcat 4.1 -- don't let spec 
non-compliance force those who are forced to care about rigorous i18n to 
tell our customers to use Tomcat 4.1 or pay for a commercial servlet 
engine if they want later spec compliance.

--
Jess Holle


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

Exception in RealmBase

[Mark Woon]

Hi all,

I have a custom Realm implementation that extends
org.apache.catalina.realm.RealmBase.  It used to work in 4.x, but in
5.0.16, I'm getting the following exception on startup:
21:17:29,719 ERROR RealmBase:1092 - Can't register null
java.lang.NullPointerException
  at org.apache.catalina.realm.RealmBase.init(RealmBase.java:1088)
  at org.apache.catalina.realm.RealmBase.start(RealmBase.java:769)
  at
org.pharmgen.webapp.tomcat.PharmGenRealmAdapter.setRealm(PharmGenRealmAdapter.java:34) 

  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 

  at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 

  at java.lang.reflect.Method.invoke(Method.java:324)
  at
org.securityfilter.config.SecurityConfig.addRealm(SecurityConfig.java:216)
[snip]
I've taken a look at the source, and as far as I can tell, it's because
the container is null.  What is responsible for providing the Realm the
container it's in?  Is there some new bit of configuration I need to do
in Tomcat 5?  I'm also surprised that there's this bit of code in
RealmBase.init():
if( container== null ) {
// do some stuff, and don't set container or oname
}
if( oname==null ) {
try {
  ContainerBase cb=(ContainerBase)container;
  // >>> NPE HAPPENS HERE  <<<
  oname=new ObjectName(cb.getDomain()+":type=Realm" +
cb.getContainerSuffix());
  // some other stuff
} catch (Throwable e) {
  log.error( "Can't register " + oname, e);
}
}
I don't have any experience with JMX, so maybe it's doing something
behind the scenes, but if not, that bit of code looks wrong.  While this
seems to be an error that can be safely ignored if I'm not using JMX,
it's still a little distressing.
Any help would be appreciated.

Thanks,
-Mark

servlet

[anil]

Sir,
How to create my own directory to store the servlets using tomcat 4.1?




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

DO NOT REPLY [Bug 25819] - java.lang.NoClassDefFoundError: org/apache/tomcat/util/buf/C2BConverter

[bugzilla]

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

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

java.lang.NoClassDefFoundError: org/apache/tomcat/util/buf/C2BConverter





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 15:09 ---
A missing doPrivileged block is missing and the real exception is hidden for a
reason I can't explain (I don't know how jk works...I will take a look). Just
edit your catalina.properties and clean the following two properties:

package.access=
package.definition=

or just remove org.apache.tomcat. 

It should work.

-- Jeanfrancois

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

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

[remm]

remm2004/01/05 07:04:14

  Modified:catalina/src/share/org/apache/catalina/users
MemoryUserDatabase.java
  Log:
  - Bug 25822: Only save the user database if it's modified.
  - Submitted by Xavier Poinsard.
  
  Revision  ChangesPath
  1.3   +22 -4 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/users/MemoryUserDatabase.java
  
  Index: MemoryUserDatabase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/users/MemoryUserDatabase.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- MemoryUserDatabase.java   14 Aug 2002 19:36:17 -  1.2
  +++ MemoryUserDatabase.java   5 Jan 2004 15:04:14 -   1.3
  @@ -138,6 +138,12 @@
   
   
   /**
  + * Was the database modified ?
  + */
  +private boolean modified = false;
  +
  +
  +/**
* The relative (to catalina.base) or absolute pathname to
* the XML file in which we will save our persistent information.
*/
  @@ -287,6 +293,7 @@
   synchronized (groups) {
   groups.put(group.getGroupname(), group);
   }
  +modified = true;
   return (group);
   
   }
  @@ -304,6 +311,7 @@
   synchronized (roles) {
   roles.put(role.getRolename(), role);
   }
  +modified = true;
   return (role);
   
   }
  @@ -323,6 +331,7 @@
   synchronized (users) {
   users.put(user.getUsername(), user);
   }
  +modified = true;
   return (user);
   
   }
  @@ -426,6 +435,7 @@
   
   }
   }
  +modified = false;
   
   }
   
  @@ -445,6 +455,7 @@
   }
   groups.remove(group.getGroupname());
   }
  +modified = true;
   
   }
   
  @@ -469,6 +480,7 @@
   }
   roles.remove(role.getRolename());
   }
  +modified = true;
   
   }
   
  @@ -483,6 +495,7 @@
   synchronized (users) {
   users.remove(user.getUsername());
   }
  +modified = true;
   
   }
   
  @@ -494,6 +507,11 @@
* @exception Exception if any exception is thrown during saving
*/
   public void save() throws Exception {
  +
  +if (!modified) {
  +return;
  +}
  +modified = false;
   
   // Write out contents to a temporary file
   File fileNew = new File(pathnameNew);
  
  
  

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

DO NOT REPLY [Bug 25901] - Why the default character encoding is not a UTF-8?

[bugzilla]

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

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

Why the default character encoding is not a UTF-8?

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 14:34 ---
Please do not reopen this issue (or I'll close it again). As I said, if you want
to discuss this, there's tomcat-user (FYI, the default encoding is HTTP is
ISO-8859-1, not UTF-8; I suggest you read the RFC).

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

DO NOT REPLY [Bug 25901] - Why the default character encoding is not a UTF-8?

[bugzilla]

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

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

Why the default character encoding is not a UTF-8?

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 14:31 ---
To Remy:
Sorry, I can't agree with you. This is a really problem of the Tomcat. Just try 
to send in some HTML form field a string with two different languages. Any 
browser will solve this problem by using a UTF-8 encoding, but Tomcat will not 
understand this.
So the org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING should be a "UTF-
8" instead of "ISO-8859-1"

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

DO NOT REPLY [Bug 25901] - Why the default character encoding is not a UTF-8?

[bugzilla]

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

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

Why the default character encoding is not a UTF-8?

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 14:08 ---
I think you shouldn't waste your time with questions on BZ. Please post on
tomcat-user.

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

DO NOT REPLY [Bug 25901] New: - Why the default character encoding is not a UTF-8?

[bugzilla]

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

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

Why the default character encoding is not a UTF-8?

   Summary: Why the default character encoding is not a UTF-8?
   Product: Tomcat 5
   Version: 5.0.16
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Connector:Coyote
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have a problem: I want to allow for the users of my web site to use a locale 
login names. I use a form-based authentication, and I must send a 
j_security_check request. I can't define a character encoding in the client 
browser, but I can force it to use a UTF-8. And I can't change encoding on the 
server side before processing a j_security_check filter :-(

Thanks for comments

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

Re: Jk2 object model

[jean-frederic clere]

Costin Manolache wrote:
I remember some time ago Mladen (?) was suggesting to use C++ for jk2 
instead of the pseudo-OO programming.
I am -1 for using C++... And wondering why you want to use C++.

Did anything got discussed/decided 
about this or the low-level model ?

Costin

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



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

RE: HttpSession handling

[Shapira, Yoav]

Howdy,

>Reading the servlet spec raised a couple of thoughts about http session

The servlet spec v2.4, I hope?

>Should I write a patch for these?

Not yet.

>"SRV.7.6 Last Accessed Times
>The getLastAccessedTime method of the HttpSession interface allows a
>servlet
>to determine the last time the session was accessed before the current
>request. The session is considered to be accessed when a request that
is
>part
>of the session is first handled by the servlet container."

See the JavaDoc for this method in the 2.4 servlet spec: it's not the
same as what you quoted above.  It's much cleaner, and tomcat implements
it exactly and correctly.

>Thought #2
>
>If the session is created by the current request, the
>session.getLastAccessedTime() returns the session creation time. Should
it
>return 0 instead? I'd find it a bit less incorrect.

I consider creation as a special type of access, and therefore I think
tomcat's behavior is correct.  Does the spec say otherwise?  I also
don't care much for "a bit less incorrect" -- if the spec gives leeway
to the container implementation, we need to have a very good reason to
change current behavior (thereby affecting many users who may rely on
it).

>"SRV.7.5 Session Timeouts
>The session invalidation will not take effect until all servlets using
that
>session have exited the service method."
>
>Tomcat does nothing to ensure this.
>
>To reproduce, set session timeout to 3mins and put the following code
to
>service method:
>
>HttpSession session = request.getSession();
>Thread.sleep(200 * 1000L); // a long operation =)
>session.getLastAccessedTime();
>
>->IllegalStateException is thrown

That one is interesting.  Are you sure the session has been invalidated
by tomcat and there's no other code running in your webapp that may have
caused this?

Yoav Shapira



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 25896] - Windows installer (exe) create a directory with Space

[bugzilla]

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

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

Windows installer (exe) create a directory with Space

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 12:56 ---
Thanks 
marking invalid

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

DO NOT REPLY [Bug 25899] New: - Encoding bug in Jasper compiler when using <%@ include > directive

[bugzilla]

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

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

Encoding bug in Jasper compiler when using <%@ include > directive

   Summary: Encoding bug in Jasper compiler when using <%@ include >
directive
   Product: Tomcat 4
   Version: 4.1.29
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


There is a bug in Jasper compiler that incorrectly assigns ISO-8859-1 encoding 
for included file when including files using <%@ include file="..."> directive 
and the included file contains <%@ page > directive.

For example:

page1.jsp:
<%@ page contentType="text/html; charset=ISO-8859-2" %>

Test łćżĆŁŃ


<%@ include file="page2.jsp"%> 

page2.jsp:
<%@ page import="java.util.*" %>

Test łćżĆŁŃ



Jasper correctly recognizes encoding of file page1.jsp as ISO-8859-2. Since 
page2.jsp does not have its encoding set and it is included from page1.jsp, it 
should also have ISO-8859-2 encoding. Jasper incorrectly treats this file as 
having ISO-8859-1 encoding. 
The problem disappears when <%@ page import="java.util.*" %> directive is 
removed from page2.jsp.

Patch for this bug follows:
Index: ParserController.java
===
RCS file: /home/cvspublic/jakarta-tomcat-
jasper/jasper2/src/share/org/apache/jasper/compiler/ParserController.java,v
retrieving revision 1.4.2.1
diff -c -r1.4.2.1 ParserController.java
*** ParserController.java   18 Jul 2002 18:04:24 -  1.4.2.1
--- ParserController.java   5 Jan 2004 12:52:09 -
***
*** 260,270 
int loc = contentType.indexOf("charset=");
if (loc != -1) {
newEncoding = contentType.substring(loc+8);
-   return;
}
}
-   if (newEncoding == null)
-   newEncoding = "ISO-8859-1";
} else {
return;
}
--- 260,270 
int loc = contentType.indexOf("charset=");
if (loc != -1) {
newEncoding = contentType.substring(loc+8);
}
+   if (newEncoding == null)
+   newEncoding = "ISO-8859-1";
+   return;
}
} else {
return;
}

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

Fwd: an little mistake on site ?

[Pier Fumagalli]

Begin forwarded message:

From: "v.z." <[EMAIL PROTECTED]>
Date: 5 January 2004 11:19:40 GMT
To: [EMAIL PROTECTED]
Subject: an little mistake on site ?
Hi.
On download source-site  seems is present en little error.
I've tried to check archive  JK 2 Source Release .zip by pgp 
signature, your provided , and had mistake because the KEYS file don't 
contains appropriate public key.
I'am not very experienced Linux user, and could make mistake , but the 
same procedure with tomkat archive was ok.
Vadim.
 
 
 

Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25896] - Windows installer (exe) create a directory with Space

[bugzilla]

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

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

Windows installer (exe) create a directory with Space





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 12:17 ---
The Xerces doc says:

The syntax is the same as for schemaLocation attributes in instance documents: 
e.g, "http://www.example.com file_name.xsd". The user can specify more than one 
XML Schema in the list.   

and the schemaLocation takes a URI, not a file name.

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

DO NOT REPLY [Bug 25896] - Windows installer (exe) create a directory with Space

[bugzilla]

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

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

Windows installer (exe) create a directory with Space





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 10:42 ---
According to xerces in 
http://xml.apache.org/xerces2-j/properties.html
i can use
with http://apache.org/xml/properties/schema/external-schemaLocation
a String Example :

xmlReader.setProperty("http://apache.org/xml/properties/schema/external-schemaLocation";
,"http://schemas.xmlsoap.org/soap/envelope/ "+myschemalocation);

it is true that if i URLEncode the myschemalocaiton , the "problem"
will be solved , but the "myschemalocaiton" is a file on the server harddisk

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

DO NOT REPLY [Bug 25896] - Windows installer (exe) create a directory with Space

[bugzilla]

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

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

Windows installer (exe) create a directory with Space





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 10:34 ---
Why is that a problem? Schemas should be referenced using URLs, and URLs never 
contain spaces (replace by %20).

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

DO NOT REPLY [Bug 4663] - Broken Pipe under some load

[bugzilla]

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

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

Broken Pipe under some load

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |
Version|4.0.1 Final |4.1.29



--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 10:34 ---
Same behaviour of org.apache.jk.server.JkCoyoteHandler in TC 4.1.29 as 
reported in bug 4663 for 4.1.24. Is it planned this error to be repored under 
certain debug level, so actually we can just turn it off? The situations is 
rather common (user presses stop button after some heavy report was selected 
and has to wait) and the stack traces are undesirable in production 
environment. 

Jan 5, 2004 12:18:49 PM org.apache.jk.server.JkCoyoteHandler action
SEVERE: Error in action code
java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:457)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:654)
at org.apache.jk.server.JkCoyoteHandler.action
(JkCoyoteHandler.java:435)
at org.apache.coyote.Response.action(Response.java:222)
at org.apache.coyote.Response.finish(Response.java:343)
at org.apache.jk.server.JkCoyoteHandler.invoke
(JkCoyoteHandler.java:314)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:387)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:673)
at org.apache.jk.common.ChannelSocket.processConnection
(ChannelSocket.java:615)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:786)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:666)
at java.lang.Thread.run(Thread.java:536)

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

Re: Jk2 object model

[Henri Gomez]

Bill Barker a écrit :

- Original Message - 
From: "Costin Manolache" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, January 04, 2004 11:44 PM
Subject: Jk2 object model



I remember some time ago Mladen (?) was suggesting to use C++ for jk2
instead of the pseudo-OO programming. Did anything got discussed/decided
about this or the low-level model ?


The only suggestion I remember like this is mine to use Xerces-C (and it was
heavily rejected :).  I'm not really in favor of paying the cost for C++ in
the critical code when the current implementation works well.  About the
only thing it doesn't have is multiple inheritance (which, if it comes up,
I'd rather do a COM-style QueryInterface, since it won't come up much).
I'd like we don't start C++ in such area for many reasons, including the 
fact the Apache codebase is not C++ but just good old C.

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

DO NOT REPLY [Bug 25886] - Feature: PersistenceManager less restrictive at createSession with maxActiveSessions

[bugzilla]

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

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

Feature: PersistenceManager less restrictive at createSession with maxActiveSessions





--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 09:49 ---
Good desicion !

Now we can remove the rejectedSession Property also 

thanx
Peter

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

DO NOT REPLY [Bug 25896] New: - Windows installer (exe) create a directory with Space

[bugzilla]

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

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

Windows installer (exe) create a directory with Space

   Summary: Windows installer (exe) create a directory with Space
   Product: Tomcat 4
   Version: 4.1.29
  Platform: Other
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Installable Packages
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


the windows installer installs tomcat in 
"c:\program files\apache group\tomcat 4.1"
By itself its not a real problem, but when coming to use 
Xerces 2.6 and load xml schemas , it generate an error
as xerces uses SPACE as a separator
can this default install directory change ?
The Xerces Error is a bizzare one and tomcat4 users will
spend time tracing back that it is the space that creates the problem 
(file.xsd must have even number of URI's)

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

DO NOT REPLY [Bug 25886] - Feature: PersistenceManager less restrictive at createSession with maxActiveSessions

[bugzilla]

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

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

Feature: PersistenceManager less restrictive at createSession with maxActiveSessions

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 08:51 ---
Fixed. The check is gone, I don't see the point of enforcing the active session
value with a persistent manager.

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

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

[remm]

remm2004/01/05 00:50:00

  Modified:catalina/src/share/org/apache/catalina/session
PersistentManagerBase.java
  Log:
  - Bug 25886: Remove the check on the maximum amount of active sessions
during session creation. The whole point of the persistent manager is that
excess sessions will be swaped out.
  
  Revision  ChangesPath
  1.15  +4 -27 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java
  
  Index: PersistentManagerBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- PersistentManagerBase.java10 Dec 2003 23:00:36 -  1.14
  +++ PersistentManagerBase.java5 Jan 2004 08:50:00 -   1.15
  @@ -657,29 +657,6 @@
   
   
   /**
  - * Return a new session object as long as the number of active
  - * sessions does not exceed maxActiveSessions. If there
  - * aren't too many active sessions, or if there is no limit,
  - * a session is created or retrieved from the recycled pool.
  - *
  - * @exception IllegalStateException if a new session cannot be
  - *  instantiated for any reason
  - */
  -public Session createSession() {
  -
  -if ((maxActiveSessions >= 0) &&
  -(sessions.size() >= maxActiveSessions)) {
  -rejectedSessions++;
  -throw new IllegalStateException
  -(sm.getString("standardManager.createSession.ise"));
  -}
  -
  -return (super.createSession());
  -
  -}
  -
  -
  -/**
* Return the active Session, associated with this Manager, with the
* specified session id (if any); otherwise return null.
* This method checks the persistence store if persistence is enabled,
  
  
  

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

DO NOT REPLY [Bug 25885] - ApplicationParameter override test with wrong value at StandardContext

[bugzilla]

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

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

ApplicationParameter override  test with wrong value at StandardContext

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-01-05 08:46 ---
Fixed. Thanks.

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

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

[remm]

remm2004/01/05 00:46:20

  Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
  Log:
  - Bug 25885: Incorrect test.
  - Submitted by Peter Rossbach.
  
  Revision  ChangesPath
  1.104 +2 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.103
  retrieving revision 1.104
  diff -u -r1.103 -r1.104
  --- StandardContext.java  17 Dec 2003 22:39:27 -  1.103
  +++ StandardContext.java  5 Jan 2004 08:46:20 -   1.104
  @@ -1726,7 +1726,7 @@
   synchronized (applicationParameters) {
   String newName = parameter.getName();
   for (int i = 0; i < applicationParameters.length; i++) {
  -if (name.equals(applicationParameters[i].getName()) &&
  +if (newName.equals(applicationParameters[i].getName()) &&
   !applicationParameters[i].getOverride())
   return;
   }
  
  
  

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

Re: Jk2 object model

[Bill Barker]

- Original Message - 
From: "Costin Manolache" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, January 04, 2004 11:44 PM
Subject: Jk2 object model


> I remember some time ago Mladen (?) was suggesting to use C++ for jk2
> instead of the pseudo-OO programming. Did anything got discussed/decided
> about this or the low-level model ?
>

The only suggestion I remember like this is mine to use Xerces-C (and it was
heavily rejected :).  I'm not really in favor of paying the cost for C++ in
the critical code when the current implementation works well.  About the
only thing it doesn't have is multiple inheritance (which, if it comes up,
I'd rather do a COM-style QueryInterface, since it won't come up much).

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


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]

Jk2 object model

[Costin Manolache]

I remember some time ago Mladen (?) was suggesting to use C++ for jk2 
instead of the pseudo-OO programming. Did anything got discussed/decided 
about this or the low-level model ?

Costin

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

JK2 Won't create .so's for Tomcat 5/Apache 2.0.48

[James Myers]

Hello,

I have lost the remainder of what hair I had trying to get JK2 to create
mod_jk2.so and jkini.so.
Has anyone ever made this combination work?

I'm using configure like this:

./configure --with-tomcat41=/usr/local/tomcat5.0 \
--with-apache2=/usr/local/apache2 \
--with-apxs2=/usr/local/apache2/bin/apxs
Any help would be greatly appreciated.

Thanks



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