Should methods in a business-logic class called from a Struts Action always be static methods?
No. In fact, generally, they shouldn't be static.
One important thing to understand about Struts is that it does not provide a lot of help or guidelines for writing the model or business logic part of your application. You are therefore free to use whatever classes and whatever patterns your heart desires and they will work just fine within the Struts framework.
The business-logic methods generally shouldn't be static mainly because, if the same business logic is used in more than one action, than both threads can't access it at the same time correct?
Joined: Feb 15, 2005
No, the fact that Actions are multithreaded is not the reason your business logic methods should not usually be static. Multiple threads can safely execute a static method, provided it's coded as "thread safe".
The main reason for not making frequent use of static methods is that static methods defeat the purpose of object-oriented programming and design. You want to design your business logic with objects that represent real objects in your business domain and you want to define the behavior of those objects in non-static methods. If all you're doing is calling a bunch of static methods from your Action class, you're not writing object-oriented code. You're writing procedural code. You might as well be writing it in COBOL as Java.
This is one of the jabs at Enterprise JavaBeans. We are told that statefull EJBs are to heavy weight and that they do not scale well. So we switch over to stateless EJBs which feel a lot like static methods.
What technology are you using for your business tier and data layer?
I am also a little curious about your statement "I'd like to use the adapter pattern"...what is the reason?