[
https://issues.apache.org/jira/browse/ISIS-779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Haywood resolved ISIS-779.
------------------------------
Resolution: Not a Problem
Fix Version/s: (was: core-2.0.0)
core-1.8.0
This substantially duplicates ISIS-948, which in the end has the
EventBusService as a singleton. There's a lot of discussion there, I am pretty
confident that ISIS-948 has tackled this issue correctly.
> Refactor EventBusService as a @RequestScoped service, and have it own the
> guava EventBus as a field.
> ----------------------------------------------------------------------------------------------------
>
> Key: ISIS-779
> URL: https://issues.apache.org/jira/browse/ISIS-779
> Project: Isis
> Issue Type: Improvement
> Components: Core
> Affects Versions: core-1.4.0
> Reporter: Dan Haywood
> Assignee: Dan Haywood
> Priority: Minor
> Fix For: core-1.8.0
>
>
> Originally this ticket was raised as a bug to the effect that "EventBus
> should not re-register services on open/close; this is not thread-safe."
> Subsequent analysis shows that isn't actually the case; the current design is
> thread-safe.
> How it works is that, although EventBusServiceDefault is application-scoped,
> the guava EventBus itself is obtained from the PersistenceSession, ie is in
> effect for the session.
> It would however be preferrable to convert EventBusService(Default) into a
> request-scoped, and then having it simply new up the guava EventBus each
> time. The only real issue is the ordering of the service injection; the
> domain services do a reverse callback to the EventBusService in the
> setterXxx() / injectXxx()
> ; there might be ordering issues.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
