Jersey is a REST framework that provides JAX-RS Reference Implementation and more.

In attachments you can see a project which uses: Jersey, Weld, Jetty and jersey bean validation module.

The problem is, when I've upgraded Jersey from 2.14 to 2.23.1 my custom exception mapper:

@Provider
public class ValidationExceptionMapper implements
        ExceptionMapper<ValidationException> {

    @Override
    public Response toResponse(ValidationException exception) {
        final ResponseEntity resp = ResponseEntity.builder()
.message("Hurray, my custom ValidationExceptionMapper was called!")
.build();

        return Response.status(Status.BAD_REQUEST).entity(resp).build();
    }
}

is no longer called - Jersey uses the built-in exception mapper for this exception: org.glassfish.jersey.server.validation.internal.ValidationExceptionMapper and unfortunately I cannot override it.

The problem is strictly related to the Weld integration. Because without dependency to Weld, my custom exception mapper has a higher priority than the one provided by jersey-bean-validation module.

Environment

Windows 7/ Ubuntu 16.04 Oracle JDK 1.7.0_75 Jetty 9.2.13.v20150730 Any Jersey version above 2.14

Affected Versions

[2.23.1]

Simple is a high performance HTTP server for the Java platform. A container has been implemented for Jersey similar to the existing Grizzly container. Simple offers the following benefits as a Jersey contribution.

1. Currently benchamarks at about twice as fast as Grizzly, Jetty, and AsyncWeb

http://www.simpleframework.org/performance/grizzly/run1/ScalabilityApacheBench.png http://www.simpleframework.org/performance/grizzly/run2/ScalabilityApacheBench.png

2. Supports the full set of HTTP capabilities, including integrated multipart uploads, 100 continue, cookies, sessions, HTTP/1.0, HTTP/1.1, HTTPS

3. Build around NIO so has very low latencies

http://www.simpleframework.org/performance/grizzly/run1/LatencyApacheBench.png http://www.simpleframework.org/performance/grizzly/run2/LatencyApacheBench.png

A full test suite for the connector is also required.

Environment

Operating System: All Platform: All URL: http://www.simpleframework.org

We have a custom MessageBodyWriter in our application for serializing DTO objects to XML in output stream

We have a custom MessageBodyWriter in our application that produces data of Media type application/xml.As we know Jersey 2.x has an algorithm(https://jersey.java.net/documentation/latest/message-body-workers.html#mbw.writer.selection.algorithm) that chooses a suitable MBR from a list of internal and custom MessageBodyWriters to persist entity into output buffer.The algorithm sorts MBR is based upon Object type distance and media type distance.So our Custom MBR is not getting invoked as we saw in the Jersey common code (MessageBodyFactory.getMessageBodyWriter())that our Custom Writer is at the below in the list and some other provider whose isWriteable() method returns true getting invoked.Further based on media type sorting our writers gets priority as we have mentioned media type as "application/xml" ,but in terms of Object type distance the priority gets lower as the DTO objects to be persist has long distance from Object super class .Eventually our Custom writer sits below in the list of writer providers and other JAXB providers like (specifically XmlRootElementJaxbProvider) gets priority and as its isWriteable() returns true so this provider (XmlRootElementJaxbProvider) gets called

The question is how can we force Jersey to invoke custom MessageBodyWriters ??Should we try adding a custom media type(like application/vnd.xml) to force it to call our Custom MessageBodyWriters ??

Environment

Glassfish 4.1

Affected Versions

[2.10]

There doesn't seem to be a way to pass information into the Application that unit tests launch. I looked at https://jersey.java.net/documentation/latest/user-guide.html#test-framework and this use-case was not covered.

For example, I am trying to pass a ServletContext attribute to the JAX-RS application in order to indicate which HK2 dynamic configuration should be bound at runtime. Unit tests bind to mock implementations whereas in production I bind to real implementations.

Affected Versions

[2.4.1]

Name of "vfsfile" protocol has been changed to "vfs" in Jboss-7 but VfsSchemeScanner is mapped to vfsfile and vfszip protocols.

So because of this I'm getting error when jersey tries to scan my rest resources during jboss startup:

01:01:25,195 ERROR (MSC service thr) [             [/ScoreCard]] StandardWrapper.Throwable: com.sun.jersey.core.spi.scanning.ScannerException: The URI scheme vfs of the URI vfs:/D:/views/third-party/jboss/jboss-as-7.0.1.Final/standalone/deployments/ScoreCard.ear/ScoreCard.war/WEB-INF/classes/com/lex
/scoreCard/web/rest/ 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)
        at com.sun.jersey.api.core.ScanningResourceConfig.init(ScanningResourceConfig.java:78)
        at com.sun.jersey.api.core.PackagesResourceConfig.init(PackagesResourceConfig.java:116)
        at com.sun.jersey.api.core.PackagesResourceConfig.<init>(PackagesResourceConfig.java:81)
        at com.sun.jersey.api.core.PackagesResourceConfig.<init>(PackagesResourceConfig.java:92)
        at com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:677)
        at com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:655)
        at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:206)
        at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:342)
        at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:516)
        at javax.servlet.GenericServlet.init(GenericServlet.java:242)
        at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1202)
        at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1102)
        at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3631)
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:3844)
        at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
        at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)

Can we add additional "vfs" protocol to VfsSchemeScanner?

Affected Versions

[1.4]

The closest existing report that I could find was on nabble: http://jersey.576304.n2.nabble.com/Jersey-truncating-the-slashes-from-the-uploaded-file-name-td5984041.html

IE sends non-standard conforming (bug surrise, eh?) filename: -----------------------------7db13314200d0 Content-Disposition: form-data; name="file"; filename="C:\tmp\Ext.js" Content-Type: application/octet-stream

What my application gets when reading the filename is "C:tmpExt.js"

Apparently (from reading the forum thread mentioned above) this bug has been around since Jersey 1.3 at least.

Affected Versions

[1.8]

In version 1.0.3.1 when I configured the com.sun.jersey.spi.container.servlet.ServletContainer in the web.xml with a url-pattern of *.ui I was able to access that service; however in the latest version 1.1.5, that functionality appears broken.

The following code replicates the problem.

1. 1. 1. web.xml

SimpleMVNREST

We have desirable behavior that we want to implement, such as returning location headers on creation of entities. Currently, the only way I see to do this is to customize the WebResource. This requires making the current package level constructor public. For now, I have to cheat and have a com.sun.jersey.api.client in our project, that can then trick the compiler into allowing access.

Environment

Operating System: All Platform: Macintosh

I submitted this feature request to the JAX-RS API repository and Mr. Karg suggested that it should first be implemented by one of the vendors before it can be taken into consideration as a Specification standard.

What do you think of it? Would you see potential in such a feature?

We detected memory leak in response.readEntity.

When we use "response.readEntity(String.class)", there were not memory leak. But when we use "MediaType.TEXT_XML" and "response.readEntity(ErrorBean.class);", then memory leak was occurred.

The following table is the result of 'jstat -gcutil' when memory full is occurred.

| S0 | S1 | E | O | P | YGC | YGCT | FGC | ... | | 0.00 | 0.00 | 98.78 | 99.96 | 99.36 | 10975 | 176.220 | 2665 | ... | | 0.00 | 0.00 | 100.00 | 99.96 | 99.36 | 10975 | 176.220 | 2666 | ... | | 0.00 | 0.00 | 100.00 | 99.96 | 99.36 | 10975 | 176.220 | 2666 | ... |

And the following is the problematic codes. They are called in JAX-RS Resource deployed on tomcat7.

Client client = ClientBuilder.newClient();
WebTarget target = client.target("http://xxxx.xxx"); Invocation.Builder invocationBuilder = target.request(MediaType.TEXT_XML);
try {
  response = invocationBuilder.post(Entity.entity("<test><id>1234</id></test>", MediaType.TEXT_XML));
  ErrorBean err = response.readEntity(ErrorBean.class);
} catch(Exception e) {
  // handle Exception } finally {
  if (response != null) {
    response.close();
  }
}

@XmlRootElement(name = "error")
public class ErrorBean {	
	private String code;
	private String message;
	private String resource;

	public ErrorBean() {}

	public String getCode() {
		return code;
	}

	public void setCode(String code) {
		this.code = code;
	}

	public String getMessage() {
		return message;
	}

	public void setMessage(String message) {
		this.message = message;
	}

	public String getResource() {
		return resource;
	}

	public void setResource(String resource) {
		this.resource = resource;
	}
}

Environment

OS : Ubuntu 13.10 64bit WAS : apache-tomcat-7.x JDK : jdk1.7.0_45

Affected Versions

[2.7]

The new jersey-spring3 module expects an XML based spring configuration. I'm able to work around the issue when running the application by having the following WebApplicationInitializer:

public class MyServiceWebAppInitializer implements WebApplicationInitializer {

    @Override
    public void onStartup(ServletContext container) {
        AnnotationConfigWebApplicationContext rootContext = new AnnotationConfigWebApplicationContext();
        rootContext.register(MyServiceSpringConfig.class);
        container.addListener(new ContextLoaderListener(rootContext));
        container.addListener(new RequestContextListener());

        // The following line is required to avoid having jersey-spring3 registering it's own Spring root context.
        container.setInitParameter("contextConfigLocation", "");
    }
}

The last line makes jersey-spring3 skip initializing a new spring context in SpringWebApplicationInitializer (GitHub).

When writing integration tests that extends from JerseyTest, however, this doesn't work. Using @RunWith(SpringJUnit4ClassRunner.class) and supplying my config class to @ContextConfiguration, jersey-spring3 still tries to initialize a ClassPathXmlApplicationContext in SpringComponentProvider (GitHub), and fails because the default applicationContext.xml file isn't found.

Example code:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = MyServiceSpringConfig.class)
public class MyIntegrationTest extends JerseyTest {

    @Override
    protected Application configure() {
        return new MyServiceJerseyConfig();
    }

    @Test
    public void someTest() throws Exception {
        // Very useful test
    }
}

The MyServiceJerseyConfig class:

@ApplicationPath("webapi")
public class MyServiceJerseyConfig extends ResourceConfig {
    public MyServiceJerseyConfig() {
        packages("com.acme.myservice");
    }
}

Environment

Spring 3.2.3, Jersey 2.2-SNAPSHOT

Affected Versions

[2.2]

After upgrading from Jersey 2.37 to 2.38, my project's main sources started building against JUnit Jupiter which is now getting pulled in as a transitive dependency of jersey-media-multipart. The JUnit dependency in the pom for jersey-media-multipart is missing <scope>test</scope>.

The pom for jersey-media-multipart 2.38 has this:

        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
        </dependency>

The pom for jersey-media-multipart 2.37 is also missing test scope:

        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
        </dependency>

Even though "test" scope is missing in 2.37, this problem was not visible in 2.37 because dependencyManagement for org.glassfish.jersey:project forced test scope:

            <dependency>
                <groupId>junit</groupId>
                <artifactId>junit</artifactId>
                <version>4.13.1</version>
                <scope>test</scope>
            </dependency>

In 2.38, dependencyManagement for org.glassfish.jersey:project now imports the JUnit BOM (which is good):

            <dependency>
                <groupId>org.junit</groupId>
                <artifactId>junit-bom</artifactId>
                <version>${junit5.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>

So, now that the JUnit BOM is imported, any projects missing "test" scope for junit-jupiter need to be corrected. I noticed this for jersey-media-multipart but didn't check if any other Jersey modules also have the same issue.

As a workaround, I have to force an exclusion in my project's pom:

        <dependency>
            <groupId>org.glassfish.jersey.media</groupId>
            <artifactId>jersey-media-multipart</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>org.junit.jupiter</groupId>
                    <artifactId>junit-jupiter</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

It looks like the current release has a dependency on a version of jackson-databind that's reporting a CVE:

https://mvnrepository.com/artifact/org.glassfish.jersey.media/jersey-media-json-jackson/3.1.0

We've worked around it via a Maven exclusion and import of the latest jackson-databind but want to report it. (A search didn't turn up any open issues, apologies if this is already known/reported.)

https://github.com/eclipse-ee4j/jersey/blob/86ea75573f8bd007a6f28d961a920fee751fbfd7/docs/src/main/docbook/rx-client.xml#L806 %gt; is wrong. Unfortunately I cannot provide a solution due to licensing issues.

The JAX-RS URL matching is broken by design, because it treats URL with and without trailing slash as equivalent, as evidenced in https://github.com/jakartaee/rest/issues/468. The JAX-RS contributors seem to be unwilling to address this elephant in the room.

Could Jersey implement a config property to toggle this behavior off?