On Sep 7, 2007, at 10:00 AM, Ryan McDonough wrote:
> 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.
>
Right, we did discuss supporting a general interceptor capability
earlier but didn't really come up with any good use-cases that
couldn't be better met by other methods. Seems like validation might
a good use although, as Paul points out, a basic capability already
exists if validation doesn't require knowledge of all of a methods
arguments values.
On the 303 front, how is a class normally expected to access a
validator instance (beanCheck in Dhanji's example) ?
Marc.
> 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
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.