Clarify interceptor order in method validation triggering

Description

We need to think about when a parameter validation interceptor ought to be executed in the interceptor stack
Before or after transaction, security? Some interceptors can change param values.
It's likely that transaction and security must go first. What about others?

Gunnar Morling added a comment - 16/Nov/11 8:12 AM
I guess the validation interceptor should be executed as late as possible. I'm just wondering whether this is something which we should define in BV. Wouldn't BV not only provide the API/meta model for method validation, while it's up to integrators how/when to invoke it? In that case we might just add some sort of recommendation related to that aspect to the spec.

Environment

None

Activity

Show:
Emmanuel Bernard
August 28, 2012, 7:00 PM

Decide whether or not non-CDI Java EE managed beans also have interceptors enabled automatically via a non-portable way by the container or are we forcing the user to add the Bean Validation interceptor manually on its beans.
We will try and aligned Java EE managed beans and CDI beans feature wise so so far the logic would be to get a solution transparent to the user like in CDI.

Hardy Ferentschik
August 29, 2012, 9:49 AM

I think we should at most add a recommendation.

Emmanuel Bernard
August 29, 2012, 11:01 AM

At most? But we need to decide of the behavior in Java EE, we can't leave it hanging undefined.

Fixed

Assignee

Emmanuel Bernard

Reporter

Emmanuel Bernard

Labels

None

Feedback Requested

None

Feedback Requested By

None

backPortable

None

Suitable for new contributors

None

Pull Request

None

backportDecision

None

backportReEvaluate

None

Components

Fix versions

Priority

Major
Configure