Re: [Springframework-developer] EBJ 3 and J2EE 1.5

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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