[jira] [Created] (CXF-7172) Error Validating Signed MTOM Message CXF 3.0.6 and up
Hrvoje Slavicek created CXF-7172:
Summary: Error Validating Signed MTOM Message CXF 3.0.6 and up
Key: CXF-7172
URL: https://issues.apache.org/jira/browse/CXF-7172
Project: CXF
Issue Type: Bug
Components: WS-* Components
Affects Versions: 3.1.8, 3.0.6
Reporter: Hrvoje Slavicek
As explained :
http://stackoverflow.com/questions/37308017/error-validating-signed-mtom-message-cxf-3-0-6-and-up
I created a simple web service using CXF that has MTOM enabled, it also expects
a time stamp and the body to be signed, it configured like this:
@ComponentScan(basePackageClasses={MyService.class})
@Configuration
@ImportResource({ "classpath:META-INF/cxf/cxf.xml" })
public class CXFConfig {
@Autowired
Bus cxfBus;
@Autowired
MyService ws;
@Bean
public Endpoint endpoint() {
EndpointImpl endpoint = new EndpointImpl(cxfBus, ws);
endpoint.publish("/MyService");
SOAPBinding binding = (SOAPBinding)endpoint.getBinding();
binding.setMTOMEnabled(true);
Map inProps = new HashMap();
inProps.put(WSHandlerConstants.ACTION, WSHandlerConstants.SIGNATURE+"
"+WSHandlerConstants.TIMESTAMP);
inProps.put(WSHandlerConstants.SIG_PROP_FILE, "wsserver.properties");
WSS4JInInterceptor inc = new WSS4JInInterceptor(inProps);
endpoint.getInInterceptors().add(inc);
return endpoint;
}
}
My Service Interface is:
@WebService
@Component
public interface MyService {
@WebMethod(action="doStuff")
public String doStuff(@WebParam(name="FileData") MTOMMessage message)
throws IOException;
}
My Data Type is:
@XmlType
@XmlAccessorType(XmlAccessType.FIELD)
public class MTOMMessage {
@XmlElement(name = "data", required = true)
@XmlMimeType("text/xml")
protected DataHandler data;
@XmlElement(name = "FileName", required = true)
protected String fileName;
//Getters and Setters
}
I then have a client to call it:
public static void main(String[] args) throws IOException {
String xmlLoc = "classpath:com/avum/dasn/ws/test/client-context.xml";
ClassPathXmlApplicationContext ctx = new
ClassPathXmlApplicationContext(xmlLoc);
MyService svc = ctx.getBean(MyService.class);
MTOMMessage msg = new MTOMMessage();
msg.setXmlData(new DataHandler(getURLForTestFile()));
msg.setFileName("TestFileName");
System.out.println(svc.doStuff(msg));
}
The client-context.xml looks like this:
If I’m using CXF version 3.0.5 or lower this works fine. However if I use 3.0.6
or later I get “A security error was encountered when verifying the message.”.
On the server I’m getting messages like “Couldn't validate the References”.
This is because the server doesn’t get the same DigestValue that comes across
in the ds:DigestValue element.
I think it has something to do with the way MTOM message are handled by the
server side code because if I disable MTOM (on the client and server) then it
works fine. I’m not sure how to get this working in later versions of CXF. Does
anyone have any ideas what I’m doing wrong?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-7172) Error Validating Signed MTOM Message CXF 3.0.6 and up
[
https://issues.apache.org/jira/browse/CXF-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hrvoje Slavicek updated CXF-7172:
-
Priority: Critical (was: Major)
> Error Validating Signed MTOM Message CXF 3.0.6 and up
> -
>
> Key: CXF-7172
> URL: https://issues.apache.org/jira/browse/CXF-7172
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.0.6, 3.1.8
>Reporter: Hrvoje Slavicek
>Priority: Critical
>
> As explained :
> http://stackoverflow.com/questions/37308017/error-validating-signed-mtom-message-cxf-3-0-6-and-up
> I created a simple web service using CXF that has MTOM enabled, it also
> expects a time stamp and the body to be signed, it configured like this:
> @ComponentScan(basePackageClasses={MyService.class})
> @Configuration
> @ImportResource({ "classpath:META-INF/cxf/cxf.xml" })
> public class CXFConfig {
> @Autowired
> Bus cxfBus;
> @Autowired
> MyService ws;
> @Bean
> public Endpoint endpoint() {
> EndpointImpl endpoint = new EndpointImpl(cxfBus, ws);
> endpoint.publish("/MyService");
> SOAPBinding binding = (SOAPBinding)endpoint.getBinding();
> binding.setMTOMEnabled(true);
> Map inProps = new HashMap();
> inProps.put(WSHandlerConstants.ACTION, WSHandlerConstants.SIGNATURE+"
> "+WSHandlerConstants.TIMESTAMP);
> inProps.put(WSHandlerConstants.SIG_PROP_FILE, "wsserver.properties");
> WSS4JInInterceptor inc = new WSS4JInInterceptor(inProps);
> endpoint.getInInterceptors().add(inc);
> return endpoint;
> }
> }
> My Service Interface is:
> @WebService
> @Component
> public interface MyService {
> @WebMethod(action="doStuff")
> public String doStuff(@WebParam(name="FileData") MTOMMessage message)
> throws IOException;
> }
> My Data Type is:
> @XmlType
> @XmlAccessorType(XmlAccessType.FIELD)
> public class MTOMMessage {
> @XmlElement(name = "data", required = true)
> @XmlMimeType("text/xml")
> protected DataHandler data;
> @XmlElement(name = "FileName", required = true)
> protected String fileName;
> //Getters and Setters
> }
> I then have a client to call it:
> public static void main(String[] args) throws IOException {
> String xmlLoc = "classpath:com/avum/dasn/ws/test/client-context.xml";
> ClassPathXmlApplicationContext ctx = new
> ClassPathXmlApplicationContext(xmlLoc);
> MyService svc = ctx.getBean(MyService.class);
> MTOMMessage msg = new MTOMMessage();
> msg.setXmlData(new DataHandler(getURLForTestFile()));
> msg.setFileName("TestFileName");
> System.out.println(svc.doStuff(msg));
> }
> The client-context.xml looks like this:
>
>
>
>
>
>
>
>
>
>
> value="com.co.test.PasswordCallbackHandler"/>
>
>
>
>
>
> If I’m using CXF version 3.0.5 or lower this works fine. However if I use
> 3.0.6 or later I get “A security error was encountered when verifying the
> message.”. On the server I’m getting messages like “Couldn't validate the
> References”. This is because the server doesn’t get the same DigestValue that
> comes across in the ds:DigestValue element.
> I think it has something to do with the way MTOM message are handled by the
> server side code because if I disable MTOM (on the client and server) then it
> works fine. I’m not sure how to get this working in later versions of CXF.
> Does anyone have any ideas what I’m doing wrong?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7172) Error Validating Signed MTOM Message CXF 3.0.6 and up
[
https://issues.apache.org/jira/browse/CXF-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15734886#comment-15734886
]
Colm O hEigeartaigh commented on CXF-7172:
--
Please see the explanation given in this thread:
http://cxf.547215.n5.nabble.com/CXF-3-0-6-MTOM-WS-Security-Exception-td5774657.html
Colm.
> Error Validating Signed MTOM Message CXF 3.0.6 and up
> -
>
> Key: CXF-7172
> URL: https://issues.apache.org/jira/browse/CXF-7172
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.0.6, 3.1.8
>Reporter: Hrvoje Slavicek
>Priority: Critical
>
> As explained :
> http://stackoverflow.com/questions/37308017/error-validating-signed-mtom-message-cxf-3-0-6-and-up
> I created a simple web service using CXF that has MTOM enabled, it also
> expects a time stamp and the body to be signed, it configured like this:
> @ComponentScan(basePackageClasses={MyService.class})
> @Configuration
> @ImportResource({ "classpath:META-INF/cxf/cxf.xml" })
> public class CXFConfig {
> @Autowired
> Bus cxfBus;
> @Autowired
> MyService ws;
> @Bean
> public Endpoint endpoint() {
> EndpointImpl endpoint = new EndpointImpl(cxfBus, ws);
> endpoint.publish("/MyService");
> SOAPBinding binding = (SOAPBinding)endpoint.getBinding();
> binding.setMTOMEnabled(true);
> Map inProps = new HashMap();
> inProps.put(WSHandlerConstants.ACTION, WSHandlerConstants.SIGNATURE+"
> "+WSHandlerConstants.TIMESTAMP);
> inProps.put(WSHandlerConstants.SIG_PROP_FILE, "wsserver.properties");
> WSS4JInInterceptor inc = new WSS4JInInterceptor(inProps);
> endpoint.getInInterceptors().add(inc);
> return endpoint;
> }
> }
> My Service Interface is:
> @WebService
> @Component
> public interface MyService {
> @WebMethod(action="doStuff")
> public String doStuff(@WebParam(name="FileData") MTOMMessage message)
> throws IOException;
> }
> My Data Type is:
> @XmlType
> @XmlAccessorType(XmlAccessType.FIELD)
> public class MTOMMessage {
> @XmlElement(name = "data", required = true)
> @XmlMimeType("text/xml")
> protected DataHandler data;
> @XmlElement(name = "FileName", required = true)
> protected String fileName;
> //Getters and Setters
> }
> I then have a client to call it:
> public static void main(String[] args) throws IOException {
> String xmlLoc = "classpath:com/avum/dasn/ws/test/client-context.xml";
> ClassPathXmlApplicationContext ctx = new
> ClassPathXmlApplicationContext(xmlLoc);
> MyService svc = ctx.getBean(MyService.class);
> MTOMMessage msg = new MTOMMessage();
> msg.setXmlData(new DataHandler(getURLForTestFile()));
> msg.setFileName("TestFileName");
> System.out.println(svc.doStuff(msg));
> }
> The client-context.xml looks like this:
>
>
>
>
>
>
>
>
>
>
> value="com.co.test.PasswordCallbackHandler"/>
>
>
>
>
>
> If I’m using CXF version 3.0.5 or lower this works fine. However if I use
> 3.0.6 or later I get “A security error was encountered when verifying the
> message.”. On the server I’m getting messages like “Couldn't validate the
> References”. This is because the server doesn’t get the same DigestValue that
> comes across in the ds:DigestValue element.
> I think it has something to do with the way MTOM message are handled by the
> server side code because if I disable MTOM (on the client and server) then it
> works fine. I’m not sure how to get this working in later versions of CXF.
> Does anyone have any ideas what I’m doing wrong?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CXF-7172) Error Validating Signed MTOM Message CXF 3.0.6 and up
[
https://issues.apache.org/jira/browse/CXF-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh reassigned CXF-7172:
Assignee: Colm O hEigeartaigh
> Error Validating Signed MTOM Message CXF 3.0.6 and up
> -
>
> Key: CXF-7172
> URL: https://issues.apache.org/jira/browse/CXF-7172
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.0.6, 3.1.8
>Reporter: Hrvoje Slavicek
>Assignee: Colm O hEigeartaigh
>Priority: Critical
>
> As explained :
> http://stackoverflow.com/questions/37308017/error-validating-signed-mtom-message-cxf-3-0-6-and-up
> I created a simple web service using CXF that has MTOM enabled, it also
> expects a time stamp and the body to be signed, it configured like this:
> @ComponentScan(basePackageClasses={MyService.class})
> @Configuration
> @ImportResource({ "classpath:META-INF/cxf/cxf.xml" })
> public class CXFConfig {
> @Autowired
> Bus cxfBus;
> @Autowired
> MyService ws;
> @Bean
> public Endpoint endpoint() {
> EndpointImpl endpoint = new EndpointImpl(cxfBus, ws);
> endpoint.publish("/MyService");
> SOAPBinding binding = (SOAPBinding)endpoint.getBinding();
> binding.setMTOMEnabled(true);
> Map inProps = new HashMap();
> inProps.put(WSHandlerConstants.ACTION, WSHandlerConstants.SIGNATURE+"
> "+WSHandlerConstants.TIMESTAMP);
> inProps.put(WSHandlerConstants.SIG_PROP_FILE, "wsserver.properties");
> WSS4JInInterceptor inc = new WSS4JInInterceptor(inProps);
> endpoint.getInInterceptors().add(inc);
> return endpoint;
> }
> }
> My Service Interface is:
> @WebService
> @Component
> public interface MyService {
> @WebMethod(action="doStuff")
> public String doStuff(@WebParam(name="FileData") MTOMMessage message)
> throws IOException;
> }
> My Data Type is:
> @XmlType
> @XmlAccessorType(XmlAccessType.FIELD)
> public class MTOMMessage {
> @XmlElement(name = "data", required = true)
> @XmlMimeType("text/xml")
> protected DataHandler data;
> @XmlElement(name = "FileName", required = true)
> protected String fileName;
> //Getters and Setters
> }
> I then have a client to call it:
> public static void main(String[] args) throws IOException {
> String xmlLoc = "classpath:com/avum/dasn/ws/test/client-context.xml";
> ClassPathXmlApplicationContext ctx = new
> ClassPathXmlApplicationContext(xmlLoc);
> MyService svc = ctx.getBean(MyService.class);
> MTOMMessage msg = new MTOMMessage();
> msg.setXmlData(new DataHandler(getURLForTestFile()));
> msg.setFileName("TestFileName");
> System.out.println(svc.doStuff(msg));
> }
> The client-context.xml looks like this:
>
>
>
>
>
>
>
>
>
>
> value="com.co.test.PasswordCallbackHandler"/>
>
>
>
>
>
> If I’m using CXF version 3.0.5 or lower this works fine. However if I use
> 3.0.6 or later I get “A security error was encountered when verifying the
> message.”. On the server I’m getting messages like “Couldn't validate the
> References”. This is because the server doesn’t get the same DigestValue that
> comes across in the ds:DigestValue element.
> I think it has something to do with the way MTOM message are handled by the
> server side code because if I disable MTOM (on the client and server) then it
> works fine. I’m not sure how to get this working in later versions of CXF.
> Does anyone have any ideas what I’m doing wrong?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-7172) Error Validating Signed MTOM Message CXF 3.0.6 and up
[
https://issues.apache.org/jira/browse/CXF-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved CXF-7172.
--
Resolution: Not A Problem
> Error Validating Signed MTOM Message CXF 3.0.6 and up
> -
>
> Key: CXF-7172
> URL: https://issues.apache.org/jira/browse/CXF-7172
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.0.6, 3.1.8
>Reporter: Hrvoje Slavicek
>Priority: Critical
>
> As explained :
> http://stackoverflow.com/questions/37308017/error-validating-signed-mtom-message-cxf-3-0-6-and-up
> I created a simple web service using CXF that has MTOM enabled, it also
> expects a time stamp and the body to be signed, it configured like this:
> @ComponentScan(basePackageClasses={MyService.class})
> @Configuration
> @ImportResource({ "classpath:META-INF/cxf/cxf.xml" })
> public class CXFConfig {
> @Autowired
> Bus cxfBus;
> @Autowired
> MyService ws;
> @Bean
> public Endpoint endpoint() {
> EndpointImpl endpoint = new EndpointImpl(cxfBus, ws);
> endpoint.publish("/MyService");
> SOAPBinding binding = (SOAPBinding)endpoint.getBinding();
> binding.setMTOMEnabled(true);
> Map inProps = new HashMap();
> inProps.put(WSHandlerConstants.ACTION, WSHandlerConstants.SIGNATURE+"
> "+WSHandlerConstants.TIMESTAMP);
> inProps.put(WSHandlerConstants.SIG_PROP_FILE, "wsserver.properties");
> WSS4JInInterceptor inc = new WSS4JInInterceptor(inProps);
> endpoint.getInInterceptors().add(inc);
> return endpoint;
> }
> }
> My Service Interface is:
> @WebService
> @Component
> public interface MyService {
> @WebMethod(action="doStuff")
> public String doStuff(@WebParam(name="FileData") MTOMMessage message)
> throws IOException;
> }
> My Data Type is:
> @XmlType
> @XmlAccessorType(XmlAccessType.FIELD)
> public class MTOMMessage {
> @XmlElement(name = "data", required = true)
> @XmlMimeType("text/xml")
> protected DataHandler data;
> @XmlElement(name = "FileName", required = true)
> protected String fileName;
> //Getters and Setters
> }
> I then have a client to call it:
> public static void main(String[] args) throws IOException {
> String xmlLoc = "classpath:com/avum/dasn/ws/test/client-context.xml";
> ClassPathXmlApplicationContext ctx = new
> ClassPathXmlApplicationContext(xmlLoc);
> MyService svc = ctx.getBean(MyService.class);
> MTOMMessage msg = new MTOMMessage();
> msg.setXmlData(new DataHandler(getURLForTestFile()));
> msg.setFileName("TestFileName");
> System.out.println(svc.doStuff(msg));
> }
> The client-context.xml looks like this:
>
>
>
>
>
>
>
>
>
>
> value="com.co.test.PasswordCallbackHandler"/>
>
>
>
>
>
> If I’m using CXF version 3.0.5 or lower this works fine. However if I use
> 3.0.6 or later I get “A security error was encountered when verifying the
> message.”. On the server I’m getting messages like “Couldn't validate the
> References”. This is because the server doesn’t get the same DigestValue that
> comes across in the ds:DigestValue element.
> I think it has something to do with the way MTOM message are handled by the
> server side code because if I disable MTOM (on the client and server) then it
> works fine. I’m not sure how to get this working in later versions of CXF.
> Does anyone have any ideas what I’m doing wrong?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7119) Introduce a JAX-RS client provider for catching technical exceptions (e.g. IOException)
[ https://issues.apache.org/jira/browse/CXF-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15735416#comment-15735416 ] Jörg Hohwiller commented on CXF-7119: - [~sergey_beryozkin] awesome - you are an hero. This sounds like a perfect solution. I will test as soon as the release is available in maven central. > Introduce a JAX-RS client provider for catching technical exceptions (e.g. > IOException) > --- > > Key: CXF-7119 > URL: https://issues.apache.org/jira/browse/CXF-7119 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Affects Versions: 3.1.3 >Reporter: Jörg Hohwiller >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.9 > > > When using CXF for REST/JAX-RS service clients I quickly noticed that I need > to tweak the error handling. My services use an ExceptionMapper that provides > error details via JSON result payload. Hence I want to access this and render > an exception with further details and more context information what works > fine with ResponseExceptionMapper. > However, when a technical error (IOException such as unkown host, connection > refused, timeout, etc.) occurrs I only get generic errors from CXF client > (org.apache.cxf.interceptor.Fault: Could not send Message.). This is > undesired but unfortunately my custom ResponseExceptionMapper is never called > for such technical errors. There seems to be no way to archive my goal with > CXF itself. I could only wrap the client again with a custom written dynamic > proxy to reach my goal. > It seems that CXF hardwires this behaviour: > https://github.com/apache/cxf/blob/master/rt/rs/client/src/main/java/org/apache/cxf/jaxrs/client/AbstractClient.java#L596 > https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/interceptor/MessageSenderInterceptor.java#L64 > It would be awesome if in such case ResponseExceptionMapper would also be > applied so I have the chance to interfere and produce better exceptions (e.g. > with a message containing the name of the application/microservice that could > not be called, the URL, etc.) for my individual needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-7169) Upgrade to woodstox to 5.x
[ https://issues.apache.org/jira/browse/CXF-7169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-7169. -- Resolution: Fixed Assignee: Daniel Kulp Fix Version/s: 3.2.0 > Upgrade to woodstox to 5.x > -- > > Key: CXF-7169 > URL: https://issues.apache.org/jira/browse/CXF-7169 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.1.5 >Reporter: Rebecca Searls >Assignee: Daniel Kulp > Fix For: 3.2.0 > > > CXF's version of woodstox is quite out of date. 3rd party produces that use > CXF request this dependency be updated to the more current version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7162) Inconsistent reading of formatted xml when validating schema
[ https://issues.apache.org/jira/browse/CXF-7162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15735791#comment-15735791 ] ASF GitHub Bot commented on CXF-7162: - Github user asfgit closed the pull request at: https://github.com/apache/cxf/pull/210 > Inconsistent reading of formatted xml when validating schema > > > Key: CXF-7162 > URL: https://issues.apache.org/jira/browse/CXF-7162 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 2.7.18, 3.1.8 > Environment: All >Reporter: Rodrigo Merino > > When calling StaxUtils.copy() with a source reader that is validating schema, > the spaces between tags used for formatting the XML are not copied to the > output. > This causes, when used, the soap body signature validation to fail when using > schema validation. > I have already reported this to woodstox > (https://github.com/FasterXML/woodstox/issues/29) but anyway, > StaxUtils.copy() should be aware of both situations (CHARACTERS AND SPACES). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-7162) Inconsistent reading of formatted xml when validating schema
[ https://issues.apache.org/jira/browse/CXF-7162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-7162. -- Resolution: Fixed Assignee: Daniel Kulp Fix Version/s: 3.0.12 3.1.9 > Inconsistent reading of formatted xml when validating schema > > > Key: CXF-7162 > URL: https://issues.apache.org/jira/browse/CXF-7162 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 2.7.18, 3.1.8 > Environment: All >Reporter: Rodrigo Merino >Assignee: Daniel Kulp > Fix For: 3.1.9, 3.0.12 > > > When calling StaxUtils.copy() with a source reader that is validating schema, > the spaces between tags used for formatting the XML are not copied to the > output. > This causes, when used, the soap body signature validation to fail when using > schema validation. > I have already reported this to woodstox > (https://github.com/FasterXML/woodstox/issues/29) but anyway, > StaxUtils.copy() should be aware of both situations (CHARACTERS AND SPACES). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7173) JAX WS - GZIPINnterceptor does not work
Fiorald created CXF-7173:
Summary: JAX WS - GZIPINnterceptor does not work
Key: CXF-7173
URL: https://issues.apache.org/jira/browse/CXF-7173
Project: CXF
Issue Type: Bug
Components: JAX-WS Runtime
Affects Versions: 3.0.3
Reporter: Fiorald
I have created a ws using jax ws and apache cxf.
When i try to call my ws from SOAP UI using gzip compress i am getting the
following error.
I have set to my cxf-beans.xml the jaxws:inInterceptor but the error persists
23:13,255 WARNING [org.apache.cxf.phase.PhaseInterceptorChain]
(http-localhost/127.0.0.1:8080-1) Interceptor for
{http://agosducato.it/}AgosSmartCredit.ws.provider.CheckIban has thrown
exception, unwinding now: java.lang.RuntimeException: Couldn't parse stream.
at
org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1705)
[cxf-core-3.0.4.jar:3.0.4]
at
org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:123)
[cxf-core-3.0.4.jar:3.0.4]
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
[cxf-core-3.0.4.jar:3.0.4]
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
[cxf-core-3.0.4.jar:3.0.4]
at
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:249)
[cxf-rt-transports-http-3.0.4.jar:3.0.4]
at
org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:97)
at
org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:131)
at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286)
[cxf-rt-transports-http-3.0.4.jar:3.0.4]
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206)
[cxf-rt-transports-http-3.0.4.jar:3.0.4]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
[jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
[jbossws-spi-2.3.1.Final-redhat-1.jar:2.3.1.Final-redhat-1]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
[jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
[jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
[jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
[jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
[jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512)
[jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at
org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
[jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150)
[jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
[jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
[jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
[jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854)
[jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
[jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
[jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_111]
Caused by: com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start byte 0x8b (at
char #2, byte #-1)
at
com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:550)
[woodstox-core-asl-4.4.1.jar:4.4.1]
at
com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:605)
[jira] [Commented] (CXF-7119) Introduce a JAX-RS client provider for catching technical exceptions (e.g. IOException)
[ https://issues.apache.org/jira/browse/CXF-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736421#comment-15736421 ] Sergey Beryozkin commented on CXF-7119: --- No problems, thanks, the fault chain was always available in CXF, I only added a flag to avoid wrapping the original RuntimeEx, cheers > Introduce a JAX-RS client provider for catching technical exceptions (e.g. > IOException) > --- > > Key: CXF-7119 > URL: https://issues.apache.org/jira/browse/CXF-7119 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Affects Versions: 3.1.3 >Reporter: Jörg Hohwiller >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.9 > > > When using CXF for REST/JAX-RS service clients I quickly noticed that I need > to tweak the error handling. My services use an ExceptionMapper that provides > error details via JSON result payload. Hence I want to access this and render > an exception with further details and more context information what works > fine with ResponseExceptionMapper. > However, when a technical error (IOException such as unkown host, connection > refused, timeout, etc.) occurrs I only get generic errors from CXF client > (org.apache.cxf.interceptor.Fault: Could not send Message.). This is > undesired but unfortunately my custom ResponseExceptionMapper is never called > for such technical errors. There seems to be no way to archive my goal with > CXF itself. I could only wrap the client again with a custom written dynamic > proxy to reach my goal. > It seems that CXF hardwires this behaviour: > https://github.com/apache/cxf/blob/master/rt/rs/client/src/main/java/org/apache/cxf/jaxrs/client/AbstractClient.java#L596 > https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/interceptor/MessageSenderInterceptor.java#L64 > It would be awesome if in such case ResponseExceptionMapper would also be > applied so I have the chance to interfere and produce better exceptions (e.g. > with a message containing the name of the application/microservice that could > not be called, the URL, etc.) for my individual needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7171) Mark autogenerated classes as Serializable gengerated using cxf-wadl2java-plugin in maven
[ https://issues.apache.org/jira/browse/CXF-7171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736425#comment-15736425 ] Sergey Beryozkin commented on CXF-7171: --- I think the following answers it: http://stackoverflow.com/questions/3677088/how-to-generate-classes-from-xsd-that-implements-serializable > Mark autogenerated classes as Serializable gengerated using > cxf-wadl2java-plugin in maven > - > > Key: CXF-7171 > URL: https://issues.apache.org/jira/browse/CXF-7171 > Project: CXF > Issue Type: Wish >Reporter: gop > > My java file implemented Serializable interface. When trying to auto-generate > that file in another REST application using cxf-wadl2java-plugin in maven, > autogenerated class is not having Serializable implemented. Is there any way > to achieve this? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7174) NullPointerException when Content-Type is not specified in the http request
Andy McCright created CXF-7174:
--
Summary: NullPointerException when Content-Type is not specified
in the http request
Key: CXF-7174
URL: https://issues.apache.org/jira/browse/CXF-7174
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.1.8
Reporter: Andy McCright
When the Content-Type header is not specified in the HttpServletRequest, a null
pointer is possible when calling Headers.copyFromRequest(...) followed by
Headers.determineContentType(). This scenario is possible when using
non-traditional clients like curl.
Here is an example (snippet) of the NPE:
2016-12-09T09:29:47.24-0600 [APP/0] ERR Caused by:
java.lang.NullPointerException
2016-12-09T09:29:47.24-0600 [APP/0] ERRat
org.apache.cxf.transport.http.Headers.determineContentType(Headers.java:374)
2016-12-09T09:29:47.24-0600 [APP/0] ERRat
org.apache.cxf.transport.http.Headers.setProtocolHeadersInConnection(Headers.java:363)
2016-12-09T09:29:47.24-0600 [APP/0] ERRat
org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.setProtocolHeaders(URLConnectionHTTPConduit.java:279)
2016-12-09T09:29:47.24-0600 [APP/0] ERRat
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.java:1301)
2016-12-09T09:29:47.24-0600 [APP/0] ERRat
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1337)
2016-12-09T09:29:47.24-0600 [APP/0] ERR... 56 more
The failing line of code is:
if (ctList != null && ctList.size() == 1) {
ct = ctList.get(0).toString(); // <--- here
The reason it fails is that copyFromRequest(...) will create a singleton list
and wrap the request's content-type value in it. If the content-type from the
request is null, then ctList will be a singleton list with a null value in it,
so the call to toString() will be on a null value.
Instead, the code should be:
if (ctList != null && ctList.size() == 1 && ctList.get(0) != null) {
ct = ctList.get(0).toString();
...
This ensures that a default content type of text/xml is returned when no
content-type is specified in the request -- or whatever was specified in the
Message.
This approach is preferable to just setting ctList (via the
headers.get(Message.CONTENT_TYPE) field) to null because other places in the
code depend on that list to be non-null.
I have a patch and test case to be delivered shortly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7174) NullPointerException when Content-Type is not specified in the http request
[
https://issues.apache.org/jira/browse/CXF-7174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736701#comment-15736701
]
ASF GitHub Bot commented on CXF-7174:
-
GitHub user andymc12 opened a pull request:
https://github.com/apache/cxf/pull/213
CXF-7174: Avoid NPE when content-type not set in http request
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/andymc12/cxf master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/213.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #213
commit 96e5325b013ecb43ab81ae1ee2094a7b0ff06e20
Author: andymc12
Date: 2016-12-09T23:41:33Z
CXF-7174: Avoid NPE when content-type not set in http request
> NullPointerException when Content-Type is not specified in the http request
> ---
>
> Key: CXF-7174
> URL: https://issues.apache.org/jira/browse/CXF-7174
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.8
>Reporter: Andy McCright
>
> When the Content-Type header is not specified in the HttpServletRequest, a
> null pointer is possible when calling Headers.copyFromRequest(...) followed
> by Headers.determineContentType(). This scenario is possible when using
> non-traditional clients like curl.
> Here is an example (snippet) of the NPE:
> 2016-12-09T09:29:47.24-0600 [APP/0] ERR Caused by:
> java.lang.NullPointerException
> 2016-12-09T09:29:47.24-0600 [APP/0] ERRat
> org.apache.cxf.transport.http.Headers.determineContentType(Headers.java:374)
> 2016-12-09T09:29:47.24-0600 [APP/0] ERRat
> org.apache.cxf.transport.http.Headers.setProtocolHeadersInConnection(Headers.java:363)
> 2016-12-09T09:29:47.24-0600 [APP/0] ERRat
> org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.setProtocolHeaders(URLConnectionHTTPConduit.java:279)
> 2016-12-09T09:29:47.24-0600 [APP/0] ERRat
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.java:1301)
> 2016-12-09T09:29:47.24-0600 [APP/0] ERRat
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1337)
> 2016-12-09T09:29:47.24-0600 [APP/0] ERR... 56 more
> The failing line of code is:
> if (ctList != null && ctList.size() == 1) {
> ct = ctList.get(0).toString(); // <--- here
> The reason it fails is that copyFromRequest(...) will create a singleton list
> and wrap the request's content-type value in it. If the content-type from
> the request is null, then ctList will be a singleton list with a null value
> in it, so the call to toString() will be on a null value.
> Instead, the code should be:
> if (ctList != null && ctList.size() == 1 && ctList.get(0) != null) {
> ct = ctList.get(0).toString();
> ...
> This ensures that a default content type of text/xml is returned when no
> content-type is specified in the request -- or whatever was specified in the
> Message.
> This approach is preferable to just setting ctList (via the
> headers.get(Message.CONTENT_TYPE) field) to null because other places in the
> code depend on that list to be non-null.
> I have a patch and test case to be delivered shortly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
