[jira] [Created] (CXF-7063) cxf-core 3.1.7 is not validating the xml with xsd
Saritha created CXF-7063:
Summary: cxf-core 3.1.7 is not validating the xml with xsd
Key: CXF-7063
URL: https://issues.apache.org/jira/browse/CXF-7063
Project: CXF
Issue Type: Bug
Reporter: Saritha
Priority: Blocker
cxf-core 3.1.7 is not validating the xml with xsd at appropriate location
Exception says: Could not generate the XML stream caused by:
org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of
element 'ATT_CheckRS'..
Sample code is as below
import org.apache.camel.Exchange;
import org.apache.camel.Message;
import org.apache.camel.Processor;
public class TestProcess implements Processor {
public void process(Exchange exchange) throws Exception {
Message message = exchange.getOut();
message.setBody( bindMessage());
exchange.setOut(message);
//java.lang.System.out.println("MIP of Http Endpoint is " +
message);
java.lang.System.out.println("NEW MIP of Http Endpoint is " +
exchange.getPattern());
}
private String bindMessage(){
return"http://www.w3.org/2001/XMLSchema-instance\";
xmlns=\"http://www.travel.org/ABC/2003/05\";>"
+""
+""
+""
+""
+""
+""
+""
+""
+"";
}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7060) Provide Karaf 4 specific features and commands
[ https://issues.apache.org/jira/browse/CXF-7060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15506086#comment-15506086 ] Sergey Beryozkin commented on CXF-7060: --- Hi Guillaume, I had to start syncing between Karak and Karaf specific features: http://git-wip-us.apache.org/repos/asf/cxf/commit/44c608c2 I wonder if some features can be shared somehow... > Provide Karaf 4 specific features and commands > -- > > Key: CXF-7060 > URL: https://issues.apache.org/jira/browse/CXF-7060 > Project: CXF > Issue Type: Improvement > Components: OSGi >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: 3.2.0 > > > There are a few shortcomings when using the existing features in Karaf 4.x. > Creating specific features and commands will allow: > * to not depend on blueprint > * to validate the feature definitions correctly > * fix existing features > In addition some features have a strong dependency on jetty, while Karaf 4.1 > will provide a choice for the http / war provider (jetty, tomcat, undertow), > so it would make sense to refactor some features to better leverage those > possibilities. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15506092#comment-15506092
]
Sergey Beryozkin commented on CXF-7045:
---
Hi Andriy, great, thanks.
FYI, I also updated newly introduced Karaf4 specific features:
http://git-wip-us.apache.org/repos/asf/cxf/commit/44c608c2
(see CXF-7060)
Thanks, Sergey
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7060) Provide Karaf 4 specific features and commands
[ https://issues.apache.org/jira/browse/CXF-7060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15506209#comment-15506209 ] Guillaume Nodet commented on CXF-7060: -- One possibility would be to use the 1.3 namespace. I don't think we need to use any new feature from 1.4, so that should be fine. The benefit is that support for the 1.3 namespace has been added back into 2.4.3 and 3.0.4. We may want to keep commands separated though. Another option would be to use an xslt to generate the 1.0 version of the features.xml from the 1.3 version. > Provide Karaf 4 specific features and commands > -- > > Key: CXF-7060 > URL: https://issues.apache.org/jira/browse/CXF-7060 > Project: CXF > Issue Type: Improvement > Components: OSGi >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: 3.2.0 > > > There are a few shortcomings when using the existing features in Karaf 4.x. > Creating specific features and commands will allow: > * to not depend on blueprint > * to validate the feature definitions correctly > * fix existing features > In addition some features have a strong dependency on jetty, while Karaf 4.1 > will provide a choice for the http / war provider (jetty, tomcat, undertow), > so it would make sense to refactor some features to better leverage those > possibilities. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7060) Provide Karaf 4 specific features and commands
[ https://issues.apache.org/jira/browse/CXF-7060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15506484#comment-15506484 ] Christian Schneider commented on CXF-7060: -- About the commands.. I wonder if we could switch to felix gogo commands. They should work reasonably well in karaf and would make us less dependent on the karaf version. We might loose some features (especially parameter auto complete) but that might be ok. WDYT? > Provide Karaf 4 specific features and commands > -- > > Key: CXF-7060 > URL: https://issues.apache.org/jira/browse/CXF-7060 > Project: CXF > Issue Type: Improvement > Components: OSGi >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: 3.2.0 > > > There are a few shortcomings when using the existing features in Karaf 4.x. > Creating specific features and commands will allow: > * to not depend on blueprint > * to validate the feature definitions correctly > * fix existing features > In addition some features have a strong dependency on jetty, while Karaf 4.1 > will provide a choice for the http / war provider (jetty, tomcat, undertow), > so it would make sense to refactor some features to better leverage those > possibilities. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7060) Provide Karaf 4 specific features and commands
[ https://issues.apache.org/jira/browse/CXF-7060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15506619#comment-15506619 ] Guillaume Nodet commented on CXF-7060: -- Until we can have full support for gogo commands in karaf, i'd rather provide both if plain gogo commands are actually needed. Such support (with help and completions) is doable, as I've done it inside the gogo-jline shell, but it's not integrated into karaf yet. > Provide Karaf 4 specific features and commands > -- > > Key: CXF-7060 > URL: https://issues.apache.org/jira/browse/CXF-7060 > Project: CXF > Issue Type: Improvement > Components: OSGi >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: 3.2.0 > > > There are a few shortcomings when using the existing features in Karaf 4.x. > Creating specific features and commands will allow: > * to not depend on blueprint > * to validate the feature definitions correctly > * fix existing features > In addition some features have a strong dependency on jetty, while Karaf 4.1 > will provide a choice for the http / war provider (jetty, tomcat, undertow), > so it would make sense to refactor some features to better leverage those > possibilities. -- 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
]
Javier Irazazábal 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:
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]]>
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.
> 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:
> 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);
> }
> }
>
>
[jira] [Created] (CXF-7064) DelegatingXMLStreamWriter.writeCData(text) writes several CDATA sections for a signed XML file
Javier Irazazábal created CXF-7064:
--
Summary: 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
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 message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7065) WSDL2Java-generated classes no longer deserializaing properly in recent Java 8 JRE
Scott Wells created CXF-7065: Summary: WSDL2Java-generated classes no longer deserializaing properly in recent Java 8 JRE Key: CXF-7065 URL: https://issues.apache.org/jira/browse/CXF-7065 Project: CXF Issue Type: Bug Components: JAX-WS Runtime Affects Versions: 3.0.10 Reporter: Scott Wells Priority: Critical I've been using CXF for a set of WSDL-derived SOAP clients for about two years without issue. Recently something changed that caused certain portions of the SOAP envelope to silently fail to deserialize into the corresponding Java classes. I've confirmed that this problem does not occur with Oracle Java 1.8.0_74 but it does occur with Oracle Java 1.8.0_102. I see the same problem with recent OpenJDK builds. I've confirmed this behavior on both Windows and Mac OS X. Obviously the variable here is the JRE, but I figured I'd check in here and see if you guys were aware of anything that might be causing it and, ideally, might have thoughts/ETA for a fix. For more details on a specific SOAP envelope that exhibits this issue, take a look at my more recent comments here: https://youtrack.jetbrains.com/oauth?state=%2Fissue%2FJRE-14 By the way, I'm using 3.0.10 because my product must run under Java 6 currently. I'm hoping to remove that restriction in the medium-term, but for now it's required. Please let me know if you need anything further from me. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7060) Provide Karaf 4 specific features and commands
[ https://issues.apache.org/jira/browse/CXF-7060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15506931#comment-15506931 ] Christian Schneider commented on CXF-7060: -- In that case I would wait for the improved support and only then move the commands to gogo style. I would rather avoid having the code twice for now. > Provide Karaf 4 specific features and commands > -- > > Key: CXF-7060 > URL: https://issues.apache.org/jira/browse/CXF-7060 > Project: CXF > Issue Type: Improvement > Components: OSGi >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: 3.2.0 > > > There are a few shortcomings when using the existing features in Karaf 4.x. > Creating specific features and commands will allow: > * to not depend on blueprint > * to validate the feature definitions correctly > * fix existing features > In addition some features have a strong dependency on jetty, while Karaf 4.1 > will provide a choice for the http / war provider (jetty, tomcat, undertow), > so it would make sense to refactor some features to better leverage those > possibilities. -- 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=15508153#comment-15508153 ] Andy Zhang commented on CXF-7048: - [~ffang] Hi Freeman, I am not sure how this ticket will be handled. Could you please provide a work around before the issue gets fixed? Thanks. > 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. > I've verified that dot net client also always expects SequenceAcknowledgement > in the response. It makes sense to always send the SequenceAcknowledgement in > the response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
