[jira] [Comment Edited] (CXF-5052) Classpath references should be understood using wsdlRoot batch processing options in cxf-codegen
[ https://issues.apache.org/jira/browse/CXF-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369786#comment-16369786 ] Oliver edited comment on CXF-5052 at 2/20/18 7:50 AM: -- [~dkulp] Are there any plans to resolve this issue or is there some workaround? We currently use the cxf-codegen-plugin to generate classes for over 50 wsdl files in one project. If we use the wsdl path is generated with the local path (i. e. [file:/C:/path/to/my.wsdl|file:///C:/path/to/my.wsdl]) in the java classes. We use the following configuration: {code:java} org.apache.cxf cxf-codegen-plugin 3.2.2 generate-wsdl generate-sources ${project.build.directory}/generated/cxf ${basedir}/src/main/resources/Service/ **/*.wsdl **/*Abstract* -impl -server -client wsdl2java {code} was (Author: oli_ver): [~dkulp] Are there any plans to resolve this issue or is there some workaround? We currently use the cxf-codegen-plugin to generate classes for over 50 wsdl files in one project. If we use the wsdl path is generated with the local path (i. e. file:/C:/path/to/my.wsdl) in the java classes. We use the following configuration: {code:java} org.apache.cxf cxf-codegen-plugin 3.2.2 generate-wsdl generate-sources ${project.build.directory}/generated/cxf ${basedir}/src/main/resources/Service/ **/*.wsdl **/*Abstract* -impl -server -client wsdl2java {code} > Classpath references should be understood using wsdlRoot batch processing > options in cxf-codegen > > > Key: CXF-5052 > URL: https://issues.apache.org/jira/browse/CXF-5052 > Project: CXF > Issue Type: Improvement > Components: Tooling >Affects Versions: 2.7.5 > Environment: All >Reporter: Zach Melnick >Priority: Major > > The generated client code should be able to reference a relative classpath > rather than an absolute one when using the wsdlRoot option to generate > clients and services via the cxf-codegen plugin. > Relative classpaths can be specified when using the non-batch processing > wsdlLocation options. This can be done when using something like > classpath:wsdl/foo.wsdl. > However, using the classpath reference in wsdlRoot does not work in the same > fashion. > classpath:wsdl/ should be able to find the wsdl > directory in ${basedir}/src/main/resources/wsdl, and generate the clients > with a wsdlLocation value relative to the classpath, making the behavior > between and consistant. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-5052) Classpath references should be understood using wsdlRoot batch processing options in cxf-codegen
[ https://issues.apache.org/jira/browse/CXF-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369786#comment-16369786 ] Oliver commented on CXF-5052: - [~dkulp] Are there any plans to resolve this issue or is there some workaround? We currently use the cxf-codegen-plugin to generate classes for over 50 wsdl files in one project. If we use the wsdl path is generated with the local path (i. e. file:/C:/path/to/my.wsdl) in the java classes. We use the following configuration: {code:java} org.apache.cxf cxf-codegen-plugin 3.2.2 generate-wsdl generate-sources ${project.build.directory}/generated/cxf ${basedir}/src/main/resources/Service/ **/*.wsdl **/*Abstract* -impl -server -client wsdl2java {code} > Classpath references should be understood using wsdlRoot batch processing > options in cxf-codegen > > > Key: CXF-5052 > URL: https://issues.apache.org/jira/browse/CXF-5052 > Project: CXF > Issue Type: Improvement > Components: Tooling >Affects Versions: 2.7.5 > Environment: All >Reporter: Zach Melnick >Priority: Major > > The generated client code should be able to reference a relative classpath > rather than an absolute one when using the wsdlRoot option to generate > clients and services via the cxf-codegen plugin. > Relative classpaths can be specified when using the non-batch processing > wsdlLocation options. This can be done when using something like > classpath:wsdl/foo.wsdl. > However, using the classpath reference in wsdlRoot does not work in the same > fashion. > classpath:wsdl/ should be able to find the wsdl > directory in ${basedir}/src/main/resources/wsdl, and generate the clients > with a wsdlLocation value relative to the classpath, making the behavior > between and consistant. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7651) SOAP, strange behaviour, attibute value is converted from 0x0d 0x0a to 0x22
[ https://issues.apache.org/jira/browse/CXF-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vittorio Zinno updated CXF-7651: Attachment: (was: image-2018-02-19-18-27-30-612.png) > SOAP, strange behaviour, attibute value is converted from 0x0d 0x0a to 0x22 > --- > > Key: CXF-7651 > URL: https://issues.apache.org/jira/browse/CXF-7651 > Project: CXF > Issue Type: Bug >Affects Versions: 3.2.2 >Reporter: Vittorio Zinno >Priority: Major > Attachments: image-2018-02-19-18-27-37-944.png, > image-2018-02-19-18-54-03-107.png, image-2018-02-19-18-55-28-697.png > > > It's about SOAP. > The value of this attribute is changed. > > Example > DB > !image-2018-02-19-18-54-03-107.png! > CORRECT > Version with cxf-core-3.2.1.jar > !image-2018-02-19-18-55-28-697.png! > > WRONG > Version with cxf-core-3.2.2.jar > !image-2018-02-19-18-27-30-612.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7651) SOAP, strange behaviour, attibute value is converted from 0x0d 0x0a to 0x22
[ https://issues.apache.org/jira/browse/CXF-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vittorio Zinno updated CXF-7651: Description: It's about SOAP. The value of this attribute is changed. Example DB !image-2018-02-19-18-54-03-107.png! CORRECT Version with cxf-core-3.2.1.jar !image-2018-02-19-18-55-28-697.png! WRONG Version with cxf-core-3.2.2.jar !image-2018-02-19-18-27-30-612.png! was: It's about SOAP. The value of this attribute is changed. Example DB !image-2018-02-19-18-54-03-107.png! Version with cxf-core-3.2.2.jar !image-2018-02-19-18-55-28-697.png! Version with cxf-core-3.2.1.jar !image-2018-02-19-18-27-30-612.png! > SOAP, strange behaviour, attibute value is converted from 0x0d 0x0a to 0x22 > --- > > Key: CXF-7651 > URL: https://issues.apache.org/jira/browse/CXF-7651 > Project: CXF > Issue Type: Bug >Affects Versions: 3.2.2 >Reporter: Vittorio Zinno >Priority: Major > Attachments: image-2018-02-19-18-27-30-612.png, > image-2018-02-19-18-27-37-944.png, image-2018-02-19-18-54-03-107.png, > image-2018-02-19-18-55-28-697.png > > > It's about SOAP. > The value of this attribute is changed. > > Example > DB > !image-2018-02-19-18-54-03-107.png! > CORRECT > Version with cxf-core-3.2.1.jar > !image-2018-02-19-18-55-28-697.png! > > WRONG > Version with cxf-core-3.2.2.jar > !image-2018-02-19-18-27-30-612.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7651) SOAP, strange behaviour, attibute value is converted from 0x0d 0x0a to 0x22
Vittorio Zinno created CXF-7651: --- Summary: SOAP, strange behaviour, attibute value is converted from 0x0d 0x0a to 0x22 Key: CXF-7651 URL: https://issues.apache.org/jira/browse/CXF-7651 Project: CXF Issue Type: Bug Affects Versions: 3.2.2 Reporter: Vittorio Zinno Attachments: image-2018-02-19-18-27-30-612.png, image-2018-02-19-18-27-37-944.png, image-2018-02-19-18-54-03-107.png, image-2018-02-19-18-55-28-697.png It's about SOAP. The value of this attribute is changed. Example DB !image-2018-02-19-18-54-03-107.png! Version with cxf-core-3.2.2.jar !image-2018-02-19-18-55-28-697.png! Version with cxf-core-3.2.1.jar !image-2018-02-19-18-27-30-612.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7640) Create a form to set the use of Spring in the classHelper on a per client way
[ https://issues.apache.org/jira/browse/CXF-7640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369306#comment-16369306 ] Osvaldo Pina commented on CXF-7640: --- I will explore the message property solution. But I need some help. Sorry If the questions are too basic: * The overall idea is to set a message property and check its value at ClassHelper with Message.getContextualProperty? If so how can set a message property? * Why not set a Bus property? Getting the property via BusFactory.getThreadDefaultBus() and then Call setProperty and at ClassHelper do the same and then call getProperty? > Create a form to set the use of Spring in the classHelper on a per client way > -- > > Key: CXF-7640 > URL: https://issues.apache.org/jira/browse/CXF-7640 > Project: CXF > Issue Type: Improvement > Components: Core >Reporter: Osvaldo Pina >Priority: Major > Attachments: cxf7640.txt > > > The solution for CXF-6191 allows for configuration of the use of Spring in > ClassHelper in a per vm way via System property. Would be nice to have a way > to configure it in a per instance way (or, at least, in a per classloader way) > > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7650) CXF WS-Provider returns http 200 although an error occurred
Kai Rommel created CXF-7650: --- Summary: CXF WS-Provider returns http 200 although an error occurred Key: CXF-7650 URL: https://issues.apache.org/jira/browse/CXF-7650 Project: CXF Issue Type: Bug Components: Core Affects Versions: 3.2.2 Reporter: Kai Rommel Attachments: 0001-WS-Provider-handles-exception-in-fault-handling-and-.patch Hi, I am faced with the issue, that a CXF WS-Provider returns a http 200, although an error within the WS-Provider occurred. ### Error within the WS-Provider [ qtp1256350655-27] PhaseInterceptorChain DEBUG Invoking handleFault on interceptor org.apache.cxf.ws.policy.ServerPolicyOutFaultInterceptor@53236355 [ qtp1256350655-27] PhaseInterceptorChain WARN Application \{http://cxf.apache.org/hello_world_soap_http}GreeterService#\{http://cxf.apache.org/hello_world_soap_http}greetMe has thrown exception, unwinding now org.apache.cxf.interceptor.Fault: No configured signature username detected at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:237) at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.handleBinding(AsymmetricBindingHandler.java:117) at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessageInternal(PolicyBasedWSS4JOutInterceptor.java:185) at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:109) at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:96) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:112) at org.apache.cxf.phase.PhaseInterceptorChain.wrapExceptionAsFault(PhaseInterceptorChain.java:374) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:332) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267) at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:247) at org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:79) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:190) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:170) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.Server.handle(Server.java:530) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:347) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:256) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626) at java.lang.Thread.run(Thread.java:748) Caused by: org.apache.cxf.ws.policy.PolicyException: No configured signature username detected at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractCommonBindingHandler.unassertPolicy(AbstractCommonBindingHandler.java:92) at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.getSignatureBuilder(AbstractBindingBuilder.java:1863) at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignature(AsymmetricBindingHandler.java:721) at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBefor