You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by tom` frost <to...@gmail.com> on 2007/11/09 18:41:00 UTC
S2 best location of application init params
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.
Thanks,
Tom
Re: S2 best location of application init params
Posted by Jim Cushing <ji...@mac.com>.
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" <to...@gmail.com> 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.
>
>Thanks,
>Tom
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: S2 best location of application init params
Posted by Dave Newton <ne...@yahoo.com>.
In addition, the application context is available to
S2 actions w/o being tied to servlet.
d.
--- Wes Wannemacher <we...@wantii.com> wrote:
> There are two other options that I've used in the
> past... One is
> Spring. You could create a custom bean or set of
> beans and initialize
> them with Spring and use the spring plug-in to help
> get at those beans
> any time you need them.
>
> Spring is a big framework though and will add some
> complexity. The
> other option, if you are hoping to keep from
> depending on the Servlet
> API is a static initializer block. The problem with
> static blocks
> though is that they can get out of control when you
> start adding them
> to obscure classes. If you only have a small amount
> of lifting to do,
> I would use a static block. The advantage is that it
> adds no external
> dependencies which will make unit testing easy, but
> the disadvantage
> is that it can become unwieldy.
>
> If you are working on a large app, go with Spring,
> you may end up
> using some of it's other features. For a small app
> with minimal
> lifting, go with the static block. Of course,
> depending on the Servlet
> API isn't all bad, so don't count it out unless you
> really need to.
>
> -W
>
> On 11/9/07, tom` frost <to...@gmail.com> wrote:
> > I would still need to use the Servlet API to
> retrieve those values,
> > correct? I'm trying to find a way to pass in
> values directly to Struts, I
> > guess.
> >
> > On 11/9/00, Martin Gainty <mg...@hotmail.com>
> wrote:
> > >
> > > Hi Tom-
> > >
> > > how about implementing the default
> initialisation parameters by placing
> > > the
> > > init-param in web.xml?
> > > e.g.
> > > <init-param>
> > > <param-name>debug</param-name>
> > > <param-value>true</param-value>
> > > </init-param>
> > >
> > > M--
> > > ----- Original Message -----
> > > From: "tom` frost" <to...@gmail.com>
> > > To: <us...@struts.apache.org>
> > > Sent: Friday, November 09, 2007 12:41 PM
> > > Subject: S2 best location of application init
> params
> > >
> > >
> > > > 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.
> > > >
> > > > Thanks,
> > > > Tom
> > > >
> > >
> > >
> > >
>
---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail:
> user-help@struts.apache.org
> > >
> > >
> >
>
>
> --
> Wesley Wannemacher
> President, Head Engineer/Consultant
> WanTii, Inc.
> http://www.wantii.com
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> user-unsubscribe@struts.apache.org
> For additional commands, e-mail:
> user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: S2 best location of application init params
Posted by Wes Wannemacher <we...@wantii.com>.
There are two other options that I've used in the past... One is
Spring. You could create a custom bean or set of beans and initialize
them with Spring and use the spring plug-in to help get at those beans
any time you need them.
Spring is a big framework though and will add some complexity. The
other option, if you are hoping to keep from depending on the Servlet
API is a static initializer block. The problem with static blocks
though is that they can get out of control when you start adding them
to obscure classes. If you only have a small amount of lifting to do,
I would use a static block. The advantage is that it adds no external
dependencies which will make unit testing easy, but the disadvantage
is that it can become unwieldy.
If you are working on a large app, go with Spring, you may end up
using some of it's other features. For a small app with minimal
lifting, go with the static block. Of course, depending on the Servlet
API isn't all bad, so don't count it out unless you really need to.
-W
On 11/9/07, tom` frost <to...@gmail.com> wrote:
> I would still need to use the Servlet API to retrieve those values,
> correct? I'm trying to find a way to pass in values directly to Struts, I
> guess.
>
> On 11/9/00, Martin Gainty <mg...@hotmail.com> wrote:
> >
> > Hi Tom-
> >
> > how about implementing the default initialisation parameters by placing
> > the
> > init-param in web.xml?
> > e.g.
> > <init-param>
> > <param-name>debug</param-name>
> > <param-value>true</param-value>
> > </init-param>
> >
> > M--
> > ----- Original Message -----
> > From: "tom` frost" <to...@gmail.com>
> > To: <us...@struts.apache.org>
> > Sent: Friday, November 09, 2007 12:41 PM
> > Subject: S2 best location of application init params
> >
> >
> > > 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.
> > >
> > > Thanks,
> > > Tom
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
--
Wesley Wannemacher
President, Head Engineer/Consultant
WanTii, Inc.
http://www.wantii.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: S2 best location of application init params
Posted by tom` frost <to...@gmail.com>.
I would still need to use the Servlet API to retrieve those values,
correct? I'm trying to find a way to pass in values directly to Struts, I
guess.
On 11/9/00, Martin Gainty <mg...@hotmail.com> wrote:
>
> Hi Tom-
>
> how about implementing the default initialisation parameters by placing
> the
> init-param in web.xml?
> e.g.
> <init-param>
> <param-name>debug</param-name>
> <param-value>true</param-value>
> </init-param>
>
> M--
> ----- Original Message -----
> From: "tom` frost" <to...@gmail.com>
> To: <us...@struts.apache.org>
> Sent: Friday, November 09, 2007 12:41 PM
> Subject: S2 best location of application init params
>
>
> > 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.
> >
> > Thanks,
> > Tom
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>