On Thu, 31 Mar 2005 01:07:14 +0200, Leon Rosenberg
<[EMAIL PROTECTED]> wrote:
> > I would first say that you probably want to think about
> > refactoring your design.
>
> I think this is always true :-)
We have a rule about when refactoring is advisable. Usually it is
not. However, in this ca
I had a few thoughts on this one that are not directly related to your
question but which impact what you are doing.
A.
What the heck is ActionB b = new ActionB() doing in there? Why not
Action b = new ActionB()?
B.
If you were relying on only one instance of an Action being available,
why
Well, the bottom line is you got a solution, and in the end that's all
that matters :)
Leon Rosenberg wrote:
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
> 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 objec
> 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 objec
TED]
> Gesendet: Donnerstag, 31. März 2005 00:45
> An: Struts Users Mailing List
> Betreff: Re: How to protect an action from the "user"
>
> Leon Rosenberg wrote:
>
> >The question is now, how can I ensure, that an action is actually
> >created once, and from
TED]
> Gesendet: Donnerstag, 31. März 2005 00:45
> An: Struts Users Mailing List
> Betreff: Re: How to protect an action from the "user"
>
> Leon Rosenberg wrote:
>
> >The question is now, how can I ensure, that an action is actually
> >created once, and from
Whoops, too quick on the trigger.
You'd want to look at Action.processActionCreate to implement my
somewhat... suspect solution outlined below.
It's easy and fun; we did a processRoles override for doing our own
role-based action access; really nothing to it. It's nice all that stuff
is abstrac
Hi Leon,
I would first say that you probably want to think about refactoring your
design. 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)
Leon Rosenberg wrote:
The question is now, how can I ensure, that an action is actually created
once, and from proper "caller" without changing 500 existing action classes.
The only thing I could imagine, would be introducing a test mode, and if
running in test mode, throw an exception in the BaseA
Hi,
I have following problem. Recently in code review we found some places,
where one very young and very inexperienced developer was directly
instantiating an action:
in execute of ActionA:
...
ActionB b = new ActionB();
b.callSomeMethod();
...
Unfortunately ActionB was getting some resources
Hi,
I have following problem. Recently in code review we found some places,
where one very young and very inexperienced developer was directly
instantiating an action:
in execute of ActionA:
...
ActionB b = new ActionB();
b.callSomeMethod();
...
Unfortunately ActionB was getting some resources
12 matches
Mail list logo