Sergey,
Exactly, this plugin provides the beanvalidation annotations for
complextypes at the client + server side, making BeanValidation possible
on both sides.
What is missing so far:
1.) Necessary: Add a switch to wadl2java to allow adding @Valid to the
method + parameters for generated methods, to enable automatic validation
2.) Nice to have: Add BeanValidation annotation support to
wadl2java/SourceGenerator.java for the query parameters
These are currently not covered by the krasa-jaxb-tools, as they seem to
be handled completely separate from the JAXB processing.
see https://github.com/apache/cxf/pull/146/files, SourceGenerator.java
where I added @NotNull support;
Adding support for the others would require access to the complextypes
of the schema.
If you give me a hint how to access these effectively I can add the
other ones as well.
However, I'll try the schema validation approach as well, but I think it
would be nice to have both options available and leave it up to the
developer.
Best regards,
Johannes
Am 24.08.2016 um 18:49 schrieb Sergey Beryozkin:
Let me clarify -
https://github.com/krasa/krasa-jaxb-tools
what can it do ? Can you configure JAXB compiler with that plugin for
it to generate Beans with the bean validation annotations ?
I.e, is the only thing you are missing is having @Valid annotations
added to the generated methods ?
Cheers, Sergey
On 24/08/16 17:45, Sergey Beryozkin wrote:
Hi
On 24/08/16 17:36, J. Fiala wrote:
Hi,
I see the following cases when BeanValidation is preferable to schema
validation:
1.) if the error should be clearly associated to the property which
caused the error. This is possible with beanvalidation using the
propertypath, with xml schema validation error messages you usually get
the reference to the type but not the field which caused the error.
(e.g. cvc-pattern-valid: Value ''{0}'' is not facet-valid with respect
to pattern ''{1}'' for type ''{2}''.)
Where did you copy this message from ? Can you try CXF
JAXBElementProvider ?
2.) if the error message should be human readable / presented to the
end
user
ExceptionMapper can be used for it
3.) if the schema validation causes memory troubles e.g. with bigger
xml
requests with binary data in it (although this should be rarely the
case
with SAXParsers)
IMHO especially in case 1+2 it would be nice to use the beanvalidation,
especially if the rest api is directly tied to a ui.
It might be nice to have but it is difficult to see a compelling case at
the moment, especially if wadl-to-java is used to generate the
interfaces for the clients to consume some HTTP services - BeanVal won;t
be effective in the client side
Thanks, Sergey
Best regards,
Johannes
Am 23.08.2016 um 23:21 schrieb Sergey Beryozkin:
Hi
I'm not sure I'm understanding why is it needed.
If we have a WADL-first approach which is where wadl-to-java becomes
useful, one can properly design XML schema (have all the restrictions
specified as needed). Then import this schema as a WADL grammar to
generate the JAXB beans and then use the same schema to enforce the
JAXB-level schema validation which will work on the client and on the
server sides.
FYI, you can configure CXF JAXBElementProvider with XML schema
references.
Cheers, Sergey
On 23/08/16 18:03, J. Fiala wrote:
Hi,
CXF supports bean validation, however wadl2java doesn't support any
bean
validation annotations yet (see
https://github.com/krasa/krasa-jaxb-tools for the implementation for
complex parameters).
As it is not allowed to add @Valid to the method signatures of the
implementation classes, the @Valid annotation needs to be added to
the
interface (which is generated using wadl2java).
Are there any plans to add @Valid-support to wadl2java (for methods +
complex parameters)?
Best regards,
Johannes
