I am getting the following error when deploying an application on JBoss 4.2.1
7:05:59,673 ERROR [Application Name]StandardWrapper.Throwable
java.lang.IllegalStateException: Application was not properly initialized at
startup, could not find Factory: javax.faces.context.FacesContextFactory
I browsed the net and I found many posts which suggested to add an entry in web.xml but that entry was already there. And all the required libraries are there in web-inf.
So any solutions anybody ?
Ensure that your classpath is clean (i.e. no duplicate different versioned classes/JAR files, keep in mind that JBoss ships with builtin JSF libraries!) and that your web.xml is declared as at least Servlet 2.3.
Related
Resource annotations on the fields of the org.springframework.web.servlet.DispatcherServlet class will be ignored. The annotations could not be obtained because of the exception :
java.lang.NoClassDefFoundError: org.springframework.web.context.WebApplicationContext
I am also seeing some Maven dependency errors when I performed a Maven build, Can you please help how I can resolve these classpath errors
using spring-core-4.1.4.release.jar, spring-webmvc-4.1.4.RELEASE.jar
Error #2 - This is another error being displayed, which may be related to above error,
javax.servlet.UnavailableException: SRVE0203E: Servlet [appServlet]: org.springframework.web.servlet.DispatcherServlet was found, but is missing another required class.
SRVE0206E: This error typically implies that the servlet was originally compiled with classes which cannot be located by the server.
Your application clearly needs the Spring framework and can't find it. It either needs to be deployed as part of the EAR/WAR, or configured as a shared library in your server and mapped to your application.
Websphere 8.0.0.11
Hibernate 4.2.21.Final
I have found many questions about this same problem but none of them worked for me.
If I deploy the application in Websphere it works OK.
However we have defined a shared library that contains all the third party libraries (spring, hibernate, javassist, etc) so that our WARs are thinner.
This way during deployment we associate our thin WAR against that Websphere shared library.
The point is that when we deploy the application this way the ClassCastException Hibernate exception _$$_javassist_856 cannot be cast to javassist.util.proxy.Proxy is thrown.
I have checked the loaded jars in the websphere console and can only see one javassist jar (3.18.1-GA) in the classpath.
Why could this be happening?
UPDATE
I have also tried using PARENT_FIRST and PARENT_LAST class loading.
UPDATE 2
I just found out that Websphere is loading its own javassist jar:
URL location = ProxyFactory.class.getProtectionDomain().getCodeSource().getLocation();
logger.info("{}", location);
It prints: file:/opt/IBM/WebSphere/AppServer/plugins/javassist.jar
After trying pretty much everything I found on S.O. without any success I decided to downgrade Hibernate to version 4.1.12.Final. This is the maximum 4.x version compatible with Websphere 8.x.
The problem is that Javassist leaves traces in its generated code. With Javassist on the class path twice, its classes are loaded twice. Two types are however only equal if they have the same name and are loaded by the same class loader. In your case, the generated class resolves its Javassist dependeny to a type that is loaded by your application class loader while your code is casting the instance to the Javassist type that is loaded by the Websphere class loader (or the other way around).
Are you sharing any Hibernate dependencies between applications? Try to not use any shared libraries related to Hibernate in your application to avoid this.
We are integrating an internal framework into our weblogic application and we are running into deployment problems.
Technologies Used
Weblogic 10.3.6 application
Spring 3.0
Maven 2
Eclipse J2EE
The Problem
On startup of the weblogic application, we receive the following NoSuchMethodError while initializing one of the beans. This error is occuring when calling classes in the org.joda.time (2.0) jar.
Caused By: java.lang.NoSuchMethodError: org.joda.time.DateTimeZone.convertLocalToUTC(JZ)J
at org.joda.time.LocalDate.toDateTimeAtStartOfDay(LocalDate.java:715)
at org.joda.time.LocalDate.toDateTimeAtStartOfDay(LocalDate.java:690)
. . . excluded . . .
Things We Have Tried
After Googling "NoSuchMethodError spring", many of the problems seem to be incompatible Spring versions. After printing the dependency tree, the only Spring version in use is 3.0.
Googling "NoSuchMethodError" usually gave JAR hell solutions.
Multiple versions of the same dependency. After doing some maven dependency management, the only joda-time jar in use is 2.0. Additionally, the local repository was purged of any unnecessary jars.
.war / runtime may not have the correct jars included in the lib directory. After looking into the WEB_INF/lib directory, the only joda-time jar is version 2.0, which contains all of the appropriate class files
One mysterious thing is that the DateTimeZone.convertLocalToUTC(JZ)J has been a part of the org.joda.time project since 1.0, so even if we have incompatible versions, the method should still be found, especially if the class and package are able to be found.
Finally there are no other DateTimeZone classes in the project (ctrl+shift+T search in eclipse) so I'm confused as to which class is being loaded if the org.joda.DateTimeZone class is not being loaded.
Questions:
Can anyone explain why the method could not be found?
Are there more places to check for existing or conflicting jars?
Is there a way to check the DateTimeZone class that the LocalDate class is using during runtime via Eclipse debug?
Here's some interesting reading:
prefer-web-inf-classes Element
The weblogic.xml Web application deployment descriptor contains a
element (a sub-element of the
element). By default, this element is set to
False. Setting this element to True subverts the classloader
delegation model so that class definitions from the Web application
are loaded in preference to class definitions in higher-level
classloaders. This allows a Web application to use its own version of
a third-party class, which might also be part of WebLogic Server. See
“weblogic.xml Deployment Descriptor Elements.”
taken from: http://docs.oracle.com/cd/E15051_01/wls/docs103/programming/classloading.html
Other troubleshooting tips:
You can try: -verbose:class and check your managed server's logs to check if the class is being loaded properly.
An efficient way to confirm which intrusive jar might be getting loaded is by running a whereis.jsp within the same webcontext (i.e., JVM instance) of this app.
--whereis.jsp --
<%# page import="java.security.*" %>
<%# page import="java.net.URL" %>
<%
Class cls = org.joda.time.DateTimeZone.class;
ProtectionDomain pDomain = cls.getProtectionDomain();
CodeSource cSource = pDomain.getCodeSource();
URL loc = cSource.getLocation();
out.println(loc);
// it should print something like "c:/jars/MyJar.jar"
%>
You can also try jarscan on your $WEBLOGIC_HOME folder to see if you can find the jar that contains this class: https://java.net/projects/jarscan/pages/Tutorial
A NoSuchMethodError is almost always due to conflicting library versions. In this case I'm guessing there are multiple versions of joda libraries in the two projects.
Weblogic is pulling the org.joda jar.
Tryu adding this in your weblogic.xml to exclude the jar that weblogic is pulling, and instead use your appllication jar.
The below is from my application, you can have a look what all we have to removed for our application.
<wls:container-descriptor>
<wls:prefer-application-packages>
<wls:package-name>antlr.*</wls:package-name>
<wls:package-name>org.slf4j.*</wls:package-name>
<wls:package-name>org.slf4j.helpers.*</wls:package-name>
<wls:package-name>org.slf4j.impl.*</wls:package-name>
<wls:package-name>org.slf4j.spi.*</wls:package-name>
<wls:package-name>org.hibernate.*</wls:package-name>
<wls:package-name>org.springframework.*</wls:package-name>
<wls:package-name>javax.persistence.*</wls:package-name>
<wls:package-name>org.apache.commons.*</wls:package-name>
<wls:package-name>org.apache.xmlbeans.*</wls:package-name>
<wls:package-name>javassist.*</wls:package-name>
<wls:package-name>org.joda.*</wls:package-name>
<wls:package-name>javax.xml.bind.*</wls:package-name>
<wls:package-name>com.sun.xml.bind.*</wls:package-name>
<wls:package-name>org.eclipse.persistence.*</wls:package-name>
</wls:prefer-application-packages>
<wls:show-archived-real-path-enabled>true</wls:show-archived-real-path-enabled>
</wls:container-descriptor>
I am trying to run the Spring 4 example given # https://spring.io/guides/gs/messaging-stomp-websocket. When I try to connect to socket, it throws me following exception. As per the example you need tomcat 7.0.50 and I checked the executable jar which has right version of tomcat. Any pointer would be helpful.
java.lang.IllegalArgumentException: No 'javax.websocket.server.ServerContainer' ServletContext attribute. Are you running in a Servlet container that supports JSR-356?
Check that you have tomcat7-websocket.jar and websocket-api.jar bundled in your executable jar - perhaps you're just getting vanilla tomcat without the extra websocket bits.
I got the same error message in another use case: I deactivated auto configuration and added WebSocketConfig manually to the configuration. Then I got the abovementioned error message.
Fixing the problem was easy: just adding WebSocketAutoConfiguration to the configuration.
I know that this is an ancient thread but I ran into this error and resolved it in modern times by adding implementation("org.springframework.boot:spring-boot-starter-tomcat") explicitly to my project.
I am trying to deploy a war that i didnt write and i am getting this error in my logs:
java.lang.NoClassDefFoundError: HttpSessionListener
i know that HttpSessionListener lives in servlet-api.jar which is found in the lib dir of tomcat(my app server).
I tried including servlet-api.jar in the war's WEB-INF/lib folder, but the logs yelled at me for doing that:
INFO: validateJarFile(/home/test/apache-tomcat-6.0.18/webapps/test/WEB-INF/lib/servlet-api.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class
the internets claim that you dont have to include that class in your lib folder.
edit:
i removed the offending listener (which was causing the problem above) from web.xml because it didnt look very important. this revealed more errors:
java.lang.Error: Unresolved compilation problem:
The type javax.servlet.FilterChain cannot be resolved. It is indirectly referenced from required .class files
what am i missing?
Though the question is too old will tell about a possible problem nowadays. As per the Tomcat 10 download page:
Users of Tomcat 10 onwards should be aware that, ..., the primary package for all implemented APIs has changed from javax.* to jakarta.*. This will almost certainly require code changes to enable applications to migrate from Tomcat 9 and earlier to Tomcat 10 and later.
So use Tomcat 9 instead of 10.
#BalusC's explanation sounds more plausible than mine ...
Some other possible explanations / things to check:
The servlet-api.jar is not in $CATALINA_HOME/lib, or for some reason doesn't contain the class. (I know you said you "know" it's there, but you didn't specifically say you checked it.)
Something else is broken which caused the first attempted load of HttpSessionListener to fail with an uncaught exception during static initialization. (This is kind of implausible, since HttpSessionListener is an interface. But it is worth checking the logs for earlier class loading errors ... just in case.)
The missing class might be named foo.bar.HttpSessionListener rather than javax.servlet.http.HttpSessionListener. This is likely to show up in the nested stack trace.
If something in the WAR you are deploying is creating its own classloader, it is possible that is is doing this incorrectly and the HttpSessionListener class is not on the classloader's effective classpath.
EDIT
If you are now seeing unresolved compilation errors reported in the logs, you should be suspecting the WAR file and the process used to build it. Specifically, it sounds like the WAR includes classes that had Java compilation errors!
(Or maybe this is a problem compiling JSPs ... but that would show up in the logs too.)
As per its javadoc that class was introduced in Servlet API version 2.3.
If you're receiving this error, then it can have basically three causes:
Your web.xml is declared as Servlet 2.2 or lower (or incorrectly declared; Tomcat may fall back to least compatibility modus). Since you're using Java EE 5 and thus Servlet 2.5, the web.xml should then be declared like as:
<web-app
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
id="YourWebAppID" version="2.5">
Your servletcontainer doesn't support Servlet 2.3 at all and will fall back to least compatibilty modus. But this can be excluded since Tomcat 6 should support Servlet 2.5.
You actually have another Servlet API JAR file of an ancient version in the classpath which is taking precedence in classloading. Since you already excluded WEB-INF/lib the next places to look would be JRE/lib and JRE/lib/ext folders.
Update: as per your edit, FilterChain was also introduced in Servlet API version 2.3.
1 + 1 = ... :)
java.lang.NoClassDefFoundError: javax/servlet/ServletContextListener for this NoClassDefFoundError on HttpSessionListener , ServletListener , ServletContextListener, etc. can be caused by a custom classloader like Sysdeo DevLoader (when using it with Eclipse) in you Context definition in the Tomcat’s server.xml file.
<Loader classname="org.apache.catalina.loader.DevLoader"
reloadable="true" debug="1" />
there.....insted of this use...
<Loader classname="org.apache.catalina.loader.DevLoader"
reloadable="true"
debug="1" useSystemClassLoaderAsParent="false"/>
and add DevLoader.jar to ur class path