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

Sterotyped @Alternative with @Priority not working properly

    XMLWordPrintable

Details

    • Bug
    • Resolution: Won't Do
    • Minor
    • None
    • 2.3.x
    • Java SE Support
    • None

    Description

      HI,

      I am currently upgrading multiple libraries from JEE 6 standard to JEE 7 standard.
      This includes upgrading CDI 1.0 to CDI 1.1.

      The weld version I am using is the one that comes bundled in weblogic 12.2.1.2.
      Weld 2.3.2.Final.

      For some integration tests, that use weld-se-core, we need to disable producers that would work in the container under normal circumstances. One common example is if the producer that runs in the container reads the JNDI environment.

      While investigating some tests that fail, I have noticed that the @Priority annotation is not effective when bundled inside of a stereotype.

      Productive code pattern

      pulic class BusinessLogic{

      @Inject
      @WhateverFolderQualifier
      String whateverFolderPath;
      }

      The above business logic CDI bean would be injected the string through a producer that does a JNDI lookup.

      public class WhateverFolderPathProcuder{

      @Produces
      @WhateverFolderQualifier
      public String whateverFolderPathProcuder(InjectionPoint ip){
      return someJndiLookupThattWilFailOutsideOfTheCOntianer;
      }
      }

      Integration tests want to override container behavior

      When we want to test the business logic component, we want that string field injected with some unit test mock string coming from a test producer alternative.

      In short, we want to pretend that the default producer does not exist.
      When in my src/test/java I have something I write a producer like this:

      @Alternative
      @Prioiry(Test)
      public class WhateverFolderPathTestProcuder{
      @Produces
      @WhateverFolderQualifier
      public String whateverFolderPathProcuder(InjectionPoint ip){
      return someJndiLookupThattWilFailOutsideOfTheCOntianer;
      }
      }

      And in addition the beans.xml the:
      <alternatives><class>WhateverFolderPathTestProcuder</class><alternatives>

      is declared.
      Everything works fine.

      However, the original code that stopped working used to make use of a "Test" steortype.
      So that the @Alternative annotation would be hidden in a sterotype as e.g. @TestAlternative.

      This @TestAlternative stereotype now was augmented to contain as well the @Priority annotation within it.
      I believe there isn a single case where I do not want an alternative to be globally applied. So if a class is an alternative 99.9% of the time it will have a priority. And in this case the priority was going into the stereotype.

      The hope was that this steortype could both:
      (a) flag an alternative as being a test alternative which can be quickly identified by doing a source code search to see where the pattern is being applied
      (b) make the test alternative injectable into the src/main/java BeanArchive logic of any component.

      The behavior of weld when the @Priority annotation is in the TestAlternative stereotype is exactly as if it were not there.

      This means taht:
      (a) my sterotyped TestProducer will be used to inject the dummy String into code written in src/test/java that needs this configuration value
      (b) but the code in src/main/java BeanArchieve continues using the real producer for the CDI container.

      Therefore, for now, as a work-around, I:
      (a) continue using the sterotype to only get the @Alternative annotation into the test producer.
      (b) duplicate the @Prioity annotation in the stereotype directly into the test producer, to make sure that the priority annotation is effective not just in srct/test/java but also in src/main/java.

      This is a tiny bug with a work-around.
      It is just to make you aware of the sitatuion.

      Many thanks.

      Kind regards.

      Attachments

        Activity

          People

            Unassigned Unassigned
            nuno.godinhomatos NUNO GODINHO DE MATOS (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: