The DataSource configuration __tomcat of Tomcat in the primary study of Jndi

Some people say that there is no real understanding of Java EE without mastering Jndi.
It seems that I have never understood. the role of Java EE

Before we talk about Jndi, let's start with the role of Java EE.
the Java EE specification delegates responsibility to multiple development roles: component providers (Component Provider), Application assemblers (application assembler), deployment Personnel (Deployer), and system administrators Administrator).

Component Provider This role is responsible for creating Java EE components, Java EE components can be WEB applications, enterprise-class
JavaBean (EJB) component, or application client (for example, a GUI client application based on Swing). Component providers include: HTML
Designers, document programmers, and other developer roles. Most Java EE developers spend a considerable amount of time on the role of component providers. Application Assembler
This role will be multiple Java EE
The module is bundled into one integrated, deployable Whole: Enterprise Archive (EAR) file. Application assemblers Select components, distinguish how they interact, configure their security and transactional attributes, and package applications to
EAR file. Many Ides, such as Websphere®studio, Idea, JBuilder, WebLogic Workshop
And other Ides, you can help application assemblers Configure the EAR file interactively. Deployment Personnel (Deployer) This role is responsible for deployment, which means that the EAR
Install to Java EE
Container (Application server), and then configure resources, such as database connection pooling, to bind the resources that the application requires to specific resources on the application server and start the application.
System administrator This role is responsible for ensuring that the resources required by the container are available to the container. Post-binding of external resources

Any non-trivial (nontrivial) Java EE application needs access to information describing the environment it expects to use. This means that when developing and testing components, developers assume some deployment responsibilities in order to temporarily test the code. It's important to understand that when you do this, you're out of the developer's domain. Otherwise, you can try to rely on a JDBC driver, or a URL, a JMS queue name, or other machine resources that have an unconscious, occasionally potentially catastrophic hint. What is Jndi

Naming and directory interfaces, Java naming and directory Interface.
Why there are jndi.
The reason for the birth of Jndi seems simple. With the development of distributed applications, remote Access object access becomes a common method. Although the remote communication can still be realized by programming means such as socket, it still has its limitation according to the theory of the pattern. RMI technology, the generation of RMI-IIOP technology, makes the search of remote objects become the technical focus. The Jndi technology was born. Once the Jndi technology is produced, it is easy to find remote or local objects.

Many developers know that tight coupling between code and external resources is a potential problem, but in practice they often forget about the division of roles. In small development work, which refers to team size or scale of deployment, even ignoring role partitioning can be successful.
The Java EE specification requires all Java-EE containers to provide a JNDI specification implementation. The role of JNDI in Java EE is a common mechanism for the "switch"--J2EE component to locate other components, resources, or services at run time. In most cases, the container that provides the JNDI provider can act as a limited data store, so the administrator can set the execution properties of the application and have other applications reference these properties (Java Management Extensions, Java Management extensions, JMX) can also be used for this purpose. The main role of JNDI in the Java EE application is to provide an indirect layer so that the component can discover the resources needed without having to understand these indirection. As an example

Typical data source configuration, I will not cite examples, you must know.
So, how to use Jndi to configure it. Separate development from deployment.
Take Tomcat for example: server.xml

<GlobalNamingResources> <!--Editable User database that can also is used by Userdatabaserealm to AU Thenticate users--> <resource name= "userdatabase" auth= Container "type=" Org.apache.catalina. Userdatabase "description=" User database that can is updated and saved "factory=" org.apache.ca Talina.users.MemoryUserDatabaseFactory "pathname=" Conf/tomcat-users.xml "/> <resource na Me= "Jdbc/mysql" scope= "shareable" type= "Javax.sql.DataSource" factory= "ORG.APACHE.TOMCAT.D" Bcp.dbcp.BasicDataSourceFactory "url=" jdbc:mysql://localhost:3306/armstrong "driverclassname =" Com.mys Ql.jdbc.Driver "username=" root "password=" Nington "/> <resource name=" jdbc/ Mysql_c3p0 "scope=" shareable "type=" Com.mchange.v2.c3p0.ComboPooledDataSource "factory=" org.apache.na Ming.factory.BeanFactory"Jdbcurl=" Jdbc:mysql://localhost:3306/armstrong "driverclass=" Com.mysql.jdbc.Driver "user=" root "pass word= "Nington"/> </GlobalNamingResources>

context.xml

<Context>
    <WatchedResource>${catalina.base}/conf/web.xml</WatchedResource> 
    < ResourceLink global= "jdbc/mysql_c3p0" name= "Jdbc/mysql" type= "Javax.sql.DataSource"/> <watchedresource  
    >WEB-INF/web.xml</WatchedResource>
</Context>

Spring.xml

<!--<bean id= "DataSource" class= "Com.mchange.v2.c3p0.ComboPooledDataSource"-->
          <!-- Destroy-method= "Close" >-->
        <!--<property name= "Driverclass" value= "${app.db.driver}"/>-->
        <!--<property name= "Jdbcurl" value= "${app.db.url}"/>-->
        <!--<property name= "user" value = "${app.db.user}"/>-->
        <!--<property name= "password" value= "${app.db.password}"/>-->
        <!--<property name= "maxpoolsize" value= "${app.db.maxpoolsize}"/>-->
        <!--<property Name= " Minpoolsize "value="/>-->
        <!--<property name= "initialpoolsize" value= "ten"/>-->
        <! --<property name= "MaxIdleTime" value= "/>-->
    <!--</bean>-->

    <jee:jndi-lookup Id= "DataSource" jndi-name= "Jdbc/mysql"/>

If there is no problem, it should be done. Of course Tomcat has a lot of other configuration options and is interested in having access to relevant information. beyond the data source

Of course, the resources in Java EE are not limited to the JDBC data source. There are many types of references, including resource references (already discussed), environment entities, and EJB references. Especially
EJB reference, which exposes another key role of JNDI in Java EE: finding other application components. Imagine this: When a company from order
Ontology processing Services (OOPS) has purchased a deployable EJB
Component to handle customer orders, what happens. For illustrative purposes, we call it processorders V1.0. Processorders 1.0
There are two parts: a set of interfaces and support classes (home and remote interfaces, and supported transport classes), and the actual EJB component itself. Select OOPS
is because of its professionalism in this field. The company follows the Java EE specification and writes WEB applications that use EJB references. The company's deployment staff
Processorders 1.0 binds to the JNDI tree, uses it as a ejb/processorders/1.0, and parses the Web
The resource name of the application to point to this global JNDI name. So far, these are EJB
Component is a very common usage. However, when we consider the interaction between the company's development cycle and the company's suppliers, things get complicated. Here, JNDI can also help us. Let's assume
OOPS released a new version of the Processorders
V1.1. This new version has some of the features that a new application within the company needs, and it naturally extends the business interface of the EJB component.
Here, the company has the following options: You can update all applications to use the new version, or you can write your own version, or use JNDI
Reference resolution that allows each application to use its own EJB without affecting other applications
Component versions. Updating all applications immediately is a nightmare for maintenance, requiring complete regression testing of all components, which is often a daunting task, and another round of debugging if any functional test fails.
Writing internal (in-house) components is often unnecessary duplication of effort. If the component is written by a company that has expertise in this business area, then the given IT
Stores cannot be as proficient in business functions as professional component suppliers. As you might have guessed, the best solution is to use JNDI parsing. JNDI for EJB
References that are very similar to JDBC resources. For each reference, the deployer needs to give the new component a specific name, such as
ejb/processorders/1.1) is bound to the global tree, and for each additional component that requires an EJB component, the EJB is also resolved for the component in the deployment descriptor
Reference. Depend on the V1.0
Previous applications do not require any modification or need to be tested, which shortens implementation time, lowers costs, and reduces complexity. This is a very effective method in an environment where services tend to transition. You can do this type of configuration management for all the components that are available in the application architecture, from
EJB Component to JMS
Queues and themes, and then to simple configuration strings or other objects, which reduces the maintenance costs of service changes over time, and simplifies deployment and reduces integration efforts.Concluding remarks

There is an old computer science joke: Each programming problem can be solved by just one abstraction layer (or indirectly). In Java EE, JNDI is the glue that puts the application of Java EE together, but it is not too tight to make it easy to separate and reassemble them. The indirect addressing provided by JNDI allows scalable, powerful, and flexible applications to be delivered across the enterprise. This is the promise of Java EE, and after some planning and prior consideration, this commitment is fully achievable. In fact, it's much easier than many people think.