EJB3 = EJB2 + xDoclet?

原帖一(by schlemiel)
我只提一个问题。EJB2+xDoclet能否实现entity bean的继承?如果能,请问如何做。如果不能,请问EJB3=EJB2+xDoclet的等式如何成立。烦请板桥大人正面解答。

原帖二(by banq)
废话,等式不成立,我和jakarta99争什么?你要和我争这个等式,另外开贴PK,不要缠在这里,条理清晰一些好不好,我看你说话好像条理不清哦!

如果我没理解错的话,banq的意思是:EJB3 = EJB2 + xDoclet这一等式成立。现在,请banq正面回答:

(1)EJB3支持entity bean继承。请问EJB2 + xDoclet是否支持entity bean继承?如果支持,请问如何实现?我所说的“entity bean继承”,例如有Employee和Manager两个entity bean,Manager extends Employee。

(2)如果第一问的答案是“不能实现”,请问“等式成立”之说该作何解释?

jakarta99提出公式:
EJB3 = EJB2 + AOP +Ioc + xDoclet + others,

我o他分析了,为什么要去除AOP,因为AOP是EJB container实现,既可以实现EJB3 又可以实现EJB2。

Ioc也可去除,因为这已经隐含在xDoclet(Annotation)中了,否则xDoclet(Annotation)就是无根的树,xDoclet(Annotation)只是给予编程者一个表现,没有Ioc,xDoclet只会增加编程难度,而不会简化。

基于上面理由:EJB3 = EJB2 + xDoclet + others

因为,others是jakarta99自己定义,他没有说清楚有多少东西,我希望看问题看主要的,将零零碎碎的东西去除,提纲契领,写成:
EJB3 = EJB2 + xDoclet(Annotation)

如果你觉得上述推理有问题,请指出。我想我们讨论的是等式问题,不要由此从逻辑上衍生出其他问题,我精力有限,不能一一回答,见谅。


>我想我们讨论的是等式问题,不要由此从逻辑上衍生出其他问题,我精力有限,不能一一回答,见谅。

我很赞同“不要衍生其他问题”的意见,因此您不需要铺陈数百字的背景知识。我的问题很简单:EJB2+xDoclet能不能实现entity bean继承?能,或者不能。如果不能,EJB3=EJB2+xDoclet的等式如何成立?

预先作个揣测:如果您的回答是“不能实现entity bean继承”并且“等式仍旧成立”,我是否可以理解为您对等号与加号进行了独具创意的重新诠释?当然这只是个揣测,待您回答以后再说。

EJB3 =EJB2 + xDoclet的始作佣者应该是你,这个题目也和JK99没什么关系,不要躲躲藏藏的,直接回答好了。

这场面真和当时有国外大师出来说了句ejb2.x不行,然后就接着国内一大堆人出来把大师的话一句句摘出来狠批ejb2.x,搞得好象自己早知道ejb2.x的种种不是,很牛b一样。真不过这个公式未必绝对错,就象ejb2.x未必全错,错只错在用的人用错地方而已。至于那一大堆人,还是那一堆屎。

>真不过这个公式未必绝对错,就象ejb2.x未必全错,错只错在用的人用错地方而已。

在我的理解里面,A+B=C,要么等于要么不等于,这“未必绝对错”请问该怎么理解?莫非1+1=2“未必绝对对”,1+1=3“未必绝对错”?果然是很有新意的伟大创见,这得听听dabb大师如何解释。

> >真不过这个公式未必绝对错,就象ejb2.x未必全错,错只错?> 用的人用错地方而已。
>
> 在我的理解里面,A+B=C,要么等于要么不等于,这“未必绝?> 错”请问该怎么理解?莫非1+1=2“未必绝对对”,1+1=3“未
> 鼐源怼保抗皇呛苡行乱獾奈按蟠醇獾锰dabb大师?> 何解释。


这种人就叫和事老,最后什么都和不成,把自己给搅进去了,变成搅X棍

"我的问题很简单:EJB2+xDoclet能不能实现entity bean继承?"

这个问题本身也糊涂~~~

entity bean继承,或者说CMP抽象类的具体实现, 是EJB2容器的责任. 从这个意义上, 那个等式里的EJB2已经包含了entity bean继承.

不过EJB3里PERSISTENCE和EJB2已经完全风马牛不相及了, 即使从客户端开发角度看也是. 呵呵.


>entity bean继承,或者说CMP抽象类的具体实现, 是EJB2容器的责任. 从这个意义上, 那个等式里的EJB2已经包含了entity bean继承.

请不要试图搅混水。我在一开始就已经把“entity bean继承”这个概念解释得很清楚:

>我所说的“entity bean继承”,例如有Employee和Manager两个entity bean,Manager extends Employee。

欢迎参加讨论,不过麻烦请把前面说的话看清楚,不要随便曲解我提的问题。EJB2+xDoclet能不能开发出这样的两个EJB:A与B两个EJB,A extends B。这是我的问题,希望能得到一个正面解答:能,或者不能。

O, 没看到原问题. 是我错了, 大侠. :-)

我可实在是不留神没看见原题, 真的没有试图阴谋迫害谁, :-)

不过, 针对那个A继承B的问题, 也没有什么不可以的.
EJB2.X SPEC并没有规定EJB继承的具体标准, 但是在EJB2.X和标准JAVA框架内, 这是可以做的, 至少手工可以. 事实上, WSAD里有这个功能的支持. WebLogic也没什么问题. :-)
xDoclet唯一不支持的是O-R映射的继承, 但这是容易扩展的.

另外, 一个讨论技术问题的网站, 何必剑拔弩张.

中华民族的传统美德还是要保持的. 呵呵.

> 我可实在是不留神没看见原题, 真的没有试图阴谋迫害谁,
> :-)
>
> 不过, 针对那个A继承B的问题, 也没有什么不可以的.
> EJB2.X SPEC并没有规定EJB继承的具体标准,
> 但是在EJB2.X和标准JAVA框架内, 这是可以做的,
> 至少手工可以. 事实上, WSAD里有这个功能的支持.
> WebLogic也没什么问题. :-)
> xDoclet唯一不支持的是O-R映射的继承, 但这是容易扩展的.
>
>
> 另外, 一个讨论技术问题的网站, 何必剑拔弩张.
>
> 中华民族的传统美德还是要保持的. 呵呵.


这是Upto Vendor的方式吧,得看看你有钱没钱买得起WebSphere了,而且要改成我用 EJB 2.X+Xdoclet+WEbSphere 实现了Entity继承,少一个条件可不行。

>xDoclet唯一不支持的是O-R映射的继承, 但这是容易扩展的.

第一,还是要麻烦你看清楚我的原话。我说的是“entity bean继承”。如果我的EJB知识还没有那么差的话,O-R映射在EJB体系里就是entity bean。so……

第二,“不支持”,并且“容易扩展”,是否由此可以推出EJB3 != EJB2 + xDoclet?万望明示。

>另外, 一个讨论技术问题的网站, 何必剑拔弩张.

第三,我没有看到谁在剑拔弩张。我提一个问题,希望得到一个明确的答案,仅此而已。我相信这是一个论坛所应有的功能。我相信banq大人办一个论坛也不希望一个有明确答案的技术问题得不到解答。

>中华民族的传统美德还是要保持的. 呵呵

第四,我相信中华民族的传统美德不包括“你好我好大家好”的打哈哈和不求甚解的态度,我相信中华民族的传统美德不包括“对于有明确答案的问题不予正面作答”的讨论方式。

我只要一个明确答案:EJB3=EJB2+xDoclet这一等式,成立,或者不成立。banq大人一开始就已经说得很清楚了,我们讨论等式就讨论等式,不要衍生出诸多无关的话题。你再这样把什么“中华民族的传统美德”扯出来,我担心严格的banq大人要删你帖子哦。

"第一,还是要麻烦你看清楚我的原话。我说的是“entity bean继承”。如果我的EJB知识还没有那么差的话,O-R映射在EJB体系里就是entity bean。so……

说的就是ENTITY BEAN继承, shlemiel大侠. 毕竟 ENTITY BEAN 除了数据映射之外还要其他各种INTERFACE才能满足COMPONENT CONTRACT不是吗? 你可以试试, XDOC是可以在继承的情况下正确产生这些INTERFACE的. XDOC唯一不能处理的是数据映射的处理, 而这是容易扩展的, 事实上有些工具, 比如WSAD, 支持这个功能, 虽然它不用XDOCLET. 希望我这次说清楚了. 呵呵.

明示谈不上, 不过BANQ那个等式本身只是为了简单地表达他作为COMPONENT开发人员的体验. 从COMPONENT开发模式看, 简化CONTRACT的手段的确是通过ANNOTATION, 这的确是XDOCLET的精髓.

其实说到底, 我不觉得你现在关心更多的是技术问题本身. 实际上, banq在其他场合已经用某种方式认可了JAKARTA的说法 (如果你早说, 我就给你置顶云云). :-) 就技术问题本身而言, 我觉得事实已经清楚了.

再回到 ENITTY INHERITANCE, 其实我以前并没有仔细考虑过, 呵呵. 昨天看明白了问题后还是费了些脑汁和GOOGLE才明白的. 从这个讨论也学了一招, 多谢shlemiel大侠.

我想, BANQ前面之所以惹恼了几位江湖好汉, 原因可能在于他的自负姿态. 我认为澄清问题本身比打击BANQ的自负更重要, 如果我们关心的是技术的话. 这不是不求甚解, 而是"就事论事"和"点到为止". 可惜有些朋友觉得掐架比J2EE更有趣.

"PROGRAMMER 相轻", 也有中华民族传统的影子呢, 虽然算不上美德.

ANYWAY, 我觉得, shlemiel, Jakarta, ray_linn, 还有BANQ坛主, 都有很强的J2EE修为. 关于 entity inheritance + xdoclet, 关于 EJB3 从各个视角的分析, 关于 COM+ 和 EJB3 的比较, 我觉得都可以写出颇有意义的好文章. 十分可惜这些思想的碰撞, 没有产生更正面的结果, 而是以现在这种方式发生的.

To Ray_Linn:

其实, 我个人觉得 ENTITY INHERITANCE 本身是在 EJB2 和 JAVA 框架内实现的, 当然有一些界面约束必须满足, 比如父类和子类的主键类型必须统一. 这个过程, 如果完全手工, 是毫无问题的.

xDoclet提供的是"简化"和"自动化"开发过程的功能. 不幸, xDoclet不能提供ENTITY INHERITANCE的"自动化", 但这不妨碍手工编写.

WASD/WEBSPHERE的例子, 是为了证明: 1. ENTITY INHERITANCE 虽然没有JSR153的明确指导, 但是在JSR153前提下是合法的. 2. 实现这个过程的自动化, 是可行的.