Holger, I'm a bit confused by your explanations, notably about the method isPropertySet(Object helperObject). What property is it supposed to test? I'd be tempted to write/understand it as: isPropertySet(Object object, String propertyName), implying reflection is used for getting accessing the property. I suppose also you would base you logic on the fact that a property is set when it is null. However sometimes a null value is a valid value, which is not the same as having no value set (we had to do such distinction in some cases). In any case, the way to decouple your business objects from the struts stuff is usually done via intermediate objects which are typically called value objects or command objects. These objects are part of the interface to your business logic and are not dependent on Struts. In this approach, the Action typically create those value/command objects and populate them using the data from the ActionForm object. I have tried to automate this process in a separate mapper framework (pre-release available on Ted Husted's site) so that custom coding is removed as much as possible. Finally, to answer your question about static method, building up on David's answer: make sure that all the required state information for the request to process is passed as parameters, so that you method only accesses these parameters. Fr. -----Original Message----- From: David Winterfeldt [mailto:[EMAIL PROTECTED]] Sent: 16 July 2001 21:22 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Java-related question: thread safe ActionClasses If you call a static method that doesn't access any external variables that are maintaining state, it will be safe to call from a thread. Just like the perform method in your Action class should be thread safe since it can be used by multiple threads. The general consensus is that it is good to separate your business logic from being aware of the web layer. David --- Holger Wiechert <[EMAIL PROTECTED]> wrote: > Hi, > > I've got a question about an issue to the thread > safe execution. > The whole setup was made in order to have a business > logic triggered by > struts, that still can retrieve information from its > environment -- here Struts -- without > having explicit knowledge of it. In short, the > processing is like this: > > a) the ActionObject gets the business object > b) calls the business method on the business object > including > -the HttpServletRequest just received in the perform > call, and > -a reference to itself > c) the business object now uses this reference to > retrieve from this object > some information about the business objects > environment. Thus, the business object > calls the ActionObject (without knowing, that it > is a struts Action) and hands in > the HttpServletRequest (as an java.lang.Object). > d) the ActionObject uses the HttpServletRequest to > get the desired information > (like request.getParameter()) and returns the > result back to the business object. > > Basically, I want to know, if I can use a static > method (no static fields) within the ActionObject > for performing the environment lookup thread safe. > > Sounds a little complicated, doesn't it? Well, to > those who have the time to get involved. > It's actually not that difficult. > > The class structure in my struts app is like the > following: > > -Class MyActionClass: extends ...struts.Action > implements myClasses.Environment > > -Interface myClasses.Environment has (let's say) > just one method: > public boolean isPropertySet(Object helperObject) > > -Class DoSomeStuffRq is a class that contains > a)translated form data, and > b) an java.lang.Object reference to store the > HttpServletRequest > (which the MyActionObject just has recieved in its > perform method). > > -Class MyBusinessClass: > doSomeBusinessStuff(DoSomeStuffRq stuffInfo, > Environment env) > > The Environment interface is there in order to > decouple Struts from the business logic - giving > the chance to reuse the MyBusinessClass when not > using Struts anymore (well, I hope I don't have to, > but still). > > So finer grained, the actions are: > > 1) Let the MyActionClass get the businessObject (of > type MyBusinessClass), > 2) MyActionClass calls the method > businessObject.doSomeBusinessStuff(stuffInfo, this); > > ["this" is of type Environment] > > 3) in order to process the business actions, the > BusinessObject has to > retrieve a boolean value from it's (unknown) > environment. So it calls > the isPropertySet from the Environment interface > (which has the MyActionClass implementation): > > public StuffResponse > doSomeBusinessStuff(DoSomeStuffRq stuffInfo, > Environment env) > { > boolean importantProperty = > environment.isPropertySet(stuffInfo.getObjectReference()); > ... > } > > where stuffInfo.getObjectReference() gives the above > mentioned HttpServletRequest reference as a > java.lang.Object. > > 4) the rest is quite obvious: myActionObject does a > cast of the java.lang.Object to the > HttpServletRequest > and gets a request parameter. Then, it returns a > boolean value depending on that request parameter. > > Well, there's lots to argue about in the whole > scenario. > Questions like: does it make sense to do all that > stuff to decouple business logic and Struts; is > there > a better way of passing the parameters between the > objects, shall the MyActionClass handle the lookup, > when all I need is a HttpServletRequest and so on. > But the simple question I'm interested in is: Can I > have the MyActionClass' method > public boolean isPropertySet(Object helperObject) > being static? > > I think, I can, because: > As long as I don't use any class members in the > MyActionClass, the thread safety shall be > given -- no matter if the method is static or not. > Is that true? > Well it's more a java related question, but I think > there are some people here, who are interested > in this issue too. > > Thanks in advance for your time, > Holger > > > __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ ************************************************************************ The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com ***********************************************************************
