If you have a @DependsOn at the CDI level with class, qualifier level semantics, it basically comprises a super-set of what EJB has today. Since @Named is a qualifier, you could use that to express initialization order dependencies as well. As an upshot of that discussion, I think we might also end up with a @JndiLocation qualifier.
Hope it helps. Let me know if I should explain further.
No problem - I followed the CDI discussion :-). But if you change the @DependsOn annotation for CDI-needs you will break the existent EJB 3.1 contract. Would you like to use @Named (Strings) or other qualifiers (classes)?
From EJB perspective having a class is more convenient.
What do you think?
adam On 10.09.2011, at 06:25, Reza Rahman 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 >> >> >