[jira] [Created] (CXF-7066) Ability to set extensionMappings with Spring Boot properties
Kiriakos Vadaloukas created CXF-7066: Summary: Ability to set extensionMappings with Spring Boot properties Key: CXF-7066 URL: https://issues.apache.org/jira/browse/CXF-7066 Project: CXF Issue Type: Improvement Reporter: Kiriakos Vadaloukas Priority: Minor Add the ability to set extensionMappings with Spring Boot CxfProperties. I tried this with no luck: cxf.servlet.init.jaxrs.extensions=json=application/json Old XML configuration example: jaxrs.extensions xml=application/xml json=application/json -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-7064) DelegatingXMLStreamWriter.writeCData(text) writes several CDATA sections for a signed XML file
[
https://issues.apache.org/jira/browse/CXF-7064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-7064:
-
Description:
HI,
When implementing a CDATA interceptor in order to include a signed XML file in
a SOAP envelope, we are getting several CDATA sections in the XML that makes
the service reject the envelope:
{code:java}
import java.util.regex.Pattern;
import javax.xml.stream.XMLStreamException;
import javax.xml.stream.XMLStreamWriter;
import org.apache.cxf.staxutils.DelegatingXMLStreamWriter;
/**
* Simple CDATA XML Stream Writer that exports some items as CDATA
*/
public class CDataXMLStreamWriter extends DelegatingXMLStreamWriter {
private static final Pattern XML_CHARS = Pattern.compile( "[&<>]" );
private static final String CDataOpen = "";
public CDataXMLStreamWriter(XMLStreamWriter del) {
super(del);
}
@Override
public void writeCharacters(String text) throws XMLStreamException {
boolean useCData = XML_CHARS.matcher( text ).find();
if (useCData) {
//super.writeCharacters(CDataOpen);
System.out.println("text" + text);
//super.writeCharacters(text);
//super.writeCharacters(CDataClose);
super.writeCData(text);
}else {
super.writeCharacters(text);
}
}
public void writeStartElement(String local) throws XMLStreamException {
super.writeStartElement(local);
}
}
{code:java}
That's urgent to solve this for us.
This is an example of the unwanted output:
{code:xml}
EwJVWTErMCkGA1UECgwiQURNSU5JU1RSQUNJT04gTkFDSU9OQUwgREUgQ09SUk]]>
{code:xml}
was:
HI,
When implementing a CDATA interceptor in order to include a signed XML file in
a SOAP envelope, we are getting several CDATA sections in the XML that makes
the service reject the envelope:
import java.util.regex.Pattern;
import javax.xml.stream.XMLStreamException;
import javax.xml.stream.XMLStreamWriter;
import org.apache.cxf.staxutils.DelegatingXMLStreamWriter;
/**
* Simple CDATA XML Stream Writer that exports some items as CDATA
*/
public class CDataXMLStreamWriter extends DelegatingXMLStreamWriter {
private static final Pattern XML_CHARS = Pattern.compile( "[&<>]" );
private static final String CDataOpen = "";
public CDataXMLStreamWriter(XMLStreamWriter del) {
super(del);
}
@Override
public void writeCharacters(String text) throws XMLStreamException {
boolean useCData = XML_CHARS.matcher( text ).find();
if (useCData) {
//super.writeCharacters(CDataOpen);
System.out.println("text" + text);
//super.writeCharacters(text);
//super.writeCharacters(CDataClose);
super.writeCData(text);
}else {
super.writeCharacters(text);
}
}
public void writeStartElement(String local) throws XMLStreamException {
super.writeStartElement(local);
}
}
That's urgent to solve this for us.
This is an example of the unwanted output:
EwJVWTErMCkGA1UECgwiQURNSU5JU1RSQUNJT04gTkFDSU9OQUwgREUgQ09SUk]]>
> DelegatingXMLStreamWriter.writeCData(text) writes several CDATA sections for
> a signed XML file
> --
>
> Key: CXF-7064
> URL: https://issues.apache.org/jira/browse/CXF-7064
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.1.7
> Environment: windows 7/ linux centos 6
>Reporter: Javier Irazazábal
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> HI,
> When implementing a CDATA interceptor in order to include a signed XML file
> in a SOAP envelope, we are getting several CDATA sections in the XML that
> makes the service reject the envelope:
> {code:java}
> import java.util.regex.Pattern;
> import javax.xml.stream.XMLStreamException;
> import javax.xml.stream.XMLStreamWriter;
> import org.apache.cxf.staxutils.DelegatingXMLStreamWriter;
>
> /**
> * Simple CDATA XML Stream Writer that exports some items as CDATA
> */
> public class CDataXMLStreamWriter extends DelegatingXMLStreamWriter {
>
> private static final Pattern XML_CHARS = Pattern.compile( "[&<>]" );
> private static final String CDataOpen = "";
>
> public CDataXMLStreamWriter(XMLStreamWriter del) {
> super(del);
> }
> @Override
> public void writeCharacters(String text) throws XMLStreamException {
> boolean useCData = XML_CHARS.matcher( text ).find();
> if (useCData) {
> //super.writeCharacters(CDataOpen);
> System.out.println("text" + text);
> //super.writeCharacters(text);
> //super.writeC
[jira] [Updated] (CXF-7064) DelegatingXMLStreamWriter.writeCData(text) writes several CDATA sections for a signed XML file
[
https://issues.apache.org/jira/browse/CXF-7064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-7064:
-
Description:
HI,
When implementing a CDATA interceptor in order to include a signed XML file in
a SOAP envelope, we are getting several CDATA sections in the XML that makes
the service reject the envelope:
{code:java}
import java.util.regex.Pattern;
import javax.xml.stream.XMLStreamException;
import javax.xml.stream.XMLStreamWriter;
import org.apache.cxf.staxutils.DelegatingXMLStreamWriter;
/**
* Simple CDATA XML Stream Writer that exports some items as CDATA
*/
public class CDataXMLStreamWriter extends DelegatingXMLStreamWriter {
private static final Pattern XML_CHARS = Pattern.compile( "[&<>]" );
private static final String CDataOpen = "";
public CDataXMLStreamWriter(XMLStreamWriter del) {
super(del);
}
@Override
public void writeCharacters(String text) throws XMLStreamException {
boolean useCData = XML_CHARS.matcher( text ).find();
if (useCData) {
//super.writeCharacters(CDataOpen);
System.out.println("text" + text);
//super.writeCharacters(text);
//super.writeCharacters(CDataClose);
super.writeCData(text);
}else {
super.writeCharacters(text);
}
}
public void writeStartElement(String local) throws XMLStreamException {
super.writeStartElement(local);
}
}
{code:java}
That's urgent to solve this for us.
This is an example of the unwanted output:
EwJVWTErMCkGA1UECgwiQURNSU5JU1RSQUNJT04gTkFDSU9OQUwgREUgQ09SUk]]>
was:
HI,
When implementing a CDATA interceptor in order to include a signed XML file in
a SOAP envelope, we are getting several CDATA sections in the XML that makes
the service reject the envelope:
{code:java}
import java.util.regex.Pattern;
import javax.xml.stream.XMLStreamException;
import javax.xml.stream.XMLStreamWriter;
import org.apache.cxf.staxutils.DelegatingXMLStreamWriter;
/**
* Simple CDATA XML Stream Writer that exports some items as CDATA
*/
public class CDataXMLStreamWriter extends DelegatingXMLStreamWriter {
private static final Pattern XML_CHARS = Pattern.compile( "[&<>]" );
private static final String CDataOpen = "";
public CDataXMLStreamWriter(XMLStreamWriter del) {
super(del);
}
@Override
public void writeCharacters(String text) throws XMLStreamException {
boolean useCData = XML_CHARS.matcher( text ).find();
if (useCData) {
//super.writeCharacters(CDataOpen);
System.out.println("text" + text);
//super.writeCharacters(text);
//super.writeCharacters(CDataClose);
super.writeCData(text);
}else {
super.writeCharacters(text);
}
}
public void writeStartElement(String local) throws XMLStreamException {
super.writeStartElement(local);
}
}
{code:java}
That's urgent to solve this for us.
This is an example of the unwanted output:
{code:xml}
EwJVWTErMCkGA1UECgwiQURNSU5JU1RSQUNJT04gTkFDSU9OQUwgREUgQ09SUk]]>
{code:xml}
> DelegatingXMLStreamWriter.writeCData(text) writes several CDATA sections for
> a signed XML file
> --
>
> Key: CXF-7064
> URL: https://issues.apache.org/jira/browse/CXF-7064
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.1.7
> Environment: windows 7/ linux centos 6
>Reporter: Javier Irazazábal
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> HI,
> When implementing a CDATA interceptor in order to include a signed XML file
> in a SOAP envelope, we are getting several CDATA sections in the XML that
> makes the service reject the envelope:
> {code:java}
> import java.util.regex.Pattern;
> import javax.xml.stream.XMLStreamException;
> import javax.xml.stream.XMLStreamWriter;
> import org.apache.cxf.staxutils.DelegatingXMLStreamWriter;
>
> /**
> * Simple CDATA XML Stream Writer that exports some items as CDATA
> */
> public class CDataXMLStreamWriter extends DelegatingXMLStreamWriter {
>
> private static final Pattern XML_CHARS = Pattern.compile( "[&<>]" );
> private static final String CDataOpen = "";
>
> public CDataXMLStreamWriter(XMLStreamWriter del) {
> super(del);
> }
> @Override
> public void writeCharacters(String text) throws XMLStreamException {
> boolean useCData = XML_CHARS.matcher( text ).find();
> if (useCData) {
> //super.writeCharacters(CDataOpen);
> System.out.println("text" + text);
> //super.writeCharacters(text);
>
[jira] [Updated] (CXF-7064) DelegatingXMLStreamWriter.writeCData(text) writes several CDATA sections for a signed XML file
[
https://issues.apache.org/jira/browse/CXF-7064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-7064:
-
Description:
HI,
When implementing a CDATA interceptor in order to include a signed XML file in
a SOAP envelope, we are getting several CDATA sections in the XML that makes
the service reject the envelope:
{code:java}
import java.util.regex.Pattern;
import javax.xml.stream.XMLStreamException;
import javax.xml.stream.XMLStreamWriter;
import org.apache.cxf.staxutils.DelegatingXMLStreamWriter;
/**
* Simple CDATA XML Stream Writer that exports some items as CDATA
*/
public class CDataXMLStreamWriter extends DelegatingXMLStreamWriter {
private static final Pattern XML_CHARS = Pattern.compile( "[&<>]" );
private static final String CDataOpen = "";
public CDataXMLStreamWriter(XMLStreamWriter del) {
super(del);
}
@Override
public void writeCharacters(String text) throws XMLStreamException {
boolean useCData = XML_CHARS.matcher( text ).find();
if (useCData) {
//super.writeCharacters(CDataOpen);
System.out.println("text" + text);
//super.writeCharacters(text);
//super.writeCharacters(CDataClose);
super.writeCData(text);
}else {
super.writeCharacters(text);
}
}
public void writeStartElement(String local) throws XMLStreamException {
super.writeStartElement(local);
}
}
{code}
That's urgent to solve this for us.
This is an example of the unwanted output:
EwJVWTErMCkGA1UECgwiQURNSU5JU1RSQUNJT04gTkFDSU9OQUwgREUgQ09SUk]]>
was:
HI,
When implementing a CDATA interceptor in order to include a signed XML file in
a SOAP envelope, we are getting several CDATA sections in the XML that makes
the service reject the envelope:
{code:java}
import java.util.regex.Pattern;
import javax.xml.stream.XMLStreamException;
import javax.xml.stream.XMLStreamWriter;
import org.apache.cxf.staxutils.DelegatingXMLStreamWriter;
/**
* Simple CDATA XML Stream Writer that exports some items as CDATA
*/
public class CDataXMLStreamWriter extends DelegatingXMLStreamWriter {
private static final Pattern XML_CHARS = Pattern.compile( "[&<>]" );
private static final String CDataOpen = "";
public CDataXMLStreamWriter(XMLStreamWriter del) {
super(del);
}
@Override
public void writeCharacters(String text) throws XMLStreamException {
boolean useCData = XML_CHARS.matcher( text ).find();
if (useCData) {
//super.writeCharacters(CDataOpen);
System.out.println("text" + text);
//super.writeCharacters(text);
//super.writeCharacters(CDataClose);
super.writeCData(text);
}else {
super.writeCharacters(text);
}
}
public void writeStartElement(String local) throws XMLStreamException {
super.writeStartElement(local);
}
}
{code:java}
That's urgent to solve this for us.
This is an example of the unwanted output:
EwJVWTErMCkGA1UECgwiQURNSU5JU1RSQUNJT04gTkFDSU9OQUwgREUgQ09SUk]]>
> DelegatingXMLStreamWriter.writeCData(text) writes several CDATA sections for
> a signed XML file
> --
>
> Key: CXF-7064
> URL: https://issues.apache.org/jira/browse/CXF-7064
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.1.7
> Environment: windows 7/ linux centos 6
>Reporter: Javier Irazazábal
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> HI,
> When implementing a CDATA interceptor in order to include a signed XML file
> in a SOAP envelope, we are getting several CDATA sections in the XML that
> makes the service reject the envelope:
> {code:java}
> import java.util.regex.Pattern;
> import javax.xml.stream.XMLStreamException;
> import javax.xml.stream.XMLStreamWriter;
> import org.apache.cxf.staxutils.DelegatingXMLStreamWriter;
>
> /**
> * Simple CDATA XML Stream Writer that exports some items as CDATA
> */
> public class CDataXMLStreamWriter extends DelegatingXMLStreamWriter {
>
> private static final Pattern XML_CHARS = Pattern.compile( "[&<>]" );
> private static final String CDataOpen = "";
>
> public CDataXMLStreamWriter(XMLStreamWriter del) {
> super(del);
> }
> @Override
> public void writeCharacters(String text) throws XMLStreamException {
> boolean useCData = XML_CHARS.matcher( text ).find();
> if (useCData) {
> //super.writeCharacters(CDataOpen);
> System.out.println("text" + text);
> //super.writeCharacters(text);
> //super.writeC
[jira] [Resolved] (CXF-7062) wsdl2java generates incorrect @XmlElement(namespace=“…”)
[ https://issues.apache.org/jira/browse/CXF-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-7062. -- Resolution: Not A Problem Assignee: Daniel Kulp Fix Version/s: Invalid The "status" elements are within the element the has a targetNamespace of http://v1_0_0.parameters.provider.soap.common.masterdata.rps.com and elementFormDefault="qualified" . Thus, they SHOULD have that namespace on the XmlElement as per spec. This is working correctly. The "type" parameter on the element (and it's namespace) has NO bearing on the namespace of the element itself. > wsdl2java generates incorrect @XmlElement(namespace=“…”) > > > Key: CXF-7062 > URL: https://issues.apache.org/jira/browse/CXF-7062 > Project: CXF > Issue Type: Bug > Components: Soap Binding >Affects Versions: 3.1.7 > Environment: MacOSX 10.11, Java v1.8 >Reporter: Randy Leonard >Assignee: Daniel Kulp >Priority: Blocker > Fix For: Invalid > > > I am using Apache CXF 3.1.7, and the wsdl2java command is generating code > with missing/incorrect namespace attributes on the @XMLEment annotation. > Note I generally use four distinct namespaces within each WSDL document, > which are as follows: > • Shared data types across many WSDL documents > (http://v1_0_0.datatypes.provider.soap.foundation.rps.com) > • Domain-specific data types > (http://v1_0_0.datatypes.provider.soap.common.masterdata.rps.com) > • Parameter types > (http://v1_0_0.parameters.provider.soap.common.masterdata.rps.com) > • Service types (http://v1_0_0.provider.soap.common.masterdata.rps.com) > This gives a nice separation of data types, and has worked quite well for me > with Axis2. I am having issues, however, when applying this approach to CXF. > Below is an example WSDL document with the namespaces defined above: > ——— > > targetNamespace="http://v1_0_0.provider.soap.common.masterdata.rps.com"; > xmlns:foundationTypes="http://v1_0_0.datatypes.provider.soap.foundation.rps.com"; > > xmlns:masterdataCommonTypes="http://v1_0_0.datatypes.provider.soap.common.masterdata.rps.com"; > xmlns:parameter="http://v1_0_0.parameters.provider.soap.common.masterdata.rps.com"; > xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; > xmlns:tns="http://v1_0_0.provider.soap.common.masterdata.rps.com"; > xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"; > xmlns:xs="http://www.w3.org/2001/XMLSchema"; > xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap12/"; > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; > xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/";> > >elementFormDefault="qualified" > targetNamespace="http://v1_0_0.parameters.provider.soap.common.masterdata.rps.com"; > > >namespace="http://v1_0_0.datatypes.provider.soap.foundation.rps.com"; > schemaLocation="schemas/FoundationTypes.xsd" /> >namespace="http://v1_0_0.datatypes.provider.soap.common.masterdata.rps.com"; > schemaLocation="schemas/MasterDataCommonTypes.xsd" /> > > > > > >name="paymentSchemeId" type="xs:string" minOccurs="0" /> >type="xs:string" minOccurs="0" /> > > > > > > > > >type="foundationTypes:Status" /> >type="masterdataCommonTypes:ConsumerChannel" minOccurs="0" > maxOccurs="unbounded" /> > > > > > > > > >name="paymentSchemeId" type="xs:string" minOccurs="0" /> >type="xs:string" minOccurs="0" /> > > > > > > >
[jira] [Created] (CXF-7067) cxf-codegen-plugin version 3.1.x fails to download wsdlArtifact
Atle Tokle created CXF-7067: --- Summary: cxf-codegen-plugin version 3.1.x fails to download wsdlArtifact Key: CXF-7067 URL: https://issues.apache.org/jira/browse/CXF-7067 Project: CXF Issue Type: Bug Components: Build system Affects Versions: 3.1.7, 3.1.0 Reporter: Atle Tokle I am upgrading my project from using cxf version 3.0.1 to 3.1.7. And have my wsdl's in maven. But it fails to download. Have tested that all 3.0.x versions is OK, but 3.1.7 (and 3.1.0) both fails. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7068) WSSecurity Policy not take all suit algorithm
Alejandro Otero Freire created CXF-7068: --- Summary: WSSecurity Policy not take all suit algorithm Key: CXF-7068 URL: https://issues.apache.org/jira/browse/CXF-7068 Project: CXF Issue Type: Bug Components: WS-* Components Affects Versions: 2.7.18 Reporter: Alejandro Otero Freire If you definie in the policy this: It's only load Base128Rsa15, if you change the order, always load the first one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CXF-7068) WSSecurity Policy not take all suit algorithm
[ https://issues.apache.org/jira/browse/CXF-7068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-7068. Resolution: Not A Problem > WSSecurity Policy not take all suit algorithm > - > > Key: CXF-7068 > URL: https://issues.apache.org/jira/browse/CXF-7068 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.7.18 >Reporter: Alejandro Otero Freire > > If you definie in the policy this: > > > > >/> >/> > > > It's only load Base128Rsa15, if you change the order, always load the first > one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7068) WSSecurity Policy not take all suit algorithm
[ https://issues.apache.org/jira/browse/CXF-7068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15513603#comment-15513603 ] Colm O hEigeartaigh commented on CXF-7068: -- You need to wrap the multiple policies in an "ExactlyOne" instead. See this email thread: http://cxf.547215.n5.nabble.com/ws-policies-AlgorithmSuite-td5739309.html > WSSecurity Policy not take all suit algorithm > - > > Key: CXF-7068 > URL: https://issues.apache.org/jira/browse/CXF-7068 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.7.18 >Reporter: Alejandro Otero Freire > > If you definie in the policy this: > > > > >/> >/> > > > It's only load Base128Rsa15, if you change the order, always load the first > one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7048) Response does not include SequenceAcknowledgement
[ https://issues.apache.org/jira/browse/CXF-7048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15514700#comment-15514700 ] Andy Zhang commented on CXF-7048: - As a work around I added the missing SequenceAcknowledgement but the client still complains. Please ignore this ticket. > Response does not include SequenceAcknowledgement > - > > Key: CXF-7048 > URL: https://issues.apache.org/jira/browse/CXF-7048 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.7 > Environment: JBoss >Reporter: Andy Zhang >Priority: Critical > Fix For: 3.1.8 > > > I have a CXF web service deployed to JBoss and a CXF client. The > deliveryAssurance is AtMostOnce. > When the service is fast no retransmission is needed and the response > includes SequenceAcknowledgement. But when the service is slow the client > usually sends retransmissions. The RM framework sends responses to only > include the SequenceAcknowledgement. When the request is successfully > processed it does not include the SequenceAcknowledgement in the actual > response. But the client expects it and keeps waiting till it times out. > dot net client also always expects SequenceAcknowledgement in the response. > If the SequenceAcknowledgement is not found it returns a fault saying "A > reply message was received with no acknowledgement." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CXF-7048) Response does not include SequenceAcknowledgement
[ https://issues.apache.org/jira/browse/CXF-7048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Zhang closed CXF-7048. --- Resolution: Not A Bug > Response does not include SequenceAcknowledgement > - > > Key: CXF-7048 > URL: https://issues.apache.org/jira/browse/CXF-7048 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.7 > Environment: JBoss >Reporter: Andy Zhang >Priority: Critical > Fix For: 3.1.8 > > > I have a CXF web service deployed to JBoss and a CXF client. The > deliveryAssurance is AtMostOnce. > When the service is fast no retransmission is needed and the response > includes SequenceAcknowledgement. But when the service is slow the client > usually sends retransmissions. The RM framework sends responses to only > include the SequenceAcknowledgement. When the request is successfully > processed it does not include the SequenceAcknowledgement in the actual > response. But the client expects it and keeps waiting till it times out. > dot net client also always expects SequenceAcknowledgement in the response. > If the SequenceAcknowledgement is not found it returns a fault saying "A > reply message was received with no acknowledgement." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7062) wsdl2java generates incorrect @XmlElement(namespace=“…”)
[ https://issues.apache.org/jira/browse/CXF-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15515446#comment-15515446 ] Randy Leonard commented on CXF-7062: Thanks for taking a look at this, but I may not have been to clear on a few things... so let me take another stab at why I am certain this is a bug: The Status element is defined as follows: The 'foundationTypes' prefix is defined as follows: xmlns:foundationTypes="http://v1_0_0.datatypes.provider.soap.foundation.rps.com"; Further, the Status type is defined via the following import: http://v1_0_0.datatypes.provider.soap.foundation.rps.com"; schemaLocation="schemas/FoundationTypes.xsd" /> The FoundationTypes.xsd file contains the following: http://v1_0_0.datatypes.provider.soap.foundation.rps.com"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified" xmlns:foundationTypes="http://v1_0_0.datatypes.provider.soap.foundation.rps.com"; targetNamespace="http://v1_0_0.datatypes.provider.soap.foundation.rps.com";> And also, the CXF wsdl2java command generates the following java packages: com.rps.foundation.soap.provider.datatypes.v1_0_0 com.rps.masterdata.common.soap.provider.datatypes.v1_0_0 com.rps.masterdata.common.soap.provider.parameters.v1_0_0 com.rps.masterdata.common.soap.provider.v1_0_0 But most importantly, when I run this same wsdl through Axis2's wsdl2java utility, I get the status element properly prefixed in the generated Java XmlElement annotations... but not when running this through CXF. A final note is that when I hand modify the generated source XmlElement to have the proper namespace for the status element, I get no unmarshaling errors within CXF client code... but leaving the generated XmlElement untouched results in unmarshalling errors in CXF client. Let me know if you wish I provide further details, or to work with you directly on reproducing this issue. Thanks, Randy > wsdl2java generates incorrect @XmlElement(namespace=“…”) > > > Key: CXF-7062 > URL: https://issues.apache.org/jira/browse/CXF-7062 > Project: CXF > Issue Type: Bug > Components: Soap Binding >Affects Versions: 3.1.7 > Environment: MacOSX 10.11, Java v1.8 >Reporter: Randy Leonard >Assignee: Daniel Kulp >Priority: Blocker > Fix For: Invalid > > > I am using Apache CXF 3.1.7, and the wsdl2java command is generating code > with missing/incorrect namespace attributes on the @XMLEment annotation. > Note I generally use four distinct namespaces within each WSDL document, > which are as follows: > • Shared data types across many WSDL documents > (http://v1_0_0.datatypes.provider.soap.foundation.rps.com) > • Domain-specific data types > (http://v1_0_0.datatypes.provider.soap.common.masterdata.rps.com) > • Parameter types > (http://v1_0_0.parameters.provider.soap.common.masterdata.rps.com) > • Service types (http://v1_0_0.provider.soap.common.masterdata.rps.com) > This gives a nice separation of data types, and has worked quite well for me > with Axis2. I am having issues, however, when applying this approach to CXF. > Below is an example WSDL document with the namespaces defined above: > ——— > > targetNamespace="http://v1_0_0.provider.soap.common.masterdata.rps.com"; > xmlns:foundationTypes="http://v1_0_0.datatypes.provider.soap.foundation.rps.com"; > > xmlns:masterdataCommonTypes="http://v1_0_0.datatypes.provider.soap.common.masterdata.rps.com"; > xmlns:parameter="http://v1_0_0.parameters.provider.soap.common.masterdata.rps.com"; > xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; > xmlns:tns="http://v1_0_0.provider.soap.common.masterdata.rps.com"; > xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"; > xmlns:xs="http://www.w3.org/2001/XMLSchema"; > xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap12/"; > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; > xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/";> > >elementFormDefault="qualified" > targetNamespace="http://v1_0_0.parameters.provider.soap.common.masterdata.rps.com"; > > >namespace="http://v1_0_0.datatypes.provider.soap.foundation.rps.com"; > schemaLocation="schemas/FoundationTypes.xsd" /> >namespace="http://v1_0_0.datatypes.provider.soap.common.masterdata.rps.com"; > schemaLocation="schemas/MasterDataCommonTypes.xsd"
[jira] [Reopened] (CXF-7062) wsdl2java generates incorrect @XmlElement(namespace=“…”)
[ https://issues.apache.org/jira/browse/CXF-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randy Leonard reopened CXF-7062: See latest comment > wsdl2java generates incorrect @XmlElement(namespace=“…”) > > > Key: CXF-7062 > URL: https://issues.apache.org/jira/browse/CXF-7062 > Project: CXF > Issue Type: Bug > Components: Soap Binding >Affects Versions: 3.1.7 > Environment: MacOSX 10.11, Java v1.8 >Reporter: Randy Leonard >Assignee: Daniel Kulp >Priority: Blocker > Fix For: Invalid > > > I am using Apache CXF 3.1.7, and the wsdl2java command is generating code > with missing/incorrect namespace attributes on the @XMLEment annotation. > Note I generally use four distinct namespaces within each WSDL document, > which are as follows: > • Shared data types across many WSDL documents > (http://v1_0_0.datatypes.provider.soap.foundation.rps.com) > • Domain-specific data types > (http://v1_0_0.datatypes.provider.soap.common.masterdata.rps.com) > • Parameter types > (http://v1_0_0.parameters.provider.soap.common.masterdata.rps.com) > • Service types (http://v1_0_0.provider.soap.common.masterdata.rps.com) > This gives a nice separation of data types, and has worked quite well for me > with Axis2. I am having issues, however, when applying this approach to CXF. > Below is an example WSDL document with the namespaces defined above: > ——— > > targetNamespace="http://v1_0_0.provider.soap.common.masterdata.rps.com"; > xmlns:foundationTypes="http://v1_0_0.datatypes.provider.soap.foundation.rps.com"; > > xmlns:masterdataCommonTypes="http://v1_0_0.datatypes.provider.soap.common.masterdata.rps.com"; > xmlns:parameter="http://v1_0_0.parameters.provider.soap.common.masterdata.rps.com"; > xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; > xmlns:tns="http://v1_0_0.provider.soap.common.masterdata.rps.com"; > xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"; > xmlns:xs="http://www.w3.org/2001/XMLSchema"; > xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap12/"; > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; > xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/";> > >elementFormDefault="qualified" > targetNamespace="http://v1_0_0.parameters.provider.soap.common.masterdata.rps.com"; > > >namespace="http://v1_0_0.datatypes.provider.soap.foundation.rps.com"; > schemaLocation="schemas/FoundationTypes.xsd" /> >namespace="http://v1_0_0.datatypes.provider.soap.common.masterdata.rps.com"; > schemaLocation="schemas/MasterDataCommonTypes.xsd" /> > > > > > >name="paymentSchemeId" type="xs:string" minOccurs="0" /> >type="xs:string" minOccurs="0" /> > > > > > > > > >type="foundationTypes:Status" /> >type="masterdataCommonTypes:ConsumerChannel" minOccurs="0" > maxOccurs="unbounded" /> > > > > > > > > >name="paymentSchemeId" type="xs:string" minOccurs="0" /> >type="xs:string" minOccurs="0" /> > > > > > > > > >type="foundationTypes:Status" /> > > > > > > >name="request" /> > > >name="response" /> > > >name="request" /> > > >name="response" /> >
[jira] [Comment Edited] (CXF-7062) wsdl2java generates incorrect @XmlElement(namespace=“…”)
[ https://issues.apache.org/jira/browse/CXF-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15515446#comment-15515446 ] Randy Leonard edited comment on CXF-7062 at 9/23/16 5:20 AM: - Thanks for taking a look at this, but I may not have been to clear on a few things... so let me take another stab at why I am certain this is a bug: The Status element is defined as follows: The 'foundationTypes' prefix is defined as follows: xmlns:foundationTypes="http://v1_0_0.datatypes.provider.soap.foundation.rps.com"; Further, the Status type is defined via the following import: http://v1_0_0.datatypes.provider.soap.foundation.rps.com"; schemaLocation="schemas/FoundationTypes.xsd" /> The FoundationTypes.xsd file contains the following: http://v1_0_0.datatypes.provider.soap.foundation.rps.com"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified" xmlns:foundationTypes="http://v1_0_0.datatypes.provider.soap.foundation.rps.com"; targetNamespace="http://v1_0_0.datatypes.provider.soap.foundation.rps.com";> And also, the CXF wsdl2java command generates the following java packages: com.rps.foundation.soap.provider.datatypes.v1_0_0 (which contains Status.java) com.rps.masterdata.common.soap.provider.datatypes.v1_0_0 com.rps.masterdata.common.soap.provider.parameters.v1_0_0 com.rps.masterdata.common.soap.provider.v1_0_0 But most importantly, when I run this same wsdl through Axis2's wsdl2java utility, I get the status element properly prefixed in the generated Java XmlElement annotations... but not when running this through CXF. A final note is that when I hand modify the generated source XmlElement to have the proper namespace for the status element, I get no unmarshaling errors within CXF client code... but leaving the generated XmlElement untouched results in unmarshalling errors in CXF client. Let me know if you wish I provide further details, or to work with you directly on reproducing this issue. Thanks, Randy was (Author: randy.leonard@gmail.com): Thanks for taking a look at this, but I may not have been to clear on a few things... so let me take another stab at why I am certain this is a bug: The Status element is defined as follows: The 'foundationTypes' prefix is defined as follows: xmlns:foundationTypes="http://v1_0_0.datatypes.provider.soap.foundation.rps.com"; Further, the Status type is defined via the following import: http://v1_0_0.datatypes.provider.soap.foundation.rps.com"; schemaLocation="schemas/FoundationTypes.xsd" /> The FoundationTypes.xsd file contains the following: http://v1_0_0.datatypes.provider.soap.foundation.rps.com"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified" xmlns:foundationTypes="http://v1_0_0.datatypes.provider.soap.foundation.rps.com"; targetNamespace="http://v1_0_0.datatypes.provider.soap.foundation.rps.com";> And also, the CXF wsdl2java command generates the following java packages: com.rps.foundation.soap.provider.datatypes.v1_0_0 com.rps.masterdata.common.soap.provider.datatypes.v1_0_0 com.rps.masterdata.common.soap.provider.parameters.v1_0_0 com.rps.masterdata.common.soap.provider.v1_0_0 But most importantly, when I run this same wsdl through Axis2's wsdl2java utility, I get the status element properly prefixed in the generated Java XmlElement annotations... but not when running this through CXF. A final note is that when I hand modify the generated source XmlElement to have the proper namespace for the status element, I get no unmarshaling errors within CXF client code... but leaving the generated XmlElement untouched results in unmarshalling errors in CXF client. Let me know if you wish I provide further details, or to work with you directly on reproducing this issue. Thanks, Randy > wsdl2java generates incorrect @XmlElement(namespace=“…”) > > > Key: CXF-7062 > URL: https://issues.apache.org/jira/browse/CXF-7062 > Project: CXF > Issue Type: Bug > Components: Soap Binding >Affects Versions: 3.1.7 > Environment: MacOSX 10.11, Java v1.8 >Reporter: Randy Leonard >Assignee: Daniel Kulp >Priority: Blocker > Fix For: Invalid > > > I am using Apache CXF 3.1.7, and the wsdl2java command is generating code > with missing/incorrect namespace attributes on the @XMLEment annotation. > Note I generally use four distinct namespaces within each WSDL document, > wh
