> Is it possible to get at the LoginException in GF when authentication
> fails?
In Glassfish it is "possible" but you will have to implement a part of the authentication system used by the container for your application (this could be a JSR 196 server authentication module, a servlet filter or a Tomcat authenticator Valve).
Glassfish implements the servlet profile of jsr 196, which allows you to define a Server Authentication Module (SAM) that has full access to the servlet request and response messages; and that implements the desried "login mechanism". JSR 196 also defines a Login Bridge Profile, which defines how a SAM calls a JAAS login module, and in this case the SAM could trap any LoginException and store it such that it could be found by the subsequent error processing.
(Tomcat derived) authenticator valves also have access to the servlet request and response, so another approach would be to integrate your own version of the FormAuthenticator.
the above approaches are not universally applicable (at least at this time) so if you are looking for a more portable mechanism, another approach would be to define and configure a servlet filter on the login page of your application. The filter would trap the login error/exception, and put in a place where it can be found during the processing of the form error page. Jan suggested the session.
I haven't tried the servlet filter approach, so I apologize if you have already ruled that out. I can help you if you are interested in an approach based on the servlet profile of JSR 196.
As noted by Jan, the Servlet spec does not define how exceptions are passed from the processing of the form login page, through to the processing of the error page. Moreover, the Servlet spec does not require the use of JAAS for authentication, nor does it require that authentication failures be reported via LoginExceptions... so I think providing a portable solution would require work to be done at various levels.
"Perhaps" (as Jan suggested) it would be feasible to add something in the 3.0 Servlet spec to require that an exception resulting form the processing of j_security_check be reported via attributes of the session. FBL does typically create sessions prior to successful auth, so building in an error reporting reliance of FBL on a session may be acceptable.
Ron
ps: also as noted by Jan, the FormAuthenticator redirects to the error page to ensure that the proper constraints are enforced. another approach could be to change the FormAuthenticator, such that it only does a "redirect" to the error page, if the constraints on the error page are not satisfied by the current request (otherwise it could do a forward). For this to work, the protection on the error page would have to be no greater than that on the login page.
[Message sent by forum member 'monzillo' (monzillo)]
http://forums.java.net/jive/thread.jspa?messageID=265538