随笔分类(103)

    昨天看到《精通EJB3.0》的中文版出来了，虽然早就在预料之中了，不过多少还是有一点想法的，终于第一本 EJB 3.0 的书正式出来了，对目前 EJB 3.0 的追逐总归是有了点方向，但我仍然感觉，EJB 3.0 不可能像 EJB 2.0 那样火了，Java 世界已经进入了多元化时代，Spring 已经逐步的蚕食了 EJB 说占有的份额，用其简单灵活的配置吸引了无数人的眼光，从另外一方面来说，标准的东西毕竟是标准，从制定到实现的周期比较长，如果中间出现了新的需求，一些问题，都需要等到下一个标准中去实现，而开源的就比较灵活了，有问题可以随时调整，所以会带给大家更为 agile 的感觉，不过对于大公司大项目而言，他们并不希望这样的灵活性，他们需要的是风险小，稳定，所以 EJB 3.0 对于一些大型的企业应用来说依然需要的是 EJB，因为有 IBM 和 BEA 这样大公司的支持了，不过自从五月份 JavaEE 5 规范正式定稿，这两大公司都没有拿出真正的 EJB 3.0 的产品出来，倒是 JBoss 在标准出来后很快就拿出了可用的产品，这样也可以看出来，IBM 和 BEA 没有像过去几年对于 EJB 2.0 那样的重视了，他们关注的是 SOA 的市场，毕竟 SOA 在 EAI 方面比 JavaEE 强了很多。

    对于分布式对象领域，EJB 3.0 还是有着不错的竞争优势的，毕竟这是他的传统优势，在群里面和大家聊天的时候，寒江也提到过用 RCP + EJB 3.0 作为方案，其实这也是一套不错的应用方案。

    EJB 3.0 比 EJB 2.0 确实要轻了很多，但并没有给我们太多的惊喜，因为 EJB 3.0 给我们带来的大部分新鲜都已经被 Spring 和 Hibernate 捷足先登了，我个人也是比较喜欢 Spring 和 Hibernate 来做项目，毕竟用起来会更加的灵活，更加的强大，特别是新版的 Spring 和 Hibernate 同时都支持了 JPA 的标准，又一次的在 JavaEE 应用上和 EJB 3.0 展开了下一轮的竞争，一切都好，就看你怎么选择，我选择的是 Spring + Hibernate，或许更加熟悉一些又或许更加轻量，更加 agile。

    一直从dearbook创办起就在 dearbook 买书直到现在，已经成为了钻石VIP会员了，经历了 dearbook 发展中的种种，不过说起来 dearbook 的服务确实不像其标语中说标榜的"第二书店，第一服务"，从我这么多年和他们打交道的经验来说，服务确实很难让人满意。

    过去一开始的时候，都是采用在网上选书，然后邮局汇款，发邮局包裹的方式，效率很低，也很麻烦，每次总是要往邮局跑两次，最大的问题是，网上列出来的书，往往是不一定有货的，有一次买书，选了一堆书最后发现就一本书有货，最后拿到手的只有那一本书，很是郁闷，这样就余下了一些钱在 dearbook，然后又用这些钱继续去买其它的书，最后在升级会员的时候，这些余款购买的书又没有记入积分中，升级的时候就差了这么几分，最后催了好几次才把自己会员资格提高。

    随着和当当网合作以后，付款和收货方面确实有很大的改善，付款直接用网上银行，直接送货上门，都大大的提高了我买书的兴趣，不过 dearbook 网站系统很不争气，频频出现问题，首先发现一个明显的 bug 就是在收藏夹里删除一些书籍的时候，收藏夹就变乱了，都是一些莫名其妙的书，再打开一下这个页面就好了。接着是在和 CSDN Passport 整合的时候，收藏夹里的书彻底丢光了，而这时候没有人告诉我怎么回事。

    在与当当网的合作中dearbook 的积分系统也频频出现问题，当当网是用 Email 账户登录的，dearbook 积分系统也是用 Email 账户登录的，当我修改了当当网的 Email 以后，dearbook 积分系统也换成了新的 Email，但原有 Email 对应积分没有转到新的 Email 帐号上来，打电话去问，答曰，没有提供合并积分的功能，于是一堆积分就泡汤了。

    最近积分比较多，在 dearbook 换了两本书，最后收包裹的时候，只收到一本书，觉得奇怪，打电话去问，才把第二本书给重新寄过来，浪费了我几分钟的电话费。

    这次 dearbook 又心血来潮的要把 D币积分转换为 C 币，因为过去在两个Email 账户上都是有积分的，所以想转换到同一个账户上，结果当我在 CSDN 上修改了 Email 地址后，却发现我过去的积分就消失了，很是郁闷。昨天发了邮件，今天打了电话，到现在也没有人给我答复，看了一下账户里的 C 币，还是不对。

关于敏捷问题

周末听 rocket 介绍了一些来自 thoughtworks 关于敏捷的一些思想，同时也引发了大家的一些思考和讨论。从一种角度来看， Agile 体现了一种软件开发最根本的问题，就是由人在一定的时间内开发出高质量的软件，Agile 更加注重人在整个活动里的作用，而传统的瀑布模型中，似乎更加注重文档等，也就是我过去所在的公司，一切开发都由文档驱动，在这样的情况下，团队中每个人都是可以被替代的，从某种意义上来说，降低了软件开发的风险，但是效率却很难提高。而 Agile 注重的一个方面就是 pair，通过拉近人与人之间的具体来加快信息在团队中的流转速度，使信息像水流一样源源不断的流动，这样在 change 发生时，能够得到更快的响应，而瀑布模型则需要慢慢的由文档传播开来，传递速度和面都比较有限。

虽然 thoughtworks 给了我们一个极具诱惑的 Agile 果子，某种意义上来说是建立在他们公司利益基础上的，真正的去做 Agile 需要更加清醒和理智的想问题。Agile 是一种实践的方法论，需要大量实践和经验才能真正的去理解它，另外一方面，从传统的开发方式转型至 Agile，多多少少都会有过去残留的痕迹，而这些看不见的痕迹，可能会暗暗的抹杀 Agile 最初承诺的效果。

Agile 是一种好东西，某种意义上，资本家从开发人员手里榨取了更大的价值，这是建立在效率提高基础之上的，但它却散发着无比的诱惑，或许大家希望自己少写一些文档，或许大家厌倦了瀑布模型的流程，或许。。。。

    这里我们要将 Tapestry 与其它主要的 Java Web 框架做一番比较，包括 Struts，JSF。

    Struts 是一个 Action 方式的 Web 框架，所有的请求直接对应了相应的 Action，我们需要通过一些相应的技巧性处理才能把我们在页面上的 Click，Value Change 等转换到后端对应的 Action，抽象程度显得不够高，并且这样会使 Struts 在处理一些较为复杂的页面时配置过多，造成开发和维护上的繁杂。另外 Struts 默认使用的 Tiles 模板框架使用了 <jsp:include> 方式的拼装页面技术，并且在每个页面都需要配置，这样的话，又增加了不少的配置量。在Struts中，经常需要使用标签库通过 EL（Expression Language）来显示组件ActionForm中内容，这就涉及到一个结合的问题，标签库是别人写的，而且 Struts 在这方面并没有确定的标准，如何才能让自己的组件库和现有的组件库很好的结合，难度和麻烦就体现在这个结合点上。

    JSF的视图层开发的基本思路和Struts差不多，只不过换了不同标签库，也需要标签库+组件的结合思考，不过因为组件这里是通用组件，没有什么限制，并且遵循了一个共同的标准，所以这样比Struts要轻松一些。JSF 提供了一套完整的生命周期和组件标准，我们很容易的为其定制一些组件和使用现有的组件库。另外JSF采用了事件驱动的方式，同一个页面对应的多个 Action 请求会比较直接的通过 EL映射到后端对应的 Java 方法上，从而大大减少了复杂页面的配置量。但是在默认情况下，JSF 每个页面的都需要配置其单独的导航，如果页面导航复杂的话，配置还是不少的。JSF 在默认情况下并没有集成模板引擎，但是开源的 Facelets 模板引擎提供了类似 Tapestry 的模板方式，从另外一种方式简化了 JSF 的开发。JSF 采用了 HTML 页面保存组件树的机制，页面的所有组件和组件状态被序列化到页面中或者 Session 中，这样的话，如果在页面上 Javascrīpt 通过修改 DOM 的方式修改页面的组件，会导致页面和组件树不一致，导致 JSF 无法正常工作，但是可以通过 Ajax 方式向服务端发出更新组件树的请求，但这样需要走完 JSF 整个生命周期，显得较为笨重，所以从架构上来看，JSF 在处理页面问题上不够灵活，也不够 Ajax 化。

    Tapestry使用了组件库的概念替代了标签库，没有标签库概念，这样就没有标签库和自己的组件需要结合的问题，都是组件的使用，组件中分Tapestry标准组件和自己定义的组件，这也是接触了JSP体系的人学习Tapestry面临的一个思路转换。这样极大的减小了页面修改而带来的修改难度。同为事件驱动的框架，在配置上 Tapestry 有着和 JSF 类似的优势，我们只需要简单的在 XML 文件里配置事件和后端方法的对应关系，或者使用 OGNL 直接在页面中与后端方法建立关联。在页面导航上，Tapestry 是根据监听器方法的返回值而确定，这样就省去了页面导航部分的配置。Tapestry 的模板技术天生就是其优势所在，这样的方式将前台页面的制作和后台业务系统的开发完美的结合在一起。Tapestry 因为没有 JSF 这样的组件树绑定的方式，就能够比较容易的和 Ajax 绑定在一起，目前开源的 Tacos 组件库就提供了很多这样的组件，并且整合了 Dojo Toolkit 使得我们开发页面中有了更多好用的组件，并且只需要很简单的配置工作就可以使用功能强大的 Web 组件和 Ajax 功能。

    另外，JSF/Tapestry不只是支持HTML，也支持多种客户端语言如WML或XUI等。

    虽然看起来两者似乎没有什么联系，但是看起来 工作流 的一些概念和状态图有着惊人的相似之处，或许是我过去对 UML 的理解太少了，而对 UML 的理解有仅限于 Class Diagram 和 Sequence Diagram，而且仅仅是一些粗浅的认识，而在和 Sze Hung 老大以及 james 讨论问题的时候，也经常遇到状态机的概念，或许是我在这方面太过于薄弱了。今天在 dearbook 定的 UML User Guide 2nd 也到了，这本凝聚了 Rational 三巨头的心血之作中贯彻着这样的思想。希望能够从中吸取更多精华吧。

    很多粗人都常常认为 UML 只是画图的东西，三两页就可以讲完的东西，何必弄这么多呢，还印出 n 多本书，简直就是骗钱了。其实说来，UML 难道仅仅是一种图形工具吗，它凝聚了更多更深刻的 OOP 的概念，在各种各样的应用中才发现，原来 UML 比我开始想想的要丰富的多。

    看过一些人在网上的评论，才发现，其实人民邮电出版社和机械工业出版社的书其实并不是太差了，只是机械的纸实在是说不过去，在我书架上放的一堆书中，原来清华大学出版社的书是最差的，无论从纸张，从排版，从翻译，因为有康博这样被骂死也还要出来招摇撞骗的所谓翻译团队。近些年来，一些出版社都开始建立了一些自己的图书品牌，比如说电子工业出版社的“博文视点”，比如人民邮电出版社的“图灵系列”，我个人感觉其中的书的选题和印刷都还不错，虽然也会有一些比较烂的作品出来了。

　　今天看了一篇很有意思的文章， http://www.blogjava.net/uiiang/archive/2006/10/30/77993.html ，介绍了种种项目中的编码的恶习，其中很多的东西看起来真的是很搞笑，比如趴在Tab上睡着了那个，用中文做变量名的，还有 if(condition) a  else a 那个也比较搞笑，算是夸张了点。

　　不过想想看，自己一直都在算是比较正规的软件企业，编码规范还是有一定的要求的，不会出现这么搞笑的问题，不过有些问题还是会经常的犯，比如说，又一次看一个同事写一个方法写了 1500 行，我立刻让他改，最后精简代码，分开写，也算是减少到可以接受的程度，另外一个恶习就是复制代码，很多开发人员自身都是不怎么会写代码的，做开发就是找过去相识的，复制，粘贴，改，所以会出现一堆比较搞笑的问题，于是，错误便不是自己犯的了，人家写错了，自己也就抄错了，我在第一次参加 Code Review 的时候就碰到这个情况，我自己的东西都是自己手工写的，出现了一些问题，被大家指出来了，其它人写的东西都是抄来抄去，发现问题都不是自己的，因为改过去的代码需要上面授权，还有一堆测试要重做，所以看大致是可以用的也就蒙混过关了，造成了越来越混乱的代码。

　　其实说来要把代码写的更好一点没有想象中那么难的，凡事从小做起，从点滴做起，慢慢的把一些好的东西变成自己的习惯，重要的是要积累，而不是放任自流，多去看看人家著名的开源项目，看看人家代码是怎么写的，多去和自己的比较，然后善于用一些 Audit 工具评估自己的代码，让自己对自己的代码中出现的问题有一个更明确的认识，然后慢慢的去改变自己的习惯，其实从长远角度来说对自己有很大的好处的，起码自己的编码能力提升了，基础更加稳固了，有能力去胜任更高级的工作，不然，天天复制别人的代码，自己又天天只能写出来一些不符合规范的代码，而自己又天天不去想不去问，一直这样下去，开发能力还能提高吗？

　　其实我还是很喜欢一本书《代码大全 2nd》，今年上半年才出来的中文版，里面针对我们开发的时候出现的问题给出了很多规范和解决方案，我会经常抽空去看看这本书，然后想想自己该如何去改善自己的开发习惯，去写出更好的代码，另外就是用一些 Audit 工具去针对自己的代码做出一些评审，比如 CodePro，另外我们一些同事在 Maven 上用一些插件对 CVS 上的代码做出 Audit 并发布在项目站点上，这些都是不错的手段了。

　　其实说来最重要的还是自己的态度，工具，好的方法都不能转变对于开发恶劣的态度的。

     摘要:   阅读全文      摘要: 这几天突发奇想，过去通过一些对 Navigation 的实现来省去了 JSF Navigation 的配置，现在又有新的想法了，能不能在 face-config.xml 中连 Managed Bean 都不要配置了呢，答案是肯定的，并且在实践中也得到了证明。  阅读全文     花了近一周的时间，把 iCustomer 大改了一番，其实说来也没有特别大的变化了，修改的东西只不过是一些过去的一些bug和网上朋友们的一些建议，其实重点还是放在改 bug 上，另外就是 Order 这部分系统的领域模型重构，Order 与 OrderItem 之间的关联由原来的 one-to-many 改成了现在的 composite-element 方式，参考了 Hibernate Reference 的内容，从理解上来说这样的关联方式也是比较合适的，有过去的松散的关联方式换成了现在这样紧密的关联方式。通过前面近两个月对 Hibernate 概念更深层次的思考与理解，现在在处理起这样的问题都变得轻松了很多，没有那么多的问题会很让我在开发中卡壳，而且是那种一卡就卡上个好几天不能解决的。当这样的关联关系复杂了以后，Hibernate 的功效才更好的发挥出来了，我们拿关联对象就不用再写一堆方法去拿了，需要的时候去取，Hibernate 就会自动的取帮你取好。实际上这次改 Order 部分时候，很多情况下都是在删过去的代码，过去的方式真的太复杂了，全部要自己手工一个个的去拿，简直就是把 Hibenate 当 SQL 用，从思想上来说，这显然是不正确的。

    另外想想看，如果在一个项目中用起 Hibernate 或者使用同样方式的 EJB3 Persistence 真的会存在着太多的风险了。Hibernate 走的是方式上的变革，我们必须去用新的思想去考虑问题，而不是仅仅用用它而已，我们需要从对象建模的角度就开始考虑 ORM 的存在，以对象为中心的方式去组织业务逻辑，而不是以表为中心去组织，刚开始用 Hibernate 的时候，大部分情况还是在考虑表如何如何的，但是用了一段时间以后，发现这样的方式和 Hibernate 真正的核心思想相差太大了。所以说要正确的去用 Hibernate 决不是看了一两本书，做了几个简单的 CRUD 就可以的了，需要在许多复杂关联中经受考验才可以，而一个要很好的去用 Hibernate 的项目，一定是要有这样经验的人去做才可以的，几个刚翻几页书，知道怎么用就去拿 Hibernate 做项目的人真的还是远远不够的，这种情况在 iCustomer 0.1 版本中表现的非常突出，混乱的配置和关联关系，让使用了 Hibernate 后，代码未减反增，我努力在 0.2 的版本中做出一些修改了，当然只是比原来好了一些，离真正理想的情况还是有差距的。当然有空我会把这样的一些经验和大家分享一下，让大家在学习 Hibernate 上少走一些我曾经走过的弯路了。

    又用回了 JSF，开始发现这样的方式真的有很多的好处了，而且在 JSF 的使用和经验上有一些积累，用它来建立一个不大的项目经验应该是足够的了。Backing Bean 的方式比 Action 的方式配置文件的数量上要减少了很多，说能够减少到原来的 1/4 甚至更多都不为过了，因为我们一般情况下一个 Backing Bean 对应一个页面，只需要配置一处，而一个页面中如果有很多操作的话 Action 方式就需要配置很多了，比如一个查询页面，查询需要一个 Action，查看查询的一个记录需要一个 Action，删除记录需要一个 Action，修改一条记录又需要一个 Action，算起来正好 1:4，是不是省了很多配置呢，在结合扩展的 Navigation 方式，连 Navigation 都不需要配置了。配置文件真的少了很多了。

    用到了一个 Tomahawk 组件中独有的 forceId 属性，不能说有多爽，但是可以让你在写 JavaScript 的时候省了好一些代码了，过去一个组件的 id 生成出来就是 form:cid 的形式，而用了 forcdId = "true" 后，生成出来的 id 就是你在组件的 Tag 中实际定义的值，当然用的时候也要小心了，千万不能重复，包括同一页面中不能重复，也包括一个页面中包含另外一个页面时不能重复 。

    连续三天做了三场 Share Session，讲了一些关于系统开发的三个层的东西，Web Layer / Business Layer / Persistence Layer 分别以各个层面最优秀的技术为例和组内组外的同事们分享了一些我关于这些技术的理解。

    虽然说讲的还不是很好了，但是这三天却给了我很大的提高，不仅仅是技术上面，更多的是在一种表达能力方面的。可以说是第一次真正意义上的上台讲东西了，因为面对的不光是同组熟悉的同事，还有很多不是太熟悉的，还有几位老大，甚至在最后一次讲JSF的时候，大老板还进来坐了一会，压力还是挺大的，虽然要讲的东西已经在之前在脑子里演练无数次了，但是要想把自己想的东西和别人讲清楚，的确不是那么容易的事情了，当发现下面的同事满脸的迷茫，就得赶紧换一个角度来说明问题，不过还算过得去的是，自己并没有太多的紧张了，虽然是第一次正式的在台上讲东西，面对面的对着大家，不过自己要讲的东西心里还比较有底，心里比较踏实了，于是也就没有太多的紧张了。

    通过三天对各个方面的技术的介绍和总结，其实也不知道大家真正能理解多少，因为太多东西没有经过实践是不会有太深刻的理解的，虽然有些东西当时是听懂了，但是却不会深深的刻进你的脑子，时间一长就忘记了。三天里，总结了这一年来我对 Java Web 开发的几个方面的理解了，虽然这一年学到了很多很多，但还有太多太多的不了解了，有些东西当自己看的时候觉得自己了解，但是当需要把这个东西和别人分享的时候，却发现自己有太多太多的不知道了。

    似乎很久没有写些什么了，因为最近想的太多，做的太少了。
    第一次发现 Hibernate 原来并不是自己过去想像的那样简单，它很复杂，很强大，却能让你最后要做的事情变的很少，虽然它带来了如此多的好处，但如果想真正的用好它，必须有一个非常熟悉它的人在你的团队里，这样才能够最大的发挥它的巨大威力。虽然每个人都可以花不多的时间去用会 Hibernate ，但却只有很少的人能够灵活的驾驭它，让它为你服务，因为它同传统的关系数据库可以说是截然不同的两条路，从玩 SQL 走过来的人，多多少少会受到它的限制，而变得不易接受ORM，像我就是一个典型了，当得到高手指点的时候，发现过去的很多想法偏离轨道还是挺远的了，幸亏有人指点，得以走回正道。
    作为 J2EE 中另一个骄傲，Spring 也以它的独特观点改变了 J2EE 的世界，过去用 Spring 只是稍微理解了它的 IoC 的思想，和简单的使用了它的 Transaction 管理功能，最近细看了一下它的 AOP 感觉震动还是挺大的。基于 Interceptor 的 AOP 真的是很好用，也很强大，甚至于说，它会是一种改变 Java 开发模式的一种动力了，虽然只是刚开始看看，没有什么深刻的理解，但却也能够有一些很大的感触了，或许 AOP 在目前还是刚刚起步，或许太多的人没有接受它理解它，AOP 的应用层面还是比较低了。

用 Hibernate 碰到一个很傻的问题，在 iCustomer 中有这样的关联，有服务记录，该记录会与 Customer 关联，当时为了在不需要的时候不在 VO 里 new 出 Customer，用了这样的写法。

public Customer getCustomer() {
 if (null == customer) {
  customer = new Customer();
 }
 return customer;
}

这样看似没有问题，当使用到 Customer 的时候才会创建该对象。但是每次却会报告脏数据错误，其实最重要的是我忽略了一个问题，这个方法同样会被 Hibernate 调用，在 null 的时候给 new 出一个相应的 Customer，这样就会出现问题了，如果你把 Customer 设成 null，Hibernate 调用该方法时就会自动给你 new 一个 Customer，并没有任何 id，这样在保存的时候会引发脏数据错误。所以一定要避免这样的写法。

别人给出的建议是把这样的 new Customer 的逻辑放在外面写，手动处理 Customer 的创建。页面上传递的是 Customer 的 id，后台手动加载 Customer 的 PO，然后 set 给 Support。

　　经过大约四个月的开发，和五位开发设计及美工人员的努力，AgileJava iCustomer 的第一个不是那么稳定的版本终于拿出来了，我们终于走出了我们的第一步，在这期间，我们也得到了很多朋友的支持和帮助，我们要感谢这些支持者的贡献。

　　在这个阶段里，我们团队成员一起把我们研究 JSF, Spring, Hibernate，以及 Acegi 的成果都集中在这个项目中了。虽然很多东西都只是那么点点滴滴，但是在这期间有很多朋友在积极的帮助我们，参与我们的 OpenDoc 活动，把自己的宝贵时间分享出来，为大家带来了很多很好的文档，上周末，我们得到了 javascud 的大力支持，我们有了自己的 SVN，有了自己的 JIRA，这样的话，我们便可以建立我们自己的协作开发平台，让我们的经验和更多的朋友分享，同时，我们也欢迎更多的朋友能够参与到我们的开源活动中来，因为有了你们，我们才可以更壮大，因为有了你们，我们才可以更成熟，因为有了大家的齐心协力，我们才能为了一个共同的目标去奋斗，因为有了大家的协作，我们才会在共同努力中进步。

　　开源也不是一句口号，我们只想用我们自己的行动来证明这一切，正因为我们是热爱开源的，所以我们才会去努力做的更好；正因为我们有着一个奋斗目标，我们才会孜孜不倦的去奋斗。此前 SpringSide 为我们做出了一个榜样，EasyJF 让我们梦想在自己的努力中实现，CowNew 也成为我们开源一个很好的先例，正是因为大家有这个梦想，有这些前辈们的努力，我们才看到国内开源的希望。

　　其实我们更希望做到的，只是让新的技术能够更贴近实践了，让大家的实践能够更容易，让大家的开发能够更轻松，所以我们才从过去只是为了朋友做的一个小小的系统中找到方向，所以我们的开源团队名称叫做 AgileJava 就是为了让我们的开发更敏捷。

　　下面我简单的介绍一下我们现在已有的系统和我们未来的目标：

　　AgileJava iCustomer 系统是一套开源的 CRM (客户关系管理) 系统，使用了新一代轻量级 J2EE 技术： JSF，Spring，Hibernate， Acegi 等作为系统的基础开发框架，力图打造一个轻快好用的 J2EE 应用。

　　在系统开发过程中，我们同时将系统中的基础框架以及大量可以简化 J2EE 应用开发的组件从应用中抽取出来，并独立提供给广大开发人员，作为项目开发的基础框架，为大家进行快速开发提供支持。我们为该框架命名为 AgileJava Framework。 AgileJava Framework 的目标是致力于为广大开发者提供一个敏捷高效的 J2EE 快速平台。

　　另一方面，我们将以此框架为基础，通过 Eclipse Plugin 的方式提供一套完整的基于代码生成的解决方案，用于快速生成应用的基础代码。该开发工具同样沿用我们 AgileJava 的名称，叫做 AgileJava Studio。 AgileJava Studio 将致力于减少开发工作中的重复劳动，给开发者带开更好的开发体验。

　　我们将会将 AgileJava iCustomer， AgileJava Framework， AgileJava Studio 作为开源项目来运作，一方面建立一个完整的企业级的客户关系管理系统，另一方面建立一个为 J2EE 项目提供快速开发能力的基础框架和开发工具。

　　因为国内的开源模式一直没有什么好的先例，并且开源的路线在国内因为一些误解方面的问题，一直没有很好的发展起来，虽然我们选择了开源，但是我们更多的希望只是通过一个完整的企业级应用的方式来探索开源的方向，并为我们中小型企业级应用打造一个方便易用功能强大的解决方案，用我们的实践带给所有参与者一些经验，无论是开源方面的经验，还是在轻量级 J2EE 应用开发的经验。虽然国内很多软件企业都在用这些技术，但因为版权的问题，无法和更多的朋友分享，所以我们更需要一个开放的交流环境，通过这样开源的方式，通过大家的努力，把我们在实践中的经验拿出来，和大家分享，共同促进我们软件开发的大环境的改善，共同提高大家的开发能力和开发水平。

　　在这里，我们鼓励的是一种知识共享，通过这样的共享，我们把我们自己拥有的一份知识扩展到大家拥有的无数份知识。我们通过自己的实践，我们能够更深入的去了解了现有的各种技术的长与短，通过大家的交流与协作，我们在知识上互相弥补。通过这样的实践，我们不光是再做我们这个系统，更多的是我们有了更多的思想，更多的经验，我们有能力去打造更好的系统。

　　我们目前采用了以 JSF, Spring, Hibernate 为中心的主体框架，并努力使之扩展到一个中小型商业应用所需要的主要技术领域，并使之更简单易用。

				 目前采用的技术：
 JSF (Myfaces Implement)，完整的视图层解决方案，一个标准的事件驱动的 MVC Framework。
 Spring Framework ： 其 IoC 容器为我们的业务对象控制带来了很大的便利。
 Hibernate 3 ： 目前最优秀，使用面最广的 ORM Framework。
 Acegi ： 一个基于 Spring 的通用 Security Framework。
 Quartz ： Java 世界最好也几乎是唯一的 Job Schedule 工具，为我们调度 Batch Job 提供了很大的便利。
 Shale ： struts 社区在 JSF 领域的重大贡献，以 JSF 为基础为我们提供了一系列好用的东西。

		

				 预计后面准备采用的技术：
 Compass + Lucene ： Java 世界里最好用的开源 Search Engine 组合，Compass 使 POJO 能够更方便的去使用 Lucene 的底层引擎。
 BIRT ： Eclipse 社区贡献的一个重量级 BI 应用。当第一眼看到它时，就抛弃过去的 iReport + JasperReport 的组合了,够专业。
 Facelets ： 为 JSF 量身定做的模板框架，JSF 的 Fans 们不用再靠着 struts 的 tiles 也能活啦。
 AjaxAnywhere ： 不用写 JavaScript 也能 Ajax ，它为我们提供了这样的可能。
 ICE Faces Component : 当它的第一个beta版本出来的时候，我就对它颇有兴趣，或许是目前免费的 JSF 组件库中最好的 Ajax 实现了。

		

　　我希望能够有更多热爱开源的朋友加入到我们的行列中来，不论你来自何方，做着什么样的工作，只要我们有着开源的这个共同的目标，我们就可以共同的去为着自己的爱好，自己的理想，自己的信念所奋斗，记住，开源决不是三分钟的热度，需要你持之以恒的奋斗。

     摘要: 过去的一段时间，一直有人拿 JSF 的 Navigation 当靶子，批评 JSF，其实细心的人会发现，在 Java 世界，这样的批评常常是很片面的，几乎所有成熟的应用框架，在除了实现某些默认的功能外，还保留一些扩展的接口，提供了相当的扩展性，比如说 struts， spring 等很多的 web framework 都提供了很多扩展的接口，当然，JSF 也一样。JSF 的 Navigation 中，我们一个 page 都有一个 from-view-id ，它的每个 navigation 出口 to-view-id 都必须定义，所以在不同的 from-view-id 中会有一些重复的 to-view-id，并且每当有一个新的 navigation 路径，我们都必须配置这个路径，才能够在 action 中正确的转向我们这个路径。很多情况下，这样的方式用起来都不是很爽，我们需要有一些简单的方式，我们在 action 事件中，直接 return 一个 page 的 path 就会直接 forward 到这个 page ，在用的时候会方便一些，有没有办法去做到呢？  阅读全文