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

The sad part in this is that I clearly pointed out all of what you said in the analysis. It is just unfortunate to see a needless lashing out just because I did not choose to make the exact decisions that someone in the Spring team would have made on some small stuff that's pretty gray. However, 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. Let's not let suspicions rein over goodwill guys

However, I'll let the evidence do the talking as to my "bias". Mark, please also kindly make sure to list what XML configuration beyond that one XML attribute you thought was "verbose" I'd like to make sure I capture all your concerns for the "puzzler/solver". I think it will add great depth to the analysis.

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 (a one or two sentence explanation, if possible, would be nice). Coming back to Dario's point, why make developers choose between meta-models at all? Folks should be able to use Spring as a fully compatible EJB 3.x container if they so choose…what's the motivation here? How does this help developers?

Reza

That was part of the original motivation for Spring but by no means the defining characteristic. Right from the start, Spring provided its distinctive own programming and configuration model, very general and very flexible, *adapting* to J2EE environments very nicely but immediately transcending J2EE as well. There is a lot of non-J2EE usage of Spring out there, even and in particular in enterprise environments. This trend has been showing for years, with the rise of enterprise OSGi as the most recent indication.

That said - Spring is still very supportive of traditional J2EE runtime environments, more so than anything that comes out of the JCP these days. Spring 2.5 still supports J2EE 1.3 , bringing the full power of Spring's Java 5 support (including the annotation-based configuration model) into J2EE 1.4 environments such as WebLogic 9 and WebSphere 6.1. This matters a lot to enterprise software development in the real world, where J2EE 1.4 will remain a mainstream deployment platform for years to come.

Juergen