Looks pretty well researched.
I hate to pass the buck, but this looks like it falls into OGNL's
space. Back in Tapestry 1 days, there were similar problems (about
not finding accessor methods for properties) that were caused by
multi-threaded access to OGNL and, within OGNL, to
java.beans.Introspector.
On 8/4/05, Andy Maag <[EMAIL PROTECTED]> wrote:
> 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]
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
