J2EE application deployment (III): Advanced

Outline:
==========================================
I. Module order
II. Dependency Library problems
2.1 one solution
2.2 solution 2
2.3 dependent database application instances
==========================================
Body:
==========================================
In the previous two articles, we learned the basic concepts and practices of J2EE application encapsulation and deployment. Let's take a look at several possible problems.
I. Module order
The J2EE specification does not specify how to deploy the J2EE module in the EAR file. In particular, the J2EE specification does not specify the order of modules to be deployed. If a component in a module needs to use the component of another module to be deployed, it may cause problems.
Therefore, you must note that most application servers deploy the EAR file in the following steps:
All resource adapters in the EAR file are deployed as basic connectors. If multiple resource adapters exist, their deployment order is the order they are listed in the application. xml deployment descriptor.
Deploy all EJB modules. Because EJB may use some resource adapters during initialization, the EJB is deployed after the resource adapter. If multiple EJB modules exist, their deployment order is the order they are listed in application. xml.
Deploy all Web application modules. Since resource adapters and EJBs may be used during Web application initialization, all Web applications are deployed after the two. If multiple Web application modules exist, their deployment order is the order they are listed in application. xml.
II. Dependency Library problems
During J2EE application encapsulation and deployment, the most common problems occur in the tool class and support class. Where should these libraries be stored when encapsulating Web applications or EJB applications? Web applications and EJB applications generally have the ability to be "detached" (this refers to the loading reverse process), which is supported by the class loaders that are deployed in fashion. If we put the tool class and support class into the standard class path of the application server, these classes are likely to completely lose the ability to be detached. In this way, if the Web application or EJB application wants to update the version of a library, and when the Web application or EJB application is re-deployed, the dependent libraries including the tool class and support class should also be re-deployed. In this case, it is inconvenient to put the tool class into the standard class path of the application server, because every time a Web application and EJB application are deployed, the entire application server must be restarted, which is obviously not the ideal choice.
In the standard J2EE definition, where can we re-deploy the runtime (hot deployment) if the dependent libraries are stored? There are two simple solutions, but basically both are not reasonable:
The dependent libraries encapsulated in JAR files can be placed in the Web-INFlib Directory of the WEB application. Generally, the WEB-INFlib directory is only used to store servlets. JSP pages and servlets will search for this directory when reading new classes. If the tool library is used only for JSP pages and servlets of a Web application, it should be said that this solution is sufficient. However, if the same tool library is used for EJB components, JMS consumers, application startup classes, and application closing classes, this solution is no longer effective because for them, the WEB-INFlib directory is invisible.