Faces Servlet failed to preload on startup in Web application
Sag shi
Greenhorn
Posts: 6
posted 2 years ago
I am facing few issues when deploying the JSF app in 12c.
If any kind of suggestions appreciated.
http://stackoverflow.com/questions/29857571/weblogic-12c-java-lang-illegalstateexception-could-not-find-backup-for-factory
I have raised this issue on stack overflow too if you want to see in detail about this error. Thanks in advance.
If any kind of suggestions appreciated.
http://stackoverflow.com/questions/29857571/weblogic-12c-java-lang-illegalstateexception-could-not-find-backup-for-factory
I have raised this issue on stack overflow too if you want to see in detail about this error. Thanks in advance.
posted 2 years ago
This is the Spring-JSF bridge that allows you to reference Spring beans in EL just like they were JSF Managed Beans. Actually, there's another version: org.springframework.web.jsf.el.SpringBeanFacesELResolver, but one of them is supposed to be obsolete now.
This class is not part of JSF. It's a Spring component. So you have to include the appropriate spring jar into your JSF webapp's WEB-INF/lib directory.
This class is not part of JSF. It's a Spring component. So you have to include the appropriate spring jar into your JSF webapp's WEB-INF/lib directory.
An IDE is no substitute for an Intelligent Developer.
Sag shi
Greenhorn
Posts: 6
posted 2 years ago
Thanks Tim for reply. I may be wrong but could you please elaborate in detail. I am struck with this issue for a while. Most of the issues related with this on google keep saying there might be issue with multiple JSF versions polluting the class path from weblogic shared library.
For that I have the weblogic classloader if you would like to have a quick look.
1. For reading the bean we already added the variable resolver in config file so I am not sure if this is bridge issue.
<!-- read Spring beans from JSF backing beans -->
<el-resolver>org.springframework.web.jsf.el.SpringBeanFacesELResolver</el-resolver>
<variable-resolver>org.springframework.web.jsf.DelegatingVariableResolver</variable-resolver>
2. What do you think about this error - <Unexpected exception when attempting to tear down the Mojarra runtime java.lang.IllegalStateException: Could not find backup for factory javax.faces.application.ApplicationFactory. and
java.lang.IllegalStateException: Could not find backup for factory javax.faces.context.FacesContextFactory.
Error starts with below line.
Here is the detailed Web Logic Class loader for my application in case you can make something out of this. Any kind of help is appreciated. Let me know incase you require pom.xml I will post that too.
For that I have the weblogic classloader if you would like to have a quick look.
1. For reading the bean we already added the variable resolver in config file so I am not sure if this is bridge issue.
<!-- read Spring beans from JSF backing beans -->
<el-resolver>org.springframework.web.jsf.el.SpringBeanFacesELResolver</el-resolver>
<variable-resolver>org.springframework.web.jsf.DelegatingVariableResolver</variable-resolver>
2. What do you think about this error - <Unexpected exception when attempting to tear down the Mojarra runtime java.lang.IllegalStateException: Could not find backup for factory javax.faces.application.ApplicationFactory. and
java.lang.IllegalStateException: Could not find backup for factory javax.faces.context.FacesContextFactory.
Error starts with below line.
Here is the detailed Web Logic Class loader for my application in case you can make something out of this. Any kind of help is appreciated. Let me know incase you require pom.xml I will post that too.
posted 2 years ago
Spring is not built into WebLogic, so that's something that you will have to provide as part of your deployable WAR.
As far as JSF pollution goes, that's a very real problem. One of the primary differences between the old J2EE standard and the newer JEE standard is that in JEE, JSF is a built-in capability. Thus, there is a copy of JSF built right into the WLS server.
If you include JSF libraries in your webapp, there will be at best version conflicts and at worse severe classpath data issues, leaving the application (and possibly the server) corrupted. Results are totally unpredictable.
The job isn't made any easier by the fact that a lot of what's published on the Web is either older (J2EE-based) or Tomcat (limited JEE) examples. Tomcat does not include the full stack, neither JSF nor EJB nor a lot of other JEE-standard things, so that makes it necessary for Tomcat WARs to include libraries that full-compliance WARs such as those used by WLS do not.
The best place to resolve issues with JSF JARs and components is in the WebLogic documentation. It will tell you how to properly define a webapp for the version of JEE that it supports as well as overrides if you should find it necessary to ignore the built-in JSF and use an alternative implementation.
As far as JSF pollution goes, that's a very real problem. One of the primary differences between the old J2EE standard and the newer JEE standard is that in JEE, JSF is a built-in capability. Thus, there is a copy of JSF built right into the WLS server.
If you include JSF libraries in your webapp, there will be at best version conflicts and at worse severe classpath data issues, leaving the application (and possibly the server) corrupted. Results are totally unpredictable.
The job isn't made any easier by the fact that a lot of what's published on the Web is either older (J2EE-based) or Tomcat (limited JEE) examples. Tomcat does not include the full stack, neither JSF nor EJB nor a lot of other JEE-standard things, so that makes it necessary for Tomcat WARs to include libraries that full-compliance WARs such as those used by WLS do not.
The best place to resolve issues with JSF JARs and components is in the WebLogic documentation. It will tell you how to properly define a webapp for the version of JEE that it supports as well as overrides if you should find it necessary to ignore the built-in JSF and use an alternative implementation.
An IDE is no substitute for an Intelligent Developer.
Sag shi
Greenhorn
Posts: 6
posted 2 years ago
Yes you are right the JSF polluting making things complicated. If you see the weblogic classloader analyzer in above post it has all the information about which Jar loading from weblogic shared library or my application and what all jars I did override to make that work.
The same application is working in Weblogic 10.3.6 but not in newer 12c Versions(with spring 4 and hibernate 4 upgrades).
I did analyze the class loader if there is really any conflict but didn't find any. Not sure what exactly issue is.
The same application is working in Weblogic 10.3.6 but not in newer 12c Versions(with spring 4 and hibernate 4 upgrades).
I did analyze the class loader if there is really any conflict but didn't find any. Not sure what exactly issue is.
posted 2 years ago
One problem with polluted classloader contexts is that it's possible to have 2 instances of 1 class. One in the local context (the webapp) and one in the global context (the server itself). Well, actually, more than 2 is possible, but 2 is bad enough.
In such a situation, if a class is maintaining state - especially in static properties, you might end up in a situation where you set a property in one class context, but later retrieved it from another. So what went in may not be what comes back.
I'm not sure just how far you can depend on analysis tools to detect such issues. You can do a static classpath scan, but if a class was loaded dynamically, you can't see that. So the safest approach is to make sure you're set up according to instructions.
And that means that if they don't tell you to put the javax.faces-2.2.9 jar in your WAR/EAR, then either don't do it, or read and carefully follow their instructions on how to override the server-supplied JSF subsystem.
In such a situation, if a class is maintaining state - especially in static properties, you might end up in a situation where you set a property in one class context, but later retrieved it from another. So what went in may not be what comes back.
I'm not sure just how far you can depend on analysis tools to detect such issues. You can do a static classpath scan, but if a class was loaded dynamically, you can't see that. So the safest approach is to make sure you're set up according to instructions.
And that means that if they don't tell you to put the javax.faces-2.2.9 jar in your WAR/EAR, then either don't do it, or read and carefully follow their instructions on how to override the server-supplied JSF subsystem.
An IDE is no substitute for an Intelligent Developer.
| Consider Paul's rocket mass heater. |