Validator: Message Validation

[igarashitm]

Hi all,

I've written a prototype of Message Validator stuff and passed the compilation. I've just mapped the Transformer related classes into Validator's one by one. Please take a look when you like and let's start to discuss with this.

[branch] https://github.com/igarashitm/core/tree/SWITCHYARD-492

[commit] https://github.com/igarashitm/core/commit/b5ab2c1773d9fcf022e527316ffdb77c6ab178ba

The points need to be crarified which I've noticed are ...

• Validator needs Sequence? (cf. api/src/main/java/org/switchyard/validate/ValidateSequence.java)

Unlike Transformer, Validator doesn't need to be taken care the ordering, but still need to be able to chain

• When validator should be applied? (cf. runtime/src/main/java/org/switchyard/internal/ExchangeImpl.java)

in ExchangeImpl#send() before apply Transformer right now. after transform may be better when OUT state because it's just the boundary with the caller.

• Should Validator be applied every Message#getContent(Class<T>)? (cf. runtime/src/main/java/org/switchyard/internal/DefaultMessage.java)

currently not applied. After actually transforming occurred may be the candidate to apply Validator.

• Any Validator should be auto registered? (cf. deploy/base/src/main/java/org/switchyard/deploy/internal/AbstractDeployment.java)

Just I'm not sure why JAXB Transformer should be auto-registered, so will take a look further.

Any advice would be appreciated

Thanks,

Tomo

[kcbabo]

Hey Tomo,

I took a first pass at this and I think you are headed down the right track.  My view on some of your questions:

- I don't think chained validators are required, so sequence can go.

- Was actually thinking about the order of transform and validate today!  :-)  My view is that there should be a check before *and* after the transform, which allows validation to be performed on the input and output types if required. 

- I do not think validation should be applied to getClass() because this is merely changing the representation of the content vs. it's format.

- I don't see a need to auto-register a validator at this point.

cheers,

keith

[rcernich]

Is it possible to turn validation off?  I would guess some users would like this option to improve performance.  In the case where validation is disabled, would it be possible to validate a message if there was an exception in the workflow?  I think that would be nice from an error reporting perspective for the case where the system is stable, but a consumer or provider changes its message format, which causes an error.  Of course, I'm assuming you'd get more detailed information out of the validator than you would simply by looking at the error message (e.g. "field foo must be of type int").

Best,

Rob

[kcbabo]

@Rob - the user would have to add a validator to the application in order for validation to occur, so it's kind of an opt in deal.  We won't be validating unless the user explicitly requests it by configuring the validator.

[igarashitm]

Thanks Keith,

- I don't think chained validators are required, so sequence can go.

I think there is the case want to apply multiple Validator at the same time... but no good concrete example comes to my mind at this time so I'll remove the ValidateSequence.

- Was actually thinking about the order of transform and validate today!  :-)  My view is that there should be a check before *and* after the transform, which allows validation to be performed on the input and output types if required.

- I do not think validation should be applied to getClass() because this is merely changing the representation of the content vs. it's format.

OK, that makes sense. will do.

- I don't see a need to auto-register a validator at this point.

OK, I'll remove the methods arround the auto-register for validator. That seems not to be needed for validators.

Thanks,

Tomo

[igarashitm]

done.

https://github.com/igarashitm/core/commit/f86c8aec1bb2f6ffa0c6bc2eab8e12209949a3a7

In order to control dependency between TransformHandler and ValidateHandler, added 2 ValidateHandler into HandlerChain (DomainImpl()) ...

        // Build out the system handlers chain.  It would be cleaner if we

        // handled this via config.

        _defaultHandlers = new DefaultHandlerChain();

        _defaultHandlers.addFirst("validation." + ValidateHandler.Phase.BEFORE_TRANSFORM,

                new ValidateHandler(_validatorRegistry, ValidateHandler.Phase.BEFORE_TRANSFORM));

        _defaultHandlers.addFirst("transformation", new TransformHandler(_transformerRegistry));

        _defaultHandlers.addFirst("validation." + ValidateHandler.Phase.AFTER_TRANSFORM,

                new ValidateHandler(_validatorRegistry, ValidateHandler.Phase.AFTER_TRANSFORM));

and the name of property - identifying Validator - contains Phase name (ExchangeImpl#initInValidator()).

            _context.setProperty(

                    Validator.class.getName() + "." + ValidateHandler.Phase.BEFORE_TRANSFORM,

                    exchangeInputType,

                    Scope.IN);

looks not so clean and this may make issue when they are handled via config. Is there any better way?

Thanks,

Tomo

[igarashitm]

added testcases.

https://github.com/igarashitm/core/commit/412aa94a7afe591f395d705df35aeb02e3bcfa7b

https://github.com/igarashitm/core/commit/a5d0ae7ffd7c4c977ddfb56cee0d5adad3d0b2ff

I have noticed the ValidateHandler should not know about "Phase" because managing dependency between handlers is DomainImpl's responsibility, so moved "Phase" enum into DomainImpl. ValidateHandler is just given a String for property suffix which identify the corresponding Validator.

[igarashitm]

All builds successfully completed on my env.

https://github.com/igarashitm/core/tree/SWITCHYARD-492

https://github.com/igarashitm/core/commit/a5d0ae7ffd7c4c977ddfb56cee0d5adad3d0b2ff

https://github.com/igarashitm/release/tree/SWITCHYARD-492

https://github.com/igarashitm/release/commit/eadc5460cb2aaf50ec9b59e3cb34defd83224e76

Once 0.3 is released, I'll rebase it again on latest upstream and trigger pull request.