I am using Richfaces 3.3.1 and MyFaces 1.2.
I required to add File Upload in my JSF form.
I made a simple JSF form in which there was only one tag that is rich:fileupload, it was running properly and i added Listener too and the file was getting saved on the path I added.
But, as soon as I try to add some other tag in the page I get an exception which I could not figure out.
java.lang.NullPointerException
at javax.faces.webapp._ErrorPageWriter.writeVariables(_ErrorPageWriter.java:329)
at javax.faces.webapp._ErrorPageWriter.writeVariables(_ErrorPageWriter.java:305)
at javax.faces.webapp._ErrorPageWriter.debugHtml(_ErrorPageWriter.java:187)
at javax.faces.webapp._ErrorPageWriter.handleThrowable(_ErrorPageWriter.java:494)
at javax.faces.webapp._ErrorPageWriter.handleException(_ErrorPageWriter.java:479)
at javax.faces.webapp.FacesServlet.handleLifecycleException(FacesServlet.java:294)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:192)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:347)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:861)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:620)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:745)
This is caused by a bug in MyFaces error handler itself.
Somewhere in your code an exception occurred. MyFaces was trying to render a "nice" error page with some debug information and all about that exception. However, during rendering of that "nice" error page, it bugged with a NullPointerException and hence it couldn't finish the job to inform you about that exception. All detail about that underlying exception is apparently completely lost.
This is indeed not helpful. You could for now disable the MyFaces "nice" error page by adding the below entry to webapp's web.xml as per MyFaces documentation:
<context-param>
<param-name>org.apache.myfaces.ERROR_HANDLING</param-name>
<param-value>false</param-value>
</context-param>
This should present you the server default error page with the detail about the actual exception, so that you can finally investigate and fix it the usual way.
You can also try upgrading MyFaces 1.2 to latest 1.2.x available, which is currently 1.2.12, and see if the bug in its error handling is solved over there.
Related
I created a liferay plugin portlet project and deployed in Liferay 6.2. When i try to deploy, i am getting " Portlet Portlet_WAR_portletID has a null portlet bag" error. I am not able to find the root as i could see i am referring correct plugin project.
SEVERE: Servlet.service() for servlet jsp threw exception
java.lang.NullPointerException
at com.liferay.portlet.PortletContextFactory._create(PortletContextFactory.java:84)
at com.liferay.portlet.PortletContextFactory.create(PortletContextFactory.java:40)
at com.liferay.portlet.PortletConfigFactoryImpl.create(PortletConfigFactoryImpl.java:56)
at com.liferay.portlet.PortletConfigFactoryUtil.create(PortletConfigFactoryUtil.java:32)
at org.apache.jsp.html.portal.render_005fportlet_jsp._jspService(render_005fportlet_jsp.java:606)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at com.liferay.portal.servlet.DirectRequestDispatcher.include(DirectRequestDispatcher.java:57)
at com.liferay.portal.servlet.ClassLoaderRequestDispatcherWrapper.doDispatch(ClassLoaderRequestDispatcherWrapper.java:78)
at com.liferay.portal.servlet.ClassLoaderRequestDispatcherWrapper.include(ClassLoaderRequestDispatcherWrapper.java:53)
at com.liferay.portlet.PortletContainerImpl._doRender(PortletContainerImpl.java:655)
at com.liferay.portlet.PortletContainerImpl.render(PortletContainerImpl.java:138)
at com.liferay.portlet.SecurityPortletContainerWrapper.render(SecurityPortletContainerWrapper.java:141)
at com.liferay.portlet.RestrictPortletContainerWrapper.render(RestrictPortletContainerWrapper.java:126)
at com.liferay.portal.kernel.portlet.PortletContainerUtil.render(PortletContainerUtil.java:156)
at com.liferay.portal.layoutconfiguration.util.PortletRenderer._render(PortletRenderer.java:120)
at com.liferay.portal.layoutconfiguration.util.PortletRenderer.access$4(PortletRenderer.java:107)
at com.liferay.portal.layoutconfiguration.util.PortletRenderer$PortletRendererCallable.doCall(PortletRenderer.java:174)
at com.liferay.portal.layoutconfiguration.util.PortletRenderer$PortletRendererCallable.doCall(PortletRenderer.java:1)
at com.liferay.portal.kernel.executor.CopyThreadLocalCallable.call(CopyThreadLocalCallable.java:69)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at com.liferay.portal.kernel.concurrent.ThreadPoolExecutor$WorkerTask._runTask(ThreadPoolExecutor.java:682)
at com.liferay.portal.kernel.concurrent.ThreadPoolExecutor$WorkerTask.run(ThreadPoolExecutor.java:593)
at java.lang.Thread.run(Unknown Source)
Redeploy your portlet again. I faced same issue. I stop server and then clean my portlet then I started my server. When I checked in browser then I got internal server and in console "
portlet contains a null bag". I deployed again and the it is coming perfectly.
The most common solution for this problem is that just undeploy the portlet from the tomcat and redeploy it.
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
I am trying to run my javaEE site locally in Netbeans IDE. I believe I have everything set up correctly, but I am receiving the following error:
Initializing... deploy?DEFAULT=C:\Documents and
Settings\nicholasr\Desktop\Work Notes\temp code
files\ASP\build\web&name=ASP&force=true failed on GlassFish Server 3.1
Error occurred during deployment: Exception while deploying the app
[ASP] : Servlet [Resource Servlet] and Servlet [Persistent Faces
Servlet] have the same url pattern: [/xmlhttp/*]. Please see
server.log for more details. C:\Documents and
Settings\nicholasr\Desktop\Work Notes\temp code
files\ASP\nbproject\build-impl.xml:871: The module has not been
deployed. at
org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:187)
at org.netbeans.modules.j2ee.ant.Deploy.execute(Deploy.java:106) at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor62.invoke(Unknown Source) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597) at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348) at
org.apache.tools.ant.Target.execute(Target.java:390) at
org.apache.tools.ant.Target.performTasks(Target.java:411) at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at
org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:284)
at
org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:539)
at
org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:154)
BUILD FAILED (total time: 58 seconds)
I've done some searching on the net, but don't see any related links. Does anyone know why I would be getting this error and how it can be resolved? I can provide any additional information if needed. Thanks!
Error occurred during deployment: Exception while deploying the app [ASP] : Servlet [Resource Servlet] and Servlet [Persistent Faces Servlet] have the same url pattern: [/xmlhttp/]*
You seem to be using IceFaces. I don't do IceFaces, but the error message suggests that they shouldn't be mapped on the very same URL pattern. I did some minor research and based on the following documents...
Adding IceFaces 2 to your application
Converting IceFaces 1.8 to IceFaces 2
The previously declared Persistent Faces Servlet and Blocking Servlet are no longer needed in ICEfaces 2, as their functionality has changed and setup has been reduced. Remove all declarations and mappings for those two servlets:
... I can only conclude that the "Persistent Faces Servlet" is typical for IceFaces 1.8.x and the "Resource Servlet" is typical for IceFaces 2.x. You should use the one or the other, not both. I think you're targeting IceFaces 2.x, so you should get rid of the declaration and the mapping of the "Persistent Faces Servlet" in your web.xml altogether.
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
I'm running Tomcat 6.0.29 and created a realm and loginmodule of my own. They are defined in server.xml like so:
<Realm className="mycompany.tomcat.MyRepositoryRealm"
appName="My_Realm"
userClassNames="mycompany.tomcat.IdentityPrincipal"
roleClassNames="mycompany.tomcat.RolePrincipal"
useContextClassLoader="true"/>
I have added the library containing these classes to my tomcat/lib folder. Other than that, I have not changed Tomcat from it's default configuration.
When I go to fire up the Tomcat manager application at http://localhost:9080/manager/html, I can't log in and the tomcat log shows an error and stacktrace for my login module.
Any ideas? Thanks!
Edit:
Per request, here is the stacktrace. My realm connects to a JBoss service, so that's why I get the NamingContextFactory error.
javax.security.auth.login.LoginException: Cannot instantiate class: org.jnp.interfaces.NamingContextFactory
at mycompany.tomcat.MyRepositoryLoginModule.login(MyRepositoryLoginModule.java:88)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
at org.apache.catalina.realm.JAASRealm.authenticate(JAASRealm.java:410)
at org.apache.catalina.realm.JAASRealm.authenticate(JAASRealm.java:335)
at mycompany.tomcat.MyRepositoryRealm.authenticate(MyRepositoryRealm.java:34)
at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:181)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:528)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:619)
I was able to figure out the problem.
Security realms can be defined for an engine, host, or context. I had defined the realm for the whole host (in server.xml), so the tomcat manager application was trying to use it. I fixed the problem by defining the realm in a META-INF/context.xml file inside of my web application.