[JERSEY-1579] Regression: when no entity body is present in request, Jersey returns 415 instead of providing null as entity parameter value to the appropriate resource method Created: 14/Nov/12  Updated: 10/Sep/15  Resolved: 16/Nov/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

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


 Description   

Although it is not clear to me from the spec how an implementation should behave in this case,
Jersey used to invoke resource method with null value provided as entity parameter until version 2.0-m09-1.

We should IMHO fix this or at least provide a configurable option to allow current users to switch back to the original behaviour.



 Comments   
Comment by Jakub Podlesak [ 16/Nov/12 ]

fixed on the master branch





[JERSEY-1552] Inbound headers (response) are not modifiable on the client side in filter or interceptor. Created: 01/Nov/12  Updated: 10/Sep/15  Resolved: 01/Nov/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Major
Reporter: Marek Potociar Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours
Original Estimate: Not Specified


 Description   

Trying to modify inbound headers on the client side in a filter or interceptor results in an UnsupportedOperationException.






[JERSEY-1551] Providers registered via DynamicFeature for particular contracts are registered for all recognized contracts. Created: 01/Nov/12  Updated: 10/Sep/15  Resolved: 01/Nov/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m09
Fix Version/s: 2.0-m10, 2.0

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





[JERSEY-1546] Extended WADL support Created: 30/Oct/12  Updated: 10/Sep/15  Resolved: 09/Nov/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: New Feature Priority: Blocker
Reporter: Miroslav Fuksa Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 day, 11 hours
Original Estimate: 5 days





[JERSEY-1539] Response#getEntity does not throw IllegalStateException Created: 29/Oct/12  Updated: 10/Sep/15  Resolved: 29/Oct/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m09
Fix Version/s: 2.0-m10

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

javadoc of Response#getEntity() says:

Throws:
java.lang.IllegalStateException - if the entity was previously fully consumed as an input stream, or if the response has been closed.

Neither close, nor consume does throw any exception, null is returned.

Response response = client.target(url).buildGet().invoke();
response.close(); //or response.readEntity(String.class);
response.getEntity();


 Comments   
Comment by jan.supol [ 29/Oct/12 ]

Duplicate of JERSEY-1449





[JERSEY-1520] ReaderInterceptor not invoked Created: 21/Oct/12  Updated: 10/Sep/15  Resolved: 25/Oct/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m09
Fix Version/s: 2.0-m10, 2.0

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

Glassfish 4 b58



 Description   

aroundReadFrom is not invoked for any provided ReaderInterceptor.

Given the class below, the WriterInterceptor's aroundWriteTo is called, aroundReadFrom not.

@Provider
class TestInterceptor2 implements ReaderInterceptor, WriterInterceptor {

private static Logger log = Logger.getLogger(TestInterceptor2.class
.getName());

@Override
public Object aroundReadFrom(ReaderInterceptorContext rCtx)
throws IOException, WebApplicationException

{ log.info("RI2 around read to called"); return rCtx.proceed(); }

@Override
public void aroundWriteTo(WriterInterceptorContext wCtx)
throws IOException, WebApplicationException

{ log.info("WI2 around write to called"); wCtx.proceed(); }

}



 Comments   
Comment by algermissen [ 25/Oct/12 ]

Well, this is embarassing. Surely you need to send a request body for the message body reader and its interceptors to be invoked.

Works fine, actually.

Sorry 'bout that.
Jan





[JERSEY-1519] NPE in Jersey wadl when generating resource Created: 19/Oct/12  Updated: 10/Sep/15  Resolved: 19/Nov/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m09
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

On response for request

OPTIONS /jaxrs_spec_resource_requestmatching_web/resource/subresource/something

and a resource

@Path("resource/subresource")
public class MainSubResource {
	@GET
	@Path("{id}")
	public String neverHere() {
		return ID;
	}
}

I got:

java.lang.NullPointerException
at org.glassfish.jersey.server.wadl.internal.WadlBuilder.generateResource(WadlBuilder.java:400)
at org.glassfish.jersey.server.wadl.internal.WadlBuilder.generateResource(WadlBuilder.java:322)
at org.glassfish.jersey.server.wadl.internal.WadlBuilder.generate(WadlBuilder.java:101)
at org.glassfish.jersey.server.wadl.internal.WadlApplicationContextImpl.getApplication(WadlApplicationContextImpl.java:105)
at org.glassfish.jersey.server.wadl.internal.WadlApplicationContextImpl.getApplication(WadlApplicationContextImpl.java:124)
at org.glassfish.jersey.server.internal.routing.MethodSelectingRouter$6.apply(MethodSelectingRouter.java:613)
at org.glassfish.jersey.server.internal.routing.MethodSelectingRouter$6.apply(MethodSelectingRouter.java:596)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:198)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:316)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:174)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:747)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:309)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:346)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:312)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:195)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1593)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:285)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:665)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:604)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:337)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:240)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:172)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:825)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:578)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:558)
at java.lang.Thread.run(Thread.java:662)



 Comments   
Comment by jan.supol [ 01/Nov/12 ]

Fixed in Trunk





[JERSEY-1512] UserDefined provider that should override standard entity providers is not used Created: 18/Oct/12  Updated: 10/Sep/15  Resolved: 19/Nov/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m09
Fix Version/s: 2.0-m10

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes


 Description   

For instance:

@Provider
public class ByteArrayProvider implements
		MessageBodyReader<byte[]>, MessageBodyWriter<byte[]> {
...
}
@Path("resource")
public class Resource {
	@Path("bytearray")
	@POST
	public byte[] bytearray(byte[] bytes) {
		return bytes;
	}
}

Standard provider is used, not ByteArrayProvider.






[JERSEY-1507] Standard providers for java.lang.Boolean, java.lang.Character, java.lang.Number does not work Created: 16/Oct/12  Updated: 10/Sep/15  Resolved: 30/Oct/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m09
Fix Version/s: 2.0-m10

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours
Original Estimate: Not Specified


 Description   
@Path("resource")
public class Resource {
	@Path("number")
	@POST
	@Consumes(MediaType.TEXT_PLAIN)
	@Produces(MediaType.TEXT_PLAIN)
	public Number number(Number number){
		return number;
	}

	@Path("boolean")
	@POST
	@Consumes(MediaType.TEXT_PLAIN)
	@Produces(MediaType.TEXT_PLAIN)
	public Boolean bigbool(Boolean bool){
		return bool;		
	}
	@Path("character")
	@POST
	@Consumes(MediaType.TEXT_PLAIN)
	@Produces(MediaType.TEXT_PLAIN)
	public Character character(Character character){
		return character;
	}

}

...
Invocation.Builder builder = webtarget.request(MediaType.TEXT_PLAIN_TYPE);
Invocation i = builder.build("POST",Entity.entity(new Boolean(true), MediaType.TEXT_PLAIN_TYPE));
i.invoke();

returns:

<< 415 UNSUPPORTED_MEDIA_TYPE

spec says:

java.lang.Boolean, java.lang.Character, java.lang.Number Only for text/plain. Corresponding
primitive types supported via boxing/unboxing conversion.

Note that primitive types work.

Also, for BigDecimal (which is Number as well) The following message prints out:

Caused by: org.glassfish.jersey.message.internal.MessageBodyProviderNotFoundException: MessageBodyWriter not found for media type=tex
t/plain, type=class java.math.BigDecimal, genericType=class java.math.BigDecimal.
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:219)
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:163)
at org.glassfish.jersey.message.internal.ExceptionWrapperInterceptor.aroundWriteTo(ExceptionWrapperInterceptor.java:79)
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:163)
at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:825)
at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:815)
at org.glassfish.jersey.client.RequestWriter.writeRequestEntity(RequestWriter.java:240)
at org.glassfish.jersey.client.HttpUrlConnector._apply(HttpUrlConnector.java:213)
at org.glassfish.jersey.client.HttpUrlConnector.apply(HttpUrlConnector.java:136)
at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:208)






[JERSEY-1506] OutboundJaxrsResponse$Builder.link is not supported yet Created: 16/Oct/12  Updated: 10/Sep/15  Resolved: 19/Nov/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m09
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 minute
Original Estimate: 3 hours


 Description   

When adding link to ResponseBuilder, the following error appears:

ERROR: java.lang.UnsupportedOperationException: Not supported yet.
at org.glassfish.jersey.message.internal.OutboundJaxrsResponse$Builder.link(OutboundJaxrsResponse.java:506)
at com.sun.ts.tests.jaxrs.api.client.clientresponsecontext.JAXRSClient.hasLinkWhenLinkTest(JAXRSClient.java:756)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ts.lib.harness.EETest.run(EETest.java:550)
at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:113)
at com.sun.ts.tests.common.vehicle.EmptyVehicleRunner.run(EmptyVehicleRunner.java:30)
at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:102)
at com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:446)
at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:210)
at com.sun.ts.lib.harness.EETest.run(EETest.java:257)
at com.sun.ts.tests.common.vehicle.VehicleClient.main(VehicleClient.java:27)






[JERSEY-1504] Update grizzly to 2.3-beta5 Created: 16/Oct/12  Updated: 10/Sep/15  Resolved: 18/Oct/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Blocker
Reporter: Pavel Bucek Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 4 hours
Original Estimate: Not Specified





[JERSEY-1498] Integrate Jersey 2.0-m09 into GF trunk Created: 15/Oct/12  Updated: 10/Sep/15  Resolved: 16/Oct/12

Status: Closed
Project: jersey
Component/s: release
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: Task Priority: Blocker
Reporter: Pavel Bucek Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 6 hours, 30 minutes
Original Estimate: 3 hours


 Comments   
Comment by Jakub Podlesak [ 16/Oct/12 ]

Changes submitted into GF workspace.





Setup hudson job to verify Jersey snapshot with the latest GF (to catch integration issues early) (JERSEY-1483)

[JERSEY-1496] Setup hudson job Created: 15/Oct/12  Updated: 10/Sep/15  Resolved: 13/Nov/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: Sub-task Priority: Blocker
Reporter: Pavel Bucek Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 10 hours
Original Estimate: 3 hours





Setup hudson job to verify Jersey snapshot with the latest GF (to catch integration issues early) (JERSEY-1483)

[JERSEY-1495] Propose GF integration process Created: 15/Oct/12  Updated: 10/Sep/15  Resolved: 16/Nov/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: Sub-task Priority: Blocker
Reporter: Pavel Bucek Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 hours
Original Estimate: 6 hours


 Description   
  • include link to gf workspace setup guide
  • how to maintain GF integration patch
  • policy for monitoring continuous integration job
  • who is responsible for fixing new integration issues





Improved diagnostics (JERSEY-1470)

[JERSEY-1491] Add Errors utility (similar to the one in Jersey 1.x) Created: 15/Oct/12  Updated: 10/Sep/15  Resolved: 19/Nov/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: Sub-task Priority: Blocker
Reporter: Marek Potociar Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 15 hours
Original Estimate: 12 hours

Issue Links:
Duplicate
is duplicated by JERSEY-1138 Add support for injectable Errors (li... Closed

 Description   

Validation should be converted to leverage the new feature as part of the task. This will allow to get rid of the manual issue list creation and passing to the resource building and validation API.






Improved diagnostics (JERSEY-1470)

[JERSEY-1489] Improve guidelines on error handling (rethrowing, logging, meaningful logged messages, ...) Created: 15/Oct/12  Updated: 10/Sep/15  Resolved: 29/Oct/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: Sub-task Priority: Blocker
Reporter: Marek Potociar Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours
Original Estimate: 3 hours





[JERSEY-1483] Setup hudson job to verify Jersey snapshot with the latest GF (to catch integration issues early) Created: 15/Oct/12  Updated: 10/Sep/15  Resolved: 16/Nov/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: Improvement Priority: Blocker
Reporter: Martin Matula Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: 0 minutes Remaining Estimate: Not Specified
Σ Time Spent: 13 hours Time Spent: Not Specified
Σ Original Estimate: 9 hours Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
JERSEY-1495 Propose GF integration process Sub-task Closed Jakub Podlesak  
JERSEY-1496 Setup hudson job Sub-task Closed Jakub Podlesak  




[JERSEY-1481] Ordering of MBW still does not seem to work. When the MBW type parameter is provided in a super class, seems it is not extracted correctly. Jakub has the use-case (from glassfish) that is still broken. Created: 12/Oct/12  Updated: 10/Sep/15  Resolved: 07/Nov/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Blocker
Reporter: Martin Matula Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 hours
Original Estimate: 3 hours


 Comments   
Comment by Pavel Bucek [ 22/Oct/12 ]

can you please share the testcase or describe it here somehow?

Comment by Martin Matula [ 22/Oct/12 ]

Work with Jakub. He reported the issue, but did not file it, so I filed it for him.





[JERSEY-1477] Support for async callbacks Created: 12/Oct/12  Updated: 10/Sep/15  Resolved: 30/Oct/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: New Feature Priority: Blocker
Reporter: Martin Matula Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 19 hours
Original Estimate: 18 hours





[JERSEY-1474] Convert existing binders to features. Remove the binder classes from the public API (they should be hidden in the features). Created: 12/Oct/12  Updated: 10/Sep/15  Resolved: 07/Nov/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: New Feature Priority: Blocker
Reporter: Martin Matula Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 8 hours
Original Estimate: 6 hours


 Description   

Demo: No binder class in the public API, all tests passing.






[JERSEY-1473] SSE EventSource does not shut down the executor service and holds the thread until the next event arrives. We need to refactor it to be able to shut it down immediately upon calling close(). Created: 12/Oct/12  Updated: 10/Sep/15  Resolved: 17/Oct/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Blocker
Reporter: Martin Matula Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 minute
Original Estimate: 3 hours

Issue Links:
Related
is related to JERSEY-1472 Refactor SSE client-side support to u... Closed

 Comments   
Comment by Marek Potociar [ 17/Oct/12 ]

Resolved as part of JERSEY-1472.





[JERSEY-1472] Refactor SSE client-side support to utilize ChunkedInput (similarly to the server side utilizing ChunkedOutput). Created: 12/Oct/12  Updated: 10/Sep/15  Resolved: 22/Oct/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: Improvement Priority: Blocker
Reporter: Martin Matula Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 13 hours
Original Estimate: 12 hours

Issue Links:
Related
is related to JERSEY-1473 SSE EventSource does not shut down th... Closed




[JERSEY-1471] Improve Container API (besides JERSEY-1173) - add missing start/stop methods, make it more generic Created: 12/Oct/12  Updated: 10/Sep/15  Resolved: 15/Oct/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: Improvement Priority: Blocker
Reporter: Martin Matula Assignee: Pavel Bucek
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JERSEY-966 Look into unification of core-server ... Closed

 Comments   
Comment by Pavel Bucek [ 15/Oct/12 ]

already covered by JERSEY-966





[JERSEY-1469] ReaderInterceptor#aroundReadFrom & WriterInterceptor#aroundWriteTo are defined to throw WebApplicationException but throw it encapsulated in MessageProcessingException Created: 12/Oct/12  Updated: 10/Sep/15  Resolved: 01/Nov/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m08
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Michal Gajdos
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 minute
Original Estimate: 3 hours


 Description   

ExceptionWrapperInterceptor encapsulates webapplicationException into a MessageProcessingException, so when a user want to check for WebApplicationException (The user exception) thrown by the user, a MessageProcessingException is what he is given instead.
But javadoc says:

WebApplicationException - thrown by wrapped method.






[JERSEY-1468] Jersey prints error stack trace instead of throwing the error from Response#readEntity() Created: 11/Oct/12  Updated: 10/Sep/15  Resolved: 01/Nov/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m08
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 minute
Original Estimate: 3 hours


 Description   
class Interceptor implements ReaderInterceptor{
	@Override
	public Object aroundReadFrom(ReaderInterceptorContext ctx)
			throws IOException, WebApplicationException {
		throw new IOException("error");
	}
}

response = invocation.invoke();
String entity = response.readEntity(String.class);

I throw the exception in the ReaderInterceptor, but
readEntity (InboundMessageContext) prints the stack trace of the IOException and returns the original entity.

Java has no way to get know the Exception occurred, i.e. there is no programatic way to get know the Exception occurred in the interceptor. Also, the throwing of IOException in the interceptor has no meaning this way. Better way to do this is the way it is done in bufferEntity, where IOException is encapsulated in MessageProcessingException.






[JERSEY-1463] There is no Content-Type set in the Response when entity length is 0 Created: 10/Oct/12  Updated: 10/Sep/15  Resolved: 19/Oct/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m08
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Pavel Bucek
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 minute
Original Estimate: 3 hours


 Description   
@Path("resource")
public class MediaResource {
	@GET
	@Path("method")
	@Produces(MediaType.APPLICATION_ATOM_XML)
	public Response method(){
		return Response.ok().build();
	}
}

Request/Response:

>> "GET /web/resource/method HTTP/1.1[\r][\n]"
>> "User-Agent: Jakarta Commons-HttpClient/3.1[\r][\n]"
>> "Host: localhost:6080[\r][\n]"
>> "[\r][\n]"
<< "HTTP/1.1 200 OK[\r][\n]"
<< "Server: Apache-Coyote/1.1[\r][\n]"
<< "Content-Length: 0[\r][\n]"
<< "Date: Wed, 10 Oct 2012 15:04:51 GMT[\r][\n]"

It gave the Content-Type header in Jersey 1.13



 Comments   
Comment by Pavel Bucek [ 19/Oct/12 ]

is there any reason for content-type to be present when there is no entity (other than Jersey 1 included it in the response)?

Comment by Pavel Bucek [ 19/Oct/12 ]

The Content-Type entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET.

(from rfc2616, sec 14.17)

not sure whether I understand it correctly, but it says it should be media type of entity body. there is no entity body, thus no content-type header. Am I wrong?





[JERSEY-1462] Content-Type is Text/plain when no @Produces Created: 10/Oct/12  Updated: 30/Oct/12  Resolved: 30/Oct/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m08
Fix Version/s: 2.0-m10

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Miroslav Fuksa
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 hours
Original Estimate: 3 hours


 Description   
@Path("nomedia")
public class NoMediaResource {
	@GET
	@Path("nothing")
	public String nothing() {
		return "nothing";
	}
}

The request/response to this resource looks like:

>> "GET /web/nomedia/nothing HTTP/1.1[\r][\n]"
>> "User-Agent: Jakarta Commons-HttpClient/3.1[\r][\n]"
>> "Host: localhost:6080[\r][\n]"
>> "[\r][\n]"
<< "HTTP/1.1 200 OK[\r][\n]"
<< "Server: Apache-Coyote/1.1[\r][\n]"
<< "Content-Type: text/plain[\r][\n]"
<< "Content-Length: 7[\r][\n]"
<< "Date: Wed, 10 Oct 2012 14:47:21 GMT[\r][\n]"

But the spec. Section 3.8, paragraph 9 says:

If M contains '/' or 'application/*', set Mselected = 'application/octet-stream', finish.



 Comments   
Comment by Miroslav Fuksa [ 23/Oct/12 ]

Agreed with Jan:
This issue is not actually a bug. 3.8, point 2 says:

"Else set P = fV (writers)g where ‘writers’ is the set of MessageBodyWriter that support the class of the returned entity object."

In the test case MBWriters for text/plain will be found and therefore specific Media Type will be found and algorithm will not get to point 9 at all and will stop at point 8.

Comment by Miroslav Fuksa [ 30/Oct/12 ]

see previous comment - works correctly. Test has been written and merged to master.





[JERSEY-1461] Response does not contain ContentType from @Produces on a resource class Created: 10/Oct/12  Updated: 10/Sep/15  Resolved: 19/Oct/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m08
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Pavel Bucek
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour
Original Estimate: 3 hours


 Description   
@Produces(MediaType.TEXT_HTML)
@Path("resource")
public class MediaResource {
	@GET
	@Path("class")
	public Response clazz(){
		return Response.ok().build();
	}
}

Request / Response to this resource is:

>> "GET /web/resource/class HTTP/1.1[\r][\n]"
>> "User-Agent: Jakarta Commons-HttpClient/3.1[\r][\n]"
>> "Host: localhost:6080[\r][\n]"
>> "[\r][\n]"
<< "HTTP/1.1 200 OK[\r][\n]"
<< "Server: Apache-Coyote/1.1[\r][\n]"
<< "Content-Length: 0[\r][\n]"
<< "Date: Wed, 10 Oct 2012 14:21:26 GMT[\r][\n]"
<< "[\r][\n]"

Spec., Chapter 3.8, Step 2. says:

Else if the class is annotated with @Produces, set P = V (class).



 Comments   
Comment by jan.supol [ 10/Oct/12 ]

See Jersey-1463 for the possible reason

Comment by Pavel Bucek [ 19/Oct/12 ]

well.. if there is no entity, there is no content-type; can you re-test with actually returning some entity?

Comment by jan.supol [ 19/Oct/12 ]

Rfc 2616, section 14.17 says:

The Content-Type entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET.

This does neither say the Content-Type can be omitted when no entity, nor it says it should not be omitted, correct, but it surely say it shall be there for HEAD requests, which Jersey have not.

Comment by Pavel Bucek [ 19/Oct/12 ]

I haven't seen any HEAD request in issue description..

anyway, HEAD is about receiving everything exact response as GET would return, but with not entity (all headers should be preserved, even Content-Length and Content-Type).

Comment by Pavel Bucek [ 19/Oct/12 ]

I would propose to close this one and continue in JERSEY-1463, is it ok? (seems like duplicate to me and the other one is more relevant to the real cause).

Comment by jan.supol [ 19/Oct/12 ]

I see. Please close both 1461 and 1463 as invalid, then.





[JERSEY-1458] UriBuilder#resolveTemplate(Map) does not throw IAE. Created: 09/Oct/12  Updated: 10/Sep/15  Resolved: 19/Oct/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m08
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours, 30 minutes
Original Estimate: 3 hours


 Description   

javadoc says:

java.lang.IllegalArgumentException - if the name-value map or any of the names or values in the map is null.

but this does not throw any exception:

		Map<String, Object> map = new HashMap<String, Object>();
		map.put("a", "xyz");
		map.put(null, "path");
		UriBuilder builder = UriBuilder.fromPath("").path("{a}/{b}");
		builder.resolveTemplates(map);





[JERSEY-1457] UriBuilder#uri(String) throws Schema specific part is opaque when uri does not have the schema Created: 09/Oct/12  Updated: 10/Sep/15  Resolved: 01/Nov/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m08
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 minute
Original Estimate: 3 hours

Issue Links:
Related
is related to JERSEY-1698 UriBuilder#uri(String) throws Schema ... Closed

 Description   
String origUris[] = {"news:comp.lang.java", "tel:+1-816-555-1212"};
URI[] replaceUris = {new URI(null, "news.lang.java", null), new URI(null, "+1-866-555-1212", null)};
int cnt = 0;
while (cnt < origUris.length()){
UriBuilder.fromUri(new URI(origUris[cnt])).uri(replaceUris[cnt].toASCIIString()).build();
cnt++;
}

throws:

Schema specific part is opaque.

This worked in previous version. Also UriBuilder.fromUri(new URI(origUris[cnt])).uri(replaceUris[cnt]).build(); works. There has been added additional check for schema in the String, but the schema can be taken from the original.






[JERSEY-1455] every request with entity contains headers "content-encoding" and "content-language" set to "" (blank string). Created: 09/Oct/12  Updated: 10/Sep/15  Resolved: 22/Oct/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Blocker
Reporter: Pavel Bucek Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours
Original Estimate: 3 hours


 Description   

headers should not be present when not explicitly set.

testcase: everything with client sending entity, for example HttpMethodEntityTest.testPost(). Enable logging to see request headers.






[JERSEY-1454] UriBuilder#build(Object...,false) does not leave '/' symbols uncoded Created: 09/Oct/12  Updated: 10/Sep/15  Resolved: 17/Oct/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m08
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Pavel Bucek
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 30 minutes
Original Estimate: 3 hours


 Description   

the false does still encode slash into '%2F'; there is no difference in true and false.
But the javadoc says:

encodeSlashInPath - if true, the slash ('/') characters in parameter values will be encoded if the template is placed in the URI path component, otherwise the slash characters will not be encoded in path templates.

Example:

		String s[] = { "path-rootless/test2", "x%yz", "/path-absolute",
				"%test1", "fred@example.com" };	
		URI uri = UriBuilder.fromPath("").path("{v}/{w}/{x}/{y}/{z}/{w}")
				.build(s[0], s[1], s[2], s[3], s[4], s[1], false);
System.out.println(uri.getRawPath); //path-rootless%2Ftest2/x%25yz/%2Fpath-absolute/%25test1/fred@example.com/x%25yz


 Comments   
Comment by jan.supol [ 09/Oct/12 ]

#resolveTemplate(String, Object, false) does encode it as well.

Comment by Pavel Bucek [ 17/Oct/12 ]

issue mentioned in description is invalid, it is calling

build(Object...)

instead if

build(Object[] values, boolean encodeSlashInPath)

or

buildFromEncoded(Object...)
Comment by Pavel Bucek [ 17/Oct/12 ]

the other issue (first comment) looks like already solved or need more data. My testcase:

        URI uri = UriBuilder.fromPath("").path("test/{v}/test")
                .resolveTemplate("v", "/path-absolute", false).build();
        System.out.println(uri.getRawPath()); //path-rootless%2Ftest2/x%25yz/%2Fpath-absolute/%25test1/fred@example.com/x%25yz

prints:

test//path-absolute/test

which seems correct.





[JERSEY-1453] ResponseBuilder#allow((Set)null) throws NPE Created: 08/Oct/12  Updated: 10/Sep/15  Resolved: 05/Nov/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m08
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour, 31 minutes
Original Estimate: 3 hours


 Description   

javadoc says:

if null any existing allowed method list will be removed.

But

RuntimeDelegate.getInstance().createResponseBuilder().allow((Set<String>)null).build();

result in

java.lang.NullPointerException
at org.glassfish.jersey.message.internal.OutboundJaxrsResponse$Builder.allow(OutboundJaxrsResponse.java:517)



 Comments   
Comment by jan.supol [ 08/Oct/12 ]

The same for allow(String...)

Comment by jan.supol [ 01/Nov/12 ]

still does not work for #allow((String[])null)





[JERSEY-1449] Response#bufferEntity does not Throw IllegalStateException Created: 04/Oct/12  Updated: 10/Sep/15  Resolved: 12/Mar/13

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m08
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 4 hours, 30 minutes
Original Estimate: 3 hours


 Description   
Response response = Response.ok().build();
response.close();
response.bufferEntity();


 Comments   
Comment by jan.supol [ 04/Oct/12 ]

getEntity does not throw that either.

Comment by jan.supol [ 04/Mar/13 ]

both hasEntity and getEntity still does not throw Illegal State Exception in RC1, though getEntity throws NPE





[JERSEY-1447] ClientRequestContext#getEntityAnnotations() returns no annotations Created: 03/Oct/12  Updated: 10/Sep/15  Resolved: 22/Oct/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m08
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours
Original Estimate: 3 hours


 Description   

Javadoc says:

Get the annotations attached to the entity.

Attaching the annotations to an entity:

@Provider
public class Provider {
}

Annotation[] annotations = Provider.class.getAnnotations();
ClientRequestFilter filter = new ClientRequestFilter(){
	@Override
	public void filter(ClientRequestContext context) throws IOException {
             Annotation[] annotations = context.getEntityAnnotations();
//annotations is an empty array!
	}
}

Entity<String> post = Entity.entity("test", MediaType.WILDCARD_TYPE,
				annotations);
Client client = ClientFactory.newClient();
Configuration config = client.configuration();
config.register(filter);
WebTarget target = client.target("http://localhost:8080/");
Invocation.Builder builder = target.request();
Invocation invocation = builder.buildPost(post); //!!send entity with attached annotations
Response response = invocation.invoke();


 Comments   
Comment by Miroslav Fuksa [ 17/Oct/12 ]

Just a note:
We have discussed whether also annotation from entity class should be returned.
example:

@MyAnnotation
public class MyEntity {
}

public final class MyFilter implements ClientRequestFilter {

    @Override
    public void filter(ClientRequestContext request) throws IOException {

      ???? request.getEntityAnnotations() // should return also MyAnnotaion?
      ...
    }
    
}

We have decided to make it in the same way as the server handles it. Server does not return class annotations. ContainerResponseContext.getEntityAnnotations returns:
1. annotaions attached to entity in ResponseBuilder, example: Response response = Response.ok().entity("get", new Annotation[]

{ANNOTATION}

).build()
2. resource method annotations

Therefore the client will beheave the same and ClientRequestContext.getEntityAnnotations() will not return class annotaions.





[JERSEY-1444] ContainerRequestContext.setRequestUri() does not change the uri to go to Created: 02/Oct/12  Updated: 10/Sep/15  Resolved: 22/Oct/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m08
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 hours
Original Estimate: 3 hours


 Description   

On a @PreMatching Request filter there is

URI uri;
try {
	uri = new URI(requestContext.getUriInfo().getPath() + "uri");
} catch (URISyntaxException e) {
	throw new IOException(e);
}
requestContext.setRequestUri(uri);

But it goes to original resource method anyway.






[JERSEY-1442] WebTarget#resolveTemplate(,,boolean) gets the same result whether the boolean is true or false Created: 02/Oct/12  Updated: 10/Sep/15  Resolved: 19/Oct/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m08
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Pavel Bucek
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 minute
Original Estimate: 3 hours


 Description   

the slash is not encodeded in either case.



 Comments   
Comment by Pavel Bucek [ 19/Oct/12 ]

included testcase would significantly improve this bug report.

following gives expected results:

        Client c = ClientFactory.newClient();

        WebTarget webTarget = c.target("http://oracle.com/{a}");

        System.out.println(webTarget.resolveTemplate("a", "/test", false).getUri());
        System.out.println(webTarget.resolveTemplate("a", "/test", true).getUri());

result:

http://oracle.com//test
http://oracle.com/%2Ftest

closing as invalid, feel free to reopen with a testcase.





[JERSEY-1425] Implement support for javax.ws.rs.ConstrainedTo annotation. Created: 17/Sep/12  Updated: 10/Sep/15  Resolved: 22/Oct/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: New Feature Priority: Blocker
Reporter: Marek Potociar Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 18 hours
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by JERSEY-1476 Support @ConstrainTo annotation from ... Closed




[JERSEY-1422] ContainerResponseContext#getHEaderString does not use HeaderDelegate Created: 12/Sep/12  Updated: 10/Sep/15  Resolved: 22/Oct/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m07
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Pavel Bucek
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 30 minutes
Original Estimate: 3 hours


 Description   

javadoc says:

The method converts the non-string header values to strings using a RuntimeDelegate.HeaderDelegate if one is available.

Basically, I have this server side:

public class StringBean {
	private String header;

	public String get() {
		return header;
	}

	public void set(String header) {
		this.header = header;
	}
	
	@Override
	public String toString() {
		return "StringBean. To get a value, use rather #get() method.";
	}

	public StringBean(String header) {
		super();
		this.header = header;
	}
}


@Provider
public class StringBeanHeaderDelegate implements HeaderDelegate<StringBean> {

	@Override
	public StringBean fromString(String string) throws IllegalArgumentException {
		return new StringBean(string);
	}

	@Override
	public String toString(StringBean bean) throws IllegalArgumentException {
		return bean.get();
	}
}

@Path("resource")
class Resource {
...
@POST
@Path("xxx")
public Response xxx(){
return Response.ok().header("HEADER",new StringBean("Entity"));
}
}

but responseContext:

class Filter implements ContainerResponseFilter {
	public void filter(ContainerRequestContext requestContext,
			ContainerResponseContext responseContext) throws IOException {
               String header = responseContext.getHeaderString("HEADER");
        }
}

gets:

StringBean. To get a value, use rather #get() method.

in header.

It works the same for both automatic discovery of the HeaderDelegate provider and putting the delegate to Application#getClasses().



 Comments   
Comment by Pavel Bucek [ 22/Oct/12 ]

That was a bug in HeaderDelegate javadoc, which is already fixed, see http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/ext/RuntimeDelegate.HeaderDelegate.html

closing as won't fix, since reported issue is no longer valid with recent spec change.





[JERSEY-1409] Extended WADL generation fail under OSGI Created: 06/Sep/12  Updated: 10/Sep/15  Resolved: 12/Nov/12

Status: Closed
Project: jersey
Component/s: osgi
Affects Version/s: 1.13
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Major
Reporter: Mikhail Mazursky Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 10 hours
Original Estimate: Not Specified
Environment:

Linux, Equinox 3.7, OpenJDK 1.7.0_03


Tags: classloader, osgi, wadl

 Description   

Using code based on [1]:

@Override
public List<WadlGeneratorDescription> configure() {
	return generator(WadlGeneratorResourceDocSupport.class).prop("resourceDocStream", "resourcedoc.xml").descriptions();
}

i get the following stacktrace:

java.lang.RuntimeException: Could not load wadl generators from wadlGeneratorDescriptions.
        at com.sun.jersey.api.wadl.config.WadlGeneratorConfig.createWadlGenerator(WadlGeneratorConfig.java:184) ~[na:na]
        at com.sun.jersey.server.impl.wadl.WadlApplicationContextImpl.<init>(WadlApplicationContextImpl.java:92) ~[na:na]
        at com.sun.jersey.server.impl.wadl.WadlFactory.init(WadlFactory.java:96) ~[na:na]
        at com.sun.jersey.server.impl.application.RootResourceUriRules.initWadl(RootResourceUriRules.java:169) ~[na:na]
        at com.sun.jersey.server.impl.application.RootResourceUriRules.<init>(RootResourceUriRules.java:106) ~[na:na]
        at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1300) ~[na:na]
        at com.sun.jersey.server.impl.application.WebApplicationImpl.access$700(WebApplicationImpl.java:163) ~[na:na]
        at com.sun.jersey.server.impl.application.WebApplicationImpl$13.f(WebApplicationImpl.java:769) ~[na:na]
        at com.sun.jersey.server.impl.application.WebApplicationImpl$13.f(WebApplicationImpl.java:765) ~[na:na]
        at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193) ~[na:na]
        at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:765) ~[na:na]
        at com.sun.jersey.guice.spi.container.servlet.GuiceContainer.initiate(GuiceContainer.java:121) ~[na:na]
        at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:319) ~[na:na]
        at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:609) ~[na:na]
        at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:210) ~[na:na]
        at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:374) ~[na:na]
        at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:557) ~[na:na]
        [snip]
Caused by: java.lang.RuntimeException: The resource 'resourcedoc.xml' does not exist.
        at com.sun.jersey.api.wadl.config.WadlGeneratorLoader.setProperty(WadlGeneratorLoader.java:203) ~[na:na]
        at com.sun.jersey.api.wadl.config.WadlGeneratorLoader.loadWadlGenerator(WadlGeneratorLoader.java:139) ~[na:na]
        at com.sun.jersey.api.wadl.config.WadlGeneratorLoader.loadWadlGeneratorDescriptions(WadlGeneratorLoader.java:114) ~[na:na]
        at com.sun.jersey.api.wadl.config.WadlGeneratorConfig.createWadlGenerator(WadlGeneratorConfig.java:182) ~[na:na]
        ... 66 common frames omitted

The same code works perfectly if used outside of OSGI (under Grizzly).

[1]: https://wikis.oracle.com/display/Jersey/HowToConfigureExtendedWADL



 Comments   
Comment by Mikhail Mazursky [ 06/Sep/12 ]

The problem is in com.sun.jersey.api.wadl.config.WadlGeneratorLoader.setProperty() that uses wrong (for OSGI) classloader:

final String resource = propertyValue.toString();
ClassLoader loader = Thread.currentThread().getContextClassLoader();
if (loader == null) {
    loader = WadlGeneratorLoader.class.getClassLoader();
}
final InputStream is = loader.getResourceAsStream(resource);
if (is == null) {
    String message = "The resource '" + resource + "' does not exist.";
    throw new RuntimeException(message);
}

I see some possible workarounds/fixes:

  • Somehow pass a Classloader to use to load specified resource;
  • Improve parameter passing to property method so that InputStream can be passed - i tried to load the resource myself, then pass it's contents as ByteArrayInputStream to the .prop("resourceDocStream", bais) but it fails because of a too strick type check:
    final Class<?> paramClazz = method.getParameterTypes()[0];
    if (paramClazz == propertyValue.getClass()) {
        method.invoke(generator, propertyValue);
    

    I propose to change this code to:

    final Class<?> paramClazz = method.getParameterTypes()[0];
    -- if (paramClazz == propertyValue.getClass()) {
    ++ if (paramClazz.isAssignableFrom(propertyValue.getClass())) {
        method.invoke(generator, propertyValue);
    

    This also looks like the right thing to do anyway.

  • Add WadlGeneratorResourceDocSupport.setResourceDocArray(byte[]) so that resource contents can be passed directly (this is not relevant if the previous fix is implemented).

p.s. looks like a possible NPE in

if (loader == null) {
    loader = WadlGeneratorLoader.class.getClassLoader();
}
final InputStream is = loader.getResourceAsStream(resource);

because .getClassLoader() can return null.

Comment by Jakub Podlesak [ 27/Sep/12 ]

Do you have a reproducible test case handy that you could attach to this report? That would help us a lot to speed up fixing this. Thanks for understanding!

Comment by Mikhail Mazursky [ 06/Oct/12 ]

You may take a look at this sample [1]. It reproduces the problem, but i failed to make it work for non-extended WADL too. It have some weird OSGi-related problem that my original setup do not have. You can launch it using the provided instructions on the page. It seems that due to some Jetty-related issue you have to stop/start the application from the console using:
stop com.ash2k.example.osgi-wadl
start com.ash2k.example.osgi-wadl

Hope that helps.

[1]: https://github.com/ash2k/osgi-jetty-playground

Comment by Jakub Podlesak [ 15/Oct/12 ]

Thanks! I am now able to reproduce.

Comment by Jakub Podlesak [ 24/Oct/12 ]

Going to relax the parameter check as suggested above so that you can pass an InputStream in.
Please keep in mind that in OSGi environment, you would need to get the input stream via OSGi API, e.g. like follows:

InputStream resourceStream = FrameworkUtil.getBundle(this.getClass()).getEntry(RESOURCEDOC_FILE).openStream();

If there is demand we might want to wire better OSGi support directly into the Jersey WADL codebase,
but that would not be doable in 1.15 timeframe.

Comment by Jakub Podlesak [ 24/Oct/12 ]

Fixed in the main trunk:

Sending changes.txt
Sending jersey-server/src/main/java/com/sun/jersey/api/wadl/config/WadlGeneratorLoader.java
Transmitting file data ..
Committed revision 5797.

Comment by Jakub Podlesak [ 09/Nov/12 ]

Re-opening to be able to implement a better fix. It should not be required to pass an input stream in.

Comment by Jakub Podlesak [ 12/Nov/12 ]

Jersey 1 codebase left intact, but applied a fix to Jersey 2 codebase, where you should not need to provide an input stream directly,
if required resource files are located in the very same bundle as the WadlGeneratorConfigurator class itself.
Added a test case to the extended wadl webapp example.





[JERSEY-1405] Analyze and improve performance- jersey on grizzly (server side) Created: 04/Sep/12  Updated: 10/Sep/15  Resolved: 15/Nov/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: Task Priority: Blocker
Reporter: Pavel Bucek Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 day, 19 hours
Original Estimate: 1 day, 6 hours


 Comments   
Comment by Jakub Podlesak [ 15/Nov/12 ]

Established performance test infrastructure to continuously
measure 38 performance indicators.

Suggested an improvement to the TopLink team, that helped to speed up MOXy JSON processing. It is 4-6 times faster now (based on actual numbers).

Identified another room for improvement in sub resource locator processing.





[JERSEY-1385] Add support for JAX-RS StringConverters. Created: 21/Aug/12  Updated: 10/Sep/15  Resolved: 22/Oct/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: Task Priority: Blocker
Reporter: Marek Potociar Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 day, 3 hours
Original Estimate: 12 hours

Issue Links:
Dependency
depends on JAX_RS_SPEC-61 Improved marshalling for string-based... Resolved




[JERSEY-1351] Update client-side Configuration.register(...) method impls to match the new apidocs. Created: 08/Aug/12  Updated: 10/Sep/15  Resolved: 01/Nov/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: Task Priority: Blocker
Reporter: Marek Potociar Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 12 hours
Original Estimate: 12 hours

Issue Links:
Related
is related to JERSEY-1325 Implement support for the newly intro... Closed




[JERSEY-1330] Run JsonMoxyTest and XmlMoxyTest with MOXy 2.4.1 Created: 02/Aug/12  Updated: 10/Sep/15  Resolved: 22/Oct/12

Status: Closed
Project: jersey
Component/s: media
Affects Version/s: 2.0-m05, 2.0-m10, 2.0
Fix Version/s: 2.0-m10, 2.0

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


 Description   

Find out which of the (incl. @Ignored) test cases, present in mentioned classes, are still failing and communicate this with the MOXy team (to work on fixes).






[JERSEY-1325] Implement support for the newly introduced common configuration API. Created: 01/Aug/12  Updated: 10/Sep/15  Resolved: 01/Nov/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: Task Priority: Blocker
Reporter: Marek Potociar Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 day, 13 hours
Original Estimate: 18 hours

Issue Links:
Related
is related to JERSEY-1351 Update client-side Configuration.regi... Closed




[JERSEY-1309] Pass all the existing TCK tests (including the new ones). Created: 25/Jul/12  Updated: 10/Sep/15  Resolved: 15/Oct/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: Task Priority: Blocker
Reporter: Martin Matula Assignee: Pavel Bucek
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Pavel Bucek [ 15/Oct/12 ]

we have separate individual issues (marked as blocker)





[JERSEY-1222] Investigate if there is a need to re-add core-common/src/main/java/org/glassfish/jersey/message/internal/MimeMultipartProvider.java Created: 15/Jun/12  Updated: 10/Sep/15  Resolved: 15/Oct/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m07
Fix Version/s: 2.0-m10

Type: Task Priority: Blocker
Reporter: Jakub Podlesak Assignee: Pavel Bucek
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

To get rid of javax.mail dependency the above mentioned provider and related tests were removed from the Jersey code base.
We should investigate if we want to re-add this provider, and if so, how to do it (which module should it belong to...)



 Comments   
Comment by Jakub Podlesak [ 15/Jun/12 ]

removal review request number: 215

and here is the commit:

commit e57a4c32bdd4ffdfbbdb7e2abad029f887bc5d11
Author: Jakub Podlesak <jakub.podlesak@oracle.com>
Date: Fri Jun 15 12:38:59 2012 +0200

got rid of javax.mail dependency, required for GF integration

Change-Id: Iddc47b2fbeff25bfdb264bb64bbdfe5c770ee203

Comment by Martin Matula [ 12/Oct/12 ]

we should finally deal with this task - increasing priority





[JERSEY-1209] SyncInvoker#<anymethod_with_argument_class> throws NullPointer exception with given Class==null, another exception might be better Created: 13/Jun/12  Updated: 10/Sep/15  Resolved: 07/Nov/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m05
Fix Version/s: 2.0-m10

Type: Improvement Priority: Blocker
Reporter: jan.supol Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 hours
Original Estimate: 3 hours


 Description   

SyncInvoker interface implementation (Invocation.Builder) implementation in jersey throws null pointer exception
example:

Client client = ClientFactory.newClient();
Target target = client.target(getUrl());
SyncInvoker sync = target.request();
Class<Response> clazz = null;
sync.delete(clazz);

throws

13.6.2012 14:20:55 org.glassfish.jersey.process.internal.ResponseProcessor notifyCallback
WARNING: Invocation of a result method on a request execution callback has failed.
java.lang.NullPointerException
at org.glassfish.jersey.message.internal.MutableEntity.extractType(MutableEntity.java:508)
at org.glassfish.jersey.message.internal.MutableEntity.content(MutableEntity.java:302)
at org.glassfish.jersey.message.internal.AbstractMutableMessage.content(AbstractMutableMessage.java:174)
at org.glassfish.jersey.message.internal.JaxrsResponseView.readEntity(JaxrsResponseView.java:101)
at org.glassfish.jersey.client.JerseyInvocation$2.completed(JerseyInvocation.java:609)
at org.glassfish.jersey.client.JerseyInvocation$2.completed(JerseyInvocation.java:599)
at org.glassfish.jersey.client.JerseyClient$1$1.result(JerseyClient.java:285)
at org.glassfish.jersey.process.internal.ResponseProcessor.notifyCallback(ResponseProcessor.java:298)
at org.glassfish.jersey.process.internal.ResponseProcessor.setResult(ResponseProcessor.java:288)
at org.glassfish.jersey.process.internal.ResponseProcessor.access$700(ResponseProcessor.java:86)
at org.glassfish.jersey.process.internal.ResponseProcessor$1.run(ResponseProcessor.java:241)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:237)
at org.glassfish.jersey.process.internal.ResponseProcessor.run(ResponseProcessor.java:185)
at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:253)
at com.google.common.util.concurrent.ExecutionList$RunnableExecutorPair.execute(ExecutionList.java:149)
at com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:105)
at com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:155)
at org.glassfish.jersey.process.internal.RequestInvoker$2.run(RequestInvoker.java:213)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:237)
at org.glassfish.jersey.process.internal.RequestInvoker$3.run(RequestInvoker.java:223)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:253)
at com.google.common.util.concurrent.AbstractListeningExecutorService.submit(AbstractListeningExecutorService.java:44)
at com.google.common.util.concurrent.AbstractListeningExecutorService.submit(AbstractListeningExecutorService.java:41)
at org.glassfish.jersey.process.internal.RequestInvoker.apply(RequestInvoker.java:219)
at org.glassfish.jersey.client.JerseyClient$1.call(JerseyClient.java:281)
at org.glassfish.jersey.client.JerseyClient$1.call(JerseyClient.java:256)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:364)
at org.glassfish.jersey.client.JerseyClient.submit(JerseyClient.java:255)
at org.glassfish.jersey.client.JerseyInvocation.submit(JerseyInvocation.java:599)
at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:554)
at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:325)
at org.glassfish.jersey.client.JerseyInvocation$Builder.delete(JerseyInvocation.java:273)
at com.sun.ts.tests.jaxrs.spec.client.syncinvoker.JAXRSClient$2.run(JAXRSClient.java:119)
at com.sun.ts.tests.jaxrs.spec.client.syncinvoker.JAXRSClient.checkInvocationException(JAXRSClient.java:1213)
at com.sun.ts.tests.jaxrs.spec.client.syncinvoker.JAXRSClient.deleteWithNullClassTest(JAXRSClient.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ts.lib.harness.EETest.run(EETest.java:495)
at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:113)
at com.sun.ts.tests.common.vehicle.EmptyVehicleRunner.run(EmptyVehicleRunner.java:30)
at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:102)
at com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:392)
at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:210)
at com.sun.ts.lib.harness.EETest.run(EETest.java:204)
at com.sun.ts.tests.common.vehicle.VehicleClient.main(VehicleClient.java:27)

IllegalArgumentException or declared InvocationException would be more helpful



 Comments   
Comment by Pavel Bucek [ 15/Oct/12 ]

we should be checking NPE for the return java type before the request is sent





[JERSEY-1138] Add support for injectable Errors (like in Jersey 1.x) Created: 10/May/12  Updated: 10/Sep/15  Resolved: 15/Oct/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m10, 2.0

Type: New Feature Priority: Critical
Reporter: Marek Potociar Assignee: Marek Potociar
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JERSEY-1491 Add Errors utility (similar to the on... Closed

 Description   

Validation should be converted to leverage the new feature as part of the task. This will allow to get rid of the manual issue list creation and passing to the resource building and validation API.






[JERSEY-517] Replace Jersey's dependency injection (DI) code with an @Inject-based framework Created: 23/Apr/10  Updated: 10/Sep/15  Resolved: 19/Nov/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 1.1.5
Fix Version/s: 2.0-m10, 2.0

Type: New Feature Priority: Major
Reporter: mmc41 Assignee: Unassigned
Resolution: Fixed Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 517

 Description   

As discussed on the mailing list thread "Appeal to jersey developers for
better+reliable javax.inject/cdi/weld support", jersey's own legacy dependency
manager is becomming a big problem. Jersey's own dependency injector was
originally a good feature but now is highly problematic.

What changed the situation? Well now we have javax.inject and CDI in the Java 6
standard + many good implementations in spring, weld, guice etc. Developers
using new Java 6 SE/EE technology is or will be using other dependency injection
managers and it is a PAIN to get it to interoperate with jersey.

The situation now is that we have a "feature" that is hard to maintain and a
stone around the neck for java users that use JEE6 or guice/spring/weld/etc.
Normally, I do not recommend removing features but for a feature that subtracts
value for everybody and is costly to maintain I would say get rid of it as soon
as possible.

Hence, It would be much better if Jersey's own legacy dependency manager would
be completely removed and for Jersey just to ride on top of any standard
javax.inject and/or CDI implementation. This would give great benefits for both
users of jersey and jersey developers.

As for compatibility, the biggest problem with java is the unwillingness to
cleanup things because of a 100% mindset on "backwards compatibility" that
overcomplicates Java. If users want the old api then they should not upgrade
their jersey libs. However, if you insist on some compatibility you could for
example introduce a annotation processor that would convert existing source code
at runtime to use standard annotations ? But maybe a clean cut would be much
better for everybody ?



 Comments   
Comment by sandoz [ 23/Apr/10 ]

Jersey's DI code implements the JAX-RS 1.1 programming model.

But still i would like to rip it out and replace it with an @Inject framework
(and also use that framework internally within the Jersey implementation).

However, it may still require some Jersey-specific support for the cases where
the @Inject framework limits the JAX-RS 1.1 programming model.

This is a big issue that if implemented will result in a major re-write of
certain areas, introduce new dependencies, and potentially affect existing
Jersey developers who use a chosen DI framework with Jersey.

I would like see such work happen in conjunction with any JAX-RS 2.0 effort.

Comment by mmc41 [ 23/Apr/10 ]

You write that this "will result in a major re-write of certain areas". That
sounds costly?

Is it not more accurate to say that the change "will result in a major code
deletion/cleaning + small relatively small new additions to support pluggable
dependency injection managers".

I would guess that on the long run, that besides being of great benefit to
users, this would save the jersey project man hours since you would not have to
maintain a lot of legacy code.

Comment by sandoz [ 23/Apr/10 ]

It is costly however you categorize it, which is why it might be best to
associate this with any JAX-RS 2.0 development work. Not sure yet...

It should result in a fair bit of deletion but then dependencies on deleted code
need to change too. Jersey also uses it's DI mechanism internally in some cases.

I agree on the good benefits you mention. This has been on my mind for a while

Comment by Jakub Podlesak [ 22/Sep/11 ]

Changing priority. This new feature will be implemented in Jersey 2.

Comment by Pavel Bucek [ 19/Nov/12 ]

Jersey 2 uses hk2 for DI.





Generated at Mon Jul 25 10:23:18 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.