Axis 2 and Transfer-Encoding Chunked

We upgraded one of our clients from Axis 1.2 to Axis 2 and it was observed that calls to the downstream system started failing. Checked with the backend guys and they confirmed that our IP address showed up in their access logs, so the handshake had succeeded. But the request xml was not received at their end.

The first step was to plug in tcpmon and trace the data sent over the wire. (TCPMon is a utility that allows the user to monitor the messages passed along in TCP based conversation). If Eclipse is your preferred IDE, download up the TCPMon Eclipse plugin, copy the same to the ECLIPSE_HOME/plugins directory, go to Window -> Show View -> Other -> TCP Monitor -> TCP Monitor and it will open the TCPMon View. Change the endpoint to the TCP Listener endpoint and configure the actual downstream endpoint in TCPMon.

Logs indicated that Transfer-Encoding was being sent as "chunked". Now this was different from the Axis 1.2 logs which had Content-Length set in the HTTP header. Reading up the Axis2 documentation threw some more light on the topic.

By default Apache Axis 1.2 uses 'org.apache.axis.transport.http.HTTPSender' and this in turn uses HTTP/1.0, hence the default behaviour is to set Content-Length. But with Axis 2 which uses HTTP/1.1, the default is Transfer-Encoding set to "chunked". When the data is sent in chunked format, there are some special characters introduced in the payload (refer the snippet below). If the downstream system is a legacy system which does not support HTTP 1.1 (as is ours) and is unable to parse the message due to these additional characters, it returns a Soap Fault Exception.

The solution to this is to disable HTTP chunking as follows.
options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.FALSE);

That said, if this issue is caught in the development stage, check if the team hosting the web service can support HTTP Chunking, since it is the preferred approach, especially when dealing with large messages like messages with attachments (MTOM).


HTTP Header using Axis 2

POST /test HTTP/1.1
Content-Type: text/xml; charset=UTF-8
SOAPAction: "http://test.com/wsdl/07/08/10#testDiagnosticRequest"
User-Agent: Axis2
Host: 127.0.0.1:8086
Transfer-Encoding: chunked
1aa









"
0

HTTP Header using Axis 1.2

Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.2.1
Host: 127.0.0.1:8086
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: "urn:GAT__Inbox/OpCreate"
Content-Length: 6698


...

Hibernate, Tomcat 6.0 and mysql

My normal configuration stack is Spring, Hibernate and Oracle on Weblogic. Switched today to the lightweight mysql and Tomcat - blame it on limited RAM.

Issue: The error thrown up in the logs is
java.lang.UnsupportedOperationException: Not supported by BasicDataSource
at org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.java:899)
...

The configuration files are listed below

server.xml located at %CATALINA_HOME%/conf

context.xml located at %CATALINA_HOME%/conf

hibernate.cfg.xml

com.mysql.jdbc.Driver
java:comp/env/jdbc/products
true
org.hibernate.dialect.MySQLDialect
root
xxxxxx

Reason: Hibernate.jar/DatasourceConnectionProvider/getConnection method invokes Tomcat 6/BasicDataSource passing the username and password.
But the BasicDataSource getConnection(String username, String password) method throws UnsupportedOperationException.

Solution: Remove the credentials from the hibernate.cfg.xml file, retain 'em only in the datasource setting. This will result in the no argument getConnection method being invoked which is implemented in BasicDataSource

Google chrome offline installer

The Google chrome download offers an online installer, but try installing from the office comp and the proxy plays spoilsport.

So, how do you go about downloading an offline installer. Kinda simple, just add 'standalone=1' to the url for the online installer. Offline installation url

Auto-updation might not work, well you can't have everything :-)

CXF and Weblogic

Tried CXF with Tomcat - works like a dream. Next, tried deploying the war onto Weblogic and the dream turns sour. Well, eventually things did turn out all right, if only I'd read the documentation on the apache site earlier, details summarized below. There are 2 ways u can work it.

1. Put jars in endorsed folder (This way is not recommended, since it might break the application server itself. The method below is preferred, as it impacts a single module only.)
- Put the geronimo-ws-metadata_2.0_spec-1.1.1.jar in the $Weblogic_Home/jdk_../jre/lib/endorsed folder.
- Deploy the CXF war in weblogic.
2. Pack war in an ear, deploy the ear with weblogic-application.xml - Create a standard J2EE application.xml file in the META-INF folder.

Axis 1.2 / Spring and Upper case operation names

If your wsdl has an operation name starting with an upper case, don't go for the Axis1.2 + Spring 1.2.5 dynamic proxy solution.

Problem => Axis generates remote interface methods in lower camel case notation even if the web service operation is in upper case. Initially thought Axis was the problem, but a simple Axis client works perfectly. It is when you try wiring together Axis and Spring to generate an Axis dynamic proxy using JaxRpcPortProxyFactoryBean that the problem crops up. Spring invokes the operation in the same case as interface method name.

Resolution => Tweak the generated interface manually or simply wire in Axis and Spring bypassing the JaxRpcPortProxyFactoryBean.

Need to check if Spring 2 has this problem sorted out.

Needle in a haystack

Neat concept - There's a related article on GigaOm - BigData

Javascript related links

How to load javascript w/o blocking - The best way to load external javascript
Event delegation in JavaScript
HTML 5 introduced three new options for client-side data storage: sessionStorage, localStorage, and client-side databases. A write-up on Session Storage