When running in Tomcat I can't see uncaught Facelet Runtime Exceptions being output in the catalina.out or localhost log files.
When running in Jetty I get the following:
2014-05-24 11:15:44.804:WARN:oejs.ServletHandler:/delivery
javax.faces.view.facelets.FaceletException: Error Parsing /delivery.xhtml: Error Traced[line: 47] The entity name must immediately follow the '&' in the entity reference.
at com.sun.faces.facelets.compiler.SAXCompiler.doCompile(SAXCompiler.java:456)
at com.sun.faces.facelets.compiler.SAXCompiler.doMetadataCompile(SAXCompiler.java:439)
at com.sun.faces.facelets.compiler.Compiler.metadataCompile(Compiler.java:130)
at com.sun.faces.facelets.impl.DefaultFaceletFactory.createMetadataFacelet(DefaultFaceletFactory.java:495)
at com.sun.faces.facelets.impl.DefaultFaceletFactory.access$200(DefaultFaceletFactory.java:106)
at com.sun.faces.facelets.impl.DefaultFaceletFactory$2.newInstance(DefaultFaceletFactory.java:205)
at com.sun.faces.facelets.impl.DefaultFaceletFactory$2.newInstance(DefaultFaceletFactory.java:203)
at com.sun.faces.facelets.impl.DefaultFaceletCache$2.newInstance(DefaultFaceletCache.java:97)
at com.sun.faces.facelets.impl.DefaultFaceletCache$2.newInstance(DefaultFaceletCache.java:92)
at com.sun.faces.util.ExpiringConcurrentCache$1.call(ExpiringConcurrentCache.java:99)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at com.sun.faces.util.ExpiringConcurrentCache.get(ExpiringConcurrentCache.java:114)
at com.sun.faces.facelets.impl.DefaultFaceletCache.getViewMetadataFacelet(DefaultFaceletCache.java:146)
at com.sun.faces.facelets.impl.DefaultFaceletCache.getViewMetadataFacelet(DefaultFaceletCache.java:63)
at com.sun.faces.facelets.impl.DefaultFaceletFactory.getMetadataFacelet(DefaultFaceletFactory.java:316)
at com.sun.faces.facelets.impl.DefaultFaceletFactory.getMetadataFacelet(DefaultFaceletFactory.java:246)
at com.sun.faces.application.view.ViewMetadataImpl.createMetadataView(ViewMetadataImpl.java:114)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:241)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:575)
Related
This question already has an answer here:
How to properly install and configure JSF libraries via Maven?
(1 answer)
Closed 5 years ago.
I am migrating from glassfish 4 to wildfly 8.1.
Before project had been migrated from jsf 2.0 to jsf 2.2 and everything worked well on glassfish 4
This exception comes when I try to deploy an application to wildfly 8.1:
INFO [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-4) Initializing Mojarra 2.2.6-jbossorg-4 20140501-1134 for context ''
22:35:02,685 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-4) Critical error during deployment: : com.sun.faces.config.ConfigurationException: The tag named inputFile from namespace http://xmlns.jcp.org/jsf/html has a null handler-class defined
at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processHandlerClass(FaceletTaglibConfigProcessor.java:422) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTags(FaceletTaglibConfigProcessor.java:378) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTagLibrary(FaceletTaglibConfigProcessor.java:321) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:270) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:437) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216) [jsf-impl-2.2.6-jbossorg-4.jar:]
at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:190) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
22:35:02,686 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: The tag named inputFile from namespace http://xmlns.jcp.org/jsf/html has a null handler-class defined
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:219)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
... 3 more
Caused by: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: The tag named inputFile from namespace http://xmlns.jcp.org/jsf/html has a null handler-class defined
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:275)
at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173)
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:190)
... 7 more
Caused by: com.sun.faces.config.ConfigurationException: The tag named inputFile from namespace http://xmlns.jcp.org/jsf/html has a null handler-class defined
at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processHandlerClass(FaceletTaglibConfigProcessor.java:422)
at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTags(FaceletTaglibConfigProcessor.java:378)
at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTagLibrary(FaceletTaglibConfigProcessor.java:321)
at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:270)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:437)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216)
... 9 more
Project spec: JSF 2.2, WildFly 8.1, Primefaces 5
By the way Mojarra version is 2.2.6 so there is should not be issue like here
I have found the solution
In case if you already migrated to JSF 2.2 remove JSF 2.2 library from project library list because Wildfly 8.1 alredy comes with JSF implementation.
After build a lot of converters in my JSF app, I turned my attention to Omnifaces and everything's working like a charm. The problem arises when I deploy my application. The first time I access to my login page, it throws the next exception:
SEVERE: BeanManager enum singleton failed to initialize.
java.lang.IllegalStateException: javax.naming.NamingException: Lookup failed for 'java:comp/BeanManager' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException: Error retrieving java:comp/BeanManager [Root exception is java.lang.IllegalStateException: Cannot resolve bean manager]]
at org.omnifaces.util.JNDI.lookup(JNDI.java:87)
at org.omnifaces.config.BeanManager.init(BeanManager.java:76)
at org.omnifaces.config.BeanManager.getReference(BeanManager.java:115)
at org.omnifaces.application.OmniApplication.createValidator(OmniApplication.java:105)
at com.sun.faces.component.validator.ComponentValidators.addValidatorsToComponent(ComponentValidators.java:280)
at com.sun.faces.component.validator.ComponentValidators.addDefaultValidatorsToComponent(ComponentValidators.java:147)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.processValidators(ComponentTagHandlerDelegateImpl.java:550)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.privateOnComponentPopulated(ComponentTagHandlerDelegateImpl.java:531)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:195)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
at com.sun.faces.facelets.tag.jsf.core.MetadataHandler.apply(MetadataHandler.java:104)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:86)
at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
at com.sun.faces.application.view.ViewMetadataImpl.createMetadataView(ViewMetadataImpl.java:116)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:233)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:809)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:671)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:505)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:476)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:355)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:305)
at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:464)
at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:253)
at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1333)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.naming.NamingException: Lookup failed for 'java:comp/BeanManager' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException: Error retrieving java:comp/BeanManager [Root exception is java.lang.IllegalStateException: Cannot resolve bean manager]]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:518)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at org.omnifaces.util.JNDI.lookup(JNDI.java:83)
... 53 more
Caused by: javax.naming.NamingException: Error retrieving java:comp/BeanManager [Root exception is java.lang.IllegalStateException: Cannot resolve bean manager]
at org.glassfish.weld.BeanManagerNamingProxy.handle(BeanManagerNamingProxy.java:129)
at com.sun.enterprise.naming.impl.NamedNamingObjectManager.tryNamedProxies(NamedNamingObjectManager.java:89)
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:174)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:498)
... 57 more
Caused by: java.lang.IllegalStateException: Cannot resolve bean manager
at org.glassfish.weld.BeanManagerNamingProxy.handle(BeanManagerNamingProxy.java:119)
... 60 more
However, when I refresh my page, everything works fine.
Any ideas? Regards !!!
I'm using Glassfish 3.1.2.2 with JSF 2.1
This will be thrown when the webapp is not explicitly CDI-enabled while it's deployed to an implicitly CDI-enabled server (such as GlassFish 3 in your case). This is fixed since OmniFaces 1.8. An alternative is to explicitly enable CDI in your webapp by creating a /WEB-INF/beans.xml file.
I was getting this exception while trying to run my Payara 4.1 application. Actually I was interchangeably getting the following 2:
Exception 0 :
org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001413: The bean Managed Bean [class com.baw.website.beans.quality.ui.AuditBean] with qualifiers [#Default #Any #Named] declares a passivating scope but has a non-passivation-capable dependency Managed Bean [class com.baw.website.rest.clients.AuthUtil] with qualifiers [#Any #Default]
and
Caused by: javax.naming.NamingException: Lookup failed for 'java:comp/BeanManager' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException: Error retrieving java:comp/BeanManager [Root exception is java.lang.IllegalStateException: Cannot resolve bean manager]]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.omnifaces.util.JNDI.lookup(JNDI.java:90)
After analyzing, I found that I had 2 classes with the same name in different packages:
com.mycompany.mypackageone.Myclass
com.mycompany.mypackagetwo.Myclass
One of them was being CDI-injected into a ManagedBean which was related to a JSF page that used Omnifaces. I'm not sure where the conflict was occurring (I do have a beans.xml). But for me, stop/starting Payara, and renaming one of the 2 identically-named classes did the trick and got rid of the errors.
This question already has answers here:
java.lang.NoClassDefFoundError: javax/servlet/jsp/jstl/core/Config
(2 answers)
Closed 7 years ago.
I get an error, when I started my JavaServer Faces application. On the browser I get following error:
HTTP Status 500 -
--------------------------------------------------------------------------------
type Exception report
message
description The server encountered an internal error () that prevented it from fulfilling this request.
exception
javax.servlet.ServletException: javax/servlet/jsp/jstl/core/Config
javax.faces.webapp.FacesServlet.service(FacesServlet.java:229)
root cause
java.lang.NoClassDefFoundError: javax/servlet/jsp/jstl/core/Config
org.apache.myfaces.view.jsp.JspViewDeclarationLanguage.buildView(JspViewDeclarationLanguage.java:91)
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:77)
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
root cause
java.lang.ClassNotFoundException: javax.servlet.jsp.jstl.core.Config
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1676)
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1521)
org.apache.myfaces.view.jsp.JspViewDeclarationLanguage.buildView(JspViewDeclarationLanguage.java:91)
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:77)
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
note The full stack trace of the root cause is available in the Apache Tomcat/7.0.12 logs.
On my Eclipse IDE follwoing error:
Nov 19, 2013 8:37:17 PM org.apache.catalina.startup.Catalina start
Information: Server startup in 2518 ms
Nov 19, 2013 8:37:18 PM org.apache.catalina.core.StandardWrapperValve invoke
Schwerwiegend: Servlet.service() for servlet [Faces Servlet] in context with path [/de.xxx.jsf.first] threw exception [javax/servlet/jsp/jstl/core/Config] with root cause
java.lang.ClassNotFoundException: javax.servlet.jsp.jstl.core.Config
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1676)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1521)
at org.apache.myfaces.view.jsp.JspViewDeclarationLanguage.buildView(JspViewDeclarationLanguage.java:91)
at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:77)
at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:562)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:395)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:250)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:188)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:166)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:302)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
How is this caused and how can I solve it?
java.lang.ClassNotFoundException: javax.servlet.jsp.jstl.core.Config
A ClassNotFoundException means that the specified class is missing in the runtime classpath. As the package name hints, it's part of JSTL.
JSF (more specifically, Facelets) has indeed a dependency on JSTL for the <c:xxx> tags. When JSF loads, it's implicitly also loading JSTL core taglib configuration. However, if it cannot be found, you'll get exactly this exception.
JSTL (and JSF!) is normally already provided out the box on Java EE container such as JBoss AS/EAP/WildFly, GlassFish, TomEE, WebLogic, etcetera. However, you're using Tomcat, which is a barebones JSP/Servlet container and doesn't ship with JSTL out the box. If upgrading to e.g. TomEE is not an option, you'd need to manuall supply JSTL along with the webapp, like as you did for JSF.
Just download jstl-1.2.jar and drop it in /WEB-INF/lib folder of your webapp, along with the JSF JAR(s).
See also:
Our JSTL wiki page
It seems you are missing lib.
check if JSTL 1.1 - jstl.jar is added in your classpath.
Add jstl maven dependency in pom.xml:
<dependency>
<groupId>jstl</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>
When I develop my JSF application in localhost, with glassfish Server, it works, but when I deploy it in my server (Tomcat 7.0) it shows following exception, can anybody resolve this issue?
org.apache.jasper.JasperException: Unable to convert string "#{initParam.pageWidth}" to class "javax.el.ValueExpression" for attribute "value": Property Editor not registered with the PropertyEditorManager
org.apache.jasper.runtime.JspRuntimeLibrary.getValueFromPropertyEditorManager(JspRuntimeLibrary.java:846)
org.apache.jsp.details_jsp._jspx_meth_h_005foutputText_005f0(details_jsp.java:415)
org.apache.jsp.details_jsp._jspService(details_jsp.java:159)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:389)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:546)
com.sun.faces.application.view.JspViewHandlingStrategy.executePageToBuildView(JspViewHandlingStrategy.java:363)
com.sun.faces.application.view.JspViewHandlingStrategy.buildView(JspViewHandlingStrategy.java:153)
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
note The full stack trace of the root cause is available in the VMware vFabric tc Runtime 2.6.1.RELEASE/7.0.20.B.RELEASE logs.
U have to check for main 3 libraries::jsf-api.jar,jsf-impl.jar,jstl.jarto solve this issue.
I have an error-page directive which redirect all exception to an error display page
My web.xml:
<web-app [...]>
[...]
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/view/error.xhtml</location>
</error-page>
</web-app>
It works for almost any exception but today I noticed that sometimes and JSF error is logged and the exception is not handled (i.e., there is no redirection to the error page).
Here what I have in the log:
javax.enterprise.resource.webcontainer.jsf.context || JSF1073: javax.faces.event.AbortProcessingException caught during processing of INVOKE_APPLICATION 5 : UIComponent-ClientId=searchForm:j_idt147, Message=/view/listView.xhtml #217,7 actionListener="#{listController.nextPageClicked}": java.lang.NullPointerException
javax.enterprise.resource.webcontainer.jsf.context || /view/listView.xhtml #217,7 actionListener="#{listController.nextPageClicked}": java.lang.NullPointerException
javax.faces.event.AbortProcessingException: /view/listView.xhtml #217,7 actionListener="#{listController.nextPageClicked}": java.lang.NullPointerException
at javax.faces.event.MethodExpressionActionListener.processAction(MethodExpressionActionListener.java:182)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.NullPointerException
at ch.ethz.id.wai.web.controller.ListController.nextPageClicked(ListController.java:410)
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)
How can I also handle these exceptions?
Edit: by handle I don't mean that I want to correct the problem causing the exception (which is another topic) but my question is how can I catch the exception in JSF with the <error-page> directive. An error page is visible, an entry in the log can be easily missed.
This is by design. When an actionListener method throws an exception, it will only be logged and not thrown. It's "just" a listener intented for trivial preprocessing/logging tasks and such, not a real action. Only when an action method throws an exception, it will be delegated all the way to the container and end up in the default error page.
If you want to perform exception-sensitive business actions, do it in the action method instead.
See also:
Differences between action and actionListener