Pursuing the idea of convention over configuration, further, enterprise applications can be developed without any initial configuration required. The APIs provide default behavior that matches the majority of use cases. Engineer are only required to put extra effort in if that behavior is not sufficient.
This implies that in today's world, enterprise projects can be set up with minimal configuration involved. The days of extensive XML configuration are over. Especially, applications that don't ship web frontend technology can keep XML files to a minimum.
Let's start with a simple example of an application that offers REST endpoints, and accesses databases and external systems. REST endpoints are integrated by JAX-RS that internally uses servlets to handle requests. Servlets traditionally are configured using the web.xml deployment descriptor file residing under WEB-INF. However, JAX-RS ships a shortcut by sub-classing Application, annotated with @ApplicationPath, as shown in the previous chapter. This registers a JAX-RS application servlet for the provided path. At startup time, the project will be scanned for JAX-RS related classes such as resources or providers. After the application has been started, the REST endpoints are available to handle requests even without a provided web.xml file.
Managed beans are traditionally configured using a beans.xml configuration file. In web archive applications this file also resides under WEB-INF. Nowadays, it is primarily used to specify the bean discovery mode, that is, which CDI beans are considered per default. It's advisable to configure the bean-discovery-mode of all, not just annotated beans. The beans.xml file can override CDI bean composition of all sorts, such as interceptors, alternatives, decorators, and so on. As the CDI specification states, for the simplest example it's sufficient for this file to be empty.
The JPA persistence units are configured using the persistence.xml file under META-INF. As previously shown, it comprises the datasource definitions that are used in the the application. Mapping JPA entities to database tables is configured via annotations in domain model classes. This approach keeps the concerns in a single place and minimizes XML usage.
For the majority of enterprise applications that don't include a web frontend, this amount of configuration is already sufficient. Frontend technologies such as JSF are usually configured via web.xml and faces-config.xml or if required, via additional, implementation-specific files.
In the past, vendor-specific configuration files, such as jboss-web.xml or glassfish-web.xml, were quite common. In a modern Java EE world, the majority of applications don't require these workarounds anymore. In order to allow portability, it is highly advisable to implement features using standard APIs first and only if this is not possible within reasonable effort to go with vendor-specific features. Experience with legacy projects showed that this approach leads to better manageable situations. Unlike vendor-specific features, Java EE standards are guaranteed to continue to work in the future.
At application startup, the container scans the available classes for annotations and known types. Managed beans, resources, entities, extensions, and cross-cutting concerns are discovered and configured appropriately. This mechanism is a great benefit for developers. They don't need to explicitly specify required classes in configuration files but can rely on the server's discovery; inversion of control at its best.