I'm using JSF2.0 (Mojarra 2.0.6) under WAS7 application server. My web module facet is set to support (servlet API) version - 2.5. Also Im using RSA8.0.4.
I can see below exception during server start-up. Can any one suggest?
com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0100E: Uncaught init() exception created by servlet Faces Servlet in application FATCAKycApplication:
java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:851)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:309)
at javax.faces.webapp.FacesServlet.init(FacesServlet.java:219)
I think this question is very similar to what you are experiencing, you could try the approach described in BalusC's answer
Related
We are migrating our application from JSF (MyFaces, Trinidad) 1.2 to JSF (MyFaces, Trinidad) 2.0. I have done the all basic changes like updating the XMLNS for Faces-Config, updating the Web.xml to support 3.0, removed Facelets, el-api, el-ri Jars.
When I set the classloaderMode to PARENT_LAST in Websphere 8.5.5 for picking our MyFaces & Trinidad jar, I'm getting the below error.
A java: URL name was used, but Naming was not configured to handle java: URL names. The likely cause is a user in error attempting to specify a java: URL name in a non-J2EE client or server environment. Throwing ConfigurationException
But I'm NOT getting the same exception when I set the classloaderMode to PARENT_FIRST. How can I resolve this problem? Please help me.
The error sounds like you have include WAS JNDI classes in your WAR, which when combined with PARENT_LAST causes the JDK JNDI to use those uninitialized classes rather than the ones included with WAS. You should not repackage WAS JARs in your application.
I am working with an app that uses spring-security 3.0 and oauth2 using spring-security-oauth-1.0.0.M3. It works fine. But it looks like migrating to spring-security 3.1 will not be trivial. I have been unable to find confirmation that the oauth module is still supported.
For example, the oauth tutorial mentions 3.0 not 3.1:
https://github.com/SpringSource/spring-security-oauth/wiki/tutorial
And I have encountered a problem similar to the Mar 4, 2012 comment in the following discussion when I attempt to do a straight upgrade to 3.1 using spring-security-oauth 1.0.0.M3 or M4:
http://code.google.com/p/spring-security-social/wiki/Usage
Specifically I see this in the Tomcat logs:
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration
problem: Failed to import bean definitions from URL location ...
Offending resource: class path resource [spring/applicationContext.xml]; nested
exception is org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected
exception parsing XML document from URL ...; nested exception is
org.springframework.beans.FatalBeanException: Invalid NamespaceHandler class
[org.springframework.security.oauth2.config.OAuth2SecurityNamespaceHandler] for namespace
[http://www.springframework.org/schema/security/oauth2]: problem with handler class file or
dependent class; nested exception is java.lang.NoClassDefFoundError:
org/springframework/security/web/util/AntUrlPathMatcher
Can someone suggest a solution to the above problem, or point to a reference for using spring-security 3.1 and spring-security-oauth, or else suggest a better alternative to implement oauth2 using spring-security 3.1?
Or if I'm missing a fundamental point of spring-security 3.1, that would also be useful to know.
Thanks!
Yes, Spring Security OAuth milestone build 1.0.0.M6, and specifically the oauth2 module, supports Spring Security 3.1.0. It is not yet considered a release. The OAuth 2.0 spec itself is not final.
The 1.0.0.M6 samples appear to be the most accurate and complete reference for implementation. The full 1.0.0.M6 tag zipball is here.
The OAuth 2 Developers Guide is a good textual reference. It's not 100% accurate, at least with respect to 1.0.0.M6. For example, the attribute user-approval-page belongs to authorization-server not authorization-code.
The Maven pom.xml must refer to artifactId spring-security-oauth2 (not spring-security-oauth as in older versions such as 1.0.0.M3).
I am having some trouble with JSF2 and websphere 7.0. I have searched in the internet but nothing. The thing looks to be that websphere puts its 1.2 libraries and override my 2.0 libs. The app is working fine in apache-tomcat
Thirst of all, when i try to get an xhtml page (with simple html the app works, the problem is with jsf) the server shows the error:
could not find factory: javax.faces.context.FacesContextFactory
i've read that i had to use the "parent last" option in the class loader section, but it didn't worked. Then i went to jsp and jsf options on the web module properties, and there i can choose between Sun reference implementation 1.2 and MyFaces 1.2, the sun was selected, so i choose myfaces and now the error is another one: if i try to go to "something.xhtml", it redirects to "something.jsf", which doesn't exists..
any idea?
thanks!
It seems that you didn't include the JSF implementation on your classpath.
Here's how I solved it.
Use the following library: javax.faces-2.1.7.jar
If you are on PrimeFaces 3.1: primefaces-3.1.1.jar
Application Server instance: Class Loading - Parent Last
Enterprise Application instance (war Module): Class Loading - Parent Last
Make sure to remove all Servlet Container libraries such as those needed by Tomcat.
I have been struggling with the unholy alliance that is WebSphere 7+ and Mojarra 2.0.4 and have run into something of a showstopper.
I followed the directions as specified at this forum post and got Mojarra 2.0.4 initializing properly: http://forum.primefaces.org/viewtopic.php?f=3&t=6860
Basically I created an isolated classloader shared library that refers externally to the Mojarra and Primefaces jars, added the shared library to the webapp and reversed the classloader to go PARENT_LAST. All of that works.
When I attempt to access my web app http://server:port/context/index.xhtml it is hitting the FacesServlet correctly but then instantly the Request Dispatcher is redirecting to index.jsp???
I don't have any JSP specified ANYWHERE in my code, my app, my web.xml, and in fact I specified DEFAULT-SUFFIX to be .xhtml and that didn't help. All my web pages are .xhtml extension and FacesServlet is mapped correctly to *.xhtml.
I have tried adding XHTML as a mime type to WebSphere, disabling the Request Dispatcher, all to no avail. I have been able to get this running correctly on Tomcat 6-7, JBoss 6 and Glassfish 3 with no problems but for some reason WebSphere insists on a JSP file extension?
I appreciate any help you might have.
WAS7 sometimes does not undeploy the web applications properly. Clearing WAS_PROFILE_HOME/temp and WAS_PROFILE_HOME/wstemp may help.
Please help with this issue, I'm going mad...
I'm trying to make a client-server web application using Weblogic 10 as an application server and IIS as a webserver (corporate constraints), with EJB 3 and Struts 2. I am however having strage problems which I cannot solve.
Using Struts 2.2 I get the following stack trace while starting the server:
<12-ott-2010 16.02.21 CEST> <Error> <HTTP> <BEA-101165> <Could not load user def
ined filter in web.xml: org.apache.struts2.dispatcher.FilterDispatcher.
java.lang.reflect.InvocationTargetException - Class: com.opensymphony.xwork2.inj
ect.ContainerImpl$MethodInjector
File: ContainerImpl.java
Method: inject
Line: 295 - com/opensymphony/xwork2/inject/ContainerImpl.java:295:-1
at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:428)
at org.apache.struts2.dispatcher.FilterDispatcher.init(FilterDispatcher.
java:190)
at weblogic.servlet.internal.FilterManager$FilterInitAction.run(FilterMa
nager.java:320)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(Authenticate
dSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(Unknown Source)
Truncated. see log file for complete stacktrace
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
[...]
java.lang.IllegalArgumentException: Javassist library is missing in classpath! P
lease add missed dependency!
at ognl.OgnlRuntime.<clinit>(OgnlRuntime.java:165)
[...]
However, the Javassist package is clearly visible in the web classpath (/WEB-INF/lib direcotry) among all the other Struts-related libraries, I can also browse its packages and classes. I also put it in the CLASSPATH library and in Weblogic initializaion parameters but nothing works. I don't know what to think. Is this a Struts 2/Weblogic integration bug?
Even weirder is the fact that initially I managed to make Struts 2 work. Then for some reason (I don't really know what for) it stopped and I can't get rid of that error.
Thanks for your help.
Often solutions come when all hope is lost. Apparently all I had to do was moving all Struts libraries (including Javassist) to the /lib directory of the parent EAR project. This sounds weird to me, but it works and I'm sticking with the solution.
I'm not very familiar with Weblogic and Enterprise apps in general, so it didn't came to mind readily that the server treats the EAR as the base context and not the contained WAR.