Hi,
Michael Müller wrote:
additionally, there's a problem/bug with performParentAction() in
WOComponent: before the actual parentAction gets called via
parent.valueForKey(action), WOF calls pushValuesToParent(). In case
of stateless components this method also prematurely resets the
_flag is a state !
public boolean flag() {
Boolean _flag;
if(_flag == null) {
// Initialize _flag to a Boolean instance: it can't be
set to null
[...]
}
I've hit the send button to early. The special thing about a
stateless component is that only one instance of the component is
used. With concurrent request handling it's very likely that a reset
and valueForKey are called at eh same time.
Uli
Am 07.12.2006 um 16:25 schrieb Ulrich
A stateless component should be locked to one request/response loop
and thus thread at a given time. No two things should happen
concurrently.
If the stateless component is needed by another thread, a new copy
will be created.
I have had a similar problem that I traced back to having my
-Original Message-
From: Pierre Bernard [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 07, 2006 4:49 PM
To: Ulrich Köster; Francis Labrie
Cc: WebObjects Development
Subject: Re: Bug in stateless WOComponent management?
A stateless component should be locked to one request/response loop
On Dec 7, 2006, at 7:49 AM, Pierre Bernard wrote:
A stateless component should be locked to one request/response loop
and thus thread at a given time. No two things should happen
concurrently.
If the stateless component is needed by another thread, a new copy
will be created.
I have
Recursive stateless components should work just fine, I use them all
the time. In the stateless side, each time it needs an instance of
the component if there isn't an instance available to service the
need, it will create a new instance for the pool. Its possible that
1 instance will
