November 2009 - jbossws-issues - Jboss List Archives

[JBoss JIRA] Created: (JBWS-2696) Better logging for messages that can not be parsed

by Darran Lofthouse (JIRA)

Better logging for messages that can not be parsed -------------------------------------------------- Key: JBWS-2696 URL: https://jira.jboss.org/jira/browse/JBWS-2696 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.1.2 Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: jbossws-native-3.2.0 The MessageFactoryImpl class uses for the following check for the content type of the incoming message: - if (isSoapContent(contentType) == false) { throw new SOAPException("Unsupported content type: " + contentType); } For various servers even though the incoming message is not a SOAP message the message may still contain useful information that could help diagnose the failure. Consider adding an option to still log the payload of the incoming message. -- 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

13 years, 5 months

3
5
0 / 0

[JBoss JIRA] Created: (JBWS-2379) Using a custom HandlerResolver on client while using WS-Security does not add ws-security header to soap envelope

by Yousuf Haider (JIRA)

Using a custom HandlerResolver on client while using WS-Security does not add ws-security header to soap envelope ----------------------------------------------------------------------------------------------------------------- Key: JBWS-2379 URL: https://jira.jboss.org/jira/browse/JBWS-2379 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: ws-security Affects Versions: jbossws-2.0.1.SP2 Environment: JBoss4.3 JDK1.5 Reporter: Yousuf Haider I have a webservice deployed as an EJB endpoint with the correct WS-Security Configuration (using UsernameToken) My standalone java client code looks like this: ReflectorEjbWsseApi port = null; Service service = (Service) Service.create(wsdlURL, serviceQName); service.setHandlerResolver(new CustomHandlerResolver); port = service.getPort(ReflectorEjbWsseApi.class); HandlerResolver hr = new HandlerResolver(); ((BindingProvider)port).getRequestContext().put(BindingProvider.USERNAME_PROPERTY, WebServiceConstants.USERNAME); ((BindingProvider)port).getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, WebServiceConstants.PASSWORD); URL securityURL = new File("jboss-wsse-client.xml").toURL(); ((StubExt)port).setSecurityConfig(securityURL.toExternalForm()); ((StubExt) port).setConfigName("Standard WSSecurity Client"); ((BindingProvider)port).getRequestContext().put(StubExt.PROPERTY_AUTH_TYPE, StubExt.PROPERTY_AUTH_TYPE_WSSE); As you can see I am setting my own custom HandlerResolver. However by doing this I am somehow overriding the default HandlerChain which would have used the USERNAME_PROPERTY and PASSWORD_PROPERTY values and added the ws-security header to the soap message. When executing this code I get a SOAPFault from the server saying that the soap message does not contain a required header. javax.xml.ws.soap.SOAPFaultException: org.jboss.ws.core.CommonSOAPFaultException: This service requires <wsse:Security>, which is missing. If I don't set the handlerResolver by removing this line from my client: service.setHandlerResolver(new CustomHandlerResolver); the request goes through fine and I get a valid response. My own customhandlers do nothing but some logging activity. I should be able to use my own custom handlers with WS-Security. -- 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

13 years, 5 months

3
6
0 / 0

[JBoss JIRA] Created: (JBWS-2695) Setting a new config at runtime the properties are not available to RemotingConnectionImpl

by Darran Lofthouse (JIRA)

Setting a new config at runtime the properties are not available to RemotingConnectionImpl ------------------------------------------------------------------------------------------ Key: JBWS-2695 URL: https://jira.jboss.org/jira/browse/JBWS-2695 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.1.2 Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: jbossws-native-3.2.0 Using the following to replace the configuration for the client: - ((StubExt)port).setConfigName("Custom Client Config","descriptors/jaxws-client-config.xml"); Handlers are updated as required, however the properties that are processed by RemotingConnectionImpl still use the original values. This is because the MessageContext obtains the config from the OperationMetaData as the custom config was not set when the MessageContext was created. -- 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

13 years, 5 months

3
5
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

13 years, 6 months

2
4
0 / 0

[JBoss JIRA] Created: (JBWS-2787) Remove dependency on framework in Native stack

by Richard Opalka (JIRA)

Remove dependency on framework in Native stack ---------------------------------------------- Key: JBWS-2787 URL: https://jira.jboss.org/jira/browse/JBWS-2787 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.2.1 Reporter: Richard Opalka Assignee: Richard Opalka Fix For: jbossws-native-3.3 See NettyHttpServerAdapter (TODO comment) After fixing it remove the dependency in modules/core/pom.xml -- 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

13 years, 7 months

2
6
0 / 0

[JBoss JIRA] Created: (JBWS-2102) javax.xml.ws.addressing package not available in JBossWS-Metro

by Andrew Dinn (JIRA)

javax.xml.ws.addressing package not available in JBossWS-Metro -------------------------------------------------------------- Key: JBWS-2102 URL: http://jira.jboss.com/jira/browse/JBWS-2102 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: jbossws-metro-1.0.1 Reporter: Andrew Dinn The AddressingProperties and related API classes in the javax.xml.ws.addressing package are not available in JBossWS-Metro. These are needed for the Web Services Transactions 1.1 implementation to operate over the Metro stack. -- 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

13 years, 7 months

4
23
0 / 0

[JBoss JIRA] Created: (JBWS-2742) Getting Classcast Exception Inconsistently with the WSAddressing Implemented Services

by vinoth kumar (JIRA)

Getting Classcast Exception Inconsistently with the WSAddressing Implemented Services ------------------------------------------------------------------------------------- Key: JBWS-2742 URL: https://jira.jboss.org/jira/browse/JBWS-2742 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.1.0 Environment: Linux - Ubuntu Reporter: vinoth kumar We are using JBOSS 4.2.3 with JBOSSWS Native 3.1.0 deployed. We had implemented WSAddressing for Our Services as per the Steps given in the link : http://www.jboss.org/community/wiki/JBossWS-NativeUserGuide. This WSAddressing implementation works fine without any issues if we give a single hit to the Services from the client for a given time. But if we have multiple simultaneous hits, we are getting the Classcast Exception inconsistently. We had done the following changes in Client, Code: Service service = Service.create(wsdlURL, serviceName); port1 = (IdentityServiceImpl)service.getPort(IdentityServiceImpl.class); BindingProvider bindingProvider = (BindingProvider)port1; List<Handler> customHandlerChain = new ArrayList<Handler>(); customHandlerChain.add(new ClientHandler()); customHandlerChain.add(new WSAddressingClientHandler()); bindingProvider.getBinding().setHandlerChain(customHandlerChain); The Exception that we are getting is, Code: javax.xml.ws.WebServiceException: java.lang.ClassCastException: com.mobax.signage.ws.RemoveDeviceResponse cannot be cast to com.mobax.signage.ws.GetDeviceResponseRe sponse at org.jboss.ws.core.jaxws.client.ClientImpl.handleRemoteException(ClientImpl.java:404) at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:314) at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:172) at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:152) at $Proxy103.removeDevice(Unknown Source) at com.mobax.mashup.webserviceconsumer.SignageServiceConsumer.removeDevices(SignageServiceConsumer.j ava:264) at com.mobax.mashup.responsebuilder.EnablerResponseParser.removeDevice(EnablerResponseParser.java:14 89) at com.mobax.mashup.servlet.signage.RemoveDevice.processRequest(RemoveDevice.java:60) at com.mobax.mashup.servlet.signage.RemoveDevice.doGet(RemoveDevice.java:88) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446) at java.lang.Thread.run(Thread.java:619) As per Our understanding, We are invoking the method port1.getDeviceResponse() . Before receiving the response for this request, we are invoking another method port1.removeDevice() . The Proxy seems to be waiting for the Response for the second request removeDevice() . When it receives the Response for the first request getDeviceResponse(), the proxy tries to parse this response assuming that this response belongs to the Second request, thus Resulting in Classcast Exception. We would like to know whether anybody have Successfully implemented the WSAddressing in their Services without having any issues. Interestingly, we had find out a WORKAROUND for this issue. The workaround is to generate the following code for every Request. i.e., before calling any Requests, if we generate the following proxy every time newly, then the Exception does not Occurs. Code: port1 = (IdentityServiceImpl)service.getPort(IdentityServiceImpl.class); BindingProvider bindingProvider = (BindingProvider)port1; List<Handler> customHandlerChain = new ArrayList<Handler>(); customHandlerChain.add(new ClientHandler()); customHandlerChain.add(new WSAddressingClientHandler()); bindingProvider.getBinding().setHandlerChain(customHandlerChain); -- 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

13 years, 7 months

3
5
0 / 0

[JBoss JIRA] Created: (JBWS-2460) wsconsume --verbose does not show full error trace

by Thomas Diesler (JIRA)

wsconsume --verbose does not show full error trace -------------------------------------------------- Key: JBWS-2460 URL: https://jira.jboss.org/jira/browse/JBWS-2460 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: tools-jaxws Affects Versions: jbossws-native-3.0.4 Environment: JBoss-5.0.0.GA Reporter: Thomas Diesler Hi Folks, when I invoke plain wsconsume, I get > wsconsume ws-humantask-api.wsdl parsing WSDL... Failed to parse the WSDL. Failed to invoke WsImport java.lang.IllegalStateException: WsImport invocation failed. Try the verbose switch for more information at org.jboss.ws.tools.jaxws.impl.SunRIConsumerImpl.consume(SunRIConsumerImpl.java:233) at org.jboss.wsf.spi.tools.cmd.WSConsume.importServices(WSConsume.java:222) at org.jboss.wsf.spi.tools.cmd.WSConsume.main(WSConsume.java:80) Error: Could not import. (use --verbose to see full traces) Error: WsImport invocation failed. Try the verbose switch for more information When I use the verbose switch, I get > wsconsume --verbose ws-humantask-api.wsdl parsing WSDL... Failed to parse the WSDL. Failed to invoke WsImport java.lang.IllegalStateException: WsImport invocation failed. Try the verbose switch for more information at org.jboss.ws.tools.jaxws.impl.SunRIConsumerImpl.consume(SunRIConsumerImpl.java:233) at org.jboss.wsf.spi.tools.cmd.WSConsume.importServices(WSConsume.java:222) at org.jboss.wsf.spi.tools.cmd.WSConsume.main(WSConsume.java:80) Error: Could not import. (use --verbose to see full traces) java.lang.IllegalStateException: WsImport invocation failed. Try the verbose switch for more information at org.jboss.ws.tools.jaxws.impl.SunRIConsumerImpl.consume(SunRIConsumerImpl.java:233) at org.jboss.wsf.spi.tools.cmd.WSConsume.importServices(WSConsume.java:222) at org.jboss.wsf.spi.tools.cmd.WSConsume.main(WSConsume.java:80) The (invalid) wsdl itself you can get from here http://www.oasis-open.org/committees/download.php/27599/ws-humantask-1.1-... -- 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

13 years, 7 months

3
5
0 / 0

[JBoss JIRA] Created: (JBWS-2394) Upgrate WSIT dependency to 1.4

by Alessio Soldano (JIRA)

Upgrate WSIT dependency to 1.4 ------------------------------ Key: JBWS-2394 URL: https://jira.jboss.org/jira/browse/JBWS-2394 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-metro Reporter: Alessio Soldano -- 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

13 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBWS-2348) Fix jbws1969 testcase

by Alessio Soldano (JIRA)

Fix jbws1969 testcase --------------------- Key: JBWS-2348 URL: https://jira.jboss.org/jira/browse/JBWS-2348 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-metro Reporter: Alessio Soldano The jbws1969 testcase currently fails with metro because of missing wrappers. They are not meant to be provided by users in a real world scenario, as the wsdl is provided. This means this test has either to move to the native tests or we should add the wrappers to the test. -- 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

13 years, 7 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues November 2009