Return-Path: X-Original-To: apmail-incubator-wink-user-archive@minotaur.apache.org Delivered-To: apmail-incubator-wink-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6AA3A9A77 for ; Tue, 20 Sep 2011 01:57:18 +0000 (UTC) Received: (qmail 70455 invoked by uid 500); 20 Sep 2011 01:57:18 -0000 Delivered-To: apmail-incubator-wink-user-archive@incubator.apache.org Received: (qmail 70419 invoked by uid 500); 20 Sep 2011 01:57:18 -0000 Mailing-List: contact wink-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: wink-user@incubator.apache.org Delivered-To: mailing list wink-user@incubator.apache.org Received: (qmail 70411 invoked by uid 99); 20 Sep 2011 01:57:18 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Sep 2011 01:57:18 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of bryant.luk@gmail.com designates 209.85.213.47 as permitted sender) Received: from [209.85.213.47] (HELO mail-yw0-f47.google.com) (209.85.213.47) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Sep 2011 01:57:08 +0000 Received: by ywf7 with SMTP id 7so142352ywf.6 for ; Mon, 19 Sep 2011 18:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; bh=8VaX1BGfLgqhFJd2Gn7eDYQjoJ8oSo0S7yMSTFbL1jo=; b=C9NmH+FReKn8J16UjaAyQL9ByydRE8QcwXET911q2leUem61SUlsAljWwrqV/EgZ+5 Ny+apI47AGblPx7G3JCBmXrDWnMA3/UE1yLMw9rPh/d4J0aO0o84qAbu6qEpjhPGbGbt R/5afAi8bA/JN5+lvAf/jVP9UKTTym60z/AKs= Received: by 10.150.57.17 with SMTP id f17mr128800yba.398.1316483807846; Mon, 19 Sep 2011 18:56:47 -0700 (PDT) Received: from [10.0.1.56] (cpe-66-68-20-129.austin.res.rr.com. [66.68.20.129]) by mx.google.com with ESMTPS id t10sm6824066anl.26.2011.09.19.18.56.45 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Sep 2011 18:56:46 -0700 (PDT) From: Bryant Luk Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_07FA64F6-D344-4D82-9141-84E959E3ECAE" Subject: Re: Entity Manipulation Prior to REST Implementation Call Date: Mon, 19 Sep 2011 20:56:46 -0500 In-Reply-To: To: wink-user@incubator.apache.org References: <71578A23-3B13-4380-BE6F-745538BCB6CD@gmail.com> Message-Id: <51E0F4A0-F40B-4B46-92EF-879BC68852A4@gmail.com> X-Mailer: Apple Mail (2.1244.3) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_07FA64F6-D344-4D82-9141-84E959E3ECAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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! >=20 > 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. >=20 > 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 :) >=20 > Again, thanks again for the help. It's really priceless. >=20 > On Mon, Sep 19, 2011 at 23:49, Bryant Luk = wrote: > Hi Ron, >=20 > I think you want to add an instance variable like >=20 > public class MyMBR implements MessageBodyReader { > @Context > javax.ws.rs.core.UriInfo uriInfo; >=20 > public MyEntityType readFrom(....) { > // uriInfo.getPath() or getPathParameters() > } >=20 > } >=20 > On Mon, Sep 19, 2011 at 3:40 PM, Ron 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 read=46rom 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 = 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 > >> > > > > >=20 --Apple-Mail=_07FA64F6-D344-4D82-9141-84E959E3ECAE Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii 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 <bryant.luk@gmail.com> 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 <webron@gmail.com> 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 <bryant.luk@gmail.com> 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
>>
>
>


--Apple-Mail=_07FA64F6-D344-4D82-9141-84E959E3ECAE--