Dec 19th, 2007, 09:26 AM
I'm not sure I understand what you mean ... Do you mean "Configuration of Spring Bean via XML" ?
Originally Posted by jeffastorey
Actually, last time I used EJB, it was before annotations. Lots of XML ... which I dont like. I should give a try to EJB3 ...
I like Hibernate with annotations. And I like IoC with Spring.
With annotations, you can have the definition of your POJO and their related aspects (like persistence) in the same source file. I find it easier to find my way around, instead of having to switch between a java file and an XML definition.
I dont really have any technical reason not to like EJB. I dont have much experience with them, and when I've seen them, it usually was in huge heavy projects. Spring "feels" more lightweight, with not as much constraints on the developer. But that probably comes more from the kind of projects in which they are used than on the technology itself ...
Dec 19th, 2007, 09:40 AM
My first experience with EJB was EJB3 so I did have the use of annotations (which is great compared to deployment descriptors). But in a development environment, it seems to slow things down sometimes since you need to recompile when you change an annotation vs changing an xml file (as you would in spring).
In terms of advantages/disadvantages of Spring/Hibernate persistence vs the application server's persistence layer, does the app server offer more powerful options (in addition to vendor independence)? Lastly, I think I've been hinting around this a bit, but if you use the app server's persistence layer is it then acceptable (or even expected) to have a mix of EJB (for the persistence) and Spring (for other things you may want to be lighter weight)?
Thanks for your help!
Dec 19th, 2007, 09:50 AM
Antoher point for which I like Spring, is that I can run on Tomcat during the dev. That means much faster startup times than WebLogic !
For the compilation, I dont find it that much of a problem. Eclipse (or other IDE) should be able to handle automatic code compilation, hot code replacement (in some cases) or automatic redeployement of the application being developed.
Also, I'm sure there is a place for Spring even if you do use EJB. For example, you could use SpringMVC at the presentation layer.
On the other side, if you are comfortable with EJB and container managed persistence, there is no need to change. That's a perfectly valid solution used by tons of people as well ...
For a real comparison of EJB / Spring, you will need somebody else than me, with more experience in both environments ...
Dec 19th, 2007, 09:52 AM
Thanks for all of the input. I appreciate your thoughts on the topics.