We have an application which uses JSF2 and Spring. The application works fine when deployed. But this happens if I went through the following steps:
Open the login page of the application.
Redeployed the application on the server.
Tried to login using the previously opened login page, and it shows the following exception:
javax.servlet.ServletException: null source
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:321)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
root cause
java.lang.IllegalArgumentException: null source
at java.util.EventObject.<init>(EventObject.java:38)
at javax.faces.event.SystemEvent.<init>(SystemEvent.java:67)
at javax.faces.event.ComponentSystemEvent.<init>(ComponentSystemEvent.java:69)
at javax.faces.event.PostRestoreStateEvent.<init>(PostRestoreStateEvent.java:69)
at com.sun.faces.lifecycle.RestoreViewPhase.deliverPostRestoreStateEvent(RestoreViewPhase.java:256)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:245)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:97)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:107)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:114)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:308)
If I click on the first login page and then enter the login details the application does not break. This only occurs if I try to use the previously loaded login page with the newly deployed application.
Anyone knows the answer?
This one should have been thrown as a ViewExpiredException. It's a bug which started to manifest in Mojarra 2.0.3 and is been fixed in Mojarra 2.1.0. See also issue 1762 (note that Mojarra 2.1.0 doesn't work on Tomcat/Jetty, use at least Mojarra 2.1.1 then).
Basically, when Mojarra fails to build or restore the view, then it usually throws a specific enough exception, but due to this bug, a valid view was incorrectly been expected later in the code which in turn results in IllegalArgumentException: null source. The possible real cause would have been that the view contains a simple XML syntax error, such as a missing tag or broken attribute value, for which Mojarra would usually have thrown a FaceletException with a very detailed message with line number and position and such.
To prevent the ViewExpiredException, you would have to refresh the page by a GET request before doing any actions on it. If you're using a Mojarra version where this bug does not manifest (e.g. 2.0.2 or older, or 2.1.0 or newer), then you could gracefully handle it with an <error-page> in web.xml on the particular exception and provide a custom error page wherein the enduser is informed that the session has been expired, along with a link to the initial request URI.
This looks like http://java.net/jira/browse/JAVASERVERFACES-1758
which is not fixed in Mojarra 2.1.x
As long as javax.faces.PARTIAL_STATE_SAVING is set to false you'll receive that java.lang.IllegalArgumentException. If you set javax.faces.PARTIAL_STATE_SAVING to true (and you know what you are doing) you will get the "good old" javax.faces.application.ViewExpiredException back.
In my case turned out i had missing end tag in xhtml file for one of the jstl calls. i was using choose tag and one of the when tags in between choose did not have an end tag
Related
org.primefaces.webapp.filter.FileUploadFilter does not registered to my application, unless I define FileUploadFilter explicitly in my spring configuration like;
#Bean
FileUploadFilter fileUploadFilter() {
return new FileUploadFilter();
}
Referring to this question;
If you're however not using JSF 2.2 yet and you can't upgrade it
(should be effortless when already on a Servlet 3.0 compatible
container), then you need to manually register the below PrimeFaces
file upload filter in web.xml (it will parse the multi part request
and fill the regular request parameter map so that FacesServlet can
continue working as usual)
Conversely I have javax.faces in my classpath: org.glassfish:javax.faces:jar:2.2.13:compile. (and mojarra impl)
Should we go manually with this? Or else It can not be detected and registered automatically, we have to register a manual configuration to joinfaces
UPDATE: Actually this is not directly relevant to registration of FileUploadFilter. Embedded jetty in spring-boot does not pick up annotated configurations example of which FacesServlet has a #MultipartConfig annotation. I have opened an issue to spring-boot for that:
https://github.com/spring-projects/spring-boot/issues/6681
https://github.com/spring-projects/spring-boot/issues/6680 will fix the issue. WebServletHandler will pick up #MultipartConfig annotated classes.
I'm building a web application running on Liberty profile 8.5, with JSF 2.0 feature enabled (jsf-2.0 in server.xml) and BIRT integration in the web app.
The web application includes all BIRT needed libs in WEB-INF/lib folder, but the only way to make it working (specially for chart report) is to set the classloader to 'parentlast' in the server.xml:
<webApplication contextRoot="MyApp" id="MyApp" location="MyApp.war" name="MyApp">
<classloader delegation="parentLast"/>
</webApplication>
In this way, I correctly see charts and reports.
But the 'parentlast' setting makes JSF not working, with this exception:
[ERROR ] SRVE0315E: An execption occurred:
com.ibm.ws.webcontainer.webapp.WebAppErrorReport:
javax.servlet.ServletException: SRVE0207E: Uncaught initialization
exception created by servlet at
com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:385)
at [internal classes] Caused by: javax.servlet.ServletException:
SRVE0207E: Uncaught initialization exception created by servlet ... 3
more
Caused by: java.lang.IllegalStateException: No Factories configured for this Application. This happens if the faces-initialization does not work at all - make sure that you properly include all configuration settings necessary for a basic faces application and that all the necessary libs are included. Also check the logging output of your web application and your container for any exceptions!
If you did that and find nothing, the mistake might be due to the fact that you use some special web-containers which do not support registering context-listeners via TLD files and a context listener is not setup in your web.xml.
A typical config looks like this;
<listener><listenerclass>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>
Without the parentlast setting, the JSF pages are correctly shown, but BIRT charts don't work.
I understand this behaviour, as the parentlast classloading makes the application seeing at first the application libs, where JSF is not included (it's loaded at server scope).
Any suggestion?
Thank you in advance!
our customer doesn't want to have session handling with cookies and it also will cause problems with an Apache/mod_rewrite gateway, so i tried to use
<tracking-mode>URL</tracking-mode>
in our web.xml. That should be all with Glassfish3/Servlet 3.0. However now i get ViewExpiredExceptions when trying to log in(it's not an AJAX request):
<p:commandButton id="submit"
value="${msg['Login.submit.label']}"
action="#{loginBean.login}"
ajax="false"/>
I also tried to save the session on the client side, than i can see the JSESSIONID in the URL but that throws NotSerializableExceptions for my #EJBs. Any ideas? Do i miss something? It used to work fine with the cookies.
UPDATE: LoginBean.login returns "Home.xhtml?faces-redirect=true", expected behaviour when clicking the commandButton: POST on Login.xhtml, my login page, redirect and GET on Home.xhtml.
SECOND UPDATE:
Looks like my action never gets called, i'm directly getting the ViewExpiredException and a HTTP 500 error code.
THIRD UPDATE:
Looks like the HttpSession is always null with tracking mode set to URL, with cookies the HttpSession is correctly created. Shouldn't the FacesServlet create a session and append the JSESSIONID in the URL if there is no session?
ANOTHER UPDATE:
With
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
the session will be created on postback. But than i'm running into
java.io.NotSerializableException
.
The other option is to set restore view compability to true.
Edit your web.xml and add following code and try.
<context-param>
<param-name>com.sun.faces.enableRestoreView11Compatibility</param-name>
<param-value>true</param-value>
</context-param>
Updated:
Reference
com.sun.faces.enableRestoreView11Compatibility is a JSF 1.2 setting that tells JSF 1.2 to behave like JSF 1.1.
com.sun.faces.enableRestoreView11Compatibility == true means "do not throw a ViewExpiredException; instead, just create a new view if the old one has expired."
The IBM notes on the JSF 1.1 behaviour say:
This can have adverse behaviors because it is a new view, and items that are usually in the view, such as state, are no longer be there.
The default JSF 1.2 behaviour is defined in the spec as this:
If the request is a postback, call ViewHandler.restoreView(), passing the FacesContext instance for the current request and the view identifier, and returning a UIViewRoot for the restored view. If the return from ViewHandler.restoreView() is null, throw a ViewExpiredException with an appropriate error message. javax.faces.application.ViewExpiredException is a FacesException` that must be thrown to signal to the application that the expected view was not returned for the view identifier. An application may choose to perform some action based on this exception.
To have a ViewExpiredException thrown when the view expires, remove the com.sun.faces.enableRestoreView11Compatibility parameter or set it to false.
The com.sun namespace suggests that the parameter is a Sun/Mojarra and derived implementation-specific setting, so it probably will not work with all JSF implementations.
Fixed by updating Mojarra. My Glassfish 3.1.2.2 came with Mojarra 2.1.6 and this bug:
https://java.net/jira/browse/JAVASERVERFACES-2143
Updated to 2.1.22 and everything works.
I'm developing JSF application with mojarra.
I'm getting javascript error "mojarra is not defined".
After deploy everything is ok, ajax call works properly.
But after refreshing page, error appears.
There is lack of javascript include in head tag after refreshing.
It seems to be working very moody.
Same behavior I have on Tomcat and Glassfish, Mojarra is in version 2.0.3.
One of the reason this error can appear is by using <head>..</head> and <body>...</body> tags instead of <h:head>...</h:head> and <h:body>...</h:body>.
Namespace - xmlns:h="http://java.sun.com/jsf/html"
I am planning to use Cometd library in my application that runs on JBoss AS 6. Therefore I downloaded cometd 2.4.0 and tried to deploy example war (from cometd-demo/target) to my AS. I was aware that this was not possible without modifications, so I did the changes in web.xml:
Changed to servlet 3.0 in web-app tag (it is originally 2.5). Used complete tag from CometD faq answer. Also uncommented continuation filter that was already in web.xml, based on this description
Based on faq answer, added async-supported tag. However, this causes problems: if I just uncomment it, web.xml can't be parsed. I found out that this is due to order of tags in XML, so moved async-supported tag down the order, just after load-on-startup tag. However, Jboss still throws exceptions:
ERROR
[org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/cometd-demo-2.4.0].[cometd]]
Servlet.service() for servlet cometd threw exception:
java.lang.IllegalStateException: The servlet or filters that are being
used by this request do not support async operation
ERROR
[org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/cometd-demo-2.4.0].[cometd]]
Servlet.service() for servlet cometd threw exception:
java.lang.ClassNotFoundException:
org.eclipse.jetty.server.AbstractHttpConnection from
BaseClassLoader#12a54b
Complete web.xml file that I use is here.
Example runs no my Jboss despite all errors reported, but by watching firebug, I can see that it does quick pooling instead of long pool. It seems that server thinks that browser has multiple connections open, which is not the case (see JSON below):
[{"id":"137","successful":true,"advice":{"interval":2000,"reconnect":"retry","multiple-clients":true,"timeout":20000},"channel":"/meta/connect"}]
Did anyone managed to make examples work with JBoss as6 and how? What I did wrong here?
remove:
<!-- Portability Filter, needed only to run on non Jetty or non Servlet-3.0 containers -->
<filter>
<filter-name>continuation</filter-name>
<filter-class>org.eclipse.jetty.continuation.ContinuationFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>continuation</filter-name>
<url-pattern>/cometd/*</url-pattern>
</filter-mapping>
from web.xml
I have the same setup and the same problem even if I remove continuation filter from web.xml.
I've found a thread on cometd-users group complaining about multiple-client issue on Tomcat 7 and the cause seems to be a Tomcat bug around Content-Type that is not set to "application/json".
However I've inspected packets and on JBossAS6 the content-type is correctly set on server responses.
UPDATE
I've give a try using Jetty 7 and the problem disappeared. The "multiple-clients" issue affects Tomcat as well as JBoss6 AS