html table - td right align problem

I was recently trying to right align the contents of a in  table on my page and the align was not happening. The contents were still left aligned.

While there might be multiple causes for this, the following fixed the problem for me:

td style="float:right"

minor headache solved.

Multiple instances of Jetty

I recently had to run multiple instances of Jetty on the same machine. I thought seeing to it that the two instances run on different ports should allow them to run independently but this did not work. I got the following error:

                        Starting Jetty: Already Running!!

To allow multiple instances of Jetty to run use pay attention to the line

    Configure id="Server" class="org.mortbay.jetty.Server"

in the jetty.xml file (or configuration file). Here make sure that the id parameter is unique to your Jetty  instance. While this solves the issue, poking around somemore with the innards of jetty.sh reveals some absolute paths that, in my book, are better when turned to relative paths, especially in this case where we are trying to run multiple instances.

The JETTY_RUN is the parameter which decides where the jetty.pid file should be stored. It defaults to the first available of /var/run, /usr/var/run, and /tmp if not set. Change this value to an absolute path that is unique to this instance of Jetty should address the issue.


I found some of this information at http://capitalcodemonkey.blogspot.com/2008/04/creating-multiple-jetty-server.html

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.