The UriInfo should be available during a request/response cycle. Basically an object is injected that looks up the "real" ThreadLocal UriInfo instance at runtime.
All of the @Context injectable interfaces should be available to you. Most of this is discussed in the JAX-RS spec which is relatively short. I would also check out the JavaDocs for the JAX-RS packages (javax.ws.rs.*). On Sep 19, 2011, at 4:13 PM, Ron wrote: > Oh wow, that sounds incredible! > It also seems to be a JAX-RS implementation agnostic solution! > > Are you sure the UriInfo will be available at that stage and not be prepared > only after the readFrom(..) call? > I'm having a hard time finding a description of the life-cycle of a REST > request in the JAX-RS architecture. > > Also, if it's not too much to ask, can you please tell me if and where I > could have found out about this option on my own? I appreciate the help, but > if I can learn those things on my own, I'd spam the mailing list less :) > > Again, thanks again for the help. It's really priceless. > > On Mon, Sep 19, 2011 at 23:49, Bryant Luk <[email protected]> wrote: > Hi Ron, > > I think you want to add an instance variable like > > public class MyMBR implements MessageBodyReader<MyEntityType> { > @Context > javax.ws.rs.core.UriInfo uriInfo; > > public MyEntityType readFrom(....) { > // uriInfo.getPath() or getPathParameters() > } > > } > > On Mon, Sep 19, 2011 at 3:40 PM, Ron <[email protected]> wrote: > > Bryant, > > > > Thank you for pointing me to that direction. That lead me to do some > > investigation about Jackson and apparently, combining the answers I got from > > there and here, I'm about half-way through the solution. > > > > However, in order to fully use this method, I'd need to have the parsed URL, > > as that would hold the id of the entity I'd want to load from the database. > > > > I realize readFrom gives me the HTTP headers as a parameter and I could > > parse the URL on my own from there, but that seems to be a bit of an > > over-work the next step in the REST invocation is just that parsing (so that > > the engine knows which method to call and which parameters to inject). > > > > Is there a way to utilize the URL parsing in that stage in any way? > > > > Thanks again for the help, > > Ron > > > > On Mon, Sep 19, 2011 at 01:02, Bryant Luk <[email protected]> wrote: > >> > >> You can create your own JAX-RS MessageBodyReader if you want. You can do > >> the entity lookup and return the newly created entity in the readFrom > >> method. This is the standard way of doing it in JAX-RS. To create the > >> MessageBodyReader, you can either extend an existing JSON > >> MessageBodyReader, > >> write your own JSON parser, or use a @Context Providers to lookup a generic > >> JAX-RS JSON that's active in the system. > >> > >> On Sep 18, 2011, at 5:13 AM, Ron wrote: > >> > >> > Hi everyone, > >> > > >> > I hope this haven't been asked and answered before - I wasn't sure > >> > exactly what to look for. > >> > > >> > Brief description of our architecture: > >> > We have an entity-management Spring-based system. The system consisted > >> > of several entities - all JAXB annotated. Those entities are used both > >> > with our DB ORM framework and by our REST API implementation. The > >> > entities are sent to the REST API in JSON format. > >> > > >> > Currently, when the client invoke an API call, it needs to send the > >> > whole JSON/entity. > >> > For example, assume the following API declaration: > >> > > >> > @PUT > >> > @Path("/entity") > >> > @Consumes({MediaType.APPLICATION_JSON}) > >> > public void updateEntity(FooEntity fooEntity) { ... } > >> > > >> > What I'd like to do is allow the client to send only parts of the > >> > entity, and somehow add a hook before the actual updateEntity(...) > >> > invocation. In that hook, I would read the actual entity from the > >> > database (or whichever source), and modify only the fields received > >> > from the client, and only then invoke the updateEntity(...) with the > >> > newly created entity. I would probably want to put some extra > >> > security-checks logic in that hook. > >> > > >> > Is there any way to do it? If there's more than one way, I'd like to > >> > hear the options out there (with pros and cons if willing). > >> > > >> > Thanks, > >> > Ron > >> > > > > >
