for sure the performance issue only appeared as soon as we started to use it for classes which get instantiated quite often.
http://www.irian.atYour JSF/JEE powerhouse -
JEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/11/30 Gerhard Petracek
<gerhard.petracek@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.atYour JSF/JEE powerhouse -
JEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/11/30 Gunnar Morling
<gunnar.morling@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev