Note that we also have an open issue for ordering events (for which we have a good and consistent proposal), which will then offer a full alternative to this approach - right now expressing order is not possible.
On 26 Sep 2011, at 11:52, Pete Muir wrote:
> If you think it's important for the CDI EG to consider, then I would suggest you add an issue, that way it is certain to get addressed. Personally, I dislike this approach to reacting to startup/shutdown, and prefer using the CDI event bus to do this (and there is already a proposal in for CDI 1.1 that provides such a facility) so I will not be pushing for such an approach. > > On 26 Sep 2011, at 01:15, Reza Rahman wrote: > >> Pete, >> >> I am a bit short on time at the moment, but did you really need me to do this? Otherwise, you could write something up in the CDI 1.1 EG and I'll certainly be happy to get you useful feedback on it :-). >> >> Cheers, >> Reza >> >> >> On 9/12/2011 3:14 PM, Pete Muir wrote: >>> Reza, >>> >>> Could you file a CDI issue for this so we can track and discuss on the CDI EG? >>> >>> On 12 Sep 2011, at 11:19, reza_rahman@lycos.com wrote: >>> >>>> Pete, >>>> >>>> There isn't a better way that we have seen. It's definitely ugly, but it might be the only way to do it. >>>> >>>> Cheers, >>>> Reza >>>> >>>> >>>> Sep 12, 2011 11:17:03 AM, jsr345-experts@ejb-spec.java.net 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={@DependentQualifier(British.class), @DependentQualifier(value=Gender.class, attributes={@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@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 >>> >>> >>> ----- >>> No virus found in this message. >>> Checked by AVG - www.avg.com >>> Version: 10.0.1392 / Virus Database: 1520/3890 - Release Date: 09/11/11 >>> >>> >>> >> >