[jira] [Commented] (CXF-4559) Part of SoapMessage content interchange between two concurrent webservice calls
[
https://issues.apache.org/jira/browse/CXF-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476010#comment-13476010
]
csupi commented on CXF-4559:
Thanks for your quick reply.
I created a unit test for testing the JAXB before, and it was success without
the XmlJavaTypeAdapter annotation.
I modified your test to looks like my JAXB test. The only difference between
mine and yours is that I created the unmarshallers before the start of the
threads.
I upload my modified test.
Part of SoapMessage content interchange between two concurrent webservice
calls
---
Key: CXF-4559
URL: https://issues.apache.org/jira/browse/CXF-4559
Project: CXF
Issue Type: Bug
Affects Versions: 2.5.4, 2.5.5, 2.5.6
Environment: Java 64-Bit Server 1.6.0_31
Ubuntu 12.04 64-Bit
Reporter: csupi
Assignee: Daniel Kulp
Priority: Critical
Fix For: Invalid
Attachments: ConcurrentTest.java
I have a simple cxf webservice call with a DTO parameter. There is a HashMap
and some other fields in the DTO.
I realized that there are some cases where the content in the map is changed
somewhere on the server side.
I created a simple unit test. I put a String into the map and into a field
where the map is. Create a webservice with jetty and create 15 clients to
call my webservice 1000 times.
After the test execution I realized that about in the 2% of the calls, the
String in the map differs from the value in the field.
Here is my unit test:
{noformat}
import java.io.Serializable;
import java.util.ArrayList;
import java.util.Collection;
import java.util.HashMap;
import java.util.UUID;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.atomic.AtomicInteger;
import javax.jws.WebParam;
import javax.jws.WebService;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import org.apache.cxf.interceptor.LoggingInInterceptor;
import org.apache.cxf.jaxws.JaxWsProxyFactoryBean;
import org.apache.cxf.jaxws.JaxWsServerFactoryBean;
import org.junit.Test;
public class WebserviceEndpointIt {
private static final int number_of_clients = 15;
private final AtomicInteger badCounter = new AtomicInteger(0);
private final AtomicInteger successCounter = new AtomicInteger(0);
@XmlAccessorType(XmlAccessType.FIELD)
public static class Event implements Serializable {
private static final long serialVersionUID = 1L;
private final HashMapString, Object map = new HashMapString,
Object();
private String expected;
private String i;
private String thread;
}
@WebService
public interface MockWebservice {
void doit(@WebParam(name = message) Event message);
}
public class MockWebserviceImpl implements MockWebservice {
@Override
public void doit(final Event message) {
/*
* read the two strings from the FIELD and the MAP
*/
final String expected = message.expected;
final Object idFromMap = message.map == null ? null :
message.map.get(expected);
if (expected == null || idFromMap == null ||
!expected.equals(idFromMap)) {
WebserviceEndpointIt.this.badCounter.incrementAndGet();
} else {
WebserviceEndpointIt.this.successCounter.incrementAndGet();
}
}
}
@Test
public void testMyWebService() throws InterruptedException,
ExecutionException {
final MockWebservice endpoint = new MockWebserviceImpl();
final JaxWsServerFactoryBean svrFactory = new
JaxWsServerFactoryBean();
svrFactory.setServiceClass(MockWebservice.class);
svrFactory.setAddress(http://localhost:9000/myService;);
svrFactory.setServiceBean(endpoint);
svrFactory.create();
svrFactory.getInInterceptors().add(new LoggingInInterceptor());
final CollectionCallableObject clients = new
ArrayListCallableObject();
for (int i = 0; i number_of_clients; i++) {
final int thread = i;
clients.add(new CallableObject() {
@Override
public Object call() throws Exception {
final MockWebservice client = createClient();
for (int i = 0; i 1000; i++) {
final Event message = new Event();
final String id = Integer.valueOf(thread).toString()
+ - + Integer.valueOf(i).toString() +
+
[jira] [Updated] (CXF-4559) Part of SoapMessage content interchange between two concurrent webservice calls
[
https://issues.apache.org/jira/browse/CXF-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
csupi updated CXF-4559:
---
Attachment: ConcurrentTestPrecreatedJAXBContext.java
Part of SoapMessage content interchange between two concurrent webservice
calls
---
Key: CXF-4559
URL: https://issues.apache.org/jira/browse/CXF-4559
Project: CXF
Issue Type: Bug
Affects Versions: 2.5.4, 2.5.5, 2.5.6
Environment: Java 64-Bit Server 1.6.0_31
Ubuntu 12.04 64-Bit
Reporter: csupi
Assignee: Daniel Kulp
Priority: Critical
Fix For: Invalid
Attachments: ConcurrentTest.java,
ConcurrentTestPrecreatedJAXBContext.java
I have a simple cxf webservice call with a DTO parameter. There is a HashMap
and some other fields in the DTO.
I realized that there are some cases where the content in the map is changed
somewhere on the server side.
I created a simple unit test. I put a String into the map and into a field
where the map is. Create a webservice with jetty and create 15 clients to
call my webservice 1000 times.
After the test execution I realized that about in the 2% of the calls, the
String in the map differs from the value in the field.
Here is my unit test:
{noformat}
import java.io.Serializable;
import java.util.ArrayList;
import java.util.Collection;
import java.util.HashMap;
import java.util.UUID;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.atomic.AtomicInteger;
import javax.jws.WebParam;
import javax.jws.WebService;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import org.apache.cxf.interceptor.LoggingInInterceptor;
import org.apache.cxf.jaxws.JaxWsProxyFactoryBean;
import org.apache.cxf.jaxws.JaxWsServerFactoryBean;
import org.junit.Test;
public class WebserviceEndpointIt {
private static final int number_of_clients = 15;
private final AtomicInteger badCounter = new AtomicInteger(0);
private final AtomicInteger successCounter = new AtomicInteger(0);
@XmlAccessorType(XmlAccessType.FIELD)
public static class Event implements Serializable {
private static final long serialVersionUID = 1L;
private final HashMapString, Object map = new HashMapString,
Object();
private String expected;
private String i;
private String thread;
}
@WebService
public interface MockWebservice {
void doit(@WebParam(name = message) Event message);
}
public class MockWebserviceImpl implements MockWebservice {
@Override
public void doit(final Event message) {
/*
* read the two strings from the FIELD and the MAP
*/
final String expected = message.expected;
final Object idFromMap = message.map == null ? null :
message.map.get(expected);
if (expected == null || idFromMap == null ||
!expected.equals(idFromMap)) {
WebserviceEndpointIt.this.badCounter.incrementAndGet();
} else {
WebserviceEndpointIt.this.successCounter.incrementAndGet();
}
}
}
@Test
public void testMyWebService() throws InterruptedException,
ExecutionException {
final MockWebservice endpoint = new MockWebserviceImpl();
final JaxWsServerFactoryBean svrFactory = new
JaxWsServerFactoryBean();
svrFactory.setServiceClass(MockWebservice.class);
svrFactory.setAddress(http://localhost:9000/myService;);
svrFactory.setServiceBean(endpoint);
svrFactory.create();
svrFactory.getInInterceptors().add(new LoggingInInterceptor());
final CollectionCallableObject clients = new
ArrayListCallableObject();
for (int i = 0; i number_of_clients; i++) {
final int thread = i;
clients.add(new CallableObject() {
@Override
public Object call() throws Exception {
final MockWebservice client = createClient();
for (int i = 0; i 1000; i++) {
final Event message = new Event();
final String id = Integer.valueOf(thread).toString()
+ - + Integer.valueOf(i).toString() +
+ UUID.randomUUID().toString();
/*
* put the same string into the MAP and the FIELD
*/
message.map.put(expected, id);
message.expected = id;
[jira] [Resolved] (CXF-4554) http://schemas.xmlsoap.org/soap/http/ should not be in the SoapTransportFactory active namespaces list
[ https://issues.apache.org/jira/browse/CXF-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CXF-4554. --- Resolution: Fixed Fix Version/s: 2.7.1 2.6.4 2.5.7 Applied the patch into trunk, cxf-2.6.x-fixes and cxf-2.5.x-fixes branches. http://schemas.xmlsoap.org/soap/http/; should not be in the SoapTransportFactory active namespaces list - Key: CXF-4554 URL: https://issues.apache.org/jira/browse/CXF-4554 Project: CXF Issue Type: Bug Affects Versions: 2.4.9, 2.5.5, 2.6.2 Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.5.7, 2.6.4, 2.7.1 http://schemas.xmlsoap.org/soap/http/; is not a validate namespace for SOAP http binding, we need to remove it to avoid the stack over follow exception. Here is the mail thread[1] which discusses about it [1]http://camel.465427.n5.nabble.com/Camel-CXF-web-services-are-not-available-tp5720790p5720845.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Issues with Attachments: week of 2012-10-15
CXF - Monday, October 15, 2012 2 Issues with Attachments (sorted oldest to newest) [CXF-4524] Large request causes socket timeout on subsequent requests on WebLogic hosted service - Created: 2012-09-27 - Updated: 2012-09-27 - Type: Bug - Fix Versions: [] - Reporter: Chris Pimlott - Assigned: Unassigned - Attachments: [stacktrace.client.txt, stacktrace.weblogic.txt, weblogic-socketTimeoutBug.zip] - https://issues.apache.org/jira/browse/CXF-4524 [CXF-4562] Soap Fault fields precedence is incorrect - Created: 2012-10-15 - Updated: 2012-10-15 - Type: Bug - Fix Versions: [] - Reporter: Han Hong Fang - Assigned: Freeman Fang - Attachments: [Soap12FaultOutInterceptor.patch] - https://issues.apache.org/jira/browse/CXF-4562
[jira] [Resolved] (CXF-4562) Soap Fault fields precedence is incorrect
[ https://issues.apache.org/jira/browse/CXF-4562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-4562. --- Resolution: Fixed Fix Version/s: 2.7.1 2.6.4 2.5.7 2.4.11 apply patch on behalf of Han Hong Fang with thanks http://svn.apache.org/viewvc?rev=1398207view=rev for trunk http://svn.apache.org/viewvc?rev=1398209view=rev for 2.6.x branch http://svn.apache.org/viewvc?rev=1398211view=rev for 2.5.x branch http://svn.apache.org/viewvc?rev=1398213view=rev for 2.4.x branch Soap Fault fields precedence is incorrect - Key: CXF-4562 URL: https://issues.apache.org/jira/browse/CXF-4562 Project: CXF Issue Type: Bug Components: Soap Binding Affects Versions: 2.6.2 Environment: Window 7 + sun jdk 1.6.0_29 Reporter: Han Hong Fang Assignee: Freeman Fang Fix For: 2.4.11, 2.5.7, 2.6.4, 2.7.1 Attachments: Soap12FaultOutInterceptor.patch According to JSR224 spec chapter 10.2.2.3, the the fields of the fault message are populated according to the following rules of precedence: - faultcode - faultstring - faultactor (role in SOAP 1.2) - detail But in current impl of cxf 2.6.2, detail is before faultactor(role in SOAP 1.2). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4555) enable http:conduit to configure the chunk size
[ https://issues.apache.org/jira/browse/CXF-4555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476040#comment-13476040 ] Freeman Fang commented on CXF-4555: --- commit fix http://svn.apache.org/viewvc?rev=1398200view=rev for trunk http://svn.apache.org/viewvc?rev=1398214view=rev for 2.6.x branch http://svn.apache.org/viewvc?rev=1398217view=rev for 2.5.x branch http://svn.apache.org/viewvc?rev=1398224view=rev for 2.4.x branch TODO: also need make new async HTTP transport chunk size configurable enable http:conduit to configure the chunk size --- Key: CXF-4555 URL: https://issues.apache.org/jira/browse/CXF-4555 Project: CXF Issue Type: Improvement Reporter: Freeman Fang Assignee: Freeman Fang -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4560) Default JAX-RS SAML Claim namespace is incorrect
[ https://issues.apache.org/jira/browse/CXF-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-4560. -- Resolution: Fixed Default JAX-RS SAML Claim namespace is incorrect Key: CXF-4560 URL: https://issues.apache.org/jira/browse/CXF-4560 Project: CXF Issue Type: Bug Components: JAX-RS Security Affects Versions: 2.5.6, 2.6.3, 2.7.0 Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 2.7.1 The default JAX-RS Claim namespace is incorrect. Instead of http://schemas.xmlsoap.org/ws/2005/05/identity/claims; it should be urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified. I will fix this on trunk only (i.e. for CXF 2.7.1) for backwards compatibility reasons. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4487) cxf-codegen-plugin: Error resolving component warnings for imported types
[
https://issues.apache.org/jira/browse/CXF-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476154#comment-13476154
]
Dennis Kieselhorst commented on CXF-4487:
-
I also get several warnings with 2.6.2:
{code}
[WARNING] C:\path\project\src\main\resources\wsdl\MyService.wsdl [19:13]:
src-resolve.4.2: ...
at
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
Source)
at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
Source)
at
org.apache.xerces.impl.xs.traversers.XSDHandler.getGlobalDecl(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDElementTraverser.traverseLocal(Unknown
Source)
at
org.apache.xerces.impl.xs.traversers.XSDHandler.traverseLocalElements(Unknown
Source)
at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown
Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown Source)
at org.apache.xerces.jaxp.validation.XMLSchemaFactory.newSchema(Unknown
Source)
at
com.sun.tools.xjc.reader.internalizer.DOMForest.weakSchemaCorrectnessCheck(DOMForest.java:486)
at
com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:227)
at
com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:85)
at
org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:411)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJavaContainer.java:603)
{code}
After updating to 2.6.3 I also get errors for other imported types:
{code}
[ERROR] Failed to execute goal
org.apache.cxf:cxf-codegen-plugin:2.6.3:wsdl2java (generate-wsdl2java) on
project ...
Caused by: org.apache.cxf.tools.common.ToolException: Schema Error :
src-resolve: Cannot resolve the name 'xxx:YYY' to a(n) 'element declaration'
component.
at
org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.validateSchema(JAXBDataBinding.java:914)
at
org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.addSchemas(JAXBDataBinding.java:655)
at
org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:392)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJavaContainer.java:603)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:248)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:142)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:300)
at
org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
at
org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo.generate(WSDL2JavaMojo.java:380)
at
org.apache.cxf.maven_plugin.AbstractCodegenMoho.execute(AbstractCodegenMoho.java:257)
at
org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:477)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
Caused by: org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name
'xxx:YYY' to a(n) 'element declaration' component.
at
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
Source)
at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
Source)
at
org.apache.xerces.impl.xs.traversers.XSDHandler.getGlobalDecl(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDElementTraverser.traverseLocal(Unknown
Source)
at
org.apache.xerces.impl.xs.traversers.XSDHandler.traverseLocalElements(Unknown
Source)
at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown
Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown Source)
at
[jira] [Created] (CXF-4563) Empty XML or JSON responses are not processed correctly on the client side
Sergey Beryozkin created CXF-4563: - Summary: Empty XML or JSON responses are not processed correctly on the client side Key: CXF-4563 URL: https://issues.apache.org/jira/browse/CXF-4563 Project: CXF Issue Type: Bug Components: JAX-RS Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Fix For: 2.5.7, 2.6.4, 2.7.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4564) NPE in MavenToolErrorListener during wsdl2java code generation
Dennis Kieselhorst created CXF-4564:
---
Summary: NPE in MavenToolErrorListener during wsdl2java code
generation
Key: CXF-4564
URL: https://issues.apache.org/jira/browse/CXF-4564
Project: CXF
Issue Type: Bug
Components: Tooling
Affects Versions: 2.6.3
Environment: JDK 7
Reporter: Dennis Kieselhorst
Running wsdl2java with 2.6.3 on JDK 7 causes an NPE. Everything is fine JDK 6.
{code}
[ERROR] Failed to execute goal
org.apache.cxf:cxf-codegen-plugin:2.6.3:wsdl2java (wsdl-MyService.wsdl) on
project dominic-communication: Execution wsdl-MyService.wsdl of goal
org.apache.cxf:cxf-codegen-plugin:2.6.3:wsdl2java failed:
java.lang.NullPointerException - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.cxf:cxf-codegen-plugin:2.6.3:wsdl2java (wsdl-RegistrarService.wsdl)
on project MyProject: Execution wsdl-MyService.wsdl of goal
org.apache.cxf:cxf-codegen-plugin:2.6.3:wsdl2java failed:
java.lang.NullPointerException
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
wsdl-RegistrarService.wsdl of goal
org.apache.cxf:cxf-codegen-plugin:2.6.3:wsdl2java failed:
java.lang.NullPointerException
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: org.apache.cxf.tools.common.ToolException:
java.lang.NullPointerException
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:308)
at
org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
at
org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo.generate(WSDL2JavaMojo.java:380)
at
org.apache.cxf.maven_plugin.AbstractCodegenMoho.execute(AbstractCodegenMoho.java:257)
at
org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:477)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
Caused by: java.lang.NullPointerException
at java.io.File.init(File.java:251)
at
org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo$MavenToolErrorListener$1.init(WSDL2JavaMojo.java:76)
at
org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo$MavenToolErrorListener.addError(WSDL2JavaMojo.java:74)
at
org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBBindErrorListener.error(JAXBBindErrorListener.java:40)
at
com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.error(SchemaCompilerImpl.java:316)
at com.sun.tools.xjc.ErrorReceiver.error(ErrorReceiver.java:94)
at
com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:405)
at
com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:304)
at
[jira] [Commented] (CXF-4559) Part of SoapMessage content interchange between two concurrent webservice calls
[
https://issues.apache.org/jira/browse/CXF-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476181#comment-13476181
]
Daniel Kulp commented on CXF-4559:
--
In your test, you are not just creating a new unmarshaller per thread, but you
are creating an entire new JAXContext per thread. That would be insanely
expensive. Change to:
{code:java}
JAXBContext ctx = JAXBContext.newInstance(Event.class);
final Unmarshaller[] marshaller = new Unmarshaller[NUMBER_OF_CLIENTS];
for (int i = 0; i NUMBER_OF_CLIENTS; i++) {
marshaller[i] = ctx.createUnmarshaller();
}
{code}
to use a single JAXBContext, but per thread unmarshaller. That would show the
issue with 2.1.13.
Part of SoapMessage content interchange between two concurrent webservice
calls
---
Key: CXF-4559
URL: https://issues.apache.org/jira/browse/CXF-4559
Project: CXF
Issue Type: Bug
Affects Versions: 2.5.4, 2.5.5, 2.5.6
Environment: Java 64-Bit Server 1.6.0_31
Ubuntu 12.04 64-Bit
Reporter: csupi
Assignee: Daniel Kulp
Priority: Critical
Fix For: Invalid
Attachments: ConcurrentTest.java,
ConcurrentTestPrecreatedJAXBContext.java
I have a simple cxf webservice call with a DTO parameter. There is a HashMap
and some other fields in the DTO.
I realized that there are some cases where the content in the map is changed
somewhere on the server side.
I created a simple unit test. I put a String into the map and into a field
where the map is. Create a webservice with jetty and create 15 clients to
call my webservice 1000 times.
After the test execution I realized that about in the 2% of the calls, the
String in the map differs from the value in the field.
Here is my unit test:
{noformat}
import java.io.Serializable;
import java.util.ArrayList;
import java.util.Collection;
import java.util.HashMap;
import java.util.UUID;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.atomic.AtomicInteger;
import javax.jws.WebParam;
import javax.jws.WebService;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import org.apache.cxf.interceptor.LoggingInInterceptor;
import org.apache.cxf.jaxws.JaxWsProxyFactoryBean;
import org.apache.cxf.jaxws.JaxWsServerFactoryBean;
import org.junit.Test;
public class WebserviceEndpointIt {
private static final int number_of_clients = 15;
private final AtomicInteger badCounter = new AtomicInteger(0);
private final AtomicInteger successCounter = new AtomicInteger(0);
@XmlAccessorType(XmlAccessType.FIELD)
public static class Event implements Serializable {
private static final long serialVersionUID = 1L;
private final HashMapString, Object map = new HashMapString,
Object();
private String expected;
private String i;
private String thread;
}
@WebService
public interface MockWebservice {
void doit(@WebParam(name = message) Event message);
}
public class MockWebserviceImpl implements MockWebservice {
@Override
public void doit(final Event message) {
/*
* read the two strings from the FIELD and the MAP
*/
final String expected = message.expected;
final Object idFromMap = message.map == null ? null :
message.map.get(expected);
if (expected == null || idFromMap == null ||
!expected.equals(idFromMap)) {
WebserviceEndpointIt.this.badCounter.incrementAndGet();
} else {
WebserviceEndpointIt.this.successCounter.incrementAndGet();
}
}
}
@Test
public void testMyWebService() throws InterruptedException,
ExecutionException {
final MockWebservice endpoint = new MockWebserviceImpl();
final JaxWsServerFactoryBean svrFactory = new
JaxWsServerFactoryBean();
svrFactory.setServiceClass(MockWebservice.class);
svrFactory.setAddress(http://localhost:9000/myService;);
svrFactory.setServiceBean(endpoint);
svrFactory.create();
svrFactory.getInInterceptors().add(new LoggingInInterceptor());
final CollectionCallableObject clients = new
ArrayListCallableObject();
for (int i = 0; i number_of_clients; i++) {
final int thread = i;
clients.add(new CallableObject() {
@Override
public Object call() throws Exception {
final MockWebservice client =
[jira] [Created] (CXF-4565) The message flow is not correct when handler throw ProtocolException outbound
Yi Xiao created CXF-4565: Summary: The message flow is not correct when handler throw ProtocolException outbound Key: CXF-4565 URL: https://issues.apache.org/jira/browse/CXF-4565 Project: CXF Issue Type: Bug Components: JAX-WS Runtime Reporter: Yi Xiao The scenario is using two SoapHandler and one LogicalHandler to intercept the message from client, and when LogicalHandler at server side handle the outbound message, it throws a ProtocolException. Now, the message flow at server side in CXF is: Server_SOAPHandler1_handleMessage_Inbound: Server_SOAPHandler2_handleMessage_Inbound: Server_LogicalHandler_handleMessage_Inbound: Server_countString: Server_LogicalHandler_handleMessage_Outbound: Server_LogicalHandler_handleFault_Outbound: // All of the three Server_SOAPHandler2_handleFault_Outbound: // handlerFault methods Server_SOAPHandler1_handleFault_Outbound: // are invoked Server_LogicalHandler_close: Server_SOAPHandler2_close: Server_SOAPHandler1_close: But according to jsr224 9.3.2.1 Throw ProtocolException or a subclass This indicates that normal message processing should cease. Subsequent actions depend on whether the MEP in use requires a response to the message currently being processed or not: No response Normal message processing stops, close is called on each previously invoked handler in the chain, the exception is dispatched (see section 9.1.2.3). I also test the same case in WebSphere8.5 and Glassfish3.1.2.2, the message flow is: Server_SOAPHandler1_handleMessage_Inbound: Server_SOAPHandler2_handleMessage_Inbound: Server_LogicalHandler_handleMessage_Inbound: Server_countString: Server_LogicalHandler_handleMessage_Outbound: Server_LogicalHandler_close: Server_SOAPHandler2_close: Server_SOAPHandler1_close: The handleFault methods are not called, and the close methods are called directly, I think it matches the spec better. I also provide a patch for the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4565) The message flow is not correct when handler throw ProtocolException outbound
[ https://issues.apache.org/jira/browse/CXF-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Xiao updated CXF-4565: - Attachment: cxf-4565.patch Could some one review the patch? thank you very much :) The message flow is not correct when handler throw ProtocolException outbound - Key: CXF-4565 URL: https://issues.apache.org/jira/browse/CXF-4565 Project: CXF Issue Type: Bug Components: JAX-WS Runtime Reporter: Yi Xiao Labels: handler Attachments: cxf-4565.patch The scenario is using two SoapHandler and one LogicalHandler to intercept the message from client, and when LogicalHandler at server side handle the outbound message, it throws a ProtocolException. Now, the message flow at server side in CXF is: Server_SOAPHandler1_handleMessage_Inbound: Server_SOAPHandler2_handleMessage_Inbound: Server_LogicalHandler_handleMessage_Inbound: Server_countString: Server_LogicalHandler_handleMessage_Outbound: Server_LogicalHandler_handleFault_Outbound: // All of the three Server_SOAPHandler2_handleFault_Outbound: // handlerFault methods Server_SOAPHandler1_handleFault_Outbound: // are invoked Server_LogicalHandler_close: Server_SOAPHandler2_close: Server_SOAPHandler1_close: But according to jsr224 9.3.2.1 Throw ProtocolException or a subclass This indicates that normal message processing should cease. Subsequent actions depend on whether the MEP in use requires a response to the message currently being processed or not: No response Normal message processing stops, close is called on each previously invoked handler in the chain, the exception is dispatched (see section 9.1.2.3). I also test the same case in WebSphere8.5 and Glassfish3.1.2.2, the message flow is: Server_SOAPHandler1_handleMessage_Inbound: Server_SOAPHandler2_handleMessage_Inbound: Server_LogicalHandler_handleMessage_Inbound: Server_countString: Server_LogicalHandler_handleMessage_Outbound: Server_LogicalHandler_close: Server_SOAPHandler2_close: Server_SOAPHandler1_close: The handleFault methods are not called, and the close methods are called directly, I think it matches the spec better. I also provide a patch for the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4559) Part of SoapMessage content interchange between two concurrent webservice calls
[
https://issues.apache.org/jira/browse/CXF-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476209#comment-13476209
]
csupi commented on CXF-4559:
You are right. I tried it. It really looks like a JAXB issue.
thank you
Part of SoapMessage content interchange between two concurrent webservice
calls
---
Key: CXF-4559
URL: https://issues.apache.org/jira/browse/CXF-4559
Project: CXF
Issue Type: Bug
Affects Versions: 2.5.4, 2.5.5, 2.5.6
Environment: Java 64-Bit Server 1.6.0_31
Ubuntu 12.04 64-Bit
Reporter: csupi
Assignee: Daniel Kulp
Priority: Critical
Fix For: Invalid
Attachments: ConcurrentTest.java,
ConcurrentTestPrecreatedJAXBContext.java
I have a simple cxf webservice call with a DTO parameter. There is a HashMap
and some other fields in the DTO.
I realized that there are some cases where the content in the map is changed
somewhere on the server side.
I created a simple unit test. I put a String into the map and into a field
where the map is. Create a webservice with jetty and create 15 clients to
call my webservice 1000 times.
After the test execution I realized that about in the 2% of the calls, the
String in the map differs from the value in the field.
Here is my unit test:
{noformat}
import java.io.Serializable;
import java.util.ArrayList;
import java.util.Collection;
import java.util.HashMap;
import java.util.UUID;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.atomic.AtomicInteger;
import javax.jws.WebParam;
import javax.jws.WebService;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import org.apache.cxf.interceptor.LoggingInInterceptor;
import org.apache.cxf.jaxws.JaxWsProxyFactoryBean;
import org.apache.cxf.jaxws.JaxWsServerFactoryBean;
import org.junit.Test;
public class WebserviceEndpointIt {
private static final int number_of_clients = 15;
private final AtomicInteger badCounter = new AtomicInteger(0);
private final AtomicInteger successCounter = new AtomicInteger(0);
@XmlAccessorType(XmlAccessType.FIELD)
public static class Event implements Serializable {
private static final long serialVersionUID = 1L;
private final HashMapString, Object map = new HashMapString,
Object();
private String expected;
private String i;
private String thread;
}
@WebService
public interface MockWebservice {
void doit(@WebParam(name = message) Event message);
}
public class MockWebserviceImpl implements MockWebservice {
@Override
public void doit(final Event message) {
/*
* read the two strings from the FIELD and the MAP
*/
final String expected = message.expected;
final Object idFromMap = message.map == null ? null :
message.map.get(expected);
if (expected == null || idFromMap == null ||
!expected.equals(idFromMap)) {
WebserviceEndpointIt.this.badCounter.incrementAndGet();
} else {
WebserviceEndpointIt.this.successCounter.incrementAndGet();
}
}
}
@Test
public void testMyWebService() throws InterruptedException,
ExecutionException {
final MockWebservice endpoint = new MockWebserviceImpl();
final JaxWsServerFactoryBean svrFactory = new
JaxWsServerFactoryBean();
svrFactory.setServiceClass(MockWebservice.class);
svrFactory.setAddress(http://localhost:9000/myService;);
svrFactory.setServiceBean(endpoint);
svrFactory.create();
svrFactory.getInInterceptors().add(new LoggingInInterceptor());
final CollectionCallableObject clients = new
ArrayListCallableObject();
for (int i = 0; i number_of_clients; i++) {
final int thread = i;
clients.add(new CallableObject() {
@Override
public Object call() throws Exception {
final MockWebservice client = createClient();
for (int i = 0; i 1000; i++) {
final Event message = new Event();
final String id = Integer.valueOf(thread).toString()
+ - + Integer.valueOf(i).toString() +
+ UUID.randomUUID().toString();
/*
* put the same string into the MAP and the FIELD
*/
message.map.put(expected, id);
[jira] [Created] (CXF-4566) StaxTransformFeature outTransformElements does not work when converting namespaces
Aki Yoshida created CXF-4566: Summary: StaxTransformFeature outTransformElements does not work when converting namespaces Key: CXF-4566 URL: https://issues.apache.org/jira/browse/CXF-4566 Project: CXF Issue Type: Bug Components: Core Affects Versions: 2.6.3 Reporter: Aki Yoshida Assignee: Aki Yoshida When replacing a namespace with another namespace, if some elements belonging to that namespace must retain that namespace, the transformation will result with the undeclared namespace for those elements. http://cxf.547215.n5.nabble.com/StaxTransformFeature-outTransformElements-problem-tc5716579.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4567) Couple error messages did not get moved to managers properties file
Daniel Kulp created CXF-4567: Summary: Couple error messages did not get moved to managers properties file Key: CXF-4567 URL: https://issues.apache.org/jira/browse/CXF-4567 Project: CXF Issue Type: Bug Components: Core Affects Versions: 2.7.0, 2.6.3 Reporter: Daniel Kulp Assignee: Daniel Kulp Fix For: 2.6.4, 2.7.1 When several of the managers were moved to org/apache/cxf/bus/managers/, their error messages that were in their previos package Messages.properties were not moved with them. For example: NO_BINDING_FACTORY_EXC -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4567) Couple error messages did not get moved to managers properties file
[ https://issues.apache.org/jira/browse/CXF-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476343#comment-13476343 ] Daniel Kulp commented on CXF-4567: -- Actually, just the BindingFactoryManagerImpl Couple error messages did not get moved to managers properties file --- Key: CXF-4567 URL: https://issues.apache.org/jira/browse/CXF-4567 Project: CXF Issue Type: Bug Components: Core Affects Versions: 2.6.3, 2.7.0 Reporter: Daniel Kulp Assignee: Daniel Kulp Fix For: 2.6.4, 2.7.1 When several of the managers were moved to org/apache/cxf/bus/managers/, their error messages that were in their previos package Messages.properties were not moved with them. For example: NO_BINDING_FACTORY_EXC -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4568) Adding OAuthContextUtils
Thorsten Hoeger created CXF-4568: Summary: Adding OAuthContextUtils Key: CXF-4568 URL: https://issues.apache.org/jira/browse/CXF-4568 Project: CXF Issue Type: Improvement Components: JAX-RS Security Affects Versions: 2.7.1 Reporter: Thorsten Hoeger Priority: Minor Attachments: 0001-Added-OAuthContextutils.patch, 0002-checkstyle-changes.patch I'm using a small collection of utility methods I've written to check and assert some values of the OAuthContext in my REST methods. Now I just want to contribute them to CXF and I hope they help somebody. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4569) cxf-services-wsn-core doesn't support to be installed with other verion of CXF
Willem Jiang created CXF-4569: - Summary: cxf-services-wsn-core doesn't support to be installed with other verion of CXF Key: CXF-4569 URL: https://issues.apache.org/jira/browse/CXF-4569 Project: CXF Issue Type: Bug Components: Services Affects Versions: 2.7.0, 2.6.3, 2.5.6 Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.5.7, 2.6.4, 2.7.1 As WSN services is using JAX-WS API, it should not dependent on specification of CXF. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CXF-4565) The message flow is not correct when handler throw ProtocolException outbound
[ https://issues.apache.org/jira/browse/CXF-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-4565: - Assignee: Freeman Fang The message flow is not correct when handler throw ProtocolException outbound - Key: CXF-4565 URL: https://issues.apache.org/jira/browse/CXF-4565 Project: CXF Issue Type: Bug Components: JAX-WS Runtime Reporter: Yi Xiao Assignee: Freeman Fang Labels: handler Attachments: cxf-4565.patch The scenario is using two SoapHandler and one LogicalHandler to intercept the message from client, and when LogicalHandler at server side handle the outbound message, it throws a ProtocolException. Now, the message flow at server side in CXF is: Server_SOAPHandler1_handleMessage_Inbound: Server_SOAPHandler2_handleMessage_Inbound: Server_LogicalHandler_handleMessage_Inbound: Server_countString: Server_LogicalHandler_handleMessage_Outbound: Server_LogicalHandler_handleFault_Outbound: // All of the three Server_SOAPHandler2_handleFault_Outbound: // handlerFault methods Server_SOAPHandler1_handleFault_Outbound: // are invoked Server_LogicalHandler_close: Server_SOAPHandler2_close: Server_SOAPHandler1_close: But according to jsr224 9.3.2.1 Throw ProtocolException or a subclass This indicates that normal message processing should cease. Subsequent actions depend on whether the MEP in use requires a response to the message currently being processed or not: No response Normal message processing stops, close is called on each previously invoked handler in the chain, the exception is dispatched (see section 9.1.2.3). I also test the same case in WebSphere8.5 and Glassfish3.1.2.2, the message flow is: Server_SOAPHandler1_handleMessage_Inbound: Server_SOAPHandler2_handleMessage_Inbound: Server_LogicalHandler_handleMessage_Inbound: Server_countString: Server_LogicalHandler_handleMessage_Outbound: Server_LogicalHandler_close: Server_SOAPHandler2_close: Server_SOAPHandler1_close: The handleFault methods are not called, and the close methods are called directly, I think it matches the spec better. I also provide a patch for the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4569) cxf-services-wsn-core doesn't support to be installed with other verion of CXF
[ https://issues.apache.org/jira/browse/CXF-4569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CXF-4569. --- Resolution: Fixed Applied the patch into trunk, 2.6.x-fixes and 2.5.x-fixes branches. cxf-services-wsn-core doesn't support to be installed with other verion of CXF -- Key: CXF-4569 URL: https://issues.apache.org/jira/browse/CXF-4569 Project: CXF Issue Type: Bug Components: Services Affects Versions: 2.5.6, 2.6.3, 2.7.0 Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.5.7, 2.6.4, 2.7.1 As WSN services is using JAX-WS API, it should not dependent on specification of CXF. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4570) Attachment Header Content-ID conversion
Jinhua Wang created CXF-4570: Summary: Attachment Header Content-ID conversion Key: CXF-4570 URL: https://issues.apache.org/jira/browse/CXF-4570 Project: CXF Issue Type: Bug Components: JAX-WS Runtime Reporter: Jinhua Wang Attachments: AttachmentUtil.java.patch I have a migrating problem for headers in attachment. For example, the message sent out contains Content-ID:foo, Content-ID header value is foo instead of foo at server side. When creating attachment of the following code: org.apache.cxf.attachment.AttachmentUtil.createAttachment(InputStream, InternetHeaders) There's a id conversion at first. But in the following header processing, there's no id conversion for Content-ID. Since Content-ID conversion is needed for id(new AttachmentImpl(id)), I think it is also useful for headers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4570) Attachment Header Content-ID conversion
[ https://issues.apache.org/jira/browse/CXF-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinhua Wang updated CXF-4570: - Attachment: AttachmentUtil.java.patch Attachment Header Content-ID conversion --- Key: CXF-4570 URL: https://issues.apache.org/jira/browse/CXF-4570 Project: CXF Issue Type: Bug Components: JAX-WS Runtime Reporter: Jinhua Wang Attachments: AttachmentUtil.java.patch I have a migrating problem for headers in attachment. For example, the message sent out contains Content-ID:foo, Content-ID header value is foo instead of foo at server side. When creating attachment of the following code: org.apache.cxf.attachment.AttachmentUtil.createAttachment(InputStream, InternetHeaders) There's a id conversion at first. But in the following header processing, there's no id conversion for Content-ID. Since Content-ID conversion is needed for id(new AttachmentImpl(id)), I think it is also useful for headers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4565) The message flow is not correct when handler throw ProtocolException outbound
[ https://issues.apache.org/jira/browse/CXF-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-4565. --- Resolution: Fixed Fix Version/s: 2.7.1 2.6.4 2.5.7 2.4.11 apply patch on behalf of Yi Xiao with thanks http://svn.apache.org/viewvc?rev=1398629view=rev for trunk http://svn.apache.org/viewvc?rev=1398632view=rev for 2.6.x branch http://svn.apache.org/viewvc?rev=1398633view=rev for 2.5.x branch http://svn.apache.org/viewvc?rev=1398636view=rev for 2.4.x branch The message flow is not correct when handler throw ProtocolException outbound - Key: CXF-4565 URL: https://issues.apache.org/jira/browse/CXF-4565 Project: CXF Issue Type: Bug Components: JAX-WS Runtime Reporter: Yi Xiao Assignee: Freeman Fang Labels: handler Fix For: 2.4.11, 2.5.7, 2.6.4, 2.7.1 Attachments: cxf-4565.patch The scenario is using two SoapHandler and one LogicalHandler to intercept the message from client, and when LogicalHandler at server side handle the outbound message, it throws a ProtocolException. Now, the message flow at server side in CXF is: Server_SOAPHandler1_handleMessage_Inbound: Server_SOAPHandler2_handleMessage_Inbound: Server_LogicalHandler_handleMessage_Inbound: Server_countString: Server_LogicalHandler_handleMessage_Outbound: Server_LogicalHandler_handleFault_Outbound: // All of the three Server_SOAPHandler2_handleFault_Outbound: // handlerFault methods Server_SOAPHandler1_handleFault_Outbound: // are invoked Server_LogicalHandler_close: Server_SOAPHandler2_close: Server_SOAPHandler1_close: But according to jsr224 9.3.2.1 Throw ProtocolException or a subclass This indicates that normal message processing should cease. Subsequent actions depend on whether the MEP in use requires a response to the message currently being processed or not: No response Normal message processing stops, close is called on each previously invoked handler in the chain, the exception is dispatched (see section 9.1.2.3). I also test the same case in WebSphere8.5 and Glassfish3.1.2.2, the message flow is: Server_SOAPHandler1_handleMessage_Inbound: Server_SOAPHandler2_handleMessage_Inbound: Server_LogicalHandler_handleMessage_Inbound: Server_countString: Server_LogicalHandler_handleMessage_Outbound: Server_LogicalHandler_close: Server_SOAPHandler2_close: Server_SOAPHandler1_close: The handleFault methods are not called, and the close methods are called directly, I think it matches the spec better. I also provide a patch for the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4565) The message flow is not correct when handler throw ProtocolException outbound
[ https://issues.apache.org/jira/browse/CXF-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476719#comment-13476719 ] Yi Xiao commented on CXF-4565: -- You are welcome. The message flow is not correct when handler throw ProtocolException outbound - Key: CXF-4565 URL: https://issues.apache.org/jira/browse/CXF-4565 Project: CXF Issue Type: Bug Components: JAX-WS Runtime Reporter: Yi Xiao Assignee: Freeman Fang Labels: handler Fix For: 2.4.11, 2.5.7, 2.6.4, 2.7.1 Attachments: cxf-4565.patch The scenario is using two SoapHandler and one LogicalHandler to intercept the message from client, and when LogicalHandler at server side handle the outbound message, it throws a ProtocolException. Now, the message flow at server side in CXF is: Server_SOAPHandler1_handleMessage_Inbound: Server_SOAPHandler2_handleMessage_Inbound: Server_LogicalHandler_handleMessage_Inbound: Server_countString: Server_LogicalHandler_handleMessage_Outbound: Server_LogicalHandler_handleFault_Outbound: // All of the three Server_SOAPHandler2_handleFault_Outbound: // handlerFault methods Server_SOAPHandler1_handleFault_Outbound: // are invoked Server_LogicalHandler_close: Server_SOAPHandler2_close: Server_SOAPHandler1_close: But according to jsr224 9.3.2.1 Throw ProtocolException or a subclass This indicates that normal message processing should cease. Subsequent actions depend on whether the MEP in use requires a response to the message currently being processed or not: No response Normal message processing stops, close is called on each previously invoked handler in the chain, the exception is dispatched (see section 9.1.2.3). I also test the same case in WebSphere8.5 and Glassfish3.1.2.2, the message flow is: Server_SOAPHandler1_handleMessage_Inbound: Server_SOAPHandler2_handleMessage_Inbound: Server_LogicalHandler_handleMessage_Inbound: Server_countString: Server_LogicalHandler_handleMessage_Outbound: Server_LogicalHandler_close: Server_SOAPHandler2_close: Server_SOAPHandler1_close: The handleFault methods are not called, and the close methods are called directly, I think it matches the spec better. I also provide a patch for the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
