Salut,
glassfish_at_javadesktop.org wrote:
> @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.
OK let's say the Servlet class is missing or worse, web.xml. How can we
support the scenario? In that case, WebContainer doesn't know/have any
idea the request mapped to /yourServlet is an application that failed to
deploy because it cannot read that information (missing web.xml). Event
it he found it, how can WebContainer now /yourServlet is a valid URL
(but not a valid application)? How can we detect this is an invalid
links versus this is an invalid application? I agree it can be guessed
in some case, but in general, I don't think it is doable.
If you don't watch your server.log, you would think it is a true 404
error.
How are you deploying your application? The deploy command must have
failed...unless you are using the autodeploy directory, which I agree
could be problematic to find if it failed or not without looking at
server.log.
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.
If you try to deploy a war file (war-bogus) with path /myWar, but there
is already an application (war-ok) that use /myWar, how can sent the
information back to the browser that war-bogus failed to deploy? Issuing
/myWar will be mapped to war-ok all the times. So in that case, the only
solution is to look at server.log unfortunately.
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?
Usually when deployment pass but loading of the Servlet fail, you are
supposed to receive a 503 Not Available. But when the deployment fail,
The WebContainer has no idea about the failed deployment so it is
expected to get a 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.
I've missed that part. So your application deploy fine, but all requests
fails, right? Probably because your Servlet fail to load properly. I
agree in that case (deployment works, but runtime fail) you should have
got a 503 Not Available, not a 404. Can you share a simple test case?
A+
-- Jeanfrancois
>
>
> @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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>