quickly simulate a http POST request

While there may be many different ways to do this, one of the easiest ways would be to use SOAP UI. This is a great tool for testing Web Services, but lends itself well to what we want to achieve here.

1) Download SOAP UI and quickly create a project > test suite > test case > test step (HTTP request). Choose defaults for all values and you should be done in less than a minute.

2) Now in the Http test Request window, select the method as POST and put in the target URL. There is a space to enter the body of the request. In the example below, I have chosen "text/xml" for media type and have pasted a JSON string in the body. You can also set any headers that you need to set.

3) Hit the green arrow in the top left hand corner of the window. Your test is underway.

4) You will see the response, if any, in the response tab.

As mentioned earlier in this post, SOAP UI is an excellent tool to test Web Services. Give it a WSDL and it generates a whole suite of tests to test each and every call of the wsdl. Pretty cool huh? It can do much more than what we have touched upon here. Its an essential tool for any development involving web services.

modifying JAR files

Ever been in the situation where you just had to make changes to a JAR file? For whatever reason you cannot make a new JAR but have to change the one that you have ? I had to recently replace a class file inside a JAR file and this is the learning from that.

What's the bid deal you ask? Why not just use Winzip or WinRAR.. those can open up JAR files. Well, you can open the JARs up, but you can't fix them once you've broken them. If the need is to have a JAR file you can place on your build path, sneaking in a class file and the zipping it up wont work. No matter how cute you try to get naming your zipped file. The reason this does not work is that every JAR has a manifest file automatically created in it. And Winzip just doesn't play right with manifest files.

What you need to do is use the JAR utility that comes with JDK. This way you can insert you class file and create a new JAR that your application can pick up.

1) use the following command to "unzip" or expand your jar:

> jar xf .jar

This will cause the contents of the JAr to be extracted in the current directory.

2) Make your changes .. replace class file.. whatever.

3) use the following command to "zip" or create your new jar:

jar cf jar-file input-file(s)/folder

Of course, the Sun site has detailed information.

You could also use the u parameter to update only the files you need.
jar -uf .jar

log4j - a good configuration

I was fine-tuning my log4j settings today and decided upon the config below (as regards the format of output). This was keeping in mind what could be grep-ed easily and that we had multiple users hit our test environment.

The NDC bit is particularly useful. It lets you track which user/client caused the log entry.

log4j.appender.R.layout.ConversionPattern=%d{ISO8601} %-5p %10t %x [%C{1}] - %m%n

%d{ISO8601} - date and its format

%-5p last 5 letters of the priority

%t - thread name

%x - Nested Diagnostic Context (NDC)

%C - Java class name, %C{1} will output the last one component

%m - log message

%n - new line

The code required for NDC in the classes is quite simple and is at the end of this post. Turns out NDC has a known memory leak issue which should not trouble you if you use the NDC.remove() method after completeing all your log statements. _______________________________

..

..

import org.apache.log4j.NDC;

..

..

NDC.push("any ID that helps you identify the client >>"+ID);

..

//all log statements

..

logger.debug("whatever");

..

NDC.pop();

NDC.remove();

I found most of the information at http://www.vipan.com/htdocs/log4jhelp.html.

Today, I was in the unwieldy business of compiling Java code on my machine and testing the class files on another deployment (on different machine no less.) And Eclipse decided roil the already muddy waters. I placed class files on the server multiple times but never saw my changes come through. Double checked everything - times stamp on the class file, was I copying it to the correct folder, was my ftp client screwing up, did my Tomcat have the latest ... nothing seemed to work.

Finally I checked file sizes. Eclipse was dishing out crap as compiled files. "Clean" took out the old files, but the supposedly latest class files actually seemed to be generated from old code. It was particularly insidious behaviour not to warn me about this. Sometimes the classes just would not be there after a "clean + compile". And the problem disappeared just as it had arrived - without me doing anything about it . Other possibly relevant information - I had a couple of related projects (as opposed to jars). Moral of the story - Eclipse ain't perfect. Its capable of throwing a spanner in the works. Quietly at that.