ghs的又一个IP被封了
上周，Google的Blogger被封了，至今未解禁。今天，我的博客无法通过绑定的域名访问，当然，估计一大片绑定域名的GAE应用访问不了，比如xuming.net。看来GFW在搞大动作啊，唉，可怜的中国网民。
昨天我的这个博客还是可以通过域名blog.shoopman.org来访问的，今天一早却访问不了。一开始以为是公司网络太差了，但还是尝试了Google App Engine送的域名shoopmanlog.appspot.com来访问，没有问题，由此确定，又一个ghs的IP被GFW干掉了。
GFW是强大的，但中国网民的智慧更是强大，我在xiao3meng这里找到了一个ghs的IP，马上到GoDaddy的域名管理里去重新设置了A记录，现在就是在等待域名解析生效了。如果你是通过blog.shoopman.org看到了这篇文章，那说明域名解析已经生效了。如果以后再出现访问不了的问题，那就先试试用shoopmanlog.appspot.com这个域名来访问吧。
该评论已关闭—-已成最新网络流行语
在盗盗的Twitter上看到一个“如何迅速了解近期国内发生的敏感事件？——请用Google”该评论已关闭”。点那连接一看，果然Google的搜索结果里基本上都是很敏感的事情，不信？点这试试！ 不得不佩服中国网民的智慧。至于为什么，还是继续问一下Google吧，http://www.google.cn/search?hl=zh-CN&newwindow=1&q=%E8%AF%A5%E8%AF%84%E8%AE%BA%E5%B7%B2%E5%85%B3%E9%97%AD&meta=&aq=f&oq。
SpringSide的网站怎么又访问不了了？
SpringSide还在1.x的时候，有个同事就比较推崇它，而后就断断续续的关注一下，不过也只是远观，并没有花什么精力研究。前一年多的时间里，工作主要是在Eclipse RCP上，也就没有再逛SpringSide。最近换了工作，重拾Java Web开发，于是又开始研究SpringSide。此时，SpringSide3.0都已经发布了。真是应该感谢SpringSide给我们提供的集成那么多Java主流框架的例子与经验。
一边看SpringSide的代码，一边在考虑能否把SpringSide应用到项目当中，便时不时在网上查看SpringSide的Wiki，可前几天却发现，SpringSide网站却访问不了了，到现在还没有恢复。SpringSide创始人江南白衣在JavaEye的博客里，最后发表的文章已经是4月初的了;JavaEye论坛里也没见这次SpringSide网站问题的讨论，却我却看到了去年3月份SpringSide网站也曾经访问不了。希望SpringSide能像去年一样，重新站起来啊，要不然，万一在应用SpringSide的过程中遇到问题，还不好解决呢。期望SpringSide回归！
PS. 昨晚发现满江红开源组织的网站（http://www.redsaga.com）也访问不了，才记起SpringSide的网站空间是由满江红提供的。同样感谢满江红为我们翻译那么多高质量的文档，也同样的期望满江红早日回归！
Spring @Autowired 的使用问题
最近小小的在研究一下SpringSide3的代码，并对照着它的mini-web示例项目开始了测试。开始还是比较顺利的， mini-web在tomcat6 + mysql5里跑起来了，测试用例也没有问题，于是开始动手改造。
但是改了一下，再运行UserManager的测试用例，却报了以下错误：
[main] ERROR org.springframework.test.context.TestContextManager – Caught exception while allowing TestExecutionListener [org.springframework.test.context.support.DependencyInjectionTestExecutionListener@1904e0d] to prepare test instance [testCreate(cn.cu.manager.UserManagerTest)]
org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘cn.cu.manager.UserManagerTest’: Autowiring of fields failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private cn.cu.manager.user.UserManager cn.cu.manager.UserManagerTest.userManager; nested exception is java.lang.IllegalArgumentException
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessAfterInstantiation(AutowiredAnnotationBeanPostProcessor.java:243)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:959)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireBeanProperties(AbstractAutowireCapableBeanFactory.java:329)
at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:110)
at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:75)
at org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:255)
at org.springframework.test.context.junit38.AbstractJUnit38SpringContextTests.runBare(AbstractJUnit38SpringContextTests.java:183)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: org.springframework.beans.factory.BeanCreationException: Could not autowire field: private cn.cu.manager.user.UserManager cn.cu.manager.UserManagerTest.userManager; nested exception is java.lang.IllegalArgumentException
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:435)
at org.springframework.beans.factory.annotation.InjectionMetadata.injectFields(InjectionMetadata.java:105)
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessAfterInstantiation(AutowiredAnnotationBeanPostProcessor.java:240)
… 16 more
Caused by: java.lang.IllegalArgumentException
at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:63)
at java.lang.reflect.Field.set(Field.java:656)
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:431)
… 18 more
只得到网上找答案，未果，不过还是找到了点有价值的东西：
不使用自动装配。必须通过ref元素指定依赖，这是默认设置。由于显式指定协作者可以使配置更灵活、更清晰，因此对于较大的部署配置，推荐采用该设置。而且在某种程度上，它也是系统架构的一种文档形式。
byName 根据属性名自动装配。此选项将检查容器并根据名字查找与属性完全一致的bean，并将其与属性自动装配。例如，在bean定义中将autowire设置为by name，而该bean包含master属性（同时提供setMaster(..)方法），Spring就会查找名为master的bean定义，并用它来装配给master属性。
byType 如果容器中存在一个与指定属性类型相同的bean，那么将与该属性自动装配。如果存在多个该类型的bean，那么将会抛出异常，并指出不能使用byType方式进行自动装配。若没有找到相匹配的bean，则什么事都不发生，属性也不会被设置。如果你不希望这样，那么可以通过设置dependency-check="objects"让Spring抛出异常。
constructor 与byType的方式类似，不同之处在于它应用于构造器参数。如果在容器中没有找到与构造器参数类型一致的bean，那么将会抛出异常。
autodetect 通过bean类的自省机制（introspection）来决定是使用constructor还是byType方式进行自动装配。如果发现默认的构造器，那么将使用byType方式。
———————————————————————————-
理解自动装配的优缺点是很重要的。其中优点包括：
自动装配能显著减少配置的数量。不过，采用bean模板也可以达到同样的目的。
自动装配可以使配置与java代码同步更新。例如，如果你需要给一个java类增加一个依赖，那么该依赖将被自动实现而不需要修改配置。因此强烈推荐在开发过程中采用自动装配，而在系统趋于稳定的时候改为显式装配的方式。
自动装配的一些缺点：
尽管自动装配比显式装配更神奇，但是，正如上面所提到的，Spring会尽量避免在装配不明确的时候进行猜测，因为装配不明确可能出现难以预料的结果，而且Spring所管理的对象之间的关联关系也不再能清晰的进行文档化。
对于那些根据Spring配置文件生成文档的工具来说，自动装配将会使这些工具没法生成依赖信息。
如果采用by type方式自动装配，那么容器中类型与自动装配bean的属性或者构造函数参数类型一致的bean只能有一个，如果配置可能存在多个这样的bean，那么就要考虑采用显式装配了。
尽管使用autowire没有对错之分，但是能在一个项目中保持一定程度的一致性是最好的做法。例如，通常情况下如果没有使用自动装配，那么仅自动装配一个或两个bean定义可能会引起开发者的混淆。
想了想自己对mini-web的改造经过，觉得可能问题出在一个接口上面：我把EntityManager提出了个接口IEntityManager
Google App Engine Java SDK 1.2.1 发布
Google App Engine Java SDK 1.2.1在5月13号发布了。这是Google App Engine 宣布支持Java语言以来，首次SDK更新。
SDK更新内容如下：(来自SDK项目WIKI)
- Added validation of appengine-web.xml, cron.xml, and datastore-indexes.xml.
- New <user-permissions> element added to appengine-web.xml to grant custom third-party permissions (e.g. OgnlInvokePermission).
- Support for unindexed datastore properties of arbitrary types.
- Added HTTP Proxy support to appcfg.sh.
- Response limit raised from 1MB to 10MB
JDO/JPA Changes
- Fix handling of user-defined @Order
tring pk
用SkyDrive当作博客的外链图片
原来是使用Google免费的Picasa相册来存放博客中的图片，但由于图片外部连接获取较麻烦，而且对外链的图片大小也有所限制，所以现在已经把照片转移到Windows Live的SkyDrive上来。
SkyDrive是Windows Live的一项服务，申请一个Windows Live ID就可以享用25G网络硬盘，单个文件最大是50M，支持外链，还可以设置共享模式。不过，相对而言，SkyDrive的下载速度是要比Picasa的慢一些。
下面是SkyDrive的介绍：
在 Windows Live 服务器上免费存储、管理和下载文件、照片和收藏夹 (表示收藏的网站，其网址保存在计算机或联机服务器上，以便您方便快捷地进行访问。) 。在 Windows Live 网络 (用户在 Windows Live 中与之交流和共享信息的一群人。用户的网络包括添加到个人资料中的联系人、添加到 Messenger 中的联系人或同时添加到这两者中的联系人。用户网络中的联系人可以在最近更新列表中看到有关该用户最近活动的信息，也可以看到其他信息，这取决于权限设置。) 上与朋友共享您创建的照片和文件、合作完成文档，或向所有人显示您创建的照片和文件。使用 Windows Live ID (您用于登录 Windows Live 程序和服务（如 Windows Live Hotmail 和 Windows Live Messenger）、Microsoft 服务（如 Xbox LIVE、MSN 和 Office Live）以及任何其他显示 Windows Live ID 徽标的站点的电子邮件地址和密码。) 登录 Windows Live SkyDrive 网站后，您可以执行以下操作：
- 存储空间：最多存储 25 GB 的照片和文件。SkyDrive 存储空间指示器会显示您已使用的存储空间。
- 文件管理：在您创建的顶层文件夹 (在 Windows Live SkyDrive 主页的“文档”、“收藏夹”或“照片”部分显示的文件夹。也称作根文件夹。) 和子文件夹 (在顶层文件夹中创建的文件夹。) 中管理您的文件。
- 权限控制：为您创建的每个顶层文件夹选择权限 (允许您限制哪些人能够查看和下载文件夹中的文件的一种设置。) 。如果将您的照片、文件和收藏夹存储到个人文件夹 (只有您可以查看或编辑该顶层文件夹中的文件。您可以使用个人文件夹存储个人文件。) 中，只有您可以访问这些文件；如果保存到共享文件夹 (只有您和您选择的联系人可以查看该顶层文件夹中的照片或文件。对于您允许访问该顶层文件夹的每个人，您可以授予他们读者或编辑者的角色。) 中，您可以与您的 Windows Live 网络、扩展网络 (Windows Live 上您网络中的联系人，包括您的 Windows Live Messenger 和个人资料联系人以及您网络中联系人的个人资料联系人。) 以及联系人列表 (包含每个联系人的姓名和电子邮件地址的列表。) 中的联系人共享这些文件；如果保存到公共文件夹 (Internet 上的任何人都可以查看该顶层文件夹中的照片和文件，但只有您可以编辑这些照片和文件。) 中，Internet 中的所有人都可以查看这些文件。
- 方便：即使您使用其他人的计算机，也可以追踪您最喜爱的网站。
- 灵活：可以上载任何大小不超过 50 MB 的照片和文件，而且上载后，您可以移动、复制、删除和重命名您的照片或文件，还可以为其添加标题。
- 显示：以 JPG、JPEG、GIF、BMP、PNG、TIF 和 TIFF 文件格式 (使用文件名的最后三个字母（称为文件扩展名）表示文件类型，在计算机上存储信息的标准方式。不同程序使用的文件扩展名不同。.) 存储的照片可以缩略图 (图像的缩略版或页面的电子版，通常用于快速浏览多个图像或页面。) 方式显示，并且具有访问权限的用户可以通过 SkyDrive 或以联机幻灯片的形式查看这些照片。
- 共享：共享指向文件夹、文件和照片的链接，或者将照片和文件嵌入您的日志 (weblog 的简写 (blog)。它是一种联机日志。日志中通常包含个人想法和网络链接，最新的日志显示在最上端。) 或网页。您还可以通过添加人物标签 (附加到照片上的文本数据，通过标识照片中的人来说明照片的定义和意义。) 让其他人知道您在 SkyDrive 中添加了他们的照片。
终于不用耳机也能听到Dell本本的声音了
Windows7在我的Dell 1400安装起来后，几乎不用再手工安装驱动就能使用了：主板驱动、网卡驱动、无线网卡驱动、N合一的读卡器驱动都安装起来了，而且运行正常；至于显卡驱动，在Windows7自动更新后也安装了新的驱动—-NVIDIA GeForce 8400M GS (Prerelease – WDDM 1.1)。遗憾的是声卡驱动，虽然安装起来了，但只有接耳机才能听到声音，而本本本身的扬声器却没有声音。
在Dell技术论坛里找到了同病相怜的兄弟，并按里面的回复，从Dell官方网站上下载了Windows Vista 32位的声卡驱动，安装并重启后，终于不用耳机也能听到声音了。
从Windows XP(32位) 升级到了Windows7 (64位)
Windows7 RC版5月5日正式发布了，上周五回到家里，决定还是下载一个64位的来安装试试：
- 首先，一直都是使用盗版的Windows操作系统，这个Windows7 RC好歹是免费的嘛，还可以自动更新。据说这个版本只能使用到2010年6月1日，而且从2010年3月1日起，每两个小时自动重启。不过，到那个时候，破解补丁之类的应该出来了吧，或者大不了重新安装其他版本的Windows7或者退回到Windows XP嘛。
- 其次，采用64位的原因是打算把我的 Dell Vostro 1400 内存加到4G，用64位操作系统就不用浪费内存了，也不用找其他软件来识别4G内存。我的Dell 1400 CPU是Intel T7250，这下总算发挥更多作用了；而现在只有一根2G的金泰克DDR2 667的内存在撑着，原来的Windows XP在被我安装了一大堆杂七杂八的软件后，跑得已经比较吃力了。
经过ADSL 17小时的拼搏，Windows7 RC Ultimate 64bit总算在第二天下午下载完毕。虽然国内BT、迅雷等已经有了N个版本的下载，有些还有中文语言包或者号称简体中文版的，但为了不白费功夫，我还是决定从微软官方下载英文版，到时可以顺便联系一下英语嘛，哈哈！官方的下载页面在http://www.microsoft.com/windows/windows-7/download.aspx，下载时可以用Windows Live帐号登录，或者注册一个Windows Live帐号，比较简单。
为了避免安装失败后影响工作，我先通过WinPE把原来的XP备份了，然后加载Windows7的ISO，运行setup.exe，提示“不是32位程序”！汗，发晕了，我的Windows7是64位的嘛。赶紧切回Windows XP，上网找一下硬盘安装Windows7的办法（虽然Dell 1400有刻录DVD光驱，但我却没有DVD光盘，清苦的日子啊）：http://bbs.vista123.com/thread-132461-1-1.html，按照这个帖子里的第一个办法，即是用Nt6 hdd Installer来安装。我的安装过程居然用了一个小时，以至在安装过程中想重启了，但最终还是忍住了。一般来说，Windows7的全新安装只需要十多二十分钟，后来在Dell 1420上的安装就只用了20分钟。
安装完成后就是使用了。界面当然是漂亮得没话说，但是内存吃得也够多的了，裸机就使用了700多M。由于没有使用过Windows Vista，直接从Windows XP 过渡到 Windows7，一下子当然不适应，而且又是英文版的，对我的小半吊子英语来说太高深了，就算我有看软件帮助及说明的习惯，在有些时候还是搞不懂某些功能。不过，大体感觉还是不错的，使用了几天，慢慢的习惯了，当然遇到了不少问题，以后有空再写出来了。
javax.servlet.jsp.PageContext cannot be resolved to a type
一个JSP页面，内容如下：
<%@ taglib prefix=”s” uri=”/struts-tags” %>
<%@ taglib prefix=”c” uri=”http://java.sun.com/jsp/jstl/core” %>
<%@ taglib prefix=”security” uri=”http://www.springframework.org/security/tags” %><c:set var=”ctx” value=”${pageContext.request.contextPath}”/>
可是在Eclipse3.4里居然报错：
javax.servlet.jsp.PageContext cannot be resolved to a type
但是如果把
<c:set var=”ctx” value=”${pageContext.request.contextPath}”/>
换成
<c:set var=”ctx” value=”${pageContext.['request'].contextPath}”/>
就没有问题了。
更新：
经路人甲提醒，把jsp-api.jar加入到classpath中，直接用
<c:set var=”ctx” value=”${pageContext.request.contextPath}”/>
也不报错了。注意，像servlet-api.jar一样，一般servlet容器都会自带，所以在发布自己的项目时，不需要带上jsp-api.jar。