I'm having three xml files and in all of them the schema versions are defined. However I removed all the version and kept it as default one, But I'm having these error messages and my beans are not getting intialized. Please refer the attached image to see the errors:
ApplicationContext.xml file
SecurityConfig.xml file
Servlet-context.xml file
Spring-version : 5.3.19
Java version - 17
Maven - 3.8.7
Wildfly - 25
I've also tried to make the schema version as 5.3.19, by making that error goes away but at the runtime same error comes. Please help me in resolving this.
Related
I am using log4j 2.4 and trying to convert log4j2.xml to log4j.properties, however monitorInterval property doesn't seem to be working with log4j2.properties.
status = trace
name=PropertiesConfig
property.filename = logs
appenders = console, file
monitorInterval=10
though log4j2 following documentation
https://logging.apache.org/log4j/2.x/manual/configuration.html#Properties
clearly stats that
Properties configuration files support the advertiser,
monitorInterval, name, packages, shutdownHook, status
any changes in property file doesn't leads to reloading of logging configuration. On the contrary, it seems to be perfectly working in xml format
<Configuration status="TRACE" monitorInterval="5">
where whenever I do make any changes in .xml my log4j configuration is picked up and is verified via following log.
2016-06-17 14:43:17,267 Thread-5 DEBUG Reconfiguration started for context 1198108795 (org.apache.logging.log4j.core.LoggerContext#86be70a)
2016-06-17 14:43:17,268 Thread-5 DEBUG Not in a ServletContext environment, thus not loading WebLookup plugin.
2016-06-17 14:43:17,273 Thread-5 DEBUG Initializing configuration XmlConfiguration[location=/Users/userx/Desktop/logs/log4j2_prod.xml]
I also tried to upgrade Log4j version to 2.5 but still observe same behavior.
To add to Ralph's answer, this was fixed in Log4j 2.6. The corresponding ticket is https://issues.apache.org/jira/browse/LOG4J2-1263
Please use Log4j-2.6.1 or later.
This was a bug that has been fixed. I would suggest updating the latest log4j release.
Summary: I have a very basic Java 1.8 and Spring 4.0.5 project, I'm using Maven 3.2.3 to manage it. Maven exec cannot seem to see my Spring context, even though it appears to me that it is in the classpath.
My spring context is in
<project root>/src/main/resources/spring/ch2-beans.xml
and I load it using:
ClassPathXmlApplicationContext applicationContext = new ClassPathXmlApplicationContext("/spring/ch2-beans.xml");
after a "mvn clean compile" I see
<project root>/target/classes/spring/ch2-beans.xml
and when I run:
mvn -X exec:java -Dexec.mainClass="com.wiley.beginning.spring.ch2.Main"
I see the following debug output which makes me think the classpath is indeed correct:
[DEBUG] Collected project classpath [/Users/me/Documents/workspace/BeginningSpring/chapter2/spring-book-ch2/target/classes]
[DEBUG] Adding to classpath : file:/Users/me/Documents/workspace/BeginningSpring/chapter2/spring-book-ch2/target/classes/
Yet I get the following error:
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from class path resource [spring/ch2-beans.xml]; nested exception is java.io.FileNotFoundException: class path resource [spring/ch2-beans.xml] cannot be opened because it does not exist
Can anyone point me in the direction of sorting this out? What I've posted above is the result of many different attempts to solve this, and I'm stumped by the error when it certainly appears that the file path should be in the classpath, so perhaps this is something that has changed since I last coded (a while ago..). Thanks!
Update..
Thinking that it might be some classpath issue with exec:java I ran the same code inside a unit test, executed within maven. Same error. I've also tried loading the xml file as "classpath:/spring/ch2-beans.xml", did not fix it.
There was a hyphen in the file name of the Spring configuration I was trying to load, and it appears that the classloader won't accept that. Hyphens are illegal in identifier names in Java, apparently this applies also to external resources.
Once I removed the hyphen from the xml file name, it was found.
On a related note, I'm pretty annoyed with the "Beginning Spring" book example which uses these hyphenated names.
I am trying to run a very simple ear applicaiton . i seem to run into exactly this issue but the discussions here dont work for me JDBC resource name being modified by container (__pm being appended to it)
In my case also the datasource name is being appened by __pm. I have no clue where it comes from but the server logs point to the fact that instead of searching for databasename it searches for databasename__pm and fails the deployment.
Persistence.xml :-
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
<persistence-unit name="FCK-ejbPU" transaction-type="JTA">
<jta-data-source>FCKDatabase</jta-data-source>
<exclude-unlisted-classes>false</exclude-unlisted-classes>
<properties/>
</persistence-unit>
</persistence>
Glassfish logs :
Error occurred during deployment: Exception while preparing the app : Invalid resource : { ResourceInfo : (jndiName=java:app/jdbc/FCKDatabase__pm), (applicationName=FCK) }. Please see server.log for more details.
Exception while invoking class org.glassfish.persistence.jpa.JPADeployer prepare method : java.lang.RuntimeException: Invalid resource : { ResourceInfo : (jndiName=java:app/jdbc/FCKDatabase__pm), (applicationName=FCK) }
Invalid resource : { ResourceInfo : (jndiName=java:app/jdbc/FCKDatabase__pm), (applicationName=FCK) }
As you can see my the JNDI name of my resources is appened with __pm.
Also on the Glassfish server console the resource is correctly shown as FCKDatabase and not FCKDatabase_pm
Any idea where this __pm comes from ?
System:
Netbeans 7.3
Glassfish Server 3.1.2
The problem was that the mysql connector jar file was not placed into the glassfish server. This kicks in a series of problems. The one that I posted above is just one of the error messages that the server logs contains. I suggest going through the entire list of error message and try to debug from there. The following link helped me place the jar files at the correct location:
Connecting a MySQL database to Glassfish classpath is not set or classname is wrong
Blog Class name is wrong or classpath is not set for: com.mysql.jdbc.jdbc2.optional.MysqlDataSource
Since Netbeans 7.1 when the IDE generates the persistence.xml the jta field and glassfish-resouces JDNI name is generated with a prefix java:module/, it has to be deleted in both files, it has to look like jdbc/[anyName]. This was tested on Netbeans 8.1 and Glassfish 4.0.
In the image, the second option shows the generated name, which is invalid en Glassfish because the ':'
Here is another solution which I have found, it will be helpful to anyone.
Copy the resource name which you are facing the problem and follow the below steps.
Login into Glassfish console
Goto Resources
JDBC --> JDBC Resources
Click on New button to add resource
Enter the copied resource into JNDI name field and select the pool name and enter the description.
Click on Ok button
Redeploy the application and check.
In my case I just moved my glassfish-resources.xml file,
from:
my_web_app / src / main / webapp / WEB-INF
to:
my_web_app / src / main / setup
And GlassFish started to recognize the file the created the resources.
I updated a project that was using struts 2.2.3.1 to the 2.3.1.2 in the pom.xml file. After running maven it picked up the jar from the repo and all that and built the package just fine. But, when I run the webapp I am getting this error:
2012-04-26 13:42:06,300 ERROR org.apache.struts2.dispatcher.Dispatcher.error:38 - Dispatcher initialization faile Unable to load configuration. - bean - jar:file:/Library/Tomcat/apache-tomcat-6.0.35/webapps/idmadmin/WEB-INF/lib/struts2-core-2.3.1.2.jar!/struts-default.xml:29:72.....
I was thinking that maybe the old one was still stuck in the classpath but I don't see it.
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