August 2012 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3500) @SchemaValidation doesn't work in JBoss 7.1.1 Final

by Jim Ma (JIRA)

Jim Ma created JBWS-3500: ---------------------------- Summary: @SchemaValidation doesn't work in JBoss 7.1.1 Final Key: JBWS-3500 URL: https://issues.jboss.org/browse/JBWS-3500 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Jim Ma Assignee: Jim Ma Fix For: jbossws-cxf-4.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

4
8
0 / 0

[JBoss JIRA] Created: (JBWS-2932) Support for HTTP Digest authentication, when acting as a client to an external web service

by Ian (JIRA)

Support for HTTP Digest authentication, when acting as a client to an external web service ------------------------------------------------------------------------------------------ Key: JBWS-2932 URL: https://jira.jboss.org/jira/browse/JBWS-2932 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-metro-3.2.1, jbossws-native-3.2.1, jbossws-cxf-3.2.1 Reporter: Ian Please implement HTTP Digest Authentication when acting as a client to an external web service. I don't mean using WS-Security, just using HTTP authentication in a similar that Basic Authentication is used - using JAX-WS code similar to this: String url = configuration.getString(CONFIG_URL); BindingProvider provider = (BindingProvider)requestInvoker; provider.getRequestContext().put(BindingProvider.USERNAME_PROPERTY, username); provider.getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, password); This code works if run as a standalone java client (probably because Metro supports it). However it doesn't work with JBossWS: * Native implementation simply doesn't work at all * Metro implementation has classloading issues when web service calls are made (to do with WS-Addressing I think, I've seen other posts about it). * CXF has the same issues as Metro Given from my reading that the WS-Security work supports Digest authentication, it doesn't seem a difficult task. I'd suggest one of two ways to fix it: 1. Implement it in JBossWS native, OR 2. Fix the classloading issues in Metro and/or CXF so those stacks can be used (given they already support it). -- 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

12 years, 3 months

3
3
0 / 0

[JBoss JIRA] (JBWS-3532) WSDL published to wrong directory when path contains blank characters

by Hans-Ulrich Schmidt (JIRA)

Hans-Ulrich Schmidt created JBWS-3532: ----------------------------------------- Summary: WSDL published to wrong directory when path contains blank characters Key: JBWS-3532 URL: https://issues.jboss.org/browse/JBWS-3532 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Affects Versions: jbossws-cxf-4.0.2 Environment: Windows - probably all versions, particularly Windows XP 32 Bit, Windows 2008 Server 32 Bit & 64 Bit Java 1.6.0_27 - 1.6.0_33 (at least) Reporter: Hans-Ulrich Schmidt We use JBoss at Fujitsu as platform for our ServerView products. Currently we are shifting from JBoss 5.1 to JBoss 7. While we used the Metro WS stack with JBoss 5.1, we now want to use the CXF stack. After some adaptation works our web services work fine, except when JBoss is installed in a directory whose path name contains blank characters. In this case the following messages appear in the log file: 11:18:25,740 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (MSC service thread 1-3) Creating Service {http://schemas.fujitsu.com/serverview/security/2008/07/sts}STSService from WSDL: WEB-INF/wsdl/2008-07/sts.wsdl 11:18:26,599 INFO [org.apache.cxf.endpoint.ServerImpl] (MSC service thread 1-3) Setting the server's publish address to be http://jbossws.undefined.host:3169/cas/sts/service/v2008_07 11:18:26,662 INFO [org.jboss.wsf.stack.cxf.deployment.WSDLFilePublisher] (MSC service thread 1-3) WSDL published to: file:/C:/Program%20Files/Fujitsu/ServerView%20Suite/jboss/standalone/data/wsdl/STS.ear/sts-endpoint.war/2008-07/sts.wsdl 11:18:26,771 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.deployment.subunit."STS.ear"."sts-endpoint.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."STS.ear"."sts-endpoint.war".INSTALL: Failed to process phase INSTALL of subdeployment "sts-endpoint.war" of deployment "STS.ear" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [rt.jar:1.6.0_27] at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.6.0_27] at java.lang.Thread.run(Unknown Source) [rt.jar:1.6.0_27] Caused by: java.lang.RuntimeException: Cannot publish wsdl to: C:\Program Files\Fujitsu\ServerView Suite\jboss\standalone\data\wsdl\STS.ear\sts-endpoint.war\2008-07\sts.wsdl at org.jboss.wsf.stack.cxf.deployment.WSDLFilePublisher.publishWsdlFiles(WSDLFilePublisher.java:107) at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.publishContractToFilesystem(EndpointImpl.java:222) at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:93) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:239) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:509) at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:117) at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:113) at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:66) at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:74) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] ... 5 more Caused by: java.io.FileNotFoundException: C:\Program Files\Fujitsu\ServerView Suite\jboss\standalone\data\wsdl\STS.ear\sts-endpoint.war\2008-07\..\Unversioned\fault.wsdl (The system cannot find the path specified) at java.io.FileInputStream.open(Native Method) [rt.jar:1.6.0_27] at java.io.FileInputStream.<init>(Unknown Source) [rt.jar:1.6.0_27] at java.io.FileInputStream.<init>(Unknown Source) [rt.jar:1.6.0_27] at sun.net.www.protocol.file.FileURLConnection.connect(Unknown Source) [rt.jar:1.6.0_27] at sun.net.www.protocol.file.FileURLConnection.getInputStream(Unknown Source) [rt.jar:1.6.0_27] at java.net.URL.openStream(Unknown Source) [rt.jar:1.6.0_27] at org.jboss.ws.common.utils.AbstractWSDLFilePublisher.publishWsdlImports(AbstractWSDLFilePublisher.java:172) at org.jboss.wsf.stack.cxf.deployment.WSDLFilePublisher.publishWsdlFiles(WSDLFilePublisher.java:91) ... 14 more 11:18:27,021 INFO [org.jboss.as.server] (management-handler-thread - 7) JBAS015870: Deploy of deployment "STS.ear" was rolled back with failure message {"JBAS014671: Failed services" => {"jboss.deployment.subunit.\"STS.ear\".\"sts-endpoint.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"STS.ear\".\"sts-endpoint.war\".INSTALL: Failed to process phase INSTALL of subdeployment \"sts-endpoint.war\" of deployment \"STS.ear\""}} 11:18:27,224 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment cas-acc-ejb.jar in 213ms 11:18:27,255 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment sts-srv-ejb.jar in 243ms 11:18:27,318 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment sts-audit.jar in 302ms 11:18:29,115 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment sts-endpoint.war in 2097ms 11:18:29,255 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment STS.ear in 2248ms 11:18:29,271 INFO [org.jboss.as.controller] (management-handler-thread - 7) JBAS014774: Service status report JBAS014777: Services which failed to start: service jboss.deployment.subunit."STS.ear"."sts-endpoint.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."STS.ear"."sts-endpoint.war".INSTALL: Failed to process phase INSTALL of subdeployment "sts-endpoint.war" of deployment "STS.ear" There problem here is that the apparently missing WSDL file "fault.wsdl" is created in the directory C:\Program%20Files\Fujitsu\ServerView%20Suite\jboss\standalone\data\wsdl\STS.ear\sts-endpoint.war\Unversioned\fault.wsdl rather than in the correct directory C:\Program Files\Fujitsu\ServerView Suite\jboss\standalone\data\wsdl\STS.ear\sts-endpoint.war\Unversioned\fault.wsdl, where it is later on searched for. I found no other workaround than to correct the problem in line 86 of this source file: [jbossws-cxf-server-4.0.2.GA]/src/main/java/org/jboss/wsf/stack/cxf/deployment/WSDLFilePublisher.java Original: 83 Document doc = getWsdlDocument(bus, def); 84 writeDocument(doc, wsdlFile); 85 86 URL wsdlPublishURL = wsdlFile.toURI().toURL(); 87 log.info("WSDL published to: " + wsdlPublishURL); 88 89 // Process the wsdl imports Workaround: 83 Document doc = getWsdlDocument(bus, def); 84 writeDocument(doc, wsdlFile); 85 86 //URL wsdlPublishURL = wsdlFile.toURI().toURL(); incorrect! Workaround below: 87 URL wsdlPublishURL = new URL(URLDecoder.decode(wsdlFile.toURI().toURL().toExternalForm(), "UTF-8")); 88 log.info("WSDL published to: " + wsdlPublishURL); 89 90 // Process the wsdl imports -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
2
0 / 0

[JBoss JIRA] (JBWS-3540) EndpointPublisher: xsd imports cause deployment error unless placed in WEB-INF dir

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3540: ------------------------------------- Summary: EndpointPublisher: xsd imports cause deployment error unless placed in WEB-INF dir Key: JBWS-3540 URL: https://issues.jboss.org/browse/JBWS-3540 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf, jbossws-integration Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-4.1 We have EndpointPublisher deployment issues with wsdls containing schema imports when the wsdl and schema files are not in WEB-INF/wsdl folder. When using the EndpointPublisher directly, the base path for looking up schemas should be directly derived from the directory included in wsdlLocation if any. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBWS-2569) Soap over TCP/IP Transport for Jboss WS

by Bryan Kearney (JIRA)

Soap over TCP/IP Transport for Jboss WS --------------------------------------- Key: JBWS-2569 URL: https://jira.jboss.org/jira/browse/JBWS-2569 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Environment: Jboss 5.0.X, any WS stack, running on Fedora Reporter: Bryan Kearney I would like to see one of the supported WS stackes support SOAP over a TCP/IP transport instead of http. I have 2 main drivers for this: 1) Performance (http://blogs.sun.com/oleksiys/entry/soap_tcp_makes_web_services). 2) Interoperability with the M$ stack, specifically the WCF classes. -- bk -- 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

12 years, 3 months

3
4
0 / 0

[JBoss JIRA] (JBWS-3539) java.net.BindException: Address already in use when <cxf:bus> is defined in jbossws-cxf.xml

by Jim Ma (JIRA)

Jim Ma created JBWS-3539: ---------------------------- Summary: java.net.BindException: Address already in use when <cxf:bus> is defined in jbossws-cxf.xml Key: JBWS-3539 URL: https://issues.jboss.org/browse/JBWS-3539 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Affects Versions: jbossws-cxf-4.1.0.Beta1 Reporter: Jim Ma Assignee: Jim Ma When the <cxf:bus> is defined in jbossws-cxf.xml, cxf tries to create http connector and fails with address in use error. We need to look at how to replace the DestinationFactory in the bus created by jbossws-cxf with ServletDestinationFactory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
1
0 / 0

[JBoss JIRA] (JBWS-3538) SchemaLocation of imported schemas rewritten in WSDL take address from proxy-host and not wsdl-host.

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3538?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3538: --------------------------------------- Can perhaps the Dynamic address rewrite [1] help here? [1] https://docs.jboss.org/author/display/JBWS/Advanced+User+Guide#AdvancedUs... > SchemaLocation of imported schemas rewritten in WSDL take address from proxy-host and not wsdl-host. > ---------------------------------------------------------------------------------------------------- > > Key: JBWS-3538 > URL: https://issues.jboss.org/browse/JBWS-3538 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.0.2 > Environment: JBoss Enterprise Application Platform 6.0.0.GA > Reporter: Mustafa Musaji > Assignee: Kyle Lape > Labels: web_service > > If you add a proxy to the HTTP/1.1 connector in standalone.xml > {code:xml} > <subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false"> > <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http" proxy-name="someothermachine.somewhere" proxy-port="8080"/> > <virtual-server name="default-host" enable-welcome-root="true"> > <alias name="localhost"/> > <alias name="example.com"/> > </virtual-server> > </subsystem> > {code} > and you also have a rewrite rule in web service subsystem > {code:xml} > <subsystem xmlns="urn:jboss:domain:webservices:1.1"> > <modify-wsdl-address>true</modify-wsdl-address> > <wsdl-host>wsdlHostAddress</wsdl-host> > <endpoint-config name="Standard-Endpoint-Config"/> > <endpoint-config name="Recording-Endpoint-Config"> > <pre-handler-chain name="recording-handlers" protocol-bindings="##SOAP11_HTTP ##SOAP11_HTTP_MTOM ##SOAP12_HTTP ##SOAP12_HTTP_MTOM"> > <handler name="RecordingHandler" class="org.jboss.ws.common.invocation.RecordingServerHandler"/> > </pre-handler-chain> > </endpoint-config> > </subsystem> > {code} > The resulting WSDL published by JBoss will have the schemaLocation as the proxy-name and not the wsdl-host. This results in clients unable to process the WSDL -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3536) Enabling SOAP Logging with CXF does not seem to work in EAP 6

by Viral Gohel (JIRA)

Viral Gohel created JBWS-3536: --------------------------------- Summary: Enabling SOAP Logging with CXF does not seem to work in EAP 6 Key: JBWS-3536 URL: https://issues.jboss.org/browse/JBWS-3536 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Affects Versions: jbossws-cxf-4.0 Reporter: Viral Gohel Priority: Minor EAP 6 still has the cxf-extension-jbossws.xml contained under $JBOSS_HOME/modules/org/jboss/ws/jaxws-client/main/jbossws-cxf-client-4.0.4.GA-redhat-1. The approaches as provided in the link[1][2] does not seem to work. [1] http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/5... [2] https://community.jboss.org/wiki/JBossWS-StackCXFUserGuide#SOAP_Message_L... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
3
0 / 0

[JBoss JIRA] (JBWS-3534) JBossWS CXF ignoring wsdlLocation attribute in @WebService annotation

by emollient mind (JIRA)

emollient mind created JBWS-3534: ------------------------------------ Summary: JBossWS CXF ignoring wsdlLocation attribute in @WebService annotation Key: JBWS-3534 URL: https://issues.jboss.org/browse/JBWS-3534 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Affects Versions: jbossws-cxf-4.0.2 Environment: All, JBoss AS 7.1 Reporter: emollient mind Priority: Critical when wsdlLocation attribute is specified on the @WebService annotation the service fails to deploy. log shows wsdlLocation=null. source of Bug class Name : org.jboss.wsf.stack.cxf.metadata.MetadataBuilder Method name : protected DDEndpoint createDDEndpoint(Class<?> sepClass, ArchiveDeployment dep, Endpoint ep) code : DDEndpoint result = new DDEndpoint(); result.setId(ep.getShortName()); result.setAddress(ep.getAddress()); result.setImplementor(ep.getTargetBeanName()); result.setMtomEnabled(isMtomEnabled(ep.getTargetBeanClass())); result.setEpClass(seiClass != null ? seiClass : sepClass); result.setPortName(new QName(serviceNS, portName)); result.setServiceName(new QName(serviceNS, serviceName)); Map<String, Object> props = new HashMap<String, Object>(); for (String k : ep.getProperties()) { props.put(k, ep.getProperty(k)); } Bug fix : add missing statement : result.setWsdlLocation(...) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
2
0 / 0

[JBoss JIRA] (JBWS-3533) JBossWS Native 3.4.0 GA Addressing Issue

by Kiran Chitturi (JIRA)

Kiran Chitturi created JBWS-3533: ------------------------------------ Summary: JBossWS Native 3.4.0 GA Addressing Issue Key: JBWS-3533 URL: https://issues.jboss.org/browse/JBWS-3533 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.4.0 Environment: JBoss 5.1.0 GA with JBossWS Native 3.4.0 . Reporter: Kiran Chitturi Getting below exception while calling a WebSerivce with Addressing enabled and made optional 2012-08-07 02:19:02,348 ERROR [org.jboss.ws.core.jaxws.SOAPFaultHelperJAXWS] (http-0.0.0.0-8680-1) SOAP request exception java.lang.NullPointerException at org.jboss.ws.extensions.addressing.soap.SOAPAddressingPropertiesImpl.registerNamespaces(SOAPAddressingPropertiesImpl.java:235) at org.jboss.ws.extensions.addressing.soap.SOAPAddressingPropertiesImpl.readHeaders(SOAPAddressingPropertiesImpl.java:128) at org.jboss.ws.extensions.addressing.jaxws.WSAddressingServerHandler.handleInbound(WSAddressingServerHandler.java:116) at org.jboss.wsf.common.handler.GenericHandler.handleMessage(GenericHandler.java:53) at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:328) at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:146) at org.jboss.ws.core.jaxws.handler.HandlerDelegateJAXWS.callRequestHandlerChain(HandlerDelegateJAXWS.java:98) at org.jboss.ws.core.server.ServiceEndpointInvoker.callRequestHandlerChain(ServiceEndpointInvoker.java:129) at org.jboss.ws.core.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:176) at org.jboss.wsf.stack.jbws.RequestHandlerImpl.processRequest(RequestHandlerImpl.java:527) at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:316) at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doPost(RequestHandlerImpl.java:222) at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:147) at org.jboss.wsf.common.servlet.AbstractEndpointServlet.service(AbstractEndpointServlet.java:87) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) 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:235) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190) at org.jboss.web.tomcat.service.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:135) at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:94) at org.jboss.web.tomcat.service.session.LockingValve.invoke(LockingValve.java:62) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) 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:158) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues August 2012