今天遇到在处理一个多classloader调用本地native方法报错的问题的时候，想要通过调用本地的一个dll进行测试。该dll是在32位环境下编译的。而OneCoder的调试机器是64位的win7。自然调用会报如下错误：

Can’t load IA 32-bit .dll on a AMD 64-bit

错误信息很明显，于是替换了一个32位的JDK，重新测试，结果又报找不到dll的异常。加载dll的代码很简单：

System.loadLibrary("hello”);//dll的文件名为hello.dll

此时，我已经按照经验将dll扔到C:\windows\System32目录下了，感觉应该万无一失的，结果却不行。以前在做windows下libvirt接口开发的时候，就是这么做的，当时运行正常。这是为什么？

仔细回忆，想起当时的环境是win7 32位，而现在是64位的，难道windows的目录有变化？马上查看，果然在windows目录下又发现了一个SysWow64的文件夹，里面的文件几乎和System32内的文件一致。立马把hello.dll扔到里面再次运行。成功！

果然64位的win7的目录有变化，后来笔者也在网上搜索了一番，有几篇介绍windows32位和64位系统dll文件夹命名规则的文章，如果大家有兴趣可以去搜索一下。

由该问题，笔者也想起之前对于windows下libvirt开发的文章中介绍的操作方式可能不够严谨，当时也有很多朋友向OneCoder询问为什么他们按照我介绍的扔到System32目录下，仍然不好用，但是我没能给出解答，如此看来，很可能是那些朋友的开发环境是64位的系统，如果是这样，那他们放到C:\Windows\SysWoW64下，应该会好用了。 

最近很多人问我有没有Netty4的Hello World样例，很早之前知道Netty要出4，当时只知道4的包名完全边了，因为Netty从JBoss中独立出来了，并采用了新的netty.io的域名，但是没想到代码也有这么大的调整。

首先，感谢又拍云存储赞助的存储空间。让我的小站以可以体验一下CDN加速的快感。

虽然我是第一次使用又拍云，甚至是第一次使用云存储，但是上手起来还是很迅速的。这得益于又拍云后台操作的简便，以及详细的操作说明。
又拍云的空间分两类，一种是文件类的，一种是图片类的。主要的区别就是图片类空间支持缩略图的功能。

对于一个wordpress个人博客而言，主要的加速就是将常用的css和js文件放在云存储上。别小看这看似小巧的文件，从本站实际感受和统计来看，访问速度却有提升，而近一个月仅js和css文件请求的流量节省就有350多mb。如果是一个访问量更大的网站而不是我的这个小小的博客，那带来的效果就会更明显了。着实令我感到欣喜。

就我这一个月的使用来看，又拍云存储的CDN加速及其带来的流量节约功能是我非常喜欢的。速度快，无峰值带宽限制。

其次是操作方便，可以用FTP上传下载文件，也可以用其提供的API和开发包进行更多个性化的使用和操作。

再就是强大的后台统计功能，可以根据域名、空间及时间跨度进行灵活查看，并记录全网访问详细数据，可以进行数据分析使用。

当然，图片空间其实也是又拍云的一大亮点，不过由于这里由于我之前购买了又拍的图片管家服务， 这部分功能就暂且没有体验，不过从后台来看，与图片管家的功能几乎是一致的，缩略图、防盗链功能一应俱全，是非常实用的。

经过我的亲身体验，个人感觉不论是针对个人博客还是中大型网站，又拍云存储，都不失为加速访问，节约流量的一个不错的选择。
 

最近需要利用flume来做收集远端日志，所以学习一些flume最基本的用法。这里仅作记录。

远端日志收集的整体思路是远端自定义实现log4j的appender把消息发送到flume端，flume端自定义实现一个sink来按照我们的规则保存日志。

自定义Sink代码：

public class LocalFileLogSink extends AbstractSink implements Configurable {
     private static final Logger logger = LoggerFactory
              . getLogger(LocalFileLogSink .class );
            private static final String PROP_KEY_ROOTPATH = "rootPath";
      private String rootPath;
     @Override
     public void configure(Context context) {
          String rootPath = context.getString(PROP_KEY_ROOTPATH );
          setRootPath(rootPath);
     }
          
          @Override
          public Status process() throws EventDeliveryException {
           logger .debug("Do process" );
       ｝
}

实现Configurable接口，即可在初始化时，通过configure方法从context中获取配置的参数的值。这里，我们是想从flume的配置文件中获取rootPath的值，也就是日志保存的根路径。在flume-conf.properties中配置如下：

agent.sinks = loggerSink
agent.sinks.loggerSink.rootPath = ./logs

loggerSink是自定义sink的名称，我们取值时的key，只需要loggerSink后面的部分即可，即这里的rootPath。

实际业务逻辑的执行，是通过继承复写AbstractSink中的process方法实现。从基类的getChannel方法中获取信道，从中取出Event处理即可。

 Channel ch = getChannel();
            Transaction txn = ch.getTransaction();
          txn.begin();
           try {
               logger .debug("Get event." );
              Event event = ch.take();
              txn.commit();
              status = Status. READY ;
              return status;
                    ｝finally {
              Log. info( "trx close.");
              txn.close();
          }

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

在使用log4j2+slf4j的时候遇到这个错误提示，这不到类。在slf4j的官网有正好有相应的说明。需要添加依赖包

slf4j-api-1.7.5.jar slf4j-simple-1.7.5.jar

在Gradle的build.gradle配置文件种添加依赖

dependencies{
compile(
"org.apache.logging.log4j:log4j-api:$log4j_version",
"org.apache.logging.log4j:log4j-core:$log4j_version",
"org.slf4j:slf4j-api:$slf4j_version",
"org.slf4j:slf4j-simple:$slf4j_version"
)}

刷新工程。再次输出，问题解决。

实话说，不是正规解法，只是因为用的Java，利用里里面的API而已。仅供一笑了。

PS：代码是AC过的。

package com.coderli.acm.poj;

import java.math.BigDecimal;
import java.util.Scanner;

/**
 * Time Limit: 500MS Memory Limit: 10000K Description
 * 
 * 对数值很大、精度很高的数进行高精度计算是一类十分常见的问题。比如，对国债进行计算就是属于这类问题。
 * 
 * 现在要你解决的问题是：对一个实数R( 0.0 < R < 99.999 )，要求写程序精确计算 R 的 n 次方(Rn)，其中n 是整数并且 0 < n
 * <= 25。
 * 
 * Input T输入包括多组 R 和 n。 R 的值占第 1 到第 6 列，n 的值占第 8 和第 9 列。
 * 
 * Output 对于每组输入，要求输出一行，该行包含精确的 R 的 n 次方。输出需要去掉前导的 0 后不要的 0 。如果输出是整数，不要输出小数点。
 * 
 * Sample Input
 * 
 * 95.123 12<br&gt;
 * 0.4321 20<br&gt;
 * 5.1234 15<br&gt;
 * 6.7592 9<br&gt;
 * 98.999 10<br&gt;
 * 1.0100 12<br&gt;
 * 
 * Sample Output
 * 
 * 548815620517731830194541.899025343415715973535967221869852721
 * .00000005148554641076956121994511276767154838481760200726351203835429763013462401
 * 43992025569.928573701266488041146654993318703707511666295476720493953024
 * 29448126.764121021618164430206909037173276672
 * 90429072743629540498.107596019456651774561044010001
 * 1.126825030131969720661201
 * 
 * @author OneCoder
 * @blog http://www.coderli.com
 * @date 2013年10月14日 下午1:21:26
 */
public class Poj1001 {

	public static void main(String[] args) {

		Scanner input = new Scanner(System.in);
		while (input.hasNext()) {
			BigDecimal bdR = input.nextBigDecimal();
			int n = input.nextInt();
			for (int i = 0; i < n; i++) {
				
			}
			BigDecimal result = bdR.pow(n);
			// 去掉结尾无用的0
			String strResult = result.stripTrailingZeros().toPlainString();
			// 去掉开头的无用的0
			if (strResult.startsWith("0.")) {
				strResult = strResult.substring(1);
			}
			System.out.println(strResult);
		}
	}
}

在项目中需要自定义实现一个log4j的appender。根据log中MDC里的信息，构造日志存储的目录结构。自定义实现log4j appender的方法已经介绍过了。主要是覆盖AppenderSkeleton中的appender方法。

@Override
      protected void append(LoggingEvent event) {
           this .logEvent = event;
     }

日志内容的获取和格式处理，通过Layout进行格式化

this .getLayout().format(event).getBytes( DEFAULT_CS )

这里有个问题，一般情况下，我们常用的org.apache.log4j.PatternLayout是不会处理异常堆栈的。因为，其内部的方法，返回的是true。

public  boolean ignoresThrowable () {
    return true ;
  }

在这种情况，如果你的日志里有异常对象，如logger.error(“错误信息。”, e) 那么e将会被忽略。这时候需要我们自己处理。处理方式如下：

if (layout .ignoresThrowable()) {
      String[] s = event.getThrowableStrRep();
      if (s != null ) {
      int len = s. length;
      for( int i = 0; i < len; i++) {
           // 处理异常堆栈，比如记录到日志文件中
     }

从Maven切换到Gradle，原有的几G的本地缓存库当然想继续使用。在用户手册中找到了答案。在50.6.3章节。

如果想使用Maven本地缓存，需要定义：

repositories {
    mavenLocal()
}

Gradle使用与Maven相同的策略去定位本地Maven缓存的位置。如果在settings.xml中定义了本地Maven仓库的地址，则使用该地址。在USER_HOME/.m2下的settings.xml文件中的配置会覆盖存放在M2_HOME/conf下的settings.xml文件中的配置。如果没有settings.xml配置文件，Gradle会使用默认的USER_HOME/.m2/repository地址。

现在我们来看一个典型的多项目构建的例子。下面是工程的布局：

样例7.10 多项目构建 - 分层布局

构建结构

multiproject/
 api/
 services/webservice/
 shared/

注意：本样例的代码可以在Gradle完整安装包的samples/java/multiproject目录下找到

这里我们有三个工程。api工程生成用于Java客户端访问XML webservice服务的JAR包。webservice工程是一个web应用，用于返回XML信息。shared工程包含了api和webservice工程共同使用的代码。

7.3.1 定义一个多项目构建

为了定义一个多项目构建，你需要创建一个配置文件(settings file)。该配置文件存放在源码树的根目录，指定了哪些项目需要包含在构建任务之中。该配置文件必须命名位settings.gradle。在本例中，我们使用一个简单的层次布局。下面是相关的配置文件：

样例7.11 多项目构建 - settings.gradle 文件

include "shared", "api","services:webservice", "services:shared"

更多关于配置文件的信息，可在第56章的多项目构建中找到。

7.3.2 常用配置

对于大多数的多项目构建来说，有一些对所有项目都常用的配置。在我们的样例中，我们使用一种叫做配置注入的技术，将这些通用配置定义在根项目中。这里，根项目就像一个容易，子项目在这种情况下覆盖了该容器中的元素 - 并注入了特殊的配置。这样，我们可以轻松的给所有归档定义清单内容和一些通用的依赖:

样例7.12 多项目构建 - 通用配置

subprojects {
    apply plugin: 'java'
    apply plugin: 'eclipse-wtp'
    repositories {
       mavenCentral()
}
    dependencies {
        testCompile 'junit:junit:4.11'
}
    version = '1.0'
    jar {
        manifest.attributes provider: 'gradle'
} }

注意到，我们的样例对每个子项目都应用Java插件。这意味着我们在之前部分看过的任务和配置属性对每个子项目都是可用的。因此，你可以通过在项目根路径执行gradle build命令给所有的工程进行编译，测试并打成JAR包。

7.3.3 项目间依赖

你可以在同一个构建中增加项目间的依赖，例如，一个项目的JAR包被用于另一个项目的编译。在api项目的构建文件中，我们将增加一个对shared工程JAR包的依赖。由于这个依赖的存在，Gradle将会确保shared工程总是在api项目之前先进行构建。

样例7.13 多项目构建 - 项目间依赖

dependencies {
    compile project(':shared')
}

关于如何关闭该功能，可参见第56.7.1章节的”关闭依赖项目的构建”部分。

7.3.4 创建一个分支

我们可以增加一个分支，用于打包给客户端使用：

样例7.14 多项目构建 - 分支文件

task dist(type: Zip) {
    dependsOn spiJar
    from 'src/dist'
    into('libs') {
        from spiJar.archivePath
        from configurations.runtime
    }
}
artifacts {
   archives dist
}

7.2 一个基本的Java项目

我们来看一个简单的例子。把下面的代码加入你的构建文件，以使用Java插件：

例子 7.1 使用Java插件

build.gradle
apply plugin: 'java'

注意：该样例的代码可在Gradle的安装包中的samples/java/quickstart路径下找到。

这就是你定义一个Java项目所需要做的一切。这就会在你项目里使用Java插件，该插件会给你的项目增加很多任务。

Gradle期望在src/main/java路径下找到你项目的源代码，并且测试在src/test/java路径下的代码。同时，在src/main/resources路径下的文件也会作为资源文件包含在JAR包中，并且src/test/resources下的所有文件会包含在classpath下以运行测试程序。所有的输出文件都生成在build目录下，JAR包生成在build/libs目录下。

7.2.1 编译项目

Java插件给你的项目构建增加很多任务。然而，只有屈指可数的任务你将会在构建项目的时候用到。最常用的任务是build任务，该任务会对项目执行完整的编译。当你运行gradle build的时候，Gradle会编译并测试你的代码，然后生成一个包含类和资源文件的JAR包。

例7.2 构建Java项目</div>

gradle build输出

> gradle build
:compileJava
:processResources
:classes
:jar
:assemble
:compileTestJava
:processTestResources
:testClasses
:test
:check
:build
BUILD SUCCESSFUL
Total time: 1 secs

其他一些有用的任务是：

clean
     清空build编译目录，删除所有构建文件。

assemble
     编译并给你的代码打包，但是不执行单元测试。其他的插件为本任务增加更多的特性支持。例如，如果你使用War插件，那么该任务也会给你的项目编译出War包。

check
     编译并测试代码。其他的插件会对该任务提供更多检测支持。例如，如果你使用Code-quality插件，那么该任务会同时对你的代码执行Checkstyle检测。

7.2.2 外部依赖

通常，一个Java项目会依赖一些外部的JAR文件。为了在项目中引用这些JAR文件，你需要告诉Gradle哪里可以找到它们。在Gradle里，JAR包等资源放在资源库（repository）中。资源库可以用来查找项目的依赖，也可以用于发布项目归档。在这个样例中，我们将使用公共的Maven库：

样例7.3 添加Maven库

repositories {
    mavenCentral()
}

我们来添加一些依赖。这里，我们会声明我们产品的类有在编译期依赖于commons collections，同时我们的测试类在编译期依赖于junit:

样例7.4 添加依赖

dependencies {
       compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
       testCompile group: 'junit', name: 'junit', version: '4.+'
}

更多的内容，可在第八章的依赖管理基础中找到。

7.2.3 自定义项目

Java插件给你的项目添加了许多属性。这些属性都有默认值，并且通常情况下这些默认值足以满足使用。如果这些值不满足要求，那么修改起来也是很容易的。我们来看一下例子。这里，我们将指定Java项目的版本号，同时指定我们编写代码所使用的Java版本。我们也会在JAR包的描述清单中(manifest)增加一些属性。

样例7.5 自定义MANIFEST.MF

sourceCompatibility = 1.5
   version = '1.0'
   jar {
       manifest {
           attributes 'Implementation-Title': 'Gradle Quickstart', 'Implementation-Version': versi
} }

Java插件添加的也是规则的任务，如果把它们声明在构建文件里也是完全一样的。这就意味这，你可以使用任何之前章节中介绍的机制去自定义这些任务。例如，你可以设置任务的属性，给任务增加行为，修改任务的依赖，或是完全的替代任务。在我们的样例中，我们将要配置test任务，该任务的类型是Test，当测试执行的时候增加一个系统属性：

样例7.6 增加一个测试系统属性

test {
    systemProperties 'property': 'value'
}

7.2.4 发布JAR包</div>

通常，JAR包需要被发布到某个地方。为了完成这个功能，你需要告诉Gradle把JAR包发布到哪里。在Gradle中，如JAR之类的压缩包都被发布到库中。在我们的样例中，我们将会发布到本地仓库。你也可以发布到一个或多个远端地址。

样例7.7 发布JAR包</div>

uploadArchives {
    repositories {
       flatDir {
           dirs 'repos'
} }
}

执行gradle uploadArchives命令以发布JAR包。

7.2.5 创建Eclipse工程</div>

为了把你的项目导入到Eclipse，你需要在构建文件中增加其他插件：

样例 7.8 Eclipse 插件

apply plugin: 'eclipse'

现在执行gradle eclipse命令以生成Eclipse工程文件。更多关于Eclipse任务可以在第38章 Eclipse插件中看到。

7.2.6 概要

下面是完整的构建文件的样例：

样例7.9 Java样例-完整构建文件

   apply plugin: 'java'
   apply plugin: 'eclipse'
   sourceCompatibility = 1.6
   version = '1.0'
   jar {
       manifest {
           attributes 'Implementation-Title': 'Gradle Quickstart', 'Implementation-Version'
   } }
  repositories {
       mavenCentral()
  }
   dependencies {
       compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
       testCompile group: 'junit', name: 'junit', version: '4.+'
  }
   test {
       systemProperties 'property': 'value'
   }
   uploadArchives {
       repositories {
          flatDir {
              dirs 'repos'
          } 
      }
  }