|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 193
Messages: 193
Messages: 193
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Article: The New Features in EJB 3.1
"The New Features in EJB 3.1" is a preview of the changes the EJB 3.1 expert group is working on for the next version of the Java EE specification. The idea is to give you a head's up on the changes as well as gather your feedback early so the expert group has the best chance of getting it right.
EJB 3.0 brought simplicity to Java EE 5 by moving away from a heavyweight programming model. EJB 3.1 aims to build on those successes by moving further down the path of simplicity as well as adding a handful of much-needed features. In each article in this series, Reza Rahman lets you know about the progress made by the expert group over the next few months.
The first article covers the two features that have been discussed in detail so far—making interfaces optional for EJBs and Singleton Beans. You'll also get a look-ahead into the possible features yet to be discussed. Remember, none of this has been finalized yet; all of this is really just a peek into the inner workings of the JCP so that you have a chance provide early feedback.
|
|
|
Message #245920
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
The concurrency annotations look interesting, but don't make special annotations for each of them.
Just adding attribute values is simple and clear enough, don't complicate by adding lots of variants.
|
|
|
Message #245921
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
Christophe,
Would you mind sending this comment to the expert group at jsr-318-comments@jcp.org? That would make it "real" for the committee members and the spec lead. It would help me out too so I don't have to be the second-hand source (which I don't mind at all, it's just less effective).
Cheers,
Reza
|
|
|
Message #245937
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
I agree with Christophe; please use parameters, otherwise you have to work out all values of all parameters in all permutations. With only one parameter and only a few values this seems doable, but it probably will cascade into unmanagability pretty quick...
component.setAlignment(SwingConstants.LEFT);
or
component.setAlignmentLeft();
component.setAlignmentCentered();
component.setAlignmentRight();
The latter also can make sense, but you combine the property being set and its value.
|
|
|
Message #245953
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
Sounds nice! EJBs in the servlet container are my personal favourite!
Holger
|
|
|
Message #245954
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
Can they learn from Spring and Guice, nope! That is what committees do, they make things complicated
Still complicated and weird, and couldn't they allow EJBs to run in a servlet container many years ago, but no, no, they had to make it very complicated, you need a container, you need special deployment descriptors for different types of containers, you need to implement interfaces, even now, DI in ejb crippled! Just call it the POJO spec from your friends at SUN and their friends, the JCP memebers, get rid of the container all-together, drop backward compatibility, call it a day. I think this will happen when EJB 7.1 comes out.
|
|
|
Message #245962
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
KISS
Adding @Singleton (good), but loading it up with transactions, a giant instance lock, and who knows what else by default (bad). Why not keep @Singletons simple by default like Spring or Guice or basically anybody else?
|
|
|
Message #245963
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Whata about criteria API
I thought there was suppose to be some sort of query criteria API?
|
|
|
Message #245965
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: KISS
Adding @Singleton (good), but loading it up with transactions, a giant instance lock, and who knows what else by default (bad). Why not keep @Singletons simple by default like Spring or Guice or basically anybody else?
In theory I agree with you that things should be left simple. But considering almost every EJB application I have seen has transactional EJB's it might make sense to have the Singleton EJB be transactional by default.
|
|
|
Message #245966
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: KISS
In theory I agree with you that things should be left simple. But considering almost every EJB application I have seen has transactional EJB's it might make sense to have the Singleton EJB be transactional by default.
Then EJB remains a heavyweight, specialized use and Spring or Guice replace JavaEE as a general framework.
@Stateful and @Stateless are heavyweight by design, and all the documentation and tutorials encourage heavyweight use. So, of course, they're mainly used only in heavyweight situations. If you have a lightweight use, you use Spring instead.
|
|
|
Message #245970
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
be trendy, bash a standard
Still complicated and weird
..
JB 3.1: the answer to the question nobody asked
..
I don't believe that EJB has a future, if they keep the name EJB.
I'm really tired of the bashing that EJB and JSF are getting.
If any normal framework is criticized without giving proper arguments and examples the critique is seen as unfounded and childish, and the criticizer gets flamed.
If a standard is bashed with sweeping statements and without any kind of concrete arguments the only thing that happens is half a dozen others join in to bash some more, even though usually they haven't even used the technology in production.
Ps. I use GWT and Spring, and have absolutely no vested interests in EJB or JSF.
/Henri Karapuu
|
|
|
Message #245971
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
EJB 3.1: the answer to the question nobody asked.
Seriously, the most funniest thing I've heard all day !!! ROTFLMAO !!!
p.s: Go Grails!!!
|
|
|
Message #245974
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: be trendy, bash a standard
If a standard is bashed with sweeping statements and without any kind of concrete arguments the only thing that happens is half a dozen others join in to bash some more, even though usually they haven't even used the technology in production.
I didn't bash it. I implied that no one cares about it. Of course that's an exaggeration IMO, improvements to the EJB spec now are just rearranging the deck chairs on the Titanic.
EJB 1-2 were the most over-complicated and over-sold standards I've ever had the displeasure of working with. 3+ might be better but the reality is that it's like putting a sticker on Chinese toothpaste that says "now without antifreeze".
|
|
|
Message #245975
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: be trendy, bash a standard
I didn't bash it. I implied that no one cares about it. Of course that's an exaggeration IMO, improvements to the EJB spec now are just rearranging the deck chairs on the Titanic.
Right. And that isn't mindless bashing. At all. Obviously. In any way....
|
|
|
Message #245978
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring Overtakes EJB as a Skills Requirement
I don't believe that EJB has a future, if they keep the name EJB.
See also Spring Overtakes EJB as a Skills Requirement.
Heh...OK, let me get this straight. The president of the company that produces and sells the proprietary Spring product publishes an article on his blog that talks up his product and talks down his competition. Pure marketing....
|
|
|
Message #245979
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Whata about criteria API
I thought there was suppose to be some sort of query criteria API?
That's a separate spec (JPA 2.0) and expert group.
|
|
|
Message #245980
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: be trendy, bash a standard
I didn't bash it. I implied that no one cares about it. Of course that's an exaggeration IMO, improvements to the EJB spec now are just rearranging the deck chairs on the Titanic.
EJB 1-2 were the most over-complicated and over-sold standards I've ever had the displeasure of working with. 3+ might be better but the reality is that it's like putting a sticker on Chinese toothpaste that says "now without antifreeze".
Your view is outdated.
There were certainly complexity issues in EJB 1-2. However, EJB 3.0 and JPA have simplified things significantly. EJB 3.1 and JPA 2.0 moves that effort forward further.
It will take a while for EJB to completely over come the perception scars it suffered from the complexities of the earlier releases of the specification. However, I have no doubt it will do so.
|
|
|
Message #245982
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring Overtakes EJB as a Skills Requirement
Randy
Heh...OK, let me get this straight. The president of the company that produces and sells the proprietary Spring product publishes an article on his blog that talks up his product and talks down his competition. Pure marketing....
Ok, I'll bite :-)
My blog was published on the SpringSource web site. I've never made any secret of my affiliation. I believe that you work for a large application server vendor (IBM), which still promotes the use of EJB. While I am not suggesting you make any secret of that, I suspect most readers of this thread were unaware of it, and it would have been wise to make your own affiliation clear before casting aspersions on others.
Second, wrt to my alleged vested interest; I was a long-term critic of EJB before Spring or SpringSource existed. It is a matter of public record that I have been extremely consistent on my views on this matter, regardless of my affiliation at any time.
Second, wrt "proprietary Spring product." Spring is Apache License open source. That is about the most liberal license available. It is simply misleading to call an open source product a "proprietary product." In any case, since you work for a company that produces countless proprietary products, this is clearly a cheap shot. As for "company that produces and sells the proprietary Spring product", again this is pure FUD: Spring is free to use. We do not sell Spring.
Third, with respect to "pure marketing": my post extensively quoted factual information which you and anyone else can verify. Your post merely insulted me without citing any information whatever.
Rgds
Rod
CEO, SpringSource
Founder, Spring Framework
|
|
|
Message #245983
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring Overtakes EJB as a Skills Requirement
Randy
Frankly, it would seem wiser to consider the implications of the evidence than to try to shoot the messenger. Or do you think that the job trends don't matter?
Note that IBM has previously engaged with Spring and SpringSource in various ways, so fortunately many of your colleagues don't seem to share your attitude. We share many users and customers with IBM, and I think they definitely expect a positive engagement from the two companies.
Rgds
Rod
|
|
|
Message #245985
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: be trendy, bash a standard
I didn't bash it. I implied that no one cares about it. Of course that's an exaggeration IMO, improvements to the EJB spec now are just rearranging the deck chairs on the Titanic.
Right. And that isn't mindless bashing. At all. Obviously. In any way....
No it's not. There's not one thing in that statement that says anything about whether EJB is good or bad. If you can't understand that or refuse to, you should consider that perhaps you are not thinking objectively. Passive aggressive sarcasm is a poor substitute for meaningful arguments.
|
|
|
Message #245984
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring Overtakes EJB as a Skills Requirement
I don't believe that EJB has a future, if they keep the name EJB.
See also Spring Overtakes EJB as a Skills Requirement.
Heh...OK, let me get this straight. The president of the company that produces and sells the proprietary Spring product publishes an article on his blog that talks up his product and talks down his competition. Pure marketing....
Rod's blog actually surprised me. Given the way I21, Spring zealots, and TSS talk, I thought the numbers would have been *WAY* worse. I actually think his blog was a positive one for EJB. EJB usage remained constant in the graphs he provided over time, leading me to believe this was an upper bound. Spring has only matched it recently.
On a related note, my EJB 3.0 book is also selling very well. About 1700 copies last quarter and its been out since May 2006.
So, EJB's demise is greatly exaggerated it seems...
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
|
Message #245987
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: be trendy, bash a standard
I didn't bash it. I implied that no one cares about it. Of course that's an exaggeration IMO, improvements to the EJB spec now are just rearranging the deck chairs on the Titanic.
EJB 1-2 were the most over-complicated and over-sold standards I've ever had the displeasure of working with. 3+ might be better but the reality is that it's like putting a sticker on Chinese toothpaste that says "now without antifreeze".
Your view is outdated.
There were certainly complexity issues in EJB 1-2.
You say it's outdated to think that EJB 1-2 are complex but you agree with the assertion. Are you calling your own views outdated?
However, EJB 3.0 and JPA have simplified things significantly. EJB 3.1 and JPA 2.0 moves that effort forward further.
I didn't suggest anything to the contrary.
It will take a while for EJB to completely over come the perception scars it suffered from the complexities of the earlier releases of the specification. However, I have no doubt it will do so.
And this is where we disagree. I think it will not. That was my point. These are called opinions. There is no correct or wrong (or outdated) opinion.
|
|
|
Message #245990
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring Overtakes EJB as a Skills Requirement
Randy
Heh...OK, let me get this straight. The president of the company that produces and sells the proprietary Spring product publishes an article on his blog that talks up his product and talks down his competition. Pure marketing....
Ok, I'll bite :-)
My blog was published on the SpringSource web site. I've never made any secret of my affiliation. I believe that you work for a large application server vendor (IBM), which still promotes the use of EJB. While I am not suggesting you make any secret of that, I suspect most readers of this thread were unaware of it, and it would have been wise to make your own affiliation clear before casting aspersions on others.
Second, wrt to my alleged vested interest; I was a long-term critic of EJB before Spring or SpringSource existed. It is a matter of public record that I have been extremely consistent on my views on this matter, regardless of my affiliation at any time.
Second, wrt "proprietary Spring product." Spring is Apache License open source. That is about the most liberal license available. It is simply misleading to call an open source product a "proprietary product." In any case, since you work for a company that produces countless proprietary products, this is clearly a cheap shot. As for "company that produces and sells the proprietary Spring product", again this is pure FUD: Spring is free to use. We do not sell Spring.
Third, with respect to "pure marketing": my post extensively quoted factual information which you and anyone else can verify. Your post merely insulted me without citing any information whatever.
Rgds
Rod
CEO, SpringSource
Founder, Spring Framework
Randy gave a valid opinion. Far from a cheap shot.
The thing is, Spring, although open source, *is* proprietary as it isn't standardized and is controlled by one vendor. Spring is a commercial product no matter how you try to spin it. Not that there is anything wrong with being commercial, open-source, and proprietary, but really Rod, this spin has become tiresome over the years. I'm glad people are *finally* calling you on it and realizing that SpringSource is a commercial vendor trying to make a buck just like the rest of us.
--
Bill Burke
JBoss, a division of Red hat
http://bill.burkecentral.com
|
|
|
Message #245991
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: KISS
encourage heavyweight use
Heavyweight is an abstract term. Can you describe what heavyweight specifically means to you.
|
|
|
Message #245993
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Promoting Spring
Rod,
I know this is a bit of topic, but why do you bother to continue playing the ejb vs Spring game? You are the front runner of one of the most popular (successful) frameworks in Javaland. You have already proven yourself and Spring.
If I was in your position I would not bother writing baited articles about ejb vs spring job trends, etc...
Why do you bother?
~Matt
*** I personally have been moving more towards developing in Flex/Guice/JPA, but at my company I still support a 50/50 mix of EJB and Spring applications.
|
|
|
Message #246003
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
This simply surreal, how can anybody defend EJBs, a technology that requires a specialized container to make it work! Why would you through so much trouble of configuring and maintaing this type of infrastructure. Spring has proved that it can be done without it. If EJB's to survive, there should be no need for a heavyweight container. Any servlet container should suffice.
|
|
|
Message #246004
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring Overtakes EJB as a Skills Requirement
The thing is, Spring, although open source, *is* proprietary as it isn't standardized and is controlled by one vendor. I think "proprietary" is the wrong word here. I would call it de facto standard. Just like hibernate is also a de fatco standard and is not proprietary.
|
|
|
Message #246005
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring Overtakes EJB as a Skills Requirement
I believe that you work for a large application server vendor (IBM), which still promotes the use of EJB. Hey Randy, are you responsible for my daily Webspshere pleasure???
|
|
|
Message #246006
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: KISS
Heavyweight is an abstract term. Can you describe what heavyweight specifically means to you.
lightweight = as light as possible, i.e. pure java call with no interception at all. You can add heavier operations as necessary, but the defaults should be light.
If EJB makes singletons with zero overhead, they can be used everywhere, without worrying about the cost, because they have no additional cost. It would be awesome.
If you do want transactions on your class, it's trivial to add a @TransactionAttribute on the class, which also serves as documentation for the class behavior. I don't see any value at all to enabling transactions and concurrency by default on a @Singleton, and see several disadvantages.
|
|
|
Message #246007
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: be trendy, bash a standard
I'm really tired of the bashing that EJB and JSF are getting.
I think EJB could be much more successful, if they would change the name. Sorry, I think that's a valid point, not bashing.
|
|
|
Message #246009
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
This simply surreal, how can anybody defend EJBs, a technology that requires a specialized container to make it work! Why would you through so much trouble of configuring and maintaing this type of infrastructure. Spring has proved that it can be done without it. If EJB's to survive, there should be no need for a heavyweight container. Any servlet container should suffice.
That can easily be reworded as such:
This is simply surreal, how can anybody defend Spring, a technology that requires a specialized container (Spring) to make it work! Why would you go through so much trouble of configuring and maintaining this type of infrastructure?
Spring IS a container. Spring beans have to be configured. Just like EJB. EJB containers can work in Tomcat and unit tests (see OpenEJB). The dependency injection of EJBs isn't that great, and the interceptors don't have sophisticated pointcuts but that may change in 3.1.
These day's you don't have to decide between spending big bucks on a commercial app servers or using Tomcat. There's JBoss, GlassFish, Geronimo, etc. EJB, JTA, JPA, JAX-WS, and the rest of Java EE come with these app servers and you can plug your program right in without needing a bunch of extra jar files and configuration. I don't understand what is so hard about that. It's so easy and powerful.
And what are you guys talking about, EJB 3.0 is heavyweight? Can you please be more specific. It's based on POJOs like Spring, and uses a container bundled with the app server instead of requiring you add and configure an external container such as Spring.
|
|
|
Message #246010
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring Overtakes EJB as a Skills Requirement
The thing is, Spring, although open source, *is* proprietary as it isn't standardized and is controlled by one vendor. I think "proprietary" is the wrong word here. I would call it de facto standard. Just like hibernate is also a de fatco standard and is not proprietary.
IBM does not have exclusive control over branded distributions of EJB. Hence, their EJB implementation is not proprietary.
On the other hand, AFAIK, SpringSource has exclusive control over the branded Spring distribution. This is the very definition of "proprietary".
If I'm wrong and SpringSource does not own the Spring trademark, then SpringSource is pretty fucked as a business. I think CDN's Elba and Oracle's Unbreakable have shown how truly useless source code is in a business sense...
As far as de facto, a de facto what? A de facto EJB? I think Rod's blog pretty much proves it is far from being a de facto anything based on EJB job numbers being pretty much even with Springs. Not that I really care...
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
|
Message #246012
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring Overtakes EJB as a Skills Requirement
Not that I really care...
You're right, it's time for the weekend...
|
|
|
Message #246013
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: KISS
I don't see any value at all to enabling transactions and concurrency by default on a @Singleton, and see several disadvantages.
I think the expert group is still trying to decide weather or not to make singleton Beans transactional by default. You should send the EJB3 JCP an email with your comments on the subject. I have heard the group is very open to suggestions.
I personally find Spring and EJB3 "heavy" to some extent, just in different ways.
|
|
|
Message #246014
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: KISS
I don't see any value at all to enabling transactions and concurrency by default on a @Singleton, and see several disadvantages.
I think the expert group is still trying to decide weather or not to make singleton Beans transactional by default. You should send the EJB3 JCP an email with your comments on the subject. I have heard the group is very open to suggestions.
I personally find Spring and EJB3 "heavy" to some extent, just in different ways.
They are very open to suggestions...
It would be cool if Reza, et al. could post links to their blogs. TSS isn't the best place in the world to get feedback on new features for EJB because of the Spring disruptions.
|
|
|
Message #246015
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
We ported 75% of project written in ejb to light weight programming using spring. We are planning to convert the remaining ejb project after 2 months.
Is ejb still necessary in this day and age?
|
|
|
Message #246022
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
We ported 75% of project written in ejb to light weight programming using spring. We are planning to convert the remaining ejb project after 2 months.
Is ejb still necessary in this day and age?
Yes, I actually like EJB 3. In comparison, I would prefer not to use Spring, even though it is one of most popular framework. I like what spring can do and its concept. But I don't like to program in XML. Spring turns java programming into XML configuration (or programming depending how do you look at it), which turns me off. I have followed Spring from very beginning, even before the Spring becomes the spring, read Rod Johson's 1st book several times and incorporate the JDBC template into one of the project (before Spring becomes a project). Not so closely recently. I think Spring can use Annotation instead of XML now, but I rather use EJB 3 and JPA.
Our old project is EJB 2.x and our new project is EJB 3 with JDK 1.6. I like it a lot. In case we need AOP, I just directly programming in AspectJ, which is pretty easy to do (except Intellij doesn't like it).
There may still some short comings in EJB 3, but so far I can still tolerate them. I might change my positions, but this is my current state of the mind.
Chester
|
|
|
Message #246024
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
"Your Help is Needed"
What's wrong with the java community? The EC members are asking feedbacks. Make your voice heard and tell them what's wrong with EJB, tell the feature you need being it DI, Interception or aspects!
Everyone those days seem to criticise EJB and the containers, can someone tell me what's a definition of a container? If Spring isn't a container what would it be?
Lightweight VS Heavy? OpenEJB, EasyBeans, Embedded JBoss with tomcat. Plans (after users request) are to make Glassfish, JBoss modular so you "deactivate" (if that's the word) the unneeded feature.
Folks who are deeming EJB to failure are dreaming, attacking the specs (lows) and EG members (leaders) make a good marketing and that's a reason that kept me away from being a Spring enthusiast (and I've used it for real world projects!). It's about ETHIC! I'll *may* change my mind about I21 or SpringSource (and their owners) when they'll change their attitude in the JEE community.
One last question when did Spring adopted annotations and stop being an XMLish crap (what we all hated in struts)? in 2.5 after the EJB3 Big Bang (another marketing argument against EJB.. would you mind?).
JEE folks! Please try to be POSITIF and stop TROLLING over and over misleading the beginners devs that take you for java gods! It's really sucking with those kind of arguing!
PS: Best ever JEE framework? Drop ALL JEE!!
signature
A mad JEE Lover!
|
|
|
Message #246027
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: be trendy, bash a standard
I didn't bash it. I implied that no one cares about it. Of course that's an exaggeration IMO, improvements to the EJB spec now are just rearranging the deck chairs on the Titanic.
EJB 1-2 were the most over-complicated and over-sold standards I've ever had the displeasure of working with. 3+ might be better but the reality is that it's like putting a sticker on Chinese toothpaste that says "now without antifreeze".
Your view is outdated.
There were certainly complexity issues in EJB 1-2. However, EJB 3.0 and JPA have simplified things significantly. EJB 3.1 and JPA 2.0 moves that effort forward further.
It will take a while for EJB to completely over come the perception scars it suffered from the complexities of the earlier releases of the specification. However, I have no doubt it will do so.
Thanks a lot for the encouraging words. We'll certainly try our best, whatever the odds...
|
|
|
Message #246028
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring Overtakes EJB as a Skills Requirement
On a related note, my EJB 3.0 book is also selling very well. About 1700 copies last quarter and its been out since May 2006.
So, EJB's demise is greatly exaggerated it seems...
I'm happy to say we are seeing similar success with EJB 3 in Action despite many doubters.
|
|
|
Message #246029
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring Overtakes EJB as a Skills Requirement
The thing is, Spring, although open source, *is* proprietary as it isn't standardized and is controlled by one vendor. Spring is a commercial product no matter how you try to spin it. Not that there is anything wrong with being commercial, open-source, and proprietary, but really Rod, this spin has become tiresome over the years. I'm glad people are *finally* calling you on it and realizing that SpringSource is a commercial vendor trying to make a buck just like the rest of us.
Bill:
Could not agree more. Like yourself, the increasing tolerance towards a particularly dangerous form of creeping vendor lock-in is what worries me most about Java EE bashing, and I can speak as someone who has nothing to do with any products or frameworks, commercial, open source or otherwise.
Reza
|
|
|
Message #246030
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
If EJB's to survive, there should be no need for a heavyweight container. Any servlet container should suffice.
That's precisely what is being done in the OpenEJB, EasyBeans and Embedded JBoss solutions, not to mention the graviton towards a "lite" version of EJB (discussed in a later article).
|
|
|
Message #246031
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
This simply surreal, how can anybody defend EJBs, a technology that requires a specialized container to make it work! Why would you through so much trouble of configuring and maintaing this type of infrastructure. Spring has proved that it can be done without it. If EJB's to survive, there should be no need for a heavyweight container. Any servlet container should suffice.
That can easily be reworded as such:
This is simply surreal, how can anybody defend Spring, a technology that requires a specialized container (Spring) to make it work! Why would you go through so much trouble of configuring and maintaining this type of infrastructure?
Spring IS a container. Spring beans have to be configured. Just like EJB. EJB containers can work in Tomcat and unit tests (see OpenEJB). The dependency injection of EJBs isn't that great, and the interceptors don't have sophisticated pointcuts but that may change in 3.1.
These day's you don't have to decide between spending big bucks on a commercial app servers or using Tomcat. There's JBoss, GlassFish, Geronimo, etc. EJB, JTA, JPA, JAX-WS, and the rest of Java EE come with these app servers and you can plug your program right in without needing a bunch of extra jar files and configuration. I don't understand what is so hard about that. It's so easy and powerful.
And what are you guys talking about, EJB 3.0 is heavyweight? Can you please be more specific. It's based on POJOs like Spring, and uses a container bundled with the app server instead of requiring you add and configure an external container such as Spring.
Well said...
|
|
|
Message #246032
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: KISS
I don't see any value at all to enabling transactions and concurrency by default on a @Singleton, and see several disadvantages.
I think the expert group is still trying to decide weather or not to make singleton Beans transactional by default. You should send the EJB3 JCP an email with your comments on the subject. I have heard the group is very open to suggestions.
I personally find Spring and EJB3 "heavy" to some extent, just in different ways.
Matt,
It's not that big a deal. A lot of them are watching this thread, so it is OK to post comments here.
Reza
|
|
|
Message #246033
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: KISS
I don't see any value at all to enabling transactions and concurrency by default on a @Singleton, and see several disadvantages.
I think the expert group is still trying to decide weather or not to make singleton Beans transactional by default. You should send the EJB3 JCP an email with your comments on the subject. I have heard the group is very open to suggestions.
I personally find Spring and EJB3 "heavy" to some extent, just in different ways.
They are very open to suggestions...
It would be cool if Reza, et al. could post links to their blogs. TSS isn't the best place in the world to get feedback on new features for EJB because of the Spring disruptions.
Bill:
I don't see it as a disruption as such. The constructive comments are worth it, right? Given EJB's past, I think a little hostility is understandable. I think in a way it is a good thing. It might "keep it real" for us on the committee...
Reza
|
|
|
Message #246034
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
There may still some short comings in EJB 3, but so far I can still tolerate them.
Chester,
Mind sharing your thoughts? What would you like to see?
Reza
|
|
|
Message #246035
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: "Your Help is Needed"
What's wrong with the java community? The EC members are asking feedbacks. Make your voice heard and tell them what's wrong with EJB, tell the feature you need being it DI, Interception or aspects!
Everyone those days seem to criticise EJB and the containers, can someone tell me what's a definition of a container? If Spring isn't a container what would it be?
Lightweight VS Heavy? OpenEJB, EasyBeans, Embedded JBoss with tomcat. Plans (after users request) are to make Glassfish, JBoss modular so you "deactivate" (if that's the word) the unneeded feature.
Folks who are deeming EJB to failure are dreaming, attacking the specs (lows) and EG members (leaders) make a good marketing and that's a reason that kept me away from being a Spring enthusiast (and I've used it for real world projects!). It's about ETHIC! I'll *may* change my mind about I21 or SpringSource (and their owners) when they'll change their attitude in the JEE community.
One last question when did Spring adopted annotations and stop being an XMLish crap (what we all hated in struts)? in 2.5 after the EJB3 Big Bang (another marketing argument against EJB.. would you mind?).
JEE folks! Please try to be POSITIF and stop TROLLING over and over misleading the beginners devs that take you for java gods! It's really sucking with those kind of arguing!
PS: Best ever JEE framework? Drop ALL JEE!!
signature
A mad JEE Lover!
Daoud:
Your sentiments are definitely appreciated. Honestly though, I think pretty much anyone in the EJB expert group expects a little hostility, whether deserved or not. We consider it a privilege to be given the opportunity to win people back. Talk about a great technology comeback story!
Bad marketing had a lot to do with the problems with EJB 1.x and 2.x. This time we can really focus on the technology instead...
Reza
|
|
|
Message #246036
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
This simply surreal, how can anybody defend EJBs, a technology that requires a specialized container to make it work! Why would you through so much trouble of configuring and maintaing this type of infrastructure. Spring has proved that it can be done without it. If EJB's to survive, there should be no need for a heavyweight container. Any servlet container should suffice.
Have you really tried EJB3.0?
I used Spring for about 2 years and found it easier and more flexible compared to EJB2.1. However my main concern has been always its verbose configuration which really becomes a nightmare for large scale projects.
Nowadays I'm using EJB3 and really found it more cleaner and easier framework for development compared to Spring. IMHO, JavaEE 5 did a good job in listening to the community and learning from open source (thanks to Spring and Hibernate).
|
|
|
Message #246037
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
Have you really tried EJB3.0?
I think his point is that with "J2EE" you need a container offering a large number of services the majority of which your average application doesn't use or need. He proposes a much simpler setup using servlet container, and indeed this is adequate for the many. There is no "one size fits all" however much the J2EE/EJB crowd want to purvey their environment as being fit for all.
When EJB (4?) grasps this key fact (which it allegedly is going to do) and doesn't require all components/services in a downloadable product (unlike EJB3 which still does impose this) so developers can download and utilise just what they need ... then your beloved EJB will be fit for purpose for the majority.
|
|
|
Message #246039
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
why waste time Rod
ejb has some value but its diminished in last few years .
spring has definitely taken a big share of the ejb market.
ejbs are very complex to develop and maintain. its a bitter truth about ejbs although its still robust from XA etc.
The worst part of this thread is people like bill and rod locking horns on some silly argument. most of the threads on TSS are filled with emotions, frustrations, egoistic comments and some irritating(this thread may be it :) ).
Rod - spring is awesome ! Dont waste time responding to folks who could never achieve the success you have.
they just want to take their frustration out on someone smart like you. just read the headlines on tss and leave it at that. dont read the threads unless you are the author of the article :-).
|
|
|
Message #246040
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring Overtakes EJB as a Skills Requirement
Rod's blog actually surprised me. Given the way I21, Spring zealots, and TSS talk, I thought the numbers would have been *WAY* worse. I actually think his blog was a positive one for EJB.
LOL. I was not surprised by numbers at all given that EJB was very much overused from day one (neearly every project uisng JEE used EJB in the early days). Given that EJB3 has been out for more than two years, how can it be positive for EJB?
|
|
|
Message #246041
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring Overtakes EJB as a Skills Requirement
Randy
Heh...OK, let me get this straight. The president of the company that produces and sells the proprietary Spring product publishes an article on his blog that talks up his product and talks down his competition. Pure marketing....
Ok, I'll bite :-)
My blog was published on the SpringSource web site. I've never made any secret of my affiliation. I believe that you work for a large application server vendor (IBM), which still promotes the use of EJB. While I am not suggesting you make any secret of that, I suspect most readers of this thread were unaware of it, and it would have been wise to make your own affiliation clear before casting aspersions on others.
Second, wrt to my alleged vested interest; I was a long-term critic of EJB before Spring or SpringSource existed. It is a matter of public record that I have been extremely consistent on my views on this matter, regardless of my affiliation at any time.
Second, wrt "proprietary Spring product." Spring is Apache License open source. That is about the most liberal license available. It is simply misleading to call an open source product a "proprietary product." In any case, since you work for a company that produces countless proprietary products, this is clearly a cheap shot. As for "company that produces and sells the proprietary Spring product", again this is pure FUD: Spring is free to use. We do not sell Spring.
Third, with respect to "pure marketing": my post extensively quoted factual information which you and anyone else can verify. Your post merely insulted me without citing any information whatever.
Rgds
Rod
CEO, SpringSource
Founder, Spring Framework
Both of you are unnecessarily harsh and unfair in this thread, though I agree with the point in Rod’s original blog.
I knew Randy is from IBM. He might just forgot to put the famous signature “Work for IBM but not speak for IBM”.
|
|
|
Message #246043
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: "Your Help is Needed"
What's wrong with the java community? The EC members are asking feedbacks. Make your voice heard and tell them what's wrong with EJB, tell the feature you need being it DI, Interception or aspects!
Everyone those days seem to criticise EJB and the containers, can someone tell me what's a definition of a container? If Spring isn't a container what would it be?
Lightweight VS Heavy? OpenEJB, EasyBeans, Embedded JBoss with tomcat. Plans (after users request) are to make Glassfish, JBoss modular so you "deactivate" (if that's the word) the unneeded feature.
Folks who are deeming EJB to failure are dreaming, attacking the specs (lows) and EG members (leaders) make a good marketing and that's a reason that kept me away from being a Spring enthusiast (and I've used it for real world projects!). It's about ETHIC! I'll *may* change my mind about I21 or SpringSource (and their owners) when they'll change their attitude in the JEE community.
One last question when did Spring adopted annotations and stop being an XMLish crap (what we all hated in struts)? in 2.5 after the EJB3 Big Bang (another marketing argument against EJB.. would you mind?).
JEE folks! Please try to be POSITIF and stop TROLLING over and over misleading the beginners devs that take you for java gods! It's really sucking with those kind of arguing!
PS: Best ever JEE framework? Drop ALL JEE!!
signature
A mad JEE Lover!
Daoud:
Your sentiments are definitely appreciated. Honestly though, I think pretty much anyone in the EJB expert group expects a little hostility, whether deserved or not. We consider it a privilege to be given the opportunity to win people back. Talk about a great technology comeback story!
Bad marketing had a lot to do with the problems with EJB 1.x and 2.x. This time we can really focus on the technology instead...
Reza
|
|
|
Message #246045
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: "Your Help is Needed"
The bazaar is EJB cannot re-invent itself as “POJO”. EJB3.1 or EJB4.0 has to be something else such as ABC or XYZ to be successful.
|
|
|
Message #246051
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Dead parrot
Everytime I hear EJB I think of Monty Pythons "Dead Parrot sketch".
We decided to use EJB3 on my current project, two months on, we spent a week refactoring it out, only leaving JPA (which is a subset of Hibernate really) in the mix.
EJB3 was a massive step forward compared to previous incarnations, but it is still weighed down by too much past bagage which creates coding and deployment complexities. That all renders EJB somewhere in between "useless" and "pointless".
Personally, beyond the Servlet spec, there are really only two parts of the JEE spec worth their salt: JPA and JMS, and any three of those can be used individually or altogether without the pain of a full JEE server.
So to summarize EJB:
"'E's not pinin'! 'E's passed on! This parrot is no more! He has ceased to be! 'E's expired and gone to meet 'is maker! 'E's a stiff! Bereft of life, 'e rests in peace! If you hadn't nailed 'im to the perch 'e'd be pushing up the daisies!"
|
|
|
Message #246052
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Keep up the good work!
I really like what's happening with the EJB spec. To me its clear that open source initiatives like Spring et cetera have had their impact as to where the standard is going - and that is a good thing. That's also quite normal when you think of the kind of relative 'greenfield' these initiatives start out with.
Once successful, things are bound to be standardized and that is something we're seeing now (to some degree). POJO driven development is clearly one of the most important factors, along with the Java language maturing that will help getting a JEE platform which could have a bright future.
|
|
|
Message #246059
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
Have you really tried EJB3.0?
I think his point is that with "J2EE" you need a container offering a large number of services the majority of which your average application doesn't use or need. He proposes a much simpler setup using servlet container, and indeed this is adequate for the many. There is no "one size fits all" however much the J2EE/EJB crowd want to purvey their environment as being fit for all.
When EJB (4?) grasps this key fact (which it allegedly is going to do) and doesn't require all components/services in a downloadable product (unlike EJB3 which still does impose this) so developers can download and utilise just what they need ... then your beloved EJB will be fit for purpose for the majority.
Raul:
Actually, you can use EJB 3.0 today in a Servlet container. Check out OpenEJB, EasyBeans and JBoss embedded. In addition, we are working on a lite version of EJB 3.1 that is specifically geared for use in lightweight containers. I'll talk about this in a later article.
Hope this clarifies things.
Reza
|
|
|
Message #246060
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Keep up the good work!
POJO driven development is clearly one of the most important factors, along with the Java language maturing that will help getting a JEE platform which could have a bright future.
We certainly hope so!
|
|
|
Message #246061
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Dead parrot
EJB3 was a massive step forward compared to previous incarnations, but it is still weighed down by too much past bagage which creates coding and deployment complexities.
Your experience honestly seems strange. What container were you using? What time-frame? Was it a beta or Java EE 5 certified?
|
|
|
Message #246062
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
I think that the whole “container” emphasis is very damaging to the brains of many many developers. With all the talk about “Servlet” container “EJB” container we forget that upon close examination we actually need “connectors”. I mean that decent applications usually needs more layers and scopes than it is defined by J2EE spec. My colleagues are shocked when I say that objects in our application need to live in scopes other than request and session - they simply do not get it.
I think that at large we should start to talk more and emphasize more the generic containers like OSGI and lessen emphasis on the Servlet cartridge and Persistence cartridge. No doubts they are important and complex beasts - but they are NOT goals - they are means.
Unfortunate emphasis on the Servlet vs EJB container and such shifts collective focus from seeking solutions to the ‘business’ problems to the seeking solutions for the problems of ‘means’.
|
|
|
Message #246063
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: why waste time Rod
Dont waste time responding to folks who could never achieve the success you have.
they just want to take their frustration out on someone smart like you. just read the headlines on tss and leave it at that. dont read the threads unless you are the author of the article :-).
Frankly, you could use some of your own advice about not polluting a potentially valuable discussion forum with supercilious rants. Rod and Bill have both contributed quite a bit for all of us and are worthy of at least basic courtesy.
|
|
|
Message #246064
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
agenda
These guys from JBoss really like to spread FUD.
If Spring is not open source project, then I don't know which one is. Calling it not based on standard API would be ok, but saying its proprietary, wow dude.
That even beats the old timer when some JBoss guys went to AspectJ training and claimed later how they invented AOP or something.
|
|
|
Message #246066
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The SpringSource Certification Program
I was curious about the recently launched certification program on Spring Framework Professional from SpringSource. I was flabbergasted to read the requirements one has satisfy to be able to take this exam. I quote this directly from their site:
To become a certified Spring Framework Professional, you must successfully complete a certification exam. A person is eligible to take the certification exam if that person has recently attended the Four Day Core Spring course, is a significant contributor within the Spring community ...
Rod Johnson, tell me. Do you think this is the only way one could gain Spring knowledge? Do you believe after that 4 days one can gain sufficient knowledge and experience to pass that exam?
Is this really fair? Is Spring really going proprietary? Assume Sun imposes similar requirements for taking the Java programmer certification. Or IBM imposes such requirements for it's certification. The whole industry would jump on them and bash them.
This is really not fair of SpringSource. It is a shame SpringSource is gradually turning into the dirty and greedy Microsoft we all saw exposed in the 90's. This is pure robbing. It's absurd. It's abuse of power. It's greediness to the power 100.
I know some of you would say the guys have to generate some revenues to survive. I agree but there should be some other way. Sun is also giving Java away for free but doesn't impose such dirty and silly requirements for taking their certifications.
If Spring is going to choose this way, lets all gradually abandon it, after all EJB has gotten amazingly better from 3.0.
I'm starting to hate Spring!!!
Jan
|
|
|
Message #246068
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
There may still some short comings in EJB 3, but so far I can still tolerate them.
Chester,
Mind sharing your thoughts? What would you like to see?
Reza
Reza,
here are few things on my mind,
Disclaimer:
Since I never exactly sure the clear boundaries between EJB3 and JPA, so comments and wish lists are mixed for both EJB 3 and JPA.
Also, If you found something wrong, I would be glad that you point out to me.
The list is a bit long, hope you don't mind.
Chester
1) For EJB 3, I wish there is a startup class that allows me to do application-wide initialization before any Session Bean is used.
Currently, what I do is to make an abstract Base Session Bean and make sure all SessionBean (Stateless) extends from the Base Session Bean. In this abstract base session bean, we use @PostConstruct method to do the initialization. And we carefully make sure the initialization is only done once. Perhaps @Singleton will help here. But I still want start up class so that nothing got initialized before start up class is called.
2) Dealing with Cached Entity Beans.
EntityManager.merge() method acts more like add() instead of merge(). I am not sure this is intension of the spec or due to the specific vendor’s implementation. This is not desirable.
In some cases, we cache the resulting entities from finder method or search. The cached entities, when we ready to use them, has to be “merged” with EntityManager.merge() method to put back to the persistence context in order to use JPA‘s query language.
Since merge() is more like add(), the next JPQL select query may cause entity manager to “persist” an “new entity” in the context. This becomes really problematic under concurrent multi-threaded situation.
So far, we are able to avoid this problem by reducing the use of JPQL and use native query instead. With native query, we don’t need to call merge() method.
But In general, how do one use Cached Entity Bean with Entity Manager ?
3) Entity model doesn’t seem to support certain modeling:
Suppose I have two tables in database:
CREATE TABLE NODE
(
NODE_ID NUMBER(38),
--
CONSTRAINT PK_NODE PRIMARY KEY(NODE_ID)
);
CREATE TABLE SUB_NODE
(
SUB_NODE_ID NUMBER(38),
SUB_NAME VARCHAR(125),
--
CONSTRAINT PK_SUB_NODE PRIMARY KEY(SUB_NODE_ID),
CONSTRAINT FK1_SUB_NODE FOREIGN KEY(SUB_NODE_ID) REFERENCES NODE
);
In this case, table Sub_node is “derived” from table Node: sub_node’s PK is the also FK to Node Table. I would like to model the objects with Node and SubNode objects. When A SubNode is created, Node must be inserted first into NODE table to satisfy the relational constraint;
but I would also be able to create Node Object independently without Sub_node. To do above, I would hope to to do something like this:
@Entity
@Table(name=”NODE”)
class Node {
}
@Entity
@Table(name=”SUB_NODE”)
class SubNode extends Node {
}
But this is not allowed. One can @SuperClass annotation for Node, that would be ok for SubNode object; but it can not create Node object independently.
4) Validation Support
EJB 3.x should enable EntityManager support validation out of box.
For example, we have the following table and entity for Node with node Name column.
@Entity
@Table(name=”NODE”)
class Node {
@Column(name=”node_name”)
private String nodeName;
public String getName() { return this.nodeName; }
}
During the EntityManager.persist() call:
entityManager.persist(new Node(“this is a very long node name”));
EntityManager should automatically validation the name value size and make sure the size is not longer than the column size of the Node table.
This can be easily done by extract Entity’s table name, and get the table’s metadata (column infos) and cached them. Then use reflection or other methods to get String field value and compare the size with cached column size.
We did it use reflection. In this case we have to add additional annotation to make sure we can get the public accessible field value. Something like :
@Column(name=”node_name”)
@FieldMapping(getter = “getName”)
private String nodeName;
@FieldMapping is our own customized annotation.
The validation should not limited to String fields, but also to numbers (MAX VALUE, MIN VALUE),
TIME (BEFORE, AFTER) etc.
Additional annotation or other mechanism would be needed to provide the properties for the fields.
5 EntityManager should add more supports for createNativeQuery.
EnityManager uses createQuery(sql) to create a JPQL Query. The SQL is a JPQL string which allows parameter place holder “?” or named parameter in the format “:<parameter name>”.
Since the JPQL already know the Entity’s class by parsing the JPQL string, the query’s getResultList() or getSingleResult() methods require no class cast.
On the other hand, EntityManager.createNativeQuery(sql, Class) only support “?” and doesn’t support named argument “:<parameter name>”;
and the results from the query in getResultList() and getSingleResult() requires one to do class cast.
List<SubNode> results = (SubNode) query.getResultList();
As result,in every method having such use, we have to add @SuppressWarning("unchecked") annotation.
This is a bit of shame. As one can easily change EntityManager to supports both functions. We actually did on our own.
But I thought EntityManger should support this out of box.
Query<T> q = EntityManager.createNativeQuery(sql, Class<T>);
List<T> results = q.getResultList();
And named arguments can be easily supported as well.
6.Query should be able to access underline meta data of the database, table and column just like what we can do in JDBC. Otherwise, we have to part in JPA query, another part in JDBC.
7.Query should support Map results with column name as the key.
JPA currently supports getResultList() method to return query results. For native query, this requires one to know the position of the each column such as “ select a, b, c from mytable”. But one can not use “Select * from mytable” in native query. As now I would not know if the 1st column is “a” or “b” or “c” anymore.
Map<String, Object> results = Query.getResultMap()
would solve this problem.
8. Query doesn’t support JDBC Batch query. In many cases, batch update/insert is much faster for large amount of insert/update.
This is not the “Batch” in JPQL, which is really simply set operation. I am referring the following:
String sql = "INSERT INTO CUSTOMERS VALUES (?,?,?)";
PreparedStatement stmt = con.prepareStatement(sql);
stmt.setInt(1,1);
stmt.setString(2, "J Smith");
stmt.setString(3, "617 555-1323");
stmt.addBatch( );
stmt.setInt(1,2);
stmt.setString(2, "A Smith");
stmt.setString(3, "617 555-1132");
stmt.addBatch( );
int[] upCounts = stmt.executeBatch( );
con.commit( );
|
|
|
Message #246067
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: agenda
These guys from JBoss really like to spread FUD.
If Spring is not open source project, then I don't know which one is. Calling it not based on standard API would be ok, but saying its proprietary, wow dude.
That even beats the old timer when some JBoss guys went to AspectJ training and claimed later how they invented AOP or something.
Afu:
I think we should all be holding ourselves to a higher standard of discussion here. Mutual respect never hurts. Bill's comments were albeit needlessly harsh, but not completely off-base.
Here is a definition for the word "proprietary":
The word "proprietary" indicates that a party exercises control over an item, usually to the exclusion of other parties. . In other words, "proprietary" != "closed source".
I think it is a perfectly valid observation to say that the Spring framework is currently controlled by a very small group of people with vested financial interests and things are likely to stay that way in the foreseeable future. Have you ever tried to fork a non-trivial open source project? It is more or less an impractical proposition. Things have gone so far as to implicitly express this control in terms of the very name of a commercial organization.
I am glad you've at least observed that open source != standard. I think that much is obvious.
Reza
|
|
|
Message #246069
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The SpringSource Certification Program
I was curious about the recently launched certification program on Spring Framework Professional from SpringSource. I was flabbergasted to read the requirements one has satisfy to be able to take this exam. I quote this directly from their site:
To become a certified Spring Framework Professional, you must successfully complete a certification exam. A person is eligible to take the certification exam if that person has recently attended the Four Day Core Spring course, is a significant contributor within the Spring community ...
Rod Johnson, tell me. Do you think this is the only way one could gain Spring knowledge? Do you believe after that 4 days one can gain sufficient knowledge and experience to pass that exam?
Is this really fair? Is Spring really going proprietary? Assume Sun imposes similar requirements for taking the Java programmer certification. Or IBM imposes such requirements for it's certification. The whole industry would jump on them and bash them.
This is really not fair of SpringSource. It is a shame SpringSource is gradually turning into the dirty and greedy Microsoft we all saw exposed in the 90's. This is pure robbing. It's absurd. It's abuse of power. It's greediness to the power 100.
I know some of you would say the guys have to generate some revenues to survive. I agree but there should be some other way. Sun is also giving Java away for free but doesn't impose such dirty and silly requirements for taking their certifications.
If Spring is going to choose this way, lets all gradually abandon it, after all EJB has gotten amazingly better from 3.0.
I'm starting to hate Spring!!!
Jan
Jan:
While I agree with a lot of your observations, can I earnestly beg you to take this discussion to a Spring forum instead?
I put a lot of hard work to try to put together this article (all my personal time since I work for a small/local Philly consulting company). It really hurts to see this get horribly derailed from its original intent and turn into a flame-fest instead of discussion about the article.
Thanks,
Reza
|
|
|
Message #246070
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The SpringSource Certification Program
First, I agree with Reza that this is not a thread about Spring. Please note that I only posted here to respond to an attack which I did not think should be left unanswered.
Is Spring really going proprietary?
No.
Assume Sun imposes similar requirements for taking the Java programmer certification. Or IBM imposes such requirements for it's certification. The whole industry would jump on them and bash them. This is really not fair of SpringSource. It is a shame SpringSource is gradually turning into the dirty and greedy Microsoft we all saw exposed in the 90's. This is pure robbing. It's absurd. It's abuse of power. It's greediness to the power 100.
Jan, this is a gross overreaction. Furthermore, you are of course free not to take the SpringSource Certification, in just the same way as you are free to continue to use Spring without paying anything--which is obviously not true with IBM or Microsoft.
Requiring completion of a training course is not an unusual requirement. Consider, for example, BEA requirements for many certifications. Or Red Hat certification information.
In fact, I believe it's rather unusual--and in the spirit of open source--for us to provide the "grandfathering" provision, which exempts candidates for the exam from completing a training course. Please read it. Why would you not take this up, if you feel you have made a sufficient contribution?
Our goal is to provide a certification which provides a strong endorsement of the necessary skill level. We have seen a very positive reaction to our announcement in the Spring community.
The discussion in this thread should be about EJB 3.1... I have no wish to hijack it. If people would stop making inaccurate statements about Spring and SpringSource, I would be very happy to bow out, unless I want to say something about EJB 3.1.
Rgds
Rod
|
|
|
Message #246071
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The SpringSource Certification Program
Reza
I put a lot of hard work to try to put together this article (all my personal time since I work for a small/local Philly consulting company). It really hurts to see this get horribly derailed from its original intent and turn into a flame-fest instead of discussion about the article.
Yes, I know you did and I think you did a good job on the article. Such discussion around JSRs is healthy and I applaud you for initiating it.
Rgds
Rod
|
|
|
Message #246072
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
Chester
1) For EJB 3, I wish there is a startup class that allows me to do application-wide initialization before any Session Bean is used.
I agree. This is a very important point and I hope it's addressed in future versions of the spec.
Your other points all concern JPA, which is now a separate specification. I suppose you should send them to that expert group's email alias...
Rgds
Rod
|
|
|
Message #246073
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Spring with Annotations
We ported 75% of project written in ejb to light weight programming using spring. We are planning to convert the remaining ejb project after 2 months.
Is ejb still necessary in this day and age?
Yes, I actually like EJB 3. In comparison, I would prefer not to use Spring, even though it is one of most popular framework. I like what spring can do and its concept. But I don't like to program in XML. Spring turns java programming into XML configuration (or programming depending how do you look at it), which turns me off. I have followed Spring from very beginning, even before the Spring becomes the spring, read Rod Johson's 1st book several times and incorporate the JDBC template into one of the project (before Spring becomes a project). Not so closely recently. I think Spring can use Annotation instead of XML now, but I rather use EJB 3 and JPA.
Our old project is EJB 2.x and our new project is EJB 3 with JDK 1.6. I like it a lot. In case we need AOP, I just directly programming in AspectJ, which is pretty easy to do (except Intellij doesn't like it).
There may still some short comings in EJB 3, but so far I can still tolerate them. I might change my positions, but this is my current state of the mind.
Chester
The current Spring Version supports Annotations and I believe there is a book that focuses on how to use Annotations to configure a Spring App instead of using a lot of XML.
http://blog.interface21.com/main/2007/05/14/annotation-driven-dependency-injection-in-spring-21/
I have not used the latest EJB 3.0 Spec and therefore can't really bash it but I have been working with Spring for a while and enjoy using it way more then I enjoy doing the old EJB 2.1 using heavy tools like WSAD and Websphere at my old company.
You say you like working with JPA and again the latest Spring version allows you to make working with JPA even better.
http://dev2dev.bea.com/pub/a/2006/03/jpa-spring-medrec.html
Hope that helps Chester.
-Andrew
P.S. I do not work for SpringSource. :-)
|
|
|
Message #246074
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
Have you really tried EJB3.0?
I think his point is that with "J2EE" you need a container offering a large number of services the majority of which your average application doesn't use or need. He proposes a much simpler setup using servlet container, and indeed this is adequate for the many. There is no "one size fits all" however much the J2EE/EJB crowd want to purvey their environment as being fit for all.
When EJB (4?) grasps this key fact (which it allegedly is going to do) and doesn't require all components/services in a downloadable product (unlike EJB3 which still does impose this) so developers can download and utilise just what they need ... then your beloved EJB will be fit for purpose for the majority.
And my point is ease of use of EJB3 compared to Spring. If this ease of use requires downloading and installing a free, open source app server like JBoss, Glassfish, Geronimo, OpenEJB and... I don't mind doing so.
BTW, as you might have heard, nowadays there are embed-able ejb containers that you can run inside your servlet container, if you wish so.
|
|
|
Message #246079
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
There may still some short comings in EJB 3, but so far I can still tolerate them.
Chester,
Mind sharing your thoughts? What would you like to see?
Reza
Reza,
here are few things on my mind,
Disclaimer:
Since I never exactly sure the clear boundaries between EJB3 and JPA, so comments and wish lists are mixed for both EJB 3 and JPA.
Also, If you found something wrong, I would be glad that you point out to me.
The list is a bit long, hope you don't mind.
Chester
1) For EJB 3, I wish there is a startup class that allows me to do application-wide initialization before any Session Bean is used.
Currently, what I do is to make an abstract Base Session Bean and make sure all SessionBean (Stateless) extends from the Base Session Bean. In this abstract base session bean, we use @PostConstruct method to do the initialization. And we carefully make sure the initialization is only done once. Perhaps @Singleton will help here. But I still want start up class so that nothing got initialized before start up class is called.
Chester,
Instead of creating an abstract session bean and extending it, couldn't you use default interceptors?
|
|
|
Message #246083
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Dead parrot
Your experience honestly seems strange. What container were you using? What time-frame? Was it a beta or Java EE 5 certified?
JBoss 4.0.5 patched for EJB3 (we used stateless session beans and JPA). We used it from November up until around last week.
EJB3 pulls a lot of trick on you (some JBoss related):
- Having to manage deployment into EJB container AND servlet container - adds a great deal of configuration and deployment complexity.
- Characteristic of two containers: having to bend over backwards to share objects and dependencies without throwing in the kitchen sink.
- The EJB container more or less swallowing and obfuscating issues, so it is hard to know whether it is deployment, configuration or code that is the problem (no doubt a JBoss issue).
..the list goes on.
The fact is, as long as you need to deploy EJB's in a separate container even for the simplest of use cases to access the services it will always be a pain and add more headaches than it solves.
|
|
|
Message #246084
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring Overtakes EJB as a Skills Requirement
I don't believe that EJB has a future, if they keep the name EJB.
See also Spring Overtakes EJB as a Skills Requirement.
Hm, interesting. And are you sure that only a small minority of the Spring users are using EJB as a sideline? I'll not be to fast on that. In a lot of projects where I saw Spring used, it is just added to the software stack. However, that mastering an (excellent) configuration framework becomes a prime job requirement leaves me somewhat astonished.
In about the same number of projects, everything is done with spring (would you actually consider it wise to use spring as a factory of good old DAOS??) creating massive XML repositories that are by no means easier to manage than good old EJB 2.1 configurations.
Really, given EJB3, spring is obsolete as an end user framework. You might of course argue that EJB did nothing but copy a lot of concepts already in spring (and elsewhere) and you probably right. Still there is zero need to use two frameworks if one suffices. Entropy kills codebases faster than anything else.
|
|
|
Message #246085
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
It's indeed very nice to see the ejb spec leaders are willing to listen from the community.
And it's really very painful to see the spring folks are disrupting the entire thread.
If you just analyze every single reply in this thread, almost 80% of the replies were comparing spring and ejb.
Yes, it's true that ejb was over engineered and was very complex to use. But one needs to really admire the effort put by the spec leaders to give a much better solution in ejb 3.0. We use ejb 3.0 in some of our projects and we are pretty much satisfied with it.
Let spring be the best framework out there. But what prevents you all from providing suggestions to improve the ejb spec? So it really looks like, most of you don't want the ejb spec to improve. Or on the other hand, looks like you don't like competition.
Like many web frameworks ranging from JSF, Wicket, GWT etc.. why not there be many application frameworks?
Or why not try to make spring a "Java EE" standard like seam is doing with "web beans" JSR?
It would be very interesting if the guys who thump "spring is the best" can list down the features which spring has now which has no equivalent in ejb. That would be very helpful for the spec leaders to collect much more valuable information.
And i personally feel that ejb is going in the right direction. And any product/project which listens to the community has been successful.
Keep up the good work ejb team.
And it's really heartening to see Reza responding to most of the replies. And i would like to add some suggestions on my behalf.
(Though it may look non-trivial) I still find the JNDI lookups (especially for remote ejbs) still a bit complex.
And i would like to see the ejbs running in servlet containers (as proposed in the ejb 3.1 spec)
|
|
|
Message #246086
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
And one more thing....
(please correct me if i'm wrong)
Since ejb uses RMI-IIOP underhood, there is no way (atleast to me!!) to define the ports used for communication.
I would like to see something like:
lookup "MySessionBean" which is deployed on "ServerName:port number", from this "local port".
Also i would like to know, if there is a way to have "secure" lookups, say, using ssh or similar techonologies?
|
|
|
Message #246087
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
If EJB3 is no longer EJB (i.e. EJB 1 & 2), why are you insisting calling it EJB?
Will the Java community be better served if the baggage of EJB 2.1 is thrown out of the window? When that happens, I don't think there can be disruption/distraction from Spring any more.
And Spring couldn't have become so popular and widely used without (the help of) EJB 1 & 2. Just look at .NET people.
Let's put another nail on the coffin.
|
|
|
Message #246088
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
My 2 cents.
1. I think the singleton attribute should really be the default behavior for stateless session beans.
In 90% of the cases, they should be considered as "Classes with static methods that use transactions".
Sorry for over-simplifying, but thats the reality, :)
An alternative would be to offer transaction attribute support for Servlets or any classes representing some kind of facade, :)
2. Pluggable injection support (for any kind of class) is a real plus.
3. (out of scope but heck, lets use the chance) Criteria API for JPA will be cool.
4. An out of the box generic DAO implementation for JPA will be nice.
5. Explicit support for entity instance based security is required (which user can update what entity)
5. Caching/Data refresh annotations for business logic methods (like in Spring).
|
|
|
Message #246089
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Dead parrot
Your experience honestly seems strange. What container were you using? What time-frame? Was it a beta or Java EE 5 certified?
JBoss 4.0.5 patched for EJB3 (we used stateless session beans and JPA). We used it from November up until around last week.
EJB3 pulls a lot of trick on you (some JBoss related):
- Having to manage deployment into EJB container AND servlet container - adds a great deal of configuration and deployment complexity.
- Characteristic of two containers: having to bend over backwards to share objects and dependencies without throwing in the kitchen sink.
- The EJB container more or less swallowing and obfuscating issues, so it is hard to know whether it is deployment, configuration or code that is the problem (no doubt a JBoss issue).
..the list goes on.
The fact is, as long as you need to deploy EJB's in a separate container even for the simplest of use cases to access the services it will always be a pain and add more headaches than it solves.
This is why I keep saying the whole effort of EJB is a waste of time at this point. 3.1 or whatever comes after it.
On the surface the embeddable EJB container like a good solution but in real life it will still require a lot of configurations and tinkering. What is worse form a marketing perspective is the EJB LIGHT solution which Reza is talking about. It almost sounds like Vista Ultimate and Vista Enterprise!
|
|
|
Message #246090
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The SpringSource Certification Program
<blockquoteYes, I know you did and I think you did a good job on the article. Such discussion around JSRs is healthy and I applaud you for initiating it.>
Rod:
Thanks for the kind words. I'm trying to do my best (as is the rest of the expert group) to make EJB all that it could and should be.
In fact, I would urge you to send your comments to the JSR if time permits. Although there is a lot of information out there, it is often outdated, full of hyperbole or comments on Java EE instead of EJB...
Reza
|
|
|
Message #246091
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Embeddable Containers are very desirable
I would aprechiate if any container was embeddable, especially for automated testing it's very useful and during deployment it shortens deployment cycle a lot.
|
|
|
Message #246093
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
Chester
1) For EJB 3, I wish there is a startup class that allows me to do application-wide initialization before any Session Bean is used.
I agree. This is a very important point and I hope it's addressed in future versions of the spec.
Your other points all concern JPA, which is now a separate specification. I suppose you should send them to that expert group's email alias...
Rgds
Rod
Although I didn't dive into the details of it in the article, this is actually one of the intended uses for Singleton Beans. You can mark methods on Singetons with @Startup and @Shutdown. These methods will be called when the container starts-up and shuts-down respectively.
Is this what you were looking for?
Reza
|
|
|
Message #246094
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Dead parrot
The fact is, as long as you need to deploy EJB's in a separate container even for the simplest of use cases to access the services it will always be a pain and add more headaches than it solves.
Willie:
Two comments here -
1. Try the code examples for EJB 3 in Action on JBoss. It was honestly a breeze to write and deploy apps. A number of our own customers who use JBoss AS can independently comment on this.
2. As mentioned in the article, one of the changes in EJB 3.1 is support for deploying directly to a Servlet container without a separate JAR (which is I'm guessing what you are referring to as "separate container"). FYI, OpenEJB will let you do this today. In fact, the OpenEJB folks were helpful in putting together this proposed change.
Hope this helps,
Reza
|
|
|
Message #246095
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
George:
If EJB3 is no longer EJB (i.e. EJB 1 & 2), why are you insisting calling it EJB?
While the look, feel and implementation of EJB has changed drastically, EJB still remains what it started out as - a middleware platform for developing application components. That's why it's a cheap marketing gimmick to rename it. Can you understand why this might be distasteful to a bunch of mostly engineers sitting on a technical committee? It's also disrespectful to all the early EJB adopters who have stuck by it through good times and bad.
Will the Java community be better served if the baggage of EJB 2.1 is thrown out of the window?
Could you kindly specify what features you are talking about?
Thanks,
Reza
|
|
|
Message #246096
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Dead parrot
Moh:
On the surface the embeddable EJB container like a good solution but in real life it will still require a lot of configurations and tinkering.
Not quite. Give OpenEJB a try. One could argue it is easier to configure than Spring.
The point in working towards EJB is that a lot of us have observed that it has a number of good fundamental ideas (as someone already alluded, some of these ideas have been adopted by Spring). Not to mention many EJB 3 customers will attest to the fact that it does make server-side component development due to heavy defaulting, minimal configuration and annotations adoption.
Reza
|
|
|
Message #246097
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
Although I didn't dive into the details of it in the article, this is actually one of the intended uses for Singleton Beans. You can mark methods on Singetons with @Startup and @Shutdown. These methods will be called when the container starts-up and shuts-down respectively.
Is this what you were looking for?
Reza
Why not just add a well-known @Observes event for startup and shutdown, like javax.ejb.StartupEvent and javax.ejb.ShutdownEvent?
|
|
|
Message #246098
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Embeddable Containers are very desirable
I would aprechiate if any container was embeddable, especially for automated testing it's very useful and during deployment it shortens deployment cycle a lot.
Peter:
Give OpenEJB, EasyBeans and Embedded JBoss a spin. A lot of folks really like these solutions.
Reza
|
|
|
Message #246100
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
Why not just add a well-known @Observes event for startup and shutdown, like javax.ejb.StartupEvent and javax.ejb.ShutdownEvent?
Scott:
Can you kindly elaborate on this?
Thanks,
Reza
|
|
|
Message #246101
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Event handling
Why not just add a well-known @Observes event for startup and shutdown, like javax.ejb.StartupEvent and javax.ejb.ShutdownEvent?
Scott:
Can you kindly elaborate on this?
Thanks,
Reza
Startup and Shutdown are really system-wide events, so they should be handled like events.
The WebBeans API has a very nice general event-handling system based on an @Observes parameter annotation. To listen for a StartupEvent, you'd write:
import javax.ejb.*;
import javax.webbeans.*;
@Singleton
public class MySingleton {
public void startup(@Observes StartupEvent event)
{
...
}
public void shutdown(@Observes ShutdownEvent event)
{
..
}
}
The beauty of that system is that its totally general, simple, and type-safe (in the sense of only sending events to receivers that understand StartupEvent.)
Plus, you could theoretically add data to the StartupEvent (I don't think I'd recommend doing that in the spec, though.)
So instead of creating a aspect with @Startup or @Shutdown, you would just be creating a new Event class, i.e. it would be a simpler solution (since aspects are intrinsically more complicated than event classes.)
|
|
|
Message #246102
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring Overtakes EJB as a Skills Requirement
Really, given EJB3, spring is obsolete as an end user framework.
[scratch head] Really? Where in EJB is IoC? Not just for persistance. Where is Remoting? Web Flow? Batch? Spring .Net? etc.
Or do you just mean Spring FrameWork?
To be honest, I have never used Spring with EJBs (1-3). But it has still been very valuable.
|
|
|
Message #246106
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Positif
Or why not try to make spring a "Java EE" standard like seam is doing with "web beans" JSR?
It would be very interesting if the guys who thump "spring is the best" can list down the features which spring has now which has no equivalent in ejb. That would be very helpful for the spec leaders to collect much more valuable information.
Well said! that was my point about being positif in the community. :)
Best Regards
Daoud AbdelMonem Faleh
|
|
|
Message #246107
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Positif
Or why not try to make spring a "Java EE" standard like seam is doing with "web beans" JSR?
It would be very interesting if the guys who thump "spring is the best" can list down the features which spring has now which has no equivalent in ejb. That would be very helpful for the spec leaders to collect much more valuable information.
Well said! that was my point about being positif in the community. :)
Best Regards
Daoud AbdelMonem Faleh
Unfortunately, Rod would never do this. He's too interested in protecting his little fiefdom than doing anything truly beneficial to the EE community. Here's why I think this a bad move.
|
|
|
Message #246108
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring Overtakes EJB as a Skills Requirement
On a related note, my EJB 3.0 book is also selling very well. About 1700 copies last quarter and its been out since May 2006.
So, EJB's demise is greatly exaggerated it seems...
I'm happy to say we are seeing similar success with EJB 3 in Action despite many doubters.
Amazon Java bestseller list
BTW: Yesterday "Enterprise JavaBeans 3.0" was on position 40 something!? We should have more book reviews on TSS!!!
|
|
|
Message #246109
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Embeddable Containers are very desirable
I would aprechiate if any container was embeddable, especially for automated testing it's very useful and during deployment it shortens deployment cycle a lot.
JBoss has an embedded EJB3 container which we used on my project for unit-testing. Unfortunately, it was pretty much useless: hard to configure (harder than a standalone container), swallowed Exceptions completely, and wasn't particularly friendly to integrate into a maven build.
|
|
|
Message #246110
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Dead parrot
Not quite. Give OpenEJB a try. One could argue it is easier to configure than Spring.
If that is really true, I'd be prepared to try it out. As I mentioned in another comment, we tried using Embedded JBoss for unit-testing, but it ended up almost being a bigger pain than the actual "real" JBoss server.
|
|
|
Message #246111
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Embeddable Containers are very desirable
I would aprechiate if any container was embeddable, especially for automated testing it's very useful and during deployment it shortens deployment cycle a lot.
JBoss has an embedded EJB3 container which we used on my project for unit-testing. Unfortunately, it was pretty much useless: hard to configure (harder than a standalone container), swallowed Exceptions completely, and wasn't particularly friendly to integrate into a maven build.
Was it the old Embeddable EJB3 container? Or the newer Embeddable JBoss one? Please email me your problems. I'm sure you can find my address...
Bill
|
|
|
Message #246112
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Positif
Or why not try to make spring a "Java EE" standard like seam is doing with "web beans" JSR?
It would be very interesting if the guys who thump "spring is the best" can list down the features which spring has now which has no equivalent in ejb. That would be very helpful for the spec leaders to collect much more valuable information.
Well said! that was my point about being positif in the community. :)
Best Regards
Daoud AbdelMonem Faleh
Unfortunately, Rod would never do this. He's too interested in protecting his little fiefdom than doing anything truly beneficial to the EE community. Here's why I think this a bad move.
Bill,
Your article was quite informative.
So, is IoC is what we need to take from spring and standardize in ejb 3.1?
|
|
|
Message #246118
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring Overtakes EJB as a Skills Requirement
....Or do you think that the job trends don't matter?...
Job trends ?
Hmm, in my (very little) experience tons of developers simply jump on the next bandwagon.
Following pseudo-technicians (see http://www.cs.wustl.edu/~schmidt/editorial-5.html for a description of who I'm talking about) guidelines built with googled buzzword put in a blender.
Those who think a little different (see http://zeroc.com/newsletter/issue22.pdf editorial) are normally flamed because they have always said (since the beginning) that EJB 1-2 were totally crazy (don't know about 3, but I really don't care, I am tired and getting old) and SOAP is an unuseful (and stupid) step backward.
IMHO.
Guido
|
|
|
Message #246117
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The SpringSource Certification Program
Requiring completion of a training course is not an unusual requirement. Consider, for example, BEA requirements for many certifications. Or Red Hat certification information.
In fact, I believe it's rather unusual--and in the spirit of open source--for us to provide the "grandfathering" provision, which exempts candidates for the exam from completing a training course. Please read it. Why would you not take this up, if you feel you have made a sufficient contribution
Rod
Not that I really care. But you guys wrote books about your stuff, and now you are actually telling people reading the book(s) is not sufficient to take up the certification, but taking a four day training course is?
At least the Sun people are decent enough to acknowledge that reading the spec and working through their how-tos is sufficient to gain the necessary knowledge to sit the test.
|
|
|
Message #246119
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: KISS
encourage heavyweight use
Heavyweight is an abstract term. Can you describe what heavyweight specifically means to you.
Whatever requires more than the necessary to accomplish a certain job (assuming that some job is even accomplished, but should not be taken for granted).
Guido
|
|
|
Message #246153
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The New Features in EJB 3.1
Chester,
Instead of creating an abstract session bean and extending it, couldn't you use default interceptors?
That probably is another way doing this. I haven't thought of that.
But both ways are not ideal, as it would be invoked when first used and invoked multiple times unnecessarily.
Chester
|
|
|
Message #246154
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Embeddable Containers are very desirable
JBoss has an embedded EJB3 container which we used on my project for unit-testing. Unfortunately, it was pretty much useless: hard to configure (harder than a standalone container), swallowed Exceptions completely, and wasn't particularly friendly to integrate into a maven build.
Was it the old Embeddable EJB3 container? Or the newer Embeddable JBoss one? Please email me your problems. I'm sure you can find my address...
Bill
It was embedded Jboss as found here: http://wiki.jboss.org/wiki/Wiki.jsp?page=EmbeddedJBoss
The problems where primarily three-fold:
- Configuration and documentation: I could not much documentation, but eventually got it running semi-smoothly by copy-pasting the the conf, log, deploy directories from some sample embedded apps I found. I realize that configuring embedded JBoss is very close to configuring full JBoss, but nonetheless some clearer documentation and smoother running out of the box would be nice.
- Classpath issues when integrating into Maven: worked fine in Eclipse, but running embedded JBoss from a Maven2 script for normal unit-tests was a carwreck: EJB classes could not be found and a bunch of other issues that ended up being more of a pain to resolve than just work around.
- Deployment issues got very obfuscated, for instance an Entity might be invalidly mapped or something along those lines, but from the trace it was not immediately apparent that this was the case. Better, more detailed error messages would be helpful.
it's been a while now, so I don't remember more in detail than that: at the moment we just deploy WAR files into JBoss and use JPA (with Hibernate as the provider) for the persistence, with an Open Session In View pattern implemented with Wickets RequestCycle for the transaction management (which is actually quite a nice little setup).
I think Embedded JBoss and embedded EJB servers are a wonderful idea, and potentially the thing that can save EJB from complete irrelevance (EJB3 has a lot of nice ideas, but is still dragged down by the bagage of history), but unfortunately, we were not too happy with what we got out of it at the time.
Maybe I'll reevaluate my stance once things are more straightforward and robust.
|
|
|
Message #246173
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The SpringSource Certification Program
"While I agree with a lot of your observations, can I earnestly beg you to take this discussion to a Spring forum instead?
I put a lot of hard work to try to put together this article (all my personal time since I work for a small/local Philly consulting company). It really hurts to see this get horribly derailed from its original intent and turn into a flame-fest instead of discussion about the article."
Great point.
It turned into a flame fest because Rod Johnson had to post his blog about how Spring is taking over EJB. He also generically says "EJB" rather than drawing the distinction between EJB 2.x and EBJ 3.0 (deliberately confusing people so that they still associate the complexity and heaviness of the 2.1 version with 3.0 version, which is in fact much easier and lighter).
This kind of behavior from Rod Johnson indicates that he is worried that, if people take a serious look at EJB 3.0 and JPA, the need or desire from them to use Spring becomes much less. Spring became hugely popular because of the huge complexity and heaviness of EJB 2.x. But EJB 3.0 makes Spring not as desirable or relevant. Thus, in a forum that's simply about new EJB 3.1 features and soliciting feedback, Rod feels the need to post his standard "EJB sucks and Spring is the only way to go" stance, and shamelessly plug his own framework, and get people diverted away from a constructive discussion about improving EJB 3.x and get into a yet another useless "Spring vs JEE" flame fest.
Based on this kind of behavior, I'm much less inclined to use Spring.
But on a technical note, EJB 3.0 makes me less inclined to use Spring. EJB 3.0 is a fantastic spec, and is a huge improvement over 2.1. It fully embraces the POJO model, and makes wiring services simple via annotations, and greatly reduces XML configuration hell (a bane to the existence of every Java Enterprise developer, including Spring developers - heck especially Spring developers).
As far as feedback - the ability to run regular session or message driven beans outside the container, so that they can be tested (or unit-tested) without firing up the big container, would be awesome. You can already do that with Entity beans (JPA). But to be able to do it with the others would be great.
|
|
|
Message #246174
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Embeddable Containers are very desirable
Configuration and documentation: I could not much documentation, but eventually got it running semi-smoothly by copy-pasting the the conf, log, deploy directories from some sample embedded apps I found. I realize that configuring embedded JBoss is very close to configuring full JBoss, but nonetheless some clearer documentation and smoother running out of the box would be nice.
Apologies. I thought I made that clear in the doco, that goal was to have exact configuration steps as the app server. To be consistent with config between app server and embedded.
Classpath issues when integrating into Maven: worked fine in Eclipse, but running embedded JBoss from a Maven2 script for normal unit-tests was a carwreck: EJB classes could not be found and a bunch of other issues that ended up being more of a pain to resolve than just work around.
I found that Maven doesn't set java.class.path properly. Was this the problem?
Deployment issues got very obfuscated, for instance an Entity might be invalidly mapped or something along those lines, but from the trace it was not immediately apparent that this was the case. Better, more detailed error messages would be helpful.
Only excuse I have is the immaturity of the JBoss 5 kernel at the time. We're getting there, things just take time. The goal is to be able to morph JBoss to the environment you want to run it within. As we move things to the JBoss 5 architecture things *should* get smaller, faster, easier.
|
|
|
Message #246176
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Give Credit Where It is Due
All these flames are missing the point...and that is the progress that has been made in enterprise Java. It took Spring to really shake things up enough for those responsible for EJB to really gut the spec and come up with something new. I haven't really used EJB 3.0 yet (we run WebSphere here...), but it is an entirely different beast than the old EJB, in a good way. The spec has really leveraged annotations in Java 5 to the hilt and come up with something fairly lightweight and POJO-based. Criticizing the spec based on bad experiences with the older EJB is just wrong.
Spring is a great framework (what the original EJB should have been), but it is also not without its faults. I'll echo (Crazy) Bob Lee's comments here that typing in Java class names into an XML file is a step backward. Hopefully the newer 2.5+ versions of Spring address some of these weaknesses.
What I'd like to see...:
1) You shouldn't have to run in an application server to use EJB. One of the nice things about Spring is that it has always been environment-agnostic. (Is this the EJB "Lite" Reza was referring to?)
2) The multiple @ConcurrencyXXX annotations are a mistake, as is the suggestion to break up @TransactionAttribute. One annotation with multiple properties will suffice. Annotations are nice, but too many of them on a given element reduces readability.
|
|
|
Message #246175
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The SpringSource Certification Program
He also generically says "EJB" rather than drawing the distinction between EJB 2.x and EBJ 3.0 (deliberately confusing people so that they still associate the complexity and heaviness of the 2.1 version with 3.0 version, which is in fact much easier and lighter).
So, wouldn't it be better to rename it?
|
|
|
Message #246181
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The SpringSource Certification Program
Jeff
It turned into a flame fest because Rod Johnson had to post his blog about how Spring is taking over EJB.
Please read the thread. I did not post that link. It was posted by someone without any connection to Spring. I merely posted in this thread to counter a specific attack.
Rgds
Rod
|
|
|
Message #246185
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The SpringSource Certification Program
Jeff
It turned into a flame fest because Rod Johnson had to post his blog about how Spring is taking over EJB.
Please read the thread. I did not post that link. It was posted by someone without any connection to Spring. I merely posted in this thread to counter a specific attack.
Rgds
Rod
I did post that link and I have no connections to Spring.
|
|
|
Message #246186
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Give Credit Where It is Due
2) The multiple @ConcurrencyXXX annotations are a mistake, as is the suggestion to break up @TransactionAttribute. One annotation with multiple properties will suffice. Annotations are nice, but too many of them on a given element reduces readability.
Well, I guess only one of the multiple transaction annotations would be used on a given element.
However, I would have thought that breaking up @TransactionAttribute doesn't make sense as EJB 3.0 already defines it, and it doesn't make sense to chop and change in successive versions of the spec.
|
|
|
Message #246206
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Give Credit Where It is Due
1) You shouldn't have to run in an application server to use EJB. One of the nice things about Spring is that it has always been environment-agnostic. (Is this the EJB "Lite" Reza was referring to?)
As to the discussion so far, yes...I'll try to get more details on it soon since there is so much interest on it...
Reza
|
|
|
Message #246207
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The SpringSource Certification Program
"So, wouldn't it be better to rename it? "
Yes.
I think it should be renamed to something like "JEE POJO Beans", something else along those lines. There is a lot of negative baggage attached to the name "EJB" (and deservedly so).
|
|
|
Message #246208
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Give Credit Where It is Due
However, I would have thought that breaking up @TransactionAttribute doesn't make sense as EJB 3.0 already defines it, and it doesn't make sense to chop and change in successive versions of the spec.
I think there is enough emphasis on this for me to try to follow this up on the committee. This was my own gut reaction too...
Reza
|
|
|
Message #246213
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Give Credit Where It is Due
makes wiring services simple via annotations, and greatly reduces XML configuration hell (a bane to the existence of every Java Enterprise developer, including Spring developers - heck especially Spring developers).
I'll echo (Crazy) Bob Lee's comments here that typing in Java class names into an XML file is a step backward. Hopefully the newer 2.5+ versions of Spring address some of these weaknesses.
Indeed, you really need to check out Spring 2.5! You'll be surprised. A Spring/EJB3 discussion based on Spring 2.0 (like in this thread) is effectively outdated. We go pretty far with our annotation-based support options in 2.5... certainly beyond what you would expect.
You may for example use XML bean definitions that consist of nothing more than id/class pairs, with everything else expressed in annotations. Or you'll avoid XML bean definitions completely, autodetecting components in the classpath based on stereotype annotations.
If you prefer to have it that way, your XML application context will merely define core resources, instructions on where to find components in the classpath, as well as some policies. Pretty similar to JPA's persistence.xml when using JPA entity detection in the classpath.
For an overview, check out Rod's introduction to Spring 2.5 on TSS, in particular the section "Beyond XML" with its coverage of @Autowired and <context:component-scan>:
http://www.theserverside.com/tt/articles/article.tss?l=IntrotoSpring25
For a comprehensive overview of Spring-supported dependency injection annotations, including common Java EE 5 annotations and Spring's JMX annotations, see my recent blog post:
http://blog.springsource.com/main/2008/01/28/spring-25s-comprehensive-annotation-support/
Juergen
|
|
|
Message #246210
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Benz Town Citizen
"I did post that link and I have no connections to Spring."
I stand corrected and my apologies go to Rod Johnson.
And I can't blame Rod Johnson for promoting Spring in his own blog, and saying it's taking over EJB in the job market.
But I disagree with Rod's stance somewhat. What I think is happening is that people are increasingly leaving behind the old EJB 2.x model, and moving more towards POJO frameworks in general, including Spring, EJB3.0/JPA, Hibernate, iBatis, Toplink, and so on. Spring is certainly increasing in popularity, but EJB, thanks to 3.0 and JPA, still remains relevant (and desirable to use, I think).
I also think that Spring benefited immensely from the extreme heaviness and complexity (and overselling) of EJB 2.x. Now that EJB 3.0 fully embraced a more lightweight POJO model, Spring desirability goes down somewhat (people don't have to escape the "complex beast" into the "Spring sanctuary" anymore).
One things for sure, the existence of Spring sure shook up the Java enterprise world, and caused the committee to wake and smell the coffee, and come up with something better than the 2.x abomination. That is a very good thing indeed.
That said, Benz Town Citizen, you should not have posted Rod's blog. It was not relevant to the thread.
And I reacted to it because all the Spring vs EJB (whether 2.x or 3.0) grows very tiresome. And Spring supporters making proclamations stating that "JEE is dead and Spring has won" (or something along those lines) grows tiresome as well.
|
|
|
Message #246211
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
When is a POJO not a POJO?
I worry that what we're calling a POJO isn't really a POJO. Your EJB 3.1 POJO littered with EJB 3.1 annotations isn't plain -- it depends on EJB annotations. This isn't that much different than extending an EJB base class or implementing an EJB interface. Your "plain" old Java object is coupled to the annotaitons, making it... not plain.
Now maybe you can start compiling your "POJOs" with such annotations disabled. But suppose you want to now use your POJO in another annotation-driven environment. Do you go and add those annotations to your POJO? Your POJOs source now becomes littered with annotations from any framework you hope to use it in.
I actually like it better than the annotations are external to the POJO (whether in XML descirptor, XML config file, or even purpose-built hard-coded decoration/wrapper classes).
|
|
|
Message #246212
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Give Credit Where It is Due
It took Spring to really shake things up enough for those responsible for EJB to really gut the spec and come up with something new.
This is precisely why I believe it is vital that Spring and EJB 3 continue to co-exist as competitors. Any mono-culture is bad for innovation and bad for customers. Somewhat perversely, this applies to the Java EE spec itself too. Non-standard solutions, whether commercial, not-for-profit, closed-source or open-source are all part of a healthy Java server-side ecosystem.
|
|
|
Message #246214
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Benz Town Citizen
Jeff
I stand corrected and my apologies go to Rod Johnson.
Thank you. I appreciate it.
Rgds
Rod
|
|
|
Message #246215
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: When is a POJO not a POJO?
I worry that what we're calling a POJO isn't really a POJO. Your EJB 3.1 POJO littered with EJB 3.1 annotations isn't plain -- it depends on EJB annotations. This isn't that much different than extending an EJB base class or implementing an EJB interface. Your "plain" old Java object is coupled to the annotaitons, making it... not plain.
Now maybe you can start compiling your "POJOs" with such annotations disabled. But suppose you want to now use your POJO in another annotation-driven environment. Do you go and add those annotations to your POJO? Your POJOs source now becomes littered with annotations from any framework you hope to use it in.
I actually like it better than the annotations are external to the POJO (whether in XML descirptor, XML config file, or even purpose-built hard-coded decoration/wrapper classes).
FYI, it is perfectly OK to use 100% XML metadata using EJB 3.x if that's what you prefer...
Reza
|
|
|
Message #246217
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Benz Town Citizen
That said, Benz Town Citizen, you should not have posted Rod's blog. It was not relevant to the thread.
I respect your opinion and it seems like you're not the only one who thinks that way.
But to me the post is relevant.
|
|
|
Message #246216
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: Juergen Hoeller
"Indeed, you really need to check out Spring 2.5! You'll be surprised. A Spring/EJB3 discussion based on Spring 2.0 (like in this thread) is effectively outdated. We go pretty far with our annotation-based support options in 2.5... certainly beyond what you would expect."
Good point. Just like confusing EJB 2.x with EJB3 is wrong, one should consider the new annotations feature in Spring 2.5, and not state the Spring is all XML hell.
As far as I'm concerned, the less XML configuration, the better, and annotations present a very pleasant and viable alternative.
Also, the less app server or container dependency (for testing purposes), the better.
I will say this, however. EJB3 delivered us out of XML configuration hell before Spring did. So that's one feather in EJB's cap. ;-)
|
|
|
Message #246218
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: RE: Juergen Hoeller
EJB3 delivered us out of XML configuration hell before Spring did. So that's one feather in EJB's cap. ;-)
Juergen:
Glad to hear this from you. Just because Spring and EJB 3 are competing technologies doesn't mean the people around both cannot have healthy respect for each other or say good things about competing technologies when it is warranted.
Personally, I make a conscious effort to point out what's good about Spring, even if it doesn't favor EJB in every case...I think anything short of that is just a poor show :-).
Reza
|
|
|
Message #246220
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring Overtakes EJB as a Skills Requirement
Well obviously I kicked over a hornet's nest but looking over the ensuing dialog it hasn't been all bad.
My post was specifically responding to the EJB-basher who'd cited Rod's blog entry as "evidence" that the EJB brand name was so damaged that it should be tossed. As Rod himself mentions, he's been an anti-advocate of EJB from the beginning, so using Rod's anti-EJB marketing piece as evidence of how the EJB brand name is worthless was, in my personal view, humorous and ludicrous.
As always, I don't speak for my employer IBM. And actually when I wrote the posting I was responding more as a member of the EJB 3.1 expert group, not anything in relation to where I happen to work.
On the points of proprietary, etc. I was using the definition "a single implementation whose API and behavior is controlled by a single vendor or entity." Bill and Reza subsequently made good posts that I completely agree with, so I don't have anything to add there.
Randy
|
|
