subject:"404"


Hello,

I am currently installing and configuring a webserver with the couple 
httpd/tomcat.

This server hosts many tomcat applications, each one with its own hostname.


My current Tomcat configuration is something like that :

   Host name=appli1.domain.fr  appBase=/var/www/appli1
   unpackWARs=true autoDeploy=true xmlValidation=false
   xmlNamespaceAware=false
   Context path= docBase=/var/www/appli1 crossContext=false
...
   Host name=appli2.domain.fr  appBase=/var/www/appli2
   unpackWARs=true autoDeploy=true xmlValidation=false
   xmlNamespaceAware=false
   Context path= docBase=/var/www/appli2 crossContext=false
...

The httpd VHost configuration is:

   VirtualHost *:80
ServerName appli1.domain.fr
ProxyPass / ajp://appli1.domain.fr:8009/ retry=1
...

   VirtualHost *:80
ServerName appli2.domain.fr
ProxyPass / ajp://appli2.domain.fr:8009/ retry=1
...

It's working for every applications except the appli2.
The appli2 interprets the index.jsp which redirects to 
http://appli2.domain.fr/stylesheets/welcome.faces.
At this point I have a 404 error : /The requested resource 
(/stylesheets/cas.faces) is not available./


How could it interprets the index.jsp but then cannot find the 
/stylesheets/welcome.faces ?

Does it come from my configuration or may it come from the application ?


I have tried a different Tomcat configuration :

   Host name=localhost  appBase=webapps unpackWARs=true
   autoDeploy=true xmlValidation=false xmlNamespaceAware=false
   Context path= docBase=/var/www/appli2 crossContext=false
...

Then the apache2 vhost :

   VirtualHost *:80
ServerName appli2.domain.fr
ProxyPass / ajp://localhost:8009/ retry=1
...


This one works fine but I would like to understand where does the 
problem comes from.



Regards,
arnaud

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Error 404 when redirected

2010-10-07 Thread André Warnier


arnaud icard wrote:
...


It's working for every applications except the appli2.
The appli2 interprets the index.jsp which redirects to 
http://appli2.domain.fr/stylesheets/welcome.faces.
At this point I have a 404 error : /The requested resource 
(/stylesheets/cas.faces) is not available./


How could it interprets the index.jsp but then cannot find the 
/stylesheets/welcome.faces ?

Does it come from my configuration or may it come from the application ?


Hi.
I have no idea if this may be the cause of the problem, but I notice a discrepancy between 
what you are writing, and the error message.

It is not complaining about the welcome.faces, but about not finding the 
cas.faces.
May it be that there is a link in welcome.faces which should point to cas.faces, but 
is incorrect ?



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Error 404 when redirected

2010-10-07 Thread Caldarale, Charles R

 From: arnaud icard [mailto:arnaud.ic...@univ-avignon.fr] 
 Subject: Error 404 when redirected

 I am currently installing and configuring a 
 webserver with the couple httpd/tomcat.

Exact versions?

 My current Tomcat configuration is something like that :
 Host name=appli1.domain.fr  appBase=/var/www/appli1 
 unpackWARs=true autoDeploy=true xmlValidation=false
 xmlNamespaceAware=false
    Context path= docBase=/var/www/appli1 crossContext=false

The above is seriously broken.  First, it is absolutely illegal to have the 
appBase the same as docBase.  Second, you should not be placing Context 
elements in server.xml.  Third, each Host should have a unique appBase 
directory.  Fourth, the default webapp for a given appBase must be named ROOT 
(case sensitive).

Remove the Context elements from server.xml, and restructure your file layout 
to look like this:

/
var/
  www/
appli1/
  ROOT/
META-INF/
  context.xml
WEB-INF/
  classes/
  lib/
other appli1 directories and files
appli2/
  ROOT/
META-INF/
  context.xml
WEB-INF/
  classes/
  lib/   
other appli2 directories and files

The context.xml file in each ROOT's META-INF directory can actually be omitted 
for the two webapps you showed, since it would contain no useful information 
(the path and docBase attributes must not be used here).  Only if you had some 
non-default attribute to specify would you create a Context element inside it.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Error 404 when redirected


Hi André,

this difference is due to a slight modification I made.
The error is the same with the original code.



André Warnier a écrit le 07/10/2010 12:33:

arnaud icard wrote:
...


It's working for every applications except the appli2.
The appli2 interprets the index.jsp which redirects to 
http://appli2.domain.fr/stylesheets/welcome.faces.
At this point I have a 404 error : /The requested resource 
(/stylesheets/cas.faces) is not available./


How could it interprets the index.jsp but then cannot find the 
/stylesheets/welcome.faces ?

Does it come from my configuration or may it come from the application ?


Hi.
I have no idea if this may be the cause of the problem, but I notice a 
discrepancy between what you are writing, and the error message.
It is not complaining about the welcome.faces, but about not finding 
the cas.faces.
May it be that there is a link in welcome.faces which should point 
to cas.faces, but is incorrect ?



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Error 404 when redirected




Caldarale, Charles R a écrit le 07/10/2010 13:50:

I am currently installing and configuring a
webserver with the couple httpd/tomcat.
 

Exact versions?
   


httpd : Apache/2.2.9 (Debian)
tomcat : Apache Tomcat/6.0.29


My current Tomcat configuration is something like that :
Host name=appli1.domain.fr  appBase=/var/www/appli1
unpackWARs=true autoDeploy=true xmlValidation=false
xmlNamespaceAware=false
 Context path= docBase=/var/www/appli1 crossContext=false
 

The above is seriously broken.  First, it is absolutely illegal to have the 
appBase the same as docBase.
Indead. This page helped me to understand why : 
http://www.lisnichenko.com/articles/tomcat-appbase-and-docbase.html

Second, you should not be placingContext  elements in server.xml.
This is not completly true : 
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html

I quote the webpage :

   *Context* elements may be explicitly defined:

   * ...
   * Inside a Host element in the main conf/server.xml.

This is what I did there. But I guess this is the complete opposite to 
what is written just above on the same webpage.

Third, eachHost  should have a unique appBase directory.

This is already the case, isn't it?

Fourth, the default webapp for a given appBase must be named ROOT (case 
sensitive)
   
I had to made an exception for an application (uPortal) which is 
deployed in an uPortal/ folder

But I corrected this for the others.

Remove theContext  elements from server.xml, and restructure your file layout 
to look like this:
   

Most of these applications are deployed using /ant deploy/.
Thus I cannot place context file in the application/ROOT/META-INF (well 
I could but it would mean that I had to copy the context file each time 
I launch /ant deploy/)



So I now have the following server.xml :

   Host name=appli1.domain.fr  appBase=/var/www/appli1
   unpackWARs=true autoDeploy=true xmlValidation=false
   xmlNamespaceAware=false
   Context path= docBase=ROOT crossContext=false
...
   Host name=appli2.domain.fr  appBase=/var/www/appli2
   unpackWARs=true autoDeploy=true xmlValidation=false
   xmlNamespaceAware=false
   Context path= docBase=ROOT crossContext=false
   ...
   Host name=uportal.domain.fr  appBase=/var/www/uportal
   unpackWARs=true autoDeploy=true xmlValidation=false
   xmlNamespaceAware=false
   Context path= docBase=uportal crossContext=false
...
   Context path=/ResourceServingWebapp
   docBase=ResourceServingWebapp crossContext=false
   ...

The file layout for uportal is (yes 2 times uportal):
/var/www/uportal/
uportal/
ResourceServingWebapp/


Everything works fine... but I don't get why I had to specify ROOT in 
the docBase argument. Is it not the value by default ?


Regards,
arnaud


/
var/
   www/
 appli1/
   ROOT/
 META-INF/
   context.xml
 WEB-INF/
   classes/
   lib/
 other appli1 directories and files
 appli2/
   ROOT/
 META-INF/
   context.xml
 WEB-INF/
   classes/
   lib/
 other appli2 directories and files

The context.xml file in each ROOT's META-INF directory can actually be omitted for 
the two webapps you showed, since it would contain no useful information (the path 
and docBase attributes must not be used here).  Only if you had some non-default 
attribute to specify would you create aContext  element inside it.

  - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

   

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Error 404 when redirected

2010-10-07 Thread Caldarale, Charles R

 From: arnaud icard [mailto:arnaud.ic...@univ-avignon.fr] 
 Subject: Re: Error 404 when redirected

  Second, you should not be placing Context elements in server.xml.
 This is not completly true

Note that I said should not rather than must not.  You can place Context 
elements in server.xml, but it is not best practice, and is strongly 
discouraged.  Don't do it.

  Third, each Host should have a unique appBase directory.
 This is already the case, isn't it?

Not really, since docBase == appBase in your original config.  Your original 
configuration was ambiguous.

 Most of these applications are deployed using ant deploy.

Not relevant.

 Thus I cannot place context file in the application/ROOT/META-INF 

Of course you can.  However, as I stated earlier, you don't actually need any 
Context elements in the examples you gave.

 So I now have the following server.xml :
   Context path= docBase=ROOT crossContext=false

Just remove the Context elements like the above - they're unnecessary.

    Context path= docBase=uportal crossContext=false

Remove that one as well, and change the uportal directory name to ROOT.

    Context path=/ResourceServingWebapp docBase=ResourceServingWebapp 
crossContext=false

That Context element is also not necessary - remove it.

 The file layout for uportal is (yes 2 times uportal): 
 /var/www/uportal/
     uportal/

Change the above to ROOT/.

     ResourceServingWebapp/

That one is fine.

 I don't get why I had to specify ROOT in the docBase argument.

You shouldn't have a docBase argument, because you don't need any Context 
elements at all.

 Is it not the value by default ?

No; there is no default for docBase, since it should be used only when a 
Context element is in conf/Catalina/[host]/[appName].xml, and the associated 
webapp is located outside of the Host's appBase directory.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Error 404 when redirected

Thank you for these explanations Chuck!

Caldarale, Charles R a écrit le 07/10/2010 15:38:

From: arnaud icard [mailto:arnaud.ic...@univ-avignon.fr]
Subject: Re: Error 404 when redirected

Second, you should not be placingContext  elements in server.xml.

This is not completly true

Note that I said should not rather than must not.  You can placeContext  
elements in server.xml, but it is not best practice, and is strongly discouraged.  Don't do it.

Third, eachHost  should have a unique appBase directory.

This is already the case, isn't it?

Not really, since docBase == appBase in your original config.  Your original 
configuration was ambiguous.

Most of these applications are deployed using ant deploy.

Not relevant.

Thus I cannot place context file in the application/ROOT/META-INF

Of course you can.  However, as I stated earlier, you don't actually need 
anyContext  elements in the examples you gave.

So I now have the following server.xml :
Context path= docBase=ROOT crossContext=false

Just remove theContext  elements like the above - they're unnecessary.

 Context path= docBase=uportal crossContext=false

Remove that one as well, and change the uportal directory name to ROOT.

 Context path=/ResourceServingWebapp docBase=ResourceServingWebapp 
crossContext=false

ThatContext  element is also not necessary - remove it.

The file layout for uportal is (yes 2 times uportal):
/var/www/uportal/
 uportal/

Change the above to ROOT/.

 ResourceServingWebapp/

That one is fine.

I don't get why I had to specify ROOT in the docBase argument.

You shouldn't have a docBase argument, because you don't need anyContext  
elements at all.

Is it not the value by default ?

No; there is no default for docBase, since it should be used only when aContext  
element is in conf/Catalina/[host]/[appName].xml, and the associated webapp is located 
outside of theHost's appBase directory.

  - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Webapp reloading issue and intermittent 404 errors

2010-08-09 Thread Tomislav Petrović

Caldarale, Charles R said on 8.7.2010 3:31:

From: Caldarale, Charles R
Subject: RE: Webapp reloading issue and intermittent 404 errors

Given the test on lines 129-130, it is impossible to have a -1 at line
131 - unless there's a JVM bug.

6u21 was just released tonight, so you might give that a shot and see if the 
problem has been addressed.

Included in 6u21 are fixes for the problems described here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6875866
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6935535

Both seem to have a lot in common with the issue under discussion.

There's another String-related fix in the bug list, but the details are not 
retrievable at the moment:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6948602

Just to let you know, installing 6u21 seems to solve problem completely 
(hasn't manifested after upgrade at all).

--
Tomy t.petro...@inet.hr

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: 404 with mod_jk

2010-07-15 Thread Michael Powe



On Thu, Jul 15, 2010 at 01:52:17AM -0400, Michael Powe wrote:
 On Thu, Jul 15, 2010 at 02:28:52AM +0200, André Warnier wrote:
  Michael Powe wrote:
 
  To install mod_jk, I resorted to my good friend Google, and used a
  tutorial to set up the connector.  In that tutorial, the method used
  was to create a properties file (workers.properties) which set up the
  worker `worker1'.  
  ...
  I'm installing a clean version of Apache, built from httpd.apache.org
  sources, in /usr/local in order to get around all the weird (IMO)
  configuration for the version installed in Ubuntu by default.  At this
  point, I've fiddled so many things I've lost track of where I'm at.
  Sometimes, when you can't get something to work, it's best to return
  to first principles.
 
  I will not often say this, but I believe your problems may stem from the 
  above, and that you would do better by using the pre-packaged versions of 
  things (except Tomcat)
 
  1) it is hard to judge the correctness of a tutorial found on Google.
  The mod_jk instructions on the mod_jk pages of the Tomcat website are 
  pretty good, and they are at least accurate and up-to-date.
 
 True.  One of them was the `quick start for the impatient' on the
 mod_jk doc page.
  
  2) the standard Apache packages for Debian and Ubuntu are quite good, and a 
  lot easier to install and maintain than working everything out from scratch.
  I suggest the following order :
  apt-get install sun-java6-jdk
  (then Tomcat, but for Tomcat, I suggest installing it from the Tomcat site 
  distribution)
  apt-get install apache2
  apt-get install libapache2-mod-jk
  (the last 2 work out of the box and take max. 3 minutes altogether)

Well, it never rains but it pours.  After doing `sudo apt-get purge
apache2':

po...@ubuntu:~$ sudo apt-get install apache2
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following extra packages will be installed:
  apache2-mpm-worker
The following NEW packages will be installed:
  apache2 apache2-mpm-worker
0 upgraded, 2 newly installed, 0 to remove and 221 not upgraded.
Need to get 0B/3,846B of archives.
After this operation, 119kB of additional disk space will be used.
Do you want to continue [Y/n]? 
Selecting previously deselected package apache2-mpm-worker.
(Reading database ... 166454 files and directories currently
installed.)
Unpacking apache2-mpm-worker (from
.../apache2-mpm-worker_2.2.14-5ubuntu8_i386.deb) ...
Selecting previously deselected package apache2.
Unpacking apache2 (from .../apache2_2.2.14-5ubuntu8_i386.deb) ...
Setting up apache2-mpm-worker (2.2.14-5ubuntu8) ...
No apache MPM package installed

Now, the Apache installation is completely broken and will not install
properly.  That's the problem with these package systems:  no error
messages to indicate what might have gone wrong and nontrivial to
figure it out.  We'll see what they say over in ubuntu forums.  I
could shoot myself or go to bed.  I choose bed.

Thanks.

mp

-- 
Michael Powemich...@trollope.orgNaugatuck CT USA

He speaks well, he's well-read, but he's an idiot.
  -- N.D. Kalu, describing Rush Limbaugh


pgplCYZ1R46Yl.pgp
Description: PGP signature

Re: 404 with mod_jk

2010-07-15 Thread Rainer Jung


On 13.07.2010 23:17, Michael Powe wrote:

Hello,

I asked this question in the httpd list but no joy.

I have set up tomcat 6 and IBM httpd server to proxy requests using
mod_jk.

IBM_HTTP_Server/6.0.2 Apache/2.0.47 (Unix) mod_jk/1.2.30 Server at
localhost Port 80

I have followed all instructions as nearly as I can make
out.

The mod_jk log shows:

[Tue Jul 13 16:41:02 2010] [7639:50215792] [trace]
map_uri_to_worker_ext::jk_uri_worker_map.c (951): enter
[Tue Jul 13 16:41:02 2010] [7639:50215792] [debug]
map_uri_to_worker_ext::jk_uri_worker_map.c (1036): Attempting to map
URI '/TlTaggerTest/target.jsp' from 9 maps
[Tue Jul 13 16:41:02 2010] [7639:50215792] [trace]
find_match::jk_uri_worker_map.c (839): enter
[Tue Jul 13 16:41:02 2010] [7639:50215792] [debug]
find_match::jk_uri_worker_map.c (850): Attempting to map context URI
'/TlTaggerTest/*.jsp=worker1' source 'JkMount'
[Tue Jul 13 16:41:02 2010] [7639:50215792] [debug]
find_match::jk_uri_worker_map.c (863): Found a wildchar match
'/TlTaggerTest/*.jsp=worker1'
[Tue Jul 13 16:41:02 2010] [7639:50215792] [trace]
find_match::jk_uri_worker_map.c (866): exit
[Tue Jul 13 16:41:02 2010] [7639:50215792] [trace]
map_uri_to_worker_ext::jk_uri_worker_map.c (1065): exit


The next lines should have been:

... [7639:50215792] [trace] jk_handler::mod_jk.c (2383): enter
... [7639:50215792] [debug] jk_handler::mod_jk.c (2462): Into handler 
jakarta-servlet worker=worker1 r-proxyreq=0


It seems there is some other module, that handles the request instead of 
mod_jk or the handler is not set correctly. If you compiled to module 
yourself, you can easily find out by applying a little change:


2366 static int jk_handler(request_rec * r)
2367 {
2368 const char *worker_name;
2369 jk_server_conf_t *xconf;
2370 int rc, dmt = 1;
2371
2372 /* We do DIR_MAGIC_TYPE here to make sure TC gets all requests, 
even
2373  * if they are directory requests, in case there are no static 
files
2374  * visible to Apache and/or DirectoryIndex was not used. This 
is only

2375  * used when JkOptions has ForwardDirectories set. */
2376 /* Not for me, try next handler */
2377 if (strcmp(r-handler, JK_HANDLER)
2378  (dmt = strcmp(r-handler, DIR_MAGIC_TYPE)))
2379 return DECLINED;
2380

Before line 2372 add the following lines:

if (JK_IS_DEBUG_LEVEL(xconf-log)) {
jk_log(xconf-log, JK_LOG_DEBUG,
   Starting jk handler, Apache thinks it should use '%s',
   r-handler ? r-handler : NULL);
}

Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: 404 with mod_jk

2010-07-15 Thread Michael Powe

Hello,

Thank you!  I did compile the module myself, wanting to be sure it was
properly compatible with my target environments.

I'll mod the code and see what new information is logged.

Thanks.

mp

On Thu, Jul 15, 2010 at 01:54:48PM +0200, Rainer Jung wrote:
 On 13.07.2010 23:17, Michael Powe wrote:
 Hello,
 
 I asked this question in the httpd list but no joy.
 
 I have set up tomcat 6 and IBM httpd server to proxy requests using
 mod_jk.
 
 IBM_HTTP_Server/6.0.2 Apache/2.0.47 (Unix) mod_jk/1.2.30 Server at
 localhost Port 80
 
 I have followed all instructions as nearly as I can make
 out.
 
 The mod_jk log shows:
 
 [Tue Jul 13 16:41:02 2010] [7639:50215792] [trace]
 map_uri_to_worker_ext::jk_uri_worker_map.c (951): enter
 [Tue Jul 13 16:41:02 2010] [7639:50215792] [debug]
 map_uri_to_worker_ext::jk_uri_worker_map.c (1036): Attempting to map
 URI '/TlTaggerTest/target.jsp' from 9 maps
 [Tue Jul 13 16:41:02 2010] [7639:50215792] [trace]
 find_match::jk_uri_worker_map.c (839): enter
 [Tue Jul 13 16:41:02 2010] [7639:50215792] [debug]
 find_match::jk_uri_worker_map.c (850): Attempting to map context URI
 '/TlTaggerTest/*.jsp=worker1' source 'JkMount'
 [Tue Jul 13 16:41:02 2010] [7639:50215792] [debug]
 find_match::jk_uri_worker_map.c (863): Found a wildchar match
 '/TlTaggerTest/*.jsp=worker1'
 [Tue Jul 13 16:41:02 2010] [7639:50215792] [trace]
 find_match::jk_uri_worker_map.c (866): exit
 [Tue Jul 13 16:41:02 2010] [7639:50215792] [trace]
 map_uri_to_worker_ext::jk_uri_worker_map.c (1065): exit
 
 The next lines should have been:
 
 ... [7639:50215792] [trace] jk_handler::mod_jk.c (2383): enter
 ... [7639:50215792] [debug] jk_handler::mod_jk.c (2462): Into handler 
 jakarta-servlet worker=worker1 r-proxyreq=0
 
 It seems there is some other module, that handles the request instead of 
 mod_jk or the handler is not set correctly. If you compiled to module 
 yourself, you can easily find out by applying a little change:
 
 2366 static int jk_handler(request_rec * r)
 2367 {
 2368 const char *worker_name;
 2369 jk_server_conf_t *xconf;
 2370 int rc, dmt = 1;
 2371
 2372 /* We do DIR_MAGIC_TYPE here to make sure TC gets all requests, 
 even
 2373  * if they are directory requests, in case there are no static 
 files
 2374  * visible to Apache and/or DirectoryIndex was not used. This 
 is only
 2375  * used when JkOptions has ForwardDirectories set. */
 2376 /* Not for me, try next handler */
 2377 if (strcmp(r-handler, JK_HANDLER)
 2378  (dmt = strcmp(r-handler, DIR_MAGIC_TYPE)))
 2379 return DECLINED;
 2380
 
 Before line 2372 add the following lines:
 
 if (JK_IS_DEBUG_LEVEL(xconf-log)) {
 jk_log(xconf-log, JK_LOG_DEBUG,
Starting jk handler, Apache thinks it should use '%s',
r-handler ? r-handler : NULL);
 }
 
 Regards,
 
 Rainer
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

-- 
Michael Powemich...@trollope.orgNaugatuck CT USA
In every country and in every age, the priest has been hostile to
liberty.  He is always in alliance with the despot, abetting his
abuses in return for protection to his own. -- Thomas Jefferson to
Horatio G. Spafford, 1814. ME 14:119


pgpbbwaSM5eFq.pgp
Description: PGP signature

Re: 404 with mod_jk

2010-07-14 Thread Rainer Jung

 
(406): exit
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
ajp_validate::jk_ajp_common.c (2616): exit
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] validate::jk_ajp13_worker.c 
(37): exit
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] init::jk_ajp13_worker.c 
(47): enter
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] ajp_init::jk_ajp_common.c 
(2700): enter
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] ajp_init::jk_ajp_common.c 
(2800): setting endpoint options:
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] ajp_init::jk_ajp_common.c 
(2803): keepalive:  0
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] ajp_init::jk_ajp_common.c 
(2807): socket timeout: 0
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] ajp_init::jk_ajp_common.c 
(2811): socket connect timeout: 0
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] ajp_init::jk_ajp_common.c 
(2815): buffer size:0
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] ajp_init::jk_ajp_common.c 
(2819): pool timeout:   0
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] ajp_init::jk_ajp_common.c 
(2823): ping timeout:   1
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] ajp_init::jk_ajp_common.c 
(2827): connect timeout:0
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] ajp_init::jk_ajp_common.c 
(2831): reply timeout:  0
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] ajp_init::jk_ajp_common.c 
(2835): prepost timeout:0
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] ajp_init::jk_ajp_common.c 
(2839): recovery options:   0
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] ajp_init::jk_ajp_common.c 
(2843): retries:2
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] ajp_init::jk_ajp_common.c 
(2847): max packet size:8192
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] ajp_init::jk_ajp_common.c 
(2851): retry interval: 100
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
ajp_create_endpoint_cache::jk_ajp_common.c (2653): enter
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
ajp_create_endpoint_cache::jk_ajp_common.c (2662): setting connection pool size 
to 25 with min 13 and acquire timeout 200
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
ajp_create_endpoint_cache::jk_ajp_common.c (2688): exit
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] ajp_init::jk_ajp_common.c 
(2883): exit


- anything in the httpd error log? Maybe your mod_jk module file is not
really compatible with your web server binary and you get process crashes?


After the server restart, the following:

[Tue Jul 13 22:21:00 2010] [notice] suEXEC mechanism enabled (wrapper: 
/opt/IBMIHS/bin/suexec)
[Tue Jul 13 22:21:02 2010] [notice] IBM_HTTP_Server/6.0.2 Apache/2.0.47 (Unix) 
mod_jk/1.2.30 configured -- resuming normal operations
[Tue Jul 13 22:21:02 2010] [notice] Core file limit is 0; core dumps will be 
not be written for server crashes

Attempt to reach URL http://localhost/TlTaggerTest/target.jsp:

[Tue Jul 13 22:39:46 2010] [error] [client 127.0.0.1] File does not exist: 
target.jsp


If those remarks do not help, we will need your configuration and more
complete logs.


 From httpd.conf:

VirtualHost localhost
 ServerName localhost
 DocumentRoot /opt/IBMIHS/htdocs/en_US
 CustomLog logs/vhost_local_access_log combined

#JkMount /manager ajp13
#JkMount /manager/* ajp13
#
#JkMount /helloworld ajp13
#JkMount /helloworld/* ajp13
#
#JkMount /docs ajp13
#JkMount /docs/* ajp13
#
#JkMount /host-manager ajp13
#JkMount /host-manager/* ajp13

 JkMount /TlTaggerTest/*.jsp worker1
/VirtualHost

Your help is really appreciated.


Thanks for the info, the startup looks good assuming that there were no 
non-debug non-trace lines.


One piece is missing, namely the full log lines from the time sending 
the test request to the return of the 404. My first question aimed at 
asking, whether the few log lines you provided contained really 
everything that gets logged by mod_jk during handling the test request 
(excluding startup).


Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: 404 with mod_jk

 22:21:00 2010] [12002:3987136] [debug] 
 ajp_init::jk_ajp_common.c (2851): retry interval: 100
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
 ajp_create_endpoint_cache::jk_ajp_common.c (2653): enter
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
 ajp_create_endpoint_cache::jk_ajp_common.c (2662): setting connection pool 
 size to 25 with min 13 and acquire timeout 200
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
 ajp_create_endpoint_cache::jk_ajp_common.c (2688): exit
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
 ajp_init::jk_ajp_common.c (2883): exit
 
 - anything in the httpd error log? Maybe your mod_jk module file is not
 really compatible with your web server binary and you get process crashes?
 
 After the server restart, the following:
 
 [Tue Jul 13 22:21:00 2010] [notice] suEXEC mechanism enabled (wrapper: 
 /opt/IBMIHS/bin/suexec)
 [Tue Jul 13 22:21:02 2010] [notice] IBM_HTTP_Server/6.0.2 Apache/2.0.47 
 (Unix) mod_jk/1.2.30 configured -- resuming normal operations
 [Tue Jul 13 22:21:02 2010] [notice] Core file limit is 0; core dumps will 
 be not be written for server crashes
 
 Attempt to reach URL http://localhost/TlTaggerTest/target.jsp:
 
 [Tue Jul 13 22:39:46 2010] [error] [client 127.0.0.1] File does not exist: 
 target.jsp
 
 If those remarks do not help, we will need your configuration and more
 complete logs.
 
  From httpd.conf:
 
 VirtualHost localhost
  ServerName localhost
  DocumentRoot /opt/IBMIHS/htdocs/en_US
  CustomLog logs/vhost_local_access_log combined
 
 #JkMount /manager ajp13
 #JkMount /manager/* ajp13
 #
 #JkMount /helloworld ajp13
 #JkMount /helloworld/* ajp13
 #
 #JkMount /docs ajp13
 #JkMount /docs/* ajp13
 #
 #JkMount /host-manager ajp13
 #JkMount /host-manager/* ajp13
 
  JkMount /TlTaggerTest/*.jsp worker1
 /VirtualHost
 
 Your help is really appreciated.
 
 Thanks for the info, the startup looks good assuming that there were no 
 non-debug non-trace lines.
 
 One piece is missing, namely the full log lines from the time sending 
 the test request to the return of the 404. My first question aimed at 
 asking, whether the few log lines you provided contained really 
 everything that gets logged by mod_jk during handling the test request 
 (excluding startup).
 
 Regards,
 
 Rainer
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

-- 
Michael Powemich...@trollope.orgNaugatuck CT USA
Usenet is like a herd of performing elephants with diarrhea --
massive, difficult to redirect, awe-inspiring, entertaining, and a
source of mind-boggling amounts of excrement when you least expect
it. -- Gene Spafford


pgp61Ha8XXwva.pgp
Description: PGP signature

Re: 404 with mod_jk

2010-07-14 Thread André Warnier

): reply timeout:  0
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
ajp_init::jk_ajp_common.c (2835): prepost timeout:0
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
ajp_init::jk_ajp_common.c (2839): recovery options:   0
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
ajp_init::jk_ajp_common.c (2843): retries:2
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
ajp_init::jk_ajp_common.c (2847): max packet size:8192
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
ajp_init::jk_ajp_common.c (2851): retry interval: 100
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
ajp_create_endpoint_cache::jk_ajp_common.c (2653): enter
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
ajp_create_endpoint_cache::jk_ajp_common.c (2662): setting connection pool 
size to 25 with min 13 and acquire timeout 200
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
ajp_create_endpoint_cache::jk_ajp_common.c (2688): exit
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
ajp_init::jk_ajp_common.c (2883): exit



- anything in the httpd error log? Maybe your mod_jk module file is not
really compatible with your web server binary and you get process crashes?

After the server restart, the following:

[Tue Jul 13 22:21:00 2010] [notice] suEXEC mechanism enabled (wrapper: 
/opt/IBMIHS/bin/suexec)
[Tue Jul 13 22:21:02 2010] [notice] IBM_HTTP_Server/6.0.2 Apache/2.0.47 
(Unix) mod_jk/1.2.30 configured -- resuming normal operations
[Tue Jul 13 22:21:02 2010] [notice] Core file limit is 0; core dumps will 
be not be written for server crashes


Attempt to reach URL http://localhost/TlTaggerTest/target.jsp:

[Tue Jul 13 22:39:46 2010] [error] [client 127.0.0.1] File does not exist: 
target.jsp



If those remarks do not help, we will need your configuration and more
complete logs.

From httpd.conf:

VirtualHost localhost
ServerName localhost
DocumentRoot /opt/IBMIHS/htdocs/en_US
CustomLog logs/vhost_local_access_log combined

#JkMount /manager ajp13
#JkMount /manager/* ajp13
#
#JkMount /helloworld ajp13
#JkMount /helloworld/* ajp13
#
#JkMount /docs ajp13
#JkMount /docs/* ajp13
#
#JkMount /host-manager ajp13
#JkMount /host-manager/* ajp13

JkMount /TlTaggerTest/*.jsp worker1
/VirtualHost

Your help is really appreciated.
Thanks for the info, the startup looks good assuming that there were no 
non-debug non-trace lines.


One piece is missing, namely the full log lines from the time sending 
the test request to the return of the 404. My first question aimed at 
asking, whether the few log lines you provided contained really 
everything that gets logged by mod_jk during handling the test request 
(excluding startup).


Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: 404 with mod_jk

 options:
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
 ajp_init::jk_ajp_common.c (2803): keepalive:  0
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
 ajp_init::jk_ajp_common.c (2807): socket timeout: 0
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
 ajp_init::jk_ajp_common.c (2811): socket connect timeout: 0
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
 ajp_init::jk_ajp_common.c (2815): buffer size:0
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
 ajp_init::jk_ajp_common.c (2819): pool timeout:   0
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
 ajp_init::jk_ajp_common.c (2823): ping timeout:   1
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
 ajp_init::jk_ajp_common.c (2827): connect timeout:0
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
 ajp_init::jk_ajp_common.c (2831): reply timeout:  0
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
 ajp_init::jk_ajp_common.c (2835): prepost timeout:0
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
 ajp_init::jk_ajp_common.c (2839): recovery options:   0
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
 ajp_init::jk_ajp_common.c (2843): retries:2
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
 ajp_init::jk_ajp_common.c (2847): max packet size:8192
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
 ajp_init::jk_ajp_common.c (2851): retry interval: 100
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
 ajp_create_endpoint_cache::jk_ajp_common.c (2653): enter
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
 ajp_create_endpoint_cache::jk_ajp_common.c (2662): setting connection 
 pool size to 25 with min 13 and acquire timeout 200
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
 ajp_create_endpoint_cache::jk_ajp_common.c (2688): exit
 [Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
 ajp_init::jk_ajp_common.c (2883): exit
 
 - anything in the httpd error log? Maybe your mod_jk module file is not
 really compatible with your web server binary and you get process 
 crashes?
 After the server restart, the following:
 
 [Tue Jul 13 22:21:00 2010] [notice] suEXEC mechanism enabled (wrapper: 
 /opt/IBMIHS/bin/suexec)
 [Tue Jul 13 22:21:02 2010] [notice] IBM_HTTP_Server/6.0.2 Apache/2.0.47 
 (Unix) mod_jk/1.2.30 configured -- resuming normal operations
 [Tue Jul 13 22:21:02 2010] [notice] Core file limit is 0; core dumps 
 will be not be written for server crashes
 
 Attempt to reach URL http://localhost/TlTaggerTest/target.jsp:
 
 [Tue Jul 13 22:39:46 2010] [error] [client 127.0.0.1] File does not 
 exist: target.jsp
 
 If those remarks do not help, we will need your configuration and more
 complete logs.
 From httpd.conf:
 
 VirtualHost localhost
 ServerName localhost
 DocumentRoot /opt/IBMIHS/htdocs/en_US
 CustomLog logs/vhost_local_access_log combined
 
 #JkMount /manager ajp13
 #JkMount /manager/* ajp13
 #
 #JkMount /helloworld ajp13
 #JkMount /helloworld/* ajp13
 #
 #JkMount /docs ajp13
 #JkMount /docs/* ajp13
 #
 #JkMount /host-manager ajp13
 #JkMount /host-manager/* ajp13
 
 JkMount /TlTaggerTest/*.jsp worker1
 /VirtualHost
 
 Your help is really appreciated.
 Thanks for the info, the startup looks good assuming that there were no 
 non-debug non-trace lines.
 
 One piece is missing, namely the full log lines from the time sending 
 the test request to the return of the 404. My first question aimed at 
 asking, whether the few log lines you provided contained really 
 everything that gets logged by mod_jk during handling the test request 
 (excluding startup).
 
 Regards,
 
 Rainer
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

-- 
Michael Powemich...@trollope.orgNaugatuck CT USA

Oil production is in decline in 33 of the 48 largest oil producing
countries, ...
  -- Chevron Oil web site


pgpmrL74aj0HX.pgp
Description: PGP signature

Re: 404 with mod_jk

2010-07-14 Thread Konstantin Kolinko

2010/7/14 Michael Powe mich...@trollope.org:
 VirtualHost localhost
(...)
 #    JkMount /host-manager ajp13
 #    JkMount /host-manager/* ajp13
 
     JkMount /TlTaggerTest/*.jsp worker1
 /VirtualHost
 

 The VirtualHost section was created by the ApacheConfig option in
 Tomcat.

Trivial question:  are you sure, that your worker name is correct
(worker1 vs. ajp13).  I am curious, why Tomcat-generated
configuration has different worker name.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: 404 with mod_jk

2010-07-14 Thread Rainer Jung


On 14.07.2010 14:37, Konstantin Kolinko wrote:

2010/7/14 Michael Powemich...@trollope.org:

VirtualHost localhost

(...)

#JkMount /host-manager ajp13
#JkMount /host-manager/* ajp13

JkMount /TlTaggerTest/*.jsp worker1
/VirtualHost



The VirtualHost section was created by the ApacheConfig option in
Tomcat.


Trivial question:  are you sure, that your worker name is correct
(worker1 vs. ajp13).  I am curious, why Tomcat-generated
configuration has different worker name.


The auto configuration feature of Tomcat should be deprecated. It is of 
no real use except for a trivial starter configuration. It *always* uses 
a single worker named ajp13.


Because of this feature (I guess because) mod_jk has a builtin worker 
named ajp13, which even if no worker named ajp13 is explicitely 
defined tries to contact localhost at 8009 if the a URL is mounted to a 
worker named ajp13. Legacy stuff.


Nevertheless, although the config the OP uses is not sufficient for 
prime time, it should work. I didn't yet have the time to compare, where 
exactly the log lines stop compared with a working request.


Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: 404 with mod_jk

On Wed, Jul 14, 2010 at 04:37:17PM +0200, Rainer Jung wrote:
 On 14.07.2010 14:37, Konstantin Kolinko wrote:
 2010/7/14 Michael Powemich...@trollope.org:
 VirtualHost localhost
 (...)
 #JkMount /host-manager ajp13
 #JkMount /host-manager/* ajp13
 
 JkMount /TlTaggerTest/*.jsp worker1
 /VirtualHost
 
 
 The VirtualHost section was created by the ApacheConfig option in
 Tomcat.
 
 Trivial question:  are you sure, that your worker name is correct
 (worker1 vs. ajp13).  I am curious, why Tomcat-generated
 configuration has different worker name.
 
 The auto configuration feature of Tomcat should be deprecated. It is of 
 no real use except for a trivial starter configuration. It *always* uses 
 a single worker named ajp13.
 
 Because of this feature (I guess because) mod_jk has a builtin worker 
 named ajp13, which even if no worker named ajp13 is explicitely 
 defined tries to contact localhost at 8009 if the a URL is mounted to a 
 worker named ajp13. Legacy stuff.
 
 Nevertheless, although the config the OP uses is not sufficient for 
 prime time, it should work. I didn't yet have the time to compare, where 
 exactly the log lines stop compared with a working request.

Hello,

The evolution of this process is as follows.  I am updating an Apache
module with some additional functionality.  This module is installed
in two places, one an Apache 2.0 server and the other an IBM httpd
server.  In both instances, Apache is serving pages in front of a
Tomcat server.  Additionally, the module needs to run in multiple
virtual hosts.  Therefore, I have to recreate the production design
locally, in order to be able to install my module and test my new
additions.

To install mod_jk, I resorted to my good friend Google, and used a
tutorial to set up the connector.  In that tutorial, the method used
was to create a properties file (workers.properties) which set up the
worker `worker1'.  

Failing to get that process working, I fell back to the ApacheConfig
directive, given the possibility that I might be leaving out something
simple yet critical in my `hand-rolled' method.  I just changed the
worker name back to `worker1' because I didn't want to keep fiddling
with the conf files, and `worker1' was already in place.  Really, I
just used ApacheConfig to get something to compare to my existing
setup.

I really appreciate your taking time to look at this.  It is such a
huge time-waster for me.  I'm spending more time setting up the test
environment than on my code.

I'm installing a clean version of Apache, built from httpd.apache.org
sources, in /usr/local in order to get around all the weird (IMO)
configuration for the version installed in Ubuntu by default.  At this
point, I've fiddled so many things I've lost track of where I'm at.
Sometimes, when you can't get something to work, it's best to return
to first principles.

Thanks.

mp

-- 
Michael Powemich...@trollope.orgNaugatuck CT USA


And your crybaby whiny opinion would be.?


pgpZDJceFOHaq.pgp
Description: PGP signature

Re: 404 with mod_jk

2010-07-14 Thread André Warnier

Michael Powe wrote:
...

To install mod_jk, I resorted to my good friend Google, and used a
tutorial to set up the connector. In that tutorial, the method used
was to create a properties file (workers.properties) which set up the
worker `worker1'.

...

I'm installing a clean version of Apache, built from httpd.apache.org
sources, in /usr/local in order to get around all the weird (IMO)
configuration for the version installed in Ubuntu by default. At this
point, I've fiddled so many things I've lost track of where I'm at.
Sometimes, when you can't get something to work, it's best to return
to first principles.

I will not often say this, but I believe your problems may stem from the above, and that
you would do better by using the pre-packaged versions of things (except Tomcat)

.
1) it is hard to judge the correctness of a tutorial found on Google.
The mod_jk instructions on the mod_jk pages of the Tomcat website are pretty good, and
they are at least accurate and up-to-date.

2) the standard Apache packages for Debian and Ubuntu are quite good, and a lot easier to
install and maintain than working everything out from scratch.

I suggest the following order :
apt-get install sun-java6-jdk
(then Tomcat, but for Tomcat, I suggest installing it from the Tomcat site
distribution)
apt-get install apache2
apt-get install libapache2-mod-jk
(the last 2 work out of the box and take max. 3 minutes altogether)

Then you just need to add a workers.properties file and your JkMount mappings, and
you'll be up and running in no time.

The weird configuration things you are mentioning for Apache, are quite easy to follow
once you get over the initial surprise, and are actually a clever way to facilitate
enabling/disabling modules and virtual hosts.

I offer to explain summarily, maybe off-list, if you have trouble there.

This all does not mean that it would not be interesting to find out where your current
problem is. But as Konstantin and/or Rainer mentioned, I believe the first thing would be
to get out of the auto-configure thing. I do not believe that this part has been well
maintained since quite a while now.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: 404 with mod_jk

On Thu, Jul 15, 2010 at 02:28:52AM +0200, André Warnier wrote:
 Michael Powe wrote:

 To install mod_jk, I resorted to my good friend Google, and used a
 tutorial to set up the connector.  In that tutorial, the method used
 was to create a properties file (workers.properties) which set up the
 worker `worker1'.  
 ...
 I'm installing a clean version of Apache, built from httpd.apache.org
 sources, in /usr/local in order to get around all the weird (IMO)
 configuration for the version installed in Ubuntu by default.  At this
 point, I've fiddled so many things I've lost track of where I'm at.
 Sometimes, when you can't get something to work, it's best to return
 to first principles.

 I will not often say this, but I believe your problems may stem from the 
 above, and that you would do better by using the pre-packaged versions of 
 things (except Tomcat)

 1) it is hard to judge the correctness of a tutorial found on Google.
 The mod_jk instructions on the mod_jk pages of the Tomcat website are 
 pretty good, and they are at least accurate and up-to-date.

True.  One of them was the `quick start for the impatient' on the
mod_jk doc page.
 
 2) the standard Apache packages for Debian and Ubuntu are quite good, and a 
 lot easier to install and maintain than working everything out from scratch.
 I suggest the following order :
 apt-get install sun-java6-jdk
 (then Tomcat, but for Tomcat, I suggest installing it from the Tomcat site 
 distribution)
 apt-get install apache2
 apt-get install libapache2-mod-jk
 (the last 2 work out of the box and take max. 3 minutes altogether)
 
 Then you just need to add a workers.properties file and your JkMount 
 mappings, and you'll be up and running in no time.
 
 The weird configuration things you are mentioning for Apache, are quite 
 easy to follow once you get over the initial surprise, and are actually a 
 clever way to facilitate enabling/disabling modules and virtual hosts.
 I offer to explain summarily, maybe off-list, if you have trouble there.

Well, it can't hurt for me to uninstall/reinstall to get things back
to a clean configuration.

Also, there's more to the weirdness of the Apache installation than
just the module/vh setup.  First, they've arbitrarily renamed some
elements (e.g., replaced `httpd' with `apache2' in various places),
which serves no useful purpose.  Second, `apxs' (renamed to `apxs2')
does not work correctly for compiling and installing my existing
module.  Maybe it works if you create one from scratch, I don't
know. Nor does `apachectl' (renamed to `apache2ctl').  `apache2ctl'
fails sometimes with the weird message `bad user name
${APACHE_RUN_USER}', meaning I take it that this variable is not
properly exported unless you run `/etc/init.d/apache2'.  Which only
takes `start|stop|restart|reload' for arguments.  (And setting the var
in the shell does not work.)  Third, you have files needed for
development/admin work in /etc/apache2, /var/lib/apache2 and
/usr/share/apache2 -- I mean, WTF?

For me, the summary of all that is that I installed the IBM server
into /opt and all the module-related stuff (apxs) and control stuff
(apachectl) just works.  And I'm not giving props to IBM so much as
I'm saying that the design of the installation for Ubuntu was not
intended for usage as a development package.  

/rant

I'll do as you suggest regarding the OOB installation and see where I
get.  I spent most of today working on my module, so at least I have a
feeling of progress.

Thanks.

mp 
 
-- 
Michael Powemich...@trollope.orgNaugatuck CT USA
I'll carry your books, I'll carry a tune, I'll carry on, carry over,
carry forward, Cary Grant, cash  carry, Carry Me Back To Old
Virginia, I'll even Hara Kari if you show me how, but I will *not*
carry a gun.  -- Hawkeye, M*A*S*H


pgpA74AJDIOI1.pgp
Description: PGP signature

404 with mod_jk

2010-07-13 Thread Michael Powe

Hello,

I asked this question in the httpd list but no joy.

I have set up tomcat 6 and IBM httpd server to proxy requests using
mod_jk.  

IBM_HTTP_Server/6.0.2 Apache/2.0.47 (Unix) mod_jk/1.2.30 Server at
localhost Port 80

I have followed all instructions as nearly as I can make
out. 

The mod_jk log shows:

[Tue Jul 13 16:41:02 2010] [7639:50215792] [trace]
map_uri_to_worker_ext::jk_uri_worker_map.c (951): enter
[Tue Jul 13 16:41:02 2010] [7639:50215792] [debug]
map_uri_to_worker_ext::jk_uri_worker_map.c (1036): Attempting to map
URI '/TlTaggerTest/target.jsp' from 9 maps
[Tue Jul 13 16:41:02 2010] [7639:50215792] [trace]
find_match::jk_uri_worker_map.c (839): enter
[Tue Jul 13 16:41:02 2010] [7639:50215792] [debug]
find_match::jk_uri_worker_map.c (850): Attempting to map context URI
'/TlTaggerTest/*.jsp=worker1' source 'JkMount'
[Tue Jul 13 16:41:02 2010] [7639:50215792] [debug]
find_match::jk_uri_worker_map.c (863): Found a wildchar match
'/TlTaggerTest/*.jsp=worker1'
[Tue Jul 13 16:41:02 2010] [7639:50215792] [trace]
find_match::jk_uri_worker_map.c (866): exit
[Tue Jul 13 16:41:02 2010] [7639:50215792] [trace]
map_uri_to_worker_ext::jk_uri_worker_map.c (1065): exit

The Apache access log shows:

localhost - - [13/Jul/2010:16:41:02 -0400] GET
/TlTaggerTest/target.jsp  404 332 - Mozilla/5.0 (X11; U; Linux
i686; en-US; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid)
Firefox/3.6.3 -

No indication on the Tomcat side of any activity.

The ajp13 connector is enabled.  Both mod_jk and ajp13 connector are
on port 8009.

The files are available directly from Tomcat through port 8080.

The local files (in htdocs) are properly served.

localhost - - [13/Jul/2010:16:58:01 -0400] GET
/TlTaggerTest/target.html  200 67 - Mozilla/5.0 (X11; U; Linux
i686; en-US; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid)
Firefox/3.6.3 -

I sure would appreciate any pointers for troubleshooting or
resolution. 

Thanks.

mp

-- 
Michael Powemich...@trollope.orgNaugatuck CT USA


47.3% of all statistics are made up on the spot. - Steven Wright


pgpqpMwrTG7dh.pgp
Description: PGP signature

Re: 404 with mod_jk

2010-07-13 Thread Rainer Jung


On 13.07.2010 23:17, Michael Powe wrote:

Hello,

I asked this question in the httpd list but no joy.

I have set up tomcat 6 and IBM httpd server to proxy requests using
mod_jk.

IBM_HTTP_Server/6.0.2 Apache/2.0.47 (Unix) mod_jk/1.2.30 Server at
localhost Port 80

I have followed all instructions as nearly as I can make
out.

The mod_jk log shows:

[Tue Jul 13 16:41:02 2010] [7639:50215792] [trace]
map_uri_to_worker_ext::jk_uri_worker_map.c (951): enter
[Tue Jul 13 16:41:02 2010] [7639:50215792] [debug]
map_uri_to_worker_ext::jk_uri_worker_map.c (1036): Attempting to map
URI '/TlTaggerTest/target.jsp' from 9 maps
[Tue Jul 13 16:41:02 2010] [7639:50215792] [trace]
find_match::jk_uri_worker_map.c (839): enter
[Tue Jul 13 16:41:02 2010] [7639:50215792] [debug]
find_match::jk_uri_worker_map.c (850): Attempting to map context URI
'/TlTaggerTest/*.jsp=worker1' source 'JkMount'
[Tue Jul 13 16:41:02 2010] [7639:50215792] [debug]
find_match::jk_uri_worker_map.c (863): Found a wildchar match
'/TlTaggerTest/*.jsp=worker1'
[Tue Jul 13 16:41:02 2010] [7639:50215792] [trace]
find_match::jk_uri_worker_map.c (866): exit
[Tue Jul 13 16:41:02 2010] [7639:50215792] [trace]
map_uri_to_worker_ext::jk_uri_worker_map.c (1065): exit

The Apache access log shows:

localhost - - [13/Jul/2010:16:41:02 -0400] GET
/TlTaggerTest/target.jsp  404 332 - Mozilla/5.0 (X11; U; Linux
i686; en-US; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid)
Firefox/3.6.3 -

No indication on the Tomcat side of any activity.

The ajp13 connector is enabled.  Both mod_jk and ajp13 connector are
on port 8009.

The files are available directly from Tomcat through port 8080.

The local files (in htdocs) are properly served.

localhost - - [13/Jul/2010:16:58:01 -0400] GET
/TlTaggerTest/target.html  200 67 - Mozilla/5.0 (X11; U; Linux
i686; en-US; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid)
Firefox/3.6.3 -

I sure would appreciate any pointers for troubleshooting or
resolution.

Thanks.

mp


Since you already have trace logging enabled:

- is this all that gets logged in the jk log file for the request?

- can you see your worker worker1 getting configured during startup
(debug log messages)?

- anything in the httpd error log? Maybe your mod_jk module file is not 
really compatible with your web server binary and you get process crashes?


If those remarks do not help, we will need your configuration and more 
complete logs.


Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: 404 with mod_jk

2010-07-13 Thread Michael Powe

Hello,

Thank you for the reply.

See below for comments.

On Wed, Jul 14, 2010 at 12:37:05AM +0200, Rainer Jung wrote:

 On 13.07.2010 23:17, Michael Powe wrote:
 Hello,
 
 I asked this question in the httpd list but no joy.
 
 I have set up tomcat 6 and IBM httpd server to proxy requests using
 mod_jk.
 
 IBM_HTTP_Server/6.0.2 Apache/2.0.47 (Unix) mod_jk/1.2.30 Server at
 localhost Port 80
 
 I have followed all instructions as nearly as I can make
 out.
 

 
 Since you already have trace logging enabled:
 
 - is this all that gets logged in the jk log file for the request?

I rotated the mod_jk log and restarted the server.  I get a huge trace
log, 33K.  It appears to me to be initializing correctly, in the sense
that there are no error messages.  
 
 - can you see your worker worker1 getting configured during startup
 (debug log messages)?

[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
uri_worker_map_dump::jk_uri_worker_map.c (195): exit
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
uri_worker_map_open::jk_uri_worker_map.c (830): exit
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
uri_worker_map_alloc::jk_uri_worker_map.c (240): exit
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] init_jk::mod_jk.c (3112): 
Using fcntl() for locking.
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] init_jk::mod_jk.c (3128): 
Setting default connection pool max size to 25
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
jk_map_read_property::jk_map.c (491): Adding property 'worker.list' with value 
'worker1' to map.
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
jk_map_read_property::jk_map.c (491): Adding property 'worker.worker1.type' 
with value 'ajp13' to map.
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
jk_map_read_property::jk_map.c (491): Adding property 'worker.worker1.host' 
with value 'localhost' to map.
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
jk_map_read_property::jk_map.c (491): Adding property 'worker.worker1.port' 
with value '8009' to map.
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
jk_map_resolve_references::jk_map.c (766): enter 
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
jk_map_resolve_references::jk_map.c (774): Checking for references with prefix 
worker. with wildcard (recursion 1)
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
jk_map_resolve_references::jk_map.c (830): exit
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
jk_shm_calculate_size::jk_shm.c (97): enter
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
jk_shm_calculate_size::jk_shm.c (132): shared memory will contain 1 ajp workers 
of size 256 and 0 lb workers of size 320 with 0 members of size 320+256
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
jk_shm_calculate_size::jk_shm.c (139): exit

[ ... ]

[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] wc_open::jk_worker.c (50): 
enter
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] jk_map_dump::jk_map.c (589): 
Dump of map: 'ServerRoot' - '/opt/IBMIHS'
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] jk_map_dump::jk_map.c (589): 
Dump of map: 'worker.list' - 'worker1'
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] jk_map_dump::jk_map.c (589): 
Dump of map: 'worker.worker1.type' - 'ajp13'
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] jk_map_dump::jk_map.c (589): 
Dump of map: 'worker.worker1.host' - 'localhost'
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] jk_map_dump::jk_map.c (589): 
Dump of map: 'worker.worker1.port' - '8009'
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
build_worker_map::jk_worker.c (236): enter
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
build_worker_map::jk_worker.c (242): creating worker worker1
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
wc_create_worker::jk_worker.c (126): enter
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
wc_create_worker::jk_worker.c (146): about to create instance worker1 of ajp13
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
ajp13_worker_factory::jk_ajp13_worker.c (80): enter
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
ajp_worker_factory::jk_ajp_common.c (2892): enter
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
ajp_worker_factory::jk_ajp_common.c (2934): exit
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
ajp13_worker_factory::jk_ajp13_worker.c (92): exit
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
wc_create_worker::jk_worker.c (159): about to validate and init worker1
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] validate::jk_ajp13_worker.c 
(35): enter
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] 
ajp_validate::jk_ajp_common.c (2579): enter
[Tue Jul 13 22:21:00 2010] [12002:3987136] [debug] 
ajp_validate::jk_ajp_common.c (2605): worker worker1 contact is 'localhost:8009'
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] jk_resolve::jk_connect.c 
(329): enter
[Tue Jul 13 22:21:00 2010] [12002:3987136] [trace] jk_resolve::jk_connect.c 
(406): exit
[Tue Jul 13 22:21:00

Re: Webapp reloading issue and intermittent 404 errors

2010-07-07 Thread Tomislav Petrović

Tomislav Petrović said on 30.6.2010 16:27:
 Forgot to say:
 Tomcat service is started with following parameters:

 JVM: have to check whether server or client, not sure at the moment.

 Server, one would hope. Did you find out the exact version?

 
 Yup JVM path for tomcat is ..\jdk1.6.0_18\jre\bin\server\jvm.dll, so 
 Java 6 update 18 server.

Although initial excpetion and stacktrace (related to webapp reloading, 
actually checking that it should or should not be reloaded) went away with 
reloadable=false workaround I now have similar problem.

Please help since now machine is in (or near) production :(.

New stacktrace in catalina logs looks like (and produces 404 errors):

Jul 5, 2010 7:13:47 AM org.apache.catalina.connector.CoyoteAdapter service
SEVERE: An exception or error occurred in the container during the request 
processing
java.lang.StringIndexOutOfBoundsException: String index out of range: 115
at java.lang.String.substring(String.java:1934)
at org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131)
at 
org.apache.naming.resources.FileDirContext.normalize(FileDirContext.java:771)
at 
org.apache.naming.resources.FileDirContext.file(FileDirContext.java:811)
at 
org.apache.naming.resources.FileDirContext.getAttributes(FileDirContext.java:429)
at 
org.apache.naming.resources.BaseDirContext.getAttributes(BaseDirContext.java:747)
at 
org.apache.naming.resources.ProxyDirContext.revalidate(ProxyDirContext.java:1501)
at 
org.apache.naming.resources.ProxyDirContext.cacheLookup(ProxyDirContext.java:1457)
at 
org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:288)
at 
org.apache.tomcat.util.http.mapper.Mapper.internalMapWrapper(Mapper.java:823)
at 
org.apache.tomcat.util.http.mapper.Mapper.internalMap(Mapper.java:667)
at org.apache.tomcat.util.http.mapper.Mapper.map(Mapper.java:557)
at 
org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:462)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:296)
at 
org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859)
at 
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579)
at 
org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555)
at java.lang.Thread.run(Thread.java:619)

Everything else is same as I posted before (config file, JVM versions, etc)
Any advice is appreciated
--
Tomy t.petro...@inet.hr

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Webapp reloading issue and intermittent 404 errors

2010-07-07 Thread Pid

On 07/07/2010 11:07, Tomislav Petrović wrote:
 Tomislav Petrović said on 30.6.2010 16:27:
 Forgot to say:
 Tomcat service is started with following parameters:

 JVM: have to check whether server or client, not sure at the moment.

 Server, one would hope. Did you find out the exact version?


 Yup JVM path for tomcat is ..\jdk1.6.0_18\jre\bin\server\jvm.dll, so 
 Java 6 update 18 server.
 
 Although initial excpetion and stacktrace (related to webapp reloading, 
 actually checking that it should or should not be reloaded) went away with 
 reloadable=false workaround I now have similar problem.
 
 Please help since now machine is in (or near) production :(.
 
 New stacktrace in catalina logs looks like (and produces 404 errors):
 
 Jul 5, 2010 7:13:47 AM org.apache.catalina.connector.CoyoteAdapter service
 SEVERE: An exception or error occurred in the container during the request 
 processing
 java.lang.StringIndexOutOfBoundsException: String index out of range: 115
   at java.lang.String.substring(String.java:1934)
   at org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131)
   at 
 org.apache.naming.resources.FileDirContext.normalize(FileDirContext.java:771)
   at 
 org.apache.naming.resources.FileDirContext.file(FileDirContext.java:811)
   at 
 org.apache.naming.resources.FileDirContext.getAttributes(FileDirContext.java:429)
   at 
 org.apache.naming.resources.BaseDirContext.getAttributes(BaseDirContext.java:747)
   at 
 org.apache.naming.resources.ProxyDirContext.revalidate(ProxyDirContext.java:1501)
   at 
 org.apache.naming.resources.ProxyDirContext.cacheLookup(ProxyDirContext.java:1457)
   at 
 org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:288)
   at 
 org.apache.tomcat.util.http.mapper.Mapper.internalMapWrapper(Mapper.java:823)
   at 
 org.apache.tomcat.util.http.mapper.Mapper.internalMap(Mapper.java:667)
   at org.apache.tomcat.util.http.mapper.Mapper.map(Mapper.java:557)
   at 
 org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:462)
   at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:296)
   at 
 org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859)
   at 
 org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579)
   at 
 org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555)
   at java.lang.Thread.run(Thread.java:619)
 
 Everything else is same as I posted before (config file, JVM versions, 
 etc)
 Any advice is appreciated

I think the general feeling is that it's a JVM bug - but no-one can work
out what it is.  I can't even work out how to get 115 characters out of
a normal file path.

Can you move the installation from:
 D:\Program Files\Apache Software Foundation\Tomcat 6.0

To:
 D:\Tomcat60


?

p

 --
 Tomy t.petro...@inet.hr
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 




signature.asc
Description: OpenPGP digital signature

Re: Webapp reloading issue and intermittent 404 errors

2010-07-07 Thread Tomislav Petrović

Pid said on 7.7.2010 12:26:
 On 07/07/2010 11:07, Tomislav Petrović wrote:
 Tomislav Petrović said on 30.6.2010 16:27:
 Forgot to say:
 Tomcat service is started with following parameters:

 JVM: have to check whether server or client, not sure at the moment.

 Server, one would hope. Did you find out the exact version?


 Yup JVM path for tomcat is ..\jdk1.6.0_18\jre\bin\server\jvm.dll, so
 Java 6 update 18 server.

 Although initial excpetion and stacktrace (related to webapp reloading, 
 actually checking that it should or should not be reloaded) went away with 
 reloadable=false workaround I now have similar problem.

 Please help since now machine is in (or near) production :(.

 New stacktrace in catalina logs looks like (and produces 404 errors):

 Jul 5, 2010 7:13:47 AM org.apache.catalina.connector.CoyoteAdapter service
 SEVERE: An exception or error occurred in the container during the request 
 processing
 java.lang.StringIndexOutOfBoundsException: String index out of range: 115
  at java.lang.String.substring(String.java:1934)
  at org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131)
  at 
 org.apache.naming.resources.FileDirContext.normalize(FileDirContext.java:771)
  at 
 org.apache.naming.resources.FileDirContext.file(FileDirContext.java:811)
  at 
 org.apache.naming.resources.FileDirContext.getAttributes(FileDirContext.java:429)
  at 
 org.apache.naming.resources.BaseDirContext.getAttributes(BaseDirContext.java:747)
  at 
 org.apache.naming.resources.ProxyDirContext.revalidate(ProxyDirContext.java:1501)
  at 
 org.apache.naming.resources.ProxyDirContext.cacheLookup(ProxyDirContext.java:1457)
  at 
 org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:288)
  at 
 org.apache.tomcat.util.http.mapper.Mapper.internalMapWrapper(Mapper.java:823)
  at 
 org.apache.tomcat.util.http.mapper.Mapper.internalMap(Mapper.java:667)
  at org.apache.tomcat.util.http.mapper.Mapper.map(Mapper.java:557)
  at 
 org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:462)
  at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:296)
  at 
 org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859)
  at 
 org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579)
  at 
 org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555)
  at java.lang.Thread.run(Thread.java:619)

 Everything else is same as I posted before (config file, JVM versions, 
 etc)
 Any advice is appreciated
 
 I think the general feeling is that it's a JVM bug - but no-one can work
 out what it is.  I can't even work out how to get 115 characters out of
 a normal file path.
 
 Can you move the installation from:
   D:\Program Files\Apache Software Foundation\Tomcat 6.0
 
 To:
   D:\Tomcat60
 
 

Don't know have to check with customer, but actual index varies in each 
occurrence of stack trace, sometimes it is even -1. In two days we had:
2x java.lang.StringIndexOutOfBoundsException: String index out of range: 131
1x java.lang.StringIndexOutOfBoundsException: String index out of range: 118
1x java.lang.StringIndexOutOfBoundsException: String index out of range: 106
4x java.lang.StringIndexOutOfBoundsException: String index out of range: -1 
3x java.lang.StringIndexOutOfBoundsException: String index out of range: 127
2x java.lang.StringIndexOutOfBoundsException: String index out of range: 126
1x java.lang.StringIndexOutOfBoundsException: String index out of range: 123
Rest of stacktrace is identical in all occurences.

In addition
--
Tomy t.petro...@inet.hr

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Webapp reloading issue and intermittent 404 errors

2010-07-07 Thread Pid

On 07/07/2010 11:35, Tomislav Petrović wrote:
 Pid said on 7.7.2010 12:26:
 On 07/07/2010 11:07, Tomislav Petrović wrote:
 Tomislav Petrović said on 30.6.2010 16:27:
 Forgot to say:
 Tomcat service is started with following parameters:

 JVM: have to check whether server or client, not sure at the moment.

 Server, one would hope. Did you find out the exact version?


 Yup JVM path for tomcat is ..\jdk1.6.0_18\jre\bin\server\jvm.dll, so
 Java 6 update 18 server.

 Although initial excpetion and stacktrace (related to webapp reloading, 
 actually checking that it should or should not be reloaded) went away with 
 reloadable=false workaround I now have similar problem.

 Please help since now machine is in (or near) production :(.

 New stacktrace in catalina logs looks like (and produces 404 errors):

 Jul 5, 2010 7:13:47 AM org.apache.catalina.connector.CoyoteAdapter service
 SEVERE: An exception or error occurred in the container during the request 
 processing
 java.lang.StringIndexOutOfBoundsException: String index out of range: 115
 at java.lang.String.substring(String.java:1934)
 at org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131)
 at 
 org.apache.naming.resources.FileDirContext.normalize(FileDirContext.java:771)
 at 
 org.apache.naming.resources.FileDirContext.file(FileDirContext.java:811)
 at 
 org.apache.naming.resources.FileDirContext.getAttributes(FileDirContext.java:429)
 at 
 org.apache.naming.resources.BaseDirContext.getAttributes(BaseDirContext.java:747)
 at 
 org.apache.naming.resources.ProxyDirContext.revalidate(ProxyDirContext.java:1501)
 at 
 org.apache.naming.resources.ProxyDirContext.cacheLookup(ProxyDirContext.java:1457)
 at 
 org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:288)
 at 
 org.apache.tomcat.util.http.mapper.Mapper.internalMapWrapper(Mapper.java:823)
 at 
 org.apache.tomcat.util.http.mapper.Mapper.internalMap(Mapper.java:667)
 at org.apache.tomcat.util.http.mapper.Mapper.map(Mapper.java:557)
 at 
 org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:462)
 at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:296)
 at 
 org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859)
 at 
 org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579)
 at 
 org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555)
 at java.lang.Thread.run(Thread.java:619)

 Everything else is same as I posted before (config file, JVM versions, 
 etc)
 Any advice is appreciated

 I think the general feeling is that it's a JVM bug - but no-one can work
 out what it is.  I can't even work out how to get 115 characters out of
 a normal file path.

 Can you move the installation from:
   D:\Program Files\Apache Software Foundation\Tomcat 6.0

 To:
   D:\Tomcat60


 
 Don't know have to check with customer, but actual index varies in each 
 occurrence of stack trace, sometimes it is even -1. In two days we had:
 2x java.lang.StringIndexOutOfBoundsException: String index out of range: 131
 1x java.lang.StringIndexOutOfBoundsException: String index out of range: 118
 1x java.lang.StringIndexOutOfBoundsException: String index out of range: 106
 4x java.lang.StringIndexOutOfBoundsException: String index out of range: -1 
 3x java.lang.StringIndexOutOfBoundsException: String index out of range: 127
 2x java.lang.StringIndexOutOfBoundsException: String index out of range: 126
 1x java.lang.StringIndexOutOfBoundsException: String index out of range: 123
 Rest of stacktrace is identical in all occurences.

I wondered if it doesn't like spaces in File paths.


p

 In addition
 --
 Tomy t.petro...@inet.hr
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 




signature.asc
Description: OpenPGP digital signature

Re: Webapp reloading issue and intermittent 404 errors

2010-07-07 Thread André Warnier


Pid wrote:
..


I wondered if it doesn't like spaces in File paths.


I did not want to ask that question. Good that someone did.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Webapp reloading issue and intermittent 404 errors

2010-07-07 Thread Caldarale, Charles R

 From: Tomislav Petrović [mailto:t.petro...@inet.hr]
 Subject: Re: Webapp reloading issue and intermittent 404 errors

 Don't know have to check with customer, but actual index varies in each
 occurrence of stack trace, sometimes it is even -1.

Here's the code of interest:

127 while (true) {
128 int index = normalized.indexOf(//);
129 if (index  0)
130 break;
131 normalized = normalized.substring(0, index) +
132 normalized.substring(index + 1);
133 }

Given the test on lines 129-130, it is impossible to have a -1 at line 131 - 
unless there's a JVM bug.

You could try running with a -client option instead of -server (if it's 
available on your platform), or create a .hotspot_compiler file in the Tomcat 
current directory containing this line:

exclude org.apache.catalina.util.RequestUtil normalize

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Webapp reloading issue and intermittent 404 errors

2010-07-07 Thread Konstantin Kolinko

2010/6/30 Tomislav Petrović t.petro...@inet.hr:
 Pid said on 30.6.2010 13:06:

 On 30/06/2010 11:59, Tomislav Petrović wrote:

        Context path=/some_webapp docBase=/some_webapp debug=0
 reloadable=true crossContext=true
        ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB
 type=javax.sql.DataSource /
        ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2
 type=javax.sql.DataSource /

 If these are the actual values then it's a miracle it's working at all.

 Only app name/paths and jdbs names have been changed to dummy values.


 Instead of defining it there, remove the debug, path and docBase
 attributes and put it in

  some_webapp/META-INF/context.xml


 Tomcat will work out the rest automatically.

(...)

 And do you really think this would solve my initial problem, or?


As I mentioned in
https://issues.apache.org/bugzilla/show_bug.cgi?id=49488#c2

having double slash in a path is unusual.

Context path=/some_webapp docBase=/some_webapp
probably should be
Context path=/some_webapp docBase=some_webapp

but it would be much better to place this context definition in a
separate file, as was already
mentioned.


Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Webapp reloading issue and intermittent 404 errors

2010-07-07 Thread Caldarale, Charles R

 From: Caldarale, Charles R
 Subject: RE: Webapp reloading issue and intermittent 404 errors

 Given the test on lines 129-130, it is impossible to have a -1 at line
 131 - unless there's a JVM bug.

6u21 was just released tonight, so you might give that a shot and see if the 
problem has been addressed.

Included in 6u21 are fixes for the problems described here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6875866
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6935535

Both seem to have a lot in common with the issue under discussion.

There's another String-related fix in the bug list, but the details are not 
retrievable at the moment:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6948602

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Webapp reloading issue and intermittent 404 errors

2010-07-07 Thread Konstantin Kolinko

2010/7/8 Caldarale, Charles R chuck.caldar...@unisys.com:
 From: Caldarale, Charles R
 Subject: RE: Webapp reloading issue and intermittent 404 errors

 Given the test on lines 129-130, it is impossible to have a -1 at line
 131 - unless there's a JVM bug.

 6u21 was just released tonight, so you might give that a shot and see if the 
 problem has been addressed.

 Included in 6u21 are fixes for the problems described here:
 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6875866
 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6935535

 Both seem to have a lot in common with the issue under discussion.

 There's another String-related fix in the bug list, but the details are not 
 retrievable at the moment:
 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6948602

Oh. It matches this case.

The issue names mention SSE 4.2, so it supposedly happens only on
certain families of Intel CPUs.

http://en.wikipedia.org/wiki/SSE4

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Webapp reloading issue and intermittent 404 errors

2010-07-07 Thread Caldarale, Charles R

 From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
 Subject: Re: Webapp reloading issue and intermittent 404 errors

 Oh. It matches this case.

All three seem to.

 The issue names mention SSE 4.2, so it supposedly happens only on
 certain families of Intel CPUs.

Right - just Nehalem chips (i7).  The OP didn't say what the hardware was; even 
if it's not an i7, the fixes might address the problem, since Sun often doesn't 
give complete descriptions of fixes.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Webapp reloading issue and intermittent 404 errors

Pid said on 29.6.2010 23:20:
 On 29/06/2010 19:29, Konstantin Kolinko wrote:
 2010/6/29 Caldarale, Charles Rchuck.caldar...@unisys.com:
 From: Tomislav Petrović [mailto:t.petro...@inet.hr]
 Subject: Re: Webapp reloading issue and intermittent 404 errors

 org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131)

 IIRC, you are not the first person to report an exception at this spot in 
 the code.  (Unfortunately, I can't locate the other thread at the moment, 
 but it was fairly recent.)

 That was
 https://issues.apache.org/bugzilla/show_bug.cgi?id=49488

   The code in question has been run through many test cases, inside and 
 outside of Tomcat, and does not appear to contain any errors (although it 
 could be slightly more efficient).

 Weird.  I couldn't find that in bugzilla.  Anyhow, it's Windows this
 time too.

 Tomislav: where is the Tomcat installation on the filing system, and
 where are the webapps being deployed from, if not tomcat/webapps?

 What type of filing system is it?

 Also, did you manage to get hold of the config files yet?

Good news is when I put reloadable=false on context problem (both of them, 
intermittent 404 too) went away, so I have workaround. Bad news is server is 
going into production so no messing with it no more.

Yes, this is same bug as one in bugzilla, don't know if what triggered is same.

Here is detailed info (my first suspect is Resources in server.xml but this 
is only my guess.

Tomcat is Apache Tomcat/6.0.24, running without tcnative-1.dll

Java version is: 1.6 update 18

Windows version: 2003 SP2 (32 bit)

NTFS file system is used, Tomcat is installed in D:\Program Files\Apache 
Software Foundation\Tomcat 6.0 folder, webapp is in D:\Program Files\Apache 
Software Foundation\Tomcat 6.0\webapps\some_name folder.

This is content of server.xml, I believe that all other conf files are at their 
default values (except for pwd in users file), feel free to ask for any other 
conf file.

?xml version='1.0' encoding='utf-8'?
Server port=8005 shutdown=SHUTDOWN

  Listener className=org.apache.catalina.core.AprLifecycleListener 
SSLEngine=on /
  Listener className=org.apache.catalina.core.JasperListener /
  Listener 
className=org.apache.catalina.core.JreMemoryLeakPreventionListener /
  Listener className=org.apache.catalina.mbeans.ServerLifecycleListener /
  Listener 
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener /

  GlobalNamingResources
Resource name=UserDatabase auth=Container
  type=org.apache.catalina.UserDatabase
  description=User database that can be updated and saved
  factory=org.apache.catalina.users.MemoryUserDatabaseFactory
  pathname=conf/tomcat-users.xml /
Resource name=jdbc/SomeDB auth=Container type=javax.sql.DataSource 
  maxActive=48
  maxIdle=10
  maxWait=1
  driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver
  username=auser
  password=*

url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName;loginTimeout=5
  removeAbandoned=true
  removeAbandonedTimeout=60
  logAbandoned=true
  validationQuery=SELECT 1/
Resource name=jdbc/SomeDB2 auth=Container type=javax.sql.DataSource 
  maxActive=48
  maxIdle=10
  maxWait=1
  driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver
  username=auser2
  password=**
  url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName2
  removeAbandoned=true
  removeAbandonedTimeout=60
  logAbandoned=true
  validationQuery=SELECT 1/

  /GlobalNamingResources

  Service name=Catalina

Connector port=8080 protocol=HTTP/1.1 
   connectionTimeout=2 
   redirectPort=8443 /
Connector port=8009 protocol=AJP/1.3 redirectPort=8443 /

Engine name=Catalina defaultHost=localhost

  Realm className=org.apache.catalina.realm.UserDatabaseRealm
 resourceName=UserDatabase/

  Host name=localhost  appBase=webapps
unpackWARs=true autoDeploy=true
xmlValidation=false xmlNamespaceAware=false

Valve className=org.apache.catalina.valves.AccessLogValve 
directory=logs  
   prefix=localhost_access_log. suffix=.txt pattern=common 
resolveHosts=false/

  Context path=/some_webapp docBase=/some_webapp debug=0 
reloadable=true crossContext=true
ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB 
type=javax.sql.DataSource /
ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2 
type=javax.sql.DataSource /
/Context
  /Host
/Engine
  /Service
/Server

Let me know if I can provide any more info or update

Re: Webapp reloading issue and intermittent 404 errors


Tomislav Petrović said on 30.6.2010 12:59:

Pid said on 29.6.2010 23:20:

On 29/06/2010 19:29, Konstantin Kolinko wrote:

2010/6/29 Caldarale, Charles Rchuck.caldar...@unisys.com:

From: Tomislav Petrović [mailto:t.petro...@inet.hr]
Subject: Re: Webapp reloading issue and intermittent 404 errors

org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131)


IIRC, you are not the first person to report an exception at this spot in the 
code.  (Unfortunately, I can't locate the other thread at the moment, but it 
was fairly recent.)


That was
https://issues.apache.org/bugzilla/show_bug.cgi?id=49488


   The code in question has been run through many test cases, inside and 
outside of Tomcat, and does not appear to contain any errors (although it could 
be slightly more efficient).


Weird.  I couldn't find that in bugzilla.  Anyhow, it's Windows this
time too.


Tomislav: where is the Tomcat installation on the filing system, and
where are the webapps being deployed from, if not tomcat/webapps?

What type of filing system is it?


Also, did you manage to get hold of the config files yet?


Good news is when I put reloadable=false on context problem (both of them, 
intermittent 404 too) went away, so I have workaround. Bad news is server is 
going into production so no messing with it no more.

Yes, this is same bug as one in bugzilla, don't know if what triggered is same.

Here is detailed info (my first suspect isResources in server.xml but this is 
only my guess.

Tomcat is Apache Tomcat/6.0.24, running without tcnative-1.dll

Java version is: 1.6 update 18

Windows version: 2003 SP2 (32 bit)

NTFS file system is used, Tomcat is installed in D:\Program Files\Apache Software 
Foundation\Tomcat 6.0 folder, webapp is in D:\Program Files\Apache Software 
Foundation\Tomcat 6.0\webapps\some_name folder.

This is content of server.xml, I believe that all other conf files are at their 
default values (except for pwd in users file), feel free to ask for any other 
conf file.

?xml version='1.0' encoding='utf-8'?
Server port=8005 shutdown=SHUTDOWN

   Listener className=org.apache.catalina.core.AprLifecycleListener 
SSLEngine=on /
   Listener className=org.apache.catalina.core.JasperListener /
   Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener 
/
   Listener className=org.apache.catalina.mbeans.ServerLifecycleListener /
   Listener 
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener /

   GlobalNamingResources
 Resource name=UserDatabase auth=Container
   type=org.apache.catalina.UserDatabase
   description=User database that can be updated and saved
   factory=org.apache.catalina.users.MemoryUserDatabaseFactory
   pathname=conf/tomcat-users.xml /
 Resource name=jdbc/SomeDB auth=Container type=javax.sql.DataSource
  maxActive=48
  maxIdle=10
  maxWait=1
  driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver
  username=auser
  password=*
  
url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName;loginTimeout=5
  removeAbandoned=true
  removeAbandonedTimeout=60
  logAbandoned=true
  validationQuery=SELECT 1/
 Resource name=jdbc/SomeDB2 auth=Container type=javax.sql.DataSource
  maxActive=48
  maxIdle=10
  maxWait=1
  driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver
  username=auser2
  password=**
  url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName2
  removeAbandoned=true
  removeAbandonedTimeout=60
  logAbandoned=true
  validationQuery=SELECT 1/

   /GlobalNamingResources

   Service name=Catalina

 Connector port=8080 protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8443 /
 Connector port=8009 protocol=AJP/1.3 redirectPort=8443 /

 Engine name=Catalina defaultHost=localhost

   Realm className=org.apache.catalina.realm.UserDatabaseRealm
  resourceName=UserDatabase/

   Host name=localhost  appBase=webapps
 unpackWARs=true autoDeploy=true
 xmlValidation=false xmlNamespaceAware=false

 Valve className=org.apache.catalina.valves.AccessLogValve 
directory=logs
prefix=localhost_access_log. suffix=.txt pattern=common 
resolveHosts=false/

Context path=/some_webapp docBase=/some_webapp debug=0 reloadable=true 
crossContext=true
ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB 
type=javax.sql.DataSource /
ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2 
type=javax.sql.DataSource /
 /Context
   /Host
 /Engine
   /Service
/Server

Let me know if I

Re: Webapp reloading issue and intermittent 404 errors

On 30/06/2010 11:59, Tomislav Petrović wrote:
 Context path=/some_webapp docBase=/some_webapp debug=0 
 reloadable=true crossContext=true
   ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB 
 type=javax.sql.DataSource /
   ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2 
 type=javax.sql.DataSource /

If these are the actual values then it's a miracle it's working at all.

Instead of defining it there, remove the debug, path and docBase
attributes and put it in

 some_webapp/META-INF/context.xml


Tomcat will work out the rest automatically.


p



signature.asc
Description: OpenPGP digital signature

Re: Webapp reloading issue and intermittent 404 errors

On 30/06/2010 12:04, Tomislav Petrović wrote:
 Tomislav Petrović said on 30.6.2010 12:59:
 Pid said on 29.6.2010 23:20:
 On 29/06/2010 19:29, Konstantin Kolinko wrote:
 2010/6/29 Caldarale, Charles Rchuck.caldar...@unisys.com:
 From: Tomislav Petrović [mailto:t.petro...@inet.hr]
 Subject: Re: Webapp reloading issue and intermittent 404 errors

 org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131)

 IIRC, you are not the first person to report an exception at this
 spot in the code.  (Unfortunately, I can't locate the other thread
 at the moment, but it was fairly recent.)

 That was
 https://issues.apache.org/bugzilla/show_bug.cgi?id=49488

The code in question has been run through many test cases,
 inside and outside of Tomcat, and does not appear to contain any
 errors (although it could be slightly more efficient).

 Weird.  I couldn't find that in bugzilla.  Anyhow, it's Windows this
 time too.

 Tomislav: where is the Tomcat installation on the filing system, and
 where are the webapps being deployed from, if not tomcat/webapps?

 What type of filing system is it?

 Also, did you manage to get hold of the config files yet?

 Good news is when I put reloadable=false on context problem (both of
 them, intermittent 404 too) went away, so I have workaround. Bad news
 is server is going into production so no messing with it no more.

 Yes, this is same bug as one in bugzilla, don't know if what triggered
 is same.

 Here is detailed info (my first suspect isResources in server.xml
 but this is only my guess.

 Tomcat is Apache Tomcat/6.0.24, running without tcnative-1.dll

 Java version is: 1.6 update 18

 Windows version: 2003 SP2 (32 bit)

 NTFS file system is used, Tomcat is installed in D:\Program
 Files\Apache Software Foundation\Tomcat 6.0 folder, webapp is in
 D:\Program Files\Apache Software Foundation\Tomcat
 6.0\webapps\some_name folder.

 This is content of server.xml, I believe that all other conf files are
 at their default values (except for pwd in users file), feel free to
 ask for any other conf file.

 ?xml version='1.0' encoding='utf-8'?
 Server port=8005 shutdown=SHUTDOWN

Listener className=org.apache.catalina.core.AprLifecycleListener
 SSLEngine=on /
Listener className=org.apache.catalina.core.JasperListener /
Listener
 className=org.apache.catalina.core.JreMemoryLeakPreventionListener /
Listener
 className=org.apache.catalina.mbeans.ServerLifecycleListener /
Listener
 className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener /

GlobalNamingResources
  Resource name=UserDatabase auth=Container
type=org.apache.catalina.UserDatabase
description=User database that can be updated and saved

 factory=org.apache.catalina.users.MemoryUserDatabaseFactory
pathname=conf/tomcat-users.xml /
  Resource name=jdbc/SomeDB auth=Container
 type=javax.sql.DataSource
   maxActive=48
   maxIdle=10
   maxWait=1
   driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver
   username=auser
   password=*

 url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName;loginTimeout=5

   removeAbandoned=true
   removeAbandonedTimeout=60
   logAbandoned=true
   validationQuery=SELECT 1/
  Resource name=jdbc/SomeDB2 auth=Container
 type=javax.sql.DataSource
   maxActive=48
   maxIdle=10
   maxWait=1
   driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver
   username=auser2
   password=**
   url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName2
   removeAbandoned=true
   removeAbandonedTimeout=60
   logAbandoned=true
   validationQuery=SELECT 1/

/GlobalNamingResources

Service name=Catalina

  Connector port=8080 protocol=HTTP/1.1
 connectionTimeout=2
 redirectPort=8443 /
  Connector port=8009 protocol=AJP/1.3 redirectPort=8443 /

  Engine name=Catalina defaultHost=localhost

Realm className=org.apache.catalina.realm.UserDatabaseRealm
   resourceName=UserDatabase/

Host name=localhost  appBase=webapps
  unpackWARs=true autoDeploy=true
  xmlValidation=false xmlNamespaceAware=false

  Valve className=org.apache.catalina.valves.AccessLogValve
 directory=logs
 prefix=localhost_access_log. suffix=.txt
 pattern=common resolveHosts=false/

 Context path=/some_webapp docBase=/some_webapp debug=0
 reloadable=true crossContext=true
 ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB
 type=javax.sql.DataSource /
 ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2
 type=javax.sql.DataSource /
  /Context
/Host
  /Engine
/Service
 /Server

 Let me know if I can provide any more info or update bugzilla (don't
 have acc

Re: Webapp reloading issue and intermittent 404 errors


Pid said on 30.6.2010 13:12:

On 30/06/2010 12:04, Tomislav Petrović wrote:

Tomislav Petrović said on 30.6.2010 12:59:

Pid said on 29.6.2010 23:20:

On 29/06/2010 19:29, Konstantin Kolinko wrote:

2010/6/29 Caldarale, Charles Rchuck.caldar...@unisys.com:

From: Tomislav Petrović [mailto:t.petro...@inet.hr]
Subject: Re: Webapp reloading issue and intermittent 404 errors

org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131)


IIRC, you are not the first person to report an exception at this
spot in the code.  (Unfortunately, I can't locate the other thread
at the moment, but it was fairly recent.)


That was
https://issues.apache.org/bugzilla/show_bug.cgi?id=49488


The code in question has been run through many test cases,
inside and outside of Tomcat, and does not appear to contain any
errors (although it could be slightly more efficient).


Weird.  I couldn't find that in bugzilla.  Anyhow, it's Windows this
time too.


Tomislav: where is the Tomcat installation on the filing system, and
where are the webapps being deployed from, if not tomcat/webapps?

What type of filing system is it?


Also, did you manage to get hold of the config files yet?


Good news is when I put reloadable=false on context problem (both of
them, intermittent 404 too) went away, so I have workaround. Bad news
is server is going into production so no messing with it no more.

Yes, this is same bug as one in bugzilla, don't know if what triggered
is same.

Here is detailed info (my first suspect isResources in server.xml
but this is only my guess.

Tomcat is Apache Tomcat/6.0.24, running without tcnative-1.dll

Java version is: 1.6 update 18

Windows version: 2003 SP2 (32 bit)

NTFS file system is used, Tomcat is installed in D:\Program
Files\Apache Software Foundation\Tomcat 6.0 folder, webapp is in
D:\Program Files\Apache Software Foundation\Tomcat
6.0\webapps\some_name folder.

This is content of server.xml, I believe that all other conf files are
at their default values (except for pwd in users file), feel free to
ask for any other conf file.

?xml version='1.0' encoding='utf-8'?
Server port=8005 shutdown=SHUTDOWN

Listener className=org.apache.catalina.core.AprLifecycleListener
SSLEngine=on /
Listener className=org.apache.catalina.core.JasperListener /
Listener
className=org.apache.catalina.core.JreMemoryLeakPreventionListener /
Listener
className=org.apache.catalina.mbeans.ServerLifecycleListener /
Listener
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener /


GlobalNamingResources
  Resource name=UserDatabase auth=Container
type=org.apache.catalina.UserDatabase
description=User database that can be updated and saved

factory=org.apache.catalina.users.MemoryUserDatabaseFactory
pathname=conf/tomcat-users.xml /
  Resource name=jdbc/SomeDB auth=Container
type=javax.sql.DataSource
   maxActive=48
   maxIdle=10
   maxWait=1
   driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver
   username=auser
   password=*

url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName;loginTimeout=5

   removeAbandoned=true
   removeAbandonedTimeout=60
   logAbandoned=true
   validationQuery=SELECT 1/
  Resource name=jdbc/SomeDB2 auth=Container
type=javax.sql.DataSource
   maxActive=48
   maxIdle=10
   maxWait=1
   driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver
   username=auser2
   password=**
   url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName2
   removeAbandoned=true
   removeAbandonedTimeout=60
   logAbandoned=true
   validationQuery=SELECT 1/

/GlobalNamingResources

Service name=Catalina

  Connector port=8080 protocol=HTTP/1.1
 connectionTimeout=2
 redirectPort=8443 /
  Connector port=8009 protocol=AJP/1.3 redirectPort=8443 /

  Engine name=Catalina defaultHost=localhost

Realm className=org.apache.catalina.realm.UserDatabaseRealm
   resourceName=UserDatabase/

Host name=localhost  appBase=webapps
  unpackWARs=true autoDeploy=true
  xmlValidation=false xmlNamespaceAware=false

  Valve className=org.apache.catalina.valves.AccessLogValve
directory=logs
 prefix=localhost_access_log. suffix=.txt
pattern=common resolveHosts=false/

 Context path=/some_webapp docBase=/some_webapp debug=0
reloadable=true crossContext=true
 ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB
type=javax.sql.DataSource /
 ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2
type=javax.sql.DataSource /
  /Context
/Host
  /Engine
/Service
/Server

Let me know if I can provide any more info or update bugzilla (don't
have acc but can open).

Thanks to all for your

Re: Webapp reloading issue and intermittent 404 errors


Pid said on 30.6.2010 13:06:

On 30/06/2010 11:59, Tomislav Petrović wrote:

Context path=/some_webapp docBase=/some_webapp debug=0 reloadable=true 
crossContext=true
ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB 
type=javax.sql.DataSource /
ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2 
type=javax.sql.DataSource /


If these are the actual values then it's a miracle it's working at all.


Only app name/paths and jdbs names have been changed to dummy values.



Instead of defining it there, remove the debug, path and docBase
attributes and put it in

  some_webapp/META-INF/context.xml


Tomcat will work out the rest automatically.



Sorry for newbie question.
Can you post me how my new server.xml should look and how 
some_webapp/META-INF/context.xml should look.


Also would apprecite link to right documentation why it should be that 
way, thanks.


And do you really think this would solve my initial problem, or?

--
Tomy t.petro...@inet.hr

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Webapp reloading issue and intermittent 404 errors

 From: Pid [mailto:p...@pidster.com]
 Subject: Re: Webapp reloading issue and intermittent 404 errors

  JVM: have to check whether server or client, not sure at the moment.

 Server, one would hope.

Probably not - it's a 32-bit Windows, and you have to build your own JVM if you 
want a server version for that.

 Did you find out the exact version?

He stated 6u18.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Webapp reloading issue and intermittent 404 errors

On 30/06/2010 13:38, Caldarale, Charles R wrote:
 From: Pid [mailto:p...@pidster.com]
 Subject: Re: Webapp reloading issue and intermittent 404 errors

 JVM: have to check whether server or client, not sure at the moment.

 Server, one would hope.

 Probably not - it's a 32-bit Windows, and you have to build your own JVM if 
 you want a server version for that.

Really?!  I thought later versions had the server JVM too (for some
reason I now can't put my finger on).

 Did you find out the exact version?

 He stated 6u18.

I spotted it after I sent. Doh.

p

  - Chuck

 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
 MATERIAL and is thus for use only by the intended recipient. If you received 
 this in error, please contact the sender and delete the e-mail and its 
 attachments from all computers.

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

signature.asc
Description: OpenPGP digital signature

Re: Webapp reloading issue and intermittent 404 errors

2010-06-30 Thread David kerber

On 6/30/2010 8:41 AM, Pid wrote:

On 30/06/2010 13:38, Caldarale, Charles R wrote:

From: Pid [mailto:p...@pidster.com]
Subject: Re: Webapp reloading issue and intermittent 404 errors

JVM: have to check whether server or client, not sure at the moment.

Server, one would hope.

Probably not - it's a 32-bit Windows, and you have to build your own JVM if you 
want a server version for that.

Really?!  I thought later versions had the server JVM too (for some
reason I now can't put my finger on).

They do; I've been using the server version for quite a while on32-bit 
windows (the performance jumps were huge for some of my apps), and have 
never built a JVM myself.

D

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Webapp reloading issue and intermittent 404 errors

 From: Pid [mailto:p...@pidster.com]
 Subject: Re: Webapp reloading issue and intermittent 404 errors

  Probably not - it's a 32-bit Windows, and you have to build your own
  JVM if you want a server version for that.

 Really?!  I thought later versions had the server JVM too (for some
 reason I now can't put my finger on).

You're right - I stand corrected; there are both server and client DLLs in the 
32-bit download.  The 64-bit one continues to have only the server version.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Webapp reloading issue and intermittent 404 errors

2010-06-30 Thread David kerber

On 6/30/2010 8:38 AM, Caldarale, Charles R wrote:

From: Pid [mailto:p...@pidster.com]
Subject: Re: Webapp reloading issue and intermittent 404 errors

JVM: have to check whether server or client, not sure at the moment.

Server, one would hope.

Probably not - it's a 32-bit Windows, and you have to build your own JVM if you 
want a server version for that.

I think you've made your first mistake here, Chuck (at least the first 
one that I know enough about to catch!!).  If you download the jdk from 
Sun, you can get a server version of the jvm for Win32.  I've been using 
one for months for the performance gain in one of my apps.

D

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Webapp reloading issue and intermittent 404 errors

 From: Tomislav Petrović [mailto:t.petro...@inet.hr]
 Subject: Re: Webapp reloading issue and intermittent 404 errors

  Do you actually have an 'endorsed' directory in your Tomcat
  installation?  What's in it if you do?

 No I don't, this folder doesn't exist, will have to investigate 
 who put it in here.

Tomcat did, during the service installation.  Perfectly normal, but rarely 
useful.

 -XX:NewSize=16m
 -XX:MaxNewSize=16m

I would definitely remove both NewSize settings.  Not associated with the 
problem at hand, but probably detrimental to performance.  The JVM does a 
decent job of adjusting the NewSize value as needed for the current workload.

 Can you please point me in some doc documentation why it 
 isn't ok cause we had better experience with incgc than 
 default one on our load tests.

-Xincgc used to utilize the train GC model - which was a real dog and not 
capable of using multiple threads.  For current JVMs, -Xincgc triggers the 
concurrent (low pause) collector.  This will generally result in slightly less 
throughput, but much less stoppage time and somewhat less variation in response 
times.  If you're happy with it, leave it.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Webapp reloading issue and intermittent 404 errors

On 30/06/2010 12:45, Tomislav Petrović wrote:
 Pid said on 30.6.2010 13:12:
 On 30/06/2010 12:04, Tomislav Petrović wrote:
 Tomislav Petrović said on 30.6.2010 12:59:
 Pid said on 29.6.2010 23:20:
 On 29/06/2010 19:29, Konstantin Kolinko wrote:
 2010/6/29 Caldarale, Charles Rchuck.caldar...@unisys.com:
 From: Tomislav Petrović [mailto:t.petro...@inet.hr]
 Subject: Re: Webapp reloading issue and intermittent 404 errors

 org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131)

 IIRC, you are not the first person to report an exception at this
 spot in the code.  (Unfortunately, I can't locate the other thread
 at the moment, but it was fairly recent.)

 That was
 https://issues.apache.org/bugzilla/show_bug.cgi?id=49488

 The code in question has been run through many test cases,
 inside and outside of Tomcat, and does not appear to contain any
 errors (although it could be slightly more efficient).

 Weird.  I couldn't find that in bugzilla.  Anyhow, it's Windows this
 time too.

 Tomislav: where is the Tomcat installation on the filing system, and
 where are the webapps being deployed from, if not tomcat/webapps?

 What type of filing system is it?

 Also, did you manage to get hold of the config files yet?

 Good news is when I put reloadable=false on context problem (both of
 them, intermittent 404 too) went away, so I have workaround. Bad news
 is server is going into production so no messing with it no more.

 Yes, this is same bug as one in bugzilla, don't know if what triggered
 is same.

 Here is detailed info (my first suspect isResources in server.xml
 but this is only my guess.

 Tomcat is Apache Tomcat/6.0.24, running without tcnative-1.dll

 Java version is: 1.6 update 18

 Windows version: 2003 SP2 (32 bit)

 NTFS file system is used, Tomcat is installed in D:\Program
 Files\Apache Software Foundation\Tomcat 6.0 folder, webapp is in
 D:\Program Files\Apache Software Foundation\Tomcat
 6.0\webapps\some_name folder.

 This is content of server.xml, I believe that all other conf files are
 at their default values (except for pwd in users file), feel free to
 ask for any other conf file.

 ?xml version='1.0' encoding='utf-8'?
 Server port=8005 shutdown=SHUTDOWN

 Listener className=org.apache.catalina.core.AprLifecycleListener
 SSLEngine=on /
 Listener className=org.apache.catalina.core.JasperListener /
 Listener
 className=org.apache.catalina.core.JreMemoryLeakPreventionListener /
 Listener
 className=org.apache.catalina.mbeans.ServerLifecycleListener /
 Listener
 className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener
 /

 GlobalNamingResources
   Resource name=UserDatabase auth=Container
 type=org.apache.catalina.UserDatabase
 description=User database that can be updated and
 saved

 factory=org.apache.catalina.users.MemoryUserDatabaseFactory
 pathname=conf/tomcat-users.xml /
   Resource name=jdbc/SomeDB auth=Container
 type=javax.sql.DataSource
maxActive=48
maxIdle=10
maxWait=1

 driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver
username=auser
password=*

 url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName;loginTimeout=5

removeAbandoned=true
removeAbandonedTimeout=60
logAbandoned=true
validationQuery=SELECT 1/
   Resource name=jdbc/SomeDB2 auth=Container
 type=javax.sql.DataSource
maxActive=48
maxIdle=10
maxWait=1

 driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver
username=auser2
password=**

 url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName2
removeAbandoned=true
removeAbandonedTimeout=60
logAbandoned=true
validationQuery=SELECT 1/

 /GlobalNamingResources

 Service name=Catalina

   Connector port=8080 protocol=HTTP/1.1
  connectionTimeout=2
  redirectPort=8443 /
   Connector port=8009 protocol=AJP/1.3 redirectPort=8443 /

   Engine name=Catalina defaultHost=localhost

 Realm className=org.apache.catalina.realm.UserDatabaseRealm
resourceName=UserDatabase/

 Host name=localhost  appBase=webapps
   unpackWARs=true autoDeploy=true
   xmlValidation=false xmlNamespaceAware=false

   Valve className=org.apache.catalina.valves.AccessLogValve
 directory=logs
  prefix=localhost_access_log. suffix=.txt
 pattern=common resolveHosts=false/

  Context path=/some_webapp docBase=/some_webapp debug=0
 reloadable=true crossContext=true
  ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB
 type=javax.sql.DataSource /
  ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2
 type=javax.sql.DataSource /
   /Context
 /Host

RE: Webapp reloading issue and intermittent 404 errors

 From: Tomislav Petrović [mailto:t.petro...@inet.hr]
 Subject: Re: Webapp reloading issue and intermittent 404 errors

 Can you post me how my new server.xml should look and how
 some_webapp/META-INF/context.xml should look.

Just remove all Context elements from server.xml - it's bad practice to have 
them there, since it violates the principle of self-contained webapps, and 
making any changes require restarting Tomcat, not just the webapp.

Context reloadable=true crossContext=true
  ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB 
type=javax.sql.DataSource /
  ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2 
type=javax.sql.DataSource /
/Context

 Also would apprecite link to right documentation why it 
 should be that way, thanks.

http://tomcat.apache.org/tomcat-6.0-doc/config/context.html

 And do you really think this would solve my initial problem, or?

Nope.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Webapp reloading issue and intermittent 404 errors

On 30/06/2010 13:07, Tomislav Petrović wrote:
 Pid said on 30.6.2010 13:06:
 On 30/06/2010 11:59, Tomislav Petrović wrote:
 Context path=/some_webapp docBase=/some_webapp debug=0
 reloadable=true crossContext=true
 ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB
 type=javax.sql.DataSource /
 ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2
 type=javax.sql.DataSource /

 If these are the actual values then it's a miracle it's working at all.
 
 Only app name/paths and jdbs names have been changed to dummy values.
 

 Instead of defining it there, remove the debug, path and docBase
 attributes and put it in

   some_webapp/META-INF/context.xml


 Tomcat will work out the rest automatically.
 
 
 Sorry for newbie question.
 Can you post me how my new server.xml should look and how
 some_webapp/META-INF/context.xml should look.

Nope.  Just do the following, it's not complicated:

0. Stop Tomcat.

1. Create a file (in each app) myappname/META-INF/context.xml.

2. Copy the entire Context definition  it's sub-elements into the file

3. Remove the 3 attributes I named (debug is deprecated, path  docBase
aren't used here)

4. Completely delete the Context definitions from server.xml.

5. Start Tomcat.


 Also would apprecite link to right documentation why it should be that
 way, thanks.

It's in the same place as the rest of the documentation:

 http://tomcat.apache.org/tomcat-6.0-doc/config/context.html


 And do you really think this would solve my initial problem, or?

Maybe, maybe not, but if we eliminate all the possible problems, we'll
know it's not one of those.


p




signature.asc
Description: OpenPGP digital signature

Re: Webapp reloading issue and intermittent 404 errors


Pid said on 30.6.2010 15:05:

On 30/06/2010 13:07, Tomislav Petrović wrote:

Pid said on 30.6.2010 13:06:

On 30/06/2010 11:59, Tomislav Petrović wrote:

 Context path=/some_webapp docBase=/some_webapp debug=0
reloadable=true crossContext=true
 ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB
type=javax.sql.DataSource /
 ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2
type=javax.sql.DataSource /


If these are the actual values then it's a miracle it's working at all.


Only app name/paths and jdbs names have been changed to dummy values.



Instead of defining it there, remove the debug, path and docBase
attributes and put it in

   some_webapp/META-INF/context.xml


Tomcat will work out the rest automatically.



Sorry for newbie question.
Can you post me how my new server.xml should look and how
some_webapp/META-INF/context.xml should look.


Nope.  Just do the following, it's not complicated:

0. Stop Tomcat.

1. Create a file (in each app) myappname/META-INF/context.xml.

2. Copy the entire Context definition  it's sub-elements into the file

3. Remove the 3 attributes I named (debug is deprecated, path  docBase
aren't used here)

4. Completely delete the Context definitions from server.xml.

5. Start Tomcat.



Also would apprecite link to right documentation why it should be that
way, thanks.


It's in the same place as the rest of the documentation:

  http://tomcat.apache.org/tomcat-6.0-doc/config/context.html



And do you really think this would solve my initial problem, or?


Maybe, maybe not, but if we eliminate all the possible problems, we'll
know it's not one of those.




All advise them to do so in future installations but can't change that 
on this particular server anymore. Since workaround works server is 
going into production and hence freezed for all changes :(.


--
Tomy t.petro...@inet.hr

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Webapp reloading issue and intermittent 404 errors