Friday, May 20, 2011

PyWSClient Release 1

A while back at work we needed a client to exercise our SOAP web services. For a while we used the SOA Client firefox plugin, and we also looked at the soapUI eclipse plugin. Neither quite did it for us - soapUI had a terrible interface and SOA Client produced messages that were not WS-I Basic profile compliant, so our server side choked on them.

I was also looking for an excuse to learn PySide, so I wrote my own. It is about 150 lines of python code, and makes use of the suds soap client for python and of course PySide to draw the GUI. Suds was super cool, as it built up a object representation of the service interface for me to dynamically build the needed inputs for each service. The whole thing is rather alpha at the moment - no real error messages if you do anything wrong, default window sizing is off, etc. - but it does work (at least for me). So in the open source spirit of release early, release often I'm putting it out there if anyone wants it. No license - public domain.


Features:
 - Select a WSDL address and sections for each call with fields for the parameters are provided
 - Supports HTTP Basic authentication
 - Shows the SOAP response text as well as the XML for the request and response

You can directly run the .py script if you have suds and Qt and PySide installed. I've also built a Mac .app (built it on Snow Leopard, so likely won't work for anything below that) that you can get from the DMG download. Feel free to comment or email me if it is useful to you or if you have any suggestions / patches.

.py file:

DMG for Mac (22 MB):

Tuesday, May 10, 2011

Recommended Reading

This is mostly for our new hires here at Data In Motion, but might be of interest for others as well - a list of books a that are a good starting place to learn enterprise Java, Guice / dependency injection, coding style and more. Hope to get copies of these for the office sometime.

Dependency Injection: Design patterns using Spring and Guice
By: Dhanji R. Prasanna
This one is available on Safari Proquest. Good intro to dependency injection / inversion of control by the guy who wrote the guice-servlet and guice-persist extensions, among other things.

Clean Code: A Handbook of Agile Software Craftsmanship
By: Robert C. Martin
Covers writing readable, self documenting code.

Refactoring: Improving the Design of Existing Code
By: Martin Fowler
Great book on executing evolutionary code change and design improvement while keeping code functional. Check out the author's website - he's behind lots of cool ideas in software engineering, there are some good articles there:
http://martinfowler.com/


JavaScript: The Good Parts
By: Douglas Crockford
Not too closely related to anything we are up to at work at the moment, but if you want to learn Javascript and enjoy it, take a look at this book. Definitely written for programmers - doesn't waste a word.

Profiling Tomcat with VisualVM on Mac OS X

I spent some time this last weekend (working on Mother's day - I'm terrible!) trying to figure out what was killing the performance of a particular operation in our tomcat application. This quest led me to do battle with a few bugs in the latest version of Java on Mac to get VisualVM profiling tomcat apps nicely.

VisualVM is included on Mac - you can fire it up by running `jvisualvm` in Terminal. It can attach to a VM in a couple of ways: locally, or over JMX. Either way requires a bit of fiddling. I got JMX working first, but apparently the instrumenting profiler doesn't work that way (maybe just for me?). There is a sampling profiler that works over JMX, but it only shows hot spots (methods with highest self time), not a call tree, and the hot spot information didn't help much with my issue.

UPDATE: I was wrong here. Call tree seems to work fine with the sampling profiler, just need to take a snapshot as a commenter pointed out, just like with the profiler. I still have the memory button grayed out with the sampler over JMX, so setting up the local option may be needed there or when you want to use the instrumenting profiler to get more precise data than the sampler can provide (but also poorer performance when profiling - see here)

 So I had to figure out how to connect locally as well. Here's what I found on both:

JMX Connection:
For this we just need to set the right JVM options before we start tomcat to enable JMX and allow VisualVM to connect without making us mess with authentication. Very bad idea on a production machine, but fine for development. Running the following before starting tomcat did the trick:
export JAVA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8086 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"
At this point you should be able to fire up VisualVM, chose File -> Add JMX Connection, put in localhost:8086 and connect.

Local:
Turns out that VisualVM finds local VMs to attach to through data in directories called hsperfdata_{current user's name} that java applications create in the directory specified by the property java.io.tmpdir if the option -XX:+UsePerfData is on. It looks like its on by default for me. On Mac, java.io.tmpdir defaults to /tmp, so that is where VisualVM is looking for these files. Tomcat however uses its own temp directory, at temp under your tomcat install. This gets a little more complex because it used to be that no matter what you set java.io.tmpdir to, java would still put the hsperfdata directories in the system tmp so that things like VisualVM could find it - its only in Java 6 update 24 that it gets put in the user specified temp directory. So this will become irrelevant when the next update is released and pushed out by Apple for Macs.

The bug report for the JVM is here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7009828

In the mean time, one way to work around this issue is to point VisualVM to the temp directory you are actually using with the -J-Djava.io.tmpdir option. So start up VisualVM like this:
jvisualvm -J-Djava.io.tmpdir=$CATALINA_HOME/temp

replacing $CATALINA_HOME with the path to your tomcat install.

I ran into one final complication here: It looks like tomcat sets java.io.tmpdir to $CATALINA_BASE/temp without a trailing slash. I found that this caused the jvm make folders like temphsperfdata_{username}, rather than put a hsperfdata_{username} folder in the temp directory. So finally, run
export CATALINA_TMPDIR=$CATALINA_HOME/temp/

again replacing $CATALINA_HOME with the path to your tomcat install. Be sure to include the trailing slash. At long last, I was able to fire up tomcat and VisualVM, see tomcat listed under the "local" section and run the profiler!