Does EJB 3.0 really make application development easy?

Discussions

News: Does EJB 3.0 really make application development easy?

  1. Raghu Kodali has written a blog entry called Does EJB 3.0 really make application development easy? detailing his migration of one of the J2EE 1.4 tutorials from EJB 2.1 to EJB 3.0 to see if the claims about EJB 3.0 regarding simplicity and code size were true.
    EJB 3.0 definitely simplifies the development of entity and session beans. Ease of use comes from the simplified model, and leveraging well known artifacts like POJOs and interfaces. The new EntityManager API is a big plus; I was able to make the changes to the business methods quite easily and did not require the need of reading the specification... All the features that make the application development easier will also provide returns in application maintenance cycle. All in all, I will recommend that developers take a fresh and unbiased look at the EJB 3.0 specification, by checking out the features and giving the publicly available EJB 3.0 containers a spin.
    Publicly available EJB3 containers are available from two places as of this writing:

    Threaded Messages (46)

  2. There real name of EJB's should be ETB's (Enterprise Transaction Beans). That's what the spec is about.

    In my field experience, there are limits too how much you can (and should) simplify transactional business methods.
  3. Caucho (with whom I am not affiliated) have a container that has as least some support for EJB 3.0, I'm not sure how comprehensive it is. They also have some built in support for IoC. http://www.caucho.com
  4. I tried to find a link to it on caucho.com, but was unsuccessful: do you have a direct URL?
  5. resin 3[ Go to top ]

    Just download resin3 http://www.caucho.com/download/

    Docs: http://www.caucho.com/resin-3.0/ejb3/index.xtp

    They should update their site, it's really bad.
  6. resin 3[ Go to top ]

    Thank you. I updated the list of EJB3 containers.
  7. good article[ Go to top ]

    I saw this blog last week and was hoping it would make it to TSS. Great article Raghu.
  8. We've announced this before on TSS, but I wanted to shamelessly plug some of JBoss's EJB 3 features while we're on the topic of EJB3. We liked the new EJB 3 development model and thought new features for the Session/MDB side got neglected. So here's some JBoss EJB3 extensions:


    I'm hoping that other vendors will pick these extensions up as well and that we can agree on some de facto standard and get an iteration of them in EJB 3.1.

    Bill
  9. I would like to have methods with transaction lifecycle greater than call/method lifecycle.

    In other words, a new thread is kept running with handle to the same transaction as the one started by the called method, while the method returns a value.

    Could't we have a EJBContext.createThread(Runnable) in which the container associates the thread to the transaction?
  10. I would like to have methods with transaction lifecycle greater than call/method lifecycle. In other words, a new thread is kept running with handle to the same transaction as the one started by the called method, while the method returns a value.Could't we have a EJBContext.createThread(Runnable) in which the container associates the thread to the transaction?

    Our asynch EJBs do propagate TX and Security, but I see what you mean. You want even finer grain thread control...
  11. I would like to have methods with transaction lifecycle greater than call/method lifecycle. In other words, a new thread is kept running with handle to the same transaction as the one started by the called method, while the method returns a value.Could't we have a EJBContext.createThread(Runnable) in which the container associates the thread to the transaction?
    Our asynch EJBs do propagate TX and Security, but I see what you mean. You want even finer grain thread control...

    It works using Stateful Session Beans (EJB 2.1 Spec, p. 365):
    A stateful session bean instance may, but is not required to, commit a started transaction before a business method returns. If a transaction has not been completed by the end of a businessmethod, the container retains the association between the transaction and the instance across multiple client calls until the instance eventually completes the transaction.
  12. I would like to have methods with transaction lifecycle greater than call/method lifecycle. In other words, a new thread is kept running with handle to the same transaction as the one started by the called method, while the method returns a value.Could't we have a EJBContext.createThread(Runnable) in which the container associates the thread to the transaction?
    Our asynch EJBs do propagate TX and Security, but I see what you mean. You want even finer grain thread control...
    It works using Stateful Session Beans (EJB 2.1 Spec, p. 365):A stateful session bean instance may, but is not required to, commit a started transaction before a business method returns. If a transaction has not been completed by the end of a businessmethod, the container retains the association between the transaction and the instance across multiple client calls until the instance eventually completes the transaction.

    I'm not sure this would actually work...Although the SFSB does retain this information, there is no standard way to propagate TX/Security to another thread (except maybe JCA WorkManager??? Never used it). So what I'm saying is that you couldn't spawn threads to call this SFSB. The EJB Container may/may not throw an exception when you tried this.

    Bill
  13. I would like to have methods with transaction lifecycle greater than call/method lifecycle. In other words, a new thread is kept running with handle to the same transaction as the one started by the called method, while the method returns a value.Could't we have a EJBContext.createThread(Runnable) in which the container associates the thread to the transaction?
    Our asynch EJBs do propagate TX and Security, but I see what you mean. You want even finer grain thread control...
    It works using Stateful Session Beans (EJB 2.1 Spec, p. 365):A stateful session bean instance may, but is not required to, commit a started transaction before a business method returns. If a transaction has not been completed by the end of a businessmethod, the container retains the association between the transaction and the instance across multiple client calls until the instance eventually completes the transaction.

    I'm not talking about tx propagation between calls, but between threads, which I think it's a major EJB limitation.

    let's say

    1. methodCall on thread 1
    2. txmgr.begin
    3. actual method call
    3.1. get adapter A
    3.2. enlist adapter A in tx 1
    3.3. new thread 2
    3.4 runnable->run get adapter B
    3.5 enlist adapter B in tx 1
    ...
    ...
    method return
    thread 1 dies
    ...
    ...
    thread 2 before dying.
    tx 1 commit
    thread 2 dies
  14. We have a lot of resistance to moving a transaction from one thread to another. The async beans code in WebSphere 6.0 does the following:

       * JNDI and component meta data
         The new thread can use the same JNDI stuff as the component that created it
       * Security
         Any credential on the old thread is propogated
       * Transaction
         It has no impact on the existing tr if any on the original thread. The new thread has a local transaction by default and the developer may start a global transaction if it chooses
       * i18n
         Copied over
       * Profiles (WAS feature)
         Copied over.

    Basically the Runnable runs with an exact copy of the thread context of the creator with the exception of the transaction. WebSphere allows this to be tuned so that only a subset is copied (performance reasons).
  15. You get that with the JSR 236/237. These will give fine grained threading. I'd question the value of the JBoss async calls given that work is coming. The same thing can be done with slightly more code using these JSRs.

    Billy
  16. You get that with the JSR 236/237. These will give fine grained threading. I'd question the value of the JBoss async calls given that work is coming. The same thing can be done with slightly more code using these JSRs.Billy

    Well, that's the whole point...Less coding, simpler development. I don't think 236 nor 237 come close to addressing simplicity. I don't know how many times I've gone to a site that was using MDBs just for asynchronicity. Talk about using a sledgehammer...

    Bill
  17. Talk about using a sledgehammer...

    Unfortunately, QoS-by-contract and simplicity are often conceptually at odds. I have seen MDBs being used for async as well, but it's not that much of a sledgehammer, and it's getting simpler.

    No offense, but you (Bill) and Billy are talking about two fundamentally different approaches to systems. I've seen them both, and I can tell you which one is being used to run the major financial exchanges.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  18. Unfortunately, QoS-by-contract and simplicity are often conceptually at odds.

    I don't think so at all. For example in a servlet's descriptor I could switch amongst security constraints (none, integrity, confidentiality) without recompiling. Asynchronicity seems just another delivery parameter, likely easily annotated.
  19. I don't mind simpler programming model so long as when I need to kick down, I can. Thats what 236/237 addresses and whats sorely lacking in the spec today. It's too dumbed down and I talk with lots of customers dropping J2EE for J2SE plus some framework not because it's easier but because it's just not possible with J2EE stack. A lot of the changes I've been making in WebSphere are in reaction to this. Async beans gives J2EE application a fully supported threading model. This is being standardized in 236/237 and the WebSphere Partition Facility (WPF) offers hot singleton support for customers that needs asymmetric clusters. The combination of both these features makes WebSphere useful for the highend customer because basically they can do what they need using this 'toolkit', J2EE + Async + WPF.

    I think Cameron may be talking to the same customer set. The async API you've proposed could be built very simply as a sample using proxies on top of 236/237, I don't see a whole lot of value making it part of the standard given this.

    I prefer this approach. Make the underly primitive APIs available to customers. Make a simple wrapper on top for common use cases but don't hide the primitives because some customer don't like the simple wrapper.

    Billy
  20. I don't mind simpler programming models so long as when I need to kick down, I can (...) I prefer this approach. Make the underlying primitive APIs available to customers. Make a simple wrapper on top for common use cases but don't hide the primitives because some customer don't like the simple wrapper.Billy

    I support this view. As I see it, J2EE is about specifications for low-level system services, which is arguably where standardization is most important.

    Such low-level APIs are usually not about convenience or simplicity, but rather about allowing to work at a very basic level, not imposing any restrictions in usage style. Consider JDBC or JavaMail as examples: those APIs are powerful (allowing to control each and every detail), but they are arguably not convenient.

    This tradeoff is fine, IMO: As long as the low-level APIs are standardized, higher-level conveniences can be built on top of it. This is where application frameworks like Spring and data access libraries like iBATIS SQL Maps come in. The same applies to the Servlet/Portlet APIs and web MVC frameworks that build on them.

    Essentially, all of J2EE follows that low-level system service approach - except for EJB, which enters the application domain and provides a specific application component model. The latter is fine for system entry points (such as servlets and remote services), IMO, but less important for local components within an application.

    There will always be a demand for different application-level programming models (both in the UI tier and in the middle tier), because of user requirements differing so widely. The beauty of J2EE is that it allows for a rich ecosystem here, all building on the same standardized low-level system services (Servlet API, JTA, JNDI, etc).

    Juergen
  21. So when can we expect to see IBM release a WebSphere "EJB3" Tech Preview ? (especially given your blatant marketing of WebSphere 6 and all its so-called advanced features).
  22. It is blatant and yes, I am shameless :) But after Bill plugged the other stuff, I couldn't resist.

    But, I do think our stuff is really cool plus I have quite a bit of sweat in it so what can I say.

    I can't comment on when we'll have EJB 3.0 in preview or otherwise as it's not announced publicly yet.

    Billy
  23. It is blatant and yes, I am shameless :) But after Bill plugged the other stuff, I couldn't resist.But, I do think our stuff is really cool plus I have quite a bit of sweat in it so what can I say.I can't comment on when we'll have EJB 3.0 in preview or otherwise as it's not announced publicly yet.Billy

    Actually we (Oracle)will support EJB 3.0 features in production release of Oracle Application Server 10g 10.1.3 (planned to shipped this summer)as fully supported feature so customers do not have wait another one year and get a jumpstart in building EJB 3.0 applications.

    Debu Panda
    Oracle
    http://radio.weblogs.com/0135826/
  24. slow progress on jsr 237 ?[ Go to top ]

    Too bad that the Work Manager JSR doesn't seem to make any progress. It's not even in the proposed list of JSRs to be considered for J2EE 5.0! Do you know any details considering bea is in the expert group?

    Simon
  25. slow progress on jsr 237 ?[ Go to top ]

    The JSR is moving along. In the meanwhile, both WebLogic and WebSphere implemented a subset of the Async beans APIs that are portable across both products. Some enterprising soul could implement this on JBoss/Geronimo pretty easily also. I've also written a layer to make the async beans APIs look like Doug Leas concurrentj with little effort. Problem is just the process of getting the code to the public.

    I also work for IBM BTW, your note makes me think I work for BEA.
  26. slow progress on jsr 237 ?[ Go to top ]

    I see, WebSphere and not WebLogic. Anyway, looking forward to the relese of this JSR; definitely a huge need.

    Simon
  27. I don't know how many times I've gone to a site that was using MDBs just for asynchronicity. Talk about using a sledgehammer...Bill

    I use MDBs not only for asynchronicity, but also for load balancing a system via multiple MDBs with different message selectors.

    Using JMX hooks, I can throttle the number of MDBs instances per message selector allowing me to dynamically control the resource load of various "levels" or "weights" of async processes in the container. The JMS queue functions as a persistent threading/process buffer. All of this done with very little infrastructure coding at all.

    The one thing I wish were easier to do with MDBs is to be able to either dynamically create new MDBs on the fly or at a minimum to be able to easily change pooled MDB message selectors at run-time.

    I am all for making MDBs more lightweight, but don't gut all the functionality they currently have in 2.1 because that sledgehammer is a mighty fine sledgehammer for some of us.
  28. Dynamic MDBs[ Go to top ]

    You can do the equivalent of dynamic MDBs in WebSphere 6.0 with very little code. You can also deliver the messages using a custom threading scheme if transactions aren't important (delivering market data feeds etc). We've used this to dynamically subscribe to market data feeds when a particular cluster members needs them. We used a couple of threads to pull a dynamic set of topic subscriptions into WebSphere and then used a sequenced thread pool to deliver those messages to the POJOs interested in the messages. The sequencer delivers the message using a threading model that ensures for a given topic messages are delivered serially whilst messages from different topics are processed in parallel.

    When combined with WebSphere Partitioning Facility (WPF, a feature of WebSphere XD) then this becomes a great way for building electronic trading systems or applications with dynamic messaging requirements.

    Billy
  29. whats a pojo[ Go to top ]

    ?
  30. whats a pojo[ Go to top ]

    Plain old java object. A term coined by Martin Fowler to denote a standalone java class that can be executed in any environment. That is, it doesn't need any framework nor application container.
  31. We've announced this before on TSS, but I wanted to shamelessly plug some of JBoss's EJB 3 features while we're on the topic of EJB3.

    Bill, it's shameless how you hi-jacked this thread from being a good documented example of using the Oracle EJB 3.0 Preview to easily and successfully migrate an app! :-)

    <<blockquote>I'm hoping that other vendors will pick these extensions up as well and that we can agree on some de facto standard and get an iteration of them in EJB 3.1</blockquote>
    So many things to consider, so little time...
    I am not yet convinced that these things will make the spec better or simpler, but will gladly reserve judgment until later on to see if people actually try out these types of proprietary features.

    -Mike
  32. We've announced this before on TSS, but I wanted to shamelessly plug some of JBoss's EJB 3 features while we're on the topic of EJB3.
    Bill, it's shameless how you hi-jacked this thread from being a good documented example of using the Oracle EJB 3.0 Preview to easily and successfully migrate an app!

    If I didn't, you'd have like zero comments on this thread...It is hard to argue against a well written blog/article such as Raghu's. So good, I've referenced it from our WIKI.
  33. So, nobody says "EJB 3.0 sucks"[ Go to top ]

    When i saw this thread, i firstly thought that people would say lots of negative opinions. I'm just a j2ee newbie and worked only on a hibernate based project. I really want to know if EJB has a future?
  34. So, nobody says "EJB 3.0 sucks"[ Go to top ]

    When i saw this thread, i firstly thought that people would say lots of negative opinions. I'm just a j2ee newbie and worked only on a hibernate based project. I really want to know if EJB has a future?

    Get with the times, dude. The "EJB sucks" thing was so 2 years ago...
  35. So, nobody says "EJB 3.0 sucks"[ Go to top ]

    Get with the times, dude. The "EJB sucks" thing was so 2 years ago...

    Well, in the meantime, even Linda - the EJB spec lead - herself essentially says that EJB 2.1 sucks (in her public presentations). Of course, EJB 2.1 is still the official production version of EJB out there, and will continue to play that role for at least a further year.

    After all, certified EJB3 containers are still a while away... a lot of early PR doesn't change that fact. Previews are nice, but noone is gonna get certified before the official release of the J2EE 1.5 umbrella spec - which won't happen before early/mid 2006.

    So arguably, EJB in its current production incarnation still sucks, and will continue to do so for a while :-)

    That said, Oracle's EJB3 preview and the associated documentation look decent. Congratulations, good job there!

    There are huge gaps in the API, though, in particular regarding exception handling: There doesn't seem to be any consistent exception strategy in the persistence part, for example. Well, not really a surprise; after all, the spec is still unfinished...

    Juergen
  36. So, nobody says "EJB 3.0 sucks"[ Go to top ]

    After all, certified EJB3 containers are still a while away... a lot of early PR doesn't change that fact. Previews are nice, but noone is gonna get certified before the official release of the J2EE 1.5 umbrella spec - which won't happen before early/mid 2006.

    So arguably, EJB in its current production incarnation still sucks, and will continue to do so for a while :-)


    OK, so let me get this reasoning straight:

    Because an EJB3 implementation cannot be *certified* until mid 2006, it will be impossible to use it in production mid until 2006. This is the case even though there are alpha releases out *now*, and mature releases will certainly be available coincident with the approval of JSR-220 (which has to happen well before the new J2EE rev).

    OK, got it.

    And as a corollary to that, since Sping/Hibernate can never, ever be certified as compliant with any standard anywhere, nobody anywhere can never ever use Spring/Hibernate in production.

    Something wrong there, but I can't quite put my finger on it...

    There are huge gaps in the API, though, in particular regarding exception handling: There doesn't seem to be any consistent exception strategy in the persistence part, for example. Well, not really a surprise; after all, the spec is still unfinished...

    Very nicely spotted, Juergen. Correct, the spec is not finished. That's why its called "Early Draft Release 2". Ooops, I feel like I'm stating the bleeding obvious....

    Cheers mate
  37. So, nobody says "EJB 3.0 sucks"[ Go to top ]

    And as a corollary to that, since Sping/Hibernate can never, ever be certified as compliant with any standard anywhere, nobody anywhere can never ever use Spring/Hibernate in production.
    Spring and Hibernate are mature products with large user bases. Unlike an immature spec, they won't change in a way that breaks user code. With a spec that is evolving, it is likely that application code developed against each snapshot will be broken. It's hard for vendors to protect against that.

    If standardization was the be all and end all, people would be using entity beans rather than Hibernate, TopLink, Kodo and others. But they chose to deliver applications that worked and took a reasonable time to deliver...
  38. So, nobody says "EJB 3.0 sucks"[ Go to top ]

    Spring and Hibernate are mature products with large user bases

    Since EJB 3.0 implementations can be very simple wrappers around mature ORM products like Hibernate/TopLink/Kodo, and mature EJB 2.1 containers, all with even larger user bases, this is spurious.

    Unlike an immature spec, they won't change in a way that breaks user code.


    Hmmmm .... one month ago, Hibernate changed in a way that broke user code.

    Can I take this as the Spring team committing to never make any changes that break user code in any future revision of Spring?

    Wow. That's a big call.
    If standardization was the be all and end all, people would be using entity beans rather than Hibernate, TopLink, Kodo and others.

    Strawman. Nobody here every claimed that standardisation is the be-all/and-all. But, when a technology is sufficiently understood, it makes sense to standardize.


    The question really is: what should people starting new projects now, that they expect to go into production in 12 - 18 months time use? Is it safe to adopt EJB3 for *development* now? Maybe, maybe not, depends upon who you are, how risk-averse you are. But there is certainly no doubt that (for non-toy projects) if you are starting a project in three months from now, then by the time you go into production, there will be mature implementations.
  39. So, nobody says "EJB 3.0 sucks"[ Go to top ]

    Hmmmm .... one month ago, Hibernate changed in a way that broke user code.
    True. No doubt you had valid reasons for making that choice. But the migration exercise wasn't too hard, as the same mappings should work and the API is quite similar (if a superset). If your user community had objected violently you no doubt wouldn't have made the same degree of changes, so it's not like there was no accountability there. Furthermore, as with any technology meant to act on POJOs, users with well-designed Hibernate applications should find that most of their domain model should require no change. The POJO point is crucial here.
    Can I take this as the Spring team committing to never make any changes that break user code in any future revision of Spring?
    Well our record on backward compatibility so far has been excellent. Compared for example with EJB 1.0 - 1.1 - 2.x - 3.0. I'm happy to make a commitment to continue that excellent record. It's not so difficult with a well-designed framework using Dependency Injection and AOP.

    Realistically you can never get 100%. E.g. if you upgrade most app servers to a major or even a point release--even on the same specification version--typically any really complex application will break. But will usually be easy enough to fix. But we are confident that we can continue to be damn close to 100%.

    Anyway, the extreme twist on this came from you, not me. My point was that we know that the evolution of the EJB3 spec towards the final product is likely to break code written against it now; it's unlikely that the same is true of code written against Spring now, because lots of applications have been written against it, many corner cases identified and addressed etc.

    I'm not quite sure what we're arguing about at this point: as you rightly say, it's a decision for companies to make whether or not they're comfortable developing against a non-final spec, not for us to make for them.

    Rgds
    Rod
  40. So, nobody says "EJB 3.0 sucks"[ Go to top ]

    Gavin,

    This is not about certification per se, it's about production-readiness of the overall J2EE environment. J2EE servers like WebLogic and WebSphere usually don't declare a version production-ready until it's fully certified for a specific J2EE umbrella spec. You can't simply plug EJB3 into an existing J2EE 1.3 or 1.4 environment there.

    The main difference between a library like Hibernate or Spring and an EJB container is that the former drops nicely into existing J2EE environments, interacting with the established server infrastructure, while the latter does not: to properly run a full EJB3 container in a J2EE environment, you need to upgrade your J2EE *server*.

    Many people happily drop new Hibernate or Spring versions into applications running in their *existing* J2EE environment. But hardly anyone upgrades the entire J2EE server in an instant; that approvement process can take ages. An in particular, noone will upgrade their entire production J2EE server to a pre-release version.

    So how can someone properly adopt EJB 3.0 on, for example, WebLogic or WebSphere before production J2EE 1.5 versions of those servers are out? At best, someone could choose to use standalone "javax.persistence" on such an existing server, but that's hardly full EJB 3.0. Direct Hibernate or TopLink usage might be a better choice in such scenarios.

    I am aware that the JBoss EJB3 preview is implemented as add-on to JBoss4. However, I doubt that this strategy can last beyond the previews, in particular due to the conflict between the EJB3 jar and the old EJB2 jar. In the current previews, there is just an excerpt of EJB3 in the jar, but what to do with the final, full EJB3 implementation, which is bound to have overlap with the old EJB2 API classes?

    Juergen
  41. So, nobody says "EJB 3.0 sucks"[ Go to top ]

    Gavin,This is not about certification per se, it's about production-readiness of the overall J2EE environment. J2EE servers like WebLogic and WebSphere usually don't declare a version production-ready until it's fully certified for a specific J2EE umbrella spec. You can't simply plug EJB3 into an existing J2EE 1.3 or 1.4 environment there.

    This is *NOT* completely true as I remember BEA always included early implementation of J2EE features in the past.

    The document proves that WLS 6.0 included features of EJB 2.x before it was finalized.

    http://e-docs.bea.com/wls/docs60/ejb/EJB_whatsnew.html

    The Enterprise JavaBeans 2.0 implementation in WebLogic Server Version 6.0 will be fully supported and can be used in production. However, be advised that the Sun Microsystems EJB 2.0 specification is not yet finalized, and the WebLogic Server implementation of the EJB 2.0 architecture is based on the most current public draft of this specification.


    regards
    Debu
  42. So, nobody says "EJB 3.0 sucks"[ Go to top ]

    The document proves that WLS 6.0 included features of EJB 2.x before it was finalized.
    I remember very well. I actually tried to use that new CMP implementation at the time. Not a happy experience, as it was quite immature, unlike WLS as a whole, which we were otherwise happy with in. I also remember the radical changes in the EJB 2.0 spec at a late stage in the review process.
  43. So, nobody says "EJB 3.0 sucks"[ Go to top ]

    Rod,
    We will make sure that you will have not have the similar experience with Oracle's EJB3 implementation when we go to production (:-

    Our EJB3 Persistence layer is built on the top of Oracle TopLink and hence inherits all it's robustness

    -Debu Panda
    Principal Product Manager, EJB Container
    Oracle Application Server development team
  44. So, nobody says "EJB 3.0 sucks"[ Go to top ]

    Our EJB3 Persistence layer is built on the top of Oracle TopLink and hence inherits all it's robustness.

    This is certainly true and an indicator that Oracle's EJB3 persistence *backend* will be robust. It doesn't say anything about EJB3 API stability before the final spec gets released, though.

    Early EJB adopters might have burned their fingers back in the EJB 2.0 pre-final days, when the last-minute introduction of local interfaces radically changed EJB 2.0's overall approach from the ground up...

    Juergen
  45. hardly anyone upgrades the entire J2EE server in an instant; that approvement process can take ages. An in particular, noone will upgrade their entire production J2EE server to a pre-release version.

    And even when the server version is a 6.0 production one, and you have the approval, sometimes trying to follow the upgrade path so carefully documented by the app server provider in order to move your cluster to a new version is an incredibly painful process, that literally takes weeks because of having to wait the usual "talk with 1st level support - wait until they understand they don't know a damn about how to solve your problem - wait until they admit they have never tried something like that - talk with the second level support - send them your whole app server config - wait for them to reply (from the other part of the globe, different timezones, etc.) - retry and move on - restart from 1st level support with the new problem...
  46. So, nobody says "EJB 3.0 sucks"[ Go to top ]

    When i saw this thread, i firstly thought that people would say lots of negative opinions. I'm just a j2ee newbie and worked only on a hibernate based project. I really want to know if EJB has a future?
    Get with the times, dude. The "EJB sucks" thing was so 2 years ago...

    You forgot the end "...and can I sell you a container?"
  47. So, nobody says "EJB 3.0 sucks"[ Go to top ]

    When i saw this thread, i firstly thought that people would say lots of negative opinions. I'm just a j2ee newbie and worked only on a hibernate based project. I really want to know if EJB has a future?
    Get with the times, dude. The "EJB sucks" thing was so 2 years ago...
    You forgot the end "...and can I sell you a container?"

    Who cares whether EJB3 sucks or not? The vendors will have a hard time selling it, won't they?