injection SFSB to SLSB

[mindflyer]

I have SLSB (TdwsPrinter) and SFSB (AdminPrintTask). TdwsPrinter uses AdminPrintTask (it invokes methods and then @Remove method). Sometimes they work correctly, sometimes I see error such as "Could not find SFSB jboss.j2ee:service=EJB3,name=AdminPrintTask; key: 3j001-pmol3k-fee00im0-1-fee4izq1-20".
I investigated in debug mode and saw that JBoss injects reference to AdminPrintTask only when JBoss creates instance of TdwsPrinter. This proxy-object has guid of instance of AdminPrintTask - and when I invoke TdwsPrinter second time then JBoss can't find AdminPrintTask with old guid because that instance was destroyed.
I thought that container must reset state of SLSB after each invoking.
May be, Do I use injection incorrectly?

@Stateful(name="AdminPrintTask")
@Remote(AdminPrintTask.class)
@Local(AdminPrintTask.class)
@Cache(DestroyOveragedCache.class)
@CacheConfig(maxSize = 2000, idleTimeoutSeconds = 1800, name = "topdog2.ejb3:service=EJB3SFSBCache")
@SecurityDomain("td2")
@PermitAll
@Depends({"topdog2.reports:target=BirtService,protocol=local,service=proxyFactory,type=adaptor"})
public class AdminPrintTaskBean implements AdminPrintTask {
...
}


@Stateless(name="TdwsPrinter")
@Local(TdwsPrinter.class)
@SecurityDomain("td2")
@PermitAll
@Depends({"topdog2.reports:target=BirtService,protocol=local,service=proxyFactory,type=adaptor"})
public class TdwsPrinterBean implements TdwsPrinter {
 @EJB(mappedName = "AdminPrintTask/local")
 private AdminPrintTask taskBuilder;
...
}

PS: JBoss 4.2.2

[xmedeko]

I have a similar problem with JBoss 5.0.1 GA. I have one SFSB (which holds some data) with only local business interface . And several SLSBs with remote interfaces. All SLSBs inject the SFSB using @EJB. I have a standalone Swing client accessing the SLBS. I have observed that:

- Each SLSB inject new SFSB although the session is the same.

- When the session is removed (by a business method marked as @Remove), the next call to a SLBS throws "javax.ejb.NoSuchEJBException: Could not find stateful bean: all5z-81lkw2-ftl86qub-1-ftl9srgf-a0". I suspect (like the previous post), that @EJB is not refreshed each time the SLBS is called, but only when it is created.

Is this a normal behaviour or a bug?

[xmedeko]

Hmm, I think injecting of SFSB into SLSB is a wrong design:

http://www.coderanch.com/t/436872/EJB-Other-Java-EE-Technologies/java/Dependency-injection-stateful-session-beans

[xmedeko]

Hmm, I have changed my all SLSBs info SFSBs, but it didn't help my problem. If fact, I need something like http session, but for session beans called from Swing client. I.e. the client calls a several session bean, they gets some object which are related to this client (a quick operation) and then make some lengthy operation, like accessing DB or the local filesystem.

Yes, if I will have just one SFSB, then it would work for me. However, I'd like to have more remote interfaces just to have the code logically separated, since I have a quite few business methods to call.

Thanks for any help
Andy

[itsme]

Just a possibility to get rid of this problem could be to transfer the session informations between the client and server (like cookies). If this would be to big, you can also maintain all session information on the server side (database) and just transfer the session id.

We are using the second approach where the client sends with every request his session id to the server. This can be done by facading the already written ejb's with another ejb but needs change in every server request at client side.

Hope this helps in a way.

[xmedeko]

Well, then I do not see, why SFSBs exists. I have hoped they can do this for me.

[xmedeko]

I fact, when I use just one SFSB, then it works fine, just I have many methods there and sometimes ugly names like getCountForAAA(), getCountForBBB(). I still cannot believe there is not any nice easy way how to break my code into more objects :-)

[xmedeko]

Well, this probably point into the soltion:

http://www.jboss.org/index.html?module=bb&op=viewtopic&t=73311

Proxies to the session beans must be serializable, so they can be used to pass around ...