[weld-issues] [JBoss JIRA] (WELD-2275) Sterotyped @Alternavei with @Priority not working properly

[Nuno Godinho de Matos (JIRA)]

Title: Message Title

Nuno Godinho de Matos updated an issue   Weld / WELD-2275 Sterotyped @Alternavei with @Priority not working properly Change By: Nuno Godinho de Matos 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 , this means . Weld   2.3.2.Final. For some integration tests, that use weld-se-core container , we need to disable producers that would work in the container under normal circumstances. Because they depend on contianer resources, such as 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. h1. 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; } } * h1. 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 . So In short, we want to get weld to ignore pretend that the default producer does not exist . So When in my src/test/java I would have somehting like 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 will have the : <alternatives><class>WhateverFolderPathTestProcuder</class><alternatives> Declared. So if the code is written exactly as above declared . My produtive business logic gets injected with the Alternative without a problem Everything works fine . It is as if the producer for production environment is dead. Which is just as I want it to be. However, the original code that stopped working used to make use of a "Test" steortype. So that the @Alternative qualifier, annotation would normally be called hidden in a : sterotype as e.g. @TestAlternative. This @TestAlternative sterotype stereotype now was augmented to contain as well the @Priority annotation within it. In 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 can 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) made make the test alternative globaly available injectable into the src/main/java BeanArchive logic of any component . The behavior of weld when the @Priority annotation is in the TestAlternative   sterotype   stereotype is exactly as if it were not there. That This means , taht: (a) my sterotyped TestProducer will be used to inject the dummy String into code written in src/test/java that want the string. needs this configuration value But (b) but the code in src/main/java   cotinues BeanArchieve  continues using the real producer for the CDI container. As Therefore, for now, as a work-around, I countinue : (a) continue using the steotype sterotype to only get the @Alternative annotation into the test producer. And I (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 of course a tiny bug of minimal priority. There is with a work - around for this . It is just to make you aware of the sitatuion. Many thanks for taking a look . Kind regards. Add Comment   This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)

_______________________________________________
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues