If by classes you mean any one of the types of EJB.beanInterface (
http://download.oracle.com/javaee/6/api/javax/ejb/EJB.html#beanInterface%28%29
) then yes this makes sense have.
Note that DependsOn.value would need a default.
Carlo
On 09/12/2011 05:29 PM, Adam Bien wrote:
> Your answer is perfect! If you do not like to have EJB's @DependsOn annotation, we could make it more usable for EJBs :-)
>
> You are right -> it looks ugly. For CDI we will have to consider the types AND qualifiers...
>
> thanks!,
>
> adam
> On 12.09.2011, at 15:47, Pete Muir wrote:
>
>> The issue with @DependsOn for CDI is that specifying a CDI dependency using an annotation is extremely ugly. Say I have a CDI bean:
>>
>> @Colored @Red
>> class Parrot {
>>
>> }
>>
>> If I wanted to depend on that using @DependsOn:
>>
>> @DependsOn(type=Parrot.class, qualifiers={Colored.class, Red.class})
>>
>> it's pretty nasty. We're not going to win anyone to Java EE with this.
>>
>> However it get's worse.
>>
>> @British @Gender(MALE)
>> class Person {
>>
>> }
>>
>> @DependsOn(type=Person.class, qualifiers={_at_DependentQualifier(British.class), @DependentQualifier(value=Gender.class, attributes={_at_DependentQualifierAttribute(name="value", value="MALE")}))
>>
>> This is now basically useless, and I've yet to hear anyone say that this is a good approach.
>>
>> I know that some people have proposed requiring this only works with @Named e.g.
>>
>> @British @Gender(MALE)
>> @Named("britishMalePerson")
>> class Person {
>>
>> }
>>
>> @DependsOn("britishMalePerson")
>>
>> However this cannot be included in the CDI spec as it is a complete deviation from the guiding principles of CDI.
>>
>> I've yet to see a better approach - any ideas? :-D
>>
>> Pete
>>
>> On 12 Sep 2011, at 04:13, Antonio Goncalves wrote:
>>
>>> Wouldn't it also make sense to have @DependsOn on some CDI beans (@ApplicationScoped for example) ?
>>>
>>>
>>> On Sat, Sep 10, 2011 at 06:25, Reza Rahman<reza_rahman_at_lycos.com> wrote:
>>> Adam,
>>>
>>> I hate to say this, but I'd rather focus on moving @DependsOn to CDI where name-based qualifiers would be unlikely to be used anyway.
>>>
>>> Cheers,
>>> Reza
>>>
>>>
>>>
>>> On 9/9/2011 7:23 PM, Marina Vatkina wrote:
>>> Adam,
>>>
>>> What would be the use-case for the new element?
>>>
>>> thanks,
>>> -marina
>>>
>>> Adam Bien wrote:
>>> Hi All,
>>>
>>> currently the @DependsOn annotation looks like:
>>> @Target(value = {ElementType.TYPE})
>>> @Retention(value = RetentionPolicy.RUNTIME)
>>> public @interface DependsOn {
>>>
>>> public String[] value();
>>> }
>>>
>>>
>>> I would like to extend it with a class element:
>>>
>>> @Target(value = {ElementType.TYPE})
>>> @Retention(value = RetentionPolicy.RUNTIME)
>>> public @interface DependsOn {
>>>
>>> public String[] value();
>>> *public Class[] classes() default void.class;*
>>> }
>>>
>>> It should be possible to specify the dependencies as simple EJB-names as well as referring directly to the classes,
>>>
>>> any thoughts?
>>>
>>> adam
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 10.0.1392 / Virus Database: 1520/3886 - Release Date: 09/09/11
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Antonio Goncalves
>>> Software architect and Java Champion
>>>
>>> Web site | Twitter | Blog | LinkedIn | Paris JUG
> Independent Consultant, Speaker, Java Champion
>
> Weblog: blog.adam-bien.com
> press: press.adam-bien.com
> eMail: abien_at_adam-bien.com
> twitter: twitter.com/AdamBien
> Mobile: 0049(0)170 280 3144
>
> Author of:
> "Real World Java EE Night Hacks", "Real World Java EE Patterns--Rethinking Best Practices"
>
>
>
>
>
>
>
>
>
>
>
>
>