|
From: Tim C. <tc...@ta...> - 2004-05-11 14:46:33
|
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/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
>
>
>
|