Thanx Jason for answering.
I saw and i do agree with your design.
I have another question.
Do you think that there are performance implications?
Actions are reused in multithreading.
But since in java all objects go into the heap
it would no difference between using instance vars and local-method vars.
I mean, do you think that there are performance differences between:
1. Subclassing Strut's Action, then calling from it's execute method another
execute on a new object as to be thread safe.
ie:
execute (ActionMapping mapping, ActionF ..){
/*
MyPersonalThreadSafeAction can use all the instance members he wants since
this instance will be re-created for a new thread.
*/
new MyPersonalThreadSafeAction(mapping, forward,...).execute();
}
2. Subclassing Strut's Action but this time using other methods but passing
all the args everytime.
ie:
CustomAction extends Action;
+ execute(arg1,arg2,...)
- privateHandler1(arg1,arg2,...)) //all private handlers can't use instance
members since they are on concurrent access.
- privateHandler2(arg1,arg2,...))
flow-> execute->privateHandler1->privateHandler2 ...
What do you think about it?
I guess the only diff between instance members and local method vars is in
that instance members
can reuse memory space because of the static allocation.
ie: private MyObject myInstance;
Maybe the first case is better because of using instance members.
The problem is that i have to create at least two classes one for the
subclassing of the default Action class
and another for calling the right object, all of that beacuse of Struts
mappings need the class name.
The first class is a kind of wrapper.
Example:
--Mapping:
action type="com.CreateUserAction"
--the class:
public class CreateUserAction extends Action{
...
execute(..){
new MyCreateUserAction().execute();
}
--and the class:
class MyCreateUserAction{
private Object myThreadSafeInstance;
execute(..){
do what i want.
Thnx for your time!
"Jason Miller" <[EMAIL PROTECTED]> ha scritto nel messaggio
news:[EMAIL PROTECTED]
> I have a similar hierarchy, with a base action providing generic
> services like VO manipulation, security methods, exception manipulation,
> and framework interaction, and in general I pass everything as
> parameters. This is mitigated by the fact that the action classes
> simply adapt the input to the backend, the pass everything off. In
> other words, the actions don't really do much aside from act as a glue
> layer.
>
> This is really a combination of both concepts you've listed. The local
> methods provide the generic action services, and the processing for the
> request is actually done by handing everything off to other objects,
> which handle their own synchronization issues.
>
> I would say you're on the right track.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
