4:52 a.m.
Hi all,
While implementing the rules around automatic method validation, I realised that there is
no option to
disable automatic method validation altogether via XML.
I thought I could do something like this:
<validated-executables>
<executable-type>NONE</executable-type>
</validated-executables>
However, the xml configuration only acts as a global default for the valuation type and
can still
be overridden by explicit @ValidateExecutable annotations. See the algorithm in section
10.1.2 [1].
In fact the xml configuration is consulted last to determine whether validation should
occur or not.
As a result we already created BVAL-435 [2] to rename <validated-executables/> to
<default-validated-executables/>.
I think that better reflects the intention of this configuration option.
This still does not address the issue of really disabling method validation - BVAL-436
[3]. I see that useful in the case
where you deal with a library where you cannot change the code/annotations and you want to
disable validation altogether.
That's currently not possible.
WDYT? Is it too late to add an additional option?
--Hardy
[1] http://beanvalidation.org/1.1/spec/1.1.0.cr1/#integration-general-executable
[2] https://hibernate.onjira.com/browse/BVAL-435
[3] https://hibernate.onjira.com/browse/BVAL-436
12:50 p.m.
I am sympathetic to the idea but being very late in the game, I want a
strong backing by the expert group.
Please speak up your feedback (whatever it is).
I anticipate the following impact:
- integration chapter will add the disable rule
- add the disable flag to the BootstrapConfiguration
- add the disable option to the XSD
- oh and find a name and good structure for it. Hardy any idea?
Emmanuel
On Fri 2013-03-08 11:52, Hardy Ferentschik wrote:
Hi all,
While implementing the rules around automatic method validation, I realised that there is
no option to
disable automatic method validation altogether via XML.
I thought I could do something like this:
<validated-executables>
<executable-type>NONE</executable-type>
</validated-executables>
However, the xml configuration only acts as a global default for the valuation type and
can still
be overridden by explicit @ValidateExecutable annotations. See the algorithm in section
10.1.2 [1].
In fact the xml configuration is consulted last to determine whether validation should
occur or not.
As a result we already created BVAL-435 [2] to rename <validated-executables/> to
<default-validated-executables/>.
I think that better reflects the intention of this configuration option.
This still does not address the issue of really disabling method validation - BVAL-436
[3]. I see that useful in the case
where you deal with a library where you cannot change the code/annotations and you want
to disable validation altogether.
That's currently not possible.
WDYT? Is it too late to add an additional option?
--Hardy
[1] http://beanvalidation.org/1.1/spec/1.1.0.cr1/#integration-general-executable
[2] https://hibernate.onjira.com/browse/BVAL-435
[3] https://hibernate.onjira.com/browse/BVAL-436
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
2:33 p.m.
On 8 Jan 2013, at 7:50 PM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
I am sympathetic to the idea but being very late in the game, I want
a
strong backing by the expert group.
Please speak up your feedback (whatever it is).
I anticipate the following impact:
- integration chapter will add the disable rule
- add the disable flag to the BootstrapConfiguration
- add the disable option to the XSD
- oh and find a name and good structure for it. Hardy any idea?
maybe one could mirror <default-validated-executables/> and call it
<override-validated-executables/> !?
--Hardy
2:37 a.m.
It feels like override-validated-executables would provide a lit of
executable types validated. I don't think that feature makes sense as
deciding if a specific executable type is validated depends on a class
basis(eg JPA vs JAX-Rs action method.
I thought you had in mind a global flag to disable it entirely. I have
mocked two approaches, please give me your thoughts:
https://gist.github.com/emmanuelbernard/2191bad0c7d8742a8eea
Approach #1 has my preference I believe.
Check out the schema design after both approaches in the gist. I reused
the design JPA uses to exclude classes from being scanned. But I am not
an XML expert and there might be better options.
Likewise BootstrapConfiguration would get a Boolean
getDisableValidationExecution() method that is ignored by Bean
Validation engines proper.
Emmanuel
On Fri 2013-03-08 21:33, Hardy Ferentschik wrote:
On 8 Jan 2013, at 7:50 PM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
> I am sympathetic to the idea but being very late in the game, I want a
> strong backing by the expert group.
> Please speak up your feedback (whatever it is).
>
> I anticipate the following impact:
>
> - integration chapter will add the disable rule
> - add the disable flag to the BootstrapConfiguration
> - add the disable option to the XSD
> - oh and find a name and good structure for it. Hardy any idea?
maybe one could mirror <default-validated-executables/> and call it
<override-validated-executables/> !?
--Hardy
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
5:43 a.m.
On 13 Jan 2013, at 8:37 AM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
https://gist.github.com/emmanuelbernard/2191bad0c7d8742a8eea
Approach #1 has my preference I believe.
+1 A single flag works.
Likewise BootstrapConfiguration would get a Boolean
getDisableValidationExecution() method that is ignored by Bean
Validation engines proper.
Would isValidationExecutionDisabled() not a better name?
--Hardy
5:54 a.m.
What I like about approach #2 is that it bundles the configuration related
to executable validation in one element.
Maybe an attribute could be used for the flag:
<executable-validation enabled="true|false">
<default-validated-executables>
<executable-type>NONE</executable-type>
</default-validated-executables>
</executable-validation>
Generally I like "positive" flag names better than negated ones (i.e.
"enabled" instead of "disabled").
If you want to stick to two elements instead of an attribute, a xs:choice
could be used to express that only one of the elements may be present in a
given instance document.
Would isValidationExecutionDisabled() not a better name?
Or isValidationOnExecutionEnabled()?
--Gunnar
2013/3/13 Hardy Ferentschik <hardy(a)hibernate.org>
>
> On 13 Jan 2013, at 8:37 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>
> wrote:
>
> > https://gist.github.com/emmanuelbernard/2191bad0c7d8742a8eea
> >
> > Approach #1 has my preference I believe.
>
> +1 A single flag works.
>
> > Likewise BootstrapConfiguration would get a Boolean
> > getDisableValidationExecution() method that is ignored by Bean
> > Validation engines proper.
>
Would isValidationExecutionDisabled() not a better name?
>
> --Hardy
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
6:09 a.m.
I'd like BootstrapConfiguration to mimic the name we use in the XSD.
Does that change your proposal?
I thought about using choice but it forces people to comment out their
default validated executable section.
That being said, I like your proposal for
<executable-validation enabled="false"/> with a default to true.
How would that be designed in BootstrapConfiguration?
Emmanuel
On Wed 2013-03-13 11:54, Gunnar Morling wrote:
What I like about approach #2 is that it bundles the configuration
related
to executable validation in one element.
Maybe an attribute could be used for the flag:
<executable-validation enabled="true|false">
<default-validated-executables>
<executable-type>NONE</executable-type>
</default-validated-executables>
</executable-validation>
Generally I like "positive" flag names better than negated ones (i.e.
"enabled" instead of "disabled").
If you want to stick to two elements instead of an attribute, a xs:choice
could be used to express that only one of the elements may be present in a
given instance document.
> Would isValidationExecutionDisabled() not a better name?
Or isValidationOnExecutionEnabled()?
--Gunnar
2013/3/13 Hardy Ferentschik <hardy(a)hibernate.org>
>
> On 13 Jan 2013, at 8:37 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>
> wrote:
>
> > https://gist.github.com/emmanuelbernard/2191bad0c7d8742a8eea
> >
> > Approach #1 has my preference I believe.
>
> +1 A single flag works.
>
> > Likewise BootstrapConfiguration would get a Boolean
> > getDisableValidationExecution() method that is ignored by Bean
> > Validation engines proper.
>
> Would isValidationExecutionDisabled() not a better name?
>
> --Hardy
>
> _______________________________________________
> 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
8:35 a.m.
I'd like BootstrapConfiguration to mimic the name we use in the
XSD.
Does that change your proposal?
Maybe isExecutableValidationEnabled() then? I guess this would match
<executable-validation
enabled="true|false"> quite closely.
How would that be designed in BootstrapConfiguration?
Two methods, isExecutableValidationEnabled() and
getDefaultValidatedExecutableTypes()? It would be in the responsibility of
the caller to make use of the latter only if the former returned true.
2013/3/13 Emmanuel Bernard <emmanuel(a)hibernate.org>
I'd like BootstrapConfiguration to mimic the name we use in the
XSD.
> Does that change your proposal?
>
> I thought about using choice but it forces people to comment out their
> default validated executable section.
>
> That being said, I like your proposal for
> <executable-validation enabled="false"/> with a default to true.
>
How would that be designed in BootstrapConfiguration?
>
> Emmanuel
>
> On Wed 2013-03-13 11:54, Gunnar Morling wrote:
> > What I like about approach #2 is that it bundles the configuration
> related
> > to executable validation in one element.
> >
> > Maybe an attribute could be used for the flag:
> >
> > <executable-validation enabled="true|false">
> > <default-validated-executables>
> > <executable-type>NONE</executable-type>
> > </default-validated-executables>
> > </executable-validation>
> >
> > Generally I like "positive" flag names better than negated ones (i.e.
> > "enabled" instead of "disabled").
> >
> > If you want to stick to two elements instead of an attribute, a xs:choice
> > could be used to express that only one of the elements may be present in
> a
> > given instance document.
> >
> > > Would isValidationExecutionDisabled() not a better name?
> >
> > Or isValidationOnExecutionEnabled()?
> >
> > --Gunnar
> >
> >
> >
> > 2013/3/13 Hardy Ferentschik <hardy(a)hibernate.org>
> >
> > >
> > > On 13 Jan 2013, at 8:37 AM, Emmanuel Bernard
<emmanuel(a)hibernate.org>
> > > wrote:
> > >
> > > > https://gist.github.com/emmanuelbernard/2191bad0c7d8742a8eea
> > > >
> > > > Approach #1 has my preference I believe.
> > >
> > > +1 A single flag works.
> > >
> > > > Likewise BootstrapConfiguration would get a Boolean
> > > > getDisableValidationExecution() method that is ignored by Bean
> > > > Validation engines proper.
> > >
> > > Would isValidationExecutionDisabled() not a better name?
> > >
> > > --Hardy
> > >
> > > _______________________________________________
> > > 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
>
6:53 a.m.
On 13 Jan 2013, at 11:54 AM, Gunnar Morling <gunnar(a)hibernate.org> wrote:
What I like about approach #2 is that it bundles the configuration
related to executable validation in one element.
Maybe an attribute could be used for the flag:
<executable-validation enabled="true|false">
<default-validated-executables>
<executable-type>NONE</executable-type>
</default-validated-executables>
</executable-validation>
the enabled flag seems need, but we would need then probably another object in
BootstrapConfiguration wrapping the
executable-validation config. I am not sure this is worth it.
Generally I like "positive" flag names better than negated
ones (i.e. "enabled" instead of "disabled").
In this case I actually prefer isValidationExecutionDisabled(). That's the more
relevant/interesting case.
--Hardy
8:39 a.m.
but we would need then probably another object in
BootstrapConfiguration
wrapping the
executable-validation config. I am not sure this is worth it.
We could also do
<executable-validation enabled="true|false">
<executable-type>GETTER_METHODS</executable-type>
<executable-type>CONSTRUCTORS</executable-type>
</executable-validation>
I'd slightly prefer an explicit list element for the executable types. I
think this reads better, should we add another sub-element to
<executable-validation> one day. But I could also live with the simpler
form I guess.
2013/3/13 Hardy Ferentschik <hardy(a)hibernate.org>
>
> On 13 Jan 2013, at 11:54 AM, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>
> > What I like about approach #2 is that it bundles the configuration
> related to executable validation in one element.
> >
> > Maybe an attribute could be used for the flag:
> >
> > <executable-validation enabled="true|false">
> > <default-validated-executables>
> > <executable-type>NONE</executable-type>
> > </default-validated-executables>
> > </executable-validation>
>
> the enabled flag seems need, but we would need then probably another
> object in BootstrapConfiguration wrapping the
executable-validation config. I am not sure this is worth it.
>
> > Generally I like "positive" flag names better than negated ones (i.e.
> "enabled" instead of "disabled").
>
> In this case I actually prefer isValidationExecutionDisabled(). That's the
> more relevant/interesting case.
>
> --Hardy
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
10:44 a.m.
hi gunnar,
imo that's too verbose and maybe not that clear/intuitive due to the
different (implicit) constellations.
regards,
gerhard
2013/3/13 Gunnar Morling <gunnar(a)hibernate.org>
> but we would need then probably another object in
BootstrapConfiguration
wrapping the
> executable-validation config. I am not sure this is worth it.
We could also do
<executable-validation enabled="true|false">
<executable-type>GETTER_METHODS</executable-type>
<executable-type>CONSTRUCTORS</executable-type>
</executable-validation>
I'd slightly prefer an explicit list element for the executable types. I
think this reads better, should we add another sub-element to
<executable-validation> one day. But I could also live with the simpler
form I guess.
2013/3/13 Hardy Ferentschik <hardy(a)hibernate.org>
>
> On 13 Jan 2013, at 11:54 AM, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>
> > What I like about approach #2 is that it bundles the configuration
> related to executable validation in one element.
> >
> > Maybe an attribute could be used for the flag:
> >
> > <executable-validation enabled="true|false">
> > <default-validated-executables>
> > <executable-type>NONE</executable-type>
> > </default-validated-executables>
> > </executable-validation>
>
> the enabled flag seems need, but we would need then probably another
> object in BootstrapConfiguration wrapping the
> executable-validation config. I am not sure this is worth it.
>
> > Generally I like "positive" flag names better than negated ones (i.e.
> "enabled" instead of "disabled").
>
> In this case I actually prefer isValidationExecutionDisabled(). That's
> the more relevant/interesting case.
>
> --Hardy
> _______________________________________________
> 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
4297
days inactive
4306
days old
beanvalidation-dev@lists.jboss.org
10 comments
4 participants
participants (4)
-
Emmanuel Bernard -
Gerhard Petracek -
Gunnar Morling -
Hardy Ferentschik