Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-05-11 11:44:33
|
Tim, =20 <quote> Of course there is no credit to Spring. Why should there be? The main part of the EJB->Hibernate->EJB 3.0 and EJB 3.0 discussions were centered around it's Entity Bean solution. Particularly CMP. </quote> =20 As Thomas already elaborated, there's also a completely revamped Session = Bean model that does imitate Spring's development model, just like EJB 3 = Entity Beans imitate Hibernate respectively HQL. Why give repeated = explicit credits to Hibernate but not a single one to Spring (or any = other concrete lightweight container product)? =20 <quote> "Why oh why does this have to be part of the EJB spec? Why not doing a separate O/R mapping spec - no matter if within or outsider the JDO scope? There's no technical reason for tying this to an EJB container" I completely disagree. BMP/CMP/EJB has been getting a bad rap for a while now due to it's performance issues. It was in fact just plain garbage in most cases. So why not fix it? Why create a whole new spec and leave the other one in its state? What good does that do anyone? </quote> =20 The old EJB model, in particular EJB 2.x Entity Beans, will still be = around - live and kicking, without a single deprecation. I don't see the = point in adding a completely new POJO persistence model to the EJB spec: = It could simply refer to a separate O/R mapping spec (whether JDO or a = new one) instead, allowing the latter to address any environment (rather = than just EJB), and allowing persistence tool vendors to implement it = (rather than just EJB container vendors). =20 =20 For the record, I don't really expect to see a consequence regarding the = former point - I just wanted to publically note it. They will never = credit Spring in public, at least as long as it is not part of JBoss = Group ;-) =20 I have a pretty strong opinion regarding the latter point, though. There = isn't a single technical reason for a completely new O/R mapping spec as = part of EJB 3. It seems they just don't want to admit that EJB 1.x/2.x = Entity Beans have been such a failure, by still calling the new thing = "Entity Beans" (even if it's something completely new). =20 Juergen |
|
From: Rod J. <rod...@in...> - 2004-05-11 17:02:55
|
I don't think this is the right place for this discussion,
but my discussion of what is now called Setter Injection
in "Expert 1:1 J2EE" (published in 2002) and the 30,000 lines
of code that accompanied it predated all the lightweight
containers around. Even the Spring project on SourceForge
began months before other present-generation container
projects AFAIK. (Please note that I know the PicoContainer
guys, and what they did was totally independent of Spring,
but of course it wasn't initially doing Setter Injection.)
Please also note that I do not claim that EJB3 stole anything
from Spring or that anyone stole anything from anyone else.
There's just an undeniable similarity.
Regards,
Rod
---- Original message ----
>Date: Tue, 11 May 2004 10:45:52 -0400
>From: Tim Chen <tc...@ta...>
>Subject: Re: [Springframework-developer] EBJ 3 and J2EE 1.5
>To: spr...@li...
>
>Good point Thomas but Spring is not the only container with
Setter
>injection ;)
>
>-Tim
>
>tho...@tr... wrote:
>
>>Tim,
>>
>>I agree that the discussion on The ServerSide has centered
around the Entity
>>Bean solution, but Linda's presentation did cover a lot
more. She talked a lot
>>about Session Beans and Dependency Injection. Here is a
transcript of a few of
>>her slides:
>>
>>Access to Bean's Environment
>> - Get JNDI APIs out of developer's view
>> - Techniques/mechanisms
>> 1)Declarative expression of dependencies in metadata
>> 2)Container injection of resource, etc. entries
>> 3)Simple programmatic lookup mechanisms
>> - Different usages, both have their place
>> 2) very simple; facilitates testability (esp. setter
injection techniques)
>> 3) more flexible; dynamic
>>
>>Injection
>> - Container can initialize instance variables at time bean
is made available
>> - Setter injection is better technique
>> - Better testability
>> - Can use to inject ejbContext, EntityManager,
resources, etc
>> - Considered constructor injection, but found it not as
simple / flexible
>>
>>
>>One code example:
>>
>>@Session public class MySessionBean {
>> private DataSource customerDB;
>>
>> @Inject private void setCustomerDB(DataSource customerDB)
{
>> customerDB = myDB;
>> }
>>
>>
>> public void myMethod (String myString) {
>> ...
>> Connection conn = customerDB.getConnection();
>> ...
>> }
>>}
>>
>>I think it looks very familiar :-)
>>
>>Thomas
>>
>>
>>Quoting Tim Chen <tc...@ta...>:
>>
>>
>>
>>>Jurgen's post quotes:
>>>"And there hasn't been a single credit to Spring and co in
Linda's=20
>>>talk... (but lots and lots of credits to Hibernate)."
>>>Of course there is no credit to Spring. Why should there
be?
>>>The main part of the EJB->Hibernate->EJB 3.0 and EJB 3.0
discussions=20
>>>were centered around it's Entity Bean solution.
>>>Particularly CMP.
>>>
>>>"Spring=92s main aim is to make J2EE easier to use and
promote good=20
>>>programming practice." *
>>>It does this by being a POJO/Dependency Injector
container. And it does=20
>>>it very well. (Otherwise we wouldnt be using it ;)
>>>
>>>"Hibernate is a powerful, ultra-high performance
object/relational=20
>>>persistence and query service for Java." **
>>>Given that, EJB (at least from the entity side) is closer
to Hibernate=20
>>>than Spring.
>>>EJB is NOT a container.
>>>
>>>"There's a strong difference in terms of flexibility of
deployment: EJB=20
>>>3 can by design never match Spring's capability of
adapting to all sorts=20
>>>of environments, even if adopting the same development
model."
>>>Again. Why should it?! EJB was never meant to run outside
of a non-ejb=20
>>>container. You can still use Hibernate for that anyways so
who really=20
>>>cares? If you chose to use EJB then you've chosen to run
in container.=20
>>>If you don't want to then it's very simple.. don't use
EJBs.
>>>
>>>"Why oh why does this have to be part of the EJB spec? Why
not doing a=20
>>>separate O/R mapping spec - no matter if within or
outsider the JDO=20
>>>scope? There's no technical reason for tying this to an
EJB container"
>>>I completely disagree. BMP/CMP/EJB has been getting a bad
rap for a=20
>>>while now due to it's performance issues. It was in fact
just plain=20
>>>garbage in most cases. So why not fix it? Why create a
whole new spec=20
>>>and leave the other one in its state? What good does that
do anyone?
>>>
>>>"It is not good enough to have some EJB 3 EntityManager
implementations=20
>>>that can run outside an EJB container. It's still part of
the EJB spec,=20
>>>not allowing certification for anything but a complete EJB
container=20
>>>implementation (which includes the entire EJB 2 model)."
>>>I agree with that one. Backwards compatibility with
something that was=20
>>>intrinsically broken is just a bad idea.
>>>
>>>-Tim
>>>
>>>* http://www.theserverside.com/articles/article.tss?
l=3DSpringFramework
>>>** http://www.hibernate.org/
>>>
>>>Jeff Boring wrote:
>>>
>>>
>>>
>>>>I agree with most of Juergen's comments about EJB 3=20
>>>>(http://blog.hibernate.org/cgi-bin/pollxn.cgi?
storypath=3D/Gavin=20
>>>>King/ejb3.html).
>>>>I'd like to see:
>>>>1) Gavin's response
>>>>2) Juergen and/or Rod join JSR 244
>>>>Has anyone talked with Gavin (Juergen/Rod?) about this.
Can you=20
>>>>provide a synopsis of what he said? I'd like to believe
that he has=20
>>>>not completely gone over to the dark side :).
>>>>Politics aside, somebody representing this point of view
still needs=20
>>>>to contribute. We all know that most of what we want will
currently be=20
>>>>vetoed by the big vendors. However, we should still try
and fight for=20
>>>>what we can get. Rod is the most qualified from what I
know. Rod, can=20
>>>>you let us know what is going on in this area? Is there
something some=20
>>>>of us could do to support you in this effort?
>>>>Jeff W. Boring
>>>>Impulse Point
>>>>
>>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by Sleepycat Software
>>>Learn developer strategies Cisco, Motorola, Ericsson &
Lucent use to
>>>deliver higher performing products faster, at low TCO.
>>>http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
>>>_______________________________________________
>>>Springframework-developer mailing list
>>>Spr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/springframewor
k-developer
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by Sleepycat Software
>>Learn developer strategies Cisco, Motorola, Ericsson &
Lucent use to
>>deliver higher performing products faster, at low TCO.
>>http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework
-developer
>>
>>
>>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Sleepycat Software
>Learn developer strategies Cisco, Motorola, Ericsson &
Lucent use to
>deliver higher performing products faster, at low TCO.
>http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-
developer
|
|
From: Tim C. <tc...@ta...> - 2004-05-11 14:40:16
|
>> For the record, I don't really expect to see a consequence regarding t= he former point - I just wanted to >> publically note it. They will never= credit Spring in public, at least as long as it is not part of JBoss >> = Group ;-) hehe are you saying that politics are involved.. no way that would never = happen ;) >>The old EJB model, in particular EJB 2.x Entity Beans, will still be ar= ound - live and kicking, without a single deprecation. that is true and I don't know why they decided on this other than to say=20 that it is a way to give people upgrading to the new J2EE spec a chance=20 to ease into the transition? /me is always trying to find the good in thi= ngs >> It seems they just don't want to admit that EJB 1.x/2.x Entity Beans=20 have been such a failure, by still calling the new thing "Entity Beans"=20 (even if it's something completely new). actually I would disagree with this point solely from the pov of someone=20 attending the symposium. many times Gavin had trashed EJB 1.x/2.x and=20 Linda didn't disagree nor did she try to defend it in her own talks. I=20 think they (Sun) have pretty much acknowledged their failure. -Tim j=FCrgen h=F6ller [werk3AT] wrote: >Tim, >=20 ><quote> >Of course there is no credit to Spring. Why should there be? >The main part of the EJB->Hibernate->EJB 3.0 and EJB 3.0 discussions >were centered around it's Entity Bean solution. >Particularly CMP. ></quote> >=20 >As Thomas already elaborated, there's also a completely revamped Session= Bean model that does imitate Spring's development model, just like EJB 3= Entity Beans imitate Hibernate respectively HQL. Why give repeated expli= cit credits to Hibernate but not a single one to Spring (or any other con= crete lightweight container product)? >=20 ><quote> >"Why oh why does this have to be part of the EJB spec? Why not doing a >separate O/R mapping spec - no matter if within or outsider the JDO >scope? There's no technical reason for tying this to an EJB container" >I completely disagree. BMP/CMP/EJB has been getting a bad rap for a >while now due to it's performance issues. It was in fact just plain >garbage in most cases. So why not fix it? Why create a whole new spec >and leave the other one in its state? What good does that do anyone? ></quote> >=20 >The old EJB model, in particular EJB 2.x Entity Beans, will still be aro= und - live and kicking, without a single deprecation. I don't see the poi= nt in adding a completely new POJO persistence model to the EJB spec: It = could simply refer to a separate O/R mapping spec (whether JDO or a new o= ne) instead, allowing the latter to address any environment (rather than = just EJB), and allowing persistence tool vendors to implement it (rather = than just EJB container vendors). >=20 >=20 >For the record, I don't really expect to see a consequence regarding the= former point - I just wanted to publically note it. They will never cred= it Spring in public, at least as long as it is not part of JBoss Group ;-= ) >=20 >I have a pretty strong opinion regarding the latter point, though. There= isn't a single technical reason for a completely new O/R mapping spec as= part of EJB 3. It seems they just don't want to admit that EJB 1.x/2.x E= ntity Beans have been such a failure, by still calling the new thing "Ent= ity Beans" (even if it's something completely new). >=20 >Juergen > > > >------------------------------------------------------- >This SF.Net email is sponsored by Sleepycat Software >Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to=20 >deliver higher performing products faster, at low TCO. >http://www.sleepycat.com/telcomwpreg.php?From=3Ddnemail3 >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > =20 > |
