JBoss EAP 6.x understand the deployment phase - ResourceAdapters, EJB, jar, war

Question

In JBoss, how is the sequence of the deployment phase? What is the order of object being instantiated and available to use? Considering an enterprise application (*.ear), inspecting all deployment log (server.log) the deployment phase looks like:

1. All libs are deployed - .class files are loaded and available;
2. All *.jar modules are deployed - .class files are loaded and available;
3. If some *.jar is an EJB Jar, through the configuration files (Ex. ejb-jar.xml) or annotations, the JNDI tree is created;
4. If some *.jar has a persistence.xml file configuration, all entity and link to datasources are loaded;
5. All *.war modules start the deploy phase;
6. Through configuration files (web.xml), listeners and context-root are loaded and eventually security aspects.
7. Ear deployed successful.

Questions:

• What about the resource adapters modules, the PersistenceContext and the EJB Pool?
• When a persistence.xml is found, does a connection to the data-source and so to the DB pool start?
• Since the datasource (DB) is configured in the standalone.xml or domain.xml, when happens the first connection to the DB pool? When I inject the PersistenceContext and use the EntityManager?
• When the EJB pool is loaded and available to use?
• Is correct to say that during the EJB jar deploy, the JNDI tree is created and then available?
• When an EJB is discovered, it's loaded inside the pool (as reference to inject/lookup)?

When a .war module is deployed and ready, even if the full deploy of the .ear is not completed yet, possibly servlet or listener are started from the container.

• What happens if some of this objects (listener, servlet) try to use EJBs or PersistenceContext or other objects? Are those objects available?
• Is it possible to have deadlock problem and hang the deployment thread/phase?

Overscrupulous

Answer 1

• It is possible to control the deployment order of jars and wars in application.xml using <initialize-in-order>true</initialize-in-order>
• The lifecycle of the resource adapters is controlled by the connector architecture
• The lifecycle of Container-Managed Entity Managers are managed by JBoss. Assuming you are injecting into an EJB using @PersistenceContext, this happens prior to @PostConstruct.
• Singleton EJB initialization order can be defined using @DependsOn("OtherBean")
• You can ensure the EJB endpoints are available using the deployment order in the first bullet
• Not sure if it is possible to dead lock - it is far more likely that you will see a JNDI exception

Theorize

Thanks for the information and the useful links. You deserve the bounty. I edited my question and added other questions related to the deployment phase and how the container manage the resources. – Overscrupulous

Answer 2

I will try to address the rest of your questions:

When a persistence.xml is found, does a connection to the data-source and so to the DB pool start?

Yes, that must happen (if no connection already is made), otherwise no table structure (DDL) could be validated or be created.

Since the datasource (DB) is configured in the standalone.xml or domain.xml, when happens the first connection to the DB pool? When I inject the PersistenceContext and use the EntityManager?

The answer to this question is: it depends. If your JDBC Datasource is configured with a minimum pool size MIN_POOL_SIZE>0 and has the prefill flag set to true, then WildFly will create MIN_POOL_SIZE connections to the DB server, without any deployments at all that use that datasource (after changing that flag you will need to disable/enable the datasource). Otherwise on deployment: it is created as many connections as needed (depending on what you do on deployment, but for simple applications a single one), except you have a MIN_POOL_SIZE>0 defined and the strict minimum flag is set to true, in which case AT LEAST MIN_POOL_SIZE connections will be created.

When is the EJB pool loaded and available for use?

It is available for use after deploying the EJB submodule, with all its dependencies.

Is correct to say that during the EJB jar deploy, the JNDI tree is created and then available?

I would formulate that in the following way: After (not during) it is checked that all EJBs can be deployed (e.g all their dependencies could be solved), then JNDI entries are created (in the JNDI tree). According to what I noticed, if a single EJB fails, nothing is deployed, which makes me think I am right here.

[When a .war module is deployed] What happens if some of this objects (listener, servlet) try to use EJBs or PersistenceContext or other objects? Are those objects available?

Yes, definitely. We use that feature to execute some init code from a servlet, when the WAR file is deployed (e.g to create some entities with some default values).

Is it possible to have deadlock problem and hang the deployment thread/phase?

Theoretically yes, practically no (I doubt the guys at RedHat did not think about this).

---

Some tips: if you use MySQL, you can check what connections are made to the server with show processlist. Otherwise if you use Linux/Unix, you can check all made connections to your DB server with netstat.

Stole