J2EE without EJB 勘误表

大家可以在这里跟帖，提出自己发现的翻译中的问题。

我在这里更正一下，由于粗心，gigix 将我的名字错写为李鲲。我的名字其实叫做李锟，这个字生僻一些。鲲鹏的这个鲲字也很好，不过名字是老爸取的，为了表示尊敬，不便于随便更改的。

P33:
采用本地接口的无状态session bean
与远程EJB相比，采用远程接口的SLSB简单一些，对面向对象原则的支持也好得多，因为访问这些SLSB的时候，用不着借助传输对象。
原文：
SLSBs with local interfaces are simpler than remote EJBs, and do a lot better on object orientation, as they don’t require the use of transfer objects to access them.
这里，“采用远程接口的SLSB简单一些”是笔误。应该为“采用本地接口的SLSB简单一些”。

中文版到现在为止看了20多页，只发现一个错误(当然，我不是中英文对着看的，所以只有在明显感觉不适的时候才会去翻英文，所以也许还有其它bug?):

P70 第一行：
而这些远程异常肯本不会发生。
印错了一个字，“肯本”应为“根本”。
P84：
另外，代码重构也不会破坏源码级元数据，这正是外部 XML 部署描述文件的一个重大缺陷。
原文为：
Source-level metadata also survives refactoring, thus addressing a significant weakness of external XML deployment descriptors.
这里这句话这样翻译含义不是很明确。作者的意思是源码级元数据可以参与重构，重构工具在重构时可以对源码级元数据进行自动的处理。而假如元数据保存在 XML 部署描述文件中，重构工具找到相应的 XML 文件，并且自动对文件进行修改要困难的多（如果不是完全没有可能的话）。


整个 20 页都没有“所以”两个字啊。

faint,不好意思，我昨天一共看到第20页，一不小心就把这个页码写上去了
问题出在第11页第7行.

对于 scalability 这个词，我在第 5 章和第 12 章翻译做“可伸缩性”。而在第 4 章 Jacques 翻译做“可扩展性”。这确实是我们协调中出现的一个小问题。大家只需要知道，在这本书中“可扩展性”和“可伸缩性”是完全相同的含义。
用 Google 搜索，这个词的两种翻译同样大量存在。甚至在 M$ 网站的两个中文页面中，翻译都不相同。
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/zh-chs/library/ServerHelp/397571d6-c30c-4c35-a30e-caa5b1b4b91c.mspx
http://www.microsoft.com/windows/windowsmedia/cn/9series/encoder/extensible.aspx

如果按照 scalable 的含义“可升级的”，那么翻译做“可扩展性”似乎更适合，因为这里好像只有扩张的含义。不过实际上这个词在计算机领域的含义要更加广泛，应该同时包括扩张和收缩两种含义。即在需要的时候，我可以升级应用系统的能力以支持更大的用户量/负荷，而当不需要的时候，应用系统还可以降下来以降低维护支持的成本。所以我翻译做“可伸缩性”。高度的可伸缩性，伸缩自如，以满足不同的需要，是企业应用必备的一个特性。

读完第8章，挑一点骨头，感觉这一章就是译注有点多：
必要的只有1的前16个字(后面属于抒情),7,8
2,5，6,9聊胜于无
3 给了一个不能从网上查阅全文的过期刊物(所以也不太方便有心查阅的人买到)的某篇文章的引用
4有那么一点点文不对题

P97：
“处于性能考虑”应为“出于性能考虑”。
P116：
“并不像EJB那些极具侵入性”应为“并不像EJB那样极具侵入性”。
P117：
竞争确实也有自己的问题，但是竞争的确可以促进世界进步。
原文：
Competition may lead to its own problems, but it has proven to generate much faster progress.
应该翻译做：
竞争确实也有自己的问题，但是竞争的确可以产生快得多的进步。
当然，计划经济也能带来进步，这里强调市场经济相对于计划经济的巨大优势。
P118：
不要轻易升级开源产品，除非绝对需要最新的特性。不要让开源产品牵着你的鼻子走。
原文：
Unless you absolutely need the latest features, upgrade your framework versions on your timetable, not the timetable of each project.
这里，是否存在后一句的含义，值得商榷。

评价一下原文和译文的风格，gigix 的风格要比 Rod Johnson 潇洒一些。其实 Rod Johnson 的文风相当地保守和严谨，可以用滴水不漏来形容。Rod Johnson 特别喜欢使用长句，所以相当难翻。gigix 的翻译不太拘泥于原文，注重传神，给读者带来了很流畅的阅读体验，这是非常有特色的。但是正因为这个特点，给了张恂攻击的口实。

P124：
“因此可以不仅可以在其中管理粗粒度的对象”多了前面的“可以”，
应为：
“因此不仅可以在其中管理粗粒度的对象”。

P145：
“从而在运行天衣无缝地将拦截器和其他的advice整合进来”少了一个“时”，
应为：
“从而在运行时天衣无缝地将拦截器和其他的advice整合进来”。

P158：
“或是其他类似的集中式的静态工厂”
原文为：
or a centralized static factory that knows how to create both,
翻译为：
“或是两者均可创建的集中式静态工厂”
似乎更加准确。
另外这一页最下面代码中
productManager.setInventoryService(inventoryManager);
印错了，其实原文中就已经错了。
应该为：
productManager.setInventoryManager(inventoryManager);

P182：
因此，我们建议通过设置 Resource 对象的 bean 属性来访问各种文件资源。
这样翻译有点颠倒，也容易混淆，应为：
因此，我们建议通过设置 bean 的类型为 Resource 接口的属性来访问各种文件资源。

P185：
“也不需要在web环境之运行你的业务逻辑”，少了一个“外”，
应为：
“也不需要在web环境之外运行你的业务逻辑”。

老实说，这本书第九章"事务管理"，翻译的一般般。主要是中文不通顺，有几个地方（我感觉得到的有5/6处）按照英文硬译，看起来会有歧义。
比如：
p234 第16行

1. 什么是带事务功能的缓存？这里显然有一些歧义在。
2. 这里事务完成回调中事务完成是修饰回调的。第一次读，我还以为是需要一个事务来完成回调。faint.
3. 最后面那半句话，说实在我没看懂，但是直觉这个翻译在修饰关系上和原文是不同的。
而且，这两段话给我的感觉是作者也没有说清楚，TransactionManager并没有可以注册的回调，只是spring的实现提供了。spring的AbstractPlatformTransactionManager在commit的时候调用了所有这些回调(在非嵌套情况下)，或者将这些回调注册到外层事务。
因此，这里的回调方法是spring的实现替数据访问框架提供的，而AbstractPlatformTransactionManager只是提供了注册这些回调方法的方法。