January 2019 - resteasy-dev - Jboss List Archives

How to make (java) method available from ClientRequestContext?

by Michal Szynkiewicz

Hi, MicroProfile Rest Client 1.2 requires that the method that is handling the request is available under a specific key in the ClientRequestContext [1]. I've been struggling to find an elegant way of implementing it in SmallRye. Currently, I have it working with a filter and digging out the ClientInvocation from ClientRequestContextImpl [2] but would rather not use reflection for that. Could you give me some tip how to implement it better, if possible? Thanks, Michał [1] https://github.com/eclipse/microprofile-rest-client/blob/857ce67949a1e846... [2] https://github.com/michalszynkiewicz/smallrye-rest-client/blob/99e05e9793...

5 years, 10 months

3
4
0 / 0

Injecting HttpHeaders into ClientRequestFilter (with @Context)

by Michal Szynkiewicz

Hi, The MP Rest Client 1.2 TCK assumes the ${subject} should be possible but I'm getting "RESTEASY003880: Unable to find contextual data of type: javax.ws.rs.core.HttpHeaders" when I try. I think it's possible to add an implementation of HttpHeaders to ResteasyProviderFactory.getContextDataMap(), and then make the headers from it populated to the request with a filter but is there a better way? Maybe some add-on that would make it work out of the box? ;) Thanks, Michał

5 years, 10 months

2
2
0 / 0

Question about how we do injections

by Ron Sigal

I've been looking at an old issue, RESTEASY-1709 "Same JAX-RS Provider instance injected across applications", which I thought I had solved by injecting a javassist created proxy, but the reporter couldn't get it to work so it's been sitting for almost a year. Anyway, I've been trying to port the old code to master, and I see that injection has changed to do a lot of stuff with CompletableFutures. In particular, a series of injections into, say, a resource, becomes a composition of CompletionStages, each one doing a single injection. I'm trying to understand why. One reason I can see is that, at least in the case of an asynchronous invocation, you want to do as little as possible before returning a CompletableFuture. That would provide better responsiveness. But I have two questions: 1. Is constructing a CompletableFuture that much faster than just doing the injection? 2. I don't how much space a CompletableFuture takes, but we've turned a simple loop into a collection of CompletableFutures, which would seem to occupy more space. Isn't that counterproductive in terms of our general mandate to create a smaller footprint for container applications? I'm not saying that the new code is wrong. I'm just saying that I don't understand why it's right. Any thoughts? -- My company's smarter than your company (unless you work for Red Hat)

5 years, 11 months

2
1
0 / 0

Multiple Applications in a WAR

by Ron Sigal

There is a discussion on the jaxrs-dev mailing list about having multiple Application objects in a single WAR. Does anyone know of any real world use cases for that? -Ron -- My company's smarter than your company (unless you work for Red Hat)

5 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

resteasy-dev January 2019