<?xml version="1.0" encoding="utf-8"?><!-- generator="wordpress/2.0.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: JDO and EJB Join Forces, But What Will the Spec Look Like?</title>
	<link>http://blog.exis.com/colin/archives/2004/09/25/jdo-and-ejb-join-forces-but-what-will-the-spec-look-like/</link>
	<description>Whatever hits the spot</description>
	<pubDate>Wed, 08 Sep 2010 03:00:57 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.2</generator>

	<item>
		<title>by: the_mindstorm</title>
		<link>http://blog.exis.com/colin/archives/2004/09/25/jdo-and-ejb-join-forces-but-what-will-the-spec-look-like/#comment-20</link>
		<pubDate>Tue, 28 Sep 2004 18:24:18 +0000</pubDate>
		<guid>http://blog.exis.com/colin/archives/2004/09/25/jdo-and-ejb-join-forces-but-what-will-the-spec-look-like/#comment-20</guid>
					<description>Hi Colin!

Last readings revealed me that there is some kind of confusion flying around persistence. Maybe at some point it will be necessary to tell the people that persistence is not orm (nor JDBC only).

./the_mindstorm
[&lt;a href=&quot;http://themindstorms.blogspot.com/2004/09/wise-men-voices-were-listened-in-sun.html&quot;&gt;read more...&lt;/a&gt;]</description>
		<content:encoded><![CDATA[<p>Hi Colin!</p>
<p>Last readings revealed me that there is some kind of confusion flying around persistence. Maybe at some point it will be necessary to tell the people that persistence is not orm (nor JDBC only).</p>
<p>./the_mindstorm<br />
[<a href="http://themindstorms.blogspot.com/2004/09/wise-men-voices-were-listened-in-sun.html">read more&#8230;</a>]
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Colin Sampaleanu</title>
		<link>http://blog.exis.com/colin/archives/2004/09/25/jdo-and-ejb-join-forces-but-what-will-the-spec-look-like/#comment-19</link>
		<pubDate>Sun, 26 Sep 2004 00:10:29 +0000</pubDate>
		<guid>http://blog.exis.com/colin/archives/2004/09/25/jdo-and-ejb-join-forces-but-what-will-the-spec-look-like/#comment-19</guid>
					<description>Gavin,

Thanks for your comment. I could have expressed myself better than &quot;most or all of the useful features&quot;, as essentially what I meant is what I think you said, those features from Hibernate 2, Hibernate 3 and JDO 2 which don't exist in the EJB 3 persistence spec from this Spring) and which &lt;b&gt;do&lt;/b&gt; add some compelling value. I.e. the main thing I was trying to get across was that I hoped the spec would still move forward so it is relatively compelling to use feature wise (not withstanding some things that don't make sense to add) compared to the proprietary solutions...</description>
		<content:encoded><![CDATA[<p>Gavin,</p>
<p>Thanks for your comment. I could have expressed myself better than &#8220;most or all of the useful features&#8221;, as essentially what I meant is what I think you said, those features from Hibernate 2, Hibernate 3 and JDO 2 which don&#8217;t exist in the EJB 3 persistence spec from this Spring) and which <b>do</b> add some compelling value. I.e. the main thing I was trying to get across was that I hoped the spec would still move forward so it is relatively compelling to use feature wise (not withstanding some things that don&#8217;t make sense to add) compared to the proprietary solutions&#8230;
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Gavin</title>
		<link>http://blog.exis.com/colin/archives/2004/09/25/jdo-and-ejb-join-forces-but-what-will-the-spec-look-like/#comment-18</link>
		<pubDate>Sat, 25 Sep 2004 23:40:52 +0000</pubDate>
		<guid>http://blog.exis.com/colin/archives/2004/09/25/jdo-and-ejb-join-forces-but-what-will-the-spec-look-like/#comment-18</guid>
					<description>&quot;includes most or all of the useful features&quot;

One of the important things to consider when writing specs is that it must be possible for the market to produce competitive implementations. Which means you have to weigh up the value of a feature and decide if it is *really* of sufficient value to a user, or if it just creates an extra barrier to entry for new implementations. If we just throw everything Hibernate3 has into JSR-220, we will create a market with exactly one implementation: namely Hibernate3. One of our goals is to constrain the complexity of the spec, which means we won't be shovelling in features that are of marginal usefulness (while keeping open the possibility of adding them in a later revision).

&quot;The direction of the existing EJB persistence draft, issued this spring, limiting the API to running in an EJB container, never made any sense to me or a number of people.&quot;

Um. I've been telling you guys for months that EJB3 persistence was *absolutely* appropriate for out of container operation, and that vendors would be providing this. I even blogged about this. But &quot;a number of people&quot; found it convenient to disbelieve me. :-( This was *incredibly* frustrating (especially since I could not talk about everything I knew was being discussed with respect to this). grrrrrr. Anyway, now that it is official we can move on.</description>
		<content:encoded><![CDATA[<p>&#8220;includes most or all of the useful features&#8221;</p>
<p>One of the important things to consider when writing specs is that it must be possible for the market to produce competitive implementations. Which means you have to weigh up the value of a feature and decide if it is *really* of sufficient value to a user, or if it just creates an extra barrier to entry for new implementations. If we just throw everything Hibernate3 has into JSR-220, we will create a market with exactly one implementation: namely Hibernate3. One of our goals is to constrain the complexity of the spec, which means we won&#8217;t be shovelling in features that are of marginal usefulness (while keeping open the possibility of adding them in a later revision).</p>
<p>&#8220;The direction of the existing EJB persistence draft, issued this spring, limiting the API to running in an EJB container, never made any sense to me or a number of people.&#8221;</p>
<p>Um. I&#8217;ve been telling you guys for months that EJB3 persistence was *absolutely* appropriate for out of container operation, and that vendors would be providing this. I even blogged about this. But &#8220;a number of people&#8221; found it convenient to disbelieve me. <img src='http://blog.exis.com/colin/wp-includes/images/smilies/icon_sad.gif' alt=':-(' class='wp-smiley' />  This was *incredibly* frustrating (especially since I could not talk about everything I knew was being discussed with respect to this). grrrrrr. Anyway, now that it is official we can move on.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Gabriel Mihalache</title>
		<link>http://blog.exis.com/colin/archives/2004/09/25/jdo-and-ejb-join-forces-but-what-will-the-spec-look-like/#comment-17</link>
		<pubDate>Sat, 25 Sep 2004 20:21:52 +0000</pubDate>
		<guid>http://blog.exis.com/colin/archives/2004/09/25/jdo-and-ejb-join-forces-but-what-will-the-spec-look-like/#comment-17</guid>
					<description>It would have been best if you would have said that Spring will support it IF it's any good. Otherwise, you make it sound that anything midly popular or coming from a JSR will make it, regardless of its quality. :-)</description>
		<content:encoded><![CDATA[<p>It would have been best if you would have said that Spring will support it IF it&#8217;s any good. Otherwise, you make it sound that anything midly popular or coming from a JSR will make it, regardless of its quality. <img src='http://blog.exis.com/colin/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' />
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
