I posted a question a few weeks back regarding sporadic disappearance
of "in" parameters (see below).
After following Kent's advice to do some logging, the common theme to
the unexpected null parameters is that they are OGNL static field
references.
In my web tests (built on JWebUnit), I've done logging of the form:
protected void prepareForRender(IRequestCycle cycle) {
LOGGER.debug("BEGIN prepareForRender " +
System.identityHashCode(this) + " " + getExtendedId());
super.prepareForRender(cycle);
LOGGER.debug("Restart: " +
((ServiceLink)getComponent("linkRestart")).getService());
LOGGER.debug("Reset: " +
((ServiceLink)getComponent("linkReset")).getService());
LOGGER.debug("END prepareForRender " +
System.identityHashCode(this) + " " + getExtendedId());
}
The logging shows that when several instances of a control/page are
initialized simultaneously, some of the static values occasionally are
initialized to null (generally isolated to one of the instances being
initialized). Because the ParameterManager treats those values as
invariant, the value for the parameter will never be re-evaluated, and
every request that is serviced by that page/component will always use
null for the parameter value.
Has anyone else stumbled across this, or similar problems? As
promised, Tapestry is not allowing two concurrent threads to a single
page/component instance. However, I'm still seeing inconsistent
behavior under concurrent access, possibly due to an underlying OGNL
bug (or Tapestry not using OGNL in a thread-safe manner).
As always, any brilliant advice is appreciated =).
-Andy
Andy Maag <andy.maag <at> gmail.com> writes:
> The simplest manifestation of this problem is with the ServiceLink
> component. Occasionally, we will see an error such as the one at the
> bottom of this email. From my perusal of the Tapestry 3.0.3 source
> code, this condition could only be reached if "null" were passed in as
> the "service" parameter to the ServiceLink component. However, every
> one of our ServiceLink instances uses one of the Tapestry constants
> (i.e. <at> org.apache.tapestry.Tapestry <at> RESTART_SERVICE) for the service
> parameter.
>
> Have others seen issues with parameters not being connected properly?
> We had seen one or two cases in our application code that were fixed
> by changing the parameter to "auto".
I'd guess that this is caused by concurrent accesses to the same page
instance. After the component is rendered, its parameters are reset
to their default value (null in most cases). If they're now accessed,
they'll return null. To verify, try overriding prepareForRender()
and cleanupAfterRender() to perform some logging.
However, in theory, each thread should get its own page instance, so
this could never happen.
--
Author of an e-Book for learning Tapestry (http://www.agileskills2.org/EWDT)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
