<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Is Spring between the devil and the EJB?</title>
	<atom:link href="http://www.andygibson.net/blog/index.php/2008/08/28/is-spring-between-the-devil-and-the-ejb/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.andygibson.net/blog/index.php/2008/08/28/is-spring-between-the-devil-and-the-ejb/</link>
	<description>Software Development Blog</description>
	<lastBuildDate>Thu, 11 Mar 2010 04:38:29 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Andy Gibson</title>
		<link>http://www.andygibson.net/blog/index.php/2008/08/28/is-spring-between-the-devil-and-the-ejb/comment-page-1/#comment-58</link>
		<dc:creator>Andy Gibson</dc:creator>
		<pubDate>Sun, 05 Oct 2008 03:46:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.andygibson.net/blog/?p=11#comment-58</guid>
		<description>I made this comment drawing from many years of working with Delphi, a platform which had many different component sets. However, those components were used within the same kind of core application code. A component for GWT is wholly different than a JSF component, which is different again from a Wicket Style component. Compare this to the .NET market where it is more like having multiple vendors producing JSF components.

I agree that there is some missing standardization there and this could be down to the way the standards bodies work. When Microsoft developed .NET and the component libraries, it was easy to spot flaws in the design at implementation time and go back and rectify them. With Java standards, the flaws don&#039;t show up till the standard is set in stone, and in JSF&#039;s case, the IDE and component developers are trying to get things working together, and multiple component libraries are trying to play nice together at run time. It is too late at that point to go and clarify the issues.

Also, it&#039;s interesting that it&#039;s hard to use a JSF library without setting up additional web filters  and so on in web.xml. I imagine that this dependency on external mechanisms outside the jsf framework causes some problems, inconsistencies and incompatibilities.</description>
		<content:encoded><![CDATA[<p>I made this comment drawing from many years of working with Delphi, a platform which had many different component sets. However, those components were used within the same kind of core application code. A component for GWT is wholly different than a JSF component, which is different again from a Wicket Style component. Compare this to the .NET market where it is more like having multiple vendors producing JSF components.</p>
<p>I agree that there is some missing standardization there and this could be down to the way the standards bodies work. When Microsoft developed .NET and the component libraries, it was easy to spot flaws in the design at implementation time and go back and rectify them. With Java standards, the flaws don&#8217;t show up till the standard is set in stone, and in JSF&#8217;s case, the IDE and component developers are trying to get things working together, and multiple component libraries are trying to play nice together at run time. It is too late at that point to go and clarify the issues.</p>
<p>Also, it&#8217;s interesting that it&#8217;s hard to use a JSF library without setting up additional web filters  and so on in web.xml. I imagine that this dependency on external mechanisms outside the jsf framework causes some problems, inconsistencies and incompatibilities.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Francisco</title>
		<link>http://www.andygibson.net/blog/index.php/2008/08/28/is-spring-between-the-devil-and-the-ejb/comment-page-1/#comment-51</link>
		<dc:creator>Francisco</dc:creator>
		<pubDate>Sat, 04 Oct 2008 11:00:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.andygibson.net/blog/?p=11#comment-51</guid>
		<description>I do not think that it is right to say:

&quot;Compare to ASP.net, where even though different libraries may be used, the core ASP.net / Winforms is the same.
I would imagine this is also an issue when interviewing for jobs since 5 years Java could mean anything&quot;

Of course 5 years Java could mean anything, 5 years C# could also mean anything (between C# 3.0 and Java 1.6 I prefer C# but that is another story). This is why it is so easy for those Ruby guys to say that Ruby is better than Java: We do not call things by their name: I have never read an article saying Ruby on Rails is superior to Seam or AppFuse.

The proper comparision would be between ASP.NET 3.5 and JSF 1.2 (because 2.0 is still not ready) and while Seam has made a lot to improve things for JSF the sad truth is that JSF is inferior precisely where it should be stronger: Standarization. Any component kit for ASP.NET will try  to be compatible with the core Ajax library in ASP.NET (http://www.asp.net/ajax/) and therefore will try to play well when combined with other component kits,if for no othere reason to avoid angrying microsoft and avoid getting ignored because they cause problems when combined with the official kit, but if you try to mix all this in one project you are in for a nightmare: http://www.free-jsf-components.net/.

I think what JSF needs is some kind of project the objective of making JSF from different author play together (and play with Seam/WebBeans). We need real functional standarization.</description>
		<content:encoded><![CDATA[<p>I do not think that it is right to say:</p>
<p>&#8220;Compare to ASP.net, where even though different libraries may be used, the core ASP.net / Winforms is the same.<br />
I would imagine this is also an issue when interviewing for jobs since 5 years Java could mean anything&#8221;</p>
<p>Of course 5 years Java could mean anything, 5 years C# could also mean anything (between C# 3.0 and Java 1.6 I prefer C# but that is another story). This is why it is so easy for those Ruby guys to say that Ruby is better than Java: We do not call things by their name: I have never read an article saying Ruby on Rails is superior to Seam or AppFuse.</p>
<p>The proper comparision would be between ASP.NET 3.5 and JSF 1.2 (because 2.0 is still not ready) and while Seam has made a lot to improve things for JSF the sad truth is that JSF is inferior precisely where it should be stronger: Standarization. Any component kit for ASP.NET will try  to be compatible with the core Ajax library in ASP.NET (<a href="http://www.asp.net/ajax/" rel="nofollow">http://www.asp.net/ajax/</a>) and therefore will try to play well when combined with other component kits,if for no othere reason to avoid angrying microsoft and avoid getting ignored because they cause problems when combined with the official kit, but if you try to mix all this in one project you are in for a nightmare: <a href="http://www.free-jsf-components.net/" rel="nofollow">http://www.free-jsf-components.net/</a>.</p>
<p>I think what JSF needs is some kind of project the objective of making JSF from different author play together (and play with Seam/WebBeans). We need real functional standarization.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andy Gibson</title>
		<link>http://www.andygibson.net/blog/index.php/2008/08/28/is-spring-between-the-devil-and-the-ejb/comment-page-1/#comment-26</link>
		<dc:creator>Andy Gibson</dc:creator>
		<pubDate>Tue, 02 Sep 2008 23:09:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.andygibson.net/blog/?p=11#comment-26</guid>
		<description>Thanks ashish, Java does have problems with regards to keeping a core set of technologies, especially since non-standard technologies evolve and develop much faster (Spring/EJB3.0, Hibernate/JPA etc..). Plus java developers also have their own ideas on how things should be done. 
Compare to ASP.net, where even though different libraries may be used, the core ASP.net / Winforms is the same. 
I would imagine this is also an issue when interviewing for jobs since 5 years Java could mean anything, while 5 years ASP.net is targeting the core technology.</description>
		<content:encoded><![CDATA[<p>Thanks ashish, Java does have problems with regards to keeping a core set of technologies, especially since non-standard technologies evolve and develop much faster (Spring/EJB3.0, Hibernate/JPA etc..). Plus java developers also have their own ideas on how things should be done.<br />
Compare to ASP.net, where even though different libraries may be used, the core ASP.net / Winforms is the same.<br />
I would imagine this is also an issue when interviewing for jobs since 5 years Java could mean anything, while 5 years ASP.net is targeting the core technology.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ashish jain</title>
		<link>http://www.andygibson.net/blog/index.php/2008/08/28/is-spring-between-the-devil-and-the-ejb/comment-page-1/#comment-25</link>
		<dc:creator>ashish jain</dc:creator>
		<pubDate>Tue, 02 Sep 2008 14:32:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.andygibson.net/blog/?p=11#comment-25</guid>
		<description>Well written article, you captured my thoughts, which were nourishing, when i read about spring app server. 
One of major advantage of Java, it is standards driven. But using spring, it&#039;s making me spring geek, rather than java professional. 
I just read an article about java 7, and their support for java modules (JSr 277?). But spring embracing of OSGi, will create another rift b/w choice of technologies, which is bad for java.</description>
		<content:encoded><![CDATA[<p>Well written article, you captured my thoughts, which were nourishing, when i read about spring app server.<br />
One of major advantage of Java, it is standards driven. But using spring, it&#8217;s making me spring geek, rather than java professional.<br />
I just read an article about java 7, and their support for java modules (JSr 277?). But spring embracing of OSGi, will create another rift b/w choice of technologies, which is bad for java.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
