[JAX_RS_SPEC-488] Pluggable implementations Created: 07/Oct/14  Updated: 31/Mar/15

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.1
Fix Version/s: None

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

Issue Links:
Relates
relates to JAX_RS_SPEC-110 Allow multiple JAX-RS implementations... Open

 Description   

Seems that containers are not able to switch JAX-RS implementations like JPA due to the specification limitations.

Related issue for the Wildfly container: https://github.com/javaee-samples/javaee7-samples/issues/93#issuecomment-58228004



 Comments   
Comment by arungupta [ 07/Oct/14 ]

It would be great to have a pluggable JAX-RS implementations, just like JPA. I see several requests for using Jersey in WildFly and vice versa.

Comment by r_uchoa [ 09/Feb/15 ]

I completely agree. A pluggable implementation would be great.

Comment by briehman [ 31/Mar/15 ]

This should definitely be included. We would like to be able to use Jersey but there is no way to remove resteasy from being loaded.





[JAX_RS_SPEC-512] Support for HTTP/2.0 and HPACK Created: 26/Mar/15  Updated: 26/Mar/15

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: mkarg Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: HPACK, HTTP/2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

EG Discussion


 Description   

HTTP/2.0 and HPACK claim to provide dramatic improvements particularly with complex multi-resource requests due to parallel multi-responses, binary data format, and header compression.

Servlet 4.0 already provides support for this, and in near future people will demand support for it in JAX-RS – independent of Servlet 4.0 or not. As a consequence, API and / or spec changes of JAX-RS might be needed to address the JAX-RS alignments to HTTP/2.0 and HPACK.






[JAX_RS_SPEC-511] Review if Enum.value() can be used to convert it to string if Enum fromValue() exists Created: 11/Mar/15  Updated: 11/Mar/15

Status: Open
Project: jax-rs-spec
Component/s: model api
Affects Version/s: None
Fix Version/s: 2.1

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Marek Potociar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

We have a user request, and I'm not certain if it is completely 'won't fix' or something can be done by default without having to depend on ParamConverter.

The issue seems to be is that JAXB generates fromValue and valueOf and the value() is apparently aligned with fromValue() while toString() (which is used by default for the conversion) is not.






[JAX_RS_SPEC-460] If Enum has fromValue method throwing the exception then consider allowing for checking valueOf too. Created: 01/May/14  Updated: 11/Mar/15

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 1.1, 2.0
Fix Version/s: 2.1

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Marek Potociar
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Consider this enum generated by JAXB from a schema:

public enum CarType {
    BMW("BMW"),
    AUDI("Audi") 
    //...
}

CarType fromValue will accept "BMW" and "Audi", valueOf - "BMW" and "AUDI". The spec requires fromValue(), if available, be checked first.

Consider updating the spec to mention that if the enum fromValue throws IllegalArgumentException (reliably indicating that the issue is that the fromValue implementation has found no match) then let it continue to valueOf(). This will let users not to worry about the the fact that either "BMW" or "AUDI" won't be converted.

The alternative option is to recommend using ParamConverterProvider but it appears the default conversion algorithm can be tuned a tiny bit to let users avoid registering custom providers.



 Comments   
Comment by jeroenvlek [ 06/May/14 ]

I've submitted this bug to the people of CXF. We encountered it in a project where we had uppercase enums with lowercase string values (analogue to the example above) generated by JAXB. The CXF implementation follows the spec and never reaches valueOf(), because fromValue() throws an exception, instead of returning null.

Cheers,
Jeroen Vlek

Comment by beryozkin_sergey [ 11/Mar/15 ]

The spec talks about fromString and valueOf. This JIRA is invalid if fromValue() is not be formally supported by the spec - but given that fromValue works differently from valueOf it makes sense IMHO to update the spec to check fromValue() if it is available.

Comment by beryozkin_sergey [ 11/Mar/15 ]

Though if course, ParamConverter can be a simpler solution to avoid dealing with various Enum conversion subtleties by default





[JAX_RS_SPEC-510] Incorrect code example for DynamicFeature Created: 22/Feb/15  Updated: 22/Feb/15

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.0
Fix Version/s: None

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

NA


Tags: specissue

 Description   

The code example for Section 6.5.3 Dynamic Binding has an incorrect method parameter declaration for the DynamicFeature interface.

... void configure(ResourceInfo resourceInfo, Configuration config) ....

It used the Configuration object as the second parameter which incorrect.

The right signature is

... void configure(ResourceInfo resourceInfo, FeatureContext ctx) ....
as per JAX-RS 2.0 javadocs [ http://bit.ly/1B2lvE4 ]






[JAX_RS_SPEC-502] Passing data from a filter to a resource Created: 17/Dec/14  Updated: 21/Feb/15

Status: Open
Project: jax-rs-spec
Component/s: filters&handlers
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Bug Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: filters
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: filters

 Description   

Currently there is no way to pass information from a filter to a
resource. It would be cool if there was a method on
ContainerRequestContext (or something) that could register a value that
could be injected via @Context. For example:

containerRequestContext.pushContext(IDToken.class, token);

@Path
public class Resource

{ @Context IDToken token; }

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

Actually, with Jersey it's possible to inject ContainerRequestContext via @Context, but this behavior doesn't seem to be specified in the JAX-RS specification.
Another possibility is to inject HttpServletRequest via @Context, which is specified in JAX-RS. But the downside of this is that it depends on running on a servlet container, and may thus not always work (for example, I couldn't get this to work with Jersey's test framework because the injected HttpServletRequest was null).

Either way, I think the proposal in the description is much cleaner than what's currently possible, so I agree this issue should be resolved as such.





[JAX_RS_SPEC-445] Add support for automatic handling of redirect status codes in JAX-RS client Created: 31/Jan/14  Updated: 21/Feb/15

Status: Open
Project: jax-rs-spec
Component/s: client
Affects Version/s: 2.0
Fix Version/s: 2.1

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

Issue Links:
Dependency
blocks MVC_SPEC-23 Support for HTTP redirect Open

 Description   

We should support handling of redirects automatically, esp. 301, 302, 307 and 308.

  • It should be possible to enable/disable the feature.
  • Automated client-side URI translation should be supported for 301 and 308


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

Will this support also include a way to retrieve the resolved request URI (as with Jersey's ClientResponse::getResolvedRequestUri method https://jersey.java.net/apidocs/2.15/jersey/org/glassfish/jersey/client/ClientResponse.html#getResolvedRequestUri%28%29), or should I file a separate issue for this?





[JAX_RS_SPEC-509] Typo in AsyncResponse Created: 21/Feb/15  Updated: 21/Feb/15

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

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


 Description   

In the javadoc of AsyncResponse http://docs.oracle.com/javaee/7/api/javax/ws/rs/container/AsyncResponse.html:

using the @Suspend annotation.
should be
using the @Suspended annotation.






[JAX_RS_SPEC-507] Introduce a DefaultMethod HTTP method annotation Created: 22/Jan/15  Updated: 16/Feb/15

Status: Open
Project: jax-rs-spec
Component/s: model api, spec
Affects Version/s: None
Fix Version/s: 2.1

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Santiago Pericas-Geertsen
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In some cases it can be useful to have any HTTP method supported by a given JAX-RS resource method.

For a resource method annotated with a DefaultMethod annotation it still has to satisfy all the resource selection algorithm requirements with the only minor exception that any HTTP method matches. Important: it is not meant to catch the requests which fail a path or media type matches.

Effectively, DefaultMethod is a HTTP Method analog of a wild-card support
now available for media types (example, @Consumes("/")) and Path("

{var:.*}

").

Examples:

@Path("/rest")
public class Resource {
   @DefaultMethod
   @Path("proxy")
   public void asyncProxy(@Suspended AsyncResponse ar, InputStream is);

   @DefaultMethod
   @Path("proxyGet")
   public Response getOrOption(@Suspended AsyncResponse ar);
}

and

@Path("{var:.*}")
public class Resource {
   @DefaultMethod
   public void all(@Suspended AsyncResponse ar, InputStream is);
}

Use cases:

  • simpler support for extension HTTP Methods; the current alternative is to ship a custom HttpMethod annotation extension which requires a bit more work and leads to the proliferation of multiple implementations with the same name (ex, PATCH, etc).
  • simpler support for implementing HTTP server proxies with JAX-RS (it is nearly impossible to do it now if it is to support all well known and any extension verbs)
  • minor optimizations in cases when multiple HTTP methods (ex, GET and OPTIONS) are available on the same PATH
  • support for other specific situations where a dynamic method-based dispatch is needed


 Comments   
Comment by beryozkin_sergey [ 22/Jan/15 ]

Implementation wise it is straightforward.

1. API

package javax.ws.rs;

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

/**
 * Indicates that the annotated method responds to any HTTP Method requests.
 *
 * @see HttpMethod
 * @since 2.1
 */
@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@HttpMethod("DefaultMethod")
@Documented
public @interface DefaultMethod {
}

2. The spec text, add a subsection 3.3.6 "Default Method" and say a resource method annotated with this annotation matches any HTTP method.
3. The spec text, resource selection, note that if multiple methods matching HTTP verb are found (ex, @Path("/a") @GET doGet() and @Path("/a") @DefaultMethod doAll() ) then a concrete method is preferred (@GET one in this case). I think this has to be the last check when comparing multiple matching resource candidates, which are otherwise completely identical as far as the final resource method selection is concerned.

Comment by mkarg [ 25/Jan/15 ]

While I would see a purpose in a general "catch-all" fallback method (which effectively replaces rejecting a non-routable request by default-routing it to a common "error" catching Java method), I in fact do not see a real-world use case for having an all-verbs matcher. I mean, can you give a real-world example where this is needed and couldn't be done by simply adding multiple @GET @HEAD annotations to the same Java method?

Comment by beryozkin_sergey [ 25/Jan/15 ]

The use cases text is straightforward. And I'm not keen to go into a 'real world case' discussion, this whole 'real world case' thing does not help.
Let me ask in turn, what is a real world case example for supporting just Consumes("/"). Doing JAX-RS in the first place ? Most well-known real world web sites are apparently not even written with JAX-RS...

Comment by mkarg [ 25/Jan/15 ]

A real-world use case would just make it easier for me to understand why the solution is needed. I just do not see it without. Regarding "Consumes" I don't understand what this has to do with your proposal. Also I don't see that well-known web sites are good candidates for JAX-RS, as JAX-RS is not for web sites but for web services. It seems we should really clarify whether we talk about REST or Servlet.NG.

Comment by beryozkin_sergey [ 25/Jan/15 ]

I think you just don't want to read the few lines of some use cases I thought of. I'm not interested to continue discussing things nothing do with simple improvement which you need a real word example for to convince you it might be needed. JAX-RS has many features which could not have been introduced if we followed your line of 'give me a real world example challenge': this is just arguing for the sake of the arguing. It is a simple improvement which may, if accepted, simply few things.
Why do we have HttpHeader.getMediaType if getHeaders is there ? Why do we have Consumes wildcard if we could just say Consumes (a, b, c, d, e, f), why do we just do any improvements at all and what the real world example for that. Nonsense

Comment by beryozkin_sergey [ 25/Jan/15 ]

Sorry for a rant. Basically, what I'd like to say is that IMHO the example with Consumes should give you the best answer.
It is a minor enhancement request, the optimization request, but also something which may help in other cases where having to list all the methods is awkward. I do not think we need to talk about real world examples in order to justify a possible acceptance of this minor request because every optimization can be avoided in principle but it does not necessarily justify the avoiding of the optimizations. I'm sorry it sounds like it is a critical issue for me - it is not.
Sergey

Comment by mkarg [ 26/Jan/15 ]

In fact I have read the proposal multiple lines and did not understand the actual benefit. That's the sole reason why I asked for a real-world example. If you don't like to provide one, that is ok for me, I just abstain from discussing your proposal then, as I cannot make up a sound opinion on the idea. About the existing convenience methods, I was not involved in the decision to add them, so I'm the wrong person to ask why those do exist. If you ask me, I don't need those either, but that is not the scope of the proposal. In fact I didn't want to make you angry, I just wanted to understand the benefit. Sorry if you felt I want to annoy you, it was not intended.

Comment by beryozkin_sergey [ 26/Jan/15 ]

Hi Markus, sorry for forgetting how to do a proper discussion yesterday, but it was Sunday after all . Let me do a short summary in another comment a bit later on.
Thanks for your input

Comment by beryozkin_sergey [ 16/Feb/15 ]

Sorry for a delay, just would like to complete the action and provide another summary. I'm now on the fence too regarding the resolution of this issue, up to other experts what to do with it. Either way, here is what I thought when I was creating this issue:

  • @DefaultMethod is as useful as @Path("var:.*") or a wildcard Produces or Consumes which is about 5-10 %. The JAX-RS users won't migrate to @DefaultMethod. for the same reason they did not migrate to having only @Path("var:.*") in their resources.
  • In some cases it can be just handy not to list all the known and custom HTTP verb annotations
  • In some cases it can make it easier to use a JAX-RS runtime to match a request, prepare the parameters and manage the invocation in a non-JAX-RS service environment - this was my original case - I've implemented it with a CXF extension.

Thanks





[JAX_RS_SPEC-508] MediaType isCompatible doesn't work when subtype is wildcard with suffix Created: 05/Feb/15  Updated: 10/Feb/15

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0.1
Fix Version/s: None

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


 Description   

MediaType isCompatible produced incorrect results when subtype is wildcard with suffix. So for example "application/*+xml" is not compatible with "application/vnd.test.type+xml".



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

Moving to JAX-RS where this issue belongs. I'll watch this issue to see whether there can be anything done in Jersey.





[JAX_RS_SPEC-505] Section 3.2 is unclear on primitive and param conversions Created: 12/Jan/15  Updated: 04/Feb/15  Resolved: 04/Feb/15

Status: Resolved
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Bug Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Santiago Pericas-Geertsen
Resolution: Fixed Votes: 0
Labels: paramconverter, parameters
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: paramconverter, parameters

 Description   

Section 3.2 talks about what status and exceptions should be thrown if there is a problem dealing with primitives or ParamConverters.

"Other exceptions thrown during construction of field or property values using 3 or 4 above are treated as client errors: "

It goes on to state which exceptions to throw. Now, I think "using 3 or 4 above" should probably be removed from the spec. So that parsing primitives and param converters are consistent with valueOf and Constructor.



 Comments   
Comment by beryozkin_sergey [ 13/Jan/15 ]

Hi Santiago
+1; The following should also be updated IMHO

"5. List<T> , Set<T> , or SortedSet<T> , where T satisfies 1, 3 or 4 above."

Comment by Santiago Pericas-Geertsen [ 04/Feb/15 ]

See updated Section 3.2.





[JAX_RS_SPEC-506] Consider using @javax.annotation.Priority Created: 16/Jan/15  Updated: 16/Jan/15

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: annotation, priority
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: annotation, priority

 Description   

Instead of JAX-RS' @Priority annotation, which could be deprecated in favor of the common one.






[JAX_RS_SPEC-489] JavaDocs for Client, WebTarget and Invocation should clearly say whether invocations MUST be thread-safe Created: 28/Oct/14  Updated: 26/Dec/14

Status: Open
Project: jax-rs-spec
Component/s: client
Affects Version/s: 2.1
Fix Version/s: None

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

Issue Links:
Related
is related to JAX_RS_SPEC-490 Document thread-safety Open

 Description   

JAX-RS 2.0 provides a Client API which is prepared for intense reuse of object instances of Client, WebTarget and Invocation. Unfortunately the JavaDocs of these classes do not say whether a caller can rely upon these instances are thread-safe. As a recent discussion on the user's mailing list has discovered, users abstain from the rist of concurrent usage of these instances as they fear risk of producing problems. Hence, the JAX-RS 2.1 specification should clearly point out (in PDF and / or JavaDocs) whether implementations of Client, WebTarget and Invocation MUST be thread-safe. This unambiguity would allow users to safely the same Client instance from different application threads for example.






[JAX_RS_SPEC-490] Document thread-safety Created: 07/Nov/14  Updated: 26/Dec/14

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.0
Fix Version/s: None

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

Issue Links:
Related
is related to JAX_RS_SPEC-489 JavaDocs for Client, WebTarget and In... Open

 Description   

The Javadoc of all classes should document their thread-safety, otherwise programmers are forced to make potentially-wrong assumptions.



 Comments   
Comment by r_uchoa [ 07/Nov/14 ]

Especially javax.ws.rs.client.Client.

Comment by mkarg [ 26/Dec/14 ]

I'd like to extend this idea by the following:

  • The JAX-RS specification and / or JavaDocs should clearly express that it is valid to reuse WebTarget, Request, and Invocation instances multiple times without any need to "reset" them between ionnvocations, and it must be allowed that multiple threads are used for these invocations without any further thread-safety measures on behalf of the application.

After there had been some discussions on the Jersey mailing list, it seems there is demand to use multiple threads executing invocations against shared instances of WebTarget, Request and Invocation.

Comment by mkarg [ 26/Dec/14 ]

More or less the same issue.





[JAX_RS_SPEC-504] Spec should declare a vendor-neutral way to start JAX-RS server in Java SE environment Created: 23/Dec/14  Updated: 23/Dec/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.1
Fix Version/s: None

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


 Description   

JAX-RS declares Java SE as one of several possible environments. Unfortunately it does not declare how to start a JAX-RS server application in pure Java SE. As a consequence, all vendors provides different methods to do so, leading to vendor-locked-in applications.

To get rid of the vendor-lock-in I'd like to propose that the JAX-RS specification defines a vendor-neutral API how a JAX-RS server application can be started in a pure Java SE environment.

This does not imply any assumptions upon how a JAX-RS implementation reacts upon such an API invocation other than "the application is started on the specified endpoint defined by the root URI appended by @ApplicationPath (if existing)".

A proposed API could look like this and is up to further discussion among the expert group:

JAXRS.start(URI rootURI, Application application)





[JAX_RS_SPEC-503] Support for forward/redirect Created: 17/Dec/14  Updated: 17/Dec/14

Status: Open
Project: jax-rs-spec
Component/s: server
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Bug Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: forward, redirect
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: forward, redirect

 Description   

Similar to what is supported by the Servlet spec.






[JAX_RS_SPEC-501] Exception handling and recovery during validation Created: 11/Dec/14  Updated: 11/Dec/14

Status: Open
Project: jax-rs-spec
Component/s: server
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Improvement Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: exceptions, validation
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: exceptions, validation

 Description   

The only way to handle exceptions thrown during (declarative) resource validation is via exception mappers. This mechanism may be insufficient in some cases, especially when an application (or framework) can recover from some errors. The problem is that there is a single mapper for say, ConstrainValidationException, for all resource methods in an application, making error recovery difficult.






[JAX_RS_SPEC-500] Exceptions thrown during validation Created: 11/Dec/14  Updated: 11/Dec/14

Status: Open
Project: jax-rs-spec
Component/s: server
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Bug Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: exceptions, validation
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: exceptions, validation

 Description   

The specification should be more explicit on how the underlying BV exceptions are reported to applications during resource validation. Applications can use exception mappers to handle these exceptions, but only if the specification is clear as to how these exceptions are reported.

Some users have stated that certain JAX-RS implementations wrap exceptions, making it more difficult to handle them in mappers.






[JAX_RS_SPEC-499] ResponseBuilder should have a method accepting a map of headers Created: 26/Nov/14  Updated: 26/Nov/14

Status: Open
Project: jax-rs-spec
Component/s: model api
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Marek Potociar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In can be tedious to manually set the cached headers on an instance of ResponseBuilder.
Response.fromResponse implementation has the code that might be reused






[JAX_RS_SPEC-493] Reader and Writer interceptors should see the request context properties Created: 12/Nov/14  Updated: 26/Nov/14  Resolved: 26/Nov/14

Status: Resolved
Project: jax-rs-spec
Component/s: client, model api
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: beryozkin_sergey Assignee: beryozkin_sergey
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The interceptors should see the properties set either on Client or Container request context. For example, it can be handy if a client request filter has aborted a request and would like to pass a hint to a reader interceptor on how to act on such a response.






[JAX_RS_SPEC-498] Support java.util.Optional as parameter type in resource methods Created: 24/Nov/14  Updated: 24/Nov/14

Status: Open
Project: jax-rs-spec
Component/s: filters&handlers
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: aioobe_ Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Jersey fills in missing optional resource method arguments with 'null'. Dealing with "possibly null" variables can be a bit of an annoyance, so more than often I do

Optional<String> optArg1 = Optional.ofNullable(arg1);
Optional<String> optArg2 = Optional.ofNullable(arg2);
...

at the top of my resource methods. This opens up for use of many convenience methods such as map, orElse, orElseThrow, ifPresent etc.

So, request for enhancement: Let Jersey handle java.util.Optional as parameter type in resource methods directly.






[JAX_RS_SPEC-497] Add getAcceptableEncodings to HttpHeaders Created: 20/Nov/14  Updated: 20/Nov/14

Status: Open
Project: jax-rs-spec
Component/s: model api
Affects Version/s: None
Fix Version/s: 2.1

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Marek Potociar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Accept-Encoding can have values with the qualifiers and it can be tricky for users to deal with sorting them, HttpHeaders already has a similar support for language and type qualifiers






[JAX_RS_SPEC-496] Standardize proxy-based JAX-RS client API Created: 18/Nov/14  Updated: 18/Nov/14

Status: Open
Project: jax-rs-spec
Component/s: client, spec
Affects Version/s: None
Fix Version/s: None

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


 Description   

All major JAX-RS implementations have some kind of proxy-based extension to build restful clients using an interface and the same set of annotations used server-side. If you're familiar with writing JAX-RS services, the development of a client becomes much easier.

This is also the core idea of frameworks like Square's
Retrofit and Netflix Feign.

Some references:

A small example for Facebook's Graph API:

Client client = ClientBuilder.newClient();
WebTarget target = client.target("https://graph.facebook.com/");
target = target.path("{id}").resolveTemplate("id", id);
 
Response response = target.request().get();
FBUser user = builder.get(FBUser.class);

vs

@Path("/")
public interface FacebookAPI {
	@GET
	@Path("{id}")
	FBUser getUserInfo(@PathParam("id") String id);
}

FacebookAPI endpoint  = /* initialize client */;
FBUser user = endpoint.getUserInfo(id);

There are several use cases where this approach is useful, eg. for REST services that don't use HATEOAS, JSON-LD or any other mechanism to express the available resources or actions.






[JAX_RS_SPEC-495] Allow to differentiate default values for "null parameters" & "empty parameters" Created: 18/Nov/14  Updated: 18/Nov/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

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


 Description   

Assume the following resource method:
@GET Response getMessages(@QueryParam("unread") boolean unread)

{ ... }

Now I would like to be able to have the following behavior:
GET "/messages" -> unread = false
GET "/messages?unread" -> unread = true
This is analog to HTML boolean attributes, where the mere presence of an attribute indicates the value "true".

However, because @DefaultValue is used for both cases, I can't obtain this behavior. So I would like to suggest to differentiate the 2 cases, e.g. by adding an attribute: @DefaultValue(value="false", emptyValue="true")






[JAX_RS_SPEC-494] Clarify processing of empty parameters Created: 18/Nov/14  Updated: 18/Nov/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

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


 Description   

Empty parameters (i.e. "a" in URIs like "?a" and "?a=&b=c") have specific behavior (see pseudo-code below, using Jersey), but in my opinion this is not clearly specified in neither the specification (sections 3.2 & 3.3.2) nor the Javadoc of @DefaultValue.

if(p == null)

{ return try-parse(@DefaultValue)-or-return-500 || JavaDefaultValue }

else if(p.isEmpty()) {
try

{ return parse(p) } catch(e) { return try-parse(@DefaultValue)-or-return-500 || JavaDefaultValue }
} else {
try { return parse(p) }

catch(e)

{ return 404/400 }

}



 Comments   
Comment by Anthony Ve [ 18/Nov/14 ]

Specifically:

  • in the specification I read it as though there are only 2 cases: either @DefaultValue is used, or either the parameter is parsed (using constructor/valueOf/fromString) & a 400/404 is returned if it fails. However for empty parameters, a combination of both is used.
  • in the Javadoc of @DefaultValue it says "The default value is used if the corresponding meta-data is not present in the request." In my opinion, this statement does not include the case of requests like "?a=&b=c", where I'd consider "a" to be present in the request.




[JAX_RS_SPEC-492] Support for HTTP proxies in Client API Created: 12/Nov/14  Updated: 12/Nov/14

Status: Open
Project: jax-rs-spec
Component/s: client
Affects Version/s: None
Fix Version/s: 2.1

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Marek Potociar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Having an API for simplifying configuring the clients which need to go via proxies might be useful






[JAX_RS_SPEC-491] Add a 'doc' property to all of JAX-RS annotations Created: 12/Nov/14  Updated: 12/Nov/14

Status: Open
Project: jax-rs-spec
Component/s: model api
Affects Version/s: None
Fix Version/s: 2.1

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Marek Potociar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Java Docs do not always adequately describe the purpose of a given JAX-RS method or parameter. A 'doc' property set by default to an empty string can be useful to offer a JAX-RS specific documentation and it will be easier for various document generators (WADL, Swagger) to get a documentation from a well known property, example:

@Path(value="/root", doc="RootResource")





[JAX_RS_SPEC-276] API needs to support multiple links per rel Created: 21/Oct/12  Updated: 05/Nov/14

Status: In Progress
Project: jax-rs-spec
Component/s: hypermedia
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Bug Priority: Critical
Reporter: algermissen Assignee: Santiago Pericas-Geertsen
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

RFC 5988 requires parsers to ignore multiple links with the same rel value for any given Link header:

http://tools.ietf.org/html/rfc5988#section-5.3

However, this requirement does not apply across multiple Link headers, as clarified here:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07612.html

Given that, the relevant API constructs must be fixed, for example:

ContainerResponseContext.hasLink(String relation)
ContainerResponseContext.getLink(String relation)
ContainerResponseContext.getLinkBuilder(String relation)

But there might be others, I think.

Jan



 Comments   
Comment by Santiago Pericas-Geertsen [ 06/Feb/13 ]

Although it would be possible to modify the API to return multiple links, a few of the EG members indicated that this change will no be for the benefit of supporting the common case. Thus, we should review if additional methods are required after gaining more experience with the API. Moving to ice box.

Comment by Santiago Pericas-Geertsen [ 05/Nov/14 ]

We can certainly add a getLinks(String rel) method to the appropriate classes that returns a set of links given a relation. Do we have a sense as to how common this use case may be?

I don't want to extend the API just to cover a corner case which can be easily handled as follows,

r.getLinks().stream().filter(l -> "myrel".equals(l.getRel()))

using lambdas. Regardless, we do need to clarify the semantics of the existing methods if rel values are not unique.





[JAX_RS_SPEC-444] Annotations to declare resource method response status type Created: 06/Jan/14  Updated: 22/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: hypermedia, spec
Affects Version/s: 2.1
Fix Version/s: ice box

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


 Description   

Rather than having to return a generic Response object in order to set
the status code to 201 CREATED, it would be nice to be able to mark a
resource method as @Creates, @Modifies, @Deletes, and have the
framework automatically map successful responses to something like 201
CREATED, 200 OK, 204 NO CONTENT.






[JAX_RS_SPEC-441] Explore making support for q parameter more compatible with RFC2616 Created: 12/Dec/13  Updated: 22/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: runtime
Affects Version/s: 2.1
Fix Version/s: ice box

Type: Task Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: accept, algorithm, q

 Description   

From "Ron Sigal":

I was surprised that the algorithm in Section 3.8 of the JAX-RS spec seems to be inconsistent with the algorithm implicit in http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1, which I described on RESTEASY-994 as

1. Let PO = the partial order on accepted media types induced by "is less specific than".

2. Add "dummy/dummy;q=0" as the minimal element in PO, where "dummy/dummy;q=0" is a wildcard like "/"

3. For each M in available media types:
Let Q_M = max

{ q | q is the quality factor of a maximal element in PO }

4. Let Q = max

{ Q_M | M in available media types }

5. Let MT =

{ M | M is an available media type such that M_Q = Q }

6. If no element in MT matches an accepted media type, return a "406" response.

7. Return an arbitrary element of MT

Actually, there are a couple of gaps in http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1:

1. There is no mention of tie breaking in the case that multiple available media type are assigned the same quality factor. I think that the consensus on RESTEASY-994 is that the available media type that matches the more specific requested media range should be given preference. For example, given

Accept: application/json, /

application/json and application/xml would both have a quality factor of 1.0, but application/json should be preferred. Step 7 could be changed to implement tie breaking based on specificity.

2. There is no precise definition of "more specific". For example, I would expect application/json to be more specific that /;a=1;b=2;c=3, but Resteasy currently prefers the latter because it counts the number of parameters. I think that should be changed with the ordering defined:

media type 1 is more specific than media type 2 if and only if

  • media type 1 has a non wildcard type and media type 2 has a wildcard type, or
  • media type 1 has a non wildcard subtype and media type 2 has a wildcard subtype, or
  • media type 1 has more parameters than media type 2

3. It's a minor thing, but there's no suggestion for what to do with

Accept: application/json, application/xml, application/json;q=0.5

Anyway, the way things are, Request.selectVariant() is governed by http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14 (I guess), and negotiation based on the @Produces annotation is governed by Section 3.8 of the JAX-RS spec, and I believe they can legally return different results. In particular, the JAX-RS algorithm doesn't have a notion of basing the quality factor of an available media type on the most specific matching requested media range. For example, given the somewhat artificial case

Accept; application/json;q=0.5, application/*

and

@Produces("application/json, application/xml")

the HTTP algorithm would assign a quality factor of 0.5 to application/json because application/json;q=0.5 is more specific than application/*, but the JAX-RS algorithm gives

M = { S("application/json;q=0.5", "application/json"), S("application/", "application/json"), S("application/", "application/xml")
=

{ application/json;q=0.5, application/json;q=1.0, application/xml;q=1.0 }

where

application/json;q=1.0 >= application/xml;q=1.0 > application/json;q=0.5

and

application/xml;q=1.0 >= application/json;q=1.0 > application/json;q=0.5

are both legal orderings, so that either application/json or application/xml could be returned.






[JAX_RS_SPEC-440] WebApplicationException contract could clarify behaviour related to JTA resources Created: 09/Dec/13  Updated: 22/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.1
Fix Version/s: ice box

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

Issue Links:
Related
is related to GLASSFISH-20699 GlassFish returns 500 instead of 404 ... Reopened

 Description   

This is based on JERSEY-2137 (GLASSFISH-20699 respectively).

If a WebApplicationException is thrown from a resource method belonging to a @Transactional annotated JAX-RS component,
it is not clear if the WebApplicationException should drive the response and JTA runtime should be worked around,
or (based on the JTA spec) the exception should be handled by JTA runtime instead (transaction would be rolled back,
etc, see: https://javaee-spec.java.net/nonav/javadocs/javax/transaction/Transactional.html).
Maybe this could be clarified in the JAX-RS spec.

Currently one way to avoid WebApplicationException to cause rollback is to use the dontRollbackOn parameter on the @Transactional annotation.
I.e. the following should provide a predictable result:

@RequestScoped
@Path("test")
@Transactional(dontRollbackOn=WebApplicationException.class)
public class MyTransactionalService {

        @GET
        @Produces(MediaType.TEXT_PLAIN)
        public String get() {
          ...
        }
}





[JAX_RS_SPEC-434] Add Response.getRequestUri() Created: 23/Oct/13  Updated: 22/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: client
Affects Version/s: 2.1
Fix Version/s: ice box

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


 Description   

When a request is redirected by the server (e.g. 301 MOVED PERMANENTLY) there is no easy way for clients to discover the final URI. Yes, we can disable ClientProperties.FOLLOW_REDIRECTS and manually walk the graph but it would be far more convenient for the implementation to expose the final request URI since it already has this information.

This is useful for URL canonicalization.






[JAX_RS_SPEC-430] Update Cookie and NewCookie to RFC 6265 Created: 10/Oct/13  Updated: 22/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.1
Fix Version/s: ice box

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


 Description   

Cookie and NewCookie are designed to support RFC 2109, which nobody ever implemented (OK, Opera supported it, but they probably no longer do now that they switched to Chromium), and worse, it breaks in recent Google Chrome.

The de-facto Web standard (aka Netscape spec or version 0) has been finally documented and standardized as RFC 6265, and I think it's time to update everyone to it: http://tools.ietf.org/html/rfc6265

Notable differences:

  • no Comment or Version
  • space required between semi-colon and attribute name
  • many attribute values are not quoted (e.g. Path)

I haven't dug to find what breaks Chrome, but it's either the Version (tried setting it to 0, to no avail), the lack of spaces, or the quotes in the Path. I wrote my own HeaderDelegate using the RFC 6265 syntax, that I injected into Resteasy to replace the default one using RFC 2109 and it now works like a charm.

What I'm thus proposing is:

  • @Deprecate the comment and version properties
  • use the RFC 6265 syntax. I'd go as far as ignoring version and comment, but you might want to keep using RFC 2109 when version is set to 1 (should it still be the default?) and only switch to RFC 6265 otherwise.


 Comments   
Comment by t.broyer [ 10/Oct/13 ]

Somewhat related: JERSEY-317





[JAX_RS_SPEC-421] EntityTag.equals(): Remove unnecessary call to super.equals() Created: 28/Aug/13  Updated: 22/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: runtime
Affects Version/s: 2.0
Fix Version/s: 2.1

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


 Description   

javax.ws.rs.core.EntityTag invokes:

if (!(obj instanceof EntityTag))
  return super.equals(obj);

The second line should return false.

  1. This is the first time I've ever seen equals() delegate to super in case of a type mismatch. I find it hard to imagine when this would be useful.
  2. EntityTag extends Object, so in this case we are guaranteed super.equals(obj) will return false. We might as well return false for clarity, if nothing else.





[JAX_RS_SPEC-417] Add delegation mechanism for Allow header value Created: 19/Jul/13  Updated: 22/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.0
Fix Version/s: 2.1

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

Tags: 405, allow, header, method_not_allowed, options

 Description   

Please see discussion with Santiago on the User's mailing list here.

The issue is that there is no mechanism in the specification for a User to provide the contents of the "Allow" header during 405 Method Not Allowed handling. The spec provides for setting of the Allow header through at least the following means:

  • User can call ResponseBuilder.allow methods (but this requires a matched method), or
  • User can create an @OPTIONS annotated method for a specific Http Options request, or
  • User can set the header directly in the Response (for example in a filter - as Jan's Cacheable annotations here), or
  • Implementor sets the Allow header in the case where no (matched) @OPTIONS method is available or to support a 405 Method Not Allowed

So, the User can control all cases except the 405 Method Not Allowed handling, which defaults to the implementors solution. This can result in a mismatch between the Allow methods intended by the User, and those generated by the implementation.

The request is to add some form of delegation mechanism in order that the User can control the response in this case.

Note(s):

a) I suspect that there is a more general requirement here to be able to delegate the provision of header values to a resource method. For example, ETags strike me as something that fall into this category.

b) The implementation to support the 405 Method Not Allowed case probably needs to support some form of Uri matching, as by definition there is no matched method at this point.






[JAX_RS_SPEC-415] Add "public Builder type(MediaType type)" method to the Link.Builder interface Created: 25/Jun/13  Updated: 22/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: hypermedia
Affects Version/s: 2.1
Fix Version/s: ice box

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


 Description   

The Link.Builder interface definition in package javax.ws.rs.core.Link includes a method to set the MediaType using a String, as follows:

public Builder type(String type);

It would be useful for the Builder to support setting of the 'type' by MediaType instance, especially as these are statics i.e.

public Builder type(MediaType type);

This may even be preferable as it restricts the 'type' to configured MediaTypes.






[JAX_RS_SPEC-412] Enable SecurityContext to handle composite principals Created: 01/Jun/13  Updated: 22/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: 2.1

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


 Description   

Injectable SecurityContext only naturally supports authentication schemes with a single principal.

However, OAuth and similar, delegation-oriented, authentication schemes have more than one principal. For example, OAuth has client and resource owner.

When writing filters for these schemes, one has to work around SecurityContext - in fact, the only way to make the second principal available to a resource class is by creating a specialized Principal and casting to that in the resource class - relying on the filter chain to have set an appropriate SecurityContext instance.

Discussion on how to do this is probably best done on the list.

Priority explanation: I put the priority to "major" because it currently negatively affects work I do on general filters in the delegated authorization space. I think this is a major area of JAX-RS to operate in - hence I am reluctant to set it to "minor".






[JAX_RS_SPEC-406] Matching algorithm should ignore resource methods which do not match request HTTP verb and Media Type(s) in section 3.7.2 Created: 20/May/13  Updated: 22/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: 2.1

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


 Description   

Given

GET /sub

and

@Path("/")
public class Resource {
   @POST
   @Path("sub")
   public void post();

   @Path("{id}")
   public Resource locator() {
   }

   @GET
   public void get();
   }
} 

Resource#get method will not be selected, which is spec compliant.
Note, Resource.post method is added to the list of candidates even though it does not match @GET. This of course won't make it selectable in the end but the side-effect is that Resource.locator will come out as the 2nd best candidate and will be dropped.

If we have only those resource methods which match not only Path, but also HTTP verb and Media Types added to the list of candidates, then in this case we will only a single candidate, Resource.locator and thus Resource.get will be selected



 Comments   
Comment by beryozkin_sergey [ 20/May/13 ]

Note that we have a non-match in this case not because we do not do en expensive subresource check and then backtracking, etc.
but because we start checking non-locator methods on HTTP Verb + Media Types too late, after locator candidates have been dropped.

The example in https://java.net/jira/browse/JAX_RS_SPEC-405 works in JAX-RS 1.1 and will work again in 2.0/2.1 by pure 'luck' (path comparison), but this 'luck' is achieved quite effectively without any expensive sub-resource exploration.

If we have this issue fixed then the example in both JAX_RS_SPEC-405 and JAX_RS_SPEC-406 work without any performance penalties. Once we have JAX_RS_SPEC-405 fixed it will become rather strange that the example in this section won't work (positively).

That said I agree JAX_RS_SPEC-405 is a separate issue (bug fix) from this one (improvement). Thanks





[JAX_RS_SPEC-402] Restrict the case of having the empty payload to HTTP Content-Length available and set to 0 Created: 01/May/13  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.1
Fix Version/s: ice box

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


 Description   

Hi All, we have the cases where:

  • the non-empty payload is available and no Content-Length header is available
  • checking InputStream.available() to determine if the payload is really empty causes side-effects

Proposal: have the spec text saying that the runtime can only reliably determine the payload is empty if Content-Length is available and set to 0.






[JAX_RS_SPEC-391] Clarify what HttpHeaders.getRequestHeader should return when the header is not available Created: 22/Mar/13  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: model api
Affects Version/s: 2.1
Fix Version/s: ice box

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


 Description   

It is not clear what HttpHeaders.getRequestHeader should return when no given header is available.

getRequestHeader(String) returns List. If we look at getAcceptableMediaTypes/getAcceptableLanguages, they return singleton lists with default values in case of missing Accept Accept-Language headers - so one may assume that getRequestHeader(String) should return an empty List if no header is available.

On the other hand, getHeaderString returns 'null' when the header is not available. Also, the docs for getRequestHeader(String) say that it is a shortcut for getRequestHeaders().get(name), which also implies 'null'.

Thus I'm nearly sure that getRequestHeader(String) needs to return 'null' if no header is available but I'd appreciate the clarifications at the API level.



 Comments   
Comment by beryozkin_sergey [ 26/Mar/13 ]

Marek, can you give me a favor and may be just answer it here if updating the docs is tricky at this stage ? I may need to do some more work depending on the answer

Comment by Santiago Pericas-Geertsen [ 26/Mar/13 ]

The fact that getRequestHeader(name) is equivalent to getRequestHeaders().get(name) implies that it must return null by definition Map.get(). I don't think the priority of this clarification is worth a re-spin of the release.

Comment by beryozkin_sergey [ 26/Mar/13 ]

Sounds good. Hope you appreciate that there is some scope for the alternative reading. For example, one might've assumed that the Map has been prepared to have empty lists.

Anyway, major thanks for the clarifications.

Comment by Santiago Pericas-Geertsen [ 26/Mar/13 ]

I agree that this is worth clarifying, but I just don't think it's worth the effort at this point. Moving to ice box.

Comment by beryozkin_sergey [ 26/Mar/13 ]

Sure - I should've said earlier I'm perfectly OK with this move





[JAX_RS_SPEC-370] Support passing the properties in the outbound filter/interceptor chain Created: 25/Feb/13  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: model api
Affects Version/s: 2.1
Fix Version/s: ice box

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


 Description   

Can be postponed and moved to ice-box, if preferred.
The particular case we have is passing a property from WriterInterceptor (or ContainerResponseFilter) to MessageBodyWriter, this will work with the implementation specific code, but preferably one would just do containerResponseContext.getProperties().put("a", "b").
Note at the moment MessageBodyWriter can not get such properties in the portable way, but the feature may be handy even at the filter and write interceptor level only



 Comments   
Comment by Marek Potociar [ 06/Mar/13 ]

I think one way to allow this would be to make ContainerRequestContext (officially) injectable via @Context. But it's really too late now for the change IMO. Let's do this as part of MR.





[JAX_RS_SPEC-360] It would be useful to have a standard annotation to indicate fault codes Created: 19/Feb/13  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.1
Fix Version/s: ice box

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


 Description   

At the moment here is no standard way using annotation to indicate what status code a method / or exception will produce, this makes it harder to generate complete WADL descriptions of the service.

For example:

@Status(200, 404)
@GET
@Path("{path}")
public String get(....) {}

Or even the more complicated:

@Status(404)
public NotFoundException extends WebApplicaitonException {...}

@GET
@Path("{path}")
public String get(....) throws NotFoundException {}

A generator tool could then output the correct WADL description along with the types in this case.



 Comments   
Comment by Marek Potociar [ 20/Feb/13 ]

Deferring to future consideration.





[JAX_RS_SPEC-359] It would be useful to have a UriTemplateParser as part of the spec Created: 19/Feb/13  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.1
Fix Version/s: ice box

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


 Description   

UriTemplateParser is useful when generating client boilerplate as it allows a client to extra parameters from a URI that the user of the API has provided.

At the moment I have to rely on an internal implementation that is part of Jersey making the JAX-RS 2.0 client not cross platform.



 Comments   
Comment by gdavison [ 19/Feb/13 ]

I wonder if this could be as simple as adding a method to UriBuilder:

public boolean match(URI uri, Map<String,String> parameters);

This would greatly reduce the API impact of this request.

Comment by Marek Potociar [ 20/Feb/13 ]

Not sure what the method above is supposed to do. Can you please elaborate?

Comment by gdavison [ 20/Feb/13 ]

Sure, sorry the original bug was poorly written.

So the problem I am trying to deal with when generating a JAX-RS 2.0 client is that the user would like the client to be able to take in a URI:

http://example.com/name/Bob/age/41

And to understand and extract the parameters so they can be reset, so assuming the template looks like this:

http://example.com/name/

{name}/age/{age}

So ideally the code would look like this:

String template = "http://example.com/name/{name}

/age/

{age}

";
UriBuilder builder = UriBuilder.fromPath(template);
Map<String,String> parameters = new HashMap<>();
builder.match(uri, parameters);

Then you can change a parameter:

parameters.put("name", "Arnold");
builder.build(parameters);

Which would give the URI:

http://example.com/name/Arnold/age/41

The match method returns a boolean so it would return false if the URI didn't match what was being provided. I hope this is a lot clearer as to my intent.

Comment by Marek Potociar [ 20/Feb/13 ]

Ok, so what you are looking for is perhaps a method like:

Map<String, String> params = builder.parametersOf(uri);

Correct? Or do you prefer your version where you have to create the Map instance? (If yes, then why?)

FWIW, I'm releasing PFD today, but let me bring this up to EG - maybe we can add this before final release if EG agrees.

Comment by gdavison [ 20/Feb/13 ]

I think the reason behind having to pass the parameters in is that it allow the method to still return a boolean parameter which tells you if the URI matches at all. I guess the method could throw an exception in this case instead - don't have a suggestion of a suitable one though.

Also the conservative part of me always like to be able to pass in a Map just in case I want to be able to reuse an instance of an object. (I spend many a happy hour dealing with the fact that early versions of AWT would always create a Rectangle to get hold of size rather than allows you to pass one in as that did for Graphics2D)

It would be useful to have this as the JAX-RS 2.0 client generated for the moment is depending on the jersey UriTemplate class and I would like to have it removed of course.

Comment by Marek Potociar [ 20/Feb/13 ]

Thinking more about it, I'd really like to have a solution that does not mixes up a builder components with URI template matching ones...

So the proposed solution may look like:

  • introduce UriTemplate to represent, well, URI templates...
  • add ability to build UriTemplate instances from UriBuilder
  • expose the boolean UriTemplate.match(URI, Map<String, String>) method as part of the UriTemplate API.
Comment by Marek Potociar [ 06/Mar/13 ]

The proposal was discussed in EG and EG decided that it's too late to include this in 2.0 release unfortunately. We need to defer the issue for now.





[JAX_RS_SPEC-363] JAX-RS response 406 with no entity but RFC 2616 recommends to have one Created: 14/Dec/12  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.1
Fix Version/s: ice box

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

No envirmonent specific


Issue Links:
Duplicate
is duplicated by JAX_RS_SPEC-362 406 not returning entity Resolved
Tags: rfc2616

 Description   

Apparently, JAX-RS (JSR 311) for every situation with 406 Status, say that response will have no entity. For example, in section 3.7.2 Request Matching, Identify the method that will handle the request:

At least one of the acceptable response entity body media types is a supported output data format (see section 3.5). If no methods support one of the acceptable response entity body media types an implementation MUST generate a WebApplicationException with a not acceptable response (HTTP 406 status) and no entity. The exception MUST be processed as described in section 3.3.4.

However, RFC 2616 recommends another thing:

10.4.7 406 Not Acceptable

The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.

Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.

Note: HTTP/1.1 servers are allowed to return responses which are
not acceptable according to the accept headers sent in the
request. In some cases, this may even be preferable to sending a
406 response. User agents are encouraged to inspect the headers of
an incoming response to determine if it is acceptable.

So, what should I do for Jersey include an entity containing a list of available entity characteristics in 406 scenario.



 Comments   
Comment by rdllopes [ 14/Dec/12 ]

I should have removed the last sentence (but I can edit the issue).

Comment by rdllopes [ 14/Dec/12 ]

This issue was discussed in http://java.net/projects/jersey/lists/users/archive/2012-12/message/20.





[JAX_RS_SPEC-317] client convenience methods for forms Created: 07/Dec/12  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.1
Fix Version/s: ice box

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


 Description   

Was wondering if we could add some convenience methods to Sync and AsyncInvoker?

Response post(Form form);

etc. And any other post() method that has an Entity as parameter.

Basically this would be a shorthand for post(Entity.form(form)). Since we have a specific type for form data (Form), IMO, this makes a lot of sense.



 Comments   
Comment by Marek Potociar [ 09/Jan/13 ]

Would you agree with deferring these types of usability enhancements to JAX-RS 2.1 MR?

Comment by patriot1burke [ 09/Jan/13 ]

Sure, i don't care. They are really simple though.

Comment by Santiago Pericas-Geertsen [ 06/Feb/13 ]

It was agreed to move this to the MR.





[JAX_RS_SPEC-313] Improve usability of GenericType Created: 16/Nov/12  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: runtime
Affects Version/s: 2.1
Fix Version/s: ice box

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

Issue Links:
Duplicate
is duplicated by JAX_RS_SPEC-119 Provide tidier API for GenericType an... Resolved

 Description   

http://jersey.java.net/nonav/apidocs/1.15/jersey/com/sun/jersey/api/client/WebResource.html offers two methods for retrieving entities. One takes Class, the other GenericType. GenericType is clumsy to construct and isn't great from a code-readability point of view.

I propose replacing it with an API discussed here: https://github.com/FasterXML/jackson-core/issues/41#issuecomment-10432125

Assuming we use something like ClassMate (discussed in the above link) I propose the following API:

TypeResolver.resolve(Type type, Type... typeParameters)

The resulting user code would look like this:

WebResource resource = ...;

// Simple type: URL.class
resource.get(URL.class);

// Compound type: List<URL>
resource.get(TypeResolver.resolve(List.class, URL.class));

// Compound type: Map<String, Integer>
resource.get(TypeResolver.resolve(Map.class, String.class, Integer.class));

// A mix of simple and compound types, for example HTTP headers
// Map<String, List<String>>
resource.get(TypeResolver.resolve(Map.class, String.class, TypeResolver.resolve(List.class, String.class)));

Notice how you can specify multiple type parameters (GenericType is limited to one) and the syntax is consistent whether you specify simple types or compound types. Lastly, this Builder pattern provides far more flexibility at runtime.

See http://www.cowtowncoder.com/blog/archives/2010/12/entry_436.html for a related discussion

I believe very little effort would be involved in integrating this into Jersey 2.0 because the ClassMate library exists and already does all the heavy lifting.



 Comments   
Comment by Marek Potociar [ 04/Feb/13 ]

Personally I do not find the TypeResolver approach more readable. But it may be a matter of taste.

In any case, it's unfortunately too late for this kind of change. What we can consider doing in JAX-RS 2.0 MR is to introduce GenericType.of(Type, Type...) factory method or similar to support the suggested type-construction approach. Deferring the issue.





[JAX_RS_SPEC-304] Integration of EJB authorization with JAX-RS Created: 28/Oct/12  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: server
Affects Version/s: 2.1
Fix Version/s: ice box

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

EJB



 Description   

The JAX-RS API already describes the possibility to integrate JAX-RS with EJB by simply adding the @Stateless annotation to a JAX-RS resource, and it defines the ability to access a Principal instance to find out about the current user of an authenticated request.

An EJB typically obtains automatic authorization using security annotations like @RolesAllowed. In turn, it becomes the EJB container's responsibility to prevent unauthorized callers from entering the annotated method, but automatically throw a security exception (and propagate it to the client).

As a result, it is possible to write a JAX-RS resource which is a secured EJB, using code like this:

@Stateful @Path("/stats") class UserStatistics {
  @GET @RolesAllowed("Administrators") public getSomeInterestingMetrics() {...}
}

Unfortunately the JAX-RS specification so far does not explicitly say how a JAX-RS implementation has to react when it finds @RolesAllowed or other security annotations. From the EJB perspective, the author of such a code would possibly want to achieve the following:

(1) The annoations are "fully operational", hence operate as described by their particular specifications.
(2) The central Java EE security provider is utilized.
(3) Non-authenticated requests, or non-authorized Principals, will not enter the resource method but instead the JAX-RS implementation responds with "403 Forbidden".
(4) The JAX-RS's automatically provided "Allow" header for an OPTIONS request will omit any HTTP methods which would be not executed following the sense of (3) when requested with the same security credentials as the OPTIONS call (i. e. either unauthenticated or authenticated as the same user).
(5) A "403 Forbidden" response will be mapped to a security exception on the client.

As a result of this assumption I want to propose to add this enhancement to an upcoming release of the JAX-RS specification.



 Comments   
Comment by patriot1burke [ 29/Oct/12 ]

+1.

Comment by Santiago Pericas-Geertsen [ 29/Oct/12 ]

+1

Comment by Marek Potociar [ 30/Oct/12 ]

Targeting for future release.

Comment by patriot1burke [ 13/Nov/12 ]

Not sure I agree with the OPTIONS stufff, but the 403 Forbidden sounds pretty good, straight forward, and intuitive.

Comment by rkorn [ 02/Sep/13 ]

Are there any workarounds to "mary" EJB-role-based-security and JAX-RS security till this feature is implemented?

Comment by abhi0123 [ 17/Nov/13 ]

What about security though deployment descriptors, ejb-jar.xml + container-specific-ejb-jar.xml when deployed as an ejb-jar or web.xml + container-specific-web.xml when deployed as war? I didn't see anything clearly said in the spec about that.





[JAX_RS_SPEC-301] CDI Events Created: 23/Oct/12  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: injection
Affects Version/s: 2.1
Fix Version/s: ice box

Type: New Feature Priority: Major
Reporter: mkarg Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Jersey 2.0 M08-1, JAX-RS 2.0 M12, JRE 1.7.0_07



 Description   

Java EE contains CDI, which provides Events. Java EE contains JAX-RS, which provides events (in the sense of @Suspended -> .resume()). Readers might wonder why JAX-RS does not tell a word on CDI Events. It would allow interesting scenarios, where a MDB receives a JMS message, triggers a CDI event, and that CDI event resumes a suspended JAX-RS response. As one idea of Java EE 7 is to further integrate the participating technologies and specifications, this scenario is a killer for MDB/JMS, CDI Events and JAX-RS async responses: This scenario allows to integrate asynchronous integration of different technologies, and as such is a perfect technology suite for implementing business processes ontop of Java EE 7!



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

No plans to resolve in JAX-RS 2.0. Targeting for a future release.

Comment by walec51 [ 26/Dec/12 ]

I also think that async JAX-RS and CDI events would be a powerful and natural combination.
Hope this will become a topic for the Java 8 EE spec.





[JAX_RS_SPEC-300] @MessageDriven as JAX-RS resource Created: 23/Oct/12  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.1
Fix Version/s: ice box

Type: New Feature Priority: Minor
Reporter: mkarg Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Jersey 2.0 M08-1, JAX-RS 2.0 M12, JRE 1.7.0_07



 Description   

The specification says that a JAX-RS resource can be annotated as @Stateless, hence be a stateless session bean. It is unclear why it should not be possible to mark is as @MessageDriven instead. This would make sense if a bean is to be triggered on two ways from a consuming services: Old style services could use JMS, while new style service could use REST. While it might be technically possible already, the fact that the specification does not clearly allow it leads to a possibly over-complex design, where an MDB in turn calls a SLSB that is a JAX-RS resource. If it is technically possible, the spec should state that it MUST be possible on all implementations.



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

Deferring for future re-evaluation.





[JAX_RS_SPEC-290] Spec must be clear about the fact that JAX-RS on Java EE enforces underlying Servlets 3.0 and Autoconfiguration Created: 23/Oct/12  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: server
Affects Version/s: 2.1
Fix Version/s: ice box

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

Jersey 2.0 M08-1, JAX-RS 2.0 M12, JRE 1.7.0_07



 Description   

The JAX-RS 2.0 spec should clearly say that when deploying to a Java EE container independent of the actual technology it is using no configuration is required by the application programmer or developer, but an auto-scanning mechanism MUST be applied by the Java EE container (even if that one is NOT based on Servlet 3.0). That is the only way to guarantee WORA in Java EE, since Java EE enforces Servlets, but does not enforce JAX-RS to base on Servlets. The spec currently only says how to deploy on Servlets but does not mandate Servlets itself. This unfortunately leaves room for implementations that are provided by Java EE containers, but that will not base on Servlets.



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

Deferring for future re-evaluation. Currently only official supported EE deployment model is on top of a Servlet container.

Comment by mkarg [ 02/Nov/12 ]

Maybe you misunderstood my intention. All I want to reach is that JAX-RS 2.0 clearly says that a Java EE container MUST support JAX-RS on top of Servlet 3.x, and any other possible support of JAX-RS is only additional.





[JAX_RS_SPEC-226] Add support for jax-rs-catalog for client injection Created: 05/Jul/12  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.1
Fix Version/s: ice box

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


 Description   

The new client injection specification is a big step forward in JAX_RS_SPEC-170; but to support real world system you need a method of being able to control service URI at deploy time so that it is easy to test services and to deploy to different environments.

The wadl.java.net project makes use of a catalog file for this, similar to what is implemented for the JAX-WS RI and is detailed here:

http://kingsfleet.blogspot.co.uk/2012/03/catalog-support-for-wadl-client.html



 Comments   
Comment by Marek Potociar [ 05/Sep/12 ]

Moving to ice-box for post-2.0 evaluation.





[JAX_RS_SPEC-159] Support for relative URIs Created: 22/Dec/11  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.1
Fix Version/s: ice box

Type: New Feature Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The JAX-RS API provides very little support for relative URIs. Classes such as Target, Link and UriBuilder should better support relative URIs, including automatic conversion into absolute URIs using contextual information.

The API should support the generation of relative URIs in headers/entities as well as the ability to follow these URIs without manually (via user code) turning them into absolute URIs.



 Comments   
Comment by Marek Potociar [ 05/Jun/12 ]

Deferring for a future release. (MR of 2.0 is the current target)





[JAX_RS_SPEC-157] Provide an Interceptor API to wrap around execution of Resource method Created: 21/Dec/11  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 1.1
Fix Version/s: ice box

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


 Description   

It is desirable to automatically measure certain metrics (e.g resource method execution time) in a JAX-RS container operational environment - It is currently possible to do that for MBRs and MBWs and other providers, but there is no interceptor control point for resource method invocation. It will be good to add this interceptor API to the spec.

Here is some context from the email thread

On Dec 20, 2011, at 10:22 PM, Sastry Malladi wrote:

>
> >> Yes, it would require adding annotations. Without any use of an API, I'm not sure this case belongs to the spec. I think this should better be handled by implementations or other tools (like profilers).
>
> Well, I understand your position that this may not be addressed in the spec. But in reality, any organization that uses JAX-RS to deploy their services/resources, would want to monitor and measure these metrics automatically, especially in the internet world, and would need a way to do that. For example, we are doing this currently by writing a jersey response filter and approximating by subtracting MBR and MBW times and so on. I beg to differ that this is not a profiler/tooling issue

I think it's a valid use case, there's no question about that. IMO the best way to address this is via a monitoring/listener API (which some implementations support). This API could work not just around resource method invocations but also all the providers --I don't see a good reason to only support resource methods.

However, such an API is currently not in scope for JAX-RS 2.0. If you haven't done so, file it as an issue for tracking purposes.

– Santiago



 Comments   
Comment by Marek Potociar [ 24/Feb/12 ]

What would be the expected behavior for async case? Could this be done via CDI-managed JAX-RS resources?

Comment by Marek Potociar [ 21/May/12 ]

Out of scope for 2.0 and very limited time left - deferring to a future release.

Comment by Santiago Pericas-Geertsen [ 20/Oct/14 ]

This seems interesting, but more of an implementation feature than a spec feature IMO.





[JAX_RS_SPEC-365] Seam Framework JaxRS templating support Created: 08/Dec/11  Updated: 20/Oct/14  Resolved: 20/Oct/14

Status: Closed
Project: jax-rs-spec
Component/s: None
Affects Version/s: 1.1
Fix Version/s: ice box

Type: Improvement Priority: Minor
Reporter: bsdmonkey Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Having explored Seam Framework JaxRS templating support [1] I find it useful and could be incorporated into the spec.
@ResponseTemplate and @ResponseTemplates annotations to designate the template[s] to use for either the default response mime-type for the method annotated with @Produces or with a property (like in Seam doc) @ResponseTemplate(value = "/freemarker/categories.ftl", produces = "application/xml").
Provide and SPI to register TemplatingProviders (FreeMarker etc...) the extension provider should implement an Interface. The implementation (during registration) express its interest in a specific templating language by mean of RegEX (.ftl, /templates/freemarker/).

[1] http://docs.jboss.org/seam/3/rest/latest/reference/en-US/html/rest.templating.html



 Comments   
Comment by Santiago Pericas-Geertsen [ 20/Oct/14 ]

This is now for the new JSR 371: MVC.





[JAX_RS_SPEC-121] Formalize the List<?> and Map<?> XML and JSON mappings Created: 10/Aug/11  Updated: 20/Oct/14  Resolved: 20/Oct/14

Status: Closed
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: ice box

Type: Improvement Priority: Major
Reporter: gdavison Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently there is support for generically mapping List<?> types to XML document, and with less complication JSON documents. The contents are wrapped up in a XML element with no namespace with a local name that in some english cases are plural versions of the generic parameters localname.

This does present some problems, not least that the lack of namespaces means that any client side JAX-B classes will by default end up without a package.

The suggestion is to solve this problem in two way, first of all change the defaults for namespaces to follow the following rules:

1. Look at the method returning the collection object and see if there is a @CollectionType annotation

If so use the namespace and local name defined in this annotation. If no local name rule is defined use an agreed pluralization table to ensure inter-op between different implementations.

2. If no namespace look for a package-info definition for the package containing the resource and use any XML namespace defined here

3. If no package-info found then default using the standard JAX-B rule for converting packages to namspaces.

This results in sensible defaults and allow the user to override the settings with the @CollectionType annotation that would be as simple as:

public @interface CollectionType
{
String namespace();
String name();
}



 Comments   
Comment by gdavison [ 10/Aug/11 ]

For JSON types of course only the name would be significant.

Comment by gdavison [ 10/Aug/11 ]

If there is going to have to be generic mapping Map<Key,Value> then I guess it would be of the form:

<collectionName>
<entry>
<key>...</key>
<value>...</value>
</entry>
</collectionName>

We could go further and provide extra annotation properties to control the name and the namespace of the entry element in the same annotation. So:

public @interface CollectionType

{ String namespace(); String name(); String entryName(); }
Comment by Marek Potociar [ 05/Jun/12 ]

Deferred for a future revision. It should be probably moved to a JSON binding or JAXB3 spec once the JSRs are formed.

Comment by Santiago Pericas-Geertsen [ 20/Oct/14 ]

This ought to be addressed by the new JSR 367: JSON binding.





[JAX_RS_SPEC-110] Allow multiple JAX-RS implementations share one JVM Created: 09/Jun/11  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.1
Fix Version/s: ice box

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

Issue Links:
Related
is related to JERSEY-1451 jersey-core should not Export-Package... Resolved
Relates
relates to JAX_RS_SPEC-488 Pluggable implementations Open

 Description   

In JAX-RS 1.1, javax.ws.rs.ext.RuntimeDelegate class variable, rd, is used
to keep a JAX-RS implementation RuntimeDelegate instance.

This instance is then used in JAX-RS API internal classes
like follows:

RuntimeDelegate.getInstance().createUriBuilder()

If multiple JAX-RS implementations are running within one JVM, only
a single RuntimeDelegate implementation is used for all JAX-RS API calls.
This disallows multiple JAX-RS implementations to run correctly in parallel
within one JVM. Our Jersey users experience this issue even when trying
to run different Jersey versions within one container.



 Comments   
Comment by ceefour [ 12/Oct/12 ]

Also affects Jersey/CXF running in OSGi containers e.g. Karaf.

See #JERSEY-1451

Comment by Marek Potociar [ 04/Feb/13 ]

Deferred to future release.





[JAX_RS_SPEC-60] Resource metamodel Created: 11/Mar/11  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.1
Fix Version/s: ice box

Type: New Feature Priority: Major
Reporter: robc Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

(Email from Bill Burke, http://java.net/projects/jax-rs-spec/lists/jsr339-experts/archive/2011-03/message/29)

  • MetaData API so that extensions to RESTEasy can browse through the JAX-RS resources defined
  • A Dynamic way to register JAX-RS resources (not based on annotations) because currently in order
    to define new resources dynamically we need to generate bytecode with the proper JAX-RS annotations


 Comments   
Comment by Marek Potociar [ 24/Feb/12 ]

Need to spend more time prototyping. We should revisit this in the next major JAX-RS version. Moving to ice-box.





[JAX_RS_SPEC-36] Support for EXI and FastInfoset Created: 19/Feb/11  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: ice box

Type: New Feature Priority: Trivial
Reporter: mkarg Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Transmission of XML is quite a burden for the net due to a lot of formatting and readability information. Due to that, several proposals had been created, like Fast Infoset. It makes sense to support such transport encodings. As client and server only rely on the transported encoding, it is necessary to contain the used encoding in the specification of the service. As the service is implemented using JAX-RS with transparency to the underlying levels like Servlets or Containers, JAX-RS must contain a possibility to define the encoding supported by the service (otherwise the service implementation would become dependent of specific Servlets or Containers).

I want to propose a minimum set of encodings:

(Mandatory) EXI - http://www.w3.org/TR/2011/PR-exi-20110120/

(Optional but mentioned) Fast Infoset



 Comments   
Comment by Marek Potociar [ 21/May/12 ]

Out of scope for 2.0 and very limited time left - deferring to a future release.

Comment by Santiago Pericas-Geertsen [ 20/Oct/14 ]

Given the growth of JSON in recent years. Is support for binary XML formats still as relevant as before? Perhaps this is an area for the JAX-RS implementations to innovate, not the spec.





[JAX_RS_SPEC-29] Extends @MatrixParam with ("subpath;param") Created: 30/Jul/10  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.1
Fix Version/s: ice box

Type: Improvement Priority: Minor
Reporter: joseaio Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Related
is related to JAX_RS_SPEC-201 getMatrixParameters() on UriInfo and ... Resolved
Relates
relates to JAX_RS_SPEC-3 @MatrixParam should not inherit values Open
Issuezilla Id: 102

 Description   

> Can be a new feature?
>
> On this URL: GET /mercedes/e55;color=black/2006/interior;color=tan
>
> Mapped as: @Path("/

{make}

/

{model}

/

{year}

/

{extra}

")
>
> Can access to all "color" matrix params, for example, with:
>
> @MatrixParam("model;color")
> @MatrixParam("extra;color")
>
> Thanks to Bill Burke for example (on their book "RESTfull Java with JAX-RS)
>

Yes, rather than using @PathParam("model") PathSegment ps.

Can you please log an issue here:

http://jsr311.dev.java.net/

Paul.



 Comments   
Comment by Santiago Pericas-Geertsen [ 06/Feb/13 ]

Interesting feature that didn't make the cut for 2.0. Moving to ice box for future review.





[JAX_RS_SPEC-3] @MatrixParam should not inherit values Created: 19/Jan/09  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.1
Fix Version/s: ice box

Type: Improvement Priority: Trivial
Reporter: cowwoc Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Related
is related to JAX_RS_SPEC-201 getMatrixParameters() on UriInfo and ... Resolved
Relates
relates to JAX_RS_SPEC-29 Extends @MatrixParam with ("subpath;p... Open
Issuezilla Id: 63

 Description   

Given: /images;offset=

{offset}

;count=

{count}/random;count={count}

Where /images is implemented using one resource, and /random using a sub-resource

If I declare @MatrixParam in the sub-resource random but the client does not
specify the "count" parameter at all, I should get null (indicating the
parameter was missing) instead of inheriting the value of count from /images.
Currently there is no obvious way to detect the real value of count for /random.

With respect to implementing the entire URL with a single Resource, it should be
possible to get:

1) The first, last value or some other convention, or
2) A list of all values, or
3) A mapping between path segments and the associated parameter values (similar
to what we would get if we used a sub-resource)



 Comments   
Comment by mhadley [ 16/Mar/09 ]

Changing the current behavior would introduce a backwards incompatibility. We could consider adding a
new property to @MatrixParam to control inheritance but the default value would need to represent the
current behavior. A workaround is to use UriInfo.getPathSegments() in the method body.

Comment by Marek Potociar [ 08/Feb/13 ]

Deferring to future release.

Comment by cowwoc [ 22/Oct/13 ]

Instead of adding a new property to @MatrixParam to control inheritance, leave the current method as-is and add a second method that returns #3 (a mapping between map segments and associated values). This will maintain backwards compatibility and allow us to test the approach in the Jersey namespace before promoting it to javax.ws.rs.

Marek, what do you think?





[JAX_RS_SPEC-43] Provide method to access X509 client certificates Created: 10/Jun/10  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.1
Fix Version/s: ice box

Type: Improvement Priority: Minor
Reporter: rebach Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 100

 Description   

JAX-RS should provide a way to access an X509 certificate of the client.
Currently it seems only possible with a Servlet-Based implementation to access
this.

see https://jsr311.dev.java.net/servlets/ReadMsg?list=users&msgNo=1068



 Comments   
Comment by rebach [ 28/Mar/11 ]

Maybe this could just use @Inject on a argument or field of type X509Certificate[]

Comment by bblfish [ 28/Mar/11 ]

The orginal thread has been lost above. It can be found here now
http://java.net/nonav/projects/jsr311/lists/users/archive/2010-06/message/1

The reason why this is needed is that
1. Not all web servers are Servlet Based.
2. The Servlet Based solution is more of a bad hack than anything else
Just for reference, this is the current standard solution:

X509Certificate[] certificates = (X509Certificate[]) request
.getAttribute("javax.servlet.request.X509Certificate");

That is very opaque.

Comment by bblfish [ 07/Apr/11 ]

Perhaps the correct solution is to get the authentication layer to place the X509 certificate in the Subject, as explained in the JAAS Guide
http://download.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#Subject

This is what we did at the Clerezza incubator project. The FoafSslAuthentication class creates a new subject with a wrapped X509Claim.

https://svn.apache.org/repos/asf/incubator/clerezza/trunk/parent/platform.security.foafssl/core/src/main/scala/org/apache/clerezza/foafssl/auth/FoafSslAuthentication.scala

Then this can be called everywhere because the subject is always associated with the thread of execution, as in this class

https://svn.apache.org/repos/asf/incubator/clerezza/trunk/parent/platform.security.foafssl/test/src/main/scala/org/apache/clerezza/foafssl/test/WebIDTester.scala

where getSubject just is the code

public static Subject getSubject(final AccessControlContext context) {
Subject subject;
try {
subject = AccessController.doPrivileged(new PrivilegedExceptionAction<Subject>() {

@Override
public Subject run() throws Exception

{ return Subject.getSubject(context); }

});
} catch (PrivilegedActionException ex) {
Exception cause = (Exception)ex.getCause();
if (cause instanceof RuntimeException)

{ throw (RuntimeException) cause; }

throw new RuntimeException(cause);
}
return subject;
}

and the context can be got with the static java method AccessController.getContext()

Comment by bblfish [ 07/Apr/11 ]

this was discussed on the Clerezza list here https://issues.apache.org/jira/browse/CLEREZZA-481

Comment by Santiago Pericas-Geertsen [ 06/Feb/13 ]

Authentication and related topics have been pushed to MR. Moving to ice box.

Comment by rebach [ 07/Feb/13 ]

Not sure what "pushed to MR" means. But while I trhink that specifying "authentication and related topics" is not something in any way urgent for JAX-RS giving ways to access all the relevant information of a request in a JAX-RS application is indeed urgent. Requiring application to fall back to the servlet level defeats the purpose of having a higher level of abstraction. Also standardizing this seems neither complicated nor implying major architectural choices.

X509Certificate[] certificates = request.getX509Certificates();

would do the trick.





[JAX_RS_SPEC-27] Specify mapping of AccessLocalException for EJBs with @RolesAllowed Created: 31/May/10  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.1
Fix Version/s: ice box

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 99

 Description   

When @RolesAllowed is declared on an session bean that is also a resource class
and then the EJB may throw a AccessLocalException if the client is not authorized.

JAX-RS implementations should map this AccessLocalException to a 401 response.

Applications will of course need to correctly set up credentials and the sharing
of those between the web and ejb containers.

It remains an open issue how a JAX-RS implementation can obtain information to
return a WWW-Authenticate response header.



 Comments   
Comment by matthewcornell [ 21/May/12 ]

Hello folks. I'm new to Java EE and found that the server's returning of 500 vs. 401 to be misleading and confusing. Is this considered a minor issue for developers? Thanks very much. – matt

Comment by Marek Potociar [ 08/Feb/13 ]

We're waiting for a better common security auth context support in JEE to be able to deal with this in a portable way. Deferring to future release.





[JAX_RS_SPEC-24] Need way to generate similar resource URL's from given URL Created: 09/Feb/10  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.1
Fix Version/s: ice box

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 96

 Description   

I posted along these lines a while back, but I continue to run into cases where
I need to make modifications to a URI, and there doesn't seem to be an easy way
to do it.
For instance, if my resource has URI .../color/red/width/10/height/5, I find
myself needing to redirect the client after an "edit" operation to
.../color/BLUE/width/10/height/2.

What I really want is
UriInfo.getAbsolutePathBuilder().addOrReplaceSegment("color/$","BLUE").addOrReplaceSegment("height/$

{height}

","2");



 Comments   
Comment by Marek Potociar [ 08/Feb/13 ]

Perhaps it would make sense to expose the full matched URI template via UriInfo?

Comment by Marek Potociar [ 08/Feb/13 ]

Deferring to future release.





[JAX_RS_SPEC-18] @HttpMethod should guess value if omitted Created: 12/Dec/09  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.1
Fix Version/s: ice box

Type: New Feature Priority: Minor
Reporter: mkarg Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Related
is related to JAX_RS_SPEC-71 Alignment of "Convention over Configu... Open
Issuezilla Id: 88

 Description   

Typically, JAX-RS methods are defined by a 1:1 relation between the
annotation's (@interface's) name, and the same name provided in the @HttpMethod
value:

@HttpMethod("FOOBAR")
public @interface FOOBAR {
}

As it is rather tedious and error-prone to always repeat the same string twice,
it would be a nice feature if by default the @HttpMethod would expect this name
equalness if the value attribute was left out:

@HttpMethod // implies value="FOOBAR" by default
public @interface FOOBAR {
}

The reduces the possibility of typos (unintentional deviation of @HttpMethod's
value and annotation's interface name) and is less boring.

As this is not a major feature but just a slight improvement, and as this is
does not break the binary backwards compatibility, I want to propose the
adoption of this minor feature into JSR311 Maintenance Release 1.2.



 Comments   
Comment by mkarg [ 12/Dec/09 ]

I'd like to discuss the following, optional addition to the above proposal:

In case the annotation's (@interface's) name contains an underscore character
('_'), each occurence of this character shall get replaced by a hyphen
character ('-') in the default value of the @HttpMethod annotation:

@HttpMethod // implied value="FOO-BAR" due to default behaviour
public @interface FOO_BAR {
}

The reason is that it is more typical in HTTP names to use hyphens instead of
underscores. For example, WebDAV is using underscores in several HTTP method
names like "VERSION-CONTROL". It makes sense to follow the "convention over
configuration" pattern and support the convention of hyphens in HTTP instead of
forcing explicit configuration.

Comment by Marek Potociar [ 08/Feb/13 ]

Deferring to future release.





[JAX_RS_SPEC-15] Response/ResponseBuilder should be Generic Created: 10/Nov/09  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.1
Fix Version/s: ice box

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

Operating System: All
Platform: All
URL: http://n2.nabble.com/xml-schema-in-request-and-response-wadl-td3943317.html#a3943317


Issue Links:
Duplicate
is duplicated by JAX_RS_SPEC-108 Response doesn't have a generic type Resolved
Issuezilla Id: 83

 Description   

As discussed in this thread, ideally Response/ResponseBuilder would be generic
to better support static discovery of types for WADL.

A couple of methods were discussed. Paul Sandoz's original proposal made use of
the .<Type> notation:

public class Main {

     public static class Response<T> {

         private final T entity;

         private Response(T entity) {
             this.entity = entity;
         }

         public T getEntity() {
             return entity;
         }

         public static class ResponseBuilder<T> {
             private T entity;

             public ResponseBuilder<T> entity(T entity) {
                 this.entity = entity;
                 return this;
             }

             public Response<T> build() {
                 return new Response<T>(entity);
             }

             static protected <T> ResponseBuilder<T> newInstance() {
                 return RuntimeDelegate.getInstance().<T>createResponseBuilder();
             }
         }

         static public <T> ResponseBuilder<T> start() {
             return new ResponseBuilder<T>();
         }

     }

     public static class RuntimeDelegate {
         public static RuntimeDelegate getInstance() {
             return new RuntimeDelegate();
         }

         public <T> Response.ResponseBuilder<T> createResponseBuilder() {
             return new Response.ResponseBuilder<T>();
         }
     }

     /**
      * @param args the command line arguments
      */
     public static void main(String[] args) {
         Response<String> r = Response.<String>start().entity("xx").build();

         String e = r.getEntity();
         System.out.println(e);
     }
} 

And then I put forward a modified version that removed the need for using the
.<Type> notation by creating a new interim typed version of the Builder:

// Generified Response
public class Response<T> {

    static class GListString extends GenericEntity<List<String>> {
        public GListString(List<String> list) {
            super(list);
        }
    }

    private final T entity;

    private Response(T entity) {
        this.entity = entity;
    }

    public T getEntity() {
        return entity;
    }
   
    public static <T> ResponseBuilder<T> start() {
        return new ResponseBuilder<T>("Some State");
    }
   
    public static class ResponseBuilder<T> {

        private Object state;
        private Type type;
        private T entity;

        public ResponseBuilder(Object state) {
            this.state = state;
        }

        public ResponseBuilder(Object state, Type type, T object) {
            this(state);
            this.type = type;
            this.entity = object;
        }
       
       
        public ResponseBuilder<T> header(String name, String value) {
            return this;
        }


        public <T, K extends GenericEntity<T>> ResponseBuilder<T> entity(K ent) {
            return new ResponseBuilder<T>(state, ent.getType(), ent.getEntity());
        }

        public <T> ResponseBuilder<T> entity(T ent) {
            return new ResponseBuilder<T>(state, ent.getClass(), ent);
        }

        public Response<T> build() {
            return new Response<T>(entity);
        }

    }


    public static void main(String[] args) {

        List<String> list = new ArrayList<String>();
        GListString genericList =
            new GListString(list);

        Response<List<String>> response = Response
            .start()
            .header("Content-Type", "fudge")
            .entity(list)
            .build();

        // Using generic entity
        //

        Response<List<String>> genericResponse = Response
            .start()
            .header("Content-Type", "fudge")
            .entity(genericList)
            .build();

        // String example
        //
       
        Response<String> stringResponse = Response
           .start()                        // ResponseBuilder<?>
           .entity("String")           // ResponseBuilder<String>
           .header("Content-Type", "cheese")  // ResponseBuilder<String>
           .build();
    }
} 

It is possible that neither solution is correct; but it would be good to look
for a modification that covers some of the ideas in the 2.x spec release.



 Comments   
Comment by sandoz [ 10/Nov/09 ]

It's a bit of a hack but one can recast rather than wrap state.

public class Main {

   public static class Response<T> {

       private final T entity;

       private Response(T entity) {
           this.entity = entity;
       }

       public T getEntity() {
           return entity;
       }

       public static <T> ResponseBuilder<T> start() {
           return new ResponseBuilder<T>();
       }

       public static class ResponseBuilder<T> {
           private T entity;

           public ResponseBuilder<T> header(String name, String value) {
               return this;
           }

           public <V> ResponseBuilder<V> entity(V ent) {
               ResponseBuilder<V> vThis = (ResponseBuilder<V>)this;
               vThis.entity = ent;
               return vThis;
           }

           public Response<T> build() {
               return new Response<T>(entity);
           }
       }

       /**
        * @param args the command line arguments
        */
       public static void main(String[] args) {

           Response<String> stringResponse = Response.start()
                   .entity(1)
                   .entity("String")
                   .header("Content-Type", "cheese")
                   .build();
       }
   }
}
Comment by Marek Potociar [ 05/Jun/12 ]

Targeting for 2.0 PFD, but might need to be moved to 2.0 MR.

Comment by Marek Potociar [ 05/Sep/12 ]

Deferring to post-2.0 evaluation.

Since we would end up using type-erased Response in a lot of places, perhaps it would be better to consider introducing a generic response sub-class instead (like in Jersey 1.x).





[JAX_RS_SPEC-5] Improve handling of trailing slash Created: 10/Mar/09  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.1
Fix Version/s: ice box

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

Operating System: All
Platform: All


Issuezilla Id: 71

 Description   

As per the current spec trailing slashes are ignored for the selection of root
resources and resource methods.

This is odd, because it gives effectively two names to the HTTP-resources made
available but it also has a significant practical disadvantage: A resource
method that generates relative links has to have the UriInfo injected and check
for the presence/absence of trailing slash and either adapt the relative links
or send a redirect. It would be good if implementations would free applications
from this burden.

See also: mail-thread from 2009-01-06 on users@jsr311.dev.java.net "trailing slash"



 Comments   
Comment by Marek Potociar [ 05/Jun/12 ]

Deferring for future release. Should be revised as part of 2.0 MR.





[JAX_RS_SPEC-467] javax.ws.rs.* packages should implement java.lang.AutoCloseable where applicable Created: 18/Jun/14  Updated: 16/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: model api
Affects Version/s: 2.0
Fix Version/s: 2.1

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

All



 Description   

Currently the javax.ws.rs.core.Response and javax.ws.rs.client.Client implement close(), but not the AutoCloseable interface. This would be a nice feature so that developers can leverage the try-with-resources syntax.



 Comments   
Comment by mkull [ 09/Oct/14 ]

I'd like that too. If there are concerns regarding backward compatibility to Java6: Derive from Closeable instead and override close() with a no-throws declaration.

Comment by Santiago Pericas-Geertsen [ 09/Oct/14 ]

We'll look at this for JAX-RS.next which will likely require JDK 8.

Comment by atehrani [ 16/Oct/14 ]

Great to hear that this has been resolved! Any reason why this change is tied to JDK 8? I would think the minimum would be JDK 7?

Comment by Santiago Pericas-Geertsen [ 16/Oct/14 ]

It hasn't been resolved, it's status is OPEN. I has just been assigned to version 2.1. We intend to use JDK 8 with JAX-RS 2.1 given that by the time it becomes available, JDK 7 will be EOLed.





[JAX_RS_SPEC-409] JAX-RS client API should be moved to Java SE Created: 24/May/13  Updated: 15/Oct/14  Resolved: 15/Oct/14

Status: Closed
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: ice box

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


 Description   

The JAX-RS client API should be moved to Java SE so clients can use them without having to introduce an additional dependency.

Do let me know if anything needs to be explained further - I am happy to help.

Please note that these are purely my personal views and certainly not of Oracle's as a company.



 Comments   
Comment by Santiago Pericas-Geertsen [ 15/Oct/14 ]

Will be refiled as a JDK JEP as it really does not apply to the JAX-RS spec per se.





[JAX_RS_SPEC-366] Inheritance for JAX-RS annotations Created: 25/Mar/11  Updated: 15/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 1.1
Fix Version/s: 2.1

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


 Description   

Please consider adding the @Inherited annotation to @Path, @Provider, and possibly also
to other JAX-RS annotations as well. This would allow JAX-RS annotations to be inherited
from a parent class to its subclasses.

This is required in situations where developers use AOP tools for creating
dynamic proxies around classes bearing JAX-RS annotations. Right now the
proxies do not have access to those annotations can can thus not be registered
as REST services.






[JAX_RS_SPEC-414] Incorrect code sample in section 5.4 Created: 20/Jun/13  Updated: 15/Oct/14  Resolved: 15/Oct/14

Status: Closed
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.0
Fix Version/s: ice box

Type: Bug Priority: Minor
Reporter: Ian Evans Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In Section 5.4 of the spec, the following code example is shown:

Customer c = client.target("http://examples.org/customers/123")
  .request("application/xml").get(Customer.class);
String newId = client.target("http://examples.org/gold-customers/")
  .request().post(xml(c), String.class);

This won't compile. The xml method within the post method is missing Entity.

Customer c = client.target("http://examples.org/customers/123")
  .request("application/xml").get(Customer.class);
String newId = client.target("http://examples.org/gold-customers/")
  .request().post(Entity.xml(c), String.class);


 Comments   
Comment by Santiago Pericas-Geertsen [ 15/Oct/14 ]

It compiles with the correct import.





[JAX_RS_SPEC-416] Add abstraction for Link Relation Type Created: 25/Jun/13  Updated: 15/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: hypermedia
Affects Version/s: 2.0
Fix Version/s: 2.1

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


 Description   

It would be useful for the API to specify an abstraction for Link Relation Type in a similar manner to the abstraction of Media Type (javax.ws.rs.core.MediaType).

RFC 5988 defines 'Registered Relation Types' (as maintained by IANA here) and 'Extension Relation Types' which are somewhat more local.

It is noted that the list of 'Registered Relation Types' changes (infrequently) and therefore would introduce a degree of ongoing maintenance.

It is also noted that RFC 5988 indicates that 'Extension Relation Types' are URIs which SHOULD be lowercase.

It would be useful for implementors to be able to easily implement compliant Extension Relation Types, and that single entry point could be used to resolve either from a String based value (by a valueOf() method for instance).

Additionally, this would allow the Link.Builder interface to support setting of the "rel" by LinkRelationType, allow implementors to use a List<LinkRelationType> in the Builder implementation, and generally increase the robustness in this area.

I can provide a Gist of something I'm working with if that's useful.






[JAX_RS_SPEC-431] Jersey Client should support Delete with an Entity Created: 23/Sep/13  Updated: 15/Oct/14  Resolved: 15/Oct/14

Status: Closed
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: ice box

Type: New Feature Priority: Minor
Reporter: subodh_r Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: e/likra

 Description   

It should be possible to do the following:

Client client = ClientBuilder.newClient();
WebTarget target = client.target(restURL);
Response response = target.request().delete(Entity.text("payload"));



 Comments   
Comment by Libor Kramolis [ 18/Oct/13 ]

I guess it is intention to not have delete with entity method. You should just identify entity on server side by URI.

From HTTP 1.1 spec:

The DELETE method requests that the origin server delete the resource identified by the Request-URI.

Comment by Libor Kramolis [ 18/Oct/13 ]

(Issue moved from JERSEY project.)

Comment by subodh_r [ 19/Oct/13 ]

The spec does not explicitly prohibit it so maybe the API should not either?

Also see related thread on stackoverflow: http://stackoverflow.com/questions/299628/is-an-entity-body-allowed-for-an-http-delete-request/2074380#2074380

Comment by Santiago Pericas-Geertsen [ 15/Oct/14 ]

Not a spec issue.





[JAX_RS_SPEC-439] PDF uses incorrect method signature for DynamicFeature.configure() Created: 08/Dec/13  Updated: 15/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.0
Fix Version/s: 2.1

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


 Description   

In jsr339-jaxrs-2.0-final-spec.pdf section 6.5.3, the DynamicLoggingFilterFeature example is written as if the method signature of DynamicFeature.configure was

void configure(ResourceInfo, Configuration)

but it is actually

void configure(ResourceInfo, FeatureContext)






[JAX_RS_SPEC-38] Hyperlinking Support Issues Created: 19/Feb/11  Updated: 15/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: 2.1

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

Issue Links:
Related
is related to JAX_RS_SPEC-52 Hypermedia support Resolved
Tags: 2_0

 Description   

JSR 339 will provide Hypermedia support. A first proposal will be Jersey's optional / experimental HATEOAS and Hyperlinking support based on content filtering. There are two issues with that proposal and need to be solved to provide the best value to the programmer. Note that this particular RFE is not about HATEOAS (i. e. not about "Actions") but about Hperlinking (i. e. "Relations").

(1) Link injection

The Hypermedia sample is using XmlAdapters to replace JAXB references by URIs. This is not very smart, as it puts the burden on the programmer. As he has to implement the marshalling and unmarshalling for each reference, he has to implements things that a JAX-RS engine actually knows. Instead of enforcing the programmer to do that, it would be better if JAX-RS would specify a way that automates this.

There is an experimental annoation "@Ref" provided by Jersey, which does the work for the programmer, but it has shortcoming in two aspects.

(a) It is intended to work only with references of the Java types "String" and "URI", while typically JAXB object trees have references of any custom Java type but typically not "String" or "URI". Obviously linking should work with any XmlElement reference instead (or additionally), just as it is possible with XmlAdapters in the Hypermedia sample. In short: "@Ref" should do what @XmlJavaTypeAdapter does plus automatically writing the XmlAdapter.

(b) It seems "@Ref" doesn't guess the sub-resource locator on its own. It would be good if the JAX-RS specification would include an algorithm for automatic guessing of the sub-resource locator. For example, if there is only one method that has a return type of the referenced type and that method is annotated with @GET, it can be the only sub-resource locator suited for the need of "@Ref" reference-to-URI replacement and vice versay. So in that case, an algorithm is running, and that algorithm needs to be defined by the specification to prevent different results from different JAX-RS engines.

(2) Adressing fragments

In some cases it might be needed to references fragments, i. e. not entities but parts of entities. For example, there might be a sub-resource for "Order" which contains child elements of "Ordered Items". It could be the case that a different resource needs to reference not a complete order but one "Ordered Item" only (i. e. a row of the overall order containing the item's code and number of ordered items). Typically such references are implemented using URI fragments like "http://myserver/orders/12345#001" to identify <item id="001"> within <order id="12345">. A different example would be linking to employees being parts of an organization (not to standalone persons), or particular characteristics of items (not to general characteristics as standalone entities), etc. Just everything that couldn't live as a standalone object from a real world perspective.

When providing support for Hyperlinking in JAX-RS, it also makes sense to provide support for URI fragments. In our application for example we are using this using custom code in our product basing on Jersey 1.4 already, by the support of specialized XmlAdapters. The solution is rather simple and could be implemented ontop of (1) Link injection.



 Comments   
Comment by Marek Potociar [ 05/Sep/12 ]

Deferring for post-2.0 evaluation.





[JAX_RS_SPEC-71] Alignment of "Convention over Configuration" / "Configuration By Exception" with other Java EE 6 APIs Created: 07/Apr/11  Updated: 15/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 1.1
Fix Version/s: 2.1

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

Issue Links:
Duplicate
is duplicated by JAX_RS_SPEC-34 it would be nice if @PathParam @FormP... Resolved
is duplicated by JAX_RS_SPEC-59 Convention over configuration Resolved
Related
is related to JAX_RS_SPEC-18 @HttpMethod should guess value if omi... Open
Tags: CoC, ConventionOverConfiguration, JAX-RS, REST, javaee

 Description   

JAX-RS 2.0 should behave (Configuration by Exception / Convention over Configuration) like JPA 2 / EJB 3.2 / CDI APIs:

1. The value of the @Path annotation should be derived from class / method name respectively
2. The default MediaType for @Consumes / @Produces should be MediaType.TEXT_PLAIN
3. There is no need for the specification of @Consumes / @Produces in case 2.
4. A single method (regardless of its name) in a resource / sub resource should be defaulted to a @GET request.
5... [TBD]

But: HTTP methods (@GET, @POST, @PUT ...) must not be automatically derived from method names.

See also: JAX_RS_SPEC-59



 Comments   
Comment by Marek Potociar [ 07/Feb/13 ]

Ad 1. The value of the @Path annotation should be derived from class / method name respectively

This is a good suggestion. However, there's a lot to agree upon yet:

  1. we need to agree on the method for deriving path value from the Java artifacts. My suggestion would be to use "camel-case to all lower-case, dash separated", e.g. BookStore -> book-store, customerAddress() -> customer-address. This approach produces URIs in a canonical form that is very readable and supports applying generic redirection filters that detect non-canonical URIs and canonicalize them (e.g. upper-case letters in URI, see for instance www.stackoverflow.com).
  2. we need to agree what to do with common prefixes and suffixes (Resource, get(), post*. My current suggestion would be to strip them out, but we need to come up with a complete set.
  3. etc.

Ad 2, 3. The default MediaType for @Consumes / @Produces should be MediaType.TEXT_PLAIN

There is a default value specified already and it would be BW incompatible to change it. I suggest we do not proceed with the proposed CoC in this area.

Ad 4. A single method (regardless of its name) in a resource / sub resource should be defaulted to a @GET request.

I'm a bit afraid of loosing some readability, but we may want to start experimenting with this in our implementations and see how users react to that. If the experiment proves to be successful, we may proceed with standardizing.

Comment by Marek Potociar [ 07/Feb/13 ]

Deferring for future release.





[JAX_RS_SPEC-21] Mixing of OPTIONs Created: 29/Dec/09  Updated: 15/Oct/14

Status: Reopened
Project: jax-rs-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 2.1

Type: Improvement Priority: Minor
Reporter: mkarg Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 92

 Description   

JAX-RS specifies that a compliant implementation has to answer OPTIONS requests
by an Allows header created automatically by inspection which HttpMethods have
been found in the resource code.

Sometimes it is necessary that a resource implements OPTIONS to provide some
more headers. Example: A WebDAV resource must return the header "DAV: 1, 2" to
indicate it's "compliance class" (strange but true, since inspecting the Allows
header would provide the same information, but this discussion is out of scope).

The problem is that the automatic Allows header will not be provided as soon as
a OPTIONS implementation is found. So the implementation must not just provide
the additional headers, but also everything that JAX-RS would do automatically.
This is not very smart.

I want to suggest that the next release of JAX-RS specifies a away how to mix
both results, the automatic one of JAX-RS and the manual one of the
implementation.



 Comments   
Comment by cowwoc [ 24/Feb/11 ]

A possible workaround is to use a servlet filter to modify the response before returning it to the user. This is obviously much harder to maintain than having the complete implementation in one class file. There is a further problem you might want to consider...

I am trying to implement Cross-Origin Resource Sharing for my resources: http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing

It's very difficult to implement this in a separate filter because I'm being asked to make authentication decisions about the resource without being able to access its internal state.

Comment by mkarg [ 25/Feb/11 ]

cowwoc, your proposal of using servlet filters will break WORA, as JAX-RS is not dependent of servlets. It is valid to implement JAX-RS without a servlet environment or even standalone. Also, an API that is specialized for implementing RESTful services must support people in extending its features, but not stand in mutual exclusiveness.

Comment by cowwoc [ 25/Feb/11 ]

Hi Mark (I assume it is you),

I agree with you. I was thinking we could provide users with a Response object associated with the default OPTIONS implementation and let them modify it to their liking before returning it. For example:

@OPTIONS
public Response getOptions(Context someContextObject)

{ Response response = someContextObject.getDefaultOptionsResponse(); response.header("Access-Control-Allow-Origin", "*"); return response; }

This implies that users must be able to retrieve and modify all properties found in a Response object. Currently I can add headers to a Response object but I can't find a way to retrieve existing headers or remove them.

Gili

Comment by mkarg [ 25/Feb/11 ]

Gili, yes it is me.

Your idea of having a more general way of mixing autogenerated Response with manually provided headers is quite interesting indeed. But why not going a bit further beyond your "getDefaultOptionsResponse" idea and allowing to inspect any autogenerated Response? I mean, it could be interesting to get access to the following autogenerators, too:

  • Response autogenerated for OPTIONS as described in this case
  • Response autogenerated for conditional requests
  • Response autogenerated when returning JAXB XMLRootElements
  • Response autogenerated by Request.evaluatePreconditions
  • etc.

I could imagine for example that it might make sense to say that it must be possible to do this:

@Whatever
public SomeEntity sample(@Context Response autogenerated, @Context Request request)

{ autogenerated.header("Custom-Header", "some value"); // Add custom header. autogenerated.status("299 My Status"); // Add custom status. return new SomeEntity(autogenerated.getHeader("Date")); // Process autogenerated headers. }

This would allow to mix not only the headers but to also mix in autogenerated header values into the entity content, which might makes sense in some cases, or to set a custom status code without having to replace the return type SomeEntity by Response, making the code much cleaner to read.

Comment by cowwoc [ 26/Feb/11 ]

Mark,

Your approach sounds great to me.

Comment by mkarg [ 27/Feb/11 ]

Gili,

thanks. But let's see what the EG thinks about it and whether the RI will discover implementation obstacles.

Regards
Markus

Comment by Santiago Pericas-Geertsen [ 06/Sep/12 ]

Is there a strong reason for not using a JAX-RS ContainerResponseFilter for this now? If so, please re-open the issue.

Comment by cowwoc [ 06/Sep/12 ]

Santiago,

Please reopen this issue. I stated why a ContainerResponseFilter isn't a good solution in my first comment (see above).

Comment by Santiago Pericas-Geertsen [ 06/Sep/12 ]

Well the comment was about servlet filters, not JAX-RS filters. If you have a case for not using a JAX-RS filter for this, please re-open the issue.

Comment by cowwoc [ 06/Sep/12 ]

Santiago,

1. I don't have permission to reopen issues.
2. The same reasoning applies. If you're dealing with Cross-Origin Resource Sharing (CORS) you're going to need one filter per resource. That's potentially hundreds of filter files floating around instead of embedding the logic inside the Resource where it belongs. In short: it is a maintenance nightmare.

Using filters makes sense if you want to apply the same logic for multiple resources. In the case of CORS that's rarely the case.

Comment by mkarg [ 06/Sep/12 ]

I think it would be beneficial to finally decide about this issue if you could post the solution to the original question using ContainerResponseFilter as in your proposal. How would the code look like to mix the autogenerated OPTIONS and the custom OPTIONS responses?

Comment by Santiago Pericas-Geertsen [ 06/Sep/12 ]

Re-opening by popular demand and to continue the discussion.

Comment by Santiago Pericas-Geertsen [ 06/Sep/12 ]

cowwoc,

Could you elaborate why you'd need a single filter per resource? I'm assuming that you're talking about generating some Access-Control-* headers? There's a few injectable artifacts that a JAX-RS response filter can get access to (like ResourceInfo).

Comment by cowwoc [ 06/Sep/12 ]

Santiago,

Even if it's technically possible, it seems like a maintenance nightmare. Code related to a resource should lie inside the resource. Imagine what happens if these decisions are centralized in a filter and resources are added, rename or renamed.

I believe there are good use-cases for both options. When you need to add the same headers across multiple resources (e.g. caching or expiration headers) a filter makes perfect sense. When you need to add headers specific to a resource, they belong inside the resource itself.

Also, coming back to Mark's point, sometimes we want to append to existing headers (such as OPTIONS). To do this, we need access to the original/default headers.

Comment by Santiago Pericas-Geertsen [ 06/Sep/12 ]

Filters are by definition a one-size-fits-all type of solution. We obviously cannot introduce a specific API solution for each use case. The way I see it there's already two options: if you want the code to be in the resource use @OPTIONS, otherwise use a response filter to modify the standard response. (Incidentally, response filters have access to all the headers in the request and the response and, of course, they can be updated).

Sorry, I just don't see a strong enough or broad enough use case that would justify extending the existing API with specific support for it.

Comment by mkarg [ 06/Sep/12 ]

Well, as you can see, at least two people including me see this need. It is a really bad hack to work around this lack of support. As cowwoc said, it is a maintenance nightmare. That is a strong argument in my eyes.

Comment by cowwoc [ 06/Sep/12 ]

Santiago,

Mark proposed a nice approach for giving @OPTIONS access to the default header values. What do you think?

Comment by beryozkin_sergey [ 17/Sep/12 ]

I think stating in the spec that if Response provided by custom Response implementation does not contain Allow then the runtime MUST add it itself (as opposed to having a user write a custom Response filter for adding it) is sufficient

Comment by cowwoc [ 18/Sep/12 ]

Beryozkin,

What's the benefit of going this route instead of giving users access to the default headers?

Whatever headers you mandate today will be outdated shortly after the spec is released. I don't like the idea of having to wait an additional two years for a revised spec which mandates yet a different set of headers must be generated. Better to give users access to the default headers and allow them to override it as needed.

In OOP, subclasses that override methods often make use of the super implementation. We should be able to do the same.

Comment by patriot1burke [ 05/Feb/13 ]

I personally would not support any new spec API to support default OPTIONS handling because I like what we have currently in RESTEasy.

The way we handle this in Resteasy, is that the runtime throws a specific DefaultOptionsMethodException which is a form of a WebApplicationException. Users that want to override the default OPTIONS behavior write an ExceptionMapper for this exception. The default Response is contained within the exception, so users can copy whatever data they want from it. This approach is good because users can target default OPTIONS behavior and not have to worry about whether or not specific OPTIONS support was added to the resource already.

FYI, our entire internal exception model is mappable and also turned into a response that is filterable.
Also, the uses cases that markus wants to "intercept" are also filterable in our implementation because we pretty much turn every default response into a JAX-RS response and let the filtering layer run.

Comment by cowwoc [ 05/Feb/13 ]

Patriot1burke,

It sounds like you're using exception-handling to drive non-exceptional behavior. Aside from the ideological issue, the practical overhead of using exceptions (versus normal program flow) is extremely large.





[JAX_RS_SPEC-289] Support for JAX-WS in RI Created: 23/Oct/12  Updated: 15/Oct/14  Resolved: 15/Oct/14

Status: Closed
Project: jax-rs-spec
Component/s: runtime
Affects Version/s: 2.0
Fix Version/s: ice box

Type: Improvement Priority: Minor
Reporter: mkarg Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Jersey 2.0 M08-1, JAX-RS 2.0 M12, JRE 1.7.0_07



 Description   

It is a bit a shame that the RI does not support JAX-WS endpoints, while the spec talks about those. The RI should reflect all, not just some, functionality mentioned in the spec. As JAX-WS endpoints are the only endpoint types that will run natively on ANY JRE (not only on Sun's), the RI should provide support for JAX-WS. Moreover, as the stakeholders of JAX-RS participate to this JRE, I think it would be a good idea that they commit to JAX-WS due to that reason, and change the spec to say "A compliant JAX-RS implementation MUST provide a JAX-WS endpoint of type javax.xml.ws.Provider.". That commitment will provide the only possible solution for writing portable Java SE based JAX-RS applications.

I intentionally posted this in the JAX-RS JIRA instead of the Jersey JIRA because I only complain this since it is mentioned in the spec, and theoretically the spec lead could decide to simply use a different product as the RI, so it is not necessarily or clearly a Jersey (or only-Jersey) issue.



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

Not a spec issue.

Comment by mkarg [ 02/Nov/12 ]

I have to object. As the above text proposes a spec change by saying 'change the spec to say "A compliant JAX-RS implementation MUST provide a JAX-WS endpoint of type javax.xml.ws.Provider.' this is a spec issue.

Comment by Marek Potociar [ 05/Nov/12 ]

Moving to icebox.

Comment by beryozkin_sergey [ 09/Sep/13 ]

This definitely goes beyond the JAX-RS scope. We have a number of proper JAX-WS implementations providing javax.xml.ws.Provider so the idea of suggesting that JAX-RS implementations having to offer a JAX-WS endpoint is strange, there's more to it than just offer a javax.xml.ws.Provider support as far as JAX-WS is concerned which can not be reasonably implemented at the JAX-RS level

Comment by Santiago Pericas-Geertsen [ 15/Oct/14 ]

I just don't see enough traction for this idea. We have way too many issues to work on, so I'm closing this one. If reopened, please find some votes.





[JAX_RS_SPEC-308] Introduce MessageTooLargeException Created: 05/Nov/12  Updated: 15/Oct/14

Status: Reopened
Project: jax-rs-spec
Component/s: runtime
Affects Version/s: 2.0
Fix Version/s: 2.1

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


 Description   

HTTP 413 is important status which is used to indicate a request message is to large (example, in case of multiparts, etc).

Please introduce MessageTooLargeException



 Comments   
Comment by Marek Potociar [ 30/Nov/12 ]

I don't think I want to introduce another exception. We could use the similar logic to justify a separate exception for every HTTP error code. But IMO we should really be careful about adding too many exception types.

Closing as Won't Fix. Feel free to reopen if you feel strongly about this. Then we can move this discussion to EG.

Comment by beryozkin_sergey [ 30/Nov/12 ]

I don't think it is going to be productive, now that you've closed and then kind of offer to continue. Of course I won't reopen.

I thought 413 was a code which 'stands out' from the practical point of view...

Comment by beryozkin_sergey [ 18/Dec/12 ]

I'm changing my mind and reopening. Will accept whatever next action is done on it.

Summary: 413 is useful when the payload size has to be restricted to a certain limit (multiparts, etc), or, for example, when a given XML is deemed to have too many nested elements, etc.

Comment by Marek Potociar [ 07/Feb/13 ]

Let's give it a test of time and see if people really want it. We can then add it in MR. Deffering (but keeping open ).





[JAX_RS_SPEC-318] Spec text to do with mapping WebApplicationExceptions makes it impossible to get custom cause exceptions visible to mappers Created: 13/Dec/12  Updated: 15/Oct/14

Status: Reopened
Project: jax-rs-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 2.1

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


 Description   

WAE and subclasses have constructors accepting Response and cause Throwable.

The spec text makes it impossible for the application code to throw WAE initialized with Response containing entity and the cause exception and make this cause exception visible to custom mappers expecting to react somehow to the cause exceptions.

Proposal:

1. Keep the current optimization in place but update the spec to say that "if WAE Response entity is null or WAE cause exception is not null - use the mapper, otherwise - use WAE Response entity directly"

IMHO, much better solution is to drop this optimization - the typical mapper will never blindly replace WAE initialized Response - so keeping this optimization in place would really be about protecting the expectations of the providers which have not been written well.

If that still not an option - then 1 has to be done IMHO, the mappers must be able to see WAE cause exceptions if it is what the user wished by using the relevant constructors from the code



 Comments   
Comment by Santiago Pericas-Geertsen [ 13/Dec/12 ]

Could you elaborate on the use case in which you need a response with a non-null entity and (ii) a cause? And why can't you just use a response with a null entity for the mapper to kick in?

Comment by beryozkin_sergey [ 13/Dec/12 ]

I want my custom mapper to see all WAE exceptions I'm throwing and specifically deal with analyzing all the cause exception if any for the purpose of not necessarily creating the response but for some other reasons, example, for logging the cause exceptions.

Now let me ask you too: do you agree that the spec should support public exception API, and specifically, public WAE constructors accepting Response & cause ? You may not agree the case I described above is convincing but the API is there, it offers the option to get non-empty Response & cause, and hence it has to be supported.

Comment by Santiago Pericas-Geertsen [ 14/Dec/12 ]

The spec talks about non-empty entities in responses, rather than non-empty responses. I can, indeed, throw a WAE with a cause and a response and have it mapped provided that the entity in the response is empty.

I admit I would have preferred all WAE's to be mapped as well, but a decision has been made the JAX-RS 1.X EG to incorporate this optimization. Thus, we need a really strong case to overturn such a decision, especially when considering the BC implications.

Comment by beryozkin_sergey [ 14/Dec/12 ]

Hi Santiago - thanks for the constructive comments;

FYI - my only concern, though I don't have any specific use case of my own - is that the optimization makes it impossible to pass cause exceptions with Responses containing non-empty entities. IMHO some wording or fix has to be done to make some compromise, leaving it as is would be not ideal at all.

Here are few possible approaches:

1. Introduce "SHOULD" or "MAY" into the optimization - this will clearly let users know that they can not rely on WAE constructors to pass the cause Throwable to the mappers alongside Responses with non-empty entities

2. Add a check to such WAE constructor enforcing that the user does not 'lose' the cause Throwable

3. Introduce JAX-RS property (alongside other useful properties) to do with enabling or disabling the optimization

4. Introduce RI specific property which will let those providers which may be indirectly relying on the optimization to keep it enabled till they can have proper checks which will prevent the existing Response entities being lost

etc

1/2 seems OK - the user then will rely on the mapper to create the entity - the possibility remains though that the mapper won't have enough context (as opposed to the application code) for creating a proper entity - may be this is hypothetical but who knows...

Comment by Santiago Pericas-Geertsen [ 17/Dec/12 ]

I suspect that the original intent of this decision was for those cases, as you said, where the application had context to provide a better response entity than any mapper would; in those cases, you'd certainly want that response entity to be used without any mapping.

In option (1) you suggest using SHOULD or MAY, but it isn't clear to me where. Do you want to provide some text for review?

Comment by beryozkin_sergey [ 17/Dec/12 ]

Your last comment makes a lot of sense - this actually convinced me that the original proposal to resolve this issue is offer "or" option.

The actual issue is how to ensure no cause exception gets lost. It is obvious that if at least a single RI user used a WAE constructor accepting Response with non-null entity and cause Throwable then RI-level JIRA issue to do with the exception being lost would've been opened. It has not been and thus it proves this path has not been exercised by RI users.

It is also obvious that whoever decided to try this path will see an exception being thrown.

Thus I propose to change:

"If the response property of the exception does not contain an entity and an exception mapping
provider (see Section 4.4) is available for WebApplicationException or the corresponding sub-
class, an implementation MUST use the provider to create a new Response instance, otherwise the
response property is used directly"

to

"If the response property of the exception does not contain an entity or the exception cause is available and an exception mapping provider (see Section 4.4) is available for WebApplicationException or the corresponding sub-
class, an implementation MUST use the provider to create a new Response instance, otherwise the
response property is used directly"

IMHO it is safe for RI (as far as BC is concerned) due to the above conclusions but also protects users from getting the cause throwables from being accidentally lost.

If the above is not agreed upon then the only solution IMHO is to enforce the relevant constructor to prevent the loss (option2 in my previous post)

Comment by Santiago Pericas-Geertsen [ 18/Dec/12 ]

I think the proposed text is getting difficult to parse and interpret. But you're basically suggesting that out of the 4 cases (entity, no entity, cause, no cause), we only use the optimization for entity + no cause; otherwise, we run the mapper. Correct? If so, I don't have any strong objections to this change.

Comment by beryozkin_sergey [ 18/Dec/12 ]

"we only use the optimization for entity + no cause; otherwise, we run the mapper."

Yes - this will keep the existing optimization and prevent the loss of the cause if it has been included alongside the entity.

Comment by Marek Potociar [ 07/Jan/13 ]

I am not convinced that we should run mappers for WAEs with a non-null cause. The entity in the response should IMO be the only "source of truth" that decides if the response should be used or not.

Comment by beryozkin_sergey [ 10/Jan/13 ]

Well, I agree with the "source of truth" and such, but ultimately if is about covering a rare case which has not happened yet in practice in RI at least: the case where the excefption mapper is also used as a central place where the cause exceptions are logged and such; API does allow to throw WAE with Response containing a non-null entity and also the cause - so with the optimization the non null cause is lost - thus I honestly do not envisage any negative side-effects if this case gets covered at the spec level and additionally the minor API 'hole' is closed to make sure the runtime will never lose the causes

Comment by Santiago Pericas-Geertsen [ 08/Feb/13 ]

We had a long discussion on this one without any agreement, so I'm closing it. If re-opened, please assign to "ice box".

Comment by beryozkin_sergey [ 08/Feb/13 ]

How more disappointing the handling of this request can be.

Santiago, your last comment was: "I think the proposed text is getting difficult to parse and interpret. But you're basically suggesting that out of the 4 cases (entity, no entity, cause, no cause), we only use the optimization for entity + no cause; otherwise, we run the mapper. Correct? If so, I don't have any strong objections to this change.
", followed by Marek's "not convinced", and there you go, just closing it without any idea why

Comment by beryozkin_sergey [ 08/Feb/13 ]

Just for the sake of the principle, up to you where to push this issue next

Comment by Santiago Pericas-Geertsen [ 08/Feb/13 ]

I closed it because even though I was not against the change, I was not convinced by the need for it either --I think this is very clear from my comments. In preparation for PFD, we need to either resolve or postpone all issues for which there's no agreement, such as this one.

Comment by beryozkin_sergey [ 08/Feb/13 ]

Ok, sorry anyway. At the moment the count of issues I opened and which will be not resolved is > than the one which have been resolved/fixed, thus I'm a bit edgy

Comment by Marek Potociar [ 08/Feb/13 ]

I understand your disappointment, but frankly, that is not a metrics we can take into account. I believe we tried to do a fair assessment of all the issues and if we saw a potential value, rather than closing, we deferred the resolution.

Also, there are people who filed just 1 issue and we rejected it. That means 100% rejection rate. Imagine how edgy they must be...

Comment by beryozkin_sergey [ 08/Feb/13 ]

fair enough





[JAX_RS_SPEC-55] Support for JSR-330 annotations and CDI Created: 07/Mar/11  Updated: 15/Oct/14

Status: In Progress
Project: jax-rs-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 2.1

Type: New Feature Priority: Critical
Reporter: robc Assignee: Unassigned
Resolution: Unresolved Votes: 12
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAX_RS_SPEC-35 provide a way to allow dependency inj... Closed
is related to JAX_RS_SPEC-67 Allow custom resource creation Open
is related to JAX_RS_SPEC-72 Standardization of ResourceContext / ... Resolved

 Description   

As described in the JAX-RS 2.0 JSR (http://jcp.org/en/jsr/proposalDetails?id=339):

JAX-RS 1.1 was defined before JSR-330 was specified and as a result does not utilize 330 annotations, such as @Inject, as effectively as it could. This JSR will specify closer integration with 330 annotations that may potentially render some existing annotations in JAX-RS, such as @Context, deprecated or redundant.



 Comments   
Comment by Marek Potociar [ 06/Sep/11 ]

DI integration proposal drafted: http://java.net/projects/jax-rs-spec/pages/DI

Comment by Marek Potociar [ 23/May/12 ]

There are some interaction issues connected to this and we need to take more time to resolve them. Deferring to a future release.

Comment by reza_rahman [ 08/Jun/13 ]

In a Java EE environment, it might also be very useful to be able to do this:

@Inject
Client client;

Or this:

@Inject @Target("http://....")
WebTarget target;

Do let me know if anything needs to be explained further - I am happy to help.

Please note that these are purely my personal views and certainly not of Oracle's as a company.





[JAX_RS_SPEC-487] Consider adding CORS support in JAX-RS.next Created: 17/Sep/14  Updated: 17/Sep/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 2.1

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


 Description   

From the JAX-RS users mailing list:

Currently, when CORS is needed one has to use impl specific code, such
as:

or some custom impl, or "frameworks":

I think JAX-RS should be having something like this, out of the box.






[JAX_RS_SPEC-486] The specification should require a default MBR for StreamingOutput be provided Created: 17/Sep/14  Updated: 17/Sep/14

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: None
Fix Version/s: 2.1

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Santiago Pericas-Geertsen
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I've seen such queries few times and there was another one yesterday.

If a client or server has a binary content coming as InputStream that needs to be saved to some local OutputStream then the current approach is to write a custom code that will manually (possibly with the help of the utility class) read from InputStream and write to OutputStream.

Having the following code instead looks interesting IMHO and makes the code simpler and a bit more portable (example, the utility IO copy class would be typically application or framework specific):

    StreamingOutput so = myResource.request("application/pdf").get(StreamingOutput.class);
    so.write(new FileOutputStream("output.pdf"));


 Comments   
Comment by beryozkin_sergey [ 17/Sep/14 ]

This can also facilitate nearly the end to end streaming if the server also uses StreamingOutput to write the response binary data





[JAX_RS_SPEC-485] Client.close() should close client filters implementing Closeable Created: 12/Sep/14  Updated: 12/Sep/14

Status: Open
Project: jax-rs-spec
Component/s: model api
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Marek Potociar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It can help with writing portable client filters operating with the client cache managers, etc. Effectively this issue is about updating the documentation of Client.close().



 Comments   
Comment by beryozkin_sergey [ 12/Sep/14 ]

For it to be effective a client filter/interceptor instance would need to be created per client, so it would probably have a limited effect, but I'll keep this issue open for now.





[JAX_RS_SPEC-483] Response.created() and ResponseBuilder.location() have the conflicting documentation about relative URIs Created: 27/Aug/14  Updated: 28/Aug/14

Status: Open
Project: jax-rs-spec
Component/s: model api
Affects Version/s: 2.0.1
Fix Version/s: 2.1

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


 Description   

We've had an issue opened with a reference to Response.created() which recommends the use of UriInfo.getRequestUri to resolve relative references, while ResponseBuilder.location to which Response.created() delegates recommends the use of UriInfo.getBaseUri.

Either Response.created() or ResponseBuilder.location() API docs need to be fixed.

IMHO it's actually be better be done for 2.0.2



 Comments   
Comment by Santiago Pericas-Geertsen [ 28/Aug/14 ]

I see your point, I don't recall what's the rationale for this decision. At the same time, it is always possible for created() to resolve the URI before setting the location in the ResponseBuilder, right?

Comment by beryozkin_sergey [ 28/Aug/14 ]

It's a documentation typo, here is the code from javax.ws.rs.core.Response:

public static ResponseBuilder created(URI location) {
        return status(Status.CREATED).location(location);
}

Whatever URI is passed to Response.created(URI) is immediately delegated to ResponseBuilder.location().
The question is, what should ResponseBuilder.location() do if it sees a relative URI. So far I thought it was supposed to be resolved against UriInfo.getBaseUri() as per ResponseBuilder.location() docs. Some users think it has to be according to Response.created() docs.

Comment by Santiago Pericas-Geertsen [ 28/Aug/14 ]

I was looking at the Javadoc, not the code. I see your point now.

Comment by beryozkin_sergey [ 28/Aug/14 ]

Resolving it against request URI is probably better for the purpose of creating Location (i.e, Response.created() doc rules), typically newly created resources would have their URIs extending the parent resource URI. But I'm 99.9 % sure that if we say ResponseBuilder.location() should also resolve it against the request URI then it will break some users' code.
I'd say we probably need to have a new ResponseBuilder.locationAgainstRequestUri(URI location) method (better named ) and get Response.created() delegating to it to avoid any issues.





[JAX_RS_SPEC-482] Clarify if Application.getClasses and getSingletons can be directly used by Configuration injected on the server Created: 26/Aug/14  Updated: 28/Aug/14

Status: Open
Project: jax-rs-spec
Component/s: model api
Affects Version/s: None
Fix Version/s: 2.1

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Marek Potociar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Santiago Pericas-Geertsen [ 28/Aug/14 ]

You mean to add new classes and singletons through the Configuration object? Doesn't the Javadoc state that the values returned are immutable?

Comment by beryozkin_sergey [ 28/Aug/14 ]

Hi Santiago,
Sorry, what I meant was that Configuration.getProperties() does use Application.getProperties() on the server to build the complete list of properties.
Next, Configuration.getClasses() and Configuration.getInstances() are supposed to return a list of classes of registered providers/features.
I wonder, given that on the server Application.getClasses() and Application.getInstances() are in most cases would return a superset of providers/classes too,
should Application.getClasses() and Application.getInstances() be used by Configuration.getClasses() and Configuration.getInstances() ? I mean, should Configuration.getClasses() and Configuration.getInstances() effectively delegate to Application.getClasses() and Application.getInstances() for Configuration to show all classes/instances including those of the root resources ?

Thanks, Sergey





[JAX_RS_SPEC-481] Clarify whether UriInfo.getPath includes a leading slash or not, or provide an alternative Created: 22/Aug/14  Updated: 27/Aug/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

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


 Description   

The Javadoc for UriInfo.getPath just says: "Get the path of the current request relative to the base URI as a string."

In my opinion, it should also specify whether it includes a leading slash or not.

For example: Jersey 2.7 includes the slash, while Jersey 2.8 & later don't. Since it isn't specified, both behaviors are spec-compliant. However,



 Comments   
Comment by Anthony Ve [ 22/Aug/14 ]

one of our applications relied on the leading slash, so it broke when upgrading Jersey.

Personally I feel a leading slash should be included, but some quick tests contradict this. Of the following 4, only the first gives the desired URI:

1) new URI("http://localhost/project/rs/").resolve("users");
2) new URI("http://localhost/project/rs/").resolve("/users");
3) new URI("http://localhost/project/rs").resolve("users");
4) new URI("http://localhost/project/rs").resolve("/users");

So for this to work:

UriInfo info = ...;
info.getBaseUri().resolve(info.getPath());

the following behavior should be specified:

info.getBaseUri() must include a trailing slash, and info.getPath() may not include a leading slash

PS: this issue is related to issue 438: "Provide the recommendation on the use of trailing slashes in UriInfo.getBaseUri"

Comment by beryozkin_sergey [ 26/Aug/14 ]

IMHO the users should be encouraged to work with the builders returned from UriInfo -> this will let them not to worry about trailing slashes. I.e, the alternative you've mentioned in the JIRA subject is actually UriInfo.getBaseUriBuilder().path(uriInfo.getPath())

Comment by Anthony Ve [ 27/Aug/14 ]

Yes, I agree that String manipulation of URIs is just wrong. And now I also noticed that the alternative with URIs is already explicitly mentioned in the javadoc of UriInfo.getAbsolutePath(), so this bug may be closed. Sorry for the overhead.

For reference: the Jersey bug is https://java.net/jira/browse/JERSEY-2458 For Jersey <= 2.7 uriInfo.getAbsolutePath() was not equal to uriInfo.getBaseUri().resolve(uriInfo.getPath(false))





[JAX_RS_SPEC-484] Review and update if needed API docs using the word "resolve" Created: 27/Aug/14  Updated: 27/Aug/14

Status: Open
Project: jax-rs-spec
Component/s: model api
Affects Version/s: 2.0.1
Fix Version/s: 2.1

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Santiago Pericas-Geertsen
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

ResponseBuilder, UriInfo and possibly other API docs use (URI) "resolve" in some cases. For example, ResponseBuilder.location(), etc.
Now that JAX-RS 2.0 has its own URI resolution support, it is becoming a bit confusing what exactly is meant by "resolve".
For example, given "http://a/b" and a relative "b" supplied to ResponseBuilder.location(), most likely the users would expect "http://a/b/b" given that it is a new Location. However, URI Resolution will produce "http://a/b/".

IMHO it will help avoiding lots of confusion going forward if various API referring to "resolve" get clarified what is meant, the concatenation or an actual resolution.



 Comments   
Comment by beryozkin_sergey [ 27/Aug/14 ]

IMHO if this issue gets accepted then it's better be done for 2.0.2





[JAX_RS_SPEC-438] Provide the recommendation on the use of trailing slashes in UriInfo.getBaseUri Created: 29/Nov/13  Updated: 27/Aug/14

Status: Open
Project: jax-rs-spec
Component/s: model api
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Marek Potociar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Please expand UriInfo.getBaseUri documentation with the recommendation on the use trailing slashes.



 Comments   
Comment by beryozkin_sergey [ 02/Dec/13 ]

It might be important for users working directly with URI to resolve the relative references against the base URI, where a trailing slash will affect the result. However, working with UriInfo#getBaseUriBuilder() is a safe option which should be recommended.

My preferred text would read something like this: "Users should not depend on the base URI containing a trailing slash for building URI links. Using UriInfo#getBaseUriBuilder() is recommended".

This should be enough IMHO as both "http://myhost.com" and "http://myhost.com/" qualify as base URIs so restricting UriInfo#getBaseUri to have or not to have a trailing slash can be problematic. And recommending using a UriBuilder will solve the issue of concatenating the path segment values.

Note no ambiguity exists for absolute or request URIs, only for the base URI





[JAX_RS_SPEC-474] Update Configuration documentation to clarify where it can be injected Created: 23/Jul/14  Updated: 26/Aug/14  Resolved: 26/Aug/14

Status: Resolved
Project: jax-rs-spec
Component/s: model api
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: beryozkin_sergey
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Configuration can be injected as the JAX-RS context. Please clarify if it can be injected into server root resources. If yes then resolving it as Wont Fix or similar with the related comment will be fine, thanks



 Comments   
Comment by beryozkin_sergey [ 26/Aug/14 ]

Application.getProperties clearly refers to Configuration being injected in the server context





[JAX_RS_SPEC-447] Improve javadoc of WebApplicationException(String) Created: 26/Feb/14  Updated: 21/Aug/14  Resolved: 30/Jul/14

Status: Resolved
Project: jax-rs-spec
Component/s: runtime, spec
Affects Version/s: 2.0
Fix Version/s: 2.0.1

Type: Bug Priority: Trivial
Reporter: jan.supol Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: 2.0.1-candidate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The javadoc says:

public WebApplicationException(java.lang.String message)
Construct a new instance with a blank message and default HTTP status code of 500.

The message is not blank.

The same at
WebApplicationException(java.lang.String message, int status)
WebApplicationException(java.lang.String message, Response.Status status)
WebApplicationException(java.lang.String message, java.lang.Throwable cause)
WebApplicationException(java.lang.String message, java.lang.Throwable cause, int status)
WebApplicationException(java.lang.String message, java.lang.Throwable cause, Response.Status status)






[JAX_RS_SPEC-456] Javadoc: ParamConverter et all missing @Since 2.0 Created: 24/Mar/14  Updated: 21/Aug/14  Resolved: 30/Jul/14

Status: Resolved
Project: jax-rs-spec
Component/s: providers, spec
Affects Version/s: 2.0
Fix Version/s: 2.0.1

Type: Bug Priority: Trivial
Reporter: maslen Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: 2.0.1-candidate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JAX-RS 2.0



 Description   

Just a really minor nit, but...

ParamConverter is, I believe, new for JAX-RS 2.0, but the Javadoc doesn't mark it as @Since 2.0.

Ditto for ParamConverter.Lazy and ParamConverterProvider.

(They also aren't mentioned directly in the PDF spec, other than a passing reference in section 3.2, but perhaps that's OK).






[JAX_RS_SPEC-479] Entity.getAnnotations() should never return null. Created: 06/Aug/14  Updated: 21/Aug/14  Resolved: 06/Aug/14

Status: Resolved
Project: jax-rs-spec
Component/s: spec
Affects Version/s: None
Fix Version/s: 2.0.1

Type: Bug Priority: Major
Reporter: Marek Potociar Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: 2.0.1-candidate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The javadoc states that the method either returns annotation array, if there are any annotations set, or an empty array, if no annotations have ben set. Creating an Entity instance by passing 'null' into the annotations constructor parameter however violates the javadoc.






[JAX_RS_SPEC-407] ResponseBuilder.entity(Object entity, Annotation[] annotations) and ContainerResponseContext.getEntityAnnotations() javadoc needs clarification Created: 20/May/13  Updated: 21/Aug/14  Resolved: 06/Aug/14

Status: Resolved
Project: jax-rs-spec
Component/s: server, spec
Affects Version/s: 2.0
Fix Version/s: 2.0.1

Type: Bug Priority: Major
Reporter: Marek Potociar Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: 2.0.1-candidate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It should be made more clear that:

  • ResponseBuilder.entity(Object entity, Annotation[] annotations) attaches more annotations to the entity in addition to the ones present on the invoked resource method
  • ContainerResponseContext.getEntityAnnotations() returns annotations present on the invoked response method and any annotations attached programmatically to the response entity via ResponseBuilder.entity(Object entity, Annotation[] annotations), or entity annotations set explicitly by a previous filter in the container response filter chain.


 Comments   
Comment by Marek Potociar [ 23/Jul/14 ]

Marking as a candidate to be fixed in 2.0.1 release.





[JAX_RS_SPEC-480] UriBuilder.fromPath implementation needs to enforce the relativity of the path Created: 07/Aug/14  Updated: 07/Aug/14  Resolved: 07/Aug/14

Status: Resolved
Project: jax-rs-spec
Component/s: model api
Affects Version/s: None
Fix Version/s: 2.0.1, 2.1

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Marek Potociar
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

UriBuilder.fromPath documentation states that a builder representing a relative URI is created. UriBuilder.fromPath delegates to a newly created UriBuilder.path() method whose documentation states that " Existing '/' characters are preserved".

So UriBuilder.fromPath("/a") would return a builder representing "/a" which does not qualify as a relative URI.

The same issue exists for UriBuilder.from(Class) and UriBuilder.from(Class, String) methods though in the latter case one can say that UriBuilder implementation can take care of dealing with Class or Method level Path annotations starting from "/". But ideally the spec code would deal with it



 Comments   
Comment by beryozkin_sergey [ 07/Aug/14 ]

Sorry for the noise, I should've checked first if URI "/a" is absolute or not





[JAX_RS_SPEC-423] Returning a reference to a mutable object value stored in one of the object's fields exposes the internal representation of the object Created: 05/Sep/13  Updated: 06/Aug/14  Resolved: 06/Aug/14

Status: Resolved
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: 2.0.1

Type: Bug Priority: Minor
Reporter: akilas Assignee: Marek Potociar
Resolution: Works as designed Votes: 0
Labels: 2.0.1-candidate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Returning a reference to a mutable object value stored in one of the object's fields exposes the internal representation of the object. If instances are accessed by untrusted code, and unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different. Returning a new copy of the object is better approach in many situations. These are the affected classes:

javax.ws.rs.client.Entity : 277
javax.ws.rs.core.NewCookie : 290
javax.ws.rs.core.NewCookie : 182
javax.ws.rs.core.NewCookie : 230



 Comments   
Comment by Marek Potociar [ 06/Aug/14 ]

Will not make the suggested changes - the overhead of creating new object instances is a lot greater than any potential risk associated with exposing internal mutable state in this case.





[JAX_RS_SPEC-478] JAX-RS 2.0 Client API must be able to provide OUTPUT and INPUT for custom HTTP methods Created: 06/Aug/14  Updated: 06/Aug/14

Status: Open
Project: jax-rs-spec
Component/s: client, spec
Affects Version/s: 2.0
Fix Version/s: None

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

Java SE 7, Java EE 7


Issue Links:
Blocks
blocks JAX_RS_SPEC-41 JAX-RS 2.0 Client API must be able to... Closed
Tags: 2_1, client_api, webdav

 Description   

The JAX-RS 2.0 API defines a Client API for accessing RESTful web services. As some of them are using non-standard HTTP verbs, like SEARCH in WebDAV, it is obvious that any implementation of the JAX-RS standard must be able to correctly (in the sense of the HTTP specification) handle such custom verbs. "Correctly" hereby means, to make no (not any) assumptions.

While this JIRA system already contains an accepted ticket that the JAX-RS 2.0 specification MUST clearly defined the Client API's transparency to custom verbs, latest tests proved that there are failing implementations - includig the RI, Jersey: The Jersey client fails to open an OUTPUT stream with the SEARCH verb, hence renders WebDAV to fail! While this might simply an implementation fault of the Jersey client (it doesn't force transparency of verbs but simply relies on the JRE), it is assumed that the Jersey authors failed to do so since possibly the enforcement of verb-transparency is not clear in any way ambiguous.

Hence, I am filing this additional ticket to improve the specification phrasing in an even more unambiguous and clear way makes finally absolutely clear to all implementors, that the Client API MUST be absolutely transparent w.r.t. custom verbs. This explicitly includes absolutely any assumptions whether a custom verb results in opening an INPUT or OUTPUT stream, is cacheable, is idempotent, or whatever different and unexpected sideeffect any internally used sub component might apply.

A custom verb MUST be allowed to open INPUT and OUTPUT streams. It MUST NOT be expected to be idempotent or cacheable unless otherwise declared by explicit use HTTP headers.



 Comments   
Comment by mkarg [ 06/Aug/14 ]

Extension and clarification to JAX_RS_SPEC-41.

Comment by mkarg [ 06/Aug/14 ]

I'd like to note that the Jersey client correctly processes SEARCH on JRE 8, while it fails on JRE 7. This is a proof that the Jersey client relies on undocumented lower level implementation details, hence does not transparently handle custom verbs. As said, this proofs that the specification is not clear enough – other wise the RI would not fail in this point.





[JAX_RS_SPEC-41] JAX-RS 2.0 Client API must be able to process custom HTTP methods Created: 02/Feb/11  Updated: 06/Aug/14  Resolved: 09/Jun/11

Status: Closed
Project: jax-rs-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0

Type: New Feature Priority: Critical
Reporter: mkarg Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: 0 minutes Remaining Estimate: 0 minutes
Σ Time Spent: 2 days Time Spent: 2 days
Σ Original Estimate: Not Specified Original Estimate: Not Specified
Environment:

WebDAV


Issue Links:
Blocks
is blocked by JAX_RS_SPEC-478 JAX-RS 2.0 Client API must be able to... Open
Dependency
depends on JAX_RS_SPEC-50 Low-level client API Resolved
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAX_RS_SPEC-74 Provide wording for javadoc as well a... Sub-task Closed mkarg  
Tags: 2_0, client_api, webdav

 Description   

JAX-RS 2.0 will standardize a client API for REST. Just as the server side of JAX-RS is extendable in multiple ways, extensibility of the client must be aligned at the same level. This includes the ability to execute methods other than the standard HTTP ones (GET, PUT, POST, DELETE etc.), especially common ones like those of WebDAV (PROPFIND, etc.) or PATCH.

To support this type of extension, it is necessary that the specification clearly mandates that an implementation of the JAX-RS 2.0 client API MUST NOT restrict the method names in any way, but that instead ANY possibly unknown or future method names MUST work.

The reason for this is that the typical implementations might rely on the Java SE class HttpURLConnection which is unable to process other methods thatn the standard HTTP ones, which leads to the fact that WebDAV and other extensions do not work. To enforce that any implementation of the client API is able to execute any kind of extension, the specification must contain clear words about the wanted behaviour.



 Comments   
Comment by mkarg [ 04/May/11 ]

To make absolutely clear to every implementor, the JavaDocs and / or Specification should say that the implementation MUST be able to process not only GET, HEAD etc. but also "strange" or "foreign" methods like PROPFIND and SEARCH.

The reason for that is: HttpClientConnection of the JRE also has a method to pass any name in, but its implementation does not execute neither PROPFIND not SEARCH. So having an API is not enough, but we must enforce that the implementation will be able to pass ANY string over the wire without checking it for anything! Without that, all the nice new methods are useless.

Comment by Marek Potociar [ 05/May/11 ]

Hi Markus,

Can you provide the initial proposal how the javadoc wording should be fixed and what the spec should state about this?
I have created a subtask for this issue to track the effort: JAX_RS_SPEC-74

Please, feel free to assign the task to yourself and provide the proposal.

Thanks,
Marek

Comment by Marek Potociar [ 09/Jun/11 ]

Fix delivered into the public repository.

Comment by mkarg [ 13/Aug/12 ]

Does this fix also solve http://java.net/jira/browse/JERSEY-1367 ?





[JAX_RS_SPEC-477] Supporting Streams API for bulk-processing of headers Created: 06/Aug/14  Updated: 06/Aug/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.1
Fix Version/s: None

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

Java SE 8, Java EE 8



 Description   

The JAX-RS API 2.0 defines the Headers interface to access a list of all provided request headers. Typically this form of mass-provision is utilized by some kind of filtering and / or iteration algorithm, since obviously nobody really needs literally all headers (including even potentially unknown custom headers).

With the rise of Java 8 in the incarnation of both, the current Java SE 8 and the future Java EE 8 platforms, Streams API is the typical means to code bulk processing. Java SE 8 for example was overhauled to provide streams to process lots of mass-content like in the Collections API. The resulting code is often more concise and better readable, also supports potentially parallel execution by usage of parallel streams.

As Java SE 8 might be very popular at time of JAX-RS 2.1 publication, and as Java EE 8 is assumed to demand JAX-RS 2.1 and Java SE 8 as core technologies, it would be wise and beneficial to define additional APIs which allow to directly produce streams for header batch-processing.

The following serves as a proposal to discuss:

Wherever bulk access on headers is used in JAX-RS 2.0 (like the Headers interface), there should be an additional, similar method defined producing a stream of headers. To illustrate this, the following API...

MultivaluedMap<String, String> Headers.getRequestHeaders()

...could get extended by the following API...

Stream<Map.Entry<String, Stream<String>>> Headers.getRequestHeaders()

...to simplify processing using the Streams API.

While it is clear that the following code is possible without streams...

for  (final Map.Entry<String, String> h: Headers.getRequestHeaders().entrySet())
  if (h.getKey().startsWith("X-OTRS") {
    final List<String> v = h.getValue();
    if (v.contains("XYZ")
      System.out.println(v);
  }

...it is obvious that the following stream processing looks more concise to readers familiar with the Stream API...

Headers.stream().filter(h -> h.getKey().startsWith("X-OTRS")).map(h -> h.getValue()).filter(v -> v.contains("XYZ")).forEach(s -> System.out::println)





[JAX_RS_SPEC-476] Supporting Lamda Expressions with asynchronous invocations Created: 06/Aug/14  Updated: 06/Aug/14

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.1
Fix Version/s: None

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

Java SE 8, Java EE 8



 Description   

The JAX-RS API 2.0 defines the InvocationCallback interface to specify reaction upon task termination, which includes either task completion or task failure.

With the rise of Java 8 in the incarnation of both, the current Java SE 8 and the future Java EE 8 platforms, Lambda expression are the typical means to express callbacks. Java SE 8 for example was overhauled to allow Lambda expressions as substitutes for lots of previous callback classes, like Runnable and Callable. Not only this made usage of those particular APIs more readible and consise, it also reduces the sheer number of classes to load at runtime.

As Java SE 8 might be very popular at time of JAX-RS 2.1 publication, and as Java EE 8 is assumed to demand JAX-RS 2.1 and Java SE 8 as core technologies, it would be wise and beneficial to define additional APIs which allow to provide two distinct Lambda expressions for processing task termination.

The following serves as a proposal to discuss:

Wherever the InvocationCallback<RESPONSE> is used in JAX-RS 2.0, there should be an additional, similar method defined accepting a type-sequence of Consumer<RESPONSE> (onCompletion) and Consumer<Throwable> (onFailure). To illustrate this, the following API...

AsyncInvoker.get(InvocationCallback<T> callback)

...should get extended by the following API...

AsyncInvoker.get(Consumer<T> onCompletion, Consumer<Throwable> onFailure)

...to support the use of Lambda expressions.

While it is clear that it is possible to simply write an anonymous class...

AsyncInvoker.get(new InvocationCallback() {
  public final void completed(final RESPONSE r) {
    System.out.println(r);
  }
  public final void failed(final Throwable t) {
    System.err.println(t);
  }
});

...it is obviously much more consise, easier to read, and potentially faster to execute at runtime, to instead write...

AsyncInvoker.get((r) -> System.out::println, (t) -> System.err::println);

...to get the rather exactly same reaction.






[JAX_RS_SPEC-422] Can't use Link.JaxbLink for unmarshalling Created: 29/Aug/13  Updated: 05/Aug/14  Resolved: 05/Aug/14

Status: Resolved
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: 2.0.1

Type: Bug Priority: Critical
Reporter: patriot1burke Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: 2.0.1-candidate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by JAX_RS_SPEC-446 Link.JaxbLink cannot be unmarshalled Resolved
Related
is related to JAX_RS_SPEC-475 Make Link.JaxbLink setters public Open

 Description   

The problem stems from a missing setter method in Link.JaxbLink

public void setUri(URI uri)

{ this.uri = uri; }

If you add that then unmarshalling works. Otherwise you'll always get a NULL URI.

I can fix this, but the problem is that I"ll then fail the TCK signature tests. Can this be challenged? I marked this as critical as this is something that would require a TCK challenge to fix.



 Comments   
Comment by patriot1burke [ 29/Aug/13 ]

Seems JAXB is ok with a private setter method. I'm pinging Lance to see if adding a private method is ok.

Comment by otrosien [ 17/Jan/14 ]

Is anyone looking into this? Is there a workaround?

Comment by Marek Potociar [ 23/Jul/14 ]

For 2.0.1 we will try to add a package private/private setters and then create a follow-up task to make the setters public in 2.1

Comment by Marek Potociar [ 05/Aug/14 ]

It seems that the setters do not need to be public. I have added package-private setters that should not break TCK signature tests. I'm going to close this one as resolved and I have opened a new JAX_RS_SPEC-475 follow-up task to make the setters public in 2.1.





[JAX_RS_SPEC-475] Make Link.JaxbLink setters public Created: 05/Aug/14  Updated: 05/Aug/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0.1
Fix Version/s: 2.1

Type: Improvement Priority: Major
Reporter: Marek Potociar Assignee: Marek Potociar
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAX_RS_SPEC-422 Can't use Link.JaxbLink for unmarshal... Resolved

 Description   

This is a follow-up for JAX_RS_SPEC-422.






[JAX_RS_SPEC-405] JAX-RS 2.0 Matching Algorithm may lose locators in some cases Created: 20/May/13  Updated: 31/Jul/14  Resolved: 31/Jul/14

Status: Resolved
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.0
Fix Version/s: 2.0.1

Type: Bug Priority: Major
Reporter: beryozkin_sergey Assignee: Marek Potociar
Resolution: Works as designed Votes: 0
Labels: 2.0.1-candidate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Given

GET /sub

and

@Path("/")
public class Resource {
   @POST
   @Path("{id}")
   public void post();

   @Path("sub")
   public Resource locator() {
   }

   @GET
   public void get();
   }
} 

Resource#get method will not be selected. This worked for JAX-RS 1.1



 Comments   
Comment by Marek Potociar [ 21/May/13 ]

I do not think this actually worked in JAX-RS 1.1. Please provide a step-by-step walk-through if you think otherwise.

Comment by beryozkin_sergey [ 23/May/13 ]

Marek - you were right after all, the example was not correct, copy and paste issue I guess. Fixing now, my apologies this time

Comment by Marek Potociar [ 23/Jul/14 ]

Hi Sergey, can we close the issue?

Comment by Marek Potociar [ 23/Jul/14 ]

Adding as a candidate for evaluation in 2.0.1 release timeframe.

Comment by Marek Potociar [ 31/Jul/14 ]

After a discussion with Santiago, we have concluded that the algorithm works as designed and that it we would not be addressing this issue. As such I am closing the issue.





[JAX_RS_SPEC-459] Typo in MediaType Javadoc Created: 24/Apr/14  Updated: 30/Jul/14  Resolved: 30/Jul/14

Status: Resolved
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.0
Fix Version/s: 2.0.1

Type: Bug Priority: Trivial
Reporter: cowwoc Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: 2.0.1-candidate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

All the MediaType Javadoc contain a comment like this:

A {@code String} constant representing "{@value #TEXT_HTML}" media type.

If you examine the resulting Javadoc you will notice the @value is quoted twice. To correct this, simply remove the quotes surrounding all @values.






[JAX_RS_SPEC-464] ResponseBuilder loses StatusType reason phrase Created: 03/Jun/14  Updated: 30/Jul/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: 2.1

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


 Description   

Response.StatusType has a getReasonPhrase method [1] which is not used by ResponseBuilder.status(StatusType) method. This issue was reported by a user who created a custom StatusType.

Here is a possible fix:

public ResponseBuilder status(StatusType status) {
            if (status == null) {
                throw new IllegalArgumentException();
            }
            ResponseBuilder rb = status(status.getStatusCode());
            if (status.getReasonPhrase() != null) {
                // let the user set a media type
                rb.entity(status.getReasonPhrase());
            }
            return rb; 
        }

[1] https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/core/Response.StatusType.html#getReasonPhrase()



 Comments   
Comment by Marek Potociar [ 30/Jul/14 ]

Unfortunately, this fix will not work because reason phrase is not part of HTTP Response message-body , but part of HTTP Response Status-Line (see RFC2616, sect. 6.1).

The only way to fix the issue would be to introduce a new abstract method in the ResponseBuilder, which is a change that would need to wait until JAX-RS 2.1 release (cannot be fixed as part of a 2.0.x bug-fix release).





[JAX_RS_SPEC-471] CacheControl.equals() and hashCode() implementation is broken because of cacheExtension field Created: 03/Jul/14  Updated: 30/Jul/14  Resolved: 30/Jul/14

Status: Resolved
Project: jax-rs-spec
Component/s: runtime
Affects Version/s: 2.0
Fix Version/s: 2.0.1

Type: Bug Priority: Major
Reporter: cowwoc Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: 2.0.1-candidate
Remaining Estimate: 30 minutes
Time Spent: Not Specified
Original Estimate: 30 minutes


 Description   

CacheControl.hashCode() and CacheControl.equals() return different values depending on whether this.cacheExtension is null or an empty map.

This means that the following code returns false:

CacheControl first = new CacheControl();
CacheControl second = new CacheControl();
second.getCacheExtension(); // trigger lazy initialization of field
return first.equals(second);

Lazy initialization of fields should not affect their value. equals() and hashcode() need to be fixed to return the same value whether the map is initialized or not (or just initialize it eagerly to begin with).



 Comments   
Comment by cowwoc [ 03/Jul/14 ]

Actually this problem is worse than I thought. All fields of type List are affected. This means fields privateFields, noCacheFields are also affected.

Comment by cowwoc [ 03/Jul/14 ]

Workaround: Run the following before comparing two CacheControl instances:

actualCacheControl.getCacheExtension();
actualCacheControl.getPrivateFields();
actualCacheControl.getNoCacheFields();
expectedCacheControl.getCacheExtension();
expectedCacheControl.getPrivateFields();
expectedCacheControl.getNoCacheFields();

Ugly, but it works.





[JAX_RS_SPEC-432] BufferedInputStream may not be closed in client/ext.FactoryFinder.find() Created: 18/Oct/13  Updated: 30/Jul/14  Resolved: 18/Oct/13

Status: Resolved
Project: jax-rs-spec
Component/s: client, runtime
Affects Version/s: 1.0, 1.1, 2.0
Fix Version/s: 2.0.1

Type: Bug Priority: Major
Reporter: Marek Potociar Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: 2.0.1-candidate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JERSEY-1850 InputStream not closed Resolved

 Description   

See JERSEY-1850.






[JAX_RS_SPEC-418] WebApplicationException should take StatusType Created: 23/Jul/13  Updated: 23/Jul/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: ice box

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


 Description   

WebApplicationException should take StatusType instead of Response.Status in it's constructors. This will allow to pass custom StatusTypes.



 Comments   
Comment by Libor Kramolis [ 01/Aug/13 ]

Moving it to JAX-RS JIRA project.





[JAX_RS_SPEC-446] Link.JaxbLink cannot be unmarshalled Created: 18/Feb/14  Updated: 23/Jul/14  Resolved: 23/Jul/14

Status: Resolved
Project: jax-rs-spec
Component/s: hypermedia
Affects Version/s: 2.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Michal Gajdos 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 JAX_RS_SPEC-422 Can't use Link.JaxbLink for unmarshal... Resolved

 Description   

Link.JaxbLink doesn't contain any setters and hence it cannot be unmarshalled using JAXB. Link.JaxbAdapter receives an object with null fields during unmarshalling.






[JAX_RS_SPEC-463] JAX-RS treats URLs with and without a trailing slash as equivalent Created: 16/May/14  Updated: 23/Jul/14

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.0
Fix Version/s: ice box

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


 Description   

In section 3.7.3 "Converting URI Templates to Regular Expressions" JAX-RS appends "(/.*)?" to the resulting regex, thus treating URLs with or without a trailing slash as equivalent.

This is a mistake. According to RFC 1808, section 4, step 6, the two URLs are not equivalent. As a result, relative paths resolve to a different URL depending on whether the URL contained a trailing slash or not. It is important to differentiate between the two and only match the address the user asks for. See http://stackoverflow.com/a/4765962/14731 for more information.

Ideally, users should be able to specify multiple @Path annotations (or one with multiple values) so that users who want to match URLs with or without a trailing slash can do so. Alternatively, allow users to specify a non-capturing regex so that UriBuilder doesn't treat it as a template parameter needing a value.



 Comments   
Comment by cowwoc [ 16/May/14 ]

To clarify, JAX-RS is matching a resource for a URL without a trailing slash (against my wishes). The resource returns an HTML response entity. The HTML, CSS, JS code then resolve paths relative to this incorrect URL and result in broken links.

We can certainly come up with server-side workarounds, but the fundamental fact remains that the two URLs are not equivalent and users should be able to configure a resource to only match a URL that ends with a slash, failing to match otherwise. Furthermore, failing to match and matching and then returning HTTP 404 is not the same thing because in the latter case a subsequent servlet filter may decide to match a URL that Jersey did not consume.

Comment by cowwoc [ 16/May/14 ]

One possible solution is to borrow the idea of regex non-capturing groups. (?:regex) matches a regular expression without defining a new group. Similarly, JAX-RS could allow {?:regex} to match a regular expression without defining a new template parameter. Users could then define precisely the regex that should be used, and JAX-RS would guarantee that the regex would not be modified (as is currently the case by appending (/.*)? to the end).





[JAX_RS_SPEC-420] Clarify the behavior of whether Client is thread-safe or not Created: 08/Aug/13  Updated: 23/Jul/14

Status: Open
Project: jax-rs-spec
Component/s: client
Affects Version/s: 2.0
Fix Version/s: 2.1

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


 Description   

Capturing the email discussion ...

While the spec is quiet about this, it's reasonable to expect that both Client and WebTarget instances should be thread-safe.

This is a good point - can you please file a new issue against JAX-RS-SPEC that we should clarify this?

Marek

On Jul 31, 2013, at 8:26 PM, Arun Gupta <Arun.p.Gupta@oracle.COM> wrote:

> Marek,
>
> Is the Client instance thread-safe ?
>
> Arun
>
> On 7/31/13 2:35 AM, Marek Potociar wrote:
>> Hi Arun,
>>
>> I guess it depends. Without any more context, I would make it application scoped.
>>
>> Thanks,
>> Marek
>>
>> On Jul 31, 2013, at 1:26 AM, Arun Gupta <arun.p.gupta@oracle.com> wrote:
>>
>>> For a bean like ...
>>>
>>> @Named
>>> @XXXScoped
>>> public class MovieClientBean implements Serializable {
>>>
>>> Client client;
>>> WebTarget target;
>>>
>>> @PostConstruct
>>> public void init()

{ >>> client = ClientBuilder.newClient(); >>> target = client >>> .target("http://localhost:8080/movieplex7/webresources/movie/"); >>> }

>>> }
>>>
>>> Should the scope be @RequestScoped or @ApplicationScoped (thread-safe ?) ?
>>>
>>> Arun






[JAX_RS_SPEC-473] Declarative HATEOAS support Created: 15/Jul/14  Updated: 15/Jul/14

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.0
Fix Version/s: 2.1

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


 Description   

With JAX-RS 2.0 initial support for HATEOAS was introduced with building Link headers (server side) and following them (client side).

With JAX-RS 2.1 this support should get improved by a declarative way of defining links. JAYWAY provided an idea how this could look like in an HATEOAS talk available on YouTube (https://www.youtube.com/watch?v=CcQE9481lMs) and I'd like to propose a discussion on their proposal for 2.1.

In a nutshell, the idea is to have a @Rel annoation which declares the relationship type (hence a potential link) to other resources within a resource class. An entity interceptor could use reflection to build link headers from that meta information and add these to the response.

As a result, no more dealing with .link() is needed on the server side when implementing a RMM Level 3 application, which makes the server sided code much cleaner and technology-free (pure application objects).






[JAX_RS_SPEC-469] Users should be able to add arbitrary values to Vary header Created: 02/Jul/14  Updated: 09/Jul/14

Status: Open
Project: jax-rs-spec
Component/s: runtime
Affects Version/s: 2.0
Fix Version/s: None

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


 Description   

Currently javax.ws.rs.core.Variant only supports 3 kinds of values:

  • encodings
  • languages
  • mediaType

But, according to http://tools.ietf.org/html/rfc7231#section-7.1.4 we should be able to pass arbitrary headers Vary. For example, one might want to specify Vary: Authorization. See http://stackoverflow.com/a/1701075/14731 for a use-case.



 Comments   
Comment by cowwoc [ 09/Jul/14 ]

http://webmasters.stackexchange.com/a/24452 discusses another use-case: Vary: Cookies





[JAX_RS_SPEC-472] Clarify if MBR/MBW should see annotations from interfaces and concrete classes Created: 04/Jul/14  Updated: 04/Jul/14

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Santiago Pericas-Geertsen
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Given


public interface RootInterface {
   @GET
   @Produces
   String get();
}

public class RootImpl implements RootInterface {
   @A
   String get();
}

should MBR and MBW see @GET + @Produces only or @GET + @Produces + @A where @A is a custom non-JAX-RS annotation ?

Proposal: update the Annotation Inheritance spec text accordingly, probably makes sense to avoid merging but I'm not sure

Thanks






[JAX_RS_SPEC-470] Clarify how default MessageBodyReaders should deal with concrete implementations of interfaces Created: 02/Jul/14  Updated: 02/Jul/14

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Santiago Pericas-Geertsen
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

We've had a user reporting an issue to do with CXF javax.activation.DataSource provider throwing an exception after a user typed 'javax.activation.FileDataSource' in the signature.

Given that the spec requires support for java.io.File it was easy to provide a support for javax.activation.FileDataSource OOB.

Now the user asks is it against the spec for a default provider to support a type not specifically mentioned in the spec.

IMHO the spec should clarify what MessageBodyReader supporting the interfaces required to be supported by the spec should do when it sees a concrete, well-known interface implementation.

Here are 3 proposed solutions:
1. Recommend that "Default MessageBodyReaders may support some concrete implementations" - the problem here is that we may have a portability issue between the implementations
2. Specify some of concrete implementations such as javax.activation.FileDataSource, and a couple of known JAXP Source classes.
3. Request that if concrete implementation class is typed in the method signature and it is different from the class MessageBodyReader uses to support a given interface then throw 500.

I think 3 may be reasonable - but may be we can relax it a bit with 2.






[JAX_RS_SPEC-468] Provide API support for HTTP 202 Created: 01/Jul/14  Updated: 01/Jul/14

Status: Open
Project: jax-rs-spec
Component/s: model api
Affects Version/s: None
Fix Version/s: 2.1

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


 Description   

HTTP 202 provides for the immediate response to the client.
We have a @Oneway annotation in Apache CXF which supports it.

It can be useful to JAX-RS developers to have something like:

@POST
@Accepted
// or @Oneway
@Consumes(...)
void ping(Ping ping) {...}

The @Accepted docs would say that a 'void' is expected and no @Produces is supported.






[JAX_RS_SPEC-466] Investigate the possibility of a single resource method supporting multiple HTTP verbs Created: 18/Jun/14  Updated: 18/Jun/14

Status: Open
Project: jax-rs-spec
Component/s: runtime
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Santiago Pericas-Geertsen
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This is probably a non starter, but I wonder, can we have something similar to what is possible with Servlet API where a single handler supports multiple methods ?
Now and then the users are asking, example, a user wanted to write a JAX-RS server proxying the calls. It may be handy to do:

@HttpVerbs("GET", "POST")
// or simply update the spec to allow listing @GET, @POST, etc on the a single method
public Response getOrPost() {
}

This won't change anything in the way resource methods are matched except the runtime will expect that a single method can handle few HTTP verbs.






[JAX_RS_SPEC-465] Provide for more predictability in the way filters or interceptors are ordered Created: 18/Jun/14  Updated: 18/Jun/14

Status: Open
Project: jax-rs-spec
Component/s: filters&handlers
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Marek Potociar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

At the moment filters or interceptors are ordered according to their priorities which are integer values.
The chance of interceptors interfering with one another is possible.
This is more of the issue with the filters/interceptors modifying the input stream: example, one handler wants to decrypt the stream, another - do something else, both are coming from different providers but we definitely want to run the decrypting interceptor first.

Perhaps we can introduce another key which can be used to group the interceptors more predictably






[JAX_RS_SPEC-462] Add support for HTTP client timeouts Created: 09/May/14  Updated: 09/May/14

Status: Open
Project: jax-rs-spec
Component/s: client
Affects Version/s: 2.0
Fix Version/s: None

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


 Description   

The spec should support HTTP client timeouts.

Example (ClientBuilder):

Client client = ClientBuilder.newBuilder()
    .property("javax.ws.rs.client.http.connectionTimeout", 1000)
    .property("javax.ws.rs.client.http.socketTimeout", 5000)
    .build();

– or –

Client client = ClientBuilder.newBuilder()
    .property(ClientProperties.CONNECTION_TIMEOUT, 1000)
    .property(ClientProperties.SOCKET_TIMEOUT, 5000)
    .build();

Jersey and RESTEasy support this feature in their vendor specific implementations.






[JAX_RS_SPEC-461] Clarification how to implement asynchronous resource methods which run on both, Java SE and Java EE. Created: 01/May/14  Updated: 01/May/14

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.0
Fix Version/s: 2.1

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


 Description   

The JAX-RS 2.0 specification introduces support for asynchronous resource methods. The examples in the specification show different implementation styles depending on the underlying platform: Java SE implies manual creation of an Executor, while Java EE (explicitly EJB) forbid that but enforces the use of an injected ManagedExecutorServer. This foils the WORA principle of Java. Hence, the specification should clarify how it is possible to write one single implementation which fits into SE and EE without code changes in the application / without providing Java EE libraries on a Java SE platform to declare a non-used injection point on Java SE.

As this is not a new feature but simply a clarification in the form of a joint EE / SE code example, I want to propose this issue to be part of JAX-RS 2.1 specification maintenance release.






[JAX_RS_SPEC-457] Alignment with WebSockets API: Encoders and Decoders Created: 29/Mar/14  Updated: 03/Apr/14

Status: Open
Project: jax-rs-spec
Component/s: providers
Affects Version/s: 2.0
Fix Version/s: 2.1

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


 Description   

Apparently the Java API for WebSockets provides converters for entities, named Encoders and Decoders. We should discuss whether it makes sense to support these in JAX-RS 2.1, as it is really strange for people to see that two APIs in Java do the rather same thing using different interfaces: Encoding and Decoding entities.



 Comments   
Comment by beryozkin_sergey [ 03/Apr/14 ]

I'm not sure it is realistic. I think WebSocket API is disconnected with JAX-RS API and it is a bit unfortunate, as JAX-RS users wishing to use WebSocket API will have to make the choice, as opposed to the possible SSE binding,

IMHO, it is more interesting to consider binding JAX-RS to WebSockets and standardizing on a binding, may be sometime after SSE effort if the requirements will be there. We've done it in CXF, where a regular JAX-RS resource can be used to receive or send the data to WebSockets clients using JAX-RS chains of filters/writers/readers

Sergey





[JAX_RS_SPEC-458] Container filter and interceptor contexts should return a list of binding annotations Created: 03/Apr/14  Updated: 03/Apr/14

Status: Open
Project: jax-rs-spec
Component/s: filters&handlers
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Marek Potociar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

We've had a user asking for supporting this case:

@A
public MyFilter implements ContainerRequestFilter {
 // needs to get an access to @A on the bound methods
}

@Path("root")
public MyRoot {

    @GET
    @Path("1")
    @A("1")
    public getIt1() {}

    @GET
    @Path("2")
    @A("2")
    public getIt2() {} 
}

So effectively @A is a conduit for passing parameters to the filter re what it needs to do on a per-method specific basis.

My answer was to inject ResourceInfo and proceed from there. This can work but might be tricky in some inheritance cases I guess and won't work if the filter was bound indirectly via Application having A("somevalue").

Perhaps we can have contexts having a new method introduced:
Annotation[] getBindingAnnotations().






[JAX_RS_SPEC-449] Introduce a typed version of StreamingOutput Created: 13/Mar/14  Updated: 25/Mar/14

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: None
Fix Version/s: 2.1

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


 Description   

Markus Karg typed a nice code prototype suggesting the use of java.util.Stream in scope of the possible support for SSE.
java.util.Stream is available in Java 8 and perhaps it won't map 1 to 1 to JAX-RS centric activities.

It would be very good for JAX-RS 2.1 API introduce a typed version of StreamingOutput, similar to java.util.Stream, such that it can be used
with or without SSE. Something like

interface StreamingResponse<T> {
   interface Writer<T> {
        void write(T);
        // may be useful in non SSE cases, 
        // to properly format the payload, example, to start/end the document with a root tag
        // OutputStream getEntityStream();
        
   }

   writeTo(Writer<T> stream);
}


 Comments   
Comment by beryozkin_sergey [ 25/Mar/14 ]

We have it working nicely in scope of binding WebSocket invocations to JAX-RS endpoints, but it will also make it much simpler to produce streaming responses without having to write into OutputStream all the time.

StreamingResponse provider implementation is straghtforward: it is implemented by asking the injected Providers context to find MBW and delegating to it.





[JAX_RS_SPEC-455] Clarification when JAX-RS engine has to close OutputStream provided to WriterInterceptor Created: 18/Mar/14  Updated: 18/Mar/14

Status: Open
Project: jax-rs-spec
Component/s: filters&handlers
Affects Version/s: 2.0
Fix Version/s: 2.1

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


 Description   

Please see RI bug https://java.net/jira/browse/JERSEY-2455 to understand impliciations.

The JavaDocs of WriterInterceptorContext.setOutputStream() says "The JAX-RS runtime is responsible for closing the output stream that is set.", but unfortunately does not mandate when that closing has to be performed. This leads to the problem described in JERSEY-2455. It is essential for programmers to know when this automatic close happens so they know whether they must manually workaround JERSEY-2455 by adding an explicit close(), or whether they can rely on the fact that a bug like JERSEY-2455 will never happen thanks to the TCK checking it!






[JAX_RS_SPEC-454] Simplify access to properties set in filters Created: 18/Mar/14  Updated: 18/Mar/14

Status: Open
Project: jax-rs-spec
Component/s: model api
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Marek Potociar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Right now, HttpServletRequest can be used to access properties set in the filters, while filters themselves can access HTTP servlet attributes indirectly via nice API. Ideally the same should be possible for the JAX-RS application code.
One option is to add a method to Request, another as suggested by Bill - introduce a new Context






[JAX_RS_SPEC-453] Querying the final mapping: Let dynamic filters know whether a method is mapped to a particular HTTP METHOD and URL Created: 15/Mar/14  Updated: 15/Mar/14

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.0
Fix Version/s: 2.1

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


 Description   

The JAX-RS 2.0 specification brings a very flexible way to configure dynamic filters so that they really only are applied to those methods which need to be really filtered. This makes implementing filters simpler and more concise.

There is one thing left open which a dynamic filter cannot solve so far: Replacing a method call in case the method is not implemented by the application. For example, I had to write a filter which answers @OPTIONS requests on the absolute URL "/" (the static "super root"!), but ONLY in case this is not already implemented by some real JAX-RS resource method. As the filter should be able to work with ANY JAX-RS application, at time of coding the filter it was not clear, when such methods will exist. Also apparently at time of writing a filter programmer cannot know at which root path an application might be linked later in case no @ApplicationPath is provided. AFAIK it is impossible to write such a filter yet in a simple way.

So I want to propose an addition to the JAX-RS API which makes it possible for dynamic filters to find out whether there exists a mapping for a particular absolute path and HTTP method combination.






[JAX_RS_SPEC-452] Support for WebSockets using java.util.stream.Stream<T> result type and @WebSockets annotation Created: 15/Mar/14  Updated: 15/Mar/14

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.0
Fix Version/s: 2.1

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


 Description   

REST over HTTP is client driven and stateless, as is the JAX-RS 2.0 API.

While this serves rather well for most cases, more and more there is a demand for asynchronous updates to recently received information, particularly using WebSockets. In addition, at time of GA of JAX-RS 2.1, Java SE 8 will be the current platform, with Java EE 8 being the next ambrella spec for JAX-RS. Java SE 8 provides a standard interface for typed asynchronous information streams in the package java.util.stream.

As WebSockets are simply and compatibly extending HTTP by a natural way to bring asynchronous updates to an HTTP enabled client, Stream<T> is the natural way to deliver the provided updates as Java objects to the receiving party. As a consequence, utilizing WebSockets is the first-class technology to implement asynchronous updates in a RESTful HTTP environment, and Stream<T> is the optimal interface to consume these.

As a consequence, it just makes sense to support the following combination:

@WebSockets
@GET
public java.util.stream.Stream<T> get() {
// Asynchronously provide T instances on demand
}






[JAX_RS_SPEC-451] Specification must clarify sequence of invocations for configure() and getProperties(). Created: 15/Mar/14  Updated: 15/Mar/14

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.0
Fix Version/s: 2.1

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


 Description   

Since JAX-RS 2.0 there is an API for sharing configuration properties among all registered features. The application and all features have the possibility to query and modify a shared set of properties, hence allowing an application to modify the behaviour of features, also allowing features to modify the behaviour of other features.

One problem which arises is the sequence when an application / any features are asked to modify the configuration. For example, an application A defines two features F1 and F2. F1 and F2 are provided by different vendors and don't know about the existence of each other, but solely know a shared property name. The application wants to modify the behaviour of F1. F1 wants in turn to modify the behaviour of the "unknown" F2 by setting a property. Hence, to make this example work, there must be some guarantee that A.getProperties() is invoked first, second must be F1.configure(), and F2.configure() must be last.

Currently the JAX-RS 2.0 specification, neither the PDF nor the JavaDocs, say anything about this sequence. In fact, it took even up to Jersey 2.7 to make the RI at least guarantee A comes before any F, but still Jersey 2.7 calls F1 and F2 in an apparently random sequence. So it currently is possible in Jersey to have A modify F1, but it is a vabanque play whether F1 will be able to modify the behaviour of an "unknown" F2.

BTW, this is a real-world example. F1 is a Feature, and F2 is an extention provided to F1. So while F2 knows F1 for sure, F1 does not know about the existence of F2. So this is not an academic discussion, it is a real problem.

Hence it is necessary that JAX-RS 2.1 defines (A) that A.getProperties() must be called before any F.configure() is called, and (B) that there must be a way to explicitly declare the sequence in which F1.configure() / F2.configure() is called (e. g. by using @Priority).






[JAX_RS_SPEC-450] Specification text and DefaultValue/Encoded docs should clarify where annotations have to be located on bean setters for them to be effective Created: 13/Mar/14  Updated: 13/Mar/14

Status: Open
Project: jax-rs-spec
Component/s: model api, spec
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Improvement Priority: Minor
Reporter: beryozkin_sergey Assignee: Santiago Pericas-Geertsen
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

We have a user request implying that the following is correct:
(1)

public class Root {
   @QueryParam("{id}")
   @A
   @B
   @Encoded 
   @DefaultValue("1")
   public void setId(String id) {}
}

as opposed to

(2)

public class Root {
   @QueryParam("{id}")
   public void setId(@A @B @Encoded @DefaultValue("1") String id) {}
}

It is not really obvious which version is right or if both versions are OK. JAX-RS @Encoded and @DefaultValue can target Methods but it is not obvious @A & @B can. For example, they may have been built originally with the idea that they would be applied to resource method parameters, which is often a typical case.

Specifically, the question came up in scope of discussing passing annotations to ParamConverterProvider on BeanParam setters.
In fact ParamConverterProvider documentation provides the only hint that it is really the option (2) which is correct, "E.g. if a string value is to be converted into a method parameter, this would be the annotations on that parameter as returned by Method.getParameterAnnotations()."

IMHO some further clarifications will help.






<

[JAX_RS_SPEC-448] The specification should recommend that Content-Type is defaulted to application/octet-stream at the start of the matching process Created: 13/Mar/14  Updated: 13/Mar/14

Status: Open
Project: jax-rs-spec