[
https://issues.apache.org/jira/browse/ISIS-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Haywood resolved ISIS-1848.
-------------------------------
Resolution: Fixed
> References of type java.lang.Object (sometimes) not rendered correctly in
> Wicket viewer
> ---------------------------------------------------------------------------------------
>
> Key: ISIS-1848
> URL: https://issues.apache.org/jira/browse/ISIS-1848
> Project: Isis
> Issue Type: Bug
> Affects Versions: 1.15.1
> Reporter: Dan Haywood
> Assignee: Dan Haywood
> Priority: Major
> Fix For: 1.16.1
>
>
> This is down to a race condition, I think.
> At any rate, the ObjectSpecificationOnStandaloneList for FreeStandingList
> (the internal pojo that holds the result of an action invocation) is asked
> for its ObjectSpecId. It tries to do this by asking for the value of the
> corresponding ObjectSpecIfFacet.
> However, no such facet (in some circumstances, presumably) is installed for
> this ObjectSpec, and so it searches up the hierarchy. The superclass is
> java.lang.Object, and so we return the ObjectSpecId for java.lang.Object.
> This in turn causes the cache of ObjectSpecId -> ObjectSpecification's to be
> corrupted, with java.lang.Object mapping to the list.
> In the Wicket viewer, when attempting to render a reference property of type
> java.lang.Object (such as the Task_object mixin for Estatio), the
> SpecificationLoader reports that a reference of this type is not isObject()
> (because it's using ObjectSpecificationOnStandaloneList), resulting in an
> UnknownPanel being selected to render the Wicket model for the reference
> property. This simply shows a toString().
> The fix, I think, is to not search up the hierarchy in the case of
> ObjectSpecIdFacet... an ObjectSpecification must be able to answer this
> question itself.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
