A brief aside from all the techno-babble.
You know how when you’re on the other side of the world and you say where you’re from people always say things like, “Oh, my second cousin Jake lives there, you must know them…”
Well in the spirit of the aforementioned, and in the knowledge that there are quite a few java bloggers in Sydney: My sister (Anna Hobbs) lives there and some of her friends are developers. Anyone reading this know her?
Hi Anna!
JMock is your friend…
JMock does actually look quite similar to what I’ve done, but it is focussed more on the normal use of Mockobjects – ie. checking they were called with the expected values.
I’m not really doing Mocks at this point – its more like convincing an application that its running inside a real servlet container. Which means that I have to be able to understand that when I get a call like request.getHeader(“user-agent”), I need to return “Fakezilla”, but when I get request.getHeader(“if-modified-since”), I have to return a valid date string, or null. I’m not trying to assert how the mocks are called, just fake up a convincing looking environment. What I’ve ended up with is essentially a form of dynamic dispatch, as each mock has a collection of MethodReceivers in a Map keyed by method name, and each MethodReceiver has a Map of MethodReturn objects, keyed by an ArrayList of the arguments. Its then a case of calling getReturnValue on the MethodReturn object (confused yet?). I can therefore return different responses based on the actual values (not just type) of the arguments.
I can also simply make the Mock return a hard-coded response directly where I can get away with it (methods with no arguments for example).
There’s some syntactic ugliness in the setup code due to Java’s lack of enclosures – the closest approximation I’ve found is to implement an interface ‘in-place’ with an anonymous block. The alternative is hundreds of really tiny and very similar looking concrete classes.
The whole thing isn’t exactly generic or lightweight, as you have to know quite a lot about what your application is going to need in the way of parameters, and which methods its going to call on the request/response objects, but it has been quite illuminating finding out just how the application in question interacts with its environment.
And its nice to work on something a little off the wall every now and then 🙂
The Lucene guys have added an updated file format information page. Interesting for wannabe searchengine technology mavens (like me).
There’s also a new article on the site about the LARM webcrawler project that’s currently underway here.
Spent the afternoon making a servlet based application run all by itself by mocking the HttpServletRequest/Response, ServletContext etc etc. interfaces. It was also a great opportunity to use dynamic proxies in anger for the first time. I ended up with a rather nice abstract implementation of InvocationHandler that contained a Map of method names and MethodReceiver objects for the calls I cared about. Using dynamic proxies saved loads of time – I could code up canned responses to the method calls I was interested in and ignore the rest. It was kind of fun being able to instantiate a servlet inside a TestCase, call doGet() and get all the HTML dumped to System.out.
I didn’t quite reimplement EasyMock from scratch, but there’s probably some synergy to be had there…
I’ve posted a straight copy of my ANT build file for Webwork up here.
The project is just something I was toying with as an excuse for learning Webwork & Castor – its vapour at the moment – don’t expect a Roller-killer anytime soon 🙂
I’ll add some more details (source code, jsp’s, required jar files etc.) as and when it occurs to me.
Untangling the Gordian Knot. Currently working on a project to untangle a hairball project. Its quite tempting to cut the Gordian Knot, but we… [development]
Interfaces are my friend in this situation. I have found it really useful to extract a single method on the bloated object I’m trying to break up into an interface, and substituting a reference to the interface in the calling code wherever possible, repeating for each method, initially by defining one interface per method, and occasionally consolidating the interfaces where I find that several of them are passed around together. It does mean that for really blob-like objects, at about the halfway stage I find myself with humourous constructors like:-
MyThing thing = new MyThing(this, this, this, this, this);
Where ‘this’ is some bloated object that now implements 5 distinct interfaces, and the target class has been refactored to work through the interfaces. Its so obviously wrong that sheer embarrassment forces you to keep refactoring until its all clean. Writing tests gets really easy too. Its easy to make the TestCase implement an interface and pass itself to the object under test (self-shunt pattern) when the interface only declares one method!
Another useful AOP article here.
Jumping back on the aspects bandwagon (trying to explain something often helps
me to understand it):
Indirection, aka abstraction: You call a method on an interface, and the
recipient is determined at runtime, and may be at the end of several ‘middlemen’
who simply pass the message along. What AOP does for you is allow you to
dynamically compose a whole method call chain using reusable interceptors. So
calling setFoo() on something that appears to be a simple bean can actually take
a quick detour to your validation interceptor to check the syntax, then visit
the persistence interceptor, telling it that the field is dirty, before
returning. This is nothing that can’t already be done without AOP, but AOP (ie.
interceptors & extensions) appears to be much more flexible and reusable. Being
able to define your interceptor stack in a descriptor or programmatically means
you can substantially alter the behaviour of bits of your application while its
running, and the calling code still sees a simple ‘setFoo’ bean like interface.
And the possibilities for code reuse look huge.
Of course, I could be entirely wrong – I’m still trying to wrap my brain around
the concept.
Webwork+XDoclet 1.2 beta+ANT+Resin == Rapid Prototyping City
This is somewhat sketchy on the details, but I wanted to get it out there while it was fresh in my mind.
How to iteratively prototype a webapp:-
Get Webwork and import it into your project.
Slap together an ANT script that compiles your stuff and WARs it up, puts the web.xml file from webwork in WEB-INF and includes webwork.jar in your WEB-INF/lib folder. Add an extra line to copy your WAR to your servlet container’s webapps directory.
Build at least one class that extends ActionSupport. Override execute() to return Action.SUCCESS.
Put a class-level javadoc comment that looks something like this in it:
/** * @webwork.action * name="myCoolAction" * input="myInput.jsp" * success="myCoolActionSuccess.jsp" /*
Write a simple jsp called myInput.jsp with an input form along the lines of:-
FORM METHOD="POST" ACTION="myCoolAction.action"
Write a quick success.jsp page with a ‘well done’ or similar message.
Get XDoclet 1.2 beta. Stick the jars in Ant’s classpath. Add a target that look like this:-
<target name="xdoclet" depends="init" <taskdef name="webdoclet" classname="xdoclet.modules.web.WebDocletTask" classpathref="class.path" />
<webdoclet
destdir="${build}/src"
mergedir="parent-fake-to-debug"
excludedtags="@version,@author,@todo"
addedtags="@xdoclet-generated at ${TODAY}, XDoclet,@version ${version}"
verbose="false"
>
<fileset dir="${src.java}">
<include name="**/*Servlet.java"/>
<include name="**/*Filter.java"/>
<include name="**/*Tag.java"/>
<include name="**/*Action.java"/>
</fileset>
<webWorkConfigProperties destDir="${webinf.classes}"/>
</webdoclet>
</target>
Include the target into your default build, just before the compilation step.
Run ANT. Wait for resin to reload your webapp.
Open /yourWebapp/myInput.jsp. Submit it. See the success.jsp page. Modify your Action class’s execute() method to actually do something, like check for the right name/value pairs. Make it return Action.INPUT to go round again, Action.SUCCESS to succeed and go to success.jsp, Action.ERROR to report an error etc.
Repeat.
More details when I have time.
Web-the_simplest_thing_that_can_possibly-Work. I get WebWork. Finally. For some reason I’ve had a mental block on it up until now. Every time I sat down to explore it something came up, or I got bored. Finally cracked it this afternoon. Turns it I was expecting something complex, and it’s actually really simple. This appeared to cause me as much (or more) mental discontinuity as when I’m expecting something to be trivial, and it turns out to be much more complex. WW really is very simple, but it lacks an ‘idiots guide’ which would have been very helpful to me. I’ll see if I can retrace my steps and post my experiences up sometime. [Pushing the envelope]
Great! A WW idiots guide would be fantastic. Did you read Joseph Ottinger’s tutorial? Maybe that would be a good starting point to collaborate on?
Doh! No I didn’t know about Joseph’s tutorial, I must have skimmed over the post where you mentioned it. That would have made life much easier 🙂
I find this kind of blow-by-blow guide to be an excellent ‘kickstart’ when using a new tool or framework. It helps me get my mind around the paradigm of the tool being used. I wish every new technology had one of these. For anyone else like me who missed Mike’s link, the guide can be found here:-
Darren Hobbs 