@Jeanfrancois
[b]>> I'm really interested to see your test case as if the JSP fail for some
reason to compile/render, you should have got an exception from there
and not a 404.[/b]
Indeed, isn't this the point? A missing class or jar invites a 404 response in glassfish. If you don't watch your server.log, you would think it is a true 404 error. After painstaking effort--almost like finding a needle in a haystack-- , you find the problem to be a missing class, shared jar or [inappriopriate] setting in the web.xml. But glassfish is indiscriminate about all these errors and displays them as 404. Then in the server.log, you discover that:
1. On finding [missing class or jar or whatever] error, glassfish goes in search of the page in “/glassfish/domains/domain1/docroot”. And when that fails--as it is bound to do--it then displays a HTTP Status 404. I ask, isn't this promiscuous use of 404 not a misuse or even an abuse of the spirit of the HTTP Status 404?
[b]>>How do you deploy your application? The deployment must have failed,
hence your are getting 404, which is the expected status/error.[/b]
In my opening salvo (above) I said “...after a successful verification and deployment...” I therefore don't understand the basis of your assumption, unless you are implying that a verification and deployment, flagged as successful by glassfish is not what it says they are.
@Alex Sherwin
[b]I've never had a problem with any WAR files deployed with 404 errors[/b]
Or put another way, “[u]It works for me[/u]” (IW4M)--always an irritant response. Fine, but it works for you doesn't mean it works for everyone, otherwise one wouldn't be raising the issue, would one? Beside, it is EAR and not WAR—similar but different requirements. Thanks for your response anyway.
[Message sent by forum member 'nuffsaidx' (nuffsaidx)]
http://forums.java.net/jive/thread.jspa?messageID=324958