[JERSEY-1627] Localization of error messages in Glassfish does not work properly. Created: 17/Dec/12  Updated: 10/Sep/15  Resolved: 26/Feb/13

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

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

Issue Links:
Duplicate
is duplicated by JERSEY-1639 Meaningful error messages are not sho... Closed
is duplicated by JERSEY-1643 Misleading localization message logge... Closed

 Comments   
Comment by Jakub Podlesak [ 26/Feb/13 ]

This was already hot-fixed in m11, Pavel is going to create a follow-up issue.

Comment by Jakub Podlesak [ 26/Feb/13 ]

re-opening to fix remaining estimate...





[JERSEY-1620] Allow Features to register new HK2 Binders. Created: 13/Dec/12  Updated: 10/Sep/15  Resolved: 14/Dec/12

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

Type: New Feature Priority: Blocker
Reporter: Marek Potociar Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 hours
Original Estimate: 3 hours





[JERSEY-1619] Client.register(Class) registers Feature when configure() == false Created: 13/Dec/12  Updated: 10/Sep/15  Resolved: 13/Dec/12

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

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Marek Potociar
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
final Feature feature = new Feature() {
	@Override
	public boolean configure(FeatureContext context) {
		// false returning feature is not to be registered
		return false;
	}
};
Client client = ClientConfig.newClient();
client.register(feature.getClass());
client.getConfiguration().isRegistered(feature.getClass()) == true


 Comments   
Comment by Marek Potociar [ 13/Dec/12 ]

This issue is invalid.

The feature class is registered, but is not ever going to be enabled (i.e. if you checked at runtime - e.g. from a ClientRequestFilter), the configuration.isEnabled(Feature.class) would still return false.





[JERSEY-1615] standard JAXBElementProvider does not work for appropriate mediaType Created: 11/Dec/12  Updated: 10/Sep/15  Resolved: 17/Dec/12

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

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


 Description   

Spec., section 4.2.4 Standard Entity Providers, says:

javax.xml.bind.JAXBElement and application-supplied JAXB classes XML media types (text/xml, application/xml and application/*+xml).

But for application/atom+xml:

"POST /web/resource/jaxb HTTP/1.1[\r][\n]"
"Content-Type: application/atom+xml[\r][\n]"
"Accept: application/atom+xml[\r][\n]"
"Content-Length: 15[\r][\n]"
"User-Agent: Jakarta Commons-HttpClient/3.1[\r][\n]"
"Host: localhost:6080[\r][\n]"
"[\r][\n]"

the following response is given:

"<tag>jaxb</tag>"
"HTTP/1.1 415 Unsupported Media Type[\r][\n]"
"HTTP/1.1 415 Unsupported Media Type[\r][\n]"
"Server: Apache-Coyote/1.1[\r][\n]"
"Content-Type: text/html;charset=utf-8[\r][\n]"
"Content-Length: 1117[\r][\n]"
"Date: Tue, 11 Dec 2012 17:40:53 GMT[\r][\n]"
"[\r][\n]"

on resource:

@Path("resource")
public class Resource {
@Context HttpHeaders headers;
	@Path("jaxb")	
	@POST
	public Response jaxb(JAXBElement<String> jaxb) {
		MediaType media = headers.getMediaType();
		return Response.ok(jaxb).type(media).build();
	}	
}


 Comments   
Comment by jan.supol [ 12/Dec/12 ]

Duplicates 1501





[JERSEY-1606] Hudson maintenance: upgrade to 2.2.1 Created: 04/Dec/12  Updated: 10/Sep/15  Resolved: 04/Dec/12

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

Type: Task 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   

GF integration jobs require Hudson plugins that are only available for the latest hudson.
We need to upgrade to hudson 2.2.1 and also update/install some additional hudson plugins.






[JERSEY-1602] Configuration.register does not register Feature Created: 22/Nov/12  Updated: 10/Sep/15  Resolved: 13/Dec/12

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

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Michal Gajdos
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Client client = ClientFactory.newClient();
final Configuration fullConfig = client.configuration();		
fullConfig.register(new Feature() {
	@Override
	public boolean configure(Configurable arg0) {
		return true;
	}
});
System.out.println(fullConfig.getFeatures().size()); //prints 0


 Comments   
Comment by Michal Gajdos [ 26/Nov/12 ]

This behaviour is correct according to the javadoc:

The returned set contains the features that have already been successfully
{@link Feature#configure(Configurable) configured} in this configuration context.

Note: Feature}}s are not immediately configured when they are passed to the {{Configuration so Configuration#getFeatures() cannot return anything else than an empty set.

Configuration/Configurable functionality has been refactored A LOT in the latest milestones/snapshots of the spec, see:

http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/core/Configuration.html
http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/client/Configurable.html





[JERSEY-1601] Avoid using String type to store password when using HTTPBasicAuthFilter Created: 22/Nov/12  Updated: 10/Sep/15  Resolved: 27/Nov/12

Status: Closed
Project: jersey
Component/s: security
Affects Version/s: 1.15
Fix Version/s: 2.0-m11, 2.0

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


 Description   

It is fine to keep the API using String type (current filter constructor), but there should be also another way/constructor so that user code can avoid using String completely to handle password data.
We also need to ensure String type is not used internally for password data.



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

Fixed in both Jersey 1 and Jersey 2 workspace.





[JERSEY-1600] SSE failed on WLS for case when integrated with Nucleus Created: 21/Nov/12  Updated: 10/Sep/15  Resolved: 22/Nov/12

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

Type: Bug Priority: Blocker
Reporter: martin.mares Assignee: Marek Potociar
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: wls

 Description   

We have GF Nucleus integrated in WLS. It use jersey and SSE. When SSE implementation try to suspend servlet.
Sorry for short description but we are in touch.

java.lang.IllegalStateException: The async-support is disabled on this request: weblogic.servlet.internal.ServletRequestImpl@7246688[
POST /command/progress-custom HTTP/1.1
Accept: text/event-stream
X-If-Command-Model-Match: upvq8Ay69hGqQsnCVWYvPQ==
X-Indent: true
Content-Type: application/x-www-form-urlencoded
Content-Language: 
Content-Encoding: 
X-Requested-By: CLI
Authorization: *
User-Agent: Jersey/2.0-m09 (HttpUrlConnection 1.7.0_09)
Connection: keep-alive
Content-Length: 11

]
	at weblogic.servlet.internal.ServletRequestImpl.startAsync(ServletRequestImpl.java:1855)
	at weblogic.servlet.internal.ServletRequestImpl.startAsync(ServletRequestImpl.java:1842)
	at org.glassfish.jersey.servlet.async.AsyncContextDelegateProviderImpl$ExtensionImpl.suspend(AsyncContextDelegateProviderImpl.java:85)
	at org.glassfish.jersey.servlet.internal.ResponseWriter.suspend(ResponseWriter.java:97)
	at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:448)
	at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:284)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:201)
	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:761)
	at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:309)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:349)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:312)
	at com.oracle.glassfish.wlsintegration.admin.restadapter.impl.RestAdminServletContainer.service(RestAdminServletContainer.java:78)
	at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:189)
	at com.oracle.glassfish.wlsintegration.admin.restadapter.impl.AbstractServletRestAdapter.service(AbstractServletRestAdapter.java:89)
	at com.oracle.glassfish.wlsintegration.admin.restadapter.web.RestAdapterServlet.invokeRestAdapter(RestAdapterServlet.java:96)
	at com.oracle.glassfish.wlsintegration.admin.restadapter.web.RestAdapterServlet.processRequest(RestAdapterServlet.java:68)
	at com.oracle.glassfish.wlsintegration.admin.restadapter.web.RestAdapterServlet.service(RestAdapterServlet.java:109)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:844)
	at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:279)
	at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:253)
	at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:135)
	at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:340)
	at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:25)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:78)
	at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:137)
	at java.security.AccessController.doPrivileged(Native Method)
	at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:315)
	at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:460)
	at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:120)
	at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:217)
	at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:81)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:78)
	at oracle.dms.servlet.DMSServletFilter.doFilter(DMSServletFilter.java:225)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:78)
	at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3323)
	at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3289)
	at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
	at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
	at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
	at weblogic.servlet.internal.WebAppServletContext.doSecuredExecute(WebAppServletContext.java:2176)
	at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2102)
	at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2080)
	at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1537)
	at weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run(ContainerSupportProviderImpl.java:254)
	at weblogic.work.ExecuteThread.execute(ExecuteThread.java:295)
	at weblogic.work.ExecuteThread.run(ExecuteThread.java:254)


 Comments   
Comment by martin.mares [ 21/Nov/12 ]

You can see com/oracle/glassfish/wlsintegration/admin/restadapter/web/RestAdapterServlet on stack trace
This servlet has followed annotation:

@WebServlet(name = "RestAdapterServlet", urlPatterns = {"/*"}, asyncSupported=true)

So, this is strange that suspend does not work. And it can be problem on WLS. I will add more people to find out solution.

Comment by Marek Potociar [ 22/Nov/12 ]

This seems to be a problem in WLS that is prepending a non-async Servlet filter in front of each application Servlet instance. That effectively prevents Servlet async support from working. This needs to be addressed in WLS.





[JERSEY-1598] ProvidersOrderingTest failing after some change. Created: 20/Nov/12  Updated: 10/Sep/15  Resolved: 11/Dec/12

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

Type: Bug Priority: Major
Reporter: Pavel Bucek Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour
Original Estimate: Not Specified


 Description   

when you change

    public static final class MyByteArrayProvider extends AbstractMessageReaderWriterProvider<byte[]>

to

    public static final class MyByteArrayProvider extends AbstractMessageReaderWriterProvider<byte[]>
    implements MessageBodyReader<byte[]>, MessageBodyWriter<byte[]>

test will fail. Possible issue is in type discovery, looks like latter case is discovered as MessageBodyReader/Writer<Object> instead of <byte[]>






[JERSEY-1587] Investigate building issues on JDK 7u9 Created: 19/Nov/12  Updated: 10/Sep/15  Resolved: 22/Nov/12

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

Type: Task Priority: Blocker
Reporter: Pavel Bucek Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours, 1 minute
Original Estimate: 3 hours





[JERSEY-1586] Integrate Jersey 2.0-m10 into GF Created: 19/Nov/12  Updated: 11/Dec/12  Resolved: 11/Dec/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m11, 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, 5 hours
Original Estimate: 3 hours


 Comments   
Comment by Miroslav Fuksa [ 11/Dec/12 ]

integration finished (Jakub fixed a bug in Jersey).





[JERSEY-1585] Release Jersey 2.0-m10 Created: 19/Nov/12  Updated: 10/Sep/15  Resolved: 22/Nov/12

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

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


 Comments   
Comment by Miroslav Fuksa [ 22/Nov/12 ]

released





Support Bean Validation (JERSEY-1029)

[JERSEY-1583] Integration of Bean Validation into Jersey 2.x- resource POJO validation- pre-method invocation validation- response validation Created: 19/Nov/12  Updated: 10/Sep/15  Resolved: 14/Dec/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m11, 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: 1 day, 11 hours
Original Estimate: 1 day, 6 hours


 Comments   
Comment by Michal Gajdos [ 14/Dec/12 ]
  • merged into trunk




Support Bean Validation (JERSEY-1029)

[JERSEY-1582] Get familiar with BeanValidation Created: 19/Nov/12  Updated: 10/Sep/15  Resolved: 05/Dec/12

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

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





[JERSEY-1570] Resoure.from(Object resource, List<ResourceModelIssue> issueList) does not create Resource based on instance (Object resource) Created: 09/Nov/12  Updated: 10/Sep/15  Resolved: 11/Dec/12

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

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


 Description   

This code does not store instance but only uses the class of the instance (the instance is ignored):

    public static Resource from(Object resource, List<ResourceModelIssue> issueList) {
        final Builder builder = new IntrospectionModeller(resource.getClass(), issueList).createResourceBuilder(true);
        return builder.isEmpty() ? null : builder.build();
    }

MethodHadnler is then class based and not instance based.

The instance should be kept and used for request dispatching.



 Comments   
Comment by Miroslav Fuksa [ 11/Dec/12 ]

Finally agreed with Marek that the current functionality works as desired. We do not want to create Resources which have instance based Method Handler. Preferable way it to create class based resources and register instance as a singleton.

So, current methods (Resource.from(Object) and Resource.builder(Object)) are really intended to create class based method handlers.





[JERSEY-1569] Refactor resource model - extract sub resource method from Resources Created: 09/Nov/12  Updated: 11/Dec/12  Resolved: 11/Dec/12

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

Type: Bug Priority: Critical
Reporter: Miroslav Fuksa Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 days, 12 hours
Original Estimate: 12 hours

Issue Links:
Dependency
blocks JERSEY-1479 Refactor WADL support to provide the ... Closed

 Description   

Currently these resource classes will create 2 internal model Resources (= org.glassfish.jersey.server.model.Resource):

    @Path("path")
    public static class ResourceClass {
        @GET
        public String get() {
            return "get";
        }

        @POST
        public String post(String post) {
            return post;
        }

        @Path("second")
        @GET
        public String getSecond() {
            return "subresource method"; // ! NON UNIQUE RESOURCE METHOD
        }

    }

    @Path("path/second")
    public static class ResourceSecondClass {
        @GET
        public String get() {
            return "resource"; // ! NON UNIQUE RESOURCE METHOD
        }

        @POST
        public String post(String post) {
            return post;
        }
    }

Resource 1: "path"

  • resource method: GET: get()
  • resource method: POST: post(String post)
  • sub resource method "second": GET: getSecond() ----> "/path/second" --> NON UNIQUE

Resource 2: "path/second"

  • resource method : GET: get() -------> "/path/second" --> NON UNIQUE
  • resource method : POST: post(String post)

First problem is that the validation does not say anything about not unique resource. This is a bug.

The second problem is that such a model is confusing and makes processing like validation, wadl generation more difficult. It would be better to represent ResourceClass.getSecond() SUB RESOURCE method in Resource model as RESOURCE method in ResourceSecond class (with empty path).

We agreed to change the model generation as following:

  • There will be no SUB resource methods in Resource model class. They will be placed into appropriate resources, so that result path is the same but the method path is empty (they are just resource methods and not subresource).
  • Resource will contain either (XOR):
    • one or more Resource Methods
    • or one Sub Resource Locator
      it should never contain both above options.

Note: currently it is also possible to have resource methods and subresource locators (with empty path) which is not corresponding to the spec. For example this should not be possible and validation error should be reported:

    // this is wrong, resource cannot have both, resource methods and subResourceLocators !
    @Path("aaa")
    public static class AaaResource {
        @GET
        public String get() {
            return "aaa"; 
        }

        
        public Object subResourceLocator(String post) {           
            return ...
        }
    }

This should also be fixed.






[JERSEY-1559] Migrate Jersey to the latest JAX-RS API. Created: 05/Nov/12  Updated: 10/Sep/15  Resolved: 11/Dec/12

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

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





[JERSEY-1558] Support HK2 Binder registration via JAX-RS Configuration/Configurable register methods. Created: 05/Nov/12  Updated: 10/Sep/15  Resolved: 13/Dec/12

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

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


 Description   

The idea is to remove addBinder(...) methods and instead use directly register(...) methods as with any other provider.






[JERSEY-1543] Ignore MBW.getSize(). Created: 30/Oct/12  Updated: 10/Sep/15  Resolved: 13/Dec/12

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

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

Issue Links:
Related
is related to JAX_RS_SPEC-277 Deprecate the MessageBodyWriter.getSi... Resolved
is related to JERSEY-1617 Support outbound entity buffering to ... Closed
is related to JERSEY-1584 Add server-side support for response ... Closed

 Description   

See JAX_RS_SPEC-277.

Just a thought - perhaps it would make sense to provide a compatibility switch?






[JERSEY-1517] Make ChunkedInput and ChunkedOutput commonly supported on both, client and server. Created: 19/Oct/12  Updated: 10/Sep/15  Resolved: 14/Dec/12

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

Type: Task Priority: Major
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-1591 Get rid of core-server dependency in ... Closed

 Description   

Currently we support ChunkedOutput only on the server side and ChunkedInput only on the client side. We should be able to support chunked I/O uniformly (read+write) on both, client and server.






[JERSEY-1514] Revisit ChunkedInput/ChunkParser Created: 18/Oct/12  Updated: 10/Sep/15  Resolved: 14/Dec/12

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

Type: Task Priority: Blocker
Reporter: Martin Matula Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JERSEY-1591 Get rid of core-server dependency in ... Closed




[JERSEY-1263] @ErrorParam (or similar) parameter annotation for type conversion issues Created: 29/Jun/12  Updated: 10/Sep/15  Resolved: 14/Dec/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: 1.13, 2.0-m05
Fix Version/s: 2.0-m11, 2.0

Type: New Feature Priority: Major
Reporter: Martin Matula Assignee: Marek Potociar
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently if I have a resource method that uses @PathParam/QueryParam or some other param annotation to inject param value, and the param value cannot be converted to the variable type (e.g. I declare my param as "@QueryParam("abc") int count" and somebody passes in "a" which can't be converted to int), jersey returns 404. This significantly reduces the usability of parameter injection for production use. I propose we add @ErrorParam annotation (or similar) to allow users to gracefully handle this type of errors. This annotation, if present, would cause that parameters with mismatching type to be injected with default values and @ErrorParam annotated parameter (would always have to be of type MultivaluedMap<String, String>) will be populated with paramname-value pair in error. So one could write resource methods that look like this:

@GET
public String get(@QueryParam("count") int count, @ErrorParam Map<String, String> errors) {
    if (!errors.isEmpty()) {
        throw new WebApplicationException(...whatever response you want to generate...);
    }
    ... do whatever you want to do if parameters are fine ...
}


 Comments   
Comment by George Sapountzis [ 07/Aug/12 ]

In the text you suggest to use MultivaluedMap<String, String>, while in the code you use Map<String, String>.

Misc ideas for discussion:

Use Map<String, RuntimeException> for the errors. The exception message is the default error message and JAX-RS providers can provide sub-exceptions with more specific error information.

An alternative approach is to use the functional type Either:

/**
 * Parameter binding result: Either[Cause, Value]
 */
public class SamsonParam<T> {

    private final boolean error;
    private final RuntimeException cause;
    private final T value;

    private SamsonParam(boolean error, RuntimeException cause, T value) {
        this.error = error;
        this.cause = cause;
        this.value = value;
    }

    public static <T> SamsonParam<T> fromError(RuntimeException cause) {
        return new SamsonParam<T>(true, cause, null);
    }

    public static <T> SamsonParam<T> fromValue(T value) {
        return new SamsonParam<T>(false, null, value);
    }

    public boolean isError() {
        return error;
    }

    public RuntimeException getCause() {
        return cause;
    }

    public T getValue() {
        return value;
    }

}

and the resource would be:

@GET
public String get(@QueryParam("count") SamsonParam<Integer> countParam) {
    if (countParam.isError()) {
        throw new WebApplicationException(...whatever response you want to generate...);
    }

    Integer count = countParam.getValue();

    ... do whatever you want to do if parameters are fine ...

}

The problem with the above is that it does not play well with bean/method validation. It requires extending for custom composite types and defining rules for annotation application "across" the custom type, see https://hibernate.onjira.com/browse/HV-565 .

Comment by Marek Potociar [ 14/Dec/12 ]

This feature should be covered by the introduced support for Bean Validation. The validation errors result in a ValidationException being thrown. A custom validation exception mapper can be plugged in to process the validation issues.





[JERSEY-1139] Support for extensions in the resource model. Created: 10/May/12  Updated: 14/Dec/12  Resolved: 14/Dec/12

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

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


 Description   

TODO: Define more specifically what the feature is about.






[JERSEY-1124] ServiceFinder not returning services in META-INF/services Created: 27/Apr/12  Updated: 10/Sep/15  Resolved: 17/Dec/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 1.9.1, 2.0
Fix Version/s: 2.0-m11, 2.0

Type: Bug Priority: Critical
Reporter: charlesk40 Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 6 hours
Original Estimate: Not Specified

Tags: 1_13-blocker

 Description   

Shouldn't the servicesUrls return when we have services defined in META-INF/services even if we have BUNDLE_VERSION defined?

http://java.net/projects/jersey/sources/svn/content/trunk/jersey/jersey-core/src/main/java/com/sun/jersey/spi/service/ServiceFinder.java?rev=5697

private static Enumeration<URL> filterServiceURLsWithVersion(String serviceName, Enumeration<URL> serviceUrls) {
0217. if (BUNDLE_VERSION == null || !serviceUrls.hasMoreElements())
0218. return serviceUrls;



 Comments   
Comment by Martin Matula [ 02/May/12 ]

This was intentional due to various versioning issues we have been facing in GlassFish which has a particular version of Jersey on system classpath. But it created a lot of other issues. So we are most likely going to remove this restriction in the next update. Assigning to Michal.

Comment by charlesk40 [ 02/May/12 ]

Can some one explain in more detail what will be removed or changed?
Thank you.

Comment by Michal Gajdos [ 22/May/12 ]

We are considering to remove the constraint that enforces you to use the same version of Jersey additions (e.g. jersey-oauth, jersey-atom, ..) as the jersey-core (ServiceFinder) has. This constraint is influencing services registered via META-INF/services mechanism (e.g. in GlassFish it's not possible to use jersey-oauth that has different version than Jersey libraries bundled in the GlassFish). Will be resolved in 1.13.

Comment by Pavel Bucek [ 24/May/12 ]

just short question:

do you have some usecase for which Jerseys ServiceFinder doesn't work correctly? "serviceUrls" can still be returned even if BUNDLE_VERSION is not null, checking mechanism is more complex than this single check. Its purpose is to deny loading JERSEY providers from different JERSEY versions, it should not affect you at all (unless you are repackaging Jersey). (BUNDLE_VERSION is taken from manifest of jar where jersey-core/ServiceFinder impl resides).

more details will be greatly appreciated / this is somehow sensitive and hard to test problem and change might cause regressions in lots of places/products.

Comment by charlesk40 [ 24/May/12 ]

We have a bundle that includes all the jersey jars as embeded dependencies.

So something like:
application.jar (bundle)
— jersey-core.jar
— jersey-x.jar
— META-INF/MANIFEST.MF (Contains the BUNDLE_VERSION OSGi header)
/services (Contains some providers we would like Jersey to pickup using the ServiceFinder)

Since we have the BUNDLE_VERSION defined, and because of the check that I have mentioned, providers don't get picked up.

Comment by Pavel Bucek [ 24/May/12 ]

have you gone any further in your debugging session? Can you tell us which condition you don't meet?

it will most likely be somewhere in ServiceFinder.compatibleManifest method.

Comment by sameerShah [ 25/May/12 ]

After debugging this issue further, the compatibleManifest method returns false

if(moduleVersion != null &&
                    (!moduleVersion.equals(MODULE_VERSION_VALUE)) ||
                        (symbolicName != null &&
                        (BUNDLE_SYMBOLIC_NAME.startsWith("com.sun.jersey") ^ symbolicName.startsWith("com.sun.jersey")))) {
                return false;
            }

The values for the variables are as follows:
modulleVersion = 1.4
BUNDLE_SYMBOLIC_NAME = com.sun.jersey.jersey-core
SymbolicName = com.abc.testBundle

Does this help?

Comment by Pavel Bucek [ 25/May/12 ]

yes, thanks! just one more info needed - MODULE_VERSION_VALUE.

most helpful thing would be striping down your project and send minimal reproducible case, but I understand it can be difficult..

Comment by Pavel Bucek [ 25/May/12 ]

aha! This might be already fixed. I've just tried to recreate your case and noticed one (significant) difference:

if(moduleVersion != null &&
        (!moduleVersion.equals(MODULE_VERSION_VALUE) ||
            (symbolicName != null &&
            (BUNDLE_SYMBOLIC_NAME.startsWith("com.sun.jersey") ^ symbolicName.startsWith("com.sun.jersey"))))) {
    return false;
}

(misplaced parenthesis)

Can you please try Jersey 1.13 and verify if your issue is still valid?

Comment by Pavel Bucek [ 31/May/12 ]

any update?

Comment by sameerShah [ 31/May/12 ]

I tried with 1.13 build but still no change.

moduleVersion : 1.13-b01
MODULE_VERSION_VALUE: 1.13-b01
BUNDLE_SYMBOLIC_NAME = com.sun.jersey.jersey-core
SymbolicName = com.abc.testBundle

The change in the parenthesis does not help. since the if condition still resolves to true and hence the compatibleManifest function returns false.

Comment by Michal Gajdos [ 25/Jun/12 ]

Fixed for 1.13.

Comment by Jakub Podlesak [ 22/Nov/12 ]

This should be fixed also in 2.0 Jersey version. Mira just bumped into an issue related to the check when integrating Jersey 2.0-m10 into GF.





[JERSEY-1029] Support Bean Validation Created: 18/Mar/12  Updated: 10/Sep/15  Resolved: 17/Dec/12

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

Type: New Feature Priority: Critical
Reporter: Martin Matula Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: 0 minutes Remaining Estimate: Not Specified
Σ Time Spent: 1 day, 17 hours Time Spent: Not Specified
Σ Original Estimate: 1 day, 12 hours Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
JERSEY-1582 Get familiar with BeanValidation Sub-task Closed Michal Gajdos  
JERSEY-1583 Integration of Bean Validation into J... Sub-task Closed Michal Gajdos  

 Description   

DEMO: create example demonstrating Bean Validation support in JAX-RS






Generated at Sun Jul 24 16:18:31 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.