Mar 03, 2013 12:09:05 PM org.apache.catalina.core.ApplicationContext log
INFO: Marking servlet Faces Servlet as unavailable
Mar 03, 2013 12:09:05 PM org.apache.catalina.core.StandardContext loadOnStartup
SEVERE: Servlet /mavenproject1 threw load() exception
java.lang.ClassNotFoundException: javax.faces.webapp.FacesServlet
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1713)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1558)
at org.apache.catalina.core.DefaultInstanceManager.loadClass(DefaultInstanceManager.java:527)
at org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:509)
at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:137)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1088)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5033)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5317)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:657)
at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1637)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
When I'm trying to deploy an application with Faces Servlet, I get this stacktrace.
This would mean there's no FacesServlet available, but this is clearly not the case since these libraries are available in the WAR.
jsf-api-2.2.0-m09.jar
jsf-impl-2.2.0-m09.jar
javaee-web-api-6.0.jar
I don't have a clue in what might be wrong. As stated in the title, I am running on Tomcat 7.0.37.
The problem is most likely with javaee-web-api-6.0.jar. This jar contains javax.servlet.* classes. And when Tomcat found them in this jar it blocks the jar for classloading. This means that no classes from this jar can be loaded at all! Including javax.faces.webapp.FacesServlet which is in it. See servlet spec (3.0), section 10.7.2:
The class loader that a container uses to load a servlet in a WAR must allow the developer to load any resources contained in library JARs within the WAR following normal Java SE semantics using getResource. As described in the Java EE license agreement, servlet containers that are not part of a Java EE product should not allow the application to override Java SE platform classes, such as those in the java.* and javax.* namespaces, that Java SE does not allow to be modified. The container should not allow applications to override or access the container’s implementation classes. It is recommended also that the application class loader be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs. An implementation MUST also guarantee that for every web application deployed in a container, a call to Thread.currentThread.getContextClassLoader() MUST return a ClassLoader instance that implements the contract specified in this section. Furthermore, the ClassLoader instance MUST be a separate instance for each deployed web application. The container is required to set the thread context ClassLoader as described above before making any callbacks (including listener callbacks) into the web application, and set it back to the original ClassLoader, once the callback returns.
Clean up your dependencies!
Related
I'm trying to get a clear understanding of where #DeclareRoles annotation can be used. The API simply says:
Used by application to declare roles. It can be specified on a class.
I've used #DeclareRoles successfully with GlassFish and Payara and for them I can put #DeclareRoles anywhere; it seems those EE servers will scan and find all usages. I tried transferring some code to WebLogic 12.2.1 and started getting some role errors at deployment. I tracked the problem down to WebLogic wanting the #DeclareRoles annotation only on a Servlet class.
So should #DeclareRoles be able to put on any class and the GlassFish/Payara behavior is correct? Or should #DeclareRoles be limited only to a Servlet class and the WebLogic behavior is correct. Given WebLogic's history, I tend to think it's not doing the right thing.
After looking into this more, I found JSR-340, Servlet 3.1 specification, section 15.5.1 AND JSR-369, Servlet 4.0 specification, section 15.2.2 both state:
The #DeclareRoles annotation may only be defined in classes
implementing the javax.servlet.Servlet interface or a subclass
thereof.
So, it looks like WebLogic got this right and GlassFish/Payara behavior is outside of the spec.
According to the Java EE 7.0 & 8.0 Specifications, javax.annotation.security.DeclareRoles need only be supported by web containers and EJB containers.
In other words, the class that is annotated must be an EJB or a servlet.
In a JSF/facelet page, I'm trying to call a method with an enum value as a parameter, like this:
<f:viewAction action="#{myController.myMethod('MY_ENUM_VALUE')}" />
The code is working correctly using Tomcat but when trying with Websphere, this is not working anymore and I get the following exception.
Caused by: javax.el.MethodNotFoundException: /myPage.xhtml #16,24 action="#{myController.myMethod('MY_ENUM_VALUE')}": Method not found: com.example.MyController#807f4c26.myMethod(java.lang.String)
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:109)
I'm wondering if there is a simple solution (configuration in Websphere?) or if I should integrate a different EL implementation in my WAR to override the one of Websphere. Any other suggestion is also welcome.
Additional information:
Websphere 8.5, using Mojarra 2.2.5 implementation (override implementation of Websphere, using PARENT_LAST mode)
Using Spring (with the SpringBeanFacesELResolver configured in faces-config.xml)
I'm not packaging any special EL implementation in the EAR/WAR.
Tomcat does not provide a JSF implementation so you are free to provide any version compatible with the servler/JSP version provided by your Tomcat server.
However, WebSphere AS 8.5 is a full Java EE 6 application server that integrates JSF into the container.
Bundling libraries into a WAR that are contained in the server does not automatically override the server libraries. Java defaults to a parent-first class loading model. Some of the configuration information available in arbitrary enterprise libraries may not make sense to the container and result in undefined behavior. Additionally, deployment descriptors can specify the loading of WAR-specific libraries that are not necessarily compatible with the container.
Some containers (WebSphere among them) support parent-last class loading. This can result in so much weird behavior it should generally be avoided.
As far as I am aware there is only one documented way to support a com.sun.faces... JSF implementation and I suspect in is only temporarily there to support WAS 7 binary JSF app WAR files.
So, it is possible that you are not really overriding the platform implementation but are triggering some undefined behavior by bundling JSF libraries in the WAR file.
It is possible I've missed something about what you are doing; if so, provide more details.
I have upgraded application to use javax.faces-2.2.4 and primefaces-4.0 jars.After deploying my application to weblogic from myeclipse I am getting below error:
Jan 10, 2014 2:37:13 PM javax.faces.FactoryFinder$FactoryManager getFactory
SEVERE: Application was not properly initialized at startup, could not find Factory: javax.faces.application.ApplicationFactory. Attempting to find backup.
Jan 10, 2014 2:37:13 PM com.sun.faces.config.ConfigureListener contextDestroyed
SEVERE: Unexpected exception when attempting to tear down the Mojarra runtime
java.lang.IllegalStateException: Could not find backup for factory javax.faces.application.ApplicationFactory.
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:1135)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:379)
at com.sun.faces.config.InitFacesContext.getApplication(InitFacesContext.java:140)
at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:310)
at weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:482)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at weblogic.servlet.internal.EventsManager.notifyContextDestroyedEvent(EventsManager.java:200)
at weblogic.servlet.internal.WebAppServletContext.destroy(WebAppServletContext.java:3225)
at weblogic.servlet.internal.ServletContextManager.destroyContext(ServletContextManager.java:247)
at weblogic.servlet.internal.HttpServer.unloadWebApp(HttpServer.java:461)
at weblogic.servlet.internal.WebAppModule.destroyContexts(WebAppModule.java:1545)
at weblogic.servlet.internal.WebAppModule.deactivate(WebAppModule.java:509)
at weblogic.application.internal.flow.ModuleStateDriver$2.previous(ModuleStateDriver.java:387)
at weblogic.application.utils.StateMachineDriver.previousState(StateMachineDriver.java:223)
at weblogic.application.utils.StateMachineDriver.previousState(StateMachineDriver.java:215)
at weblogic.application.internal.flow.ModuleStateDriver.deactivate(ModuleStateDriver.java:141)
at weblogic.application.internal.flow.ScopedModuleDriver.deactivate(ScopedModuleDriver.java:206)
at weblogic.application.internal.flow.ModuleListenerInvoker.deactivate(ModuleListenerInvoker.java:261)
at weblogic.application.internal.flow.DeploymentCallbackFlow$2.previous(DeploymentCallbackFlow.java:547)
at weblogic.application.utils.StateMachineDriver.previousState(StateMachineDriver.java:223)
at weblogic.application.utils.StateMachineDriver.previousState(StateMachineDriver.java:215)
at weblogic.application.internal.flow.DeploymentCallbackFlow.deactivate(DeploymentCallbackFlow.java:192)
at weblogic.application.internal.flow.DeploymentCallbackFlow.deactivate(DeploymentCallbackFlow.java:184)
at weblogic.application.internal.BaseDeployment$2.previous(BaseDeployment.java:677)
at weblogic.application.utils.StateMachineDriver.previousState(StateMachineDriver.java:223)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:63)
at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:212)
at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:59)
at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:161)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:79)
at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:184)
at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:361)
at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:51)
at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:200)
at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:30)
at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:240)
at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:169)
at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:123)
at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:180)
at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:96)
at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
Even ApplicationContextAware.setApplicationContext(org.springframework.context.ApplicationContext ) method has not been called
java.lang.IllegalStateException: Could not find backup for factory javax.faces.application.ApplicationFactory.
One of more common causes of this exception is that the webapp's runtime classpath is polluted with multiple different JSF API versions which are colliding/confusing each other.
This is likely also the case in your case. Weblogic itself already ships with JSF bundled, however you're supplying another one along with your webapp. So effectively you end up with two different versioned JSF APIs in the webapp's runtime classpath.
I don't do Weblogic, but basically you have 2 options:
Tell Weblogic to not load its bundled JSF, so that effectively only the webapp-bundled JSF is loaded.
If you intend to upgrade Weblogic's bundled JSF version, then don't upgrade it via your webapp, but directly in Weblogic itself. Or perhaps, upgrade the whole server to a newer version if the desired JSF API version is incompatible with the Servlet version of the server (JSF 2.2 requires Servlet 3.0).
Consult its admin documentation for clues.
You only needs to clean build and deploy this new build on weblogic
I am getting an error while running a JSF project. Here is the error log;
org.apache.catalina.core.StandardContext filterStart
SEVERE: Exception starting filter PrimeFaces FileUpload Filter
java.lang.ClassNotFoundException: org.primefaces.webapp.filter.FileUploadFilter
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1714)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
at org.apache.catalina.core.DefaultInstanceManager.loadClass(DefaultInstanceManager.java:527)
at org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:509)
at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:137)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:260)
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:107)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4775)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5452)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
org.apache.catalina.core.StandardContext startInternal
SEVERE: Error filterStart
org.apache.catalina.core.StandardContext startInternal
SEVERE: Context [/Project] startup failed due to previous errors
I've already created a user library added commons-fileupload-1.3.jar and commons-io-2.4.jar files but I'm still gettin the error. Any ideas?
I gather that you mean the Eclipse-specific user library management when you said "user library" there. I also gather that you've PrimeFaces already installed, otherwise this is food for Mr. Obvious. Its FileUploadFilter will indeed fail to initialize like that if Commons FileUpload and/or Commons IO are absent. You should see a NoClassDefFoundError further in the stack trace.
Just creating a new "user library" and adding to Build Path of project's properties is not exactly the right way. They also need to end up in /WEB-INF/lib of the built WAR. Usually, you'd need to add the user library in Deployment Assembly section of project's properties as well. However, this whole process is unnecessarily clumsy. Just drop those two JAR files in /WEB-INF/lib folder of dynamic web project. Eclipse will then automatically do all the necessary magic. You don't need to fiddle in project's properties. To avoid conflicts, undo all those changes which you ever made in Build Path.
I'd like to use <p:calendar> in my JSF app developed in Netbeans, so I added the PrimeFaces library. However, when I deploy the app, it errors as follows:
Context with name [/ManagedBeansWithComponents] has not yet been started
C:\Users\Dell-pc\Documents\NetBeansProjects\ManagedBeansWithComponents\nbproject\build- impl.xml:1040: The module has not been deployed.
See the server log for details.
BUILD FAILED (total time: 1 second)
And the server log says:
Source Document: jar:file:/C:/Users/Dell-pc/Documents/NetBeansProjects/ManagedBeansWithComponents/build/web/WEB-INF/lib/primefaces-3.5.jar!/META-INF/faces-config.xml
Cause: Class 'org.primefaces.component.fileupload.FileUploadRenderer' is missing a runtime dependency: java.lang.NoClassDefFoundError: org/apache/commons/fileupload/FileItem
How is this caused and how can I solve it?
java.lang.NoClassDefFoundError: org/apache/commons/fileupload/FileItem
There is the cause. It's crystal clear. The mentioned class is missing in the runtime classpath. The solution is rather straightforward: put the mentioned class (or, the JAR file containing it) in the runtime classpath. As the package name hints, it's available on http://commons.apache.org/fileupload (which in turn has by the way http://commons.apache.org/io as dependency). Just download and drop those JARs in the same place as PrimeFaces JAR and all should be well.
Unrelated to the concrete problem, note that this particular problem is in turn unintented by PrimeFaces. This problem should actually only occur when you register the FileUploadFilter for the <p:fileUpload> component in web.xml. However, since GlassFish 4.0, it is overzealously preloading every single JSF component and renderer class found in the classpath even if it's never used by the application. The class loading in turn causes all its runtime dependencies to be checked. If it's missing, then you get the NoClassDefFoundError. This problem is thus specific to GlassFish 4.0 and does not occur when using GlassFish 3.x or any other servletcontainer such as Tomcat or JBoss.