[JBoss JIRA] Created: (JBWS-2461) Request / Response Resource Optimisation
by Darran Lofthouse (JIRA)
Request / Response Resource Optimisation
----------------------------------------
Key: JBWS-2461
URL: https://jira.jboss.org/jira/browse/JBWS-2461
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.0.5
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: jbossws-native-3.0.6
There are a few points where the management of resources can be optimised, in these places we are relying on a few techniques that are leading to potential leaks.
The first area to optimise is the use of ThreadLocals for DocumentBuilders etc - these should be optimised to be better related to the request / response.
A second area relates to SwapableMemoryDataSource - something is needed to clean up files not automatically deleted from killed / crashed JVMs. Secondly relying on finalize to delete the files can lead to a large number of files on disk before GC especially with large heaps. Ideally these will be better associated with the current request to be cleaned up at the end of processing.
Although these are two different problems I have grouped them together as the common problem is tracking resources with the request they really belong to.
--
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, 1 month
[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
14 years, 1 month
[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
14 years, 1 month
[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
14 years, 1 month
[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
14 years, 3 months
[JBoss JIRA] Created: (JBWS-2462) Address rewrite test fails in Metro integration
by Richard Opalka (JIRA)
Address rewrite test fails in Metro integration
-----------------------------------------------
Key: JBWS-2462
URL: https://jira.jboss.org/jira/browse/JBWS-2462
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jbossws-metro-3.0.5
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: jbossws-metro-3.0.6
18:25:47,441 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/home/opalka/svn/jbossws/stack/metro/trunk/modules/testsuite/framework-tests/target/test-libs/jaxws-jbws2150-sec.war state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: Error during deploy: vfszip:/home/opalka/svn/jbossws/stack/metro/trunk/modules/testsuite/framework-tests/target/test-libs/jaxws-jbws2150-sec.war
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:177)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
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:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
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:585)
at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:270)
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:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
at org.jboss.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
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:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
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:585)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
at sun.rmi.transport.Transport$1.run(Transport.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
at java.lang.Thread.run(Thread.java:595)
Caused by: javax.xml.ws.WebServiceException: Failed to build METRO runtime model
at org.jboss.wsf.stack.metro.metadata.RuntimeModelDeploymentAspect.start(RuntimeModelDeploymentAspect.java:133)
at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.deploy(DeploymentAspectManagerImpl.java:129)
at org.jboss.wsf.container.jboss50.deployer.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:75)
at org.jboss.wsf.container.jboss50.deployer.AbstractWebServiceDeployer.internalDeploy(AbstractWebServiceDeployer.java:60)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
... 63 more
Caused by: java.lang.Error: Undefined operation name echo
at com.sun.xml.ws.model.JavaMethodImpl.freeze(JavaMethodImpl.java:327)
at com.sun.xml.ws.model.AbstractSEIModelImpl.freeze(AbstractSEIModelImpl.java:97)
at com.sun.xml.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:268)
at com.sun.xml.ws.server.EndpointFactory.createSEIModel(EndpointFactory.java:322)
at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:188)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:467)
at org.jboss.wsf.stack.metro.DeploymentDescriptorParserExt.parseAdapters(DeploymentDescriptorParserExt.java:295)
at org.jboss.wsf.stack.metro.DeploymentDescriptorParserExt.parse(DeploymentDescriptorParserExt.java:171)
at org.jboss.wsf.stack.metro.metadata.RuntimeModelDeploymentAspect.start(RuntimeModelDeploymentAspect.java:109)
... 68 more
--
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