DO NOT REPLY [Bug 18650] - Exception while processing a JAR file

2003-11-04 Thread 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=18650

Exception while processing a JAR file





--- Additional Comments From [EMAIL PROTECTED]  2003-11-04 07:27 ---
This is not a valid test case.
"temp" is the JDK temp dir, and as such is needed to be able to read JARs.

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



NSAPI and Solaris

2003-11-04 Thread James McGovern
Was looking for the binaries for the NSAPI Plugin for IPlanet that supports APJ13 
protocol running on Solaris and couldn't find it. Noticed 
 that the Solaris code hasn't been updated in a 1 1/2 years.
 
Is this an unsupported configuration? Are there alternatives? 

tomcat http11 connector: setTimeout in seconds

2003-11-04 Thread Klaas-van-der Ploeg
(I posted this on tomcat-user, without response)


java.org.apache.coyote.http11.Http11Protocol.setTimeout(int timeouts) {
timeout = timeouts * 1000;
setAttribute("timeout", ""+timeouts);
}

I think this is not correct. According to the documentation, the timeout 
can be configured in milliseconds. So, the result of setting the timeout 
to 2 would be a timeout for 20.000.000 milliseconds. 

My proposed fixed would be:

java.org.apache.coyote.http11.Http11Protocol.setTimeout(int timeouts) {
timeout = timeouts;
setAttribute("timeout", ""+timeouts);
}




We're using Tomcat 4.1.12 on blackdown 1.4.1-beta.
I'm currently investigating a problem which happens to be that a 
pocketpc2002 connects to tomcat, and sometimes this causes the tomcat http 
connector to wait on the InputStream.read() method in 
InternalInputBuffer.fill(). While investigating, we firstly wanted to 
identify the problem before upgrading to a higher (and stable) jvm 
version.
While debugging the http connector code, I came across a problem which is 
shortly described above.

I'm wondering, could this InputStream.read() sympthom be caused by the 
timeout being set to 20.000.000 milliseconds??


Thanks.
Klaas

Re: NSAPI and Solaris

2003-11-04 Thread Bill Barker
AFAIK, IPlanet is still supported.  However, there hasn't been an active
developer on the project for a very long time, and so there hasn't been
anyone to generate the binaries.  I would suggest getting the source distro,
and compiling yourself.  And, unless you plan to offer the binaries back,
stop whining.

- Original Message - 
From: "James McGovern" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 03, 2003 4:16 AM
Subject: NSAPI and Solaris


Was looking for the binaries for the NSAPI Plugin for IPlanet that supports
APJ13 protocol running on Solaris and couldn't find it. Noticed
 that the Solaris code hasn't been updated in a 1 1/2 years.

Is this an unsupported configuration? Are there alternatives?


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]

Re: jk2/apr patch v2

2003-11-04 Thread jean-frederic clere
Kurt Miller wrote:
Thanks to jean-frederic clere for input on this. Ok, here goes again... ;-)

Attached is a patch that makes the following changes for building jk2 via
configure and make:
1) Introduces a new configure argument called --enable-apr-threads= for
use with --with-apr. This argument allows for threading to be configured for
apr because apr doesn't always guess threading the same way apache is
configured.
2) Changes --with-apr to configure apr while configuring jk2. This allows
for the correct naming of the apr library name instead of hard coding it and
compiler consistency with apache13 (I copied stuff from the webapp connector
for this)
3) Added compiler consistency checks for apache13 and apache2. The same
compiler must be used for jk2 as was used for apache. For apache13 a side
effect is that apr is also configured to use the same compiler (picked up
via the environment).
4) Added checks to force the use of --with-apr for apache13 and disallow use
of --with-apr for apache2.
Please review and consider for committing if there are no issues or
objections.
+++
+APR_LDFLAGS="${APR_DIR}/.libs/${APR_LDFLAGS}"
+++
That is still weird...
--apr-la-file gives the path to the apr library when installed. (better than 
--link-libtool).
I think we should install the library something like:
+++
$(LIBTOOL) --mode=install \
  cp $(APR_DIR)/$(APR_LIBNAME) $(LIB_DIR)/$(APR_LIBNAME)
$(LIBTOOL) --mode=finish $(LIB_DIR)
+++

Anyway the proposed patch is already much better than the actual code.


-Kurt





-
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 24380] New: - Tomcat cannot support file download with non-ISO characters filename

2003-11-04 Thread 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=24380

Tomcat cannot support file download with non-ISO characters filename

   Summary: Tomcat cannot support file download with non-ISO
characters filename
   Product: Tomcat 4
   Version: 4.1.29
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The problem seems is a header encoding proglem. Tomcat 4.1.29 always return 
headers encoded in UTF8 irrespective of content type and any other settings. 
This casued browser(MSIE) cannot download file with correct non-ISO characters 
filename. There is no such problem found in 4.0.6 which outputs the filename in 
headers with ISO encoding.

Have tried charset=Big5, ISO8859-1, ..., all failed.

Example:

// filename obtained from file system in ISO format and convert to correct xxx 
encoding
filename=new String(filename.getBytes("ISO8859-1"), "xxx");
response.setContentType("application/x-download;charset=xxx"); 
response.setHeader("Content-Disposition", "filename="+filename);
ServletOutputStream out = response.getOutputStream();
// ... read the file from disk and write to user
out.close();

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



Re: jk2/apr patch v2

2003-11-04 Thread Henri Gomez
jean-frederic clere a écrit :

Kurt Miller wrote:

Thanks to jean-frederic clere for input on this. Ok, here goes 
again... ;-)

Attached is a patch that makes the following changes for building jk2 via
configure and make:
1) Introduces a new configure argument called 
--enable-apr-threads= for
use with --with-apr. This argument allows for threading to be 
configured for
apr because apr doesn't always guess threading the same way apache is
configured.

2) Changes --with-apr to configure apr while configuring jk2. This allows
for the correct naming of the apr library name instead of hard coding 
it and
compiler consistency with apache13 (I copied stuff from the webapp 
connector
for this)

3) Added compiler consistency checks for apache13 and apache2. The same
compiler must be used for jk2 as was used for apache. For apache13 a side
effect is that apr is also configured to use the same compiler (picked up
via the environment).
4) Added checks to force the use of --with-apr for apache13 and 
disallow use
of --with-apr for apache2.

Please review and consider for committing if there are no issues or
objections.


+++
+APR_LDFLAGS="${APR_DIR}/.libs/${APR_LDFLAGS}"
+++
That is still weird...
--apr-la-file gives the path to the apr library when installed. (better 
than --link-libtool).
I think we should install the library something like:
+++
$(LIBTOOL) --mode=install \
  cp $(APR_DIR)/$(APR_LIBNAME) $(LIB_DIR)/$(APR_LIBNAME)
$(LIBTOOL) --mode=finish $(LIB_DIR)
+++

Anyway the proposed patch is already much better than the actual code.
Ok, I'll commit it asap

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


cvs commit: jakarta-tomcat-connectors/jk/support jk_apr.m4 jk_apxs.m4

2003-11-04 Thread hgomez
hgomez  2003/11/04 04:48:05

  Modified:jk/native2 configure.in Makefile.in
   jk/support jk_apr.m4 jk_apxs.m4
  Log:
  Latest apr / apr_utils patch.
  
  Provided by Kurt Muller
  
  Revision  ChangesPath
  1.12  +33 -9 jakarta-tomcat-connectors/jk/native2/configure.in
  
  Index: configure.in
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/configure.in,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- configure.in  3 Nov 2003 09:49:58 -   1.11
  +++ configure.in  4 Nov 2003 12:48:04 -   1.12
  @@ -64,6 +64,7 @@
   dnl sinclude(../support/jk_apache_static.m4)
   sinclude(../support/jk_apxs.m4)
   sinclude(../support/jk_ws.m4)
  +sinclude(../support/jk_exec.m4)
   sinclude(../support/jk_apr.m4)
   sinclude(../support/jk_tchome.m4)
   sinclude(../support/jk_java.m4)
  @@ -172,6 +173,7 @@
   
   dnl APR settings
   
  +JK_APR_THREADS()
   JK_APR([include/apr.h.in])
   JK_APR_INCDIR([apr.h])
   JK_APR_LIBDIR()
  @@ -203,16 +205,37 @@
   
   AC_SUBST(WEBSERVERS)
   
  -dnl check if apache 1.3 selected with jni support
  +dnl apache 1.3 consistancy checks
   if ! ${TEST} -z "$APACHE_HOME" ; then
  -dnl check jni wanted
  - if ${TEST} "${use_jni}" = "true"; then 
  - if ! ${TEST} "${use_apr}" = "true"; then
  - AC_MSG_ERROR(Apache 1.3 need apr to use jni)
  - fi
  - fi
  +dnl check if apache 1.3 was selected without apr sources
  +if ${TEST} -z "$APR_BUILD"; then
  +AC_MSG_ERROR([Apache 1.3 requires apr to built from source, use 
--with-apr])
  +fi
  +dnl make sure compiler matchs apxs
  +if ${TEST} "$APACHE_CC" != "$CC"; then
  +AC_MSG_RESULT([error])
  +AC_MSG_RESULT([compiler discovered by configure: ${CC}])
  +AC_MSG_RESULT([compiler used by apache: ${APACHE_CC}])
  +AC_MSG_RESULT([delete config.cache and try CC=${APACHE_CC} 
./configure])
  +AC_MSG_ERROR([jk2 and apache compilers must be the same])
  +fi
   fi
   
  +dnl apache 2 consistancy checks
  +if ! ${TEST} -z "$APACHE2_HOME" ; then
  +dnl check if apache 2 was selected with apr sources
  +if ${TEST} -z "$APR_BUILD"; then
  +AC_MSG_ERROR([Use apr that comes with Apache 2, remove --with-apr])
  +fi
  +dnl make sure compiler matchs apxs
  +if ${TEST} "$APACHE2_CC" != "$CC"; then
  +AC_MSG_RESULT([error])
  +AC_MSG_RESULT([compiler discovered by configure: ${CC}])
  +AC_MSG_RESULT([compiler used by apache: ${APACHE2_CC}])
  +AC_MSG_RESULT([delete config.cache and try CC=${APACHE2_CC} 
./configure])
  +AC_MSG_ERROR([jk2 and apache compilers must be the same])
  +fi
  +fi
   AC_SUBST(APACHE20_OEXT)
   AC_SUBST(LIB_JK_TYPE)
   AC_SUBST(INSTALL_TYPE)
  @@ -225,6 +248,7 @@
   AC_SUBST(APR_HOME)
   AC_SUBST(APR_INCDIR)
   AC_SUBST(APR_LIBDIR)
  +AC_SUBST(APR_CONFIGURE_ARGS)
   AC_SUBST(APR_LDFLAGS)
   AC_SUBST(COMMON_APR_OBJECTS)
   
  
  
  
  1.3   +1 -1  jakarta-tomcat-connectors/jk/native2/Makefile.in
  
  Index: Makefile.in
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/Makefile.in,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- Makefile.in   24 May 2002 07:14:08 -  1.2
  +++ Makefile.in   4 Nov 2003 12:48:05 -   1.3
  @@ -41,7 +41,7 @@
done;
   
   apr-build:
  - ( cd @APR_DIR@ && ./configure && make )
  + ( cd @APR_DIR@ && make )
   
   apr-clean:
( cd @APR_DIR@ && make clean )
  
  
  
  1.6   +66 -2 jakarta-tomcat-connectors/jk/support/jk_apr.m4
  
  Index: jk_apr.m4
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- jk_apr.m4 3 Nov 2003 09:59:45 -   1.5
  +++ jk_apr.m4 4 Nov 2003 12:48:05 -   1.6
  @@ -64,6 +64,31 @@
   dnl --
   
   dnl --
  +dnl JK_APR_THREADS
  +dnl   Configure APR threading for use with --with-apr.
  +dnl   Result goes into APR_CONFIGURE_ARGS
  +dnl --
  +AC_DEFUN(
  +  [JK_APR_THREADS],
  +  [
  +AC_ARG_ENABLE(
  +  [apr-threads],
  +  [  --enable-apr-threadsConfigure APR threading for use with 
--with-apr ],
  +  [
  +case "${enableval}" in
  +  ""|"yes"|"YES"|"true"|"TRUE")
  +APR_CONFIGURE_ARGS="--enable-threads ${APR_CONFIGURE_ARG

DO NOT REPLY [Bug 24385] New: - text conversion fails with jsp:forward/param on linux server

2003-11-04 Thread 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=24385

text conversion fails with jsp:forward/param on linux server

   Summary: text conversion fails with jsp:forward/param on linux
server
   Product: Tomcat 4
   Version: 4.1.27
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In a combination of tomcat on a linux server and IE or Mozilla on a windows 
client you get a wrong character conversion. In the following example you call 
test1.jsp, the parameter value shown in test2.jsp is in UTF-8 instead of ISO-
8859-1.

test1.jsp
-
<%@ page language="java" contentType="text/html; charset=ISO-8859-1" %>

  

-

test2.jsp
-
<%@ page language="java" contentType="text/html; charset=ISO-8859-1" %>

  

Test Umlaut Ä-Ö-Ü-ä-ö-ü
  
  
Template Text: Test Umlaut Ä-Ö-Ü-ä-ö-ü
Text from Parameter: <%= request.getParameter("param01") %>
Text from Parameter (Workaround): <%= new String(request.getParameter
("param01").getBytes("ISO-8859-1")) %>
  

-

Result
-
Template Text: Test Umlaut Ä-Ö-Ü-ä-ö-ü
Text from Parameter: Test Umlaut Ä-Ö-Ü-ä-ö-ü
Text from Parameter (Workaround): Test Umlaut Ä-Ö-Ü-ä-ö-ü
-

Doesn't occur in template texts or in parameters, which are filled in a HTML 
form.
Doesn't occur with tomcat on windows server and browser on windows client.

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



DO NOT REPLY [Bug 24380] - Tomcat cannot support file download with non-ISO characters filename

2003-11-04 Thread 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=24380

Tomcat cannot support file download with non-ISO characters filename





--- Additional Comments From [EMAIL PROTECTED]  2003-11-04 14:36 ---
There's nothing in any spec which states the encoding that must be used for
headers. content-type specifies the entity body encoding only.

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



DO NOT REPLY [Bug 24392] New: - DefaultContext Fails to reload : The server encountered an internal error (Error retrieving attribute debug) that prevented it from fulfilling this request.

2003-11-04 Thread 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=24392

DefaultContext Fails to reload : The server encountered an internal error (Error 
retrieving attribute debug) that prevented it from fulfilling this request.

   Summary: DefaultContext Fails to reload : The server encountered
an internal error (Error retrieving attribute debug)
that prevented it from fulfilling this request.
   Product: Tomcat 4
   Version: 4.1.29
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Once you create a default context in the admin app for tomcat and commit 
changes the default context is added to the server.xml
However after a restart, the default context page is no longer accessible.

Steps to reproduce:
1) Take release and install.
2) Start tomcat.
3) Log into admin application
4) Navigate to Host (localhost)
5) In Host Actions, choose Create New Default Context
6) Make appropriate settings in New Default Context and save.
7) Commit Changes
8) Log out
9) Restart tomcat
10) Login to admin app and navigate to Host (localhost) -> Default Context
11) Error reported :
type Status report

message Error retrieving attribute debug

description The server encountered an internal error (Error retrieving 
attribute debug) that prevented it from fulfilling this request.

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



tomcat session sharing problem

2003-11-04 Thread Ravi Pachipala
We are using tomcat 4.1.24 and we found a particular problem where user A in
one session is seeing user Bs information who logged in a different user in
tomcat.

We investigated this further and found that at the time this happened, there
was an exception in tomcat as follows. Both user A and B are logged in at
the same time and exception happens wen userA's session makes a
request.getParameters() call. Has anyone seen this? This is potentially a
very dangerous scenario  in production environments.

java.io.CharConversionException: isHexDigit
at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:124)
at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:87)
at
org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:407
)
at
org.apache.coyote.tomcat4.CoyoteRequest.parseRequestParameters(CoyoteRequest
.java:1966)
at
org.apache.coyote.tomcat4.CoyoteRequest.getParameterNames(CoyoteRequest.java
:953)
at
org.apache.coyote.tomcat4.CoyoteRequestFacade.getParameterNames(CoyoteReques
tFacade.java:183)
at
com.everypath.online.epservlet.ControllingServlet.getParameters(ControllingS
ervlet.java:988)
at
com.everypath.online.epservlet.ControllingServlet.getServerRequest(Controlli
ngServlet.java:725)
at
com.everypath.online.epservlet.ControllingServlet.service(ControllingServlet
.java:236)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
at
filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:
170)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:213)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:256)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180
)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172
)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at
org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261)
at
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604)
at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:562)
at
org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:619)
at java.lang.Thread.run(Thread.java:4


http://jakarta.apache.org/tomcat/tomcat-5.0-doc

2003-11-04 Thread jean-frederic clere
Hi,

I would like to correct things in the TC-5.0. Where is the repos?

Cheers

Jean-Frederic

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


Re: tomcat session sharing problem

2003-11-04 Thread Remy Maucherat
Ravi Pachipala wrote:

We are using tomcat 4.1.24 and we found a particular problem where user A in
one session is seeing user Bs information who logged in a different user in
tomcat.
We investigated this further and found that at the time this happened, there
was an exception in tomcat as follows. Both user A and B are logged in at
the same time and exception happens wen userA's session makes a
request.getParameters() call. Has anyone seen this? This is potentially a
very dangerous scenario  in production environments.
I think you should try TC 4.1.29 or 5.0.14.
(please post that kind of message on tomcat-user)
Rémy



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


RE: tomcat session sharing problem

2003-11-04 Thread Ravi Pachipala
Sorry if this is the wrong alias. I am a developer and am trying to look
into tomcat code to determine the source of problem.

Is this problem fixed in 4.1.29? I don't see any bug reports for this.

Ravi

-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 04, 2003 7:54 AM
To: Tomcat Developers List
Subject: Re: tomcat session sharing problem


Ravi Pachipala wrote:

> We are using tomcat 4.1.24 and we found a particular problem where user A
in
> one session is seeing user Bs information who logged in a different user
in
> tomcat.
> 
> We investigated this further and found that at the time this happened,
there
> was an exception in tomcat as follows. Both user A and B are logged in at
> the same time and exception happens wen userA's session makes a
> request.getParameters() call. Has anyone seen this? This is potentially a
> very dangerous scenario  in production environments.

I think you should try TC 4.1.29 or 5.0.14.
(please post that kind of message on tomcat-user)

Rémy



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


Re: http://jakarta.apache.org/tomcat/tomcat-5.0-doc

2003-11-04 Thread Tim Funk
I don't know how they published to jakarta.apache.org but the docs are in 
jakarta-tomcat-catalina/webapps/docs

-Tim

jean-frederic clere wrote:
Hi,

I would like to correct things in the TC-5.0. Where is the repos?

Cheers

Jean-Frederic



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


from phani

2003-11-04 Thread phani kumar
Hello,
 
Can you please help me.  I am working as programmer in Qatar and we are in a project 
and I 've encountered following problem as I am new to java environment. 
 
I am trying to run HelloWorld servlet. I have j2sdk1.4.0 in c:\ and 
jakarta-tomcat-5.0.12 in c:\ and 
 
now I've compiled the servlet by setting the classpath variable to tomcat's 
lib\servlets-api jar file. I could compile the servlet and the resultant .class file I 
am keeping in following directory.
 
webapps\servlets-examples\WEB-INF\classes
 
and now what URL I should type in the browser inorder to get the output.
 
I've also set the TOMCAT_HOME=c:\jakarta-tomcat-5.0.12
JAVA_HOME=c:\j2sdk1.4.0
 
Please help in getting the output.
 
Thank you very much 
 
M.phani Kumar


-
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Re: http://jakarta.apache.org/tomcat/tomcat-5.0-doc

2003-11-04 Thread Remy Maucherat
Tim Funk wrote:

I don't know how they published to jakarta.apache.org but the docs are 
in jakarta-tomcat-catalina/webapps/docs
It's a highly advanced process that few people can fathom :) I zip 
whatever is in dist/webapps/tomcat-docs, scp to the server, and unzip in 
the right place.

Rémy



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


Tomcat 4.1.27 and iis 5 connection using JNI

2003-11-04 Thread Eric Choi
Hi,

 

I am trying to setup Tomcat4.1.27 and IIS 5 using JNI.

However, I follow the instruction in the document but cannot set
successfully.

 

I am using JDK 1.4.2_01 and all installation are in Windows 2K platform.

 

Can you give me more information or suggestion on how to set it up
successfully?

 

Thanks and Regards,

 

Eric



-
Additional information is available upon request
Copyright (c) 2002 CLSA Asia-Pacific Markets. The information and statistical data 
herein have been obtained from sources we believe to be reliable but in no way are 
warranted by us as to accuracy or completeness. We do not undertake to advise you as 
to any change of our views. This is not a solicitation or any offer to buy or sell. 
CLSA Asia-Pacific Markets has produced this information for private circulation only. 
All information and advice is given in good faith but without any warranty. CLSA 
Asia-Pacific Markets, its affiliates or companies or individuals connected with CLSA 
Asia-Pacific Markets may have used the information set forth herein before publication 
and may have positions in, may from time to time purchase or sell or may be materially 
interested in any of the securities mentioned or related securities. This information 
is subject to the terms and conditions of use set forth on the www.clsa.com website. 
MITA (P) 405/07/2001. V.020402. 

This email is only for the use of the addressee and may contain information which is 
confidential, privileged or subject to copyright. If you receive this and are not the 
addressee, please contact the sender or [EMAIL PROTECTED] immediately. Thank you. 

CLSA ASIA-PACIFIC MARKETS http://www.clsa.com 



Re: http://jakarta.apache.org/tomcat/tomcat-5.0-doc

2003-11-04 Thread jean-frederic clere
Remy Maucherat wrote:
Tim Funk wrote:

I don't know how they published to jakarta.apache.org but the docs are 
in jakarta-tomcat-catalina/webapps/docs


It's a highly advanced process that few people can fathom :) I zip 
whatever is in dist/webapps/tomcat-docs, scp to the server, and unzip in 
the right place.
Thanks... I think I am now one of those ;-))

Rémy



-
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-catalina/webapps/docs/config valve.xml

2003-11-04 Thread yoavs
yoavs   2003/11/04 09:58:46

  Modified:webapps/docs/config valve.xml
  Log:
  Fixed typo in "component."
  
  Revision  ChangesPath
  1.5   +1 -1  jakarta-tomcat-catalina/webapps/docs/config/valve.xml
  
  Index: valve.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/valve.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- valve.xml 24 Jul 2003 12:52:55 -  1.4
  +++ valve.xml 4 Nov 2003 17:58:46 -   1.5
  @@ -16,7 +16,7 @@
   
   
   
  -  A Valve element represents a comonent that will be
  +  A Valve element represents a component that will be
 inserted into the request processing pipeline for the associated
 Catalina container (Engine,
 Host, or Context).
  
  
  

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



DO NOT REPLY [Bug 24347] - Try to log on with a user without any roles. Then enter "/admin", the "/admin" does not work.

2003-11-04 Thread 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=24347

Try to log on with a user without any roles. Then enter "/admin", the "/admin" does 
not work.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2003-11-04 18:15 ---
I don't see why "onewithoutrole" should have access to admin if the role hasn't
been assigned to it.  Try refreshing the page so that it doesn't try to keep
logging on using no role user.  It should log you back on with your original
admin user and you can change the role after that.

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



DO NOT REPLY [Bug 16113] - removing then replacing a jsp page continues to give a 404

2003-11-04 Thread 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=16113

removing then replacing a jsp page continues to give a 404

[EMAIL PROTECTED] changed:

   What|Removed |Added

Version|4.1.18  |4.1.29



--- Additional Comments From [EMAIL PROTECTED]  2003-11-04 18:19 ---
I have verified that it is still a bug in 4.1.29. David, would it be possible
for you to mail me a copy of your patch?

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



DO NOT REPLY [Bug 24086] - [Administration]Http 500 error in "Logger" page, when use mozilla, click "back" in toolbar

2003-11-04 Thread 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=24086

[Administration]Http 500 error in "Logger" page, when use mozilla, click "back" in 
toolbar





--- Additional Comments From [EMAIL PROTECTED]  2003-11-04 18:19 ---
What does the server log say when you get 500 on Mozilla?  You are encouraged
not to use "back" button.  You should try going back to logger page by clicking
on the logger node in the tree instead "back" button since different browser
might have unexpected results.

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



jsp:include bug in 4.1.27

2003-11-04 Thread Holtfreter, Gregory

I am currently porting webapps to Tomcat(4.1.27) from WL and believe I may have found 
a bug with the 
implementation of the jsp:include action tag. The problem I found is that when using 
the jsp:include tag in a page which resides in a context which differs from the 
request's initial context the page being included is not found. (The crossContext 
attribute of the Context element has been set to true.) 

An example may better explain this:

WebappOne
one.jsp source:
WebappOne/one.jsp
<% 
config.getServletContext().getContext("/WebappTwo").getRequestDispatcher("/two.jsp").include(request,response);
 %>

WebappTwo
two.jsp source:
WebappTwo/two.jsp


three.jsp source:
WebappTwo/three.jsp 


The text inside of WebappTwo/three.jsp will not be included in WebappTwo/two.jsp 
output when requesting WebappOne/one.jsp. However, if we move WebappTwo/three.jsp to 
WebappOne the output is included in the output of WebappTwo/two.jsp. 

I think that the cause of this is that JspRuntimeLibrary.include(...) uses the request 
to obtain a RequestDispatcher and the request is pointing to the initial context:

RequestDispatcher rd = request.getRequestDispatcher(resourcePath);
rd.include(request, new ServletResponseWrapperInclude(response, out));

The JSP 1.2 spec seems to say that jsp:include should be relative to the current page:

"A  element provides for the inclusion of static and dynamic
resources in the same context as the current page."

Thanks,
Greg Holtfreter
Software Engineer
Encyclopaedia Britannica  


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



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

2003-11-04 Thread kinman
kinman  2003/11/04 11:28:49

  Modified:jasper2/src/share/org/apache/jasper/runtime
JspRuntimeLibrary.java
  Log:
  - Use ISO-8859-1 as the default encoding for  since it is the
default encoding for the request object.
  
  Revision  ChangesPath
  1.25  +4 -4  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java
  
  Index: JspRuntimeLibrary.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- JspRuntimeLibrary.java2 Sep 2003 21:39:59 -   1.24
  +++ JspRuntimeLibrary.java4 Nov 2003 19:28:49 -   1.25
  @@ -1020,7 +1020,7 @@
}
   
if (enc == null) {
  - enc = "UTF-8";  // Is this right?
  + enc = "ISO-8859-1"; // The default request encoding 
}
   
StringBuffer out = new StringBuffer(s.length());
  
  
  

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



DO NOT REPLY [Bug 18650] - Exception while processing a JAR file

2003-11-04 Thread 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=18650

Exception while processing a JAR file





--- Additional Comments From [EMAIL PROTECTED]  2003-11-04 20:36 ---
The requirement that $CATALINA_BASE/temp must exist for temp files came 
somewhere between 4.0.3 and 4.1.27. I agree that it's now a necessary 
directory for the jdk, and I wasn't advocating deleting $CATALINA_BASE/temp 
from the tomcat install, or that it shouldn't be required. My intent was to 
show how the poor error messaging would appear if $CATALINA_BASE/temp doesn't 
exist.

A more valid test case would involve upgrading an application running on 4.0.3 
set up in a way that $CATALINA_BASE != $CATALINA_HOME (a realistic scenario) 
to 4.1.27. The upgrade to 4.1.27 will not work without $CATALINA_BASE/temp, 
and the user will have no indication why based on the error messaging.

This upgrade scenerio above happened to me, as I'm sure it will happen to 
others. It took me a better part of the day to figure out that all that was 
needed was to do 'mkdir $CATALINA_BASE/temp'. With better error messaging, 
this can be avoided.

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



RE: tomcat session sharing problem

2003-11-04 Thread Ravi Pachipala
Here is a better description. I am not sure where to look for in tomcat
code.

---
we are seeing a session mixup problem in a deployed tomcat instance running
with coyote connector. A user is seeing another user's data and request
parameters. We took a look at the coyote code and found out that parameters
are not reset till the next request. If a thread switch were to occur during
this time (due to an exception), is it possible for session data to get
mixed up? Please let us know how we can further investigate the problem or
if you have a solution for this
--

Thanks
Ravi

-Original Message-
From: Ravi Pachipala [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 04, 2003 8:27 AM
To: 'Tomcat Developers List'
Subject: RE: tomcat session sharing problem


Sorry if this is the wrong alias. I am a developer and am trying to look
into tomcat code to determine the source of problem.

Is this problem fixed in 4.1.29? I don't see any bug reports for this.

Ravi

-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 04, 2003 7:54 AM
To: Tomcat Developers List
Subject: Re: tomcat session sharing problem


Ravi Pachipala wrote:

> We are using tomcat 4.1.24 and we found a particular problem where user A
in
> one session is seeing user Bs information who logged in a different user
in
> tomcat.
> 
> We investigated this further and found that at the time this happened,
there
> was an exception in tomcat as follows. Both user A and B are logged in at
> the same time and exception happens wen userA's session makes a
> request.getParameters() call. Has anyone seen this? This is potentially a
> very dangerous scenario  in production environments.

I think you should try TC 4.1.29 or 5.0.14.
(please post that kind of message on tomcat-user)

Rémy



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


DO NOT REPLY [Bug 24413] New: - bundled JMX implementation not compliant to specification

2003-11-04 Thread 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=24413

bundled JMX implementation not compliant to specification

   Summary: bundled JMX implementation not compliant to
specification
   Product: Tomcat 5
   Version: 5.0.12
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The jmx.jar bundled with this verion, does not support values "getter" 
and "setter" for attribute "role" in ModelMBeanOperationInfo. The values that 
should be supported include "operation", "getter" and "setter". Please advise 
if any other version has a correct implementation.

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



Re: jk2/apr patch v2

2003-11-04 Thread Kurt Miller
From: "jean-frederic clere" <[EMAIL PROTECTED]>
> Kurt Miller wrote:
> > Thanks to jean-frederic clere for input on this. Ok, here goes again...
;-)
> >
> > Attached is a patch that makes the following changes for building jk2
via
> > configure and make:
> >
> > 1) Introduces a new configure argument called --enable-apr-threads=
for
> > use with --with-apr. This argument allows for threading to be configured
for
> > apr because apr doesn't always guess threading the same way apache is
> > configured.
> >
> > 2) Changes --with-apr to configure apr while configuring jk2. This
allows
> > for the correct naming of the apr library name instead of hard coding it
and
> > compiler consistency with apache13 (I copied stuff from the webapp
connector
> > for this)
> >
> > 3) Added compiler consistency checks for apache13 and apache2. The same
> > compiler must be used for jk2 as was used for apache. For apache13 a
side
> > effect is that apr is also configured to use the same compiler (picked
up
> > via the environment).
> >
> > 4) Added checks to force the use of --with-apr for apache13 and disallow
use
> > of --with-apr for apache2.
> >
> > Please review and consider for committing if there are no issues or
> > objections.
>
> +++
> +APR_LDFLAGS="${APR_DIR}/.libs/${APR_LDFLAGS}"
> +++
> That is still weird...

Yea. I was hoping that apr-config would let me know where the .a file was,
but it only tells you where the .la file is and there not in the same place.

> --apr-la-file gives the path to the apr library when installed. (better
than
> --link-libtool).
> I think we should install the library something like:
> +++
>  $(LIBTOOL) --mode=install \
>cp $(APR_DIR)/$(APR_LIBNAME) $(LIB_DIR)/$(APR_LIBNAME)
>  $(LIBTOOL) --mode=finish $(LIB_DIR)
> +++

Humm. I kinda like not having apr installed since we're staticly linking it
in. For apache13 we're forcing them to build from source but I'm not sure
that an install of apr should be forced too. I guess it conceivable that apr
could already be installed and used by other applications (subversion
maybe?), but be configured differently then is needed for jk2/apache13.

>
> Anyway the proposed patch is already much better than the actual code.
>

Thanks. :)

On another thread I noted that jk_md5 is now depending on apr-util. Since
I'm familiar with the m4 macros now would it be worthwhile for me to make a
patch to add configure support for apr-util following the same pattern as
apr? I'd be focusing on the apache13 case only (--with-apr-util) since that
is what I can test easily now.

-Kurt


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



DO NOT REPLY [Bug 24380] - Tomcat cannot support file download with non-ISO characters filename

2003-11-04 Thread 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=24380

Tomcat cannot support file download with non-ISO characters filename





--- Additional Comments From [EMAIL PROTECTED]  2003-11-05 01:50 ---
This spec grey area caused Tomcat cannot support non-ISO filename file download 
since 4.1.2x. I think it needs to define clearly somewhere or better to leave 
header encoding as ISO8859-1 as in 4.0.x version rather than UTF8 that most 
browsers, e.g. IE, do not understand.

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



Connector ObjectName includes address

2003-11-04 Thread Amy Roh
Currently, connector objectname includes address in this format:

domain:type=Connector,port=8080,address=0.0.0.0.

This causes a problem when IPV6 addresses are used since IPV6 addresses 
include colons.  The javax.management.ObjectName doesn't allow to have 
colon character in it and this causes 
javax.management.MalformedObjectNameException: ObjectName: invalid 
character ':' in value part of property.

I propose to exclude address as connector objectname property since port 
number alone should keep the objectnames unique.

Are we using address value from connector objectname anywhere?

Thanks,
Amy


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


PATCH: null terminate jk_stat->active

2003-11-04 Thread Kyle VanderBeek
Here is a patch against current CVS to fix a problem I saw and described 
in bug 24314:

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

jk_stat->active (a char[64]) is populated via strncpy() which doesn't 
guarantee that null-termination takes place.  /jkstatus treats "active" 
like a string, so we should null-terminate it, else the jkprintf's in 
jk_worker_status.c may walk right off the end.

Please apply.

-- 
[EMAIL PROTECTED]
  Some people have a way with words, while others... erm... thingy.

Index: jk/native2/common/jk_worker_ajp13.c
===
RCS file: 
/home/cvspublic/jakarta-tomcat-connectors/jk/native2/common/jk_worker_ajp13.c,v
retrieving revision 1.52
diff -u -r1.52 jk_worker_ajp13.c
--- jk/native2/common/jk_worker_ajp13.c 30 Oct 2003 20:08:36 -  1.52
+++ jk/native2/common/jk_worker_ajp13.c 5 Nov 2003 01:49:52 -
@@ -565,7 +565,9 @@
 
 /* XXX configurable ? */
 strncpy( e->stats->active, s->req_uri, 64);
-
+/* Be sure this is null terminated if it's a long url */
+e->stats->active[63] = '\0';
+
 /* Prepare the messages we'll use.*/ 
 e->request->reset( env, e->request );
 e->reply->reset( env, e->reply );

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



DO NOT REPLY [Bug 24420] New: - jasper and xerces problem compilation

2003-11-04 Thread 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=24420

jasper and xerces problem compilation

   Summary: jasper and xerces problem compilation
   Product: Tomcat 4
   Version: 4.1.29
  Platform: PC
   URL: http://comicxpert.ele.etsmtl.ca
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


Hello, 
I have a problem since one week.
I have to upgrade an existing system working with JSP and XML files.
There is a login page written in .jsp and the login/password are written in a 
XML file.
Any time I try tu access the system (by loggin), a compilation error appear.
I'm using TOMCAT 4.1.29 and J2SDK 1.4.1_05.
It's a little bit long, but you can have a look just to the firsts lines of the 
ROOT CAUSE (and the exception)




HTTP Status 500 - 



type Exception report

message 

description The server encountered an internal error () that prevented it from 
fulfilling this request.

exception 

org.apache.jasper.JasperException
at org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:254)
at org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:256)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke
(AuthenticatorBase.java:494)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2417)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:171)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:172)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:174)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service
(CoyoteAdapter.java:193)
at org.apache.coyote.http11.Http11Processor.process
(Http11Processor.java:781)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnectio
n(Http11Protocol.java:549)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:589)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:666)
at java.lang.Thread.run(Thread.java:536)


root cause 

java.lang.NullPointerException
at org.apache.xerces.parsers.AbstractSAXParser.setErrorHandler(Unknown 
Source)
 

Re: Connector ObjectName includes address

2003-11-04 Thread Bill Barker

- Original Message -
From: "Amy Roh" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, November 04, 2003 6:01 PM
Subject: Connector ObjectName includes address


> Currently, connector objectname includes address in this format:
>
> domain:type=Connector,port=8080,address=0.0.0.0.
>
> This causes a problem when IPV6 addresses are used since IPV6 addresses
> include colons.  The javax.management.ObjectName doesn't allow to have
> colon character in it and this causes
> javax.management.MalformedObjectNameException: ObjectName: invalid
> character ':' in value part of property.
>
> I propose to exclude address as connector objectname property since port
> number alone should keep the objectnames unique.
>

What about the case where I have several V-Hosts, each with it's own
Connector listening on port 80?

> Are we using address value from connector objectname anywhere?
>
> Thanks,
> Amy
>
>
>
> -
> 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]

Servlet Context Logger

2003-11-04 Thread Hatem AbouHassan
Environment:
->Tomcat 4.1.27 LE
->Linux RedHat 9

Tried to follow the instructions to use the servletContext Logger,
ServletContext.log(...)
Wrote the code, compiled successfully, but do not know where to find the log
results anywhere in Catalina.out nor localhost_testapp_log..txt

Can someone help find out where should I find the thing?

Appreciated!



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



Re: Connector ObjectName includes address

2003-11-04 Thread Amy Roh
Bill Barker wrote:

- Original Message -
From: "Amy Roh" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, November 04, 2003 6:01 PM
Subject: Connector ObjectName includes address


Currently, connector objectname includes address in this format:

domain:type=Connector,port=8080,address=0.0.0.0.

This causes a problem when IPV6 addresses are used since IPV6 addresses
include colons.  The javax.management.ObjectName doesn't allow to have
colon character in it and this causes
javax.management.MalformedObjectNameException: ObjectName: invalid
character ':' in value part of property.
I propose to exclude address as connector objectname property since port
number alone should keep the objectnames unique.


What about the case where I have several V-Hosts, each with it's own
Connector listening on port 80?
That's the case I forgot about.  I guess we need address in connector 
objectname since connectors can share the same port...



Are we using address value from connector objectname anywhere?

Thanks,
Amy


-
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]




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


Re: from phani

2003-11-04 Thread Basavaraju P. Banakar
try this

http://localhost:8080/servlets-examples/sevlet/servlet-name


- Original Message -
From: "phani kumar" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 04, 2003 9:35 PM
Subject: from phani


> Hello,
>
> Can you please help me.  I am working as programmer in Qatar and we are in
a project and I 've encountered following problem as I am new to java
environment.
>
> I am trying to run HelloWorld servlet. I have j2sdk1.4.0 in c:\ and
jakarta-tomcat-5.0.12 in c:\ and
>
> now I've compiled the servlet by setting the classpath variable to
tomcat's lib\servlets-api jar file. I could compile the servlet and the
resultant .class file I am keeping in following directory.
>
> webapps\servlets-examples\WEB-INF\classes
>
> and now what URL I should type in the browser inorder to get the output.
>
> I've also set the TOMCAT_HOME=c:\jakarta-tomcat-5.0.12
> JAVA_HOME=c:\j2sdk1.4.0
>
> Please help in getting the output.
>
> Thank you very much
>
> M.phani Kumar
>
>
> -
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard


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