Menu
▾
▴
springframework-developer
|
From: Jeff B. <jb...@ds...> - 2004-05-10 18:05:27
|
I agree with most of Juergen's comments about EJB 3 (http://blog.hibernate.org/cgi-bin/pollxn.cgi?storypath=/Gavin 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 provide a synopsis of what he said? I'd like to believe that he has not completely gone over to the dark side :). Politics aside, somebody representing this point of view still needs to contribute. We all know that most of what we want will currently be vetoed by the big vendors. However, we should still try and fight for what we can get. Rod is the most qualified from what I know. Rod, can you let us know what is going on in this area? Is there something some of us could do to support you in this effort? Jeff W. Boring Impulse Point |
|
From: Tim C. <tc...@ta...> - 2004-05-10 19:56:24
|
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 |
|
From: Jeff B. <jb...@ds...> - 2004-05-10 20:28:43
|
> EJB was never meant to run outside of a non-ejb container. < Hum... but you are mixing specification with implementation. > You can still use Hibernate for that anyways so who really cares? If you chose to use EJB then you've chosen to run in container. If you don't want to then it's very simple.. don't use EJBs. < Why is one approach a Java Specification while the other one is not? What so magically about the EJB approach that it has it's own [container implementation] specification? Jeff W. Boring Impulse Point jb...@im... -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Tim Chen Sent: Monday, May 10, 2004 3:56 PM To: spr...@li... Subject: Re: [Springframework-developer] EBJ 3 and J2EE 1.5 Jurgen's post quotes: "And there hasn't been a single credit to Spring and co in Linda's 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 were centered around it's Entity Bean solution. Particularly CMP. "Spring's main aim is to make J2EE easier to use and promote good programming practice." * It does this by being a POJO/Dependency Injector container. And it does it very well. (Otherwise we wouldnt be using it ;) "Hibernate is a powerful, ultra-high performance object/relational persistence and query service for Java." ** Given that, EJB (at least from the entity side) is closer to Hibernate than Spring. EJB is NOT a container. "There's a strong difference in terms of flexibility of deployment: EJB 3 can by design never match Spring's capability of adapting to all sorts of environments, even if adopting the same development model." Again. Why should it?! EJB was never meant to run outside of a non-ejb container. You can still use Hibernate for that anyways so who really cares? If you chose to use EJB then you've chosen to run in container. 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 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? "It is not good enough to have some EJB 3 EntityManager implementations that can run outside an EJB container. It's still part of the EJB spec, not allowing certification for anything but a complete EJB container implementation (which includes the entire EJB 2 model)." I agree with that one. Backwards compatibility with something that was intrinsically broken is just a bad idea. -Tim * http://www.theserverside.com/articles/article.tss?l=SpringFramework ** http://www.hibernate.org/ Jeff Boring wrote: > I agree with most of Juergen's comments about EJB 3 > (http://blog.hibernate.org/cgi-bin/pollxn.cgi?storypath=/Gavin > 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 > provide a synopsis of what he said? I'd like to believe that he has > not completely gone over to the dark side :). > Politics aside, somebody representing this point of view still needs > to contribute. We all know that most of what we want will currently be > vetoed by the big vendors. However, we should still try and fight for > what we can get. Rod is the most qualified from what I know. Rod, can > you let us know what is going on in this area? Is there something some > 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=dnemail3 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Tim C. <tc...@ta...> - 2004-05-11 14:40:08
|
>> Why is one approach a Java Specification while the other one is not? I think Gavin alluded to this in his talk when he answered a question about the future of hibernate. Hibernate is and will be a place to try new cutting edge methods. Specs were never meant to be cutting edge. A spec is and should be something that has been tried and tested. Hibernate (and other open source projects in general) allows for the new features to be tested. >> What so magically about the EJB approach that it has it's own [container implementation] specification? Containers require J2EE certification and J2EE certification = revenue for Sun? ;) Besides.. rememeber that EJBs also deals with many other facets that Hibernate doesn't have to deal with. ex. There is no session bean concept in Hibernate. -Tim Jeff Boring wrote: >>EJB was never meant to run outside of a non-ejb container. < >> >> > >Hum... but you are mixing specification with implementation. > > > > >>You can still use Hibernate for that anyways so who really cares? If >> >> >you chose to use EJB then you've chosen to run in container. If you >don't want to then it's very simple.. don't use EJBs. < > >Why is one approach a Java Specification while the other one is not? >What so magically about the EJB approach that it has it's own [container >implementation] specification? > >Jeff W. Boring >Impulse Point >jb...@im... > > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...] On Behalf >Of Tim Chen >Sent: Monday, May 10, 2004 3:56 PM >To: spr...@li... >Subject: Re: [Springframework-developer] EBJ 3 and J2EE 1.5 > > >Jurgen's post quotes: >"And there hasn't been a single credit to Spring and co in Linda's >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 >were centered around it's Entity Bean solution. >Particularly CMP. > >"Spring's main aim is to make J2EE easier to use and promote good >programming practice." * >It does this by being a POJO/Dependency Injector container. And it does >it very well. (Otherwise we wouldnt be using it ;) > >"Hibernate is a powerful, ultra-high performance object/relational >persistence and query service for Java." ** >Given that, EJB (at least from the entity side) is closer to Hibernate >than Spring. >EJB is NOT a container. > >"There's a strong difference in terms of flexibility of deployment: EJB >3 can by design never match Spring's capability of adapting to all sorts > >of environments, even if adopting the same development model." Again. >Why should it?! EJB was never meant to run outside of a non-ejb >container. You can still use Hibernate for that anyways so who really >cares? If you chose to use EJB then you've chosen to run in container. >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 >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? > >"It is not good enough to have some EJB 3 EntityManager implementations >that can run outside an EJB container. It's still part of the EJB spec, >not allowing certification for anything but a complete EJB container >implementation (which includes the entire EJB 2 model)." >I agree with that one. Backwards compatibility with something that was >intrinsically broken is just a bad idea. > >-Tim > >* http://www.theserverside.com/articles/article.tss?l=SpringFramework >** http://www.hibernate.org/ > >Jeff Boring wrote: > > > >>I agree with most of Juergen's comments about EJB 3 >>(http://blog.hibernate.org/cgi-bin/pollxn.cgi?storypath=/Gavin >>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 >>provide a synopsis of what he said? I'd like to believe that he has >>not completely gone over to the dark side :). >>Politics aside, somebody representing this point of view still needs >>to contribute. We all know that most of what we want will currently be >> >> > > > >>vetoed by the big vendors. However, we should still try and fight for >>what we can get. Rod is the most qualified from what I know. Rod, can >>you let us know what is going on in this area? Is there something some >> >> > > > >>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=dnemail3 >_______________________________________________ >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: <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
>
|
|
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
>
>
>
|
|
From: Rod J. <rod...@in...> - 2004-05-11 18:51:05
|
MessageI/the Spring team will make an official comment on EJB 3 in the = near future.=20 Unfortunately it's impossible due to the politics surrounding this issue = to discuss at this point in open list. Jeff, if you want to discuss = this further with me off-list that's fine. Regards, Rod ----- Original Message -----=20 From: Jeff Boring=20 To: spr...@li...=20 Sent: Monday, May 10, 2004 7:04 PM Subject: [Springframework-developer] EBJ 3 and J2EE 1.5 I agree with most of Juergen's comments about EJB 3 = (http://blog.hibernate.org/cgi-bin/pollxn.cgi?storypath=3D/Gavin = King/ejb3.html).=20 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 = provide a synopsis of what he said? I'd like to believe that he has not = completely gone over to the dark side :). Politics aside, somebody representing this point of view still needs = to contribute. We all know that most of what we want will currently be = vetoed by the big vendors. However, we should still try and fight for = what we can get. Rod is the most qualified from what I know. Rod, can = you let us know what is going on in this area? Is there something some = of us could do to support you in this effort? Jeff W. Boring Impulse Point =20 |
