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

Different BeanManager for the same context across redeployments

XMLWordPrintable

    • Hide

      The following repo contains an ear triggering the issue when deployed on a payara 5.182 full server: https://github.com/cghislai/plancul-back

      • compile with maven
      • deploy on a payara server (should deploy just fine with the default resources)
      • send a request on the /plancul-ws endpoint to trigger authentication
      • 9 times out of 10, the server throws WELD-001334: Unsatisfied dependencies for type HttpAuthenticationMechanism with qualifiers
      Show
      The following repo contains an ear triggering the issue when deployed on a payara 5.182 full server: https://github.com/cghislai/plancul-back compile with maven deploy on a payara server (should deploy just fine with the default resources) send a request on the /plancul-ws endpoint to trigger authentication 9 times out of 10, the server throws WELD-001334: Unsatisfied dependencies for type HttpAuthenticationMechanism with qualifiers

      I have an ear deployment containing an extracted war, an extracted ejb and shared librairies under lib/. In the war I have an implementation of an HttpAuthenticationMechanism that is looked up by soteria using the following construct:

      CDI.current().select(HttpAuthenticationMechanism.class).get()

      I noticed that the BeanManager instance returned by `CDI.current().getBeanManager()` is not consistent across redeployments, returning sometimes the bean manager of the war module, sometimes one of the ejb module, and sometimes one of a jar library, randomly. This prevents the above class to be resolved correctly.

      On the other hand, performing a JNDI lookpup to resolve the BeanManager at that point would systematically return that of the war, allowing the HttpAuthenticationMechanism instance to be resolved.

      This issue is also tracked on the soteria side there: https://github.com/eclipse-ee4j/soteria/issues/200.

              Unassigned Unassigned
              cghislai charles ghislain (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: