struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Hill" <andrew.david.h...@gridnode.com>
Subject RE: [OT] Use of Static Methods
Date Thu, 10 Jul 2003 08:56:34 GMT
<snip>
In the mean time, I suggest you avoid this trap for your application
specific classes, and implement the singleton pattern instead.
</snip>

Having made this mistake a fair few times myself I give this suggestion a
big +1

-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Thursday, 10 July 2003 16:42
To: Struts Users Mailing List
Subject: Re: [OT] Use of Static Methods




On Thu, 10 Jul 2003, Simon Kelly wrote:

> Date: Thu, 10 Jul 2003 09:56:14 +0200
> From: Simon Kelly <kelly@ipe.fzk.de>
> Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> Subject: Re: [OT] Use of Static Methods
>
> I'm gonna get shot down in flames here, but I feel this may be a good way
of
> looking at the differences between static and non-static methods.

A lot of the discussions in this thread have been about philosophy --
let's also take a look at a use case that is more practical to Struts
oriented developers and use that to compare the two approaches.

Many of you will be aware that Struts uses BeanUtils.populate() --
which, in Struts 1.1, references a static method on the BeanUtils class
from version 1.6.1 of BeanUtils -- that performs the copy+convert loop.
It's cool and all that.  One of the many reasons to like Struts :-).

But, more than a few people have complained that the populate()
method throws an exception the first time that it runs into a problem
doing a conversion.  Because the list of request parameters is stored in
something like a Hashtable or HashMap in your servlet container, that
means you have no idea which (if any) conversions were performed
successfully -- you have to throw them away.  What some people would
prefer is the opportunity to do all the conversions that can be done, and
report all the failures in one custom exception at the end of the process.

"That doesn't seem to hard," you might say.  "All I need to do is create a
MyBeanUtils class with a custom copyProperties() method that behaves the
way *I* want it to, and use it instead of the standard one".  In other
words, your application will call MyBeanUtils.populate() instead of
BeanUtils.populate().

But ... how do you convince *Struts* to use your version of
copyProperties() instead of the standard one ... since it requires
modification of all calling programs to use MyBeanUtils.populate()
instead of BeanUtils.populate()?  This is why the language purists in this
thread have been jumping up and down saying that you cannot override a
static method in a manner that is transparent the calling class.
Requiring the caller to switch the class name is generally not an option.

However, if BeanUtils were to provide a way to ask for an instance of some
class that implemented the "bean utils" interface, and also provided a
factory mechanism so that you could plug in your own implementations,
you'd be a happy camper.  You could provide your own custom
implementation, and because Struts would ask the appropriate factory
method for an instance of BeanUtils, it would also use your custom
implementation.

For the specific case of BeanUtils, we are halfway there (using the
singleton pattern) already on the HEAD branch of the CVS repository.  It
turns out that we need to do this so that commons-beanutils can be placed
in a shared class loader in a servlet container (i.e. in the common/lib
directory for Tomcat) but allow each web application to have its own bean
named "foo" with no interference.  What remains to be done is a mechanism
to register your replacement BeanUtilsBean (I'm going to suggest using
commons-discovery for this), but you can count on support for this some
time in the 1.2.x lifecycle.

In the mean time, I suggest you avoid this trap for your application
specific classes, and implement the singleton pattern instead.

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message