[
https://issues.apache.org/jira/browse/ISIS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14379467#comment-14379467
]
Dan Haywood commented on ISIS-1045:
-----------------------------------
The issue with Guava event bus queueing events has been tackled in ISIS-1028.
Because it isn't possible to change guava's behaviour, we now also support the
Axon Simple Event Bus (implemented in that ticket).
As for this ticket, pertaining to the use of a threadlocal as a mechanism for
passing an event between different phases, we've decided to get rid of the
threadlocal and just reuse the same event from EXECUTING to EXECUTED. If there
is a requirement to pass information from validating to executing, then use
QueryResultsCache or the Scratchpad services.
> New domain events are created for each phase for properties, but not for
> collections nor actions. The current design doesn't support use of the
> wrapper factory.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISIS-1045
> URL: https://issues.apache.org/jira/browse/ISIS-1045
> Project: Isis
> Issue Type: Improvement
> Components: Core
> Affects Versions: core-1.7.0
> Reporter: Dan Haywood
> Assignee: Dan Haywood
> Priority: Minor
> Fix For: 1.9.0
>
>
> In the domain events design we have 5 phases:
> hide/disable/validate/pre-execute/post-execute. The framework attempts to
> reuse the same event where possible
> for actions:
> - for hide, always creates new event
> - for disable, always creates new event
> - for validate, always creates new event, puts onto thread-local
> - for pre-execute, uses the event from validate (obtain from thread-local)
> - for post-execute, uses the event from pre-execute (passed as local var).
> for collections:
> - ditto
> but for properties, although we originally had the same algorithm, this was
> changed (patch from Oscar) to:
> - for hide, always creates new event
> - for disable, always creates new event
> - for validate, always creates new event, puts onto thread-local
> - for pre-execute, always creates a new event (ignores that on thread-local)
> - for post-execute, uses the event from pre-execute (passed as local var).
> The reason that Oscar needed this change was because the framework does not
> anticipate there being more than one "pending" interaction. However, if the
> wrapper factory is used, then this assumption isn't true, because validateX()
> -> wrap -> validateY().
> This use case actually needs a stack of pending interaction events to support
> this change.
> As things stand:
> * the getUserData() functionality is broken for property domain events
> * the underlying problem remains for actions -> actions using the wrapper
> factory during the validate phase.
> There is also a suggestion that the Guava event bus might be an issue in that
> it buffers changes; I'm not exactly sure what this means (we don't use the
> async guava bus), and I don't know if its behaviour is significant or not.
> But in any case, the above design defect is an issue irrespective and which
> needs addressing; once that's fixed then we can look at the Guava event bus
> to decide if it is also a problem for us or not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
