struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Cushing <>
Subject Re: S2 best location of application init params
Date Fri, 09 Nov 2007 21:38:44 GMT
If you're using Spring (and if you're not, now might be the time to consider it), I'd say make
that a property of your application object that needs to configuration. That is, using your
example, say you've got a class, TransactionLogger that needs "the home directory of the file
system to which the application will write." Give it a property, loggingDirectory, and configure
it with Spring, giving it a bean id of "transactionLogger". Then, add Struts 2's Spring plugin
to your project (just include the JAR), define a method setTransactionLogger(), and Spring/Struts
will automatically inject the TransactionLogger instance into your object. In your action,
just call transactionLogger.logTransaction(foo), and there you go!

Among the benefit of this approach are: 
1.You can unit test your business object (TransactionLogger) without involving Struts at all
2. The business object could be re-used outside your Struts application
3. The configuration is only where it needs to be; in the business object itself. So you don't
have to come up with some naming convention for your init-params, nor do you have to write
tedious code to make the business object aware of the configuration. That is, TranscationLogger
doesn't have to be tied to the Servlet API, nor do you have to write an initialization servlet
that creates a TransactionLogger.

This ventures off-topic from Struts 2, which should probably be your goal: your business objects
should not be tied to Struts or the Servlet API.

On Friday, November 09, 2007, at 12:41PM, "tom` frost" <> wrote:
>I'm looking for the best place to put application init stuff.  I'm thinking
>of something like the home directory of the file system to which the
>application will write to.  What's the best way of apssing such information
>in.  In the past I have used servlet api init params, but with all the
>effort made in S2 to separate your code from Servlet api, surely there's a
>better way.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message