Proposal for method validation on beanvalidation.org
by Gunnar Morling
Hi all,
I've pushed now a first version of the proposal for method validation
(BV-241) to beanvalidation.org [1].
The proposal is still missing some parts (e.g. the XML configuration),
but I hope it touches all major issues related to method validation.
Throughout the document I've used the "DISCUSSION" marker for sections
which still need further consideration or a decision between several
possible options.
I'd be very happy on any feedback related to these issues in
particular but of course also to the complete proposal in general.
Don't hesitate to speak up in case you think anything is incomplete,
is missing or something doesn't make sense to you; after all this is
very much work in progress. Feel free to add remarks in place within
the document or start a dedicated discussion on the mailing list.
--Gunnar
[1] http://beanvalidation.org/proposals/BVAL-241/
14 years
Re: [bv-dev] Triggering method validation
by Gunnar Morling
That's a good point.
The proposal currently suggests to redefine BeanDescriptor#isConstrained()
to let it return true also if there are any method level constraints.
Another idea would be to leave it as is and add another method such as
isMethodConstrained(), slightly simplifying your use case.
I think I actually would like that better. WDYT?
Am 30.01.2012 09:47 schrieb "Emmanuel Bernard" <emmanuel(a)hibernate.org>:
14 years, 1 month
Triggering method validation
by Gunnar Morling
Hi experts,
I'm in the middle of writing a proposal document for BVAL-241 (method
validation), which I'm planning to put up for discussion within the
next days.
One item for which I'd like to gather some feedback beforehand is how
to trigger method validation. I think we all agree that BV itself
should only provide the API and meta-model for method validation, but
it shouldn't actually trigger a validation of method level
constraints.
Instead this should be task of technologies integrating the method
validation feature to decide whether a validation is needed or not and
if so delegate that validation to BV.
The following options were mentioned at some time:
#1 Use @Valid
This would be semantically wrong IMO. @Valid is only a marker for
cascaded validation, but it shouldn't cause a validation itself.
#2 Define an annotation such as @javax.validation.ValidateGroups within BV
@ValidateGroups({Group1.class, Group2.class})
public class OrderService {
@NotNull
public Order placeOrder((a)NotNull(groups=Group1.class) @Size(min=3,
max=20) String customerCode, @NotNull Item item, @Min(1) int quantity)
{ //... }
}
This annotation could be discovered by interceptors/proxies etc. which
then would trigger a validation of the method constraints. The method
could be defined on a class level as well as on method level (with the
latter having precedence in case of conflicts).
We could surely define such an annotation and specify it semantics,
but I'm unsure how that would actually work out with technologies
using that feature. Taking CDI for example, AFAIK the annotation would
have to be annotated with the @InterceptorBinding meta annotation. I
don't know whether/how it would be possible that we define the "basic"
annotation, while integrators "enrich" it with the meta data they
require.
#3 Don't define anything related in BV, leave that completely to integrators
CDI could define a proper interceptor binding annotation, others could
use some XML based configuration etc.
Personally I think we could go for #2 and define an annotation to be
used by integrators (e.g. by checking for the annotation, Spring might
define a related point cut etc.). We would recommend to trigger
validation based on this annotation where possible and hopeful would
cover most cases that way. Integrators would still be free to define
their own means of triggering a validation if required.
Any thoughts? Are there any other alternatives?
--Gunnar
14 years, 1 month
Re: [bv-dev] Priority list
by Edward Burns
>>>>> On Mon, 26 Sep 2011 19:42:31 +0200, Emmanuel Bernard <emmanuel(a)hibernate.org> said:
EB> That being said, we can categorize issues in 4 circles:
EB> - must have
EB> - should have
I'd like to have <https://hibernate.onjira.com/browse/BVAL-250> in
there.
If no ValidationMessages.properties file, perhaps fall back to
consulting whatever ends up beind the value of the <message-bundle>
config value.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
14 years, 1 month
Re: [bv-dev] Triggering method validation
by Edward Burns
>>>>> On Fri, 27 Jan 2012 14:37:50 +0100, Gunnar Morling <gunnar.morling(a)googlemail.com> said:
>> imo we should also talk with other expert-groups about the basic idea.
GM> Absolutely. Emmanuel/I had already some discussions with folks from the CDI
GM> and JAX-RS EGs.
GM> JSF is definitely a good point, I hadn't considered that so far. Do you
GM> know who would be good to talk to?
I'd like to have Gerhard introduce the topic over there and we can
discuss it there as a group, but I'm the spec lead if you need a name.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
14 years, 1 month
Re: [bv-dev] Triggering method validation
by Edward Burns
>>>>> On Fri, 27 Jan 2012 12:53:43 +0100, Gerhard Petracek <gerhard.petracek(a)gmail.com> said:
GP> hi @ all,
GP> imo we should also talk with other expert-groups about the basic idea.
GP> e.g. the jsf-eg (i'm going to propose group-validation triggered via
GP> command components (based on a feature of myfaces extval) and maybe they
GP> have additional ideas related to this topic.)
I'd love to discuss it over there!
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
14 years, 1 month
Ctor Validation
by Edward Burns
>>>>> On Thu, 1 Dec 2011 21:34:23 +0100, Gunnar Morling <gunnar.morling(a)googlemail.com> said:
GM> I see your point. I think we should only provide the API for this. How
GM> or for which objects constructor validation is enabled should be
GM> decided by users and/or solutions integrating with BV from my point of
GM> view.
>>>>> On Thu, 1 Dec 2011 23:53:29 +0100, Emmanuel Bernard <emmanuel(a)hibernate.org> said:
EB> Yes. That concerns me a bit to be honest especially when more
EB> technologies will offer BV integrations. We need to think this
EB> through before opening pandora's box even more :)
I'm familiar with the difficulties of tackling pandora's box type
issues, and my vote would be to simply not open it during this release,
instead, focusing on resolving the method level validation issue.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
14 years, 1 month
Re: [bv-dev] Triggering method validation
by Gunnar Morling
> imo we should also talk with other expert-groups about the basic idea.
Absolutely. Emmanuel/I had already some discussions with folks from the CDI
and JAX-RS EGs.
JSF is definitely a good point, I hadn't considered that so far. Do you
know who would be good to talk to?
Am 27.01.2012 12:54 schrieb "Gerhard Petracek" <gerhard.petracek(a)gmail.com>:
>
> hi @ all,
>
> imo we should also talk with other expert-groups about the basic idea.
> e.g. the jsf-eg (i'm going to propose group-validation triggered via
command components (based on a feature of myfaces extval) and maybe they
have additional ideas related to this topic.)
>
> regards,
> gerhard
>
>
>
>
> 2012/1/27 Hardy Ferentschik <hardy(a)hibernate.org>
>>
>> Thanks Gunnar for the explanation. It made things much clearer (at least
for me).
>> Maybe my confusion was also caused by the fact that @ValidateGroups was
so
>> generically named. I don't think it really expresses its intend.
Wouldn't something like
>> @MethodValidated be better?
>>
>> --Hardy
>>
>>
>> On Jan 26, 2012, at 9:29 PM, Gunnar Morling wrote:
>>
>> > 2012/1/26 Hardy Ferentschik <hardy(a)hibernate.org>:
>> >
>> >> On Jan 22, 2012, at 8:33 PM, Gunnar Morling wrote:
>> >>> Instead this should be task of technologies integrating the method
>> >>> validation feature to decide whether a validation is needed or not
and
>> >>> if so delegate that validation to BV.
>> >>
>> >> Right. My understanding was that if method level validation is
enabled in the integrating
>> >> framework and method level annotations exist, validation gets
triggered.
>> >
>> > Yepp, I think there are different interpretations of "enabling method
>> > validation" floating around which might cause some irritations. There
>> > are actually two "levels" of enablement IMO:
>> >
>> > * A system is generally able to make use of method validation by
>> > providing the required integration layer. Taking CDI for example,
>> > there would be a CDI method interceptor which is able to intercept
>> > method calls and invoke Validator#validateParameters() and/or
>> > Validator#validateReturnValue().
>> > * Based on that integration layer, method validation is actually
>> > enabled (or not) for given types. In other words instead of enabling
>> > method validation globally for all types/methods, I think often a more
>> > fine-grained configurability is required. Sticking to the CDI example,
>> > the types to perform method validation on, would be annotated with an
>> > interceptor binding annotation which causes the validation interceptor
>> > to kick in if methods on the annotated type are invoked. Taking Spring
>> > AOP as example, the types for which to perform method validation on
>> > could be specified using an advice with type name patterns,
>> > restrictions to certain packages etc.
>> >
>> >>> #2 Define an annotation such as @javax.validation.ValidateGroups
within BV
>> >>>
>> >>> @ValidateGroups({Group1.class, Group2.class})
>> >>> public class OrderService {
>> >>>
>> >>> @NotNull
>> >>> public Order placeOrder((a)NotNull(groups=Group1.class)
@Size(min=3,
>> >>> max=20) String customerCode, @NotNull Item item, @Min(1) int
quantity)
>> >>> { //... }
>> >>>
>> >>> }
>> >>
>> >> What would @ValidateGroups in this case do?
>> >
>> > @ValidateGroups would be the second "enabler" from the two above. That
>> > is, it controls that method validation shall be performed on the
>> > methods of OrderService by means of the validation interceptor
>> > provided by the given integration layer. It would also control which
>> > groups should be validated for methods invoked on the annotated type
>> > (here Group1 and Group2). It furthermore might control whether to
>> > perform a parameter or return value validation or both.
>> >
>> > This is comparable to declarative transaction control; there exists an
>> > interceptor which is able to begin/commit transactions. To which
>> > types/operations this interceptor applies can be controlled using an
>> > annotation such as @Transactional (or other means such as an XML
>> > config).
>> >
>> >>> #3 Don't define anything related in BV, leave that completely to
integrators
>> >>
>> >> That is probably the solution I had in mind from the beginning. Seems
still most reasonable to me.
>> >
>> > That's definitely an option, but it might cause a proliferation of the
>> > JEE platform. There are several potential integrators of method
>> > validation (I know at least about CDI and JAX-RS). They could all
>> > define their own variant of @ValidateGroups, but these would likely be
>> > very similar to each other. So another option is to define one
>> > standardized annotation for that purpose in BV which then can be used
>> > by all interested integrators. For instance
>> >
>> > * JAX-RS would check for that annotation on REST resource classes and
>> > would invoke j.v.Validator upon invocation of resource methods
>> > * CDI would define a CDI method interceptor and handle the annotation
>> > as interceptor binding annotation which causes the interceptor to kick
>> > in using the standard CDI mechanisms for interceptor handling
>> >
>> >>> Taking CDI for example, AFAIK the annotation would have to be
annotated with the @InterceptorBinding meta annotation. I don't know
whether/how it would be possible that we define the "basic" annotation,
while integrators "enrich" it with the meta data they require.
>> >
>> > In between I had the chance to talk to Pete from the CDI EG. He
>> > confirmed that annotation types can programmatically be "promoted" to
>> > interceptor binding annotations. That means CDI could integrate with
>> > an annotation type defined in the BV API also if that type hasn't the
>> > @InterceptorBinding meta annotation (which it shouldn't IMO in order
>> > to avoid a compile dependency from BV to CDI).
>> >
>> > --Gunnar
>> >
>> > _______________________________________________
>> > beanvalidation-dev mailing list
>> > beanvalidation-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
14 years, 1 month
