Add CDI compatible @Eager

[omnifaces]

Add CDI compatible @Eager

[arjantijms]

Request scope (two moments), session scope and application scope have been implemented.

[devluencer-089]

Any way to make @eager a stereotype instead of a qualifier. A stereotype annotation identifies a role or behavior while a qualifier is useful for bean resolution if there are multiple implementations.

With qualifiers any injection point of an eager bean would have to be qualified (if I am not mistaken):

@Inject
@eager // meh
private MyEagerApplicationScopedManager manager;

[arjantijms]

Hi,

Any way to make @eager https://github.com/Eager a stereotype instead of
a qualifier. A stereotype annotation identifies a role or behavior while a
qualifier is useful for bean resolution if there are multiple
implementations.

Thanks for the suggestion. I'll look into it.

With qualifiers any injection point of a eager bean would have to be

qualified (if I am not mistaken):

I certainly have to double check that, as the example indeed looks
terrible. I was initially thinking about @nAmed also being a qualifier, but
if I'm not mistaken it's a special one that gets the @default qualifier
anyway.

I'll test it as soon as possible.

@Inject https://github.com/Inject
@eager https://github.com/Eager // meh
private Instance manager;

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/18#issuecomment-42723771
.

[arjantijms]

Ps

Perhaps even simpler is just to remove the @qualifier as according to
Thomas' remark on Oleg's post this isn't even needed.

[devluencer-089]

Hi Arjan,

you are right, neither a qualifier nor a stereotype annotation is required. That's probably the best way to go.

As far as my example is concerned I think you are right: if there is just one bean it should implicitly get the @Default-qualifier and @eager is superfluous. It's just odd that you could do this. Using qualifiers to add behavior just does not seem right to me.

Have you given any thought on allowing @eager as a meta-annotation on stereotypes? Would be nice to be able to do something like this:

@ApplicationScoped
@eager
@stereotype
@retention(RUNTIME)
@target(TYPE)
public @interface Startup {}

[arjantijms]

Have you given any thought on allowing @eager as a meta-annotation on stereotypes?

It sounds like a nice idea, but unfortunately I'm not 100% sure yet how to best implement this. With a definition as you give in your example the extension will not directly see the @eager annotation.

Maybe I can recursively test if each annotation encountered is a stereotype and then descend into it to see if I can find an @eager one (with some caching for previously encountered types).

I'm not sure if that is the best approach though. My knowledge of CDI is still a bit limited to be honest.

[devluencer-089]

Maybe I can recursively test if each annotation encountered is a stereotype and then descend into it to see if I can find an @eager one (with some caching for previously encountered types).

That's excactly how I would have done it by observing the ProcessBean event. (though that does not mean it's the best way.) You might be concerned about performance but according to my experience the impact on deployment time is minimal, even on larger projects.

Anyway, it's just an idea. I found it very useful to compose stereotype annotations for the extensions I wrote. And stacking is a feature JEE decided to support with stereotypes so it goes nicely with CDI.

[arjantijms]

Okay, I've added methods to recursively scan annotations and let the extension for @eager make user of it.

I was indeed somewhat concerned about performance, but I figured that even very big projects will probably not have millions of beans with hundreds of thousands of annotations that each have 6 levels of stacked stereotypes on them.

So I didn't apply any of the above mentioned caching yet as long as it's not clear whether it would indeed be a performance issue.

While at it, I added the stereotype you mentioned as well. I think it's rather useful really ;) The only point is that the name @startup is already taken in Java EE, so I'll try to think of a better name and if not I'll just leave it as it.

Thanks again for the suggestion!

[BalusC]

Also tested on Tomcat 7.0.53 + Weld 2.2.0, works flawlessly. Deploys also without trouble on Tomcat 7.0.53 w/o CDI and Tomcat 6.0.39 w/o CDI.

[arjantijms]

May have to double check the Tomcat case, as the Weld documentation says this:

The downside of javax.servlet.ServletContainerInitializer approach is that the Weld listener will be added to the end of the ordered list of discovered listeners. In practice the request and session context will not be active during ServletRequestListener and HttpSessionListener notifications. Fortunately, it's possible to combine the EnhancedListener and the old Listener to fix this problem - simply add the old Listener to the web.xml as mentioned above. Note that it must be defined before the listeners using request and session context.

See: http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#d0e5583

@eager is now using a ServletRequestListener for its work. According to the spec the request scope has to be active then, but in practice this may have some issues in some cases. At least in GF 3 the request scope isn't active in a ServletRequestListener (which is of course a bug in GF 3 then, but still)