[cdi-dev] Alternative producer methods

[Pete Muir]

I think OWB is following the spec correctly, and you would need to redeclare the disposer, which I agree is horrid. However I don't want to reopen the can of worms that is allowing disposers on other classes, as it makes booting CDI much much more complex.

On 1 Apr 2012, at 17:42, Marius Bogoevici wrote:

> I *think* that the expected behaviour in this case should be that the original disposer is disabled and only a disposer defined on the same bean class as the alternative producer should apply.
> 
> If this is a correct interpretation of the intent, it needs to make its way into the spec.
> 
> 
> 
> On 2012-04-01, at 12:06 PM, Mark Struberg wrote:
> 
>> To be more clear what I mean with the @Disposal issue please consider the following class:
>> 
>> public class DefaultBeanProducer
>> {
>>    public static boolean gotDumped = false;
>> 
>>    @Produces @QualifierProducerBased
>>    public IProducedBean generateBean()
>>    {
>>        return new ProducedBean("default", this);
>>    }
>> 
>>    public void dumpBean(@Disposes @QualifierProducerBased IProducedBean bean)
>>    {
>>        gotDumped = true;
>>    }
>> }
>> 
>> 
>> And the following @Alternative:
>> 
>> @Alternative
>> public class AlternativeOnClassAndProducerMethodBean
>> {
>>    @Produces
>>    @Alternative
>>    @QualifierProducerBased
>>    public IProducedBean generateBean2()
>>    {
>>        return new ProducedBean("AlternativeOnClassAndProducerMethodBean", this);
>>    }
>> }
>> 
>> 
>> 
>> In OWB this currently creates the following Exception:
>> WebBeansConfigurationException: Producer method component of the disposal method : dumpBean in class : org.apache.webbeans.newtests.concepts.alternatives.common.DefaultBeanProducer must be in the same class!
>> 
>> This behaviour is exactly as defined in the current spec afaik.
>> But certainly this is not very useful...
>> 
>> wdyt? Did I overlook something?
>> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>> 
>> ----- Original Message -----
>>> From: Mark Struberg <struberg at yahoo.de>
>>> To: cdi-dev <cdi-dev at lists.jboss.org>
>>> Cc: 
>>> Sent: Sunday, April 1, 2012 3:51 PM
>>> Subject: [cdi-dev] Alternative producer methods
>>> 
>>> Dear EG colleagues!
>>> 
>>> 
>>> I have a question about @Alternative on producer methods:
>>> consider the following class:
>>> 
>>> // here is NO alternative annotation!
>>> 
>>> public class AlternativeOnProducerMethodOnlyBean {
>>>   @Produces  @Alternative
>>>   public IProducedBean generateBean2() {..}
>>> }
>>> 
>>> So the class itself is NOT annotated as @Alternative
>>> 
>>> I'm not sure if 5.1.1 allows this or the other way around: if this must be 
>>> supported.
>>> 
>>> Imo the important parts are (from 5.1.1)
>>>> Each child <class> element must specify the name of an alternative 
>>> bean class. 
>>> 
>>>> If there is no class with the specified name, or if the class with the 
>>> specified 
>>> 
>>>> name is not an alternative bean class, the container automatically detects 
>>> 
>>>> the problem and treats it as a deployment problem.
>>> 
>>> The question is now how 'an alternative bean class' is to be interpreted 
>>> ^^
>>> The first paragraph of 5.1.1 says:
>>> 
>>>>  An alternative is selected for the bean archive if either ...
>>>> * the alternative is a producer method, field or resource, and the 
>>> 
>>>> bean class that declares the method or field is listed, ...
>>> 
>>> 
>>> But does this qualify the AlternativeOnProducerMethodOnlyBean as 
>>> 'alternative bean class'?
>>> 
>>> Any ideas?
>>> 
>>> Btw: the whole topic of disposal methods for @Alternative producers are 
>>> completely unspecified...
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev