jsr345-experts@ejb-spec.java.net

[jsr345-experts] Re: Extension of _at_DependsOn

From: Marina Vatkina <marina.vatkina_at_oracle.com>
Date: Mon, 12 Sep 2011 15:11:32 -0700

I would expect bean class, not the interface class to be used as a
dependency...

-marina

Carlo de Wolf wrote:
> 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"
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>