Re: CXF3 WadlGenerator @Description generates doc-tag

On 17/08/16 18:28, J. Fiala wrote: The WadlGenerator currently generates @Description comments as . These are invalid for schemas. The correct tags for comments in schemas are ... IMHO this should be corrected. Wait :-), @Description is a WADL:doc and a WADL schema supports it just fine

Re: CXF3 - Annotations in the interface are not parsed

Hmm is it somehow related to that Swagger related issue ? The interface annotation inheritance works just fine in CXF as far as I know, as far as enabling JAX-RS endpoints is concerned Note we've seen users reporting Swagger2feature can not handle it but a user has just confirmed that it

Re: WadlGenerator - Bean validation support for complex types?

Hi Can you explain please what exactly the purpose of it can be ? WADL generator simply reports the model info by using a JAXB compiler to generate XML schema, I'm trying to figure out how does the bean validation can help here or what it can change Sergey On 17/08/16 18:18, J. Fiala wrote:

Re: CXF JAXRS wadl2java - ObjectFactory.java causes MarshalException

Looks like you have CXF JSONProvider loaded... Sergey On 17/08/16 17:53, J. Fiala wrote: I'm using wadl2java to generate api and model classes from a WADL (CXF 3.1.6). I'm using the JacksonProvider in the client call: JacksonJsonProvider provider = new JacksonJsonProvider(); List providers =

Re: Spring Boot CXF JAX-RS and Jackson Provider

Hi Oh, I thought SpringBoot made XML config a history :-) I'll need to document it at CXF SpringBoot wiki page. Can you give me a favor and double check that you have no Jettison library somewhere on the classpath ? If it is available then CXF will auto-create its own CXF JSONProvider which

CXF3 DataHandler not supported in WADL

Example for DataHandler not supported in WADL: @Consumes({ MediaType.MULTIPART_FORM_DATA }) @Produces({ MediaType.APPLICATION_JSON }) @POST @Path("/helloMultipart") public void helloMultipart(@Multipart(value= "payload" , type=MediaType.APPLICATION_OCTET_STREAM) DataHandler

CXF3 wadl2java SourceGenerator does not support BeanValidation for query parameters

Currently the wadl2java SourceGenerator (cxf-tools-wadlto-jaxrs) does not support BeanValidation for query parameters I added the support of @NotNull to SourceGenerator.java to start with (see https://github.com/apache/cxf/pull/146, SourceGenerator.java). However, to add

CXF3 wadl2java - SourceGenerator does not support BeanValidation

CXF3 wadl2java SourceGenerator does not support BeanValidation for request/response structures BeanValidation support for request/response structures has been added in this extension to the cxf-wadl2java-plugin: https://github.com/jfiala/krasa-jaxb-tools It would be nice if this can somehow

CXF3 WadlGenerator @Description generates doc-tag

The WadlGenerator currently generates @Description comments as . These are invalid for schemas. The correct tags for comments in schemas are ... IMHO this should be corrected. Best regards, Johannes

CXF3 - Annotations in the interface are not parsed

Currently annotations in the interface are not parsed by CXF (e.g. @Path, @GET, @Produces, @Consumes etc.), it will only read from the implementing API class. This is especially annoying if wadl2java is used to generate the API interfaces automatically. To make it work, one has to manually

WadlGenerator - Bean validation support for complex types?

I added this PR for bean-validation-support for query parameters: https://github.com/apache/cxf/pull/146 This also adds the required-flag for params by supporting @NotNull (see related question here:

Re: Spring Boot CXF JAX-RS and Jackson Provider

Sergey, Thank you for the quick response! I'm using cxf-spring-boot-starter-jaxrs 3.1.7 with Spring Boot 1.3.3.RELEASE. You only have to add the XML using @ImportResource, then it is working immediately: @ImportResource({"classpath:/mySpringContext.xml"}) @EnableAutoConfiguration public

CXF JAXRS wadl2java - ObjectFactory.java causes MarshalException

I'm using wadl2java to generate api and model classes from a WADL (CXF 3.1.6). I'm using the JacksonProvider in the client call: JacksonJsonProvider provider = new JacksonJsonProvider(); List providers = new ArrayList(); providers.add(provider); api = JAXRSClientFactory.create(serverApp,

Re: Spring Boot CXF JAX-RS and Jackson Provider

Hi To be honest I'm not sure traditional Spring XML configuration files are even supported with Spring Boot ? (XML is the old citizen, properties is the new citizen :-)), but if it is then let me know how. Are you using CXF 3.1.7 Spring Boot starter ? I think you need to have a @Bean method

Spring Boot CXF JAX-RS and Jackson Provider

I try to run a CXF JAX-RS endpoint using Spring XML configuration and Spring Boot. The services are listed correctly when I access the server and the WADL/Swagger endpoint is generated correctly: http://localhost:8080/services/ The API methods are annoted with:

Re: default encoding in LoggingInInterceptor

On 17.08.2016 16:06, Sergey Beryozkin wrote: As I said the intermediate change I proposed for 3.2.0 will help users start working with your interceptors *faster*. The fact that 2 users in this thread have been 'surprised' by new logging interceptors should send a message that lots of users

Re: default encoding in LoggingInInterceptor

By the way, Christian, I did not mean my -1 be binding, was simply 'a disagree'. If other colleagues think removing the core interceptors in 3.2.0 is warranted then I'll support the majority decision. Thanks, Sergey On 17/08/16 15:06, Sergey Beryozkin wrote: Hi Christian On 17/08/16 14:25,

Re: default encoding in LoggingInInterceptor

Hi Christian On 17/08/16 14:25, Christian Schneider wrote: On 17.08.2016 15:17, Sergey Beryozkin wrote: On 17/08/16 14:13, Christian Schneider wrote: On 17.08.2016 15:08, Sergey Beryozkin wrote: Letting the old classes extend the new ones is also not possible as core can not depend on the

Re: default encoding in LoggingInInterceptor

On 17.08.2016 15:17, Sergey Beryozkin wrote: On 17/08/16 14:13, Christian Schneider wrote: On 17.08.2016 15:08, Sergey Beryozkin wrote: Letting the old classes extend the new ones is also not possible as core can not depend on the logging feature jar. Then we need to solve it

Re: default encoding in LoggingInInterceptor

On 17/08/16 14:13, Christian Schneider wrote: On 17.08.2016 15:08, Sergey Beryozkin wrote: Letting the old classes extend the new ones is also not possible as core can not depend on the logging feature jar. Then we need to solve it differently. Move the ext code into the core and have the

Re: default encoding in LoggingInInterceptor

On 17.08.2016 15:08, Sergey Beryozkin wrote: Letting the old classes extend the new ones is also not possible as core can not depend on the logging feature jar. Then we need to solve it differently. Move the ext code into the core and have the ext interceptors and feature simply extend that

Re: default encoding in LoggingInInterceptor

On 17/08/16 13:57, Christian Schneider wrote: On 17.08.2016 14:48, Sergey Beryozkin wrote: On 17/08/16 13:36, Christian Schneider wrote: I think logging is not a core element of CXF so I would like to move it out of cxf core. This is why I created the new logging in a separate module. that is

Re: default encoding in LoggingInInterceptor

On 17.08.2016 14:48, Sergey Beryozkin wrote: On 17/08/16 13:36, Christian Schneider wrote: I think logging is not a core element of CXF so I would like to move it out of cxf core. This is why I created the new logging in a separate module. that is fine, you mean rt/features/logging, it is fine

Re: default encoding in LoggingInInterceptor

On 17/08/16 13:36, Christian Schneider wrote: I think logging is not a core element of CXF so I would like to move it out of cxf core. This is why I created the new logging in a separate module. that is fine, you mean rt/features/logging, it is fine 3.2.0 is a minor release. So I am not sure

Re: default encoding in LoggingInInterceptor

I think logging is not a core element of CXF so I would like to move it out of cxf core. This is why I created the new logging in a separate module. 3.2.0 is a minor release. So I am not sure if we should remove something like logging from core in this release. We could try to merge the old

Re: default encoding in LoggingInInterceptor

Never mind looks like it is documented on CXF wiki :-). Let me add default constructors. But for 3.2.0 - Christian, might be worse considering just removing the old interceptors, and moving the ext logging code into the original package, think about it please. It would require the least

Re: default encoding in LoggingInInterceptor

Hi Christian, Why can't the existing/original loggers be modified instead of starting a migration effort from one package to another package ? What are the side-effects you are referring too ? Having a default constructor is needed for sure - one can just to default to whatever is required.

Re: default encoding in LoggingInInterceptor

Initially I planned to remove the old logging support completely but the effects on existing users were to big. So I kept both for now but on the long run we should remove the old logging support. As the new logging is in a separate module I was not able to change the old logging to use the

Re: default encoding in LoggingInInterceptor

Oh, I did not know we have two LoggingIn/OutInterceptor classes... Why can;t have a single LoggingInInterceptor with as many constructors as needed ? Sergey On 17/08/16 12:55, Christian Schneider wrote: If you want to use the LoggingInInterceptor then you have to inject the constructor with a

Re: default encoding in LoggingInInterceptor

If you want to use the LoggingInInterceptor then you have to inject the constructor with a LogEventSender. This allows to use the interceptor with something different than slf4j. Christian On 17.08.2016 12:52, Vjacheslav V. Borisov wrote: 2016-08-17 11:19 GMT+04:00 Christian Schneider

Re: default encoding in LoggingInInterceptor

2016-08-17 11:19 GMT+04:00 Christian Schneider : > You should also take a look at the new Logging support in: > https://github.com/apache/cxf/tree/master/rt/features/logging > > http://www.liquid-reality.de/display/liquid/2015/06/08/Enter >

Re: Swagger2Feature not finding @Api annotations in interfaces

I've updated Swagger2Feature to set media types for all the resources found in the latest 2.1.8-M1 swagger-ui distro OOB but it is also configurable with a map of extension-to-mediaTypes if needed. Give 3.1.8-SNAPSHOT a try next week please - hopefully it will eliminate any issues some

Re: default encoding in LoggingInInterceptor

On 17.08.2016 10:56, Sergey Beryozkin wrote: Hi The problem which affects Logging interceptors is that default HTTP 1.1 encoding is ISO-8859-1 but the actual HTTP Encoding header and this default value is very old. CXF server sets Encoding and it is not needed - if the consumer needs a

Re: default encoding in LoggingInInterceptor

Hi The problem which affects Logging interceptors is that default HTTP 1.1 encoding is ISO-8859-1 but the actual HTTP Encoding header and this default value is very old. CXF server sets Encoding and it is not needed - if the consumer needs a default value then it does not need Encoding

Re: default encoding in LoggingInInterceptor

I think it will assume the system default charset as default. So you could try to change that. See https://javarevisited.blogspot.de/2012/01/get-set-default-character-encoding.html Chistian On 17.08.2016 10:19, Vjacheslav V. Borisov wrote: 2016-08-17 11:19 GMT+04:00 Christian Schneider

Re: default encoding in LoggingInInterceptor

2016-08-17 11:19 GMT+04:00 Christian Schneider : > You should also take a look at the new Logging support in: > https://github.com/apache/cxf/tree/master/rt/features/logging > > http://www.liquid-reality.de/display/liquid/2015/06/08/Enter >

Re: default encoding in LoggingInInterceptor

You should also take a look at the new Logging support in: https://github.com/apache/cxf/tree/master/rt/features/logging http://www.liquid-reality.de/display/liquid/2015/06/08/Enterprise+ready+request+logging+with+CXF+3.1.0+and+elastic+search The new logging feature should also make it easier

Re: default encoding in LoggingInInterceptor

2016-08-16 13:58 GMT+04:00 Sergey Beryozkin : > Hi > > I'm still planning to investigate why only the out logging interceptor on > the server side which is being affected > Thanks, Sergey. out logging interceptor is working with utf-8, I have problems with