[JBoss JIRA] Created: (JBWS-3137) Support deploying http and jms endpoint in one deployment
by Jim Ma (JIRA)
Support deploying http and jms endpoint in one deployment
---------------------------------------------------------
Key: JBWS-3137
URL: https://jira.jboss.org/browse/JBWS-3137
Project: JBoss Web Services
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Affects Versions: jbossws-cxf-3.4.0.Beta2
Reporter: Jim Ma
Assignee: Jim Ma
Fix For: jbossws-cxf-3.4.1
When the jms endpoints is deployed with http endpoints in one war file, the WsTypeDeployer takes this deployment as "JAXWS_JSE" type . Hence the JMSDeploymentAspects will not be activated and process this mixed type deployment .
JMSTransportTestCase is the test for this user case. The jms endpoints is not registered in registry so far. We can review our WSTypeDeployer and other JMSDAs to support this mixed type deployment.
--
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
13 years, 6 months
[JBoss JIRA] Created: (JBWS-3248) Unable to lookup AuthenticationManager using JNDI - AS7
by Alessio Soldano (JIRA)
Unable to lookup AuthenticationManager using JNDI - AS7
-------------------------------------------------------
Key: JBWS-3248
URL: https://issues.jboss.org/browse/JBWS-3248
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Environment: JBoss AS 7
Reporter: Alessio Soldano
Fix For: jbossws-cxf-4.0
org.apache.ws.security.WSSecurityException: The security token could not be authenticated or authorized; nested exception is:
org.apache.ws.security.WSSecurityException: Failed Authentication : Subject has not been created; nested exception is:
java.lang.SecurityException: Unable to lookup AuthenticationManager using JNDI
at org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:173) [wss4j-1.5.11.jar:1.5.11]
at org.apache.ws.security.processor.UsernameTokenProcessor.handleToken(UsernameTokenProcessor.java:61) [wss4j-1.5.11.jar:1.5.11]
at org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:328) [wss4j-1.5.11.jar:1.5.11]
at org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:245) [wss4j-1.5.11.jar:1.5.11]
at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:218) [cxf-rt-ws-security.jar:2.3.4-SNAPSHOT]
at org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.handleMessage(AbstractUsernameTokenAuthenticatingInterceptor.java:96) [cxf-rt-ws-security.jar:2.3.4-SNAPSHOT]
at org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.handleMessage(AbstractUsernameTokenAuthenticatingInterceptor.java:67) [cxf-rt-ws-security.jar:2.3.4-SNAPSHOT]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255) [cxf-api.jar:2.3.4-SNAPSHOT]
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113) [cxf-rt-core.jar:2.3.4-SNAPSHOT]
at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:105) [cxf-rt-transports-http.jar:2.3.4-SNAPSHOT]
at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461) [cxf-rt-transports-http.jar:2.3.4-SNAPSHOT]
at org.jboss.wsf.stack.cxf.ServletControllerExt.invoke(ServletControllerExt.java:172) [jbossws-cxf-server.jar:4.0.0-SNAPSHOT]
at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:57) [jbossws-cxf-server.jar:4.0.0-SNAPSHOT]
at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:156) [jbossws-cxf-server.jar:4.0.0-SNAPSHOT]
at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:90) [jbossws-cxf-server.jar:4.0.0-SNAPSHOT]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179) [cxf-rt-transports-http.jar:2.3.4-SNAPSHOT]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103) [cxf-rt-transports-http.jar:2.3.4-SNAPSHOT]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159) [cxf-rt-transports-http.jar:2.3.4-SNAPSHOT]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [jbossweb-7.0.0.Beta4.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta4.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.0.Beta4.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.0.Beta4.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.Beta4.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.Beta4.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.Beta4.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.Beta4.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.0.Beta4.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654) [jbossweb-7.0.0.Beta4.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [jbossweb-7.0.0.Beta4.jar:7.0.0.Alpha2-SNAPSHOT]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
Caused by: org.apache.ws.security.WSSecurityException: Failed Authentication : Subject has not been created; nested exception is:
java.lang.SecurityException: Unable to lookup AuthenticationManager using JNDI
at org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.setSubject(AbstractUsernameTokenAuthenticatingInterceptor.java:147) [cxf-rt-ws-security.jar:2.3.4-SNAPSHOT]
at org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor$SubjectCreatingCallbackHandler.handleCallback(AbstractUsernameTokenAuthenticatingInterceptor.java:228) [cxf-rt-ws-security.jar:2.3.4-SNAPSHOT]
at org.apache.cxf.ws.security.wss4j.DelegatingCallbackHandler.handle(DelegatingCallbackHandler.java:38) [cxf-rt-ws-security.jar:2.3.4-SNAPSHOT]
at org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:168) [wss4j-1.5.11.jar:1.5.11]
... 30 more
Caused by: java.lang.SecurityException: Unable to lookup AuthenticationManager using JNDI
at org.jboss.wsf.stack.cxf.security.authentication.AuthenticationManagerLoader.getManager(AuthenticationManagerLoader.java:48) [jbossws-cxf-server.jar:4.0.0-SNAPSHOT]
at org.jboss.wsf.stack.cxf.security.authentication.SubjectCreatingInterceptor.createSubject(SubjectCreatingInterceptor.java:110) [jbossws-cxf-server.jar:4.0.0-SNAPSHOT]
at org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.setSubject(AbstractUsernameTokenAuthenticatingInterceptor.java:143) [cxf-rt-ws-security.jar:2.3.4-SNAPSHOT]
... 33 more
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBWS-3279) Unify CXFServletExt and CXFNonSpringServletExt
by Alessio Soldano (JIRA)
Unify CXFServletExt and CXFNonSpringServletExt
----------------------------------------------
Key: JBWS-3279
URL: https://issues.jboss.org/browse/JBWS-3279
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Reporter: Alessio Soldano
Priority: Minor
Fix For: jbossws-cxf-4.0
Once the Apache CXF 2.4 integration is done, there's no need anymore for 2 different extensions of the CXF endpoint transport servlet.
So we can unify the spring and non-spring version and remove the previously required abstraction in AS integration for selecting the servlet to use when (re)writing the endpoint web.xml.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBWS-3305) jbossws-cxf wrongly assumes that code using WSA must be employing a request-reply exchange.
by Jim Ma (JIRA)
jbossws-cxf wrongly assumes that code using WSA must be employing a request-reply exchange.
-------------------------------------------------------------------------------------------
Key: JBWS-3305
URL: https://issues.jboss.org/browse/JBWS-3305
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Affects Versions: jbossws-cxf-4.0.0.Beta1
Reporter: Jim Ma
00:44:38,254 INFO [org.jboss.ws.common.management.DefaultEndpointRegistry] (MSC service thread 1-4) remove: jboss.ws:context=ws-t11-client,endpoint=CompletionInitiator
00:44:38,256 INFO [org.jboss.ws.common.management.DefaultEndpointRegistry] (MSC service thread 1-4) remove: jboss.ws:context=ws-t11-client,endpoint=TerminationParticipant
00:44:38,258 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.deployment.unit."ws-t11-client.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."ws-t11-client.war".INSTALL: Failed to process phase INSTALL of deployment "ws-t11-client.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121) [jboss-as-server-7.0.0.Beta4-SNAPSHOT.jar:7.0.0.Beta4-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675) [jboss-msc-1.0.0.Beta8.jar:1.0.0.Beta8]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_21]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
Caused by: javax.xml.ws.WebServiceException: java.lang.NullPointerException
at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:350)
at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:71)
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:113)
at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:109)
at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:132)
at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.internalDeploy(AspectDeploymentProcessor.java:78)
at org.jboss.as.webservices.deployers.TCCLDeploymentProcessor.deploy(TCCLDeploymentProcessor.java:42)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) [jboss-as-server-7.0.0.Beta4-SNAPSHOT.jar:7.0.0.Beta4-SNAPSHOT]
... 4 more
Caused by: java.lang.NullPointerException
at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildWSAActions(JaxWsServiceFactoryBean.java:547)
at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.createOperation(JaxWsServiceFactoryBean.java:620)
at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.createInterface(ReflectionServiceFactoryBean.java:903)
at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:429)
at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:680)
at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:501)
at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:241)
at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:202)
at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:101)
at org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:157)
at org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:192)
at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:433)
at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:322)
... 13 more
The null pointer exception which causes the problem is in the following code taken from JaxWsServiceFactoryBean.buildWSAActions
. . .
if (action == null && addressing != null) {
operation.getInput().addExtensionAttribute(JAXWSAConstants.WSAM_ACTION_QNAME,
inputAction);
operation.getInput().addExtensionAttribute(JAXWSAConstants.WSAW_ACTION_QNAME,
inputAction);
operation.getOutput().addExtensionAttribute(JAXWSAConstants.WSAM_ACTION_QNAME,
computeAction(operation, "Response"));
operation.getOutput().addExtensionAttribute(JAXWSAConstants.WSAW_ACTION_QNAME,
computeAction(operation, "Response"));
} else {
MessageInfo input = operation.getInput();
input.addExtensionAttribute(JAXWSAConstants.WSAM_ACTION_QNAME, inputAction);
if (!StringUtils.isEmpty(action.input())) {
input.addExtensionAttribute(JAXWSAConstants.WSAW_ACTION_QNAME, inputAction);
}
MessageInfo output = operation.getOutput();
if (output != null && !StringUtils.isEmpty(action.output())) {
output.addExtensionAttribute(JAXWSAConstants.WSAW_ACTION_QNAME, action.output());
. . .
The offending line is the one in bold. Notice that in the else clause the result of the getOutput() call is checked ut in the case where addressing is being used it is not checked. Clearly the code is based on the wrong assumption that code using WSA must be employing a request-reply exchange.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBWS-3292) IllegalArgumentException: wrong number of arguments with jbossws-cxf Dispatch/Provider service
by Jim Ma (JIRA)
IllegalArgumentException: wrong number of arguments with jbossws-cxf Dispatch/Provider service
----------------------------------------------------------------------------------------------
Key: JBWS-3292
URL: https://issues.jboss.org/browse/JBWS-3292
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.0.0.Beta1
org.apache.cxf.interceptor.Fault: wrong number of arguments while invoking public abstract java.lang.Object javax.xml.ws.Provider.invoke(java.lang.Object) with params [com.sun.xml.internal.messaging.saaj.soap.ver1_1.Message1_1Impl@543cb1, javax.xml.transform.dom.DOMSource@5cc942].
at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:159)
at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:86)
at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:133)
at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:60)
at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:75)
at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
at org.apache.cxf.transport.local.LocalConduit$1$1.run(LocalConduit.java:132)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.IllegalArgumentException: wrong number of arguments
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:173)
at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:89)
... 12 more
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBWS-3227) handlers configuration file not found on classpath
by Richard Opalka (JIRA)
handlers configuration file not found on classpath
--------------------------------------------------
Key: JBWS-3227
URL: https://issues.jboss.org/browse/JBWS-3227
Project: JBoss Web Services
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Reporter: Richard Opalka
Fix For: jbossws-native-4.0, jbossws-cxf-4.0
12:03:31,683 ERROR [org.jboss.msc] (pool-2-thread-5) MSC-00001: Failed to start service jboss.deployment.unit.jaxws-jbws3034.war.INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit.jaxws-jbws3034.war.INSTALL: Failed to process phase INSTALL of deployment "jaxws-jbws3034.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:112)
at org.jboss.msc.service.ServiceInstanceImpl$StartTask.run(ServiceInstanceImpl.java:1163)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_20]
at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
Caused by: javax.xml.ws.WebServiceException: javax.xml.ws.WebServiceException: Could not find the handler configuration file ../../../../../../handlers.xml specified by @HandlerChain annotation
at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:343) [cxf-rt-frontend-jaxws.jar:2.3.2]
at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:62) [jbossws-cxf-server.jar:4.0.0-SNAPSHOT]
at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:239) [cxf-rt-frontend-jaxws.jar:2.3.2]
at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:489) [cxf-rt-frontend-jaxws.jar:2.3.2]
at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:112) [jbossws-cxf-server.jar:4.0.0-SNAPSHOT]
at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:102) [jbossws-cxf-server.jar:4.0.0-SNAPSHOT]
at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:119) [jbossws-cxf-server.jar:4.0.0-SNAPSHOT]
at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.internalDeploy(AspectDeploymentProcessor.java:77) [jboss-as-webservices-server-integration-7.0.0.Alpha2-SNAPSHOT.jar:4.0.0-SNAPSHOT]
at org.jboss.as.webservices.deployers.TCCLDeploymentProcessor.deploy(TCCLDeploymentProcessor.java:41) [jboss-as-webservices-server-integration-7.0.0.Alpha2-SNAPSHOT.jar:4.0.0-SNAPSHOT]
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:108)
... 4 more
Caused by: javax.xml.ws.WebServiceException: Could not find the handler configuration file ../../../../../../handlers.xml specified by @HandlerChain annotation
at org.apache.cxf.jaxws.handler.AnnotationHandlerChainBuilder.buildHandlerChainFromClass(AnnotationHandlerChainBuilder.java:88) [cxf-rt-frontend-jaxws.jar:2.3.2]
at org.apache.cxf.jaxws.handler.AnnotationHandlerChainBuilder.buildHandlerChainFromClass(AnnotationHandlerChainBuilder.java:284) [cxf-rt-frontend-jaxws.jar:2.3.2]
at org.apache.cxf.jaxws.JaxWsServerFactoryBean.buildHandlerChain(JaxWsServerFactoryBean.java:215) [cxf-rt-frontend-jaxws.jar:2.3.2]
at org.apache.cxf.jaxws.JaxWsServerFactoryBean.init(JaxWsServerFactoryBean.java:194) [cxf-rt-frontend-jaxws.jar:2.3.2]
at org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:184) [cxf-rt-frontend-jaxws.jar:2.3.2]
at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:415) [cxf-rt-frontend-jaxws.jar:2.3.2]
at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:315) [cxf-rt-frontend-jaxws.jar:2.3.2]
... 13 more
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
CVE-2011-0534 impact
by santhosh kolathur
Hello
Is JBoss WS 2.1.9 impacted due to this tomcat vulnerability? If so, is there a test code I can use to verify it?
Kol San
13 years, 7 months
[JBoss JIRA] Created: (JBWS-2317) $JAXBAccessorF_ and $JAXBAccessorM_ cache loosing classes and failing to re-create classes.
by Darran Lofthouse (JIRA)
$JAXBAccessorF_ and $JAXBAccessorM_ cache loosing classes and failing to re-create classes.
-------------------------------------------------------------------------------------------
Key: JBWS-2317
URL: https://jira.jboss.org/jira/browse/JBWS-2317
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-metro, jbossws-native
Affects Versions: jbossws-metro-3.0.3, jbossws-native-3.0.3
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: jbossws-native-3.0.4, jbossws-metro-3.0.4
The JAXB implementation contains a package of classes to optimise field and method access by dynamically generating classes to avoid reflection, this has a start-up performance hit but then leads to an optimised runtime.
The package is: -
'com.sun.xml.bind.v2.runtime.reflect.opt'
Within the Injector class is a HashMap to maintain a cache of these classes against the classloader they were created for: -
private static final Map<ClassLoader,WeakReference<Injector>> injectors =
Collections.synchronizedMap(new WeakHashMap<ClassLoader,WeakReference<Injector>>());
A WeakReference has been used to wrap the value to prevent the value retaining a reference to the ClassLoader and then preventing garbage collection and leading to a leak.
The problem is that nothing retains a reference to the Injector so as this is wrapped with a WeakReference it is garbage collected.
I will attach to this case a new version of Injector.java.
The fix switches to using a Strong reference to the Injector so it is not garbage collected.
To maintain the original requirements the Injector will no longer hold a reference to the ClassLoader and will instead make use of the one passed in.
Within the Injector the HashMap of classes will reference the Class with a WeakReference. If we get a WeakReference with no class it means the class was previously loaded but garbage collected, in this case try to load the class by name from the classloader - if this fails then redefine the class.
--
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
