Fwd: SPI to add JAX-RS annotations dynamically
by Alessio Soldano
Forwarding to the list :-)
---------- Forwarded message ----------
From: Alessio Soldano <asoldano(a)redhat.com>
Date: Wed, Sep 27, 2017 at 10:24 PM
Subject: Re: [resteasy-dev] SPI to add JAX-RS annotations dynamically
To: Christian Kaltepoth <christian(a)kaltepoth.de>
Hi Christian,
On Wed, Sep 27, 2017 at 9:19 PM, Christian Kaltepoth <christian(a)kaltepoth.de
> wrote:
>
> sorry for the delayed response. I agree that if some SPI would allow to
> modify the builders, it should be done before the resource is registered in
> the resource factory. Do you think such a SPI would be useful for others?
>
Probably yes, but your scenario might even be enough to justify it.
I would be happy to contribute some code if it improves portability between
> RESTEasy and the MVC RI.
>
Sure, feel free to work on that and send a PR.
> Thanks for pointing me to the resteasy-cdi integration. I'll have a deeper
> look at it in the next days.
>
OK, good, I hope that can offer some idea for integrating.
Cheers
Alessio
7 years, 6 months
Extending Resteasy async support (server-side)
by Stephane Epardaud
Hi,
I'm working on trying to make Resteasy and Vertx integrate better, and
while writing a prototype I noticed several things which would need
support from Resteasy.
The first thing which I need RE to support is that I want to be able to
return async types from my resource methods. In JAX-RS 2.0 async
resource methods are supported but require a peculiar style, such as
taking a "@Suspended AsyncResponse asyncResponse" parameter, returning
void, and resuming with asyncResponse.resume(entityOrException).
I know JAX-RS 2.1 supports CompletionStage<Response>. This is great, but
it doesn't define a pluggable API to support other types such as rxJava.
We should really make that be pluggable, so that I can use rx.Single or
other async frameworks.
ATM I have a prototype which supports CompletionStage and rx.Single,
without modifying RE, but it's using CDI validators to intercept the
returned value and do the plugging, which is a terrible hack. I couldn't
find a way to do this properly with RE because I can't intercept the
returned value before it's sent to the marshallers, by which time it's
too late to mark the response as async and register on the listeners.
Now, because the return type is CompletionStage<X> (or rx.Single<X>
doesn't matter), the ResourceMethodInvoker.getGenericReturnType()
returns a very unhelpful type, which I can't used to look up the proper
marshallers, so again this is something that has to be taken into account.
Sometimes I will declare a return type of CompletionStage<Object>
because Java doesn't have Union Types and I can't declare it as
CompletionStage<Response | MyEntity>, and in that case I have to look up
marshallers based on the entity instance's class rather than the
declared type. I suppose the same applies to non-async return types. Is
it the spec that fixes this looking up of marshallers based on the
static return type and not the entity's actual type?
Now, I haven't said much about things like Observable or Flowable (async
types that emit more than one value), because it's not yet clear in my
mind how that would work with RE. In my proto I do support returning
such flows and based on how the method is annotated, RE will pick one
strategy:
- collect all values in a java.util.List and when all done proceed,
- send them as HTTP Chunked: marshall and send each value as they are
made available
- send them as server-sent events but that's a bit weird when it's not
plain text
Since JAX-RS 2.1 supports server-sent events, that would also be a
strategy that makes sense.
I have contacted the CDI team to discuss async injection, because I also
want to be able to inject instances of X in my resources where there
only exists providers of type CompletionStage<X>, which requires a new
CDI API to support async resource instantiation/injection. If/when that
gets added to CDI, RE will need to be updated to support this async
injection.
Similarly I also have a problem with interceptors, because sometimes my
RE interceptors require resolving of async types before they can go on
with the request. For example for authentication or sessions my
interceptors have to wait for vert.x to resolve async values before I
can check them and proceed with the requests. The wait the interceptor
API is written doesn't let me suspend interception. It's be great if it
could. Alternately CDI interceptors have an InvocationContext parameter
given to the interceptor on which you have to call proceed() in order to
proceed. This allows me to delay proceeding until I have all my async
values resolved and only then proceed with the call to the next
interceptor. That'd work too.
And I guess the same applies to Marshallers. I have Template entity
objects that I need to marshall and that is done via an async API in
vertx, so again I can't entirely marshall the response when the
marshaller is called.
Last, and least interestingly, I've always been bitten by the fact that
ExceptionMappers are global and I can't override them per resource.
Sometimes I have UI/HTML resources that need exception mappers that
forward to UI pages, and API resources that have to serialise errors
into JSON. I've added support for an @WithExceptionMapper(Class<?
extends ExceptionMapper>) annotation that you can place on the resource
method or class to override the error mapper for this call.
WDYT?
I'm definitly game for pushing PRs for those things, BTW.
How far along are you guys with implementing JAX-RS 2.1 in RE?
Cheers.
8 years
SPI to add JAX-RS annotations dynamically
by Christian Kaltepoth
Hi,
My name is Christian Kaltepoth and I'm specification lead of JSR 371 (MVC
1.0). As you may know, JSR 371 is about creating an action-based web
framework on top of JAX-RS.
The reference implementation of JSR 371 was previously only targeted to
support Jersey. But we want to change that. Therefore, we are currently
looking for ways to integrate with other JAX-RS implementations.
Unfortunately there are certain features which cannot be implemented using
the plain JAX-RS API. That's why we are also looking into using JAX-RS
implementation specific SPIs.
One thing we are currently working on is the following requirement: MVC
controllers (which are just special CDI-based JAX-RS resources) should be
treated as if they are annotated with @Produces("text/html) without the
need to add the annotation manually. The current draft of the specification
states:
*The semantics of controller methods differ slightly from JAX-RS resource
> methods; [...] Moreover, the default media type for a response is assumed
> to be text/html , but otherwise can be declared using @Produces just like
> in JAX-RS.*
Jersey provides a special SPI which allows us to hook into the metadata for
JAX-RS resources:
https://github.com/jersey/jersey/blob/master/core-server/src/main/java/org/
glassfish/jersey/server/model/ModelProcessor.java#L75
Is there anything like that in RESTEasy? I looked into the code but
unfortunately didn't find anything like that.
Christian
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
8 years
Re: [resteasy-dev] SSE client
by Stephane Epardaud
On 04/09/17 07:59, Jim Ma wrote:
> On 09/02/2017 12:04 AM, Stephane Epardaud wrote:
>>
>> Sorta related: you add a newline at the end of the data read via SSE
>> in the client, but that's not correct: the NL should only be added if
>> you have more than one 'data' field after another.
>>
> From https://html.spec.whatwg.org/#processField, the line feed is
> always added to data buffer. But now sse client missed this step the
> remove the last character from if it is a LF.
Yes, true. But the effect is the same in that users end up with one LF
too many ;)
>>
>> And similarly, you should really do some escaping when serialising
>> SSE data, because \n and \r are special chars. I'm pretty sure as it
>> is, it's not valid SSE.
>>
> Should we escape these character ? Or we need to write another data
> field when meet these chars ?
Well, this spec has no escaping, that I can find. But yes if we do meet
a LF (or any other allowed terminator, because I'm not sure LF is the
only one), we should start a new `data: ` line. This will at least
deserialise properly on the other end.
8 years
Fwd: Programmatic resource configuration
by Alessio Soldano
Forwarding to the list, I erroneously answered Ron only.
---------- Forwarded message ----------
From: Alessio Soldano <asoldano(a)redhat.com>
Date: Mon, Aug 28, 2017 at 9:49 AM
Subject: Re: [resteasy-dev] Programmatic resource configuration
To: Ron Sigal <rsigal(a)redhat.com>
On Sat, Aug 26, 2017 at 11:36 PM, Ron Sigal <rsigal(a)redhat.com> wrote:
> I don't remember any such thing, but that's not especially probative.
>
> It sounds like a nice feature to advertise for Resteasy 4.0. Do you think
> there's much of a demand, beyond the one person?
>
Well, difficult to say, but I also think this would be a very nice feature.
I've created a JIRA anyway :-) https://issues.jboss.org/browse/RESTEASY-1707
Cheers
Alessio
> I see that I was pretty busy in 2012. ;-)
>
> On 08/17/2017 04:56 AM, Alessio Soldano wrote:
>
> Hi,
> yesterday I've been contacted by a colleague asking for a way to
> programmatically setup a JAX-RS resource in RESTEasy. By googling a bit, I
> found [1], which seems to basically document the last two commits at [2].
> That code is now 5+ yrs old, does anybody remember if a PR for adding such
> feature was ever opened / evaluated?
> Cheers
> Alessio
>
> [1] https://gist.github.com/danbev/3938238
> [2] https://github.com/danbev/Resteasy/commits/programmatic-config
>
>
> _______________________________________________
> resteasy-dev mailing listresteasy-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/resteasy-dev
>
>
> --
> My company's smarter than your company (unless you work for Red Hat)
>
>
> _______________________________________________
> resteasy-dev mailing list
> resteasy-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/resteasy-dev
>
>
8 years
SSE client
by Stephane Epardaud
Hi,
What's the purpose of SseEventSource.register(... Runnable onComplete) ?
It doesn't appear to ever be called, and even if the server closes the
connection, it doesn't get called because the client reconnects forever
(which is _not_ what I was expecting at all).
8 years, 1 month