|
From: <tho...@tr...> - 2004-05-10 20:54:35
|
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
>
|