Captor

导航

 

一、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\tools目录下运行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();
    }

 

posted on 2014-04-28 11:14  Captor  阅读(2225)  评论(0编辑  收藏  举报