Input requested: spring context in web AND ContextSingletonBeanFactoryLocator

Hi,

So I have got the ContextSingletonBeanFactoryLocator working in my application insofar as having it right now in the business method itself to get the bean out that is gonna do the work and inject other beans into it, use advice, etc. The issue is that now I want to pull it up to a new layer of abstraction so I can properly use the ContextSingletonBeanFactoryLocator and only load the application context once.

I will be using the technique described in chapter 18 of the documentation of setting the bean factory locator inside the setContext method on the EJB.

So I think it means, in the web layer I have to have a spring container that I created in the servlet context, then inside that spring context I have the EJB's and use the jee:local-slsb stuff to configure the EJB itself. I am not sure though if that is right or not and I would like to have someone confirm if that is the correct approach.

In the application that I am integrating this into, they have what they call a 3-zone architecture of the web layer, a business SLSB layer, then a data-access SLSB layer, where no single call can traverse all the layers. I am really looking forward to being able to get rid of the current ServiceLocator and BusinessDelegate with the use of spring, but I need to figure out how the context is passed among the layers properly.

I think if the web layer has knowledge of all beans from JNDI and are configured with jee:local-slsb then the top layer has ContextSingletonBeanFactoryLocator inject the context, then the second layer will then just use the third-layer bean that was still defined in the original spring context, then that one also uses the ContextSingletonBeanFactoryLocator inside it to still have access to all the beans that I want to use (they are worker beans) and I can even do it a special way of making a hierarchical context to support their three-zone model, but is that going to work? Am I on the right track? Thanks for any input!

Alrighty! I got it working ;)

Loaded the root context at boot time of the servlet context with

Code:

---

<listener>
          <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  </listener>
        <servlet>
                  <servlet-name>context</servlet-name>
                  <servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class>
                  <load-on-startup>1</load-on-startup>
        </servlet>

---

Now ya don't need both, it'll actually give you an error when it boots. I haven't decided which is the better one to get rid of b/c now i have other servlets that are #2 in the load-on-startup queue.

Then, I have an EJB in that spring container, the delegate object that calls it:

Code:

---

<jee:local-slsb id="mySuperSearchWorker" jndi-name="ejb/com/cgi/psh/fid/fidentrysearch/SuperSearchWorkerHome"
                              business-interface="com.cgi.psh.fid.fidentrysearch.ISuperSearchFieldRetriever"/>
                             
                   
                    <bean id="mySuperSearchDelegate" class="com.cgi.psh.fid.fidentrysearch.SuperSearchDelegate">
                            <property name="mySuperSearchWorker" ref="mySuperSearchWorker"/>
                    </bean>

---

I followed their instructions with the EJB and I got the errors about "is not a local SLSB"... I read online about lots of people having the same problem. It was having problems in LocalSlsbInvokerInterceptor and that thing's abstract parent because the EJB spec says return EJBObject from the home interface when create method called, NOT EJBLocalObject!!! Silly spring guys. Anyhow, I patched those files and made it work now =). Here's my version of those files, got it to work in RAD with websphere 6.1... Not sure how but I will try to figure out a way to submit to the bug database or requests for change or whatnot. It is DEFINITELY BROKEN!

I found this has been changed in 2.5.5 and another change is in the CVS head above 2.5.5 as well for some app servers and EJB configurations.