Simon Fell > Its just code > October 2005

Great shot of Barefoot's sweetness blend

Fresh into today from the windy city, Metropolis Coffee's very yummy Redline decaf

Should of been a heart, didn't quite make it

Notice how the leaves are starting to extend out now, getting better

Perhaps i should add categories to the blog and move the espresso stuff ?

In case you're not sure what my latte art is supposed to look like, check out this awesome set of latte art pictures.

I don't know if anyone is still using RESTLog.NET / Relaxer (besides me that is) but I updated the RESTLog.NET server code and the relaxer client to support the easy upload of supporting files for a blog post (such as images, zips etc). The latest RESLlog.NET code is in CVS at SourceForge, the latest drop of relaxer is available on the Relaxer page

I did a heart in a macchiato (3oz) which was even better than these 2, but my crappy camera didn't focus properly, here's a couple of cappa hearts (6oz)

Starting to feel like I'm getting somewhere now

Apache Axis 1.3 just shipped (congrats Glen, Dims & folks), and it now supports HTTP request / response gzip compression, for services that run over the internet this can be a big win. By default its turned off, the easiest way I know how to turn it on is to sub class your service locator class and override the createCall method. here's an example, lets suppose you've run WSDL2Java on the sforce enterprise WSDL, you'll be left with a SforceServiceLocator class, this is the class you'll subclass, e.g.

import javax.xml.rpc.Call;
import javax.xml.rpc.ServiceException;

import org.apache.axis.transport.http.HTTPConstants;

import com.sforce.soap.enterprise.SforceServiceLocator;

public class SforceService extends SforceServiceLocator {

	public Call createCall() throws ServiceException {
		Call call = super.createCall();
		call.setProperty(HTTPConstants.MC_ACCEPT_GZIP, Boolean.TRUE);
		call.setProperty(HTTPConstants.MC_GZIP_REQUEST, Boolean.TRUE);
		return call;
	}
}

Then your client code creates an instance of this subclass rather then SforceServiceLocator directly to get an instance of the Soap proxy.

Soap svc = new SforceService().getSoap();
LoginResult lr = svc.login("user@corp.org", "thePassword");

Your request to the server is gzipped compressed (the MC_GZIP_REQUEST property), and the request advertises (via the Accept-Encoding http header) that it'll accept a gzipped response (the MC_ACCEPPT_GZIP property). In the case of an sforce call like Query which can return very large responses you can see some big decreases in message sizes, a quick test here shows that an uncompressed response of 376426 bytes compresses down to a measly 33617 bytes (approx 9% the original size)

In addition to the above, you have to configure axis to use the vastly superior CommonsHTTPSender class rather than the default HTTPSender class as its transport, this is done by changing the transport entry in the client-config.wsdd file from java:org.apache.axis.transport.http.HTTPSender to java:org.apache.axis.transport.http.CommonsHTTPSender and adding Commons HTTP to the class path.

Nice looking shot

making very slow but steady progress on the latte art front

The codegen / compile problems in Axis 2 with the SForce WSDL are fixed in SVN (quick turnaround!). I didn't think they'd manage it, but somehow they managed to make using an Axis 2.0 client even more long winded than Indigo, perhaps I'm doing something wrong ?

public static void main(String[] args) throws Exception {
		
	SoapStub stub = new SoapStub();
		
	CallOptionsDocument od = CallOptionsDocument.Factory.newInstance();
	CallOptions options = CallOptions.Factory.newInstance();
	od.setCallOptions(options);
		
	Login l = Login.Factory.newInstance();
	l.setUsername("[username]");
	l.setPassword("[password]");
	LoginDocument ld = LoginDocument.Factory.newInstance();
	ld.setLogin(l);
	LoginResult lr = stub.login(ld, od).getLoginResponse().getResult();
		
	System.out.println("new SessionId is " + lr.getSessionId());
	System.out.println("new ServerUrl is " + lr.getServerUrl());
		
	stub = new SoapStub(null, lr.getServerUrl());
	SessionHeaderDocument sd = SessionHeaderDocument.Factory.newInstance();
	SessionHeader session = SessionHeader.Factory.newInstance();
	session.setSessionId(lr.getSessionId());
	sd.setSessionHeader(session);
		
	QueryOptionsDocument qod = QueryOptionsDocument.Factory.newInstance();
	QueryOptions qo = QueryOptions.Factory.newInstance();
	qod.setQueryOptions(qo);
		
	QueryDocument queryD = QueryDocument.Factory.newInstance();
	Query query = Query.Factory.newInstance();
	query.setQueryString("select id, name, accountNumber from Account");
	queryD.setQuery(query);
		
	QueryResult qres = stub.query(queryD, sd, od, qod).getQueryResponse().getResult();
		
	System.out.println("total query size is " + qres.getSize());
}

I must of missed the Gartner report that said the programming model for WS stacks needed to be more verbose, both Axis 2.0 & Indigo have programming models that require heaps more boiler plate code than their previous counterparts.