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

[Colin S. <col...@ex...>]

Actually, you can quite successfully use the BeanFactoryLocator variants 
to share the same ApplicationContext or BeanFactory instance(s) across 
multiple EJBs in a webapp. I am doing this in JBoss (although happilly 
am almost done removing all ejbs). Just override the default 
setSessionContext in a fashion similar to:

  /*
   * (non-Javadoc)
   * @see javax.ejb.SessionBean#setSessionContext(javax.ejb.SessionContext)
   */
  public void setSessionContext(SessionContext sessionContext) {
    super.setSessionContext(sessionContext);
    setBeanFactoryLocator(ContextSingletonBeanFactoryLocator.getInstance());
    setBeanFactoryLocatorKey(ServicesConstants.PRIMARY_CONTEXT_ID);
  }


then if you want to delegate to a real POJO service doing the work, you 
would also have something like:
  /*
   * (non-Javadoc)
   * @see 
org.springframework.ejb.support.AbstractStatelessSessionBean#onEjbCreate()
   */
  protected void onEjbCreate() throws CreateException {
    _appController = (ApplicationControllerService) 
getBeanFactory().getBean(
        CORE_SERVICES_APPLICATION_CONTROLLER_SERVICE);
  }


where _appController is the pojo service object all methods will 
delegate to.  As for passivation/activation, it's not an issue for 
stateless beans, as those are not legal states. For stateful beans, you 
will get an unload and reload on the passivation/activation, but this is 
not for real if there is already a shared instance, all that will be 
unloaded/reloaded is the reference to the shared context/beanfactory.

Regards,
Colin


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
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>