Re: [Springframework-developer] EJBs and their Bean Factories

[Luke T. <ne...@fr...>]

Unfortunately migration to an entire Spring solution isn't always an 
option for political reasons - my current client has invested a lot of 
time reading EJB books and I don't think they'd swallow it if I said we 
were going to ditch them altogether. I'm just using local stateless 
session beans which do nothing other than delegating calls to other 
business objects, but they aren't really serving any purpose other than 
getting in the way of a nicely configured application.

Maybe I'll try extending JndiBeanFactoryLocator and implement 
createBeanFactory to just load the bean factory once, then set the 
locator in my EJBs. I'm only using stateless beans and I don't really 
care about the spec if it works... or perhaps I'll just bite the bullet 
and suggest that we get rid of them altogether.

Alef Arendsen wrote:

>>Looking at the code for the EJB base classes, unless I'm missing
>>something obvious (not unheard of), it seems that by default a separate
>>bean factory is created for each bean instance.
> 
> Well, to put it bluntly: you're not mistaken; it's the way it is.
> 
> As far as I'm concerned, the issue basically is that without violated any
> rules that apply to implementing EJBs, it's just not possible to get an
> ApplicationContext shared across multiple multiple beans of different types,
> not even across multiple instances of the same type. 
> 
> For one because resources instantiated as fields of EJBs should either be
> serializable (which the ApplicationContext isn't, not even mentioning any
> beans inside it), or transient (or closed and thrown away on passivation). 
> 
> Another solution would be (and I hate to say this, but this is what we're
> currently using in one of our applications that is still based on EJBs but
> in the process of being migrated to Spring) to bind the context in a JNDI
> tree, but here, the Serializable argument also applies. So that (when
> applying the rules really strict) is one to throw away as well.
> 
> Of course when using certain EJB container, you won't have to worry about
> serializable issues when not accessing the JNDI from outside the VM the
> server is running in. Also, having the ApplicationContext defined as a
> singleton or something (ughh!) wouldn't result in too many problems using a
> simple EJB container, but I guess that's not really an option we (Spring)
> are eager to offer. The same applies to providing an approach based on
> static fields.
> 
> Ohh, there is something like the BeanFactoryLocator, but this only reads in
> BeanFactory I believe.
> 
> Basically my approach is to avoid the use EJBs where possible and if needed,
> implement an EJB using Spring's EJB layer and don't worry about one or two
> applicationcontexts too much being created. I mean, afterall, one of the
> reasons I choose Spring in the first place is to be able to get rid of EJBs.
> (I won't start a rant here, that might just be personal ;-).
> 
> I don't know if this satisfies or if somebody else has opinions?
> 
> Alef
> 
> 
> 



-- 
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk