> It seems like you're over engineering something that is > simple... what problem are you trying to solve with this?
I want to be able to do alot of the mundane setup stuff that happens in every action method without having to think aboout it. Rather than having every method create and destroy a Persistence object, I'd have an execute() method that created it, called super.execute() and destroyed it. The problem is getting this thing into the scope of the "real" Action method. A class level protected variable to store the persistence object seemed the best option, but it's not safe as it gets shared by every call into the class. I could make the Persistence Object itself a ThreadLocal, but then I've changed the creation step for a conversion step inside of the Action method. Delegates have a footprint alteration to the current Action methods. *That* seemed to me like over-engineering for this problem. But If the Persistence class itself *is* threadsafe, then I shouldnt have an issue, I figure if the Actions share them. Nothing but static public methods and static ThreadLocal class variables. I really only need one or two class level variables, and making them ThreadLocal isn't as gross of a change for me. I'm just hoping a hole gets popped into the theory before rather than after implementation... -Joe
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
