I always wondered about this.

[tatvamasi]

Lot of us got out of EJB (includes all kinds). Can you guys pitch in on when and why? Please do not quote books, we all know those reasons. Give us some enlightening EJB hell (remember? DLL hell!) experiences.

[tatvamasi]

Wow! i thought I would hear many stories by now.

[spiff]

Why force yourself to remember painful experiences?

[wpoitras]

I think its the part about not quoting books. Although I'm sure people have their own experiences, I found the arguments laid out in the books covered it pretty well.

The other thing is I don't remember EJBs being "hell" (I never used entity beans). I just never realized how much time I was wasting with all of the descriptors and API specific classes because I didn't know any better. So Spring didn't save me from hell (especially since I use Spring with stateless EJBs sometimes) just brought me to a cleaner house.

[tatvamasi]

I think its the part about not quoting books. Although I'm sure people have their own experiences, I found the arguments laid out in the books covered it pretty well.

I think I posed my question wrong, I am more interested in to some kind of banchmark. Thats about it. Books are books are books, How many times have you seen people change their mind just because book says so and never reflect on both of their experiences? I have seen it happen many times.

The other thing is I don't remember EJBs being "hell" (I never used entity beans). I just never realized how much time I was wasting with all of the descriptors and API specific classes because I didn't know any better. So Spring didn't save me from hell (especially since I use Spring with stateless EJBs sometimes) just brought me to a cleaner house.

I have seen session beans being hell as well. On a side note, spring was not in subject here. One can write POJO code without using spring. This is more of an architectural question than anything else. Search the board and you will see how many people are misguided when it comes to architecture. People are using technologies where they shouldn't have, Making their code and architecture un-necessarily complex and increasing the cost of project. I don't know, May be I just don't understand. Or May be my foreign background is preventing me from understanding.

[tatvamasi]

Why force yourself to remember painful experiences?

well don't you want to reflect on your experience both way and figure out which way was the better and why?

[spiff]

Well, if you insist

EJB wasn't entirely hell, once it was up and running. The main difficulties lied in deploying them, maintaining several descriptors and looking them up through JNDI. Of course, this required lots of hair-pulling at first, but then we could just forget about it.

To me the biggest pain in using EJBs was exception handling wrt transaction management. The fact that the specs required the transaction to be rolled back only on RuntimeExceptions and EJBException, without it being configurable, was a huge constraint. So I've seen lots of session EJB methods simply delegating their work to a "local facade", catching the eventual application exception and setting the context rollback attribute to true. Lots of useless code for something that could've been easily configured, as it is with Spring's transaction annotations and attributes.

And as with wpoitras, I've never used the old entity beans so I guess I was spared the biggest part of hell you're talking about

[Wesslan]

EJB wasn't entirely hell, once it was up and running.
The main difficulties lied in deploying them, maintaining several descriptors and looking them up through JNDI. Of course, this required lots of hair-pulling at first, but then we could just forget about it.

I fully agree. Xdoclet helped a lot though. Especially when we had to refactor stuff...
We really had no bigger problems with session beans.

To me the biggest pain in using EJBs was exception handling wrt transaction management. The fact that the specs required the transaction to be rolled back only on RuntimeExceptions and EJBException, without it being configurable, was a huge constraint. So I've seen lots of session EJB methods simply delegating their work to a "local facade", catching the eventual application exception and setting the context rollback attribute to true. Lots of useless code for something that could've been easily configured, as it is with Spring's transaction annotations and attributes.

Been there, done that, got the T-sh... headache.

And as with wpoitras, I've never used the old entity beans so I guess I was spared the biggest part of hell you're talking about

Well, I have and it wasn't an every day walk in the park, trust me!
If you have simple entities with "simple" relations, Xdoclet and some common sense speeded up the development. The problem is, (2.1) entity beans "have" to be stupid.
Antoher problem is, of course, performance. You just have to write DAO's for a lot of stuff.
Inheritance, don't even get me started on that...

After all this rambling I have to say that EJB3 looks a lot better.
I've worked (as a consultant) for a big goverment authority and the only framework allowed there is EJB so I really hope, for their sake, that EJB3 is up to the challenge.

[madtree]

The biggest pain except deployement and all the necessary plumbing was that you couldn't extend the "aspects" applied on a EJB. For instance, the container manager security was never good enough to me so I had to use all sort of proprietary hacks to make it works.

[karldmoore]

I have seen session beans being hell as well. On a side note, spring was not in subject here. One can write POJO code without using spring. This is more of an architectural question than anything else. Search the board and you will see how many people are misguided when it comes to architecture. People are using technologies where they shouldn't have, Making their code and architecture un-necessarily complex and increasing the cost of project. I don't know, May be I just don't understand. Or May be my foreign background is preventing me from understanding.

The biggest HELL when it comes to EJB that I know of were companies that were doing what you've described. People had used EJB before or heard about it so every project was an EJB product. It was a silver bullet to solve every problem. Instead of a few simple POJOs it was un-necessarily complex for absolutely no gain. This isn't just constrained to EJB as you point out though its still going on now. Every project doesn't need a DTO layer, remoting, ORM etc..... but it does happen.