As a server guy for a long time, I would like to have my code running on any device that has a JVM on it.

And recently, I just bought a small but wonderful Buffalo NAS box for my precious photos and stuffs like this at home. Previously, I had a lot of fun with a similar home/small office NAS product, the WD’s My Book World edition, but with very limited CPU and memory when compared with Buffalo’s model(200Mhz CPU, 32MB RAM vs 1.6G CPU, 256M RAM), it can only host a PHP environment on it. This time, by instinct, I am looking around to see if I can put a more useful server environment, specifically, the JAVA technology, on it.

The first step is to gain root access of the box, like all other devices if you want to hack it. Google is always my best friend on it. Without much effort, I found a wonderful and dedicated hacker community for my NAS box, following the steps, scratched my head several times, and bingo!, my lovely “#” was dancing on my screen.

The next thing to check is the CPU architecture of the box. It turns out it has an ARMv5 based CPU. Honestly, I didn’t expect there is such a build for this quite old and feature limited CPU architecture from the beginning, but it turned out there is one: 

ARMv5 Linux - Headless EABI, SoftFP ABI, Little Endian

Just for record, here is the actual JVM version output:

root@LS-WVLF5E:~# java -version java version “1.7.0_21” Java(TM) SE Embedded Runtime Environment (build 1.7.0_21-b11, headless) Java HotSpot(TM) Embedded Client VM (build 23.21-b01, mixed mode)

Then, the database server staff. The Buffalo box is shipped with a quite old 5.0.x MySQL server inside, and at first, I wanted to replace it with a newer community package using optware. After trying hard but still failed to start the new server, I reluctantly started and tested the build-in MySQL server. It turned out working quite stable and also has InnoDB engined built-in. After a little tweak, the database part is ready.

Almost done.

I dropped a pre-build server package(a J2EE application using Spring, Hibernate and all the hot stuff you named it) an an Apache Tomcat package into the NAS, modified the application’s settings accordingly, started the server, then watched the log output scrolling on my screen.

It works!

But, with a lot exceptions popping out … This time, it turned out it was caused by the JVM.

The embedded edition of ARMv5 architecture is shipped with very limited character set support, but my application have to deal with Asian languages, so it failed loudly with all the exceptions popping out. By comparing the library folder of different versions of JRE(a standard one and the embedded one), I found out that “charset.jar” was missing. My good luck again!

After putting back the missing jar file, restarted the server, everything ran as smoothly as it could.

Now, the noise from the harddisks of the NAS box happily reminds me that,  my crawlers have pulled back another batch of new data.

Nice!

国内的开发者，学习和使用基于互联网的自动化开发工具，从基本的svn、git, 到复杂点的Ivy、Maven，总会因为“墙”的存在，不时的遇到各种访问故障，要么无法访问相关资料，要么软件系统失效，学习失败。

本是在学习新事物，但是教程对不上，手册中也没有针对性的线索的解决方法，在耗费大量时间的同时，挫折感也油然而生，非常容易导致对项目和工具本身软件质量的怀疑。

从大约10年前接触各种开源软件开始，多次经历到这种情况。开始不知“墙”为何物，到习以为常，曾窃以为熟悉了“墙”的脾气，躲不起可以绕的起；但是无奈的事实是，总在最不可思议的地方，这影子般的存在，会挖下一个个大坑，吞噬着宝贵的时间和精力。

拜这无所不在的“墙”所赐，这坑，不知明天还会出现在何处。

今日，在消耗了大半天后，才突然意识到，自己是又一次的落坑了。

愤懑的拿出烂笔头，希冀这一次次爬出坑的醒悟，能慰藉一下身不由已的落坑同行们；若还能隐隐约约的起到警示牌的作用，则更妙了。

无法访问、或访问会时好时坏的常用网站

• SourceForge：间歇性的无法访问。
• Google：Google的服务，没有不受影响的，特别是Google Code和Google Group，这几个是重灾区，但是有些活跃的项目却只能在上面找到。
• “推”和“脸谱”：不用提了，他们在国内不存在。
• Stackoverflow Stackexchange系列网站：由于使用了Google和以上一些网站的Social服务，会间歇性故障。
• 各国外视频类网站：视频教程也不用奢望了。
• 邮件讨论组，IRC存档类网站：虽然很多开发者的讨论信息能在这里搜索到，但是基本上国内都是无法访问的。

下面这些自动化工具的故障会隐蔽的多，排查起来也费事的多。

• 代码管理工具：svn,git,mercury等等。这些代码版本控制工具，如果检出代码时，对方提供的是HTTP访问接口，很可能由于代码或者资源地址中存在关键字，部分拦截或被篡改，导致最终项目编译、集成失败。最佳的解决方法是使用安全加密隧道，例如svn+ssh, git+ssh；但是如果无法获得这些服务，折衷的方案就是只能使用代码压缩包了。
• 项目编译工具：开源社区中最常用的Maven（包括同门的Ivy）影响最大，也最不明显。这些工具都需要访问互联网，自动下载大量代码和插件。如果对应资源标识或自身就包含敏感关键字，就会下载失败，导致项目编译失败。例如，Apache，Spring Framework旗下的很多邮件处理相关的子项目，由于包含mail关键字，基本上都会碰到无法下载的故障。由于出错信息多为“无法满足的依赖关系”，同正常项目失败信息相同，所以很容易导致故障分析错误。
• 操作系统自动更新：正式部署时，一般会先检查系统更新。此时也可能由于以上类似的原因，导致更新无法开始或者中途失败。这些故障的排查，也只能通过阅读日志排查，检查是否有超时和链接重置的故障提示。