March 2014 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3777) wsp:Optional isn't adhered to for WS-RM policy in WSDL

by Tadayoshi Sato (JIRA)

[ https://issues.jboss.org/browse/JBWS-3777?page=com.atlassian.jira.plugin.... ] Tadayoshi Sato updated JBWS-3777: --------------------------------- Description: The {{wsp:Optional}} attribute doesn't work for WS-RM in JBoss WS CXF. As far as the specs tell both WS-Addressing 1.0 and WS-RM 1.1 should support {{wsp:Optional}}, that is, if {{wsp:Optional}} is set to {{true}} on a WS-RM policy the WS-RM policy should become optional -- the endpoint should allow both messages with and without WS-RM. However, my experimentation showed that it actually doesn't. Incidentally, I couldn't reproduce the same issue on a bare CXF runtime, so I believe this is purely a JBoss WS issue. What I did is as follows (see the attached reproducer for details): # Configured in WSDL ({{greeting.wsdl}}) an endpoint as optionally WS-RM enabled like the following: {code:xml} <wsdl:binding name="GreetingServiceSoapBinding" type="tns:GreetingService"> <wsp:Policy xmlns:wsp="http://www.w3.org/2006/07/ws-policy"> <wsam:Addressing xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata" wsp:Optional="true" /> <wsrmp:RMAssertion xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy" wsp:Optional="true" /> </wsp:Policy> ... {code} # Sent a WS-RM unaware (= no SOAP header) SOAP request from the client but got the following SOAP Fault: {code:xml} <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <faultstring>WS-Addressing is required by this endpoint.</faultstring> </soap:Fault> </soap:Body> </soap:Envelope> {code} [1] In WS-RM Policy 1.1 p.8: {quote} /wsrmp:RMAssertion/@wsp:Optional="true" Per WS-Policy, this is compact notation for two policy alternatives, one with and one without the assertion. The intuition is that the behavior indicated by the assertion is optional, or in this case, that WS-ReliableMessaging MAY be used. {quote} was: The {{wsp:Optional}} attribute doesn't work for WS-RM in JBoss WS CXF. As far as the specs tell both WS-Addressing 1.0 and WS-RM 1.1 should support {{wsp:Optional}}, that is, if {{wsp:Optional}} is set to {{true}} on a WS-RM policy the WS-RM policy should become optional - the endpoint should allow both messages with and without WS-RM. However, my experimentation showed that it actually doesn't. Incidentally, I couldn't reproduce the same issue on a bare CXF runtime, so I believe this is purely a JBoss WS issue. What I did is as follows (see the attached reproducer for details): # Configured in WSDL ({{greeting.wsdl}}) an endpoint as optionally WS-RM enabled like the following: {code:xml} <wsdl:binding name="GreetingServiceSoapBinding" type="tns:GreetingService"> <wsp:Policy xmlns:wsp="http://www.w3.org/2006/07/ws-policy"> <wsam:Addressing xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata" wsp:Optional="true" /> <wsrmp:RMAssertion xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy" wsp:Optional="true" /> </wsp:Policy> ... {code} # Sent a WS-RM unaware (= no SOAP header) SOAP request from the client but got the following SOAP Fault: {code:xml} <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <faultstring>WS-Addressing is required by this endpoint.</faultstring> </soap:Fault> </soap:Body> </soap:Envelope> {code} [1] In WS-RM Policy 1.1 p.8: {quote} /wsrmp:RMAssertion/@wsp:Optional="true" Per WS-Policy, this is compact notation for two policy alternatives, one with and one without the assertion. The intuition is that the behavior indicated by the assertion is optional, or in this case, that WS-ReliableMessaging MAY be used. {quote} > wsp:Optional isn't adhered to for WS-RM policy in WSDL > ------------------------------------------------------ > > Key: JBWS-3777 > URL: https://issues.jboss.org/browse/JBWS-3777 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.2.3 > Environment: Red Hat JBoss EAP 6.2.0 > Reporter: Tadayoshi Sato > > The {{wsp:Optional}} attribute doesn't work for WS-RM in JBoss WS CXF. As far as the specs tell both WS-Addressing 1.0 and WS-RM 1.1 should support {{wsp:Optional}}, that is, if {{wsp:Optional}} is set to {{true}} on a WS-RM policy the WS-RM policy should become optional -- the endpoint should allow both messages with and without WS-RM. However, my experimentation showed that it actually doesn't. > Incidentally, I couldn't reproduce the same issue on a bare CXF runtime, so I believe this is purely a JBoss WS issue. > What I did is as follows (see the attached reproducer for details): > # Configured in WSDL ({{greeting.wsdl}}) an endpoint as optionally WS-RM enabled like the following: > {code:xml} > <wsdl:binding name="GreetingServiceSoapBinding" type="tns:GreetingService"> > <wsp:Policy xmlns:wsp="http://www.w3.org/2006/07/ws-policy"> > <wsam:Addressing xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata" wsp:Optional="true" /> > <wsrmp:RMAssertion xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy" > wsp:Optional="true" /> > </wsp:Policy> > ... > {code} > # Sent a WS-RM unaware (= no SOAP header) SOAP request from the client but got the following SOAP Fault: > {code:xml} > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> > <soap:Body> > <soap:Fault> > <faultcode>soap:Server</faultcode> > <faultstring>WS-Addressing is required by this endpoint.</faultstring> > </soap:Fault> > </soap:Body> > </soap:Envelope> > {code} > [1] In WS-RM Policy 1.1 p.8: > {quote} > /wsrmp:RMAssertion/@wsp:Optional="true" > Per WS-Policy, this is compact notation for two policy alternatives, one with and one without the assertion. The intuition is that the behavior indicated by the assertion is optional, or in this case, that WS-ReliableMessaging MAY be used. > {quote} -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3777) wsp:Optional isn't adhered to for WS-RM policy in WSDL

by Tadayoshi Sato (JIRA)

Tadayoshi Sato created JBWS-3777: ------------------------------------ Summary: wsp:Optional isn't adhered to for WS-RM policy in WSDL Key: JBWS-3777 URL: https://issues.jboss.org/browse/JBWS-3777 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Affects Versions: jbossws-cxf-4.2.3 Environment: Red Hat JBoss EAP 6.2.0 Reporter: Tadayoshi Sato The {{wsp:Optional}} attribute doesn't work for WS-RM in JBoss WS CXF. As far as the specs tell both WS-Addressing 1.0 and WS-RM 1.1 should support {{wsp:Optional}}, that is, if {{wsp:Optional}} is set to {{true}} on a WS-RM policy the WS-RM policy should become optional - the endpoint should allow both messages with and without WS-RM. However, my experimentation showed that it actually doesn't. Incidentally, I couldn't reproduce the same issue on a bare CXF runtime, so I believe this is purely a JBoss WS issue. What I did is as follows (see the attached reproducer for details): # Configured in WSDL ({{greeting.wsdl}}) an endpoint as optionally WS-RM enabled like the following: {code:xml} <wsdl:binding name="GreetingServiceSoapBinding" type="tns:GreetingService"> <wsp:Policy xmlns:wsp="http://www.w3.org/2006/07/ws-policy"> <wsam:Addressing xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata" wsp:Optional="true" /> <wsrmp:RMAssertion xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy" wsp:Optional="true" /> </wsp:Policy> ... {code} # Sent a WS-RM unaware (= no SOAP header) SOAP request from the client but got the following SOAP Fault: {code:xml} <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <faultstring>WS-Addressing is required by this endpoint.</faultstring> </soap:Fault> </soap:Body> </soap:Envelope> {code} [1] In WS-RM Policy 1.1 p.8: {quote} /wsrmp:RMAssertion/@wsp:Optional="true" Per WS-Policy, this is compact notation for two policy alternatives, one with and one without the assertion. The intuition is that the behavior indicated by the assertion is optional, or in this case, that WS-ReliableMessaging MAY be used. {quote} -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3593) multipart/related messages exchanged for @MTOM annotated endpoint even if no attachment is included

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3593?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3593: --------------------------------------- I don't know where in the EAP documentation that is mentioned explicitly. In the community JBossWS doc, that is mentioned at https://docs.jboss.org/author/display/JBWS/JBoss+Modules (see the first yellow warning box). To be honest, I've also added come comments on this topic in few testcases in the sources, as unfortunately it's easy to forgot about the required dependencies and the server core is silent on this. > multipart/related messages exchanged for @MTOM annotated endpoint even if no attachment is included > --------------------------------------------------------------------------------------------------- > > Key: JBWS-3593 > URL: https://issues.jboss.org/browse/JBWS-3593 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-native > Affects Versions: jbossws-cxf-4.0.2, jbossws-native-4.0.2 > Environment: Jboss AS 7.1.1Final > Reporter: A l e c C R E S T A N > Assignee: Alessio Soldano > > On JBoss AS 7.1.1, with the following service implementation: > {code} > @WebService(...) > @javax.xml.ws.BindingType (value=javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_MTOM_BINDING) > public class SEIImpl { > ... > public DataHandler getBin() {...} /* maps to a type="xs:base64Binary" in wsdl */ > public List<String> getString(){...} /* maps to sequence of String in wsdl */ > ... > } > {code} > With the default *jbossws-cxf*, the responses are: > - for getString() method > Content-Type: multipart/related; type="application/xop+xml"; ... > - for getBin() method > Content-Type: multipart/related; type="application/xop+xml"; ... > -> +both responses are MTOM/XOP modified ! The getString() response should not.+ > With *jbossws-native* (after the jbossws stack switching) , the responses are the expected ones: > - for getString() method > Content-Type: text/xml;charset=UTF-8 <env:Envelope .... text content ..../env:Envelope> > - for getBin() method > Content-Type: multipart/related; type="application/xop+xml"; ... > Best regards, > Note: same behaviour with @javax.xml.ws.soap.MTOM or SOAP11HTTP_MTOM_BINDING -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3593) multipart/related messages exchanged for @MTOM annotated endpoint even if no attachment is included

by Massimiliano Calipari (JIRA)

[ https://issues.jboss.org/browse/JBWS-3593?page=com.atlassian.jira.plugin.... ] Massimiliano Calipari commented on JBWS-3593: --------------------------------------------- Thanks, that was missing. Now it works as expected. Btw, I read the documentation for Jboss EAP but I think I miss that advice, could you please post where to find it? > multipart/related messages exchanged for @MTOM annotated endpoint even if no attachment is included > --------------------------------------------------------------------------------------------------- > > Key: JBWS-3593 > URL: https://issues.jboss.org/browse/JBWS-3593 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-native > Affects Versions: jbossws-cxf-4.0.2, jbossws-native-4.0.2 > Environment: Jboss AS 7.1.1Final > Reporter: A l e c C R E S T A N > Assignee: Alessio Soldano > > On JBoss AS 7.1.1, with the following service implementation: > {code} > @WebService(...) > @javax.xml.ws.BindingType (value=javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_MTOM_BINDING) > public class SEIImpl { > ... > public DataHandler getBin() {...} /* maps to a type="xs:base64Binary" in wsdl */ > public List<String> getString(){...} /* maps to sequence of String in wsdl */ > ... > } > {code} > With the default *jbossws-cxf*, the responses are: > - for getString() method > Content-Type: multipart/related; type="application/xop+xml"; ... > - for getBin() method > Content-Type: multipart/related; type="application/xop+xml"; ... > -> +both responses are MTOM/XOP modified ! The getString() response should not.+ > With *jbossws-native* (after the jbossws stack switching) , the responses are the expected ones: > - for getString() method > Content-Type: text/xml;charset=UTF-8 <env:Envelope .... text content ..../env:Envelope> > - for getBin() method > Content-Type: multipart/related; type="application/xop+xml"; ... > Best regards, > Note: same behaviour with @javax.xml.ws.soap.MTOM or SOAP11HTTP_MTOM_BINDING -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3593) multipart/related messages exchanged for @MTOM annotated endpoint even if no attachment is included

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3593?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3593: --------------------------------------- Just to be sure, did you add a module dependency to 'org.apache.cxf' (either in MANIFEST.MF or throught jboss-deployment-structure.xml) ? > multipart/related messages exchanged for @MTOM annotated endpoint even if no attachment is included > --------------------------------------------------------------------------------------------------- > > Key: JBWS-3593 > URL: https://issues.jboss.org/browse/JBWS-3593 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-native > Affects Versions: jbossws-cxf-4.0.2, jbossws-native-4.0.2 > Environment: Jboss AS 7.1.1Final > Reporter: A l e c C R E S T A N > Assignee: Alessio Soldano > > On JBoss AS 7.1.1, with the following service implementation: > {code} > @WebService(...) > @javax.xml.ws.BindingType (value=javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_MTOM_BINDING) > public class SEIImpl { > ... > public DataHandler getBin() {...} /* maps to a type="xs:base64Binary" in wsdl */ > public List<String> getString(){...} /* maps to sequence of String in wsdl */ > ... > } > {code} > With the default *jbossws-cxf*, the responses are: > - for getString() method > Content-Type: multipart/related; type="application/xop+xml"; ... > - for getBin() method > Content-Type: multipart/related; type="application/xop+xml"; ... > -> +both responses are MTOM/XOP modified ! The getString() response should not.+ > With *jbossws-native* (after the jbossws stack switching) , the responses are the expected ones: > - for getString() method > Content-Type: text/xml;charset=UTF-8 <env:Envelope .... text content ..../env:Envelope> > - for getBin() method > Content-Type: multipart/related; type="application/xop+xml"; ... > Best regards, > Note: same behaviour with @javax.xml.ws.soap.MTOM or SOAP11HTTP_MTOM_BINDING -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3593) multipart/related messages exchanged for @MTOM annotated endpoint even if no attachment is included

by Massimiliano Calipari (JIRA)

[ https://issues.jboss.org/browse/JBWS-3593?page=com.atlassian.jira.plugin.... ] Massimiliano Calipari commented on JBWS-3593: --------------------------------------------- Hi Alessio, I'm trying to apply your workaround to a WS while migrating it to JBoss EAP 6.2 Strangely the Interceptor is ignored and not loaded at all. I tried both the @ OutInterceptors annotation and jbossws-cxf.xml configuration without success. Moreover, the jbossws-cxf.xml configuration set the MTOM processing to true on the same end-point. The MTOM configuration works, the interceptor none. {code:xml} <jaxws:endpoint implementor="MyWS" implementorClass="mypackage.MyWS"> <jaxws:outInterceptors> <bean class="mypackage.cxf.MTOMOutInterceptor" /> </jaxws:outInterceptors> <jaxws:properties> <entry key="mtom-enabled" value="true"/> </jaxws:properties> </jaxws:endpoint> {code} What can be wrong? > multipart/related messages exchanged for @MTOM annotated endpoint even if no attachment is included > --------------------------------------------------------------------------------------------------- > > Key: JBWS-3593 > URL: https://issues.jboss.org/browse/JBWS-3593 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-native > Affects Versions: jbossws-cxf-4.0.2, jbossws-native-4.0.2 > Environment: Jboss AS 7.1.1Final > Reporter: A l e c C R E S T A N > Assignee: Alessio Soldano > > On JBoss AS 7.1.1, with the following service implementation: > {code} > @WebService(...) > @javax.xml.ws.BindingType (value=javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_MTOM_BINDING) > public class SEIImpl { > ... > public DataHandler getBin() {...} /* maps to a type="xs:base64Binary" in wsdl */ > public List<String> getString(){...} /* maps to sequence of String in wsdl */ > ... > } > {code} > With the default *jbossws-cxf*, the responses are: > - for getString() method > Content-Type: multipart/related; type="application/xop+xml"; ... > - for getBin() method > Content-Type: multipart/related; type="application/xop+xml"; ... > -> +both responses are MTOM/XOP modified ! The getString() response should not.+ > With *jbossws-native* (after the jbossws stack switching) , the responses are the expected ones: > - for getString() method > Content-Type: text/xml;charset=UTF-8 <env:Envelope .... text content ..../env:Envelope> > - for getBin() method > Content-Type: multipart/related; type="application/xop+xml"; ... > Best regards, > Note: same behaviour with @javax.xml.ws.soap.MTOM or SOAP11HTTP_MTOM_BINDING -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3738) Expand WS-Trust / STS test coverage and documentation

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-3738?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-3738: -------------------------------- Committed working test for Holder-Of-Key, Committed revision 18535 > Expand WS-Trust / STS test coverage and documentation > ----------------------------------------------------- > > Key: JBWS-3738 > URL: https://issues.jboss.org/browse/JBWS-3738 > Project: JBoss Web Services > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: R Searls > Fix For: jbossws-cxf-4.4 > > > We should possibly cover more WS-Trust/STS scenarios in the testsuite (different SAML tokens, etc.) and expand the documentation accordingly. -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3773) HttpServletRequest in WebServiceContext and requests with WSA ReplyTo prop set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3773?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated JBWS-3773: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1077263, https://bugzilla.redhat.com/show_bug.cgi?id=1077259 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1077263) > HttpServletRequest in WebServiceContext and requests with WSA ReplyTo prop set > ------------------------------------------------------------------------------ > > Key: JBWS-3773 > URL: https://issues.jboss.org/browse/JBWS-3773 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.4 > > > See https://issues.apache.org/jira/browse/CXF-5602 > The HttpServletContext retrieved from the WebServiceContext can have stale values when running on AS 7 (using JBossWeb) and processing WS-Addressing requests with non generic ReplyTo header props. -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3773) HttpServletRequest in WebServiceContext and requests with WSA ReplyTo prop set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3773?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated JBWS-3773: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1077263 > HttpServletRequest in WebServiceContext and requests with WSA ReplyTo prop set > ------------------------------------------------------------------------------ > > Key: JBWS-3773 > URL: https://issues.jboss.org/browse/JBWS-3773 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.4 > > > See https://issues.apache.org/jira/browse/CXF-5602 > The HttpServletContext retrieved from the WebServiceContext can have stale values when running on AS 7 (using JBossWeb) and processing WS-Addressing requests with non generic ReplyTo header props. -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3773) HttpServletRequest in WebServiceContext and requests with WSA ReplyTo prop set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3773?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated JBWS-3773: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1077263, https://bugzilla.redhat.com/show_bug.cgi?id=1077259, https://bugzilla.redhat.com/show_bug.cgi?id=1077262 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1077263, https://bugzilla.redhat.com/show_bug.cgi?id=1077259) > HttpServletRequest in WebServiceContext and requests with WSA ReplyTo prop set > ------------------------------------------------------------------------------ > > Key: JBWS-3773 > URL: https://issues.jboss.org/browse/JBWS-3773 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.4 > > > See https://issues.apache.org/jira/browse/CXF-5602 > The HttpServletContext retrieved from the WebServiceContext can have stale values when running on AS 7 (using JBossWeb) and processing WS-Addressing requests with non generic ReplyTo header props. -- 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

10 years, 9 months

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 March 2014