我们都知道在tomcat中，可以通过在context.xml中配置resource中用于配置tomcat数据源，如下所示即是一个配置例子。
|
1
2
3
4
5
6
|
<Context> <Resource="jdbc/xx"="Container"="javax.sql.DataSource"="mymysql" driverClassName="com.mysql.jdbc.Driver" /></Context> |
配置了如上的数据源之后，在java代码中，就可以以如下代码进行访问：
|
1
2
|
InitialContextnew DataSource"java:comp/env/jdbc/xx"); |
那么,tomcat是如何将resource中的信息解析成上下文中，并可以通过jndi的方式进行访问呢。这就得从contextResource对象的创建说起。
在NamingContextListener中，namingContext被创建，同时相应的comp上下文和evn上下文被创建起来。然后通过解析context.xml，将最终的jdbc/xx节点绑定在相应的上下文中，并通过解析Resource节点，最终确定数据源对象的创建。
初始namingContext创建
首先我们进入到NamingContextListener对象中，在启动方法，即lifecycleEvent方法中，会初始化根上的namingContext，并将此对象绑定在容器中，并同时绑定在线程上。如下所示：
|
1
2
3
4
5
6
7
8
9
|
namingContextnew//创建根上下文ContextBindings.bindContext(container,//将这个上下文绑定在绑定中//因此当前容器为StandardContext，所以会将此上下文绑定在线程类加载器中，以方便后面进行获取ifinstanceof ContextBindings.bindClassLoader (container, ((Container) } |
创建子上下文
创建了根上下文后，就开始创建子上下文即comp和env了。这两个子上下文的创建封装在方法createNamingContext中，如下所示：
|
1
2
|
compCtx"comp");//这里是组件上下文envCtx"env"); //将环境上下文创建在组件上下文中 |
解析数据源
一旦创建了子上下文，就会被已经由digester解析出来的ContextResource对象加载到上下文中，这里就会碰到contextResource的进一步解析。因为，在之前仅是一个contextResource描述对象，这里要将此对象转换成一个objectFactory对象，即可以创建出数据源的一个工厂对象。这就会进入到addResource(ContextResource resource)方法。此方法的作用在于绑定子上下文，同时进行解析。我们先看如何进行信息绑定，如下代码所示：
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
|
//这里将ContextResource里面的信息，重新组装在一个ResourceRef对象//首先解析可以被确定的属性信息，如类型，验证方式等 Referencenew (resource.getType(), resource.getScope(), resource.getSingleton());//这里解析其他属性信息，这些信息以properties的方式放到ContextResource中，如driverClassName,username,password等。 Iterator<String> while String String StringRefAddrnew ref.add(refAddr); }//接下来创建子上下文，因为这里的resource createSubcontexts(envCtx, envCtx.bind(resource.getName(), }catch logger.error(sm.getString("naming.bindFailed", } |
在绑定了context之后，这里就会触发一次jndi资源的解析，即首先尝试解析数据源信息是否正确。即通过调用context.lookup进行预处理。预处理之后的值即为们想要的datasource,同时，因为ResourceRef为singleton的，所以会触发绑定值的更新。最终第二次再次lookup之后，就会直接取得datasource了。如以下代码所示：
|
1
2
3
4
5
|
if"javax.sql.DataSource".equals(ref.getClassName())) ObjectName Object...... } |
这里的envCtx.lookup和我们所应用的context.lookup没有什么不同，它会查询出一个entry值，其中type表示所绑定的对象的类型，value即绑定的值。惟一不同的是这里本应该查询出刚才绑定的resourceRef对象，但是在tomcat内部，它会对resourceRef作二次处理。即会通过使用针对于resourceRef的FactoryClassName，再其他其的getObjectInstance方法进行处理，最终取得最终的值，并重新进行绑定。
整个流程可以理解为：
- 查询出entryValue
- 判断entryValue类型,是否为REFERENCE类型
- 如果是则使用NamingManager.getObjectInstance重新获取
- 获取resourceRef所对象的FactoryClassName值
- 使用ResourceRef的FactoryClass实例化对象并调用其getObjectInstance方法
- 根据resourceRef所对应的className进行判断，如果是javax.sql.Datasource，则实例化所对应的tomcat-dbcp中的数据库连接池工厂
- 调用数据库连接池工厂再次调用getObjectInstance方法，获取最终的datasource
整个流程所对应的代码如所示：
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
//1NamingEntry0));//2if try Object (entry.value,this, if(entry.valueinstanceof boolean (String) "singleton").getContent()); if entry.type entry.value } }//3ifnull) String//获取factoryClassName值 ifnull) // factory//实际化此工厂，即类ResourceFactory ifnull) return environment);//调用其相应方法 }}//6 ifinstanceof...... if"javax.sql.DataSource")) String System.getProperty("javax.sql.DataSource.Factory", Constants.DBCP_DATASOURCE_FACTORY); factory Class.forName(javaxSqlDataSourceFactoryClassName) .newInstance();}//7ifnull)//最终返回datasource对象 return (obj,} |
在获取最终的datasource对象之后，NamingCotext会重新进行一次绑定，以避免重复获取。代码如下所示：
|
1
2
3
4
|
if//这里即指我们的resourceRef是否为单态的，默认值即为true entry.type entry.value } |
至此，整个解析过程结束。在后面的java代码中，我们通过java:comp/env/jdbc/xx这个即可访问到datasource，实际上就是访问的已经获取到的datasource值了。但通过java:xx这个命名对象值进行查询，又和上面的查询不一样（大部分相同，只是起点不一样）。关于此的差别在下一篇 tomcat如何获取jndi信息 进行处理。
转载请标明出处:i flym
本文地址:http://www.iflym.com/index.php/code/201208080004.html