#RequestScoped #Named("base") Bean not initializing in JBoss EAP 7.0 - cdi

I am using JSF api 2.2 specification Mojarra implementation with JBoss EAP 7.0 server
#javax.inject.Named.Named("base")
#javax.enterprise.context.RequestScoped
but these annotations are not initializing my bean though
#RequestScoped
#ManagedBean(name="base")
working perfectly even these are Deprecated in JSF 2.2
~Target Unreachable, identifier 'base' resolved to null, javax.el.PropertyNotFoundException: /index.xhtml #10,78 listener="#{base.getData}"
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:107)
at com.sun.faces.facelets.tag.jsf.core.DeclarativeSystemEventListener.processEvent(EventHandler.java:128)
at javax.faces.component.UIComponent$ComponentSystemEventListenerAdapter.processEvent(UIComponent.java:2584)
at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108)
at javax.faces.event.ComponentSystemEvent.processListener(ComponentSystemEvent.java:118)
at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2169)
at com.sun.faces.application.ApplicationImpl.invokeComponentListenersFor(ApplicationImpl.java:2114)
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:287)
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:245)
at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:299)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:107)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659)
~

Related

Deploying MyFaces 2.2.8 on WildFly 8.2.0

Environment :
JAVA EE 7
CDI
WildFly 8.2.0
MyFaces 2.2.8
Issue :
I am trying to run WildFly 8.2.0 with myFaces 2.2.8 as default JSF implementation.
Installion is completed . The details for this are on another SO question :
Installing Apache MyFaces 2 on WildFly 8.2.0
When my application war is deployed on WildFly 8.2.0 , the following exception is thrown and deployment doesn't complete.
Caused by: java.lang.ClassNotFoundException: org.apache.tomcat.InstanceManager from [Module "com.sun.jsf-impl:myfaces-2.2.8" from local module loader #736e9adb
(finder: local module finder #6d21714c (roots: C:\Users\xyz\wildfly-8.2.0.Final\modules,C:\Users\xyz\wildfly-8.2.0.Final\modules\system\layers\base))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final]
at org.apache.myfaces.spi.impl.Tomcat7AnnotationInjectionProvider.initManager(Tomcat7AnnotationInjectionProvider.java:182)
at org.apache.myfaces.spi.impl.Tomcat7AnnotationInjectionProvider.postConstruct(Tomcat7AnnotationInjectionProvider.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_60]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_60]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
at javax.faces.FactoryFinder.injectAndPostConstruct(FactoryFinder.java:415)
at javax.faces.FactoryFinder.newFactoryInstance(FactoryFinder.java:519)
at javax.faces.FactoryFinder._getFactory(FactoryFinder.java:361)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:225)
at com.sun.faces.config.processor.FactoryConfigProcessor.verifyFactoriesExist(FactoryConfigProcessor.java:186)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:131)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:203)
... 10 more
I have searched for the issue on web and found out same problem here http://www.hivmr.com/db/3jsapc8j3xz3js1dsasjxjpkx37379cm , but no solution has been found.
The issue can be described as :
1) MyFaces uses Tomcat7AnnotationInjectionProvider for annotation processing which requires org.apache.tomcat.InstanceManager which is not available.
2) One solution is to use CDIAnnotationDelegateInjectionProvider , but how to configure it in MyFaces is not known ?
3) How to hook MyFaces in WildFly so that JBOSS Weld can process annotations instead of MyFaces supplied class ?
Wildfly uses Mojarra as their implementation choice of JSF. To use MyFaces you can follow their installation steps explained here [1]
[1] https://developer.jboss.org/wiki/StepsToAddMyFacesSupportToWildFly

java.lang.IllegalStateException: javax.naming.NamingException: Lookup failed for 'java:comp/BeanManager'

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.

FlowDefinition Scope issue in JBoss 7.1 - Migration to JSF 2.2.1

I did the instruction from this website (JSF 2.2 in JBoss 7.1.1 Final). After I overcome the problem posted :
ClassNotFoundException for JSTL jar when I try to migrate JBoss 7.1 application to JSF 2.2
I get new issue.
No active contexts for scope type javax.faces.flow.builder.FlowDefinition
Stack Trace :
14:57:33,400 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-8) Critical error during deployment: : org.jboss.weld.context.ContextNotActiveExceptio
n: WELD-001303 No active contexts for scope type javax.faces.flow.builder.FlowDefinition
at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:607) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at com.sun.faces.application.ApplicationAssociate$PostConstructApplicationListener.loadFlows(ApplicationAssociate.java:322) [jsf-impl-2.2.1.jar:2.2.1]
at com.sun.faces.application.ApplicationAssociate$PostConstructApplicationListener.processEvent(ApplicationAssociate.java:302) [jsf-impl-2.2.1.jar:2.2.1]
at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108) [jsf-api-2.2.1.jar:2.2]
at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2187) [jsf-impl-2.2.1.jar:2.2.1]
at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163) [jsf-impl-2.2.1.jar:2.2.1]
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:296) [jsf-impl-2.2.1.jar:2.2.1]
at org.jboss.as.weld.webtier.jsf.ForwardingApplication.publishEvent(ForwardingApplication.java:288) [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final]
at javax.faces.application.ApplicationWrapper.publishEvent(ApplicationWrapper.java:739) [jsf-api-2.2.1.jar:2.2]
at com.sun.faces.config.ConfigManager.publishPostConfigEvent(ConfigManager.java:691) [jsf-impl-2.2.1.jar:2.2.1]
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:253) [jsf-impl-2.2.1.jar:2.2.1]
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3392) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3850) [jbossweb-7.0.13.Final.jar:]
at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [rt.jar:1.6.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.6.0_25]
at java.lang.Thread.run(Unknown Source) [rt.jar:1.6.0_25]
14:57:33,416 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/jsf-cdi]] (MSC service thread 1-8) Exception sending context initialized event to listener i
nstance of class com.sun.faces.config.ConfigureListener: java.lang.RuntimeException: org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type
javax.faces.flow.builder.FlowDefinition
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:273) [jsf-impl-2.2.1.jar:2.2.1]
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3392) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3850) [jbossweb-7.0.13.Final.jar:]
at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [rt.jar:1.6.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.6.0_25]
at java.lang.Thread.run(Unknown Source) [rt.jar:1.6.0_25]
Caused by: org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.faces.flow.builder.FlowDefinition
at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:607) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at com.sun.faces.application.ApplicationAssociate$PostConstructApplicationListener.loadFlows(ApplicationAssociate.java:322) [jsf-impl-2.2.1.jar:2.2.1]
at com.sun.faces.application.ApplicationAssociate$PostConstructApplicationListener.processEvent(ApplicationAssociate.java:302) [jsf-impl-2.2.1.jar:2.2.1]
at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108) [jsf-api-2.2.1.jar:2.2]
at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2187) [jsf-impl-2.2.1.jar:2.2.1]
at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163) [jsf-impl-2.2.1.jar:2.2.1]
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:296) [jsf-impl-2.2.1.jar:2.2.1]
at org.jboss.as.weld.webtier.jsf.ForwardingApplication.publishEvent(ForwardingApplication.java:288) [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final]
at javax.faces.application.ApplicationWrapper.publishEvent(ApplicationWrapper.java:739) [jsf-api-2.2.1.jar:2.2]
at com.sun.faces.config.ConfigManager.publishPostConfigEvent(ConfigManager.java:691) [jsf-impl-2.2.1.jar:2.2.1]
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:253) [jsf-impl-2.2.1.jar:2.2.1]
I tried to change weld-core module in JBoss 7 with the following jar fils.
weld-core-1.1.8.Final.jar
weld-core-2.1.1.Final.jar
It does not effect, error is the same. How can I resolve it?
One of the things that JBoss EAP 7 (and I assume Wildfly 10) also needs is a beans.xml file in the war project WEB-INF directory.
We have a number of EAR projects, with an EJB project containing the java code. It used to be that the beans.xml in this EJB project was sufficient to have JSF use CDI scopes, but with EAP 7 / JSF 2.2 this isn't enough anymore and the war project itself also needs this marker file.
I assume this is more standard compliant, but can lead to interesting bug chases if you don't realize this.

Deploying a JSF webapp results in java.lang.ClassNotFoundException: javax.servlet.jsp.jstl.core.Config [duplicate]

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>

Error when deploying JSF application on Tomcat Server

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.

Resources