The APR based Apache Tomcat Native library which allows optimal performance in production environmen

在启动tomcat的时候发现日志里有这么个奇怪的东西:信息: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:\Program Files\Java\jre1.6.0_05\bin;D:\java\apache-tomcat-6.0.16\bin实际上是tomcat建议使用apache的apr,解决办法：是把tcnative-1.dll文件放至 Tomcat 6.0\bin 目录下,链接地址:http://tomcat.heanet.ie/native/1.1.10/binaries/win32/tcnative- 1.dll


转自http://wangxuan137450.blog.163.com/blog/static/11122469620104163315842/


------------------------------------------------------------------------------
我自己注：我出这个问题是在使用eclipse开发使用jndi和dbcp连mysql的测试例子的时候，在启动tomcat的时候报的这个错，那个文件已经在我的tomcat下了，只需要在环境变量中的path中，加上tomcat的bin目录就不会报这个信息了。还有就是其实这个东西就是tomcat 官网上下载中的tomcat native。

-------------------------------

哦，这个问题，官方的参考资料是：http://tomcat.apache.org/tomcat-6.0-doc/apr.html
tomcat整合本地apr会使效率提升：
一是，处理静态资源的时候速度更快，（注：有人用jmeter，对使用apr前后的tomcat进行压力测试，结果显示，性能是有一定的提升，但是没有想象中多，只有一点点，当然，这与运行的逻辑有关，但是我个人认为在大多数情况下这部分性能提升甚微）。
二是，我认为提升比较多的是对ssl的处理效率，当tomcat处理https的请求是，如果使用本地的openssl库，肯定会比前面提升的效率高。（虽然没有实际测试数据，但我推测这里的性能提升比例上要比第一点多得多）。

运行本地apr，需要一下三个库：
  * APR library
  * JNI wrappers for APR used by Tomcat (libtcnative)
  * OpenSSL libraries

补充一下，其实这个并不是eclipse或者是myeclipse的问题，而是tomcat本身一个调用本地库的提高运行效率的特性。tomcat没有找到相应的本地库，提示一下而已。

 

---------------------------------

D:\JAVA\apache-tomcat-6.0.26\conf\Catalina\localhost目录下的一个自己程序生成一个配置文件。
我删除这个配置文件后就不能运行了也报上面的错误，我问题解决是在项目--属性--tomcat 里面的is a tomcat project 那个钩取消再重新勾上后点击下面的OK退出再运行就好了

------------------------------------

在启动tomcat的时候发现日志里有这么个奇怪的东西:信息: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:\Program Files\Java\jre1.6.0_05\bin;D:\java\apache-tomcat-6.0.16\bin

开始以为是错误,后来才知道这个实际上是tomcat建议使用apache的apr

在baidu里找了下apr有关的资料如下:

APR(Apache portable Run-time libraries，Apache可移植运行库)的目的如其名称一样，主要为上层的应用程序提供一个可以跨越多操作系统平台使用的底层支持接口库。
在早期的Apache版本中，应用程序本身必须能够处理各种具体操作系统平台的细节，并针对不同的平台调用不同的处理函数。随着Apache的进一步开发，Apache组织决定将这些通用的函数独立出来并发展成为一个新的项目。这样，APR的开发就从Apache中独立出来，Apache仅仅是使用APR而已。
目前APR主要还是由Apache使用，不过由于APR的较好的移植性，因此一些需要进行移植的C程序也开始使用APR，开源项目比如Flood loader tester(http://httpd.apache.org/test/flood/，该项目用于服务器压力测试，不仅仅适用于Apache)、FreeSwitch(www.freeswitch.org)，JXTA-C(http://jxta-c.jxta.org,C版本的JXTA点对点平台实现)；商业的项目则包括Blogline(http://www.bloglines.com/，covalent(http://www.covalent.net)等等。 APR使得平台细节的处理进行下移。对于应用程序而言，它们根本就不需要考虑具体的平台，不管是Unix、Linux还是Window，应用程序执行的接口基本都是统一一致的。因此对于APR而言，可移植性和统一的上层接口是其考虑的一个重点。而APR最早的目的并不是如此，它最早只是希望将Apache中用到的所有代码合并为一个通用的代码库，然而这不是一个正确的策略，因此后来APR改变了其目标。有的时候使用公共代码并不是一件好事，比如如何将一个请求映射到线程或者进程是平台相关的，因此仅仅一个公共的代码库并不能完成这种区分。
APR的目标则是希望安全合并所有的能够合并的代码而不需要牺牲性能。 APR的最早的一个目标就是为所有的平台(不是部分)提供一个公共的统一操作函数接口，这是一个非常了不起的目的，当然也是不现实的一个目标。我们不可能支持所有平台的所有特征，因此APR目前只能为大多数平台提供所有的APR特性支持，包括Win32、OS/2、BeOS、Darwin、Linux等等。为了能够实现这个目标，APR开发者必须为那些不能运行于所有平台的特性创建了一系列的特征宏(FEATURE MACROS)以在各个平台之间区分这些特征。这些特征宏定义非常简单，通常如下： APR_HAS_FEATURE 如果某个平台具有这个特性，则该宏必须设置为true，比如Linux和window都具有内存映射文件，同时APR提供了内存映射文件的操作接口，因此在这两个平台上，APR_HAS_MMAP宏必须设置，同时ap_mmap_*函数应该将磁盘文件映射为内存并返回适当的状态码。如果你的操作系统并不支持内存映射，那么APR_HAS_MMAP必须设置为0，而且所有的ap_mmap_*函数也可以不需要定义。第二步就是对于那些在程序中使用了不支持的函数必须提出警告。
APR中支持的基本类型
文件夹名称                         描述
atomic/srclib/apr/atomic           原子操作
dso/srclib/apr/dso                 动态加载共享库
fileio/srclib/apr/file_io       文件IO处理
mmap/srclib/apr/mmap             内存映射文件
locks/srclib/apr/locks          进程和线程互斥锁
memory/srclib/apr/memory           内存池操作
network_io/srclib/apr/network_io 网络IO处理
poll/srclib/apr/poll             轮询IO
table/srclib/apr/tables          Apache数组(堆栈)和表格以及哈希表
process /srclib/apr/threadproc     进程和线程操作
user /srclib/apr/user              用户和用户组操作
time /srclib/apr/time              时间操作
string/srclib/apr/strings       字符串操作
password /srclib/apr/passwd        终端密码处理
misc /srclib/apr/misc              大杂烩，不属于其余类的任何apr类型都可以放在里面
shmem /srclib/apr/shmem          共享内存
random /srclib/apr/random       随机数生成库

其实这个不用鸟他,如果要解决也可以,好像是下个什么dll文件放到system32下面去