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.
Related
I was working with gvNIX after installing jQuery and everything worked fine. But, when I installed the datatables web mvc datatables setup and the app was compiled, the web crashed and the server shown this error:
2015-05-25 12:47:34,583 [localhost-startStop-1] ERROR org.springframework.web.context.ContextLoader - Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in file [/home/vicente/Documentos/sts-bundle/pivotal-tc-server-developer-3.1.0.RELEASE/base-instance/wtpwebapps/FitTrainning_WebService/WEB-INF/classes/META-INF/spring/applicationContext.xml]: Invocation of init method failed; nested exception is java.lang.NoSuchMethodError: javax.persistence.Table.indexes()[Ljavax/persistence/Index;
Caused by: java.lang.NoSuchMethodError: javax.persistence.Table.indexes()[Ljavax/persistence/Index;
Are you deploying on a JBoss? There is a problem due JPA API version (JBoss includes 2.0 but gvNIX requires 2.1).
Take a look this issue on JBoss Jira for a workaround.
Good luck!
I created my hello world JSF project, but when I deploy to Tomcat 7, I get this exception:
java.lang.IllegalStateException: Could not find backup for factory javax.faces.context.FacesContextFactory.
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:1135)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:379)
at javax.faces.webapp.FacesServlet.init(FacesServlet.java:350)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1284)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:864)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:134)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
I have added those JARs to my project:
jstl-1.2.jar
javax.faces-api-2.2.jar
How is this caused and how can I solve it?
IllegalStateException: Could not find backup for factory javax.faces.context.FacesContextFactory
This exception is easier to understand if you replace "backup" by "implementation". It ultimately boils down to "I found the JSF API, but nowhere a JSF impl in the same classpath context as where I found the JSF API". In other words, you've a JSF API somewhere in runtime classpath which isn't accompanied with any JSF impl. E.g. having a jsf-api.jar or even javaee.jar without any jsf-impl.jar or javax.faces.jar in the same classpath context. Note that a web application can have multiple classpath contexts. The JSF impl has to be present in exactly the same location as the first encountered JSF API according to the classloading rules, and you need to make absolutely sure that there are no duplicate and/or conflicting versions.
In your specific case,
I had added this jars to my project : jstl-1.2.jar and javax.faces-api-2.2.jar
The javax.faces-api-2.2.jar alone is not right. There are 2 problems:
That's the "blueprint" API JAR, intented for JSF implementors such as Mojarra and MyFaces.
You forgot the JSF implementation JAR.
Provided that you'd like to use Mojarra, follow the installation instructions in its README. In your specific case, get rid of that javax.faces-api-2.2.jar and put the latest javax.faces-2.x.x.jar in /WEB-INF/lib or pom.xml and this exception should disappear.
See also:
How to properly install and configure JSF libraries via Maven?
Need to changed the weblogic-application.xml of the ear project to
<?xml version='1.0' encoding='UTF-8'?>
<weblogic-application xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-application" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-application
http://www.bea.com/ns/weblogic/weblogic-application/1.0/weblogic-application.xsd">
<prefer-application-packages>
<package-name>org.opensaml.*</package-name>
<package-name>org.slf4j.*</package-name>
<package-name>antlr.*</package-name>
</prefer-application-packages>
<prefer-application-resources>
<resource-name>javax.faces.*</resource-name>
<resource-name>com.sun.faces.*</resource-name>
<resource-name>com.bea.faces.*</resource-name>
<resource-name>META-INF/services/javax.servlet.ServletContainerInitializer</resource-name>
<resource-name>META-INF/services/com.sun.faces.spi.FacesConfigResourceProvider</resource-name>
</prefer-application-resources>
</weblogic-application>
Follwoing jar version numbers must match exactly:
javax.faces-2.x.x.jar
jsf-api-2.x.x.jar
jsf-impl-2.x.x.jar
Thanks to My colleuge , #Lookub at stackoverflow ,he added another apache server and the set the port as 8084 , it all compiled. As ide, we are using netbeans 8.2.You may do this at Services>>Servers menu . Hope this helps.
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'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.
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!