dev@jsr311.java.net

Re: jsr-303 alignment

From: Ryan McDonough <ryan_at_damnhandy.com>
Date: Fri, 7 Sep 2007 10:00:40 -0400

Actually Marc, I was modeling the idea form the EnityListener in the JPA. I
think both the javax.interceptor.* and EntityListener ideas work fairly well
and they could be applied to JAX-RS as well.

Ryan-

On 9/7/07, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
>
> Hmmm, the example below looks a lot like a specialization of
> javax.interceptor.*...
>
> Marc.
>
> On Sep 7, 2007, at 9:06 AM, Ryan McDonough wrote:
> >
> > I agree with Paul's comment that some of the validation logic could
> > be a bit
> > more complex and it would be best left in the value beans
> > themselves. Taking
> > that a little further, maybe we could provide a way to perform the
> > validation automatically through some type of callback mechanism.
> > Taking
> > Paul's example a little further with half-baked thought I had:
> >
> > @RequestListener({Jsr303ValidationListener.class})
> > class Something {
> >
> > @ValidateRequest(autoValidate=true)
> > public Response purchase(@UriParam("creditCard") CreditCard cc,
> > @UriParam("email") EMail email) {
> > ...
> >
> > }
> >
> > The ValidateRequest annotation could be used to declare that the
> > use wishes
> > to handle the the validation automagically by the listener.
> > In this instance, a listener is applied to method parameters before
> > the
> > method is called. If the beans are annotated with JSR-303
> > annotations, the
> > validation will be performed and some type of error response will be
> > generated by the listener. The messages used in the respose could
> > be pulled
> > from the JSR-303 annotations. When errors are found, the target
> > method is
> > never executed.
> >
> > Another nice thing about this that you wouldn't restricted to just
> > JSR-303
> > validation:
> >
> > @RequestListener({HibernateValidator.class})
> > class Something {
> >
> > @ValidateRequest(autoValidate=true)
> > public Response purchase(@UriParam("creditCard") CreditCard cc,
> > @UriParam("email") EMail email) {
> > ...
> >
> > }
> >
> > In this instance, we could plug in Hibernate's validation framework
> > instead,
> > or any other type of validation framework. Taking it even further,
> > we could
> > also apply Response listeners as well if needed. Thoughts?
> >
> > Ryan-
> >
> >
> > On 9/7/07, Paul Sandoz <Paul.Sandoz_at_sun.com > wrote:
> >>
> >> Hi Dhanji,
> >>
> >> Thanks for the example, that was very helpful.
> >>
> >> It is possible to do some validation with the current API:
> >>
> >> public Response purchase(@UriParam("creditCard") CreditCard cc,
> >> @UriParam("email") EMail email) {
> >> }
> >>
> >> the requirement is that CreditCard and Email have a constructor that
> >> takes a String parameter and throw a runtime exception if validation
> >> fails, the runtime exception can be caught and transformed into a 400
> >> (Bad Request).
> >>
> >> An implementation of the parameter injection can still validate all
> >> parameters even on the first failure, thus grouping errors.
> >>
> >> One advantage of 303 is that String can be used but it does seem more
> >> involved to invoke some bean checking rather than encapsulate
> >> functionality. I suppose the CreditCard and EMail could
> >> encapsulate 303
> >> functionality.
> >>
> >> Paul.
> >>
> >> Dhanji R. Prasanna wrote:
> >>> OK =)
> >>>
> >>> Here's something off the top of my head: you purchase an ebook
> >>> with a
> >>> credit card and email to deliver the ebook to. A webservice
> >>> invocation
> >>> sends the credit card number and delivery email to a JaxRs
> >>> application:
> >>>
> >>> @URITemplate("/eshop/books/{isbn}")
> >>> public class BookPurchaseService {
> >>>
> >>> @HttpMethod(POST)
> >>> public Response purchase(@Param("creditCard") String cc,
> >>> @Param("email") String email, /** ISBN, etc. **/) {
> >>> PurchaseOrder po = new PurchaseOrder(cc, email ...);
> >>>
> >>> //enter order...
> >>> purchasingBiz.processOrder (po);
> >>>
> >>> //respond with receipt number or failure code
> >>> }
> >>> }
> >>>
> >>> Now if the card # or email is invalid, your biz logic will fall over
> >>> with an exception. Typically you want to trap it before then to
> >>> give a
> >>> meaningful message back in to the client. With jsr303 you can do
> >>> something like the following:
> >>>
> >>> public class PurchaseOrder {
> >>> @Email(message = "invalid.email") private String email;
> >>> @CreditCard(message = "invalid.cc") private String cc;
> >>>
> >>> ...
> >>> }
> >>>
> >>> ...and correspondingly alter the http method:
> >>>
> >>> @HttpMethod(POST)
> >>> public Response purchase(@UriParam("creditCard") String cc,
> >>> @UriParam("email") String email) {
> >>> PurchaseOrder po = new PurchaseOrder(cc, email);
> >>>
> >>> //invoke jsr303 runtime aka BeanCheck
> >>> List<InvalidValue> errors = beanCheck.validate(po);
> >>>
> >>> if (errors.isEmpty())
> >>> //enter order...
> >>> purchasingBiz.processOrder(po);
> >>> else
> >>> //iterate errors and lookup the localized messages
> >>> to send
> >>> back (if necessary) to client
> >>> }
> >>>
> >>>
> >>> Dhanji.
> >>>
> >>> On 9/6/07, *Marc Hadley* < Marc.Hadley_at_sun.com
> >>> <mailto: Marc.Hadley_at_sun.com>> wrote:
> >>>
> >>> Me too, an example would be great.
> >>>
> >>> Marc.
> >>>
> >>> On Sep 5, 2007, at 5:01 PM, Ryan McDonough wrote:
> >>>
> >>>> +1 from me. I'm interested in seeing what you're thinking Dhanji.
> >>
> >>>>
> >>>> Ryan-
> >>>>
> >>>> On 9/5/07, Paul Sandoz <Paul.Sandoz_at_sun.com
> >>> <mailto: Paul.Sandoz_at_sun.com>> wrote:
> >>>>> Dhanji R. Prasanna wrote:
> >>>>>> An *initial* reaction suggests that we should leave this
> >> entirely
> >>>>>> to a
> >>>>>> user (bootstrap, validate, feedback error). However, since I
> >>>>>> recall Paul
> >>>>>> saying we want jsr311 to be a complete *usable* API it might be
> >>>>>> worth
> >>>>>> considering if/whether we want to integrate jsr303 in some
> >> (even
> >>>>>> optional) way. For instance, in the Response.Builder.
> >>>>>>
> >>>>>> I can explain a bit more about how bean validation in jsr303
> >>>>>> works if
> >>>>>> anyone is interested. Thoughts?
> >>>>>>
> >>>>>
> >>>>> IMHO it would be most helpful, at least to me!, to provide a
> >>>>> couple of
> >>>>> examples from the perspective of a 311 developer i.e. this will
> >> help
> >>>>> explain why 303 is useful and what benefits it offers before we
> >>>>> get into
> >>>>> the deeper technical aspects of how 303 works and determine
> >>>>> whether some
> >>>>> optional integration is required.
> >>>>>
> >>>>> Paul.
> >>>>>
> >>>>> --
> >>>>> | ? + ? = To question
> >>>>> ----------------\
> >>>>> Paul Sandoz
> >>>>> x38109
> >>>>> +33-4-76188109
> >>>>>
> >>>>>
> >>>
> >> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> >>> <mailto: dev-unsubscribe_at_jsr311.dev.java.net >
> >>>>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> >>> <mailto: dev-help_at_jsr311.dev.java.net >
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Ryan J. McDonough
> >>>> http://www.damnhandy.com
> >>>>
> >>>>
> >>>
> >> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> >>> <mailto:dev-unsubscribe_at_jsr311.dev.java.net>
> >>>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> >>> <mailto:dev-help_at_jsr311.dev.java.net>
> >>>>
> >>>
> >>> ---
> >>> Marc Hadley <marc.hadley at sun.com <http://sun.com >>
> >>> CTO Office, Sun Microsystems.
> >>>
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> >>> <mailto: dev-unsubscribe_at_jsr311.dev.java.net >
> >>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> >>> <mailto: dev-help_at_jsr311.dev.java.net >
> >>>
> >>>
> >>
> >> --
> >> | ? + ? = To question
> >> ----------------\
> >> Paul Sandoz
> >> x38109
> >> +33-4-76188109
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> >> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> >>
> >>
> >
> >
> > --
> > Ryan J. McDonough
> > http://www.damnhandy.com
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
>


-- 
Ryan J. McDonough
http://www.damnhandy.com