You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Andy Maag <an...@gmail.com> on 2005/08/04 20:53:19 UTC
Potential Bug in Tapestry 3? - OGNL static field expressions sporadically returning null
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Potential Bug in Tapestry 3? - OGNL static field expressions sporadically returning null
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <an...@gmail.com> 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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org