Reputation: 1991
My Eclipse project is suddenly no longer deploying properly. I can't trace it to any particular change I've made to the environment.
I have tested with multiple source-controlled projects and they are all behaving the same way:
May 01, 2013 12:00:45 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:\Program Files (x86)\Java\jdk1.7.0_11\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows \System32\WindowsPowerShell\v1.0\;.
May 01, 2013 12:00:45 PM org.apache.tomcat.util.digester.SetPropertiesRule begin
WARNING: [SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting property 'source' to 'org.eclipse.jst.jee.server:fismacm' did not find a matching property.
May 01, 2013 12:00:45 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-bio-8080"]
May 01, 2013 12:00:45 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["ajp-bio-8009"]
May 01, 2013 12:00:45 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 296 ms
May 01, 2013 12:00:45 PM org.apache.catalina.core.StandardService startInternal
INFO: Starting service Catalina
May 01, 2013 12:00:45 PM org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/7.0.35
May 01, 2013 12:00:46 PM org.apache.catalina.core.ApplicationContext log
INFO: No Spring WebApplicationInitializer types detected on classpath
May 01, 2013 12:00:48 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jstl/core is already defined
May 01, 2013 12:00:48 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jstl/sql_rt is already defined
May 01, 2013 12:00:48 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jsp/jstl/sql is already defined
May 01, 2013 12:00:48 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jstl/core_rt is already defined
May 01, 2013 12:00:48 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jsp/jstl/core is already defined
May 01, 2013 12:00:48 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jsp/jstl/functions is already defined
May 01, 2013 12:00:48 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jstl/fmt is already defined
May 01, 2013 12:00:48 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://jakarta.apache.org/taglibs/standard/permittedTaglibs is already defined
May 01, 2013 12:00:48 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jstl/xml is already defined
May 01, 2013 12:00:48 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://jakarta.apache.org/taglibs/standard/scriptfree is already defined
May 01, 2013 12:00:48 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jstl/fmt_rt is already defined
May 01, 2013 12:00:48 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jsp/jstl/fmt is already defined
May 01, 2013 12:00:48 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jsp/jstl/xml is already defined
May 01, 2013 12:00:48 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jstl/xml_rt is already defined
May 01, 2013 12:00:48 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jstl/sql is already defined
May 01, 2013 12:00:48 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://www.springframework.org/tags/form is already defined
May 01, 2013 12:00:48 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://www.springframework.org/tags is already defined
May 01, 2013 12:00:48 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://www.springframework.org/security/tags is already defined
May 01, 2013 12:00:48 PM org.apache.catalina.core.ApplicationContext log
INFO: No Spring WebApplicationInitializer types detected on classpath
May 01, 2013 12:00:48 PM org.apache.catalina.core.ApplicationContext log
INFO: No Spring WebApplicationInitializer types detected on classpath
May 01, 2013 12:00:48 PM org.apache.catalina.core.ApplicationContext log
INFO: Set web app root system property: 'webapp.root' = [X:\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\fismacm\]
May 01, 2013 12:00:48 PM org.apache.catalina.core.ApplicationContext log
INFO: Initializing log4j from [X:\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\fismacm\WEB- INF\log4j.properties]
May 01, 2013 12:00:48 PM org.apache.catalina.core.ApplicationContext log
INFO: Initializing Spring root WebApplicationContext
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
May 01, 2013 12:00:49 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-bio-8080"]
May 01, 2013 12:00:49 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["ajp-bio-8009"]
May 01, 2013 12:00:49 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 3898 ms
This seems like the key component: INFO: No Spring WebApplicationInitializer types detected on classpath.
I've tried cleaning the projects, redefining the servers, and even creating whole new workspaces. I've clearly missed the mark.
Any tips on getting this cleaned up would be greatly appreciated.
Upvotes: 29
Views: 184267
Reputation: 1
I was using Spring 6 with Java 21. It worked when i changed to Java 17. From what i understand it could be related to some java modules concept.
Upvotes: 0
Reputation: 22
No Spring WebApplicationInitializer types detected on classpath.
Add the following class file in WEB-INF/classes/anypackage
package mypackage.config;
import org.springframework.security.web.context.*;
public class SecurityWebApplicationInitializer
extends AbstractSecurityWebApplicationInitializer {
}
This program registers the DelegatingFilterProxy to use the springSecurityFilterChain before any other registered Filter. When used with AbstractSecurityWebApplicationInitializer(Class ...), it will also register a ContextLoaderListener. When used with AbstractSecurityWebApplicationInitializer(), this class is typically used in addition to a subclass of AbstractContextLoaderInitializer.
Upvotes: 0
Reputation: 41
Check <context:component-scan base-package="com..."/> I got the same error because I was using the incorrect base-package and it resolved after using the correct one.
Upvotes: 0
Reputation: 24910
In my case, I need to specify the war source dir correctly when packaging as war.
e.g:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>3.3.2</version>
<configuration>
<warSourceDirectory>src/main/webapp</warSourceDirectory>
</configuration>
</plugin>
(This is an extremely old project ..)
Upvotes: 0
Reputation: 83
Stop Tomcat
Upvotes: 0
Reputation: 1
In case you are using Eclipse IDE And found the problem INFO: No Spring WebApplicationInitializer types detected on classpath Please check the definition of "Web App Libraries " as shown in the picture. Is it there? If not, then "Add Library->Web App Libraries" then clean & build and restart server
Look at the class path as in the picture.
Upvotes: 0
Reputation: 6895
In my case it also turned into a multi-hour debugging session. Trying to set up a more verbose logging turned out to be completely futile because the problem was that my application did not even start. Here's my context.xml
:
<?xml version='1.0' encoding='utf-8'?>
<Context path="/rc2" docBase="rc2" antiResourceLocking="false" >
<JarScanner>
<JarScanFilter
tldScan="spring-webmvc*.jar, spring-security-taglibs*.jar, jakarta.servlet.jsp.jstl*.jar"
tldSkip="*.jar"
<!-- my-own-app*.jar on the following line was missing! -->
pluggabilityScan="${tomcat.util.scan.StandardJarScanFilter.jarsToScan}, my-own-app*.jar"
pluggabilitySkip="*.jar"/>
</JarScanner>
</Context>
The problem was that to speed up the application startup, I started skipping scanning of many JARs, unfortunately including my own application.
Upvotes: 1
Reputation: 31
I faced this problem and finally resolved. Please make sure that your web.xml and Servlet.xml file should present in web/inf folder.
Also Please add spring jars into Web Deployment assembly in project properties
We might missed out this when setting up the project from beginning.
Upvotes: 3
Reputation: 582
I spent my whole day today investigating this problem and none of the answers helped. Here is my scenario. The WebApplicationInitializer types in my case are inside jar files. we have a multi-module gradle web project where each module is packaged as a jar and included in the web artifact. The problem is that Apache tomcat's classloader is not looking for the implementations of WebApplicationIntializer in WEB-INF/lib instead its looking for those types directly under WEB-INF/classes folder.
Here is what I ended up doing for anyone who faces this problem in future.
I implemented a ServletContainerInitializer myself and added that class name to META-INF/services/javax.servlet.ServletContainerInitializer
In the implementation, I copied the code from SpringServletContainerIntializer and used reflections to find the classes implementing a CustomWebApplicationInitializer interface, I did not make use of spring's WebApplicationInitializer interface to avoid any conflicts. Basically I have the same contract as WebApplicationInitializer with a different name. Now on startup, my container initializer is called and I delegated the call to all my CustomWebApplicationInitializers.
Based on my search I also found that the loader used for tomcat can be updated to have it search in WEB-INF/lib but I have little control over the tomcat I deploy my app to so went with the above solution. Hope this helps someone.
Upvotes: 1
Reputation: 1986
Tomcat usually does not add classes in src/test/java
to the classpath. They are missing if you run tomcat in scope test. To order tomcat to respect classes in test, use -Dmaven.tomcat.useTestClasspath=true
or add
<properties>
<maven.tomcat.useTestClasspath>true</maven.tomcat.useTestClasspath>
</properties>
To your pom.xml
.
Upvotes: 1
Reputation: 37
STS has a metadata folder under its workspace. You will see the actual error in .log file under C:\Users\firstname.lastname\Documents\workspace-sts-3.9.2.RELEASE.metadata
Upvotes: 0
Reputation: 173
I got a silly error it took me an embarrassingly long to solve.... Check out my pom.xml ...
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.outbottle</groupId>
<artifactId>PersonalDetailsMVC</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>war</packaging>
<name>PersonalDetailsMVC</name>
<properties>
<endorsed.dir>${project.build.directory}/endorsed</endorsed.dir>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<spring.version>4.0.1.RELEASE</spring.version>
<jstl.version>1.2</jstl.version>
<javax.servlet.version>3.0.1</javax.servlet.version>
</properties>
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-web-api</artifactId>
<version>7.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>${javax.servlet.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>jstl</groupId>
<artifactId>jstl</artifactId>
<version>${jstl.version}</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
<compilerArguments>
<endorseddirs>${endorsed.dir}</endorseddirs>
</compilerArguments>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.3</version>
<configuration>
<failOnMissingWebXml>false</failOnMissingWebXml>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<outputDirectory>${endorsed.dir}</outputDirectory>
<silent>true</silent>
<artifactItems>
<artifactItem>
<groupId>javax</groupId>
<artifactId>javaee-endorsed-api</artifactId>
<version>7.0</version>
<type>jar</type>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Problem was my package name. It MUST be "com.outbottle" (then config/controllers/model/etc) for it to work. As you can see above, I used Maven (for the first time), Spring, 1.8 JDK and nearly had a stroke debugging this issue. All running on Glassfish (Tomcat is ok too for the above pom config). That said, I'm all happy with myself now and know Maven and Spring much better for the next step of my Spring learning curve. Hoping this helps you also!
Upvotes: 0
Reputation: 76
xml was not in the WEB-INF folder, thats why i was getting this error, make sure that web.xml and xxx-servlet.xml is inside WEB_INF folder and not in the webapp folder .
Upvotes: 0
Reputation: 337
Watch out if you are using Maven. Your folder's structure must be right.
When using Maven, the WEB-INF directory must be inside webapp:
src/main/webapp/WEB-INF
Upvotes: 9
Reputation: 51
INFO: No Spring WebApplicationInitializer types detected on classpath.
Can also show up if you're using Maven with Eclipse and deploying your WAR using;
(Eclipse, Kepler, with M2)
(right-click on your project) -> Run As -> Run on Server
It's down to the generation and deletion of the m2e-wtp folder and contents.
Make sure, Maven Archive generated files under the build directory is checked.
Under: "Window -> preferences -> Maven -> Java EE Integration"
Then:
Use M2, to do your build, i.e. the usual Clean -> package or Install etc...
If "Project -> Build Automatically" is not selected. You can force the "m2e-wtp folder and contents" generation by doing;
"(right-click on your project) -> Maven -> Update Project..."
Note: make sure the "Clean Projects" option is un-selected. Otherwise the contents of target/classes will be deleted and you're back to square one.
Also,when;
"Project -> Build Automatically" is selected the "m2e-wtp folder and contents" is generated
or "Project -> Build All"
or "(right-click on project) -> Build Project"
Upvotes: 5
Reputation: 17553
I spent hours on this, and the solution was:
Upvotes: 31
Reputation: 1991
This turned out to be a stupid error. My log4j wasn't configured to capture my error output. I was throwing configuration errors in the background and once I fixed those I was good to go and my request mappings worked fine.
Upvotes: 12
Reputation: 12453
WebApplicationInitializer is an interface you can implement in one of your classes. At startup Spring is scanning for this classes, as long as you are using servlet spec 3 and have a metadata-complete="false" attribute in your web.xml. But that doesn't seem to be the problem. The only error I can figure out is the missing slf4j-log4j12.jar.
Upvotes: 2