August 2014 - jbossws-issues - Jboss List Archives

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

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3738?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3738: ---------------------------------- Fix Version/s: jbossws-cxf-5.0 (was: jbossws-cxf-5.0.0.Beta1) > 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-5.0 > > > We should possibly cover more WS-Trust/STS scenarios in the testsuite (different SAML tokens, etc.) and expand the documentation accordingly. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3816) WSTrustActAsTestCase.testActAs failing with move to cxf 3.0.2-SNAPSHOT

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3816?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3816: ---------------------------------- Fix Version/s: jbossws-cxf-5.0 (was: jbossws-cxf-5.0.0.Beta1) > WSTrustActAsTestCase.testActAs failing with move to cxf 3.0.2-SNAPSHOT > ---------------------------------------------------------------------- > > Key: JBWS-3816 > URL: https://issues.jboss.org/browse/JBWS-3816 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: R Searls > Assignee: R Searls > Priority: Minor > Fix For: jbossws-cxf-5.0 > > > WSTrustActAsTestCase.testActAs is failing with the following error > Stacktrace > javax.xml.ws.soap.SOAPFaultException: The specified request failed > at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:159) > at com.sun.proxy.$Proxy203.sayHello(Unknown Source) > at org.jboss.test.ws.jaxws.samples.wsse.policy.trust.WSTrustActAsTestCase.testActAs(WSTrustActAsTestCase.java:71) > 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:606) > at junit.framework.TestCase.runTest(TestCase.java:168) > at junit.framework.TestCase.runBare(TestCase.java:134) > at junit.framework.TestResult$1.protect(TestResult.java:110) > at junit.framework.TestResult.runProtected(TestResult.java:128) > at junit.framework.TestResult.run(TestResult.java:113) > at junit.framework.TestCase.run(TestCase.java:124) > at junit.framework.TestSuite.runTest(TestSuite.java:243) > at junit.framework.TestSuite.run(TestSuite.java:238) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at org.jboss.wsf.test.JBossWSTestSetup$1.protect(JBossWSTestSetup.java:141) > at junit.framework.TestResult.runProtected(TestResult.java:128) > at org.jboss.wsf.test.JBossWSTestSetup.run(JBossWSTestSetup.java:148) > at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114) > 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:606) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74) > Caused by: org.apache.cxf.binding.soap.SoapFault: The specified request failed > at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:84) > at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:51) > at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:40) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:113) > at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69) > at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:798) > at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1636) > at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1525) > at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1330) > at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) > at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:638) > at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279) > at org.apache.cxf.ws.security.trust.AbstractSTSClient.issue(AbstractSTSClient.java:839) > at org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:62) > at org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:56) > at org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:52) > at org.apache.cxf.ws.security.policy.interceptors.IssuedTokenInterceptorProvider$IssuedTokenOutInterceptor.getTokenFromSTS(IssuedTokenInterceptorProvider.java:394) > at org.apache.cxf.ws.security.policy.interceptors.IssuedTokenInterceptorProvider$IssuedTokenOutInterceptor.issueToken(IssuedTokenInterceptorProvider.java:523) > at org.apache.cxf.ws.security.policy.interceptors.IssuedTokenInterceptorProvider$IssuedTokenOutInterceptor.handleMessage(IssuedTokenInterceptorProvider.java:162) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137) > ... 31 more > Standard Error > Warning: org.apache.xerces.parsers.SAXParser: Property 'http://javax.xml.XMLConstants/property/accessExternalDTD' is not recognized. > Warning: org.apache.xerces.parsers.SAXParser: Property 'http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not recognized. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3817) Avoid globally installing BouncyCastle

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3817?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3817: ---------------------------------- Fix Version/s: jbossws-cxf-5.0 (was: jbossws-cxf-5.0.0.Beta1) > Avoid globally installing BouncyCastle > -------------------------------------- > > Key: JBWS-3817 > URL: https://issues.jboss.org/browse/JBWS-3817 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > > This is about preventing Apache CXF / WSS4J from installing BouncyCastle globally and actually setting its security provider at message exchange level as described in https://issues.apache.org/jira/browse/CXF-5905 . -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3514) HTTP session scope support

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3514?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3514: ---------------------------------- Fix Version/s: jbossws-cxf-5.0 (was: jbossws-cxf-5.0.0.Beta1) > HTTP session scope support > -------------------------- > > Key: JBWS-3514 > URL: https://issues.jboss.org/browse/JBWS-3514 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: Jim Ma > Fix For: jbossws-cxf-5.0 > > > Solerman Kaplon says: > "Hello everyone, after metro stack got discontinued and CXF becoming the de-facto stack for JbossWS, I'm missing the @HttpSessionScope annotation. Basically, it automatically adds the jsession id to every http response so sessions can be tracked as usual in HTTP. For instance, that allows one to carry CDI/Seam conversations over several WS requests, very useful for rich clients. I would like for something to be included by default in jboss ws to allow for the same level of usability. Right now, the only alternative is to manually fiddle with the webservice context and add the header yourself. Another level of automation would be a Message Handler of Interceptor to do the job. Any other ideas?" > See also: > http://weblogs.java.net/blog/kohsuke/archive/2006/10/bringing_state.html -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3818) Upgrade to Apache CXF 3.0.2

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3818?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3818: ---------------------------------- Fix Version/s: jbossws-cxf-5.0 (was: jbossws-cxf-5.0.0.Beta1) > Upgrade to Apache CXF 3.0.2 > --------------------------- > > Key: JBWS-3818 > URL: https://issues.jboss.org/browse/JBWS-3818 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3820) JAXWS 2.1 / 2.0 style clients and WebServiceRef using JAXWS features cause NoSuchMethodException

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3820?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3820: ---------------------------------- Summary: JAXWS 2.1 / 2.0 style clients and WebServiceRef using JAXWS features cause NoSuchMethodException (was: JAXWS 2.1 / 2.0 clients and WebServiceRef using JAXWS features cause NoSuchMethodException) > JAXWS 2.1 / 2.0 style clients and WebServiceRef using JAXWS features cause NoSuchMethodException > ------------------------------------------------------------------------------------------------ > > Key: JBWS-3820 > URL: https://issues.jboss.org/browse/JBWS-3820 > 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.3.1, jbossws-cxf-5.0 > > > When specifying a webserviceref whose metadata require MTOM or addressing as a consequence of @MTOM / @Addressing usage, an exception is thrown if the user Service class does not implement JAXWS 2.2 feature-enabled constructor. > An example of a scenario reproducing the issue is a webserviceref as follows: > {code} > @WebServiceRef(name="service/jbws2307service") > @MTOM > HelloService service; > {code} > ... referencing a service class as follows: > {code} > @WebServiceClient(name = "HelloService", targetNamespace = "http://helloservice.org/wsdl", wsdlLocation = "WEB-INF/wsdl/HelloService.wsdl") > public class HelloService extends Service { > public HelloService(URL wsdlLocation, QName serviceName) { > super(wsdlLocation, serviceName); > } > public HelloService() { > super(HELLOSERVICE_WSDL_LOCATION, new QName("http://helloservice.org/wsdl", "HelloService")); > } > @WebEndpoint(name = "HelloPort") > public Hello getHelloPort() { > return ((Hello)super.getPort(new QName("http://helloservice.org/wsdl", "HelloPort"), Hello.class)); > } > // no constructors accepting JAX-WS WebServiceFeature > //... > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3823) Upgrade to Apache CXF 2.7.12

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3823: ------------------------------------- Summary: Upgrade to Apache CXF 2.7.12 Key: JBWS-3823 URL: https://issues.jboss.org/browse/JBWS-3823 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-4.3.1 Upgrade to Apache CXF 2.7.12 http://cxf.apache.org/cxf-2712-release-notes.html -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3798) @WebEndpoint name not considered when building up webservicerefs

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3798?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3798: ---------------------------------- Fix Version/s: jbossws-cxf-4.3.1 > @WebEndpoint name not considered when building up webservicerefs > ---------------------------------------------------------------- > > Key: JBWS-3798 > URL: https://issues.jboss.org/browse/JBWS-3798 > 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.3.1, jbossws-cxf-5.0 > > > When building up webservice refs for a provided Service class, we currently look for 'getXYZ' methods with proper return type and select the first one with proper signature (for instance supporting WebServiceFeature). > A user provided Service class could possibly have multiple getPortName methods returning the same service endpoint interface, but actually using different wsdl ports. That is possible when different @WebEndpoint annotations are specified. In such a scenario, if the user has also specified the required port QName in the webserviceref metadata (port-component-ref block, for instance in jboss-web.xml), we need to select the right method my matching the name of the @WebEndpoint annotation. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3820) JAXWS 2.1 / 2.0 clients and WebServiceRef using JAXWS features cause NoSuchMethodException

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3820?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3820: ---------------------------------- Fix Version/s: jbossws-cxf-4.3.1 > JAXWS 2.1 / 2.0 clients and WebServiceRef using JAXWS features cause NoSuchMethodException > ------------------------------------------------------------------------------------------ > > Key: JBWS-3820 > URL: https://issues.jboss.org/browse/JBWS-3820 > 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.3.1, jbossws-cxf-5.0 > > > When specifying a webserviceref whose metadata require MTOM or addressing as a consequence of @MTOM / @Addressing usage, an exception is thrown if the user Service class does not implement JAXWS 2.2 feature-enabled constructor. > An example of a scenario reproducing the issue is a webserviceref as follows: > {code} > @WebServiceRef(name="service/jbws2307service") > @MTOM > HelloService service; > {code} > ... referencing a service class as follows: > {code} > @WebServiceClient(name = "HelloService", targetNamespace = "http://helloservice.org/wsdl", wsdlLocation = "WEB-INF/wsdl/HelloService.wsdl") > public class HelloService extends Service { > public HelloService(URL wsdlLocation, QName serviceName) { > super(wsdlLocation, serviceName); > } > public HelloService() { > super(HELLOSERVICE_WSDL_LOCATION, new QName("http://helloservice.org/wsdl", "HelloService")); > } > @WebEndpoint(name = "HelloPort") > public Hello getHelloPort() { > return ((Hello)super.getPort(new QName("http://helloservice.org/wsdl", "HelloPort"), Hello.class)); > } > // no constructors accepting JAX-WS WebServiceFeature > //... > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3821) WebServiceRef injection not working properly with TCCL and NEW client Bus selection strategies

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3821?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3821: ---------------------------------- Fix Version/s: jbossws-cxf-4.3.1 > WebServiceRef injection not working properly with TCCL and NEW client Bus selection strategies > ---------------------------------------------------------------------------------------------- > > Key: JBWS-3821 > URL: https://issues.jboss.org/browse/JBWS-3821 > 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.3.1, jbossws-cxf-5.0 > > > The WebServiceRef injection assumes the server is running with the THREAD bus strategy globally configured. If that's not the case, the server can end up using unexpected bus instances for webserviceref injected clients. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 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 August 2014