Hi Ryan,
I could see that such a validation approach would be useful if
parameters need to be evaluated as a whole e.g. if x is true then y must
be present, which sort of gets into application semantics so maybe it is
not appropriate?
Maybe i am missing something but if we only need to keep validation
focused on the parameters then I am not sure we need such functionality
since it could be kept local to CreditCard or EMail beans instead:
public class CreditCard {
// Annotated?
private String v;
public CreditCard(String s) {
// Hook in your favorite validation framework here
}
public String getValue() { return v; }
public String toString() { return v; }
}
Paul.
Ryan McDonough wrote:
> 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
> <mailto: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>
> > <mailto: 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>
> > <mailto: 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>
> > <mailto: 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>
> > <mailto: dev-help_at_jsr311.dev.java.net
> <mailto:dev-help_at_jsr311.dev.java.net>>
> > >>
> > >>
> > >
> > >
> > > --
> > > Ryan J. McDonough
> > > http://www.damnhandy.com <http://www.damnhandy.com>
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> dev-unsubscribe_at_jsr311.dev.java.net
> <mailto:dev-unsubscribe_at_jsr311.dev.java.net>
> > <mailto: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>
> > <mailto: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>
> <http://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>
> > <mailto: 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>
> > <mailto: 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
> <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 question
----------------\
Paul Sandoz
x38109
+33-4-76188109