springframework-developer

RE: [Springframework-developer] EJBs vs POJOs

[James C. <dja...@gm...>]

Spring simply provides a convenient fa=E7ade to other persistence
implementations, including EJB!

You may have meant Entity Beans when you stated EJB. If so, another
way of wording your question is, "Are there cases when EJB is
preferred as a persistence mechanism over a POJO persistence
(Hibernate, TopLink, iBatis, JDO, EJB3, and dozens of others)
mechanism?"

Take these with a grain of salt, since I don't have hands-on
experience with all of the POJO persistence mechanisms. A few benefits
don't come easily to the world of POJO persistence.

a) POJO-based approaches (AFAIK) with the exception of EJB3, do not
support distributed security contexts. Even if you were writing an EJB
implementation, you would want to limit the number of network calls
your app has to make. But if you really have part of your application
on one machine, and part on another, you can invoke EJB's on the
various machines and remain within the same security context.

b) Clustered sessions are still the realm of the J2EE container.
Distributed caching of persistent object between machines is difficult
to achieve using POJO persistence.

c) Support for CORBA clients is a standard feature of J2EE.

There may be more. Of course, EJB3 will probably turn this discussion
on its ear.

If I totally missed your point, and you just wanted to know if Spring
provided lightweight (sorry Hani) alternatives for the specification
components that make up Enterprise Java Beans (EJB), namely:

- Stateless Session Bean (yes, via service interfaces, pojos you write)
- Stateful Session Bean (no)
- Entity Bean (yes, via Hibernate, TopLink, iBatis, JDO passthrus)
- Message Driven Bean (No, AFAIK)
- Timer Bean (yes, via quartz)
- Web Service Endpoints (yes, via http invoker, hessian, burlap, axis, mayb=
e
others)




> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On=20
> Behalf Of Garvey, Paul M (GE Commercial Finance)
> Sent: Thursday, April 21, 2005 3:53 PM
> To: spr...@li...
> Subject: [Springframework-developer] EJBs vs POJOs
>=20
> All,
>=20
> I fairly new to Spring and I am currently reading some documentation=20
> on it. I have bought into the concept of the lightweight feature of=20
> Spring. I do have a quick question, Springs seems to handle every=20
> scenario that I would
> use EJBs, is there a few cases where EJBs are unavoidable to use? In othe=
r
> words
> are there any scenarios where Spring is just not the best tool to use and
> EJBs is
> the more suited? Any thoughts?
>=20
> Paul
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real=20
> users. Discover which products truly live up to the hype. Start=20
> reading now. http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] EJBs vs POJOs

[Garvey, P. M \(GE C. Finance\) <pau...@ge...>]

James,
      Your response was insightful and you did partially answered my =
question.
Let me try to be a bit clearer, If I had to create an application that =
needed to
be distributed across multiple machines I would normally use EJBs =
(stateless Bean + Entity Beans)
or (stateless beans + DAOs) or (stateless beans + hibernate) etc. Could =
I use Spring
in this senario? Would it make more sense to stick with the EJB =
paradigm? I want to have a clear picture=20
in my mind of when to use Spring on a project and when to use EJBs. In =
other words,=20
when does it make most sense to use EJBs instead of Spring and vice =
versa?
Are there times when Spring is just not the solution to the problem and =
EBJ is?

Paul





-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of James Cook
Sent: Thursday, April 21, 2005 5:25 PM
To: spr...@li...
Subject: RE: [Springframework-developer] EJBs vs POJOs


Spring simply provides a convenient fa=E7ade to other persistence
implementations, including EJB!

You may have meant Entity Beans when you stated EJB. If so, another
way of wording your question is, "Are there cases when EJB is
preferred as a persistence mechanism over a POJO persistence
(Hibernate, TopLink, iBatis, JDO, EJB3, and dozens of others)
mechanism?"

Take these with a grain of salt, since I don't have hands-on
experience with all of the POJO persistence mechanisms. A few benefits
don't come easily to the world of POJO persistence.

a) POJO-based approaches (AFAIK) with the exception of EJB3, do not
support distributed security contexts. Even if you were writing an EJB
implementation, you would want to limit the number of network calls
your app has to make. But if you really have part of your application
on one machine, and part on another, you can invoke EJB's on the
various machines and remain within the same security context.

b) Clustered sessions are still the realm of the J2EE container.
Distributed caching of persistent object between machines is difficult
to achieve using POJO persistence.

c) Support for CORBA clients is a standard feature of J2EE.

There may be more. Of course, EJB3 will probably turn this discussion
on its ear.

If I totally missed your point, and you just wanted to know if Spring
provided lightweight (sorry Hani) alternatives for the specification
components that make up Enterprise Java Beans (EJB), namely:

- Stateless Session Bean (yes, via service interfaces, pojos you write)
- Stateful Session Bean (no)
- Entity Bean (yes, via Hibernate, TopLink, iBatis, JDO passthrus)
- Message Driven Bean (No, AFAIK)
- Timer Bean (yes, via quartz)
- Web Service Endpoints (yes, via http invoker, hessian, burlap, axis, =
maybe
others)




> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On=20
> Behalf Of Garvey, Paul M (GE Commercial Finance)
> Sent: Thursday, April 21, 2005 3:53 PM
> To: spr...@li...
> Subject: [Springframework-developer] EJBs vs POJOs
>=20
> All,
>=20
> I fairly new to Spring and I am currently reading some documentation=20
> on it. I have bought into the concept of the lightweight feature of=20
> Spring. I do have a quick question, Springs seems to handle every=20
> scenario that I would
> use EJBs, is there a few cases where EJBs are unavoidable to use? In =
other
> words
> are there any scenarios where Spring is just not the best tool to use =
and
> EJBs is
> the more suited? Any thoughts?
>=20
> Paul
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real=20
> users. Discover which products truly live up to the hype. Start=20
> reading now. http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] EJBs vs POJOs

[Eugene K. <eu...@ja...>]

Paul,

   There is nothing wrong with using EJB as a remore facade. That will 
give you standard access to J2EE services (JTA, remoting, failover, 
clustering). In my current project we are using the following pattern:

   EJB Layer (Stateless and MDB without any business logic)
   Spring managed POJO's (IoC + AOP + componentization)
   Persistance (DAO, CMP beans)

   This way EJB layer is used as a remote facade and all business logic 
is easily testable outside of J2EE container and allow to hook up 
aspects and nicely manage dependencies. We also found that CMP layer 
with caching provided by J2EE container perform quite well in some cases 
(especially when cluster-wide cache between transactions is turned on), 
but in some cases caching aspects allow additional performance improvment.

   regards,
   Eugene


Garvey, Paul M (GE Commercial Finance) wrote:
> James,
>       Your response was insightful and you did partially answered my question.
> Let me try to be a bit clearer, If I had to create an application that needed to
> be distributed across multiple machines I would normally use EJBs (stateless Bean + Entity Beans)
> or (stateless beans + DAOs) or (stateless beans + hibernate) etc. Could I use Spring
> in this senario? Would it make more sense to stick with the EJB paradigm? I want to have a clear picture 
> in my mind of when to use Spring on a project and when to use EJBs. In other words, 
> when does it make most sense to use EJBs instead of Spring and vice versa?
> Are there times when Spring is just not the solution to the problem and EBJ is?
> 
> Paul
> 
> 
> 
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of James Cook
> Sent: Thursday, April 21, 2005 5:25 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] EJBs vs POJOs
> 
> 
> Spring simply provides a convenient façade to other persistence
> implementations, including EJB!
> 
> You may have meant Entity Beans when you stated EJB. If so, another
> way of wording your question is, "Are there cases when EJB is
> preferred as a persistence mechanism over a POJO persistence
> (Hibernate, TopLink, iBatis, JDO, EJB3, and dozens of others)
> mechanism?"
> 
> Take these with a grain of salt, since I don't have hands-on
> experience with all of the POJO persistence mechanisms. A few benefits
> don't come easily to the world of POJO persistence.
> 
> a) POJO-based approaches (AFAIK) with the exception of EJB3, do not
> support distributed security contexts. Even if you were writing an EJB
> implementation, you would want to limit the number of network calls
> your app has to make. But if you really have part of your application
> on one machine, and part on another, you can invoke EJB's on the
> various machines and remain within the same security context.
> 
> b) Clustered sessions are still the realm of the J2EE container.
> Distributed caching of persistent object between machines is difficult
> to achieve using POJO persistence.
> 
> c) Support for CORBA clients is a standard feature of J2EE.
> 
> There may be more. Of course, EJB3 will probably turn this discussion
> on its ear.
> 
> If I totally missed your point, and you just wanted to know if Spring
> provided lightweight (sorry Hani) alternatives for the specification
> components that make up Enterprise Java Beans (EJB), namely:
> 
> - Stateless Session Bean (yes, via service interfaces, pojos you write)
> - Stateful Session Bean (no)
> - Entity Bean (yes, via Hibernate, TopLink, iBatis, JDO passthrus)
> - Message Driven Bean (No, AFAIK)
> - Timer Bean (yes, via quartz)
> - Web Service Endpoints (yes, via http invoker, hessian, burlap, axis, maybe
> others)
> 
> 
> 
> 
> 
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On 
>>Behalf Of Garvey, Paul M (GE Commercial Finance)
>>Sent: Thursday, April 21, 2005 3:53 PM
>>To: spr...@li...
>>Subject: [Springframework-developer] EJBs vs POJOs
>>
>>All,
>>
>>I fairly new to Spring and I am currently reading some documentation 
>>on it. I have bought into the concept of the lightweight feature of 
>>Spring. I do have a quick question, Springs seems to handle every 
>>scenario that I would
>>use EJBs, is there a few cases where EJBs are unavoidable to use? In other
>>words
>>are there any scenarios where Spring is just not the best tool to use and
>>EJBs is
>>the more suited? Any thoughts?
>>
>>Paul
>>

Re: [Springframework-developer] EJBs vs POJOs

[Dmitriy K. <dko...@ru...>]

To put simply - if you absolutely require to physically distribute your=20
application, EJB (SLSB facade) would probably be the good choice here.=20
Please note that you still would want to use Spring-EJB support as it=20
transparently exposes your POJO business interfaces as EJB=20
implementations (via proxies) and also frees the application code from=20
low level plumbing code related to EJB programming model e.g. JNDI=20
lookups, etc. Coupled with IoC container (for DI) you get easy testable=20
code with minimal dependence on EJB container.

Regards,
Dmitriy.

Garvey, Paul M (GE Commercial Finance) wrote:

>James,
>      Your response was insightful and you did partially answered my que=
stion.
>Let me try to be a bit clearer, If I had to create an application that n=
eeded to
>be distributed across multiple machines I would normally use EJBs (state=
less Bean + Entity Beans)
>or (stateless beans + DAOs) or (stateless beans + hibernate) etc. Could =
I use Spring
>in this senario? Would it make more sense to stick with the EJB paradigm=
? I want to have a clear picture=20
>in my mind of when to use Spring on a project and when to use EJBs. In o=
ther words,=20
>when does it make most sense to use EJBs instead of Spring and vice vers=
a?
>Are there times when Spring is just not the solution to the problem and =
EBJ is?
>
>Paul
>
>
>
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of James Cook
>Sent: Thursday, April 21, 2005 5:25 PM
>To: spr...@li...
>Subject: RE: [Springframework-developer] EJBs vs POJOs
>
>
>Spring simply provides a convenient fa=E7ade to other persistence
>implementations, including EJB!
>
>You may have meant Entity Beans when you stated EJB. If so, another
>way of wording your question is, "Are there cases when EJB is
>preferred as a persistence mechanism over a POJO persistence
>(Hibernate, TopLink, iBatis, JDO, EJB3, and dozens of others)
>mechanism?"
>
>Take these with a grain of salt, since I don't have hands-on
>experience with all of the POJO persistence mechanisms. A few benefits
>don't come easily to the world of POJO persistence.
>
>a) POJO-based approaches (AFAIK) with the exception of EJB3, do not
>support distributed security contexts. Even if you were writing an EJB
>implementation, you would want to limit the number of network calls
>your app has to make. But if you really have part of your application
>on one machine, and part on another, you can invoke EJB's on the
>various machines and remain within the same security context.
>
>b) Clustered sessions are still the realm of the J2EE container.
>Distributed caching of persistent object between machines is difficult
>to achieve using POJO persistence.
>
>c) Support for CORBA clients is a standard feature of J2EE.
>
>There may be more. Of course, EJB3 will probably turn this discussion
>on its ear.
>
>If I totally missed your point, and you just wanted to know if Spring
>provided lightweight (sorry Hani) alternatives for the specification
>components that make up Enterprise Java Beans (EJB), namely:
>
>- Stateless Session Bean (yes, via service interfaces, pojos you write)
>- Stateful Session Bean (no)
>- Entity Bean (yes, via Hibernate, TopLink, iBatis, JDO passthrus)
>- Message Driven Bean (No, AFAIK)
>- Timer Bean (yes, via quartz)
>- Web Service Endpoints (yes, via http invoker, hessian, burlap, axis, m=
aybe
>others)
>
>
>
>
> =20
>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On=20
>>Behalf Of Garvey, Paul M (GE Commercial Finance)
>>Sent: Thursday, April 21, 2005 3:53 PM
>>To: spr...@li...
>>Subject: [Springframework-developer] EJBs vs POJOs
>>
>>All,
>>
>>I fairly new to Spring and I am currently reading some documentation=20
>>on it. I have bought into the concept of the lightweight feature of=20
>>Spring. I do have a quick question, Springs seems to handle every=20
>>scenario that I would
>>use EJBs, is there a few cases where EJBs are unavoidable to use? In ot=
her
>>words
>>are there any scenarios where Spring is just not the best tool to use a=
nd
>>EJBs is
>>the more suited? Any thoughts?
>>
>>Paul
>>
>>
>>
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real=20
>>users. Discover which products truly live up to the hype. Start=20
>>reading now. http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick
>>_______________________________________________
>>Springframework-developer mailing list=20
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>   =20
>>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dclick
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> =20
>

RE: [Springframework-developer] EJBs vs POJOs

[Garvey, P. M \(GE C. Finance\) <pau...@ge...>]

Dmitriy,
        I haven't had a chance to look at Spring EJB support as yet but =
it sounds
interesting, Will be reading about Spring support this weekend. IDEs =
such as JBuilder
makes EJB development very easy, testing aside, is Spring EJB support =
easier to code
than straight EJBs?=20
=20
Paul=20
=20

=20



-----Original Message-----
From: spr...@li... =
[mailto:spr...@li...]On Behalf =
Of Dmitriy Kopylenko
Sent: Thursday, April 21, 2005 6:25 PM
To: spr...@li...
Subject: Re: [Springframework-developer] EJBs vs POJOs


To put simply - if you absolutely require to physically distribute your =
application, EJB (SLSB facade) would probably be the good choice here. =
Please note that you still would want to use Spring-EJB support as it =
transparently exposes your POJO business interfaces as EJB =
implementations (via proxies) and also frees the application code from =
low level plumbing code related to EJB programming model e.g. JNDI =
lookups, etc. Coupled with IoC container (for DI) you get easy testable =
code with minimal dependence on EJB container.

Regards,
Dmitriy.

Garvey, Paul M (GE Commercial Finance) wrote:=20

James,

      Your response was insightful and you did partially answered my =
question.

Let me try to be a bit clearer, If I had to create an application that =
needed to

be distributed across multiple machines I would normally use EJBs =
(stateless Bean + Entity Beans)

or (stateless beans + DAOs) or (stateless beans + hibernate) etc. Could =
I use Spring

in this senario? Would it make more sense to stick with the EJB =
paradigm? I want to have a clear picture=20

in my mind of when to use Spring on a project and when to use EJBs. In =
other words,=20

when does it make most sense to use EJBs instead of Spring and vice =
versa?

Are there times when Spring is just not the solution to the problem and =
EBJ is?



Paul











-----Original Message-----

From:  spr...@li...

[ mailto:spr...@li...]On Behalf

Of James Cook

Sent: Thursday, April 21, 2005 5:25 PM

To:  spr...@li...

Subject: RE: [Springframework-developer] EJBs vs POJOs





Spring simply provides a convenient fa=E7ade to other persistence

implementations, including EJB!



You may have meant Entity Beans when you stated EJB. If so, another

way of wording your question is, "Are there cases when EJB is

preferred as a persistence mechanism over a POJO persistence

(Hibernate, TopLink, iBatis, JDO, EJB3, and dozens of others)

mechanism?"



Take these with a grain of salt, since I don't have hands-on

experience with all of the POJO persistence mechanisms. A few benefits

don't come easily to the world of POJO persistence.



a) POJO-based approaches (AFAIK) with the exception of EJB3, do not

support distributed security contexts. Even if you were writing an EJB

implementation, you would want to limit the number of network calls

your app has to make. But if you really have part of your application

on one machine, and part on another, you can invoke EJB's on the

various machines and remain within the same security context.



b) Clustered sessions are still the realm of the J2EE container.

Distributed caching of persistent object between machines is difficult

to achieve using POJO persistence.



c) Support for CORBA clients is a standard feature of J2EE.



There may be more. Of course, EJB3 will probably turn this discussion

on its ear.



If I totally missed your point, and you just wanted to know if Spring

provided lightweight (sorry Hani) alternatives for the specification

components that make up Enterprise Java Beans (EJB), namely:



- Stateless Session Bean (yes, via service interfaces, pojos you write)

- Stateful Session Bean (no)

- Entity Bean (yes, via Hibernate, TopLink, iBatis, JDO passthrus)

- Message Driven Bean (No, AFAIK)

- Timer Bean (yes, via quartz)

- Web Service Endpoints (yes, via http invoker, hessian, burlap, axis, =
maybe

others)









 =20

-----Original Message-----

From:  spr...@li...

[ mailto:spr...@li...] On=20

Behalf Of Garvey, Paul M (GE Commercial Finance)

Sent: Thursday, April 21, 2005 3:53 PM

To:  spr...@li...

Subject: [Springframework-developer] EJBs vs POJOs



All,



I fairly new to Spring and I am currently reading some documentation=20

on it. I have bought into the concept of the lightweight feature of=20

Spring. I do have a quick question, Springs seems to handle every=20

scenario that I would

use EJBs, is there a few cases where EJBs are unavoidable to use? In =
other

words

are there any scenarios where Spring is just not the best tool to use =
and

EJBs is

the more suited? Any thoughts?



Paul

















-------------------------------------------------------

SF email is sponsored by - The IT Product Guide

Read honest & candid reviews on hundreds of IT Products from real=20

users. Discover which products truly live up to the hype. Start=20

reading now.  http://ads.osdn.com/?ad_ide95 =
<http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick> =
&alloc_id=14396&op=3Dick

_______________________________________________

Springframework-developer mailing list=20

Spr...@li...

https://lists.sourceforge.net/lists/listinfo/springframework-developer

   =20





-------------------------------------------------------

SF email is sponsored by - The IT Product Guide

Read honest & candid reviews on hundreds of IT Products from real users.

Discover which products truly live up to the hype. Start reading now.

http://ads.osdn.com/?ad_ide95 =
<http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick> =
&alloc_id=14396&op=3Dick

_______________________________________________

Springframework-developer mailing list

Spr...@li...

https://lists.sourceforge.net/lists/listinfo/springframework-developer





-------------------------------------------------------

SF email is sponsored by - The IT Product Guide

Read honest & candid reviews on hundreds of IT Products from real users.

Discover which products truly live up to the hype. Start reading now.

http://ads.osdn.com/?ad_ide95 =
<http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dclick> =
&alloc_id=14396&op=3Dclick

_______________________________________________

Springframework-developer mailing list

Spr...@li...

https://lists.sourceforge.net/lists/listinfo/springframework-developer

 =20

Re: [Springframework-developer] EJBs vs POJOs

[Dmitriy K. <dko...@ru...>]

>  IDEs such as JBuilder
> makes EJB development very easy, testing aside, is Spring EJB support 
> easier to code
> than straight EJBs? 
>  

It certainly is :-) Here is a good place to start: 
http://www.springframework.org/docs/reference_1.2RC2/ejb.html

Regards,
Dmitriy.

Re: [Springframework-developer] EJBs vs POJOs

[Eugene K. <eu...@ja...>]

Garvey, Paul M (GE Commercial Finance) wrote:

> Dmitriy,
>         I haven't had a chance to look at Spring EJB support as yet 
> but it sounds
> interesting, Will be reading about Spring support this weekend. IDEs 
> such as JBuilder
> makes EJB development very easy, testing aside, is Spring EJB support 
> easier to code
> than straight EJBs? 

  Paul, don't you think that rely your development on IDE is a bad idea? 
I believe it is better to setup a common build process (XDoclet, 
MiddleGen, Cactus, Ant/Maven, etc) and do not rely on concrete IDE.

  By the way, I have strange feeling about current Spring's EJB 
convenience classes. The idea is that they will automatically lookup 
Spring's application context for you and then you'll use 
getBeanFactory().getBean() in onEjbCreate() method to pull pring-managed 
POJO. However it require java:comp/env/ejb/BeanFactoryPath env property 
to be set and also custom implementation setSessionContext() in order to 
make bean factory a singleton (I don't know who would want non-singleton 
factory?).
  So, we've ended up with our own EJBM helper classes (very similar to 
the Spring but without factory ) and a custom SpringLocator singleton 
that I'm using in onEjbCreate() methods instead:

public class SpringLocator {
    private static final ApplicationContext context = new 
ClassPathXmlApplicationContext( CONTEXT_PATH);

    public static Object getBean(String id) {
        return context.getBean(id);
    }
....

  In this case I don't have to override setSessionContext in every bean. 
That of course only makes sence and should be used only on facade beans 
(session/mdb or transaction) and all inner components should use DI and 
not locator.

  regards,
  Eugene

RE: [Springframework-developer] EJBs vs POJOs

[Garvey, P. M \(GE C. Finance\) <pau...@ge...>]

Dmitriy,
       Thanks for the link i will be reading this weekend between =
cutting my lawn :-)
Paul =20



-----Original Message-----
From: spr...@li... =
[mailto:spr...@li...]On Behalf =
Of Dmitriy Kopylenko
Sent: Friday, April 22, 2005 11:20 AM
To: spr...@li...
Subject: Re: [Springframework-developer] EJBs vs POJOs




 IDEs such as JBuilder
makes EJB development very easy, testing aside, is Spring EJB support =
easier to code
than straight EJBs?=20
=20

It certainly is :-) Here is a good place to start: =
http://www.springframework.org/docs/reference_1.2RC2/ejb.html

Regards,
Dmitriy.

RE: [Springframework-developer] EJBs vs POJOs

[Garvey, P. M \(GE C. Finance\) <pau...@ge...>]

I do use ant to build but now that I am getting familiar with appfuse I =
will
need to convince other developers who are using JBuilder to develop =
their EJB
apps. I have been using ant and IntelliJ for a a while now.=20





-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Eugene Kuleshov
Sent: Friday, April 22, 2005 12:21 PM
To: spr...@li...
Subject: Re: [Springframework-developer] EJBs vs POJOs


Garvey, Paul M (GE Commercial Finance) wrote:

> Dmitriy,
>         I haven't had a chance to look at Spring EJB support as yet=20
> but it sounds
> interesting, Will be reading about Spring support this weekend. IDEs=20
> such as JBuilder
> makes EJB development very easy, testing aside, is Spring EJB support=20
> easier to code
> than straight EJBs?=20

  Paul, don't you think that rely your development on IDE is a bad idea? =

I believe it is better to setup a common build process (XDoclet,=20
MiddleGen, Cactus, Ant/Maven, etc) and do not rely on concrete IDE.

  By the way, I have strange feeling about current Spring's EJB=20
convenience classes. The idea is that they will automatically lookup=20
Spring's application context for you and then you'll use=20
getBeanFactory().getBean() in onEjbCreate() method to pull pring-managed =

POJO. However it require java:comp/env/ejb/BeanFactoryPath env property=20
to be set and also custom implementation setSessionContext() in order to =

make bean factory a singleton (I don't know who would want non-singleton =

factory?).
  So, we've ended up with our own EJBM helper classes (very similar to=20
the Spring but without factory ) and a custom SpringLocator singleton=20
that I'm using in onEjbCreate() methods instead:

public class SpringLocator {
    private static final ApplicationContext context =3D new=20
ClassPathXmlApplicationContext( CONTEXT_PATH);

    public static Object getBean(String id) {
        return context.getBean(id);
    }
....

  In this case I don't have to override setSessionContext in every bean. =

That of course only makes sence and should be used only on facade beans=20
(session/mdb or transaction) and all inner components should use DI and=20
not locator.

  regards,
  Eugene




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] EJBs vs POJOs

[Thomas V. de V. <tho...@gm...>]

Personally I'd recommend Maven (http://maven.apache.org). Especially if=20
you're dealing with multiple projects.

On 4/22/05, Garvey, Paul M (GE Commercial Finance) <pau...@ge...>=20
wrote:
>=20
>=20
> I do use ant to build but now that I am getting familiar with appfuse I=
=20
> will
> need to convince other developers who are using JBuilder to develop their=
=20
> EJB
> apps. I have been using ant and IntelliJ for a a while now.
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Eugene Kuleshov
> Sent: Friday, April 22, 2005 12:21 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] EJBs vs POJOs
>=20
> Garvey, Paul M (GE Commercial Finance) wrote:
>=20
> > Dmitriy,
> > I haven't had a chance to look at Spring EJB support as yet
> > but it sounds
> > interesting, Will be reading about Spring support this weekend. IDEs
> > such as JBuilder
> > makes EJB development very easy, testing aside, is Spring EJB support
> > easier to code
> > than straight EJBs?
>=20
> Paul, don't you think that rely your development on IDE is a bad idea?
> I believe it is better to setup a common build process (XDoclet,
> MiddleGen, Cactus, Ant/Maven, etc) and do not rely on concrete IDE.
>=20
> By the way, I have strange feeling about current Spring's EJB
> convenience classes. The idea is that they will automatically lookup
> Spring's application context for you and then you'll use
> getBeanFactory().getBean() in onEjbCreate() method to pull pring-managed
> POJO. However it require java:comp/env/ejb/BeanFactoryPath env property
> to be set and also custom implementation setSessionContext() in order to
> make bean factory a singleton (I don't know who would want non-singleton
> factory?).
> So, we've ended up with our own EJBM helper classes (very similar to
> the Spring but without factory ) and a custom SpringLocator singleton
> that I'm using in onEjbCreate() methods instead:
>=20
> public class SpringLocator {
> private static final ApplicationContext context =3D new
> ClassPathXmlApplicationContext( CONTEXT_PATH);
>=20
> public static Object getBean(String id) {
> return context.getBean(id);
> }
> ....
>=20
> In this case I don't have to override setSessionContext in every bean.
> That of course only makes sence and should be used only on facade beans
> (session/mdb or transaction) and all inner components should use DI and
> not locator.
>=20
> regards,
> Eugene
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&opclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] EJBs vs POJOs

[Ben A. <ben...@ac...>]

James Cook wrote:

>a) POJO-based approaches (AFAIK) with the exception of EJB3, do not
>support distributed security contexts.
>
Not true! :-) Acegi Security System for Spring will happily and 
transparently move your SecurityContext from one machine to another when 
used with the RMI or HttpInvoker remoting protocols. It also offers an 
EJB equivalent run-as replacement capability if the remote bean operates 
in a different security realm (ie needs different credentials) than the 
caller's security realm.

> Even if you were writing an EJB
>implementation, you would want to limit the number of network calls
>your app has to make.
>  
>
Very true about the desire to limit network calls.

Cheers
Ben

RE: [Springframework-developer] EJBs vs POJOs

[James C. <jim...@do...>]

> -----Original Message-----
> >a) POJO-based approaches (AFAIK) with the exception of EJB3, do not
> >support distributed security contexts.
> >
> Not true! :-) Acegi Security System for Spring will happily and ...

Sorry Ben! Didn't mean to short-change Acegi. :-)