一堆踩过的坑,吐血

一、Spring Data Redis 1.1.1

1. 简而言之别用这个库. Jedis就够用.
2. ListOperations<String, String> ＝ StringRedisTemplate 存数据时没问题，但如果用RedisTemplate<String, String>时，保存的key是乱码。直接用那个DefaultRedisConnection。不过整个Spring Data Redis其实没什么意义，不如直接用Jedis，但Jedis的连接池有问题，如果出错时return资源要用returnBrokenResource而不是returnResource，否则用同一个Jedis再次发指令时会出错。
3. 当使用jedis引擎时必须依赖jedis包，但Reference里没写。
4. Spring Data Redis 1.1.1依赖的是jedis 2.1.0，且需要使用commons-pool 1.6（jedis 2.4.1不兼容，因为换用commons-pool 2.2）

 

二、Spring Framework 4.0.2

1. 在多个Config里（包括Annotation和XML）指定多个properties文件定义时，加载是按最后一个定义的文件来读，前边的文件会被忽略，导致使用${"abc"}来读属性时会出错。
2. context:component-scan遍历逻辑是先下层目录(子优先遍历)，再到根目录来读.根目录下如果有@Configation定义,对应的properties文件会被读取，但初始化时又先按子目录优先来初始化。导致下层目录的@Configation定义的properties文件读不出.最终初始化可能会失败.
3. 设置了task:scheduler但没task:executor时，如果任务线程执行较慢或挂起，fixdelay的任务会无限创建新线程。建议设置task:executor 的 rejection-policy="CALLER_RUNS"

 

三、ActiveMQ 5.9.0

1. 此版本未解决发送超时，当连接成功之后，发送前如果把ActiveMQ进程kill掉，整个Client线程就挂起很长一段时间。
2. ActiveMQ的协议文档里，一些参数都要加上"transport."为前缀，实际上程序根本不认，需要去掉这个前缀才不会报错。
3. 一堆超时设置没发现什么用，包括soWriteTimeout,soTimeout,connectionTimeout=1000。如果直接把ActiveMQ直接退出之后，线程就一直挂起。实际生产时如果网线有问题或机架掉电,程序会挂起1小时以上没反应.
4. 简单的轮循消息队列建议用Redis实现，真心吞吐量大N倍。如果怕队列因为掉电丢失，可以多用save或bgsave指令要求立即保存数据，不过会降低性能。

 

四、HTMLUnit 2.14

1. 神奇且强大的东东,基本就是无界面的浏览器,现在对特殊javascript库(比如修改过的jquery之类)的支持还有问题,其它已经比较完善了.
2. QQ空间上JS写入的iFrame不能用任何方法正确拿到Frame并访问其属性。使用 BrowserVersion.FIREFOX_24 可以拿IFrame,但没有src和id属性,估计是JS未正确执行.请有研究的同学分享一下解决方案.
3. JS执行是新开Runnable线程，所以用JMX监控时会一直增加，影响对其它问题的判断。没有解决方案. 现时使用 common-pool2 来控制 ,可有效减少线程持续增加.

 

五、Redis Win64 2.6.12

1. redis-cli不支持utf-8的数据,好像Linux版也不支持
2. 和VMWare似乎有冲突,VMWare打开之后连接就出错。
3. 这个windows版稍长时间运行不太稳定,响应好像会变慢,暂未确定原因.
4. 按新浪的经验,由于redis是单线程,但由于hget较慢,导致调用hget时其它请求挂起时间较长,可能会导致问题.新浪的方案是hget都由memcache档一层.

 

六、Redis Desktop 0.7.5

1. 不能使用script功能
2. select N 之后不会立即改变提示符,但不影响操作.

 

六、ADT 22.6

1. 在eclipse内不能新建AVD。解决方法是在android-sdks ools目录下运行android.bat avd，出现AVD管理界面后再创建，所创建的AVD需要重启Eclipse才能看见。新版已解决此问题.

 

七、Gradle

　　1.  版本号自动拿最新的方式是只写"+",而不是现在网上一大堆0.9.+这种写法,那样只匹配 0.9.1~0.9.X.同样的写法可应用于dependencies,不过考虑到稳定性,建议dependencies使用精确的版本号.

buildscript {
    repositories {
        maven { url 'http://dl.bintray.com/populov/maven' }
           mavenCentral()
        mavenLocal()
    }

    dependencies {
        classpath 'com.android.tools.build:gradle:+' //注意这里没写版本号
    }
}

　　2.  同时使用apply plugin: 'android' 和 apply plugin: 'eclipse' 的话,执行gradle eclipse并不能正常生成项目目录结构,因为0.9.X的android插件未优化,不能正确生成.classpath和.project文件.而是按照默认的apply plugin: 'java' 来生成的.

　　3.  超多人在新手介绍文章都没提到的内容,我废了超多时间查资资料,哭啊 : 需要在文件根下增加repositories才能正确拿到jar或aar库!buildscript里的repositories不起作用的! F U C K!

repositories {
    maven { url 'http://dl.bintray.com/populov/maven' }
    mavenLocal()
    mavenCentral()
}

dependencies {
       compile 'com.android.support:appcompat-v7:19.1.+'
       compile 'com.android.support:support-v4:19.1.+'
       compile 'com.squareup.wire:wire-runtime:1.3.3'
       compile 'com.tonicartos:stickygridheaders:1.0.1'
       compile 'com.viewpagerindicator:library:2.4.1@aar'
       compile 'com.alibaba:fastjson:1.1.34.android'
       compile 'org.apache.httpcomponents:httpclient-android:4.3.3'
       
    //compile fileTree(dir: 'libs', include: '*.jar')
}

八、Gradle Eclipse 集成(Eclipse Kepler 4.3+STS 3.5)

1. Dependency management 无效,导致Gradle Dependencies 在package explorer不显示, 且build.gradle增加的dependencies在classpath找不到. 只能手动把jar放到libs目录或使用lib project.
2. 现在我调试时使用lib目录下的包,编译速度比较快. 但正式测试时使用gradle来build并install到测试机器.

九、Maven Android Eclipse 集成(Eclipse Kepler 4.3 + STS 3.5 + Android m2e 1.0 + maven-android-sdk-deployer)

1. 不建议使用,比gradle需要多写一大堆,而且整合后的环境还有较多问题 . 不知道未来是否会优化到java环境同一个水平.
2. 优点:
   1. 相对gradle支持Dependency management 对classpath的修改,使得Eclipse开发时可以不需要维护libs目录下的库.
   2. 插件比较丰富,比如wire和protostuff都有maven的代码生成插件,从工程角度比gradle的自动化程度要好一点点.但作用不大.
   3. 由于历史悠久,网上资料多一些.
3. 缺点:
   1. 常见gradle优于maven的地方: XML配置文件不便于阅读, 代码行数多.google官方支持gradle构建.
   2. eclipse 集成还需要加dependencyManagement才可以不报错,虽然可以自动生成,但增加了一大段内容,不利维护.主要是Android m2e 1.0不够成熟.
   3. maven-android-sdk-deployer并不完善,使用默认的install一般不能正常跑完,需要进入到子目录分步install.而且复制了很多SDK的文件,占用硬件空间.且此deployer的库命名规则随版本演进有变化,不利于长期使用.

十、Resin 4.0.X

1. UTF-8问题，Windows下任何修改配置的方式都没效，在不修改系统默认编码时，解决方案如下：
   1. 普通HTML的UTF-8问题,可以解决: 另存为UTF-8带BOM的格式(无BOM就会乱码), 并以<?xml version="1.0" encoding="UTF-8" ?>开头
   2. Java程序的UTF-8问题：需要修改起动器。分二种情况：
      1. Eclipse Debug环境，需要修改eclipse.ini，在结尾增加 -Dfile.encoding=UTF-8
      2. 普通Windows运行环境，需要在运行时加参数：resin -Dfile.encoding=UTF-8 start

 十一、Jersey 

1. 返回byte[],String之类不带Content-Length,需要返回自定义Response才能解决.代码见下.
2. UTF-8问题,代码见下.

    @GET
    @Path("book")
    public Response getBook( @QueryParam("uri") String bookURI ){
        byte[] result= dao.loadBook(bookURI);
        
        if (result == null)
            throw new NotFoundException(bookURI);
        return Response.ok(result, "application/x-protobuf;charset=UTF-8")
                       .header("Content-Length",result.length)
                       .build();
    }