short addition:
@constructor (validation):
for sure the performance issue only appeared as soon as we started to use
it for classes which get instantiated quite often.
regards,
gerhard
http://www.irian.at
Your JSF/JEE powerhouse -
JEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/11/30 Gerhard Petracek <gerhard.petracek(a)gmail.com>
hi gunnar,
@constructor:
we tried something similar in a project. it worked but it introduced a big
performance issue and we had to remove it again.
regards,
gerhard
http://www.irian.at
Your JSF/JEE powerhouse -
JEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/11/30 Gunnar Morling <gunnar.morling(a)googlemail.com>
> Hi experts,
>
> Emmanuel asked me to take the lead on the method validation feature,
> so be prepared for related questions, API proposals and requests for
> feedback via the mailing list :)
>
> The first issue I'd like to discuss is the validation of constructor
> arguments. Is this something which we want to support at all? I don't
> think there are that many interception solutions which enable
> constructor interception at all (for instance CDI interceptors don't,
> AFAIK).
>
> So personally I'd be fine with focussing on actual method validation
> in BV 1.1, waiting for user demand for constructor validation and
> adding it possibly in a later release. WDYT?
>
> If we decide to include constructor validation, should we support the
> validation of newly created objects (similar to return value
> validation), e.g. like that:
>
> public class Foo {
>
> @Valid
> public Foo() {
>
> }
>
> }
>
> Here @Valid would trigger a validation of the newly instantiated Foo
> object (whether to use @Valid or another annotation still needs to be
> discussed). Any thoughts?
>
> --Gunnar
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>