Christian Kaltepoth

Feel free to provide a pull request for this. :-) But please note that such a change may also require changes to the spec document, the TCK and maybe even...

I don't know about the details. But it wasn't actually "removed". It just wasn't part of the new JAX-RS API which was defined back then and which was heavily inspired...

I don't think that we need "custom cookie types", but "custom cookie attributes". And this could be achieved by adding a list of "custom attributes" to the `NewCookie` class. Something...

I'm also +1 for this. But I agree with @mkarg, that the incompatibilities between `@Context` and `@Inject` mentioned by @spericas should be discussed in detail.

@spericas To be honest, I'm surprised to hear that using `@Context` on parameters is a popular choice. I actually never saw this in any JAX-RS code. Of course `@*Param` usually...

@arjantijms > HttpServletRequest and ServletContext are already injectable via @Inject (built-in CDI beans). To make the others injectable should only be a matter of shipping a CDI extension that produces...

> Interesting. If that happens after the JAX-RS Servlet is called then the Servlet implementation wouldn't know about them. Correct. I don't remember all the details anymore, but if you...

> Is is intended by the Servlet spec that you have a way to access the original request? Using the original request can be problematic as the request might have...

@ggam Thanks for the summary. I would actually prefer the second option. IMO injecting a proxied view should be the default. Not sure if we really need the `Supplier` version...

I guess your example could be fixed by adding `.toArray()`, or am I missing something? ```java UriBuilder.fromUri(baseUri) .queryParam("search", searchParameterValue.toArray()) .build(); ```