JSR-220, EJB 3.0, reaches Proposed Final Draft

Discussions

News: JSR-220, EJB 3.0, reaches Proposed Final Draft

  1. JSR-220, the Enterprise JavaBean 3.0 specification, has reached Proposed Final Draft status. Programmers should expect that implementations should start to solidify now, although minor changes can still occur.

    There are a number of EJB 3.0 implementations available, including that from the JBoss application server, Glassfish (which is the reference implementation), Oracle's EJB3 beta, and JoNaS has a preview available. There are likely to be others; feel free to send in descriptions (and urls) to editor at theserverside dot com to be included.

    Threaded Messages (155)

  2. Solidify ? Is BEA giving up on the "liquid" stuff ?
  3. Yeah, didn't they just pick up Solarmetric and Nitrox? Can't wait to see what they do with it in their Eclipse-based IDE!

    Hopefully, it will be something more managable than that monstrocity of a tool from IBM - RAD.

    -Lou
  4. Any adjustments since last time?[ Go to top ]

    1st complaints were that there is no support for Collections.
    Will this wait for EJB 4 ?

    2nd, it was rummored that it would be called Entities instead of Enteriprse Beans, addressing collections and POJO.

    All this does is replaces interfaces w/ X-doclet style anotations (which then make it an interface behind the scene, messing up J2SE 5 w/ anotations syntax. And still its not amined at SQL centric, if one is SQL centic, why EJB? Trsnasctions are only for muti-data source).

    There are so many other remoting frameworks (for talking to SQL centric DAO. )

    At least support collections.


    .V
  5. Any adjustments since last time?[ Go to top ]

    1st complaints were that there is no support for Collections. Will this wait for EJB 4 ?2nd, it was rummored that it would be called Entities instead of Enteriprse Beans, addressing collections and POJO.All this does is replaces interfaces w/ X-doclet style anotations (which then make it an interface behind the scene, messing up J2SE 5 w/ anotations syntax. And still its not amined at SQL centric, if one is SQL centic, why EJB? Trsnasctions are only for muti-data source).There are so many other remoting frameworks (for talking to SQL centric DAO. )At least support collections..V

    The new entity/persistence model (which is based on POJOs and fully supports collections, inheritance and other historical complaints about entity beans) is covered in the Java Persistence API spec. That spec is produced by the same expert group (JSR 220) that produces the EJB 3 "core" spec. Want a collection of entities? Ask the Java Persistence API EntityManager to return you your favorite Java collections type loaded up with POJOs containing your data. (If this isn't the scenario you were thinking of, please repost.)

    The annotations in JavaSE 5, as leveraged by JavaEE 5, do much more than X-doclet style ones. They are compiled into the class file by javac and thus can be read by the app server at runtime. There is no need for the app server or container to turn the annotations into an interface.
  6. Any adjustments since last time?[ Go to top ]

    Randy,

    I just want collections of maps, etc.
    http://chris-richardson.blog-city.com/ejb_30__still_trying_to_catch_up_to_jdo_and_hibernate.htm
    Nothing to do w/ Persitance/DAO, or Remoting, I don't care how you do it. Other support it, only EJB 3 not. Or just don't ask for developer comments, just say, we the vendors decided to do this. I gave this same input last time EJB 3 was mentioned.

    (Instead of interface tag, now you tag w/ anotations; looks like marketing. It's same thing )

    Cameron, no need for transactions 90% of time, it just makes JEE slow, and then you can sell your expensive map, and you know better. I am not bashing. I am trying to improve it, it's called feedback. Several things I think I inflenced, I don't need a medal. You can't denay that my projects don't have transactions. It's just for noobs, to let them know Java is fine, up to you how to use it, good or bad, and if you want, you can clone a succuessful apps, like vBulletin, etc, or you can clone petstore. Why not duplicate the working aproches and avoid things that are weak. You don't think EJB 3 could be improved Cameron? PHP, Ruby and C# are on thin ice? I think EJB and Spring should have transactions for the 10% of times you need it.
    No one stops at every street corrner, even if the stop sign is facing the other way!
    Yeah, just to be safe.

    .V
  7. Any adjustments since last time?[ Go to top ]

    Randy, I just want collections of maps, etc.http://chris-richardson.blog-city.com/ejb_30__still_trying_to_catch_up_to_jdo_and_hibernate.htmNothing to do w/ Persitance/DAO, or Remoting, I don't care how you do it. Other support it, only EJB 3 not. Or just don't ask for developer comments, just say, we the vendors decided to do this. I gave this same input last time EJB 3 was mentioned.(Instead of interface tag, now you tag w/ anotations; looks like marketing. It's same thing )Cameron, no need for transactions 90% of time, it just makes JEE slow, and then you can sell your expensive map, and you know better. I am not bashing. I am trying to improve it, it's called feedback. Several things I think I inflenced, I don't need a medal. You can't denay that my projects don't have transactions. It's just for noobs, to let them know Java is fine, up to you how to use it, good or bad, and if you want, you can clone a succuessful apps, like vBulletin, etc, or you can clone petstore. Why not duplicate the working aproches and avoid things that are weak. You don't think EJB 3 could be improved Cameron? PHP, Ruby and C# are on thin ice? I think EJB and Spring should have transactions for the 10% of times you need it. No one stops at every street corrner, even if the stop sign is facing the other way! Yeah, just to be safe. .V

    Vic,
    OK, I understand what you meant now. Lists and Maps are now supported too. (Chris' blog alluded to a note in the previous spec that the restriction on these types was hoped to be lifted, and indeed it was lifted.)

    Annotations are different from interfaces, in that if your class implements a particular interface, it won't compile without that interface in the classpath. Not so with annotations. (Or at least, that's the way annotations are intended to work. However, as I understand it, a design misinterpretation occurred with the JavaSE 5 JVM spec that resulted in JVMs giving compile errors rather than just ignoring the annotations as originally intended. This is in the process of being fixed.)

    I (seriously) like your analogy of no one stops at every street corner with a stop sign on the crossing street, just to be safe. The way that most modern containers implement this part of transactional support however, it's more like having an automatic system in your car that detects whether the car on the cross-street has ran its stop sign or not. If the road is clear, you whiz through. If they've run their stop sign, you're prevented from crashing into them. Containers are (in general) heavily optimized to consume no transactional overhead if your app doesn't need them, to consume only single-phase overhead if you only touch one resource, and consume two-phase overhead only if you touch more than one resource. This is all transparent to your app.

    Randy
  8. Any adjustments since last time?[ Go to top ]

    Lists and Maps are now supported too.
    ...
    Annotations are different from interfaces, in that if your class implements a particular interface, it won't compile without that interface in the classpath. Not so with annotations. (Or at least, that's the way annotations are intended to work. However, as I understand it, a design misinterpretation occurred with the JavaSE 5 JVM spec that resulted in JVMs giving compile errors rather than just ignoring the annotations as originally intended. This is in the process of being fixed.)
    ...
    Containers are (in general) heavily optimized to consume no transactional overhead if your app doesn't need them, to consume only single-phase overhead if you only touch one resource, and consume two-phase overhead only if you touch more than one resource. This is all transparent to your app.

    Cool on collections, that was my request!
    OK on anotations, I did not know that at all.
    I personaly will pass on using ANY transactions if you don't mind :-)

    Good news for EJB!

    .V
  9. ...[ Go to top ]

    Cool on collections, that was my request!OK on anotations, I did not know that at all.I personaly will pass on using ANY transactions if you don't mind :-)Good news for EJB!.V

    Yes I looked it up, the spec looks pretty complete to me, page 17 defines the handling of collections, and also LOBs were there.
    The query language also supports joins, looks pretty much like a streamlined Hibernate (Lobs are still a messy issue in Hibernate)

    As for your dislike of transactions. I once had a similar discussion. My answer was, you can skip transactions, you wont get any problem for around a thousand hours if you are lucky, but the all nighter you probably have to face once your db or your dbs are hosed due to something connected on not having used transactions is something I would not wish your worst enemy.

    Not using transactions is like screwing around without condom (pardon the dirty pun), if you are lucky you get away with it, but if not you have a huge problem on your hands.

    I do not know why some people even after 30 years of having to deal with those problems, being tought in basic comp-sci classes, never, ever skip transactions, they are there to keep the data in a clean state, still have a basic dislike for them.

    Believe me, performance is the worst argument against transactions, it is a non argument nowadays, there are other factors which are more important to the performance than transactions.
  10. tranies[ Go to top ]

    performance is the worst argument against transactions, it is a non argument nowadays, there are other factors which are more important to the performance than transactions.

    Preformance is important. Less code is important.

    My basic belif is that transactions belong in a SQL DB layer itself, like store procedures, and not in Java or the services layer. Deal w/ it close to the source.
    This way the DBA can set it up, and even accross mutiple conected dbs (db can conect to another db, even from a diferent vendor).
    There are other langages than Java that then can use it. And a great way to thin down Java.
    I belive in SQL, those people tend to have a lot more experience than regula Java flolk, like 15 years vs 5-6.
    Even after Java is the cool kid, and we use some other cool lang many years from now... SQL!

    So: Autocomit = TRUE!

    OK, I think this horse is very dead!

    .V
  11. tranies[ Go to top ]

    My basic belif is that transactions belong in a SQL DB layer itself, like store procedures, and not in Java or the services layer.

    This is a very narrow view of transactions. I would argue that transaction demarcation can happen at different levels and there is a wider (application level) scope for transactions in most reasonably complex applications.

    While you argue that transactions are purely a database concern, I would go in the opposite direction and say that I wish there were more aspects of the system that could participate in transactions. If I add an item to a collection within a transaction and later that transaction is rolled back it would be great if the collection were returned to it's original state too, perhaps any files I have changed could be rolled back also.

    In practice, this would be quite difficult to accomplish, and even if we could, the next natural step is that somebody will be asking why their network interaction cant be involved in a transaction. Why cant I roll back the bytes I sent down a socket connection?

    The lack of fully transactional components often results in some difficult to maintain code with 'rollback' logic appearing in scattered finally blocks. Sometimes the problem manifests itself in code that performs actions in an unintuitve order, or that performs 'half an action', then attempts something else, then competes the action. All 'code smell' that compensates for a non-transactional resource.

    There is nothing wrong with using SQL level transactions but dont forget that transactions can be nested. Infact EJB allows for this nesting with the 'RequiresNew' attribute. Just because a piece of SQL is transactional doesnt mean that this transaction cannot be a part of a larger 'parent transaction'.

    You are correct that other languages can make use of these SQL transactions but sometimes transactional behaviour is a product of the requirements and if your choosen language does not have JTA style transaction demarcation then you will still need to find a solution to implement the broader scoped transactions (probably the equivilant of the nested finally anti-pattern). To suggest that the database can be solely responsible for transactions is a lot like suggesting the database can be solely responsible for application security.

    Also, to say that transactions should be performed in SQL because SQL has been around longer is a nonsense. My barber has 30 years cutting hair and the tools required to remove my appendix but I would rather this job was performed by a surgeon even if they only has 5 years experience :o).
    OK, I think this horse is very dead!

    Just a small piece of advice if I may. When expressing a view, whether it be on a wwwboard, in a blog, in an email or during a conversation, it is quite arrogant and deeply unprofessional to finish your argument with a comment that effectively says "Stop discussing it now!". On top of this, I usually find that there is no greater sign of an unstable argument than the presence of this kind of comment.
  12. tyrannies? trainees? trains? trans?[ Go to top ]

    Preformance is important.
    But at the cost of what? Is performant enough, enough? Maybe it is. It depends on what you are doing.
     Less code is important.
    Not really. The right amount of code is important. That may mean more. It may mean less.
    ...This way the DBA can set it up...
    It always comes back to this, doesn't it.
     
    Yes, doing it this way has its good points. But it also has its bad points. Integrating at the db level creates all levels of pain (Trying changing ANYTHING when more than one app is using the same database). Sometimes it is the thing to do. Sometimes it isn't. Ignoring the Cons and focusing on the Pros doesn't do anyone any good.

    And again, most ORMers have nothing against SQL. And good ORMs have places DBAs (or anyone who knows what they are doing) can tune or provide SQL.

    The real question is figuring out what are you trying to solve. Then keep an eye to the future. Then figure out how.
  13. Re: tranies[ Go to top ]

    Ya know, I can't say I've ever seen anyone, at least in the past 20 years, argue against transactions. Having worked without them, I simply can't fathom anyone not using them.
    performance is the worst argument against transactions, it is a non argument nowadays, there are other factors which are more important to the performance than transactions.
    Preformance is important. Less code is important.

    My basic belif is that transactions belong in a SQL DB layer itself, like store procedures, and not in Java or the services layer. Deal w/ it close to the source.

    To say this simply:

    That is a fine philisophy, and as long as each code path through your system results in a single DB call to either a singleton update/insert or a call to a stored procedure that does all the work (and which wraps the procedure internally into a transaction), you're golden.

    But if that's not the case, you're simply playing with fire.

    If you have any code that, say, iterates over a collection of detail items, inserting them individually, and you're using AutoCommit == TRUE, you're risking your data integrity AND slowing down your database. That, sir, is a simple basic fact.

    You risking data integrity because at any time while performing all of those distinct SQL's, something can go wrong. Program error, network error, machine failure, etc.

    You cost database performance because all of the work done in a database is done on the commit and checkpoint within the system. If you're commiting every single sql statement, you're doing execessive write on the back end.
    This way the DBA can set it up, and even accross mutiple conected dbs (db can conect to another db, even from a diferent vendor).There are other langages than Java that then can use it. And a great way to thin down Java. I belive in SQL, those people tend to have a lot more experience than regula Java flolk, like 15 years vs 5-6.Even after Java is the cool kid, and we use some other cool lang many years from now... SQL!

    Again, if yours is one of those shops that pushes all of their work in to stored procedures, then hallelujah! Our DBA's can always use more work. But then, if that's the case, the OR tools really don't apply to you, as most don't really deal with stored procedures (and I'm really curious how to save something like an Order and Order Detail Line Items in one fell swoop -- what exactly are you passing to the store procedure?).

    To me CMT is THE BIGGEST benefit of the container. In our 1/2M lines of code I don't think we have a commit in the entire bloody thing (maybe one or two in our importer). It is so nice being able to have 80 gazillion code paths through the system, beans calling utils calling beans everywhich way, updating, inserting, selecting, all of that DB stuff, and confident that if something stupid happens anywhere along the path -- boom, "do over", "what DML?", "nothing happened here, move along". I can't imagine having to deal with transactions in my code anymore.

    Back in the day, we didn't have transactions, and it was simply hell. Data corruption right and left. Then, we got SQL and transactions came for free. Sometimes we had to juggle transaction contexts to make sure one was pending, etc., knowing when to commit or rollback.

    Now I have CMT, and I barely have to even thing about that anymore. It all comes "for free".

    Auto Commit = TRUE is simply madness, on all sorts of levels. I mean, if you're going to play Sisyphus, at least make the boulder round when you push it up the hill.
  14. Re: tranies[ Go to top ]

    Again, if yours is one of those shops that pushes all of their work in to stored procedures, then hallelujah!
    I would rather my DBA, if I have one, would work on more important things. Maybe more boring - but definitely more important.
  15. Re: tranies (sic)[ Go to top ]

    What a great week! Between Rolf, George and Vic, the techno poo spreaders are in full operation! :) Probably the only thing I am getting for Christmas.
  16. Re: tranies (sic)[ Go to top ]

    What a great week! Between Rolf, George and Vic, the techno poo spreaders are in full operation! :) Probably the only thing I am getting for Christmas.
    The sad thing is that people are arguing with them instead of just ignoring them till they go away. To paraphrase Melville: Ah, Tollerud! Ah, humanity!
  17. tranies[ Go to top ]

    So: Autocomit = TRUE!OK, I think this horse is very dead!.V
    Transaction processing applications need to demarcate atomic units of work to run this stuff concurrently and emulate serialization. "autocommit" was invented by ODBC ( JDBC was an ODBC fork ) and uses it by default for single reason (legacy single user application support on RDBMS), it helps to avoid deadlocks for new users too.
    It depends on implementation, but it can be faster to demarcate transactions than to use "autocommit". It provokes more checkpoints if recovery is enabled (many people think "autocommit" is faster, but it is more a tradition than optimization).
     It is possible to ignore transactions in some applications like reports from stale data ( a.k.a OLAP or "decision support systems" ) and you can drop recovery stuff, redo logs and transactions (including "autocommit") for this kind stuff.
  18. ...[ Go to top ]

    Not using transactions is like screwing around without condom (pardon the dirty pun), if you are lucky you get away with it, but if not you have a huge problem on your hands.

    :) That's about the best way I've ever heard it put...
  19. Any adjustments since last time?[ Go to top ]

    I personaly will pass on using ANY transactions if you don't mind :-)

    .. but you said you used database transactions! Do you use them or not?

    Peace,

    Cameron Purdy
    Tangosol Coherence: The Java Data Grid
  20. Any adjustments since last time?[ Go to top ]

    Cameron, no need for transactions 90% of time, it just makes JEE slow, and then you can sell your expensive map, and you know better. I am not bashing. I am trying to improve it, it's called feedback. Several things I think I inflenced, I don't need a medal. You can't denay that my projects don't have transactions. It's just for noobs, to let them know Java is fine, up to you how to use it, good or bad, and if you want, you can clone a succuessful apps, like vBulletin, etc, or you can clone petstore. Why not duplicate the working aproches and avoid things that are weak. You don't think EJB 3 could be improved Cameron? PHP, Ruby and C# are on thin ice? I think EJB and Spring should have transactions for the 10% of times you need it. No one stops at every street corrner, even if the stop sign is facing the other way! Yeah, just to be safe. .V

    Transactions have benefits over performance too rather than regular SQL such that you may operate over multiple business objects and later commit everything as one transaction. EJB3/Hibernate are very efficient at monitoring your persistent objects in (fast) memory for later persisting once the transaction is complete. None of this 'save everything' or 'save what I've think has changed' crap.
  21. Any adjustments since last time?[ Go to top ]

    Transactions have benefits over performance too rather than regular SQL such that you may operate over multiple business objects and later commit everything as one transaction. EJB3/Hibernate are very efficient at monitoring your persistent objects in (fast) memory for later persisting once the transaction is complete. None of this 'save everything' or 'save what I've think has changed' crap.

    :-) Are you assuming your load is handled by a single application server(so that this object is all knowing)?
    1up started w/ 6 application servers(one of my sites, and one w/ less transaction hits. the other one has 40,000 studends taking a test at the same time, that's a lot of transactions and 10 server). People would benefit w/ visitng w/ DBA on what size transactions perform best and if it's better to "hold it" as your theory.
    One of the best progamers out there is Scott Feruguson, VP Tech Cuacho Resin and in one his newsgroup posts he said words to the effect: "share nothing clustering seems to be the most effective".

    My sites work, and I am OK w/ you guys using transactions in JEE world. It's SQL centric vs "ORM" centric aproach. In my projects I found that DB operations work better in the DB (optimized over 2 decades before Java existed in native code). Really, some of you should know more than one lang. Try C#, or Ruby, or something. I will try EJB's one large scale again AFTER EJB 3 application servers ship, maybe after JEE5 w/ portlets ship, but not before. I will do so using SQL in EJB and not using transactions.
    Ever heard the phrase IBM (It's Better Manual).

    The words that scare me is "transparently highly optimized". That is not a CS term, that is marketing. In the past "EJB" and term enterprise meant "deparmental" as per Grant who is an "architect" and commented in this thread and in here:
    http://www.jdocentral.com/JDO_SuccessStory_20050304.html
    where he found avoiding EJB:

    " increased application performance* and allowed us to turn new features around in a little over half the time it would have using EJB "

    (Presumably non-sql, trasnaction loaded EJB)

    So, consider alternative aproaches (popular w/ other tech stacks) and stress test to validate. Than watch what happens in production. When people say Ruby, PHP or C# is better than "Java" ... why not use Java as you would use Ruby, PHP or C#, nothing stoping you. Look at SQL based vBulletin used here:
    http://forums.fedoraforum.org
    Why Friendster left JEE for PHP?! The goal is not to write the entire stack in Java, but to use what works best at each layer. SQL! Like my current site, pointcast.com, at least when you come to it, there is no RMI excpetions. It's very SQL centric.

    KISS has allways been faster. Computers can be fast... or complex, but not both. How much consulting for free?


    .V
  22. Any adjustments since last time?[ Go to top ]

    The words that scare me is "transparently highly optimized". That is not a CS term, that is marketing. In the past "EJB" and term enterprise meant "deparmental" as per Grant who is an "architect" and commented in this thread and in here:

    http://www.jdocentral.com/JDO_SuccessStory_20050304.html

    where he found avoiding EJB: " increased application performance* and allowed us to turn new features around in a little over half the time it would have using EJB "

    You are arguing against yourself here, as this success story was achieved by using an ORM system (JDO) that does transparently produce highly optimised SQL, and which uses transactions for just about everything.
    KISS has allways been faster. Computers can be fast... or complex, but not both. How much consulting for free?

    KISS does not always mean working at the lowest level. I take KISS to mean using less code and letting well-written libraries and API implementations do my work for me. That is why I use JDO (and will probably use EJB 3.0).
  23. Any adjustments since last time?[ Go to top ]

    Why Friendster left JEE for PHP?! The goal is not to write the entire stack in Java, but to use what works best at each layer. SQL! Like my current site, pointcast.com, at least when you come to it, there is no RMI excpetions. It's very SQL centric.

    OK Vic, but how do you implement data caching using plain SQL data set oriented approach? If you have simple app (say under 50 entities, less interconnected with relationships) that is relatively simple and can be efficient. But when you move to more complex stuff with a lot of relationships, implementing data caching on recordset oriented approach can be real pain:
    - cache explosion due to complex relationships and data duplication in many recordsets,
    - cache inconsistency due to the same reasons,
    - complex and error prone cache invalidation code,
    - not enough problems?

    With OR mapping approach implementing data caching in complex apps is peace of cake (either you roll your own stuff or use third party product).

    And some domains of interest are inherently complex, you can't model everything with KISS (although you can quite a lot).
  24. Any adjustments since last time?[ Go to top ]

    ... but how do you implement data caching using plain SQL data set oriented approach? If you have simple app (say under 50 entities, less interconnected with relationships) that is relatively simple and can be efficient. But when you move to more complex stuff with a lot of relationships, implementing data caching on recordset oriented approach can be real pain:- cache explosion due to complex relationships and data duplication in many recordsets,- cache inconsistency due to the same reasons,- complex and error prone cache invalidation code,- not enough problems?With OR mapping approach implementing data caching in complex apps is peace of cake (either you roll your own stuff or use third party product).And some domains of interest are inherently complex, you can't model everything with KISS (although you can quite a lot).

    Mielta, Using tranies for caching is not a good idea. Any DAO has caching ( and no, you don't have to use tranies in DAO to get caching).
    For example, I have used iBatis SQL mapping, with great cache of the Apche iBatis. (Even some Hibrenate people's reason to switch to iBatis is becuase it had a great easy to understand cache, vs some of the Hibrenate's confusing way it handled complex cache).
    You should be able to *lean on your DB* depending on what transactions rating you need, I look up TPC.org, and go w/ it. Ex: http://tpc.org/tpcc/results/tpcc_price_perf_results.asp?resulttype=noncluster
    shows that getting 60,000 transactions per minute on DB is quite effective, or I could get orders of magnitude more.
    All the DAO cache has to do is give you a bit of breathing room, sort of like oil for your clutch.
    So lets say I have 3 servers, and I set up a cache of 30 seconds on most querries (and tune some). This means that any popualr content (from db) the more popular the more likely it will be a cache hit from the internet so it never gets to the DB. And if the content gets updated by any of the server, most of the time 30 seconds is considered real time. (plus any querries that need real time are freed up to be real time). If any of the 3 server update content, it's synced within 30 seconds from the db as the cache has decayed. In other cases, you invalidate all the caches on update. It realy is that simple.

    As for modeling complex domains, I assume you meant E/R. It takes a lot of thinking, patience, exeprience to simplify a complex busines requirment to a elegant data model. One tool is to make prototypes of the UI, to get a deper upderstanding of joins for example. While I can teach many things... I find it hard to teach the art of data modeling.

    Some of these "transparently heavily optimized" solutions work in small lab conditions. In general, the more complex the business problems are, the more it benefits from an elegant design.

    Good luck to all you other tranies, I am not saying it's wrong, it should be allowed, especialy back end tranies.

    .V
  25. Any adjustments since last time?[ Go to top ]

    Some of these "transparently heavily optimized" solutions work in small lab conditions.

    They also work in large business conditions - as in the example you posted!

    http://www.jdocentral.com/JDO_SuccessStory_20050304.html
  26. querries vs orm[ Go to top ]

    One more thing Mileta that may calrify ideas,
    If you do go to sql centric DAO, you cache the querry, not the "objects" as in ORM.

    You let the DB do the rows. In SQL centric DAO, you do not invalidate a row, but the qerry (you called it SQL DataSource I think). See if you are SQL centric, you know that SQL is a set oriented langauge, and to avoid cursors (row processing). Set theory, Ven diagrams, etc.
    So you invlidate a set of records in cache, the set from the querry. (since you gave all the records a 10% upgrade or something)

    This is what we learn from other more scaleable tech stacks, SQL good, much math in relational algebra. ORM is just OMG oversold.


    .V
  27. querries vs orm[ Go to top ]

    One more thing Mileta that may calrify ideas,If you do go to sql centric DAO, you cache the querry, not the "objects" as in ORM.You let the DB do the rows. In SQL centric DAO, you do not invalidate a row, but the qerry (you called it SQL DataSource I think).

    Yes, but how do you detect that your cached query record set is stale? You need to code it, and this is error prone and not KISS for sure. And you limit your cache hit rate a lot with this approach. And data caching is the most critical part of every web app (not the page rendering!). OR is KISS and fast when done right, SQL is complex, slow and error prone, for the most medium-to-large scale apps.
  28. querries vs orm[ Go to top ]

    how do you detect that your cached query record set is stale?
    1. You need to code it, and this is error prone and not KISS for sure.
    2.And you limit your cache hit rate a lot with this approach.
    3. And data caching is the most critical part of every web app (not the page rendering!).
    4. OR is KISS and fast when done right, SQL is complex, slow and error prone, for the most medium-to-large scale apps.

    Like I said, I used to think that, and tried ORM long time ago EJB, and then I went to the alternative aproach. Everyone should at least know the alternative aproach. Some things look great when you draw them up in magic marker.
    1. There is 0 code. When you declare your SQL select, you tell it a 30 second time out for the "SQL dataset". 0 code. In rare case when you need to flush on update, even that is something you set in XML, one line :-)
    But if you have something more complex, you may want to issue a cache invlidate in your DAO layer.
    2. I don't think so.
    3. Most critical part of any app is requirments of course. If team is technology chanllanged, they can't focus on requriments. Caching helps, if SQL centric. It creates problems, if ORM. Or you want to say perofmrance is important, then stored procedures are an element.
    4. In my experience ORM work in simpler smaller lab conditions, like deprmental scale anecodtal evidence. ( and I know anecodtal evidence of a $400Million development that switch form ORM to SQL centric becuase the experts recomends to)
    SQL centric work great on larger more complex scale on ANY tech stack. Here is another site talking about ORM Cache vs SQL "DataSet" cache:
    http://www.mail-archive.com/user-java at ibatis dot apache dot org/msg02090.html
    For this, I hope EJB 3 vendors do not use Hibrenate cacheing aproach. (Gavin, your post was unusaly uninformative).

    It is my presonal belif that if technology is not well understood, one can only do smaler scale apps. With a more elegant aproach, one can handle larger scale. Or an oversimilfication:
    Complex tech = small apps.
    Simple tech = large apps.

    It's a mistake to confuse complexity w/ sophistication. It's a lot harder to simiplify.

    .V
  29. querries vs orm[ Go to top ]

    I also like the query approach. ORM just seems wrong to me. iBatis supports this approach and I believe that spring does to (although personally I'm not sure what spring does for me and why I would want it, but that is another discussion). I have a brief discussion about this as well as some code (too simple to call it a framework or something silly like that) here
  30. querries vs orm[ Go to top ]

    ORM caches queries (Hibernate doe's it), but I think it is better to cache queries using materialized views and let database to maintan cache. If mview is too slow then probably it makes more sence to cache generated HTML.
  31. cache[ Go to top ]

    probably it makes more sence to cache generated HTML.

    Data caching should happen in a data layer, you should have full confidence in your data layer and not propogate any problems to the view layer (should you need to rewrite the view :-) to be more rich for example.
    So IMO caching of generated HTML is usualy a bad practice.

    .V
  32. cache[ Go to top ]

    probably it makes more sence to cache generated HTML.
    Data caching should happen in a data layer, you should have full confidence in your data layer and not propogate any problems to the view layer (should you need to rewrite the view :-) to be more rich for example.So IMO caching of generated HTML is usualy a bad practice. .V
    I do not know it is good or bad practice, but if it should happen in a data layer then this layer is RDBMS (I found it is a very good distributed cache). HTML cache is just a hack for maximum performance, performance is a good practice, is not it :).
    BTW if you have time to to think about this kind of cache then I am sure you will find a way to make in maintainable.
  33. cache 22[ Go to top ]

    HTML cache is just a hack for maximum performance, performance is a good practice, is not it :).
    lol. Thanks for brightening my day.

    I guess one man's performance is another man's bad practice.
    Preformance is important. Less code is important.
    Believe me, performance is the worst argument against transactions,
  34. cache[ Go to top ]

    .. if it should happen in a data layer then this layer is RDBMS (I found it is a very good distributed cache).

    Yeah, they're just like a distributed cache, except for the "distributed" part and the "cache" part. ;-)

    "When the only tool you know is a $300 hammer, ...."

    Peace,

    Cameron Purdy
    Tangosol Coherence: The Java Data Grid
  35. cache[ Go to top ]

    they're just like a distributed cache, except for the "distributed" part and the "cache" part.

    +1. DB itself is not to be used for aching.

    Most DAO's have a good working cache. Some DAO caches are buggy and need a 3rd party upgrade.

    .V
  36. cache[ Go to top ]

    Is there a reason to move this functionality to application code ? I faund DB cache is very important for performace and database maintains it without any additional applicaion code (a.k.a KISS). Application level cache is fast on single server, but it is hard to believe custom replication hack can be faster than mature RBDMS solutions on cluster.
  37. cache[ Go to top ]

    Jo, good questions.
    1st, if your DB is fast enough for your current use level and your current DAO has a poor cache, then ... don't cache. (but don't cache data in the view either then). Yes, DB should have a lot of memory also, and that is one way to make it faster, and yes, most SQL engines do very good caching of results there.

    2nd. DAO's likely require minial or no code to set up cache. Caching in a DAO is very effective (and it's not realy replication, yes it's duplicate of data). 1st of all it's in memory and then there is no network latency. Expereince shows the old 20/80 rule, is that often enough people need same rowsets. (the more often it's used, the more likely a cache hit). A littlet bit of cache goes a long way (since you know that you have a powerfull db server, you just sort of greese it). What it then does it frees up a lot of the load of the SQL server so that its free to work on the "rare" querries, etc. If your load requires mutitple application servers then you realy need to start ofloading a bit of the SQL server.... so DB more free to do Inserts, updates, page splits, stored procs, back ups, bulk inserts, non-java CRUD, etc.
    Plus if you need to unit test DAO layer, you do it there (not using view) and know where to tune it.

    hth,
    .V
  38. cache[ Go to top ]

    I have used DAO level cache in a few applications ( dynamic proxy to wrapp methods and to cache result using method and parameters as key). But I prefer DB to maintain my cache (materialized or indexed view is a DB level query cache and it can be distributed too), if I need more performance then I cache HTML, I found it is as messy as DAO level cache. It is error prone in both cases, but content cache must be bit faster.
  39. cache[ Go to top ]

    BTW probably DAO level cache is better fo automated tests, content cache is very hard to test.
  40. cache[ Go to top ]

    I found it is as messy as DAO level cache. It is error prone

    Depending on the effort, you may want to update your DAO implementation, I can vouch using Apache iBatis in production serveral times w/ over concurent 10K users that it's very predictable (non of object.equals mess, etc) and we got like 90% hit ratio. It would give you architectural benefits for sure.

    Imagein you do something like:
    < findEmployees cache X = 30 sceconds, flush on updates, return map>
    Select ..... where X = ..
    />

    ArrrayList lst= dao.findEmployes(X,Y,Z); // of maps

    and then you go an use a displaytag.sf.net jsp tag that takes a list as an arugment :-)

    The people that do nice UI sometimes are not same people that are SQL experts and you can unit test each layer separate! (in view unit test I make a fake ArrayList of Map of collumns).

    The other alteriantive (not as good but less effort) is to use a 3rd party cache and put that in your DAO layer. Many 3rd party cache jars. Put the code that you have in your "HTML" layer (lets call it view layer so you can go RiA one day, client side), similar code caching html for you now, just move it under the DAO api. (or ... wirte your own softmap or weakmap if you can handle ref)

    Or!!! Just let it be.
    Becuase requirments are most important, and you demonstrated that you can implement and go to production. Worst people are the ones that get the "framework tech stack" right... but can't deliver to production (presumably they did not spend enought time on bus. requirments).

    over and out,
    .V

    ps: did you see how I do not have to maintain mutiple beans get/sets by using map instead of bean? If sql adds or removes a field in future versions, there is no cruft. If View ads or removes a field
  41. cache[ Go to top ]

    I see. Maps can help for so called "adaptive design". I know iBatis and I think it is very good way for data access (I have used and developed this ind of frameworks myself a few years ago) ORM support dynamic data structures too (some implementations support DOM as model too), but I do not use this feature at this time. We generate most of data access code from UML models and I fond static data structures a.k.a beans are better in this process.
    I think cache is just an optimization and application or system must be tested and tuned without it first(probably it is possible to find better optimizations too). I test applications without database connection pool first too.
  42. cache[ Go to top ]

    BTW Page cache is not so complex as it sounds and can be configured without any chages in UI http://resin.mediahost.org/java_tut/cache.xtp (deployment time optimization), but there are many alternative ways too.
    Materialized view can be "transparent" too (as transparent as index, no cahnges in application code) using query rewrite features.
  43. cache[ Go to top ]

    Materialized view can be "transparent" too (as transparent as index, no cahnges in application code)

    Sorry, no. We discussed this earlier in the year in great detail, and this was shown to be false. Materialized views are almost never transparent:

    http://www.theserverside.com/news/thread.tss?thread_id=35202

    I said:
    The problem is that materialized views aren't always transparent. As I pointed out earlier, for some databases (versions of SQL Server, for example) you need to include specialised code and there are restrictions on what you can do, so the use of this technique breaks your requirement for transparency.
  44. cache[ Go to top ]

    And
    I used to think that, and tried ORM long time ago EJB,

    Yeah, the last time I used a wheel, they were square. So I stopped using them too.
  45. cache[ Go to top ]

    .. if it should happen in a data layer then this layer is RDBMS (I found it is a very good distributed cache).
    Yeah, they're just like a distributed cache, except for the "distributed" part and the "cache" part. ;-)"When the only tool you know is a $300 hammer, ...."Peace,Cameron PurdyTangosol Coherence: The Java Data Grid
    Yes, you have a reason to believe cache API, but I think it is the worst way to optimize application and your joke sounds more like ignorance.
  46. cache[ Go to top ]

    .. if it should happen in a data layer then this layer is RDBMS (I found it is a very good distributed cache).

    Yeah, they're just like a distributed cache, except for the "distributed" part and the "cache" part. ;-)

    "When the only tool you know is a $300 hammer, ...."

    you have a reason to believe cache API, but I think it is the worst way to optimize application ..

    I just find it odd that you call a database a "distributed cache", when it is the primary bottleneck in most large-scale applications, and the primary reason why people are forced to cache in the first place.

    Peace,

    Cameron Purdy
    Tangosol Coherence: The Java Data Grid
  47. cache[ Go to top ]

    Probably application is a primary bottleneck. Do you know a bottleneck and "timeout waiting for idle object" cause in www.theserverside.com ? I see cache doe's not help to solve scalability problems, some discussion forum implementations scale without cache, see hibernate forum for example, it has more features and it looks like there are more posts per day.
  48. cache[ Go to top ]

    Probably application is a primary bottleneck. Do you know a bottleneck and "timeout waiting for idle object" cause in www.theserverside.com ?

    Yes, great example! It's waiting for the database.

    Peace,

    Cameron Purdy
    Tangosol Coherence: The Java Data Grid
  49. cache[ Go to top ]

    So cache doe's not help to fight with database. Probably it makes sence to test application without cache first, it helps to find the real bottleneck and to fix application (create indexes,clusters,mvievs, partitions). Cache can help to scale better after database is tuned and all queries are fixed, but it can not help to hide performance problems. I am sure it is possible, PHP forums scale very well and the same databases are availble for JAVA too.
  50. cache[ Go to top ]

    So cache doe's not help to fight with database. Probably it makes sence to test application without cache first, it helps to find the real bottleneck and to fix application (create indexes,clusters,mvievs, partitions).

    Sorry, but I just don't see the point in bothering with all this highly technical detail if a cache can avoid it.

    This reminds me of some debates I have had with some C++ developers. They insist that huge amounts of tuning is necessary for performance, including fiddling with memory allocation and stack. When I point out that a lot of this is simply redundant as Java can give close to equivalent performance without all this tuning work, I am met with disbelief, as they insist that Java can't be as fast as C++ code, even when evidence shows that they are wrong.

    If, like those C++ people, you like tuning things in detail, of course that is fine, but if there are ways to avoid this highly time-consuming and proprietary solution to performance, why bother?
    Cache can help to scale better after database is tuned and all queries are fixed, but it can not help to hide performance problems.

    Of course they can - they can hide performance problems with databases.
    I am sure it is possible, PHP forums scale very well and the same databases are availble for JAVA too.

    I am afraid we are going over old ground here. All this has been debated before in threads on TSS. For example, if you look back at the topic

    "JBoss releases Nukes on JBoss 1.0"
    in March 2005...

    Jason McKerr of the Open Source Lab posted:
    There *have* been a great number of well-known problems with PHP nukes including security (especially this) and performance. We looked at hosts of tools for pushing simple content out to the web for the Open Source projects we host and develop. Our systems guys told me in no uncertain terms that PHP Nukes was out of the question because of those issues. I've been eagerly awaiting JBoss nukes to solve ths problem for us as many of the other solutions were a lot more than I needed.

    So, saying "PHP forums scale very well" would seem to be factually wrong as a general statement. It may be true for some cases, but Java provides a more general solution.
  51. cache[ Go to top ]

    I am talking about applications like http://www.phpbb.com, there are many good JAVA,PHP and C++ applications, but tool can not help if you believe it can hide a problems. It must be better to fix problems. Modern databases are very performant, cache and distribution are very important database features. I think it is not a good idea to fight with database, it must be better to use datbase as it documented and recommended by database provider.
  52. cache[ Go to top ]

    I am talking about applications like http://www.phpbb.com, there are many good JAVA,PHP and C++ applications, but tool can not help if you believe it can hide a problems. It must be better to fix problems. Modern databases are very performant, cache and distribution are very important database features. I think it is not a good idea to fight with database, it must be better to use datbase as it documented and recommended by database provider.

    You have things the wrong way around. Using a cache prevents you having to 'fight with the database'.

    I have to ask the following: Are all the banks, major websites and corporations who use caching above the database mistaken? Are they wasting their time, when all they need to do is to see what a particular PHP forum package can run on and use that database?

    I would like to be a fly on the wall when someone goes into an IT meeting at, say, E-Bay and says 'phpbb runs without a cache and can even use MySQL, so you are doing things wrong'.

    That would be silly. It would be silly because even the example you have given - phpbb has performance problems due to database accessing! In fact there are patches to phpbb designed to improve performance:

    http://www.gentoo.org/news/en/gwn/20040920-newsletter.xml

    "...applied some patches to the phpBB sources that reduce the hits on the database server by caching and prestoring those tables almost every page relies on..."

    "..The search for more opportunities to tweak performance is still on..."

    Sorry, but I think that your case is rather demolished when you provide an example about how direct database access is fast and that example requires caches for high performance.
  53. cache[ Go to top ]

    Yes, your interpretation is very silly. phpbb is very performant and scalable application, I am happy to use it. Authors want to make it better, probably cache will help too. Cache is just one of optimization options, but it can not solve all of performance problems, it makes sence to tune database and to use optimizations recommended by database vendors too.
  54. cache[ Go to top ]

    Yes, your interpretation is very silly.

    It was not my interpretation - it was yours:
    I am sure it is possible, PHP forums scale very well and the same databases are availble for JAVA too.
    "Use PHP forum databases for Java and your application will scale."
    phpbb is very performant and scalable application, I am happy to use it.

    Evidently it is not so performant and scalable. Perhaps you should read the link.
    Authors want to make it better, probably cache will help too.

    You seem to be twisting facts here. It was not a case of making it better - it was a case of making of dealing with a significant performance problem. From the link:

    "However, many users were still experiencing sluggish behaviour. Now the Forum administrators have looked a little closer into this and started to analyse the problem."
    Cache is just one of optimization options, but it can not solve all of performance problems, it makes sence to tune database and to use optimizations recommended by database vendors too.

    Sure, but go for the more portable and simpler option first. No point in fiddling with intricate details of the database if a cache is good enough. After all, that would take time, and time is money.
  55. cache[ Go to top ]

    There are many things to learn from PHP applications. Try it yourself, it is a good example to learn about lage scale forum implementations. It must be better than this search to prove me wrong (I do not believe I am right in all cases myself).
  56. cache[ Go to top ]

    There are many things to learn from PHP applications.

    I know - I have used PHP myself.
    Try it yourself, it is a good example to learn about lage scale forum implementations.It must be better than this search to prove me wrong (I do not believe I am right in all cases myself).

    I have seen all sorts of reports of problems with PHP. Apart from performance problems, there have also been security issues (things such as code injection), and I have personally spent far too long fiddling with compiling different PHP versions and Apache modules and supposedly portable SQL scripts for various applications (oh alright I'll name it - Horde!) to have much respect for this way of working. I have managed to get the Java/J2EE equivalents up and working in a fraction of the time.

    I am sorry if I seemed rather harsh, but I have an automatic negative reaction when anyone implies that scalability is easy because PHP manages it. Scalability means a lot of things, and PHP bulletin boards and forums is just one very narrow aspect of it. All you learn about is how to scale PHP forums!

    I don't think you and I will ever agree on these matters, but I find it educational and interesting to debate (even if it makes me re-visit old threads).... so thanks anyway.
  57. cache[ Go to top ]

    Yes, scalability is not easy in PHP too, I discuss about alternative ways to learn about it, not to sell my products.
  58. cache[ Go to top ]

    Yes, scalability is not easy in PHP too, I discuss about alternative ways to learn about it, not to sell my products.

    Well, I have no products to sell :)
  59. cached out[ Go to top ]

    Yes, scalability is not easy in PHP too, I discuss about alternative ways to learn about it, not to sell my products.

    All talk? What happens when you discover a good solution? Give it away? Sell the idea? Go to work for someone who already has figured it out (I've only been to Massachusetts once but I liked it)? No matter what you choose to do, does that invalidate your stance?
  60. cached out[ Go to top ]

    Yes, scalability is not easy in PHP too, I discuss about alternative ways to learn about it, not to sell my products.
    All talk? What happens when you discover a good solution? Give it away? Sell the idea? Go to work for someone who already has figured it out (I've only been to Massachusetts once but I liked it)? No matter what you choose to do, does that invalidate your stance?

    I think there is an ongoing thing here that anyone who is trying to break us away from having the relational database as the centre of everything (no matter how clumsy and vendor-specific such solutions may have to be) must be simply trying to sell us some theoretically inadequate corner-cutting waste of time, even though the vast experience of major corporations and websites suggests otherwise.

    Of course, database vendors would not lower themselves to the level of salesmen and marketers, would they? (Not that I think there is anything wrong with that).
  61. cached out[ Go to top ]

    "centre of everything" sounds too extreme (probably end user is centre of everything), but it solves many problems like concurrency control, recovery, cache, query optimizations, security. But I think it makes sence to cache on web server too (page cache or cached includes) if stale data can be tolerated, probably distributed cache on business level can help too, but I do not see strong arguments to use it, it looks more like a problem than the solution.
  62. cached out[ Go to top ]

    "centre of everything" sounds too extreme (probably end user is centre of everything), but it solves many problems like concurrency control, recovery, cache, query optimizations, security. But I think it makes sence to cache on web server too (page cache or cached includes) if stale data can be tolerated, probably distributed cache on business level can help too, but I do not see strong arguments to use it, it looks more like a problem than the solution.

    But it is only one way to solve such problems, and the solutions you come up with are almost always vendor-specific. Many of us think that that is a bad thing.

    However, I will probably stop here, as this could go on for some time and not progress :)
  63. cached out[ Go to top ]

    I see :)
  64. querries vs orm[ Go to top ]

    ORM caches queries (Hibernate doe's it), but I think it is better to cache queries using materialized views and let database to maintan cache.

    The potential problem with this (as we have discussed in detail before) is that database caches mechanisms like this can be extremely vendor-specific in terms of the SQL statements you have to use and the restrictions on what you can do.
  65. querries vs orm[ Go to top ]

    Yes, RDBMS implementations are not equal and there are many things to evaluate before to choose the right product. RDBMS optimization options are available for ORM too. This is oracle documentation
    http://www.oracle.com/technology/oramag/oracle/03-sep/o53business.html, but MS SQL and DB2 have similar concepts too. MySQL does it this way http://dev.mysql.com/doc/refman/5.0/en/query-cache.html
    If you are using a good ORM product then it must help to solve your portability problems.
  66. querries vs orm[ Go to top ]

    Yes, RDBMS implementations are not equal and there are many things to evaluate before to choose the right product. RDBMS optimization options are available for ORM too.

    I think there should be a principle of good software development: "Always optimise the most portable level first". If you optimise your JDO or EJB 3.0 code and you have transparent java-based cacheing (which will usually integrate transparently with your ORM), then this has the great advantage of most likely being optimised for any store. You should only work at the level of vendor-specific code if absolutely necessary (in my opinion).
  67. querries vs orm[ Go to top ]

    Yes, if ORM level cache is well integrated then it is a usefull optimization option too. I am not sure about all ORM implementations, but you can use dedicated mapping file for named queries in Hibernate to configure cache or to add query hints.
     It must be possible to drop optimization at deployment time, it depends on many aspects and I think it can not based on any dogma or best practice.
  68. querries vs orm[ Go to top ]

    It must be possible to drop optimization at deployment time, it depends on many aspects and I think it can not based on any dogma or best practice.

    Why on Earth would you want to do that? Optimisation at the ORM level (such as tailoring the fetch groups in JDO) complements (and is transparent to) other forms of cacheing, and deployment time is obviously when it is most useful. Saying this is rather like suggesting turning off the JIT when deploying Java apps!
  69. querries vs orm[ Go to top ]

    Memory limitatios is one of reasons and memory management can lag more than I/O too, if database size is constant then probaly it is possible to tune it and to cache everything on client side. Somethimes it makes sence to drop mview or index too, probably the same is about most optimizations(it can better to bypass the memory page cache on file system for example too).
  70. querries vs orm[ Go to top ]

    Memory limitatios is one of reasons and memory management can lag more than I/O too, if database size is constant then probaly it is possible to tune it and to cache everything on client side. Somethimes it makes sence to drop mview or index too, probably the same is about most optimizations(it can better to bypass the memory page cache on file system for example too).

    The sort of optimisations I was thinking about reduce memory use and improve performance because by default your ORM only loads commonly needed fields rather than entire objects. (This can improve both performance and memory in many cases if done right). So, you will probably want to include these optimisations no matter what you are doing with the database. Another thing is that I would classify most ORM use as 'server side' not 'client side' - from my point of view the client is the browser! But I guess you are considering it a 'client' of the database, which is a reasonable way of looking at things.
  71. Any adjustments since last time?[ Go to top ]

    KISS has allways been faster
    Having developed plenty of "KISS" apps (in Java and VB and C# and VB.Net and COBOL and PowerBuilder and ...) and have seen plenty done, according to your definition of KISS, they are not so simple.

    Not simple to maintain.
    Not simple to modify.
    Not simple to figure what was being done where.
    Not simple to make effiecient.

    Whether large or small. Did these apps work? Sure they did. But that is only part of the picture.

    As for
    When people say Ruby, PHP or C# is better than "Java"
    That is like saying mopeds are better than cars because you don't need a license.
  72. "Trsnasctions are only for muti-data source"?

    So, you're saying that if I am talking to only one database that I don't need to use transactions?
  73. 90 % of time... you should not use it[ Go to top ]

    Exactly. If you are conection to a single SQL DB, you should only use the SQL transactions.

    It's much faster for one, and simpler.
    Good morning.

    .V
  74. No way![ Go to top ]

    You may be developing a piece of code that uses a single DB, but this piece of code can be called within another transaction. The problem is old, and has been solved by CMTs, wich are simple to use by NOT writing any code at all.

    J2EE containers are a GOOD thing, why do people keep complaining about it? Do they miss the VB crap?
  75. 90 % of time... you should not use it[ Go to top ]

    CMT helps you demarcate boundaries (declaratively) inside your code, so you can group things together to happen as one transaction regardless if you're going to one or many databases.

    I rarely rely on SQL transactions to that end for enterprise applications.

    -Lou
  76. 90 % of time... you should not use it[ Go to top ]

    I rarely rely on SQL transactions to that end for enterprise applications.-Lou

    What about PHP, Ruby... and C# people, those groups are more effective. Ex, If you get MS C# certified developer (test 70-316) one study requirment is " to avoid distributed transactions ". So all the Computer Science breaks down when using JEE? One group is wrong here.

    Nothing in JEE prevents me from *not* using Transcations w/ EJB or w/ iBatis or Groovy. Not everyone works in banks and MQ series. What about content managment web apps where you do selects and single row inserts.Every project I deployed (BringerFuding, Vantage Learning, Ziff Davis, there's got to be more ) never used a single transaction. Transactions are not a technology flow of JEE, becuase you don't have to use it. If you have the urge to use it, fine by me.

    However, not being able to use collections w/ EJB is a technology issue.


    .V
  77. just to be "standard?"[ Go to top ]

    i admit i've not looked at EJB3 too closely yet, but i'll put the question out there for people, why should i bother with EJB3 if i'm already quite satisfied with my current OR mapping framework (Hibernate 3), which is also a de facto standard (albeit without Sun's imprimatur)? from what i've seen, and i readily admit i could be wrong about this, EJB3 doesn't really offer anything over Hibernate. standardized annotations maybe? and looks to be less functional than Hibernate. is what Vic said true, that i can't map collections of entities with EJB3? jeez, if so i must say, what a pile of sh_t. is that design by committee?
  78. just to be "standard?"[ Go to top ]

    Vic is incorrect. EJB3 will support collections. He also is incorrect about the underpinnings of annotations as it relates to the Java Persistence Spec vs. standard Java annotations. In my opinion, he is also totally wrong in his comments about transactions. The number of databases your application connnects to has very little to do with it's requirement for transactions to say the least. Many applications are vastly complex, require transational functionality and only connect to 1 database. His comment:
    If you get MS C# certified developer (test 70-316) one study requirment is " to avoid distributed transactions ". So all the Computer Science breaks down when using JEE? One group is wrong here.
    about C# certification doesn't contradict anything about Computer Science as he claims. It sounds to me that Vic is confusing an Enterprise Application with an Application that is used in the Enterprise.

    As for Hibernate, it's a great project. I come from the JDO side of the fence and have used Hibernate too. Many of the minds behind both of these technologies are behind EJB3...
  79. just to be "standard?"[ Go to top ]

    Many applications are vastly complex, require transational functionality and only connect to 1 database.

    Grant, your apps sound like a candiate for Ruby, C# or PHP. There are many people that liken complexity to sophistication, a goal on it's own. I agree that there are specail cases for transaction. Again, last several apps I wrote and put in production had 0 trasnactions code or mark up. Can you not see that there are 2 sides to this coin.

    If you want to jump of, jump.


    KISS,

    .V

    is this a thread about EJB?
  80. Besides that[ Go to top ]

    I would hardly call a C# certification computer science...
    ;-)
  81. just to be "standard?"[ Go to top ]

    If I am not misunderstanding, you should compare Hibernate to JPA (persistence spec) and not EJB3.

    See this previous article :
    http://www.theserverside.com/news/thread.tss?thread_id=33450
  82. just to be "standard?"[ Go to top ]

    i admit i've not looked at EJB3 too closely yet, but i'll put the question out there for people, why should i bother with EJB3 if i'm already quite satisfied with my current OR mapping framework (Hibernate 3), which is also a de facto standard (albeit without Sun's imprimatur)? from what i've seen, and i readily admit i could be wrong about this, EJB3 doesn't really offer anything over Hibernate. standardized annotations maybe? and looks to be less functional than Hibernate. is what Vic said true, that i can't map collections of entities with EJB3? jeez, if so i must say, what a pile of sh_t. is that design by committee?

    In JBoss's EJB 3.0 (Java Persistence) implementation sits directly on top of Hibernate and is actually a subproject of www.hibernate.org. If you are using Hibernate, then continue to use it. The EJB 3.0 persistence annotations are usable within Hibernate.

    EJB 3.0 also has nice integration between session and message driven beans and EntityManagers (the Hibernate Session). You know all the session management you have to do with Hibernate? Well, this integration handles all this session management for you. Also, with the JBoss EJB 3.0 implementation, you can inject Hibernate Sessions directly and get the same kind of behavior.

    The O/R mapping is actually pretty rich and the original poster is incorrect.

    Bill
  83. ejb3[ Go to top ]

    OK, I looked at the first tutorial at http://docs.jboss.com/seam/reference/en/html/tutorial.html. So I've got a User pojo with annotations instead of a Hibernate mapping file (mind you, I haven't paid any attention to the state of annotations in Hibernate as of J2SE 1.5, I suspect they're fairly close to those of EJB3). But this is an Entity bean and can't live outside the container. (I saw something about a JBoss microcontainer which presumably will please the TDD zealots.) Then we've got an SLSB (which still must implement a local interface) and is injected with an EntityManager used to persist the User. A couple of xml config files and a jsp with some custom tags (yes, I know they're standard JSF tags) to do the databinding. Looks pretty damn similar to my Spring, Hibernate, JSTL setup. I hate to say it, but it looks like Rod Johnson was pretty much dead on when he said in one of his books that he thought EJB3 would probably still be somewhat behind the curve or just barely caught up by the time it was released.
  84. Nested transactions?[ Go to top ]

    Statement:

    "There is nothing wrong with using SQL level transactions but dont forget that transactions can be nested. Infact EJB allows for this nesting with the 'RequiresNew' attribute."

    I think this will give the wrong picture for a reader - EJB transactions with RequiresNew are not nested.
  85. EJB3 vs. ESPB[ Go to top ]

    After following this thread before:
    http://www.theserverside.com/news/thread.tss?thread_id=38021

    and hearing all the arguments it seems that EJB3 does not offer added values to compare with what I called ESPB (Enterprise Spring POJO Beans, to distinct from the Spring MVC). From a *new* J2EE application development view, ESPB *is* an *alternative* (at least what I understood it from Rod's thread above).

    If you are asking to build a J2EE application (business layer) *now*, you surely don't want to go back for EJB 2.x and EJB 3.x is still not ready yet (it is some kind of "vacuum"). So what alternative do you have? One and only ESPB.

    The only positive thing about EJB3 is that it is a "de jure" standard (supported by many vendors). But as I mentioned in the thread above, ESPB seems to reach "de facto" standard in programming of business components which has more value. Mixing both would not be a solution (if you are making a *new* application), because of time and money constraint.

    Interesting to see what the oppinions of EJB3 supporters are?

    Cheers,
    Lofi.
  86. ejb3[ Go to top ]

    So I've got a User pojo with annotations instead of a Hibernate mapping file (mind you, I haven't paid any attention to the state of annotations in Hibernate as of J2SE 1.5, I suspect they're fairly close to those of EJB3). But this is an Entity bean and can't live outside the container.

    In EJB 3.0 Entities can live outside of the container.

    BTW. Hibernate annotations are nothing more than EJB 3.0 plus some HB specific extensions.
    Then we've got an SLSB (which still must implement a local interface)

    It's not the case any more. See simplified API spec.

    Artur
  87. ejb3[ Go to top ]

    I've got a User pojo with annotations instead of a Hibernate mapping file (mind you, I haven't paid any attention to the state of annotations in Hibernate as of J2SE 1.5, I suspect they're fairly close to those of EJB3). But this is an Entity bean and can't live outside the container.
    Entity beans are plain objects that can live and per persisted outside a container. The persistence part of EJB3 aka Java Persistence can be use in Java SE with the same set of APIs.
    Hibernate Annotations can be use on top of Hibernate as an alternative of hbm xml files. The annotation core are the standard eJB3 ones plus a set of Hibernate specific one for Hibernate only features.

    Emmanuel
  88. ejb3[ Go to top ]

    OK, I looked at the first tutorial at http://docs.jboss.com/seam/reference/en/html/tutorial.html. So I've got a User pojo with annotations instead of a Hibernate mapping file (mind you, I haven't paid any attention to the state of annotations in Hibernate as of J2SE 1.5, I suspect they're fairly close to those of EJB3). But this is an Entity bean and can't live outside the container. (I saw something about a JBoss microcontainer which presumably will please the TDD zealots.) Then we've got an SLSB (which still must implement a local interface) and is injected with an EntityManager used to persist the User. A couple of xml config files and a jsp with some custom tags (yes, I know they're standard JSF tags) to do the databinding. Looks pretty damn similar to my Spring, Hibernate, JSTL setup. I hate to say it, but it looks like Rod Johnson was pretty much dead on when he said in one of his books that he thought EJB3 would probably still be somewhat behind the curve or just barely caught up by the time it was released.

    The biggest mistake in your analysis is that you use an SLSB. To get the full benefit of EJB3, and see how this stuff is actually way ahead of what people are using today, you need to be using SFSBs.

    Check out the Seam demo applications if you want to see how EJB3 can totally change how applications are designed / architected.
  89. ejb3[ Go to top ]

    The biggest mistake in your analysis is that you use an SLSB. To get the full benefit of EJB3, and see how this stuff is actually way ahead of what people are using today, you need to be using SFSBs.

    I just looked through the first tutorial in the JBoss series of EJB3 tutorials. It used an SLSB. I'll check out SFSBs with Seam. Thanks.
  90. Seam is an interesting approach[ Go to top ]

    First, it uses ejb3 for everything except the plain view layer.
    The view controller, view model is already ejb.
    Secondly it uses AOP(EJB3 interception and dependency injection to automate lots of things like object/parameter passing in displayed table links, injection of database entity managers and transactional context switching,
    which you normally have to handcode.
    Third it uses annotations for scoping mechanisms, to bypass the dreaded request/restore cycle all webapps have to go through.
    Programming in seam is almost like programming a normal user interface in a rich client system, except that the session beans used left and right are way more powerful than normal classes.

    I canot say you can reach the same functionality and code tightness with Spring yet, too many XML artefacts are there, there is no binding as tight as SEAM does it with JSF in Spring (although Spring JSF bindings exist, they are way more verbose than SEAM is)
    But also there is nothing in seam which could not be probably done in Spring in the long run, but Seam in the areas which it tries to cover is ahead of everything in the current Java domain, and that is partially caused by the foundation EJB3 gives.
  91. Rod would say that...[ Go to top ]

    I hate to say it, but it looks like Rod Johnson was pretty much dead on when he said in one of his books that he thought EJB3 would probably still be somewhat behind the curve or just barely caught up by the time it was released.

    Rod Johnson would say that as EJBs are a direct competitor to Interface21's core product.
  92. Rod would say that[ Go to top ]

    Rod Johnson would say that as EJBs are a direct competitor to Interface21's core product.

    No. You, and JBoss, are a direct competitor to Interface21's core product. It's an important distinction. Interface21's core product, as is yours, is consulting. Interface21 has built what looks to be a very healthy (and growing) consulting practice. It's growth and success have been correlated with the growth and success of the Spring framework, which enormously simplified Java development. Your consulting practice centers around your app server, the key component of which (for any app server) has traditionally been viewed as the EJB container. You've tried to setup this false competition before, between EJB and Spring. It doesn't hold. Spring made EJB2 *easier* to use. At least for MDBs and session beans. And Hibernate did far more than Spring ever did to awaken people as to just how broken entity beans were. No, what you guys are really afraid of in Spring is not that they are competitors to EJB, it's that they're competitors to your whole app server. All the value adds that Weblogic and Websphere give someone are absent from JBoss. Your JMS implementation is crap, your JTS implementation is (was) crap. You use Tomcat as the web container (and slag off the Apache folks every chance you get - I love that!). Basically, you're the El Cheapo container. And then along comes Spring, and suddenly if I don't need Weblogic or Websphere, why the hell would I even bother with JBoss? I'll just stick ActiveMQ and JOTM in Tomcat, glue it all together with Spring, and voila! I've got my app server. And it's like a nightmare, it just keeps getting worse and worse for you guys. I've now got asynchronous MDPojos both ways in Spring, and Mr. Coyler doing the AOP. You had to grab Arjuna just to stop the hemorrhaging.

    You JBoss guys miss no opportunity to pimp your product and criticise others in the process, usually not nearly as subtle as you're doing here. Let's remember too, Spring is just a framework. Spring could vanish tomorrow and Rod will still go to work the same place he did the day before. He'll still earn a healthy paycheck. If JBoss were to vanish tomorrow, you're out of a job. So your financial and professional interest in EJB is quite explicit. As for Rod and the Spring team, I'm not so sure. I'll grant you, I'm sure they do a fair bit more consulting these days as a result of Spring, but judging by Rod, Juergen, et al's books, and their behavior in every public forum I've seen them in, they are consummate professionals dedicated to their craft. For people like that financial incentives typically pale in comparison to the pursuit of excellence. They take care in their books to point out that they are not advocating the wholesale writeoff of EJB, and also that EJB != J2EE. They explain that SLSBs and MDBs offer great value. They *do* hold that entity beans are broken. But let's remember, Hibernate became the replacement for entity beans, not Spring. Basically, they are the ultimate pragmatists.

    Maybe it's a personality flaw that is just inherent in people who create this stuff? You know, to invest so much of oneself in something just ensures these sorts of emotional responses. That's why you attack other AOP frameworks. You attack any perceived competitition to EJB3. But that can't be. The Spring guys aren't _ssholes.
  93. Rod would say that...[ Go to top ]

    Rod Johnson would say that as EJBs are a direct competitor to Interface21's core product.

    :-)

    After being at the discussion at Javapolis between some of the Spring guys and Mike Keith about what gets dependency injected and how you have to tie in to get the rest of your object model from an EJB3 component, I don't think he's particularly worried about EJB3 as a competitor. I think EJB3 will be a good step forward for the spec, but I think Spring (or other DI framework) will still be a very valuable and necessary part of EJB3 applications.
  94. Less functional[ Go to top ]

    not really, the API is very close to hibernate, but a little bit more cleaned up (the whole lock, save, persist, lockmode mess for instance).
    The HQL basically is also the query language of the entity beans, and the session manager is basically renamed to
    Entity manager, a name which makes more sense.

    Besides that you get session handling and transacitonal handling out of the box within the session bean domain, all handled by the container itself.

    If you come from Hibernate you will almost at home, in fact the JBoss implementation of the ejb3 entity beans is based on Hibernate.

    The power of EJB3 can be seen in Seam, one of the most interesting frameworks I have seen in the recent past.
  95. Interceptors[ Go to top ]

    not really, the API is very close to hibernate, but a little bit more cleaned up (the whole lock, save, persist, lockmode mess for instance).The HQL basically is also the query language of the entity beans, and the session manager is basically renamed toEntity manager, a name which makes more sense.

    To get the whole picture though, the OR mapping for EJB 3.0 isn't as rich as Hibernate's, but it is still pretty complete. Emmanuel has added a bunch of Hibernate annotation extensions so that you can use them with standard EJB 3.0 entity beans.
    Besides that you get session handling and transacitonal handling out of the box within the session bean domain, all handled by the container itself.If you come from Hibernate you will almost at home, in fact the JBoss implementation of the ejb3 entity beans is based on Hibernate.The power of EJB3 can be seen in Seam, one of the most interesting frameworks I have seen in the recent past.

    Yeah, the SEAM framework makes heavy use of the new EJB 3.0 interceptors. EJB 3.0 interceptors allow you to not only intercept method calls, but also EJB callback events like @PostCreate(ejbCreate). This allows you to do things like write your own custom injection annotations (like SEAM does). One guy did this to implement Spring/EJB3 integration.

    Bill
  96. just to be "standard?"[ Go to top ]

    i admit i've not looked at EJB3 too closely yet, but i'll put the question out there for people, why should i bother with EJB3 if i'm already quite satisfied with my current OR mapping framework (Hibernate 3), which is also a de facto standard (albeit without Sun's imprimatur)? from what i've seen, and i readily admit i could be wrong about this, EJB3 doesn't really offer anything over Hibernate. standardized annotations maybe? and looks to be less functional than Hibernate. is what Vic said true, that i can't map collections of entities with EJB3? jeez, if so i must say, what a pile of sh_t. is that design by committee?

    Given that the team who designed and developed Hibernate were deeply involved in the creation of EJB3, and considers it a massive step forward for Java, perhaps it would be worth your effort to try it out, and see if it works for you.

    Or, alternatively, you could just believe everything you read on TSS :-)
  97. Well over 95% of my time I do use it. Unfortunately if you are building enterprise service components and apps and not simple knock off silos, you don't always know how many resources will be involved. (Yes, resources, because transactions do not apply just to data stores. For example, messaging middleware can participate in transactions.)

    If you are building n-tier enterprise applications and service components your persistance layer abstracts away your knowledge of where and how your data is stored. Also, you don't write reusable components and classes that have to know these things because they can change and vary depending when and how they are used.

    The beauty of container-managed EJB transactions is that you merely have to declare whether or not a method is part of a transaction or starts one and let things manage themselves. If an exception is thrown somewhere amongst the POJOs, you can just let it force a rollback without having to code it yourself. The exception or reason for wanting a rollback may not occur in the persistence layer and you may have made multiple calls to various the persistence layer objects before encountering it.

    In your case your code would be hard wired to knowing there is only one resource, the data store and your objects would have to tell that resource to rollback. Or you would be committing every update you make. That's not a very powerful or flexible design.
  98. 90 % of time... you should not use it[ Go to top ]

    If you are conection to a single SQL DB, you should only use the SQL transactions.It's much faster for one, and simpler.

    Yup, that's exactly what JEE does.

    Vic, you can't bash what you don't understand ;-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  99. Aren't you still using transactions then?
  100. EJB3[ Go to top ]

    Some of you are complete beginners.
  101. EJB3[ Go to top ]

    Some of you are complete beginners.
    I know I am only 23 years old :) Guess I should grow up and come back.
  102. I am just interested in when they can give us the final one?
  103. I'm somewhat surprised to be making this post, but I guess that our PR engine hasn't been doing a good enough job lately.

    In addition to the previews mentioned by Joe in the OP, BEA has a preview available, available from a BEA subsidiary.

    -Patrick

    --
    Patrick Linskey
    http://bea.com
  104. Hi Patrick!
    In addition to the previews mentioned by Joe in the OP, BEA has a preview available, available from a BEA subsidiary.

    Hmmm, first of all, that deep link forces me to register. For what?

    Second, is there any information available on how to integrate that preview with BEA 9? When will WebLogic be EJB3 compliant (regarding the spec draft, of course)?

    Grant me to express some words about "doing a good enough job", though: We are developing a product for both JBoss and WebLogic, and while I'm not the run-of-the-mill JBoss fanboy (as my TheServerSide posting history shows, too), I must say that regarding both WLS 8.1 and 9, we have encountered a few bugs in the implementation of the EJB 2.1 spec's finer printed sections, while JBoss was implemented correctly.

    Worse still, bug fixes made for WLS 8.1 were not migrated to WLS 9, what made it impossible for us to migrate our application yet, even though our customers want us to as they want to be able to use JSE 5 for their extensions. I guess that is nothing your PR department can fix. :-(

    Sorry for the off topic rant, but at the moment, I'd rather recommend JBoss.

    That's just my 2 cents, though. Have a nice Christmas!

    Lars :-)
  105. KISS != less code[ Go to top ]

    Can we just clarify something please, "KISS" does not mean "less code".

    To quote the man http://www.brainyquote.com/quotes/quotes/a/alberteins103652.html.

    KISS means "Keep It Simple Stupid". What has this got to do with less lines of code; go and ask a C programmer to reduce a piece of code to it's smallest number of lines and see how simple and readable it is :)

    As it happens, Vic is right, if you don't need transactions then don't use them. That would be KISS. Of course the question is whether you need transactions :) (I have never written an app that didn't use them)
  106. In addition to the previews mentioned by Joe in the OP, BEA has a preview available, available from a BEA subsidiary.
    Hmmm, first of all, that deep link forces me to register. For what?

    Oops, sorry about that. I'm always logged in to our site, so forget about what's where. It's a link to the Kodo EJB3 preview.
    Second, is there any information available on how to integrate that preview with BEA 9?

    The docs (available from that link) do discuss how to use it in WLS 9.
    When will WebLogic be EJB3 compliant (regarding the spec draft, of course)?

    As with all the Java EE licensees, we cannot have an EJB3-compliant appserver release until we have a full Java EE 5-compliant appserver release. That'll doubtless be sometime in 2006, but I'm just an EJB flunky, so can't really intelligently comment on the timeline of the full WLS server.

    That said, we *can* have a EJB3-compliant persistence provider as soon as the EJB3 spec is finalized (which, in turn, depends on the Java EE 5 spec being finalized). Expect to see that piece of the puzzle soon after EJB3 final is out.
    Worse still, bug fixes made for WLS 8.1 were not migrated to WLS 9, what made it impossible for us to migrate our application yet, even though our customers want us to as they want to be able to use JSE 5 for their extensions. I guess that is nothing your PR department can fix.

    No, but it is something that my team (the EJB team) can fix, or at least address for the future. Happily, the approach that we're taking to implementing the EJB3 spec (both in terms of entities and session beans / MDBs) isolates that new code from the 2.1 container code, which will greatly help avoid the introduction of any instability into the old-style container code. Of course, we're doing this in a way that provides seamless interop between 2.1-style and 3.0-style beans.
    Have a nice Christmas!

    Thanks, you too!

    -Patrick

    --
    Patrick Linskey
    http://bea.com
  107. EJB3.0 : "le chant du cygne"[ Go to top ]

    Sorry for this few french words, but I don't know how to translate this one. Word by word, it means "song of the swan".
    It means that it is the last chance for EJB to meet success.
    So far, it has not reached its goals.
    On a lot of projects, I have noticed that :
  108. EJB3.0 : "le chant du cygne"[ Go to top ]

    I have noticed that :
    - EJB are complex and a lot of developpers do not manage them,
    - EJB cause problems of performance,
    - they are no real needs of distributed and transactionnal components in 99,99% of the applications.

    So why use EJB if we don't need them? For the technology sake?
  109. EJB3.0 : "le chant du cygne"[ Go to top ]

    I have noticed that :- EJB are complex and a lot of developpers do not manage them,- EJB cause problems of performance, - they are no real needs of distributed and transactionnal components in 99,99% of the applications.So why use EJB if we don't need them? For the technology sake?
    - EJB3 are POJOs and "very" simple to use thanks to DI and annotations. You can unit test your EJB3s in your junit suite.
    - EJB3 Entities are POJO managed by transparent ORM namely EntityManager (similar to the concepts behind Hibernate, Toplink, JDO). If your EJB container is slow, then choose a better one :-p
    - No need for distributed tx in 99%: agreed but *of course* your container should be smart enough to add *no* overhead of Tx involving 1 Datasource. Transactional components: you mean component demarkating tx. There is a fundamental misunderstanding of Tx in this thread, and they are useful for data consistency including on read only operation! And and a Tx demarkated sequence can be faster than your autocommit=true depending on your DB and the sequence of statements you do.

    Have a look at EJB3, really. What you're describing is just not what's in the spec.

    Emmanuel
  110. EJB3.0 : "le chant du cygne"[ Go to top ]

    Emmanuel, you are right, I am not talking about the EJB3 implementation but EJB2
    The EJB3 specification has tried to simplify the use of EJB, in order to make it as simple as POJO.
    But the question remains the same : if I don't need transactionnal and/or distributed components, why use EJBs instead of POJOs?
  111. EJB3.0 : "le chant du cygne"[ Go to top ]

    Emmanuel, you are right, I am not talking about the EJB3 implementation but EJB2The EJB3 specification has tried to simplify the use of EJB, in order to make it as simple as POJO.But the question remains the same : if I don't need transactionnal and/or distributed components, why use EJBs instead of POJOs?

    Security, concurrency are some things that come to my mind. But the problem is not EJB, it is to be able to switch fast between local objects, EJB objects, mock objects and that where Spring can help you.

    *Étrange de répondre en anglais à un autre francophone :)
  112. EJB3.0 : "le chant du cygne"[ Go to top ]

    But the question remains the same : if I don't need transactionnal and/or distributed components, why use EJBs instead of POJOs?
    I hope nobody makes you to use this stuff,
    I think it is very silly to use stuff you do not need. It reminds me a thread about "No reasons NOT to use Spring". If you do not have a reason to use some tool then it is is just a useless stuff for you.
  113. EJB3.0 : "le chant du cygne"[ Go to top ]

    But the question remains the same : if I don't need transactionnal and/or distributed components, why use EJBs instead of POJOs?
    I hope nobody makes you to use this stuff, I think it is very silly to use stuff you do not need. It reminds me a thread about "No reasons NOT to use Spring". If you do not have a reason to use some tool then it is is just a useless stuff for you.
    no worries :)
  114. EJB3.0 : "le chant du cygne"[ Go to top ]

    But the question remains the same : if I don't need transactionnal and/or distributed components, why use EJBs instead of POJOs?
    I hope nobody makes you to use this stuff, I think it is very silly to use stuff you do not need. It reminds me a thread about "No reasons NOT to use Spring". If you do not have a reason to use some tool then it is is just a useless stuff for you.
    no worries
  115. EJB3.0 : "le chant du cygne"[ Go to top ]

    But the question remains the same : if I don't need transactionnal and/or distributed components, why use EJBs instead of POJOs?
    I hope nobody makes you to use this stuff, I think it is very silly to use stuff you do not need. It reminds me a thread about "No reasons NOT to use Spring". If you do not have a reason to use some tool then it is is just a useless stuff for you.

    This really does depend on what you mean by 'stuff you do not need'. There are some coding methods that are strictly not needed, but a good developer uses them because they help make code readable and maintainable. An example is division of code into short procedures, even if those procedures are used only once. I would suggest that the use of dependency injection and aspects can, if used well, add clarity and maintainability to code in the same way. You don't strictly need these things... but using them can be good practise.
  116. EJB3.0 : "le chant du cygne"[ Go to top ]

    Emmanuel, you are right, I am not talking about the EJB3 implementation but EJB2The EJB3 specification has tried to simplify the use of EJB, in order to make it as simple as POJO.But the question remains the same : if I don't need transactionnal and/or distributed components, why use EJBs instead of POJOs?
    So you're using POJOs as services wo anything else. No IoC container to wire them all, nothing. Then yes, use your pojos in your main() app :-)
  117. EJB3.0 : "le chant du cygne"[ Go to top ]

    No, I am using Hibernate on my projects and Spring is not a good choice if I believe what said your fellow worker, Gavin King : that is "noisy", "inelegant" :
    http://houseofhaug.net/blog/archives/2005/08/12/hibernate-hates-spring/#comment-142
    Do you recommend the use of Spring with Hibernate?
  118. EJB3.0 : "le chant du cygne"[ Go to top ]

    Spring is a very good framework and I love and trust it, but I fail to find an added value by this stuff.
  119. EJB3.0 : "le chant du cygne"[ Go to top ]

    No, I am using Hibernate on my projects and Spring is not a good choice if I believe what said your fellow worker, Gavin King : that is "noisy", "inelegant" :http://houseofhaug.net/blog/archives/2005/08/12/hibernate-hates-spring/#comment-142Do you recommend the use of Spring with Hibernate?

    I think what Gavin said was: HibernateTemplate is not a good choice, not that Spring is not a good choice, because HibertnateTemplate is inelegant and he considers the active promotion of it noisy.
  120. Spring and Hibernate[ Go to top ]

    No, I am using Hibernate on my projects and Spring is not a good choice if I believe what said your fellow worker, Gavin King : that is "noisy", "inelegant" :http://houseofhaug.net/blog/archives/2005/08/12/hibernate-hates-spring/#comment-142Do you recommend the use of Spring with Hibernate?

    Please note that this comment is talking about Spring's HibernateTemplate class, nothing else. That's 1 class of about 1200 within Spring, which is simply an option for implementing DAOs (a valuable one, we think; Gavin's opinion may differ). As we explained in various places, you can alternatively also implement plain Hibernate DAOs and still let them fully participate in a Spring environment.

    Of course, none of this has any anything to do with Spring's general services, such as dependency injection, aspect configuration and transaction demarcation. This is by no means an all-or-nothing choice. In general, Spring does not restrict the application developer's choices: Implement Hibernate DAOs in the style that feels most natural to you, while stil providing Spring services to it.

    Juergen
  121. EJB3.0 : "le chant du cygne"[ Go to top ]

    No, I am using Hibernate on my projects and Spring is not a good choice if I believe what said your fellow worker, Gavin King : that is "noisy", "inelegant" :http://houseofhaug.net/blog/archives/2005/08/12/hibernate-hates-spring/#comment-142Do you recommend the use of Spring with Hibernate?

    If I recall this was not about Spring in itself but about Spring HibernateTemplate. If you're considering IoC containers such as Spring, then you also should consider looking at the EJB3 spec, because EJB3 is annotation driven dependency injection of EJB3 POJOs, EntityManager and any other JavaEE resource.
  122. EJB3.0 : "le chant du cygne"[ Go to top ]

    If I recall this was not about Spring in itself but about Spring HibernateTemplate. If you're considering IoC containers such as Spring, then you also should consider looking at the EJB3 spec, because EJB3 is annotation driven dependency injection of EJB3 POJOs, EntityManager and any other JavaEE resource.

    Except that it doesn't inject lower-granularity objects such as DAOs, only EJB3 (SL|SF)SBs, EntityManager, etc. Your own smaller beans don't get put in for you, you have to either have them wired in by Spring or hard-wire your EJB3 POJOs to particular implementations of those beans.
  123. EJB3.0 : "le chant du cygne"[ Go to top ]

    Except that it doesn't inject lower-granularity objects such as DAOs, only EJB3 (SL|SF)SBs, EntityManager, etc. Your own smaller beans don't get put in for you, you have to either have them wired in by Spring or hard-wire your EJB3 POJOs to particular implementations of those beans.

    Certainly not Jason. I do code my DAO layer as an EJB3 POJO, EJB3 Sessions can be as fine as needed, no problem with that, no overhead blah blah. Plus I benefit the EntityManager DI and JTA context binding semantic for free in my DAOs.

    Everybody has to rethink their usage of EJB Sessions in EJB3, cause there is *no* difference between a local access EJB3 session and a POJI/POJO.
  124. EJB3.0 : "le chant du cygne"[ Go to top ]

    Certainly not Jason. I do code my DAO layer as an EJB3 POJO, EJB3 Sessions can be as fine as needed, no problem with that, no overhead blah blah. Plus I benefit the EntityManager DI and JTA context binding semantic for free in my DAOs.Everybody has to rethink their usage of EJB Sessions in EJB3, cause there is *no* difference between a local access EJB3 session and a POJI/POJO.

    I wire in beans from 3rd party libraries to my Spring beans... How do I do this with EJB3? Unless / until EJB3 can manage ANY POJO, it will be limited compared to what I do in Spring today.
  125. EJB3.0 : "le chant du cygne"[ Go to top ]

    Certainly not Jason. I do code my DAO layer as an EJB3 POJO, EJB3 Sessions can be as fine as needed, no problem with that, no overhead blah blah. Plus I benefit the EntityManager DI and JTA context binding semantic for free in my DAOs.Everybody has to rethink their usage of EJB Sessions in EJB3, cause there is *no* difference between a local access EJB3 session and a POJI/POJO.
    I wire in beans from 3rd party libraries to my Spring beans... How do I do this with EJB3? Unless / until EJB3 can manage ANY POJO, it will be limited compared to what I do in Spring today.

    I answered your post wondering how to deal with DAO injection. As an basic app developper, 95% of my time I deal with business service layers injection, DAO injection, persistence context injection...
    I didn't claim EJB3 was a drop in of all Spring features, I said that EJB3 solves the practical problems of an app developper today.
  126. EJB3.0 : "le chant du cygne"[ Go to top ]

    Certainly not Jason. I do code my DAO layer as an EJB3 POJO, EJB3 Sessions can be as fine as needed, no problem with that, no overhead blah blah. Plus I benefit the EntityManager DI and JTA context binding semantic for free in my DAOs.Everybody has to rethink their usage of EJB Sessions in EJB3, cause there is *no* difference between a local access EJB3 session and a POJI/POJO.
    I wire in beans from 3rd party libraries to my Spring beans... How do I do this with EJB3? Unless / until EJB3 can manage ANY POJO, it will be limited compared to what I do in Spring today.
    I answered your post wondering how to deal with DAO injection. As an basic app developper, 95% of my time I deal with business service layers injection, DAO injection, persistence context injection...I didn't claim EJB3 was a drop in of all Spring features, I said that EJB3 solves the practical problems of an app developper today.

    Wouldn't it be much better if you said: It'll "hopefully" solve some of the practical problems of an app developer today. Spring is on the trenches already.
    IMO i think Spring has an advantage in the sense that no committees are held before we can see the implementation. A developer experiences a pain point,then makes it known,the spring guys then reply with check the latest CVS build or the sandbox or create a JIRA issue for it.But you are still assured that the stuff will work across web containers and appservers.
  127. to spring[ Go to top ]

    I do not see spring as something positioned against J2EE I see it as a complimentary framework, which only tries to simplify things left and right.
    (Face it some of the old pre annotation APIs are way to heavyweight to be used and to keep a good amount of sanity over a long period of usage)

    Spring simply hit a nerve by providing AOP without having a precompiler, by providing simplified APIs for many things, which were simply way to complicated (like the Hibernat Session
    Factory which had to be coded before Hibernate 3, or a decent OpenSessionInView Filter, and Transaction managers on POJO level)

    They must have something done right, because people jumped onto this framework in masses. But having it positioned against J2EE, I rather doubt it. Yes it allows a better handling and implementation of the BO/DAO pattern, but too many things are provided by app servers which spring cannot and does not offer.
    But on the other hand, for 95% of all applications I have encountered in the web domain, a full blown J2EE server would have been total overkill.

    One thing I really do not like how Spring moves forward is into the domain of web frameworks by providing its own. We are in a situation, that we have total webframework overkill, and having yet another one is totally pointless, the work spent there should have been better spent by providing a tighter integration into the existing ones and adding additional value there. Those integration points are there but they sometimes lack to a certain degree. But that is the nature of opensource to some degree, that things develop into a way, you personally dont really agree with.
  128. to spring[ Go to top ]

    I do not see spring as something positioned against J2EE I see it as a complimentary framework, which only tries to simplify things left and right.
    ....
    ( But having it positioned against J2EE, I rather doubt it. ....

    Hopefully i didn't imply that Spring is against J2EE, which Spring is not, and if i did i'll take back my words. I think Rod Johnson even wrote a book called J2EE without EJB to clarify this issue.
    I think i was referring to the EJB3 vs Spring debate. If anything, a part of Spring competes with EJB (though you can use the 2 together) and i think by the look of things spring is winning because we'll now have a new EJB spec that looks like a watered version of Spring.
    By the way some of the features in the upcoming version of Spring 2.0 are very nice (Like the simplification of xml).
  129. Actually if I have the choice[ Go to top ]

    Of having to use EJB session beans or spring beans, I probably would go towards the session beans and would use Spring for additional stuff (like the easier integration of Quartz), the annotations are way more lightweight than Springs xml.

    And yes, EJB3 was heavily influenced by Spring also by Hibernate and Toplink. It is good that the standards people nowadays look at the most commonly used solutions there are and try to improve upon them.

    But Spring has its merits, although EJB3 nowadays can be used as a container, its startup times even as embedded container are still way beyound the 1-2 seconds the average spring app needs for its startup. So if you do not use a dedicated EJB server the rountrip times of EJB3 still are somewhat painful.
    (the Seam jumped from 20 seconds startup time in the noejb version to 40 seconds in the embedded ejb version on a tomcat)
  130. Actually if I have the choice[ Go to top ]

    ...although EJB3 nowadays can be used as a container, its startup times even as embedded container are still way beyound the 1-2 seconds the average spring app needs for its startup. So if you do not use a dedicated EJB server the rountrip times of EJB3 still are somewhat painful.(the Seam jumped from 20 seconds startup time in the noejb version to 40 seconds in the embedded ejb version on a tomcat)

    My startup times for E-EJB3 are all under 10 seconds, even with full logging turned on. On a 2.5 year old laptop.
  131. Actually if I have the choice[ Go to top ]

    My startup times for E-EJB3 are all under 10 seconds, even with full logging turned on. On a 2.5 year old laptop.

    Note that this includes Hibernate entity beans and Seam. The E-EJB3 container starts up in 150ms, deployment of a few S(L|F)SB is between 1 and 3 seconds. Having said that, I know that the EJB3 deployers provided by JBoss are currently being investigated for performance improvements in larger applications. But 40 seconds for booking or noejb means something is wrong.
  132. Ok thanks, I will look into this[ Go to top ]

    But 40 seconds for booking or noejb means something is wrong.

    Ok thanks, I will start to investigate that. The 20 seconds for noejb (Tomcat+ Seam) were according to the forums within the normal timeframe most people get.
    I will give the ejb+tomcat booking another shot on a different machine.
  133. EJB3.0 : "le chant du cygne"[ Go to top ]

    Wouldn't it be much better if you said: It'll "hopefully" solve some of the practical problems of an app developer today. Spring is on the trenches already.IMO i think Spring has an advantage in the sense that no committees are held before we can see the implementation.

    I think JBoss and Oracle did a pretty good job of providing early implementations of the EJB3 specification for people to testdrive and use. Hell, we even have a bunch of people using JBoss EJB3 in production already (see my blog).
    A developer experiences a pain point,then makes it known,the spring guys then reply with check the latest CVS build or the sandbox or create a JIRA issue for it.

    You have this SAME exact developer experience with JBoss EJB 3.0 as it is open source, JIRA task management, and a open CVS and a vibrant attentive community. There's a good chance Glassfish has the same attentiveness and openness too. I hear Jonas has an EJB3 prototype coming too.
    But you are still assured that the stuff will work across web containers and appservers.

    EJB 3.0 persistence is pluggable between vendors as per the spec and last I heard, Spring doesn't do persistence.

    As for the rest? Cross-vendor pluggability is one of the minor goals we're trying to achieve with Embeddable JBoss EJB 3.0. "But I'll be tied to one vendor then!" you say? Well, remember, Spring is a vendor too. We're both open source.

    Bill
  134. EJB3.0 : "le chant du cygne"[ Go to top ]

    EJB 3.0 persistence is pluggable between vendors as per the spec and last I heard, Spring doesn't do persistence.

    Maybe i don't undestand, if J2SE and J(2)EE provide decent persistence, why should Spring which is not against either do persistence?
    As for the rest? Cross-vendor pluggability is one of the minor goals we're trying to achieve with Embeddable JBoss EJB 3.0. "But I'll be tied to one vendor then!" you say? Well, remember, Spring is a vendor too. We're both open source.Bill

    I thought Interface21 was the vendor and Spring an open source, apache licensed,java/j2ee framework.
  135. EJB3.0 : "le chant du cygne"[ Go to top ]

    A developer experiences a pain point,then makes it known,the spring guys then reply with check the latest CVS build or the sandbox or create a JIRA issue for it.
    You have this SAME exact developer experience with JBoss EJB 3.0 as it is open source, JIRA task management, and a open CVS and a vibrant attentive community. There's a good chance Glassfish has the same attentiveness and openness too. I hear Jonas has an EJB3 prototype coming too.

    It's not JBoss' opensourceyness that's in question, it's the EJB3 spec's, or any spec's, ability to respond rapidly to user demands. See also: EJB 2.1 to EJB 3 timeline.
  136. EJB3.0 : "le chant du cygne"[ Go to top ]

    EJB 3.0 persistence is pluggable between vendors as per the spec and last I heard, Spring doesn't do persistence.

    To be specific, Spring doesn't include an O/R mapping solution, indeed, because that is an entirely different concern that's easily as complex as everything Spring does. We believe in true separation of concerns.

    (For a little indication regarding the complexity of individual concerns, check out jar file sizes of Spring versus typical ORM providers or Web Service engines.)

    But of course, Spring comes with out-of-the-box support for all major ORM providers out there, including special approaches such as iBATIS SQL Maps, so there is arguably an even higher degree of pluggability in the persistence area.

    And as of the upcoming Spring 2.0 M2, we will also ship explicit support for the Java Persistence API (JPA, aka EJB3 persistence), so the full power of EJB3 persistence pluggability will be available to Spring-based apps as well.

    Juergen
  137. EJB3.0 : "le chant du cygne"[ Go to top ]

    Certainly not Jason. I do code my DAO layer as an EJB3 POJO, EJB3 Sessions can be as fine as needed, no problem with that, no overhead blah blah. Plus I benefit the EntityManager DI and JTA context binding semantic for free in my DAOs.Everybody has to rethink their usage of EJB Sessions in EJB3, cause there is *no* difference between a local access EJB3 session and a POJI/POJO.
    I wire in beans from 3rd party libraries to my Spring beans... How do I do this with EJB3? Unless / until EJB3 can manage ANY POJO, it will be limited compared to what I do in Spring today.

    Until I can write an entire app without writing a single line of XML, Spring will be too complex compared to the simplifications I can do today with EJB 3. Spring is also missing the seamless integration with the J2EE environment. Take all the persistence session management that session beans provide. You're just not gonna get that with Spring. Finally, I'll also not be tied to one proprietary vendor as I'll be standards based.

    I think you place too much importance on the full XML externalization of an object graph. Env-entry, resource, and ejb-ref injection probably satisfies 99% of requirements. Even if you do need this, you can extend EJB3 to write your own custom annotations and/or interceptors to inject JAXB, Spring, or even JBoss MC defined objects graphs.

    I think people need to review how simple it is to use EJB3 before making assumptions. EJB3 has the ability to let me write apps quickly with all its annotation support and braindead simple deployment. Later, if I need to fine-tune my deployment, I can use *as needed* XML overrides. The new XML DD schema supports partial deployment descriptors so you can just override what you want.

    Bill
  138. EJB3.0 : "le chant du cygne"[ Go to top ]

    Until I can write an entire app without writing a single line of XML, Spring will be too complex compared to the simplifications I can do today with EJB 3.

    I agree that the XML gets too complicated sometimes. The Spring team agreed too, which is why there is massive XML simplification with Spring 2.0 and its support for different XML schemas for domain-specific configurations (for instance, the transaction annotation support that used to take half a page is now one line. But for most of my beans (my WebWork actions as an example) they just get autowired without configuration... With my WebWork actions I don't even declare them in Springs config.
     Spring is also missing the seamless integration with the J2EE environment. Take all the persistence session management that session beans provide. You're just not gonna get that with Spring.

    Are you sure of that? You should try it. My Spring managed beans, including my WebWork actions, can be wired with annotations like @Transactional and @Secured and have transactionality and security automatically added. They don't even need to be configured in Spring the way I do it.
    Finally, I'll also not be tied to one proprietary vendor as I'll be standards based.

    I hear ya, and, if the standard met all of my needs I'd be glad to jump on board. But it doesn't, as I pointed out above. I think there will be a hybrid approach for many projects, where they use EJB3 for the things it does, but then they'll probably want to use EJB3 interceptors or something to wire in other dependencies using Spring or something. That's for those for whom using standards are more important than consistency (which is a lot of big companies), but, for me, until the EJB model can wire together EVERYTHING, why do it 2 different ways?

    On the other hand, the JPA (Java Persistence API) is very interesting. It does handle everything I need (I think, I haven't had time to try it for myself). I was particularly interested to find out at Javapolis that the JPA reference implementation donated by Oracle to Glassfish is actually TopLink (minus a couple of enterprise features) and that it will be available separate from Glassfish. That makes for some very interesting competition coming up in the opensource EJB3 space.
    I think you place too much importance on the full XML externalization of an object graph.

    I admit it... I'm a Beandoc object graph junkie :-)
      Env-entry, resource, and ejb-ref injection probably satisfies 99% of requirements. Even if you do need this, you can extend EJB3 to write your own custom annotations and/or interceptors to inject JAXB, Spring, or even JBoss MC defined objects graphs. I think people need to review how simple it is to use EJB3 before making assumptions. EJB3 has the ability to let me write apps quickly with all its annotation support and braindead simple deployment. Later, if I need to fine-tune my deployment, I can use *as needed* XML overrides. The new XML DD schema supports partial deployment descriptors so you can just override what you want.Bill

    Yes, but even 99% (and I don't think that wiring in 3rd party libs is really only 1%) isn't enough for me, because I'm then going to have to have a different way to handle that 1%. I'd rather be consistent across all of the wiring.
  139. Glassfish EJB3 dependencies[ Go to top ]

    I was particularly interested to find out at Javapolis that the JPA reference implementation donated by Oracle to Glassfish is actually TopLink (minus a couple of enterprise features) and that it will be available separate from Glassfish. That makes for some very interesting competition coming up in the opensource EJB3 space.

    Actually I noticed that too that the JSR220 entity bean base of glassfish was based toplink.
    It is very interesting because, given that hibernate and JBoss implementation has dependencies into around 20-40 third party jars (many of the jakarta commons project) while the glassfish implementation has around 4 dependencies and those looked rather familiar from the javax domain of libraries.

    Now given the fact that I have seen some Hibernate based projects with more than 80 jars and many of them related to Hibernate and that partially upgrading such systems (due to the nature Hibernate only being able to cover parts of the system) might become a real nightmare in the future (In one case I was really lucky just to have had to port one class which was omitted on one of the newer libs Hibernate and the other system used), the Glassfish implementation looks really nice from a maintainence point of view.
    One big + for open standards in that case.

    You can swap in and out different implementations and the porting effort is not that huge across those.
  140. EJB3.0 : "le chant du cygne"[ Go to top ]

    Until I can write an entire app without writing a single line of XML, Spring will be too complex compared to the simplifications I can do today with EJB 3.
    I agree that the XML gets too complicated sometimes. The Spring team agreed too, which is why there is massive XML simplification with Spring 2.0 and its support for different XML schemas for domain-specific configurations (for instance, the transaction annotation support that used to take half a page is now one line.

    I'm not entirely sure what the correlation between XML and complexity is (XML != complexity). XML *can* be complex, but then so can some annotations structures. A good XML dialect like Spring is easy to write and more importantly easy to read.

    As I demonstrated recently, XML comes with *fantastic* out of the box tooling in IDEs/plugins. This tooling makes XML an ideal format for externalized configuration. With the new XSD-based configuration you get the greatly improved validation capabilities of XML schema, domain-specific configuration (as Jason mentioned), classic, flexible <bean> configuration and support for Java 1.3+.

    Let's not forget that Java 1.3 and 1.4 are still popular platforms in many large organizations - with Spring organizations on these platforms are not left out in the cold.

    Rob

    ---------------------------------
    Interface21 - Spring from the Source
    http://www.springframework.com
  141. deployment[ Go to top ]

    Spring is also missing the seamless integration with the J2EE environment. Take all the persistence session management that session beans provide. You're just not gonna get that with Spring.

    Are you sure of that? You should try it. My Spring managed beans, including my WebWork actions, can be wired with annotations like @Transactional and @Secured and have transactionality and security automatically added. They don't even need to be configured in Spring the way I do it.

    Everybody knows Spring has tx and security support.

    I should have been more clear. I was talking mainly about deployment. At least with JBoss it is just a matter of jarring up your classes and putting the deployment in the deploy directory. No bootstrap code or configuration required. I'm ignorant of other platforms outside of WLS, but I'm sure deployment is just as easy, then again, I've never used Websphere so maybe my point is moot.
  142. EJB3.0 : "le chant du cygne"[ Go to top ]

    Until I can write an entire app without writing a single line of XML, Spring will be too complex compared to the simplifications I can do today with EJB 3. Spring is also missing the seamless integration with the J2EE environment. Take all the persistence session management that session beans provide. You're just not gonna get that with Spring.

    Such solution do exist: http://jacn.net.sf/, which provides a Java wrapper for the Spring XML configurations. It also brings much tighter integration of Spring and JEE. SEAM does have an incarnation in Spring. The CVS even has a SEAM booking demo redone in XML-less Spring (and facelets, JSF, hibernate, mini-webflow, etc) and features almost all the nice stuff as demoed in the hotel booking exmaple.

    Cheers,

    Bing
  143. Superb thanks for the hint[ Go to top ]

    Superb, I was aware that something was going on, I will check it out.

    What is the amount of code compared to Seam? One of the things which struck me in Seam, was how tight everything was, codingwise everything was stripped down to the bare minimum.
    Scoping by annotations, automated traversal of table indeces into the backend model upon triggering an action from a data table etc...

    A master detail/new blogger was implementable in around 100 locs 80 backend locs of those were properties with their setters and getters.
  144. EJB3.0 : "le chant du cygne"[ Go to top ]

    Everybody has to rethink their usage of EJB Sessions in EJB3, cause there is *no* difference between a local access EJB3 session and a POJI/POJO.

    Well, arguably *less* differences, but certainly not *no* differences. Let's not blur the notion of a POJO here.

    While an EJB3 session bean might superficially look like a POJO in appearance (well, aside from the annotations), it has very specific behavior at runtime: It's bound to JNDI, pooled by default, and proxied by the container (with some default interceptors always in the invocation chain). Exceptions thrown by the application object get wrapped by default, unless the exception classes are marked as @ApplicationException. Etc.

    EJB3 session beans have simple syntactical appearance, but very specific runtime semantics and deployment implications.

    On the other hand, a POJO is simple and straightforward in appearance *and* semantics. Spring allows you to configure raw POJOs as-is, including existing classes that were never intended for use in a container. Proxies and advices are added on an as-needed basis, with all other objects remaining completely unproxied. The same applies to pooling: only introduced on an as-needed basis. Exceptions are propagated as-is, unless explicitly treated differently.

    Essentially, Spring's core container allows for configuring service objects in a uniform manner - any kind of object, even if it "just" serves as fine-grained backend strategy that should never end up in JNDI. All of this in a very natural style, with a high degree of flexibility and decoupling, and without incurring any kind of unnecessary overhead. What you see is what you get; no hidden semantics unless you explicitly request them.

    Juergen
  145. Excellent point Juergen[ Go to top ]

    So what you are saying is that a POJO *by definition* has to have the same behaviour when constructed by "new YourClass()" as it does when instantiated by the "container"/factory?

    Of course as you mentioned you obviously won't get the wrappers (interceptors etc.) that you may or may not have defined, or any collaborators, but the POJO must still work "out of context".

    Good point. So what happens if I just instantiate an EJB3 object?
  146. EJB3.0 : "le chant du cygne"[ Go to top ]

    any kind of object, even if it "just" serves as fine-grained backend strategy that should never end up in JNDI. All of this in a very natural style, with a high degree of flexibility and decoupling, and without incurring any kind of unnecessary overhead. What you see is what you get; no hidden semantics unless you explicitly request them.Juergen
    What's wrong with JNDI, what's the fundamental difference / overhead between JNDI and a Spring BeanFactory?
    You're right, Spring comes configured with nothing as the default behavior, and EJB3 comes configured with some enabled interceptors like transactions as the default behavior. That's because the EJB EG think those behavior are of common usage in applications. If you want to remove those interceptors, you can use some annotations to configure by exception. This is just a difference of configuration defaults here, no difference of design nor conceptual overhead.

    Emmanuel
  147. EJB3.0 : "le chant du cygne"[ Go to top ]

    It looks like the lack of IoC and AOP in JNDI is a fundamental JNDI flaw :)
  148. EJB3.0 : "le chant du cygne"[ Go to top ]

    It looks like the lack of IoC and AOP in JNDI is a fundamental JNDI flaw :)

    IoC or DI are implemented in EJB3 on top of JNDI, JNDI is a bean container, like the BeanFactory I imagine. The IoC mechanism is done at a different level.
    As for AOP same answer. This has nothing to do with the "bean container".
  149. POJOness and application exceptions[ Go to top ]

    Well, arguably *less* differences, but certainly not *no* differences. Let's not blur the notion of a POJO here.

    While an EJB3 session bean might superficially look like a POJO in appearance (well, aside from the annotations), it has very specific behavior at runtime: It's bound to JNDI, pooled by default, and proxied by the container (with some default interceptors always in the invocation chain). Exceptions thrown by the application object get wrapped by default, unless the exception classes are marked as @ApplicationException. Etc.

    Only unchecked exceptions are wrapped, and only if they are not annotated with @ApplicationException, OR, if you don't declare your application exceptions with the application-exception XML element.
    On the other hand, a POJO is simple and straightforward in appearance *and* semantics. Spring allows you to configure raw POJOs as-is, including existing classes that were never intended for use in a container. Proxies and advices are added on an as-needed basis, with all other objects remaining completely unproxied. The same applies to pooling: only introduced on an as-needed basis. Exceptions are propagated as-is, unless explicitly treated differently.

    And that's the key difference. While EJB packages the most commonly used "aspects" that are used in Java EE applications, you have to wire them in with Spring. If you wire them in with Spring, you have the same "semantic change". The question is, when you wire up Spring with these "aspects" does it cease to become a POJO? When you use Spring's crappy Hibernate templates, does it cease to become a POJO? If you annotate a class with @Transactional or @Secure in Spring, does the class cease to become a POJO?

    So, you're saying that even though a session bean looks like a POJO, it isn't. Is this true even if I can test this session bean outside of a EJB container in a unit test? Is it still not a POJO?
    Essentially, Spring's core container allows for configuring service objects in a uniform manner

    Java EE provides the same measure of uniformness. Resource, ejb refs, persistence unit refs, etc... are all uniformly usuable between Java EE components like Servlets, JSPs, EJBs, interceptors, and soon JSF whether it be via XML or via an annotation.

    Also, Spring uniform configuration has the side-effect of being uniformly verbose.
  150. EJB3.0 : "le chant du cygne"[ Go to top ]

    Emmanuel, you are right, I am not talking about the EJB3 implementation but EJB2The EJB3 specification has tried to simplify the use of EJB, in order to make it as simple as POJO.But the question remains the same : if I don't need transactionnal and/or distributed components, why use EJBs instead of POJOs?

    EJBs are POJOs. Go look at the spec.
  151. EJB3.0 : "le chant du cygne"[ Go to top ]

    Emmanuel, you are right, I am not talking about the EJB3 implementation but EJB2The EJB3 specification has tried to simplify the use of EJB, in order to make it as simple as POJO.But the question remains the same : if I don't need transactionnal and/or distributed components, why use EJBs instead of POJOs?
    EJBs are POJOs. Go look at the spec.
    You may want to update the wikipedia definition of POJO
    "POJO is an acronym for Plain Old Java Object. The name is used to emphasize that the object in question is not somehow special but an ordinary Java Object, in particular not an EJB..." bla bla bla which is far from what I am reading in the ejb3 spec :)
  152. EJB3.0 : "le chant du cygne"[ Go to top ]

    Emmanuel, you are right, I am not talking about the EJB3 implementation but EJB2The EJB3 specification has tried to simplify the use of EJB, in order to make it as simple as POJO.But the question remains the same : if I don't need transactionnal and/or distributed components, why use EJBs instead of POJOs?
    EJBs are POJOs. Go look at the spec.
    You may want to update the wikipedia definition of POJO "POJO is an acronym for Plain Old Java Object. The name is used to emphasize that the object in question is not somehow special but an ordinary Java Object, in particular not an EJB..." bla bla bla which is far from what I am reading in the ejb3 spec :)
    The definition on wikipedia has just been updated twice, check out the history and compare :). It seems that the debate has moved ...
  153. EJB3.0 : "le chant du cygne"[ Go to top ]

    The definition on wikipedia has just been updated twice, check out the history and compare :). It seems that the debate has moved ...

    This is really annoying, btw. I did update wikipedia to reflect the status of EJB3 (which is in Public Final Draft and with 4/5 knwow preview implementations), and someone, anonymous obviouly, who believes he has more accurate information than an Expect Group member, removed it.
    That's bad to alienate a fact because you believe it's wrong without actually checking it.
  154. EJB3.0 : "le chant du cygne"[ Go to top ]

    The definition on wikipedia has just been updated twice, check out the history and compare :). It seems that the debate has moved ...
    This is really annoying, btw. I did update wikipedia to reflect the status of EJB3 (which is in Public Final Draft and with 4/5 knwow preview implementations), and someone, anonymous obviouly, who believes he has more accurate information than an Expect Group member, removed it.That's bad to alienate a fact because you believe it's wrong without actually checking it.
    Even if the previous definition was fine to me, believe me or not, I'm not the author of the modification. I will not comment the POJO EJB debate, since I believe they are two different things (think about the 'plain' word in the end of the wikipedia definition chapter 'Possible Ambiguity').

    regards
    patrick
  155. EJB3.0 : "le chant du cygne"[ Go to top ]

    This is really annoying, btw. I did update wikipedia to reflect the status of EJB3 (which is in Public Final Draft and with 4/5 knwow preview implementations), and someone, anonymous obviouly, who believes he has more accurate information than an Expect Group member, removed it.That's bad to alienate a fact because you believe it's wrong without actually checking it.

    Yeah, the EG membership + $4 will get you a cup of coffee at Starbucks.

    Public references like Wikipedia shouldn't be updated with information that's not factual and not even agreed upon. EJB3 == POJO is an opinion, not fact, as you can see in this thread. In my opinion, annotations and the expectation of certain call semantics make EJB3 SB's not POJOs.
  156. EJB3.0 : "le chant du cygne"[ Go to top ]

    This is really annoying, btw. I did update wikipedia to reflect the status of EJB3 (which is in Public Final Draft and with 4/5 knwow preview implementations), and someone, anonymous obviouly, who believes he has more accurate information than an Expect Group member, removed it.That's bad to alienate a fact because you believe it's wrong without actually checking it.
    Yeah, the EG membership + $4 will get you a cup of coffee at Starbucks. Public references like Wikipedia shouldn't be updated with information that's not factual and not even agreed upon. EJB3 == POJO is an opinion, not fact, as you can see in this thread. In my opinion, annotations and the expectation of certain call semantics make EJB3 SB's not POJOs.
    Exactly what I said! Read the spec an EJB Session does not have to be annotated.
    Following your definition, almost nothing is POJO. Hobernate, Toplink, JDO entities are not POJO cause these technologies change the semantic of the object my making them persistent. Please update wikipedia, it references Hibernate :-p
    My update emphasized that EJB3 was way different than EJB 1 or 2 and hence needed a clear distinction in the article, any person having read the spec would agree with that.