December 2015 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3963) JBossWS 5.1.1.Final / 5.1.2.Final errata

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3963?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3963: ---------------------------------- Summary: JBossWS 5.1.1.Final / 5.1.2.Final errata (was: JBossWS 5.1.1.Final errata) > JBossWS 5.1.1.Final / 5.1.2.Final errata > ---------------------------------------- > > Key: JBWS-3963 > URL: https://issues.jboss.org/browse/JBWS-3963 > Project: JBoss Web Services > Issue Type: Task > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.1.1.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (JBWS-3969) Optimize JBossWSInvoker::invoke

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3969: ------------------------------------- Summary: Optimize JBossWSInvoker::invoke Key: JBWS-3969 URL: https://issues.jboss.org/browse/JBWS-3969 Project: JBoss Web Services Issue Type: Enhancement Components: jbossws-cxf, jbossws-integration Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-5.1.2.Final JBossWSInvoker::invoke calls ApacheCXF AbstractJAXWSMethodInvoker::adjustMethodAndParams which checks for the existence of @UseAsyncMethod annotation on the method to be invoked. That is expensive and not needed at all if that annotation is not used (it's a cxf specific one..). We should avoid doing the check if we already know from the Jandex index that there's not such annotation in the deployment. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (JBWS-3964) Incorrect behaviour with @WebParam(header = true, mode = IN)

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3964?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3964: ---------------------------------- Fix Version/s: jbossws-cxf-5.2.0.Final > Incorrect behaviour with @WebParam(header = true, mode = IN) > ------------------------------------------------------------ > > Key: JBWS-3964 > URL: https://issues.jboss.org/browse/JBWS-3964 > Project: JBoss Web Services > Issue Type: Bug > Environment: Wildfly 9.0.2 > Reporter: Xavier Dury > Assignee: Jim Ma > Fix For: jbossws-cxf-5.2.0.Final > > > Given the following simple WebService with incoming and outgoing header @WebParams: > {code} > @Stateless > @WebService(name = "MyEchoService", targetNamespace = "urn:echo") > public class MyEchoService { > > @WebResult(name = "result") > public String echo( > @WebParam(name = "message") String message, > @WebParam(name = "paramIn", mode = Mode.IN, header = true) Holder<String> paramIn, > @WebParam(name = "paramOut", mode = Mode.OUT, header = true) Holder<String> paramOut) { > paramOut.value = "got paramIn " + paramIn.value; > return "echo " + message; > } > } > {code} > The generated WSDL contains the following operation where the incoming @WebParam (mode = IN) is present in both input and ouput: > {code} > <wsdl:operation name="echo"> > <soap:operation soapAction="" style="document"/> > <wsdl:input name="echo"> > <soap:header message="tns:echo" part="paramIn" use="literal"></soap:header> > <soap:body parts="parameters" use="literal"/> > </wsdl:input> > <wsdl:output name="echoResponse"> > <soap:header message="tns:echoResponse" part="paramIn" use="literal"></soap:header> > <soap:header message="tns:echoResponse" part="paramOut" use="literal"></soap:header> > <soap:body parts="result" use="literal"/> > </wsdl:output> > </wsdl:operation> > {code} > We can see in the following exchange that the incoming @WebParam will be copied verbatim in the response: > {code} > <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:echo"> > <soapenv:Header> > <urn:paramIn>fred</urn:paramIn> > </soapenv:Header> > <soapenv:Body> > <urn:echo> > <urn:message>hello world!</urn:message> > </urn:echo> > </soapenv:Body> > </soapenv:Envelope> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> > <soap:Header> > <paramIn xmlns="urn:echo">fred</paramIn> > <paramOut xmlns="urn:echo">got paramIn fred</paramOut> > </soap:Header> > <soap:Body> > <echoResponse xmlns="urn:echo"> > <result>echo hello world!</result> > </echoResponse> > </soap:Body> > </soap:Envelope> > {code} > When the incoming header @WebParam is not set, an empty element will be added to the body of the response: > {code} > <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:echo"> > <soapenv:Body> > <urn:echo> > <urn:message>hello world!</urn:message> > </urn:echo> > </soapenv:Body> > </soapenv:Envelope> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> > <soap:Header> > <paramOut xmlns="urn:echo">got paramIn null</paramOut> > </soap:Header> > <soap:Body> > <echoResponse xmlns="urn:echo"> > <result>echo hello world!</result> > </echoResponse> > <paramIn xsi:nil="true" xmlns="urn:echo" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> > </soap:Body> > </soap:Envelope> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (JBWS-3964) Incorrect behaviour with @WebParam(header = true, mode = IN)

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3964?page=com.atlassian.jira.plugin.... ] Alessio Soldano reopened JBWS-3964: ----------------------------------- Reopening to set dependency on CXF upgrade. This will be marked as solved here after upgrading to nex CXF version. > Incorrect behaviour with @WebParam(header = true, mode = IN) > ------------------------------------------------------------ > > Key: JBWS-3964 > URL: https://issues.jboss.org/browse/JBWS-3964 > Project: JBoss Web Services > Issue Type: Bug > Environment: Wildfly 9.0.2 > Reporter: Xavier Dury > Assignee: Jim Ma > > Given the following simple WebService with incoming and outgoing header @WebParams: > {code} > @Stateless > @WebService(name = "MyEchoService", targetNamespace = "urn:echo") > public class MyEchoService { > > @WebResult(name = "result") > public String echo( > @WebParam(name = "message") String message, > @WebParam(name = "paramIn", mode = Mode.IN, header = true) Holder<String> paramIn, > @WebParam(name = "paramOut", mode = Mode.OUT, header = true) Holder<String> paramOut) { > paramOut.value = "got paramIn " + paramIn.value; > return "echo " + message; > } > } > {code} > The generated WSDL contains the following operation where the incoming @WebParam (mode = IN) is present in both input and ouput: > {code} > <wsdl:operation name="echo"> > <soap:operation soapAction="" style="document"/> > <wsdl:input name="echo"> > <soap:header message="tns:echo" part="paramIn" use="literal"></soap:header> > <soap:body parts="parameters" use="literal"/> > </wsdl:input> > <wsdl:output name="echoResponse"> > <soap:header message="tns:echoResponse" part="paramIn" use="literal"></soap:header> > <soap:header message="tns:echoResponse" part="paramOut" use="literal"></soap:header> > <soap:body parts="result" use="literal"/> > </wsdl:output> > </wsdl:operation> > {code} > We can see in the following exchange that the incoming @WebParam will be copied verbatim in the response: > {code} > <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:echo"> > <soapenv:Header> > <urn:paramIn>fred</urn:paramIn> > </soapenv:Header> > <soapenv:Body> > <urn:echo> > <urn:message>hello world!</urn:message> > </urn:echo> > </soapenv:Body> > </soapenv:Envelope> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> > <soap:Header> > <paramIn xmlns="urn:echo">fred</paramIn> > <paramOut xmlns="urn:echo">got paramIn fred</paramOut> > </soap:Header> > <soap:Body> > <echoResponse xmlns="urn:echo"> > <result>echo hello world!</result> > </echoResponse> > </soap:Body> > </soap:Envelope> > {code} > When the incoming header @WebParam is not set, an empty element will be added to the body of the response: > {code} > <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:echo"> > <soapenv:Body> > <urn:echo> > <urn:message>hello world!</urn:message> > </urn:echo> > </soapenv:Body> > </soapenv:Envelope> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> > <soap:Header> > <paramOut xmlns="urn:echo">got paramIn null</paramOut> > </soap:Header> > <soap:Body> > <echoResponse xmlns="urn:echo"> > <result>echo hello world!</result> > </echoResponse> > <paramIn xsi:nil="true" xmlns="urn:echo" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> > </soap:Body> > </soap:Envelope> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (JBWS-3966) Avoid calling BusFactory.setThreadDefaultBus(null) in JBossWSInvoker

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3966?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3966: ---------------------------------- Fix Version/s: jbossws-cxf-5.1.2.Final (was: jbossws-cxf-5.2.0.Final) > Avoid calling BusFactory.setThreadDefaultBus(null) in JBossWSInvoker > -------------------------------------------------------------------- > > Key: JBWS-3966 > URL: https://issues.jboss.org/browse/JBWS-3966 > Project: JBoss Web Services > Issue Type: Enhancement > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.1.2.Final > > > The invocation BusFactory.setThreadDefaultBus(null) in JBossWSInvoker (just before invoking the actual user endpoint business code) is problematic performance-wise because CXF internally removes the ThreadLocal association of the current thread bus with the thread. When the JBossWSInvoker restores the former thread default bus just after the user endpoint business code execution, that ThreadLocal being unset causes CXF to access the BusFactory THREAD_BUSSES WeakHashMap within a synchronized block. Under heavy load, this easily become one of the contention hot spots in the WS invocation. > Now, the reason why the JBossWSInvoker calls BusFactory.setThreadDefaultBus(null) is to prevent the user from having access to the Bus that the integration code uses for running the deployment endpoints, to prevent users from influencing or breaking the integration (response processing, for example) in any way. > To be honest this also has a minor side effect of always wiping a thread default Bus the user might have set in its endpoint business code, regardless of which thread the code is being executed on. > As a consequence, it makes sense to create an additional Bus for the user endpoint code; that Bus will be set as thread default each time the JBossWSInvoker handles control to business methods of endpoints from the same deployment. This would prevent the BusFactory ThreadLocal from being removed (performance improvement when the integration deployment bus is later restored) and give back the same bus to the user on multiple invocations to the same deployment's endpoints. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (JBWS-3967) Upgrade to JAXB 2.2.11-jbossorg-1

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3967?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3967: ---------------------------------- Fix Version/s: jbossws-cxf-5.1.2.Final (was: jbossws-cxf-5.2.0.Final) > Upgrade to JAXB 2.2.11-jbossorg-1 > --------------------------------- > > Key: JBWS-3967 > URL: https://issues.jboss.org/browse/JBWS-3967 > Project: JBoss Web Services > Issue Type: Component Upgrade > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.1.2.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (JBWS-3964) Incorrect behaviour with @WebParam(header = true, mode = IN)

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/JBWS-3964?page=com.atlassian.jira.plugin.... ] Jim Ma commented on JBWS-3964: ------------------------------ Holder parameter should not be annotated with the Mode.IN. CXF ignores this "IN" property and always treat it as a out parameter, but we need to add some warning messing for such holder parameter in CXF and let user know what's going on. > Incorrect behaviour with @WebParam(header = true, mode = IN) > ------------------------------------------------------------ > > Key: JBWS-3964 > URL: https://issues.jboss.org/browse/JBWS-3964 > Project: JBoss Web Services > Issue Type: Bug > Environment: Wildfly 9.0.2 > Reporter: Xavier Dury > Assignee: Jim Ma > > Given the following simple WebService with incoming and outgoing header @WebParams: > {code} > @Stateless > @WebService(name = "MyEchoService", targetNamespace = "urn:echo") > public class MyEchoService { > > @WebResult(name = "result") > public String echo( > @WebParam(name = "message") String message, > @WebParam(name = "paramIn", mode = Mode.IN, header = true) Holder<String> paramIn, > @WebParam(name = "paramOut", mode = Mode.OUT, header = true) Holder<String> paramOut) { > paramOut.value = "got paramIn " + paramIn.value; > return "echo " + message; > } > } > {code} > The generated WSDL contains the following operation where the incoming @WebParam (mode = IN) is present in both input and ouput: > {code} > <wsdl:operation name="echo"> > <soap:operation soapAction="" style="document"/> > <wsdl:input name="echo"> > <soap:header message="tns:echo" part="paramIn" use="literal"></soap:header> > <soap:body parts="parameters" use="literal"/> > </wsdl:input> > <wsdl:output name="echoResponse"> > <soap:header message="tns:echoResponse" part="paramIn" use="literal"></soap:header> > <soap:header message="tns:echoResponse" part="paramOut" use="literal"></soap:header> > <soap:body parts="result" use="literal"/> > </wsdl:output> > </wsdl:operation> > {code} > We can see in the following exchange that the incoming @WebParam will be copied verbatim in the response: > {code} > <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:echo"> > <soapenv:Header> > <urn:paramIn>fred</urn:paramIn> > </soapenv:Header> > <soapenv:Body> > <urn:echo> > <urn:message>hello world!</urn:message> > </urn:echo> > </soapenv:Body> > </soapenv:Envelope> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> > <soap:Header> > <paramIn xmlns="urn:echo">fred</paramIn> > <paramOut xmlns="urn:echo">got paramIn fred</paramOut> > </soap:Header> > <soap:Body> > <echoResponse xmlns="urn:echo"> > <result>echo hello world!</result> > </echoResponse> > </soap:Body> > </soap:Envelope> > {code} > When the incoming header @WebParam is not set, an empty element will be added to the body of the response: > {code} > <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:echo"> > <soapenv:Body> > <urn:echo> > <urn:message>hello world!</urn:message> > </urn:echo> > </soapenv:Body> > </soapenv:Envelope> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> > <soap:Header> > <paramOut xmlns="urn:echo">got paramIn null</paramOut> > </soap:Header> > <soap:Body> > <echoResponse xmlns="urn:echo"> > <result>echo hello world!</result> > </echoResponse> > <paramIn xsi:nil="true" xmlns="urn:echo" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> > </soap:Body> > </soap:Envelope> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (JBWS-3968) Upgrade to Apache CXF 3.2

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3968: ------------------------------------- Summary: Upgrade to Apache CXF 3.2 Key: JBWS-3968 URL: https://issues.jboss.org/browse/JBWS-3968 Project: JBoss Web Services Issue Type: Component Upgrade Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-5.2.0.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (JBWS-3966) Avoid calling BusFactory.setThreadDefaultBus(null) in JBossWSInvoker

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3966?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3966: --------------------------------------- Done. The former behaviour (thread default bus set to null just before invoking the endpoint business call) can be restored globally on the server by setting the "org.jboss.ws.cxf.disable-deployment-user-default-thread-bus" system property to true. > Avoid calling BusFactory.setThreadDefaultBus(null) in JBossWSInvoker > -------------------------------------------------------------------- > > Key: JBWS-3966 > URL: https://issues.jboss.org/browse/JBWS-3966 > Project: JBoss Web Services > Issue Type: Enhancement > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.2.0.Final > > > The invocation BusFactory.setThreadDefaultBus(null) in JBossWSInvoker (just before invoking the actual user endpoint business code) is problematic performance-wise because CXF internally removes the ThreadLocal association of the current thread bus with the thread. When the JBossWSInvoker restores the former thread default bus just after the user endpoint business code execution, that ThreadLocal being unset causes CXF to access the BusFactory THREAD_BUSSES WeakHashMap within a synchronized block. Under heavy load, this easily become one of the contention hot spots in the WS invocation. > Now, the reason why the JBossWSInvoker calls BusFactory.setThreadDefaultBus(null) is to prevent the user from having access to the Bus that the integration code uses for running the deployment endpoints, to prevent users from influencing or breaking the integration (response processing, for example) in any way. > To be honest this also has a minor side effect of always wiping a thread default Bus the user might have set in its endpoint business code, regardless of which thread the code is being executed on. > As a consequence, it makes sense to create an additional Bus for the user endpoint code; that Bus will be set as thread default each time the JBossWSInvoker handles control to business methods of endpoints from the same deployment. This would prevent the BusFactory ThreadLocal from being removed (performance improvement when the integration deployment bus is later restored) and give back the same bus to the user on multiple invocations to the same deployment's endpoints. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (JBWS-3966) Avoid calling BusFactory.setThreadDefaultBus(null) in JBossWSInvoker

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3966?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3966: ---------------------------------- Description: The invocation BusFactory.setThreadDefaultBus(null) in JBossWSInvoker (just before invoking the actual user endpoint business code) is problematic performance-wise because CXF internally removes the ThreadLocal association of the current thread bus with the thread. When the JBossWSInvoker restores the former thread default bus just after the user endpoint business code execution, that ThreadLocal being unset causes CXF to access the BusFactory THREAD_BUSSES WeakHashMap within a synchronized block. Under heavy load, this easily become one of the contention hot spots in the WS invocation. Now, the reason why the JBossWSInvoker calls BusFactory.setThreadDefaultBus(null) is to prevent the user from having access to the Bus that the integration code uses for running the deployment endpoints, to prevent users from influencing or breaking the integration (response processing, for example) in any way. To be honest this also has a minor side effect of always wiping a thread default Bus the user might have set in its endpoint business code, regardless of which thread the code is being executed on. As a consequence, it makes sense to create an additional Bus for the user endpoint code; that Bus will be set as thread default each time the JBossWSInvoker handles control to business methods of endpoints from the same deployment. This would prevent the BusFactory ThreadLocal from being removed (performance improvement when the integration deployment bus is later restored) and give back the same bus to the user on multiple invocations to the same deployment's endpoints. was: The invocation to Analyse if we can avoid invoking BusFactory::setThreadDefaultBus in some scenarios, to reduce contention on its THREAD_BUSSES WeakHashMap. > Avoid calling BusFactory.setThreadDefaultBus(null) in JBossWSInvoker > -------------------------------------------------------------------- > > Key: JBWS-3966 > URL: https://issues.jboss.org/browse/JBWS-3966 > Project: JBoss Web Services > Issue Type: Enhancement > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.2.0.Final > > > The invocation BusFactory.setThreadDefaultBus(null) in JBossWSInvoker (just before invoking the actual user endpoint business code) is problematic performance-wise because CXF internally removes the ThreadLocal association of the current thread bus with the thread. When the JBossWSInvoker restores the former thread default bus just after the user endpoint business code execution, that ThreadLocal being unset causes CXF to access the BusFactory THREAD_BUSSES WeakHashMap within a synchronized block. Under heavy load, this easily become one of the contention hot spots in the WS invocation. > Now, the reason why the JBossWSInvoker calls BusFactory.setThreadDefaultBus(null) is to prevent the user from having access to the Bus that the integration code uses for running the deployment endpoints, to prevent users from influencing or breaking the integration (response processing, for example) in any way. > To be honest this also has a minor side effect of always wiping a thread default Bus the user might have set in its endpoint business code, regardless of which thread the code is being executed on. > As a consequence, it makes sense to create an additional Bus for the user endpoint code; that Bus will be set as thread default each time the JBossWSInvoker handles control to business methods of endpoints from the same deployment. This would prevent the BusFactory ThreadLocal from being removed (performance improvement when the integration deployment bus is later restored) and give back the same bus to the user on multiple invocations to the same deployment's endpoints. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues December 2015