@Initialized(ApplicationScoped.class) Fired Twice in Multi-WAR Deployment

[joshuak]

I have following deployment structure with the beans.xml in the appropriate place for both the WARs and the EJB JAR:

app.ear

war1.war

war2.war

ejb-jar.jar

In the ejb-jar.jar, there is @Dependent class with the following method:

private void startup(@Observes @Initialized(ApplicationScoped.class) Object obj)
{
     //Log event
}

This method is called twice because (I suspect) that each WAR has a separate class loader and individually initializes ApplicationScoped.class. My intent with using @Dependent scope for this bean was to ensure it was discarded after application initializing was over.

Is there any configuration I can do to prevent both WARs (or whatever else is the cause) from firing this event twice?

Thanks in advance for any help.

[mkouba]

Hi joshuak,

I think this is a correct behavior (see the spec 6.7.3. Application context lifecycle). But I agree that it's not clear - there was CDI-265, but got rejected with no spec update. In any case, it's not a good idea to observe this event outside the relevant WAR (you may encounter portability issues). AFAIK there is no configuration option to prevent WARs from firing the event. However, the event is only delivered to accessible observers. So it's possible to regulate the delivery by means of visibility configuration. What Java EE container do you use?

[joshuak]

Thank you for your prompt response.

We are using JBoss Wildfly 8.1.

I suppose the core of the difficulty I'm having is understanding how applications (WARs and JARs) within an EAR are supposed to interact according to CDI. On one hand, I have EAR-wide visibility for injection and event observers. On the other, I keep running into small unexpected nuances (like this one) of having the applications interact through CDI.

After looking at the spec, shouldn't there have been three events fired instead of just two, since I also have EJB application? It seems odd to me that we only ran into this problem recently when we added the beans.xml to war2.war. Previously, we were only observing one of these events, even though both war1.war and ejb-jar.jar also have beans.xml.

[mkouba]

After looking at the spec, shouldn't there have been three events fired instead of just two, since I also have EJB application?

The problem is the EJB spec does not define any means to track the container lifecycle similar to javax.servlet.ServletContextListener. In any case, this part of the CDI spec would deserve some clarification. By the way, this is not the only issue with EARs.

It seems odd to me that we only ran into this problem recently when we added the beans.xml to war2.war. Previously, we were only observing one of these events, even though both war1.war and ejb-jar.jar also have beans.xml.

That's correct provided the war2.war did not contain any bean class with a bean defining annotation - it was not recognized as a bean archive (see also 12.1. Bean archives).