Error pages with Servlet 3.0 - spring

In the web.xml file, I'm trying to specify an error page as follows.
<error-page>
<location>/WEB-INF/jsp/admin/ErrorPage.jsp</location>
</error-page>
I expect it to go without an error code according to Servlet 3.0 but it doesn't. I have to explicitly specify an appropriate error code for it to work something like the following.
<error-page>
<description>Missing page</description>
<error-code>404</error-code>
<location>/WEB-INF/jsp/admin/ErrorPage.jsp</location>
</error-page>
Why doesn't the former approach work with Servlet 3.0?
I have upgraded NetBeans 7.2.1. It supports Apache Tomcat 7.0.27.0 which has Servlet 3.0 API.
By the way, I have disabled the HTTP Monitor as it raises the following warning.
MonitorFilter::WARNING: the monitor filter must be the first filter in
the chain.
It happened when I used Spring security in my application and it was reported as a jira issue.

Have a look at this post. I never personally made this
<error-page>
<location>/WEB-INF/jsp/admin/ErrorPage.jsp</location>
</error-page>
working on Tomcat 7, as for the bug described in the link I gave you. I don't know if Apache solved it in later version of Tomcat, but I doubt.
My previous statement was probably wrong. Digging a bit, I found this: https://issues.apache.org/bugzilla/show_bug.cgi?id=52135 and the problem should have been solved in Tomcat 7.0.29, so your only solution is to update to post-29 version.
Here: http://tomcat.apache.org/tomcat-7.0-doc/changelog.html, in the changelog for version 7.0.29 you can read why there was such an issue:
Add support for a default error page to be defined in web.xml by
defining an error page with just a nested location element. It appears
this feature was intended to be included in the Servlet 3.0
specification but was accidently left out. (markt)

Related

How to disable clientwindow feature in jsf 2.2

I am running an jsf2.2 application and using Primefaces with JAVA 1.6, i am trying to disable the client window feature which removes the jfwid.Please suggest me how i can handle this issue.
I believe the ClientWindow feature is disabled by default. The following JavaDoc details the behavior:
http://docs.oracle.com/javaee/7/api/javax/faces/lifecycle/ClientWindow.html#CLIENT_WINDOW_MODE_PARAM_NAME
Also I'm not sure why disableClientWindow would be expected on a p:commandButton(h:commandButton) as that is a POST request whereas the p:button(h:button) would be a GET request.
Looking at the vld docs for the h:commandButton you'll see there is not a disableClientWindow attribute but on the h:button there is.
I've tried disable it to all application on web.xml, but without any success. I tried the follow:
<context-param>
<param-name>javax.faces.lifecycle.ClientWindow.CLIENT_WINDOW_MODE_PARAM_NAME</param-name>
<param-value>none</param-value>
</context-param>
The only way that I got it to work was using it on code before a redirect, for example:
FacesContext.getCurrentInstance().getExternalContext().getClientWindow().disableClientWindowRenderMode(FacesContext.getCurrentInstance());
return "/home?faces-redirect=true";
Or using it on own button or link:
<a jsf:disableClientWindow="true" target="_blank" jsf:outcome="go_to_anywhere?faces-redirect=true">GoToAnywhere</a>

Handle ViewExpiredExceptions from AJAX requests with Primefaces 5.1

I have a JSF 2.1 + Primefaces 5.1 web application and I want to handle ViewExpiredExceptions. Besides the configuration in web.xml (mapping the exception to a location via <error-page>), I read that we need to treat these exceptions when they are thrown during ajax requests.
Primefaces provides a <p:ajaxExceptionHandler> for this purpose. I tried to use it and, although I could see the exception being thrown in the server log, I could not do anything else. Maybe I'm using it the wrong way. How could I, for instance, send the user to the index.xhtml page when such an exception occurs, refreshing all ajax components?
I defined the exception handler factory in faces-config.xml:
<factory>
<exception-handler-factory>
org.primefaces.application.exceptionhandler.PrimeExceptionHandlerFactory
</exception-handler-factory>
</factory>
And declared the facelets handler in my template page:
<p:ajaxExceptionHandler type="javax.faces.application.ViewExpiredException"/>
Here's my web.xml configuration for these exceptions:
<error-page>
<exception-type>javax.faces.application.ViewExpiredException</exception-type>
<location>/index.xhtml</location>
</error-page>
After being unsuccessful with this approach, I tried the explicit definition of the exception handler (Check if session exists JSF) but without success either.
Can anyone tell me how to solve this problem? (I'm trying to stick with plain JSF and Primefaces, although I know that Omnifaces provides a similar solution to Primefaces', but I haven't tried it yet).

Can <security-constraint> tag in web.xml be dynamically generated or written outside web.xml?

I met a problem, I want to set the tag of security-constraint according to my configuration file dynamically, but I can't do it. So I hope tag in web.xml can be dynamically generated or written outside web.xml. Thanks a lot for your help!
I think your question could be related to this one. However, if you were working with Servlet 3.0 spec, you could try the approach of programmatically adding and configuring security for the servlet, as shown here.

websphere 7 shows full error to customer on web app deployment/starting error

i have deployed my web application in WebSphere 7. this application is build using spring and jsp servlets. some times when it get deployed due to errors it shows the following attached image like errors.
i have handled my web application errors as follows, by redirecting the errors to spring controller.
<error-page>
<error-code>500</error-code>
<!--Internal server error -->
<location>/error.p?message=500</location>
</error-page>
<error-page>
<error-code>403</error-code>
<!--Forbidden -->
<location>/main.p</location>
</error-page>
but it only works when the web application is successfully deployed. when deployment error happens WebSphere shows full error message like above.
is there any way to hide this error page and add custom error page in websphere when such deployment errors happens?
If you have an Apache server (or other) in front of your WebSphere, you may use it to redirect error 500 on a custom static web page.
Since you're using Spring, if this error can occur often, you can try to use lazy bean initialization on the remoteOMSConnectorWS (See LazyInitTargetSource). This would delay bean instantiation until its first use, most likely after webapp complete startup. In this case, your error configuration from web.xml could be used.

Error location always from root of site?

I have this XML in my web.xml file:
<error-page>
<error-code>404</error-code>
<location>/error/html/404</location>
</error-page>
If I go to a page like /indexer (which doesn't exist), then I get redirected properly to the URL /error/html/404. If I go to a page like /index/nope (which also doesn't exist), then I a blank page and the URL reads /index/error/html/404. What can I put in the location tag to always get the correct URL, regardless of where I started?
This is not normal behaviour. It should definitely be relative to the context root. I cite from page 154 of the Servlet 3.0 specification:
The subelement location element contains the location of the resource in the web
application relative to the root of the web application. The value of the location
must have a leading ‘/’.
Your problem is caused by a bug in the servletcontainer used. Report it and/or upgrade to latest version. Or, perhaps you've a bad Filter intercepting on ERROR dispatcher for an URL pattern of /* which is using the RequestDispatcher#forward() wrongly.
Update as per the comments, you're using Tomcat 7.0.16, which is a Servlet 3.0 compatible container. Although your web.xml is declared conform Servlet 2.5 instead of 3.0, I can't reproduce your problem with both web.xml versions on my local Tomcat 7.0.11, 7.0.19 nor 7.0.22. Also, the URL does not change here in browser address bar (and is not supposed to change). Just the original (wrong) URL remains in browser address bar. This makes me think that this is more likely caused by a bad filter or possibly a front controller servlet which is mapped on a too generic URL pattern of /* and is sending a redirect to the wrong URL. Check for such a filter or servlet in your webapp, debug and fix it accordingly.

Resources