Hello, again, Miro.
I do not think the approach you suggested will work as you want. Although conceptually your idea is fine, in practice there will be problems. A reference to a normal Java object, which the callback handler implementation object is, cannot be passed to another JVM on another system, which the server is, and then be called back quite so simply, for a number of reasons. The most important one is that there would need to be logic in the client that would be able to receive incoming remote method invocations from the server. This is more complicated than the EJB on the server just invoking a method on an object passed from the client.
Such things are certainly possible but not automatic.
Instead, you might want to consider this: If the client will not know in advance what questions to ask the user, perhaps you can define your own callback request objects and interfaces for the types of questions the server will want the client to ask the user. These would be conceptually similar to the security callback requests you are familiar with from the app client security callback model, but you would create the specific callback request types that the EJB and the app client would both use.
Returning to my earlier suggestion of splitting the original EJB method into two different ones, the first method could return an array (or List, for example) of your callback request types. The client could determine from the types of the callback requests returned by the EJB what questions - if any - to ask the user (perhaps the text for each question would be part of the callback request). Once the app client gathered the user's responses to those questions it would pas them back to the second method on the EJB.
Again, this might not be ideal but it may work for you.
- Tim
[Message sent by forum member 'tjquinn' (tjquinn)]
http://forums.java.net/jive/thread.jspa?messageID=273277