You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Fred Toth <ft...@synernet.com> on 2012/11/02 20:27:17 UTC

Mystery migrating from tomcat 6 to 7

Hi,

I've got a struts2/spring app that's been running under tomcat 6 with no 
problems.

I migrated it to 7 and I've hit a strange brick wall. On startup, the 
logs show the app deploying, absolutely normally with no errors at all.

However, when I try to hit any URL within the app's context, I get "not 
found (404)". Absolutely nothing in the logs.

I'm deploying by creating "data.xml" in conf/Catalina/localhost (in both 
6 an 7). The app itself is an expanded application on the file system 
(i.e. not a .war file).

Thus, the URLs should be "/data/whatever", but somehow it appears that 
though the app deployed, the context is somehow wrong or broken.

Also, the manager app lists the application normally, shows it as 
running, shows it at the correct context, etc.

Anybody seen this? For reference, here's the content of data.xml, pretty 
simple:

<?xml version='1.0' encoding='utf-8'?>
<Context docBase="/mnt/data_arch/DATA"
     allowLinking="true"
     >
</Context>

Thanks,

Fred


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


Re: Mystery migrating from tomcat 6 to 7

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fred,

On 11/2/12 4:25 PM, Fred Toth wrote:
> Well, let me post at least the last bit (the whole thing is noisy
> and long). See below for the indication of a normal startup. In
> particular, my app finishes startup with "initialized Struts-Spring
> integration successfully" and tomcat indicates it's done with
> "Server startup in 7487 ms".
> 
> Also, no amount of waiting changes behavior. Again, when I get my
> 404 errors, I get nothing in catalina.out, as if to say tomcat
> isn't even seeing the request as an error.
> 
> (Note also that I'm running on port 80 temporarily while
> debugging.)

Try enabling an AccessLogValve for both the <Host> and the <Context>.
If it shows up in the context's access log, then it's likely an
app-level configuration problem. Otherwise, Tomcat is not routing
properly for some reason.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCULgkACgkQ9CaO5/Lv0PDLNACdEDk7HEfGRXP9dea1Ptbsm70n
o9MAnio7qngpI2xZPZPT4R4Qn2BavpRy
=QNQZ
-----END PGP SIGNATURE-----

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


Re: Mystery migrating from tomcat 6 to 7

Posted by Fred Toth <ft...@synernet.com>.
Hi,

Well, let me post at least the last bit (the whole thing is noisy and 
long). See below for the indication of a normal startup. In particular, 
my app finishes startup with "initialized Struts-Spring integration 
successfully" and tomcat indicates it's done with "Server startup in 
7487 ms".

Also, no amount of waiting changes behavior. Again, when I get my 404 
errors, I get nothing in catalina.out, as if to say tomcat isn't even 
seeing the request as an error.

(Note also that I'm running on port 80 temporarily while debugging.)

Thanks,

Fred

14:31:04,643  INFO StrutsSpringObjectFactory:42 - ... initialized 
Struts-Spring integration successfully
Nov 2, 2012 2:31:05 PM org.apache.catalina.startup.HostConfig 
deployDirectory
INFO: Deploying web application directory 
/usr/local/aapg/archive-server/apache-tomcat-7.0.32/webapps/manager
Nov 2, 2012 2:31:05 PM org.apache.catalina.startup.HostConfig 
deployDirectory
INFO: Deploying web application directory 
/usr/local/aapg/archive-server/apache-tomcat-7.0.32/webapps/examples
Nov 2, 2012 2:31:05 PM org.apache.catalina.startup.HostConfig 
deployDirectory
INFO: Deploying web application directory 
/usr/local/aapg/archive-server/apache-tomcat-7.0.32/webapps/host-manager
Nov 2, 2012 2:31:05 PM org.apache.catalina.startup.HostConfig 
deployDirectory
INFO: Deploying web application directory 
/usr/local/aapg/archive-server/apache-tomcat-7.0.32/webapps/docs
Nov 2, 2012 2:31:05 PM org.apache.catalina.startup.HostConfig 
deployDirectory
INFO: Deploying web application directory 
/usr/local/aapg/archive-server/apache-tomcat-7.0.32/webapps/ROOT
Nov 2, 2012 2:31:05 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-bio-80"]
Nov 2, 2012 2:31:05 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["ajp-bio-8009"]
Nov 2, 2012 2:31:05 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 7487 ms

On 11/2/2012 3:44 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Fred,
>
> On 11/2/12 3:27 PM, Fred Toth wrote:
>> I've got a struts2/spring app that's been running under tomcat 6
>> with no problems.
>>
>> I migrated it to 7 and I've hit a strange brick wall. On startup,
>> the logs show the app deploying, absolutely normally with no errors
>> at all.
>>
>> However, when I try to hit any URL within the app's context, I get
>> "not found (404)". Absolutely nothing in the logs.
>>
>> I'm deploying by creating "data.xml" in conf/Catalina/localhost (in
>> both 6 an 7). The app itself is an expanded application on the file
>> system (i.e. not a .war file).
>>
>> Thus, the URLs should be "/data/whatever", but somehow it appears
>> that though the app deployed, the context is somehow wrong or
>> broken.
>>
>> Also, the manager app lists the application normally, shows it as
>> running, shows it at the correct context, etc.
>>
>> Anybody seen this? For reference, here's the content of data.xml,
>> pretty simple:
>>
>> <?xml version='1.0' encoding='utf-8'?> <Context
>> docBase="/mnt/data_arch/DATA" allowLinking="true"
>> </Context>
> Something similar just happened to me a few minutes ago and it looks
> like I didn't wait for the app to fully-deploy. I wasn't getting 404s,
> though: I was getting long wait times for ultimately blank responses.
>
> Are you sure the app completed deployment? There may be DNS resolution
> or entropy-collection delays when starting-up.
>
> Can you paste the whole catalina.out you have after you launch Tomcat?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlCUIowACgkQ9CaO5/Lv0PBTowCeOojUpfud072CrPrKz5ZcNL5M
> bSkAnRpfIxicYa26lqcQ/bp8H8ldY4Nd
> =qTJo
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


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


Re: Mystery migrating from tomcat 6 to 7

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fred,

On 11/2/12 3:27 PM, Fred Toth wrote:
> I've got a struts2/spring app that's been running under tomcat 6
> with no problems.
> 
> I migrated it to 7 and I've hit a strange brick wall. On startup,
> the logs show the app deploying, absolutely normally with no errors
> at all.
> 
> However, when I try to hit any URL within the app's context, I get
> "not found (404)". Absolutely nothing in the logs.
> 
> I'm deploying by creating "data.xml" in conf/Catalina/localhost (in
> both 6 an 7). The app itself is an expanded application on the file
> system (i.e. not a .war file).
> 
> Thus, the URLs should be "/data/whatever", but somehow it appears
> that though the app deployed, the context is somehow wrong or
> broken.
> 
> Also, the manager app lists the application normally, shows it as 
> running, shows it at the correct context, etc.
> 
> Anybody seen this? For reference, here's the content of data.xml,
> pretty simple:
> 
> <?xml version='1.0' encoding='utf-8'?> <Context
> docBase="/mnt/data_arch/DATA" allowLinking="true"
>> 
> </Context>

Something similar just happened to me a few minutes ago and it looks
like I didn't wait for the app to fully-deploy. I wasn't getting 404s,
though: I was getting long wait times for ultimately blank responses.

Are you sure the app completed deployment? There may be DNS resolution
or entropy-collection delays when starting-up.

Can you paste the whole catalina.out you have after you launch Tomcat?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCUIowACgkQ9CaO5/Lv0PBTowCeOojUpfud072CrPrKz5ZcNL5M
bSkAnRpfIxicYa26lqcQ/bp8H8ldY4Nd
=qTJo
-----END PGP SIGNATURE-----

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


Re: Mystery migrating from tomcat 6 to 7

Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/11/2 Fred Toth <ft...@synernet.com>:
> Hi,
>
> I've got a struts2/spring app that's been running under tomcat 6 with no
> problems.
>
> I migrated it to 7 and I've hit a strange brick wall. On startup, the logs
> show the app deploying, absolutely normally with no errors at all.
>
> However, when I try to hit any URL within the app's context, I get "not
> found (404)". Absolutely nothing in the logs.
>
> I'm deploying by creating "data.xml" in conf/Catalina/localhost (in both 6
> an 7). The app itself is an expanded application on the file system (i.e.
> not a .war file).
>
> Thus, the URLs should be "/data/whatever", but somehow it appears that
> though the app deployed, the context is somehow wrong or broken.
>
> Also, the manager app lists the application normally, shows it as running,
> shows it at the correct context, etc.
>
> Anybody seen this? For reference, here's the content of data.xml, pretty
> simple:
>
> <?xml version='1.0' encoding='utf-8'?>
> <Context docBase="/mnt/data_arch/DATA"
>     allowLinking="true"
>     >
> </Context>

1. Are any symlinks that you are using within it readable? (There is
some reason why you are using allowLinking="true"...)

2. Have you seen the "Migration guide"?
http://tomcat.apache.org/migration.html

3. Maybe you can try with some simple web application that also uses Struts?

4. Configure an AccessLogValve in your web application. Does those 404
responses come from your web application?

Best regards,
Konstantin Kolinko

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


Re: Mystery migrating from tomcat 6 to 7

Posted by Fred Toth <ft...@synernet.com>.
On 11/13/2012 2:57 AM, Konstantin Kolinko wrote:
> It looks like it overrides the default mapping of this servlet. If I
> add the above fragment to web.xml of the docs application, I get 404
> in Tomcat 7, while in Tomcat 6 it works.
>
> If I replace above with the following, it works in Tomcat 7:
>
>   <servlet-mapping>
>     <servlet-name>default</servlet-name>
>     <url-pattern>/default/*</url-pattern>
>     <url-pattern>/</url-pattern>
>   </servlet-mapping>
>
> (Well, I do not know your whole web.xml. Just trying/guessing what it might be.)
>
> Servlet Spec 3.0 defines how web.xml fragments are merged. The
> algorithm is a bit complicated. This affects how the global web.xml is
> merged with webapp's one. (The change in the order of filters is one
> known example mentioned in Migration Guide).
>
> BTW, the effective merged web.xml can be printed into the log. There
> is an attribute on <Context> that enables such logging.
>
> Best regards,
> Konstantin Kolinko

Hi again,

It appears that I can get rid of my default servlet remapping 
completely. I've taken it out and adjusted my struts2 config and 
everything appears to be working.

If memory serves (always dicey), I came up with this concept originally 
with struts1 and tomcat5. I don't remember the exact circumstances, but 
it solved the problem of the moment and I've been carrying this along as 
the application and servers and frameworks have evolved. In this current 
case, it appears to be completely unnecessary.

Thanks again,

Fred



Re: Mystery migrating from tomcat 6 to 7

Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/11/13 Fred Toth <ft...@synernet.com>:
> On 11/12/2012 4:24 PM, Konstantin Kolinko wrote:
>>
>> 2012/11/13 Fred Toth <ft...@synernet.com>:
>>>
>>> Hello again,
>>>
>>> I've found my problem, sort of.
>>>
>>> In this particular application, ever since tomcat 5, we've been remapping
>>> the DefaultServlet url-pattern. Works fine in 5 and 6, but not in 7.
>>> Which
>>> means I've got another problem, but at least I know why the app fails to
>>> run.
>>>
>>> Here's the problem bit from my web.xml:
>>>
>>>      <servlet-mapping>
>>>          <servlet-name>default</servlet-name>
>>>          <url-pattern>/default/*</url-pattern>
>>>      </servlet-mapping>
>>>
>>> The idea here is to be able to do access control at the struts level, but
>>> then to be able to forward to DefaultServlet so that it can do what it
>>> does
>>> best (like serving PDFs, for example). I'm not sure why having this setup
>>> in
>>> tomcat 7 causes my app to fail completely, but taking this out cures the
>>> core problem. URLs start working properly, but now I have access control
>>> problems that were solved by the above.
>>>
>> It was a change to fix an issue important for security. See
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50026
>>
>>
>> If you just need to forward to the servlet, do you need to map it to
>> different path?
>> It is possible to select the servlet by its name,
>> ServletContext.getNamedDispatcher("default").forward(..)
>>
>> Best regards,
>> Konstantin Kolinko
>>
>
> Thanks for the pointer, Konstantin. This helps me understand the issues.
> However, any idea why that mapping should cause my entire app to fail? The
> forwards to "/default" happen only in fairly restricted circumstances. Why,
> for example, would this cause failures to serve everything else?
>
> To be more specific: We're serving *.html with struts2 and this has nothing
> to do with DefaultServlet. Yet somehow having that mapping in place breaks
> the whole thing.
>
> I'll try your suggestion (forwarding to DefaultServlet without the mapping)
> tomorrow.
>

It looks like it overrides the default mapping of this servlet. If I
add the above fragment to web.xml of the docs application, I get 404
in Tomcat 7, while in Tomcat 6 it works.

If I replace above with the following, it works in Tomcat 7:

 <servlet-mapping>
   <servlet-name>default</servlet-name>
   <url-pattern>/default/*</url-pattern>
   <url-pattern>/</url-pattern>
 </servlet-mapping>

(Well, I do not know your whole web.xml. Just trying/guessing what it might be.)

Servlet Spec 3.0 defines how web.xml fragments are merged. The
algorithm is a bit complicated. This affects how the global web.xml is
merged with webapp's one. (The change in the order of filters is one
known example mentioned in Migration Guide).

BTW, the effective merged web.xml can be printed into the log. There
is an attribute on <Context> that enables such logging.

Best regards,
Konstantin Kolinko

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


Re: Mystery migrating from tomcat 6 to 7

Posted by Fred Toth <ft...@synernet.com>.
On 11/12/2012 4:24 PM, Konstantin Kolinko wrote:
> 2012/11/13 Fred Toth <ft...@synernet.com>:
>> Hello again,
>>
>> I've found my problem, sort of.
>>
>> In this particular application, ever since tomcat 5, we've been remapping
>> the DefaultServlet url-pattern. Works fine in 5 and 6, but not in 7. Which
>> means I've got another problem, but at least I know why the app fails to
>> run.
>>
>> Here's the problem bit from my web.xml:
>>
>>      <servlet-mapping>
>>          <servlet-name>default</servlet-name>
>>          <url-pattern>/default/*</url-pattern>
>>      </servlet-mapping>
>>
>> The idea here is to be able to do access control at the struts level, but
>> then to be able to forward to DefaultServlet so that it can do what it does
>> best (like serving PDFs, for example). I'm not sure why having this setup in
>> tomcat 7 causes my app to fail completely, but taking this out cures the
>> core problem. URLs start working properly, but now I have access control
>> problems that were solved by the above.
>>
> It was a change to fix an issue important for security. See
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50026
>
>
> If you just need to forward to the servlet, do you need to map it to
> different path?
> It is possible to select the servlet by its name,
> ServletContext.getNamedDispatcher("default").forward(..)
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org

Thanks for the pointer, Konstantin. This helps me understand the issues. 
However, any idea why that mapping should cause my entire app to fail? 
The forwards to "/default" happen only in fairly restricted 
circumstances. Why, for example, would this cause failures to serve 
everything else?

To be more specific: We're serving *.html with struts2 and this has 
nothing to do with DefaultServlet. Yet somehow having that mapping in 
place breaks the whole thing.

I'll try your suggestion (forwarding to DefaultServlet without the 
mapping) tomorrow.

Thanks,

Fred


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


Re: Mystery migrating from tomcat 6 to 7

Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/11/13 Fred Toth <ft...@synernet.com>:
> Hello again,
>
> I've found my problem, sort of.
>
> In this particular application, ever since tomcat 5, we've been remapping
> the DefaultServlet url-pattern. Works fine in 5 and 6, but not in 7. Which
> means I've got another problem, but at least I know why the app fails to
> run.
>
> Here's the problem bit from my web.xml:
>
>     <servlet-mapping>
>         <servlet-name>default</servlet-name>
>         <url-pattern>/default/*</url-pattern>
>     </servlet-mapping>
>
> The idea here is to be able to do access control at the struts level, but
> then to be able to forward to DefaultServlet so that it can do what it does
> best (like serving PDFs, for example). I'm not sure why having this setup in
> tomcat 7 causes my app to fail completely, but taking this out cures the
> core problem. URLs start working properly, but now I have access control
> problems that were solved by the above.
>

It was a change to fix an issue important for security. See
https://issues.apache.org/bugzilla/show_bug.cgi?id=50026


If you just need to forward to the servlet, do you need to map it to
different path?
It is possible to select the servlet by its name,
ServletContext.getNamedDispatcher("default").forward(..)

Best regards,
Konstantin Kolinko

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


Re: Mystery migrating from tomcat 6 to 7

Posted by Fred Toth <ft...@synernet.com>.
Hello again,

I've found my problem, sort of.

In this particular application, ever since tomcat 5, we've been 
remapping the DefaultServlet url-pattern. Works fine in 5 and 6, but not 
in 7. Which means I've got another problem, but at least I know why the 
app fails to run.

Here's the problem bit from my web.xml:

     <servlet-mapping>
         <servlet-name>default</servlet-name>
         <url-pattern>/default/*</url-pattern>
     </servlet-mapping>

The idea here is to be able to do access control at the struts level, 
but then to be able to forward to DefaultServlet so that it can do what 
it does best (like serving PDFs, for example). I'm not sure why having 
this setup in tomcat 7 causes my app to fail completely, but taking this 
out cures the core problem. URLs start working properly, but now I have 
access control problems that were solved by the above.

Could be the topic of another thread after I dig some more.

Thanks,

Fred

On 11/12/2012 2:27 PM, Fred Toth wrote:
> Hi,
>
> Sorry, just getting back to this after a delay.
>
> I've added an AccessValve to my context and it, too, reports 404. So 
> this is more confirmation that my context has actually deployed (as 
> the logs report), and, at least at some level, the requests are being 
> mapped by tomcat to the correct context. But no clue as to why my URLs 
> don't work.
>
> We do use some symlinks in our application, yes. Fiddling with 
> allowLinking true/false has no effect.
>
> And yes, I've read (and re-read) the migration guide and as far as I 
> can tell, nothing there is relevant to my problem.
>
> And no, we're not using an NFS share. Normal mount points. (I'm 
> curious though. What's wrong with running the app from NFS?)
>
> Any other ideas about where I can look?
>
> Again, all I have to do is switch to tomcat 6 and everything works 
> normally.
>
> Thanks all,
>
> Fred
>
> On 11/7/2012 3:20 PM, Pid wrote:
>> On 02/11/2012 19:27, Fred Toth wrote:
>>> <Context docBase="/mnt/data_arch/DATA"
>> Is your application mounted on an NFS share?
>>
>>
>> p
>>
>> (hint: don't do that.)
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


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


Re: Mystery migrating from tomcat 6 to 7

Posted by Fred Toth <ft...@synernet.com>.
Hi,

Sorry, just getting back to this after a delay.

I've added an AccessValve to my context and it, too, reports 404. So 
this is more confirmation that my context has actually deployed (as the 
logs report), and, at least at some level, the requests are being mapped 
by tomcat to the correct context. But no clue as to why my URLs don't work.

We do use some symlinks in our application, yes. Fiddling with 
allowLinking true/false has no effect.

And yes, I've read (and re-read) the migration guide and as far as I can 
tell, nothing there is relevant to my problem.

And no, we're not using an NFS share. Normal mount points. (I'm curious 
though. What's wrong with running the app from NFS?)

Any other ideas about where I can look?

Again, all I have to do is switch to tomcat 6 and everything works normally.

Thanks all,

Fred

On 11/7/2012 3:20 PM, Pid wrote:
> On 02/11/2012 19:27, Fred Toth wrote:
>> <Context docBase="/mnt/data_arch/DATA"
> Is your application mounted on an NFS share?
>
>
> p
>
> (hint: don't do that.)
>
>
>


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


Re: Mystery migrating from tomcat 6 to 7

Posted by Pid <pi...@pidster.com>.
On 02/11/2012 19:27, Fred Toth wrote:
> <Context docBase="/mnt/data_arch/DATA"

Is your application mounted on an NFS share?


p

(hint: don't do that.)



-- 

[key:62590808]