我认为AOP不是崭新的东东，而只是OOP的延伸，这些就象MOD 面向服务等一样，只是一种经验总结提升，以前没有有一个专门名称，现在成理论体系了，这和模式相似。
我也觉得AOP和OOP没有什么矛盾，本质上市一致的。和Design pattern的分离变化，分清责任也是一致的。至于破坏封装，我倒不太觉得。
看来是一个比较有意思的话题，不过还没怎么看懂它的好处。作为OOP的替代好像有点大了些，就算微软，ibm支持也不能说明它已经到了语言层次了，应该算作一种技术或者跟perl.java等等类似的语言层面的东西吧。
rrtrtrt
> rrtrtrt
看看jboss的intercept好了，aop的概念不过如此
为什么我用 aspectJ for Jbuilder 编译 aspectJ里面的spacewar例子，，编译通过了，，就是run的时候出错了，，报错原因是他不认aspect 这个关键字，，，，，请问怎么解决？？？？
public abstract aspect Coordinator {
我已加了aspectjrt...还是不行！！！！
为什么我用 aspectJ for Jbuilder 编译 aspectJ里面的spacewar例子，，编译通过了，，就是run的时候出错了，，报错原因是他不认aspect 这个关键字，，，，，请问怎么解决？？？？
public abstract aspect Coordinator {
我已加了aspectjrt...还是不行！！！！
只是jbuilder不识别，对程序的运行不产生影响，在编译的时候target选项原来的make 更改为none，还需要有main函数。
的确，我非常赞同Ｊ２ＥＥ分为container和application两个层面，但是既然是两个层面，一个很基础的原则就是相互彼此透明，或基本上透明，然而开发ejb却太intrusive，你必须实现接口（这个我并不反感），而且还必须继承remoteobject（我最反感某某技术必须继承某个类，明显违反了interface based这样的原则）
补充一点，一个真正好的框架和技术，应该是ＰＯＪＯ式的，即程序员负责ＰＯＪＯ这些实体或者说是功能部件的编写，而框架负责把这些部件组装起来，而且组装的规则最好是declaritive．如spring这样公认的比较好的框架就是这么做的． ＡＯＰ的确很好，但我发现斑竹似乎跟大多数技术人一样，对新技术的推崇近乎狂热，传教士般．当然，传播新知识是很好的行为，但每每看见对新知识的宣传，往往只听见说优点的，没听见说缺点的，这样客观吗？看看ＣＯＲＢＡ，ＥＪＢ，ＷＳ刚出来时候的宣传文章，跟如今的事实比较会发现有多幼稚．我并不想冒昧，只是希望斑竹可以更客观地从多面分析一个新技术，技术也并非解决当前问题的银弹
发现Halcyon的观点很对我的胃口。握手！ :->
halcyon 指出的EJB问题正是业界开源的抱怨，EJB 3.0已经解决了这些问题，而且是基于POJO的
的确．ejb３可能是一个应该关注的分水岭． 我个人认为jcp的成员似乎跟open source有敌意，也许是出于jcp member自己的商业利益吧，其实象ejb3中的entity部分完全可以学习jboss一样用hibernate来实现，不仅降低了学习难度，还可以利用hibernate已开发好的部件，更快地推出ejb３的实现，也许还能促成ejb与orm的大一统． 其实无论ejb container还是spring或pico，归根结底都是bean container，既然ejb3利用java1.5的meta技术回归到pojo，所以更准确的说现在应该是bean container标准统一的绝佳时期，至于ejb container还是其他light-weight container不过是不同的实现罢了，就一如现在的app server一样． 真切盼望这一天的到来，也希望Gavin King, Rod等人放下门派之别，共同促进java语言． ～～～可能有些偏题了．
附：理想中的bean生成方式我想是 MyBean bean1=BeanFactory.getBean("ServiceBean","JNDI"); 其中"ServiceBean"是Bean的注册名，"JNDI"是BeanFactoryProvider的注册名，如果为空，则会试图使用默认的new操作符来得到该对象 这样的话，通过插入不同的BeanFactoryProivder就可以实现灵活的对象获取方式． 假想的BeanFactoryProvider可能会有： JNDI:通过jndi得到 Singleton:单子方式 XML:从Xml生成 Serial:从普通file通过Object的deserialize操作得到
是的，未来期望有一个统一的bean container，这个bean container具有真正灵活的可伸缩性，但是不能因为灵活的伸缩性，丧失一些易学性。
大家目前之所以互相指责，互相有敌意，因为大家都想成为这个统一后的武林至尊，成为标准。
其实目前这样处于可选的状态我认为不错，对于不同用户有不同的选择：
1. 如果你是一个框架设计者，你需要设计自己独立的框架，那么Picocontainer这个真正轻量的容器是个好的选择。
2. 如果你是一个Web网站，非大型企业应用，那么Spring架构可以帮助你们解决不少问题。
3. 如果你要规划一个中大型企业应用，事务回滚机制非常重要，计算性能又相当重要，那么EJb无疑是一个合适的选择。