[
https://issues.redhat.com/browse/WFLY-13498?page=com.atlassian.jira.plugi...
]
Fearghal O Maolcatha commented on WFLY-13498:
---------------------------------------------
I understand it's difficult to do much when you're not able to reproduce the
problem yourself.
The issue is consistent in my app. The @Observes @Initialized idiom was used to eagerly
load some CDI beans in our application. I've put in a workaround to get over this
issue.
I'll try to dig into the issue a bit more in the coming days.
@ApplicationScoped Bean Not Eagerly Instantiated on Wildfly 16
--------------------------------------------------------------
Key: WFLY-13498
URL:
https://issues.redhat.com/browse/WFLY-13498
Project: WildFly
Issue Type: Bug
Components: CDI / Weld
Affects Versions: 16.0.0.Final
Reporter: Fearghal O Maolcatha
Assignee: Matěj Novotný
Priority: Major
I have an @ApplicationScoped bean that I want to be instantiated on application startup
(see sample code below). I've registered for the servlet context initialization event
but the init method is never invoked. The FactoryLocator is contained in a jar within my
war's WEB-INF/lib directory. This same code was working on Wildfly 9 but no longer
works after upgrading to Wildfly 16.
{code:java}
import javax.enterprise.context.ApplicationScoped;
import javax.enterprise.context.Initialized;
import javax.enterprise.event.Observes;
import javax.servlet.ServletContext;
@ApplicationScoped
public class FactoryLocator {
public FactoryLocator() {
System.out.println("In the constructor.........................");
}
private void init(@Observes @Initialized(ApplicationScoped.class) ServletContext sc)
{
System.out.println("Invoking the event observer
method..................");
}
}
{code}
One workaround I discovered was to extract the contents of the jars in my war's
WEB-INF/lib/ directory to my war's WEB-INF/classes directory. When I did this my
FactorLocator bean was instantiated successfully. I'd prefer not to have to do this.
After debugging through the war's deployment, I noticed that the ServletContext is
initialized before all the beans in the war's lib directory are processed
(org.jboss.weld.bootstrap.BeanDeploymentModules:processBeanDeployments). The war's
module is not aware of all observers until all the beans are processed. However, the
ServletContextEvent is fired before all the observers are known.
Should this happen that ServletContext is created before all observers are known about?
I've debugged one of the Wildfly QuickStart applications and the ServletContext
isn't created until all bean deployments are processed and the code below is executed
successfully. Is the order in which this happens supposed to be guaranteed?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)