October 2010 - jbossws-issues - Jboss List Archives

[JBoss JIRA] Created: (JBWS-3147) Spring SaajSoapMessageFactory missing child nodes.

by Jason Shepherd (JIRA)

Spring SaajSoapMessageFactory missing child nodes. -------------------------------------------------- Key: JBWS-3147 URL: https://jira.jboss.org/browse/JBWS-3147 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jbossws-2.0.1.SP2 Environment: Jboss EAP 5.0.1 Spring WS 1.5.9 JDK 1.6.0_18 Reporter: Jason Shepherd Fix For: jbossws-2.0.1.SP2 Use of the default messageFactory (org.springframework.ws.soap.saaj.SaajSoapMessageFactory) for spring web services, and an AbstractDomPayloadEndpoint. Child nodes are not appended to a response. Switching to a org.springframework.ws.soap.axiom.AxiomSoapMessageFactory means child nodes are appended correclty. Various reports are that this does not occur on other Application Servers, only JBoss. While I have reproduced it using EAP 5.0.1, I have not tested this on other application servers. http://www.techinfopad.com/spring/101202435-webservice-response-contains-... http://forum.springsource.org/showthread.php?t=30725 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBWS-2215) Produce distributable docs from wiki

by Thomas Diesler (JIRA)

Produce distributable docs from wiki ------------------------------------ Key: JBWS-2215 URL: http://jira.jboss.com/jira/browse/JBWS-2215 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-integration Reporter: Thomas Diesler Assigned To: Heiko Braun Please automate the docs export and make it part of the SVN tag. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (JBWS-3148) When multiple one-waye web services are deployed via a single war/root context the server calls them interchangeably in a random manner

by Charles Piazza (JIRA)

When multiple one-waye web services are deployed via a single war/root context the server calls them interchangeably in a random manner --------------------------------------------------------------------------------------------------------------------------------------- Key: JBWS-3148 URL: https://jira.jboss.org/browse/JBWS-3148 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Affects Versions: jbossws-cxf-3.3.1 Environment: Windows XP SP 3 JBoss 6.0.0.20100429-M3 jbossws-cxf-3.3.1.GA Java 1.6.0_21 Reporter: Charles Piazza If multipe web services annotated with the @Oneway keyword are deployed via the same war file to the same application root context, then the application will randomly call the wrong service, even if the method signatures differ. For example, if the application project is TestOneWayService and it contains two one-way web services, TestService1 and TestService2, which are deployed to JBoss AS via TestOneWayService.war -- these services will be randomly called incorrectly -- that is, service #2 will be randomly invoked when the client is explicitly calling service #1. This will happen whether or not the method signatures of both services are similar or different. I have included a complete code example of both services side and client side in the referenced forum post. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JBWS-3149) Change CXF default MinimalAlternativeSelector to MaximalAlternative in sever side

by Jim Ma (JIRA)

Change CXF default MinimalAlternativeSelector to MaximalAlternative in sever side ---------------------------------------------------------------------------------- Key: JBWS-3149 URL: https://jira.jboss.org/browse/JBWS-3149 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Affects Versions: jbossws-cxf-3.4.0.CR1 Reporter: Jim Ma Assignee: Jim Ma Fix For: jbossws-cxf-3.4.0 When deploying an endpoint whose wsdl contract includes a policy with just an optional alternative for enabling ws-addressing, it seems the default policy selector that's used on server side is not turning on ws-addressing when getting a message that actually uses ws-addressing. The wsdl is like has a policy attached to the binding as follows: <portType name="Echo"> <operation name="echo" parameterOrder="string1 testName"> <input message="tns:EchoInput" wsam:Action="EchoInputAction" /> <output message="tns:EchoOutput" wsam:Action="EchoOutputAction" /> </operation> </portType> <binding name="EchoBinding" type="tns:Echo"> <wsp:Policy> <wsam:Addressing wsp:Optional="true"> <wsp:Policy/> </wsam:Addressing> </wsp:Policy> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc" /> <operation name="echo"> <soap:operation soapAction="" /> <input> <soap:body use="literal" namespace="http://Echo.org" /> </input> <output> <soap:body use="literal" namespace="http://Echo.org" /> </output> </operation> </binding> <service name="EchoService"> <port name="EchoPort" binding="tns:EchoBinding"> <soap:address location="http://foo:9999/bar"/> </port> </service> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
2
0 / 0

[JBoss JIRA] Commented: (JBWS-491) Vote for SAMLTokenProfile-1.0

by Anil Saldhana (JIRA)

[ https://jira.jboss.org/browse/JBWS-491?page=com.atlassian.jira.plugin.sys... ] Anil Saldhana commented on JBWS-491: ------------------------------------ http://community.jboss.org/thread/157409?tstart=0 has a discussion that was recently held for the SAML token support in JBossWS. > Vote for SAMLTokenProfile-1.0 > ----------------------------- > > Key: JBWS-491 > URL: https://jira.jboss.org/browse/JBWS-491 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: productization > Reporter: Anil Saldhana > Fix For: jbossws-voting > > > There is a SAML Token Profile 1.0 defined by the WS-I organization. > http://www.ws-i.org/Profiles/SAMLTokenProfile-1.0.html > This references a SAML Token Profile from the WS-Security family at: > http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf > This specification defines SAML 1.1 assertion tokens to be used in ws-security messages. > Please vote on this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBWS-3146) Update to CXF 2.3.0 relelase

by Alessio Soldano (JIRA)

Update to CXF 2.3.0 relelase ---------------------------- Key: JBWS-3146 URL: https://jira.jboss.org/browse/JBWS-3146 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-3.4.0 The CXF 2.3.0 release is coming with a few changes in artifacts location, see the migration guide: https://cwiki.apache.org/confluence/display/CXF20DOC/2.3+Migration+Guide -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBWS-3127) Review the JMSEndpointsTestCase after the SoapJMSInInterceptor is fixed

by Jim Ma (JIRA)

Review the JMSEndpointsTestCase after the SoapJMSInInterceptor is fixed ----------------------------------------------------------------------- Key: JBWS-3127 URL: https://jira.jboss.org/browse/JBWS-3127 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Jim Ma Assignee: Jim Ma Fix For: jbossws-cxf-3.4.0 CXF commit 986571 introduces this regression failure : All Failed Tests ------------------- org.jboss.test.ws.jaxws.samples.jmsendpoints.jmstransport.JMSEndpointsTestCase.testMessagingClient (http://jbossws.jboss.org:8180/hudson/job/CXF-CORE-AS-6.0.0-SPRING-SUN-JDK... Review and re-enable it after the issue is fixed in CXF. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

2
6
0 / 0

[JBoss JIRA] Created: (JBWS-3134) Provide test cases to test updated UMDM for ServiceRef and PortComponentRef

by Richard Opalka (JIRA)

Provide test cases to test updated UMDM for ServiceRef and PortComponentRef --------------------------------------------------------------------------- Key: JBWS-3134 URL: https://jira.jboss.org/browse/JBWS-3134 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf, jbossws-native Reporter: Richard Opalka Assignee: Richard Opalka Fix For: jbossws-cxf-3.4.0, jbossws-native-3.4.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JBWS-2886) Error doing multiple calls to web service

by Marco Benuzzi (JIRA)

Error doing multiple calls to web service ----------------------------------------- Key: JBWS-2886 URL: https://jira.jboss.org/jira/browse/JBWS-2886 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.1.2 Environment: Linux Fedora 11 kernel 2.6.30.10-105 JBoss Application Platform 5.0.0.GA Reporter: Marco Benuzzi Priority: Critical I'm testing JBossWS to access a remote web service. Just for test I'm using a java console application; I run it with sun jdk 6.0.17 with classpath jboss-eap-5.0/jboss-as/client/*.jar (linux) I've created stubs client classes with wsconsume. If a make a single call all works fine. MyWebServices service = new MyWebServices(); MYSOAPHandlerResolver handlerResolver = new MYSOAPHandlerResolver(); service.setHandlerResolver(handlerResolver); MyWebServicesPT port = service.getMYWebServicesPort(); port.call1(); // OK If a make more than one call, only the first ones works fine. MyWebServices service = new MyWebServices(); MYSOAPHandlerResolver handlerResolver = new MYSOAPHandlerResolver(); service.setHandlerResolver(handlerResolver); MyWebServicesPT port = service.getMYWebServicesPort(); port.call1(); // OK port.call2(); // after 80 seconds I got an exception (please note that I don't see any network activity with wireshark) javax.xml.ws.WebServiceException: java.io.IOException: Could not transmit message at org.jboss.ws.core.jaxws.client.ClientImpl.handleRemoteException(ClientImpl.java:310) at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:243) at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:162) at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:148) at $Proxy15.commandCryptic(Unknown Source) at it.celeweb.otagw.adapter.amadeus.test.AmadeusClient.main(AmadeusClient.java:77) Caused by: java.io.IOException: Could not transmit message at org.jboss.ws.core.client.HTTPRemotingConnection.invoke(HTTPRemotingConnection.java:253) at org.jboss.ws.core.client.SOAPProtocolConnectionHTTP.invoke(SOAPProtocolConnectionHTTP.java:71) at org.jboss.ws.core.CommonClient.invoke(CommonClient.java:339) at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:231) ... 4 more Caused by: org.jboss.remoting.CannotConnectException: Can not connect http client invoker after 1 attempt(s) at org.jboss.remoting.transport.http.HTTPClientInvoker.makeInvocation(HTTPClientInvoker.java:250) at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:162) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:167) at org.jboss.remoting.Client.invoke(Client.java:1917) at org.jboss.remoting.Client.invoke(Client.java:768) at org.jboss.ws.core.client.HTTPRemotingConnection.invoke(HTTPRemotingConnection.java:232) ... 7 more Caused by: java.net.SocketException: Unexpected end of file from server at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:769) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632) at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:766) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1072) at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:373) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318) at org.jboss.remoting.transport.http.HTTPClientInvoker.getResponseCode(HTTPClientInvoker.java:1269) at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:351) at org.jboss.remoting.transport.http.HTTPClientInvoker.makeInvocation(HTTPClientInvoker.java:232) ... 12 more During the debugging of the problem, I found a strange workaround: putting a sleeb after each call. MyWebServices service = new MyWebServices(); MYSOAPHandlerResolver handlerResolver = new MYSOAPHandlerResolver(); service.setHandlerResolver(handlerResolver); MyWebServicesPT port = service.getMYWebServicesPort(); port.call1(); // OK Thread.Sleep(5000); port.call2(); // OK Thread.Sleep(5000); port.call3(); // OK Thread.Sleep(5000); port.call4(); I've tested the same web services using Axis2 as framework and all is working as expected without the need to use the sleep; so I'm sure the problem is on the JAXWS implemented in JBoss -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

4
8
0 / 0

[JBoss JIRA] Created: (JBWS-3145) Remove use of DummyBeanLocator (workaround for CXF-2927)

by Alessio Soldano (JIRA)

Remove use of DummyBeanLocator (workaround for CXF-2927) -------------------------------------------------------- Key: JBWS-3145 URL: https://jira.jboss.org/browse/JBWS-3145 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Affects Versions: jbossws-cxf-3.4.0.Beta2, jbossws-cxf-3.4.0.Beta1 Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-3.4.0 CXF-2927 has been fixed, so there's likely no need anymore for installing a custom dummy bean locator to avoid NPE as mentioned in the jira issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues October 2010