Recursive plunge inside sun CORBA code?

Question

I'm seeing a stack overflow from a recursive plunge inside
com.sun.corba.se.impl.protocol.CorbaServerRequestDispatchImpl.dispatch()
with both JDK 1.5 and JDK 1.6.
Sure enough, at line 214 in the source is a recursive call, preceded by
a comment that seems to indicate it shouldn't be a problem:
        // Destroyed POAs can be recreated by normal adapter activation.
        // So just restart the dispatch.
        dispatch(request);However, request is the same as the original argument to dispatch, so a recursive
plunge isn't unexpected! Is that code really correct?
Being a CORBA novice, I'm sure I'm doing something odd that results in
this particular path being taken in dispatch(), but because of the stack overflow,
I haven't been able to trace down exactly what in my code is resulting in reaching
line 214, but it appears related to breaking a CORBA connection. (The application
is multi-threaded application that is connecting/unconnecting to/from multiple
applications.)

Answer 1

Hi Mike,
Thanks for your suggestion. Making the interface local was the first thing I tried. (In fact, I started out with a local interface.) The strange thing is that the servlet cannot resolve the interface when it's local. That's why I made the interface remote. But now I know this only makes things worse.
So the real problem is probably my JSF servlet that doesn't resolve the local interface in the EJB JAR. In fact, it seems all EJB annotations are ignored in the servlet. Even the remote interface could only be resolved "manually" (via an JNDI lookup, using a InitalContext, etc.) Is there any known issue with EJB annotations in JSF servlets?
(By the way: it was hard to find information on the CORBA MARSHAL error. Perhaps this error can be clarified somehow in a newer version of TopLink (Essentials). At least a warning about this happening in the TopLink documentation should be nice.)
Anyway, thanks for your prompt reply. I hope you (or someone else) has some suggestions on how to getting things working the proper way (with a local interface). Do you think it will help to deploy both modules in a single EAR file instead of deploying them as separate JAR and WAR?