[CAUSEWAY-779] Refactor EventBusService as a @RequestScoped service, and have it own the guava EventBus as a field.

• Type: Improvement
• Status: Closed
• Priority: Minor
• Resolution: Not A Problem
• Affects Version/s: core-1.4.0
• Fix Version/s: core-1.8.0
• Component/s: Core
• Assignee: Unassigned
• Reporter: Daniel Keir Haywood
• Created: 11/May/14 17:48
• Updated: 23/Feb/15 22:15
• Resolved: 17/Dec/14 00:46

Description

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.

Issue Links

• duplicates: CAUSEWAY-948 Fix concurrent exception in EventBus, improve support for request-scoped services