tomakehurst/wiremock — pull request #30 by rabelenda (2013-04-30 03:26:26+00:00)
Title: Added journal capacity parameter

I created a patch with the addition of journal-capacity parameter to let specify the limit of the JournalRequest. For this I created some clases, the corresponding tests, done some refactoring and updated documentation. Of course if you want to change or ignore any of the changes, I will not be offended in any way, its your project :-).

Some notes on the implementation: On the first commit, I created only the bounded implementation, so there was no way to create unbounded request journals. Additionally, in that commit the bounded implementation was implemented with a LinkedList and an int to hold the capacity. On the second commit I opted to use the already implemented CircularBuffer provided by common-collections. I don't know if you are interested on maintain the final jar size, and try to include as few dependencies as possible, but from my point of view is better to use an already implemented class, which makes the code cleaner and is already tested :-). You are in all your right to chose the first approach, but I think if the final jar size matters then you can find alternatives to that, like proguard (http://proguard.sourceforge.net/).
I run some performance tests between both approach (LinkedList + INT vs CircularBuffer) and there are no important differences (4,5K TPS on both on my machine).

I also had to fix the LoggedRequestTest because it was failing for me. It was timezone based dependent, so if you were running it on a machine that was not on GMT+1 it would fail (this is because SimpleDateFormat takes the machine timezone to parse the date). To fix the test I just calculated the amount of milliseconds instead of having it hardcoded. Another alternative is to set the timezone on the SimpleDateFormat instance, but I tried to change as little as possible.

I hope this changes can help you. If I find myself more time I will try to include further ideas that I have. One thing that I found on an alternative tool (Mockey), and is cool for the standalone mode, is to have a GUI (which I found in your project there is some rudimentary progress on this). Which is the proper way to communicate with you for further features and design choices? Through issues in github? mail?

Regards, Roger.