Change the event that the DeserializingObserver is listening to

[renatorroliveira]

Hello guys,
I am suggesting to change the event that the DeserializingObserver is listening to.
Today it is listening to the ReadyToExecuteMethod, which is the same event that the MethodValidator is listening.
This is producing a bug in the validator. This happens because with the CDI events we can't guarantee the order of the listerner's execution. So, in my tests, when i receive the parameters of my controller's method via JSON, i annotated the method with @consumes. However, the listener of the MethodValidator is beeing executed before the DeserializingObserver. So, when i call validator.onError... it always acuses validation errors, because the validation is occurring before the processing of parameters.

So, the DeserializingObserver should be listening to another event, an event that occurs before the ReadyToExecuteMethod. It could be an existent or even a new event.

Regards

[Turini]

Thank you for reporting @renatorroliveira! I'll do some tests

[garcia-jj]

As discussed in #366, we need to review events fired on each request.

[renatorroliveira]

Yeah, but i think this bug should be corrected as soon as possible.
We cannot use the Bean Validator with @consumes at this point, it doesn't work.
The correction is kind simple, i suggest creating a new event that is fired before ReadyToExecuteMethod or, if you don't want to create new events, execute the DeserializingObserver right after the normal parameter processing.

[Turini]

@renatorroliveira, may you test with this PR (#426) code?

[Turini]

just explaining, EndOfInterceptorStack is fired just before ReadyToExecuteMethod

[renatorroliveira]

I will test as soon as i got home today.
But taking a look at the pull request, you set the MethodValidator to execute before ReadyToExecuteMethod. But that was the problem, the DeserializingObserver should execute before the MethodValidator, with this code the MethodValidator will always execute before the DeserializingObserver?
I think this is the inverse order...

[Turini]

you're right @renatorroliveira! rs. I'll fix in there, thanks again

[renatorroliveira]

I think it should be the DeserializingObserver listening to EndOfInterceptorStack and the MethodValidator listening to ReadyToExecuteMethod.
But this still have a problem, because the ExecuteMethod is listening to EndOfInterceptorStack too, and you can't guarantee that the ExecuteMethod will be called after any other listener of the EndOfInterceptorStack...

[Turini]

I'm adding a new event, because in this case it will be really necessary.

[garcia-jj]

I have commited some weeks ago a similar case: https://github.com/garcia-jj/vraptor4/commits/ot-rejectednewobservers. May be you can do somethink like this, if you want.

[Turini]

@renatorroliveira, can you test now? (with #427 changes)

[Turini]

I have commited some weeks ago a similar case: https://github.com/garcia-jj/vraptor4
/commits/ot-rejectednewobservers. May be you can do somethink like this, if you want.

thanks @garcia-jj.

[Turini]

@renatorroliveira, we replace #427 solution with #430.
Now Deserializing observes StackStarting, so it should solve the issue.
When it's possible, could you test with #430 code?

[renatorroliveira]

I will try to do some tests, i don't know how to get the specific code of the pull request, but i will look for it.

[renatorroliveira]

I've got the branch code. I will do some tests now.
But looking at the solution, i think this will solve the problem if the deserialization happens before the interceptor executor. I will post the test results later.

[Turini]

thanks @renatorroliveira! If you need any help, just let me know =)

[renatorroliveira]

Hi @Turini
Looks like the problem was solved with the #430 solved the problem!
I finally get the branch's code to work with my project =P

In my tests the deserialization and the validation worked fine.
Who should close this issue?

[Turini]

great @renatorroliveira! I'll merge this PR, and it will close the issue automatically