cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk2 configweb.xml

[mturk]

mturk   2002/10/02 23:58:24

  Modified:jk/xdocs/jk2 configweb.xml
  Log:
  Add the channel.apr and explain new options for the
  load balancer.
  
  Revision  ChangesPath
  1.10  +87 -3 jakarta-tomcat-connectors/jk/xdocs/jk2/configweb.xml
  
  Index: configweb.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk2/configweb.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- configweb.xml 26 Sep 2002 07:37:21 -  1.9
  +++ configweb.xml 3 Oct 2002 06:58:24 -   1.10
  @@ -287,6 +287,66 @@
   
   
   
  +
  +
  +A communication transport to a remote Engine using APR library
  +Magic: The local part of the name will be the Engine name,
  +to use when defining the uri mappings. For example
  +channel.apr.local_9009 will automatically define an engine named
  +local_9009, and if no other setting is set ajp13 will be used for
  +communication.
  +Magic: If no channel is defined in the config, a default channel
  +will be constructed with port=8009, engine=DEFAULT, worker=ajp13 -
  +named 'channel.apr.DEFAULT'
  +
  +
  +
  +
  +Property name
  +Default
  +Description
  +
  +
  +port
  +8009
  +Port where Tomcat is listening
  +
  +
  +host
  +localhost
  +Remote host
  +
  +
  +keepalive
  +0 (disabled)
  +If set to 1 then it enables the use of keep-alive 
packets on TCP connection 
  +
  +
  +timeout
  +0 (infinite)
  +Socket timeout for sending and receiving
  +
  +
  +ndelay
  +0
  +If set to 1 Disables the Nagle algorithm for send 
coalescing
  +
  +
  +lbfactor
  +1
  +
  +Load balancing factor to use. At this moment, it'll be set on the worker,
  +but in future it should be possible to use lb on a channel level.
  +  
  +
  +
  +group
  +lb:0
  +loadbalanced groups to which this channel and the 
associated worker will be added, multivalued
  +
  +
  +
  +
   
   The jni channel, used if tomcat is started inprocess
   
  @@ -296,9 +356,9 @@
For the moment 4 worker types are supported: 
worker.jni,ajp13,status,lb.
   
   
  -worker used in inprocess, holds the details of the Tomcat class 
to startup, and paramters to pass
  +worker used in inprocess, holds the details of the Tomcat class 
to startup, and parameters to pass
   There are two predefined jni workers onStartup and 
onShutdown. Those two workers are executed
  -during sturtup and shutdown phase of the connector. Both must 
exsist in the configuration to be able to start
  +during startup and shutdown phase of the connector. Both must 
exists in the configuration to be able to start
   and shutdown Tomcat.
   
   
  @@ -409,6 +469,30 @@
   
   
   
  +
  +timeout
  +0 (disabled)
  +If all the workers are in the error state, probably 
by Tomcat
  +refusing any new connections due to the overload, you can set the timeout forcing 
lb to wait that some
  +worker becomes available, instead of immediately returning error to the client. 
This is very useful in
  +situations with high peek load. The timeout should be set to the maximum 
application call time, but
  +not less then 1 second.
  +
  +
  +
  +attempts
  +3
  +

DO NOT REPLY [Bug 13231] - web container not sending back content type if html is in JSP

[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=13231

web container not sending back content type if html  is in JSP

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2002-10-03 06:18 ---
same thing happens when Netscape is used.
The same bug does not occur when IE and Netscape are used to access the same 
pages served by other appservers from IPlanet, Weblogic, Oracle.

If the response html (of the JSP) is saved into a .html and reopened in either 
browser, auto-selecting of the encoding as gb2312 occurs.

I suspect that the HTTP response returned by tomcat remains at 
  Content-Type: text/html;charset=ISO-8859-1
even though the html  is present, forcing the browser to use the ISO 
encoding.

would appreciate if you will look into this, or forward it to the correct 
module I/C, cos' it quite irritating to have to change the encoding manually 
upon every page access.

thanks.

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

DO NOT REPLY [Bug 12783] - Coyote Connector and HTTP 1.0 Keep-Alive

[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=12783

Coyote  Connector and HTTP 1.0 Keep-Alive

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-10-03 05:25 ---
The patch has been applied, and will appear in 4.1.13.

Thanks much!

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

cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java

[billbarker]

billbarker2002/10/02 22:24:06

  Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
  Log:
  Send the proper header for HTTP/1.0 Keep-Alives.
  
  If we're going to support it, we should do it right.
  
  Fix for bug #12783
  
  Reported By: [EMAIL PROTECTED]
  Submitted By:  C Twomey [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.38  +2 -0  
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
  
  Index: Http11Processor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
  retrieving revision 1.37
  retrieving revision 1.38
  diff -u -r1.37 -r1.38
  --- Http11Processor.java  21 Sep 2002 06:15:50 -  1.37
  +++ Http11Processor.java  3 Oct 2002 05:24:06 -   1.38
  @@ -895,6 +895,8 @@
   
   if (!keepAlive) {
   response.addHeader("Connection", "close");
  +} else if(!http11) {
  +response.addHeader("Connection", "Keep-Alive");
   }
   
   // Build the response header
  
  
  

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

DO NOT REPLY [Bug 13231] - web container not sending back content type if html is in JSP

[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=13231

web container not sending back content type if html  is in JSP

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-10-03 05:17 ---
You'll have to take this up with Microsoft.  It's their product.  

The "<%@page" directive is the only method to specify the charset within Tomcat.

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

DO NOT REPLY [Bug 13231] New: - web container not sending back content type if html is in JSP

[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=13231

web container not sending back content type if html  is in JSP

   Summary: web container not sending back content type if html
 is in JSP
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Other
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


adding the following meta tag to the JSP 
  
does not cause internet explorer to auto-select the encoding as gb2312.

putting 
  <%@ page contentType="text/html; charset=gb2312"%>
at the top of the JSP will cause internet explorer to auto-select the encoding 
as gb2312 though.

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

RE: Tomcat 4.1.12 and Servlet Access 404 Errors: BUG? One Last Assurance

[iasandcb]

About this issue, I already pointed it out by commenting to JSR-154
servlet 2.4. 
Actually invoker-like features in web containers have provided servlet
deployers with non-standard ways to invoke a servlet by sending a
request message including
"/servlet/fully-qualified-class-name-of-a-servlet".
A few months ago I found that an initial invoker-style call to a servlet
also made an instance from the servlet class and there was no
identification (or name) of the instance  because invoker-style let a
servlet deployer care about nothing with "servlet name-servlet class"
mapping in deployment descriptor. I called the instance "implicitly
initiated servlet instance" and told JSR-154 the ambiguity.

Now, I realized that the problem stems from the existence of the "real"
invoker in Tomcat and servlet deployers have taken it for granted.
However, from Tomcat 4.1.12 and 4.0.5 we need a de facto principle on
servlet name-servlet class-servlet mapping relationship.

Principle: A servlet (class) should have a servlet name and a servlet
mapping associated with that.

In my opinion, servlet spec (possibly 2.4) has to mention the above
statement in order to get rid of the ambiguity and obtain some clarity
that will assure the relationship among servlet class, name, and mapping
for not only servlet deployers but also servlet container implementors.

At this moment, I'd like to say that we need a clearer statement. What
I'm proposing is:

A servlet (class) should have at least one servlet name and
correspondent mapping for invocation.

At a mathematical point of view, mapping from servlet class to servlet
name is one-to-many. (conversely, servlet name to servlet class is
injective.) This means a servlet class can have many servlet names, but
a servlet name cannot be mapped to different servlet classes naturally.
servlet name and servlet mapping goes the same road as well.

Conclusion: servlet class <-- one-to-many --> servlet name <--
one-to-many --> servlet mapping

Here's a typical example:


http://java.sun.com/dtd/web-app_2_3.dtd";>



ias
iasandcb.TestServlet



cb
iasandcb.TestServlet



ias
/servlet/iasandcb.TestServlet



ias
/servlet/TestServlet



cb /servlet/cb


cb
/cb



In this case, we have one servlet class "iasandcb.TestServlet" and it
has two servlet name "ias" and "cb". Finally the names have two servlet
mappings respectively, therefore we have four ways to invoke the
servlet.

http://localhost:8080/test/servlet/iasandcb.TestServlet (invoker style)
http://localhost:8080/test/servlet/TestServlet
http://localhost:8080/test/servlet/cb
http://localhost:8080/test/cb

Formula: the number of the invocation ways of a servlet = sum (the
number of the servlet mappings) for each servlet name of the servlet
(The above case, 4 = 2 + 2)

I hope servlet spec and implementations can get more portablity and
security from this chance.

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] 
Sent: Thursday, October 03, 2002 12:39 AM
To: Tomcat Developers List
Subject: Re: Tomcat 4.1.12 and Servlet Access 404 Errors: BUG? One Last
Assurance




On Wed, 2 Oct 2002, micael wrote:

> Date: Wed, 02 Oct 2002 00:12:20 -0700
> From: micael <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: Tomcat 4.1.12 and Servlet Access 404 Errors: BUG? One
Last
> Assurance
>
> So I can understand, where is the difference in the code between 
> Tomcat 4.1.10 and 4.1.12?  And, do you mean that servlet mappings 
> rather than being generic to some "servlet/*" path be individualized?
>

Let's assume that you have two servlets that are currently accessed via
the following URLs:

  http://localhost:8080/myapp/servlet/com.mypackage.MyFooServlet
  http://localhost:8080/myapp/servlet/com.mypackage.MyBarServlet

that no longer work in 4.1.12.  To avoid changing all your URLs, you
have two basic choices:

(1) Re-enable the invoker servlet by uncommenting the
"/servlet/*" mapping in $CATALINA_HOME/conf/web.xml
(non-portable, might be open to future vulnerabilities)

(2) Explicitly add servlet definitions and mappings for
these two servlets:




Foo
com.mypackage.MyFooServlet



Bar
com.mypackage.MyBarServlet



Foo
 
/servlet/com.mypackage.MyFooServlet



Bar
 
/servlet/com.mypackage.MyBarServlet




The latter choice will selectively re-enable only the servlet mappings
that you actually need.  This is also guaranteed to be portable across
servlet containers, whereas the "invoker" servlet is just a Tomcat
feature.

Craig


> At 12:26 PM 10/2/2002 +1000, you wrote:
> >micael wrote:
> > >
> > > I cannot access a webapp with the normal 
> > > http://localhost:8080/myapp/servlet/mydirectory.MyServlet with 
> > > Tomcat 4.1.12.  (Also, the embedded Tomcat 4.1.12 in JBoss 3.0.3 
> > > runs fine 

Re: Is Compile Failure? was Re: Need some clarifications

[Steve Downey]

You need to be using the HEAD version of digester. It should have been built 
in the directory specified by base.path. Double check that it was built 
correctly. I just recreated it in my depends directory, and the system built 
fine.

A number of the dependencies are unreleased at this point. 'ant download' 
tries to grab the correct ones. 

On Wednesday 02 October 2002 07:54 pm, Christian Gross wrote:
> Thanks for your answer.  That helps quite a bit.  Now I have another
> issue...
>
> build-catalina:
>  [javac] Compiling 94 source files to
> D:\Instructor\Projects\jakarta-tomcat-c
> atalina\build\server\classes
>  [javac]
> D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or
> g\apache\catalina\startup\ContextConfig.java:537: cannot resolve symbol
>  [javac] symbol  : method
> setEntityResolver  (org.apache.catalina.util.Schema
> Resolver)
>  [javac] location: class org.apache.commons.digester.Digester
>  [javac] tldDigester.setEntityResolver(tldEntityResolver);
>  [javac]^
>  [javac]
> D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or
> g\apache\catalina\startup\ContextConfig.java:595: cannot resolve symbol
>  [javac] symbol  : method
> setEntityResolver  (org.apache.catalina.util.Schema
> Resolver)
>  [javac] location: class org.apache.commons.digester.Digester
>  [javac] webDigester.setEntityResolver(webEntityResolver);
>  [javac]^
>  [javac]
> D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or
> g\apache\catalina\util\SchemaResolver.java:154: cannot resolve symbol
>  [javac] symbol  : method setPublicId  (java.lang.String)
>  [javac] location: class org.apache.commons.digester.Digester
>  [javac] digester.setPublicId(publicId);
>  [javac] ^
>  [javac] Note: Some input files use or override a deprecated API.
>  [javac] Note: Recompile with -deprecation for details.
>  [javac] 3 errors
>
> BUILD FAILED
> file:D:/Instructor/Projects/jakarta-tomcat-catalina/catalina/build.xml:801:
> Comp
> ile failed; see the compiler error output for details.
>
> I checked out digester 1.3 and 1.2 and there does not seem to be a method
> setEntityResolver.  Or am I missing something?
>
> Christian Gross
>
> At 14:18 02/10/2002 -0400, you wrote:
> >On Wednesday 02 October 2002 09:38 am, Christian Gross wrote:
> > > Hi
> > >
> > > So I worked myself through the various CVS sources and have a couple of
> > > "official" position questions to ask.
> > >
> > > The CVS projects jakarta-tomcat-catalina and jakarta-tomcat-jasper,
> > > will be forming the Tomcat 5 work?
> >
> >jakarta-servletapi-5, jakarta-tomcat-5, jakarta-tomcat-catalina,
> >jakarta-tomcat-connectors, jakarta-tomcat-jasper, and jakarta-watchdog-4.0
> >are the CVS repositories involved in Tomcat 5.0
> >
> > > The CVS project jakarta-tomcat-4.0 is the 4.x branch?
> >
> >Yes
> >
> > > The CVS project jakarta-tomcat is anything before 4.0
> >
> >Tomcat 3.x, at least.
> >
> > > The CVS project jakarta-tomcat-5.0 does nothing??
> >
> >It's the master project for the whole Tomcat 5.0 project. To use it, start
> >with a directory like tc5-workspace. In that directory:
> >export CVSROOT=:pserver:[EMAIL PROTECTED]:/home/cvspublic
> >cvs co jakarta-servletapi-5
> >cvs co jakarta-tomcat-5
> >cvs co jakarta-tomcat-catalina
> >cvs co jakarta-tomcat-connectors
> >cvs co jakarta-tomcat-jasper
> >
> >then, in jakarta-tomcat-5 create a build.properties file with the
> > following definition
> >base.path = /home/sdowney/tc5-workspace/depends
> >(replace /home/sdowney/tc5-workspace with path to your workspace. I don't
> >know
> >if relative will work. I stopped dinking when I got my build system to
> >function)
> >
> >You need ant 1.5 to build Tomcat 5
> >
> >export ANT_HOME=/home/sdowney/tools/jakarta-ant-1.5
> >
> >PATH=$PATH:$ANT_HOME/bin
> >
> >ant download
> >
> >The download target in Tomcat 5 gets the necessary ancillary libraries to
> >build the system. I'm using JDK 1.4, which has a few things built in. You
> > may need to install some things in JDK 1.3, like JCE. I'm not sure.
> >
> >Then:
> >
> >ant build
> >ant test
> >[Not many tests at the moment]
> >If you're contributing, you may also want to do
> >
> >ant -Dfull.dist=on build
> >
> >That will force a full compile, rather than checking which optional
> >components
> >are available and setting things on or off based on the presense or
> > absense of classes. That useful for building a customized version, but
> > for testing purposes, a full build is better.
> >
> >To run the watchdog conformance test suite:
> >
> >ant watchdog
> >
> >
> >
> >--
> >To unsubscribe, e-mail:  
> >  For additional
> > commands, e-mail: 
>
> Christian Gross
> Software Engineering Consultant
> http://www.devspace.com
> North America: 1-450-675-4208
> Europe +41.1.701.

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_apr_socket.c jk_uriEnv.c jk_uriMap.c jk_worker_jni.c jk_worker_lb.c

[nacho]

nacho   2002/10/02 18:33:15

  Modified:jk/native2/common jk_channel_apr_socket.c jk_uriEnv.c
jk_uriMap.c jk_worker_jni.c jk_worker_lb.c
  Log:
  Problems with EOL
  
  I was  unable to catch any of the multiple times this issue was discussed on the 
list, but again..
  
  Committing files with diferent EOL than the plataform we are working on,
  damages them in CVS.. there are many ways to do this, but one of the
  most commons is to have the sources in a linux i.e., edit them in win32
  with an editor the completes the lf with a cr and commit then form linux..
  I suppouse that are many combinations for that circunstance, take care..
  
  Maybe old cygwin versions are problematic too , i dont know..
  
  Revision  ChangesPath
  1.27  +32 -32
jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c
  
  Index: jk_channel_apr_socket.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- jk_channel_apr_socket.c   2 Oct 2002 12:50:05 -   1.26
  +++ jk_channel_apr_socket.c   3 Oct 2002 01:33:14 -   1.27
  @@ -219,20 +219,20 @@
   apr_socket_t *sock=endpoint->channelData;
   apr_status_t ret;
   apr_int32_t timeout = (apr_int32_t)(socketInfo->timeout * APR_USEC_PER_SEC);
  -char msg[128];
  +char msg[128];
   int connected = 0;
  -
  +
   while (remote_sa && !connected) {
   if ((ret = apr_socket_create(&sock, remote_sa->family, SOCK_STREAM,
(apr_pool_t *)env->globalPool->_private))
   != APR_SUCCESS) {
   env->l->jkLog(env, env->l, remote_sa->next ? JK_LOG_DEBUG : 
JK_LOG_ERROR,
"channelApr.open(): error %d creating socket %d %s\n",
  -  ret, socketInfo->host);
  -remote_sa = remote_sa->next;
  -continue;
  -}
  -
  +  ret, socketInfo->host);
  +remote_sa = remote_sa->next;
  +continue;
  +}
  +
   
   env->l->jkLog(env, env->l, JK_LOG_INFO,
   "channelApr.open(): create tcp socket %d\n", sock );
  @@ -240,33 +240,33 @@
   /* the default timeout (0) will set the socket to blocking with
  infinite timeouts.
   */
  -if (timeout <= 0)
  -apr_socket_timeout_set(sock, 0);
  -else
  +if (timeout <= 0)
  +apr_socket_timeout_set(sock, 0);
  +else
   apr_socket_timeout_set(sock, timeout);
  -
  -/* make the connection out of the socket */
  -do { 
  -ret = apr_connect(sock, remote_sa);
  -} while (APR_STATUS_IS_EINTR(ret));
  -
  -/* if an error occurred, loop round and try again */
  -if (ret != APR_SUCCESS) {
  -apr_socket_close(sock);
  -env->l->jkLog(env, env->l, remote_sa->next ? JK_LOG_DEBUG : 
JK_LOG_ERROR,
  - "channelApr.open() attempt to connect to %pI (%s) failed 
%d\n",
  - remote_sa,
  - socketInfo->host,
  - ret);
  -remote_sa = remote_sa->next;
  -continue;
  -}
  -connected = 1;
  -}
   
  -if (!connected) {
  -apr_socket_close(sock);   
  -return JK_ERR;
  +/* make the connection out of the socket */
  +do { 
  +ret = apr_connect(sock, remote_sa);
  +} while (APR_STATUS_IS_EINTR(ret));
  +
  +/* if an error occurred, loop round and try again */
  +if (ret != APR_SUCCESS) {
  +apr_socket_close(sock);
  +env->l->jkLog(env, env->l, remote_sa->next ? JK_LOG_DEBUG : 
JK_LOG_ERROR,
  + "channelApr.open() attempt to connect to %pI (%s) failed 
%d\n",
  + remote_sa,
  + socketInfo->host,
  + ret);
  +remote_sa = remote_sa->next;
  +continue;
  +}
  +connected = 1;
  +}
  +
  +if (!connected) {
  +apr_socket_close(sock);   
  +return JK_ERR;
   }
   /* enable the use of keep-alive packets on TCP connection */
   if(keepalive) {
  
  
  
  1.36  +11 -11jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c
  
  Index: jk_uriEnv.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c,v
  retrieving revision 1.35
  retrieving revision 1.36
  diff -u -r1.35 -r1.36
  --- jk_uriEnv.c   2 Oct 2002 10:27:17 -   1.35
  +++ jk_uriEnv.c   3 Oct 200

Weird seg fault on Mac OS X for mod_jk2 + Apache2

[Han Ming Ong]

Folks,
I'm trying to trace down a TCP_NODELAY problem and wanted to see if it 
exists on the latest connector mod_jk2. So I configured Apache 2.0.42, 
Tomcat 4.1.12 and downloaded jakarta-tomcat-connectors-4.1.12-src. I 
managed to use GNU's libtoolize to configure (./configure 
--with-apxs2=/usr/local/apache2/bin/apxs 
--with-apr-lib=/usr/local/apache2/lib 
--with-apr-include=/usr/local/apache2/include 
--with-tomcat1=/usr/local/jakarta-tomcat-4.1.12).

The compilation was successful and I copied mod_jk2.so to 
/usr/local/apache2/modules. I configured httpd.conf to load the module 
and appended the following:


JkSet "config.file" "/usr/local/apache2/conf/workers2.properties"


I added a super simple workers2.properties file in the same dir and 
tried to start apache. I got a seg fault. Here's the stacktrace from 
Mac OS X default crash logger:

Command:httpd
PID:853

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:  KERN_INVALID_ADDRESS (0x0001) at 0x736f0028

Thread 0 Crashed:
  #0   0x90001600 in strlen
  #1   0x900023e0 in vfprintf
  #2   0x90015ee0 in __sbprintf
  #3   0x900018a8 in vfprintf
  #4   0x900017ec in fprintf
  #5   0x0060fdbc in jk2_map_default_get (jk_map.c:97)  <-- it's '97' 
because I added printf
  #6   0x0060df50 in jk2_env_createBean2 (jk_env.c:218)
  #7   0x0061ee0c in jk2_create_config (mod_jk2.c:351)
  #8   0x0002214c in ap_single_module_configure (config.c:1845)
  #9   0x7ad8 in load_module (mod_so.c:337)
  #10  0x00020308 in invoke_cmd (config.c:749)
  #11  0x000213d0 in execute_now (config.c:1347)
  #12  0x00020a40 in ap_build_config_sub (config.c:944)
  #13  0x00020f68 in ap_build_config (config.c:1151)
  #14  0x000218f0 in ap_process_resource_config (config.c:1556)
  #15  0x000220e8 in ap_read_config (config.c:1834)
  #16  0xc184 in main (main.c:615)
  #17  0x1ae0 in _start (crt.c:267)
  #18  0x1960 in start


Here's output with some printf statements inserted in jk_map.c:
entering for threadMutex  (no. maps: 25)
 0:  logger.file (°Z°Z°Z°Z°Z°Z) <- funny output is from 
fprintf(stderr,"%s", mPriv->values[i])
 1:  logger.win32 (°Z°Z°Z°Z°Z)
 2:  workerEnv (°Z°ZA°Z°Z)
 3:  uriMap (°Z°Za°Z°Z)
 4:  uriEnv (°Z°ZA°Z°Z)
 5:  endpoint (°Z°ZA°Z°Z)
 6:  uri (°Z°ZA°Z°Z)
 7:  config (°Z°Z°Z°Z°Z°Z)
 8:  ajp13 (°Z°ZA°Z°Z)
 9:  lb (,)
 10:  status (°Z°Z°Z°Z°Z)
 11:  run (,)
 12:  channel.un (°Z°ZA°Z°Z)
 13:  channel.apr (°Z°ZA°Z°Z)
 14:  shm (°Z°Z°Z°Z°Z°Z)
 15:  channel.socket (°Z°ZA°Z°Z)
 16:  handler.response (°Z°Z°Z°Z°Z°Z)
 17:  handler.logon (°Z°Z°Z°Z°Z°Z)
 18:  threadMutex (°Z°Z°Z°Z°Z°Z)
done for threadMutex
entering for logger.apache2:  (no. maps: 1)
 0:  threadMutex:0 ()
done for logger.apache2:
...
...
entering for uri:/examples/*  (no. maps: 19)
 0:  threadMutex:0 ()
 1:  logger.apache2: ()
 2:  logger.apache2 ()
 3:  logger ()
 4:  uriMap: ()
 5:  uriMap ()
 6:  config: ()
 7:  config ()
 8:  shm: ()
 9:  shm ()
 10:  workerEnv: ()
 11:  workerEnv ()
 12:  uri: ()
 13:  uri ()
 14:  threadMutex:1 ()
 15:  threadMutex:2 ()
 16:  threadMutex:3 ()
 17:  ajp13:localhost:8009 ()
 18:  channel.socket:localhost:8009 ()
done for uri:/examples/*
entering for uri  (no. maps: 26)
 0:  logger.file (°Z°Z°Z°Z°Z°Z)
 1:  logger.win32 (°Z°Z°Z°Z°Z)
 2:  workerEnv (°Z°ZA°Z°Z)
 3:  uriMap (°Z°Za°Z°Z)
 4:  uriEnv (°Z°ZA°Z°Z)
 5:  endpoint (°Z°ZA°Z°Z)
 6:  uri (°Z°ZA°Z°Z)
done for uri
entering for workerEnv  (no. maps: 19)
 0:  threadMutex:0 ()
 1:  logger.apache2: ()
 2:  logger.apache2 ()
 3:  logger ()
 4:  uriMap: ()
 5:  uriMap ()
 6:  config: ()
 7:  config ()
 8:  shm: ()
 9:  shm ()
 10:  workerEnv: ()
 11:  workerEnv ()
done for workerEnv
entering for ver  (no. maps: 1)
 0:  worker (ajp13:localhost:8009)
done for ver
[here it churns for a few seconds before segfaulting]
bin/apachectl: line 87:   853 Segmentation fault  $HTTPD -k $ARGV

Anyone has a clue on what could be wrong? Just pointers would help. I 
tried following the stack trace but am temporarily thrown off by how 
jk2_env_createBean2() gets to jk2_map_default_get(), especially the 
second parameter's type. It seems to be casted from (char *) to 
(jk_map_t *), which is kind of weird.

Appreciate it.

Han Ming


# workers2.properties 


# Shared memory handling. Needs to be set.
[shm]
file=/usr/local/apache2/logs/shm.file
size=1048576

# Example socket channel, explicitly set port and host.
[channel.socket:localhost:8009]
port=8009
host=127.0.0.1
#k

DO NOT REPLY [Bug 13060] - org.apache.jasper.JasperException: Unable to compile class for JSP

[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=13060

org.apache.jasper.JasperException: Unable to compile class for JSP

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
  Component|Catalina|Jasper 2
 OS/Version|Windows XP  |Windows NT/2K
 Resolution|WORKSFORME  |



--- Additional Comments From [EMAIL PROTECTED]  2002-10-03 00:14 
---
I experiance the same exception on Win NT 4.

The reason why may be running Tomcat as a Windows Service using tomcat.exe.
When I start Tomcat using startup.bat everything is fine, but when running the 
service the exception is thrown.

Perhaps this may also help: 
I'm also using my own PreferencesFactory in conjunction with Log4J and 
therefore I have to add a jar file with all the required classes plus the log4j-
1.2.6.jar and jdom.jar to the classpath...

HTH

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

Is Compile Failure? was Re: Need some clarifications

[Christian Gross]

Thanks for your answer.  That helps quite a bit.  Now I have another issue...

build-catalina:
 [javac] Compiling 94 source files to 
D:\Instructor\Projects\jakarta-tomcat-c
atalina\build\server\classes
 [javac] 
D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or
g\apache\catalina\startup\ContextConfig.java:537: cannot resolve symbol
 [javac] symbol  : method 
setEntityResolver  (org.apache.catalina.util.Schema
Resolver)
 [javac] location: class org.apache.commons.digester.Digester
 [javac] tldDigester.setEntityResolver(tldEntityResolver);
 [javac]^
 [javac] 
D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or
g\apache\catalina\startup\ContextConfig.java:595: cannot resolve symbol
 [javac] symbol  : method 
setEntityResolver  (org.apache.catalina.util.Schema
Resolver)
 [javac] location: class org.apache.commons.digester.Digester
 [javac] webDigester.setEntityResolver(webEntityResolver);
 [javac]^
 [javac] 
D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or
g\apache\catalina\util\SchemaResolver.java:154: cannot resolve symbol
 [javac] symbol  : method setPublicId  (java.lang.String)
 [javac] location: class org.apache.commons.digester.Digester
 [javac] digester.setPublicId(publicId);
 [javac] ^
 [javac] Note: Some input files use or override a deprecated API.
 [javac] Note: Recompile with -deprecation for details.
 [javac] 3 errors

BUILD FAILED
file:D:/Instructor/Projects/jakarta-tomcat-catalina/catalina/build.xml:801: 
Comp
ile failed; see the compiler error output for details.

I checked out digester 1.3 and 1.2 and there does not seem to be a method 
setEntityResolver.  Or am I missing something?

Christian Gross


At 14:18 02/10/2002 -0400, you wrote:

>On Wednesday 02 October 2002 09:38 am, Christian Gross wrote:
> > Hi
> >
> > So I worked myself through the various CVS sources and have a couple of
> > "official" position questions to ask.
> >
> > The CVS projects jakarta-tomcat-catalina and jakarta-tomcat-jasper, will be
> > forming the Tomcat 5 work?
>
>jakarta-servletapi-5, jakarta-tomcat-5, jakarta-tomcat-catalina,
>jakarta-tomcat-connectors, jakarta-tomcat-jasper, and jakarta-watchdog-4.0
>are the CVS repositories involved in Tomcat 5.0
>
> >
> > The CVS project jakarta-tomcat-4.0 is the 4.x branch?
> >
>Yes
>
> > The CVS project jakarta-tomcat is anything before 4.0
> >
>Tomcat 3.x, at least.
>
> > The CVS project jakarta-tomcat-5.0 does nothing??
> >
>It's the master project for the whole Tomcat 5.0 project. To use it, start
>with a directory like tc5-workspace. In that directory:
>export CVSROOT=:pserver:[EMAIL PROTECTED]:/home/cvspublic
>cvs co jakarta-servletapi-5
>cvs co jakarta-tomcat-5
>cvs co jakarta-tomcat-catalina
>cvs co jakarta-tomcat-connectors
>cvs co jakarta-tomcat-jasper
>
>then, in jakarta-tomcat-5 create a build.properties file with the following
>definition
>base.path = /home/sdowney/tc5-workspace/depends
>(replace /home/sdowney/tc5-workspace with path to your workspace. I don't 
>know
>if relative will work. I stopped dinking when I got my build system to
>function)
>
>You need ant 1.5 to build Tomcat 5
>
>export ANT_HOME=/home/sdowney/tools/jakarta-ant-1.5
>
>PATH=$PATH:$ANT_HOME/bin
>
>ant download
>
>The download target in Tomcat 5 gets the necessary ancillary libraries to
>build the system. I'm using JDK 1.4, which has a few things built in. You may
>need to install some things in JDK 1.3, like JCE. I'm not sure.
>
>Then:
>
>ant build
>ant test
>[Not many tests at the moment]
>If you're contributing, you may also want to do
>
>ant -Dfull.dist=on build
>
>That will force a full compile, rather than checking which optional 
>components
>are available and setting things on or off based on the presense or absense
>of classes. That useful for building a customized version, but for testing
>purposes, a full build is better.
>
>To run the watchdog conformance test suite:
>
>ant watchdog
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 

Christian Gross
Software Engineering Consultant
http://www.devspace.com
North America: 1-450-675-4208
Europe +41.1.701.1166


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

DO NOT REPLY [Bug 13226] New: - Can't access files with international characters

[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=13226

Can't access files with international characters

   Summary: Can't access files with international characters
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Using Tomcat 4.0.4 (installed from the RPMs now in the Jakarta archives), if 
Tomcat is serving a file that has international characters in the filename and 
a user requests that file, Tomcat misinterprets the filename. As a result, it 
gives an error, "The requested resource is not available."

For example, accessing "http://localhost/Björk"; yields the error, "The 
requested resource (/Björk/) is not available."

The expected result is to process the international characters in the filename 
correctly, and serve the file.

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

DO NOT REPLY [Bug 13223] New: - JSP pages in XML syntax do not compile properly

[bugzilla]

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

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

JSP pages in XML syntax do not compile properly

   Summary: JSP pages in XML syntax do not compile properly
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When using the XML syntax for JSP pages, compile errors are thrown whenever an 
XML-syntax JSP tag is used to apply an attribute value as in this JSP page:

This JSP fails:

http://java.sun.com/JSP/Page";
  version="1.2">


java.text.Annotation recordDetails = new java.text.Annotation("This is a test 
value");
pageContext.setAttribute("recordDetails", recordDetails, 
PageContext.PAGE_SCOPE);



  System.getProperty("java.io.tmpdir")



  

  Case ID:
  

  






This JSP works:

http://java.sun.com/JSP/Page";
  version="1.2">


java.text.Annotation recordDetails = new java.text.Annotation("This is a test 
value");
pageContext.setAttribute("recordDetails", recordDetails, 
PageContext.PAGE_SCOPE);



  System.getProperty("java.io.tmpdir")



  

  Case ID:
  

  





This JSP also fails:

http://java.sun.com/JSP/Page";
  version="1.2">


java.text.Annotation recordDetails = new java.text.Annotation("This is a test 
value");
pageContext.setAttribute("recordDetails", recordDetails, 
PageContext.PAGE_SCOPE);



  System.getProperty("java.io.tmpdir")



  

  Case ID:
  

  




Several additional variations on the above themes also fail.
The spec appears to support the first JSP example.  On the chance that I might 
have misread the spec, I also tried it without the < and />, this variation 
also fails.
It may be worth noting that this exact same example JSP works, as long as the 
jsp:root tag is removed and the page, scriptlet, and expression tags are 
replaced with their non-XML equivalents as follows:
<%@page language="java" import="java.text.*" session="false" 
isThreadSafe="true" isErrorPage="false" %>
<%
java.text.Annotation recordDetails = new java.text.Annotation("This is a test 
value");
pageContext.setAttribute("recordDetails", recordDetails, 
PageContext.PAGE_SCOPE);
%>


  <%=System.getProperty("java.io.tmpdir")%>


  

  Case ID:
  

  



In summary, it appears that the XML syntax is not supported in attribute value 
assignment.

The exception thrown is as follows (Note the problem in property lookup, this 
may be another, unrelated, bug).

type Exception report

message 

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

exception 

org.apache.jasper.JasperException: Unable to compile class for JSP
at org.apache.jasper.JspCompilationContext.compile
(JspCompilationContext.java:479)
at org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:184)
at org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:289)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240)
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:260)
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.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke
(Sta

RE: Little refactoring in o.a.t.u.net

[Ignacio J. Ortega]

here it is, only the net package zipped.. one point to look at, I've
converted the CipherData class in a inner one with public data.. all
other is merely renaming packages and moving files.. 

Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> De: Jean-Francois Arcand [mailto:[EMAIL PROTECTED]]
> Enviado el: 2 de octubre de 2002 22:57
> Para: Tomcat Developers List
> Asunto: Re: Little refactoring in o.a.t.u.net
> 
> 
> Tar the code and post it here...so we can look and enjoy :-)
> 
> -- Jeanfrancois
> 
> Ignacio J. Ortega wrote:
> 
> >I have in my workspace working a litle refactoring of the o.a.t.u.net
> >package translating the JSSE* classes to his own package ( named of
> >course jsse) and the same for PureTLs* ones ( with a package name of
> >ptls), i have the tc4.1.X & tc5 versions working, and i can 
> put the tc33
> >and others working too, althought I only need this to be able to use
> >RefactorIt.. :)) 
> >
> >( the real reason is that the only way to make RefactorIt to exclude
> >some 
> >package is for complete packages not single files ) 
> >
> >I know this is very sensitive code used by many other 
> packages parts, i
> >can live with the change in my workspace without problems.,. 
> but maybe
> >this is useful for anyone more.. 
> >
> >Comments?
> >
> >Saludos ,
> >Ignacio J. Ortega
> >
> >--
> >To unsubscribe, e-mail:   
> 
> >For additional commands, e-mail: 
> 
> >
> >
> >  
> >
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 
> 



Net.zip
Description: Binary data

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

Re: Little refactoring in o.a.t.u.net

[Bill Barker]

- Original Message -
From: "Ignacio J. Ortega" <[EMAIL PROTECTED]>
To: "'tomcat-dev'" <[EMAIL PROTECTED]>
Sent: Wednesday, October 02, 2002 1:51 PM
Subject: Little refactoring in o.a.t.u.net


> I have in my workspace working a litle refactoring of the o.a.t.u.net
> package translating the JSSE* classes to his own package ( named of
> course jsse) and the same for PureTLs* ones ( with a package name of
> ptls), i have the tc4.1.X & tc5 versions working, and i can put the tc33
> and others working too, althought I only need this to be able to use
> RefactorIt.. :))
>
> ( the real reason is that the only way to make RefactorIt to exclude
> some
> package is for complete packages not single files )
>
> I know this is very sensitive code used by many other packages parts, i
> can live with the change in my workspace without problems.,. but maybe
> this is useful for anyone more..
>
> Comments?

+1 It's a little messy in o.a.t.u.net.  Nobody should be be accessing the
JSSE* & PureTLS* classes directly, so moving them shouldn't cause any
problems (and if it does, then it's a bug ;).

Just remember to change the class names in SSLImplementation.

>
> Saludos ,
> Ignacio J. Ortega
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

Re: Little refactoring in o.a.t.u.net

[Jean-Francois Arcand]

Tar the code and post it here...so we can look and enjoy :-)

-- Jeanfrancois

Ignacio J. Ortega wrote:

>I have in my workspace working a litle refactoring of the o.a.t.u.net
>package translating the JSSE* classes to his own package ( named of
>course jsse) and the same for PureTLs* ones ( with a package name of
>ptls), i have the tc4.1.X & tc5 versions working, and i can put the tc33
>and others working too, althought I only need this to be able to use
>RefactorIt.. :)) 
>
>( the real reason is that the only way to make RefactorIt to exclude
>some 
>package is for complete packages not single files ) 
>
>I know this is very sensitive code used by many other packages parts, i
>can live with the change in my workspace without problems.,. but maybe
>this is useful for anyone more.. 
>
>Comments?
>
>Saludos ,
>Ignacio J. Ortega
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>  
>


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

Little refactoring in o.a.t.u.net

[Ignacio J. Ortega]

I have in my workspace working a litle refactoring of the o.a.t.u.net
package translating the JSSE* classes to his own package ( named of
course jsse) and the same for PureTLs* ones ( with a package name of
ptls), i have the tc4.1.X & tc5 versions working, and i can put the tc33
and others working too, althought I only need this to be able to use
RefactorIt.. :)) 

( the real reason is that the only way to make RefactorIt to exclude
some 
package is for complete packages not single files ) 

I know this is very sensitive code used by many other packages parts, i
can live with the change in my workspace without problems.,. but maybe
this is useful for anyone more.. 

Comments?

Saludos ,
Ignacio J. Ortega

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

DO NOT REPLY [Bug 13221] New: - JDBC DataSource "driverClassName is required" error

[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=13221

JDBC DataSource "driverClassName is required" error

   Summary: JDBC DataSource "driverClassName is required" error
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I'm getting the following error when I try and obtain a DataSource reference 
via the Initial Context:

javax.naming.NamingException: DbcpDataSourceFactory: driverClassName is 
required at org.apache.naming.factory.DbcpDataSourceFactory.getObjectInstance
(Unknown Source) at org.apache.naming.factory.ResourceFactory.getObjectInstance
(Unknown Source) at javax.naming.spi.NamingManager.getObjectInstance
(NamingManager.java:299) at org.apache.naming.NamingContext.lookup(Unknown 
Source) at org.apache.naming.NamingContext.lookup(Unknown Source) at 
org.apache.naming.NamingContext.lookup(Unknown Source) at 
org.apache.naming.NamingContext.lookup(Unknown Source) at 
org.apache.naming.NamingContext.lookup(Unknown Source) at 
org.apache.naming.NamingContext.lookup(Unknown Source) at 
org.apache.naming.NamingContext.lookup(Unknown Source) at 
org.apache.naming.NamingContext.lookup(Unknown Source) at 
org.apache.naming.SelectorContext.lookup(Unknown Source) at 
javax.naming.InitialContext.lookup(InitialContext.java:345) at 
tutorial.HelloServlet.service(HelloServlet.java:53) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown 
Source) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown 
Source) at org.apache.catalina.core.StandardWrapperValve.invoke(Unknown Source) 
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(Unknown Source) at org.apache.catalina.core.StandardPipeline.invoke(Unknown 
Source) at org.apache.catalina.core.ContainerBase.invoke(Unknown Source) at 
org.apache.catalina.core.StandardContextValve.invoke(Unknown Source) at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(Unknown Source) at org.apache.catalina.core.StandardPipeline.invoke(Unknown 
Source) at org.apache.catalina.core.ContainerBase.invoke(Unknown Source) at 
org.apache.catalina.core.StandardContext.invoke(Unknown Source) at 
org.apache.catalina.core.StandardHostValve.invoke(Unknown Source) at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(Unknown Source) at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(Unknown Source) at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(Unknown Source) at org.apache.catalina.valves.ErrorReportValve.invoke(Unknown 
Source) at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(Unknown Source) at org.apache.catalina.core.StandardPipeline.invoke(Unknown 
Source) at org.apache.catalina.core.ContainerBase.invoke(Unknown Source) at 
org.apache.catalina.core.StandardEngineValve.invoke(Unknown Source) at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(Unknown Source) at org.apache.catalina.core.StandardPipeline.invoke(Unknown 
Source) at org.apache.catalina.core.ContainerBase.invoke(Unknown Source) at 
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:405) at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnectio
n(Http11Protocol.java:358) at org.apache.tomcat.util.net.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:495) at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:518) at java.lang.Thread.run(Thread.java:479) 

The datasource appears to register correctly when the server starts:

DbcpDataSourceFactory:  driverClassName=com.merant.datadirect.jdbc.sqlserver.SQL
ServerDriver, url=jdbc:merant:sqlserver:tbftradesdb@mydb:1433, user=dbo

Here is the server.xml snippet:


-   

user 
dbo 


password 
duff 


driverClassName 

com.merant.datadirect.jdbc.sqlserver.SQLServerDriver


driverName
   

DO NOT REPLY [Bug 12750] - Virtual hosts using Apache 2.0.40, Tomcat 4.1.10 and mod_jk2

[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=12750

Virtual hosts using Apache 2.0.40, Tomcat 4.1.10 and mod_jk2





--- Additional Comments From [EMAIL PROTECTED]  2002-10-02 20:30 ---
Can you attach the config files used ( workers2.properties, server.xml ) ?
Also - check the log/ directory for messages - it should have something...

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

DO NOT REPLY [Bug 8107] - uninstall mod_jk2-2.0 rpm not possible

[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=8107

uninstall mod_jk2-2.0 rpm not possible

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Connector:Coyote JK 2   |Installable Packages



--- Additional Comments From [EMAIL PROTECTED]  2002-10-02 20:27 ---
Henri ?

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

DO NOT REPLY [Bug 9936] - http tunnel could not work with mod_jk

[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=9936

http tunnel could not work with mod_jk





--- Additional Comments From [EMAIL PROTECTED]  2002-10-02 20:24 ---
Can you reproduce this without using a plugin ( ie. a small java client
or use ant tasks to upload/send data ) ??

Most likely it's an issue with the body ( does it have Content-Length ?). You 
can enable debugging in several places in jk - to see what is sent. ( or use
etherreal ! )

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

DO NOT REPLY [Bug 12946] - parameter serverRoot from jk2.properties not read; workaround

[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=12946

parameter serverRoot from jk2.properties not read; workaround





--- Additional Comments From [EMAIL PROTECTED]  2002-10-02 20:15 ---
I'm confused: the output is from the native side jk, which is configured using
workers2.properties. Are you using in-process jk ? Can you give more info
about the env and a full log file ?

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

Re: [patch] JNDIRealm and SSL

[Fredrik Westermarck]

Fredrik Westermarck wrote:
> Hi!
> 
> I have added the possibility to use SSL with the JNDIRealm in the file 
> JNDIRealm.java.diff.

So how about this patch? Anyone that want to commit it, or else comment 
on how it could be done in a better way?




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

DO NOT REPLY [Bug 4371] - No responses on browsing root when using WarpConnector

[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=4371

No responses on browsing root when using WarpConnector

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Connector:Other |Connector:Webapp

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

DO NOT REPLY [Bug 5877] - Facade of facade.

[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=5877

Facade of facade.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-10-02 18:57 ---
That doesn't seem like a connector problem. AFAIK the facade is needed for 
security ( to prevent code holding references when recycling ). I never
seen 2 facades and user code shouldn't get access to the real object in any
case ! If it can - that's a serious security issue, please reopen the bug
( in the right category )

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

3798: service monitor for jk_nt_service

[Costin Manolache]

Can someone with windows experience check the attachment and 
decide what to do ? 

It seems like usefull and good, but I don't know what is the
benefit over just using 'net start' or the default service
manager.

-- 
Costin



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

DO NOT REPLY [Bug 471] - Problem using jk_nt_service (with a blank space in tomcat_home directory path) BugRat Report#797

[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=471

Problem using jk_nt_service (with a blank space in tomcat_home directory path) BugRat 
Report#797

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED



--- Additional Comments From [EMAIL PROTECTED]  2002-10-02 18:37 ---
This has been fixed.

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

Re: Need some clarifications

[Steve Downey]

On Wednesday 02 October 2002 09:38 am, Christian Gross wrote:
> Hi
>
> So I worked myself through the various CVS sources and have a couple of
> "official" position questions to ask.
>
> The CVS projects jakarta-tomcat-catalina and jakarta-tomcat-jasper, will be
> forming the Tomcat 5 work?

jakarta-servletapi-5, jakarta-tomcat-5, jakarta-tomcat-catalina, 
jakarta-tomcat-connectors, jakarta-tomcat-jasper, and jakarta-watchdog-4.0 
are the CVS repositories involved in Tomcat 5.0

>
> The CVS project jakarta-tomcat-4.0 is the 4.x branch?
>
Yes

> The CVS project jakarta-tomcat is anything before 4.0
>
Tomcat 3.x, at least. 

> The CVS project jakarta-tomcat-5.0 does nothing??
>
It's the master project for the whole Tomcat 5.0 project. To use it, start 
with a directory like tc5-workspace. In that directory:
export CVSROOT=:pserver:[EMAIL PROTECTED]:/home/cvspublic
cvs co jakarta-servletapi-5 
cvs co jakarta-tomcat-5 
cvs co jakarta-tomcat-catalina 
cvs co jakarta-tomcat-connectors 
cvs co jakarta-tomcat-jasper

then, in jakarta-tomcat-5 create a build.properties file with the following 
definition
base.path = /home/sdowney/tc5-workspace/depends
(replace /home/sdowney/tc5-workspace with path to your workspace. I don't know 
if relative will work. I stopped dinking when I got my build system to 
function)

You need ant 1.5 to build Tomcat 5

export ANT_HOME=/home/sdowney/tools/jakarta-ant-1.5

PATH=$PATH:$ANT_HOME/bin

ant download

The download target in Tomcat 5 gets the necessary ancillary libraries to 
build the system. I'm using JDK 1.4, which has a few things built in. You may 
need to install some things in JDK 1.3, like JCE. I'm not sure.

Then:

ant build
ant test
[Not many tests at the moment]
If you're contributing, you may also want to do

ant -Dfull.dist=on build

That will force a full compile, rather than checking which optional components 
are available and setting things on or off based on the presense or absense 
of classes. That useful for building a customized version, but for testing 
purposes, a full build is better.

To run the watchdog conformance test suite:

ant watchdog



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

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

[Mladen Turk]

> -Original Message-
> > 
> > Sure, like everyone else ;).
> 
> Yes, I know :-)
> 
> I'll try to get over the horrible and nonstandard DTD that we 
> use and start documenting what I can still remember, and 
> anything new that I add. And I won't write any new jk code 
> until I finish at least reviewing all the bugs ( 80 ? )
>  

Roger to that.

MT.


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

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

[Costin Manolache]

Mladen Turk wrote:

> 
> 
>> -Original Message-
>> On Behalf Of Costin Manolache
>> 
>> Are we documenting all those settings - and the details on
>> why/how :-) ?
>> 
>> 
> 
> Sure, like everyone else ;).

Yes, I know :-)

I'll try to get over the horrible and nonstandard DTD that we 
use and start documenting what I can still remember, and anything new
that I add. And I won't write any new jk code until I finish at least
reviewing all the bugs ( 80 ? )
 
-- 
Costin



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

RE: Tagging JK2_2_0_1?

[Ignacio J. Ortega]

> De: Mladen Turk [mailto:[EMAIL PROTECTED]]
> Enviado el: 2 de octubre de 2002 18:11

Well, in theory, the release is only labeled as "alpha,beta,stable,GA"
or whatever, after the tagging and the relase itself ( stagging in a
test place not the official builds one ) , asking for a vote about the
label should be for the release..

SO tag it, release it to test stagging area, and call for a vote some
days later about wich sis the label the relase will have..

No doubt we will end having a buch 2.0.X relase, until everything is
finished.. docs.. and so on..

Saludos ,
Ignacio J. Ortega

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

DO NOT REPLY [Bug 11657] - AJP13 Connector redirect does not work

[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=11657

AJP13 Connector redirect does not work

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|REMIND  |



--- Additional Comments From [EMAIL PROTECTED]  2002-10-02 17:24 ---
Actually, you're right - for jdk1.3+ it should work. I'll add code to
initialize it for ajp ( if not already set ). Probably next release
will have it.

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

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

[Mladen Turk]

> -Original Message-
> On Behalf Of Costin Manolache
> 
> Are we documenting all those settings - and the details on 
> why/how :-) ?
> 
> 

Sure, like everyone else ;).

MT.


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

Re: Need some clarifications

[Bob Herrmann]

On Wed, 2002-10-02 at 09:38, Christian Gross wrote:
> Hi
> 
> So I worked myself through the various CVS sources and have a couple of 
> "official" position questions to ask.
> 
> The CVS projects jakarta-tomcat-catalina and jakarta-tomcat-jasper, will be 
> forming the Tomcat 5 work?

Yup.

> The CVS project jakarta-tomcat-4.0 is the 4.x branch?

yes.  I think the 4.0 is tagged in there, but the HEAD is 4.1

> The CVS project jakarta-tomcat is anything before 4.0

yup.

> The CVS project jakarta-tomcat-5.0 does nothing??

It is "jakarta-tomcat-5", not "5.0" and it is used to pull together the
other bits to make Tomcat5.

If you want to build  TC5, just use the attached build.xml and type
"ant"

Cheers,
-bob


> 
> Thanks, for any help
> 
> 
> Christian Gross
> Software Engineering Consultant
> http://www.devspace.com
> North America: 1-450-675-4208
> Europe +41.1.701.1166
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
-- 
Bob Herrmann <[EMAIL PROTECTED]>


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

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

[Costin Manolache]

Are we documenting all those settings - and the details on why/how :-) ?


Mladen Turk wrote:

> 
> It is disabled by default and never checked (if you don't set the
> timeout=x inside the [lb]).
> 
>  
>> I there any way to disable completely that timeout?
>> 
>> Perhaps setting it to -1 or something like that?
>> 
>> This timeout disabled should be the default config..
>>

-- 
Costin



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

RE: [VOTE] [5.0] Milestones

[Kevin Jones]

Not a vote, just wondered when we can expect to see the milestone builds
appearing?

Kevin Jones
Developmentor
www.develop.com

> -Original Message-
> From: Larry Isaacs [mailto:[EMAIL PROTECTED]] 
> Sent: 30 September 2002 20:14
> To: Tomcat Developers List
> Subject: RE: [VOTE] [5.0] Milestones 
> 
> 
> 
> 
> > -Original Message-
> > From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, September 28, 2002 10:12 AM
> > To: Tomcat Developers List
> > Subject: [VOTE] [5.0] Milestones 
> > 
> > 
> > Hi,
> > 
> > Now that the first stable releases of Tomcat 4.1 are out (and
> > according 
> > to reports, of good overall quality), it could be appropriate 
> > to start 
> > releasing 5.0.x milestones.
> > It should be pointed out that 5.0.x is still far from being feature 
> > complete (esp the configuration code needs to be unified if 
> possible, 
> > and some optimizations are needed), so the milestones should be 
> > considered alpha or pre alpha until further notice.
> > 
> > 
> > [X] +1 Yes, start releasing milestones
> > [ ] -1 No, because:
> > 
> > 
> > 
> > 
> > Remy
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> >  [EMAIL PROTECTED]>
> > For
> > additional commands, 
> > e-mail: 
> > 
> > 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 


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

Re: Strange problem with tomcat 4.1.2

[Han Ming Ong]

Definitely a problem with an extra '--' in your XML comments. The only  
place that '--' is allowed is at the beginning and at the end:



Han Ming

On Wednesday, October 2, 2002, at 04:32  AM, Henri Gomez wrote:

> While working on 4.1.2 rpms I noticed the following error at startup :
>
> 4732 [main] INFO modeler.Registry  - Creating MBeanServer
> 5705 [main] INFO http11.Http11Protocol  - Initializing Coyote HTTP/1.1  
> on port 8080
> Starting service Tomcat-Standalone
> Apache Tomcat/4.1
> 7324 [main] ERROR digester.Digester  - Parse Fatal Error at line 307  
> column 39: The string "--" is not permitted within comments.
> org.xml.sax.SAXParseException: The string "--" is not permitted within  
> comments.
>   at  
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unkn 
> own Source)
>   at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown  
> Source)
>   at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
>   at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
>   at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source)
>   at org.apache.xerces.impl.XMLScanner.scanComment(Unknown Source)
>   at org.apache.xerces.impl.XMLDTDScannerImpl.scanComment(Unknown  
> Source)
>   at org.apache.xerces.impl.XMLDTDScannerImpl.scanDecls(Unknown Source)
>   at  
> org.apache.xerces.impl.XMLDTDScannerImpl.scanDTDExternalSubset(Unknown  
> Source)
>   at  
> org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(Un 
> known Source)
>   at  
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unkn 
> own Source)
>   at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
>   at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
>   at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
>   at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
>   at org.apache.commons.digester.Digester.parse(Digester.java:1514)
>   at  
> org.apache.catalina.startup.ContextConfig.tldScanStream(ContextConfig.j 
> ava:977)
>   at  
> org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.java 
> :1006)
>   at  
> org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:87 
> 0)
>   at  
> org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647)
>   at  
> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig. 
> java:243)
>   at  
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleS 
> upport.java:166)
>   at  
> org.apache.catalina.core.StandardContext.start(StandardContext.java:349 
> 3)
>   at  
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
>   at org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
>   at  
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
>   at  
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
>   at  
> org.apache.catalina.core.StandardService.start(StandardService.java:497 
> )
>   at  
> org.apache.catalina.core.StandardServer.start(StandardServer.java:2189)
>   at org.apache.catalina.startup.Catalina.start(Catalina.java:510)
>   at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
>   at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
>   at java.lang.reflect.Method.invoke(Native Method)
>   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
> 8720 [main] ERROR digester.Digester  - Parse Fatal Error at line 307  
> column 39: The string "--" is not permitted within comments.
> org.xml.sax.SAXParseException: The string "--" is not permitted within  
> comments.
>   at  
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unkn 
> own Source)
>   at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown  
> Source)
>
>
>
> Admin log show me the following error :
>
> 2002-10-02 13:29:01 WebappLoader[/admin]: Deploying class repositories  
> to work directory /var/tomcat4/work/Standalone/localhost/admin
> 2002-10-02 13:29:01 WebappLoader[/admin]: Deploy class files  
> /WEB-INF/classes to  
> /var/tomcat4/webapps/../server/webapps/admin/WEB-INF/classes
> 2002-10-02 13:29:01 WebappLoader[/admin]: Deploy JAR  
> /WEB-INF/lib/struts.jar to  
> /var/tomcat4/webapps/../server/webapps/admin/WEB-INF/lib/struts.jar
> 2002-10-02 13:29:02 ContextConfig[/admin] Exception processing TLD at  
> resource path /WEB-INF/controls.tld
> javax.servlet.ServletException: Exception processing TLD at resource  
> path /WEB-INF/controls.tld
> at  
> org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.java 
> :1010)
> at  
> org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:87 
> 0)
> at  
> org.apache.catalina.startup.ContextConfig.start(ContextConfig.java

[Patch] Make mod_jk2 send REDIRECT_* headers for ErrorDocument usage

[Tom Palmer]

Hi,

  The attached patch for mod_jk2 (apache 1.3 and apache 2.0) sends a
REDIRECT_URL and a REDIRECT_QUERYSTRING header if the request inside apache
is redirected (e.g. through the use of the ErrorDocument directive). This
follows the environment variables detailed in
http://httpd.apache.org/docs-2.0/custom-error.html.

  Currently if a jsp/servlet is used within an ErrorDocument directive it
has no knowledge of the original request.

  Regards,

  Tom

  Tom Palmer 
  Web Systems Developer 
  WorldCom 
  332 Science Park, Cambridge, CB4 0BZ, UK 
  Tel: +44 (0)1223 250246
 




jk2.errordocument.patch
Description: Binary data

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

DO NOT REPLY [Bug 13212] New: - JSPC is unable to compile when JSP1.1 taglib jar contains tld file

[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=13212

JSPC is unable to compile when JSP1.1 taglib jar contains tld file

   Summary: JSPC is unable to compile when JSP1.1 taglib jar
contains tld file
   Product: Tomcat 4
   Version: 4.1.12
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I can reproduce this every consistently. The bug appears when JSP 1.1 tag jar 
file contains meta-inf/*.tld file.

instructions for reproducing the bug.

1. create a simple page that uses jakarta string taglib
2. run jspc

Result: NPE should be thrown and page should not compile.

work around.

1. delete the .tld file from string.jar
2. run jspc

It would appear there's a conflict between the .tld file under 
myWebApp/WEB-INF/string.tld and meta-inf/taglib.tld in the jar.

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

Tagging JK2_2_0_1?

[Mladen Turk]

There has been some major fixes inside the uriMap, uriEnv, apr_socket
and lb that makes the 2_0_0 IMO unusable, and personally I'm ashamed as
a RM that this was a release after all :(.

Since we tagged and released JK2 as beta, seems to me that we could
easily do the same for the 2.0.1, and just pretend that 2.0.0 ewer
existed :)

The question is are we going to wait for a Apache1.3/APR/JNI builds or
just go without that. But before going to the 2_0_1 (What doesn't kill
you makes you stronger ;) could you guys do the testing against current
CVS for all the discussed items.

MT.


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

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

[Mladen Turk]

It is disabled by default and never checked (if you don't set the
timeout=x inside the [lb]).

 
> I there any way to disable completely that timeout?
> 
> Perhaps setting it to -1 or something like that?
> 
> This timeout disabled should be the default config.. 
> 


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

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

[Ignacio J. Ortega]

> De: Mladen Turk [mailto:[EMAIL PROTECTED]]
> Enviado el: 2 de octubre de 2002 17:50

I there any way to disable completely that timeout?

Perhaps setting it to -1 or something like that?

This timeout disabled should be the default config.. 

Saludos ,
Ignacio J. Ortega

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

DO NOT REPLY [Bug 11657] - AJP13 Connector redirect does not work

[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=11657

AJP13 Connector redirect does not work

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||REMIND



--- Additional Comments From [EMAIL PROTECTED]  2002-10-02 16:01 ---
I assume you are talking about a HTTPS site and a redirect. 

One problem is that we can't be sure that sun's jars are used. Some people
use Apache+SSL and tomcat without SSL. 

We need to find a better solution for that. Can you send a stack trace ?

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

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

[Mladen Turk]

> -Original Message-
> From: [EMAIL PROTECTED]
 
>   Modified:jk/native2/common jk_worker_lb.c
>   Log:
>   Introduced 3 new configuration parameters to the lb.
>   1. attempts -- replaces harcoded MAX_ATTEMPTS
>   2. recovery -- replaces hardcoded WAIT_BEFORE_RECOVER
>   3. timeout -- this one is new.
>   The timeout if set will force the lb to cycle through 
> workers if all are in the
>   error_state for the specified amount of seconds. This is usefull for
>   situations when the TC is overloaded and refuses new connections.
>   The lb will wait and after timeout will report 500 to the client.
>   

Some more clarification:

The reason for introducing timeout inside lb is from my point of view
and the applications I'm using jk2 for, fact that even using most
powerful system, there will be situations that returns 500 to the client
simply because the TC is to busy and refuses new connections. One way to
solve that is to force the TC to allow more connections eating system
resources, and the other is using lb timeout.

One drawback of using timeout is the fact that the client will get
delayed response even for the non-existent configured TC instance.
I've made such behavior at first inside the socket connector, but Nacho
(he was right) made a strong objection to that. So instead trying to
connect to the instance from connector point of view, all that is put
inside the load balancer.


MT. 


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

isapi_redirect.dll file

[Ashley Huang Wanyi]

Hello,

Can you email me this file isapi_redirect.dll , as i couldn't find it.
Thank You.

Regards,

Ashley 

Problem with Tomcat 4

[SADASIVA,SHRAVAN (HP-India,ex3)]

Hi,
    I am getting 
the following exception off the JSP engine in my tomcat 4.0 when I try to 
execute a class file off my linux box. The details are as given 
below.
 
java.lang.NoClassDefFoundError: 
sun/io/MalformedInputException    at 
sun.tools.java.Scanner.(Scanner.java:144)    
at 
sun.tools.java.Parser.(Parser.java:52)    
at 
sun.tools.javac.BatchParser.(BatchParser.java:54)    
at 
sun.tools.javac.BatchEnvironment.parseFile(BatchEnvironment.java:453)    
at 
sun.tools.javac.Main.compile(Main.java:486)    
at 
org.apache.jasper.compiler.SunJavaCompiler.compile(SunJavaCompiler.java:158)    
at 
org.apache.jasper.compiler.Compiler.compile(Compiler.java:273)    
at 
org.apache.jasper.servlet.JspServlet.doLoadJSP(JspServlet.java:612)    
at 
org.apache.jasper.servlet.JasperLoader12$1.run(JasperLoader12.java:160)    
at 
java.security.AccessController.doPrivileged(AccessController.java:37)    
at 
org.apache.jasper.servlet.JasperLoader12.loadJSP(JasperLoader12.java:156)    
at 
org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:542)    
at 
org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary(JspServlet.java:258)    
at 
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:268)    
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:429)    
at 
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:500)    
at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)    
at 
org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405)    
at 
org.apache.tomcat.core.Handler.service(Handler.java:287)    
at 
org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)    
at 
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:806)    
at 
org.apache.tomcat.core.ContextManager.service(ContextManager.java:752)    
at 
org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:213)    
at 
org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)    
at 
org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501)    
at java.lang.Thread.run(Thread.java:325)Warning: Major version number 
mismatch.Warning: Minor version number mismatch.2002-10-02 17:25:59 - 
Ctx( /gap ): JasperException: R( /gap + /Holidays.jsp + null) Unable to compile 
class for JSPNote: sun.tools.javac.Main has been deprecated.error: An error 
has occurred in the compiler; please file a bug report (http://java.sun.com/cgi-bin/bugreport.cgi).1 
error, 1 warning
Please 
Help..
 
Regards Shravan Sadasivan 

 

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

FW: Software caused connection abort

[Jindong Li]

This might be the right place for this post?

 -Original Message-
From:   Jindong Li  
Sent:   Wednesday, October 02, 2002 10:15 AM
To: '[EMAIL PROTECTED]'
Subject:Software caused connection abort

Hi there,

I'm trying out tomcat4.1.12 and noticed that I'm getting exception rather
frequently when loading pages, although it doesn't appear to affect the way
webserver works - the pages still load properly ...

Environment: Windows 2000, Tomcat 4.1.12 standalone, JDK 1.4.0 .

Here's the exception:

2002-10-02 10:11:40 StandardWrapperValve[default]: Servlet.service() for
servlet default threw exception
java.net.SocketException: Software caused connection abort: socket write
error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at
java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:126)
at
org.apache.coyote.http11.InternalOutputBuffer$OutputStreamOutputBuffer.doWri
te(InternalOutputBuffer.java:652)
at
org.apache.coyote.http11.filters.IdentityOutputFilter.doWrite(IdentityOutput
Filter.java:160)
at
org.apache.coyote.http11.InternalOutputBuffer.doWrite(InternalOutputBuffer.j
ava:523)
at org.apache.coyote.Response.doWrite(Response.java:513)
at
org.apache.coyote.tomcat4.OutputBuffer.realWriteBytes(OutputBuffer.java:380)
at
org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:360)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:338)
at
org.apache.coyote.tomcat4.OutputBuffer.writeBytes(OutputBuffer.java:407)
at
org.apache.coyote.tomcat4.OutputBuffer.write(OutputBuffer.java:394)
at
org.apache.coyote.tomcat4.CoyoteOutputStream.write(CoyoteOutputStream.java:1
10)
at
org.apache.catalina.servlets.DefaultServlet.copyRange(DefaultServlet.java:19
96)
at
org.apache.catalina.servlets.DefaultServlet.copy(DefaultServlet.java:1745)
at
org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.jav
a:1073)
at
org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:506)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
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.access$000(ApplicationFilter
Chain.java:98)
at
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain
.java:176)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:172)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:260)
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:2396)
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:170)
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.coyote.http11.Http11Processor.process(Http11P

Re: [Possible bug with jspc]

[peter lin]

Here is a bit more information. I took a look at the jar files for jsp
1.1 tags and they include a taglib.tld file in meta-inf/.  Once I remove
that, it compiles the pages fine.  It looks like there's a conflict in
either jasper compiler or jspc that is unable to resolve which .tld file
to use.

peter lin wrote:
> 
> I spent the last two days trying to use JspC to compile an entire webapp
> and came across a problem. I'm not sure if this is a bug or not, but I
> can reproduce it every time.  I'm still trying to track down the cause,
> but I thought I'd post a question and maybe some one with more knowledge
> can point me in the right direction.
> 
> I am using the following command to run jspc
> 
> C:\tomcat\bin>jspc -d ..\work\Standalone\localhost\_ -uribase
> c:/myapp/web -webapp c:/myapp/web
> 
> in one of included files I define all the taglibs i use. right now I am
> using taglibs from the Jakarta. If I use the string tag, it causes JspC
> to die with NPE. If I remove the <%@ taglib %> for string tag, jspc
> works fine.  the main difference between JSTL and string tag is JSTL is
> 1.2 and string tag is 1.1.
> 
> the page works just fine if I load it in the browser, but for some
> reason, JspC doesn't like 1.1 taglibs.
> 
> can anyone provide any insight?
> 
> peter lin
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

Re: Tomcat 4.1.12 and Servlet Access 404 Errors: BUG? One Last Assurance

[Craig R. McClanahan]

On Wed, 2 Oct 2002, micael wrote:

> Date: Wed, 02 Oct 2002 00:12:20 -0700
> From: micael <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: Tomcat 4.1.12 and Servlet Access 404 Errors: BUG? One Last
> Assurance
>
> So I can understand, where is the difference in the code between Tomcat
> 4.1.10 and 4.1.12?  And, do you mean that servlet mappings rather than
> being generic to some "servlet/*" path be individualized?
>

Let's assume that you have two servlets that are currently accessed via
the following URLs:

  http://localhost:8080/myapp/servlet/com.mypackage.MyFooServlet
  http://localhost:8080/myapp/servlet/com.mypackage.MyBarServlet

that no longer work in 4.1.12.  To avoid changing all your URLs, you have
two basic choices:

(1) Re-enable the invoker servlet by uncommenting the
"/servlet/*" mapping in $CATALINA_HOME/conf/web.xml
(non-portable, might be open to future vulnerabilities)

(2) Explicitly add servlet definitions and mappings for
these two servlets:




Foo
com.mypackage.MyFooServlet



Bar
com.mypackage.MyBarServlet



Foo
/servlet/com.mypackage.MyFooServlet



Bar
/servlet/com.mypackage.MyBarServlet




The latter choice will selectively re-enable only the servlet mappings
that you actually need.  This is also guaranteed to be portable across
servlet containers, whereas the "invoker" servlet is just a Tomcat
feature.

Craig


> At 12:26 PM 10/2/2002 +1000, you wrote:
> >micael wrote:
> > >
> > > I cannot access a webapp with the normal
> > > http://localhost:8080/myapp/servlet/mydirectory.MyServlet with Tomcat
> > > 4.1.12.  (Also, the embedded Tomcat 4.1.12 in JBoss 3.0.3 runs fine except
> > > that it won't access the examples servlets.)  The error shown is a 404 "The
> > > requested resource (/myapp/servlet/mydirectory.MyServlet) is not
> > > available.".  The same thing runs fine with Tomcat 4.1.0., both with and
> > > without JBoss.  Is this a BUG in Tomcat 4.1.12, or are there new
> > > constraints on reaching servlets from outside the container in 4.1.12?
> > >
> >
> >For security reasons (see the release notes for details), the invoker
> >servlet is disabled by default now. This servlet is what makes
> >/webapp/servlet/... paths invoke the given servlet. It's recommended
> >that you give explicit servlet definitions and mappings in the webapps's
> >web.xml instead.
> >
> >Michael
> >
> >--
> >To unsubscribe, e-mail:   
> >For additional commands, e-mail: 
>
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


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

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

[mturk]

mturk   2002/10/02 08:36:22

  Modified:jk/native2/common jk_worker_lb.c
  Log:
  Introduced 3 new configuration parameters to the lb.
  1. attempts -- replaces harcoded MAX_ATTEMPTS
  2. recovery -- replaces hardcoded WAIT_BEFORE_RECOVER
  3. timeout -- this one is new.
  The timeout if set will force the lb to cycle through workers if all are in the
  error_state for the specified amount of seconds. This is usefull for
  situations when the TC is overloaded and refuses new connections.
  The lb will wait and after timeout will report 500 to the client.
  
  Revision  ChangesPath
  1.24  +36 -9 jakarta-tomcat-connectors/jk/native2/common/jk_worker_lb.c
  
  Index: jk_worker_lb.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_lb.c,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- jk_worker_lb.c8 Jul 2002 13:33:38 -   1.23
  +++ jk_worker_lb.c2 Oct 2002 15:36:22 -   1.24
  @@ -77,15 +77,20 @@
   #define DEFAULT_LB_FACTOR   (1.0)
   
   /* Time to wait before retry... XXX make it configurable*/
  -#define WAIT_BEFORE_RECOVER (60) 
  +#define WAIT_BEFORE_RECOVER 60 
   
   #define MAX_ATTEMPTS 3
   
   #define NO_WORKER_MSG "The servlet container is temporary unavailable or being 
upgraded\n";
   
   typedef struct {
  -struct jk_mutex *cs;
  -intinitializing;
  +struct  jk_mutex *cs;
  +int initializing;
  +int attempts;
  +int recovery;
  +int timeout;
  +time_t  error_time;
  +
   } jk_worker_lb_private_t;
   
   /** Find the best worker. In process, check if timeout expired
  @@ -108,6 +113,7 @@
   int currentLevel=JK_LB_LEVELS - 1;
   char *session_route;
   time_t now = 0;
  +jk_worker_lb_private_t *lb_priv = lb->worker_private;
   
   session_route = jk2_requtil_getSessionRoute(env, s);
  
  @@ -119,7 +125,7 @@
   if(w->route != NULL &&
  0 == strcmp(session_route, w->route)) {
   if(attempt > 0 && w->in_error_state) {
  -/* We already tried to revive this worker. */
  +/* We already tried to revive this worker. */
   break;
   } else {
   return w;
  @@ -181,7 +187,7 @@
   /* Check if it's ready for recovery */
   if( now==0 ) now = time(NULL);
   
  -if((now - w->error_time) > WAIT_BEFORE_RECOVER) {
  +if((now - w->error_time) > lb_priv->recovery) {
   env->l->jkLog(env, env->l, JK_LOG_ERROR,
 "lb.getWorker() reenable %s\n", w->mbean->name);
   w->in_error_state = JK_FALSE;
  @@ -331,7 +337,18 @@
   rec=jk2_get_most_suitable_worker(env, lb, s, attempt);
   
   if (lb_priv->cs != NULL)
  -lb_priv->cs->unLock(env, lb_priv->cs);
  +lb_priv->cs->unLock(env, lb_priv->cs);
  +if (!rec && lb_priv->timeout) {
  +time_t now = time(NULL);
  +if ((int)(now - lb_priv->error_time) < lb_priv->timeout) {
  +#ifdef HAS_APR
  +apr_thread_yield();
  +#endif
  +continue;
  +}
  +}
  +else
  +lb_priv->error_time = time(NULL);
   }
   else if (!rec){
   /* If we are initializing the service wait until
  @@ -340,7 +357,7 @@
   if (lb->cs != NULL) {
   lb->cs->lock(env, lb->cs);
   lb->cs->unLock(env, lb->cs);
  -}
  +}
   continue;
   }
   attempt++;
  @@ -370,6 +387,7 @@
   }
   
   s->afterRequest( env, s);
  +lb_priv->error_time = time(NULL);
   return JK_ERR;
   }
   
  @@ -502,6 +520,7 @@
   jk_worker_t *lb=mbean->object;
   char *value=valueP;
   unsigned i = 0;
  +jk_worker_lb_private_t *lb_priv = lb->worker_private;
   
   if( strcmp( name, "worker") == 0 ) {
   if( lb->lbWorkerMap->get( env, lb->lbWorkerMap, name) != NULL ) {
  @@ -523,7 +542,13 @@
   lb->noWorkerCode=atoi( value );
   } else if( strcmp( name, "hwBalanceErr") == 0 ) {
   lb->hwBalanceErr=atoi( value );
  -}
  +} else if( strcmp( name, "timeout") == 0 ) {
  +lb_priv->timeout=atoi( value );
  +} else if( strcmp( name, "recovery") == 0 ) {
  +lb_priv->recovery=atoi( value );
  +} else if( strcmp( name, "attempts") == 0 ) {
  +lb_priv->attempts=atoi( value );
  +}
   return JK_ERR;
   }
   
  @@ -594,7 +619,9 @@
   if( jkb != NULL ) {
   worker_pri

Re: 4.1.12 JSPC question

[peter lin]

Here is a bit more information. I took a look at the jar files for jsp
1.1 tags and they include a taglib.tld file in meta-inf/.  Once I remove
that, it compiles the pages fine.  It looks like there's a conflict in
either jasper compiler or jspc that is unable to resolve which .tld file
to use.

peter lin


peter lin wrote:
> 
> after a lot of digging, I tracked part of the problem down to jakarta
> string taglib. once I removed that from my file, it correctly compiles
> the jsp page.  I'm working on tracking down the exact cause, but it
> might be an issue with jsp 1.1 tags. JSTL 1.2 compliant, but string
> taglib is 1.1.
> 
> if anyone has seen this, I'd like to hear about it. it might help me
> diagnose the problem and find a fix faster.
> 
> peter
> 
>

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

[Possible bug with jspc]

[peter lin]

I spent the last two days trying to use JspC to compile an entire webapp
and came across a problem. I'm not sure if this is a bug or not, but I
can reproduce it every time.  I'm still trying to track down the cause,
but I thought I'd post a question and maybe some one with more knowledge
can point me in the right direction.

I am using the following command to run jspc

C:\tomcat\bin>jspc -d ..\work\Standalone\localhost\_ -uribase
c:/myapp/web -webapp c:/myapp/web

in one of included files I define all the taglibs i use. right now I am
using taglibs from the Jakarta. If I use the string tag, it causes JspC
to die with NPE. If I remove the <%@ taglib %> for string tag, jspc
works fine.  the main difference between JSTL and string tag is JSTL is
1.2 and string tag is 1.1.

the page works just fine if I load it in the browser, but for some
reason, JspC doesn't like 1.1 taglibs.

can anyone provide any insight?


peter lin

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

RE: JSP Compilation Problem: Tomcat 4.1.12

[Sexton, George]

Never mind. I found this described in Bug #10036.

-Original Message-
From: Sexton, George [mailto:[EMAIL PROTECTED]]
Sent: 02 October, 2002 9:03 AM
To: Tomcat Developers List
Subject: RE: JSP Compilation Problem: Tomcat 4.1.12


I'm confused by the change in behavior. I can use JDK 1.4 w/ Tomcat 4.0.4
and it works.

-Original Message-
From: peter lin [mailto:[EMAIL PROTECTED]]
Sent: 02 October, 2002 8:56 AM
To: Tomcat Developers List
Subject: Re: JSP Compilation Problem: Tomcat 4.1.12



if you're using jdk 1.4, you have to have package names for your
classes. If you do not, it won't load the class correctly.

have you tried giving your classes a package name and trying it again?

peter

"Sexton, George" wrote:
>
> I posted this several days ago on tomcat-user and haven't gotten any
> responses so I am reposting it here.
>
> I am running into a problem with JSP pages under 4.1.12. I looked through
> the release notes, and the documentation and I can't find anything that
> seems to apply. Given a Servlet with the line:
>
> <%@ page import="WebApp, CalServlet" %>
>
> where WebApp and CalServlet are classes in my application WEB-INF/classes
> directory that compiles under 4.0.4, when I try to run the servlet under
> 4.1.12, it crashes on compile with the following message:
>
>
/usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev/index_jsp.
> java:7: '.' expected
> import WebApp;
>
> I turned on debugging, and the classpath looks correct:
>


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


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

A survey about handling bugs in open source projects

[Gunes Koru]

Hello all Tomcat contributors,

I am conducting a survey about the way defects (or bugs-I use these two words
 interchangeably) are handled in open source software projects. It is
very easy to fill out. It consists of three short sections which can be
completed at once or in different sessions. The survey can be found in the
address:

http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html

This survey includes questions that can be answered by developers,testers,
bug fixers, bug database owners, and project managers. I would greatly
appreciate if you could visit the above web page and fill out the survey.
I am sure you will find the questions very interesting and thought
provoking.  We need the help of all contributors of Tomcat in the above roles
to understand how we can use bugs data collected in your project for
software engineering research.

Nowadays, there is a huge amount of bug data on the Internet collected
during the development of all open source products. A bug database include
useful information to identify high-risk, problem-prone modules
(components) in the software. It is also possible to measure these
problem-prone components using several complexity metrics (McCabe's
cyclomatic complexity, Halstead's metrics, etc.), since the source code is
available. If a characterization, which is generalizable across many
projects (sub-projects) could be made in terms of complexity, focused
quality improvement would become possible in the future projects. So far,
in the literature, there is quite amount of evidence that 80 percent of
the problems occur from 20 percent of the modules (or software
components), which gives hope toward tremendous quality increase, time
savings, and increased success in the open source projects.

Also a bug database includes useful information about the efficiency of
development. For example, if a lot of bugs related to design of the system
are found after release, when coding bugs are expected more, then this may
indicate that the design or architecture of the system was done cursory.
Of course, these kinds of conclusions would require some kind of
classification of bugs according to their insertion time after they get
fixed.

However, before trying to find an answer to the questions like above, our
first step is to understand if the available data is usable for empirical
research purposes. This means having an idea about the consistency of bug
reports and fixes, accuracy of data, completeness of the data, etc. At
this point, we need your help. By filling out this survey, you will help
us understand availability, representativeness, and characteristics of the
data in the bug database of your project.  I'd like to stress that the
purpose of this survey is only and only research. Open source development
gained a very good momentum in the last decade. We hope that outcomes of
our research will help even increase this momentum. We will acknowledge
the help of all supporting communities when mentioning our results.

In addition to these goals, we also think that filling out this short
survey can lead to some immediate brain-storming in individuals and
groups, and exchange of ideas among the Tomcat community, which will
be useful too. As I said, you will find the survey questions interesting.
If you'd prefer to learn more about our research, I included a link in the
above web page of our survey. This link provides more information about
our research.

Once more, your contribution is very important to us. Please visit

http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html

and fill out our survey.


We greatly appreciate your helps. Please contact me for any question you
might have.

Thanks

-- 
***

A. Gunes Koru

Research Assistant, Ph.D. Student

Southern Methodist University
Computer Science and Engineering Department
6425 North Ownby Drive
Science and Information Building Room 317
Dallas, TX 75205


Home: 214 691 5633
Work: 214 768 2005
Cell: 214 893 7311
http://www.seas.smu.edu/~gkoru
Email: [EMAIL PROTECTED]

***


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

Re: [VOTE] JK2 2.1

[Costin Manolache]

Henri Gomez wrote:

> More comments on APR and JK2.
> 
> While making tomcat-connectors rpm for jk2, and also
> jk2 binaries for Linux, I wanted to have apache 1.3 jk2
> built with JNI support.

Do you have a multithreaded apache1.3 ? It's very important
to compile it as multithreaded and link pthread !

For the apr issues - I still think that apr should be 
treated as a general-purpose library, and we shouldn't 
have more than one varaiant in the system. 

Probably some APR expert could clarify this - but my opinion 
is that on linux the right place for apr is /usr/lib/libapr.so.0.9.2
and /usr/include/apr.
And I think Apache2.0 RPM should just depend on libapr.rpm, 
and same for mod_jk2.rpm

It's just too confusing to have 2 variants of the same library,
and it should be a portability library that can be used outside
apache - without apache having a special copy.

Costin

> 
> JNI support in JK2 requires APR.
> 
> So I build an apr 0.9.1 rpm, which include apr-utils
> since apr-utils couldn't be built without apr ;-[
> 
> To avoid conflict with Apache 2.0 rpms, I've installed
> apr libs in /usr/lib/apr/ and includes in /usr/include/apr.
> 
> And here we allready discover many interesting things :
> 
> With Apache 2.0, libapr shared lib in name libapr.so.0.9.2.
> With APR build, it's called libapr-0.so.0.9.2.
> 
> What you see also is that is seems that parts of apr-utils
> are included in Apache2 binaries (ie md5 stuff), so when
> you're using APR libs, you should add apr and aprutils to
> ldpath (-lapr -laprutils).
> 
> With that I was thinking being ready to make Apache 1.3
> works with APR, for JNI use purposes.
> 
> I've used :
> 
> ./configure --with-apxs=/usr/sbin/apxs --with-jni
> --with-apr-lib=/usr/lib/apr --with-apr-include=/usr/include/apr
> 
> The build works but I saw that the mod_jk2.so was linked against
> /usr/lib/libapr.so (the one from Apache 2.0 built) against the one
> in /usr/lib/arp.
> 
> So I patched Makefile.in to change -lapr to -lapr-0.
> 
> here correct build and link.
> 
> But the JNI support was still not there since the Makefile.in need
> a little rework. I tried first to use and adapt the one from Apache 2.0
> but this one didn't works since Apache 2.0.42 provide it's own libtool
> 1.4.2 and make use of rpath, which didn't works with the standard
> libtool 1.4 bundled with Redhat 7.2
> 
> No problem, I adapted the original Makefile.in from Apache 1.3 (patch
> attached) and do the build.
> 
> I finally got a mod_jk2.so and jkjni.so to be used with my Apache 1.3.
> 
> I installed mod_jk2.so and jkjni.so in Apache 1.3 modules dir,
> /usr/lib/apache, tried a restart but it failed with :
> 
> Starting httpd: Syntax error on line 1536 of /etc/httpd/conf/httpd.conf:
> Cannot load /etc/httpd/modules/mod_jk2.so into server:
> /etc/httpd/modules/mod_jk2.so: undefined symbol: jk_jni_status_code
> 
> Urg, I think it could be related to missing stuff in mod_jk2.so, since
> it's not linked against apr-util shared lib, so I rechange the
> Makefile.in, does the configure and make.
> 
> But still same error :
> 
> Cannot load /etc/httpd/modules/mod_jk2.so into server:
> /etc/httpd/modules/mod_jk2.so: undefined symbol: jk_jni_status_code
> 
> 
> When I take a look at binaries, the jkjni.so for Apache 2 is 126180
> long but the one for Apache 1.3 is only 8796 ?
> 
> Here is was ldd -v report about mod_jk2.so / jkjni.so for Apache 1.3 and
> 2.0 :
> 
> mod_jk2.so for Apache 1.3
> 
> libcrypt.so.1 => /lib/libcrypt.so.1 (0x4002f000)
> libapr-0.so.0 => /usr/lib/apr/libapr-0.so.0 (0x4005c000)
> libaprutil-0.so.0 => /usr/lib/apr/libaprutil-0.so.0 (0x4007a000)
> libc.so.6 => /lib/i686/libc.so.6 (0x4008f000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000)
> 
> Version information:
> /usr/lib/apache/mod_jk2.so:
> libc.so.6 (GLIBC_2.1.3) => /lib/i686/libc.so.6
> libc.so.6 (GLIBC_2.1) => /lib/i686/libc.so.6
> libc.so.6 (GLIBC_2.0) => /lib/i686/libc.so.6
> /lib/libcrypt.so.1:
> libc.so.6 (GLIBC_2.1.3) => /lib/i686/libc.so.6
> libc.so.6 (GLIBC_2.0) => /lib/i686/libc.so.6
> /usr/lib/apr/libapr-0.so.0:
> libc.so.6 (GLIBC_2.1.3) => /lib/i686/libc.so.6
> libc.so.6 (GLIBC_2.2) => /lib/i686/libc.so.6
> libc.so.6 (GLIBC_2.1.2) => /lib/i686/libc.so.6
> libc.so.6 (GLIBC_2.1) => /lib/i686/libc.so.6
> libc.so.6 (GLIBC_2.0) => /lib/i686/libc.so.6
> /usr/lib/apr/libaprutil-0.so.0:
> libc.so.6 (GLIBC_2.1.3) => /lib/i686/libc.so.6
> libc.so.6 (GLIBC_2.1) => /lib/i686/libc.so.6
> libc.so.6 (GLIBC_2.0) => /lib/i686/libc.so.6
> /lib/i686/libc.so.6:
> ld-linux.so.2 (GLIBC_2.1.1) => /lib/ld-linux.so.2
> ld-linux.so.2 (GLIBC_2.2.3) => /lib/ld-linux.so.2
> ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2
> ld-linux.so.2 (GLIBC_2.2) => /lib/ld-linux.so.2
> ld-linux.so.2 (GLIBC_2.0) => /lib/ld-linux.so.2
> libcrypt.so.1 => /lib/libcrypt.so.1 (0x40012000)
> libapr-0.so.0 => /usr/lib/apr/libapr-0.so.0 (0x4003f000)
> libaprutil-0.so.0 => /usr/lib/apr/libaprutil-0.so.0 (0x4005d000)
> libc.so.6 => /lib/i686/libc.so.6 (0x4007200

RE: JSP Compilation Problem: Tomcat 4.1.12

[Sexton, George]

I'm confused by the change in behavior. I can use JDK 1.4 w/ Tomcat 4.0.4
and it works.

-Original Message-
From: peter lin [mailto:[EMAIL PROTECTED]]
Sent: 02 October, 2002 8:56 AM
To: Tomcat Developers List
Subject: Re: JSP Compilation Problem: Tomcat 4.1.12



if you're using jdk 1.4, you have to have package names for your
classes. If you do not, it won't load the class correctly.

have you tried giving your classes a package name and trying it again?

peter

"Sexton, George" wrote:
>
> I posted this several days ago on tomcat-user and haven't gotten any
> responses so I am reposting it here.
>
> I am running into a problem with JSP pages under 4.1.12. I looked through
> the release notes, and the documentation and I can't find anything that
> seems to apply. Given a Servlet with the line:
>
> <%@ page import="WebApp, CalServlet" %>
>
> where WebApp and CalServlet are classes in my application WEB-INF/classes
> directory that compiles under 4.0.4, when I try to run the servlet under
> 4.1.12, it crashes on compile with the following message:
>
>
/usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev/index_jsp.
> java:7: '.' expected
> import WebApp;
>
> I turned on debugging, and the classpath looks correct:
>


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

Re: JSP Compilation Problem: Tomcat 4.1.12

[peter lin]

if you're using jdk 1.4, you have to have package names for your
classes. If you do not, it won't load the class correctly.

have you tried giving your classes a package name and trying it again?

peter

"Sexton, George" wrote:
> 
> I posted this several days ago on tomcat-user and haven't gotten any
> responses so I am reposting it here.
> 
> I am running into a problem with JSP pages under 4.1.12. I looked through
> the release notes, and the documentation and I can't find anything that
> seems to apply. Given a Servlet with the line:
> 
> <%@ page import="WebApp, CalServlet" %>
> 
> where WebApp and CalServlet are classes in my application WEB-INF/classes
> directory that compiles under 4.0.4, when I try to run the servlet under
> 4.1.12, it crashes on compile with the following message:
> 
> /usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev/index_jsp.
> java:7: '.' expected
> import WebApp;
> 
> I turned on debugging, and the classpath looks correct:
> 
> [javac] index_jsp.java added as
> /usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev/index_jsp.
> class doesn't exist.
> [javac] Compiling 1 source file
> [javac] Using modern compiler
> [javac] Compilation arguments:
> [javac] '-classpath'
> [javac]
> '/usr/java/lib/tools.jar:/usr/local/jakarta-tomcat-4.1.12/bin/bootstrap.jar:
> /home/gsexton/cdaily/WEB-INF/classes:/home/gsexton/cdaily/WEB-INF/lib/PNGEnc
> oder.jar:/home/gsexton/cdaily/WEB-INF/lib/activation.jar:/home/gsexton/cdail
> y/WEB-INF/lib/cryptix32.jar:/home/gsexton/cdaily/WEB-INF/lib/jdbc7.1-1.2.jar
> :/home/gsexton/cdaily/WEB-INF/lib/mail.jar:/usr/local/jakarta-tomcat-4.1.12/
> shared/classes:/usr/local/jakarta-tomcat-4.1.12/common/classes:/usr/local/ja
> karta-tomcat-4.1.12/common/endorsed/xmlParserAPIs.jar:/usr/local/jakarta-tom
> cat-4.1.12/common/endorsed/xercesImpl.jar:/usr/local/jakarta-tomcat-4.1.12/c
> ommon/lib/activation.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/jasper-
> runtime.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/jasper-compiler.jar:
> /usr/local/jakarta-tomcat-4.1.12/common/lib/naming-resources.jar:/usr/local/
> jakarta-tomcat-4.1.12/common/lib/commons-collections.jar:/usr/local/jakarta-
> tomcat-4.1.12/common/lib/naming-common.jar:/usr/local/jakarta-tomcat-4.1.12/
> common/lib/commons-logging-api.jar:/usr/local/jakarta-tomcat-4.1.12/common/l
> ib/ant.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/mail.jar:/usr/local/j
> akarta-tomcat-4.1.12/common/lib/commons-dbcp.jar:/usr/local/jakarta-tomcat-4
> .1.12/common/lib/servlet.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/jdb
> c2_0-stdext.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/commons-pool.jar
> :/usr/local/jakarta-tomcat-4.1.12/common/lib/jndi.jar:/usr/local/jakarta-tom
> cat-4.1.12/common/lib/naming-factory.jar:/usr/local/jakarta-tomcat-4.1.12/co
> mmon/lib/jta.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/MHS.jar:/usr/lo
> cal/jakarta-tomcat-4.1.12/common/lib/jdbc7.1-1.2.jar:/usr/local/jakarta-tomc
> at-4.1.12/common/lib/jconn2.jar'
> [javac] '-sourcepath'
> [javac]
> '/usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev'
> [javac] '-encoding'
> [javac] 'ISO-8859-1'
> [javac] '-g'
> [javac]
> [javac] The ' characters around the executable and arguments are
> [javac] not part of the command.
> [javac] File to be compiled:
> [javac]
> /usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev/index_jsp.
> java
> 
> I tried this with Tomcat running as root and got the same result. I am
> using:
> 
> java version "1.4.1"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
> Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)
> 
> On RedHat 7.2 w/ all patches applied.
> 
> Any ideas on this would be appreciated.
> 
> George Sexton
> MH Software, Inc.
> Home of Connect Daily Web Calendar Software
> http://www.mhsoftware.com/connectdaily.htm
> Voice: 303 438 9585
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

DO NOT REPLY [Bug 10565] - shutdown hook problem: java.lang.NoClassDefFoundError: java/util/Iterator

[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=10565

shutdown hook problem:  java.lang.NoClassDefFoundError: java/util/Iterator

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |



--- Additional Comments From [EMAIL PROTECTED]  2002-10-02 14:57 ---
I have searched through the servlet spec and it doesn't restrict the usage of
threads and shutdown hooks in servlets.

Anyway the problem here seems to be the (webapp)Classloader which throws a
ClassNotFoundException if it is stopped.
Isn't it possible to delegate the loading of classes to its parents when it is
in "shutdown mode"?

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

Re: Strange problem with tomcat 4.1.2

[Matt Fury]

I BELIEVE that is due to some incorrect commenting in
your server.xml file. I had this problem once and I
thats what caused it.

Double check your server.xml file.


--- Henri Gomez <[EMAIL PROTECTED]> wrote:
> While working on 4.1.2 rpms I noticed the following
> error at startup :
> 
> 4732 [main] INFO modeler.Registry  - Creating
> MBeanServer
> 5705 [main] INFO http11.Http11Protocol  -
> Initializing Coyote HTTP/1.1 
> on port 8080
> Starting service Tomcat-Standalone
> Apache Tomcat/4.1
> 7324 [main] ERROR digester.Digester  - Parse Fatal
> Error at line 307 
> column 39: The string "--" is not permitted within
> comments.
> org.xml.sax.SAXParseException: The string "--" is
> not permitted within 
> comments.
>   at 
>
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> 
> Source)
>   at
>
org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown
> Source)
>   at
>
org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
>   at
>
org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
>   at
>
org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown
> Source)
>   at
>
org.apache.xerces.impl.XMLScanner.scanComment(Unknown
> Source)
>   at
>
org.apache.xerces.impl.XMLDTDScannerImpl.scanComment(Unknown
> Source)
>   at
>
org.apache.xerces.impl.XMLDTDScannerImpl.scanDecls(Unknown
> Source)
>   at 
>
org.apache.xerces.impl.XMLDTDScannerImpl.scanDTDExternalSubset(Unknown
> 
> Source)
>   at 
>
org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(Unknown
> 
> Source)
>   at 
>
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> 
> Source)
>   at
>
org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
> Source)
>   at
>
org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
> Source)
>   at
> org.apache.xerces.parsers.XMLParser.parse(Unknown
> Source)
>   at
>
org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
>   at
>
org.apache.commons.digester.Digester.parse(Digester.java:1514)
>   at 
>
org.apache.catalina.startup.ContextConfig.tldScanStream(ContextConfig.java:977)
>   at 
>
org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.java:1006)
>   at 
>
org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:870)
>   at
>
org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647)
>   at 
>
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243)
>   at 
>
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
>   at 
>
org.apache.catalina.core.StandardContext.start(StandardContext.java:3493)
>   at
>
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
>   at
>
org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
>   at
>
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
>   at
>
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
>   at
>
org.apache.catalina.core.StandardService.start(StandardService.java:497)
>   at
>
org.apache.catalina.core.StandardServer.start(StandardServer.java:2189)
>   at
>
org.apache.catalina.startup.Catalina.start(Catalina.java:510)
>   at
>
org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
>   at
>
org.apache.catalina.startup.Catalina.process(Catalina.java:180)
>   at java.lang.reflect.Method.invoke(Native Method)
>   at
>
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
> 8720 [main] ERROR digester.Digester  - Parse Fatal
> Error at line 307 
> column 39: The string "--" is not permitted within
> comments.
> org.xml.sax.SAXParseException: The string "--" is
> not permitted within 
> comments.
>   at 
>
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> 
> Source)
>   at
>
org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown
> Source)
> 
> 
> 
> Admin log show me the following error :
> 
> 2002-10-02 13:29:01 WebappLoader[/admin]: Deploying
> class repositories 
> to work directory
> /var/tomcat4/work/Standalone/localhost/admin
> 2002-10-02 13:29:01 WebappLoader[/admin]: Deploy
> class files 
> /WEB-INF/classes to 
>
/var/tomcat4/webapps/../server/webapps/admin/WEB-INF/classes
> 2002-10-02 13:29:01 WebappLoader[/admin]: Deploy JAR
> 
> /WEB-INF/lib/struts.jar to 
>
/var/tomcat4/webapps/../server/webapps/admin/WEB-INF/lib/struts.jar
> 2002-10-02 13:29:02 ContextConfig[/admin] Exception
> processing TLD at 
> resource path /WEB-INF/controls.tld
> javax.servlet.ServletException: Exception processing
> TLD at resource 
> path /WEB-INF/controls.tld
>  at 
>
org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.java:1010)
>  at 
>
org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:870)
>  at 
>
org.apache.catalina.startup.ContextConfig.start(Contex

JSP Compilation Problem: Tomcat 4.1.12

[Sexton, George]

I posted this several days ago on tomcat-user and haven't gotten any
responses so I am reposting it here.

I am running into a problem with JSP pages under 4.1.12. I looked through
the release notes, and the documentation and I can't find anything that
seems to apply. Given a Servlet with the line:

<%@ page import="WebApp, CalServlet" %>

where WebApp and CalServlet are classes in my application WEB-INF/classes
directory that compiles under 4.0.4, when I try to run the servlet under
4.1.12, it crashes on compile with the following message:


/usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev/index_jsp.
java:7: '.' expected
import WebApp;

I turned on debugging, and the classpath looks correct:

[javac] index_jsp.java added as
/usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev/index_jsp.
class doesn't exist.
[javac] Compiling 1 source file
[javac] Using modern compiler
[javac] Compilation arguments:
[javac] '-classpath'
[javac]
'/usr/java/lib/tools.jar:/usr/local/jakarta-tomcat-4.1.12/bin/bootstrap.jar:
/home/gsexton/cdaily/WEB-INF/classes:/home/gsexton/cdaily/WEB-INF/lib/PNGEnc
oder.jar:/home/gsexton/cdaily/WEB-INF/lib/activation.jar:/home/gsexton/cdail
y/WEB-INF/lib/cryptix32.jar:/home/gsexton/cdaily/WEB-INF/lib/jdbc7.1-1.2.jar
:/home/gsexton/cdaily/WEB-INF/lib/mail.jar:/usr/local/jakarta-tomcat-4.1.12/
shared/classes:/usr/local/jakarta-tomcat-4.1.12/common/classes:/usr/local/ja
karta-tomcat-4.1.12/common/endorsed/xmlParserAPIs.jar:/usr/local/jakarta-tom
cat-4.1.12/common/endorsed/xercesImpl.jar:/usr/local/jakarta-tomcat-4.1.12/c
ommon/lib/activation.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/jasper-
runtime.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/jasper-compiler.jar:
/usr/local/jakarta-tomcat-4.1.12/common/lib/naming-resources.jar:/usr/local/
jakarta-tomcat-4.1.12/common/lib/commons-collections.jar:/usr/local/jakarta-
tomcat-4.1.12/common/lib/naming-common.jar:/usr/local/jakarta-tomcat-4.1.12/
common/lib/commons-logging-api.jar:/usr/local/jakarta-tomcat-4.1.12/common/l
ib/ant.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/mail.jar:/usr/local/j
akarta-tomcat-4.1.12/common/lib/commons-dbcp.jar:/usr/local/jakarta-tomcat-4
.1.12/common/lib/servlet.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/jdb
c2_0-stdext.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/commons-pool.jar
:/usr/local/jakarta-tomcat-4.1.12/common/lib/jndi.jar:/usr/local/jakarta-tom
cat-4.1.12/common/lib/naming-factory.jar:/usr/local/jakarta-tomcat-4.1.12/co
mmon/lib/jta.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/MHS.jar:/usr/lo
cal/jakarta-tomcat-4.1.12/common/lib/jdbc7.1-1.2.jar:/usr/local/jakarta-tomc
at-4.1.12/common/lib/jconn2.jar'
[javac] '-sourcepath'
[javac]
'/usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev'
[javac] '-encoding'
[javac] 'ISO-8859-1'
[javac] '-g'
[javac]
[javac] The ' characters around the executable and arguments are
[javac] not part of the command.
[javac] File to be compiled:
[javac]
/usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev/index_jsp.
java

I tried this with Tomcat running as root and got the same result. I am
using:

java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)

On RedHat 7.2 w/ all patches applied.


Any ideas on this would be appreciated.

George Sexton
MH Software, Inc.
Home of Connect Daily Web Calendar Software
http://www.mhsoftware.com/connectdaily.htm
Voice: 303 438 9585



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

DO NOT REPLY [Bug 13206] New: - Invalid java bean property error message could be reported better.

[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=13206

Invalid java bean property error message could be reported better.

   Summary: Invalid java bean property error message could be
reported better.
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: All
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Using an invalid Java bean that has setXXX and getXXX property methods that 
have different in and out types can be difficult to track down. The error 
message returned in such a case could be improved by including the property 
type.

For example:

public class MyBeanClass {
  MyViewClass mvc;

  public void setView(String myViewClass) {
try {
  mvc = (MyViewClass)Class.forName(myViewClass).newInstance();
} catch(Exception ex) {}
  }

  public MyViewClass getView() {
return myViewClass;
  }
}

The problem with this java bean class is that the property 'view' has two 
different types i.e. set takes a String but the get returns a MyViewClass 
object.

If we use the following code in a JSP:-


  


the following exception is thrown:-

org.apache.jasper.JasperException: Can't find a method to write property 'view' 
in a bean of type 'MyBeanClass'
at org.apache.jasper.runtime.JspRuntimeLibrary.internalIntrospecthelper
(JspRuntimeLibrary.java)
at org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper
(JspRuntimeLibrary.java)
at org.apache.jsp.myJSP$jsp._jspService(myJSP$jsp.java)

If the type of the propery was printed out in the error message this would make 
this mistake a lot easier to track down.

See line 714 in org.apache.jasper.runtime.JspRuntimeLibrary

private static void internalIntrospecthelper(Object bean, ...) ... {
  ...

  if(type == null)
throw new JasperException(
  Constants.getString("jsp.error.beans.noproperty", 
new Object[] { prop, bean.getClass().getName() 
  }));
  else
throw new JasperException(
  Constants.getString("jsp.error.beans.nomethod.setproperty",
new Object[] { prop, bean.getClass().getName()
  }));
  ...
}

The else part of the above code is been excecuted and even that the 'type' is 
found it is not inserted into the exception.

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

DO NOT REPLY [Bug 13205] New: - Tomcat Web Application Manager; config parameter is not null.

[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=13205

Tomcat Web Application Manager; config parameter is not null.

   Summary: Tomcat Web Application Manager; config parameter is not
null.
   Product: Tomcat 4
   Version: 4.1.12
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina:Modules
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Trying to install a web application from the html manager 
I found out that if I don't specify the config URL a
java.net.MalformedURLException is raised. This is because the method
request.getParameter("config") called by the servlet
org.apache.catalina.servlets.ManagerServlet returns a void string
(i.e. '') instead of null. The consequence is that the constructor
URL(String) throws that exception.

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

Need some clarifications

[Christian Gross]

Hi

So I worked myself through the various CVS sources and have a couple of 
"official" position questions to ask.

The CVS projects jakarta-tomcat-catalina and jakarta-tomcat-jasper, will be 
forming the Tomcat 5 work?

The CVS project jakarta-tomcat-4.0 is the 4.x branch?

The CVS project jakarta-tomcat is anything before 4.0

The CVS project jakarta-tomcat-5.0 does nothing??

Thanks, for any help


Christian Gross
Software Engineering Consultant
http://www.devspace.com
North America: 1-450-675-4208
Europe +41.1.701.1166


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

DO NOT REPLY [Bug 13069] - mod_webapp inits all webapps for each virtualHost

[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=13069

mod_webapp inits all webapps for each virtualHost

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-10-02 13:25 ---
Avoided by changing appBase and docBase in server.xml like this:


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

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

[mturk]

mturk   2002/10/02 05:50:05

  Modified:jk/native2/common jk_channel_apr_socket.c
  Log:
  Enable connecting to other IP addreses of the same host
  if the first one is down, checking all of them.
  This is only the case when the specified server name is not
  in the dot-ip notation.
  
  Revision  ChangesPath
  1.26  +45 -41
jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c
  
  Index: jk_channel_apr_socket.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- jk_channel_apr_socket.c   27 Sep 2002 13:07:28 -  1.25
  +++ jk_channel_apr_socket.c   2 Oct 2002 12:50:05 -   1.26
  @@ -219,51 +219,55 @@
   apr_socket_t *sock=endpoint->channelData;
   apr_status_t ret;
   apr_int32_t timeout = (apr_int32_t)(socketInfo->timeout * APR_USEC_PER_SEC);
  -char msg[128];
  +char msg[128];
  +int connected = 0;
  +
  +while (remote_sa && !connected) {
  +if ((ret = apr_socket_create(&sock, remote_sa->family, SOCK_STREAM,
  + (apr_pool_t *)env->globalPool->_private))
  +!= APR_SUCCESS) {
  +env->l->jkLog(env, env->l, remote_sa->next ? JK_LOG_DEBUG : 
JK_LOG_ERROR,
  + "channelApr.open(): error %d creating socket %d %s\n",
  +  ret, socketInfo->host);
  +remote_sa = remote_sa->next;
  +continue;
  +}
  +
   
  -if (apr_socket_create(&sock, remote_sa->family, SOCK_STREAM,
  -  (apr_pool_t *)env->globalPool->_private)
  - != APR_SUCCESS) {
  -env->l->jkLog(env, env->l, JK_LOG_ERROR,
  - "channelApr.open(): can't create socket %d %s\n",
  - errno, strerror( errno ) );
  -return JK_ERR;
  -} 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  -  "channelApr.open(): create tcp socket %d\n", sock );
  -
  -/* the default timeout (0) will set the socket to blocking with
  -   infinite timeouts.
  - */
  -if (timeout <= 0)
  -timeout = -1;
  -if (apr_setsocketopt(sock, APR_SO_TIMEOUT, timeout)!= APR_SUCCESS) {
  -env->l->jkLog(env, env->l, JK_LOG_ERROR,
  - "channelApr.open(): can't set timeout %d %s\n",
  - errno, strerror( errno ) );
  -return JK_ERR;
  -}
  -
  -/* Tries to connect to JServ (continues trying while error is EINTR) */
  -do {
   env->l->jkLog(env, env->l, JK_LOG_INFO,
  -  "channelApr.open() connect on %d\n",sock);
  -ret = apr_connect(sock, remote_sa);
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  -  "jk2_channel_apr_open: %d %s %s\n",ret, strerror( errno ),
  -  socketInfo->host);
  -
  -} while (ret == APR_EINTR);
  +"channelApr.open(): create tcp socket %d\n", sock );
  +
  +/* the default timeout (0) will set the socket to blocking with
  +   infinite timeouts.
  +*/
  +if (timeout <= 0)
  +apr_socket_timeout_set(sock, 0);
  +else
  +apr_socket_timeout_set(sock, timeout);
  +
  +/* make the connection out of the socket */
  +do { 
  +ret = apr_connect(sock, remote_sa);
  +} while (APR_STATUS_IS_EINTR(ret));
  +
  +/* if an error occurred, loop round and try again */
  +if (ret != APR_SUCCESS) {
  +apr_socket_close(sock);
  +env->l->jkLog(env, env->l, remote_sa->next ? JK_LOG_DEBUG : 
JK_LOG_ERROR,
  + "channelApr.open() attempt to connect to %pI (%s) failed 
%d\n",
  + remote_sa,
  + socketInfo->host,
  + ret);
  +remote_sa = remote_sa->next;
  +continue;
  +}
  +connected = 1;
  +}
   
  -/* Check if we connected */
  -if(ret != APR_SUCCESS ) {
  -apr_socket_close(sock);
  -env->l->jkLog(env, env->l, JK_LOG_ERROR,
  -  "channelApr.open() connect failed %d %s\n",
  -  ret, apr_strerror( ret, msg, sizeof(msg) ) );
  -return JK_ERR;
  +if (!connected) {
  +apr_socket_close(sock);   
  +return JK_ERR;
   }
  -
   /* enable the use of keep-alive packets on TCP connection */
   if(keepalive) {
   int set = 1;
  
  
  

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

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

[mturk]

mturk   2002/10/02 05:48:26

  Modified:jk/native2/common jk_worker_jni.c
  Log:
  We don't need the HAS_APR, cause we have HAVE_JNI.
  
  Revision  ChangesPath
  1.28  +4 -8  jakarta-tomcat-connectors/jk/native2/common/jk_worker_jni.c
  
  Index: jk_worker_jni.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_jni.c,v
  retrieving revision 1.27
  retrieving revision 1.28
  diff -u -r1.27 -r1.28
  --- jk_worker_jni.c   14 Jul 2002 13:33:56 -  1.27
  +++ jk_worker_jni.c   2 Oct 2002 12:48:26 -   1.28
  @@ -66,12 +66,10 @@
   #include "jk_workerEnv.h"
   #include "jk_env.h"
   #include "jk_bean.h"
  +
  +#ifdef HAVE_JNI
   
  -#ifdef HAS_APR
  -#include "apr_thread_proc.h"
  -#endif
  -
  -#ifdef HAVE_JNI
  +#include "apr_thread_proc.h"
   
   #include "jk_vm.h"
   #include "jk_registry.h"
  @@ -429,11 +427,9 @@
   jniWorker->jk_main_method,
   jargs);
   if (jniWorker->hook == JK2_WORKER_HOOK_SHUTDOWN) {
  -#ifdef HAS_APR
   while (jk_jni_status_code != 2) {
   apr_thread_yield();
   }
  -#endif
   vm->detach(env, vm);
   }
   }
  @@ -502,4 +498,4 @@
   return JK_OK;
   }

  -#endif
  +#endif
  
  
  

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

Re: [VOTE] JK2 2.1

[jean-frederic clere]

Henri Gomez wrote:
> jean-frederic clere wrote:
> 
>> Henri Gomez wrote:
>>
>>> More comments on APR and JK2.
>>>
>>> While making tomcat-connectors rpm for jk2, and also
>>> jk2 binaries for Linux, I wanted to have apache 1.3 jk2
>>> built with JNI support.
>>>
>>> JNI support in JK2 requires APR.
>>>
>>> So I build an apr 0.9.1 rpm, which include apr-utils
>>> since apr-utils couldn't be built without apr ;-[
>>>
>>> To avoid conflict with Apache 2.0 rpms, I've installed
>>> apr libs in /usr/lib/apr/ and includes in /usr/include/apr.
>>>
>>> And here we allready discover many interesting things :
>>>
>>> With Apache 2.0, libapr shared lib in name libapr.so.0.9.2.
>>> With APR build, it's called libapr-0.so.0.9.2.
>>>
>>> What you see also is that is seems that parts of apr-utils
>>> are included in Apache2 binaries (ie md5 stuff), so when
>>> you're using APR libs, you should add apr and aprutils to
>>> ldpath (-lapr -laprutils).
>>>
>>> With that I was thinking being ready to make Apache 1.3
>>> works with APR, for JNI use purposes.
>>>
>>> I've used :
>>>
>>> ./configure --with-apxs=/usr/sbin/apxs --with-jni 
>>> --with-apr-lib=/usr/lib/apr --with-apr-include=/usr/include/apr
>>>
>>> The build works but I saw that the mod_jk2.so was linked against
>>> /usr/lib/libapr.so (the one from Apache 2.0 built) against the one
>>> in /usr/lib/arp.
>>>
>>> So I patched Makefile.in to change -lapr to -lapr-0.
>>>
>>> here correct build and link.
>>
>>
>>
>> That is not enough you should use apr-config.
>> I have already patched mod_webapp for that.
> 
> 
> Could you do the same for jk2, but it should be only if --with-apr
> is present...

I will try.

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




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

Strange problem with tomcat 4.1.2

[Henri Gomez]

While working on 4.1.2 rpms I noticed the following error at startup :

4732 [main] INFO modeler.Registry  - Creating MBeanServer
5705 [main] INFO http11.Http11Protocol  - Initializing Coyote HTTP/1.1 
on port 8080
Starting service Tomcat-Standalone
Apache Tomcat/4.1
7324 [main] ERROR digester.Digester  - Parse Fatal Error at line 307 
column 39: The string "--" is not permitted within comments.
org.xml.sax.SAXParseException: The string "--" is not permitted within 
comments.
at 
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown 
Source)
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source)
at org.apache.xerces.impl.XMLScanner.scanComment(Unknown Source)
at org.apache.xerces.impl.XMLDTDScannerImpl.scanComment(Unknown Source)
at org.apache.xerces.impl.XMLDTDScannerImpl.scanDecls(Unknown Source)
at 
org.apache.xerces.impl.XMLDTDScannerImpl.scanDTDExternalSubset(Unknown 
Source)
at 
org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(Unknown 
Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.commons.digester.Digester.parse(Digester.java:1514)
at 
org.apache.catalina.startup.ContextConfig.tldScanStream(ContextConfig.java:977)
at 
org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.java:1006)
at 
org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:870)
at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647)
at 
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:3493)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
at org.apache.catalina.core.StandardService.start(StandardService.java:497)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:2189)
at org.apache.catalina.startup.Catalina.start(Catalina.java:510)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
8720 [main] ERROR digester.Digester  - Parse Fatal Error at line 307 
column 39: The string "--" is not permitted within comments.
org.xml.sax.SAXParseException: The string "--" is not permitted within 
comments.
at 
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown 
Source)
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)



Admin log show me the following error :

2002-10-02 13:29:01 WebappLoader[/admin]: Deploying class repositories 
to work directory /var/tomcat4/work/Standalone/localhost/admin
2002-10-02 13:29:01 WebappLoader[/admin]: Deploy class files 
/WEB-INF/classes to 
/var/tomcat4/webapps/../server/webapps/admin/WEB-INF/classes
2002-10-02 13:29:01 WebappLoader[/admin]: Deploy JAR 
/WEB-INF/lib/struts.jar to 
/var/tomcat4/webapps/../server/webapps/admin/WEB-INF/lib/struts.jar
2002-10-02 13:29:02 ContextConfig[/admin] Exception processing TLD at 
resource path /WEB-INF/controls.tld
javax.servlet.ServletException: Exception processing TLD at resource 
path /WEB-INF/controls.tld
 at 
org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.java:1010)
 at 
org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:870)
 at 
org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647)
 at 
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243)
 at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
 at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:3493)
 at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821)
 at 
org.apache.catalina.cor

[JK2] Unicode Log messages using 4.1.12

[Mladen Turk]

Hi, 

Since 4.1.12 I have the following messages in the jk2.properties.save

\ua\up\ur\u.\uj\un\ui\uM\uo\ud\u
e\uS\uo\u=\ui\un\up\ur\uo\uc\u00
00e\us\us\u
\uc\uh\ua\un\un\ue\ul\uJ\un\ui\u
.\ud\ui\us\ua\ub\ul\ue\ud\u=\u00
000\u
maxThreads=75
\u\#\u\#\u=\uD\uO\uC\uU\uM\uE\uN
\uT\uA\uT\uI\uO\uN\u \uO\uF\u
\uT\uH\uE\u
\uF\uO\uR\uM\uA\uT\u \uI\uN\u
\uJ\uk\uM\ua\ui\un\u
\uj\ua\uv\ua\ud\uo\uc\u.\u
backlog=10
timeout=2
\u\#\u=\uT\uh\ui\us\u
\uw\ui\ul\ul\u
\ue\un\ua\ub\ul\ue\u
\ut\uh\ue\u
\us\ut\ua\ur\ut\ui\un\ug\u
\uo\uf\u \ut\uh\ue\u
\uT\uo\um\uc\ua\ut\u
\uf\ur\uo\um\u
\um\uo\ud\u_\uj\uk\u2\u
tcpNoDelay=true
\u=
\u00FF\u00FE\#\u\#\u=\uT\uH\uI\uS\u
\uF\uI\uL\uE\u \uM\uA\uY\u
\uB\uE\u
\uO\uV\uE\uR\uR\uI\uD\uE\uN\u
\uA\uT\u
\uR\uU\uN\uT\uI\uM\uE\u.\u
\uM\uA\uK\uE\u \uS\uU\uR\uE\u
\uT\uO\uM\uC\uA\uT\u \uI\uS\u
\uS\uT\uO\uP\uE\uD\u

And when starting tomcat the apr and channelJni log messages are also
displayed using Unicode

SEVERE: No class name for  a p r   a p r
2002.10.02 09:04:36 org.apache.jk.server.JkMain newHandler
SEVERE: No class name for  c h a n n e l J n i   c h a n n e l J n i
2002.10.02 09:04:36 org.apache.jk.common.ChannelSocket init


There was no such a promblems with the previous versions of TC.

MT.


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

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

[mturk]

mturk   2002/10/02 03:58:06

  Modified:jk/native2/common jk_uriMap.c
  Log:
  Fix the wrong uri association with the webaps.
  If we specify the context in the uri, try the exactMap first cause webapp
  can have a name that is subset of some larger context, so that larger one
  would be used with the prefixMap only.
  
  Revision  ChangesPath
  1.48  +18 -7 jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c
  
  Index: jk_uriMap.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c,v
  retrieving revision 1.47
  retrieving revision 1.48
  diff -u -r1.47 -r1.48
  --- jk_uriMap.c   2 Oct 2002 10:28:36 -   1.47
  +++ jk_uriMap.c   2 Oct 2002 10:58:06 -   1.48
  @@ -487,7 +487,7 @@
   jk_uriEnv_t *hostEnv = jk2_uriMap_hostMap(env, uriMap, vhost, port);
   
   char *uri = uriEnv->uri;
  -jk_uriEnv_t *ctxEnv;
  +jk_uriEnv_t *ctxEnv = NULL;
   
   if (hostEnv == NULL)
   continue;
  @@ -498,19 +498,30 @@
   
   if (uri == NULL)
   continue;
  -
  -ctxEnv = jk2_uriMap_prefixMap(env, uriMap, hostEnv->webapps, uri,
  -  strlen(uri));
  +
  +/* If the context was specified try to find the exact one */
  +if (uriEnv->contextPath != NULL)
  +ctxEnv = jk2_uriMap_exactMap(env, uriMap, hostEnv->webapps,
  + uriEnv->contextPath,
  + uriEnv->ctxt_len);
  +/* Next find by uri prefix */
  +if (ctxEnv == NULL)
  +ctxEnv = jk2_uriMap_prefixMap(env, uriMap, hostEnv->webapps, uri,
  +  strlen(uri));
   
   if (ctxEnv == NULL) {
   env->l->jkLog(env, env->l, JK_LOG_INFO, 
  "uriMap.init() no context for %s\n", uri); 
   return JK_ERR;
  -}
  +}
  +
  +/* Correct the context path if needed */
   uriEnv->contextPath = ctxEnv->prefix;
   uriEnv->ctxt_len = ctxEnv->prefix_len;
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  -   "uriMap.init() adding context %s for %s\n", 
ctxEnv->prefix, uri); 
  +
  +if (uriMap->mbean->debug > 5) 
  +env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +  "uriMap.init() adding context %s for %s\n", 
ctxEnv->prefix, uri); 
   
   switch (uriEnv->match_type) {
   case MATCH_TYPE_EXACT:
  
  
  

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

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

[mturk]

mturk   2002/10/02 03:28:36

  Modified:jk/native2/common jk_uriMap.c
  Log:
  When creating 'free' webapps, put them to the correct vhost
  changing to the real name composed of the host[:port]/context.
  
  Revision  ChangesPath
  1.47  +12 -5 jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c
  
  Index: jk_uriMap.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c,v
  retrieving revision 1.46
  retrieving revision 1.47
  diff -u -r1.46 -r1.47
  --- jk_uriMap.c   2 Oct 2002 09:49:16 -   1.46
  +++ jk_uriMap.c   2 Oct 2002 10:28:36 -   1.47
  @@ -415,16 +415,23 @@
 strlen(context));
   /* if not alredy created, create it */
   if (ctxEnv == NULL) {
  -   jk_bean_t *mbean;
  - 
  +jk_bean_t *mbean;
  +char *ctxname;
  +
  +ctxname = uriEnv->pool->calloc(env, uriEnv->pool, strlen(vhost) + 
  +   strlen(context) + 1 );
  +
  +strcpy(ctxname, vhost);
  +strcat(ctxname, context);
  +
   env->l->jkLog(env, env->l, JK_LOG_INFO,
  -  "uriMap: creating context %s\n", context);
  +  "uriMap: creating context %s\n", ctxname);
   mbean = env->getBean2(env, "uri", context);
   if (mbean == NULL)
  -mbean = env->createBean2(env, uriMap->pool,"uri", context);
  +mbean = env->createBean2(env, uriMap->pool,"uri", ctxname);
   if (mbean == NULL || mbean->object == NULL) {
   env->l->jkLog(env, env->l, JK_LOG_ERROR,
  -  "uriMap: can't create context object %s\n",context);
  +  "uriMap: can't create context object %s\n",ctxname);
   continue;
   }
   ctxEnv = mbean->object;
  
  
  

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

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

[mturk]

mturk   2002/10/02 03:27:18

  Modified:jk/native2/common jk_uriEnv.c
  Log:
  Add the context to the getAttribute, so we can display what is
  the context of particular uri in the jkstatus
  
  Revision  ChangesPath
  1.35  +7 -5  jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c
  
  Index: jk_uriEnv.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c,v
  retrieving revision 1.34
  retrieving revision 1.35
  diff -u -r1.34 -r1.35
  --- jk_uriEnv.c   2 Oct 2002 09:45:02 -   1.34
  +++ jk_uriEnv.c   2 Oct 2002 10:27:17 -   1.35
  @@ -104,10 +104,10 @@
   uriEnv->virtual = uriEnv->pool->pstrdup(env, uriEnv->pool, host);
   return JK_OK;
   }
  -if (colon) {
  -*uri = '\0';
  +*uri = '\0';
  +if (colon)
   uriEnv->port = atoi(colon);
  -}
  +   
   /* If it doesn't start with /, it must have a vhost */
   if (strlen(host) && uri != host) {
   uriEnv->virtual = uriEnv->pool->calloc( env, uriEnv->pool, strlen(host) + 1 
);
  @@ -133,7 +133,9 @@
   return uriEnv->uri;
   } else if( strcmp( name, "group" )==0 ) {
   return uriEnv->workerName;
  -}
  +} else if( strcmp( name, "context" )==0 ) {
  +return uriEnv->contextPath;
  +}
   return NULL;
   }
   
  @@ -387,7 +389,7 @@
   return JK_OK;
   }
   
  -static char *myAttInfo[]={ "host", "uri", "group", NULL };
  +static char *myAttInfo[]={ "host", "uri", "group", "context", NULL };
   
   int JK_METHOD jk2_uriEnv_factory(jk_env_t *env, jk_pool_t *pool,
jk_bean_t *result,
  
  
  

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

JK 1.2.0 binaries for iSeries

[Henri Gomez]

Well it may be a premiere on Apache.

You could find an iSeries binary at:

http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/bin/iseries/

It's an OS400 SAVF, built on V5R1, but should works on V5R2,
which is zipped to save place.

On V5R1/V5R2 you should have the latest Apache 2.0 PTFs installed, the
one's which provide Apache 2.0.39.

Quicks instructions :

- Unzip MOD_JK.zip on you workstation (PC/Unix) and will get a MOD_JK.SAVF.

- Go to iSeries, create a SAVF enveloppe, ie :

CRTSAVF FILE(MYLIB/MOD_JK) TEXT('MOD_JK VERSION 1.2.0 iSeries')

- Send the MOD_JK file via ftp in binary into MYLIB.

- on iSeries restore SAVF :

RSTLIB SAVLIB(MOD_JK) DEV(*SAVF) SAVF(MYLIB/MOD_JK)

- You could use the new MOD_JK Apache module from the MOD_JK
   library :

# Apache Default server configuration
# LoadModule jk_module /QSYS.LIB/QHTTPSVR.LIB/QZTCJK.SRVPGM
LoadModule jk_module /QSYS.LIB/MOD_JK.LIB/MOD_JK.SRVPGM

- Or if you want to have it next to others Apache modules,
   you should copy the MOD_JK.SRVPGM to iSeries Apache 2.0.39
   module library :

CRTDUPOBJ OBJ(MOD_JK) FROMLIB(MOD_JK) OBJTYPE(*SRVPGM)
TOLIB(QHTTPSVR) NEWOBJ(MOD_JK)

MOD_JK SRVPGM is now installed on iSeries Apache modules :

- You should next add MOD_JK module to one of your Apache Server
instance by editing the Server Configuration and commenting
IBM provided MOD_JK (QZTCJK.SRVPGM)



# Apache Default server configuration
# LoadModule jk_module /QSYS.LIB/QHTTPSVR.LIB/QZTCJK.SRVPGM
LoadModule jk_module /QSYS.LIB/QHTTPSVR.LIB/MOD_JK.SRVPGM

...

I recommand you to read the documentation about configuring
Apache 2.0 on iSeries at :

http://www-1.ibm.com/servers/eserver/iseries/software/http/product/gui.html





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

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

[mturk]

mturk   2002/10/02 02:49:17

  Modified:jk/native2/common jk_uriMap.c
  Log:
  1. Correct webapps for standalone context statements inside any uri
  2. Add the contextMap (not sure if that is the correct name)
  
  The contextMap purpose is to map the uri with the prefix without the prefixes
  trailing slash, doing exact match. This allows mappings of /example if we
  only have /example/* directive, but sill alowing /examle/ as a true prefix
  match, not returning error for if we have /exam/* application too.
  
  Revision  ChangesPath
  1.46  +190 -91   jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c
  
  Index: jk_uriMap.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c,v
  retrieving revision 1.45
  retrieving revision 1.46
  diff -u -r1.45 -r1.46
  --- jk_uriMap.c   26 Sep 2002 12:29:17 -  1.45
  +++ jk_uriMap.c   2 Oct 2002 09:49:16 -   1.46
  @@ -171,14 +171,32 @@
   if (uriLen < uwr->prefix_len)
   continue;
   if (strncmp(uri, uwr->prefix, uwr->prefix_len) == 0) {
  -if (uwr->prefix_len > best_match) {
  +if (uwr->prefix_len > best_match) {
   best_match=uwr->prefix_len;
  -match=uwr;
  +match=uwr;
   }
   }
   }
   return match;
   }
  +
  +static jk_uriEnv_t *jk2_uriMap_contextMap(jk_env_t *env, jk_uriMap_t *uriMap,
  +  jk_map_t *mapTable, const char *uri, 
  +  int uriLen)
  +{
  +int i;
  +int sz = mapTable->size(env, mapTable);
  +
  +for (i = 0; i < sz; i++) {
  +jk_uriEnv_t *uwr = mapTable->valueAt(env, mapTable, i);
  +if (uriLen != uwr->prefix_len - 1)
  +continue;
  +if (strncmp(uri, uwr->prefix, uriLen) == 0) {
  +return uwr;
  +}
  +}
  +return NULL;
  +}
   
   static jk_uriEnv_t *jk2_uriMap_exactMap(jk_env_t *env, jk_uriMap_t *uriMap,
   jk_map_t *mapTable, const char *uri, 
  @@ -276,6 +294,151 @@
   }
   return uriMap->vhosts->get(env, uriMap->vhosts, "*");
   }
  +
  +static void jk2_uriMap_createHosts(jk_env_t *env, jk_uriMap_t *uriMap)
  +{
  +int i;
  +
  +for (i = 0; i < uriMap->maps->size(env, uriMap->maps); i++) {
  +jk_uriEnv_t *uriEnv = uriMap->maps->valueAt(env, uriMap->maps, i);
  +if (uriEnv == NULL) 
  +continue;
  +if (uriEnv->virtual != NULL && strlen(uriEnv->virtual)) {
  +if (uriEnv->match_type == MATCH_TYPE_HOST) {
  +jk2_map_default_create(env, &uriEnv->webapps, uriMap->pool);
  +uriMap->vhosts->put(env, uriMap->vhosts,
  +uriEnv->virtual, uriEnv, NULL);
  +} 
  +else { /* Create the missing vhosts */
  +if (!uriMap->vhosts->get(env, uriMap->vhosts,
  + uriEnv->virtual)) {
  +jk2_map_default_create(env, &uriEnv->webapps, uriMap->pool);
  +uriMap->vhosts->put(env, uriMap->vhosts,
  +uriEnv->virtual, uriEnv, NULL);
  +
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
  +  "uriMap.init() Fixing Host %s\n", 
  +  uriEnv->virtual);
  +}
  +}
  +}
  +}
  +
  +/** Make sure each vhost has a default context
  + */
  +for(i = 0; i < uriMap->vhosts->size(env, uriMap->vhosts); i++) {
  +jk_uriEnv_t *hostEnv = uriMap->vhosts->valueAt(env, uriMap->vhosts, i);
  +jk_uriEnv_t *rootCtx;
  +char *uriPath;
  +
  +if (hostEnv->virtual != NULL) {
  +uriPath=env->tmpPool->calloc(env, env->tmpPool,
  + strlen(hostEnv->virtual) + 3);
  +strcpy(uriPath, hostEnv->virtual);
  +strcat(uriPath, "/");
  +} else {
  +uriPath = "/";
  +}
  +
  +rootCtx = env->getByName2(env, "uri", uriPath);
  +if (rootCtx == NULL) {
  +env->createBean2(env, uriMap->mbean->pool, "uri", uriPath);
  +rootCtx = env->getByName2(env, "uri", uriPath);
  +if (uriMap->mbean->debug > 0) 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
  +  "uriMap.init() Create default context %s\n", 
uriPath);
  +rootCtx->mbean->setAttribute(env, rootCtx->mbean, "context", "/");
  +}
  +}
  +}
  +
  +static void jk2_uriMap_createWebapps(jk_env_t *env, jk_uriMap_t *uriMap)
  +{
  +int i;
  +
  +/* Init

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

[mturk]

mturk   2002/10/02 02:45:02

  Modified:jk/native2/common jk_uriEnv.c
  Log:
  Remove the APR code from the uriEnv.
  
  Revision  ChangesPath
  1.34  +7 -52 jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c
  
  Index: jk_uriEnv.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- jk_uriEnv.c   26 Sep 2002 12:29:17 -  1.33
  +++ jk_uriEnv.c   2 Oct 2002 09:45:02 -   1.34
  @@ -69,8 +69,6 @@
   #include "jk_uriMap.h"
   #include "jk_registry.h"
   
  -#ifdef HAS_APR
  -#include "apr_uri.h"
   /** Parse the name:
  VHOST/PATH
   
  @@ -82,46 +80,6 @@
   static int jk2_uriEnv_parseName( jk_env_t *env, jk_uriEnv_t *uriEnv,
char *name)
   {
  -
  -apr_uri_t uri;
  -char s[1024];
  -
  -/* If it uri starts with / then it is simple 
  - * default host uri
  - */
  -if (*name == '/')
  -strcpy(s, name);
  -else {
  -strcpy(s, "http://";);
  -strcat(s, name);
  -}
  -env->l->jkLog(env, env->l, JK_LOG_DEBUG,
  -  "uriEnv.parseName() uri %s name %s real %s\n", 
  -  uriEnv->name, name, s);
  -
  -if (apr_uri_parse(uriEnv->pool->_private, s, &uri) == APR_SUCCESS) {
  -
  -uriEnv->port = uri.port;
  -if (uri.hostname) {
  -if (!uriEnv->port)
  -uriEnv->virtual = uri.hostname;
  -else
  -uriEnv->virtual = apr_pstrcat(uriEnv->pool->_private,
  -uri.hostname, ":", uri.port_str, NULL);
  -}
  -else
  -uriEnv->virtual = "*";
  -uriEnv->uri = uri.path;
  -if (!uri.path)
  -uriEnv->match_type = MATCH_TYPE_HOST;
  -return JK_OK;
  -}
  -return JK_ERR;
  -}
  -#else
  -static int jk2_uriEnv_parseName( jk_env_t *env, jk_uriEnv_t *uriEnv,
  - char *name)
  -{
   char *uri = NULL;
   char *colon;
   char host[1024];
  @@ -162,7 +120,6 @@
   
   return JK_OK;
   }
  -#endif /* HAS_APR */
   
   
   static void * JK_METHOD jk2_uriEnv_getAttribute(jk_env_t *env, jk_bean_t *bean,
  @@ -397,18 +354,16 @@
   } else {
   /* context based /context/prefix/ASTERISK  */
   asterisk[1]  = '\0';
  -#if 0
  -asterisk[0]  = '\0'; /* Remove the extra '/' */
  -#endif
  +
   uriEnv->suffix  = NULL;
   uriEnv->prefix  = uri;
   uriEnv->prefix_len  =strlen( uriEnv->prefix );
  -uriEnv->match_type  = MATCH_TYPE_PREFIX;
  -if( uriEnv->mbean->debug > 0 ) {
  -env->l->jkLog(env, env->l, JK_LOG_DEBUG,
  -  "uriEnv.init() prefix mapping %s=%s\n",
  -  uriEnv->prefix, uriEnv->workerName);
  -}
  +uriEnv->match_type  = MATCH_TYPE_PREFIX;
  +if( uriEnv->mbean->debug > 0 ) {
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
  +  "uriEnv.init() prefix mapping %s=%s\n",
  +  uriEnv->prefix, uriEnv->workerName);
  +}
   }
   } else {
   /* Something like : JkMount /servlets/exampl* ajp13 */
  
  
  

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

[JK2] uriMap processing, need some opinions

[Mladen Turk]

Hi,

Having some trouble clarifying uriMap processing.


Situation 1:

[uri:/examples/*]

The context is /

Situation 2:

[uri:/examples/*]
context=/ex

The context is /ex

Situation 3:

[uri:/examples/*]
context=/examples

The context is /examples


Now since all situations need the /examples/ as a prefix match, (to be
able to sepate things like /examples/servlet/ uri with
/examples/servlests/* mapping). We have a problem accesing /examples
(without a trailing slash).

The third situation can be solved returning context if no match is found
and the uri equals to context. Is this right thing to do, and could it
be used even before the prefixMatch?.

The other two situations having context different then a uri could be
solved by adding the trailing slash to the uri (in case there isnt one)
and doing prefix match again.


So:
Situation 1 and 2:
uriRequest /examples will find context '/' and no match, and since it
doesn't ends with the trailing slash it will be added and we'll rerun
prefixMatch returning /examples/ inside the root context.

Situation 3:

uriRequest /examples will find context '/examples' and no match, and
since it doesn't ends with the trailing slash it will be added and we'll
rerun prefixMatch returning /examples/ inside the '/examples' context.


MT.


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

DO NOT REPLY [Bug 13194] New: - refreshing JSP containing a body tag gives problem on alternate refresh

[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=13194

refreshing JSP containing a body tag gives problem on alternate refresh

   Summary: refreshing JSP containing a body tag gives problem on
alternate refresh
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


suspect that the release() is not executed after the taghandler instance's 
lifecycle has ended.

to produce bug, 
1. copy the tld file to webapp root. 
2. compile the tag handler to /WEB-INF/classes. 
3. copy test.jsp to server and access it.
4. refresh the page(test.jsp), java.lang.ArrayIndexOutOfBoundsException will be 
encountered on alternate browser refresh.


tld file
--

http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd";>

  1.0
  1.1
  test
  
A tag library for the pagination, product of Ecquaria Technologies Pte Ltd.
http://www.ecquaria.com/.
  


loop
test.ArrayTag






Taghandler
---
package test;
import java.io.*;
import java.util.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
import javax.servlet.jsp.tagext.*;

public class ArrayTag extends BodyTagSupport{
private BodyContent bodyContent;
private int index = -1;
private final int[] data = new int[] {0, 1, 2};

// tag support interface methods //
public void setBodyContent(BodyContent b) {
this.bodyContent = b;
}

  /**
   * Method called at start of Tag
   * @return either a EVAL_BODY_TAG or a SKIP_BODY
   */
public int doStartTag() throws javax.servlet.jsp.JspException {
return EVAL_BODY_TAG;
}//doStartTag

//only only be called at most once
public void doInitBody() throws JspException {}

//@return EVAL_BODY_TAG, SKIP_BODY
public int doAfterBody() throws JspException{
++index;
System.out.print("[ArrayTag] index: " + index );
System.out.println(", current data: " + data[index]);
return (index
<%
  int iii = 0;
  System.out.println("\n\n-");
%>



hi there!

<%
System.out.println("iii: " + (iii++));
%>





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

DO NOT REPLY [Bug 12783] - Coyote Connector and HTTP 1.0 Keep-Alive

[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=12783

Coyote  Connector and HTTP 1.0 Keep-Alive

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
 Status|RESOLVED|REOPENED
 Resolution|INVALID |
Version|4.0.4 Final |4.1.12



--- Additional Comments From [EMAIL PROTECTED]  2002-10-02 09:00 ---
This is happening me with the coyote connector in Tomcat 4.1.12

Using a HTTP/1.0 client to POST a request using Keep-Alive, tomcat fails to 
send the Connection: Keep-Alive header back to the client, although it does 
indeed keep the connection open. While it is correct behavior for HTTP/1.1 to 
omit the keep-alive response header, it is incorrect under HTTP/1.0

Changing the following in coyote's Http11Processor.java fixes it:

old:
if (!keepAlive) {
response.addHeader("Connection", "close");
}
new:

if (!keepAlive) {
response.addHeader("Connection", "close");
} else if (!http11) {
response.addHeader("Connection", "Keep-Alive");
}

--ctwomey

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

Re: Ajp13 wrong Response

[Vince Clark]

I have been turning over every stone I can find. Still no progress. I 
haven't ruled out a session problem but can't come up with a good way to 
reproduce the error. It would have to involve some way of accepting 
multiple cookies and making requests using each one.

Do you know of any good documentation on how TC recycles sessions? I 
read a posting on the comp.lang.java newsgroup that eluded to the 
possibility of session attributes persisting in sessions that time out 
and are recycled.

I also haven't ruled out a problem with my code, and it would make sense 
that this is where the problem lies since nobody else seems to be having 
any similar problems.


Henri Gomez wrote:

> Vince Clark wrote:
>
>> I found this post while researching the mail list archives for a 
>> problem I am having. The description Henri provides sounds exactly 
>> like what is happening with my application. I have included the 
>> original threads below.
>>
>> Prior to reading this posting I had not come to Henri's conclusion:
>>
>> "Under certain conditions some request get the response for some 
>> other request"
>
>
> Hum, it came from prehistory ;-)
>
> With ajp13 and Tomcat 3.2.x, and should really be fixed with Tomcat 
> 3.3.1.
>
> i didn't see such behaviour for months
>
>
>
> -- 
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 


-- 
Vince Clark
Global Era, LLC
Software, Database, and Web Solutions
(303)433-4221 office
(303)455-2409 fax
[EMAIL PROTECTED] 
www.globalera.net




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

Re: Ajp13 wrong Response

[Henri Gomez]

Vince Clark wrote:
> I found this post while researching the mail list archives for a problem 
> I am having. The description Henri provides sounds exactly like what is 
> happening with my application. I have included the original threads below.
> 
> Prior to reading this posting I had not come to Henri's conclusion:
> 
> "Under certain conditions some request get the response for some other 
> request"

Hum, it came from prehistory ;-)

With ajp13 and Tomcat 3.2.x, and should really be fixed with Tomcat 3.3.1.

i didn't see such behaviour for months



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

Re: [VOTE] JK2 2.1

[Henri Gomez]

jean-frederic clere wrote:
> Henri Gomez wrote:
> 
>> More comments on APR and JK2.
>>
>> While making tomcat-connectors rpm for jk2, and also
>> jk2 binaries for Linux, I wanted to have apache 1.3 jk2
>> built with JNI support.
>>
>> JNI support in JK2 requires APR.
>>
>> So I build an apr 0.9.1 rpm, which include apr-utils
>> since apr-utils couldn't be built without apr ;-[
>>
>> To avoid conflict with Apache 2.0 rpms, I've installed
>> apr libs in /usr/lib/apr/ and includes in /usr/include/apr.
>>
>> And here we allready discover many interesting things :
>>
>> With Apache 2.0, libapr shared lib in name libapr.so.0.9.2.
>> With APR build, it's called libapr-0.so.0.9.2.
>>
>> What you see also is that is seems that parts of apr-utils
>> are included in Apache2 binaries (ie md5 stuff), so when
>> you're using APR libs, you should add apr and aprutils to
>> ldpath (-lapr -laprutils).
>>
>> With that I was thinking being ready to make Apache 1.3
>> works with APR, for JNI use purposes.
>>
>> I've used :
>>
>> ./configure --with-apxs=/usr/sbin/apxs --with-jni 
>> --with-apr-lib=/usr/lib/apr --with-apr-include=/usr/include/apr
>>
>> The build works but I saw that the mod_jk2.so was linked against
>> /usr/lib/libapr.so (the one from Apache 2.0 built) against the one
>> in /usr/lib/arp.
>>
>> So I patched Makefile.in to change -lapr to -lapr-0.
>>
>> here correct build and link.
> 
> 
> That is not enough you should use apr-config.
> I have already patched mod_webapp for that.

Could you do the same for jk2, but it should be only if --with-apr
is present...





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

Re: Ajp13 wrong Response

[Vince Clark]

I found this post while researching the mail list archives for a problem 
I am having. The description Henri provides sounds exactly like what is 
happening with my application. I have included the original threads below.

Prior to reading this posting I had not come to Henri's conclusion:

"Under certain conditions some request get the response for some other request"

I was convinced my problem was related to how I was handling sessions, 
or how Tomcat recycles them. But I have exhausted all resources I can 
think of or find. This is the only thing I have found that comes close 
to my problem. I will admit upfront that I am no expert in Tomcat 
configuration.

Four or five users have contacted me with the same issue, which is 
basically that when they login to my app they see data intended for 
another user. Load is probably 40 to 50 concurrent users. I cannot 
reproduce the problem and it seems to be very isolated, with only a few 
occurences over the past week or so.

My environment is Red Hat Linux 7.2, Tomcat 3.3.1, Apache 1.3.22, 
Postgres 7.1.3. User authentication is performed against Postgres and 
userid is stored in a session attribute, along with a few other attributes.

In the 3.3.1 release notes bug 6234 was listed as resolved. I read the 
contents of the bug and tried the TestServlet you provided to reproduce 
the error. I still couldn't reproduce the problem which would make since 
if I am running a version of Tomcat that is supposed to include the fix. 
I also ran the TestServlet on 3.2.3 and couldn't reproduce. Although 
nothing indicates that the bug existed prior to 3.3.

In the TestServlet you indicate that the workaround is to use 
response.getOutputStream() instead of response.getWriter(). I am using 
getOutputStream().

I realize that I may not have the same problem but would appreciate any 
insight you could provide.


---Original Threads-

Actually, you don't need to load the system (that's the good news).  It's
not a synchronization problem.  It looks like it is a problem with error
handling, but I haven't tracked down where so I can't send a patch yet.  It
seems that when you get an error, the writer gets stuck in it's last
successful request and always sends that one.  I've reverted
HttpServletResponseFacade to always throwing away it's writer on recycle (so
that my developers can actually get work done)  as a stop-gap and that seems
to have made it go away.  Of course, this is far from ideal.  What you need
to start seeing this is something like:

public class BadServlet extends HttpServlet {

  protected void doGet(HttpServletRequest request, HttpServletResponse
response)
  throws ServletException, IOException {
 PrintWriter out = response.getWriter();
 out.println("Hello World");
 throw new IOException("Hi Mom!");
}
}
- Original Message -
From: "GOMEZ Henri" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 03, 2001 7:45 AM
Subject: RE: Ajp13 wrong Response


> Very difficult to reproduce a situation under heavy load.
> I stressed my Apache/TC with ab during nigths without
> any failures but It was against simple servlets
>
> -
> Henri Gomez ___[_]
> EMAIL : [EMAIL PROTECTED](. .)
> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>
>
>
> >-Original Message-
> >From: Angel Aray [mailto:[EMAIL PROTECTED]]
> >Sent: Tuesday, July 03, 2001 2:46 PM
> >To: [EMAIL PROTECTED]
> >Subject: RE: Ajp13 wrong Response
> >
> >
> >
> >I'll try that, but the problem I am seeing is with tomcat as late
> >as TC 3.3-M3.
> >
> >-Original Message-
> >From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> >Sent: Martes, 03 de Julio de 2001 04:10 a.m.
> >To: [EMAIL PROTECTED]
> >Subject: RE: Ajp13 wrong Response
> >
> >
> >>> I am having a problem which is very difficult to reproduce.
> >>Under certain
> >>> conditions some request get the response for some other
> >>request. It looks
> >>> like at some point probably due to some synchronization
> >issues tomcat
> >>> mixes de responses from different clients.
> >
> >It was a known problem in early age of TC 3.3, with RequestDispatcher.
> >Could you try a fresh install of TC 3.3-M4 ?
> >
> >>> I hadn't seen this behavior before, but since I moved  from
> >>using just
> >>> tomcat to using apache + mod_jk + tomcat it has occurred a couple of
> >>times.
> >>>
> >>> Has anyone seen this kind of behavior before?
> >>>
> >>>
> >>> I am using apache_1.3.20, tomcat33-m3.
> >>>
> >>>
> >>
> > 



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

Re: Tomcat 4.1.12 and Servlet Access 404 Errors: BUG?

[Michael Smith]

micael wrote:
> 
> I cannot see any difference relative to the invoker filter, ExampleFilter,
> in the web.xml for Tomcat 4.1.10 versus 4.1.12.  Nothing seems to be
> commented out.  I must be missing some point here.  What is it?

The invoker servlet, whilst still defined in 4.1.12, has no
servlet-mapping defined for it in that version (it's commented out). All
of this is in the default/fallback conf/web.xml

Michael

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

DO NOT REPLY [Bug 12069] - Creation of more HttpSession objects for one previously timed out session

[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=12069

Creation of more HttpSession objects for one previously timed out session





--- Additional Comments From [EMAIL PROTECTED]  2002-10-02 07:34 ---
Hey, what is this bug list for?
If there is a bug report without any reaction for more than one month, there 
must be something wrong. At least a notice "we know about this issue, but we 
will not fix it in 4.x" would be polite.
An example:
When I have submitted a bug to a cURL bug list, the problem was fixed the same 
day.

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