I would propose the following rules:
1. If name and class is specified at the same time, the name wins
2. If a class is specified, and multiple deployments of the same EJB exist, you will get an error like "Ambiguous Dependency Error"
3. For both cases: the ordering of classes or names specifies the order of startup-dependencies
My main use case is pragmatic: auto-completion in the IDE :-)
On 09.11.2011, at 03:05, Marina Vatkina wrote:
> (moving discussion to the appropriate alias)
>
> David,
>
> @DependsOn defines the order in addition to the dependency. Annotation on the @EJB doesn't allow that. Also, you might want to depend on a bean and do not need to inject it...
>
> Adam,
>
> How would you define the rules about the classes vs. the names? Can both be specified at the same time? If yes, will the combination of classes and names be used? How would they be ordered in that case?
>
> thanks,
> -marina
>
> David Blevins wrote:
>> I wonder if we did @DependsOn wrong. Wrong-ish anyway.
>>
>> You can have a reference to something and not need @DependsOn. It's only when you intend to use it in your @PostConstruct that the @DependsOn is required. Quite often it ends up looking like this:
>>
>> @Singelton
>> @DependsOn({"red", "green"})
>> public class MySingleton {
>>
>> @EJB(beanName="red")
>> private Red red;
>>
>> @EJB(beanName="green")
>> private Green green;
>>
>> @EJB(beanName="blue")
>> private Blue blue;
>> }
>>
>> Something like this would be better:
>>
>>
>> @Singelton
>> public class MySingleton {
>>
>> @DependsOn
>> @EJB(beanName="red")
>> private Red red;
>>
>> @DependsOn
>> @EJB(beanName="green")
>> private Green green;
>>
>> @EJB(beanName="blue")
>> private Blue blue;
>> }
>>
>>
>> Obviously that doesn't handle the pure lookup case, but for something like that the classic @DependsOn would work.
>>
>> If we did that, we might want to choose a different annotation name since using the list in this context is clearly invalid. But maybe not. Maybe the same annotation and a little bean validation is all that's needed.
>>
>> Under the covers the container just constructs the full @DependsOn list and uses that as if it was just one big long @DependsOn.
>>
>>
>> -David
>>
>>
>> On Nov 8, 2011, at 3:21 PM, abien (JIRA) wrote:
>>
>>
>>> Extension of @DependsOn annotation with Class[] beans() element
>>> ---------------------------------------------------------------
>>>
>>> Key: EJB_SPEC-30
>>> URL: http://java.net/jira/browse/EJB_SPEC-30
>>> Project: ejb-spec
>>> Issue Type: New Feature
>>> Reporter: abien
>>>
>>>
>>> The @DependsOn annotation should be extended with an additional element Class[] beans
>>>
>>> @Target(value = {ElementType.TYPE})
>>> @Retention(value = RetentionPolicy.RUNTIME)
>>> public @interface DependsOn {
>>> public Class[] beans(); //NEW
>>> public String[] value();
>>> }
>>>
>>> Reason:
>>>
>>> in EJB 3.1 only the name of the bean can be used, what can be easily misspelled. The syntactical correctness of the bean-class would be checked by the compiler.
>>> Furthermore you will get auto-completion IDE-support as well.
>>>
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> If you think it was sent incorrectly contact one of the administrators: http://java.net/jira/secure/Administrators.jspa
>>> -
>>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>>
>>>
>>>
>>
>>