With Application EJB Containers addressing most of the transaction,database pooling issues.[quote post="310"]Technologies are always the ways to implement business needs and technology should be changing there is nothing obosolete or legacy[/quote]
.

[quote post="310"]Anyone who has ever studied information visualization or read a chapter in one of Edward Tufte books would quickly realize that your "new commercial" stuff is full of complete and utter chart junk (chart junk in the technical sense with regard to data to ink ratio) and ironically built on the foundations that you keep telling us is bloatware.[/quote]

I share your dislike of "chart junk" and my did my PhD thesis on getting it out of the development process. I also studied infoviz, am a big fan of Tufte and have read his books and attended his seminars. But I have a pretty different point of view on your bloatware argument. Even if Spring were not the most concise way to represent an application, the combination of configurability, simplicity and power have made it a de facto choice for building Java apps. Assuming that it were possible to have a more concise combination of language and framework, I doubt that the resulting apps would be 2x as concise because the underlying problem is essential complexity (discussed further in a JDJ article. A framework that's simple enough to make apps concise and powerful enough to support their essential complexity should be sufficient to become a standard programming model for enterprise Java. And that's where I think we're at with Spring.

The problem of the remaining "chart junk" that shows up in our daily development activities stems from the fact that for any task that we do, a lot of Java and XML that's unrelated to the task-at-hand keeps polluting the screen. For this reason the SpringSource tool suite has incorporated Mylyn's Task-Focused Interface, which, simply put, cuts all the irrelevant junk out of what you see when you're programming. To see what I mean check out the screenshot in my recent blog posting.

So even though everyone may not agree, I think it's pretty neat that we're seeing SpringSource putting such an emphasis on cutting the fat from both the framework and the tools.

I thought that was the sort of space that both Spring and JBoss were aiming at? E.g. When you need Tomcat and just 1 or 2 other Enterprise features such as messaging or transactions. Both JBoss and Spring appear modular enough to use in this fashion. And both are pushing OSGi and modularization. And both are much more capable than just this 'middle space'.

Yes, both projects help there. JBoss's JMX microkernel pioneered a more modular approach than other app servers (thanks to Rickard Oberg). However, JBoss's enduring fixation on EJB has tended to negate this potential benefit in practice, and JBoss has tended (at least in my experience) to start up slower and otherwise accumulate baggage over time. Compare with Tomcat.

Spring is certainly modular, but it's part of a server platform, rather than intended to be an alternative to an application server.

Yes, OSGi is certainly (part of) the answer. Interesting to see that even Sun with Glassfish are now looking to OSGi for runtime modularity.

Rgds
Rod

I'll agree with most of what you are saying , but maybe I'm missing something when you say

[quote post="310"]The market will need to address the gap between Tomcat and WebLogic/WebSphere.[/quote]

I thought that was the sort of space that both Spring and JBoss were aiming at? E.g. When you need Tomcat and just 1 or 2 other Enterprise features such as messaging or transactions. Both JBoss and Spring appear modular enough to use in this fashion. And both are pushing OSGi and modularization. And both are much more capable than just this 'middle space'.

Or was this trailer for your next blog post where you pull back the curtain and reveal Spring as the answer?!

Paul