While I do think there is a place for JSR-303 functionality in JAX-RS, I'm
having trouble seeing if there is anything that needs to be added in order
support it. From the examples that have been shown so far, the validation is
done in conjunction with with JAX-RS rather than some JAX-RS specific
integration point. And going forward, this could be the simplest way to
address the integration.
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