Uploaded image for project: 'Weld'
  1. Weld
  2. WELD-2304

Unexpected observer resolution of alternative beans selected using @Priority

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Rejected
    • Affects Version/s: 2.3.5.Final, 2.4.1.Final, 3.0.0.Beta1
    • Fix Version/s: None
    • Component/s: Events
    • Labels:
      None

      Description

      When trying to combine observer methods with alternative beans that are selected/enabled using @Priority an unexpected behaviour was identified.

      This unit test exposes this "possible" issue:
      https://github.com/sermojohn/core/commit/ec63f1579652af58b1e01cd141720be906b6d222

      When enabling an alternative bean of some type using a higher @Priority value than another alternative bean of the same type, if both beans define an observer method that can received an event of the same type, only the enabled bean would be expected to receive the fired events. However, both alternative beans receive the event. This restricts modularity because bean defined in a bean archive that defines an observer method cannot be replaced at runtime. When trying to do the exact same thing scenario using alternatives enabled through beans.xml, only the observer of the enabled alternative is triggered.

      If this is not an issue, probably it should be considered as a clarification improvement for CDI specification.

        Attachments

          Activity

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            sermojohn Ioannis Sermetziadis (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: