[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=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=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] [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] [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
