[
https://issues.apache.org/jira/browse/TAP5-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045762#comment-14045762
]
Lance commented on TAP5-1493:
-----------------------------
I just added some better logging since this doesn't occur on my machine
{code}
java.lang.AssertionError: expected:<class
org.apache.tapestry5.internal.services.PropertyConduitSourceImplTest$AbstractBar>
but was:<class
org.apache.tapestry5.internal.services.PropertyConduitSourceImplTest$Bar>
(possible candidates [public
org.apache.tapestry5.internal.services.PropertyConduitSourceImplTest$Bar
org.apache.tapestry5.internal.services.PropertyConduitSourceImplTest$Foo.getBar(),
public
org.apache.tapestry5.internal.services.PropertyConduitSourceImplTest$AbstractBar
org.apache.tapestry5.internal.services.PropertyConduitSourceImplTest$Foo.getBar()])
{code}
As you can (hopefully) see... there are two getBar() methods on Foo.class...
I'm guessing one is volatile and the other is not. I'm guessing
Method.getDeclaringClass() will also distinguish one from the other.
Hopefully you can see a fix now that we have this info. I'll leave it in your
capable hands ;)
Cheers,
Lance.
> Property expressions on properties that are covariant on a base class use the
> type of the base class property, not the covariant subclass
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TAP5-1493
> URL: https://issues.apache.org/jira/browse/TAP5-1493
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core, tapestry-ioc
> Affects Versions: 5.2
> Reporter: Howard M. Lewis Ship
> Priority: Critical
> Labels: month-of-tapestry
> Fix For: 5.4
>
>
> public abstract class AbstractFoo
> {
> public abstract AbstractBar getBar();
> }
> public class Foo extends AbstractFoo
> {
> public Bar getBar();
> }
> Here property bar is covariant; the subclass (Foo) changes the type of the
> return value (from AbstractBar to just Bar). Assuming that Bar is a subclass
> of AbstractBar, that's fine.
> The bug is that in this circumstance, the PropertyConduitSource sees the type
> of
> property "bar" of class Foo as AbstractBar, not Bar.
> Interestingly, a little debugging showed that the getter method for property
> bar was "public AbstractBar Foo.getBar()" ... in other words, much like with
> Generics, covariant return types may be largely
> a fiction of the compiler inserting the necessary casts in place.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
