how does the non faces request access the slsb? if that doesn't happen through a servlet that is filtere with the seam filter, @In won't work anyway. if it is filtered the PC is closed during the emulated jsf life cycle of the filter.
Thanks for you help we this.
The non faces request use remote interface to the SLSB.
My understanding is that the injection is working as all the SLSB's have a ejb-jar.xml with the SeamInterceptoe defined
<interceptor> <interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class> </interceptor>
My app is working with both Seam JSF+SFSB Client and an old Servlet Client using the same SLSB layer. I am just failing to understand the how it is working! Also what would happen if just a simple remote java client accessed the SLSB layer... how would seam know to close off things once the remote call had been made?
The SeamInterceptor injects stuff. But it needs something to inject, which is the values that are stored in the Seam contexts. So if the contexts are not there, it doesn't work. And without the Seam request filter, or a request to the JSF servlet, you won't get the contexts.
I understand that I can't inject stuff that is not there.
In my example the "bookingDatabase" would be there as it is defined in components.xml as an application wide thing (I assume). This is as per the manual.
@In EntityManager bookingDatabase;
To give you a little more background... we have a big app that uses basic ejb3 SLSB for the business layer. The existing Servlet front end is talking via Remote calls to this fine. We are in the process of moving towards Seam and have a new layer on top of the BL utilising Seam SFSB's and JSF. This is also working fine. The problem is that we want to use avoid LazyInitialiastion problems when the existing BL layer returns objects with lazy relation ships (to the Seam layer). If we use the Seam-managed persistence context this works. However I want to understand how this works when a normal client JVM calls the EJB's.