<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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: Struts Users Mailing List <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
