March 2008 - jbossws-issues - Jboss List Archives

[JBoss JIRA] Created: (JBWS-1878) ConcurrentModificationException in JAXWS Handler when requests hit JBoss during application deployment

by Wojciech Kudla (JIRA)

ConcurrentModificationException in JAXWS Handler when requests hit JBoss during application deployment ------------------------------------------------------------------------------------------------------ Key: JBWS-1878 URL: http://jira.jboss.com/jira/browse/JBWS-1878 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-jaxws Affects Versions: jbossws-2.0.1 Environment: AIX 5.3 ppc64, IBM JVM 9 (1.5.0), JBoss 4.2.1.GA with JBossWS 2.0.1.GA Reporter: Wojciech Kudla Priority: Critical When SOAP requests hit JBoss during application deployment they are somewhat queued and get processed just after the application starts. Everything works fine if the are only several requests. If there are more (like 30 or above) before the application starts, HandlerResolverImpl causes ConcurrentModificationException at line 22 (getHandlerChain()). This exception does not cause the application to stop working, but results in a very strange behaviour, namely: every request goes only through JAXWS Handler twice (on inbound and outbound traffic) but does not hit service implementation (in my case - EJB3 SLSB). The only clue for me to resolve this problem was to stick to the ConcurrentModificationException and its stacktrace. Going down this path I decided to modify some code in class org.jboss.ws.core.jaxws.handler.HandlerDelegateJAXWS. I synchronized a block of code responsible for initiating handler chains, so the modified method looks like this: public boolean callRequestHandlerChain(ServerEndpointMetaData sepMetaData, HandlerType type) { log.debug("callRequestHandlerChain: " + type); // Initialize the handler chain if (isInitialized() == false) { synchronized(resolver) { resolver.initHandlerChain(sepMetaData, HandlerType.PRE, true); resolver.initHandlerChain(sepMetaData, HandlerType.ENDPOINT, true); resolver.initHandlerChain(sepMetaData, HandlerType.POST, true); setInitialized(true); } } HandlerChainExecutor executor = createExecutor(sepMetaData, type); MessageContext msgContext = (MessageContext)MessageContextAssociation.peekMessageContext(); return executor.handleMessage(msgContext); } I tried to do synchronized(this) at the beginning but it very quickly resulted in unstable AS behaviour and stopping JVM with a core dump in the end (SIC!). Since we are talking about serious production deployment in 5 days (servicing ca. 5000 SOAP requests per hour) , I decided to incorporate my fix into the environment, but I am not completely sure wheter my fix imposes any performance pitfalls. If you find a better idea to solve this problem, please be quick to publish a solution :) -- 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

15 years, 6 months

3
5
0 / 0

[JBoss JIRA] Created: (JBWS-2074) Resource injection in WS Handler doesn't work

by Richard Opalka (JIRA)

Resource injection in WS Handler doesn't work --------------------------------------------- Key: JBWS-2074 URL: http://jira.jboss.com/jira/browse/JBWS-2074 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-2.0.3 Reporter: Richard Opalka Fix For: jbossws-native-2.0.5 -- 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

15 years, 7 months

3
24
0 / 0

[JBoss JIRA] Created: (JBWS-2015) Modify addressing handlers to work with the JAXWS-2.1 API

by Thomas Diesler (JIRA)

Modify addressing handlers to work with the JAXWS-2.1 API --------------------------------------------------------- Key: JBWS-2015 URL: http://jira.jboss.com/jira/browse/JBWS-2015 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Reporter: Thomas Diesler Fix For: jbossws-native-2.0.5 Currently we have two implementations of EndpointReference. This needs to be cleaned up to a single supported version. -- 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

15 years, 8 months

3
7
0 / 0

[JBoss JIRA] Created: (JBWS-1932) Unable to narrow port selection for UnifiedPortComponentRef

by Chris Laprun (JIRA)

Unable to narrow port selection for UnifiedPortComponentRef ----------------------------------------------------------- Key: JBWS-1932 URL: http://jira.jboss.com/jira/browse/JBWS-1932 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-jaxrpc Affects Versions: jbossws-2.0.2 Reporter: Chris Laprun Assigned To: Thomas Diesler Each time my client application tries to retrieve a service endpoint to invoke web service operations, I get the following warning on the console: WARN [org.jboss.ws.core.client.ServiceObjectFactory] Unable to narrow port selection for UnifiedPortComponentRef serviceEndpointInterface=org.jboss.portal.wsrp.core.WSRP_v1_Registration_PortType portQName=null enableMTOM=false portComponentLink=null callProperties=[] stubProperties=[] configName=null configFile=null This doesn't seem to have any ill consequences that I can notice in my testing but I'd like to solve the problem if possible. -- 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

15 years, 8 months

3
9
0 / 0

[JBoss JIRA] Created: (JBWS-1941) Fault handler chain is not called when user application exceptions are thrown

by Alessio Soldano (JIRA)

Fault handler chain is not called when user application exceptions are thrown ----------------------------------------------------------------------------- Key: JBWS-1941 URL: http://jira.jboss.com/jira/browse/JBWS-1941 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jbossws-2.0.2 Reporter: Alessio Soldano Assigned To: Alessio Soldano The fault handler chain not called when user application exception are thrown (while runtime and common soap exception cause the right handler chain to be processed). This can can be reproduced adding an handler to the exception sample test case. -- 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

15 years, 9 months

3
7
0 / 0

[JBoss JIRA] Created: (JBWS-1665) incorrect wsdl generation

by David Boeren (JIRA)

incorrect wsdl generation ------------------------- Key: JBWS-1665 URL: http://jira.jboss.com/jira/browse/JBWS-1665 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: wstools Affects Versions: jbossws-1.2.1 Reporter: David Boeren Attachments: fleet-asp-intf.jar, fleet-service-ejb.jar An EJB3 based webservice is deployed, but the wsdl produced has several blank fields including soapaction, soapfaults, and a wholly-unpopulated <message> element. -- 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

15 years, 9 months

4
16
0 / 0

[JBoss JIRA] Created: (JBWS-2064) JSON content-type handling

by Thomas Diesler (JIRA)

JSON content-type handling -------------------------- Key: JBWS-2064 URL: http://jira.jboss.com/jira/browse/JBWS-2064 Project: JBoss Web Services Issue Type: Sub-task Security Level: Public (Everyone can see) Components: jbossws-native Reporter: Thomas Diesler Fix For: jbossws-native-2.0.5 -- 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

15 years, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (JBWS-1774) Provide a tools implementation for CXF (WSContractProvider and WSContractConsumer)

by Heiko Braun (JIRA)

Provide a tools implementation for CXF (WSContractProvider and WSContractConsumer) ---------------------------------------------------------------------------------- Key: JBWS-1774 URL: http://jira.jboss.com/jira/browse/JBWS-1774 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: integration-cxf Reporter: Heiko Braun -- 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

15 years, 10 months

4
21
0 / 0

[JBoss JIRA] Created: (JBWS-1967) Get rid of web.xml rewrite

by Heiko Braun (JIRA)

Get rid of web.xml rewrite -------------------------- Key: JBWS-1967 URL: http://jira.jboss.com/jira/browse/JBWS-1967 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Reporter: Heiko Braun Fix For: jbossws-native-2.0.4 Scott wrote: The tomcat layer is being driven by the WebMetaData/JBossWebMetaData now, so any modification by the ws deployers should be done as input into a deployer like MergedJBossMetaDataDeployer does for the ejb metadata. I'd like to get this cleaned up for jbossas 5.0.0.CR1 when the war deployer is cleaned up. -- 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

15 years, 10 months

4
15
0 / 0

[JBoss JIRA] Created: (JBWS-1999) WS-Security Usename Token Profile JAAS Implementation for JSE based WebServices

by Thomas Diesler (JIRA)

WS-Security Usename Token Profile JAAS Implementation for JSE based WebServices ------------------------------------------------------------------------------- Key: JBWS-1999 URL: http://jira.jboss.com/jira/browse/JBWS-1999 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-native Reporter: Thomas Diesler Fix For: jbossws-native-2.0.4 Karl de Boer sais: I created a Username TokenProfile implementation where the userid pwd are verified against the active JAAS SecurityManager I want to share this with you. It appears to me there is only support for EJB based webservices for this. So i had to create it myself in the form of a messagehandler and some glue to integrate with JBossSX. In general i think the focus is to much on EJB Based services. I prefer the WSDL first approach to define a proper SOA. It is not a perfect implementation. I do'nt do anything with Nonce and Timestamp and i also do not support passwordDigest. So i also do not use any keystores (PasswordText is protect by the transport layer in my case (SSL)). I saw there is an issue in JIRA where the keystore shoud not be required. This is such a case. I also was surprised that JBossWS does not check anymore for the requires Username section in Jboss-wsse-server.xml. But for this there is also as JIRA issue What i did in a separate messagehandler should perhaps be moved to the WSSecurityDispatcher, which takes care of all WSSecurity related stuff. To activate the messagehandler processing i simply adjusted the default the standard-jaxws-endpoint-config.xml <endpoint-config> <config-name>Standard WSSecurity Endpoint</config-name> <post-handler-chains> <javaee:handler-chain> <javaee:protocol-bindings>##SOAP11_HTTP</javaee:protocol-bindings> <javaee:handler> <javaee:handler-name>WSSecurity Handler</javaee:handler-name> <javaee:handler-class>org.jboss.ws.extensions.security.jaxws.WSSecurityHandlerServer</javaee:handler-class> </javaee:handler> <javaee:handler> <javaee:handler-name>UserNameTokenProfileMessageHandler</javaee:handler-name> <javaee:handler-class>nl.jnc.common.services.wssecurity.UserNameTokenProfileMessageHandler</javaee:handler-class> </javaee:handler> </javaee:handler-chain> </post-handler-chains> </endpoint-config> I did not investigate how to link the authenticated user (principal) and associated roles to the WebServiceContext. I directly refer to the SecurityAssociation class which stores Subject and Principal in threadlocal. In the SEI implementaion is use the princiap and roles like this (cloul be improved): private boolean isUserInRole(String roleName) { Subject sub = SecurityAssociation.getSubject(); if (sub != null) { Set<Principal> set = SecurityAssociation.getSubject().getPrincipals(); if (set!= null) { for (Principal p : set) { if (p instanceof SimpleGroup) { SimpleGroup ng = (SimpleGroup) p; Enumeration mem = ng.members(); while (mem.hasMoreElements()) { Principal p1 = (Principal) mem.nextElement(); if (p1.getName().equalsIgnoreCase(roleName)) return true; } } } } } return false; } Attached you will find the rest. You are free to use it the way you like. In the WsSecurityManager you will also find some a method to authenticate a user with a certificate but this is not tested. I use the security implementation against an LDAP (LdapLoginModule). The users are system accounts, the data(sections) returned by the service are governed by the roles a system users has. -- 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

15 years, 10 months

3
10
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues March 2008