[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
[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
[JBoss JIRA] Created: (JBWS-2857) Validation for Document/Literal Bare Endpoints
by Darran Lofthouse (JIRA)
Validation for Document/Literal Bare Endpoints
----------------------------------------------
Key: JBWS-2857
URL: https://jira.jboss.org/jira/browse/JBWS-2857
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.2.1
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: jbossws-native-3.3
Section 3.6.2.2 of the JAX-WS specification describes the requirements for Document/Literal Bare deployments.
JBossWS Native does not verify the requirement has been met and generates a WSDL inconsistent with the endpoint itself causing subsequent failures when the endpoint is called.
The methods should be verified at deploy time.
--
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
[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
[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
[JBoss JIRA] Created: (JBWS-2886) Error doing multiple calls to web service
by Marco Benuzzi (JIRA)
Error doing multiple calls to web service
-----------------------------------------
Key: JBWS-2886
URL: https://jira.jboss.org/jira/browse/JBWS-2886
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.1.2
Environment: Linux Fedora 11 kernel 2.6.30.10-105
JBoss Application Platform 5.0.0.GA
Reporter: Marco Benuzzi
Priority: Critical
I'm testing JBossWS to access a remote web service.
Just for test I'm using a java console application; I run it with sun jdk 6.0.17 with classpath jboss-eap-5.0/jboss-as/client/*.jar (linux)
I've created stubs client classes with wsconsume.
If a make a single call all works fine.
MyWebServices service = new MyWebServices();
MYSOAPHandlerResolver handlerResolver = new MYSOAPHandlerResolver();
service.setHandlerResolver(handlerResolver);
MyWebServicesPT port = service.getMYWebServicesPort();
port.call1();
// OK
If a make more than one call, only the first ones works fine.
MyWebServices service = new MyWebServices();
MYSOAPHandlerResolver handlerResolver = new MYSOAPHandlerResolver();
service.setHandlerResolver(handlerResolver);
MyWebServicesPT port = service.getMYWebServicesPort();
port.call1();
// OK
port.call2();
// after 80 seconds I got an exception (please note that I don't see any network activity with wireshark)
javax.xml.ws.WebServiceException: java.io.IOException: Could not transmit message
at org.jboss.ws.core.jaxws.client.ClientImpl.handleRemoteException(ClientImpl.java:310)
at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:243)
at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:162)
at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:148)
at $Proxy15.commandCryptic(Unknown Source)
at it.celeweb.otagw.adapter.amadeus.test.AmadeusClient.main(AmadeusClient.java:77)
Caused by: java.io.IOException: Could not transmit message
at org.jboss.ws.core.client.HTTPRemotingConnection.invoke(HTTPRemotingConnection.java:253)
at org.jboss.ws.core.client.SOAPProtocolConnectionHTTP.invoke(SOAPProtocolConnectionHTTP.java:71)
at org.jboss.ws.core.CommonClient.invoke(CommonClient.java:339)
at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:231)
... 4 more
Caused by: org.jboss.remoting.CannotConnectException: Can not connect http client invoker after 1 attempt(s)
at org.jboss.remoting.transport.http.HTTPClientInvoker.makeInvocation(HTTPClientInvoker.java:250)
at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:162)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:167)
at org.jboss.remoting.Client.invoke(Client.java:1917)
at org.jboss.remoting.Client.invoke(Client.java:768)
at org.jboss.ws.core.client.HTTPRemotingConnection.invoke(HTTPRemotingConnection.java:232)
... 7 more
Caused by: java.net.SocketException: Unexpected end of file from server
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:769)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:766)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1072)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:373)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
at org.jboss.remoting.transport.http.HTTPClientInvoker.getResponseCode(HTTPClientInvoker.java:1269)
at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:351)
at org.jboss.remoting.transport.http.HTTPClientInvoker.makeInvocation(HTTPClientInvoker.java:232)
... 12 more
During the debugging of the problem, I found a strange workaround: putting a sleeb after each call.
MyWebServices service = new MyWebServices();
MYSOAPHandlerResolver handlerResolver = new MYSOAPHandlerResolver();
service.setHandlerResolver(handlerResolver);
MyWebServicesPT port = service.getMYWebServicesPort();
port.call1();
// OK
Thread.Sleep(5000);
port.call2();
// OK
Thread.Sleep(5000);
port.call3();
// OK
Thread.Sleep(5000);
port.call4();
I've tested the same web services using Axis2 as framework and all is working as expected without the need to use the sleep; so I'm sure the problem is on the JAXWS implemented in JBoss
--
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