Discussions

News: The Unofficial EJB 3.0 FAQ Released

  1. The Unofficial EJB 3.0 FAQ Released (40 messages)

    Debu Panda of Oracle has seen some confusion around EJB 3.0. He decided to put together an unofficial FAQ to clarify ideas. He discusses the goals of EJB 3.0, and discusses the new persistence news.
    Is Hibernate is EJB 3.0? Is Hibernate is the API for EJB 3.0 or Hibernate is the reference implementation for EJB 3.0.

    Hibernate is neither EJB 3.0 nor the reference implementation for EJB 3.0. The persistence aspect of EJB 3.0 is not based solely on Hibernate and derived from leading O-R frameworks like Hibernate, OracleAS TopLink, etc.

    Will JSR-220 produce two specifications?

    Yes, JSR-220 will produce two specifications, one for EJB and one for the unified persistence model. Also RI, TCK will be different for core EJB 3.0 specification and the POJO persistence model.

    Can I use the new persistence model delivered by JSR-220 outside EJB container?

    Yes. The new persistence model can be used outside EJB 3.0 container and also be used in J2SE.

    Why the persistence work is still being done under JSR-220 instead of creating another JSR?

    Creation of a new JSR takes long time and the JCP does not to delay the release of a simplified persistence model work started by EJB 3.0 expert committee that has been well received by the Java community. Also it does not want to throw away the work that has been done by the EJB 3.0 expert group.

    Does the EJB 3.0 expert group have any members with Object-Relational expertise?

    There are active participations from all leading application server vendors and as I understand contribution is coming from many different sources that bring vast experiences and customer inputs. This includes but not limited to Oracle, BEA, IBM, Sun and JBoss/Hibernate.

    There are several members of the EJB 3.0 expert group whose primary area of expertise is object-relational persistence. For example, Gavin King is the founder of Hibernate and the Oracle representative Mike Keith is an Architect of the TopLink development team.

    This will be complemented by when several members from JDO 2.0 expert group will join the JSR 220 expert group.

    What is target release for EJB 3.0 and the new persistence specification?

    The original target release of EJB 3.0 (and J2SE 5.0) was summer of 2005. Certainly this date will be impacted by the unification of persistence specification.

    What will happen to old-style (EJB 2.1 and EJB 2.0) CMP Entity Beans?

    EJB 3.0 compliant containers for backward compatibility will still support the old style CMP Entity beans. Also EJB 3.0 plans to extend the EJB-QL for the EJB 2.1 style CMP entity beans.
    Read The Unofficial EJB 3.0 (JSR-220) FAQ

    Threaded Messages (40)

  2. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    another question: Will JSR 220 provide easy migration from JDO 2.0 / 1.0 to the new persistence API ?

    I assume the answer is yes. Otherwise We could not consider this "new Persistence API" a serious proposal, as a lot of Companies had invested money on JDO products.
  3. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    Why the persistence work is still being done under JSR-220 instead of creating another JSR?Creation of a new JSR takes long time and the JCP does not to delay the release of a simplified persistence model work started by EJB 3.0 expert committee that has been well received by the Java community. Also it does not want to throw away the work that has been done by the EJB 3.0 expert group
    Hmm. Not quite sure why people are giving an "EJB" FAQ here since this is Persistence both inside and outside the container. Many many people want persistence outside the container and this just gives the impression that this is all being covered here.

    Perhaps they don't want to throw away the work done by the JDO 1.0 and 2.0 Expert Groups ? Any persistence model created by this group has to be usable inside and outside the container otherwise it fails the most basic aspect of its creation ... unified persistence. There are many people on the JDO 2 expert group who will be part of this group yet aren't mentioned here.
  4. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    Hmm. Not quite sure why people are giving an "EJB" FAQ here since this is Persistence both inside and outside the container.
    But that's the point. Maybe they won't be called "Entity Beans", but the point is that EJB3.0 will define persistence for both inside and outside the container.
    There are many people on the JDO 2 expert group who will be part of this group yet aren't mentioned here.
    When they're actually part of the expert group, I'm sure they will be mentioned.

     - Don
  5. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    At first I thought this "truce" positive, but thinking further,
    I ask what this new API will bring to java that JDO does not provide yet?

    facts:

    - The new API is only O/R mapping
    - Jdo is datastore transparent. providing unique API across datastores.
    - JDO 2 is specialized on O/R mapping
    - JDO 2 will be out in a few months
    - The new API will be out in no less than one year


    so ask yourself, is this good enough? where is the support to object dbs? is this a rdbms vendors lobby?

    truce or trap?
  6. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    Yes, JSR-220 will produce two specifications, one for EJB and one for the unified persistence model. Also RI, TCK will be different for core EJB 3.0 specification and the POJO persistence model.

    Now I AM confused. The POJO persistence specification is NOT in the core of EJB 3.0? So what IS this POJO persistence specification? Something entirely new? An extension of JDO (JDO 3?). This sounds like there isn't going to be a 'unified' persistence model at all - how can it be unified if there is one system for EJBs and another for POJOs? Am I misunderstanding what 'core EJB' means?

    Also, I am very wary of any new API that would require migration from an established API: JDO 2.0 looks very promising, but acceptance will be held back if there will be a need to migrate from it in a couple of years: is this part of the motive of the large DB vendors in wanting a new API, or am I too suspicious?
  7. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    "Now I AM confused. The POJO persistence specification is NOT in the core of EJB 3.0? So what IS this POJO persistence specification? Something entirely new? An extension of JDO (JDO 3?). This sounds like there isn't going to be a 'unified' persistence model at all - how can it be unified if there is one system for EJBs and another for POJOs? Am I misunderstanding what 'core EJB' means?"

    Have you looked at the Open Letter by Linda DeMichiel and Craig Russell at http://java.sun.com/j2ee/letter/persistence.html

    "The new POJO persistence model will be delivered by JSR-220 as a separate specification, Reference Implementation, and Technology Compatibility Kit, usable independently of EJB 3.0."

    regards
    Debu
  8. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    "Have you looked at the Open Letter by Linda DeMichiel and Craig Russell at http://java.sun.com/j2ee/letter/persistence.html "The new POJO persistence model will be delivered by JSR-220 as a separate specification, Reference Implementation, and Technology Compatibility Kit, usable independently of EJB 3.0."regards Debu

    Yes. I think I understand the situation better now. What still puzzles me is how JDO 2.0 fits into this: Surely JDO 2.0 will be a very full-featured POJO persistence model? So, why is there a 'new' POJO persistence model? This sounds like an attempt by DB vendors to hold back JDO adoption by suggesting that a new persistence model devised largely by the EJB 3.0 people will supercede it.
  9. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    Creation of a new JSR takes long time
    My casual observation is that this is not the case. Look at how fast BEA and IBM could submit 3 JSR's (yes, 3, not 1!!!) last winter (SDO, Timer, and Worker Manager). Obviously pushing the JSR's through is a different story. However, so far what I hear is that there is such a large consensus between the EJB 3 and JDO 2 EG's that pushing a unified Java Persistence spec through JCP is not a huge hurdle anymore. If that is true, why not create a brand new JSR to eliminate any chance of confusion? In the life time of JCP, have we ever had a case where a JSR produced more than one spec? How are we going to address the new unified Persistence spec? EJB 3.0 Part B? Isn't that an oxymoron?

    So the EJB EG, please throw away your ego, and don't give any hand-waving arguments like above, or EJB 3.0 has progressed so much, and there is such a community support behind EJB 3.0. Those are ALL garbage and I don't buy any of it. I would counter argue that JDO 2.0 is further along, because Kodo has a beta version that showcases the new JDO 2.0 features, and JPOX is also implementing the same. What do you have in the EJB 3.0 land? Maybe some early code sitting in a branch somewhere in JBoss's CVS repository?

    Since Craig Russell has already made a HUGE gesture to give up the unified Persistence spec as part of JSR-243, Linda DeMichiel, please show your leadership to take it our of JSR-220 as well and submit a new JSR together with Craig ASAP. This is what I call community spirit. And that kind of courage is what we will all applaud.
  10. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    If that is true, why not create a brand new JSR to eliminate any chance of confusion?
    What confusion is there to eliminate? It's simple. Some of the JDO EG are going to be included in the EJB3.0 EG, and the EJB3.0 spec will provide a definition of POJO based persistence for both inside and outside containers.

     - Don
  11. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    What confusion is there to eliminate? It's simple.
    If it is not confusing to you, do you care to answer some the questions raised in this thread and the earlier thread announcing the join effort? Please do not just quote the original sentences from the open letter. IMHO Debu Panda made a great effort in producing the unofficial FAQ but he could not dispel all doubts the community has.
  12. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    Sure, I can offer my opinion. To save me from guessing and missing the ones that are most important to you, can you list which questions are most important to you?

     - Don
  13. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    Things I want to know:

    1. Is it a natural situation to have a container-independet spec live in a container-dependent JSR?
    2. If the answer to 1 is no, will this problem ever be corrected? If yes, when?
    3. Do the 2 specs under JSR-220 have independent release cycles? If yes, how will that be mananged?
    4. Up to date J2SE and J2EE have had independent release cycles. Do you see any chance that that need to be tied together from now on because EJB 3. 0 belongs to J2EE 5.0, and part of the JSR has nothing to do with J2EE?
    5. Will the entire EJB 3.0 EG handle ALL issues related to the JSR, i.e., both specs? Do you see any chance of losing focus or splitting the resource? Are we going to have 2 separate sub-EG's?
    6. To be standard compliant, is it required that the JDO implementations support both specs in the JSR-220?
    7. Is there a separate name for the unified persistence spec? Calling it EJB 3.0 is definitely inappropriate if you ask me.

    Thank if you can shed more lights on this issues.
  14. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    1. Is it a natural situation to have a container-independet spec live in a container-dependent JSR?
    Yes, because although POJO persistence will be possible outside the container, there needs to be much discussion on how it integrates with the container for those using J2EE.
    3. Do the 2 specs under JSR-220 have independent release cycles?
    I wouldn't expect they would.
    4. Up to date J2SE and J2EE have had independent release cycles. Do you see any chance that that need to be tied together from now on because EJB 3. 0 belongs to J2EE 5.0, and part of the JSR has nothing to do with J2EE?
    J2EE 1.x has always relied upon J2SE 1.x, I wouldn't expect that to change. But I don't see the worry here, Java has a great track record of backward compatibility. "containerless" persistence vendors aren't going to let this lag, competition won't allow it!
    5. Will the entire EJB 3.0 EG handle ALL issues related to the JSR, i.e., both specs? Do you see any chance of losing focus or splitting the resource? Are we going to have 2 separate sub-EG's?
    I wouldn't expect sub-EG's. There aren't sub-EG for Session Beans, MDB, Entity Beans today, I wouldn't see that as necessary.
    6. To be standard compliant, is it required that the JDO implementations support both specs in the JSR-220?
    That would be a question to ask the JDO expert group and vendors.
    7. Is there a separate name for the unified persistence spec?
    I would say that is TBD, the announcement was made just Monday, so the EG has much to discuss.

     - Don
  15. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    I have totally different opinion from yours so we just have to wait to hear from the EG directly.
  16. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    Eric,

    Very good questions indeed. I agree with the point of every single one of them, and would like to see those issues resolved early rather than at some unspecified point of time in the future.

    Juergen
  17. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    Juergen:

    The Java developers' community need its own open letter to the EJB 3.0 and JDO 2.0 EG's, congratulating them on making a courageous step forward in uniting the ORM persistence API's for Java. In the meantime, we need to point out inadequacies in what have been layed out in the open letter from the EG's to the community, especially with respect to putting this new persistence API under JSR-220.

    IMHO there is not a single better group of people than the SpringFramework developers who can draft and publish this open letter, and have it co-signed by the opensource JDO implementers if possible. I think the message is we are all in support of what the EG's have done, but for the long-term benefits of the entire Java community we need to take a step further do it right now.
  18. since the new persistence API won't require an EJB container, why does it make sense to have it be part of the EJB spec?

    +1 to those hoping that the new unified spec will be backward compatible with JDO 1.0/2.0. JDO 2 (Versant, Kodo, JPOX, etc) would then give us a nice interim technology until 2006, with an easy migration path
  19. since the new persistence API won't require an EJB container, why does it make sense to have it be part of the EJB spec?
    People writing J2EE applications will demand that it be tightly integrated with the J2EE Container. This could be very difficult if the jsr work did not occur with the cooperation and close involvement of the J2EE and EJB group members. So the best solution is to have the "containerless" experts get involved with EJB3.0.

     - Don
  20. People writing J2EE applications will demand that it be tightly integrated with the J2EE Container. This could be very difficult if the jsr work did not occur with the cooperation and close involvement of the J2EE and EJB group members. So the best solution is to have the "containerless" experts get involved with EJB3.0. - Don
    Well, that's for the sake of your argument only. JTA and JMS face a demand for tight integration with the J2EE container too, and solved this through providing explicit hooks for containers in their respective specs. So if this worked for JTA and JMS, why shouldn't it work for a separate persistence JSR too? IMNSHO, there is no good technical reason to keep the persistence spec as unclear kind-of-separate-but-still-dependent child of JSR-220.

    Juergen
  21. since the new persistence API won't require an EJB container, why does it make sense to have it be part of the EJB spec?
    People writing J2EE applications will demand that it be tightly integrated with the J2EE Container. This could be very difficult if the jsr work did not occur with the cooperation and close involvement of the J2EE and EJB group members. So the best solution is to have the "containerless" experts get involved with EJB3.0. - Don
    I don't find this argument convincing. TopLink, Hibernate and JDO are all outside the EJB expert group--the first two, proprietary products, the third a specification that covers integration with J2EE and EJB but is external to EJB. Yet there is no problem using TopLink, Hibernate or JDO with J2EE or EJB. Surely "cooperation and close involvement" should occur as part of the functioning of the JCP overall, without the need for JSR-220 to produce more than one spec. In my experience, most TopLink users are using EJB, unaware that doing so could be "very difficult" because the EJB expert group wasn't responsible for TopLink. OTOH, most Hibernate users are not using EJB, and are happy without it.
  22. In my experience, most TopLink users are using EJB
    Hey Rod, I'd just to clarify, because some people use "EJB" and "Entity Beans" interchangably. Most TopLink customers (90%) are indeed running in a J2EE application of some kind, OC4J, WebLogic, WebSphere, JBOSS, etc. About 10% are running back-end batch processing, fat-client and custom server apps.

    However, most TopLink customers, regardless of J2EE or not, are using our POJO support, not Entity Beans. Easily 80% of TopLink users use it for POJO, and less than 20% use it for Entity Beans (2.x or 1.x).

     - Don
  23. I'd just to clarify, because some people use "EJB" and "Entity Beans" interchangably
    Indeed. This is a common misconception. I was referring to SLSBs and MDBs, not entity beans. My point is that TopLink's POJO (or near-POJO) persistence model works perfectly well with SLSBs and MDBs, although it's not part of J2EE or EJB; integration is at JTA level etc.
  24. since the new persistence API won't require an EJB container, why does it make sense to have it be part of the EJB spec?
    People writing J2EE applications will demand that it be tightly integrated with the J2EE Container. This could be very difficult if the jsr work did not occur with the cooperation and close involvement of the J2EE and EJB group members. So the best solution is to have the "containerless" experts get involved with EJB3.0. - Don
    Will the JSR 220 starting designing adaptors for Companies like SAP, Siebel, CICS and others just because they need to be tightly integrated with the EJB container?
    It seems that JCA is useless if you want to tightly integrate application with EJB. This container looks like very complex to integrate things.

    I hope EJB 3.0 will provide access to the filesystem because it's tightly integrated with everydays applications.
  25. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    What do you have in the EJB 3.0 land? Maybe some early code sitting in a branch somewhere in JBoss's CVS repository?
    That's funny. Take a look at Hibernate downloads. Or Amazon book rankings. The
    popularity of Hibernate. That's exactly what EJB 3.0 has. Backing of a huge developer community.

    JDO 2.0 is still a draft. Interesting, but not finished.
  26. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    Please re-read the posts in the other thread if you believe EJB3.equals("Hibernate").
  27. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    Please re-read the posts in the other thread if you believe EJB3.equals("Hibernate").
    I'm aware of the differences. And the similarities. There has been quite a few threads about this subject and as far as I know, EJB 3.0 persistence looks very much like (a subset of) Hibernate. At least the draft I read. And I'm quite happy to see entity beans, as they currently exist, gone :-)
  28. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    And I'm quite happy to see entity beans, as they currently exist, gone :-)
    They're not gone of course. The EJB 3.0 draft describes the additions dealing with the POJO-based persistence model -- it does not replace the existing persistence models (either 1.x or 2.x), which continue to be available and supported. And that's still the case with the latest announcement.

    :) And in case it's thought that no one is using the existing persistence models, we do have many (satisfied) customers of various sizes, who have significant investments in CMP -- and who are especially interested in how the new POJO model will coexist and intermix with the existing models. The new POJO model has useful features that will appeal to many developers, but there will be customers who choose to continue with the existing CMP models while also taking advantage of the other 3.x features like annotations and the removal of requirements for interfaces. Both persistence models have their place depending on the application.

    Having a single standardized persistence model for those cases where POJO persistence is appropriate, is goodness though.

    Randy Schnier
    I don't speak for IBM, just work there.
  29. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    And in case it's thought that no one is using the existing persistence models, we do have many (satisfied) customers of various sizes, who have significant investments in CMP -- and who are especially interested in how the new POJO model will coexist and intermix with the existing models.

    Yes, I completely agree with your comments. We have thousands of customers who are happy with EJB and existing CMP entity beans. However EJB needs to be simplified to make it compelling for many developers and the issues raised by the community needs to be addressed. It's good that EJB 3.0 is addressing these issues to make both camps happy.

    -Debu
  30. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    Eric,

    I'm not a spoke person for JCP or Sun but here are my obsveration

    "If that is true, why not create a brand new JSR to eliminate any chance of confusion? In the life time of JCP, have we ever had a case where a JSR produced more than one spec? How are we going to address the new unified Persistence spec? EJB 3.0 Part B? Isn't that an oxymoron?"

    I do not know of any JSR producing two specs but why we always look have to backwards. Somewhere there should be a new beginning. Let us give JSR 220 a chance to deliver this.

    "... arguments like above, or EJB 3.0 has progressed so much, and there is such a community support behind EJB 3.0. Those are ALL garbage and I don't buy any of it."

    I do not agree with these statement. Many our customers are very excited about the happening in EJB 3.0. I've seen similar sentiments among the attendees of Linda's presentations both in TSS Symposium and JavaOne2004. Don't you see the similar enthusiasm in several TSS threads that EJB 3.0 persistence model is simplified to use POJO persistence model like Hibernate, TopLink, etc


    -Debu
  31. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    Don't you see the similar enthusiasm in several TSS threads that EJB 3.0 persistence model is simplified to use POJO persistence model like Hibernate, TopLink, etc
    Yeah, I seem the same amount enthusiam for JDO 2.0, if not more than EJB 3.0. How come the unified Persistence spec is not under JSR-243, which has no tie to app servers historically and has always uses a POJO persistence model? Wouldn't you say that is a better place to start?
  32. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    EJB-3.0.0-POJO.jar = 60 MB...

    Your application running with EJB-3.0.0-POJO.jar = 61 MB....

    Your application running with JDO 2.0 is sizeless...

    ...Whatever container and datastore JDO is NOW there... fell free to look Kodo, Lido, Versant Open Access and JPOX.
  33. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    EJB-3.0.0-POJO.jar = 60 MB...
    Your application running with EJB-3.0.0-POJO.jar = 61 MB....
    Your application running with JDO 2.0 is sizeless......
    That's a good one.

    It's certainly the first time I see the size of jar files measured in imaginary numbers.

    --
    Cedric
  34. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    "In the life time of JCP, have we ever had a case where a JSR produced more than one spec? How are we going to address the new unified Persistence spec? EJB 3.0 Part B? Isn't that an oxymoron?"

    Just found out that JSR-53 produced Servlet 2.3 and JSP 1.2 specifications.

    Please look at http://jcp.org/aboutJava/communityprocess/final/jsr053/index.html

    "JSR-000053 Java TM Servlet 2.3 and JavaServer Pages TM 1.2 Specifications"

    And now everybody loves Servlets and JSPs. Let the history repeats itself and give JSR-220 to produce two great specs like JSR-43

    My flavor of numerology suggests JSR-53 and JSR-220 are similar in nature, if you sum up the integers both are divisible by 4 (:-

    -Debu
  35. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    Just found out that JSR-53 produced Servlet 2.3 and JSP 1.2 specifications.
    OK. So there is a historic precedence :-)

    I am not a lawyer but allow me to make one more arguement. If this model is so great, how come Servlets 2.4 and JSP 2.0 later became separate JSR's? I also want to point out that Servlets and JSP's share much more in common (JSP's are "compiled" into servlets) than between EJB and Persistence. To me EJB is primarily about remoting.
  36. The Unofficial EJB 3.0 FAQ Released[ Go to top ]

    My flavor of numerology suggests JSR-53 and JSR-220 are similar in nature, if you sum up the integers both are divisible by 4 (:-
    53 is prime.

    220 isn't.

    A very bad sign. I suggest you check your horoscope.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  37. I don't know if Debu Panda was involved at that time. But when asked at JavaOne 2003 "what are you going to do regards JDO", the Oracle rep on the stage said "Can't we just make it go away?"

    At that time this was quite obviously the feeling amongst the main app server vendors: JDO was an irritant, a disturbance to their tidy control of enterprise app deployments. They didn't like it.

    And now the borg-like EJB group has 'assimilated' JDO.

    Is this a political triumph for those who wanted JDO dead? Or a happy merging of two competing specs to create a sum greater than the parts? I'll wait and see how many of the JDO expert group really end up active in the EJB spec before I draw any conclusions.


    Sean
  38. I don't know if Debu Panda was involved at that time. But when asked at JavaOne 2003 "what are you going to do regards JDO", the Oracle rep on the stage said "Can't we just make it go away?"

    I can't say for anyone else but I did not present in JavaOne 2003 and did not make any such comments.

    Nobody did ask any questions in any of my JavaOne 2004 presentations

    -Debu
  39. EJB != Entity Beans[ Go to top ]

    The notion of persistence and the failures of EJB are prominent and controversial topics that receive probably more response than any other on The ServerSide. And I generally enjoy reading the discussions on here because thankfully most contributers possess a vast level of expertise and insight that overshadows the pseudo-intellectual blowhards that also like to post on here.

    It surprises me, however, that so many confuse the issue by playing fast and loose with terminology. It's always stuff like, "EJB sucks. All hail Hibernate." Hating EJB and/or loving Hibernate are your prerogative. But let's not forget that EJB != entity beans. EJB is the superset of entity beans since it consists of session beans and entity beans. When I reflect on the failures of EJB, I think of things like the degeneration of object-orientation (e.g. no easy inheritance or use of static methods), the absence of I/O from the spec, and the tricky nature of app server-specific deployment descriptors. Yet despite these weaknesses (if in fact you agree that these are weaknesses), I find session beans, especially stateless ones, are pretty cool.

    It is entity beans that can cause some indigestion, and too often people communicate in such a manner as to suggest that EJB sucks when what they really mean is that entity beans suck. Now I am not here to add my own views of how persistence should be. I can't really add anything there. Rather, my intent here is to get people to be aware of what they are talking about. I am looking forward to the EJB 3.0 Spec to see to what extent it addresses the problems I described above, which apply to all kinds of EJBs. And I will certainly look forward as well to see how the entity bean portion of the spec addresses persistence.

    So in our discussions, let's try to be more precise in describing what exactly it is we are praising or criticizing.

    Thanks.
  40. EJB != Entity Beans[ Go to top ]

    VERY well said! Seldom often I see statements here which are so accurate!
    "Alles Unglück kommt von der Terminologie" - Anton Kuh
    "All misery comes from terminology" (Hope this is translated somewhat well)

    regards,

    Messi
  41. Nothing new there[ Go to top ]

    There is nothing new in the FAQ (basically a paraphrase of what is in the open letter and in JCP site) and except talk of Oracle's contribution to the spec and Toplink. Maybe we should wait for the official one from Sun for the answers. Till then the original sources are preferable.