Nullpointerexception generated with RESTEasy wadl generator - jboss

RESTEAsy WADL generator was included in our application referring How to generate wadl file for resteasy in jboss.
Deployment done in JBoss EAP 6.4 is successful. But on accessing the WADL generation URL http://host:8080/rest-serviceapp/application.xml, it is generating the following error -
java.lang.NullPointerException
org.jboss.resteasy.wadl.ResteasyWadlWriter.getStringWriter(ResteasyWadlWriter.java:36)
org.jboss.resteasy.wadl.ResteasyWadlWriter.getBytes(ResteasyWadlWriter.java:26)
org.jboss.resteasy.wadl.ResteasyWadlServletWriter.writeWadl(ResteasyWadlServletWriter.java:32)
org.jboss.resteasy.wadl.ResteasyWadlServletWriter.writeWadl(ResteasyWadlServletWriter.java:45)
org.jboss.resteasy.wadl.ResteasyWadlServlet.service(ResteasyWadlServlet.java:55)
javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
The web.xml we use is -
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
version="3.1">
<display-name>Restapp_Service</display-name>
<context-param>
<param-name>resteasy.servlet.mapping.prefix</param-name>
<param-value>/resteasy</param-value>
</context-param>
<context-param>
<param-name>resteasy.scan</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>resteasy.scan.providers</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>resteasy.scan.resources</param-name>
<param-value>true</param-value>
</context-param>
<listener>
<listener-class>org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap</listener-class>
</listener>
<servlet>
<servlet-name>Resteasy</servlet-name>
<servlet-class>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher</servlet-class>
</servlet>
<servlet>
<servlet-name>RESTEasy WADL</servlet-name>
<servlet-class>org.jboss.resteasy.wadl.ResteasyWadlServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Resteasy</servlet-name>
<url-pattern>/resteasy/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>RESTEasy WADL</servlet-name>
<url-pattern>/application.xml</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
</welcome-file-list>
The resteasy-wadl dependency is -
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-wadl</artifactId>
<version>3.1.0</version>
</dependency>
REST service comsumes/produces JSON.
Why is the WADL/xml generation ending up in nullpointer exception? What could be the mistake(s) we are making?

I had the same issue on Wildfly 10.1.0.
I fixed it by using resteasy-wadl 3.0.19 as all other resteasy libraries have this version on Wildfly 10.1.0.
I also had to exclude the resteasy-jaxrs library in the pom, else the resteasy-jaxrs library was included in my war, causing the issue:
<!-- https://mvnrepository.com/artifact/org.jboss.resteasy/resteasy-wadl -->
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-wadl</artifactId>
<version>3.0.19.Final</version>
<exclusions>
<exclusion>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-jaxrs</artifactId>
</exclusion>
</exclusions>
</dependency>
Also, if you use another version than the version of the resteasy libraries already installed in your JBoss, these resteasy libraries (resteasy-jaxrs...) will be installed a second time as dependency of the resteasy-wadl library. These duplicate libraries seem to cause lots of conflicts.

Related

WebLogic changes the url-pattern of RESTful

After deploying my war file, Weblogic changes the url-pattern, which i've defined in web.xml for my Jersey RESTful. As you can see, I want to access my service under /rest/* but weblogic changes it to /resources/*. Where can I configure it for WebLogic?
<servlet>
<servlet-name>jersey-serlvet</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>ch.ni.service</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>jersey-serlvet</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
p.s it works with tomcat, as desired
I ran into a similar problem moving an application from Glassfish 3 to Weblogic 12.2.1. I finally caved in and followed the Jersey tutorial here.
I used the web.xml that was generated in the example to fix the code I was working on.
Short answer is I had to change the web.xml servlet definition to look like:
<servlet>
<servlet-name>Jersey Web Application</servlet-name>
<servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>jersey.config.server.provider.packages</param-name>
<param-value>your.package.with.JAXRS.resources</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Jersey Web Application</servlet-name>
<url-pattern>/webservices/*</url-pattern>
</servlet-mapping>
I also took the dependencies from the POM in the example and used them in my POM.
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet-core</artifactId>
<version>2.24</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-moxy</artifactId>
<version>2.24</version>
</dependency>
Hope it helps.

How to change default opened file when running web application in eclipse?

I have created a new Maven web application in eclipse, and it gave me a Hello World example written in a file named index.jsp located in src/main/webapp.
Let's say I have created a facelet (login.xhtml) and I want my application to run it as default page, instead of the index.jsp page.
I would like to know how and where to change the default value of the file which is lanched.
Thanks in advance.
First of all, you need add support to JSF (maybe not) and facelets in your project if you.
<!-- JSF -->
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>${jsf.version}</version>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>${jsf.version}</version>
</dependency>
<dependency>
<groupId>com.sun.facelets</groupId>
<artifactId>jsf-facelets</artifactId>
<version>${facelets.version}</version>
</dependency>
You can just add a facelets library, such as Prime Faces.
Config your web.xml, add something like this:
<!-- Faces Servlet -->
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<!-- Faces Servlet Mapping -->
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.jsf</url-pattern>
</servlet-mapping>
<!-- Use Documents Saved as *.xhtml -->
<context-param>
<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
<param-value>.xhtml</param-value>
</context-param>
<!-- Special Debug Output for Development -->
<context-param>
<param-name>facelets.DEVELOPMENT</param-name>
<param-value>true</param-value>
</context-param>
After this, you'll need change welcome-file-list in your web.xml:
<welcome-file-list>
<welcome-file>login.jsf</welcome-file>
</welcome-file-list>
If you are using facelets, so you'll need to create a faces-config.xml file, like this:
<faces-config>
<application>
<view-handler>com.sun.facelets.FaceletViewHandler</view-handler>
</application>
</faces-config>
Read more about here.

Jersey 2.1 + JBoss 7.1 NoSuchMethodError: getProperties

I am trying to run Jersey 2.1 REST service on JBoss 7.1 AS. I am getting the NoSuchMethodError: javax.ws.rs.core.Application.getProperties error during deployment:
ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/RESTService]] (MSC service thread 1-9) StandardWrapper.Throwable: java.lang.NoSuchMethodError: javax.ws.rs.core.Application.getProperties()Ljava/util/Map;
at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:271) [jersey-server-2.1.jar:]
at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:283) [jersey-container-servlet-core-2.1.jar:]
In pom.xml I have:
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>2.1</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-client</artifactId>
<version>2.1</version>
</dependency>
And in the web.xml:
<servlet>
<servlet-name>RESTService</servlet-name>
<servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>javax.ws.rs.Application</param-name>
<param-value>com.gatekeeper.restservice.RESTApplication</param-value>
</init-param>
<init-param>
<param-name>com.sun.jersey.api.json.POJOMappingFeature</param-name>
<param-value>true</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
Previously I tried with Jersey 1.17.1 and it worked (after disabling resteasy scan and jaxrs extension/subsystem in JBoss). So far I've found one similar post (but with Tomcat) where the conslusion was that the wrong javax.ws.rs.core.Application is being bound at runtime, and further that the bound class is an "old" (JAX-RS 1.1) version.
Any help how to resolve this? I'm .net guy and I'm totally blind in java :)
Thanks
Bartek
I know this thread is not that fresh, but still, I only hit this problem yesterday and nothing seems to work.
My scenario is very similar: Jersey 2.23.1 REST App (JAX-RS 2.x) already running on tomcat and need to run on JBoss 7.1.1 (built-in JAX-RS 1.1).
Turn off Restease package scanning in your web.xml:
<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>
Remove all tags with "jaxrs" from standalone.xml. Otherwise you will still face LinkageError because JBoss keeps 1.1 spec on.
Create yourApp.war!WEB-INF\jboss-deployment-structure.xml just like is pointed out here: https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7#ClassLoadinginAS7-JBossDeploymentStructureFile
This way, not only:
java.lang.NoSuchMethodError: javax.ws.rs.core.Application.getProperties()Ljava/util/Map;
Disapears, but also, JAXB works fine (No ClassNotFoundException for javax.xml.bind.JAXBException once module javax.xml.bind.api is also activated).
Obs1: The original question is mixing jersey 1.x with jersey 2.x. There is no PojoMappingFeature in jersey 2.x and base package is org.glassfish.jersey. Take a look at https://jersey.java.net/documentation/latest/migration.html#mig-1-x-json
Obs2: I have also tried other approaches like extending ResourceConfig and scanning packages from there or registering classes directly. Nothing worked like the proper documentation in item 3. So kept my servlet untouched:
<servlet>
<servlet-name>WebNize REST Service</servlet-name>
<servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>jersey.config.server.provider.packages</param-name>
<param-value>br.com.webnize.rest.service</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>WebNize REST Service</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
I hope it helps others!
In short, significant structural changes have been made between 1.17 and 2.2 of the Jersey implementation. You need to:
1) Extend your application class from "org.glassfish.jersey.server.ResourceConfig"
2) Add the packages line within the application class constructor, like so:
public class MyApplication extends ResourceConfig {
public MyApplication() {
packages("com.mysite.MyApplication");
}
}
3) Within web.xml, you'll need to update a number of places. See below:
<servlet-name>Jersey REST Service</servlet-name>
<servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>javax.ws.rs.Application</param-name>
<param-value>com.mysite.MyApplication</param-value>
</init-param>
4) Deploy and have fun.
Additionally, it seems that the practice of using wildcards within the java source is deprecated.
Not this)
#Path("/v1/status/*")
But this)
#Path("/v1/status")
An improvement, IMHO.

Deployment Error for module in GlassFish Server 3.1.2

I found the same question asked previously here but I didn't found the suitable answer. I am designing my web in JSF2.0 with PrimeFaces 3.5 as a JSF component suite. Below is the error coming while automatic deploy is in process-
Below is the error which is coming while restarting the GlassFish Server 3.1.2 (As automatic deploy is not working so i thought of restarting it)-
Below is the error displayed by GlassFish Server 3.1.2 in Eclipse console-
SEVERE: service exception
java.lang.NullPointerExceptionnull at java.lang.String.replace(String.java:2219)null at com.sun.enterprise.v3.common.PropsFileActionReporter.setMessage(PropsFileActionReporter.java:67)null at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:219)null at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)null at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)null at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)null at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)null at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)null at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)null at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)null at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)null at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)null at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)null at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)null at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)null at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)null at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)null at com.sun.grizzly.ContextTask.run(ContextTask.java:71)null at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)null at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)null at java.lang.Thread.run(Thread.java:679)null
My web.xml looks like below-
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
id="portal" version="3.0">
<display-name>Portal</display-name>
<!-- Change to "Production" when you are ready to deploy -->
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</context-param>
<context-param>
<param-name>primefaces.THEME</param-name>
<param-value>cupertino</param-value>
</context-param>
<context-param>
<param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name>
<param-value>true</param-value>
</context-param>
<!-- Primefaces file upload -->
<!-- thresholdSize specifies the maximum file size in bytes to keep uploaded
files in memory. If it exceeds this limit, it’ll be temporarily written to
disk. -->
<!-- uploadDirectory is the folder where to keep temporary files that exceed
thresholdSize. -->
<filter>
<filter-name>PrimeFaces FileUpload Filter</filter-name>
<filter-class>org.primefaces.webapp.filter.FileUploadFilter</filter-class>
<init-param>
<param-name>thresholdSize</param-name>
<param-value>51200</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>PrimeFaces FileUpload Filter</filter-name>
<servlet-name>Faces Servlet</servlet-name>
</filter-mapping>
<context-param>
<param-name>uploadDirectory</param-name>
<param-value>/opt/upload/</param-value>
</context-param>
<welcome-file-list>
<welcome-file>index.xhtml</welcome-file>
</welcome-file-list>
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>30</session-timeout>
</session-config>
</web-app>
I am using Eclipse Indigo on Ubuntu 10.04.4 LTS.

Deploying a Jersey webapp on Jboss AS 7

Currently running some webapps on Jboss AS 4/5 and I am testing migration to jboss7. When I try to deploy a jersey based webapp on JBoss AS 7 (full profile with standalone-preview config file), I get:
org.jboss.as.server.deployment.DeploymentUnitProcessingException: Only one JAX-RS Application Class allowed.
I've done a bit of hunting around on it and found that RestEasy is the default JAX-RS implementation embedded into Application Server. Posts like http://community.jboss.org/message/579996 and https://issues.jboss.org/browse/JBAS-8830) mention that the RestEasy deployer takes over.
In AS 6, it seems easier to remove the deployer whereas I have not seen any solutions for AS 7.
it has already been mentioned in this post : https://community.jboss.org/message/744530#744530 , you can just ask the resteasy module to not scan for other JAX RS implementations in your webapp; just add this to your web.xml :
<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>
worked fine for me
Besides removing the entire jaxrs subsystem in standalone.xml as mentioned in the other posts excluding the RESTEasy modules in jboss-deployment-structure.xml may also work.
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
<deployment>
<exclusions>
<module name="org.jboss.resteasy.resteasy-atom-provider" />
<module name="org.jboss.resteasy.resteasy-cdi" />
<module name="org.jboss.resteasy.resteasy-jaxrs" />
<module name="org.jboss.resteasy.resteasy-jaxb-provider" />
<module name="org.jboss.resteasy.resteasy-jackson-provider" />
<module name="org.jboss.resteasy.resteasy-jsapi" />
<module name="org.jboss.resteasy.resteasy-multipart-provider" />
<module name="org.jboss.resteasy.async-http-servlet-30" />
</exclusions>
</deployment>
</jboss-deployment-structure>
Also check out
JBoss Deployment Structure File
Implicit module dependencies for deployments
I believe the correct approach is to use app server agnostic JAX-RS application deployment. No need to mess with any JBoss configuration. All you need is, extend javax.ws.rs.core.Application in your JAX-RS web application. You can find an example here. Then, you need to put this in your web.xml.
<servlet>
<servlet-name>Jersey Web Application</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>jersey.MyApplication</param-value>
</init-param>
<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>
<load-on-startup>1</load-on-startup>
</servlet>
Package scanning mechanism does not work correctly on JBoss 7.x. I have tested this approach successfully in JBoss 7.0.2.Final and JBoss 7.1.1.Final.
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<exclude-subsystems>
<subsystem name="jaxrs" />
</exclude-subsystems>
</deployment>
</jboss-deployment-structure>
Will do the trick, works great with 7.3AS.ctomc just missed a tiny slash in the end to terminate the section.:-)
I managed to run Jersey WS on my JBOSS AS7.
What i do for JBOSS is just remove everything related to jax-rs in standalone.xml
My jersey sample code got from:
http://www.ibm.com/developerworks/web/library/wa-aj-tomcat/
The only thing i do for the jersey is remove the init-param from web.xml and copy jersey lib to WebContent/WEB-INF/lib.
<!--<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>sample.hello.resources</param-value>
</init-param>-->
In web.xml file add the files
<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>
and comment out the init-param
<!-- <init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value></param-value>
</init-param> -->
This worked out for me in jboss-as-7.1.1.Final and i did not do any changes in standalone.xml.
Ahother option:
Edit standalone/configuration/standalone.xml and comments out all jaxrs entries. This will configure Jersey instead of RESTEasy.
Remove jboss-web.xml from WEB-INF/web.xml. This file no longers works with JBoss 7
Edit web.xml, add an init-param com.sun.jersey.config.property.packages configured to your resource's package, like:
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>org.foo</param-value>
</init-param>
https://github.com/Atmosphere/atmosphere/wiki/Deploying-Atmosphere-Jersey-in-JBoss-7.1.x
You can get past this in the standalone configuration by modifying configuration/standalone.xml and removing references to jaxrs in the extensions and profile section. Note, even though I commented those portions out in my standalone.xml, JBoss will automagically remove those references altogether on next startup...
Here is what worked for me for JBoss 7.1.1 and Jersey 1.17.1. No need to modify standalone.xml or domain.xml. Besides filtering restEasy in web.xml instruct Jersey to use Jackson. You can read about this configuration here.
To save time in configuration guesses, I am posting web.xml and pom.xml from test project.
web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0">
<display-name>TestJerseyonJBoss</display-name>
<servlet>
<servlet-name>Jersey REST Service</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>com.test.rest</param-value>
</init-param>
<init-param>
<param-name>com.sun.jersey.api.json.POJOMappingFeature</param-name>
<param-value>true</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Jersey REST Service</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
<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>
</web-app>
pom.xml
<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>TestJerseyOnJBoss</groupId>
<artifactId>TestJerseyOnJBoss</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>war</packaging>
<build>
<sourceDirectory>src</sourceDirectory>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.3</version>
<configuration>
<warSourceDirectory>WebContent</warSourceDirectory>
<failOnMissingWebXml>false</failOnMissingWebXml>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-bundle</artifactId>
<version>1.17.1</version>
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-json</artifactId>
<version>1.17.1</version>
</dependency>
<dependency>
<groupId>asm</groupId>
<artifactId>asm</artifactId>
<version>3.3.1</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
</dependencies>
You should exclude jaxrs subsystem from being activated for your deployment
add this into META-INF/jboss-deployment-structure.xml
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<exclude-subsystems>
<subsystem name="jaxrs" />
</exclude-subsystems>
<deployment>
</jboss-deployment-structure>
or you can go to standalone.xml and remove subsystem there.
To do so, you need to remove
<subsystem xmlns="urn:jboss:domain:jaxrs:1.0">
...
...
<subsystem>
part of configuration, extension part of on top can stay it wont hurt either way.
or you can connect to server with CLI and run
/subsystem=webservices:remove()
Just a note, exclude-subsystems functionality and deployment-strucure:1.2 was added in 7.1.2 and as such will not work on on 7.1.1.