EJB 3.0 Early Draft 2 Released

Home

News: EJB 3.0 Early Draft 2 Released

  1. EJB 3.0 Early Draft 2 Released (70 messages)

    The second early draft for EJB 3.0 has been released. This draft is the first to have two seperate documents: one for persistence, and one for the rest. Some of the changes include support for annotated callbacks, and the long awaited interceptors for Session/Message-Driven Beans.

    According to Gavin King (Expert Group Member), some of the key new additions include:
        * the new callback listener / interceptor architecture
        * the separate document dealing with entity beans that will evolve into a complete specification out-of-container operation of the entity manager (the persistence engine)
        * native SQL queries
        * definition of interoperability with legacy EJB 2.1 clients and servers
        * complete specification of the semantics of association mappings
        * complete specification of the semantics of EJBQL

    EJB 3.0 Downloads
    JSR 220 Detail Page
    JSR 220 Early Draft Review

    P.S. note some of the questions for readers such as: Should we support interceptors for business methods of entity beans?

    Threaded Messages (70)

  2. Traditionally, spec still not available for download :))) Seems like for video cards, processors and others - press release, many journalists, cool techonology, nothing behind.
  3. I've successfully downloaded those specs :).
  4. Can you point to location where you have downloaded spec from?
  5. What's wrong with the links above?

    The first one gets you directly to the download page...
  6. The all references at the end, point to EJB 3.0 draft spec (PDF, 484K), which was published at 28 June 2004
  7. Perhaps the problem is on your side. I can send you the specs via email :). Just mail me here: antonj _at_ list.ru and I'll send zipped docs.
  8. Congratulations to the JSR-220 group!
  9. Named Entities?[ Go to top ]

    Am I missing something, or Persistence draft doesn't have notion of "named entities"? This is very useful feature (in Hibernate 3.0) - allows decople types (classes) from entities - thus You can have few different "Entities" of the same class. I wish something like 'Named Entities' were in EJB 3.0...
  10. Named Entities?[ Go to top ]

    Am I missing something, or Persistence draft doesn't have notion of "named entities"? This is very useful feature (in Hibernate 3.0) - allows decople types (classes) from entities - thus You can have few different "Entities" of the same class. I wish something like 'Named Entities' were in EJB 3.0...

    Named entities will be available when the XML mapping is finalized. If you look at the @Entity annotation, you'll see that it accepts a name. Same with EntityManager methods find. It either accepts a class or string entity name. I think merge/persist and others will ahve to accept a string name as well in the future. I bring this up with the EG

    Bill
  11. Named Entities[ Go to top ]

    Am I missing something, or Persistence draft doesn't have notion of "named entities"? This is very useful feature (in Hibernate 3.0) - allows decople types (classes) from entities - thus You can have few different "Entities" of the same class. I wish something like 'Named Entities' were in EJB 3.0...
    Named entities will be available when the XML mapping is finalized. If you look at the @Entity annotation, you'll see that it accepts a name. Same with EntityManager methods find. It either accepts a class or string entity name. I think merge/persist and others will ahve to accept a string name as well in the future. I bring this up with the EGBill

    I think this is not such a good idea. WIth EJB2, the entity was king. Users defined their object model by using entities. Relationships were to other entities. The abstract bean class was a minor player, just used for implementation of the behavior of the entity.

    With EJB3, this is reversed. With POJO persistence, the class is king. Relationships among classes are defined in the class itself. For example,

    class Department {
    Set<Employee> emps;
    ...
    }

    class Employee {
    Department dept;
    ...
    }

    These are consistent in Java and when you annotate them, or alternatively add xml metadata to make them persistent, they are consistent without reference to the entity. The entity notation is not a central feature of the architecture.

    If you now make a new collection of entities from these classes, each persistent field needs to be annotated with its corresponding entity, adding to the complexity of the metadata.

    This also affects the API. When you call find, merge, or create, you also need to tell the entity manager which entity the argument represents.

    For a specification whose design center is ease of use, this would seem to be a step backward.
     
    Craig
  12. Named Entities[ Go to top ]

    Named entities will be available when the XML mapping is finalized. If you look at the @Entity annotation, you'll see that it accepts a name. Same with EntityManager methods find. It either accepts a class or string entity name. I think merge/persist and others will ahve to accept a string name as well in the future. I bring this up with the EGBill
    I think this is not such a good idea. WIth EJB2, the entity was king. Users defined their object model by using entities. Relationships were to other entities. The abstract bean class was a minor player, just used for implementation of the behavior of the entity.With EJB3, this is reversed. With POJO persistence, the class is king. Relationships among classes are defined in the class itself. For example,class Department {Set<Employee> emps;...}class Employee {Department dept;...}These are consistent in Java and when you annotate them, or alternatively add xml metadata to make them persistent, they are consistent without reference to the entity. The entity notation is not a central feature of the architecture.If you now make a new collection of entities from these classes, each persistent field needs to be annotated with its corresponding entity, adding to the complexity of the metadata. This also affects the API. When you call find, merge, or create, you also need to tell the entity manager which entity the argument represents.For a specification whose design center is ease of use, this would seem to be a step backward.&nbsp;Craig


    The thing is, most applications do not map the same class in multiple ways. So, it makes sense to have a "class is king" approach as it makes declaring annotations less verbose and goes along with the norm. Part of ease-of-use is designing to the norm rather than the tangent use case or trying to write a "one-size-fits-all" API.

    But, I think you are wrong in stating that in EJB3 "class is king". I contend that either the class or entity are kings. It is up to the application developer. If you look at all the relationship annotations, you'll see that they all can take a "targetEntity()". Since the XML mappings will be a parallel meta-model to annotations, the same choice can be made there as well.

    Bill
  13. Named Entities[ Go to top ]

    But, I think you are wrong in stating that in EJB3 "class is king".

    Bill,

    this is not what Craig said. What he said was:
    With POJO persistence, the class is king.

    Now the interesting question is what exactly we mean when we say
    An entity bean is a lightweight persistent domain object. [Chapter 2]

    Is this the same as a POJO? If not, what is the difference?

    Cheers,
    Oliver
  14. Named Entities[ Go to top ]

    But, I think you are wrong in stating that in EJB3 "class is king".
    Bill,this is not what Craig said. What he said was:
    With POJO persistence, the class is king.
    Now the interesting question is what exactly we mean when we say
    An entity bean is a lightweight persistent domain object. [Chapter 2]
    Is this the same as a POJO? If not, what is the difference?Cheers,Oliver

    Again, I fail to see relevance of his post even if he is just talking about POJO Persistence. Multiple mappings per class (in the same application) is the fringe use case, not the norm. You design the API to be very simple with the norm, while the esoteric use case is a bit harder to configure. A framework that is easy to use at first and then easy to extend with tangent use-cases facilitates iterative development.

    Besides, this so-called "complexity" really isn't that complex and therefore irrelevant, IMNSHO.

    Bill
  15. Named Entities[ Go to top ]

    An interesting point is that developers _already_ make good use of this feature, as can be seen by the questions on the Hibernate(3) forums.
  16. Named Entities[ Go to top ]

    I'd understand if you say you disagree with the post, but if you can't see its relevance, you really need to work on your reading skills.

    No need to explicitly point out the 'not so humble' bit, though.

    Oliver
  17. Named Entities[ Go to top ]

    No need to explicitly point out the 'not so humble' bit, though.Oliver

    Apologies on the tone...Sometimes I just lack the patience to be nicey-nicey or PC.
  18. [OT] Patience?[ Go to top ]

    No need to explicitly point out the 'not so humble' bit, though.Oliver
    Apologies on the tone...Sometimes I just lack the patience to be nicey-nicey or PC.

    IMNSHO it's not only the patience you are lacking... :-/

    Lars
  19. Named Entities[ Go to top ]

    Again, I fail to see relevance of his post even if he is just talking about POJO Persistence. Multiple mappings per class (in the same application) is the fringe use case, not the norm. You design the API to be very simple with the norm, while the esoteric use case is a bit harder to configure. A framework that is easy to use at first and then easy to extend with tangent use-cases facilitates iterative development.Besides, this so-called "complexity" really isn't that complex and therefore irrelevant, IMNSHO.Bill

    To clarify why I think my post is not irrelevant, I'll be happy to summarize my issue with multiple mappings of the same class.

    1. It's a fringe use case (I agree with Bill here) and therefore does not belong in the spec in version 1.
    2. It pollutes the spec making it more difficult for users to understand what's basic and what's fringe (the additional xml metadata plus the additional parameters on create and merge).
    3. It makes it more difficult to add features in future (e.g. createAll taking a heterogeneous Collection of entity instances).
    4. Vendor extensions can implement this feature and customers can provide feedback to a future JSR on whether it's really a core feature.
    5. There are lots of features that we have already decided are not core enough to put into the persistence API for version 1. In my opinion, multiple mappings per class is not as important as other dropped features.

    Craig
  20. Named Entities[ Go to top ]

    2. It pollutes the spec making it more difficult for users to understand what's basic and what's fringe (the additional xml metadata plus the additional parameters on create and merge).

    I disagree. I think it is perfectly easy to understand. Especially in pure XML deployments. In general, people are going to name their Entities anyways, so its not that big of a leap to support this X-1 mapping.
    3. It makes it more difficult to add features in future (e.g. createAll taking a heterogeneous Collection of entity instances).

    Now that's a good fringe of the fringe.
    4. Vendor extensions can implement this feature and customers can provide feedback to a future JSR on whether it's really a core feature.

    Ask the hibernate guys. They added it to Hibernate based on user feedback.
    5. There are lots of features that we have already decided are not core enough to put into the persistence API for version 1. In my opinion, multiple mappings per class is not as important as other dropped features.Craig

    Yeah, but its trivial...

    FWIW, a few others on the EG agree with you.

    Bill
  21. O/R Mapping[ Go to top ]

    When annotations determining O/R mapping, does this mean that when the DB changes we have to change the annotations and recompile/redeploy?

    When I see a 'POJO' class that looks like below, and over 100% code bloat, not including any javadoc, I tend to believe that an external mapping (like JDO / Hibernate / Toplink) wouldn't help to make things a bit simpler to understand.

    I feel the term 'POJO' is being abused.
    @ManyToMany(mappedBy="employee", cascade=PERSIST)
    @AssociationTable(
    table=@Table(name="EMP_PROJ"),
    joinColumns=
    @JoinColumn(name="EMP_ID", referencedColumnName="ID"),
    inverseJoinColumns=
    @JoinColumn(name="PROJ_ID", referencedColumnName="ID")
    )
    public Collection<Project> getProjects() { return projects; }
    public void setProjects(Collection<Project> projects) {
    this.projects = projects;
    }
  22. O/R Mapping[ Go to top ]

    You could use external metadata in XML? It was one of the major new things in the new draft you just read.
  23. Major New Things?[ Go to top ]

    Mr. Burke 'I've stated this over and over again'

    Would be nice to see it clearly demonstrated in the 220 Persistence Specification. Seems the EJB EG loves annotations, but I know many developers who think it is code clutter, and who prefer to keep meta-data outside of the classes.
    So probably specification asumes database and application is well designed.
    Since we are only working with stable object designs, and databases that never change, the meta-data will never change (kind of like us JDO lovers ;-)

    I hear a waterfall...
  24. Seems the EJB EG loves annotations, but I know many developers who think it is code clutter, and who prefer to keep meta-data outside of the classes.

    Good points. Since the overloading mechanism of XML descriptors has to be provided for one reason or the other, it seems that declaring object/relational mapping through annotations is unnecessary and confusing. See the following link for more reasons to avoid annotations altogether for O/R mapping:

    http://www.theserverside.com/news/thread.tss?thread_id=31488#155704
  25. The spec cleary says, ejb-3_0-edr2-spec-persistence.pdf, page 119:

    "The XML deployment descriptor is intended to serve as both an alternative and an overriding mechanism to the use of Java language metadata annotations."

    Which means you choose, either use metadata annotations or an XML-deployment descriptor.
  26. The spec cleary says, ejb-3_0-edr2-spec-persistence.pdf, page 119:"The XML deployment descriptor is intended to serve as both an alternative and an overriding mechanism to the use of Java language metadata annotations."Which means you choose, either use metadata annotations or an XML-deployment descriptor.

    That’s the problem! Why even create a choice that cannot provide a complete solution on its own and presents many disadvantages? Even if we set aside the problem of ugly code-clutter due to using annotations for declaring O/R mapping in the source files, the following points explain why the industry would be much better off without such a questionable feature:

        * EG members have to work longer and harder to provide details on two different mechanisms (annotation and XML) for declaring every mapping element and various combinations.

        * Overriding behavior of XML over annotation has to be specified exhaustively.

        * Any future modifications and extensions have to be specified and implemented for both the mechanisms.

         * Thousands of additional test suits (for TCK) have to be developed, run, and analyzed to check mapping through annotations and mapping through annotations with XML overrides.

        * Any vendor implementing the new persistence standard or associated tools has to spend a lot of extra time and resources to incorporate two different mechanisms for the mapping specification.

        * Trainers have to create extra lessons to teach multiple ways of defining O/R mapping.

        * Users (developers and deployers) have to make significantly extra effort to learn and use two different ways of doing essentially the same thing. Worse, poor users have to cope with many subtle bugs, which would inevitably crop up by the overriding behavior of XML over annotations.

    So why go down the path that is going to be a lose-lose-lose-lose-lose-lose situation for EG members, vendors, trainers, developers, deployers, and end users? Why propose a substantially elaborate feature that has only a fringe benefit but has a huge cost associated with it. Defining mapping through annotations makes neither technical nor business sense. It will create an unnecessary burden on the community.
  27. Well, I'd estimate the number of Hibernate users who use XDoclet annotations between 30% and 50%. They certainly don't do it because its a lose-lose-whatever situation.

    There is no duplication, for example. If you know one syntax, you know the other one. The semantics are also the same in both metadata mechanisms. The "industry" has already decided that its a useful feature because thousands of people use it for some years now. I'm working on the front of the groups you talk about (well, not EG, but I never heard about a problem there) and none of your points are an issue. What is the basis of your claims? Personal preference? It sure is.
  28. One Man Shows[ Go to top ]

    What about the 50%-70% of Hibernate users who use XML? What about the 100% of Toplink users who use XML. What about the 100% of JDO developers who use XML? Oh, I forgot, this JSR is being driven by the JBoss camp-

    Annotations in source code are great for a one person show, who can change all tiers as needed when tweaks need to be done.

    In the real world of big business (where money is to be made by the EJB Container Vendors), you have Architects, Coders, DBAs, Operations, etc..., and this flexibility, even in a Agile world, just ain't happening.

    EJB was never meant to be a tool for 'hackers', but thanks to the Hibernate crew it will become just that, right at the time when all the Open Source tools are getting the EJB2 stuff workable for the masses.

    The resulting lag in tooling, education, beta/bug fixing will be just right for the .NET world to gain footing.
  29. One Man Shows[ Go to top ]

    So, use XML if you are happy with that and it fits your organization. Nobody forces you to do anything. There will always be both options, because its trivial to maintain them.

    Why do you want to take away options used by thousands, for no apparent reason? And if you think that the TOP 500 organizations I've seen annotations being used at are One Man Shows... well, thats your opinion and view of reality of course.

    My point is that the duplication the Anonymous Coward sees as an issue simply doesn't exist in the real world. I spend 20 minutes in a 3 day training teaching people XDoclet (after they know the Hibernate metadata basics in XML) and its more than enough. Everybody understands it right away and the consequence of using one or the other are also trivial to understand. The only place where this is seen as a problem is TSS (well, its the same five people every time, really).

    P.S. Developers in .NET use annotations all over the place and they like it.

    P.P.S. I don't see a reason to continue this discussion if you keep throwing mud at me and my work. Your cheap shots at JBoss and Hibernate are not needed.
  30. One Man Shows[ Go to top ]

    In the real world of big business (where money is to be made by the EJB Container Vendors), you have Architects, Coders, DBAs, Operations, etc...,

    Um. Interesting. I have honestly never seen or heard of an EJB deployment desciptor edited by an

    * Enterprise architect
    * DBA
    * Operations guy

    and I'm intensely skeptical that this happens in practice. You must be working in a very unusual organizations where DBAs edit deployment descriptors. The two roles who change EJB metadata in practice are:

    * developer
    * deployer

    We are designing the EJB spec to support definition and overriding of metadata by both the developer and deployer.

    FYI, I have seen XDoclet used very successfully in several highly corporate environments with 50+ developers, hundreds of entities, conservative data professionals and conservative ops people.

    Methinks you are bashing something you've never actually tried to use in practice.
  31. Have tried it, don't like it[ Go to top ]

    I think annotations are code clutter, and that deployment descriptors should be kept outside of the code. FYI, I have worked in many large companies who use external deployment descriptors on many big projects very successfully!

    You EJB3 guys seems to believe most developers prefer annotations to external meta-data, and I (and others) beg to differ. I see the point of 'ease-of-use', and argue it is great for one-man-shows who control the all tiers and J2EE development roles.

    But, this seems to me like the developer and deployer role is now one, and the new EJB3 Role of 'develoployer' will need to know 2 languages. Please argue differently.

    The arguments of duplicated effort and testing bloat made by Anonomous Coward make sense to me, as well. Please argue differently.

    It's hard not to bash JBoss.org, because the actions of JBoss.org annoys me (re Geronimo, no vote on JDO2, etc...), and the non-recognition of the JDO specification work is plain arrogant - EJB3 Persistence offers a subset of the functionality of the JDO2 specification. Please argue differently.
  32. Have tried it, don't like it[ Go to top ]

    Hi,

    while I am not a big annotation fan myself (at least not for everything and everywhere), I do not see a big problem here: you (and I) will be able to use XML descriptors instead of annotations--at least that is the intent as stated so far, and I have no indication of the contrary at this time.

    Just as you do not want to be forced to use annotations, many other people apparently do not want to be forced to use XML descriptors. I think this is one of the rare cases where we can have it both ways.

    Kind regards,
    Oliver
  33. Problems with annotations for O/R mapping[ Go to top ]

    Minimal standards have the best chances to succeed because their conciseness and clear semantics make them easy to understand, implement, and adopt. Given that one major goal of EJB 3.0 is the simplification of persistence through POJO O/R mapping, it would behoove the EG to create the initial persistence specification that is concise and logically complete.

    Chapter 5: Metadata for Object/Relational Mapping takes 34 pages out of the total of 132 pages (25%) of the Persistence specification. Efforts to standardize an elaborate optional mechanism to declare O/R mapping through annotations seems like an imprudent use of EG resources. Additionally, to be standards compliant, the vendors have to put in enormous extra efforts and resources to implement and support this alternative way of mapping specification. This will result in late and buggy product rollouts and the whole industry would suffer because of that. So it would be advisable to not stretch the penchant for annotations to the area of O/R mapping specification.
  34. Problems with annotations for O/R mapping[ Go to top ]

    Efforts to standardize an elaborate optional mechanism to declare O/R mapping through annotations seems like an imprudent use of EG resources. Additionally, to be standards compliant, the vendors have to put in enormous extra efforts and resources to implement and support this alternative way of mapping specification. This will result in late and buggy product rollouts and the whole industry would suffer because of that.

    I am not aware of any EG member or vendor who has raised this as a concern. Nor am I aware of any vendor who considers this an "enormous extra effort". So your concerns would appear to be totally spurious unless you can nominate a vendor who feels this way.
  35. Problems with annotations for O/R mapping[ Go to top ]

    I am not aware of any EG member or vendor who has raised this as a concern. Nor am I aware of any vendor who considers this an "enormous extra effort". So your concerns would appear to be totally spurious unless you can nominate a vendor who feels this way.

    There can be no denying that providing two ways of mapping declaration leads to the bloating of the standard and requires major extra efforts in its implementation. It’s hard to say why no EG member or vendor has raised this as a concern so far. Hopefully this thread would make them more aware of the associated problems from different points of view. A focused standard will benefit everyone.
  36. The spec cleary says, ejb-3_0-edr2-spec-persistence.pdf, page 119:"The XML deployment descriptor is intended to serve as both an alternative and an overriding mechanism to the use of Java language metadata annotations."Which means you choose, either use metadata annotations or an XML-deployment descriptor.

    I think many in the expert group agree that XML takes precedence over annotations, but annotations vs. XML is not an either/or choice. I think the general idea is that XML overrides or adds to the meta-model.

    Bill
  37. I agree, the spec should center on the requirements, this seems to be the provision of two declarative stages, with one overriding the other (and the flexibility to choose either) - otherwise why implement only TWO ways of doing the same thing, why not add a 3rd way of declaring meta data? or has that role not been discovered yet?

    I could certainly see myself using both declarative forms, although the merging of the meta data to paint a single picture will always be required.
  38. O/R Mapping[ Go to top ]

    When annotations determining O/R mapping, does this mean that when the DB changes we have to change the annotations and recompile/redeploy?When I see a 'POJO' class that looks like below, and over 100% code bloat, not including any javadoc, I tend to believe that an external mapping (like JDO / Hibernate / Toplink) wouldn't help to make things a bit simpler to understand.I feel the term 'POJO' is being abused.
    @ManyToMany(mappedBy="employee", cascade=PERSIST)@AssociationTable(table=@Table(name="EMP_PROJ"),joinColumns=@JoinColumn(name="EMP_ID", referencedColumnName="ID"),inverseJoinColumns=@JoinColumn(name="PROJ_ID", referencedColumnName="ID"))public Collection<Project> getProjects() { return projects; }public void setProjects(Collection<Project> projects) {this.projects = projects;}

    XML will be an alternative meta-model. I've stated this over and over again....Some developers like XDoclet some don't. Some like a mix where it make sense.

    BIll
  39. O/R Mapping[ Go to top ]

    Schema changes do not effect applications in theory, You do not need to change application to change shema, application works with logical view of database if some kind of modeling was used to design it (logical view is stable in well designed database) and you can do it in transaction.
    So probably specification asumes database and application is well designed.
  40. Summary of new stuff[ Go to top ]

    I've blogged a short list of some of the changes here:

    http://blog.hibernate.org/cgi-bin/blosxom.cgi/2005/02/09#edr2

    I'd encourage people to download and read the spec, send us feedback....

    Cheers
  41. Summary of new stuff[ Go to top ]

    send us feedback

    On Querry API:
    Object getSingleResult() I think implies a bean
    A lot of us return a Map of values.
    Maybe a
    Map getSingleResultAsMap()

    same on parms
    setPrams(Map prams)

    Can SQLResultMapping be a HashMap so I do not have to map

    Can SQLResultMapping be externalized to a XML file

    Can SQL Strings be externalized to a XML file like in Hibrenate or iBatis

    Why 4 types of beans. why does it matter, if I have a "remote" interface, I just want to use it, and maybe change lifecycle as I see fit.

    Can EJB return a List of Maps (SOAP can't)

    Can we return a rowset, and can I bypass O/R or that is a must, like can I just use it E/R style.

    Is there any Cache API

    Can it be used accross other SoA protocols

    Why does interface have to be in anotations, what's wroing with IoC XML type mapping or even a plain interface

    Can you specify EJBQL SQL ANSI level, like is is ANSI 99 or ANSI 88 or what level SQL is it.

    What is the support for stored procecures and mapped functions

    You know, it's quite silly to require a primary key for a result of a querry.(EJB must have a PK!?)

    Pagniation of results should be optional, it's a good way for newbies to get in trouble.

    Any JMX capbilities? Like monitor Cache Hits, rate of selects, durations of selects, free memory,

    .V
  42. a few more[ Go to top ]

    once a user logs into an EJB server, is his userID visable in the context of each querry?

    once a user is loged in, can they see a list of ejbs and their methods? (SoA style)

    can I call an EJB and it's mapped method via Strings?
    Ex: execCRUD("CarsEJB","updateMapedCmd3", parms)

    Can a querry results be returned as XML ?

    Any comments on the pattern used linked in the middle of this page?
    http://www.macromedia.com/devnet/mx/flash/articles/databinding_03.html

    .V
  43. Feedback[ Go to top ]

    Discussions on TSS are certainly entertaining and useful, but as the spec says:
    Please send comments to: ejb3-edr2-feedback at sun dot com

    This way your comments will go to everyone involved, not just the folks who happen to read the TSS threads.

    Thanks,
    Oliver
  44. Feedback[ Go to top ]

    Please send comments to: ejb3-edr2-feedback at sun dot com. This way your comments will go to everyone involved, not just the folks who happen to read the TSS threads.

    It was posted here. Any “EG” that does not read TSS, I sincerely don’t want their opinion.

    <rant
    Also, what makes you think that I would ever want to help an EJB JCP? How many people are burnt by EJB? How much prepetuated lies? "EJB is scalleable". It's almost expected to lie in J2EE world.
    That whole group had put quite hurting on my work for many years, helping them would be like “Stockholm syndrome”. Sun itself has resoruces so focused on marketing EJB that it puts minimal resources on the Desktop Java deployment issues. (Ex: JDNC group is writing an EJB sample in addition to working on UI.)

    I think it better to do my best to make sure none of my clients or projects ever attempt EJB 3, EJB 4, or O/R. I’d muc rather see them on Ruby on Rails, looks like fun to develop.
    />

    .V
  45. Feedback[ Go to top ]

    Vic

    My reply was a follow-up to Gavin's post. Gavin replied to the initial post in this thread.

    Kind regards,
    Oliver
  46. Feedback[ Go to top ]

    It was posted here. Any “EG” that does not read TSS, I sincerely don’t want their opinion.

    ROTFL! You can't be serious Vic. I like you, as you seem to have honest opinions, but when has anybody ever gotten good feedback from TSS? It's usually a pissing contest of who can destroy the other's argument first and better. I feel like I need to take a shower after engaging TSS with all the mud that is flying around.
    Also, what makes you think that I would ever want to help an EJB JCP? How many people are burnt by EJB? How much prepetuated lies? "EJB is scalleable".

    We have a large number of successful projects using EJB as I'm sure the other vendors and OSS J2EE projects have. That's not to say that people don't write unscalable EJB applications. "Not scalable" usually comes in three flavors.

    1) CMP 2 query language was so significantly hobbled that to perform well, you needed to escape to straight JDBC.
    2) Vendor incompetence. I know our CMP implementation didn't scale well until Alex Loubyansky implemented optimistic concurrency a few years ago.
    3) Incompetent users. There's a lot of developers out there that don't understand database concurrency. Their projects would "not scale" with any framework. Many expect their applications to run out-of-the-box with zero tuning.

    So, in reality the spec was only a third of the problem. The impotence of EJBQL has been addressed in the new specification. As for vendor incompetence, I feel pretty confident building our impl on top of Hibernate 3.0.

    Off to take a shower...

    Bill
  47. Feedback[ Go to top ]

    I know our CMP implementation didn't scale well ...
    Then only J2EE vendor to admint!
    What about it BEA, IBM, Sun.
    There's a lot of developers out there that don't understand database concurrency. Their projects would "not scale" with any framework.
    I agree that percentage wise, Java developers know least SQL. But... the marketing says that you don't have to bother with SQL if you do EJB. So... that's also the vendors fault IMO.
    EG should have customer that have implemented VLDB (large dbs).
    Vendors should be teaching SQL performance and tunning, if they want to use the word "enterprise", else it's just a pure lie. (I'd be glad to teach a SQL tuning class for jBoss)

    You got a point about showers.. but this site is for play, play, it's not for real, real. In a client meeting, I keep my mouth shut and try to nod inteligent!

    .V
  48. EG should include customers[ Go to top ]

    EG should have customer that have implemented VLDB (large dbs).

    Vic

    I think we are back to square one again. If users want to get involved, all they have to do is join the JCP and get in touch with the relevant spec leads. Alternatively, they could participate as "Individual Experts" even without being a JCP member.

    It is interesting that you expect other users of Java technology to get involved in the process while you don't even want to provide feedback to an EG yourself (and as evidenced by your posts, you have a lot of comments on the draft).

    Oliver
  49. Feedback[ Go to top ]

    Vendor incompetence. I know our CMP implementation
    > didn't scale well until Alex Loubyansky implemented
    > optimistic concurrency a few years ago.

    Actually, I think your CMP 2.0 implementation (in 4.x)
    still does not scale very well.

    I did try tuning your CMP engine - and you can find
    what I did here

    I was thinking of publishing some of those benchmark
    results sometime soon, but want to make sure that
    I've squeezed the maximum possible out of your CMP
    2.0 engine.

    -krish
  50. Feedback[ Go to top ]

    > Vendor incompetence. I know our CMP implementation > didn't scale well until Alex Loubyansky implemented > optimistic concurrency a few years ago.Actually, I think your CMP 2.0 implementation (in 4.x)still does not scale very well.I did try tuning your CMP engine - and you can findwhat I did hereI was thinking of publishing some of those benchmarkresults sometime soon, but want to make sure thatI've squeezed the maximum possible out of your CMP2.0 engine.-krish

    Yeah, you missed a few things. Let's take this to the forums.
  51. OT: JBoss 'Whip' Banner Ad[ Go to top ]

    What's up with JBoss's Ad with the woman that has a whip? For me at least, I see that whip and think, "God, she must know a lot about J2EE containers". Is that mask some kind of new wearable PC that I haven't heard of yet?
  52. Feedback[ Go to top ]

    Done, take a look at JBoss forums. If this is all, will
    redo the benchmark and publish new figures if there is
    an improvement in throughput (transactions per second).

    -krish
  53. Feedback[ Go to top ]

    Incompetent users. There's a lot of developers out there that don't understand database concurrency. Their projects would "not scale" with any framework.
    But they were told that they did not need to! In reality they needed to understand everything about database they worked with, in addition to app server own concurrency/locking settings. This chain of "myapp is appserver client, appserver is db client" had to be understood. Talking about incompetence, one J2EE vendor was compiling EJB stub classes based on deployment descriptors! Bye-bye, deployer role.
  54. Feedback[ Go to top ]

    Any “EG” that does not read TSS, I sincerely don’t want their opinion.

    You can't be serious <SNIP> when has anybody ever gotten good feedback from TSS? It's usually a pissing contest of who can destroy the other's argument first and better.

    If the "EG" does not care about what this (or JL) community is thinking/doing... what do they care about?

    "EG" needs to keep up with this and blogs, for sure.


    .V
  55. Feedback[ Go to top ]

    Any “EG” that does not read TSS, I sincerely don’t want their opinion.You can't be serious <SNIP> when has anybody ever gotten good feedback from TSS? It's usually a pissing contest of who can destroy the other's argument first and better.
    If the "EG" does not care about what this (or JL) community is thinking/doing... what do they care about?"EG" needs to keep up with this and blogs, for sure..V

    I don't entirely agree with Bill's comment about feedback. Although there is a lot of noise on TSS, I have had very useful feedback from recent threads on a variety of topics (I have recently learned a lot more about alternative web GUI systems on the JSF topic from a few days ago). But, there is a major problem about getting feedback from forums like this and blogs as they are self-selecting: after all, how many typical Java users and developers post here or have blogs? I have no idea about how anyone would go about getting the opinions of the typical developer. As for this being a pissing contest, well I think that is a problem with posts anywhere: apart from the occasions where this is intentional, it can be that one person's attempt at a reasonable post or question may be interpreted as hostile or ranting by another. Other than through moderation, it is hard to see how that can be avoided.
  56. attributes[ Go to top ]

    I do not agree that attributes for dependency injection, interceptors, etc... being defined by the ejb 3.0 spec.

    They should be defined in a separate spec to make them usable without an ejb container.


    Carlo.
  57. attributes[ Go to top ]

    I do not agree that attributes for dependency injection, interceptors, etc... being defined by the ejb 3.0 spec. <
    Actually, there are efforts underway to generalize the work done in JSR-220 to the rest of the J2EE platform. I'm not sure of the true status of this stuff, but there is a definite desire to see this happen.

    >> They should be defined in a separate spec to make them usable without an ejb container. <
    I think your definition of "ejb container" is a bit narrow. "EJB container" does not need to mean "websphere-style monolithic J2EE server". An EJB3 container can be a lightweight, embeddable microcontainer that you would use inside a Swing app for example. The ejb spec doesn't force you to have a heavyweight implementation - indeed, by splitting out the persistence stuff, it explicitly acknowledges the notion of operation outside the traditional monolithic container - and some vendors are changing their approach to this. Of course it will be a while before you can embed WebSphere, but IBM is always a couple of years behind...
  58. EJB3 Container[ Go to top ]

    So, EJB3 containers, as Servlet containers used to be, will be able to run on top of J2SE?

    That sounds interesting!
  59. EJB3 Container[ Go to top ]

    So, EJB3 containers, as Servlet containers used to be, will be able to run on top of J2SE?

    EJB3 containers will run on J2SE, neither "on top of J2SE", nor neccessarily on J2EE servers as EJB2 containers.
  60. Hi.

    I just briefly looked through the persistent specification which supposedly sould be able to be used with J2SE only.

    But I saw only a single statement that it should work stand-alone with J2SE, but no hint of how this should be done in practice.

    There are a lot of mentions of "the container" in the spec, but no explanation about what "the container" is, so I assume that it refers to a J2EE container. But I thought, it would be possible to use EJB3 POJO persistence with J2SE only (i.e without a J2EE Server), not that I would have to use a J2EE container in the J2SE only case.

    Can anyone with insight in the EJB3 POJO Persistence shed some light into this?

    As I said, I just briefly looked through the spec. so, I might have missed something obvious.

    Cheers,
    Johan Strandler
    Smart Connexion
  61. J2SE, stand-alone and the container?[ Go to top ]

    Hi.I just briefly looked through the persistent specification which supposedly sould be able to be used with J2SE only.But I saw only a single statement that it should work stand-alone with J2SE, but no hint of how this should be done in practice.There are a lot of mentions of "the container" in the spec, but no explanation about what "the container" is, so I assume that it refers to a J2EE container. But I thought, it would be possible to use EJB3 POJO persistence with J2SE only (i.e without a J2EE Server), not that I would have to use a J2EE container in the J2SE only case.Can anyone with insight in the EJB3 POJO Persistence shed some light into this?As I said, I just briefly looked through the spec. so, I might have missed something obvious.Cheers,Johan StrandlerSmart Connexion

    No, in the persistence spec, "the container" means "the entity bean container". ie. the EntityManager

    All that is needed is to define an API to get an instance of EntityManager programmatically, which will be addressed in the next draft of the spec. (It's a virtually trivial problem, Patrick Linskey has a short proposal that is under consideration in the EG.) I imagine this will require one or two pages in the final spec.

    Otherwise, everything you see there is just perfect for operation with or without a session bean.
  62. EJB 3.0 Early Draft 2 Released[ Go to top ]

    There are many interesting things in both documents, but probably this stuff too experimental to become a "standard".

    As I understand persistence is about fake Object Database + Data Access framework on top of RDBMS. How about cache ? Is it optional ? Will I get consistent results if I will mix SQL and EJBQL in the same transaction ? How it will work if I will update table and execute query on view in the same transaction ? Are you going to specify how this stuff will integrate with triggers ?
  63. EJB 3.0 Early Draft 2 Released[ Go to top ]

    BTW. Why implementation must use native SQL ? It doe's not look consistent with JDBC SQL dialect specification. Is it flaw in persistence specification or it has some hidden meaning ?
  64. Interceptor Question[ Go to top ]

    Page 27 of 64 (@Interceptor example on a @Stateless bean).

    How does the container know which interceptor to invoke for a particular method.

    Or is it such that all interceptors are invoked (in the order that they are declared), for all business methods. If this is indeed true, then the obvious question is, what if I want to turn off the security-interceptor for business_method_1, while keeping it on for business_method_2?
  65. Apply to all methods?[ Go to top ]

    Page 27 of 64 (@Interceptor example on a @Stateless bean). How does the container know which interceptor to invoke for a particular method. Or is it such that all interceptors are invoked (in the order that they are declared), for all business methods. If this is indeed true, then the obvious question is, what if I want to turn off the security-interceptor for business_method_1, while keeping it on for business_method_2?

    I was first confused too (especially those of us use AspectJ). After looked at couple of examples, I believe all interceptors apply to all business methods, which of course leads to your valid question. Hope someone from EG will give us an answer or clarify.
  66. method-level interceptors[ Go to top ]

    Page 27 of 64 (@Interceptor example on a @Stateless bean). How does the container know which interceptor to invoke for a particular method. Or is it such that all interceptors are invoked (in the order that they are declared), for all business methods. If this is indeed true, then the obvious question is, what if I want to turn off the security-interceptor for business_method_1, while keeping it on for business_method_2?

    Yes, I have this on my list of issues. I agree method level interceptors would be very nice.

    For now, I would say that you can annotate the methods that you want an aspect to apply to with your own annotation, and have the interceptor reflect upon the target method to determine if it has the annotation, before triggering the functionality.

    This is also how to build Spring-like AOP functionality on top of EJB3, incidentally. Just define your own pointcut language! ;-)
  67. method-level interceptors[ Go to top ]

    Thanks Gavin. @Interceptor (method level will be even better) is indeed a great idea. Custom lifecycle for the business interface!

    So what other methods (other than 'proceed()') does the InvocationContext interface support to control the flow of execution?

    Also, is the @Interceptor method called both before and after the business_method? OR can I have it executed only before or only after a business_method?

    Between two @Interceptor(s), invoked sequentially of-course (can I have them executed parallelly?), is there a way to pass some arbitrary parameters (thru InvocationContext?)

    Again, some really good work out there. Hope EJB 3.0 beats the hell out of the .NET camp!

    chEErs!
  68. interceptors[ Go to top ]

    Also, is the @Interceptor method called both before and after the business_method? OR can I have it executed only before or only after a business_method?


    It is an around style interceptor, which is more flexible than either :-)
    Between two @Interceptor(s), invoked sequentially of-course (can I have them executed parallelly?)
    ,

    I don't know what you mean by this. You mean in different threads?
    is there a way to pass some arbitrary parameters (thru InvocationContext?)

    Yep :-)
  69. interceptors[ Go to top ]

    It is an around style interceptor, which is more flexible than either :-)
    How, if you can elaborate, or point me to sthg that does.
    I don't know what you mean by this. You mean in different threads?
    As crazy as it sounds, is it possible?
  70. interceptors[ Go to top ]

    It is an around style interceptor, which is more flexible than either :-)
    before/after callback lets optimize interception (delegation in "prossed"), it has meaning if method is as trivial as field access.
    BTW Is this stuff inherited by subclasses or can be hidden by subclass ?
  71. Maybe (hopefully) I missed it in my review of the spec, but is there any hope for having declarative exception handling added to the spec?

    It is painful to have to jump through hoops when you have a RuntimeException that you don't want to cause an automatic rollback, or a non RuntimeException that you do want to cause an automatic rollback. (Especially when the exceptions originate from framework code you are using where you don't have a choice of the approach.)

    The second scenario is especially painful because you either need to catch the non-runtime and throw a runtime, or you need to explicitly call setRollback only, which forces you to hard code transactional logic in your code.

    I would imagine a simple metadata tag for declaring transaction rollback characteristics for specific exceptions would handle this nicely (probably defaulting to the existing EJB approach).

    I suppose you might be able to use the new interceptor feature to accomplish this, but even that seems like a lot of hoop jumping for something which should be so much simpler....