I want just to comment this point.
Who told something like this,never tried to run the same EJB on Bea Weblogic , Glassfish , and JBoss.
Any project needed different configuration and different annotations sometimes, and i had only 1 Entity and 1 MDB… was really frustating.

You are correct. I have been using Spring framework for a while and I find it is one of the easiest frameworks to use. Also it provides every thing what EJB can provide. But, community is always comparing these two technologies and blaming each other. Please help each other and try to improve the technologies and it will be good for the developers.

Thank you for the article!!

Thanks,
Krishna

I'm one of the guys that attended the meeting and honestly I was disappointed by the quality of the presentation because I was hoping to see a more constructive comparison other than trying to bash Spring product. I share Mark's point of view and probably Reza should be more careful before making bold statements about Spring or other technology or at least try to investigate before claiming how great is one product vs. other.

Anyway, good luck promoting EJB3 and keep up with the good work Spring team!

Thanks,
Valy

Thanks in advance for your help and comments.

In all fairness – you haven't. Aside from me responding to Dario's comments there and not to the content of your presentation in the first place, you seem to have missed my main points. There's a very different spin in my perspective.

[quote comment="63854"]I will choose not to judge an entire community based on the opinions of one or two people, even if they are key leaders in that community.[/quote]

I would argue that our opinion is as fair and balanced as yours. The key difference is that we 'natively' see things the Spring Way, while you tend to see everything from an EJB3 perspective. Frankly, I don't think you're seeing what Spring is really about.

[quote comment="63854"]I am still not sure how you established why it is so difficult for Spring to support EJB 100% as well as it's own extensions. No one said you could not push out additional Spring versions on top of the specification timeline (…)[/quote]

Nobody ever said it's "so difficult"; that's a gross distortion in your perspective. It is just not generally recommendable to our users. Spring differs in the defaults and recommendations from virtually everything EJB3 defines, so this would break with much-loved key elements of the Spring Way. And the Spring Way is what matters to our community.

Anyway, the term "extensions" clearly highlights your narrow perspective again: Spring is not about extending EJB3 in the first place. Spring is about a comprehensive, self-sufficient component model in its own right, integrating with EJB3 (if desired) but not being tied to it. If we decide support standard annotations, then we do so in the context of Spring's native component model. Not the other way around.

[quote comment="63854"]Folks should be able to use Spring as a fully compatible EJB 3.x container if they so choose…[/quote]

The Pitchfork project is exactly about building such an EJB3 container on top of the Spring core framework. However, the point there was to implement an EJB3 container in the first place, to be embedded in server products. This is not the typical Spring usage scenario; to the best of our knowledge, our users still prefer to use Spring natively.

In general, if folks want to use EJB 3, then they get themselves a Java EE 5 server; they don't choose an application framework for that. In other words, application frameworks integrate with EJB3; they are not themselves EJB3 containers. This applies to e.g. Seam just as much as it does to Spring. It even applies to the emerging Web Beans!

Spring works nicely as an application framework on top of a Java EE 5 server, and will be able to do an even better job there on Java EE 6. This is exactly because Spring is designed the way it is, integrating with Java EE facilities rather than implementing them. If the Spring application framework was an EJB3 container itself, it would conflict with the built-in EJB3 container of the underlying server, while not being able to provide the added value that it does at present… So what exactly would be the point?

Juergen

1. Spring 2.5 is final today.

Rgds
Rod

Thanks for your comments. To summarize and repeat myself in hopes to stopping this from turning into an endless spiraling thread:

1. I'll update my presentation to reflect Spring 2.5 once it matures. Before that, it makes little sense for me to do anything further other than mention it cursorily.
2. I'll update the presentation to use JPA support in Spring 2.0. Honestly, I think this will make little difference to the overall high-level conclusions or the general flavor of the code.
3. There is actually very little other in this post that I see as actual reasons to modify the presentation any further (of course this is a subjective evaluation). If it is really productive to do so, I will be happy to state my reasoning *only once* on each point and hope that we can agree to disagree.
4. That being said, the points that I see as gray areas, I will format into a puzzler/solver (with my viewpoints embedded into the solver part) and add as an interesting supplement to the presentation (I’m assuming that this is OK with you guys). I think that is pretty fair and square. Given the amount of stuff I am juggling at the moment, this won't happen until after thanksgiving. I'll be happy to post the puzzler/solver for you guys to review here. I have no problems listening carefully to reasonable requests at that point as well.
5. Frankly, I don't know what you are talking about on the June presentation. If you care to elaborate, I'll be happy to listen. The presentation's summary decisions have remained unchanged since Debu and I took the pains to carry out the analysis quite a few months ago. The only recent "update" is that we've managed to make some space by taking out Hibernate altogether (the original comparative analysis was on EJB 3, Spring Hibernate, which are the stacks a majority of people are interested in) and add in architectural/philosophical concerns not reflected in raw code (standardization, extensibility, pluggability, deployment, development). In the past, I briefly talked over these issues (probably around June) since I didn't really have time to cover them beyond a much distilled level. Please remember that the slides only capture about 25% of a presentation.

I hope we can leave this thread on a positive and productive note at this point.

All the best,
Reza

Reza, this is not really about passion (although there is plenty of that in the Spring project). On what basis is there a low signal to noise ratio in this post? I can only guess that your comment to that effect is there to help sidestep the fact that Mark has a bunch of valid points. Now as Mark said, some of the things he talks about are Spring 2.5 features, but much of this would apply to Spring 2.0, out now for more than a year…

FWIW, I actually remember reading an online version of your presentation back in June, and wincing at the inaccurate picture it portrays…

Colin