[jira] [Created] (CXF-4379) InjectionUtils failes to convert path-value to class annotated with XmlJavaTypeAdapter
Erling Holmqvist created CXF-4379:
-
Summary: InjectionUtils failes to convert path-value to class
annotated with XmlJavaTypeAdapter
Key: CXF-4379
URL: https://issues.apache.org/jira/browse/CXF-4379
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.6.1, 2.5.4
Reporter: Erling Holmqvist
{code:java}
package no.nrk.panorama.serum;
import static org.fest.assertions.Assertions.assertThat;
import java.lang.annotation.Annotation;
import javax.xml.bind.annotation.adapters.XmlAdapter;
import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;
import org.apache.cxf.jaxrs.model.ParameterType;
import org.apache.cxf.jaxrs.utils.InjectionUtils;
import org.apache.cxf.message.MessageImpl;
import org.junit.Test;
public class CXFInjectionUtilsJUnitTest {
public static class Adapter extends XmlAdapter {
@Override
public String marshal(final Id id) throws Exception {
return id.getId();
}
@Override
public Id unmarshal(final String idStr) throws Exception {
Id id = new DelegatingId();
id.setId(idStr);
return id;
}
}
@XmlJavaTypeAdapter(Adapter.class)
public interface Id {
public String getId();
public void setId(String id);
}
public static class DelegatingId implements Id {
private String id;
public String getId() {
return this.id;
}
public void setId(String id) {
this.id = id;
}
}
@Test
public void
handleParameter_givenValidInput_shouldReturnIdWithCorrectValue() throws
Exception {
// Arrange
String value = "1.1";
// Act
Object id = InjectionUtils.handleParameter(value, true,
Id.class, new Annotation[] {}, ParameterType.PATH,
new MessageImpl());
// Assert
assertThat(id).isInstanceOf(Id.class);
assertThat(((Id)id).getId()).isEqualTo(value);
}
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
java.lang.OutOfMemoryError in a MTOM client
I'm creating a webservice client to send huge files using MTOM. The server side (CXF) is implemented correctly: MTOM is enabled and is using DataHandler instead of byte[]. I tested the server side with not-that-big files and is working as expected: the client is sending and XOP attachment and the server side is getting a well formed DataHandler that allows read the file and put it in th file system (or database) whiout loading all in memory. Everything seems to be working, but when I try to send huge files (23 GB) I get a /java.lang.OutOfMemoryError/ in the client side (and no logs in the server side). This is the client side implementation: * DataServiceService dataServiceService = new DataServiceService(new URL(serviceURI + "?wsdl"), new QName(endpointNamespace, endpointName)); DataService dataService = dataServiceService.getPort(DataService.class); BindingProvider bindingProvider = (BindingProvider) dataService; Map requestContext = bindingProvider.getRequestContext(); requestContext.put(BindingProvider.USERNAME_PROPERTY, user); requestContext.put(BindingProvider.PASSWORD_PROPERTY, password); ((SOAPBinding) bindingProvider.getBinding()).setMTOMEnabled(true); // Preparing the request dataService.update(objects, true); // service call* When the service is called, I got: *Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2786) at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94) at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61) at javax.activation.DataHandler.writeTo(DataHandler.java:294) at com.sun.xml.internal.ws.encoding.MtomCodec$ByteArrayBuffer.write(MtomCodec.java:189) at com.sun.xml.internal.ws.encoding.MtomCodec.encode(MtomCodec.java:156) at com.sun.xml.internal.ws.encoding.SOAPBindingCodec.encode(SOAPBindingCodec.java:249) at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:144) at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:83) at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:105) at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:587) at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:546) at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:531) at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:428) at com.sun.xml.internal.ws.client.Stub.process(Stub.java:211) at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:124) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:98) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) at $Proxy38.update(Unknown Source)* This stack trace bugs me: We see that the client is using MTOM /(MtomCodec.encode(MtomCodec.java:156)/ but this codec is using a /ByteArrayOutputStream/ ??? Can some here help to understand this? and obviously ... if you know how to solve this plse let me know! -- View this message in context: http://cxf.547215.n5.nabble.com/java-lang-OutOfMemoryError-in-a-MTOM-client-tp5709736.html Sent from the cxf-issues mailing list archive at Nabble.com.
Re: java.lang.OutOfMemoryError in a MTOM client
I forgot to mention that I'm using a /FileDataSource/ to create the
/DataHandler /that I'm sending from the client:
*FieldType data = new FieldType();
data.setName("data");
FileDataSource fileDataSource = new FileDataSource(file);
fileDataSource.setFileTypeMap(new MimetypesFileTypeMap());
data.setData(new DataHandler(fileDataSource));*
Thx in advance ...
--
View this message in context:
http://cxf.547215.n5.nabble.com/java-lang-OutOfMemoryError-in-a-MTOM-client-tp5709736p5709737.html
Sent from the cxf-issues mailing list archive at Nabble.com.
[jira] [Updated] (CXF-4350) CXF JMS transport should support to JAXRS fontend client out of box
[ https://issues.apache.org/jira/browse/CXF-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang updated CXF-4350: -- Attachment: cxfrs-jms.patch > CXF JMS transport should support to JAXRS fontend client out of box > --- > > Key: CXF-4350 > URL: https://issues.apache.org/jira/browse/CXF-4350 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Willem Jiang >Assignee: Willem Jiang > Attachments: cxfrs-jms.patch > > > Current JMS transport doesn't send out Message.REQUEST_URI and > Message.HTTP_REQUEST_METHOD properties as the HTTP transport does. > We need to add these headers when the jaxrs frondend client is used with JMS > transport. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4350) CXF JMS transport should support to JAXRS fontend client out of box
[ https://issues.apache.org/jira/browse/CXF-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang updated CXF-4350: -- Attachment: (was: cxfrs-jms.patch) > CXF JMS transport should support to JAXRS fontend client out of box > --- > > Key: CXF-4350 > URL: https://issues.apache.org/jira/browse/CXF-4350 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Willem Jiang >Assignee: Willem Jiang > > Current JMS transport doesn't send out Message.REQUEST_URI and > Message.HTTP_REQUEST_METHOD properties as the HTTP transport does. > We need to add these headers when the jaxrs frondend client is used with JMS > transport. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4350) CXF JMS transport should support to JAXRS fontend client out of box
[ https://issues.apache.org/jira/browse/CXF-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang updated CXF-4350: -- Attachment: cxfrs-jms.patch > CXF JMS transport should support to JAXRS fontend client out of box > --- > > Key: CXF-4350 > URL: https://issues.apache.org/jira/browse/CXF-4350 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Willem Jiang >Assignee: Willem Jiang > Attachments: cxfrs-jms.patch > > > Current JMS transport doesn't send out Message.REQUEST_URI and > Message.HTTP_REQUEST_METHOD properties as the HTTP transport does. > We need to add these headers when the jaxrs frondend client is used with JMS > transport. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4350) CXF JMS transport should support to JAXRS fontend client out of box
[ https://issues.apache.org/jira/browse/CXF-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295041#comment-13295041 ] Willem Jiang commented on CXF-4350: --- Just added the patch of cxfrs and jms transport. This patch introduced a message header for the restful request and the jms transport will setup the jms properties for it. I also added a system test in the JAXRSJmsTest for show how to use jms URI to setup the service address. As I didn't find a way to setup the REQUEST_URI message header through the WebClient API, I just add a JAXRSFeature to update the header for testing. > CXF JMS transport should support to JAXRS fontend client out of box > --- > > Key: CXF-4350 > URL: https://issues.apache.org/jira/browse/CXF-4350 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Willem Jiang >Assignee: Willem Jiang > Attachments: cxfrs-jms.patch > > > Current JMS transport doesn't send out Message.REQUEST_URI and > Message.HTTP_REQUEST_METHOD properties as the HTTP transport does. > We need to add these headers when the jaxrs frondend client is used with JMS > transport. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4260) Poor recommendations in maven-cxf-codegen-plugin-wsdl-to-java.html
[
https://issues.apache.org/jira/browse/CXF-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295062#comment-13295062
]
Glen Mazza commented on CXF-4260:
-
OK, I've updated the documentation to remove most of the sourceRoot overrides
that were falsely implying the need to keep overriding this value, and also
added a recommendation to stick with the default. I'm looking at the
generated-test-sources issue now.
> Poor recommendations in maven-cxf-codegen-plugin-wsdl-to-java.html
> --
>
> Key: CXF-4260
> URL: https://issues.apache.org/jira/browse/CXF-4260
> Project: CXF
> Issue Type: Bug
> Components: Documentation
>Reporter: Jesse Glick
>Assignee: Glen Mazza
>Priority: Minor
>
> I added a comment
> https://cwiki.apache.org/confluence/display/CXF20DOC/Maven+cxf-codegen-plugin+%28WSDL+to+Java%29?focusedCommentId=27843292#comment-27843292
> hoping it would appear automatically at some point in the published
> documentation at
> http://cxf.apache.org/docs/maven-cxf-codegen-plugin-wsdl-to-java.html but it
> did not.
> Also suggest adding a default value for {{testSourceRoot}} of
> {{$\{project.build.directory}/generated-test-sources/cxf}}.
> Background: http://netbeans.org/bugzilla/show_bug.cgi?id=189134
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4380) JAXBElementProvider is calling wrong method for classes extending JAXBElement
Marko Voss created CXF-4380: --- Summary: JAXBElementProvider is calling wrong method for classes extending JAXBElement Key: CXF-4380 URL: https://issues.apache.org/jira/browse/CXF-4380 Project: CXF Issue Type: Bug Components: JAXB Databinding Affects Versions: 2.6.1 Reporter: Marko Voss JAXBElementProvider line 170 - 176: This peace of code performs a special handling for classes, which extends JAXBElement but it calls the wrong unmarshal method. Unmarshaller.unmarshal(Source source, Class declaredType) Unmarshaller.unmarshal(XMLStreamReader reader, Class declaredType) Unmarshaller.unmarshal(XMLEventReader reader, Class declaredType) Unmarshaller.unmarshal(Node node, Class declaredType) These methods are not able to deal with classes, which extend JAXBElement, because they explicitly check, if the declaredType is part of the known classes of the JAXBContext. This is not the case. Please use the other methods instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4380) JAXBElementProvider is calling wrong method for classes extending JAXBElement
[
https://issues.apache.org/jira/browse/CXF-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marko Voss updated CXF-4380:
Description:
JAXBElementProvider line 170 - 176:
This peace of code performs a special handling for classes, which extends
JAXBElement but it calls the wrong unmarshal method.
Unmarshaller.unmarshal(Source source, Class declaredType)
Unmarshaller.unmarshal(XMLStreamReader reader, Class declaredType)
Unmarshaller.unmarshal(XMLEventReader reader, Class declaredType)
Unmarshaller.unmarshal(Node node, Class declaredType)
These methods are not able to deal with classes, which extend JAXBElement,
because they explicitly check, if the declaredType is part of the known classes
of the JAXBContext. This is not the case.
Please use the other methods instead.
Suggested solution: Change
{code}
response =
unmarshaller.unmarshal(TransformUtils.createNewReaderIfNeeded(reader, is),
theType);
{code}
to
{code}
response =
unmarshaller.unmarshal(TransformUtils.createNewReaderIfNeeded(reader, is));
{code}
was:
JAXBElementProvider line 170 - 176:
This peace of code performs a special handling for classes, which extends
JAXBElement but it calls the wrong unmarshal method.
Unmarshaller.unmarshal(Source source, Class declaredType)
Unmarshaller.unmarshal(XMLStreamReader reader, Class declaredType)
Unmarshaller.unmarshal(XMLEventReader reader, Class declaredType)
Unmarshaller.unmarshal(Node node, Class declaredType)
These methods are not able to deal with classes, which extend JAXBElement,
because they explicitly check, if the declaredType is part of the known classes
of the JAXBContext. This is not the case.
Please use the other methods instead.
> JAXBElementProvider is calling wrong method for classes extending JAXBElement
> -
>
> Key: CXF-4380
> URL: https://issues.apache.org/jira/browse/CXF-4380
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 2.6.1
>Reporter: Marko Voss
>
> JAXBElementProvider line 170 - 176:
> This peace of code performs a special handling for classes, which extends
> JAXBElement but it calls the wrong unmarshal method.
> Unmarshaller.unmarshal(Source source, Class declaredType)
> Unmarshaller.unmarshal(XMLStreamReader reader, Class declaredType)
> Unmarshaller.unmarshal(XMLEventReader reader, Class declaredType)
> Unmarshaller.unmarshal(Node node, Class declaredType)
> These methods are not able to deal with classes, which extend JAXBElement,
> because they explicitly check, if the declaredType is part of the known
> classes of the JAXBContext. This is not the case.
> Please use the other methods instead.
> Suggested solution: Change
> {code}
> response =
> unmarshaller.unmarshal(TransformUtils.createNewReaderIfNeeded(reader, is),
> theType);
> {code}
> to
> {code}
> response =
> unmarshaller.unmarshal(TransformUtils.createNewReaderIfNeeded(reader, is));
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4380) JAXBElementProvider is calling wrong method for classes extending JAXBElement
[
https://issues.apache.org/jira/browse/CXF-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marko Voss updated CXF-4380:
Description:
JAXBElementProvider line 170 - 176:
This piece of code performs a special handling for classes, which extends
JAXBElement but it calls the wrong unmarshal method.
Unmarshaller.unmarshal(Source source, Class declaredType)
Unmarshaller.unmarshal(XMLStreamReader reader, Class declaredType)
Unmarshaller.unmarshal(XMLEventReader reader, Class declaredType)
Unmarshaller.unmarshal(Node node, Class declaredType)
These methods are not able to deal with classes, which extend JAXBElement,
because they explicitly check, if the declaredType is part of the known classes
of the JAXBContext. This is not the case.
Please use the other methods instead.
Suggested solution: Change
{code}
response =
unmarshaller.unmarshal(TransformUtils.createNewReaderIfNeeded(reader, is),
theType);
{code}
to
{code}
response =
unmarshaller.unmarshal(TransformUtils.createNewReaderIfNeeded(reader, is));
{code}
was:
JAXBElementProvider line 170 - 176:
This peace of code performs a special handling for classes, which extends
JAXBElement but it calls the wrong unmarshal method.
Unmarshaller.unmarshal(Source source, Class declaredType)
Unmarshaller.unmarshal(XMLStreamReader reader, Class declaredType)
Unmarshaller.unmarshal(XMLEventReader reader, Class declaredType)
Unmarshaller.unmarshal(Node node, Class declaredType)
These methods are not able to deal with classes, which extend JAXBElement,
because they explicitly check, if the declaredType is part of the known classes
of the JAXBContext. This is not the case.
Please use the other methods instead.
Suggested solution: Change
{code}
response =
unmarshaller.unmarshal(TransformUtils.createNewReaderIfNeeded(reader, is),
theType);
{code}
to
{code}
response =
unmarshaller.unmarshal(TransformUtils.createNewReaderIfNeeded(reader, is));
{code}
> JAXBElementProvider is calling wrong method for classes extending JAXBElement
> -
>
> Key: CXF-4380
> URL: https://issues.apache.org/jira/browse/CXF-4380
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 2.6.1
>Reporter: Marko Voss
>
> JAXBElementProvider line 170 - 176:
> This piece of code performs a special handling for classes, which extends
> JAXBElement but it calls the wrong unmarshal method.
> Unmarshaller.unmarshal(Source source, Class declaredType)
> Unmarshaller.unmarshal(XMLStreamReader reader, Class declaredType)
> Unmarshaller.unmarshal(XMLEventReader reader, Class declaredType)
> Unmarshaller.unmarshal(Node node, Class declaredType)
> These methods are not able to deal with classes, which extend JAXBElement,
> because they explicitly check, if the declaredType is part of the known
> classes of the JAXBContext. This is not the case.
> Please use the other methods instead.
> Suggested solution: Change
> {code}
> response =
> unmarshaller.unmarshal(TransformUtils.createNewReaderIfNeeded(reader, is),
> theType);
> {code}
> to
> {code}
> response =
> unmarshaller.unmarshal(TransformUtils.createNewReaderIfNeeded(reader, is));
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4381) Add optional DOM4J provider
Sergey Beryozkin created CXF-4381: - Summary: Add optional DOM4J provider Key: CXF-4381 URL: https://issues.apache.org/jira/browse/CXF-4381 Project: CXF Issue Type: Task Components: JAX-RS Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin DOM4J is still used extensively by some legacy code so it makes sense to get it optionally supported -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4381) Add optional DOM4J provider
[ https://issues.apache.org/jira/browse/CXF-4381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-4381. --- Resolution: Fixed Fix Version/s: 2.7.0 2.6.2 > Add optional DOM4J provider > --- > > Key: CXF-4381 > URL: https://issues.apache.org/jira/browse/CXF-4381 > Project: CXF > Issue Type: Task > Components: JAX-RS >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 2.6.2, 2.7.0 > > > DOM4J is still used extensively by some legacy code so it makes sense to get > it optionally supported -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4260) Poor recommendations in maven-cxf-codegen-plugin-wsdl-to-java.html
[
https://issues.apache.org/jira/browse/CXF-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Glen Mazza resolved CXF-4260.
-
Resolution: Fixed
Confluence docs updated.
> Poor recommendations in maven-cxf-codegen-plugin-wsdl-to-java.html
> --
>
> Key: CXF-4260
> URL: https://issues.apache.org/jira/browse/CXF-4260
> Project: CXF
> Issue Type: Bug
> Components: Documentation
>Reporter: Jesse Glick
>Assignee: Glen Mazza
>Priority: Minor
>
> I added a comment
> https://cwiki.apache.org/confluence/display/CXF20DOC/Maven+cxf-codegen-plugin+%28WSDL+to+Java%29?focusedCommentId=27843292#comment-27843292
> hoping it would appear automatically at some point in the published
> documentation at
> http://cxf.apache.org/docs/maven-cxf-codegen-plugin-wsdl-to-java.html but it
> did not.
> Also suggest adding a default value for {{testSourceRoot}} of
> {{$\{project.build.directory}/generated-test-sources/cxf}}.
> Background: http://netbeans.org/bugzilla/show_bug.cgi?id=189134
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4260) Poor recommendations in maven-cxf-codegen-plugin-wsdl-to-java.html
[
https://issues.apache.org/jira/browse/CXF-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295156#comment-13295156
]
Glen Mazza commented on CXF-4260:
-
The present implementation of the codegen plugin relies on the presence or
absence of a value of testSourceRoot to determine whether to generate during
the compile or test-compile phase (it presently doesn't have a capability to do
both). So given its present implementation I think we'll need to keep the
default for testSourceRoot to null for the time being.
> Poor recommendations in maven-cxf-codegen-plugin-wsdl-to-java.html
> --
>
> Key: CXF-4260
> URL: https://issues.apache.org/jira/browse/CXF-4260
> Project: CXF
> Issue Type: Bug
> Components: Documentation
>Reporter: Jesse Glick
>Assignee: Glen Mazza
>Priority: Minor
>
> I added a comment
> https://cwiki.apache.org/confluence/display/CXF20DOC/Maven+cxf-codegen-plugin+%28WSDL+to+Java%29?focusedCommentId=27843292#comment-27843292
> hoping it would appear automatically at some point in the published
> documentation at
> http://cxf.apache.org/docs/maven-cxf-codegen-plugin-wsdl-to-java.html but it
> did not.
> Also suggest adding a default value for {{testSourceRoot}} of
> {{$\{project.build.directory}/generated-test-sources/cxf}}.
> Background: http://netbeans.org/bugzilla/show_bug.cgi?id=189134
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CXF-4260) Poor recommendations in maven-cxf-codegen-plugin-wsdl-to-java.html
[
https://issues.apache.org/jira/browse/CXF-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Glen Mazza closed CXF-4260.
---
Closing, just a Confluence change so not tied to a source code release.
> Poor recommendations in maven-cxf-codegen-plugin-wsdl-to-java.html
> --
>
> Key: CXF-4260
> URL: https://issues.apache.org/jira/browse/CXF-4260
> Project: CXF
> Issue Type: Bug
> Components: Documentation
>Reporter: Jesse Glick
>Assignee: Glen Mazza
>Priority: Minor
>
> I added a comment
> https://cwiki.apache.org/confluence/display/CXF20DOC/Maven+cxf-codegen-plugin+%28WSDL+to+Java%29?focusedCommentId=27843292#comment-27843292
> hoping it would appear automatically at some point in the published
> documentation at
> http://cxf.apache.org/docs/maven-cxf-codegen-plugin-wsdl-to-java.html but it
> did not.
> Also suggest adding a default value for {{testSourceRoot}} of
> {{$\{project.build.directory}/generated-test-sources/cxf}}.
> Background: http://netbeans.org/bugzilla/show_bug.cgi?id=189134
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4360) NPE in org.apache.cxf.interceptor.WrappedOutInterceptor when WS-RM is enabled
[
https://issues.apache.org/jira/browse/CXF-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295159#comment-13295159
]
Aki Yoshida commented on CXF-4360:
--
Hi Richard,
sorry for my delay in replying. I still can't explain how this problem can
happen.
Do you have this issue on a standalone environment as well or only in your
server container? I am suspecting that your container might be adding some
interfering interceptors or having some inconsistency in the code. I cannot
reproduce this problem using your example when I make a standalone test case
out of it. I am attaching this test to this ticket so that you can look at it.
It is a maven project with a junit test case. You can run it with mvn install.
Could you investigate what is causing the issue in your environment or if it's
not a container specific problem, could you provide a standalone test case to
demonstrate this issue?
Thanks.
Regards, aki
> NPE in org.apache.cxf.interceptor.WrappedOutInterceptor when WS-RM is enabled
> -
>
> Key: CXF-4360
> URL: https://issues.apache.org/jira/browse/CXF-4360
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.6.1
> Environment: Reproducible on every environment.
>Reporter: Richard Opalka
> Fix For: 2.6.2, 2.7.0
>
> Attachments: CXF4360.patch, ReliableService.wsdl, cxf-4360.zip
>
>
> 09:52:29,353 WARNING [org.apache.cxf.phase.PhaseInterceptorChain]
> (http-localhost/127.0.0.1:8080-1) Interceptor for
> {http://www.jboss.org/jbossws/ws-extensions/wsrm}ReliableService#{http://www.jboss.org/jbossws/ws-extensions/wsrm}writeLogMessage
> has thrown exception, unwinding now: java.lang.NullPointerException
> at
> org.apache.cxf.interceptor.WrappedOutInterceptor.handleMessage(WrappedOutInterceptor.java:65)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)
> at
> org.apache.cxf.ws.addressing.impl.InternalContextUtils.rebaseResponse(InternalContextUtils.java:156)
> at
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.mediate(MAPAggregatorImpl.java:467)
> at
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.handleMessage(MAPAggregatorImpl.java:141)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:122)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:211)
> at
> org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:91)
> at
> org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:169)
> at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:187)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:110)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
> [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
> at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:135)
> at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
> [jbossws-spi-2.1.0.Beta1.jar:2.1.0.Beta1]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:156)
> [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> [jbossweb-7.0.16.Final.jar:
[jira] [Updated] (CXF-4360) NPE in org.apache.cxf.interceptor.WrappedOutInterceptor when WS-RM is enabled
[
https://issues.apache.org/jira/browse/CXF-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida updated CXF-4360:
-
Attachment: cxf-4360.zip
> NPE in org.apache.cxf.interceptor.WrappedOutInterceptor when WS-RM is enabled
> -
>
> Key: CXF-4360
> URL: https://issues.apache.org/jira/browse/CXF-4360
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.6.1
> Environment: Reproducible on every environment.
>Reporter: Richard Opalka
> Fix For: 2.6.2, 2.7.0
>
> Attachments: CXF4360.patch, ReliableService.wsdl, cxf-4360.zip
>
>
> 09:52:29,353 WARNING [org.apache.cxf.phase.PhaseInterceptorChain]
> (http-localhost/127.0.0.1:8080-1) Interceptor for
> {http://www.jboss.org/jbossws/ws-extensions/wsrm}ReliableService#{http://www.jboss.org/jbossws/ws-extensions/wsrm}writeLogMessage
> has thrown exception, unwinding now: java.lang.NullPointerException
> at
> org.apache.cxf.interceptor.WrappedOutInterceptor.handleMessage(WrappedOutInterceptor.java:65)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)
> at
> org.apache.cxf.ws.addressing.impl.InternalContextUtils.rebaseResponse(InternalContextUtils.java:156)
> at
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.mediate(MAPAggregatorImpl.java:467)
> at
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.handleMessage(MAPAggregatorImpl.java:141)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:122)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:211)
> at
> org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:91)
> at
> org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:169)
> at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:187)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:110)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
> [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
> at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:135)
> at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
> [jbossws-spi-2.1.0.Beta1.jar:2.1.0.Beta1]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:156)
> [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931)
> [jbossweb-7.0.16.Final.jar:]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_32]
> 09:52:29,359 WARNING [org.apache.cxf.ws.addressing.impl.InternalContextUtils]
> (http-localhost/127.0.0.1:8080-1) SERVER_TRANSPORT_REBASE_FAILURE_MSG:
> org.apache.cxf.interceptor.Fault
> at
> org.apache.cxf.ws.addressing.impl.InternalContextUtils.rebaseResponse(InternalContextUtils.java:161)
> at
> org.apache.cxf.ws.addressing.impl.MAPAgg
[jira] [Assigned] (CXF-4360) NPE in org.apache.cxf.interceptor.WrappedOutInterceptor when WS-RM is enabled
[
https://issues.apache.org/jira/browse/CXF-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida reassigned CXF-4360:
Assignee: Aki Yoshida
> NPE in org.apache.cxf.interceptor.WrappedOutInterceptor when WS-RM is enabled
> -
>
> Key: CXF-4360
> URL: https://issues.apache.org/jira/browse/CXF-4360
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.6.1
> Environment: Reproducible on every environment.
>Reporter: Richard Opalka
>Assignee: Aki Yoshida
> Fix For: 2.6.2, 2.7.0
>
> Attachments: CXF4360.patch, ReliableService.wsdl, cxf-4360.zip
>
>
> 09:52:29,353 WARNING [org.apache.cxf.phase.PhaseInterceptorChain]
> (http-localhost/127.0.0.1:8080-1) Interceptor for
> {http://www.jboss.org/jbossws/ws-extensions/wsrm}ReliableService#{http://www.jboss.org/jbossws/ws-extensions/wsrm}writeLogMessage
> has thrown exception, unwinding now: java.lang.NullPointerException
> at
> org.apache.cxf.interceptor.WrappedOutInterceptor.handleMessage(WrappedOutInterceptor.java:65)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)
> at
> org.apache.cxf.ws.addressing.impl.InternalContextUtils.rebaseResponse(InternalContextUtils.java:156)
> at
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.mediate(MAPAggregatorImpl.java:467)
> at
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.handleMessage(MAPAggregatorImpl.java:141)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:122)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:211)
> at
> org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:91)
> at
> org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:169)
> at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:187)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:110)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
> [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
> at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:135)
> at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
> [jbossws-spi-2.1.0.Beta1.jar:2.1.0.Beta1]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:156)
> [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931)
> [jbossweb-7.0.16.Final.jar:]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_32]
> 09:52:29,359 WARNING [org.apache.cxf.ws.addressing.impl.InternalContextUtils]
> (http-localhost/127.0.0.1:8080-1) SERVER_TRANSPORT_REBASE_FAILURE_MSG:
> org.apache.cxf.interceptor.Fault
> at
> org.apache.cxf.ws.addressing.impl.InternalContextUtils.rebaseResponse(InternalContextUtils.java:161)
> at
> or
[jira] [Commented] (CXF-4260) Poor recommendations in maven-cxf-codegen-plugin-wsdl-to-java.html
[
https://issues.apache.org/jira/browse/CXF-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295194#comment-13295194
]
Jesse Glick commented on CXF-4260:
--
"determine whether to generate during the compile or test-compile phase" -
conventionally I think you would have distinct mojos for these, each specifying
its default phase. The existing goal could be kept for compatibility but
deprecated.
> Poor recommendations in maven-cxf-codegen-plugin-wsdl-to-java.html
> --
>
> Key: CXF-4260
> URL: https://issues.apache.org/jira/browse/CXF-4260
> Project: CXF
> Issue Type: Bug
> Components: Documentation
>Reporter: Jesse Glick
>Assignee: Glen Mazza
>Priority: Minor
>
> I added a comment
> https://cwiki.apache.org/confluence/display/CXF20DOC/Maven+cxf-codegen-plugin+%28WSDL+to+Java%29?focusedCommentId=27843292#comment-27843292
> hoping it would appear automatically at some point in the published
> documentation at
> http://cxf.apache.org/docs/maven-cxf-codegen-plugin-wsdl-to-java.html but it
> did not.
> Also suggest adding a default value for {{testSourceRoot}} of
> {{$\{project.build.directory}/generated-test-sources/cxf}}.
> Background: http://netbeans.org/bugzilla/show_bug.cgi?id=189134
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DOSGI-121) Fix logging: System.out prints, printStackTrace, verbose logs
Bert Jacobs created DOSGI-121: - Summary: Fix logging: System.out prints, printStackTrace, verbose logs Key: DOSGI-121 URL: https://issues.apache.org/jira/browse/DOSGI-121 Project: CXF Distributed OSGi Issue Type: Bug Affects Versions: 1.3.1 Reporter: Bert Jacobs When I use CXF-DOSGi in a project, I notice that the logs are only useful to me when I allow the INFO level, yet they become verbose quickly and cause frequent roll-overs. I also noticed that certain errors get printed to the standard-output and standard-error stream, this becomes annoying when using an OSGi console like Karaf. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DOSGI-121) Fix logging: System.out prints, printStackTrace, verbose logs
[ https://issues.apache.org/jira/browse/DOSGI-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bert Jacobs updated DOSGI-121: -- Attachment: logtuning.patch I've revised most logging statements in the DOSGi project and created a patch: this tries to log service publications only once and tries to make certain errors stand out more. System.out and printStackTrace logging is avoided for all core classes (not for the tests). > Fix logging: System.out prints, printStackTrace, verbose logs > - > > Key: DOSGI-121 > URL: https://issues.apache.org/jira/browse/DOSGI-121 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.3.1 >Reporter: Bert Jacobs > Labels: logging > Attachments: logtuning.patch > > > When I use CXF-DOSGi in a project, I notice that the logs are only useful to > me when I allow the INFO level, yet they become verbose quickly and cause > frequent roll-overs. > I also noticed that certain errors get printed to the standard-output and > standard-error stream, this becomes annoying when using an OSGi console like > Karaf. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4382) fault message is not transmitted to decoupled faultTo endpoint if error occurs from a two way operation
Jim Ma created CXF-4382: --- Summary: fault message is not transmitted to decoupled faultTo endpoint if error occurs from a two way operation Key: CXF-4382 URL: https://issues.apache.org/jira/browse/CXF-4382 Project: CXF Issue Type: Bug Components: WS-* Components Affects Versions: 2.6.1 Reporter: Jim Ma Assignee: Jim Ma Fix For: 2.7.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
