We run under JCP 2.9
by Emmanuel Bernard
The PMO has quietly upgraded us. We are now running under the JCP 2.9 rules.
Emmanuel
13 years
Should getters be considered methods during validation
by Emmanuel Bernard
For method validation, we have so far managed to get away with
requiring an annotation based metadata to direct how method validation
behaves.
One question that popped up during the recent write up is whether or not
getters should be considered regular methods and thus be intercepted and
validation by CDI or AspectJ interceptors.
I have my own ideas, but I'd like to get your opinion on the subject.
Emmanuel
13 years
Do we need ConstraintValidatorFactory#releaseInstance()?
by Gunnar Morling
Hi all,
The latest RI version [1] also implements the spec changes regarding the
integration of BV and CDI.
During implementation Hardy, Emmanuel and I got into a discussion regarding
the lifecycle of CDI-managed objects [2] which I'd like to continue.
The question is whose responsibility is it to release involved objects such
as message interpolator, traversable resolver or constraint validators.
Generally we think objects should be released by that party/code that
created them.
This means:
1) objects created by the user and passed via bootstrap API: to be released
by user
2) objects created by BV implementation (e.g. internal caches): to be
released by BV implementation
3) objects passed by CDI integration layer (e.g. CDI-enabled message
interpolator etc. based on BootstrapConfiguration): to be released by
integration layer
I think 1) is not in our focus, let the user deal with it. For 2) we have
ValidatorFactory#close(). Interesting is 3). A CDI portable extension could
make sure that its created managed beans are properly released using CDI's
pre-destroy hook [3].
But that way a CDI-enabled ConstraintValidatorFactory could also easily
release all the constraint validators it created:
CdiConstraintValidatorFactory implements ConstraintValidatorFactory {
public <T extends ConstraintValidator<?, ?>> T getInstance(Class<T> key) {
//create validators. keep track of them.
}
@PreDestroy
public cleanUpValidators() {
//release created validators
}
}
That is, we'd again adhere to the principle that whoever creates objects
has to release them. When following this approach, we actually wouldn't
need ConstraintValidatorFactory#releaseInstance() anymore. I think this
would be a good thing as it IMO simplifies the contract between the BV
provider and code integrating with it (such as a CDI portable extension)
and clarifies responsibilities.
In the spec we would describe that a CDI-enabled CVF has to release its
validators when it itself is going to be destructed and for
ValidatorFactory#close(), that a BV provider has to release its internal
state but no objects passed to it.
One thing not possible with that approach is to release CV instances before
the application is shut down. The spec currently says that
releaseInstance() is "typically" invoked when the ValidatorFactory is
closed, but AFAICS it leaves room for releasing constraint validators also
in between. OTOH I wouldn't know when/how a BV provider would decide to do
that.
Any thoughts?
--Gunnar
[1] http://in.relation.to/Bloggers/HibernateValidator500Alpha2And431Final
[2] https://hibernate.onjira.com/browse/BVAL-338
[3] http://docs.oracle.com/javaee/6/tutorial/doc/gmgkd.html
13 years
New member to the EG
by Emmanuel Bernard
As part of the new JCP 2.9 rules, discussions on new expert group
members must be discussed in the open. While we have not officially
moved, now is a good time to get into the habit.
Jobinesh Purushothaman from Oracle has requested to join the expert
group. Here is what he wrote
Qualifications: Jobinesh Purushothaman works with Oracle as Principal Solutions Architect for Application Development Framework. He has authored a book on Oracle ADF entitled "Oracle ADF Real World Developer’s Guide", published by Packtpub in Oct 2012. He is also involved in design and architectural decisions of various products using ADF and Java EE technologies, and occasionally he speaks at industry conferences such as JavaOne and Oracle Develop. Jobinesh also spends time on training and mentoring developers on ADF and Java technologie
He proposes to contribute 4h/week. That being said, if I could actually
use the amount of time per week you guys have accepted to contribute, I
would have finished the spec last year ;P
I would like to go ahead and invite Jobinesh to join us. I always liked
feedbacks from integrating frameworks and ADF is a good case.
Any comment?
Emmanuel
13 years, 1 month
BVAL-192 'exclusive' flag for @DecimalMin/@DecimalMax
by Hardy Ferentschik
Hi,
I was looking at one of the minor changes on the BV 1.1 roadmap [1] - BVAL-192 [2].
The idea is to add a exclusive flag to the annotation @DecimalMin and @DecmimalMax.
This way you could for example easily express a negative non-zero decimal number:
@DecimalMax(value = "0.0", exclusive = true)
When dealing with decimal number such a flag can indeed simplify things, however it creates
a problem when dealing with error messages. At the moment the message for DecimalMax is for
example: "must be less than or equal to {value}". Depending on the exclusive flag this message would
need to change though. Two versions of the message would be required. Technically the right version
of the message could be selected via ConstraintValidatorContext, but it would be a first for built-in
constraints. We would also need to define the name for alternative messages. Would it be:
javax.validation.constraints.DecimalMax.message1
javax.validation.constraints.DecimalMax.message2
or
javax.validation.constraints.DecimalMax.inclusive.message
javax.validation.constraints.DecimalMax.exclusive.message
I hope this rather simple question creates some welcome breaking-up from the harder questions like
"should we consider getters for method validation" ;-)
--Hardy
[1] http://beanvalidation.org/roadmap/
[2] https://hibernate.onjira.com/browse/BVAL-192
13 years, 1 month
Re: [bv-dev] beanvalidation-dev Digest, Vol 17, Issue 11
by Faissal Boutaounte
+1 for *1.b*
*Faissal *
---
Préservons l'environnement. N'imprimez ce courriel que si nécessaire.
Please consider the environment before printing this e-mail.
2012/12/12 <beanvalidation-dev-request(a)lists.jboss.org>
> Send beanvalidation-dev mailing list submissions to
> beanvalidation-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> or, via email, send a message with subject or body 'help' to
> beanvalidation-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> beanvalidation-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of beanvalidation-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Should getters be considered methods during validation
> (Gerhard Petracek)
> 2. Re: Should getters be considered methods during validation
> (Sebastian Thomschke)
> 3. Re: Should getters be considered methods during validation
> (Gerhard Petracek)
> 4. Re: BVAL-192 'exclusive' flag for @DecimalMin/@DecimalMax
> (Hardy Ferentschik)
> 5. Re: Should getters be considered methods during validation
> (Emmanuel Bernard)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 11 Dec 2012 19:32:40 +0100
> From: Gerhard Petracek <gerhard.petracek(a)gmail.com>
> Subject: Re: [bv-dev] Should getters be considered methods during
> validation
> To: beanvalidation-dev List <beanvalidation-dev(a)lists.jboss.org>
> Message-ID:
> <CAGJtJfEbm4FpFB2V7iH50dABrH=
> RsbAsdWHOUeXRYP_j8OzPew(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> +1 for 2.b but -1 for a package annotation and/or config.
>
> regards,
> gerhard
>
>
>
> 2012/12/11 Emmanuel Bernard <emmanuel(a)hibernate.org>
>
> > That should hopefully be the last round. Here are the alternatives that
> > I think are viable http://goo.gl/ubjn3
> >
> > Please give your feedback.
> >
> > Emmanuel
> >
> > On Tue 2012-10-23 18:19, Emmanuel Bernard wrote:
> > > For method validation, we have so far managed to get away with
> > > requiring an annotation based metadata to direct how method validation
> > > behaves.
> > >
> > > One question that popped up during the recent write up is whether or
> not
> > > getters should be considered regular methods and thus be intercepted
> and
> > > validation by CDI or AspectJ interceptors.
> > >
> > > I have my own ideas, but I'd like to get your opinion on the subject.
> > >
> > > Emmanuel
> > > _______________________________________________
> > > 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
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20121211/...
>
> ------------------------------
>
> Message: 2
> Date: Tue, 11 Dec 2012 21:17:56 +0100
> From: Sebastian Thomschke <sebastian.thomschke(a)web.de>
> Subject: Re: [bv-dev] Should getters be considered methods during
> validation
> To: beanvalidation-dev(a)lists.jboss.org
> Message-ID: <50C794F4.4010508(a)web.de>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi,
>
> I'm +1 for option 1b.
>
> A constraint annotation added to a regular non-getter method always
> describes a return value contract whereas a constraint annotation added
> to a getter method may be meant to be
> a) a return value contract or
> b) a property constraint, that only is supposed to be considered during
> bean validation.
>
> For getter method constraint annotation my gut feeling is, that you
> usually want b) - a property constraint definition.
>
> In OVal we have the annotation @IsInvariant to mark the constraints
> defined on a getter for being return value contracts if not present the
> constraints are not interpreted as return value contracts.
>
> Regards,
>
> Seb
>
> On 11.12.2012 16:50, Emmanuel Bernard wrote:
> > That should hopefully be the last round. Here are the alternatives that
> > I think are viable http://goo.gl/ubjn3
> >
> > Please give your feedback.
> >
> > Emmanuel
> >
> > On Tue 2012-10-23 18:19, Emmanuel Bernard wrote:
> >> For method validation, we have so far managed to get away with
> >> requiring an annotation based metadata to direct how method validation
> >> behaves.
> >>
> >> One question that popped up during the recent write up is whether or not
> >> getters should be considered regular methods and thus be intercepted and
> >> validation by CDI or AspectJ interceptors.
> >>
> >> I have my own ideas, but I'd like to get your opinion on the subject.
> >>
> >> Emmanuel
> >> _______________________________________________
> >> 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
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 11 Dec 2012 23:12:49 +0100
> From: Gerhard Petracek <gerhard.petracek(a)gmail.com>
> Subject: Re: [bv-dev] Should getters be considered methods during
> validation
> To: beanvalidation-dev List <beanvalidation-dev(a)lists.jboss.org>
> Message-ID:
> <
> CAGJtJfHQBtYg-ObT1MCBF47O_RdasnCtyDYv_X-JkbJe3bt_Ug(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> hi sebastian,
>
> i was going to +1 1.b as well, but i don't agree with point #1 (if it is
> globally and/or users have to do it in any case) and #2.
> (with @ValidateOnCall i'm ok with both default behaviours, if there is a
> way to change it for a bv-archive.)
>
> regards,
> gerhard
>
>
>
> 2012/12/11 Sebastian Thomschke <sebastian.thomschke(a)web.de>
>
> > Hi,
> >
> > I'm +1 for option 1b.
> >
> > A constraint annotation added to a regular non-getter method always
> > describes a return value contract whereas a constraint annotation added
> > to a getter method may be meant to be
> > a) a return value contract or
> > b) a property constraint, that only is supposed to be considered during
> > bean validation.
> >
> > For getter method constraint annotation my gut feeling is, that you
> > usually want b) - a property constraint definition.
> >
> > In OVal we have the annotation @IsInvariant to mark the constraints
> > defined on a getter for being return value contracts if not present the
> > constraints are not interpreted as return value contracts.
> >
> > Regards,
> >
> > Seb
> >
> > On 11.12.2012 16:50, Emmanuel Bernard wrote:
> > > That should hopefully be the last round. Here are the alternatives that
> > > I think are viable http://goo.gl/ubjn3
> > >
> > > Please give your feedback.
> > >
> > > Emmanuel
> > >
> > > On Tue 2012-10-23 18:19, Emmanuel Bernard wrote:
> > >> For method validation, we have so far managed to get away with
> > >> requiring an annotation based metadata to direct how method validation
> > >> behaves.
> > >>
> > >> One question that popped up during the recent write up is whether or
> not
> > >> getters should be considered regular methods and thus be intercepted
> and
> > >> validation by CDI or AspectJ interceptors.
> > >>
> > >> I have my own ideas, but I'd like to get your opinion on the subject.
> > >>
> > >> Emmanuel
> > >> _______________________________________________
> > >> 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
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20121211/...
>
> ------------------------------
>
> Message: 4
> Date: Wed, 12 Dec 2012 00:46:40 +0100
> From: Hardy Ferentschik <hardy(a)hibernate.org>
> Subject: Re: [bv-dev] BVAL-192 'exclusive' flag for
> @DecimalMin/@DecimalMax
> To: beanvalidation-dev List <beanvalidation-dev(a)lists.jboss.org>
> Message-ID: <E2199861-9455-4CFA-90F1-05C2CCCF4D92(a)hibernate.org>
> Content-Type: text/plain; charset=us-ascii
>
>
> >>> @DecimalMax(value = "0.0", exclusive = true)
> >>
> >> Can we name it "inclusive" rather than "exclusive"? Personally I prefer
> >> positive variable/method names as I think they read better, in
> particular
> >> when it comes to negation.
> >
> > I think inclusive also has a clearer meaning, it took me three reads
> > through to work out what the purpose was. I wondered if Hardy picked
> > exclusive for a sensible default value, but gave up trying to get my
> > head around it (newborn baby is my excuse).
>
> Well, I just used 'exclude', because it was used in the jira ticket. Now
> that I think about it 'inclusive' is much better.
> Maybe I can play the newborn card as well? Does it still count after 4
> months? I definitely still feel tired.
>
> Welcome to the club.
>
> --Hardy
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 12 Dec 2012 09:26:15 +0100
> From: Emmanuel Bernard <emmanuel(a)hibernate.org>
> Subject: Re: [bv-dev] Should getters be considered methods during
> validation
> To: beanvalidation-dev List <beanvalidation-dev(a)lists.jboss.org>
> Cc: beanvalidation-dev List <beanvalidation-dev(a)lists.jboss.org>
> Message-ID: <A828568E-799B-4BEF-A704-01CCCCDD2E89(a)hibernate.org>
> Content-Type: text/plain; charset="utf-8"
>
> A couple of remarks, I am not tied to @ValidateOnCall. We can find better
> names and/or a different split. I like @IsInvariant described by Sebastian
> which means @ValidateOnCall(INCLUDE_GETTERS) in my proposal. My concern is
> that it would not scale for bean/package level settings nor allow to
> disable validation on a particular method.
>
> My point being, if we finally agree on the proper default and overriding
> approach we can refine names.
>
> Gerhard, let me try and clarify your position. You like 1.b but you want
> to be able to change the default global behavior per archive (with a
> validation.xml setting) if needed and therefore that's why you voted for
> 2.b. I don't see a big problem with that. My two concerns are:
>
> - I am not sure that would be useful very often in practice but I imagine
> it could be useful in a pure service archive
> - to know the behavior, it forces people to look for a validation.xml to
> see what behavior is set but as long as we have the default defined in 1,
> that's not a huge concern to me.
>
> Emmanuel
>
> On 11 d?c. 2012, at 23:12, Gerhard Petracek <gerhard.petracek(a)gmail.com>
> wrote:
>
> > hi sebastian,
> >
> > i was going to +1 1.b as well, but i don't agree with point #1 (if it is
> globally and/or users have to do it in any case) and #2.
> > (with @ValidateOnCall i'm ok with both default behaviours, if there is a
> way to change it for a bv-archive.)
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2012/12/11 Sebastian Thomschke <sebastian.thomschke(a)web.de>
> >> Hi,
> >>
> >> I'm +1 for option 1b.
> >>
> >> A constraint annotation added to a regular non-getter method always
> >> describes a return value contract whereas a constraint annotation added
> >> to a getter method may be meant to be
> >> a) a return value contract or
> >> b) a property constraint, that only is supposed to be considered during
> >> bean validation.
> >>
> >> For getter method constraint annotation my gut feeling is, that you
> >> usually want b) - a property constraint definition.
> >>
> >> In OVal we have the annotation @IsInvariant to mark the constraints
> >> defined on a getter for being return value contracts if not present the
> >> constraints are not interpreted as return value contracts.
> >>
> >> Regards,
> >>
> >> Seb
> >>
> >> On 11.12.2012 16:50, Emmanuel Bernard wrote:
> >> > That should hopefully be the last round. Here are the alternatives
> that
> >> > I think are viable http://goo.gl/ubjn3
> >> >
> >> > Please give your feedback.
> >> >
> >> > Emmanuel
> >> >
> >> > On Tue 2012-10-23 18:19, Emmanuel Bernard wrote:
> >> >> For method validation, we have so far managed to get away with
> >> >> requiring an annotation based metadata to direct how method
> validation
> >> >> behaves.
> >> >>
> >> >> One question that popped up during the recent write up is whether or
> not
> >> >> getters should be considered regular methods and thus be intercepted
> and
> >> >> validation by CDI or AspectJ interceptors.
> >> >>
> >> >> I have my own ideas, but I'd like to get your opinion on the subject.
> >> >>
> >> >> Emmanuel
> >> >> _______________________________________________
> >> >> 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
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20121212/...
>
> ------------------------------
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> End of beanvalidation-dev Digest, Vol 17, Issue 11
> **************************************************
>
13 years, 1 month
