Jersey 2.1 + JBoss 7.1 NoSuchMethodError: getProperties
Asked Answered
L

3

6

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

Landfall answered 11/8, 2013 at 20:22 Comment(0)
P
0

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.

Phenol answered 23/8, 2013 at 13:25 Comment(0)
R
1

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).

  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>
    
  2. Remove all tags with "jaxrs" from standalone.xml. Otherwise you will still face LinkageError because JBoss keeps 1.1 spec on.

  3. 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!

Roberto answered 8/7, 2016 at 18:50 Comment(0)
P
0

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.

Phenol answered 23/8, 2013 at 13:25 Comment(0)
P
-1

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.

Phenol answered 23/8, 2013 at 13:52 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.