jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicholas Lesiecki" <n...@eblox.com>
Subject RE: Refactoring question
Date Wed, 24 Apr 2002 18:26:26 GMT
I actually have an article coming out on IBM developerWorks in May on
testing just such a situation. :) The short answer is to use AspectJ to
replace certain calls (for instance, to your EjbUtil class) when running
tests. The article runs a test suite in Cactus that I'm eventually going to
work into one of the sample applications. If you're interested, you can
start by checking out:

http://www.aspectj.org
or
http://www-106.ibm.com/developerworks/library/j-aspectj/index.html

I'm kind of amused by reading your code, it looks almost exactly like some
code I've written, right down to:

HandlerHome home = EjbUtil.lookupHome(Handler.class, jndiName);

I think our static class is called EJBUtils, and the order of parameters is
reversed :)

Cheers,

Nicholas Lesiecki
Principal Software Engineer
eBlox, Inc.
(520) 615-9345 x104
Check out my new book!:
Java Tools for Extreme Programming: Mastering Open Source Tools, including
Ant, JUnit, and Cactus

http://www.amazon.com/exec/obidos/ASIN/047120708X/

Check out my article on AspectJ:
http://www-106.ibm.com/developerworks/library/j-aspectj/index.html


-----Original Message-----
From: laurent.duperval@masq.ca [mailto:laurent.duperval@masq.ca]
Sent: Wednesday, April 24, 2002 9:50 AM
To: Cactus Mailing List
Subject: Refactoring question

Hi,

We're building a servlet which receives some parameters as input and calls a
handler based on the input parameters. How that works is that one of the
parameters is used as the JNDI name of the home interface of the handler. We
pass that parameter to a static utility method which will return the home
interface of that handler. So something like this:

String jndiName = httpRequest.getParameter("name");
HandlerHome home = EjbUtil.lookupHome(Handler.class, jndiName);
Handler handler = home.create();
Response response = handler.execute();
httpResponse.print(response.toString());
.
.
.

or something similar to this. All this nice stuff is going on in the
servlet's service() method. So evidently, it's untestable unless you have
the whole container running. In order to test properly, there needs to be a
refactoring of the service method so that I can write a test for it
specifically, without needing to have a container running that will give me
the correct home for the handler and all the rest of that. Has anyone done
anything similar? What type of refactoring did you do?

I think the main problem in this case is the Handler. The name of the
handler associated with each JNDI name is defined in the deployment
descriptor for the application. Is my option, then, to modify the deployment
descriptior on the fly (a bit like it's explained in the FAQ for web.xml)
and to create a stubbed handler just for testing purposes? Or is there a
more obvious way to do this that I can't see?

Thanks for all the help,

L (who will eventually contribute back)

--
Laurent Duperval <mailto:laurent.duperval@masq.ca>

Do you need a silencer if you are going to shoot a mime?



--
To unsubscribe, e-mail:
<mailto:cactus-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:cactus-user-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:cactus-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:cactus-user-help@jakarta.apache.org>


Mime
View raw message