> I would first say that you probably want to think about > refactoring your design.
I think this is always true :-) > Actions are designed to be a > per-request handling mechanism, so anything that is creating > persistent objects, or as a result of the function creates > persistent objects (like a ThreadPool as you mentioned), > isn't really appropriate in an Action. Well in this case the action was instantiated a business object reference (like ejb remote) for later invocation of business methods in execute. I mean, I have to do it somewhere and it is tied to an Action, so the constructor seemed to be the appropriate location for it. However, our current CORBA implementation (JacORB) actually associates a separate connection with every remote instance (which is very ugly btw), so we started to move all (but not all yet :-)) remote references to the base action as private static variables with protected accesser to it. > > The idea of instantiating an Action in another and calling > methods on it, even if calling execute() itself, is not > inherently a bad thing. In fact, it's one fairly elegant > solution to the "setup Actions" problem (i.e., you do an > Action and then need to do some setup for the next screen... > do you forward to an Action that just does screen setup? > This is a good place to think about instantiating that > "setup" Action and calling execute() on it yourself). The > fact that this causes problems in your particular case > indicates you may not have a good separation of responsibilities. Hmm, I think this is something better solved by inheritance? I mean instantiating an action is like instantiating a servlet, since an action is a method extracted from the servlet (you know the dark ages, before struts), and instantiating a servlet was never a good idea, because they are managed by the container... and so should actions, shouldn't they? > > I suppose there are some vaguely hackey ways you could stop > the Action from being instantiated by anything other than > Struts, but I would frankly look at solving this from a > design perspective instead. Already done :-) Leon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
