2016-03-23 18:26 GMT+04:00 Sergey Beryozkin :
>
> I'm not sure what happens when you use @SchemaValidation and no schema
> holder. Can you please put a breakpoint in AbstractJaxbProvider.init() and
> see how SchemaValidation is processed. I can imagine that a schema will be
2016-03-23 15:48 GMT+04:00 Sergey Beryozkin :
> Thanks for the analysis and the patch, I'm traveling so will look into it
> in detail next week (though might apply the patch earlier), does your patch
> addresses all of your concerns you raised in this thread ?
>
>
Yes,
Thanks for the analysis and the patch, I'm traveling so will look into
it in detail next week (though might apply the patch earlier), does your
patch addresses all of your concerns you raised in this thread ?
Cheers, Sergey
On 23/03/16 08:21, Vjacheslav V. Borisov wrote:
Don't know, how
> Don't know, how should this fixed (or should not)
> E.g. , code like this could fix that, but seems ugly:
> resolvedLocation =
> catalogResolver.resolvePublic(publicId!=null?publicId:namespaceURI,
> systemId);
>
>
Found where it takes place in case of cxf-wadl2java-plugin,
please see
Also noticed following :
When wadl2java code generation resolves
using xml-resolver, it resolves it using publicId using this record in
catalog.xml
This is the code:
class org.apache.xml.resolver.Catalog, method resolveLocalPublic,
while (en.hasMoreElements()) {
...
if
Found workaround, removed @SchemaValidation annotaion and configured both
providers in spring, so unconfigured copies now do not crash.
Also noticed that
http://cxf.apache.org/docs/jax-rs-data-bindings.html#JAX-RSDataBindings-Schemavalidation
contains deprecated
name="schemas" should be
Playing with xml catalogs, found strage bug (or my misconfiguration, i
don't know)
When i place my catalog on default DEFAULT_CATALOG_LOCATION
(classpath:META-INF/jax-rs-catalog.xml),
it works in @SchemaValidation feature
but if I want to rename to custom location, eg
...
(and