Reputation: 2917
I am trying to deploy my web application on Wildfly 8 but get an error. The error states that The deployment scanner found a directory named META-INF that was not inside a directory whose name ends with .ear, .jar, .rar, .sar or .war.
. This is a strange problem since my web.xml is in the src/main/webapp/WEB-INF/
directory and the built package do ends with .war.
I have also tried to deploy a simple webapp generated by Maven. Is it the maven-archetype-webapp
and it also fails on deployment with the same error message. See below:
ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015010: The deployment scanner found a directory named META-INF that was not inside a directory whose name ends with .ear, .jar, .rar, .sar or .war. This is likely the result of unzipping an archive directly inside the /opt/wildfly8/standalone/deployments directory, which is a user error. The META-INF directory will not be scanned for deployments, but it is possible that the scanner may find other files from the unzipped archive and attempt to deploy them, leading to errors.
09:40:43,353 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "WebApp" (runtime-name: "WebApp")
09:40:43,354 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "pom.xml" (runtime-name: "pom.xml")
09:40:43,843 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "WebApp" (runtime-name : "WebApp")
09:40:43,844 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "pom.xml" (runtime-name : "pom.xml")
Is this a bug in WildFly or something? Since the generated Maven project also fails, it makes me think that it can be a bug.
EDIT
I have now tried the WildFly quickstart projects and their helloworld
app (https://github.com/wildfly/quickstart/tree/master/helloworld) works good on my WildFly instance. But when I add my web.xml to the helloworld project and change the servlet code to my own servlet code and the pom.xml so it corresponds with my settings, then I get errors.
04:50:28,073 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "MyService.war" (runtime-name: "MyService.war")
04:50:28,236 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment MyService.war
04:50:28,278 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016005: Starting Services for CDI deployment: MyService.war
04:50:28,285 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016008: Starting weld service for deployment MyService.war
04:50:28,318 WARN [org.jboss.weld.Event] (MSC service thread 1-2) WELD-000411: Observer method [BackedAnnotatedMethod] com.sun.jersey.server.impl.cdi.CDIExtension.processAnnotatedType(@Observes ProcessAnnotatedType<Object>) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
04:50:28,622 INFO [com.sun.jersey.api.core.PackagesResourceConfig] (MSC service thread 1-2) Scanning for root resource and provider classes in the packages:
org.rox.webservice
04:50:28,641 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./MyService: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./MyService: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
Caused by: com.sun.jersey.core.spi.scanning.ScannerException: The URI scheme vfs of the URI vfs:/content/MyService.war/WEB-INF/classes/org/rox/webservice is not supported. Package scanning deployment is not supported for such URIs.
Try using a different deployment mechanism such as explicitly declaring root resource and provider classes using an extension of javax.ws.rs.core.Application
at com.sun.jersey.core.spi.scanning.PackageNamesScanner.scan(PackageNamesScanner.java:225)
at com.sun.jersey.core.spi.scanning.PackageNamesScanner.scan(PackageNamesScanner.java:139)
The web.xml:
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
<servlet>
<servlet-name>MyWebService</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>org.rox.webservice</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>MyWebService</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
<display-name>MyWebService</display-name>
</web-app>
The pom.xml
<?xml version="1.0"?>
<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/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>MyWebService</groupId>
<artifactId>MyWebService</artifactId>
<version>8.0.0-SNAPSHOT</version>
<packaging>war</packaging>
<name>MyWebService</name>
<description>MyWebService</description>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<version.wildfly.maven.plugin>1.0.1.Final</version.wildfly.maven.plugin>
<version.compiler.plugin>3.1</version.compiler.plugin>
<version.war.plugin>2.1.1</version.war.plugin>
<!-- maven-compiler-plugin -->
<maven.compiler.target>1.7</maven.compiler.target>
<maven.compiler.source>1.7</maven.compiler.source>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.2</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-server</artifactId>
<version>1.8</version>
</dependency>
</dependencies>
<build>
<!-- Set the name of the war, used as the context root when the app
is deployed -->
<finalName>${project.artifactId}</finalName>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>${version.war.plugin}</version>
<configuration>
<!-- Java EE 7 doesn't require web.xml, Maven needs to catch up! -->
<failOnMissingWebXml>true</failOnMissingWebXml>
</configuration>
</plugin>
<!-- WildFly plugin to deploy war -->
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<version>${version.wildfly.maven.plugin}</version>
</plugin>
<!-- Compiler plugin enforces Java 1.6 compatibility and activates
annotation processors -->
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>${version.compiler.plugin}</version>
<configuration>
<source>${maven.compiler.source}</source>
<target>${maven.compiler.target}</target>
</configuration>
</plugin>
</plugins>
</build>
</project>
Upvotes: 2
Views: 5545
Reputation: 11983
delete <your project name>.war
files from \standalone\deployments
and try again.
Upvotes: 1
Reputation: 28536
EDIT: After doing a bit more digging, this was fixed in the Jersey 2.13 release https://jersey.java.net/release-notes/2.13.html. If you're stuck on Jersey 1.x, see below for the workaround.
There is an issue with using package scanning in Jersey 1.x under JBoss 7 and Wildfly. There was a ticket opened against the Jersey team for this, but it has been closed as "not critical, won't fix": https://java.net/jira/browse/JERSEY-763.
This seems extremely unhelpful since the only workaround I found is listed in that ticket and involves manually specifying all Resource
s manually in a custom class that extends javax.ws.rs.core.Application
and is passed in to the Jersey servlet as an init-param.
I suggest we comment on the ticket and ask why it's not worth fixing since package scanning is much preferred over manually specifying resources for most people.
Here is a sample that worked for me based on the details in that ticket:
web.xml:
<servlet>
<servlet-name>com.sun.jersey.samples.helloworld.resources.MyApplication</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>javax.ws.rs.Application</param-name>
<param-value>com.sun.jersey.samples.helloworld.resources.MyApplication</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<context-param>
<param-name>resteasy.scan</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>resteasy.scan.providers</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>resteasy.scan.resources</param-name>
<param-value>false</param-value>
</context-param>
com.sun.jersey.samples.helloworld.resources.MyApplication
:
package com.sun.jersey.samples.helloworld.resources;
import java.util.HashSet;
import java.util.Set;
import javax.ws.rs.core.Application;
public class MyApplication extends Application {
@Override
public Set<Class<?>> getClasses() {
final Set<Class<?>> classes = new HashSet<Class<?>>();
// Add your class resources here like below
classes.add(HelloWorldResource.class);
return classes;
}
}
Upvotes: 0
Reputation: 1846
I found this dependency in your pom.xml:
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-server</artifactId>
<version>1.8</version>
</dependency>
I think you cannot use Jersey since Wildfly comes with its own JAX-RS implementation (Resteasy). Why did you include this dependency? Try removing it, I think it should be fine then.
Upvotes: 1
Reputation: 1846
Try to use the wildfly maven plugin to deploy your app instead of copying the app manually to the deployments folder. Nevertheless, if you want or need to copy your app to the deployments folder, please copy only the archive from your target folder, not the whole maven project.
Generally you should prefer the "cli-based" deployment method over the deployments folder. The wildfly maven plugin will do all this work for you during deployment.
Upvotes: 1
Reputation: 14061
It seems that you are not deploying a WAR file or WAR directory, but the whole project. Note the pom.xml
on the server log, which shouldn't be there. I'd inspect the standalone/deployments
to check what was copied there.
Also, try to run a mvn package
and manually copying the file to standalone/deployments/
.
Upvotes: 1