-
1. Re: Alternative and @Produces question
gavin.king Mar 1, 2010 5:19 PM (in response to wujek)Hrm, actually this is sort of a hole in the spec. What you would really like to do is:
<alternatives> <method>package.FooProvider.produceFooAlternative</method> </alternatives>
But we don't yet support that. So indeed @Alternative at the method level is not very useful. We should probably go ahead and add <method> in the maintenance release.
In the meantime, use an @Alternative stereotype for your usecase.
-
2. Re: Alternative and @Produces question
koichik0818 Mar 1, 2010 5:24 PM (in response to wujek)If TestFooProvider is an alternative class, you must write
@Alternative public class TestFooProvider {...}
This may be different from your intention.
You shoud use stereotype for producer methods or fields.@Stereotype @Alternative @Target( { TYPE, METHOD, FIELD }) @Retention(RUNTIME) public @interface MyAlternative { } public class FooProvider { ... @Produces @MyAlternative public Foo produceFooAlternative() { return new TestFoo("<<< creating test >>>"); } } <beans> <alternatives> <stereotype>MyAlternative</stereotype> </alternatives> </bean>
-
3. Re: Alternative and @Produces question
wujek Mar 1, 2010 11:44 PM (in response to wujek)Hi. Thank you both for your answers.
@Gavin: the <method> element sounds nice.
I created Testalternative stereotype, as hinted by Gavin and Koichi, and it is annotated @Alternative. now I can have two methods, one 'standard', and the other one 'alternative', in one bean class, and it works fine.
Can you please explain why alternative stereotype works, and plain @Alternative does not? What is the difference in semantics? This particular stereotype doesn't add any value above the @Alternative (except that it makes my case work fine ;d), so it looks like a kind of a workaround, which could be easily avoided - since CDI / Weld is able to process @Alternative on a stereotype, I guess it could do as well for plain @Alternative? I say I guess as I don't know the code and maybe (probably) there is a reason that one works and the other does not. The only thing that comes to my mind is the sentence from the specs that I quoted before, which says that an alternative producer must have its class annotated @Alternative. Would this be dropped in the maintanance release if support for <method> is added?
Anyways, thanks for the help with this question.
Best regards,
Wujek -
4. Re: Alternative and @Produces question
koichik0818 Mar 2, 2010 10:39 AM (in response to wujek)Because FooProvider 'Class' is not specified an @Alternative, you can not list the class into <class> element in beans.xml. See P.39 in CDI spec:
Each child <class> element must specify the name of an alternative bean class.Also, because produceFooAlternative() 'Method' is not a class, you can not list the method into <class> element in beans.xml.
-
5. Re: Alternative and @Produces question
wujek Mar 2, 2010 11:12 AM (in response to wujek)Hi.
Thank you for your time and answers.
I understand the difference between class / method, and I understand the cause of the error.
The question was more conceptual, like: why does a provider method / field not support @Alternative and requires it to be placed on the class (making the whole class an alternative, which is quite a different thing) while the definition of this annotation says that it may be placed on a method / field, and at the same time, a stereotype which has @Alternative works just fine when put on a producer, as described by both of you, and proved to fix this for me?
Why is the restriction in 5.1.1 made that for a producer field / method to be an enabled alternative using plain @Alternative, the @Alternative must be placed on the class that defines the producer, whereas an alternative stereotype on a method / field works just fine? As I said in my previous post, a stereotype that is created only with @Alternative to be used on producers (just the thing you suggested and works perfect) looks like a redefinition of the exactly same concept as plain @Alternative is for, except for this use case of course.
It seems to me that stereotypes actually have much finer granularity than @Alternative (per method / field vs per class), and the new <method> element in maintenance would fix this little inconsistency.
The reason why I inquire this is that we decided to lean on CDI heavily in our new project, and I am a strong believer that I need to understand the technology well to use it correctly and produce anything of good quality. This particular use case (@Produces @Alternative) is something I stumbled upon, and I wanted to make sure that I do understand whay this works and that doesn't.
Best regards,
Wujek -
6. Re: Alternative and @Produces question
rzd Feb 5, 2013 4:54 AM (in response to gavin.king)This makes annotating producer methods and fields as alternatives pretty useless, doesn't it? I haven't found an issue in JIRA, should I create one?