In a former life, as a BEA Weblogic consultant, I'm sure I would have sorted this problem out so much sooner!

 We're using Apache's JackRabbit to provide a document repository and the configuration is done using and XML config file. Windows users appear to work fine, but on my Linux (Ubuntu) machine, the server reports problems reading the config:

org.apache.jackrabbit.core.config.ConfigurationException: Configuration file could not be read.: jackrabbit.apache.org: jackrabbit.apache.org
at org.apache.jackrabbit.core.config.ConfigurationParser.parseXML(ConfigurationParser.java:202)
at org.apache.jackrabbit.core.config.RepositoryConfigurationParser.parseRepositoryConfig(RepositoryConfigurationParser.java:181)
 

I often work on projects where we run load and performance testing for clients. Load testing produces huge amounts of data that needs to be analysed and the results of that analysis published. Much of this analysis is mechanical: calculating means, 90th percentiles, and variances; producing charts of response time over the course of a run etc.

We like to publish data in an accessible fashion that allows all the stakeholders to see progress and in particular allows everyone to participate. We've found using a Wiki for this to be excellent. However, getting data out of load testing tools and publishing it on a Wiki usually takes a lot of manual effort, so I decided to investigate how to do this as automatically as possible - so that I can actually spend my time adding value.

The tools I use are:

We have been using agile development methodologies at Black Pepper for a while now and have used Mingle in the past as an online tool for managing stories and iterations.

However, we recently decided on Jira as our feature/bug tracking tool of choice and thought it would be interesting to see if we could use Jira to manage our agile projects rather than have more than one tool.

One of the cornerstones of an agile project is tracking your velocity. This is essentially a measure of how much work you are doing over a period of time. Agile projects are run in iterations, these might be a week, 2 weeks or perhaps a month. The length of the iteration would depend on the project, but 2 week iterations are a good start. Each iteration has a collection of "stories" assigned to it. A story is basically a single feature that has been defined through your analysis of the project before the first iteration. Note that as this is an agile project, you don't have to analyse the project completely up front and have everything mapped out. You just need enough to get you on your way, you will be creating and estimating more stories as you go.

I've come across an oddity in my functional tests for a GWT application I am working on.

The Selenium RC test I have should simulate a user clicking on a button, implemented as a GWT PushButton (com.google.gwt.user.client.ui.PushButton). The problem is that the click on the button never seemed to work using the following code

 
selenium.click(BUTTON_ID);
 

A GWT PushButton is not a standard HTML <input type="submit" ...> or a <button ...> rather it is a styled button constructed from DIV and other HTML tags.

As you may gather from other entries in this blog, we've been working on a customer project which uses Flex for the client and Java for the server, with SOAP over HTTP in between. It worked well for us as a combination, because it minimised the number of new things to be learned - helpful when you're dealing with, er, aggressive delivery timescale aspirations. I've been having a few doubts about its long-term viability, though. SOAP's pretty verbose, and I'm not sure how quick the marshalling to/from XML is in ActionScript. Anyway, I was lucky enough to have a bit of spare time to investigate BlazeDS as an alternative, and thought I'd share some of the experience.

I downloaded BlazeDS and the sample applications to use as a guide in converting my existing web application. I'm not going to go into all the details here since that's not really the focus of this article - the Adobe BlazeDS Developer's Guide is well worth reading. Our server side code is a Spring application, so some extra work was required to make Blaze and Spring work together. Fortunately, Christophe Conraets has written an excellent article on the subject, along with some very handy sample code, which I have made use of.

Our server-side code is a Spring application, but there are a few minor peculiarities in the way it uses Spring 2 Security. The server is completely stateless, so the Flex client has to authenticate each request. For the SOAP version, we pass an authentication token in a custom HTTP header (Flex prevents you from accessing certain HTTP headers, the Authorization header included). In the BlazeDS version, I had to find another way of authenticating, since I couldn't see a way of getting access to the HTTP request that it uses to send the request to the server, so no way of adding my custom header.

When using Tomcat 5.5 for either development or production it is sometimes useful to have multiple instances of Tomcat running at the same time.

The instructions below allow you to set up the minimum tomcat configuration to run multiple Tomcat instances.

1. Install a Tomcat 5.5 distribution. The CATALINA_HOME environment variable will point to this location.
2. Create a directory that will be your Catalina base, identified by the environment variable CATALINA_BASE
3. Within this directory create the following directories
   • logs
   • conf
   • webapps
4. From your base Tomcat 5.5 distribution copy the following files from $CATALINA_HOME/conf to the conf directory that you have just created:
   • catalina.properties
   • context.xml
   • server.xml
   • tomcat-users.xml
   • web.xml

With this structure one can now run Tomcat. Open a terminal, ensure that the environment variable CATALINA_HOME is set to point at the directory created in (1) above, set the environment variable CATALINA_BASE to point at the directory created in (2) above.

I've recently been using JPA for the persistence layer of a project, and I'm liking it a lot. As I am a firm believer in TDD I've been applying this to the persistence layer of my application, and I thought that I'd share my approach to this.

The persistence layer uses Hibernate as the JPA provider and for test purposes this is great as it allows the RDBMS to be changed with relative ease.

In order to test the integration of the JPA provider with an RDBMS I will be using HSQLDB as the the RDBMS. This has the benefit of having a very lightweight in-memory execution model that makes it quick and easy to set up and tear down the entire database infrastructure. HSQLDB won't actually be the production RDBMS (this is likely to be MySQL), however the JPA/Hibernate combination makes it fairly trivial to use different RDBMS engines.

This is a continuation of my previous blog entry, so check out part 1 if you want to read about how to expose your Spring objects as SOAP services using XFire.

Now that we have a working SOAP web service, we can some Flex code to talk to it. In most of the documentation you'll find, people suggest using the WSDL import wizard functionality that comes with FlexBuilder3 to auto generate a bunch of boilerplate code. When I started on this project, some SOAP integration at the Flex side of things had already begun and they had indeed used this method. It gets you up to speed quite quickly, but it is very black box and incredibly verbose with the amount of ActionScript it generates.

We recently took on a project at Black Pepper which required a Flex front end that talked to a server with all of the business logic and data.

Our set of technologies for the server side was this:

• Java 5
• XFire for exposing SOAP service
• Spring Framework to wire it all together
• Hibernate for persistence
• MySql as our database
• Eclipse as our IDE of choice
• Linux or Mac desktops

So, pretty much our usual setup that we've done a load of times, except for the XFire part which was new...and the focus of this blog entry.