[JERSEY-2815] Add support for Optional from Java 8 into Jersey Created: 04/Mar/15  Updated: 04/Mar/15

Status: Open
Project: jersey
Component/s: extensions
Affects Version/s: 2.16
Fix Version/s: backlog

Type: New Feature Priority: Major
Reporter: Michal Gajdos Assignee: Michal Gajdos
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

We're currently able to support some of the types from Java 8 in Jersey (extension module). Create infrastructure for this extension module and add support for Optional (entity, param).






[JERSEY-2814] Imporve JDK container to take custom SSLContext Created: 03/Mar/15  Updated: 05/Mar/15  Resolved: 05/Mar/15

Status: Resolved
Project: jersey
Component/s: containers
Affects Version/s: 2.16
Fix Version/s: 2.17

Type: Improvement Priority: Major
Reporter: Adam Lindenthal Assignee: Adam Lindenthal
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Originally reported internally by Luk Ho.

The JDK Container currently does not allow user to set custom SSLContext, like Grizzly2 and Simple severs do.
E.g. GrizzlyHttpServerFactory.createHttpServer(..., SSLEngineConfigurator)
Please improve JDK Container so that all the containers supported by Jersey provides the same functionality.



 Comments   
Comment by Adam Lindenthal [ 05/Mar/15 ]

Fixed in 2.17.

JdkHttpServerFactory was enhanced with some new overloaded createHttpServer methods that accept SSLContext or HttpsConfigurator.





[JERSEY-2813] The RxObservableInvoker swallows errors such as 404 NotFound Created: 03/Mar/15  Updated: 04/Mar/15

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.16
Fix Version/s: None

Type: Bug Priority: Major
Reporter: grro Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The RxObservableInvoker (jersey-rx-client-rxjava-2.16) swallows errors such as 404 NotFound. See example below

RxClient<RxObservableInvoker> restClient = Rx.newClient(RxObservableInvoker.class);       

restClient.target("http://localhost:8089/DoesNotExitAndReturnsA404Error")
          .request()                 
          .rx()
          .get(byte[].class)
          .onErrorReturn(error -> new byte[] { 12, 34, 45, 65 })
          .forEach(data -> System.out.println("data size " + data.length));
	     
 > data size 0

In contrast the RxCompletionStageInvoker (jersey-rx-client-java8-2.16 ) will not ignore the error

RxClient<RxCompletionStageInvoker> restClientCompletable = Rx.newClient(RxCompletionStageInvoker.class);

restClientCompletable.target("http://localhost:8089/DoesNotExitAndReturnsA404Error")
                     .request()                 
                     .rx()
                     .get(byte[].class)                              
                     .exceptionally(error -> new byte[] { 12, 34, 45, 65 })
                     .whenComplete((data, error) -> System.out.println("data size " + data.length));
        
>  data size 4


 Comments   
Comment by grro [ 04/Mar/15 ]

the corresponding HTTP response of the example is

HTTP/1.1 404 Not Found
Server: Apache-Coyote/1.1
Content-Length: 0
Date: Wed, 04 Mar 2015 04:15:43 GMT




[JERSEY-2812] Thread not released when Jersey configured as a filter Created: 03/Mar/15  Updated: 05/Mar/15

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.16
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: fpoliquin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: containers
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive jersey2812-master.zip    

 Description   

Using the following code:

@GET
@Path("/wait")
public void waitForRessource(@Suspended final AsyncResponse asyncResponse) {
    ...
}

The following configuration works as expected:

    <servlet>
        <servlet-name>jersey</servlet-name>
        <servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
        <init-param>
            <param-name>javax.ws.rs.Application</param-name>
            <param-value>xxx</param-value>
        </init-param>
        <async-supported>true</async-supported>
    </servlet>

But if I configure Jersey using the following configuration:

    <filter>
        <filter-name>jersey</filter-name>
        <filter-class>org.glassfish.jersey.servlet.ServletContainer</filter-class>
        <async-supported>true</async-supported>
        <init-param>
            <param-name>javax.ws.rs.Application</param-name>
            <param-value>xxx</param-value>
        </init-param>
        <init-param>
            <param-name>jersey.config.servlet.filter.forwardOn404</param-name>
            <param-value>true</param-value>
        </init-param>
    </filter>

The thread executing the request is never returned to the container. The thread is stuck with this stack:

Daemon Thread [http-bio-60000-exec-10] (Suspended)
owns: Object (id=9746)
owns: SocketWrapper (id=9731)
Unsafe.park(boolean, long) line: not available [native method]
LockSupport.park(Object) line: not available
AbstractFuture$Sync(AbstractQueuedSynchronizer).parkAndCheckInterrupt() line: not available
AbstractFuture$Sync(AbstractQueuedSynchronizer).doAcquireSharedInterruptibly(int) line: not available
AbstractFuture$Sync(AbstractQueuedSynchronizer).acquireSharedInterruptibly(int) line: not available
AbstractFuture$Sync.get() line: 292
SettableFuture(AbstractFuture).get() line: 116
ResponseWriter.getResponseContext() line: 273
ResponseWriter.getResponseStatus() line: 268
WebComponent$6.get() line: 404
WebComponent$6.get() line: 401
Values$LazyValueImpl.get() line: 340
ServletContainer.doFilter(HttpServletRequest, HttpServletResponse, FilterChain, String, String, String) line: 534
ServletContainer.doFilter(HttpServletRequest, HttpServletResponse, FilterChain) line: 482
ServletContainer.doFilter(ServletRequest, ServletResponse, FilterChain) line: 419
ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 241
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 208
FiltreContexteApplicationWeb.doFilter(ServletRequest, ServletResponse, FilterChain) line: 54
ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 241
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 208
RestRecorderFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 83
ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 241
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 208
StandardWrapperValve.invoke(Request, Response) line: 220
StandardContextValve.invoke(Request, Response) line: 122
StandardHostValve.invoke(Request, Response) line: 170
ErrorReportValve.invoke(Request, Response) line: 103
AccessLogValve.invoke(Request, Response) line: 950
StandardEngineValve.invoke(Request, Response) line: 116
CoyoteAdapter.service(Request, Response) line: 421
Http11Processor(AbstractHttp11Processor).process(SocketWrapper<S>) line: 1070
Http11Protocol$Http11ConnectionHandler(AbstractProtocol$AbstractConnectionHandler).process(SocketWrapper<S>, SocketStatus) line: 611
JIoEndpoint$SocketProcessor.run() line: 316
ThreadPoolExecutor(ThreadPoolExecutor).runWorker(ThreadPoolExecutor$Worker) line: not available
ThreadPoolExecutor$Worker.run() line: not available
TaskThread$WrappingRunnable.run() line: 61
TaskThread(Thread).run() line: not available

This behavior makes the @Suspended annotation basically useless as the whole point of using it is to release the thread.

I'm using Tomcat 7.0.56 with the native Windows binaries.



 Comments   
Comment by Adam Lindenthal [ 03/Mar/15 ]

Hi fpoliquin,

thanks for reporting this issue.
Just to rule out other influences, have you tried to reproduce this on some other container (Jetty, Glassfish, etc)?

The thing is, on the first quick look into the code, the destroy() method in the ServletContainer comes from both servlet and filter classes and should be invoked in both cases.

Could you share a complete minimal example (ideally maven based servlet app with a test narrowed down as much as possible).

Many thanks,
Adam

Comment by fpoliquin [ 03/Mar/15 ]

I did a test case but I don't have the rights to upload the file in JIRA. Is there another place where I can put it?

Comment by Adam Lindenthal [ 03/Mar/15 ]

Hi, that's great.

Unfortunately, we cannot assign you the permission in JIRA, so we usually use other ways to do that. If you have a github account, please upload it there and paste a link here, if not, feel free to send me a zip with soruces via email. In both cases, I will attach it here for you, if you don't mind.

Regards,
Adam

Comment by fpoliquin [ 04/Mar/15 ]

I uploaded my test case to this URL: https://github.com/fpoliquin/jersey2812

Basically, there are 4 URLs:
1. /jersey2812/test/wait This uses the filter configuration and triggers an AsyncResponse
2. /jersey2812/test/broadcast This is used to free all waiting connections
3. /jersey2812/servlet/test/wait Same as above but with a servlet configuration
4. /jersey2812/servlet/test/broadcast Same as above but with a servlet configuration

If you look in the console, you will see that the first URL never releases the thread whereas the third one does it correctly.

Thanks.

Comment by Adam Lindenthal [ 04/Mar/15 ]

Great, thanks for the test case, I have just attached it here.

Comment by Adam Lindenthal [ 05/Mar/15 ]

Hi fpoliquin,

I am moving the issue to backlog, so that we can plan the work on it into one of the future sprints.

Regards,
Adam





[JERSEY-2811] Minor grammatical issue on home page Created: 02/Mar/15  Updated: 02/Mar/15  Resolved: 02/Mar/15

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Trivial
Reporter: mcandre Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

"Jersey provides it’s own API" should be

"Jersey provides its own API"






[JERSEY-2810] InMemory JerseyTest ignore contextPath parameter Created: 02/Mar/15  Updated: 05/Mar/15

Status: Open
Project: jersey
Component/s: test-framework
Affects Version/s: 1.18.1
Fix Version/s: 1.x-backlog

Type: Bug Priority: Major
Reporter: nfalco79 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The context path configured in the WebAppDescriptor.Builder() is ignored by test framework.
With a configured path "test" I expect that for a resource @Path("resources") annotated at class level, requests that matches resource methods start with monospaced

{schema}

://

{host}

:

{port}

/test/resources/...monospaced



 Comments   
Comment by nfalco79 [ 02/Mar/15 ]

:\ issue can not be edited.
The URLs expected are in form:
http://<host>:<port>/test/resources/...

Follow a JUnit

ContextPathTest.java
public class ContextPathTest extends JerseyTest {

	@Path("api/resources")
	public static class ContextPathResource {
		@POST
		@Consumes(MediaType.APPLICATION_JSON)
		@Path("")
		public Response create(Resource resource) {
			return Response.created(null).build();
		}
	}

	@XmlRootElement
	public static class Resource {
		private String name;

		public String getName() {
			return name;
		}

		public void setName(String name) {
			this.name = name;
		}

	}

	@Override
	protected AppDescriptor configure() {
		return new WebAppDescriptor.Builder(this.getClass().getPackage().getName())
				.contextPath("test")
				.build();
	}

	@Test
	public void context_path() {
		Resource res = new Resource();
		res.setName("my resource");

		URI uri = UriBuilder.fromUri(getBaseURI()).path("test").path(ContextPathResource.class, "create").build();

		ClientResponse response = client()
				.resource(uri)
				.post(ClientResponse.class, res);

		Assert.assertEquals(Status.CREATED.getStatusCode(), response.getStatus());
	}
}
Comment by Michal Gajdos [ 02/Mar/15 ]

I guess the expected URL should be rather `http://<host>:<port>/test/api/resources/...` but I see your point. I'll check whether the problem is in 2.x as well and if this is the case then the problem would be fixed there (and hopefully migrated into 1.x).

Comment by nfalco79 [ 02/Mar/15 ]

The expected URL refers to the issue context description.
The JUnit was writing after the issue opened and an "api" in the root resource path was introduced.
I'm sorry for the mismatch.

Comment by nfalco79 [ 03/Mar/15 ]

I think the context path should be part of JerseyTest.getBaseURI(). I would expect the same in the ContextRequest.getBaseUri() received in my ContainerRequestFilter test implementation as happen in a real call.

ContextPathTest.java
public class ContextPathTest extends JerseyTest {

	@Path("api/resources")
	public static class ContextPathResource {
		@GET
		@Consumes(MediaType.APPLICATION_JSON)
		@Path("")
		public Response get() {
			return Response.ok().build();
		}
	}

	public static class FilterFactory implements ResourceFilterFactory {
		class InternalFilter implements ResourceFilter, ContainerRequestFilter {

			@Override
			public ContainerRequestFilter getRequestFilter() {
				return this;
			}

			@Override
			public ContainerResponseFilter getResponseFilter() {
				return null;
			}

			@Override
			public ContainerRequest filter(ContainerRequest request) {
				Assert.assertEquals("/test", request.getBaseUri().getPath());
				return request;
			}

		}

		@Override
		public List<com.sun.jersey.spi.container.ResourceFilter> create(AbstractMethod am) {
			return Collections.<ResourceFilter> singletonList(new InternalFilter());
		}

	}

	@Override
	protected AppDescriptor configure() {
		return new WebAppDescriptor.Builder(ContextPathResource.class.getPackage().getName())
			.contextPath("test")
			.initParam("com.sun.jersey.spi.container.ResourceFilters", FilterFactory.class.getName())
			.build();
	}

	@Test
	public void context_path_resource_filter() {
		URI uri = UriBuilder.fromUri(getBaseURI())/*.path("test")*/.path(ContextPathResource.class).build();

		ClientResponse response = client()
				.resource(uri)
				.type(MediaType.APPLICATION_JSON_TYPE)
				.get(ClientResponse.class);

		Assert.assertEquals(Status.OK.getStatusCode(), response.getStatus());
	}
}
Comment by Adam Lindenthal [ 05/Mar/15 ]

Hi nfalco,

moving this issue to backlog, so that we can plan the work on it for one of the future sprints).

Regards,
Adam





[JERSEY-2809] ClientConfig is ignored by InMemoryTestContainerFactory Created: 02/Mar/15  Updated: 02/Mar/15

Status: Open
Project: jersey
Component/s: test-framework
Affects Version/s: 1.18.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: nfalco79 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Using InMemory jersey test framework the ClientConfig passed in configure method to the

WebAppDescriptor.Builder().clientConfig(cc)

is not used to configure the client that

JerseyTest.client()

returns.
I'm not be able to configure POJO feature so an exception was thrown by client.

com.sun.jersey.api.client.ClientHandlerException: A message body writer for Java class com.example.MyBean, and Java type class com.example.MyBean, and MIME media type application/json was not found





[JERSEY-2808] Nested objected not marshaled when enabled EntityFilteringFeature Created: 27/Feb/15  Updated: 27/Feb/15

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.10, 2.16
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rkorn Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: entity-filtering
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4.1, Jersey 2.10.4 (and 2.16.0)



 Description   

I guest, I've hit a bug with my question on StackOverflow - http://stackoverflow.com/questions/28762909/marshall-nested-objects-with-jersey-using-entityfilter-feature

I have deep nested objects in my domain model (> Level 2) and after enabling EntityFilteringFeature the nested objects dont get marshaled in my json reponse (no matter if using Jackson or Moxy).
Extending the examples at https://github.com/jersey/jersey/tree/master/examples/entity-filtering to contain some deep nested objects should show the issue.






[JERSEY-2807] Glassfish / Jersey throws NPE on startup of versioned app Created: 26/Feb/15  Updated: 27/Feb/15  Resolved: 27/Feb/15

Status: Resolved
Project: jersey
Component/s: containers
Affects Version/s: 2.10
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: lprimak Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish


Issue Links:
Duplicate
duplicates JERSEY-2626 Glassfish / Jersey throws NPE on star... Open
Tags: version

 Description   

Any GlassFish versioned applications fail on startup.

Here is the original (and seems-to-have forgotten) JIRA issue

https://java.net/jira/browse/JERSEY-2626



 Comments   
Comment by Adam Lindenthal [ 27/Feb/15 ]

Hi Iprimak,

the other issue you opened is still in backlog. Backlog does not mean the issue is closed and won't be revisited, basically every issue ends up there for some time. It is a pool from where we plan the future work based on various priorities.
As far as I understand, this is a 100% duplicate of the other issue.

If you want to remind or ask status, please use the original one.
This one is going to be closed now.

Regards,
Adam





[JERSEY-2806] Jackson serialization exception is sent in response Created: 26/Feb/15  Updated: 02/Mar/15  Resolved: 02/Mar/15

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.16
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jstrom Assignee: Michal Gajdos
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I have a WriterInterceptor which wraps all my JSON responses in a "base response container". During development of this feature I had an issue with Jackson throwing a JsonMappingException. For some reason, this was written to the output stream.

Feb 26, 2015 9:39:20 AM org.glassfish.jersey.test.inmemory.InMemoryTestContainerFactory$InMemoryTestContainer <init>
INFO: Creating InMemoryTestContainer configured at the base URI /api/
Feb 26, 2015 9:39:20 AM org.glassfish.jersey.filter.LoggingFilter log
INFO: 1 * Sending client request on thread main
1 > GET /api/test/jsonGenericList

Feb 26, 2015 9:39:20 AM org.glassfish.jersey.filter.LoggingFilter log
INFO: 2 * Client response received on thread main
2 < 400
2 < Content-Length: 208
2 < Content-Type: text/plain
Incompatible types: declared root type ([collection type; class java.util.List, contains [simple type, class com.example.jersey.test.api.TestResource$Pojo]]) vs com.example.jersey.server.api.ApiResponseRoot

Similar response was observed in regular Jersey container.

The actual exception was due to my resource method returning a value which used generics, and my interceptor did not call ctx.setGenericType(), which caused the above exception. Note that this is not what this issue is about.

The issue is rather that the error goes out to the client, and with status 400 instead of 500. In this case, it doesn't tell too much, but in other cases the information leakage may be worse. IMO a 500 with empty response, and the exception logged, would be more appropriate.

This particular error is thrown in com.fasterxml.jackson.databind.SerializerProvider.java. While googling the error, I noticed similar problems in older Jersey versions: JERSEY-2325. However, here it seems to be a stack trace and not sent as response?

I do not have a complete test case, but here are the important parts:

Response interceptor
@Priority(JerseyPriorities.POST_ENTITY_CODER)
public class ApiResponseInterceptor implements WriterInterceptor {
	@Override
	public void aroundWriteTo(WriterInterceptorContext ctx) throws IOException, WebApplicationException {

		MediaType mt = ctx.getMediaType();
		if(mt.equals(MediaType.APPLICATION_JSON_TYPE)) {
			Object entity = ctx.getEntity();
			ApiResponseRoot root = new ApiResponseRoot(entity);
			ctx.setEntity(root);
			// uncomment this removes the "exception"
			//ctx.setGenericType(ApiResponseRoot.class);
		}
		ctx.proceed();
	}
}
Simplified response wrapper
public final class ApiResponseRoot {
	@JsonInclude(value = JsonInclude.Include.NON_NULL)
	public final Object result;
	public ApiResponseRoot(Object result) {
		this.result = result;
	}
}
Resource which returns a Generics-type
@Path("test")
public class TestResource {
	public static class Pojo {
		public long id = 1;
		public String name = "Test";
	}

	@GET
	@Path("jsonGenericList")
	@Produces("application/json")
	public List<Pojo> jsonGenericList(){
		return Arrays.asList(new Pojo(), new Pojo());
	}
}


 Comments   
Comment by jstrom [ 26/Feb/15 ]

The JacksonFeature installs these:

            // add the default Jackson exception mappers
            context.register(JsonParseExceptionMapper.class);
            context.register(JsonMappingExceptionMapper.class);

Those are the ones responsible for the rendered exception.

Based on their javadocs, I would say they are more made for handling JSON data coming on the request-side, rather than response:

Implementation of ExceptionMapper to send down a "400 Bad Request" in the event unparsable JSON is received.

It makes sense when incoming JSON cannot be mapped, but when outgoing JSON fails to render, I would say it's 500 Internal Server Error, rather than 400 Bad request.

Comment by Michal Gajdos [ 02/Mar/15 ]

Interesting problem and I agree it should be 500. However I don't think this is a problem in Jersey (or any other JAX-RS implementation for that matter). I think this should be fixed in Jackson (so all JAX-RS implementations can profit from that). And the fix in Jackson would require to update the JsonMappingException so that the mapper can definitely decide whether the response should be 400 or 500. Now even if we decided to not register that handler and write our own for JsonMappingException we couldn't do it because of the fact that the exception is not specific enough about the response we should throw.

Comment by Michal Gajdos [ 02/Mar/15 ]

I am going to close this issue (won't fix) but feel free to comment (I'll watch it) or reopen it if you still think it's a problem in Jersey.

Comment by Michal Gajdos [ 02/Mar/15 ]

There is a workaround. If you don't want those mappers don't register JacksonFeature from Jersey but register JacksonJaxbJsonProvider from Jackson directly.





[JERSEY-2805] Allow JerseyTest to create client with non-default ClientBuilder Created: 26/Feb/15  Updated: 05/Mar/15

Status: Open
Project: jersey
Component/s: test-framework
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: raybirk Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently, private Client getClient(ClientConfig) always use the default ClientBuilder to create new client. Although we get some flexibility by passing in a clientConfig, not everything can be done through it. For example, it is easier to use HTTPS by using a ClientBuilder with its SslContext customized. Therefore, it would be great to have a way to specify a ClientBuilder to use.



 Comments   
Comment by Adam Lindenthal [ 05/Mar/15 ]

Hi Raybirk,

so if I understand it correctly, all you basically need is the getClient(ClientConfig) method to be proctected, so that you can extend JerseyTest, make your own test base using your customized ClientBuilder?

But could you please describe the use case a bit more? Do you need to create new clients from your custom builder?
Couldn't you just create one configured client and use multiple {{WebTarget}}s of it?

Regards,
Adam

Comment by raybirk [ 05/Mar/15 ]

Hi Adam,

Yes, making getClient(ClientConfig) protected would work. My use case is to test against a server with HTTPS with external container wrapper. I would do this to get the client:

client = ClientBuilder.newBuilder().sslContext(sslContext).hostnameVerifier(hostnameVerifier).build();

I think we cannot change WebTarget to use HTTPS but I may be wrong.

Thanks,
RayBirk





[JERSEY-2804] Release connection with basic non-preemptive authentication Created: 25/Feb/15  Updated: 25/Feb/15

Status: Open
Project: jersey
Component/s: connectors, core
Affects Version/s: 2.16
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: mario.casola Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux ubuntu 13.10, tomcat 7.0.57, jdk 1.7.0_71 64 bit



 Description   

I wanna share my experience about an issue that I encountered. The scenario is the following:

1. jersey client
2. http client connection manager
3. apache connection provider
4. basic non-preemptive authentication

the problem was that in some cases the connection was not released like expected, like the log below shows

2015-02-25 19:26:06.488 DEBUG 13230 --- [nio-8181-exec-9] h.i.c.PoolingHttpClientConnectionManager : Connection released: [id: 0][route: {}->http://localhost:8080][total kept alive: 1; route allocated: 1 of 10; total allocated: 1 of 10]
  • Example that works in both cases, successful http code or not
rootTarget.queryParam("sort", sort + "," + dir)
	.queryParam("size" + Integer.MAX_VALUE)
	.request(MediaType.APPLICATION_JSON_TYPE).get(String.class);
  • Example that works only if the request is unsuccessful
return rootTarget
	.request(MediaType.WILDCARD_TYPE)
	.post(Entity.entity(myobject, MediaType.APPLICATION_JSON_TYPE),
			MyCustomClass.class);
  • Example that doesn't work at all
Response r = null;
try {
	r = idTarget.request(MediaType.WILDCARD_TYPE)
			.put(Entity.entity(myobject, MediaType.APPLICATION_JSON_TYPE));
	if (r.getStatusInfo().getStatusCode() != Status.NO_CONTENT
			.getStatusCode()) {
		throw new InternalServerErrorException(r.getStatusInfo()
				.getReasonPhrase());
	}
} finally {
	if (r != null) {
		try {
			r.close();
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
}

This last example works only if I consume the response body like string. Response.close() doesn't work.

Instead If I change the authentication to preemptive mode everything works fine.

Best regards
Mario Casola






[JERSEY-2803] InternalServerErrorException when using SecurityEntityFilteringFeature with JacksonFeature filtering an object with a DateTime field Created: 24/Feb/15  Updated: 25/Feb/15  Resolved: 25/Feb/15

Status: Resolved
Project: jersey
Component/s: extensions
Affects Version/s: 2.16
Fix Version/s: None

Type: Bug Priority: Major
Reporter: matthewhubble Assignee: Michal Gajdos
Resolution: Duplicate Votes: 0
Labels: entity-filtering
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Running tests on Mac OS X with IntelliJ IDEA Ultimate 14


Issue Links:
Duplicate
duplicates JERSEY-2784 Selectable Entity Filtering doesn't w... Open

 Description   

If you open the "entity-filtering-jersey" example project in the Jersey repository and run the tests, everything passes. However, if you add a DateTime field to the RestrictedEntity class, the Jackson tests in RestrictedResourceTest all fail (the Moxy ones still pass). It seems there is an issue serialising objects using Jackson that have DateTime fields when the SecurityEntityFilteringFeature is registered. The SecurityEntityFilteringFeature for Jackson was added for 2.16, but appears to be broken in this case.

The tests fail with this exception:
javax.ws.rs.InternalServerErrorException: HTTP 500 Request failed.

Applying this diff to the Jersey repository in GitHub (https://github.com/jersey/jersey) on the master branch commit 685713e21831d4842c0d78e8868f1ddbaad6fef9 causes the tests to fail:

diff --git a/examples/entity-filtering-security/pom.xml b/examples/entity-filtering-security/pom.xml
index ebda6cf..c55179f 100644
--- a/examples/entity-filtering-security/pom.xml
+++ b/examples/entity-filtering-security/pom.xml
@@ -47,7 +47,7 @@
     <parent>
         <groupId>org.glassfish.jersey.examples</groupId>
         <artifactId>project</artifactId>
-        <version>2.17-SNAPSHOT</version>
+        <version>2.16</version>
     </parent>
 
     <artifactId>entity-filtering-security</artifactId>
@@ -84,6 +84,11 @@
             <type>pom</type>
             <scope>test</scope>
         </dependency>
+        <dependency>
+            <groupId>joda-time</groupId>
+            <artifactId>joda-time</artifactId>
+            <version>2.7</version>
+        </dependency>
     </dependencies>
 
     <build>
diff --git a/examples/entity-filtering-security/src/main/java/org/glassfish/jersey/examples/entityfiltering/security/domain/RestrictedEntity.java b/examples/entity-filtering-security/src/main/java/org/glassfish/jersey/examples/entityfiltering/security/domain/RestrictedEntity.java
index 448bc43..1766eaf 100644
--- a/examples/entity-filtering-security/src/main/java/org/glassfish/jersey/examples/entityfiltering/security/domain/RestrictedEntity.java
+++ b/examples/entity-filtering-security/src/main/java/org/glassfish/jersey/examples/entityfiltering/security/domain/RestrictedEntity.java
@@ -40,6 +40,8 @@
 
 package org.glassfish.jersey.examples.entityfiltering.security.domain;
 
+import org.joda.time.DateTime;
+
 import javax.annotation.security.DenyAll;
 import javax.annotation.security.PermitAll;
 import javax.annotation.security.RolesAllowed;
@@ -53,6 +55,8 @@ import javax.xml.bind.annotation.XmlRootElement;
 @XmlRootElement
 public class RestrictedEntity {
 
+    private DateTime fooBar;
+
     private String simpleField;
 
     private String denyAll;

Commenting out the DateTime field in RestrictedEntity will cause the tests to pass again. I'm not sure if other objects cause the issue.



 Comments   
Comment by Michal Gajdos [ 25/Feb/15 ]

This is the same issue as JERSEY-2784. Hence closing as duplicate. I should be able to fix it in Jersey 2.17.





[JERSEY-2801] Bug in org.glassfish.jersey.internal.util.ReflectionHelper Created: 21/Feb/15  Updated: 23/Feb/15  Resolved: 23/Feb/15

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.16
Fix Version/s: 2.17

Type: Bug Priority: Major
Reporter: Anthony Ve Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It seems there is a bug in the method getValueOfStringMethodPA. The current code is:

final Method m = c.getDeclaredMethod("valueOf", String.class);
if (!Modifier.isStatic(m.getModifiers()) && m.getReturnType() == c) {
return null;
}
return m;

but I think it should be:

final Method m = c.getDeclaredMethod("valueOf", String.class);
if (Modifier.isStatic(m.getModifiers()) && m.getReturnType() == c) {
return m;
} else {
return null;
}

because with the current code, a method "static AnyType valueOf(String value)" would be returned, even though its return type is invalid.



 Comments   
Comment by Anthony Ve [ 21/Feb/15 ]

Just for the record, it's about lines 776-780 in https://java.net/projects/jersey/sources/code/content/core-common/src/main/java/org/glassfish/jersey/internal/util/ReflectionHelper.java





[JERSEY-2800] Memory Leak when using @BeanParam within HK2 Created: 19/Feb/15  Updated: 25/Feb/15  Resolved: 25/Feb/15

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.16
Fix Version/s: 2.17

Type: Bug Priority: Major
Reporter: nicholas.hagen Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by HK2-245 BuiltActiveDescriptor should override... Closed

 Description   

There are a few similar tickets opened for this, but my investigation led me down a different path, so not sure if they are related or not. We use @BeanParam via field injection:

@Path("/test")
public class TestResource {
    @BeanParam
    protected PagingInfo pagingInfo

    ...

    public static class PagingInfo {
        @QueryParam("limit")
        private Integer limit;
		
        @QueryParam("page")
        private Integer page;
    }
}

It appears as though this instance is getting added to the "ServiceLocatorImpl.allDescriptors" field within HK2 such that after a few hours it has over 250K items (most of which are the paging info descriptors) and eventually OOM.

Digging through the code, it appears that within BeanParamValueFactoryProvider (https://github.com/jersey/jersey/blob/master/core-server/src/main/java/org/glassfish/jersey/server/internal/inject/BeanParamValueFactoryProvider.java#L112) it attempts to lookup the service for the particular BeanParam object class. That eventually calls "ServiceLocatorImpl.internalGetDescriptor" which attempts to compute the key within the "idgCache" using an "IndexedFilter". That eventually calls "ServiceLocatorImpl.getDescriptors" using that "IndexedFilter". Because it is using the "IndexedFilter" it attempts to grab the descriptor via the "descriptorsByAdvertisedContract" map using the name of the BeanParam object class as the key (line 296 of ServiceLocatorImpl). The class name is not within that map and so it returns null all the way back out to the BeanParam factory. As a result, the BeanParam factory adds the class into the service locator via https://github.com/jersey/jersey/blob/master/core-server/src/main/java/org/glassfish/jersey/server/internal/inject/BeanParamValueFactoryProvider.java#L98. The problem there is that the descriptor that gets created only ends up with a single advertised contract which is the scope per the "in(RequestScoped.class)" portion. This occurs within "ServiceLocatorImpl.addConfigurationInternal" method via its call to "getAllContracts".

What appears needs to happen is that the class name should also be set as a contract along with the scope doing one of the following:

// cal to(key) to add the type as a contract
BuilderHelper.activeLink(key).to(key).in(RequestScoped.class).build();
// or just call: descriptor.addContractType(key);

Per the JavaDocs for the activeLink, "The implementation class given will NOT automatically be added to the set of contracts of the

{@link ActiveDescriptor}

".

When I did that above in a local build it seemed to find the references properly and avoid re-adding to the map over and over thus stopping the memory leak. However, I'm not sure that is the expected fix or if there is some incompatibility between HK2 and Jersey. Looking at some of the other open BeanParam/Memory Leak tickets, there was some investigation into issues between the two.



 Comments   
Comment by Jakub Podlesak [ 24/Feb/15 ]

The above suggested fix does not seem to be sufficient. I had to add hashCode and equals method implementation to HK2's BuiltActiveDescriptor in order to get rid of the memory leak.

Going to file a bug report against HK2, so that John could address this.

Comment by Jakub Podlesak [ 24/Feb/15 ]

Hmmm, after a chat with John and some more debugging, it turns out Jersey is the only one to fix. Already submitted an internal review request.

Comment by Jakub Podlesak [ 25/Feb/15 ]

Fixed in the master branch.





[JERSEY-2799] Temporary files created via FileProvider are never deleted Created: 19/Feb/15  Updated: 19/Feb/15  Resolved: 19/Feb/15

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.16
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Michal Gajdos Assignee: Michal Gajdos
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Temporary files created in FileProvider (or in multipart module) are never deleted (or deleted only at JVM shutdown).



 Comments   
Comment by Michal Gajdos [ 19/Feb/15 ]

Users should delete the file manually when they're given a File handle.





[JERSEY-2798] Document performance penality introduced by DataSource Provider Created: 18/Feb/15  Updated: 18/Feb/15

Status: Open
Project: jersey
Component/s: docs, performance
Affects Version/s: 2.16
Fix Version/s: backlog

Type: Task Priority: Major
Reporter: Michael Osipov Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Document that the DataSource implementation used by Jersey is backed by a byte array. That might introduce a huge performance/memory penality when huge data is processed.

In my case, a client can upstream large files (hundreds of megabytes), I requested Jersey to provide a DataSource. Memory exploded. I resorted to an inputStream with a custom InputStreamDataSource in the backend. That sovled the issue.






[JERSEY-2797] Jersey(2.10.4) Entity provider selection algorithm gives less priority to custom providers(MessageBodyWriter) making it not to be invoked Created: 18/Feb/15  Updated: 05/Mar/15

Status: Open
Project: jersey
Component/s: core, media
Affects Version/s: 2.10
Fix Version/s: None

Type: Bug Priority: Major
Reporter: shaswat Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: incomplete
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4.1



 Description   

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 ??



 Comments   
Comment by Michal Gajdos [ 18/Feb/15 ]

How do you register the provider into your application?

Comment by shaswat [ 18/Feb/15 ]

We have decorated our custom MessageBodyWriter with @Provider annotation.
@Provider
@Produces("application/xml")
public class RestDataSourceMessageBodyWriter implements MessageBodyWriter<Object> {

Comment by Michal Gajdos [ 20/Feb/15 ]

Ok, so you're using package scanning to register your provider. In this case Jersey doesn't recognizes your provider as a custom provider and treats it like our providers. Try to add @Priority(1) annotation on top of your provider.

Comment by shaswat [ 23/Feb/15 ]

I added @Priority(1) annotation on top of my MBW .The issue still exist.

@Priority(1)
@Provider
@Produces("application/xml")
public class RestDataSourceMessageBodyWriter implements MessageBodyWriter<Object> {

Comment by shaswat [ 23/Feb/15 ]

I guess we can use Priorities annotation for Interceptors /filters not for MessageBodyWriters .

Comment by shaswat [ 23/Feb/15 ]

Well My custom MBR looks like below
@Provider
@Produces("application/xml")
public class RestDataSourceMessageBodyWriter implements MessageBodyWriter {

if I make my custom MBR more specific like

@Provider
@Produces("application/xml")
public class RestDataSourceMessageBodyWriter implements MessageBodyWriter<UserInfoDTO> {

(Here "UserInfoDTO" is the first DTO object which gets searlized to xml by entity provider) then it works .But we cannot write custom MBR for thousands of DTOs and it has to be any ways.What do you suggest here?

Comment by Adam Lindenthal [ 05/Mar/15 ]

Hi shaswat,

well, if you cannot make your DTOs to extend an abstract class or implement an interface, you might want to try to set the legacy ordering property.





[JERSEY-2796] Calling getClasses() on ResourceConfig breaks example in some cases Created: 17/Feb/15  Updated: 18/Feb/15  Resolved: 18/Feb/15

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.16
Fix Version/s: 2.17

Type: Bug Priority: Major
Reporter: jstrom Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Jersey 2.16, Java 1.7.0_51



 Description   

During a debugging session I added a call to rc.getClasses(), in combination with manually registering a filter. Suddenly, all my requests started giving 404 errors.

The example below demonstrates this on the simple-service example, based on Jersey 2.16:

mvn archetype:generate -DarchetypeArtifactId=jersey-quickstart-grizzly2 \
-DarchetypeGroupId=org.glassfish.jersey.archetypes -DinteractiveMode=false \
-DgroupId=com.example -DartifactId=simple-service -Dpackage=com.example \
-DarchetypeVersion=2.16

Apply patch which demonstrates problem:

  • If I remove either getClasses or register, it works fine.
  • If I call getClasses after register, it works fine.
--- a/src/main/java/com/example/Main.java
+++ b/src/main/java/com/example/Main.java
@@ -4,6 +4,9 @@ import org.glassfish.grizzly.http.server.HttpServer;
 import org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpServerFactory;
 import org.glassfish.jersey.server.ResourceConfig;

+import javax.ws.rs.container.ContainerRequestContext;
+import javax.ws.rs.container.ContainerRequestFilter;
+
 import java.io.IOException;
 import java.net.URI;

@@ -23,6 +26,9 @@ public class Main {
         // create a resource config that scans for JAX-RS resources and providers
         // in com.example package
         final ResourceConfig rc = new ResourceConfig().packages("com.example");
+
+        System.out.println("Loaded with classes "+ rc.getClasses());
+        rc.register(SimpleFilter.class);

         // create and start a new instance of grizzly http server
         // exposing the Jersey application at BASE_URI
@@ -41,5 +47,12 @@ public class Main {
         System.in.read();
         server.stop();
     }
+
+    public static class SimpleFilter implements ContainerRequestFilter {
+        @Override
+        public void filter(ContainerRequestContext crc) throws IOException {
+            System.out.println("in filter");
+        }
+    }
 }

Results:

Running com.example.MyResourceTest
Loaded with classes [class com.example.MyResource]
Feb 17, 2015 6:00:26 PM org.glassfish.grizzly.http.server.NetworkListener start
INFO: Started listener bound to [localhost:8080]
Feb 17, 2015 6:00:26 PM org.glassfish.grizzly.http.server.HttpServer start
INFO: [HttpServer] Started.
Feb 17, 2015 6:00:26 PM org.glassfish.grizzly.http.server.NetworkListener shutdownNow
INFO: Stopped listener bound to [localhost:8080]
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.425 sec <<< FAILURE!

Results :

Tests in error:
  testGetIt(com.example.MyResourceTest): HTTP 404 Not Found





[JERSEY-2795] CopyOnWriteHashMap is not thread safe Created: 17/Feb/15  Updated: 18/Feb/15

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 1.19
Fix Version/s: 1.x-backlog

Type: Bug Priority: Major
Reporter: djasonpenney Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: pull-request
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day


 Description   

Under load, I have noticed the Netflix Zuul router occasionally generates the following message:

Unable to execute RestClient request for URI:http://<omitted>
Caused by: java.lang.NullPointerException
at com.sun.jersey.client.impl.CopyOnWriteHashMap.entrySet(CopyOnWriteHashMap.java:155)
...
at com.netflix.niws.client.http.RestClient.execute(RestClient.java:89)
at com.netflix.client.AbstractLoadBalancerAwareClient.executeOnSingleServer(AbstractLoadBalancerAwareClient.java:116)

Investigation shows that com.sun.jersey.client.impl.CopyOnWriteHashMap.java is not at all thread safe. In the face of concurrent updating, certain readers will retrieve a "null" underlying view object. Second, concurrent updates may be lost.

I recommend rewrite of this class to require a volatile read for concurrent reading as well as full synchronization to protect concurrent writes.



 Comments   
Comment by Michal Gajdos [ 17/Feb/15 ]

Pull Request: https://github.com/jersey/jersey-1.x/pull/15





[JERSEY-2794] Aborted multipart upload leaves non-empty MIME*.tmp tempfile behind Created: 17/Feb/15  Updated: 18/Feb/15

Status: Open
Project: jersey
Component/s: media
Affects Version/s: 2.16
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: mikaelstaldal Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

jetty-9.2.5.v20141112

java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) Server VM (build 25.20-b23, mixed mode)

Linux 3.13.0-45-generic



 Description   

I have a resource method like this:

  @Consumes({MediaType.MULTIPART_FORM_DATA})
  @POST
  public Response upload(@Context UriInfo uriInfo.
             @FormDataParam("text") String foo,
             @FormDataParam("file") InputStream file) {
      // do stuff
  }

This usually works, but if someone upload a large file and the upload is aborted midway, a non-empty temporary file named /tmp/MIME5392929676998476902.tmp (the number varies) is left behind until the JVM is shut down. This is a resource leak which can lead to out of disk space. In this case, my resource method is never invoked (which is fine) and I see this Exception caught by my general ExceptionMapper (which is not OK):

org.eclipse.jetty.io.EofException: Early EOF
        at org.eclipse.jetty.server.HttpInput$3.noContent(HttpInput.java:486) ~[jetty-server-9.2.5.v20141112.jar:9.2.5.v20141112]
        at org.eclipse.jetty.server.HttpInput.read(HttpInput.java:124) ~[jetty-server-9.2.5.v20141112.jar:9.2.5.v20141112]
        at org.glassfish.jersey.message.internal.EntityInputStream.read(EntityInputStream.java:101) ~[jersey-common-2.16.jar:?] 
        at org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$UnCloseableInputStream.read(ReaderInterceptorExecutor.java:301) ~[jersey-common-2.16.jar:?]
        at org.jvnet.mimepull.MIMEParser.fillBuf(MIMEParser.java:440) ~[mimepull-1.9.3.jar:1.9.3]
        at org.jvnet.mimepull.MIMEParser.readBody(MIMEParser.java:216) ~[mimepull-1.9.3.jar:1.9.3]
        at org.jvnet.mimepull.MIMEParser.access$600(MIMEParser.java:68) ~[mimepull-1.9.3.jar:1.9.3]
        at org.jvnet.mimepull.MIMEParser$MIMEEventIterator.next(MIMEParser.java:165) ~[mimepull-1.9.3.jar:1.9.3]
        at org.jvnet.mimepull.MIMEParser$MIMEEventIterator.next(MIMEParser.java:132) ~[mimepull-1.9.3.jar:1.9.3]
        at org.jvnet.mimepull.MIMEMessage.makeProgress(MIMEMessage.java:198) ~[mimepull-1.9.3.jar:1.9.3]
        at org.jvnet.mimepull.MIMEMessage.parseAll(MIMEMessage.java:181) ~[mimepull-1.9.3.jar:1.9.3]
        at org.jvnet.mimepull.MIMEMessage.getAttachments(MIMEMessage.java:106) ~[mimepull-1.9.3.jar:1.9.3]
        at org.glassfish.jersey.media.multipart.internal.MultiPartReaderClientSide.readMultiPart(MultiPartReaderClientSide.java:226) ~[jersey-media-multipart-2.16.jar:?]
        at org.glassfish.jersey.media.multipart.internal.MultiPartReaderServerSide.readMultiPart(MultiPartReaderServerSide.java:91) ~[jersey-media-multipart-2.16.jar:?]
        at org.glassfish.jersey.media.multipart.internal.MultiPartReaderClientSide.readFrom(MultiPartReaderClientSide.java:180) ~[jersey-media-multipart-2.16.jar:?]
        at org.glassfish.jersey.media.multipart.internal.MultiPartReaderClientSide.readFrom(MultiPartReaderClientSide.java:92) ~[jersey-media-multipart-2.16.jar:?]
        at org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$TerminalReaderInterceptor.invokeReadFrom(ReaderInterceptorExecutor.java:259) ~[jersey-common-2.16.jar:?]
        at org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$TerminalReaderInterceptor.aroundReadFrom(ReaderInterceptorExecutor.java:235) ~[jersey-common-2.16.jar:?]
        at org.glassfish.jersey.message.internal.ReaderInterceptorExecutor.proceed(ReaderInterceptorExecutor.java:155) ~[jersey-common-2.16.jar:?]
        at org.glassfish.jersey.spi.ContentEncoder.aroundReadFrom(ContentEncoder.java:127) ~[jersey-common-2.16.jar:?] 
        at org.glassfish.jersey.message.internal.ReaderInterceptorExecutor.proceed(ReaderInterceptorExecutor.java:155) ~[jersey-common-2.16.jar:?]
        at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundReadFrom(MappableExceptionWrapperInterceptor.java:74) ~[jersey-server-2.16.jar:?]
        at org.glassfish.jersey.message.internal.ReaderInterceptorExecutor.proceed(ReaderInterceptorExecutor.java:155) ~[jersey-common-2.16.jar:?]
        at org.glassfish.jersey.message.internal.MessageBodyFactory.readFrom(MessageBodyFactory.java:1075) ~[jersey-common-2.16.jar:?]
        at org.glassfish.jersey.message.internal.InboundMessageContext.readEntity(InboundMessageContext.java:853) ~[jersey-common-2.16.jar:?]
        at org.glassfish.jersey.message.internal.InboundMessageContext.readEntity(InboundMessageContext.java:785) ~[jersey-common-2.16.jar:?]
        at org.glassfish.jersey.server.ContainerRequest.readEntity(ContainerRequest.java:233) ~[jersey-server-2.16.jar:?]
        at org.glassfish.jersey.media.multipart.internal.FormDataParamValueFactoryProvider.getEntity(FormDataParamValueFactoryProvider.java:376) ~[jersey-media-multipart-2.16.jar:?]
        at org.glassfish.jersey.media.multipart.internal.FormDataParamValueFactoryProvider.access$000(FormDataParamValueFactoryProvider.java:87) ~[jersey-media-multipart-2.16.jar:?]
        at org.glassfish.jersey.media.multipart.internal.FormDataParamValueFactoryProvider$FormDataParamValueFactory.provide(FormDataParamValueFactoryProvider.java:203) ~[jersey-media-multipart-2.16.jar:?]
        at org.glassfish.jersey.server.spi.internal.ParameterValueHelper.getParameterValues(ParameterValueHelper.java:81) ~[jersey-server-2.16.jar:?]
        at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$AbstractMethodParamInvoker.getParamValues(JavaResourceMethodDispatcherProvider.java:125) ~[jersey-server-2.16.jar:?]
        at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:158) ~[jersey-server-2.16.jar:?]
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:97) ~[jersey-server-2.16.jar:?]
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389) ~[jersey-server-2.16.jar:?]
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347) ~[jersey-server-2.16.jar:?]
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102) ~[jersey-server-2.16.jar:?]
        at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:303) [jersey-server-2.16.jar:?]
        at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) [jersey-common-2.16.jar:?]
        at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) [jersey-common-2.16.jar:?]
        at org.glassfish.jersey.internal.Errors.process(Errors.java:315) [jersey-common-2.16.jar:?]
        at org.glassfish.jersey.internal.Errors.process(Errors.java:297) [jersey-common-2.16.jar:?]
        at org.glassfish.jersey.internal.Errors.process(Errors.java:267) [jersey-common-2.16.jar:?]
        at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) [jersey-common-2.16.jar:?]
        at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:286) [jersey-server-2.16.jar:?]
        at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1072) [jersey-server-2.16.jar:?]
        at org.gh.jersey.servlet.WebComponent.service(WebComponent.java:399) [jersey-container-servlet-core-2.16.jar:?]
        at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:381) [jersey-container-servlet-core-2.16.jar:?]
        at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:344) [jersey-container-servlet-core-2.16.jar:?]
        at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:221) [jersey-container-servlet-core-2.16.jar:?]
        at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:800) [jetty-servlet-9.2.5.v20141112.jar:9.2.5.v20141112]
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1669) [jetty-servlet-9.2.5.v20141112.jar:9.2.5.v20141112]


 Comments   
Comment by Michal Gajdos [ 18/Feb/15 ]

Thanks for filing this. I am currently looking at one multipart issue (JERSEY-2663) – I'll try to solve this issue with it as well. Moving to backlog for now.





[JERSEY-2793] EntityFiltering with Jackson doesn't work for subclasses Created: 16/Feb/15  Updated: 19/Feb/15

Status: Open
Project: jersey
Component/s: extensions
Affects Version/s: 2.16
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: anna_zhdan Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: entity-filtering
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I've tried using entity filtering feature. Here is my resource class


@Path("users")
@Produces("application/json")
public class Users {

    @GET
    public Entity getUser() {
        return new User("1", "anna", "anna@example.com");
    }

}

In this case entity filtering doesn't work – whatever I pass as "select" parameter, I get only implicit "type" field for my entity
(

{"type":"jetbrains.gap.app.User"}

)
If I change method return type to User everything works fine for me.



 Comments   
Comment by Michal Gajdos [ 18/Feb/15 ]

Moving to backlog for now but I'll try to target the fix for the next version.

Comment by anna_zhdan [ 19/Feb/15 ]

Michal, we've found a warkaround for this in case of returning a single entity:

return Response.ok(new GenericEntity<Entity>(result, entityType))

as I actually have entityType in runtime for this method.
But I have a problem about fixing a case with returning a list of entities (I also know entityType for list elements in runtime). Maybe you know how to deal with this case?





[JERSEY-2792] NPE in JerseyTest.tearDown Created: 15/Feb/15  Updated: 15/Feb/15  Resolved: 15/Feb/15

Status: Resolved
Project: jersey
Component/s: test-framework
Affects Version/s: 2.16
Fix Version/s: 2.17

Type: Bug Priority: Major
Reporter: Michal Gajdos Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: pull-request
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

https://github.com/jersey/jersey/pull/140

To handle cases when tearDown throws an exception and makes exception from setup/test methods swallowed/overwritten.

Really helps with debugging setup problems. In my case corresponding setUp did not complete correctly and old test container was null.






[JERSEY-2791] Add support for micro-benchmarks in Jersey (JMH based) Created: 15/Feb/15  Updated: 18/Feb/15  Resolved: 18/Feb/15

Status: Resolved
Project: jersey
Component/s: test-framework
Affects Version/s: 2.16
Fix Version/s: 2.17

Type: Task Priority: Major
Reporter: Michal Gajdos Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

We currently don't have means to measure performance of local changes easily. This task is aimed to add support for basic, JMH based, benchmark tests to Jersey.

DEMO:

  • Create an example of such a benchmark.





[JERSEY-2790] jaxrs-ri transitively pulls in sources jars, wastes space and increases startup time Created: 14/Feb/15  Updated: 17/Feb/15  Resolved: 17/Feb/15

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.16
Fix Version/s: 2.17

Type: Bug Priority: Major
Reporter: minfrin Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When an attempt is made to depend on jaxrs-ri as below, various sources jars are included transitively.

Due to a bug in maven, it is impossible to filter out these sources files.

<dependency>
<groupId>org.glassfish.jersey.bundles</groupId>
<artifactId>jaxrs-ri</artifactId>
<version>2.16</version>
</dependency>

mvn dependency:tree reveals the sources jars included transitively:

[INFO] +- org.glassfish.jersey.bundles:jaxrs-ri:jar:2.16:compile
[INFO] | +- javax.ws.rs:javax.ws.rs-api:jar:sources:2.0.1:compile
[INFO] | +- org.glassfish.jersey.core:jersey-common:jar:sources:2.16:compile
[INFO] | +- org.glassfish.jersey.media:jersey-media-jaxb:jar:sources:2.16:compile
[INFO] | +- org.glassfish.jersey.core:jersey-client:jar:sources:2.16:compile
[INFO] | +- org.glassfish.jersey.core:jersey-server:jar:sources:2.16:compile
[INFO] | +- org.glassfish.jersey.containers:jersey-container-servlet-core:jar:sources:2.16:compile
[INFO] | - org.glassfish.jersey.containers:jersey-container-servlet:jar:sources:2.16:compile

To fix this, remove the stray dependency on the sources jars.



 Comments   
Comment by Michal Gajdos [ 17/Feb/15 ]

Nice catch. Fixed in master.





[JERSEY-2789] Astral Unicode characters included in uri parts are not properly encoded Created: 13/Feb/15  Updated: 18/Feb/15  Resolved: 18/Feb/15

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.5
Fix Version/s: 2.17

Type: Bug Priority: Major
Reporter: lcsanchez08 Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
clones JERSEY-2293 Astral Unicode characters included in... Resolved

 Description   

The URL encoding algorithm incorrectly iterates over code units (chars) instead of code points (ints). This means that characters in the Basic Multilingual Plane are encoded just fine (http://codepoints.net/basic_multilingual_plane), but characters in the Astral Plane are always incorrectly encoded as %3F%3F.



 Comments   
Comment by Michal Gajdos [ 13/Feb/15 ]

Jersey 2.x clone of JERSEY-2293.





[JERSEY-2788] Stuck in loop in ResourceConfig.scanClasses Created: 12/Feb/15  Updated: 18/Feb/15

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.15, 2.16
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: jstrom Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: osgi, scanning
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Jersey 2.15, and 2bc1fcb
Apache Karaf 3.0.3



 Description   

Hi,
I'm new with Jersey and I'm trying to run a jersey/grizzley based server in the Apache Karaf OSGI container.

In short, I have a resource directory with static files (well, only one so far) in the JAR. When ResourceConfig scans, it gets stuck in an infinite loop on this directory.

In long:

I have a pretty basic project, which fails to load. The relevant code is more or less from the tutorials:

log.info("Hello, starting!");
final ResourceConfig rc = new ResourceConfig().packages("testproject");
return GrizzlyHttpServerFactory.createHttpServer(URI.create(BASE_URI), rc);

I use basic iPOJO component to get something runnable.
In addition, i have a directory with static files under "testproject/www".

During component activation, I get stuck inside createHttpServer forever:

Name: [iPOJO] pool-1-thread-1
State: RUNNABLE
Total blocked: 9  Total waited: 3

Stack trace: 
org.glassfish.jersey.server.ResourceConfig.scanClasses(ResourceConfig.java:905)
org.glassfish.jersey.server.ResourceConfig._getClasses(ResourceConfig.java:849)
org.glassfish.jersey.server.ResourceConfig.getClasses(ResourceConfig.java:755)
org.glassfish.jersey.server.ResourceConfig$RuntimeConfig.<init>(ResourceConfig.java:1184)
org.glassfish.jersey.server.ResourceConfig$RuntimeConfig.<init>(ResourceConfig.java:1157)
org.glassfish.jersey.server.ResourceConfig.createRuntimeConfig(ResourceConfig.java:1153)
org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:322)
org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:289)
org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.<init>(GrizzlyHttpContainer.java:331)
org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpServerFactory.createHttpServer(GrizzlyHttpServerFactory.java:119)
asd.Main.startServer(Main.java:55)
asd.Main.__M_start(Main.java:89)
asd.Main.start(Main.java)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:606)
org.apache.felix.ipojo.util.Callback.call(Callback.java:237)
org.apache.felix.ipojo.util.Callback.call(Callback.java:193)
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.call(LifecycleCallback.java:86)
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.__M_stateChanged(LifecycleCallbackHandler.java:162)
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.stateChanged(LifecycleCallbackHandler.java)
org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:560)
org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:440)
org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:179)
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:319)
   - locked org.apache.felix.ipojo.ComponentFactory@46737f42
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:240)
org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:312)
org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:306)
org.apache.felix.ipojo.extender.internal.queue.JobInfoCallable.call(JobInfoCallable.java:114)
java.util.concurrent.FutureTask.run(FutureTask.java:262)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:745)

This was on jersey 2.15. I tried master, same issue. Modified the code a bit to see what's going on (patch against master):

index edc3c24..bd52cbd 100644
--- a/core-server/src/main/java/org/glassfish/jersey/server/ResourceConfig.java
+++ b/core-server/src/main/java/org/glassfish/jersey/server/ResourceConfig.java
@@ -887,6 +887,7 @@ public class ResourceConfig extends Application implements Configurable<Resource
             while (resourceFinder.hasNext()) {
                 final String next = resourceFinder.next();
                 if (afl.accept(next)) {
+                                                LOGGER.log(Level.INFO, "Loading resource "+next+" from finder "+rfs.getClass()+" -> " + rfs);
                     final InputStream in = resourceFinder.open();
                     try {
                         afl.process(next, in);
@@ -894,12 +895,14 @@ public class ResourceConfig extends Application implements Configurable<Resource
                         LOGGER.log(Level.WARNING, LocalizationMessages.RESOURCE_CONFIG_UNABLE_TO_PROCESS(next));
                     } finally {
                         try {
+                                                LOGGER.log(Level.INFO, "Closing instream for "+next);
                             in.close();
                         } catch (final IOException ex) {
                             LOGGER.log(Level.FINER, "Error closing resource stream.", ex);
                         }
                     }
-                }
+                }else
+                                                LOGGER.log(Level.INFO, "Not loading resource "+next+" from finder "+rfs.getClass()+" -> " + rfs);
             }
         }

This gives me the following output:

2015-02-12 14:42:15,170 | INFO  |  pool-1-thread-1 | Main                             | 146 - testproject - 1.0.0.SNAPSHOT | Hello, starting!
2015-02-12 14:42:15,170 | INFO  |  pool-1-thread-1 | ResourceConfig                   | 269 - org.glassfish.jersey.core.jersey-server - 2.16.0.SNAPSHOT | Not loading resource /asd/www/ from finder class java.util.HashSet -> [org.glassfish.jersey.server.internal.scanning.PackageNamesScanner@23b9b99d]
2015-02-12 14:42:15,170 | INFO  |  pool-1-thread-1 | ResourceConfig                   | 269 - org.glassfish.jersey.core.jersey-server - 2.16.0.SNAPSHOT | Not loading resource /asd/www/ from finder class java.util.HashSet -> [org.glassfish.jersey.server.internal.scanning.PackageNamesScanner@23b9b99d]
2015-02-12 14:42:15,171 | INFO  |  pool-1-thread-1 | ResourceConfig                   | 269 - org.glassfish.jersey.core.jersey-server - 2.16.0.SNAPSHOT | Not loading resource /asd/www/ from finder class java.util.HashSet -> [org.glassfish.jersey.server.internal.scanning.PackageNamesScanner@23b9b99d]

And on it goes.. forever, until JVM is killed. So, for some reason the ResourceFinder keeps giving me that directory over and over.

If i remove the www directory from my package, everything starts up perfectly fine.

As a side note, to anyone else trying to get OSGI/Jersey working: I kept getting the following exception:

java.lang.IllegalStateException: No generator was provided and there is no default generator registered
	at org.glassfish.hk2.internal.ServiceLocatorFactoryImpl.internalCreate(ServiceLocatorFactoryImpl.java:266)
	at org.glassfish.hk2.internal.ServiceLocatorFactoryImpl.create(ServiceLocatorFactoryImpl.java:230)
	at org.glassfish.jersey.internal.inject.Injections._createLocator(Injections.java:138)
	at org.glassfish.jersey.internal.inject.Injections.createLocator(Injections.java:123)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:308)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:289)
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.<init>(GrizzlyHttpContainer.java:331)
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpServerFactory.createHttpServer(GrizzlyHttpServerFactory.java:119)

until I ensured that org.glassfish.hk2.locator was installed. In my maven-bundle-plugin instructions I added "<_include>src/main/resources/bundle.osgi</_include>", which contains "Require-Bundle: org.glassfish.hk2.locator".
Is there any better way to do this? Require-bundle seems non-recommended..



 Comments   
Comment by jstrom [ 12/Feb/15 ]

Oops, log output above says "Not loading resource /asd/www/"... I missed to rewrite that part in the issue text (in the rest of the text I changed "asd" to "testproject", to avoid confusion about "asd". that fired back!)

Comment by jstrom [ 12/Feb/15 ]

After some additional testing, it seems that it fails if the scanned prefix contains any HTML files.
Some tested scenarios:

Fails:
new ResourceConfig().packages("testproject")
/testproject/Main.class
/testproject/index.html

Fails:
new ResourceConfig().packages("testproject")
/testproject/Main.class
/testproject/index.html

Fails:
new ResourceConfig().packages("testproject")
/testproject/Main.class
/testproject/www/index.html

Works:
new ResourceConfig().packages("testproject.src")
/testproject/src/Main.class
/testproject/www/index.html

Works:
new ResourceConfig().packages("testproject")
/testproject/Main.class
/www/index.html

So.. Basically it seems I can not have any .html files in the path which is scanned?
It's easy to avoid though, just keep code in "com.example.project" and HTML resources in "www" (in a particular JAR). Keeping resources under com.example.project.www would fail though (but not sure if that is common practice or not).

For the record, this did not occur when running in standalone mode (with static main() as from the tutorials).

Comment by jstrom [ 18/Feb/15 ]

I've done some more debugging, and verified this is also a problem on 2.16 (and 2.17-SNAPSHOT @ b2424a3). I've noticed that it may hang on plain directories as well, even if they have class files in them.
The actual hang boils down to this:

  1. scanClasses calls hasNext() on the ResourceFinder, in this case a BundleSchemeResourceFinder.
  2. BundleSchemeResourceFinder.hasNext will return true if an internal boolean "accessed" is false.
  3. If the AnnotationAcceptingListener does accept the resource, it calls open() on the resourceFinder, else it continues with another round of hasNext().
  4. in BundleSchemeResourceFinder, if open() is called, accessed is set to true.
  5. Since open() is never called, accessed will always be false and we are stuck in a loop.

In my case, there are a bunch of BundleSchemeResourceFinder instances added to the resource stack. These are added from ResourceConfig.init(), which eventually delegates to osgiRegistry.getPackageResources to find any resources in my bundle.
In OsgiRegistry.getPackageResources (with some extra logging added), the call to findEntries (with recurse=false) results in this:

Looking for package asd in asd [154]
  found entry /asd/BasicApiResource.class => asd.BasicApiResource at bundle://154.0:0/asd/BasicApiResource.class
  found entry /asd/Main.class => asd.Main at bundle://154.0:0/asd/Main.class
.. some more classes...
  found entry /asd/TestExceptionMapper.class => asd.TestExceptionMapper at bundle://154.0:0/asd/TestExceptionMapper.class
  found entry /asd/x/ => asd. at bundle://154.0:0/asd/x/

The /asd/x directory has a few other resources, but since findEntries is non-recursive, it only returns the directory.

A working workaround is to make sure that any directory which is scanned, does not have any subdirectories. For example, ensure all resources are located in asd.resources and have nothing but .class files there.

Comment by jstrom [ 18/Feb/15 ]

(Oh, and a side note to any future google references to "No generator was provided and there is no default generator registered", it seems to be very important that the org.glassfish.hk2.osgi-resource-locator bundle is loaded before anything else (more likely, before org.glassfish.hk2.locator). Ensure this happens by setting the start-level of this bundle to a lower value than the rest. In Karaf/Felix, it can be done with bundle:start-level org.glassfish.hk2.osgi-resource-locator 70.)

Comment by jstrom [ 18/Feb/15 ]

Another gotcha with regards to OSGI scanning: On container startup, it will not always find my resources (getPackageResources's call to bundleContext.getBundles() returns no bundles).
Workaround: ensures start-level for the application is higher jersey bundles.

Comment by Michal Gajdos [ 18/Feb/15 ]

Thank you for a very detailed description and analysis, moving to backlog for now (we should be able to look into this soon).





[JERSEY-2787] Incorrect wadl generated when entity parameter is annotated with unknown annotation Created: 11/Feb/15  Updated: 18/Feb/15

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.13, 2.14, 2.15
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: elw00d Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: wadl
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tested on Windows, Linux. Jersey is executed in standalone mode.



 Description   

Assume that we have a REST method like this:

@POST
public String putSomeEntity(Entity entity) {
   // bla bla bla
}

If execute this and go to application.wadl we should find something like this:

<method id="putSomeEntity" name="POST">
<request>
<ns2:representation xmlns:ns2="http://wadl.dev.java.net/2009/02" xmlns="" element="entity" mediaType="application/json"/>
</request>
<response>
<ns2:representation xmlns:ns2="http://wadl.dev.java.net/2009/02" xmlns="" element="entity" mediaType="application/json"/>
</response>
</method>

Let we add some unknown annotation TestAnn to this parameter:

@Target({ElementType.PARAMETER, ElementType.METHOD, ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
public @interface SomeAnnotation {
}
@POST
public String putSomeEntity(@SomeAnnotation  Entity entity) {
   // bla bla bla
}

Generated wadl will be changed to something like this:

<method id="putSomeEntity" name="POST">
<response>
<ns2:representation xmlns:ns2="http://wadl.dev.java.net/2009/02" xmlns="" element="entity" mediaType="application/json"/>
</response>
</method>

Now we have no <request/> section. If we will try to generate rest client code using this wadl, we'll get methods without parameters.

Source of this behaviour is unknown annotations processing code. In 2.15 it is org.glassfish.jersey.server.model.Parameter class, method create():

for (Annotation annotation : annotations) {
            if (ANNOTATION_HELPER_MAP.containsKey(annotation.annotationType())) {
                ParamAnnotationHelper helper = ANNOTATION_HELPER_MAP.get(annotation.annotationType());
                paramAnnotation = annotation;
                paramSource = helper.getSource();
                paramName = helper.getValueOf(annotation);
            } else if (Encoded.class == annotation.annotationType()) {
                paramEncoded = true;
            } else if (DefaultValue.class == annotation.annotationType()) {
                paramDefault = ((DefaultValue) annotation).value();
            } else {
                // Take latest unknown annotation, but don't override known annotation
                if ((paramAnnotation == null) || (paramSource == Source.UNKNOWN)) {
                    paramAnnotation = annotation;
                    paramSource = Source.UNKNOWN;
                    paramName = getValue(annotation);
                }
            }
        }

        if (paramAnnotation == null) {
            paramSource = Parameter.Source.ENTITY;
        }

When there are unknown annotation and no more annotations, this code makes parameter UNKNOWN instead of ENTITY. To quick fix this I added line to loop body:

if (annotation instanceof SomeAnnotation) continue;

Hope this can be fixed more elegantly and without any compatibility issues.



 Comments   
Comment by Michal Gajdos [ 18/Feb/15 ]

Thanks for filing the issue and for investigation where the problem might be. Moving to backlog for now until someone picks it up.





[JERSEY-2786] Memory leak with shutdown hooks, caused by configuration inheritance Created: 11/Feb/15  Updated: 18/Feb/15

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.15
Fix Version/s: backlog

Type: Bug Priority: Critical
Reporter: ogheorghies+java@gmail.com Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: memory-leak
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JERSEY-2688 Memory leak with the shutdown hooks q... Open

 Description   

The following code causes OutOfMemoryError. An actual invocation.invoke() call is neither required, nor it eliminates the problem.

OOM Repro
        Client client = ClientBuilder.newClient();
        WebTarget target = client.target("http://example.com");

        while (true) {
            WebTarget target2 = target.property("foo", "bar");
            Builder req = target2.request();
            Invocation invocation = req.buildGet();
        }

Root cause:

  • Each Jersey ClientConfig has a copy-on-write State, and each State instance creates one lazily-initialized ClientRuntime.
  • Whenever target.property() is called, a new State copy is created.
  • The JerseyInvocation created by buildGet() uses this new State instance, and accesses its lazily-initialized ClientRuntime.
  • Upon its initialization, ClientRuntime is registered as a shutdown hook with the JerseyClient.

Therefore, each iteration results in one ClientRuntime instance being added to the list of shutdown hooks in JerseyClient. The ClientRuntime instance is never removed from this list.

This issue is probably the root cause of https://java.net/jira/browse/JERSEY-2688 , which was catalogued as a "connectors" issue that has to do with ApacheConnector.






[JERSEY-2785] Use StAX instead of SAX for JAXB Created: 11/Feb/15  Updated: 19/Feb/15

Status: Open
Project: jersey
Component/s: None
Affects Version/s: 2.16
Fix Version/s: backlog

Type: Improvement Priority: Major
Reporter: evnp Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: incomplete
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Is it possible to change SAXSource to StAX XMLInputFactory in org.glassfish.jersey.message.internal.XmlRootElementJaxbProvider?

JAXB RI use woodstox StAX implementation if possible because it has great perfomance advantages, so adding woodstox jar to classpath will increase XML marshalling and unmarshalling speed.



 Comments   
Comment by Michal Gajdos [ 18/Feb/15 ]

Can you, please, elaborate more? I mean can you point us to some performance overview of these two approaches?

Comment by evnp [ 19/Feb/15 ]

See http://stackoverflow.com/questions/11773649/java-xml-parser-performance-sun-java-streaming-xml-parser-sjsxp-vs-woodsto/11782775#11782775 for example. For my private xml data this is true: woodstox is faster than default stax implementation and aalto is bit faster than woodstox.





[JERSEY-2784] Selectable Entity Filtering doesn't work with JodaTime Fields Created: 10/Feb/15  Updated: 25/Feb/15

Status: Open
Project: jersey
Component/s: extensions
Affects Version/s: 2.15
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: difranr Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: entity-filtering
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK 1.8, Cargo with Tomcat 8


Issue Links:
Duplicate
is duplicated by JERSEY-2803 InternalServerErrorException when usi... Resolved

 Description   

We have model objects that have JodaTime Instants in them and when I enabled SelectableEntityFilteringFeature, the content fails to render. I debugged it and it seems to fail specifically on the ZONE field which is of type DateTimeZone. This type is abstract and contains only static fields, therefore the method ObjectGraphImpl.getFields(final String parent) fails because the enclosed graph object is NULL.



 Comments   
Comment by difranr [ 11/Feb/15 ]

I want to further clarify, what is occurring. We have a domain object that looks like:

Bar.java
@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Thing {
  private String id;
  private Instant createdDate;
}

And then an enclosing response object that looks like:

Bar.java
@XmlRootElement
public class ThingCollectionResponse {
    private Integer total;

    private List<Thing> entries = new ArrayList<>();

    public ThingCollectionResponse() {
    }

    public ThingCollectionResponse(List<Thing> entries) {
        setEntries(entries);
    }

    public Integer getTotal() {
        return total;
    }

    public void setTotal(Integer total) {
        this.total = total;
    }

    public List<Thing> getEntries() {
        return entries;
    }

    public void setEntries(List<Thing> entries) {
        this.entries = entries;
        total = this.entries.size();
    }
}

When I access my response which returns just a Thing object it works fine and it filters just fine. It just when I return a collection via the ThingCollectionResponse that it fails to render at all, because it hits the NPE in ObjectGraphImpl.getFields().

Comment by Michal Gajdos [ 18/Feb/15 ]

Oh, I see. I guess we should introduce a way how to exclude classes (e.g. JodaTime classes) from being processed by EntityFiltering processors. Thank you for reporting this!

Comment by difranr [ 18/Feb/15 ]

@Michal It would be NICE to filter on these fields, but the code needs to recognize not to recurse into fields that are abstract/static, etc. I believe that this issue is related:

https://java.net/jira/browse/JERSEY-781

I was trying to come up with a fix, but got bogged down try to upgrade to 2.16.





[JERSEY-2783] Priority comparator fails when dealing with edge case values Integer.MIN_VALUE and Integer.MAX_VALUE Created: 10/Feb/15  Updated: 10/Feb/15  Resolved: 10/Feb/15

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.15
Fix Version/s: 2.16

Type: Bug Priority: Major
Reporter: Jakub Podlesak Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This was already fixed with the following commit:
SHA: 63e9eaa385e1600c6ff9613c5e0b6f2343420096
Author: Jakub Podlesak <jakub.podlesak@oracle.com>
Date: Mon Jan 26 2015 20:05:54 GMT+0100 (CET)
Subject: Fixed nasty RankedComparator bug (pointed out my Mira) where edge case values caused comparator malfunction
Parent: de2c2f9e58646375c65093195108ad0c9629522d






[JERSEY-2782] MOXy-based JSON unmarshaller returns null "root" Object value when an unmapped JSON property name is returned Created: 09/Feb/15  Updated: 18/Feb/15  Resolved: 18/Feb/15

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 2.15
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dallasvaughan Assignee: Michal Gajdos
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive json-moxy.zip    

 Description   

If there are any properties in a JSON-based response which are not mapped to a Java property of an @XmlRootElement-annotated class given as the return type of a POST request, the return object value is null (even if there are properties which are mapped correctly).

For comparison, when using the Jackson feature, and an unmapped JSON property is encountered during client response processing, it throws the following exception:

javax.ws.rs.ProcessingException: Error reading entity from input stream.
~
Caused by: com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "fieldC" (class com.SomeClass), not marked as ignorable (2 known properties: "fieldA", "fieldB"])

The MOXy feature, on the other hand, provides no information about what the problem is making it difficult to debug (unless you already know about this issue).



 Comments   
Comment by Michal Gajdos [ 10/Feb/15 ]

Can you provide a reproducible test-case? I am not sure I correctly understand your problem. Thanks.

Comment by dallasvaughan [ 11/Feb/15 ]

Say you want to connect to a REST-based service that returns a JSON response, such as:

{"fieldA" : "value1", "fieldB" : "value2" }

and so you create a Java class to map to this response type using MOXy:

SomeClass.java

@XmlRootElement
public class SomeClass {
   String fieldA;
   String fieldB;

   //fieldA and fieldB getters and setters
}

After receiving the response from the service, it will be successfully unmarshalled to the mapped object:

   WebTarget target = ClientBuilder.newClient().target("http://someservice.com/someresource");
   SomeClass response = target.request().get(SomeClass.class);
   //response is not null and is populated with fieldA="value1" and fieldB="value2"

However, if the service adds a field ("fieldC") to the JSON response that is not mapped in the class as a property, the response will not be unmarshalled successfully and the entire object will be set to null:

{"fieldA" : "value1", "fieldB" : "value2", "fieldC" : "value3" }

Now, when running the same code above...

   WebTarget target = ClientBuilder.newClient().target("http://someservice.com/someresource");
   SomeClass response = target.request().get(SomeClass.class);
   //response is null

Given the same conditions above, when using Jackson as the provider, it throws the error I referenced (UnrecognizedPropertyException). I would expect MOXy to handle it similarly, but it fails silently. Perhaps this is an issue with MOXy itself, but perhaps there is a way to handle this condition by Jersey more effectively .

Comment by Michal Gajdos [ 15/Feb/15 ]

I've slightly updated our json-moxy example, see attached. Unfortunately, I still cannot reproduce it. Can you look at the example and tell me what I did wrong when reproducing the issue? The sample uses MOXy 2.5 and Jersey 2.15. Take a look at JsonResource.createSimpleBean and JsonResourceTest.testGet.

Comment by dallasvaughan [ 17/Feb/15 ]

Thanks for creating this example, Michal. I think I've found the issue: If an "extra" field is in the last position and its value is null, it will return a null result. If the extra field is not null or it is not the last field, it will silently ignore this field and populate the bean with as many field/values as it can.

To verify this, switch the position of "fieldC" in the JsonResource class to be the last field, and set its value to null. This will give the result I described (though I wrongly assumed the issue arose from the extra field and not the fact that this field was null - sorry about that! :-/).

JsonResource.java
    @GET
    @Produces("application/json")
    public String createSimpleBean() {
        // return new TestBean("a", 1, 1L);
        return "{\"fieldA\" : \"a\" , \"foo\" : \"bar\" , \"fieldB\" : \"b\", \"fieldC\" : null}";
        // return "<testBean><a>a</a><b>1</b><c>1</c><foo>bar</foo></testBean>";
    }
Comment by Iaroslav Savytskyi [ 18/Feb/15 ]

This is MOXy issue. I've filled the bug against eclipselink 2.6 : https://bugs.eclipse.org/bugs/show_bug.cgi?id=460253

Comment by Michal Gajdos [ 18/Feb/15 ]

Unfortunately we cannot do anything in Jersey with this. As Iaroslav mentioned it's a problem in MOXy. I'll watch progress on the underlying issue and when it's fixed we can update MOXy in Jersey.





[JERSEY-2781] Locale-dependent test fails in org.glassfish.jersey.message.internal.QualityTest.testEnhanceWithQualityParameter Created: 09/Feb/15  Updated: 10/Feb/15  Resolved: 10/Feb/15

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.16
Fix Version/s: 2.16

Type: Bug Priority: Minor
Reporter: limomartin Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:
$ mvn --version
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
Maven home: /usr/local/Cellar/maven/3.2.5/libexec
Java version: 1.8.0_31, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "mac os x", version: "10.10.2", arch: "x86_64", family: "mac"


 Description   
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec <<< FAILURE! - in org.glassfish.jersey.message.internal.QualityTest
testEnhanceWithQualityParameter(org.glassfish.jersey.message.internal.QualityTest)  Time elapsed: 0.011 sec  <<< FAILURE!
java.lang.AssertionError: 
Expected: <{q=0.2}>
     but: was <{q=0,2}>
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.junit.Assert.assertThat(Assert.java:865)
	at org.junit.Assert.assertThat(Assert.java:832)
	at org.glassfish.jersey.message.internal.QualityTest.testEnhanceWithQualityParameter(QualityTest.java:68)

Possible hotfix (besides locale agnostic test):

$ diff pom.xml.old pom.xml
153c153
<                     <argLine>${surefire.security.argline}</argLine>
---
>                     <argLine>${surefire.security.argline} -Duser.language=en -Duser.region=US</argLine>


 Comments   
Comment by Michal Gajdos [ 10/Feb/15 ]

Nice catch, thanks.





[JERSEY-2780] Provide option to opt out from MEDIA_TYPE_MAPPINGS Created: 09/Feb/15  Updated: 18/Feb/15

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.11
Fix Version/s: icebox

Type: Improvement Priority: Major
Reporter: Michael Osipov Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I have configured MEDIA_TYPE_MAPPINGS for my Jersey apps. Unfortunately, this causes some trouble with a generic upload service in my app.

@PUT
@Path("files/{filename}")
@Produces({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON })
public Response uploadFile(
    @PathParam("filename") @NotNull @Size(max = 240) String filename, DataSource dataSource)

If someone uploads .../files/file.xml the extension is chopped of.

There should be some opt-out to this. Otherwise one has to disable this feature. This is what I did.

Here is the SO question for this.






[JERSEY-2779] ServerSent Events not working when LoggingFilter is enabled with printEntity Created: 09/Feb/15  Updated: 18/Feb/15

Status: Open
Project: jersey
Component/s: core, media
Affects Version/s: 2.15
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: quixote_arg Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: sse
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

tomcat 7.0.53



 Description   

Some time ago I added a LoggingFilter to my application, like this on the "extends ResourceConfig" class:

register(new LoggingFilter(Logger.getLogger(LoggingFilter.class.getName()), true));

After some time I noticed that the server sent events stopped working.

I reproduced it with the sample from https://jersey.java.net/documentation/latest/sse.html (adding Thread.sleep(1000) to make it more asynchronous); when the LoggingFilter was enabled (with printEntity set to true) then it will wait the whole 30 seconds and output the entire response at once (instead of one per second, 30 times)

If I comment out the LoggingFilter registration or change it to:

register(LoggingFilter.class);

then the chunks arrive once per second, as expected.

Another side effect of the this bug is that when I close the client connection, no exception is thrown on the server, hence the server keeps sending events to the client, even if the connection was closed a long time ago.



 Comments   
Comment by quixote_arg [ 09/Feb/15 ]

I think that the problem is on LoggingFilter.filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) which tries to log the entire entity which the server responded, which in the case of SSE may never finish

LoggingFilter.java
        if (printEntity && responseContext.hasEntity()) {
            OutputStream stream = new LoggingStream(b, responseContext.getEntityStream());
            responseContext.setEntityStream(stream);
            requestContext.setProperty(ENTITY_LOGGER_PROPERTY, stream);
            // not calling log(b) here - it will be called by the interceptor
        } else {
            log(b);
        }




[JERSEY-2778] ClassNotFoundException: EntityFilteringFeature Created: 08/Feb/15  Updated: 10/Feb/15  Resolved: 10/Feb/15

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 2.15
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: dutoitns@gmail.com Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 8



 Description   

I pulled Moxy onto my classpath. Now I'm suddenly getting a ClassNotFoundException as follows:

SEVERE: StandardWrapper.Throwable
java.lang.NoClassDefFoundError: org/glassfish/jersey/message/filtering/EntityFilteringFeature
at org.glassfish.jersey.moxy.json.MoxyJsonFeature.entityFilteringEnabled(MoxyJsonFeature.java:100)
at org.glassfish.jersey.moxy.json.MoxyJsonFeature.configure(MoxyJsonFeature.java:89)
at org.glassfish.jersey.model.internal.CommonConfig.configureFeatures(CommonConfig.java:709)
at org.glassfish.jersey.model.internal.CommonConfig.configureMetaProviders(CommonConfig.java:639)
at org.glassfish.jersey.server.ResourceConfig.configureMetaProviders(ResourceConfig.java:809)
at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:392)
at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:167)
at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:327)
at org.glassfish.jersey.internal.Errors$2.call(Errors.java:289)
at org.glassfish.jersey.internal.Errors$2.call(Errors.java:286)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:286)
at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:324)
at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:315)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:170)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:358)
at javax.servlet.GenericServlet.init(GenericServlet.java:158)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1284)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5231)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5518)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1575)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1565)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassNotFoundException: org.glassfish.jersey.message.filtering.EntityFilteringFeature
at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 30 more

The libraries I downloaded (jars within Jersey's jaxrs-ri-2.15.zip, and Moxy: jersey-media-moxy-2.15.jar) doesn't contain that class?



 Comments   
Comment by dutoitns@gmail.com [ 08/Feb/15 ]

Not sure about the details, but there is another issue open for Jersey 2.15 that also has to do with the EntityFilteringFeature
https://java.net/jira/browse/JERSEY-2777

Comment by Michal Gajdos [ 10/Feb/15 ]

You need to put also jersey-entity-filtering.jar (see [1]) on your class-path. Jersey media MOXy module depends on it.

[1] http://search.maven.org/#artifactdetails%7Corg.glassfish.jersey.ext%7Cjersey-entity-filtering%7C2.15%7Cjar

Comment by Michal Gajdos [ 10/Feb/15 ]

Closing as invalid. Feel free to reopen (or comment) if you think this is still an issue.





[JERSEY-2777] EntityFilteringFeature traps with NullPointerException when used with lazy JPA Parent/Child relation under EclipseLink Created: 07/Feb/15  Updated: 18/Feb/15

Status: Open
Project: jersey
Component/s: extensions
Affects Version/s: 2.15
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: Sascha_Baumeister Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: entity-filtering
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu Gnome Linux 14.10
OpenJDK 1.8
mysql-connector 5.1.34 (connector-j)
eclipse-link 2.5.2
jersey 2.15
jersey-container-jdk-http 2.15
jersey-media-moxy 2.15
jersey-entity-filtering 2.15



 Comments   
Comment by Sascha_Baumeister [ 07/Feb/15 ]

I created a test model project with two JPA entities forming a parent/child relationship, with the parent side annotated using @ManyToOne(fetch = FetchType.LAZY, optional = false).

When running a test service that retrieves the child, it works as long as I leave out either the Jersey Entity Filtering feature, or EclipseLink's Dynamic Weaving feature (enabled by adding the VM-Argument "-javaagent:<libpath>/eclipselink.jar", preventing the fallback to EAGER relationship fetching).

However, once I enable both Entity Filtering and Dynamic Weaving the former traps with a NullPointerException, generating the following stack trace:
java.lang.NullPointerException
at org.glassfish.jersey.message.filtering.ObjectGraphImpl.getFields(ObjectGraphImpl.java:94)
at org.glassfish.jersey.moxy.internal.MoxyObjectProvider.createSubgraphs(MoxyObjectProvider.java:128)
at org.glassfish.jersey.moxy.internal.MoxyObjectProvider.createSubgraphs(MoxyObjectProvider.java:139)
at org.glassfish.jersey.moxy.internal.MoxyObjectProvider.createSubgraphs(MoxyObjectProvider.java:115)
at org.glassfish.jersey.moxy.internal.MoxyObjectProvider.createObjectGraph(MoxyObjectProvider.java:91)
at org.glassfish.jersey.moxy.internal.MoxyObjectProvider.transform(MoxyObjectProvider.java:78)
at org.glassfish.jersey.moxy.internal.MoxyObjectProvider.transform(MoxyObjectProvider.java:63)
at org.glassfish.jersey.message.filtering.spi.AbstractObjectProvider.createFilteringObject(AbstractObjectProvider.java:135)
at org.glassfish.jersey.message.filtering.spi.AbstractObjectProvider.getFilteringObject(AbstractObjectProvider.java:97)
at org.glassfish.jersey.message.filtering.spi.AbstractObjectProvider.getFilteringObject(AbstractObjectProvider.java:80)
at org.glassfish.jersey.moxy.json.internal.FilteringMoxyJsonProvider.preWriteTo(FilteringMoxyJsonProvider.java:80)
at org.eclipse.persistence.jaxb.rs.MOXyJsonProvider.writeTo(MOXyJsonProvider.java:858)
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:265)
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:250)
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
at org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor.aroundWriteTo(JsonWithPaddingInterceptor.java:106)
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:85)
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1154)
at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:662)
at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:418)
at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:408)
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:306)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:316)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:286)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1073)
at org.glassfish.jersey.jdkhttp.JdkHttpHandlerContainer.handle(JdkHttpHandlerContainer.java:175)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:79)
at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:83)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:82)
at sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:675)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:79)
at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:647)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

I'd like to add my test application consisting of two source+binary JARs, including a mysql schema creation script to this topic, but don't know how to ...

Comment by Sascha_Baumeister [ 07/Feb/15 ]

As there seems to be no way to add the JARs as binaries, I decided to add the relevant sources so you can recreate the problem:

==========================
bug-model-jar:
==========================

package de.bug.model;
import javax.persistence.*;
import javax.xml.bind.annotation.*;
@XmlType
@XmlRootElement
@XmlAccessorType(XmlAccessType.NONE)
@Entity
@Table(schema = "bug", name = "Child")
public class Child {

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private final long identity;

@ManyToOne(fetch = FetchType.LAZY, optional = false)
@JoinColumn(name = "parentReference", nullable = false, updatable = false)
private final Parent parent;

@Column(nullable = true, updatable = true, length = 63)
private volatile String name;

protected Child ()

{ this.identity = 0; this.parent = null; }

public Child(String name, Parent parent)

{ this.identity = 0; this.parent = parent; this.name = name; }

@XmlElement
public long getIdentity ()

{ return this.identity; }

@XmlElement
public String getName() { return this.name; }

@XmlElement
public Parent getParent () { return this.parent; }
}



package de.bug.model;
import java.util.*;
import javax.persistence.*;
import javax.xml.bind.annotation.*;
@XmlType
@XmlRootElement
@XmlAccessorType(XmlAccessType.NONE)
@Entity
@Table(schema = "bug", name = "Parent")
public class Parent {

@XmlElement
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private final long identity;

@OneToMany(mappedBy = "parent", cascade = CascadeType.REMOVE)
private final Set<Child> children;

@XmlElement
@Column(nullable = true, updatable = true, length = 63)
private volatile String name;

protected Parent () { this.identity = 0; this.children = new HashSet<>(); }

public Parent (final String name) { this.identity = 0; this.children = new HashSet<>(); this.name = name; }

@XmlElement
public long getIdentity () { return this.identity; }

@XmlElement
public String getName()

{ return this.name; }

public Set<Child> getChildren ()

{ return this.children; }

}

File /META-INF/persistence.xml:
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
<persistence-unit name="bug" transaction-type="RESOURCE_LOCAL">
<exclude-unlisted-classes>false</exclude-unlisted-classes>
<!-- non-jta-data-source>JNDI-name in Java EE</non-jta-data-source -->

<properties>
<property name="javax.persistence.jdbc.driver" value="com.mysql.jdbc.Driver"/>
<property name="javax.persistence.jdbc.url" value="jdbc:mysql://localhost:3306/"/>
<property name="javax.persistence.jdbc.user" value="root"/>
<property name="javax.persistence.jdbc.password" value="root"/>

<property name="eclipselink.logging.level.sql" value="FINE"/>
<property name="eclipselink.logging.parameters" value="true"/>
</properties>
</persistence-unit>
</persistence>

File /META-INF/bug-mysql.sql
SET CHARACTER SET utf8;
DROP DATABASE IF EXISTS bug;
CREATE DATABASE bug CHARACTER SET utf8;
CREATE TABLE bug.Parent (
identity BIGINT NOT NULL AUTO_INCREMENT,
name VARCHAR(63) NULL,
PRIMARY KEY (identity)
) ENGINE=InnoDB;
CREATE TABLE bug.Child (
identity BIGINT NOT NULL AUTO_INCREMENT,
name VARCHAR(63) NULL,
parentReference BIGINT NOT NULL,
PRIMARY KEY (identity),
FOREIGN KEY (parentReference) REFERENCES bug.Parent (identity) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB;

==========================
bug-rest-jar:
==========================
package de.bug.rest;
import java.io.*;
import java.net.URI;
import org.glassfish.jersey.jdkhttp.JdkHttpServerFactory;
import org.glassfish.jersey.message.filtering.EntityFilteringFeature;
import org.glassfish.jersey.moxy.json.MoxyJsonFeature;
import org.glassfish.jersey.server.ResourceConfig;
import com.sun.net.httpserver.HttpServer;
public class ApplicationContainer {

static public void main (final String[] args) throws IOException {
final URI serviceURI = URI.create("http://localhost:8001/services");

final ResourceConfig configuration = new ResourceConfig();
configuration.packages("de.bug.rest");
configuration.register(MoxyJsonFeature.class);
configuration.register(EntityFilteringFeature.class);

final HttpServer server = JdkHttpServerFactory.createHttpServer(serviceURI, configuration);
try

{ System.out.format("HTTP server running on service address %s, enter \"quit\" to stop.\n", serviceURI); final BufferedReader charSource = new BufferedReader(new InputStreamReader(System.in)); while (!"quit".equals(charSource.readLine())); }

finally

{ server.stop(0); }

}
}

package de.bug.rest;
import java.util.logging.*;
import javax.ws.rs.WebApplicationException;
import javax.ws.rs.core.Response;
import javax.ws.rs.core.Response.Status;
import javax.ws.rs.ext.ExceptionMapper;
import javax.ws.rs.ext.Provider;
@Provider
public class DetailedExceptionMapper implements ExceptionMapper<Throwable> {
public Response toResponse (final Throwable exception) {
final Response response = exception instanceof WebApplicationException
? ((WebApplicationException) exception).getResponse()
: Response.status(Status.INTERNAL_SERVER_ERROR).build();
if (response.getStatus() >= 400) {
for (Throwable throwable = exception; throwable != null; throwable = throwable.getCause())

{ Logger.getGlobal().log(Level.WARNING, throwable.getMessage(), throwable); }

}
return response;
}
}

package de.bug.rest;
import javax.persistence.*;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
import de.bug.model.*;

@Path("bugs")
public class Service {

@GET
@Produces(

{ MediaType.APPLICATION_JSON }

)
public Child test () {
final EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory("bug");
try {
final EntityManager entityManager = entityManagerFactory.createEntityManager();
try

{ entityManager.getTransaction().begin(); Parent parent = new Parent("foo"); entityManager.persist(parent); entityManager.getTransaction().commit(); entityManager.getTransaction().begin(); Child child = new Child("bar", parent); entityManager.persist(child); entityManager.getTransaction().commit(); entityManager.clear(); entityManager.getTransaction().begin(); child = entityManager.find(Child.class, child.getIdentity()); parent = child.getParent(); entityManager.getTransaction().commit(); return child; }

finally

{ entityManager.close(); }

} finally

{ entityManagerFactory.close(); }

}
}

Comment by Michal Gajdos [ 18/Feb/15 ]

Thank you for the test-case. Moving to backlog for now.





[JERSEY-2776] Regression -Multipart/form-data POST having a quoted boundary parameter in the Content-Type header fails. Created: 07/Feb/15  Updated: 24/Feb/15  Resolved: 24/Feb/15

Status: Resolved
Project: jersey
Component/s: media
Affects Version/s: 2.15
Fix Version/s: 2.17

Type: Bug Priority: Major
Reporter: jontejj Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes

Attachments: HTML File does_not_work_but_is_valid    
Issue Links:
Cloners
clones JERSEY-1420 CLONE -Multipart/form-data POST havin... Resolved
Tags: boundary, jersey, multipart, pull-request, quoted

 Description   

Jersey returns HTTP status 400 when POST-ing a multipart/form-data having a quoted boundary parameter in the Content-Type header:
Content-Type: multipart/form-data;boundary="MrmiiyyJEqRYcIJyun5tMVIz70NuQ_nfD"
and use MrmiiyyJEqRYcIJyun5tMVIz70NuQ_nfD (without quotes) to separate the parts.

Use com.sun.jersey.spi.spring.container.servlet.SpringServlet.
Exception is thrown in jersey class com.sun.jersey.multipart.impl.MultiPartReaderClientSide, method readMultiPart. (org.jvnet.mimepull.MIMEParsingException: Missing start boundary).

RFC2046 states that quoted boundary values are permitted (http://www.ietf.org/rfc/rfc2046.txt):
"
WARNING TO IMPLEMENTORS: The grammar for parameters on the Content-
type field is such that it is often necessary to enclose the boundary
parameter values in quotes on the Content-type line. This is not
always necessary, but never hurts. Implementors should be sure to
study the grammar carefully in order to avoid producing invalid
Content-type fields. Thus, a typical "multipart" Content-Type header
field might look like this:
Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p

But the following is not valid:
Content-Type: multipart/mixed; boundary=gc0pJq0M:08jU534c0p
(because of the colon) and must instead be represented as
Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p"
".



 Comments   
Comment by jontejj [ 07/Feb/15 ]

This affects version 2.15 (I don't have rights to edit fields).
My suggested fix is to:

mediaType = unquoteMediaTypeParameters(mediaType, "boundary");

protected static MediaType unquoteMediaTypeParameters(final MediaType mediaType, final String... parameters) {
if (parameters == null || parameters.length == 0)

{ return mediaType; }

final HashMap<String, String> unquotedParams = new HashMap<String, String>(mediaType.getParameters());

for (final String parameterName : parameters) {
String parameterValue = mediaType.getParameters().get(parameterName);

if (parameterValue.startsWith("\""))

{ parameterValue = parameterValue.substring(1, parameterValue.length() - 1); unquotedParams.put(parameterName, parameterValue); }

}

return new MediaType(mediaType.getType(), mediaType.getSubtype(), unquotedParams);
}

Like MultiPartReaderClientSide looks like in com.sun.jersey.contribs/jersey-multipart/1.15. I'll send a PR to github.

Comment by jontejj [ 09/Feb/15 ]

Pull request: https://github.com/jersey/jersey/pull/143





[JERSEY-2775] Server-Sent Events - write to broken connection does not throw exception Created: 06/Feb/15  Updated: 18/Feb/15

Status: Open
Project: jersey
Component/s: media
Affects Version/s: 2.15
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: ricb Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: sse
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tomcat 7.0.53, RHEL 6.


Tags: sse

 Description   

We are using Server-Sent Events to allow our client application to listen to events raised by our Jersey server. This works great.

We have a requirement for our server to have an accurate list of currently-connected SSE callers (instances of our client application). To this end, our server sends a tiny message to each client (via eventOutput.write) once every five seconds. If our client is shut down while SSE-connected, or if the remote computer is powered off while SSE-connected, our server's eventOutput.write call correctly throws the ClientAbortException/SocketException exception shown below. That's perfect: we catch the exception, and mark that client as no longer connected.

The problem: there are two cases where calling eventOutput.write to a no-longer-connected computer does NOT throw an exception: 1) if the Ethernet cable of the remote computer is disconnected while the client is SSE-connected, and 2) if the network adapter in the remote computer is turned off (e.g., by an administrator) while the client is SSE-connected. In these two cases, eventOutput.write does not throw an exception. We can call eventOutput.write to the remote computer every five seconds for hours and no exception is thrown. This makes it impossible to detect that the remote computer is no longer connected.

To sum up, there are four cases:

1) Client software is shut down: eventOutput.write() correctly throws an exception.
2) Computer running client software is powered down: eventOutput.write() correctly throws an exception.
3) Etherhet cable is disconnected from computer running client software: eventOutput.write does not detect broken connection.
4) Network adapter on computer running client software is turned off: eventOutput.write does not detect broken connection.

Here is the (good/useful) exception we get in cases where eventOutput.write DOES throw the exception we want:

org.apache.catalina.connector.ClientAbortException: null
    at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:371) ~[catalina.jar:7.0.53]
    at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:333) ~[catalina.jar:7.0.53]
    at org.apache.catalina.connector.CoyoteOutputStream.flush(CoyoteOutputStream.java:101) ~[catalina.jar:7.0.53]
    at org.glassfish.jersey.servlet.internal.ResponseWriter$NonCloseableOutputStreamWrapper.flush(ResponseWriter.java:303) ~[jaxrs-ri-2.13.jar:2.13.]
    at org.glassfish.jersey.message.internal.CommittingOutputStream.flush(CommittingOutputStream.java:292) ~[jaxrs-ri-2.13.jar:2.13.]
    at org.glassfish.jersey.server.ChunkedOutput$1.call(ChunkedOutput.java:240) ~[jaxrs-ri-2.13.jar:2.13.]
    at org.glassfish.jersey.server.ChunkedOutput$1.call(ChunkedOutput.java:190) ~[jaxrs-ri-2.13.jar:2.13.]
    at org.glassfish.jersey.internal.Errors.process(Errors.java:315) ~[jaxrs-ri-2.13.jar:2.13.]
    at org.glassfish.jersey.internal.Errors.process(Errors.java:242) ~[jaxrs-ri-2.13.jar:2.13.]
    at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:347) ~[jaxrs-ri-2.13.jar:2.13.]
    at org.glassfish.jersey.server.ChunkedOutput.flushQueue(ChunkedOutput.java:190) ~[jaxrs-ri-2.13.jar:2.13.]
    at org.glassfish.jersey.server.ChunkedOutput.write(ChunkedOutput.java:180) ~[jaxrs-ri-2.13.jar:2.13.]
    at com.appserver.webservice.AgentSsePollingManager$ConnectionChecker.run(AgentSsePollingManager.java:174) ~[AgentSsePollingManager$ConnectionChecker.class:na]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_71]
    at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) [na:1.7.0_71]
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [na:1.7.0_71]
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.7.0_71]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_71]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_71]
    at java.lang.Thread.run(Thread.java:745) [na:1.7.0_71]
Caused by: java.net.SocketException: Broken pipe
    at java.net.SocketOutputStream.socketWrite0(Native Method) ~[na:1.7.0_71]
    at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113) ~[na:1.7.0_71]
    at java.net.SocketOutputStream.write(SocketOutputStream.java:159) ~[na:1.7.0_71]
    at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:215) ~[tomcat-coyote.jar:7.0.53]
    at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:480) ~[tomcat-coyote.jar:7.0.53]
    at org.apache.coyote.http11.InternalOutputBuffer.flush(InternalOutputBuffer.java:119) ~[tomcat-coyote.jar:7.0.53]
    at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:799) ~[tomcat-coyote.jar:7.0.53]
    at org.apache.coyote.Response.action(Response.java:174) ~[tomcat-coyote.jar:7.0.53]
    at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:366) ~[catalina.jar:7.0.53]
    ... 19 common frames omitted





[JERSEY-2773] Annotated CDI beans not detected while injecting into Jersey resource Created: 03/Feb/15  Updated: 10/Feb/15  Resolved: 10/Feb/15

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.13
Fix Version/s: None

Type: Bug Priority: Major
Reporter: xwibao Assignee: Unassigned
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Oracle JDK 1.8.0_31
GlassFish v4.1 b13 nightly 12-15-2014



 Description   

If we create an annotated CDI bean (ex., @RequestScoped), and try to inject it into a resource class, this will fail:

Only injection into resource classes fails; injection into servlets or EJBs works OK. Removing bean-discovery-mode, or setting it to "all", or using CDI 1.0 descriptor (xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd") makes injection work.

Please see this gist. It was created by some other guy, but it reproduces the bug perfectly.

Also tested in WildFly 8.2 (works OK).



 Comments   
Comment by Jakub Podlesak [ 10/Feb/15 ]

The GenericResource from the test case app would be injected all right if it was turned into a contextual CDI bean (i.e. by attaching @RequestScoped annotation to it). Current config is a bit vague, as based on selected discovery mode the GenericResource is either a dependent bean or CDI unmanaged component. In either case, it is not clear how Jersey should treat it.

To make it short: clearly specify scope of the GenericResource bean, and Jersey will handle it and inject just right.

Resolving as "Works as designed". Please feel free to re-open if you think otherwise.





[JERSEY-2772] Tomcat memory leak on undeploy Created: 03/Feb/15  Updated: 27/Feb/15

Status: Reopened
Project: jersey
Component/s: None
Affects Version/s: 2.15
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: kilian.koller Assignee: Adam Lindenthal
Resolution: Unresolved Votes: 0
Labels: hk2, memory-leak
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tomcat 8.0.18


Issue Links:
Duplicate
duplicates HK2-247 Tomcat memory leak on undeploy Closed

 Description   

On undeploy, I get the following errors. Any idea?

03-Feb-2015 08:48:14.362 SEVERE [http-nio-8080-exec-62] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jboss.netty.util.CharsetUtil$2] (value [org.jboss.netty.util.CharsetUtil$2@ecfacab]) and a value of type [java.util.IdentityHashMap] (value [{UTF-8=sun.nio.cs.UTF_8$Decoder@3b8a17a9}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
03-Feb-2015 08:48:14.362 SEVERE [http-nio-8080-exec-62] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jboss.netty.util.CharsetUtil$2] (value [org.jboss.netty.util.CharsetUtil$2@ecfacab]) and a value of type [java.util.IdentityHashMap] (value [{UTF-8=sun.nio.cs.UTF_8$Decoder@515aa672}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
03-Feb-2015 08:48:14.362 SEVERE [http-nio-8080-exec-62] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jboss.netty.util.CharsetUtil$2] (value [org.jboss.netty.util.CharsetUtil$2@ecfacab]) and a value of type [java.util.IdentityHashMap] (value [{UTF-8=sun.nio.cs.UTF_8$Decoder@26d65908}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
03-Feb-2015 08:48:14.362 SEVERE [http-nio-8080-exec-62] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [com.codahale.metrics.ThreadLocalRandom$1] (value [com.codahale.metrics.ThreadLocalRandom$1@558f138d]) and a value of type [com.codahale.metrics.ThreadLocalRandom] (value [com.codahale.metrics.ThreadLocalRandom@3ed371ca]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
03-Feb-2015 08:48:14.362 SEVERE [http-nio-8080-exec-62] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jboss.netty.util.CharsetUtil$2] (value [org.jboss.netty.util.CharsetUtil$2@ecfacab]) and a value of type [java.util.IdentityHashMap] (value [{UTF-8=sun.nio.cs.UTF_8$Decoder@3abe2954}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
03-Feb-2015 08:48:14.882 INFO [http-nio-8080-exec-62] org.apache.catalina.startup.HostConfig.undeploy Undeploying context [/v1]


 Comments   
Comment by kilian.koller [ 03/Feb/15 ]

Sorry, wrong errors pasted. See these:

03-Feb-2015 09:12:30.472 SEVERE [http-nio-8080-exec-75] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.Utilities$3] (value [org.jvnet.hk2.internal.Utilities$3@3705b919]) and a value of type [java.util.WeakHashMap] (value [{public org.glassfish.jersey.message.internal.XmlJaxbElementProvider$General(org.glassfish.hk2.api.Factory,javax.ws.rs.ext.Providers)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@590e679e, public org.glassfish.jersey.server.internal.inject.BeanParamValueFactoryProvider(org.glassfish.jersey.server.internal.inject.MultivaluedParameterExtractorProvider,org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@68aa64d0, private javax.ws.rs.container.ResourceContext org.glassfish.jersey.server.model.internal.VoidVoidDispatcherProvider.resourceContext=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@646fa434, private javax.inject.Provider org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.request=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@7e3814d1, private org.glassfish.jersey.server.model.internal.ResourceMethodDispatcherFactory org.glassfish.jersey.server.model.ResourceMethodInvoker$Builder.dispatcherProviderFactory=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@5420ae1f, public org.glassfish.jersey.server.internal.inject.HeaderParamValueFactoryProvider(org.glassfish.jersey.server.internal.inject.MultivaluedParameterExtractorProvider,org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@6f97dcaf, private org.glassfish.jersey.process.internal.RequestScope org.glassfish.jersey.server.ServerRuntime$Builder.requestScope=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@76c08b6d, public org.glassfish.jersey.message.internal.SourceProvider$SourceWriter(org.glassfish.hk2.api.Factory,org.glassfish.hk2.api.Factory)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@486097f8, public org.glassfish.jersey.message.internal.XmlRootElementJaxbProvider$General(org.glassfish.hk2.api.Factory,javax.ws.rs.ext.Providers)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@19e188bd, public org.glassfish.jersey.message.internal.XmlRootElementJaxbProvider$App(org.glassfish.hk2.api.Factory,javax.ws.rs.ext.Providers)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@48c25d8a, private org.glassfish.hk2.api.ServiceLocator org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider.serviceLocator=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@3aab2c1c, protected javax.ws.rs.ext.Providers com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider._providers=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@76b8b3e6, private javax.inject.Provider org.glassfish.jersey.internal.JaxrsProviders.workers=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@630979ec, public org.glassfish.jersey.server.internal.RuntimeExecutorsBinder$BackgroundSchedulerFactory(org.glassfish.jersey.spi.RuntimeThreadProvider)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@397d560a, public org.glassfish.jersey.server.internal.inject.FormParamValueFactoryProvider(org.glassfish.jersey.server.internal.inject.MultivaluedParameterExtractorProvider,org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@5a5556f5, private javax.inject.Provider org.glassfish.jersey.server.internal.inject.AbstractContainerRequestValueFactory.request=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@69c1e9da, org.glassfish.jersey.server.internal.JerseyResourceContext(org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@412f3b17, public org.glassfish.jersey.server.internal.inject.AsyncResponseValueFactoryProvider(javax.inject.Provider)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@1231f83e, public org.glassfish.jersey.server.internal.inject.ParamConverters$AggregatedProvider(org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@62a3f673, private org.glassfish.hk2.api.ServiceLocator org.glassfish.jersey.server.internal.inject.ParamInjectionResolver.locator=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@44a5cc4, public org.glassfish.jersey.message.internal.XmlCollectionJaxbProvider$General(org.glassfish.hk2.api.Factory,javax.ws.rs.ext.Providers)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@3c8538d9, private org.glassfish.hk2.api.ServiceLocator org.glassfish.jersey.server.internal.inject.BeanParamValueFactoryProvider.locator=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@2168d77f, private javax.ws.rs.core.Configuration org.glassfish.jersey.server.ServerRuntime$Builder.configuration=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@5c85bd4f, private javax.inject.Provider org.glassfish.jersey.server.validation.internal.ValidationExceptionMapper.request=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@aff6667, public org.glassfish.jersey.message.internal.XmlJaxbElementProvider$App(org.glassfish.hk2.api.Factory,javax.ws.rs.ext.Providers)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@1f29c411, private org.glassfish.jersey.server.spi.ExternalRequestScope org.glassfish.jersey.server.ServerRuntime$Builder.externalRequestScope=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@781d3ba4, private org.glassfish.hk2.api.ServiceLocator org.glassfish.jersey.server.model.ResourceMethodInvoker$Builder.locator=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@9038e2d, private org.glassfish.jersey.spi.ExceptionMappers org.glassfish.jersey.server.ServerRuntime$Builder.exceptionMappers=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@78be0d34, public org.glassfish.jersey.message.internal.SourceProvider$DomSourceReader(org.glassfish.hk2.api.Factory)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@29e6577e, private javax.ws.rs.core.Configuration org.glassfish.jersey.server.validation.internal.ValidationExceptionMapper.config=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@383799fd, org.glassfish.jersey.server.model.internal.ResourceMethodDispatcherFactory(org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@2dd01a30, private javax.inject.Provider org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor.containerRequestProvider=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@250f6513, private javax.inject.Provider org.glassfish.jersey.message.internal.DocumentProvider.tf=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@3ec99b6b, private javax.inject.Provider org.glassfish.jersey.message.internal.DocumentProvider.dbf=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@3a35053e, public org.glassfish.jersey.message.internal.XmlRootObjectJaxbProvider$App(org.glassfish.hk2.api.Factory,javax.ws.rs.ext.Providers)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@179989d2, public org.glassfish.jersey.message.internal.XmlRootObjectJaxbProvider$Text(org.glassfish.hk2.api.Factory,javax.ws.rs.ext.Providers)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@49e051cf, public org.glassfish.jersey.server.internal.routing.RuntimeModelBuilder(org.glassfish.jersey.server.model.ResourceMethodInvoker$Builder,org.glassfish.hk2.api.ServiceLocator,org.glassfish.jersey.message.MessageBodyWorkers)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@3b00895b, private org.glassfish.jersey.process.internal.RequestExecutorFactory org.glassfish.jersey.server.ServerRuntime$Builder.asyncExecutorFactory=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@290e77f0, public org.glassfish.jersey.server.internal.inject.WebTargetValueFactoryProvider(org.glassfish.hk2.api.ServiceLocator,javax.ws.rs.core.Configuration)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@7202ac1a, public org.glassfish.jersey.message.internal.SourceProvider$SaxSourceReader(javax.inject.Provider)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@3927e5bc, private java.util.concurrent.ScheduledExecutorService org.glassfish.jersey.server.ServerRuntime$Builder.backgroundScheduler=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@6d2f992, org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory(org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@5cb9af4f, public org.glassfish.jersey.message.internal.XmlCollectionJaxbProvider$App(org.glassfish.hk2.api.Factory,javax.ws.rs.ext.Providers)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@3bbcbabe, public org.glassfish.jersey.server.internal.inject.MultivaluedParameterExtractorFactory(org.glassfish.jersey.server.internal.inject.ParamConverterFactory)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@3db0b270, public org.glassfish.jersey.server.internal.inject.DelegatedInjectionValueFactoryProvider(org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@2cbfc23d, public org.glassfish.jersey.server.internal.inject.QueryParamValueFactoryProvider(org.glassfish.jersey.server.internal.inject.MultivaluedParameterExtractorProvider,org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@3dedd332, public org.glassfish.jersey.internal.ExceptionMapperFactory(org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@635ae77b, public org.glassfish.jersey.server.internal.inject.MatrixParamValueFactoryProvider(org.glassfish.jersey.server.internal.inject.MultivaluedParameterExtractorProvider,org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@5bc1fa52, public org.glassfish.jersey.message.internal.XmlCollectionJaxbProvider$Text(org.glassfish.hk2.api.Factory,javax.ws.rs.ext.Providers)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@9bd653d, private javax.inject.Provider org.glassfish.jersey.internal.JaxrsProviders.mappers=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@5a1a537b, public org.glassfish.jersey.server.internal.inject.PathParamValueFactoryProvider(org.glassfish.jersey.server.internal.inject.MultivaluedParameterExtractorProvider,org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@6ecf167c, public void org.glassfish.jersey.message.internal.AbstractJaxbProvider.setConfiguration(javax.ws.rs.core.Configuration)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@3a08629d, public org.glassfish.jersey.message.internal.XmlJaxbElementProvider$Text(org.glassfish.hk2.api.Factory,javax.ws.rs.ext.Providers)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@587e6c6c, public org.glassfish.jersey.message.internal.XmlRootObjectJaxbProvider$General(org.glassfish.hk2.api.Factory,javax.ws.rs.ext.Providers)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@50f76d93, private javax.inject.Provider org.glassfish.jersey.internal.JaxrsProviders.resolvers=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@469ded07, private org.jvnet.hk2.internal.DynamicConfigurationServiceImpl(org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@3f7873c3, private org.glassfish.hk2.api.ServiceLocator org.glassfish.jersey.internal.inject.ContextInjectionResolver.serviceLocator=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@14ce754c, private javax.inject.Provider org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.validatorProvider=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@7fbe19b3, org.glassfish.jersey.internal.inject.JerseyClassAnalyzer(org.glassfish.hk2.api.ClassAnalyzer,org.glassfish.hk2.api.IterableProvider)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@56e22696, org.glassfish.jersey.server.internal.inject.ParamConverterFactory(org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@2a78a1e2, public org.glassfish.jersey.server.ContainerMessageBodyWorkersInitializer(javax.inject.Provider)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@4d7bd5f4, public org.glassfish.jersey.message.internal.XmlRootElementJaxbProvider$Text(org.glassfish.hk2.api.Factory,javax.ws.rs.ext.Providers)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@42072e69, org.glassfish.jersey.server.internal.inject.EntityParamValueFactoryProvider(org.glassfish.jersey.server.internal.inject.MultivaluedParameterExtractorProvider,org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@5966629, public org.glassfish.jersey.server.internal.process.ServerManagedAsyncExecutorFactory(org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@6a0ea0c8, private org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory org.glassfish.jersey.server.model.ResourceMethodInvoker$Builder.invocationHandlerProviderFactory=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@79491c08, public org.glassfish.jersey.server.internal.inject.CookieParamValueFactoryProvider(org.glassfish.jersey.server.internal.inject.MultivaluedParameterExtractorProvider,org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@246012e, public org.glassfish.jersey.server.internal.inject.JaxbStringReaderProvider$RootElementProvider(javax.inject.Provider,javax.ws.rs.ext.Providers)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@34578861, public org.glassfish.jersey.message.internal.MessageBodyFactory(org.glassfish.hk2.api.ServiceLocator,javax.ws.rs.core.Configuration)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@2bc076c3, org.glassfish.jersey.server.internal.process.ReferencesInitializer(org.glassfish.hk2.api.ServiceLocator,javax.inject.Provider)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@1a5886ef, private javax.ws.rs.core.Configuration org.glassfish.jersey.server.model.ResourceMethodInvoker$Builder.globalConfig=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@2825bbfb, private org.glassfish.hk2.api.ServiceLocator org.glassfish.jersey.server.ServerRuntime$Builder.locator=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@20392a1e}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.

03-Feb-2015 09:12:30.472 SEVERE [http-nio-8080-exec-75] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.Utilities$2] (value [org.jvnet.hk2.internal.Utilities$2@86736b4]) and a value of type [java.util.WeakHashMap] (value [{}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.

03-Feb-2015 09:12:30.472 SEVERE [http-nio-8080-exec-75] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.FactoryCreator$1] (value [org.jvnet.hk2.internal.FactoryCreator$1@56d6a6a9]) and a value of type [java.util.HashSet] (value [[]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Comment by Michal Gajdos [ 03/Feb/15 ]

Does this happen only on Tomcat? Does it happen all the time you undeploy an application?

Comment by kilian.koller [ 03/Feb/15 ]

Hi,
it happens on every reload and undeploy and also on Tomcat 7.0.57. After undeploy, I can only kill Tomcat, stop won't work...

I don't have another application server to test...

Regards

Comment by Michal Gajdos [ 10/Feb/15 ]

Thanks for clarification. Moving to backlog for now.

Comment by Adam Lindenthal [ 25/Feb/15 ]

Hi, this should be drastically improved already (from Jersey 2.16 / hk2 2.4.0-b07 and above), but still present. Tomcat still log a warning and I can still see some memory leaking in profiler with repeated redeploys. I am communicating with hk2 guys and try to resolve this.

Comment by kilian.koller [ 26/Feb/15 ]

Thanks, yes, it's getting better, down to 3 messages now:

— Version 2.15

26-Feb-2015 09:12:59.884 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.FactoryCreator$1] (value [org.jvnet.hk2.internal.FactoryCreator$1@622acb2a]) and a value of type [java.util.HashSet] (value [[]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:12:59.884 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.Utilities$2] (value [org.jvnet.hk2.internal.Utilities$2@acab529]) and a value of type [java.util.WeakHashMap] (value [{}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:12:59.885 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.Utilities$3] (value [org.jvnet.hk2.internal.Utilities$3@59a0850e]) and a value of type [java.util.WeakHashMap] (value [{private javax.validation.Configuration org.glassfish.jersey.server.validation.internal.ValidationBinder$ConfiguredValidatorProvider.validationConfig=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@43b11fc, protected javax.ws.rs.core.SecurityContext com.treefin.srv.rest.resource.AbstractService.sc=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@30fce9ca, public org.glassfish.jersey.internal.ContextResolverFactory(org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@6fc07101, protected javax.servlet.ServletContext com.treefin.srv.rest.resource.AbstractService.servletContext=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@32150102, private javax.ws.rs.container.ResourceContext org.glassfish.jersey.server.validation.internal.InjectingConstraintValidatorFactory.resourceContext=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@6efd424d, protected com.treefin.srv.beans.CassandraConnection com.treefin.srv.rest.resource.AbstractService.cc=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@399844e1, private javax.ws.rs.core.Configuration org.glassfish.jersey.server.validation.internal.ValidationBinder$ConfiguredValidatorProvider.jaxRsConfig=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@55bc62aa, private javax.ws.rs.container.ResourceContext org.glassfish.jersey.server.validation.internal.ValidationBinder$ConfiguredValidatorProvider.resourceContext=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@4f3b740e, private javax.validation.ValidatorFactory org.glassfish.jersey.server.validation.internal.ValidationBinder$ConfiguredValidatorProvider.factory=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@4b50b88e, private javax.ws.rs.ext.Providers org.glassfish.jersey.server.validation.internal.ValidationBinder$ConfiguredValidatorProvider.providers=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@30945249, private javax.validation.Configuration org.glassfish.jersey.server.validation.internal.ValidationBinder$DefaultValidatorFactoryProvider.config=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@60bdfc3, protected org.glassfish.jersey.server.internal.process.ServerProcessingBinder$ContainerRequestFactory(javax.inject.Provider)=org.jvnet.hk2.internal.Utilities$SoftAnnotatedElementAnnotationInfo@12045008}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:12:59.885 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.apache.juli.OneLineFormatter$2] (value [org.apache.juli.OneLineFormatter$2@5cde0e0e]) and a value of type [org.apache.juli.DateFormatCache] (value [org.apache.juli.DateFormatCache@4eca19c6]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:12:59.885 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.apache.juli.OneLineFormatter$1] (value [org.apache.juli.OneLineFormatter$1@16e7221b]) and a value of type [org.apache.juli.OneLineFormatter$1$1] (value [{59=http-nio-8080-exec-9, 85=Cassandra Java Driver worker-0, 63=http-nio-8080-exec-11, 92=http-nio-8080-exec-17, 91=http-nio-8080-exec-16, 93=http-nio-8080-exec-18, 90=http-nio-8080-exec-15, 88=http-nio-8080-exec-13, 89=http-nio-8080-exec-14, 94=http-nio-8080-exec-19}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:12:59.885 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.FactoryCreator$1] (value [org.jvnet.hk2.internal.FactoryCreator$1@622acb2a]) and a value of type [java.util.HashSet] (value [[]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:12:59.886 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.Utilities$2] (value [org.jvnet.hk2.internal.Utilities$2@acab529]) and a value of type [java.util.WeakHashMap] (value [{}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:12:59.886 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.FactoryCreator$1] (value [org.jvnet.hk2.internal.FactoryCreator$1@622acb2a]) and a value of type [java.util.HashSet] (value [[]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:12:59.886 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.Utilities$2] (value [org.jvnet.hk2.internal.Utilities$2@acab529]) and a value of type [java.util.WeakHashMap] (value [{}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:12:59.886 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.FactoryCreator$1] (value [org.jvnet.hk2.internal.FactoryCreator$1@622acb2a]) and a value of type [java.util.HashSet] (value [[]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:12:59.887 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.Utilities$2] (value [org.jvnet.hk2.internal.Utilities$2@acab529]) and a value of type [java.util.WeakHashMap] (value [{}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:12:59.887 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.FactoryCreator$1] (value [org.jvnet.hk2.internal.FactoryCreator$1@622acb2a]) and a value of type [java.util.HashSet] (value [[]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:12:59.887 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.Utilities$2] (value [org.jvnet.hk2.internal.Utilities$2@acab529]) and a value of type [java.util.WeakHashMap] (value [{}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:12:59.887 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.FactoryCreator$1] (value [org.jvnet.hk2.internal.FactoryCreator$1@622acb2a]) and a value of type [java.util.HashSet] (value [[]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:12:59.887 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.Utilities$2] (value [org.jvnet.hk2.internal.Utilities$2@acab529]) and a value of type [java.util.WeakHashMap] (value [{}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:12:59.888 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.FactoryCreator$1] (value [org.jvnet.hk2.internal.FactoryCreator$1@622acb2a]) and a value of type [java.util.HashSet] (value [[]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:12:59.888 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.Utilities$2] (value [org.jvnet.hk2.internal.Utilities$2@acab529]) and a value of type [java.util.WeakHashMap] (value [{}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:12:59.888 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.FactoryCreator$1] (value [org.jvnet.hk2.internal.FactoryCreator$1@622acb2a]) and a value of type [java.util.HashSet] (value [[]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:12:59.888 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.Utilities$2] (value [org.jvnet.hk2.internal.Utilities$2@acab529]) and a value of type [java.util.WeakHashMap] (value [{}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.

– Version 2.16

26-Feb-2015 09:15:31.913 SEVERE [http-nio-8080-exec-19] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.PerLocatorUtilities$1] (value [org.jvnet.hk2.internal.PerLocatorUtilities$1@64d714e]) and a value of type [java.util.WeakHashMap] (value [{}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:15:31.913 SEVERE [http-nio-8080-exec-19] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.PerLocatorUtilities$2] (value [org.jvnet.hk2.internal.PerLocatorUtilities$2@68e71637]) and a value of type [java.util.WeakHashMap] (value [{private org.jvnet.hk2.internal.DynamicConfigurationServiceImpl(org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.SoftAnnotatedElementAnnotationInfo@7bb66949}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
26-Feb-2015 09:15:31.914 SEVERE [http-nio-8080-exec-19] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [v1] created a ThreadLocal with key of type [org.jvnet.hk2.internal.PerLocatorUtilities$2] (value [org.jvnet.hk2.internal.PerLocatorUtilities$2@35d0c8c6]) and a value of type [java.util.WeakHashMap] (value [{private javax.validation.Configuration org.glassfish.jersey.server.validation.internal.ValidationBinder$ConfiguredValidatorProvider.validationConfig=org.jvnet.hk2.internal.SoftAnnotatedElementAnnotationInfo@58fa0833, public org.glassfish.jersey.jaxb.internal.XmlRootObjectJaxbProvider$Text(org.glassfish.hk2.api.Factory,javax.ws.rs.ext.Providers)=org.jvnet.hk2.internal.SoftAnnotatedElementAnnotationInfo@87cebb5, public org.glassfish.jersey.server.internal.inject.BeanParamValueFactoryProvider(org.glassfish.jersey.server.internal.inject.MultivaluedParameterExtractorProvider,org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.SoftAnnotatedElementAnnotationInfo@40c837d2, private javax.ws.rs.container.ResourceContext org.glassfish.jersey.server.model.internal.VoidVoidDispatcherProvider.resourceContext=org.jvnet.hk2.internal.SoftAnnotatedElementAnnotationInfo@73ed51f5, private org.glassfish.jersey.server.model.internal.ResourceMethodDispatcherFactory org.glassfish.jersey.server.model.ResourceMethodInvoker$Builder.dispatcherProviderFactory=org.jvnet.hk2.internal.SoftAnnotatedElementAnnotationInfo@7b5e642b, public org.glassfish.jersey.server.internal.inject.HeaderParamValueFactoryProvider(org.glassfish.jersey.server.internal.inject.MultivaluedParameterExtractorProvider,org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.SoftAnnotatedElementAnnotationInfo@149019b6, private org.glassfish.jersey.process.internal.RequestScope org.glassfish.jersey.server.ServerRuntime$Builder.requestScope=org.jvnet.hk2.internal.SoftAnnotatedElementAnnotationInfo@15e7ca51, public org.glassfish.jersey.jaxb.internal.XmlRootObjectJaxbProvider$App(org.glassfish.hk2.api.Factory,javax.ws.rs.ext.Providers)=org.jvnet.hk2.internal.SoftAnnotatedElementAnnotationInfo@c1c53e1, public org.glassfish.jersey.message.internal.SourceProvider$SourceWriter(org.glassfish.hk2.api.Factory,org.glassfish.hk2.api.Factory)=org.jvnet.hk2.internal.SoftAnnotatedElementAnnotationInfo@46b0175, private javax.ws.rs.container.ResourceContext org.glassfish.jersey.server.validation.internal.InjectingConstraintValidatorFactory.resourceContext=org.jvnet.hk2.internal.SoftAnnotatedElementAnnotationInfo@10a2e5e7, private org.glassfish.hk2.api.ServiceLocator org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider.serviceLocator=org.jvnet.hk2.internal.SoftAnnotatedElementAnnotationInfo@3b3c10e0, protected javax.ws.rs.ext.Providers com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider._providers=org.jvnet.hk2.internal.SoftAnnotatedElementAnnotationInfo@55d1cf3d, private javax.inject.Provider org.glassfish.jersey.internal.JaxrsProviders.workers=org.jvnet.hk2.internal.SoftAnnotatedElementAnnotationInfo@96d0c5b, public org.glassfish.jersey.server.internal.RuntimeExecutorsBinder$BackgroundSchedulerFactory(org.glassfish.jersey.spi.RuntimeThreadProvider)=org.jvnet.hk2.internal.SoftAnnotatedElementAnnotationInfo@ee74d4c, private javax.ws.rs.core.Configuration org.glassfish.jersey.server.validation.internal.ValidationBinder$ConfiguredValidatorProvider.jaxRsConfig=org.jvnet.hk2.internal.SoftAnnotatedElementAnnotationInfo@5587f760, public org.glassfish.jersey.server.internal.inject.FormParamValueFactoryProvider(org.glassfish.jersey.server.internal.inject.MultivaluedParameterExtractorProvider,org.glassfish.hk2.api.ServiceLocator)=org.jvnet.hk2.internal.SoftAnnotatedElementAnnotationInfo@ef472ca, private javax.inject.Provider org.glassfish.jersey.server.internal.inject.AbstractContainerRequestValueFactory.request=org.jvnet.hk2.internal.SoftAnnotatedElementAnnotationInfo@6f1ab89b, private javax.validation.ValidatorFactory org.glassfish.jersey.server.validation.internal.ValidationBinder$ConfiguredValidatorProvider.fa
Comment by Adam Lindenthal [ 27/Feb/15 ]

Hi, after some investigation, I delegated the issue to hk2.

Regards,
Adam

Comment by Adam Lindenthal [ 27/Feb/15 ]

Reopening until upgrading to the future fixed version of hk2.





[JERSEY-2771] Hard to customize freemarker configuration Created: 02/Feb/15  Updated: 23/Feb/15  Resolved: 23/Feb/15

Status: Resolved
Project: jersey
Component/s: extensions
Affects Version/s: 2.16
Fix Version/s: 2.17

Type: Improvement Priority: Minor
Reporter: jeffwilde Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: mvc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

While using the jersey-mvc-freemarker extension, I found it very difficult to customize the freemarker Configuration object that is instantiated within FreeMarkerViewProcess class.

It is possible to construct your own Configuration object and let HK2 resolve it, but some of the basic (and valuable within jersey) configuration is already tied-up within an anonymous Value<Configuration> class in the FreemarkerViewProcessor class. There's no way to reuse that Configuration setup code without duplicating it wholesale.

I propose that FreeMarkerViewProcessor should resolve a true factory instead of firectly requesting a freemarker Configuration object, that'll make it easier to override/extend the configuration mechanism. As a reference, this is how the mustache templating code currently works.



 Comments   
Comment by Michal Gajdos [ 03/Feb/15 ]

GitHub PR: https://github.com/jersey/jersey/pull/141





[JERSEY-2770] Cannot inject ContainerRequestContext in ContainerRequestfilter Created: 31/Jan/15  Updated: 02/Feb/15  Resolved: 02/Feb/15

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 2.14
Fix Version/s: None

Type: Bug Priority: Major
Reporter: phil-lift Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

oracle jdk 7_u71, tomcat 7.0.57, on Mac OSX yosemite



 Description   

Injection of field @Context ContainerRequestContext fails in ContainerRequestfilter fails on start up with : java.lang.IllegalStateException: Not inside a request scope.

It fails on startup of webapp, so I understand that must happen during initialization of the filter, and that during this phase it is are not in a request scope, so it is my impression that is should be injected as a proxy, as default initialization if there is any or default constructor won't access it.

It seems reasonable to inject *request* resources in a **request ** filter.

Tried: making the filter a @Singleton, using @Inject rather than @Context. Same issue.

Workaround for now :

@Inject
private ServiceLocator serviceLocator;
....
ContainerRequestContext containerRequestContext = serviceLocator.getService(ContainerRequestContext.class);

Complete stack

Jan 31, 2015 3:26:22 PM org.glassfish.jersey.internal.Errors logErrors
WARNING: The following warnings have been detected: WARNING: Unknown HK2 failure detected:
MultiException stack 1 of 3
java.lang.IllegalStateException: Not inside a request scope.
	at jersey.repackaged.com.google.common.base.Preconditions.checkState(Preconditions.java:149)
	at org.glassfish.jersey.process.internal.RequestScope.current(RequestScope.java:228)
	at org.glassfish.jersey.process.internal.RequestScope.findOrCreate(RequestScope.java:156)
	at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2270)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
	at org.glassfish.jersey.internal.inject.ContextInjectionResolver.resolve(ContextInjectionResolver.java:116)
	at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:214)
	at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:237)
	at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:360)
	at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
	at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:114)
	at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:102)
	at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
	at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
	at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:153)
	at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2270)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
	at org.glassfish.jersey.internal.inject.Providers.getAllRankedProviders(Providers.java:235)
	at org.glassfish.jersey.server.ApplicationHandler.getProcessingProviders(ApplicationHandler.java:674)
	at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:450)
	at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:163)
	at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:323)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:289)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:286)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:286)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:320)
	at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:315)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:170)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:358)
	at javax.servlet.GenericServlet.init(GenericServlet.java:158)
	at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1284)
	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
	at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
	at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5231)
	at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5518)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1575)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1565)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)
MultiException stack 2 of 3
java.lang.IllegalArgumentException: While attempting to resolve the dependencies of com.liftsession.rest.security.RestSecurityFilter errors were found
	at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:249)
	at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:360)
	at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
	at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:114)
	at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:102)
	at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
	at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
	at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:153)
	at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2270)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
	at org.glassfish.jersey.internal.inject.Providers.getAllRankedProviders(Providers.java:235)
	at org.glassfish.jersey.server.ApplicationHandler.getProcessingProviders(ApplicationHandler.java:674)
	at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:450)
	at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:163)
	at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:323)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:289)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:286)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:286)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:320)
	at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:315)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:170)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:358)
	at javax.servlet.GenericServlet.init(GenericServlet.java:158)
	at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1284)
	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
	at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
	at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5231)
	at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5518)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1575)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1565)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)
MultiException stack 3 of 3
java.lang.IllegalStateException: Unable to perform operation: resolve on com.liftsession.rest.security.RestSecurityFilter
	at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:389)
	at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
	at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:114)
	at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:102)
	at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
	at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
	at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:153)
	at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2270)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
	at org.glassfish.jersey.internal.inject.Providers.getAllRankedProviders(Providers.java:235)
	at org.glassfish.jersey.server.ApplicationHandler.getProcessingProviders(ApplicationHandler.java:674)
	at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:450)
	at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:163)
	at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:323)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:289)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:286)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:286)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:320)
	at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:315)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:170)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:358)
	at javax.servlet.GenericServlet.init(GenericServlet.java:158)
	at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1284)
	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
	at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
	at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5231)
	at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5518)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1575)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1565)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)


Jan 31, 2015 3:26:22 PM org.apache.catalina.core.ApplicationContext log
SEVERE: StandardWrapper.Throwable
MultiException stack 1 of 3
java.lang.IllegalStateException: Not inside a request scope.
	at jersey.repackaged.com.google.common.base.Preconditions.checkState(Preconditions.java:149)
	at org.glassfish.jersey.process.internal.RequestScope.current(RequestScope.java:228)
	at org.glassfish.jersey.process.internal.RequestScope.findOrCreate(RequestScope.java:156)
	at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2270)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
	at org.glassfish.jersey.internal.inject.ContextInjectionResolver.resolve(ContextInjectionResolver.java:116)
	at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:214)
	at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:237)
	at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:360)
	at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
	at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:114)
	at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:102)
	at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
	at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
	at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:153)
	at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2270)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
	at org.glassfish.jersey.internal.inject.Providers.getAllRankedProviders(Providers.java:235)
	at org.glassfish.jersey.server.ApplicationHandler.getProcessingProviders(ApplicationHandler.java:674)
	at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:450)
	at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:163)
	at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:323)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:289)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:286)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:286)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:320)
	at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:315)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:170)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:358)
	at javax.servlet.GenericServlet.init(GenericServlet.java:158)
	at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1284)
	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
	at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
	at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5231)
	at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5518)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1575)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1565)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)
MultiException stack 2 of 3
java.lang.IllegalArgumentException: While attempting to resolve the dependencies of com.liftsession.rest.security.RestSecurityFilter errors were found
	at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:249)
	at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:360)
	at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
	at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:114)
	at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:102)
	at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
	at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
	at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:153)
	at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2270)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
	at org.glassfish.jersey.internal.inject.Providers.getAllRankedProviders(Providers.java:235)
	at org.glassfish.jersey.server.ApplicationHandler.getProcessingProviders(ApplicationHandler.java:674)
	at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:450)
	at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:163)
	at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:323)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:289)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:286)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:286)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:320)
	at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:315)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:170)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:358)
	at javax.servlet.GenericServlet.init(GenericServlet.java:158)
	at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1284)
	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
	at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
	at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5231)
	at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5518)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1575)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1565)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)
MultiException stack 3 of 3
java.lang.IllegalStateException: Unable to perform operation: resolve on com.liftsession.rest.security.RestSecurityFilter
	at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:389)
	at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
	at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:114)
	at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:102)
	at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
	at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
	at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:153)
	at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2270)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
	at org.glassfish.jersey.internal.inject.Providers.getAllRankedProviders(Providers.java:235)
	at org.glassfish.jersey.server.ApplicationHandler.getProcessingProviders(ApplicationHandler.java:674)
	at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:450)
	at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:163)
	at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:323)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:289)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:286)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:286)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:320)
	at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:315)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:170)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:358)
	at javax.servlet.GenericServlet.init(GenericServlet.java:158)
	at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1284)
	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
	at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
	at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5231)
	at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5518)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1575)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1565)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)

Jan 31, 2015 3:26:23 PM org.apache.catalina.core.StandardContext loadOnStartup
SEVERE: Servlet /services threw load() exception
java.lang.IllegalStateException: Not inside a request scope.
	at jersey.repackaged.com.google.common.base.Preconditions.checkState(Preconditions.java:149)
	at org.glassfish.jersey.process.internal.RequestScope.current(RequestScope.java:228)
	at org.glassfish.jersey.process.internal.RequestScope.findOrCreate(RequestScope.java:156)
	at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2270)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
	at org.glassfish.jersey.internal.inject.ContextInjectionResolver.resolve(ContextInjectionResolver.java:116)
	at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:214)
	at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:237)
	at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:360)
	at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
	at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:114)
	at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:102)
	at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
	at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
	at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:153)
	at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2270)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
	at org.glassfish.jersey.internal.inject.Providers.getAllRankedProviders(Providers.java:235)
	at org.glassfish.jersey.server.ApplicationHandler.getProcessingProviders(ApplicationHandler.java:674)
	at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:450)
	at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:163)
	at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:323)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:289)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:286)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:286)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:320)
	at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:315)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:170)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:358)
	at javax.servlet.GenericServlet.init(GenericServlet.java:158)
	at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1284)
	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
	at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
	at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5231)
	at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5518)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1575)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1565)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)


 Comments   
Comment by phil-lift [ 31/Jan/15 ]

I tried to get access to the ContainerRequestContext in a ContainerRequestfilter... as mentioned here

https://jersey.java.net/documentation/latest/security.html#d0e12010

16.1.1.2. Using Security Context in Container Request Filters

The SecurityContext can be directly retrieved from ContainerRequestContext via getSecurityContext() method. You can also replace the default SecurityContext in a request context with a custom one using the setSecurityContext(SecurityContext) method. If you set a custom SecurityContext instance in your ContainerRequestFilter, this security context instance will be used for injection into JAX-RS resource class fields.

If not using my workaround, how else am I supposed to gain access to ContainerRequestContext into a ContainerRequestFilter?

Maybe I am missing out on some core concepts.

Thanks

Comment by phil-lift [ 01/Feb/15 ]

I just realized the requestContext is the one and only param passed to the filter method....
Very stupid of me.

But still, anywhere else the ContainerRequestContext could be injected as proxy.

please close, and have a good laugh





[JERSEY-2769] LoggingFilter always truncates if message size is larger than 4096 Created: 30/Jan/15  Updated: 09/Feb/15

Status: Open
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: backlog

Type: Bug Priority: Minor
Reporter: akanto Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Related code in LoggingFilter.java:

```
private InputStream logInboundEntity(final StringBuilder b, InputStream stream, final Charset charset) throws IOException {
if (!stream.markSupported())

{ stream = new BufferedInputStream(stream); }

stream.mark(maxEntitySize + 1);
final byte[] entity = new byte[maxEntitySize + 1];
final int entitySize = stream.read(entity);
b.append(new String(entity, 0, Math.min(entitySize, maxEntitySize), charset));
if (entitySize > maxEntitySize)

{ b.append("...more..."); }

b.append('\n');
stream.reset();
return stream;
}
```
The stream.read(entity) reads maximum of 8192 bytes in one go (entitySize will be maximum 4096) even if the entity array size is much more larger, therefore the logging output is truncated.



 Comments   
Comment by Michal Gajdos [ 02/Feb/15 ]

You can always set maxEntitySize (in constructor) to a number you find appropriate. I am not sure I follow your last sentence - can you be more specific what you mean by that?

Comment by akanto [ 02/Feb/15 ]

Please ignore the 8192 above it was a mistake, it is 4096.

The maxEntitySize was 10000 in my tests, but the stream.read(entity) was able to read maximum of 4096 bytes from stream, although the stream itself contained more data. To make it easier to understand I have created a screenshot about the debug where you can see that the entity array length is 10001, but only 4096 bytes has been read:

I have tested it with Jersey 2.11, 2.15 and also with latest 2.16-SNAPSHOT, with the same result.

Comment by Michal Gajdos [ 02/Feb/15 ]

Oh, I see. Thanks. This happens when chunked transfer encoding is used and the entity doesn't come at once but in separated chunks. Do you encounter this on server or client (there might be a workaround on client)?

Comment by akanto [ 02/Feb/15 ]

I am using Jersey as client and I cannot have any influence on server. Please let me know whether some workaround might be applied on client side in this case? It is just about logging the rest of the message processing is perfect and I have no issues with it.

Thanks.





[JERSEY-2768] declarative linking traverses up the class hierarchy when used with bean validation Created: 30/Jan/15  Updated: 02/Feb/15

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.15
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: trombka1 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Using the declarative linking and bean validation features together causes problems because the former traverses up the class hierarchy.

Here is a sample test case:
https://github.com/trombka/jersey-declarative-linking-and-validation

The code fails with ConcurrentModificationException. It happens because
org.glassfish.jersey.linking.FieldProcessor traverses through the database driver's (datastax in this case) classes!

This is the place with the problem

FieldProcessor:152

// Recursively process all member fields
for (FieldDescriptor member : instanceDescriptor.getNonLinkFields())

{ processMember(entity, resource, member.getFieldValue(instance), processed, uriInfo,rmc); }

This code uses reflection. When the entity is a collection as well. And if the collection is a guava proxy it can go totally out of its scope just like in case of List<ValidationError>.

public static List<ValidationError> constraintViolationToValidationErrors(final ConstraintViolationException violation) {
return Lists.transform(Lists.newArrayList(violation.getConstraintViolations()),
new Function<ConstraintViolation<?>, ValidationError>() {

@Override
public ValidationError apply(final ConstraintViolation<?> violation)

{ return new ValidationError( violation.getMessage(), violation.getMessageTemplate(), getViolationPath(violation), getViolationInvalidValue(violation.getInvalidValue()) ); }

});
}



 Comments   
Comment by trombka1 [ 30/Jan/15 ]

Patch: https://github.com/jersey/jersey/pull/139





[JERSEY-2767] @Path regexp too greedy Created: 29/Jan/15  Updated: 03/Feb/15

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.13
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: xwibao Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Oracle JDK 1.8.0_31
GlassFish v4.1 b13 nightly 12-15-2014



 Description   

Imagine we have the following REST resource. We want the @GET method handle URLs like both "/1" and "/1/foo", so we use a regexp in @Path:

    @GET
    @Path("/{id}{name: (/\\w+)?}")
    public String get(@PathParam("id") Long id, @PathParam("name") String name) {
        LOG.log(Level.INFO, "GET {0} {1}", new Object[]{id, name});
        return "Foo";
    }

    @DELETE
    @Path("/{id}")
    public void delete(@PathParam("id") Long id) {
        LOG.log(Level.INFO, "DELETE {0}", id);
    }

The @GET method works, but @DELETE gets broken (405 Method Not Allowed). Seems like @GET mapping shadows that of @DELETE, and the request is being routed to @GET handler despite HTTP method annotation.



 Comments   
Comment by xwibao [ 29/Jan/15 ]

Also tested on TomEE (CXF) and WildFly (RESTEasy) - works OK.

I've noticed some other minor differences:

  • if the optional part is present (ex. "/1/foo"), the "name" param value is:
    • TomEE: foo
    • GF: /foo
    • WF: /foo
  • if absent:
    • TomEE: null
    • GF: empty string
    • WF: empty string

If needed, I can supply a working NetBeans project (though I don't see how to attach files here)

Comment by Michal Gajdos [ 03/Feb/15 ]

Thank you for filing the issue, moving to backlog for now.





[JERSEY-2766] Adding Guice integration example Created: 29/Jan/15  Updated: 29/Jan/15

Status: Open
Project: jersey
Component/s: examples
Affects Version/s: 2.15
Fix Version/s: backlog

Type: New Feature Priority: Trivial
Reporter: TheIndifferent Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: pull-request
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

https://github.com/jersey/jersey/pull/133
Pull request contains minimal web application based on Guice-Servlet module, and serving Jersey endpoints directly, without any additional third-party libraries.



 Comments   
Comment by Adam Lindenthal [ 29/Jan/15 ]

Hi Stanislav,

thanks! I will put the issue to our backlog now, until the pull request is reviewed and merged.

Regards,
Adam





[JERSEY-2765] Add support for bean validation groups Created: 29/Jan/15  Updated: 03/Feb/15

Status: Open
Project: jersey
Component/s: None
Affects Version/s: 2.15
Fix Version/s: backlog

Type: New Feature Priority: Major
Reporter: brendan.doyle@intl.verizon.com Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bean-validation
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently Jersey does not support bean validation groups, (see here )

Can this feature be considered ?



 Comments   
Comment by Michal Gajdos [ 03/Feb/15 ]

Hi Brendan,

thank you for your suggestion. We'd certainly like to have support for Bean Validation groups - I'll try to estimate the effort and based on that we'll consider implementing it (but I guess it won't be available very soon). If you were willing to contribute such support let me know, we can try to do this together.

In the meantime - moving to backlog.

Michal





[JERSEY-2764] Entity Filtering - Add support for XML (MOXy) Created: 28/Jan/15  Updated: 28/Jan/15

Status: Open
Project: jersey
Component/s: media
Affects Version/s: 2.3.1, 2.15
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: Michal Gajdos Assignee: Michal Gajdos
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: entity-filtering, xml

 Description   

XML (MOXy)

  • Add support for Entity Filtering.
  • Create Auto-discoverable.





[JERSEY-2763] @PathParam with commas to List<MyObject> Created: 25/Jan/15  Updated: 02/Mar/15

Status: In Progress
Project: jersey
Component/s: core
Affects Version/s: 2.15
Fix Version/s: backlog

Type: Bug Priority: Minor
Reporter: guillaume.l Assignee: Michal Gajdos
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I am trying to understand how the injections work for the variables annotated @PathParameter.

Regarding the injections of parameters in a list, seperated by a coma, I read the extract() method in CollectionExtractor class and your associated test in ParamConverterInternalTest, which returs a List of List.

When we call a simple webservice with the same pattern as your test ( http://.../resource/1,2,3 ), we would like a list of Object with 1,2 and 3 :

@Path("/resource")
public class AppWS {

    @GET
    @Path("/{params}")
    public Response get(@PathParam("params") List<MyObject> params) {
        return Response.status(200).entity("output").build();
    }
}

and

public class MyObject {
    Integer value;
    public MyObject(Integer value) {
        this.value = value;
    }
}

We write a specific ParamConverterProvider which splits the parameter (1,2,3) and return a ParamConverter<List<MyObject>>.

In the webservice class, when the ParamConverter is typed with an object class and therefore returns an object with this same type.

My issue is when the ParamConverter is typed with a List of Object, I expect the same type to be returned, which is not the case.

ie The value of the variable is a List of List of MyObject whereas I would like a List of MyObject.



 Comments   
Comment by Michal Gajdos [ 03/Feb/15 ]

Confirmed that this is a bug. Moving to backlog for now.

In the meantime there is a workaround - inject Collection<MyObject> into your resource method instead of List<MyObject> and update param converter provider accordingly.

Comment by guillaume.l [ 03/Feb/15 ]

Ok thanks, I will try it. Also, my workaround, I've created an object MyObjectList which extends ArrayList<MyObject>.

Comment by saadmufti [ 23/Feb/15 ]

I have similar case for @QueryParam, hopefully the two are related.

I have a QueryParam that is declared as List<Integer> and I want to oevrride the built in support for List which would require passing i something like

param=val1&parm=val2&......&param=valn

This gets quite long and rpepetitive given the limits on URL length, so I wanted to support

param=val1,val2,val3.....,valn

To do this, I wrote up a ParamConverterProvider and registered it, which looks at the passed in rawType and genericType to getConverter and res[ponds with an appropriate ParamConverter if rawType == List.class and if genericType instanceof ParameterizedType && genericType.getActualTypeArguments.length == 1 and genericType.getActualTypeArguments[0] == Integer.class .

The problem is at runtime Jersey never calls my ParamConverterProvider to decide how to handle List<Integer> and persists with the built in behavior, so the current implementation does not allow overriding the built in behavior for List<T> unless you use one of the workarounds mentioned above, like declaring the parameter to be Collection<T> or sub-classing ArrayList<T> with your own type, both of which are not ideal.

So hopefully the fix is the same both for this and the originally reported issue.

Thanks.





[JERSEY-2762] Support Declarative Linking Annotations on Methods Created: 23/Jan/15  Updated: 03/Feb/15

Status: Open
Project: jersey
Component/s: core
Affects Version/s: None
Fix Version/s: backlog

Type: Improvement Priority: Major
Reporter: rpeterson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: declarative-linking, pull-request
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently the @InjectLink and the @InjectLinks annotations have a @Target that is limited to types (Field & Type). In cases where the response object is an interface, and specifically an interface that is represented as a Proxy instance, the annotations can't be used since there are no field declarations on an interface.

This is a request to full support the annotations when they appear on the "getters" within the interface (assuming a corresponding setter is available).



 Comments   
Comment by rpeterson [ 23/Jan/15 ]

Pull Request has been created at https://github.com/jersey/jersey/pull/137





[JERSEY-2761] ResourceConfig packages() does not work on Websphere 7 Created: 23/Jan/15  Updated: 30/Jan/15  Resolved: 28/Jan/15

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 2.5
Fix Version/s: 2.12

Type: Bug Priority: Major
Reporter: engrun Assignee: Michal Gajdos
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JERSEY-2336 Support for META-INF/services discove... Resolved

 Description   

To get Jersey to work on WAS7, we have to register each resource explicitly, as packages('my.package.goes.here') does not work. That is, when using the ResourceConfig class.

The development team has structured the code like this

  • module1
  • application
  • webapp
  • othermodule

The "application" module contains all resources classes and config, whereas the "webapp" module only contains files under src/main/webapp.
So the resourcesclasses are packaged inside a jar in the lib folder when wrapping up the war file

Everything works fine on Tomcat and maven-jetty plugin when using the packages() method, however, all resources fails in WAS7 with a 404 - Not found error.

So might be related to classloaders/package scanning?



 Comments   
Comment by Michal Gajdos [ 28/Jan/15 ]

Seems like this issue duplicated JERSEY-2336 which has been fixed in version 2.12.

Comment by Michal Gajdos [ 28/Jan/15 ]

Closing issue as duplicate. If you have problems with WAS and Jersey 2.12+ feel free to reopen the issue.

Comment by engrun [ 30/Jan/15 ]

Thanks for the info
WAS 7 does not support java7, and if I have understood it correctly, Jersey version 2.7 and upwards are not compatible with Java6.

We'll stick to register each resource explicitly until we upgrade our WAS instance





[JERSEY-2760] TimeZones in DateProvider (via HttpDateFormat) can get corrupted Created: 20/Jan/15  Updated: 26/Jan/15  Resolved: 26/Jan/15

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.18.1, 2.15
Fix Version/s: 2.16

Type: Bug Priority: Critical
Reporter: stoicflame Assignee: Libor Kramolis
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Summary

I've been tracking down a pretty nasty issue that I've isolated to the HttpDateFormat. It boils down to the fact that the readDate method calls SimpleDateFormat.parse, which can result in a change to the timezone of the date format. If that happens, then all subsequent calls to format on that date format don't use GMT, but instead use the last timezone that was {{parse}}d. According to the HTTP spec, GMT must be used.

Suggested Fix

I suggest that the fix be applied at HttpDateFormat line 135: instead of immediately returning the result of f.parse(date), make a call to f.setTimeZone(GMT). The fix should be applied to both Jersey 1 and Jersey 2.

Additional Details

The bug surfaced because we were using Jersey client to read upstream responses which had invalid Last-Modified headers that used a timezone that wasn't GMT. (In my case, it was CEST.) Since both the Jersey client and the Jersey server used DateProviders which ultimately used the same HttpDateFormat, all subsequent responses from my service on that thread changed my Last-Modified headers to use CEST.

Test Case

It's pretty easy to write a test case that reproduces the problem:

    DateProvider dp = new DateProvider();
    Date now = new Date();
    assertTrue(dp.toString(now).endsWith("GMT"));
    Date lastModified = dp.fromString("Thu, 11 Sep 2014 22:30:06 CEST");
    assertTrue(dp.toString(now).endsWith("GMT")); //FAIL!!! (Should succeed)
{java}

 Comments   
Comment by Libor Kramolis [ 21/Jan/15 ]

Thanks for the report. Unfortunately SimpleDateFormat already has GMT time zone set.

Comment by Libor Kramolis [ 21/Jan/15 ]

Calling SimpleDateFormat.parse(...) can change it's time zone. It is necessary set before any use of SDF or reset after parsing String.





[JERSEY-2759] CDI scope mapping issue with singleton resources Created: 19/Jan/15  Updated: 21/Jan/15  Resolved: 19/Jan/15

Status: Resolved
Project: jersey
Component/s: extensions
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: diorcety Assignee: Unassigned
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The class com/sun/jersey/server/impl/cdi/CDIComponentProviderFactory.java may returns a object of type
com.sun.jersey.core.spi.component.ioc.IoCFullyManagedComponentProvider
with getScope return a mapping of CDI scope to jersey ones.
The issue is that this behaviour avoid to inject @RequestScoped field into a @Singleton(jersey on) class. This restriction may be valid with jersey injection but with cdi, the inject objects are proxy, and this behaviour is allowed



 Comments   
Comment by Jakub Podlesak [ 19/Jan/15 ]

Things work as designed here IIUC. But maybe
i do not understand the use case.

As you pointed out, injecting request scoped CDI beans into application scoped CDI beans works just fine. The aim of Jersey 1.x CDI support
is to fulfil JAX-RS requirement to allow CDI beans to work as JAX-RS
components.

Please feel free to re-open or ask this to be re-opened, given you provided
a reproducible test case. Thanks for understanding.

Comment by diorcety [ 19/Jan/15 ]

I didn't mean CDI bean in CDI bean .. here a short example

@javax.enterprise.context.RequestScoped
public MyService {
}

@ManagedBean
@com.sun.jersey.spi.resource.Singleton
public class MyResource {
@InjectParam
private MyService myService;
}
Comment by Jakub Podlesak [ 19/Jan/15 ]

Could you please elaborate? I need a bit more realistic use case. What do you want to achieve?
I do not see any other Jersey annotations than @Singleton and @InjectParam.

The @ManagedBean annotation on MyResource class is misleading. You wanted Jersey singleton, right?
Shall it be a JAX-RS resource class? Could you please explain?

Comment by diorcety [ 19/Jan/15 ]

If i take com.sun.jersey.samples.jersey_cdi.resources.JCDIBeanDependentSingletonResource and add one field

private @InjectParam FormBean pfb;

It will not work. Because as FormBean is a @RequestScoped bean the ResourceComponentProvider#getScope will return ComponentScope.PerRequest( see com/sun/jersey/server/impl/cdi/CDIComponentProviderFactory.java:179).
As the scope equals ComponentScope.PerRequest the injectable factory will return null (com/sun/jersey/server/impl/application/WebApplicationImpl.java:1004)
The injectable factory behaviour is good, the CDI ComponentProviderFactory seems correct too. But as CDI returns a proxy for RequestScope and SessionScope, these proxy can be handled as singleton bean and could be put in a singleton resource like JCDIBeanDependentSingletonResource
It's not a really a bug, but a serious restriction and that avoid to create singleton resource for this case

Comment by Jakub Podlesak [ 20/Jan/15 ]

For that you could utilise CDI @ApplicationScoped contextual bean and have the dynamic proxy injected via CDI directly using javax.inject.Inject. Would not that work for you?

Comment by diorcety [ 21/Jan/15 ]

Yes that should work. But with my way, shouldn't be working too?





[JERSEY-2758] Add support for nested generics to ConfigurableMoxyJsonProvider Created: 19/Jan/15  Updated: 28/Jan/15

Status: Open
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: lasselassi Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When using Moxy to generate JSON responses, types with nested generics (e.g. Collection<TypeA<TybeB>>) do not work, leading to an error being logged:

ERROR [main] MessageBodyWriter not found for media type=application/json, type=class java.util.ArrayList, genericType=java.util.Collection<foo.TypeA<foo.TypeB>>. (at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:245))

This is a known Moxy issue with nested generics which has unfortunately been unresolved since July 2013: https://bugs.eclipse.org/bugs/show_bug.cgi?id=413809

I suspected issue JERSEY-2443 might be caused by the same problem.

We have successfully fixed this problem in production with a patched version of ConfigurableMoxyJsonProvider overwriting MOXyJsonProvider::getDomainClass, as described in the original Moxy issue (comment #2). This way there is no need to wait for this issue to be fixed in Moxy.

I have created a pull request: https://github.com/jersey/jersey/pull/134



 Comments   
Comment by Libor Kramolis [ 19/Jan/15 ]

Signed OCA submitted to 'oracle-ca_us@oracle.com' by Lasse. Waiting for confirmation by Oracle.

Comment by Libor Kramolis [ 28/Jan/15 ]

OCA confirmed.





[JERSEY-2757] Invoke Dynamic Proxy Client with Custom Content-Type Created: 16/Jan/15  Updated: 10/Feb/15

Status: Open
Project: jersey
Component/s: extensions
Affects Version/s: 2.15
Fix Version/s: backlog

Type: New Feature Priority: Major
Reporter: elmar-schwarz Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: pull-request
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

any



 Description   

We need a mechanism to invoke a dynamic client proxy with a specific content-type which is not necessarily identical with the first value in the “@Comsumes” annotation. In analogy, providing a custom “Accept”-Header is already working.

The provided piece of code in pull request https://github.com/jersey/jersey/pull/136 solves the problem for us. It could be considerable to try to match the header-value against the list of consumed content-types of the actual service, but for several reasons we decided to use the provided header without validating it. We left it to the service to make the final decision to accept the content-type or not.



 Comments   
Comment by Adam Lindenthal [ 16/Jan/15 ]

Thank you for creating the issue and the pull request. We will wait, until OCA is officially listed on the OCA page and then review and eventually merge your commits.

Cheers,
Adam

Comment by Libor Kramolis [ 19/Jan/15 ]

Signed OCA submitted to 'oracle-ca_us@oracle.com' by Elmar. Waiting for confirmation by Oracle.

Comment by elmar-schwarz [ 10/Feb/15 ]

OCA confirmed





[JERSEY-2756] @FormParam Resource Argument Uses Query String Parameters when Form Argument Absent Created: 14/Jan/15  Updated: 15/Jan/15  Resolved: 15/Jan/15

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.14
Fix Version/s: None

Type: Bug Priority: Major
Reporter: apjoseph Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

spring tomcat/jetty


Issue Links:
Duplicate
duplicates JERSEY-2637 sensitive params can be exposed in lo... Resolved

 Description   

If one issues the following request:

http://localhost/test/testQueryForm?testParam=abjectFailure

To the resource below:

@POST
@Consumes("application/x-www-form-urlencoded")
@Path("/testQueryForm")
public Response testQueryForm(@QueryParam("testParam") String testQueryParam, @FormParam("testParam") String testFormParam);

It results in dual values of "abjectFailure" for both testFormParam and testQueryParam if testParam is left out of the form.

In some instances this may be desired behavior, but there seems to be no global or resource local method that exists to require "strict" injection of parameters. Lack of strict injection logic could cause unnecessary instability in clients where someone has accidentally used a queryParameter in place of a formParameter should the resource later be changed to grab parameters directly from the form -rather than via annotation injection. Strict injection also helps prevent sensitive information (like passwords) from accidentally being written to server logs due to mistaken usage of queryParams (common error) -as any decently written API would notify the user that their credentials were incorrect or absent and thus nudge them towards discovering the error in their request.

The behavior currently exhibited is also inconsistent since a formParam cannot be used in place of a queryParam (nor can a header param be used in place of either)



 Comments   
Comment by Jakub Podlesak [ 15/Jan/15 ]

We need to come up with an option that would forbid consuming query parameters by forms. Detailed discussion on why things work as they work is included in the duplicated report.





[JERSEY-2755] JERSEY-1708: Implement sub-resource runtime model caching Created: 13/Jan/15  Updated: 13/Jan/15  Resolved: 13/Jan/15

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.14
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jakub Podlesak Assignee: Jakub Podlesak
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

https://java.net/jira/browse/JERSEY-1708

The caching should occur based on the run-time subresource instance Java type information and should provide a cache-entry ageing & configurable cache size to make sure the memory consumption by the cache is manageable.
should primarily work for class based subresources, ideally also for instance based subresources.



 Comments   
Comment by Jakub Podlesak [ 13/Jan/15 ]

wrong JIRA





[JERSEY-2754] JERSEY-2736: Impossible to define ConnectionReuseStrategy using ApacheConnector Created: 13/Jan/15  Updated: 13/Jan/15

Status: Open
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: Jakub Podlesak Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There is no way to define ConnectionReuseStrategy for Apache client (using ApacheConnector) through client config, and the fact that ApacheConnector is creating HttpClientBuilder with default value for boolean "systemProperties" (which is "false"), makes it impossible to use "http.keepAlive" system property.






[JERSEY-2753] UriBuilder should leave relative path relative Created: 13/Jan/15  Updated: 20/Jan/15  Resolved: 20/Jan/15

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.18.1, 2.14
Fix Version/s: 2.16

Type: Bug Priority: Major
Reporter: rdohna Assignee: Libor Kramolis
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
    @Test
    public void jerseyUriBuilderShouldLeaveRelativePathRelative() {
        UriBuilder builder = UriBuilder.fromUri();
        builder.scheme("http");
        builder.replacePath("path");

        assertEquals("http:path", builder.build().toString());
    }

Throws:

org.junit.ComparisonFailure: expected:<http:[]path> but was:<http:[/]path>

The same test passes with Resteasy.



 Comments   
Comment by rdohna [ 13/Jan/15 ]

sorry: it should be UriBuilder builder = UriBuilder.fromUri("");... the empty string is missing. I actually used new UriBuilderImpl(); for 1.18.1, new JerseyUriBuilder(); for 2.14, and ResteasyUriBuilder.fromTemplate(""); for Resteasy.





Glassfish / Jersey throws NPE on startup of versioned app (JERSEY-2626)

[JERSEY-2752] This critical issue still exists Created: 13/Jan/15  Updated: 13/Jan/15

Status: Open
Project: jersey
Component/s: None
Affects Version/s: 2.14
Fix Version/s: backlog

Type: Sub-task Priority: Critical
Reporter: lprimak Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Just trying to get someone to look at this issue again, as it's a critical issue
Thanks






[JERSEY-2751] Entity Filtering with MOXy doesn't work well for Maps Created: 11/Jan/15  Updated: 11/Jan/15

Status: Open
Project: jersey
Component/s: extensions
Affects Version/s: 2.14
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: Michal Gajdos Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: entity-filtering, moxy

 Description   

In case of Maps both keys and values have to be propagated into ObjectGraph, e.g. in a SubGraph the "key.HOME", "value.areaCode", "value.number" have to be present (take a look at entity-filtering-selectable example). This is not the case at the moment. It's possible that this change would require a change in APIs.

Question: How is map processing (and object graphs in particular) affected when a XmlAdapter is used on a Map field?






[JERSEY-2750] @RolesAllowed does not work in JettyHttpContainer Created: 09/Jan/15  Updated: 13/Jan/15  Resolved: 13/Jan/15

Status: Resolved
Project: jersey
Component/s: containers
Affects Version/s: None
Fix Version/s: 2.15

Type: Bug Priority: Major
Reporter: jbecicka2 Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

@RolesAllowed annotation forbids access to everything in JettyHttpContainer. I would say, that this is caused by wrong implementation of SecurityContext in JettyHttpContainer:

https://github.com/jersey/jersey/blob/2.14/containers/jetty-http/src/main/java/org/glassfish/jersey/jetty/JettyHttpContainer.java#L214

@Override
public boolean isUserInRole(final String role)

{ return false; }

It means, that user is not in any role. The fix seems to be trvial:

  • return false;
    + return request.isUserInRole(role);


 Comments   
Comment by jbecicka2 [ 09/Jan/15 ]

I'm sorry. JIRA somehow changed formatting.

Anyway the fix is (I would say) just return request.isUserInRole(role) instead of false.

Comment by Jakub Podlesak [ 13/Jan/15 ]

Fixed in the master branch.





[JERSEY-2749] RolesAllowedDynamicFeature and sub-resources Created: 07/Jan/15  Updated: 13/Jan/15

Status: Open
Project: jersey
Component/s: security
Affects Version/s: 2.14
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: lmazuel Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hi,
I try to use RolesAllowedDynamicFeature this way:

ViewResource.java
@Path("/view")
@RolesAllowed("myrole")
@Singleton
public class ViewResource {

    	@Path("/subresources")
	public Class<SubResource> subresources() {
		return SubResource.class;
	}
}
SubResource.java
@Singleton
public class SubResource

    /* My resources */
}

I have registered RolesAllowedDynamicFeature.

But the role is never applied. I try to debug, I have seen that the "subresources" method is never given to the "configure" method of RolesAllowedDynamicFeature. Then, there is no chance to register the "RolesAllowedRequestFilter" filter...

If I use my role directly in the subresource, all goes fine.






[JERSEY-2748] When running grizzly http server on z/OS, incoming JAX-RS based REST request URIs are incorrectly converted from UTF-8 to EBCDIC default charset and thus lead to HTTP 404 Created: 07/Jan/15  Updated: 15/Jan/15  Resolved: 15/Jan/15

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 2.6
Fix Version/s: 2.16

Type: Bug Priority: Major
Reporter: reinhold.fuereder Assignee: Adam Lindenthal
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

z/OS, grizzly 2.3.6 http server with jersey 2.6 JAX-RS implementation



 Description   

From GRIZZLY-1726 which I filed for/in the wrong project according to @oleksiys:

In my environment (see above) URL requests (via curl) like this:

curl http://<zos hostname>:<port>/rse/mgmt/version -4

correctly comes in as ".../rse/mgmt/version" (UTF-8 I guess), before being converted to EBCDIC (cp1047) and thus no JAX-RS REST service is found for that weird characters and thus returns HTTP status code 404

I think the culprit code is one word/constant in
org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.getRequestUri(URI, Request):

    private URI getRequestUri(URI baseUri, Request grizzlyRequest) {
        // TODO: this is terrible, there must be a way to obtain the original request URI!
        String originalUri = UriBuilder
                .fromPath(
                        grizzlyRequest.getRequest().getRequestURIRef().getOriginalRequestURIBC()
                                .toString(Charsets.DEFAULT_CHARSET)).build().toString();
...

I think/claim, instead of Charsets.DEFAULT_CHARSET it should be Charsets.Charsets.UTF8_CHARSET (or even null to fallback to UTF-8). Because the incoming request URL from the request (buffer?) is already good as it is.

My follow-up comment:

Please note that I just tried/applied this mini change by patching my (old) grizzly jar ("jersey-container-grizzly2-http-2.6.jar") and it worked as expected...



 Comments   
Comment by oleksiys [ 07/Jan/15 ]

I think Charsets.ASCII_CHARSET should work for you, can you pls. try?

Comment by reinhold.fuereder [ 08/Jan/15 ]

Yes, I can: you are right, Charsets.ASCII_CHARSET also works as expected (so far...)


Of course in the original description I meant Charsets.UTF8_CHARSET instead of Charsets.Charsets.UTF8_CHARSET...

Comment by Adam Lindenthal [ 15/Jan/15 ]

Hi, thank you for submitting this and thanks Alex for the hint.
The change has been merged into master branch and the fix will be available in 2.16.

Regards,
Adam

Comment by oleksiys [ 15/Jan/15 ]

Thank you Adam!





[JERSEY-2747] Update Migration Guide Created: 05/Jan/15  Updated: 05/Jan/15

Status: Open
Project: jersey
Component/s: docs
Affects Version/s: 2.14
Fix Version/s: backlog

Type: Improvement Priority: Major
Reporter: Michal Gajdos Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

By Guillaume Drouet:






[JERSEY-2746] RuntimeExceptions thrown by request filters do not propagate when using submit() with Futures. Created: 02/Jan/15  Updated: 14/Jan/15

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.13
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: mrandall_cerner_com Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The run() method in ClientRuntime.submit(...) invokes Stages.process(...) with no catch block for runtime exceptions. As a result, when a runtime exception is thrown in a filter, the submitted runnable dies. This throwable is never passed back to the response callback. This can leave to orphaned async processes, and wreaks havoc when attempting to troubleshoot bugs as the exceptions are swallowed.

Per 6.7.2 / 4.5.2 of the JAX-RS spec, the exception should be re-wrapped in a ProcessingException, and set as the failure in the corresponding response callback, which in turn will be re-wrapped in an ExecutionException per Invocation.submit()'s javadoc.






[JERSEY-2745] Package Scanning delimiter is inconsistent with spec. Created: 02/Jan/15  Updated: 28/Jan/15

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.9, 2.14
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: martin.jamszolik Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 14.04
Tomcat on Oracle 1.7 JVM
Websphere 8.5.5.3 on 1.7 IBM JVM



 Description   

Here is the scenario:
We have the following packages that contain JAX-RS classes
com.bipt.tiva.rs
com.bipt.tiva.jaxrs
com.policyport.rs.open

However, see below how it's the only way we where able to have the scanning work in Webpshere 8.5 as described in web.xml

   <init-param>
            <param-name>jersey.config.server.provider.packages</param-name>
            <param-value>
                com.bipt.tiva.rs/,com.bipt.tiva.jaxrs/,com.policyport.rs.open/
            </param-value>
        </init-param>

Notice the forward slash before "comma" as the delimiter. That's the only way. We tried ";" "empty space","\n" as per spec but nothing else worked.

Fortunately, the "foward slash" still worked on tomcat, so for now we adopted the solution.

I am sure though that this is not intentional and is in fact a bug. Unless you guys can shed some light on this.



 Comments   
Comment by martin.jamszolik [ 02/Jan/15 ]

The full servlet configuration looks like this

<servlet> 
       <servlet-name>isf_rest_api_jersey2</servlet-name>
       <servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>         
       <init-param>
            <param-name>jersey.config.server.provider.packages</param-name>
            <param-value>
                com.bipt.tiva.rs/,com.bipt.tiva.jaxrs/,com.policyport.rs.open/
            </param-value>
        </init-param>
        <init-param>
            <param-name>jersey.config.server.provider.scanning.recursive</param-name>
            <param-value>true</param-value>
        </init-param>
        <init-param>
            <param-name>javax.ws.rs.Application</param-name>
            <param-value>com.bipt.tiva.lib.JerseyISFApplication</param-value>
        </init-param>     
        <load-on-startup>2</load-on-startup>  
</servlet>   
Comment by brad103 [ 28/Jan/15 ]

I'm not sure if it's inconsistent with the spec, but it is inconsistent with IBM's interpretation of it.

From what I've seen, there's a classloader difference between Oracle Java and IBM Java which manifests in com.ibm.ws.classloader.CompoundClassLoader. In short,

  • org.glassfish.jersey.server.internal.scanning.PackageNamesScanner#init() asks the classloader for a base URI for a package
  • The class firsts converts the supplied package names from dot notation to slashes (eg my.pkg.here becomes my/pkg/here)
  • IBM's classloader will not return packages unless the path has a trailing slash (eg my/pkg/here - this is why the trailing slash worked in the example above)

There is some discussion that setting the JVM parameter com.ibm.ws.classloader.strict changes this behaviour to not need the trailing slash, but we haven't had any joy with that.

Our workaround is to use the same package descriptions as Martin described. Note we are using package scanning defined in a ResourceConfig class rather than web.xml, but the result is the same.

Refs:
http://code.google.com/p/reflections/issues/detail?id=158#c3
http://www-01.ibm.com/support/knowledgecenter/SSAW57_7.0.0/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/xrun_jvm.html?cp=SSAW57_7.0.0%2F3-16-5-448
https://blogs.oracle.com/bhaktimehta/entry/ibm_jdk_and_classloader_getresources (possibly related)

We're on WAS 8.5.0.1 and Java 7





[JERSEY-2744] @Resource injection doesn't work when Jersey & CDI are used in standalone mode Created: 01/Jan/15  Updated: 14/Jan/15

Status: Open
Project: jersey
Component/s: containers
Affects Version/s: 2.15
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: Michal Gajdos Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See PerApplicationBeanTest in cdi-webapp example. @Resource injection will not work on SE, need to add a custom extension to make this work with Grizzly.



 Comments   
Comment by Adam Lindenthal [ 14/Jan/15 ]

Moving to backlog.





[JERSEY-2743] Jersey Async Client doesn't work with Jetty connector (jetty client >= 9.1.4.v20140401) Created: 01/Jan/15  Updated: 13/Jan/15

Status: Open
Project: jersey
Component/s: connectors
Affects Version/s: 2.14
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: Michal Gajdos Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Fix for Bug 430808 affected jersey-jetty-connector in a way it can't process async requests anymore. Underlying OutputStreamContentProvider is locked/blocked after write (and flush) is called and never woken up.

TODO: Remove jetty-maven-plugin version in rx-client-java8-webapp example when this issue is fixed.






[JERSEY-2742] LoggingFilter's LoggingStream does not delegate flush() Created: 01/Jan/15  Updated: 14/Jan/15  Resolved: 14/Jan/15

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: None
Fix Version/s: 2.16

Type: Bug Priority: Major
Reporter: thiru_mg Assignee: Libor Kramolis
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If entity logging is enabled, the private inner class LoggingStream wraps the ContextResponse object's entity stream. It saves the contents of the response body in a local buffer so that it can be logged later. It achieves this by overriding write(int). This method saves the byte being written into an internal ByteArrrayOutputStream as well as delegating to the original entity stream. But it does not override flush(). So if the original entity stream was buffering its content, it does get flushed when the client calls flush.

The problem manifests if one uses Jerseys servlets, enables entity logging and sends entities larger than 8192 bytes. The exact behavior depends on the servlet container. With Jetty, the actual entity is replaced by Jetty's error HTML contents.

So we need to override flush() and delegate to the original entity stream's flush method. Even though close() should also be overridden (and delegated), there is no known way the problem manifests itself. A cleaner solution is to make LoggingStream extend java.io.FilterOutputStream instead of directly extending java.io.OutputStream. Then no other change is required.



 Comments   
Comment by thiru_mg [ 01/Jan/15 ]

A fix is at https://gist.github.com/thiru-verticloud/59116608123d6fff0aa1

I verified that the fix indeed fixes the problem that I saw with logging entities with more than 8192 bytes while using Jersey servlet on Jetty.

Comment by Libor Kramolis [ 14/Jan/15 ]

Thanks a lot. Suggested fix looks good.





[JERSEY-2741] Cannot serialize int/Integer value as JSON Created: 29/Dec/14  Updated: 13/Jan/15  Resolved: 13/Jan/15

Status: Resolved
Project: jersey
Component/s: media
Affects Version/s: 2.14
Fix Version/s: None

Type: Bug Priority: Major
Reporter: janario Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish 4.1 and jersey-media-moxy



 Description   

I've created a simple resource that return an int value.

@GET @Path("total") @Produces(MediaType.APPLICATION_JSON)
public int total()

{ return 10; }

When I access /total I receive an error:
[2014-12-29T15:01:16.293-0200] [glassfish 4.1] [SEVERE] [] [org.glassfish.jersey.message.internal.WriterInterceptorExecutor] [tid: _ThreadID=32 _ThreadName=http-listener-1(4)] [timeMillis: 1419872476293] [levelValue: 1000] [[
MessageBodyWriter not found for media type=application/json, type=class java.lang.Integer, genericType=int.]]

As I see It should support the basic values as default.



 Comments   
Comment by Jakub Podlesak [ 13/Jan/15 ]

a standalone int is not a valid JSON, closing this as invalid





[JERSEY-2740] Null parameter value of a http request with post method Created: 29/Dec/14  Updated: 14/Jan/15

Status: Open
Project: jersey
Component/s: None
Affects Version/s: 2.14
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: wangmingjun Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: incomplete
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I've developed an api server by means of JAX-RS with jersey 2.14. And i've been testing the api via HttpURLConnection within junit. I found that when i was emulating a form submit with content type set "application/x-www-form-urlencoded; charset=UTF-8", the api server just could not got the right parameter value, just null!
But when i switched the same submit to another servlet(written via servlet 3.0 API), the servlet could retrieve the right value i passed to.



 Comments   
Comment by Michal Gajdos [ 13/Jan/15 ]

Can you post a resource class that is failing to process your request and a client (HttpURLConnection) code?

Comment by wangmingjun [ 14/Jan/15 ]

The jersey 2.14 resource class(not working as expected):

WelcomeAPI.java
// Some comments here
@Path("/welcome")
public class WelcomeAPI{
	private static Logger logger = LoggerFactory.getLogger(WelcomeAPI.class);
	
	public Response service(HttpServletRequest req){
		String name = req.getParameter("name");
		
		logger.debug("welcoming {}", name);
		
		JsonObjectBuilder builder = Json.createObjectBuilder();
		Jsons.addNullable(builder, "welcome", name);
		
		return Response.ok(builder.build().toString(), MediaType.APPLICATION_JSON + "; charset=UTF-8").build();
	}
	
	@POST
	@AccessKeyRequired
	public Response execute(@Context HttpServletRequest req){
		try{
			return service(req);
		}catch(Exception e){
			logger.error("Error occured while servicing {}", req.getRequestURI(), e);
			
			return Response.status(500).build();
		}
	}
}


The comparing servlet(working as expected):

Bar.java
@WebServlet("/hello")
public class SampleServlet extends HttpServlet{
	private static final long serialVersionUID = 1L;
	private static Logger logger = LoggerFactory.getLogger(SampleServlet.class);
	
	public void doPost(HttpServletRequest req, HttpServletResponse resp) throws IOException{
		String name = req.getParameter("name");
		
		logger.debug("hello {}", name);
		
		JsonObjectBuilder builder = Json.createObjectBuilder();
		Jsons.addNullable(builder, "hello", name);
		
		resp.getWriter().write(builder.build().toString());
	}
}


The client code:

_WelcomeAPI.java
@RunWith(JUnit4.class)
public class _WelcomeAPI extends TestCase{
	public String t(String loc) throws IOException{
		URL url = new URL(loc);
		
		HttpURLConnection conn = (HttpURLConnection) url.openConnection();
		
		conn.setDoInput(true);
		conn.setDoOutput(true);
		conn.setRequestMethod("POST");
		
		conn.setRequestProperty("Content-Type", "application/x-www-form-urlencoded");
		
		/* send request */
		OutputStream os = conn.getOutputStream();
		os.write("name=billy".getBytes());
		os.flush();
		
		/* read response */
		InputStream is = conn.getInputStream();
		ByteArrayOutputStream baos = new ByteArrayOutputStream();
		byte[] buf = new byte[128];
		int c = -1;
		while((c = is.read(buf)) != -1)
			baos.write(buf, 0, c);
		String resp = new String(baos.toByteArray());
		
		return resp;
	}
	
	@Test
	public void welcome() throws IOException{
		String loc = "http://127.1:8080/share/sample/welcome";
		String resp = t(loc);
		System.out.println(resp);
		
		JsonObject json = Json.createReader(new ByteArrayInputStream(resp.getBytes())).readObject();
		assertFalse(json.isNull("welcome"));
	}
	
	@Test
	public void hello() throws IOException{
		String loc = "http://127.1:8080/share/hello";
		String resp = t(loc);
		System.out.println(resp);
		
		JsonObject json = Json.createReader(new ByteArrayInputStream(resp.getBytes())).readObject();
		assertFalse(json.isNull("hello"));
	}
}


If you run the client code within junit4, you would probably get something like this:

junit output
{"hello":"billy"}
{"welcome":null}




[JERSEY-2739] "NameBinding" results in a deployment failure Created: 29/Dec/14  Updated: 06/Jan/15  Resolved: 06/Jan/15

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 2.14
Fix Version/s: 2.15

Type: Bug Priority: Major
Reporter: wangmingjun Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: deployment, failure, namebinding
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, Tomcat 7.0.55, Eclipse for Java EE Edition(64bit)



 Description   

I'm using NameBinding to define an annotation(named "AccessKeyRequired") used to decorate a filter(named "AccessKeyFilter") for security verify. But I found that this defined annotation could only be placed on the Application subclass's class level, while any attempt to place it on a resource class's class or method level would result in a deployment error reporting an IllegalStateException.






[JERSEY-2738] Repeated Invocation.invoke() after failed HTTP transmission fails with "Stream provider has already been initialized" Created: 27/Dec/14  Updated: 02/Feb/15

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.14
Fix Version/s: backlog

Type: Bug Priority: Critical
Reporter: mkarg Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: client
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK 8u40, Win 7 Pro SP1, 64 Bit


Attachments: Java Source File RepeatedInvocationTest.java    

 Description   

The Invocation interface provides a clean separation between the provider of an invocation and the actual invoker. The latter's sole task is to implement a stable solution for actual HTTP invocations. Hence, it is up to him to repeat failed invocations.

Unfortunately, in case Invocation.invoke() failed (e. g. when the target server is not running or is blocked by a firewall etc.) then a repeated Invocation.invoke() on the same invocation will fail, too – even when the target server is active and reachable meanwhile.

Jersey is simply printing an error message into the log, but fails to attempt another HTTP connection to the server. I can verify this behaviour using a simple JavaFX ScheduledService which automatically repeats Invocation.invoke() in case of any exception. In fact, this should work as it is the stereotypical use case for the separation of invocation preparation and invocation execution. Unfortunately it does not.



 Comments   
Comment by Adam Lindenthal [ 14/Jan/15 ]

Hi, thanks for submitting the issue.
Would you please be able to provide some minimalistic testcase?
Actually I was not able to reproduce it, but maybe I just did not understand it correctly. What I did was a really trivial and naive test, that simulated the failure (unreachable server) by short client timeouts and slow response from the resource. I know this is not precise, as the connection was already established, but as an approximation, I was hoping this would be sufficient.
After the first invocation fails, the tests calls invoke on the same Invocation instance multiple times again and the request normally works.

I will attach the file shortly - please let me know if there is an easy way how to change the code in order to reproduce your problem.

Many thanks,
Regards
Adam

Comment by mkarg [ 15/Jan/15 ]

In fact I do not know how I can write a program that simulates the actual problem: The actual cause is that the client computer is connected to the internet, while the server is not temporarily (due to a missing VPN link). The VPN link is then provided while the client already failed, but even after that, the client fails still with subsequent {{invoke}}s. When I then stop the JVM and start it again, the client can connect to the server. Hence I suppose that the problem might be in a deeper networking level (TCP? IP?). I do not know how I could simulate that in a Java test case.

Comment by Libor Kramolis [ 19/Jan/15 ]

Have you tried to create new instance of Invocation if a behaviour is same? I'm just curious if a failing is "cached" in Invocation instance or another part, e.g. Connector instance.

It is really important for us to reproduce the problem. We really appreciate any reproducible test case. It must not necessarily be unit test. May be it is not so hard. Just one jetty-like server project and another Java SE project that tries to periodically invoke server-side API. And we start with running client side and it obviously fails. But whenever I start server-side module the running client-side still fails. Is it correct assumption?

Comment by mkarg [ 19/Jan/15 ]

Thank you for picking up this issue. Unfortunately my stack of open source reproduction test cases is rather huge, so it might take a while until I can send the test case. Please don't mind if it needs a month or two until I can provide it. I will look into it, but it definitively really won't happen in the next days.

Comment by Libor Kramolis [ 20/Jan/15 ]

Ok, I understand. Could you just check my assumptions? Preparing reproducible test case takes more time. But would you be able to just try to use always new Invocation instance?





[JERSEY-2737] Injection into Feature from Binder registered in another Feature does not work Created: 25/Dec/14  Updated: 14/Jan/15

Status: Open
Project: jersey
Component/s: None
Affects Version/s: 2.14
Fix Version/s: backlog

Type: Bug Priority: Minor
Reporter: cgc Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Jersey 2.14 with jersey-container-grizzly2-http
Java 8u25



 Description   

Bug JERSEY-2581 apparently fixed injection into Features, but only if the Binder is registered in the main ResourceConfig. If the Binder is registered by another Feature, injection doesn't work.

Modified test case copied from https://github.com/jersey/jersey/blob/master/core-common/src/test/java/org/glassfish/jersey/model/internal/CommonConfigTest.java

public class JerseyInjectTest {

    private CommonConfig config;

    @Before
    public void setUp() throws Exception {
        config = new CommonConfig(null, ComponentBag.INCLUDE_ALL);
    }

    public static class InjectMe {
    }

    public static class InjectIntoFeatureInstance implements Feature {
        @Inject
        private InjectMe injectMe;
        @Override
        public boolean configure(final FeatureContext context) {
            context.property("instance-injected", injectMe != null);
            return true;
        }
    }

    public static class InjectFeature implements Feature {
        @Override
        public boolean configure(FeatureContext context) {
            context.register(new AbstractBinder() {
                @Override
                protected void configure() {
                    bind(new InjectMe());
                }
            });
            return true;
        }
    }

    @Test
    public void testFeatureInjections() throws Exception {
        config.register(new InjectFeature())
                .register(new InjectIntoFeatureInstance());

        final ServiceLocator locator = Injections.createLocator();
        config.configureMetaProviders(locator);
        assertThat("Feature instance not injected", config.getProperty("instance-injected").toString(), is("true"));
    }
}





[JERSEY-2736] Impossible to define ConnectionReuseStrategy using ApacheConnector Created: 25/Dec/14  Updated: 13/Jan/15

Status: Open
Project: jersey
Component/s: connectors
Affects Version/s: 2.13
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: TheTweak07 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There is no way to define ConnectionReuseStrategy for Apache client (using ApacheConnector) through client config, and the fact that ApacheConnector is creating HttpClientBuilder with default value for boolean "systemProperties" (which is "false"), makes it impossible to use "http.keepAlive" system property.



 Comments   
Comment by TheTweak07 [ 25/Dec/14 ]

For Jersey client with ApacheConnector of course.





[JERSEY-2735] Dynamic entity filtering incorrectly includes parent fields in children Created: 23/Dec/14  Updated: 13/Jan/15

Status: Open
Project: jersey
Component/s: extensions
Affects Version/s: 2.14
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: sbalmos Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: entity-filtering
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The dynamic entity filtering notation for the SelectableEntityFilteringFeature notes using dot-notation for selecting fields of child entities. However, if a child entity has a field named the same as the parent entity, that field is included even if it is not explicitly requested. Example is below:

@XmlRootElement
public class BigEntity

{ private Long id; private String name; private Date creationDate; private List<TestType> testTypes; ... }

@XmlRootElement
public class TestType

{ private Long id; private String value; ... }

if the entity filtering query parameter = "id,name,testTypes.value", then the resultant rendered JSON will include the id field of the testTypes children, even though it is not requested.






[JERSEY-2734] FilesScanner Tokenizer does not work well with input containing delimiter characters Created: 21/Dec/14  Updated: 22/Dec/14

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.13, 2.14
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: Philipp91 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, Java 8



 Description   

this.files = new File[Tokenizer.tokenize(fileNames, Tokenizer.COMMON_DELIMITERS).length];
for (int i = 0; i < files.length; i++)

{ files[i] = new File(fileNames[i]); }

This code has multiple problems:

  • The result of Tokenizer.tokenize is not used, only the length is taken. For the input "someFile;anotherFile", this leads to a ArrayIndexOutOfBoundsException, because the files-Array has size 2, but only fileNames[0] can be read, which won't even resolve to a file, because it has not been split.
  • COMMON_DELIMITERS contains the space character, which can easily be contained in a single file name. On Windows, this is quite common with "C:\Program Files\...".


 Comments   
Comment by Jakub Podlesak [ 22/Dec/14 ]

Although the issue does not contain a real use case, the code is indeed wrong and should be fixed.





[JERSEY-2733] @BeanParam annotated properties not included autogenerated wadl Created: 18/Dec/14  Updated: 19/Dec/14

Status: Open
Project: jersey
Component/s: extensions
Affects Version/s: 2.14
Fix Version/s: backlog

Type: Bug Priority: Minor
Reporter: apjoseph Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When using the @BeanParam annotation, annotated properties fail to show up in the generated application.wadl,



 Comments   
Comment by Adam Lindenthal [ 19/Dec/14 ]

Hi apjoseph,

thanks for creating the issue. You are right, the generated wadl looks different when having the parameters injected into separate class using @BeanParam.
The parameters shows up in the wadl, however the fact, that the method accepts concrete params is not documented there.

I am moving the issue to backlog, so that we can plan the work on it in one of the future sprints.

Regards,
Adam





[JERSEY-2732] Service Factories bound in Application got created second time on application shutdown Created: 12/Dec/14  Updated: 03/Feb/15

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.13
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: roytmana Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: hk2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK 1.7, Tomcat 7


Attachments: Java Source File RepeatedInvocationTest.java    

 Description   

It maybe something I am doing incorrectly but essentially for every service I bind using factory in singleton scope the factory gets created once again on shutdown (which also has effect of creation singe instance of the service it provides)

public class SearchApplication extends ResourceConfig {
  private static final Log LOG = LogFactory.getLog(SearchApplication.class);
  @NotNull private final ServiceLocator locator;

  @Inject
  public SearchApplication(@NotNull final ServiceLocator locator) {
    super(JDOFeature.class, RolesAllowedDynamicFeature.class, JacksonObjectMapperProvider.class, JacksonFeature.class);
    this.locator = locator;
    packages(ElasticSearchService.class.getPackage().getName(), JdoResource.class.getPackage().getName());
    register(new AbstractBinder() {
      @Override
      protected void configure() {
        bindFactory(UserPrincipalFactory.class).to(UserPrincipal.class).in(Singleton.class);
      }
    });
    register(new AbstractBinder() {
      @Override
      protected void configure() {
        bindFactory(ElasticSearchClientFactory.class).to(Client.class).in(Singleton.class);
      }
    });
    register(new AbstractBinder() {
      @Override
      protected void configure() {
        bindFactory(JacksonObjectMapperProvider.class).to(ObjectMapper.class).in(Singleton.class);
      }
    });
    register(new AbstractBinder() {
      @Override
      protected void configure() {
        bindFactory(IndexerServiceFactory.class).to(IndexerService.class).in(Singleton.class);
      }
    });

  private static class UserPrincipalFactory implements Factory<UserPrincipal> {
    private final @NotNull Provider<HttpServletRequest> requestProvider;

    @Inject
    public UserPrincipalFactory(@NotNull Provider<HttpServletRequest> requestProvider) {
      this.requestProvider = requestProvider;
      LOG.info("Creating UserPrincipalFactory");
    }

    @Override public UserPrincipal provide() {
      return new UserPrincipal(requestProvider.get());
    }

    @Override public void dispose(UserPrincipal instance) {
      LOG.info("UserPrincipalFactory.dispose(" + instance + ")");
    }
  }
INFO  12/12/14 16:32:36 reports.SearchApplication - onShutdown
INFO  12/12/14 16:32:36 reports.SearchApplication - Creating ElasticSearchClientFactory
INFO  12/12/14 16:32:36 reports.SearchApplication - ElasticSearchClientFactory.dispose(org.elasticsearch.client.node.NodeClient@68f521ae)
INFO  12/12/14 16:32:36 reports.SearchApplication - Creating UserPrincipalFactory
INFO  12/12/14 16:32:36 reports.SearchApplication - Creating IndexerServiceFactory@11631836
INFO  12/12/14 16:32:36 reports.IndexerService - IndexerService@ca8a25 instantiated
INFO  12/12/14 16:32:36 reports.SearchApplication - IndexerServiceFactory@11631836 instantiated with indexerService=gov.gao.gctrack.reports.IndexerService@ca8a25
INFO  12/12/14 16:32:36 reports.SearchApplication - IndexerServiceFactory@11631836.dispose(gov.gao.gctrack.reports.IndexerService@72c8baa3)
INFO  12/12/14 16:32:36 reports.IndexerService - Closing IndexService: gov.gao.gctrack.reports.IndexerService@72c8baa3


 Comments   
Comment by Adam Lindenthal [ 14/Jan/15 ]

Hi Roytmana,

thank you for submitting the issue. I've been trying to reproduce the described behaviour, unfortunately with no success so far.
Would you be able to provide some runnable minimalistic reproducer testcase?
I created temporarily just a small testcase based on our test framework (runs against grizzly), so I did not try to deploy it as a war on Tomcat, but I don't see why it should behave that much differently. And both provide() and dispose() methods in the dummy Factory were called only once.
If we had some more complete testcase, we could find the origin of the issue easier.
Or, at least the relevant part (hk2, jersey and a little bit of the outer environment) of the stack trace might help (take it from the debugger or simply print it out in the provide() method) - we might see then how was the provide() method called for the second time.

Regards,
Adam

Comment by Michal Gajdos [ 03/Feb/15 ]

test case attached, moving to backlog for now.





[JERSEY-2731] Support for creating client-side representation of a resource for asynchronous calls Created: 12/Dec/14  Updated: 23/Jan/15  Resolved: 23/Jan/15

Status: Resolved
Project: jersey
Component/s: extensions
Affects Version/s: None
Fix Version/s: icebox

Type: New Feature Priority: Major
Reporter: brunopalos Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: async, client
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The current implementation of WebResourceFactory don't create resources that supports HTTP asynchronous clients.



 Comments   
Comment by brunopalos [ 12/Dec/14 ]

Hi guys,

I would like to discuss the need of this feature and I would like to implement it, if it becomes decided that should go forward.

The current implementation of WebResourceFactory only support synchronous calls and it would be great to have an identical feature for asynchronous calls, which would avoid creating custom code on the users side to mask the boiler plate code of creating asynchronous clients.

I have a prototype implementation on my side but I don't like having specific annotated interfaces for the client that can't be used to create services.

An example for a synchronous annotated interface would be something like this, which can be used both by clients and service:

@GET
@Path("/RetrieveByPostcodeAndBuilding/v1.20/json.ws")
@Produces(MediaType.APPLICATION_JSON)
List<AddressDetails> retrieveByPostcodeAndBuilding(@QueryParam("Address") String address, @QueryParam("Building") String building);

An possible solution would be to have something like this:

@GET
@Path("/RetrieveByPostcodeAndBuilding/v1.20/json.ws")
@Produces(MediaType.APPLICATION_JSON)
Future<List<AddressDetails>> retrieveByPostcodeAndBuilding(
    @QueryParam("Postcode") String postcode,
    @QueryParam("Building") String building,
    @SomeNewAnnotation InvocationCallback<List<AddressDetails>> callback
);

Or:

@GET
@Path("/RetrieveByPostcodeAndBuilding/v1.20/json.ws")
@Produces(MediaType.APPLICATION_JSON)
void retrieveByPostcodeAndBuilding(
    @QueryParam("Postcode") String postcode,
    @QueryParam("Building") String building,
    @SomeNewAnnotation InvocationCallback<List<AddressDetails>> callback
);

The problem on the above suggestion is not allowing re-using the interface for the service-side.

@SomeNewAnnotation could be used by the resource factory to capture the InvocationCallback, since the current implementation injects non-annotated parameters as entities.

What do you guys think about this?

Thanks,
Bruno

Comment by Libor Kramolis [ 14/Jan/15 ]

I understand your motivation and idea. But I'm still not sure about InvocationCallback argument in server side Java API just because of usage of the same Java API on client side.

Moving to icebox - our Jersey team do not expect to work on the issue but it is still open for your contribution. May be if it is already implemented and used by you it will be easier to accept your contribution.

Comment by Marek Potociar [ 22/Jan/15 ]

I think it would be better to create a client-side wrapper API that would accept the method reference (Java SE 8 feature) and an invocation callback. That way you could "build" your async client API on top of your sync API, rather than having to place client-side artifacts into server-side interfaces just for the sake of client proxy creation...

Btw. the above is a very nice example of why client-side proxies promote tight coupling between client and server and also the reason why I dislike them and consider generally dangerous. SOAP and other RPC technologies got burnt because of features like this one.

Comment by Libor Kramolis [ 23/Jan/15 ]

I'm sorry we don't plan to provide such support.





[JERSEY-2730] Calling AsyncResponse.resume(Throwable) with null hangs up the service Created: 11/Dec/14  Updated: 11/Dec/14

Status: Open
Project: jersey
Component/s: None
Affects Version/s: 2.13
Fix Version/s: backlog

Type: Bug Priority: Minor
Reporter: adeon Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

jetty-runner-9.2.6.v20141205


Tags: async

 Description   

When AsyncResponse.resume(Throwable) is called two times with null as a parameter causes the entire service hang-up and does not accept any new incoming requests.

Example:

@Path("/resource")
@Consumes({MediaType.APPLICATION_JSON})
@Produces({MediaType.APPLICATION_JSON})
public class MyResource {

	@GET
	public void get(@Suspended final AsyncResponse asyncResponse)	{
		asyncResponse.resume((Throwable)null);
	}
}

Calling the above method for the first time returns HTTP status 500. Calling it one more time, makes the client wait forever, even if AsyncResponse.setTimeout() is set before.

Although passing null as the Throwable to resume() is quite unusual, the framework should reject or handle it in resilient way.






[JERSEY-2729] Confusing and inadequate exception "java.lang.IllegalStateException: Already connected" raised Created: 11/Dec/14  Updated: 11/Dec/14  Resolved: 11/Dec/14

Status: Resolved
Project: jersey
Component/s: connectors
Affects Version/s: 2.13
Fix Version/s: None

Type: Bug Priority: Major
Reporter: adams74 Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java 8 64bit Windows/Linux


Issue Links:
Duplicate
duplicates JERSEY-2728 SSLHandshakeException masked by usele... Open

 Description   

Misleading exception is raised once the Jersey client is called once the host with a non-existing, broken or unavailable url is passed in as a parameter for target method. There is no chance to establish connection to such the host but the client is reporting java.lang.IllegalStateException: Already connected instead of rather anticipated UnknownHostException or ConnectException.

Example:
class DigestRequest {

}

class DigestResponse {

}

public class DigestNoLimitClient {

public static void main(String[] args) throws Exception

{ String host = "http://blabla.bla"; Client client = ClientBuilder.newClient(); Entity<DigestRequest> request = Entity.json(new DigestRequest()); Response response = client.target(host).request().post(request); DigestResponse responseObject = response.readEntity(DigestResponse.class); System.out.println(responseObject); }

}

Result:
Exception in thread "main" javax.ws.rs.ProcessingException: Already connected
at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:255)
at org.glassfish.jersey.client.JerseyInvocation$1.call(JerseyInvocation.java:667)
at org.glassfish.jersey.client.JerseyInvocation$1.call(JerseyInvocation.java:664)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:228)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:424)
at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:664)
at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:424)
at org.glassfish.jersey.client.JerseyInvocation$Builder.post(JerseyInvocation.java:333)
at net.adamsmolnik.client.DigestNoLimitClient.main(DigestNoLimitClient.java:43)
Caused by: java.lang.IllegalStateException: Already connected
at sun.net.www.protocol.http.HttpURLConnection.setRequestProperty(HttpURLConnection.java:3000)
at org.glassfish.jersey.client.HttpUrlConnector.setOutboundHeaders(HttpUrlConnector.java:348)
at org.glassfish.jersey.client.HttpUrlConnector.access$100(HttpUrlConnector.java:87)
at org.glassfish.jersey.client.HttpUrlConnector$3.getOutputStream(HttpUrlConnector.java:311)
at org.glassfish.jersey.message.internal.CommittingOutputStream.commitStream(CommittingOutputStream.java:200)
at org.glassfish.jersey.message.internal.CommittingOutputStream.commitStream(CommittingOutputStream.java:194)
at org.glassfish.jersey.message.internal.CommittingOutputStream.commit(CommittingOutputStream.java:262)
at org.glassfish.jersey.message.internal.OutboundMessageContext.commitStream(OutboundMessageContext.java:811)
at org.glassfish.jersey.client.ClientRequest.writeEntity(ClientRequest.java:546)
at org.glassfish.jersey.client.HttpUrlConnector._apply(HttpUrlConnector.java:315)
at org.glassfish.jersey.client.HttpUrlConnector.apply(HttpUrlConnector.java:227)
at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:246)

Compare the behavior of code listed above with that showed below:

String host = "http://blabla.bla";
HttpURLConnection con = (HttpURLConnection)new URL(host).openConnection();
con.setDoOutput(true);
con.getOutputStream().write(1);

You get the exception as expected:
Exception in thread "main" java.net.UnknownHostException: blabla.bla
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:184)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)



 Comments   
Comment by Jakub Podlesak [ 11/Dec/14 ]

This should be addressed as part of fix for JERSEY-2728





[JERSEY-2728] SSLHandshakeException masked by useless IllegalStateException: Already connected Created: 10/Dec/14  Updated: 11/Dec/14

Status: Open
Project: jersey
Component/s: connectors
Affects Version/s: 2.13
Fix Version/s: backlog

Type: Bug Priority: Minor
Reporter: vksavochkin Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by JERSEY-2729 Confusing and inadequate exception "j... Resolved

 Description   

When connecting to https endpoint, jersey throws this useless
IllegalStateException instead of original
javax.net.ssl.SSLHandshakeException:

javax.ws.rs.ProcessingException: Already connected
at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:255)
at org.glassfish.jersey.client.JerseyInvocation$1.call(JerseyInvocation.java:667)
at org.glassfish.jersey.client.JerseyInvocation$1.call(JerseyInvocation.java:664)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:228)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:424)
at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:664)
at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:424)
at org.glassfish.jersey.client.JerseyInvocation$Builder.post(JerseyInvocation.java:333)
at my.test.TestService.foo(TestService.java:65)
...
Caused by: java.lang.IllegalStateException: Already connected
at sun.net.www.protocol.http.HttpURLConnection.setRequestProperty(HttpURLConnection.java:3000)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.setRequestProperty(HttpsURLConnectionImpl.java:316)
at org.glassfish.jersey.client.HttpUrlConnector.setOutboundHeaders(HttpUrlConnector.java:348)
at org.glassfish.jersey.client.HttpUrlConnector.access$100(HttpUrlConnector.java:87)
at org.glassfish.jersey.client.HttpUrlConnector$3.getOutputStream(HttpUrlConnector.java:311)
at org.glassfish.jersey.message.internal.CommittingOutputStream.commitStream(CommittingOutputStream.java:200)
at org.glassfish.jersey.message.internal.CommittingOutputStream.commitStream(CommittingOutputStream.java:194)
at org.glassfish.jersey.message.internal.CommittingOutputStream.commit(CommittingOutputStream.java:262)
at org.glassfish.jersey.message.internal.OutboundMessageContext.commitStream(OutboundMessageContext.java:811)
at org.glassfish.jersey.client.ClientRequest.writeEntity(ClientRequest.java:546)
at org.glassfish.jersey.client.HttpUrlConnector._apply(HttpUrlConnector.java:315)
at org.glassfish.jersey.client.HttpUrlConnector.apply(HttpUrlConnector.java:227)
at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:246)
... 32 more

I think, org.glassfish.jersey.client.ClientRequest#writeEntity should
catch all exceptions not just IOException when logging close() errors
in "finally" block.

Also, SSLException should be treated like a ConnectException.



 Comments   
Comment by Jakub Podlesak [ 10/Dec/14 ]

Agreed with Vladimir he would create a pull request for this.
Moving to backlog, as we have not agreed any time frame.

@Vladimir: feel free to submit the request whenever it is ready, thanks





[JERSEY-2727] Performance degradation after moving to jersey 2 (2.13) Created: 10/Dec/14  Updated: 18/Feb/15  Resolved: 18/Feb/15

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: None
Fix Version/s: 2.16

Type: Bug Priority: Critical
Reporter: nahsh Assignee: Unassigned
Resolution: Fixed Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

redhat, spring 4.0.0, embedded jetty 9


Issue Links:
Blocks
is blocked by JERSEY-1708 Implement sub-resource runtime model ... Resolved
Related
is related to JERSEY-1708 Implement sub-resource runtime model ... Resolved
Tags: performance

 Description   

We're working on a server using spring 4, embedded jetty 9 and jersey. Recently, we moved to jersey 2.13 and we noticed a degradation in performance. I performed some investigations using YourKit. I saw that there is a massive CPU usage in reflection done by jersey. Also, there are many NoSuchMethodExceptions and ClassNotFoundExceptions in Yourkit snapshot.

Is there any jersey configuration or a best practice to avoid this issue, or to optimize jersey? Or maybe it is a known issue in jersey 2?

Here are two screenshots from YourKit, showing the hot-spots, after excluding the socket read (java.net.SocketInputStream.socketRead0). The first one is with Merged Callees:

And the second one if with Back Trace:



 Comments   
Comment by Jakub Podlesak [ 10/Dec/14 ]

What was the original Jersey version? There is certain performance drop between Jersey 1.x and 2.x that we are already aware of.

Could you please provide a minimal reproducible test case?

A good practice generally is to avoid using sub-resource locators as they might trigger some introspection (using reflection) at runtime. Not sure though if that is your case.

Comment by nahsh [ 10/Dec/14 ]

Thank you for you reply Jakub.

We used jersey 1.18 and moved to version 2.13

Give you an example is not trivial.

We do use sub-resources. It is part of jax-rs. Could it be the problem? Are you planing a fix for it?

Thanks.

Comment by Jakub Podlesak [ 11/Dec/14 ]

Linking to related JERSEY-1708 issue

Comment by Jakub Podlesak [ 11/Dec/14 ]

Introducing a cache for the sub-resources should definitely help in your case then.

There will still be a performance drop comparing to Jersey 1.18.
This is something we want to get addressed as well in a longer term perspective.

I can not promise anything concrete, but JERSEY-1708 will be solved soonish.

Comment by yairogen [ 11/Dec/14 ]

I'm reading this thread and I wonder. We are hearing in my company more than a few complaints on the above mentioned performance drop in Jersey 2 VS Jersey 1.

Apparently from your statement above this is a known issue (not only in relation to sub-resources).

Are there plan to release a version that fixes all known performance issues? Is there a roadmap here you can share?

Specifically on the sub-resources front, when is JERSEY-1708 planned to be fixed and released? I see it doesn't have an assigned version to it.

Thanks.

Comment by Jakub Podlesak [ 13/Jan/15 ]

Blocked by JERSEY-1708

Comment by Jakub Podlesak [ 13/Jan/15 ]

Moving to backlog, due to lack of a better place. Should get addressed soonish though.

Comment by nobeh5 [ 19/Jan/15 ]

We have also observed the same degradation upgrading from Jersey 1.18 to Jersey 2.14. We also do extensively use sub-resources.

Comment by Jakub Podlesak [ 18/Feb/15 ]

In 2.16, sub-resource caching has been introduced,
thus the issue should be gone now.

Please feel free to re-open, if the observed performance is not improved.





[JERSEY-2726] NPE in jersey/spring (integration) RequestContextFilter Created: 09/Dec/14  Updated: 09/Dec/14

Status: Open
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: Miroslav Fuksa Assignee: Jakub Podlesak
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I use jersey/spring RequestContextFilter for spring integration (Jersey 2, Spring 4).

When I throw an WAE exception from my Prematching ContainerRequestFilter (@Priority 1000) then there is NPE in org.glassfish.jersey.server.spring.scope.RequestContextFilter.

javax.servlet.ServletException: org.glassfish.jersey.server.internal.process.MappableException: java.lang.NullPointerException
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:393) ~[jersey-container-servlet-core-2.13.jar:na]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:381) ~[jersey-container-servlet-core-2.13.jar:na]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:344) ~[jersey-container-servlet-core-2.13.jar:na]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:221) ~[jersey-container-servlet-core-2.13.jar:na]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:769) ~[jetty-servlet-9.2.2.v20140723.jar:9.2.2.v20140723]
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) [jetty-servlet-9.2.2.v20140723.jar:9.2.2.v20140723]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) [jetty-server-9.2.2.v20140723.jar:9.2.2.v20140723]
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) [jetty-security-9.2.2.v20140723.jar:9.2.2.v20140723]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) [jetty-server-9.2.2.v20140723.jar:9.2.2.v20140723]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1125) [jetty-server-9.2.2.v20140723.jar:9.2.2.v20140723]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) [jetty-servlet-9.2.2.v20140723.jar:9.2.2.v20140723]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) [jetty-server-9.2.2.v20140723.jar:9.2.2.v20140723]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1059) [jetty-server-9.2.2.v20140723.jar:9.2.2.v20140723]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [jetty-server-9.2.2.v20140723.jar:9.2.2.v20140723]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) [jetty-server-9.2.2.v20140723.jar:9.2.2.v20140723]
at org.eclipse.jetty.server.Server.handle(Server.java:485) [jetty-server-9.2.2.v20140723.jar:9.2.2.v20140723]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:290) [jetty-server-9.2.2.v20140723.jar:9.2.2.v20140723]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:248) [jetty-server-9.2.2.v20140723.jar:9.2.2.v20140723]
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) [jetty-io-9.2.2.v20140723.jar:9.2.2.v20140723]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:606) [jetty-util-9.2.2.v20140723.jar:9.2.2.v20140723]
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:535) [jetty-util-9.2.2.v20140723.jar:9.2.2.v20140723]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_25]
Caused by: org.glassfish.jersey.server.internal.process.MappableException: java.lang.NullPointerException
at org.glassfish.jersey.server.ContainerFilteringStage$ResponseFilterStage.apply(ContainerFilteringStage.java:197) ~[jersey-server-2.13.jar:na]
at org.glassfish.jersey.server.ContainerFilteringStage$ResponseFilterStage.apply(ContainerFilteringStage.java:162) ~[jersey-server-2.13.jar:na]
at org.glassfish.jersey.process.internal.Stages.process(Stages.java:171) ~[jersey-common-2.13.jar:na]
at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:375) ~[jersey-server-2.13.jar:na]
at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:420) ~[jersey-server-2.13.jar:na]
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:277) ~[jersey-server-2.13.jar:na]
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) ~[jersey-common-2.13.jar:na]
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) ~[jersey-common-2.13.jar:na]
at org.glassfish.jersey.internal.Errors.process(Errors.java:315) ~[jersey-common-2.13.jar:na]
at org.glassfish.jersey.internal.Errors.process(Errors.java:297) ~[jersey-common-2.13.jar:na]
at org.glassfish.jersey.internal.Errors.process(Errors.java:267) ~[jersey-common-2.13.jar:na]
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:297) ~[jersey-common-2.13.jar:na]
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:254) ~[jersey-server-2.13.jar:na]
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1030) ~[jersey-server-2.13.jar:na]
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:373) ~[jersey-container-servlet-core-2.13.jar:na]
... 21 common frames omitted
Caused by: java.lang.NullPointerException: null
at org.glassfish.jersey.server.spring.scope.RequestContextFilter$2.resetAttributes(RequestContextFilter.java:106) ~[jersey-spring3-2.13.jar:na]
at org.glassfish.jersey.server.spring.scope.RequestContextFilter.filter(RequestContextFilter.java:118) ~[jersey-spring3-2.13.jar:na]
at org.glassfish.jersey.server.ContainerFilteringStage$ResponseFilterStage.apply(ContainerFilteringStage.java:195) ~[jersey-server-2.13.jar:na]
... 35 common frames omitted


The reason is that my Prematching filter (that throws WAE) is executed before RequestContextFilter and "attributes" are not set yet. Then the WAE is thrown. Then RequestContextFilter is executed to handle the error response and it fails for NPE. It would be good to add NPE checks to the code of the RequestContextFilter and to set @Priority of RequestContextFilter to 100 for example (must be run before other filters).

Workaround:

register this filter instead of RequestContextFilter:

@Priority(1)
@PreMatching
@Provider
public class JerseySpringWorkaroundFilter extends RequestContextFilter {
public JerseySpringWorkaroundFilter(ServiceLocator locator)

{ super(locator); }

}



 Comments   
Comment by Jakub Podlesak [ 09/Dec/14 ]

Spring RequestContextHolder should be integrated differently in Jersey Spring module. Current solution relying on request/response filter SPI works only in the sync case. I bet things would fail badly in an async case.

To solve this correctly we need to come up with a better request scope integration mechanism. We are about to introduce a new Jersey SPI, ExternalRequestScope, which needs to be then implemented by the Spring integration module. The old RequestContextFilter will then be removed.

Comment by Jakub Podlesak [ 09/Dec/14 ]

To fix this, current RequestContextFilter shall be replaced by a custom implementation of ExternalRequestScope (to be introduced as part of CDI container agnostic support)





[JERSEY-2725] Provide SPI for wrapping the resource method call Created: 09/Dec/14  Updated: 15/Dec/14  Resolved: 15/Dec/14

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Miroslav Fuksa Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It would be nice to have possibility to wrap a resource method call. The use case for this SPI is to handle database transactions (open transaction before resource method, commit or rollback transaction at the end of the method depending on the result/exception). Currently existing SPIs are not sufficient for this use case. Filters are not executed in case of exceptions, Interceptors are not executed when there is no body, combination of filters and exception mappers is not the best and always working solution too. Maybe event listeners (RequestEvent) could be the solution but I am not sure this will always work (and it looks quite complex for this case).

Or is there a way that I have not considered?

I think in Jersey 1.x there was such a SPI (something like ResourceMethodDispatcher).

thanks
Mira



 Comments   
Comment by Jakub Podlesak [ 09/Dec/14 ]

Since you are using Jersey 2, which uses HK2 internally, you should be able to take advantage of HK2 AOP capabilities. There is an example provided here: https://hk2.java.net/2.3.0/aop-example.html

Comment by Miroslav Fuksa [ 15/Dec/14 ]

I did not know about it. Thanks. Anyway, Michal asked me to enter this issue and I do not depend on it, so if you don't think it is needed to implement such a SPI (because it can be solved by HK2 for example), feel free to close it. I personally think it would make sense to have something simple for wrapping purpose.

thanks
Mira

Comment by Jakub Podlesak [ 15/Dec/14 ]

Currently, users should be able to leverage means provided by other frameworks that integrate with Jersey such as HK2 (HK2 AOP feature), CDI (CDI interceptors), etc.

At the moment i am closing this as "won't fix". We should be able to re-consider if there is a strong compelling reason.

@Mira: thanks for taking the time to deal with this and for filing the report.





[JERSEY-2724] The proxy client throws UnsupportedOperationException when calling toString Created: 07/Dec/14  Updated: 24/Feb/15  Resolved: 24/Feb/15

Status: Resolved
Project: jersey
Component/s: extensions
Affects Version/s: 2.13
Fix Version/s: 2.17

Type: Bug Priority: Minor
Reporter: eiden Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: pull-request
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If I call toString() on a proxy client, it throws an UnsupportedOperationException:

@Path("/")
interface MyClient {
    @GET String get();
}

@Test
public void buildClient() {
    WebTarget target = ClientBuilder.newClient()
                            .target("http://localhost/");

    MyClient client = WebResourceFactory.newResource(MyClient.class, target);

    client.toString(); //<-- throws java.lang.UnsupportedOperationException: Not a resource method
}

It's not a good thing to throw exceptions in toString

Pull request:
https://github.com/jersey/jersey/pull/131



 Comments   
Comment by Jakub Podlesak [ 09/Dec/14 ]

Thanks for the pull request, we will incorporate this after 2.14 is out (it is being released nowadays).

Comment by eiden [ 09/Dec/14 ]

Great. I have some other suggestions for improvement of the proxy client. Should I create JIRA tickets for those suggestions, or do you prefer to take the discussion on the dev mailing list first?





[JERSEY-2723] grizzly parse uri error for URI path beginning with two consecutive slashes Created: 04/Dec/14  Updated: 10/Dec/14

Status: Open
Project: jersey
Component/s: containers
Affects Version/s: 2.13
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: icode Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The exception happens whenever handling URI path beginning with two consecutive slashes (three slashes are fine from that perspective).

"stack message"
javax.ws.rs.core.UriBuilderException: java.net.URISyntaxException: Expected authority at index 2: //
	at org.glassfish.jersey.uri.internal.JerseyUriBuilder.createURI(JerseyUriBuilder.java:908) ~[jersey-common-2.13.jar:na]
	at org.glassfish.jersey.uri.internal.JerseyUriBuilder._build(JerseyUriBuilder.java:897) ~[jersey-common-2.13.jar:na]
	at org.glassfish.jersey.uri.internal.JerseyUriBuilder.build(JerseyUriBuilder.java:810) ~[jersey-common-2.13.jar:na]
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.getRequestUri(GrizzlyHttpContainer.java:451) ~[jersey-container-grizzly2-http-2.10.1.jar:na]
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:348) ~[jersey-container-grizzly2-http-2.10.1.jar:na]
	at org.glassfish.grizzly.http.server.HttpHandler$1.run(HttpHandler.java:219) ~[grizzly-http-server-2.3.16.jar:2.3.16]
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565) [grizzly-framework-2.3.16.jar:2.3.16]
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545) [grizzly-framework-2.3.16.jar:2.3.16]
	at java.lang.Thread.run(Thread.java:745) [na:1.7.0_65]

please fix bug at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer private URI getRequestUri(URI baseUri, Request grizzlyRequest)

"GrizzlyHttpContainer"

private URI getRequestUri(URI baseUri, Request grizzlyRequest) {
        // TODO: this is terrible, there must be a way to obtain the original request URI!
      +//please use getRequestURIRef().getDecodedURI() or normalize 
        String originalUri = UriBuilder.fromPath(
                grizzlyRequest.getRequest().getRequestURIRef().getOriginalRequestURIBC().toString(Charsets.DEFAULT_CHARSET)
        ).build().toString();

        String queryString = grizzlyRequest.getQueryString();
        if (queryString != null) {
            originalUri = originalUri + "?" + ContainerUtils.encodeUnsafeCharacters(queryString);
        }

        return baseUri.resolve(originalUri);
    }

please use getRequestURIRef().getDecodedURI() or normalize

  
        String originalUri = UriBuilder.fromPath(
grizzlyRequest.getRequest().getRequestURIRef().getOriginalRequestURIBC().toString(Charsets.DEFAULT_CHARSET)
        ).build().toString();

please! thanks lot



 Comments   
Comment by Jakub Podlesak [ 09/Dec/14 ]

Any chance you could submit a pull request containing a reproducible test covering your use case? Thanks in advance for any response!

Comment by icode [ 09/Dec/14 ]

please visit http://localhost:port// on grizzly container

Comment by Jakub Podlesak [ 10/Dec/14 ]

Things will not be that easy, we need to be able to retain multiple consecutive slashes in the URI. However we should try to address this issue somehow.

We should avoid any code leading to new URI("//") call which could be caused also by URI.resolve method invocation.

Comment by icode [ 10/Dec/14 ]

why move to backlog?this important!grizzly can't use basic

Comment by Jakub Podlesak [ 10/Dec/14 ]

While i agree this is important, the bug could still be worked around using e.g. an appropriately
configured Apache httpd server instance running in front of Grizzly.
Schedule for the current Jersey sprint is very tight, and i am not sure this would fit in, that is all the backlog assignment says.





[JERSEY-2722] ExceptionMapperFactory should take into account priority of mappers as set by @Priority annotation Created: 03/Dec/14  Updated: 10/Dec/14

Status: Open
Project: jersey
Component/s: media
Affects Version/s: 2.13
Fix Version/s: backlog

Type: Improvement Priority: Major
Reporter: sarxos Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:
  • OpenJDK 7 (1.7.0_65)
  • CentOS 6
  • Jetty Embedded 9.x


 Description   

Hello Jersey Team,

After upgrading from 2.6 to 2.13 I discover issue with Jersey exception mappers. I do have my own exception mapper defined for JsonMappingException (among many other mappers), but whenever I send invalid JSON, the Jersey is using default exception mapper that comes registered with JacksonFeature (see logs below):

Request:

2014-12-03 13:14:59,540 [qtp880578076-30] INFO  com.github.sarxos.elm.Application - 15 * Server has received a request on thread qtp880578076-30
15 > POST https://x.x.x.x:8443/xxx/api/register
15 > Content-Type: application/json; charset=UTF-8
{
"t":"abba",
"s":44444,
}

And the response:

2014-12-03 13:14:59,549 [qtp880578076-30] DEBUG org.glassfish.jersey.tracing.general - EXCEPTION_MAPPING Exception mapper [com.fasterxml.jackson.jaxrs.base.JsonMappingExceptionMapper @499ca5ec] maps [com.fasterxml.jackson.databind.JsonMappingException @6600e06] ('Numeric value (44444) out of range of Java byte
 at [Source: org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$UnCloseableInputStream@2eda6dd2; line: 3, column: 10] (through reference chain: com.github.sarxos.elm.Device["s"])') to <400/CLIENT_ERROR|Bad Request> [ 0.09 ms]
2014-12-03 13:14:59,550 [qtp880578076-30] INFO  com.github.sarxos.elm.Application - 16 * Server responded with a response on thread qtp880578076-30
16 < 400
16 < Content-Type: text/plain
Numeric value (44444) out of range of Java byte
 at [Source: org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$UnCloseableInputStream@2eda6dd2; line: 3, column: 10] (through reference chain: com.github.sarxos.elm.Device["s"])

This fragment is important:

Exception mapper [com.fasterxml.jackson.jaxrs.base.JsonMappingExceptionMapper @499ca5ec] maps [com.fasterxml.jackson.databind.JsonMappingException @6600e06] 

I can clearly see, that Jersey is using default JsonMappingExceptionMapper instead of my own mapper I created especially for this purpose.

I suspect that the effect I'm observing is caused by the enhancement implemented by JERSEY-2283 in 2.7, commit 4f04eda4079305b8f5b357902de7d9e09c581d34.

I'm unable to reproduce it on the development environment (Ubuntu 14, Oracle Java 8, Eclipse), but on the test environment (CentOS 6, OpenJDK 7) it is reproducible in 100% cases. I suspect that JARs order or class loading time is important here. In the Jersey ExceptionMapperFactory these two mappers (custom one I expect to be used, and a default one) has the same inheritance distance calculated, so I guess that it's safe to assume that the first one found will be always returned and there is no other order rule here.

Therefore, due to above, maybe it's worth to consider adding e.g. @Piority annotation value to be compared when distance for all available mappers of the same type is exactly the same? What do you think?



 Comments   
Comment by Jakub Podlesak [ 09/Dec/14 ]

Until this gets implemented, you should be able to use https://jersey.java.net/apidocs/2.13/jersey/org/glassfish/jersey/spi/ExtendedExceptionMapper.html to workaround the issue.

Comment by sarxos [ 10/Dec/14 ]

Jakub,

Thank you. For now I w/a this by adding this piece of code in my ResourceConfig:

@Inject
public MyResourceConfig(ServiceLocator locator) {
	// w/a for JERSEY-2722
	register(JacksonJaxbJsonProvider.class, MessageBodyReader.class, MessageBodyWriter.class);
	// ...
}

This is to skip the code from if block from line 81 in JacksonFeature.java.





[JERSEY-2721] Proxy client fails to send an entity if it has any annotation Created: 03/Dec/14  Updated: 18/Dec/14  Resolved: 18/Dec/14

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.15

Type: Bug Priority: Major
Reporter: walec51 Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by walec51 [ 03/Dec/14 ]

Hi, I'm evaluating you Jersey Proxy Client for our projects in Allegro and I've stumbled upon a nasty bug.

This interface works ok:

public interface OrderEndpoint {

    public static final String ORDERS_PATH = "/orders";

    @Path(ORDERS_PATH)
    @POST
    @Consumes(NewOrderRequest.MIME_TYPE)
    @Produces(OrderResponse.MIME_TYPE)
    OrderResponse createOrder(
        NewOrderRequest request
    );

}

but if I add any annotation to the request argument like this:

public interface OrderEndpoint {

    public static final String ORDERS_PATH = "/orders";

    @Path(ORDERS_PATH)
    @POST
    @Consumes(NewOrderRequest.MIME_TYPE)
    @Produces(OrderResponse.MIME_TYPE)
    OrderResponse createOrder(
        @NotNull NewOrderRequest request
    );

}

The Proxy Client API stop to send the entity in the HTTP request.

I've localized the problem and I'm preparing an pull request.

Comment by walec51 [ 03/Dec/14 ]

Fix:
https://github.com/jersey/jersey/pull/129

Comment by Marek Potociar [ 18/Dec/14 ]

Resolved by accepting a contributed pull request.





[JERSEY-2720] Parameters with non-JAX-RS annotations lack distinction between entity parameters and parameters of unknown source Created: 01/Dec/14  Updated: 02/Feb/15

Status: Open
Project: jersey
Component/s: None
Affects Version/s: 2.13
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: jfmorin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Attachments: File jersey-bug-example.7z    

 Description   

When an entity parameter (bearing no JAX-RS annotations) has non-JAX-RS annotations, it is considered as being of unknown source instead of a standard entity parameter, and is thus excluded from any WADL and related XSD schemas.

The problem comes from the static org.glassfish.jersey.server.Parameter.create(Class, Class, boolean, Class<?>, Type, Annotation[]) method (starting on line 281 in jersey-server-2.13.jar).

This method includes a loop that assigns a parameter a Parameter.Source.UNKNOWN source type whenever a non-JAX-RS annotation is found, unless a JAX-RS annotation has been found before. More specifically, the bug is found on lines 318–322.

This behaviour is not wrong per se, but what happens if, for example, I need to add a Swagger @ApiParam annotation to such a parameter? If the Parameter.Source.UNKNOWN type is to be kept, there should be a way to distinguish legitimate entity parameters bearing non-JAX-RS annotations and parameters that are actually of unknown source (likely to be a configuration error).



 Comments   
Comment by Jakub Podlesak [ 15/Dec/14 ]

Could you please attach or include a concrete reproducible test case, where you believe things are broken?

The third statement/paragraph in your description is IMHO wrong. E.g. given two annotations, first of them
being a JAX-RS annotation, and the second one a non-JAX-RS one, you will still end up with a known source,
i.e. the code in the for cycle does exactly what is stated in the javadoc.

Comment by jfmorin [ 14/Jan/15 ]

My third paragraph lacked precision: whenever a JAX-RS annotation is found, it indeed has precedence over any non-JAX-RS annotation. Sorry about that!

I prepared a small project that reproduces the problem but I seem to have no rights to attach files to this ticket. How can I proceed to provide the requested test case?

Comment by Jakub Podlesak [ 14/Jan/15 ]

Then please e-mail it to me directly: jakub dot podlesak at oracle dot com.

Comment by Jakub Podlesak [ 15/Jan/15 ]

reproducer test case application from Jean-Francois

Comment by jfmorin [ 22/Jan/15 ]

I forgot to mention that I used Jersey 2.15 in my sample project to make sure the bug is still present. As a matter of fact, the create(...) method of the Parameter class hasn't changed in versions 2.14 and 2.15.





[JERSEY-2719] Jersey client queryParams incorrect encoding Created: 01/Dec/14  Updated: 19/Dec/14

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 1.18
Fix Version/s: 1.x-backlog

Type: Bug Priority: Major
Reporter: skarnecki Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When using Jersey to GET from on of our Jersey managed endpoints I got 404 since parameters passed as queryParams are encoded incorrectly. I was able to fix that using UriBuilder instead of method queryParams on webresource

Details:

Entry details:
parameters = "file" => "/Shared/Documents/test/d %20“Iñtërnâtiônàlizætiøν☃”_7726af1977cc7131e1af061acc8dbe51/SINGLE_TEST_ONLY-2014-11-26-15-59-16 f %20“Iñtërnâtiônàlizætiøν☃”.txt"


Client code execution:
        WebResource resource = getWebResouce();
        for (Map.Entry<String, String> params : parameters.entrySet()) {
            resource = resource.queryParam(params.getKey(), params.getValue());
        }

        ClientResponse clientResponse = resource
                .type(MediaType.TEXT_PLAIN + "; charset=utf-8")
                .get(ClientResponse.class);

Jersey encoded parameters:
parameters = "file" => "/Shared/Documents/test/d+%20“Iñtërnâtiônàlizætiøν☃”_7726af1977cc7131e1af061acc8dbe51/SINGLE_TEST_ONLY-2014-11-26-15-59-16+f+%20“Iñtërnâtiônàlizætiøν☃”.txt"

results in endpoint :
"/Shared/Documents/test/d “Iñtërnâtiônàlizætiøν☃”_7726af1977cc7131e1af061acc8dbe51/SINGLE_TEST_ONLY-2014-11-26-15-59-16 f “Iñtërnâtiônàlizætiøν☃”.txt"




 Comments   
Comment by skarnecki [ 01/Dec/14 ]

I'm unable to edit this task.

results in endpoint :
"/Shared/Documents/test/d  “Iñtërnâtiônàlizætiøν☃”_7726af1977cc7131e1af061acc8dbe51/SINGLE_TEST_ONLY-2014-11-26-15-59-16 f  “Iñtërnâtiônàlizætiøν☃”.txt"

%20 -> converted to space (undesired behavior)

Comment by Adam Lindenthal [ 19/Dec/14 ]

Hi Skarnecki,

thanks for creating the issue. You are right, the %20 sequence in the query part of the URI is decoded into a space. Technically speaking, it probably should not and we should only decode + to space and leave percent encoded sequences intact.

I am moving the issue to backlog, so that we can take a look at it in some of the future sprints.
However, I cannot not promisse, that this will be change - this needs some discussion in our team, I guess although the GET form parameters should be encoded the way you are suggesting, I can imagine lot of people would complain if we change this, as we would most likely break a lot of apps with this.

Regards,
Adam





[JERSEY-2718] Cleanup code, fixing performance issues Created: 28/Nov/14  Updated: 14/Jan/15  Resolved: 14/Jan/15

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.16

Type: Improvement Priority: Minor
Reporter: loxal Assignee: Adam Lindenthal
Resolution: Fixed Votes: 0
Labels: pull-request
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I've fixed some major performance issues, cf. my Pull Request.



 Comments   
Comment by loxal [ 28/Nov/14 ]

GitHub reference:

Comment by Adam Lindenthal [ 13/Jan/15 ]

Hi loxal,

thanks for creating the issue and the pull request.
Seems like you have discussed everything with Marek on github, so this seems to be ready to merge. We will do that shortly, as soon as the next version will be out.

Regards,
Adam

Comment by loxal [ 13/Jan/15 ]

Cool, thanks Adam!

Comment by Adam Lindenthal [ 14/Jan/15 ]

Pull request #125 merged. Thanks.





[JERSEY-2717] Maven test fail due to missing asm dependency Created: 28/Nov/14  Updated: 02/Dec/14  Resolved: 02/Dec/14

Status: Resolved
Project: jersey
Component/s: containers
Affects Version/s: 2.13
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sarxos Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Oracle Java 8, Ubuntu 14.04, Jersey 2.13-SNAPSHOT (master)



 Description   

Hello Jersey Team,

Some tests are failing on master due to missing asm dependency. I fixed this by modifying this file:

containers/jdk-http/pom.xml

And adding missing dependency with test cope:

<dependencies>
    <dependency>
        <groupId>asm</groupId>
        <artifactId>asm</artifactId>
        <version>3.3.1</version>
        <scope>test</scope>
    </dependency>
</dependencies>

Now jersey-container-jdk-http module tests are passing. I can push this change to Jersey repository on github if you like.

The failure log:

[INFO] ------------------------------------------------------------------------
[INFO] Building jersey-container-jdk-http 2.14-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-versions) @ jersey-container-jdk-http ---
[INFO] 
[INFO] --- build-helper-maven-plugin:1.7:parse-version (parse-version) @ jersey-container-jdk-http ---
[INFO] 
[INFO] --- maven-istack-commons-plugin:2.6.1:rs-gen (default) @ jersey-container-jdk-http ---
Resources:
org/glassfish/jersey/jdkhttp/internal/localization.properties
Skipping /home/sarxos/workspace/jersey/containers/jdk-http/src/main/resources/org/glassfish/jersey/jdkhttp/internal/localization.properties
[INFO] 
[INFO] --- build-helper-maven-plugin:1.7:add-source (default) @ jersey-container-jdk-http ---
[INFO] Source directory: /home/sarxos/workspace/jersey/containers/jdk-http/target/generated-sources/rsrc-gen added.
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ jersey-container-jdk-http ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 0 resource
[INFO] Copying 2 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ jersey-container-jdk-http ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 5 source files to /home/sarxos/workspace/jersey/containers/jdk-http/target/classes
[INFO] 
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ jersey-container-jdk-http ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/sarxos/workspace/jersey/containers/jdk-http/src/test/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ jersey-container-jdk-http ---
[INFO] Nothing to compile - all classes are up to date
[INFO] 
[INFO] --- maven-surefire-plugin:2.17:test (default-test) @ jersey-container-jdk-http ---
[INFO] Surefire report directory: /home/sarxos/workspace/jersey/containers/jdk-http/target/surefire-reports

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running org.glassfish.jersey.jdkhttp.LifecycleListenerTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.364 sec <<< FAILURE! - in org.glassfish.jersey.jdkhttp.LifecycleListenerTest
testStartupShutdownHooks(org.glassfish.jersey.jdkhttp.LifecycleListenerTest)  Time elapsed: 0.29 sec  <<< ERROR!
java.lang.NoClassDefFoundError: org/objectweb/asm/ClassVisitor
	at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.glassfish.jersey.server.ResourceConfig.scanClasses(ResourceConfig.java:885)
	at org.glassfish.jersey.server.ResourceConfig._getClasses(ResourceConfig.java:849)
	at org.glassfish.jersey.server.ResourceConfig.getClasses(ResourceConfig.java:755)
	at org.glassfish.jersey.server.ResourceConfig$RuntimeConfig.<init>(ResourceConfig.java:1181)
	at org.glassfish.jersey.server.ResourceConfig$RuntimeConfig.<init>(ResourceConfig.java:1154)
	at org.glassfish.jersey.server.ResourceConfig.createRuntimeConfig(ResourceConfig.java:1150)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:318)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:273)
	at org.glassfish.jersey.jdkhttp.JdkHttpHandlerContainer.<init>(JdkHttpHandlerContainer.java:98)
	at org.glassfish.jersey.jdkhttp.JdkHttpServerFactory.createHttpServer(JdkHttpServerFactory.java:104)
	at org.glassfish.jersey.jdkhttp.JdkHttpServerFactory.createHttpServer(JdkHttpServerFactory.java:85)
	at org.glassfish.jersey.jdkhttp.AbstractJdkHttpServerTester.startServer(AbstractJdkHttpServerTester.java:113)
	at org.glassfish.jersey.jdkhttp.LifecycleListenerTest.testStartupShutdownHooks(LifecycleListenerTest.java:146)

testReload(org.glassfish.jersey.jdkhttp.LifecycleListenerTest)  Time elapsed: 0.016 sec  <<< ERROR!
java.lang.NoClassDefFoundError: org/objectweb/asm/ClassVisitor
	at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.glassfish.jersey.server.ResourceConfig.scanClasses(ResourceConfig.java:885)
	at org.glassfish.jersey.server.ResourceConfig._getClasses(ResourceConfig.java:849)
	at org.glassfish.jersey.server.ResourceConfig.getClasses(ResourceConfig.java:755)
	at org.glassfish.jersey.server.ResourceConfig$RuntimeConfig.<init>(ResourceConfig.java:1181)
	at org.glassfish.jersey.server.ResourceConfig$RuntimeConfig.<init>(ResourceConfig.java:1154)
	at org.glassfish.jersey.server.ResourceConfig.createRuntimeConfig(ResourceConfig.java:1150)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:318)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:273)
	at org.glassfish.jersey.jdkhttp.JdkHttpHandlerContainer.<init>(JdkHttpHandlerContainer.java:98)
	at org.glassfish.jersey.jdkhttp.JdkHttpServerFactory.createHttpServer(JdkHttpServerFactory.java:104)
	at org.glassfish.jersey.jdkhttp.JdkHttpServerFactory.createHttpServer(JdkHttpServerFactory.java:85)
	at org.glassfish.jersey.jdkhttp.AbstractJdkHttpServerTester.startServer(AbstractJdkHttpServerTester.java:113)
	at org.glassfish.jersey.jdkhttp.LifecycleListenerTest.testReload(LifecycleListenerTest.java:111)

Running org.glassfish.jersey.jdkhttp.JdkHttpPackageTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.02 sec <<< FAILURE! - in org.glassfish.jersey.jdkhttp.JdkHttpPackageTest
testJdkHttpPackage(org.glassfish.jersey.jdkhttp.JdkHttpPackageTest)  Time elapsed: 0.02 sec  <<< ERROR!
java.lang.NoClassDefFoundError: org/objectweb/asm/ClassVisitor
	at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.glassfish.jersey.server.ResourceConfig.scanClasses(ResourceConfig.java:885)
	at org.glassfish.jersey.server.ResourceConfig._getClasses(ResourceConfig.java:849)
	at org.glassfish.jersey.server.ResourceConfig.getClasses(ResourceConfig.java:755)
	at org.glassfish.jersey.server.ResourceConfig$RuntimeConfig.<init>(ResourceConfig.java:1181)
	at org.glassfish.jersey.server.ResourceConfig$RuntimeConfig.<init>(ResourceConfig.java:1154)
	at org.glassfish.jersey.server.ResourceConfig.createRuntimeConfig(ResourceConfig.java:1150)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:318)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:273)
	at org.glassfish.jersey.jdkhttp.JdkHttpHandlerContainer.<init>(JdkHttpHandlerContainer.java:98)
	at org.glassfish.jersey.jdkhttp.JdkHttpServerFactory.createHttpServer(JdkHttpServerFactory.java:104)
	at org.glassfish.jersey.jdkhttp.JdkHttpServerFactory.createHttpServer(JdkHttpServerFactory.java:85)
	at org.glassfish.jersey.jdkhttp.AbstractJdkHttpServerTester.startServer(AbstractJdkHttpServerTester.java:113)
	at org.glassfish.jersey.jdkhttp.JdkHttpPackageTest.testJdkHttpPackage(JdkHttpPackageTest.java:79)

Running org.glassfish.jersey.jdkhttp.RuntimeDelegateTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.34 sec - in org.glassfish.jersey.jdkhttp.RuntimeDelegateTest
Running org.glassfish.jersey.jdkhttp.BasicJdkHttpServerTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.023 sec <<< FAILURE! - in org.glassfish.jersey.jdkhttp.BasicJdkHttpServerTest
testCreateHttpsServer(org.glassfish.jersey.jdkhttp.BasicJdkHttpServerTest)  Time elapsed: 0.014 sec  <<< ERROR!
java.lang.NoClassDefFoundError: org/objectweb/asm/ClassVisitor
	at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.glassfish.jersey.server.ResourceConfig.scanClasses(ResourceConfig.java:885)
	at org.glassfish.jersey.server.ResourceConfig._getClasses(ResourceConfig.java:849)
	at org.glassfish.jersey.server.ResourceConfig.getClasses(ResourceConfig.java:755)
	at org.glassfish.jersey.server.ResourceConfig$RuntimeConfig.<init>(ResourceConfig.java:1181)
	at org.glassfish.jersey.server.ResourceConfig$RuntimeConfig.<init>(ResourceConfig.java:1154)
	at org.glassfish.jersey.server.ResourceConfig.createRuntimeConfig(ResourceConfig.java:1150)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:318)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:273)
	at org.glassfish.jersey.jdkhttp.JdkHttpHandlerContainer.<init>(JdkHttpHandlerContainer.java:98)
	at org.glassfish.jersey.jdkhttp.JdkHttpServerFactory.createHttpServer(JdkHttpServerFactory.java:104)
	at org.glassfish.jersey.jdkhttp.JdkHttpServerFactory.createHttpServer(JdkHttpServerFactory.java:85)
	at org.glassfish.jersey.jdkhttp.BasicJdkHttpServerTest.testCreateHttpsServer(BasicJdkHttpServerTest.java:87)

testCreateHttpServer(org.glassfish.jersey.jdkhttp.BasicJdkHttpServerTest)  Time elapsed: 0.008 sec  <<< ERROR!
java.lang.NoClassDefFoundError: org/objectweb/asm/ClassVisitor
	at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.glassfish.jersey.server.ResourceConfig.scanClasses(ResourceConfig.java:885)
	at org.glassfish.jersey.server.ResourceConfig._getClasses(ResourceConfig.java:849)
	at org.glassfish.jersey.server.ResourceConfig.getClasses(ResourceConfig.java:755)
	at org.glassfish.jersey.server.ResourceConfig$RuntimeConfig.<init>(ResourceConfig.java:1181)
	at org.glassfish.jersey.server.ResourceConfig$RuntimeConfig.<init>(ResourceConfig.java:1154)
	at org.glassfish.jersey.server.ResourceConfig.createRuntimeConfig(ResourceConfig.java:1150)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:318)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:273)
	at org.glassfish.jersey.jdkhttp.JdkHttpHandlerContainer.<init>(JdkHttpHandlerContainer.java:98)
	at org.glassfish.jersey.jdkhttp.JdkHttpServerFactory.createHttpServer(JdkHttpServerFactory.java:104)
	at org.glassfish.jersey.jdkhttp.JdkHttpServerFactory.createHttpServer(JdkHttpServerFactory.java:85)
	at org.glassfish.jersey.jdkhttp.BasicJdkHttpServerTest.testCreateHttpServer(BasicJdkHttpServerTest.java:78)


Results :

Tests in error: 
  LifecycleListenerTest.testStartupShutdownHooks:146->AbstractJdkHttpServerTester.startServer:113 » NoClassDefFound
  LifecycleListenerTest.testReload:111->AbstractJdkHttpServerTester.startServer:113 » NoClassDefFound
  JdkHttpPackageTest.testJdkHttpPackage:79->AbstractJdkHttpServerTester.startServer:113 » NoClassDefFound
  BasicJdkHttpServerTest.testCreateHttpsServer:87 » NoClassDefFound org/objectwe...
  BasicJdkHttpServerTest.testCreateHttpServer:78 » NoClassDefFound org/objectweb...

Tests run: 6, Failures: 0, Errors: 5, Skipped: 0


 Comments   
Comment by Adam Lindenthal [ 02/Dec/14 ]

Hi Bartosz,

are you sure there are still problems with this on the latest version (as discussed on GitHub under your pull request for ServiceLocator)?
I just tried to build the latest snapshot with JDK 1.8.0_20-b26 and everything runs smooth on my side.

The jdk-http-container module has a parent containers which has the compile scope dependency to jersey-server.

And core-server/pom.xml contains:

        <dependency>
            <groupId>org.ow2.asm</groupId>
            <artifactId>asm-debug-all</artifactId>
            <optional>true</optional>
        </dependency>

,

which is all that should be needed. I re-checked the effective pom of the jdk-http-container and can see the asm dependency there indeed.
If you simply clone the github master and build it with your JDK (btw, could you please share the exact version?), does it still fail?

Thanks,
Adam

Comment by sarxos [ 02/Dec/14 ]

Hi Adam,

My JDK is Oracle Java 1.8.0_25, OS is Ubuntu 14.04.

I performed full build. I removed my local repository content (completely, by rm -rf ~/.m2/repository && mkdir ~/.m2/repository), and executed mvn clean verify. The error this time is completely different, but it seems like it's caused by some issue with the IO. To w/a this problem I had to build the artifacts first (by mvn clean install -P skip-tests) and run tests (by mvn verify) later, after the build with skip-tests is completed. I suspect that the original issue (with missing asm classes) may be caused by the same IO problem because all tests, on the same branch as before, on the same commit, are working well this time.

Therefore, due to above, I think we can close this issue as well, as JERSEY-2716.

The error I noticed:

Could not find artifact org.glassfish.jersey.core:jersey-common:jar:2.14-SNAPSHOT

Stack trace:

testExtendedWadl(org.glassfish.jersey.examples.extendedwadl.ExtendedWadlWebappOsgiTest)  Time elapsed: 0.816 sec  <<< ERROR!
java.io.IOException: Error resolving artifact org.glassfish.jersey.core:jersey-common:jar:2.14-SNAPSHOT: Could not find artifact org.glassfish.jersey.core:jersey-common:jar:2.14-SNAPSHOT in VG (http://192.168.1.30:8081/nexus/content/groups/public/)
	at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:258)
	at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolveFile(AetherBasedResolver.java:239)
	at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:223)
	at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:122)
	at java.net.URL.openStream(URL.java:1038)
	at org.ops4j.pax.exam.forked.provision.StreamUtils.streamCopy(StreamUtils.java:103)
	at org.ops4j.pax.exam.forked.provision.PlatformImpl.download(PlatformImpl.java:133)
	at org.ops4j.pax.exam.forked.ForkedTestContainer.downloadBundle(ForkedTestContainer.java:352)
	at org.ops4j.pax.exam.forked.ForkedTestContainer.installAndStartBundles(ForkedTestContainer.java:281)
	at org.ops4j.pax.exam.forked.ForkedTestContainer.start(ForkedTestContainer.java:150)
	at org.ops4j.pax.exam.spi.reactors.AllConfinedStagedReactor.invoke(AllConfinedStagedReactor.java:79)
	at org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:278)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
	at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:112)
	at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)



[             DefaultJavaRunner] - Unwrapping stream I/O.
[             DefaultJavaRunner] - Unwrapping stream I/O.

Results :

Tests in error: 
  ExtendedWadlWebappOsgiTest.testWadlOptionsMethod » IO Error resolving artifact...
  ExtendedWadlWebappOsgiTest.testExtendedWadl » IO Error resolving artifact org....

Tests run: 4, Failures: 0, Errors: 2, Skipped: 0
Comment by Adam Lindenthal [ 02/Dec/14 ]

Thanks for detailed description. I guess your environment is pretty complex (lot of things that can go wrong).
As you suggested, I am closing this. However, feel free to write us if you have some new observations and start to think that this should be reopened.

Have a nice day,
Adam





[JERSEY-2716] Could not find artifact org.netbeans.api:org-openide-util-lookup:jar:RELEASE80 Created: 28/Nov/14  Updated: 02/Dec/14  Resolved: 02/Dec/14

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 2.13
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sarxos Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: pull-request
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Oracle Java 8, Ubuntu 14.04



 Description   

Hi,

I was trying to build Jersey but I get error from Maven.

Could not find artifact org.netbeans.api:org-openide-util-lookup:jar:RELEASE80

Is there a repository where this artifact can be found? As a temporary w/a I modified the following file:

incubator/html-json/pom.xml

And updated org-openide-util-lookup dependency to:

<dependency>
  <groupId>org.codeartisans.thirdparties.swing</groupId>
  <artifactId>org-openide-util-lookup</artifactId>
  <version>8.3.1</version>
  <scope>provided</scope>
</dependency>

These are different:

  • org.netbeans.api -> org.codeartisans.thirdparties.swing
  • RELEASE80 -> 8.3.1

I can push this change to Jersey repository (on github) if you like.



 Comments   
Comment by sarxos [ 02/Dec/14 ]

Pull request has been created to fix this issue in Jersey repository on Github.

https://github.com/jersey/jersey/pull/127

Comment by sarxos [ 02/Dec/14 ]

The root cause was my Nexus which acts as a mirror. I need to register all custom repositories from poms as proxy in my Nexus and then make them public prior the build is invoked. Everything works well after I did this, thus please close this issue as invalid.

Comment by Adam Lindenthal [ 02/Dec/14 ]

Hi, as discussed on github, I am closing the issue.

Thanks,
Adam





[JERSEY-2715] SEVERE: MessageBodyWriter not found for media type=application/xml, type=... Created: 28/Nov/14  Updated: 10/Dec/14  Resolved: 10/Dec/14

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: tim100@mailinator.com Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I am working on Restful service. The problem occurred after we moved to Glassfish 4.1 . The error string is :

SEVERE: MessageBodyWriter not found for media type=application/xml, type=...

But my classes consume application/json. Here is example:

@Path("get_customer_info")
@Consumes("application/json;charset=utf8")
public class CustomerInfoResource {

@Context
private UriInfo context;

public CustomerInfoResource () {
}

@POST
public Player getPlayerInfo()

{ .... }

}
I have done the following and could not solve it: Added all jersey jars version 2.13 , jackson jars 2.4.3 . Also added jersey-media-json-jackson-2.13.jar which contains org.glassfish.jersey.jackson.JacksonFeature class. By the way ApplicationConfig class is:

@javax.ws.rs.ApplicationPath("resources")
public class ApplicationConfig extends Application {

@Override
public Set<Class<?>> getClasses() {
Set<Class<?>> resources = new java.util.HashSet<Class<?>>();
try

{ Class jsonProvider = Class.forName("org.glassfish.jersey.jackson.JacksonFeature"); resources.add(jsonProvider); }

catch (ClassNotFoundException ex)

{ java.util.logging.Logger.getLogger(getClass().getName()).log(java.util.logging.Level.SEVERE, null, ex); }

addRestResourceClasses(resources);
return resources;
}



 Comments   
Comment by Jakub Podlesak [ 10/Dec/14 ]

MessageBodyWriter is for what you produce, please add also @Produces("application/json") to your resource class.

I am closing this report as invalid. Please feel free to re-open if you think otherwise.





[JERSEY-2714] Location header forcibly expanded to absolute path Created: 25/Nov/14  Updated: 02/Dec/14

Status: Open
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: SimonHGR Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Unless I'm horribly mistaken:

Current version of Jersey (as of November 2014) seems to have decided that a "Location" header that is set on a response will be forcibly pre-pended with the base path of the application.

Presumably, this is an attempt to comply with the HTTP specification, which does indeed call for an absolute URL in this header.

However, common practice is to use a relative URI instead, and earlier versions (sorry I can't be more specific) used to allow this using the ResponseBuilder . header mechanism, although the Response.created(URI) mechanism has, so far as I'm aware, always expanded the location to absolute (which is why my code uses the header mechanism).

The reason that an absolute URL is a disaster is that it will be wrong in a clustered environment. Normal practice, for this reason, is to use a relative URI, and the W3C notes that a change to the specification to "permit" relative URIs is likely to be made.



 Comments   
Comment by Adam Lindenthal [ 02/Dec/14 ]

Hi Simon, this behaviour was introduced in Jersey 2.3 in September 2013 and yes, it was in order to comply with the HTTP specification.
I guess we should discuss this and maybe introduce a property to make both behaviours possible.
I will move the issue to backlog, so that we can plan the work on it in the future.





[JERSEY-2713] jersey 2.13 charset ISO-8859-9 is not working Created: 25/Nov/14  Updated: 27/Feb/15  Resolved: 27/Feb/15

Status: Resolved
Project: jersey
Component/s: release
Affects Version/s: 1.18.1, 2.13
Fix Version/s: None

Type: Bug Priority: Major
Reporter: creativeUser Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: incomplete
Remaining Estimate: 2 weeks
Time Spent: Not Specified
Original Estimate: 2 weeks
Environment:

Java Tomcat 7 Jersey 2.13



 Description   

The charset for Turkish is not responding in 2.13 release but works for 1.18
Details;

http://stackoverflow.com/questions/26897632/restful-service-jersey-2x-charset-iso-8859-9-is-not-working



 Comments   
Comment by Libor Kramolis [ 14/Jan/15 ]

I can not reproduce the problem. Try to prepare reproducible test case. I've prepared unit test for you - https://gist.github.com/shamoh/692ff96e86f5ce775d51.

Comment by Michal Gajdos [ 18/Feb/15 ]

Hi, have you tried to run the provided test-case?

Comment by Adam Lindenthal [ 27/Feb/15 ]

Seems that creativeUser is not an activeUser any more

I will close the issue now, feel free to request reopening in case you can provide a reproducible test case (e.g. based on LIbor's code).

Regards,
Adam





[JERSEY-2712] Client leaks connections when read entity type is a stream Created: 25/Nov/14  Updated: 14/Jan/15  Resolved: 14/Jan/15

Status:<