Looks like an oversight to me ... using equals() would make more sense
to me as well. It is intended primarily for Hibernate entities, but
equals() works there as well, as Hibernate ensures that primary key
identity is the same as object identity with a context.
Perhaps Dan can shed some light? @Cached was written by Dan Adams.
On Mon, Dec 22, 2008 at 4:44 PM, Doug Hauge <doug.ha...@lithium.com> wrote:
> I'm trying to use the '@Cached' annotation with a watch expression
> to cache results of methods in a form contained within a loop. For
> some watch expressions, I construct a string, so the code basically
> looks like
>
> @Cached(watch="watchKey")
> Object getData() {
> // return data;
> }
>
> String getWatchKey() {
> return a.toString() + ":" + b.toString();
> }
>
> When I do this, though, the cached annotation does not seem to work
> properly, in that the 'getData()' method is called multiple times
> in a request. The problem seems to be that '==' is used instead of
> 'equals' in the code 'CachedWorker' generates to compare the result
> of the watch expression. Is this intentional, so we need to make sure
> the watch expression returns the exact same object if we want to use
> a cached value? Or should it be changed to use 'equals'?
>
> Doug
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
