Hi suhail;
I appreciate you feedback here is some additional information that will help you understand why we are pursing the LifecycleListener implementation.
the third party api that I am calling is a Tibco/RV communication to a remote application that responds back asynchronously to the caller after being called. That being said I need to spin a Thread, make a call to the third party api, and wait for the multiple responses back from the call. This unit of work does WORK inside the EJB. I have a ProofOfConcept, but since I am creating a Thread, and opening a socket or the third party api is, this is a major [b]NO NO[/b] according to the EJB specification, which is why I was pursuing the LifecycleListener implementation in the first place.
Doing this unit of work inside a MDB is also prohibited by the EJB specification, I believe?
The documentation you sent I've seen and it shows how to initialize your LifecycleListener, which I've been able to do. It does not however show how an EJB or MDB would call into the LifecycleListener bean. This is where a lot of my misunderstanding is.
I put a static synchronized method on my LifecycleListener implementation class and had my EJB call, but since they reside in different ClassLoaders the initialization values to the third party are always null.
If I could see how clients are calling the LifecycleListener in code I may be able to understand the real purpose of the LifecycleListener. It appears to me that the LifecycleListener creates resources only and how communication gets to the LifecycleListener bean I don't understand. Does it put something in the JNDI tree so then the EJB/MDBs can get a hook to it from there???
Thanks for your knowledge
Regards
Peter
[Message sent by forum member 'peterdelaney' (peterdelaney)]
http://forums.java.net/jive/thread.jspa?messageID=342557