Using HttPClient to invoke a web service

Assume that the web service operation accepts a zip file as a base64 encoded string in its SOAP message body. Here is a way how I got it to work using commons HttpClient.

import org.apache.commons.io.FileUtils;
import org.apache.commons.httpclient.*;
import org.apache.commons.codec.binary.Base64;
import javax.xml.soap.*

public class FileUploader{

public static void main(String args[]) throws Exception{
String serviceEndpointUrl;// assign the service endpoint url here
File uploadingFile=new File("HelloWorld.zip");
HttpClient client = new HttpClient();
PostMethod method = new PostMethod(serviceEndpointUrl);

RequestEntity re= getRequestEntity(uploadingFile)
method.setRequestEntity(re);

method.getParams().setParameter(HttpMethodParams.RETRY_HANDLER,
new DefaultHttpMethodRetryHandler(1, false));

int statusCode = client.executeMethod(method);

String responseBody = method.getResponseBodyAsString();
System.out.println(responseBody);
}

static RequestEntity getRequestEntity(File file) throws Exception{
MessageFactory mFactory = MessageFactory.newInstance();
SOAPMessage message= mFactory.createMessage();
SOAPBody body= message.getSOAPBody();
SOAPElement zipElement=body.addChildElement("zip");

StringBuilder content= new StringBuilder();
byte[] arr= FileUtils.readFileToByteArray(file);
byte[] encoded= Base64.encodeBase64Chunked(arr);

for (int i= 0; i < encoded.length; i++) {
content.append((char) encoded[i]);
}

ByteArrayOutputStream b= new ByteArrayOutputStream();
message.writeTo(b);
String base64EncodedString= b.toString();

return new StringEntity(base64EncodedString);
}

You will need Apache commons jars in your classpath.

Converting a String to org.jdom.Document

import org.jdom.*;

String xml="<name> buddhika < /name >";

SAXBuilder builder=new SAXBuilder();

Document doc = builder.build(new StringReader(xml));

Useful Linux Commands and Tools

To list the kernel routing table
$ netstat -nr

To get the information about USB buses in the system and devices connected to them
$ lsusb

To get a listing of open ports with associated processes
$ sudo lsof -i
or
$ sudo netstat -lptu

Using netcat to setup a server
$ nc -l -p [port]

Using netcat as a proxy
$ nc -l -p [listening-port] | nc [host:port] | nc -l -p [output-port]

Any request sent via the listening port will be directed to the host defined in the second stage of the pipe and the results can be gathered from the output port.

Building ODE- Errors and Tips

It seems building ODE is not the easiest thing to do. I found this the hard way when I really messed up all sorts of things when trying to build ODE in my office machine. (Funny thing is that it went to the extent of reinstalling the OS). The process is quite strange if you are new to the Ruby world like me, because ODE uses a Ruby build system called buildr. Before installing buildr following packages has to be installed if Ruby is not installed in your system.

Ruby - packages related to the language
RubyGems - the Ruby package manager

buildr internally uses the Ruby build program Rake which is a simple ruby build program with capabilities similar to make.

So the second time I was prepared. I metaculously went through the instructions in the ODE and buildr sites. Since the information is scattered a bit across sites, here is the exact the steps I went through for a succesful ODE build. Note that ODE branch and ODE trunk uses different versions of buildr. So both versions of buildr has to be installed first.

Important: I am using an Ubuntu box. So these steps are for an Ubuntu system.

Installing buildr


Step 1 - Installing Ruby

$ sudo apt-get install ruby-full ruby1.8-dev libopenssl-ruby build-essential

Step 2 - Installing RubyGems

$ wget http://rubyforge.org/frs/download.php/38646/rubygems-1.2.0.tgz
$ tar xzf rubygems-1.2.0.tgz
$ cd rubygems-1.2.0
$ sudo ruby setup.rb
$ sudo ln -s /usr/bin/gem1.8 /usr/bin/gem

Step 3 - Installing buildr

$ sudo env JAVA_HOME=$JAVA_HOME gem install buildr -v 1.2.10
//this version is used to build ODE branch

$ sudo env JAVA_HOME=$JAVA_HOME gem install buildr -v 1.3.2
//this version is used to build ODE trunk

Step 4 - Source checkout

Now installing buildr has been done ODE can be built from its source. To checkout ODE.

Branch

$> svn checkout http://svn.apache.org/repos/asf/ode/branches/APACHE_ODE_1.X ode-1.X

Trunk

$> svn checkout http://svn.apache.org/repos/asf/ode/trunk ode-trunk

Step 5 - Build ODE

Go to the checkout directory. In this case ode-1.x in case of branch and ode-trunk in case of trunk.

Building branch

$> buildr _1.2.10_ clean install TEST=no

Building trunk

$> buildr _1.3.2_ clean install TEST=no

Generating Eclipse project files

$> buildr eclipse

Generating IDEA project files

$> buildr idea

Note: It also work even if you don't mention the buildr version in trunk build. But in the branch build version number has to be used. Otherwise you may see an error similar to this.

rake aborted!
can't activate buildr (~> 1.2.4, runtime), already activated buildr-1.3.2
~/ode-1.x/Rakefile:17

Using Eclipse BatchCompiler

Using the BatchCompiler to compile a Java source at runtime is well documented in the Eclipse help system. The problem that I came across was providing the classpath for the compilation to happen. Actually the jars needed, I had included in the runtime classpath of my plugin and were inside the plugin project. First challenge was to get the classpath entries so that I can append them to compile String to be fed in to the compiler. Surprisingly it wasn't easy enough as I had thought. After some experimentations on plugin API I finally got following code to work.

Dictionary manifest=Activator.getDefault().getBundle().getHeaders();
Enumeration cpKeyEnum=manifest.keys();
String classpath;

while(cpKeyEnum.hasMoreElements()){
Object cpKey=cpKeyEnum.nextElement();
if(cpKey.toString().equals("Bundle-ClassPath")){
classPath=manifest.get(cpKey).toString();
break;
}
}

Activator is the plugin activator class. Here the classpath is obtained as a comma seperated list of relative paths included in the "Bundle-ClassPath" header of MANIFEST.MF.

After solving that soon I realised the BatchCompiler itself cannot access the jars from the relative paths I got from the earlier exercise. So I had to extract these jars to a temporary location and feed the absolute path of this location to the BatchCompiler.

Changing runtime classPath of an Eclipse plugin programmatically??

While I was developing some functionality for a Eclipse plugin I came across the need to change the classpath at runtime so that some runtime generated class files can be accessed by the code. I found a hack after some Googling. (http://forums.sun.com/thread.jspa?threadID=300557). It worked fine when run as a standalone Java program. But when tried to port my code to the plugin it failed miserbly.
Only other thing that I could think of was using a seperate classloader to load these classes which actually worked. Seems that's the way to go to be on the safe side.

Revolution or scam?

I happened to hit upon an incredulous site when I was lazily surfing the web. This site happens to be promoting a book which says the science that Newton and Einstien nurtured is fundamenatally flawed. First chapter is freely available at the site. This guy goes on to say that even the mathematical derivation of some of Einstien's equations are wrong. Not being much of a physicist I am not in a position to challenge them. But what can be said is that the first chapter is full of drama. He discredits most fundamental aspects of science concepts such as work etc. May be just like most Internet hypes this may well be a scam to make some quick buck. Anyway since radical thinking is the corner stone of science this may be an interesting reading to an open minded to ponder about.

Way to reach the site for anyone interested.
www.thefinaltheory.com.