Solution: implement an asynchronous job (where the job execution service make sure that OOo doesnt terminate) ... or register a listener inside OOo to be notified in case the frame or the whole office will be closed.
If I use asynchronous job can I reference my Server class and call functions on it from within openoffice ? On 11/9/06, Andreas Schlüns <[EMAIL PROTECTED]> wrote:
Tabish F. Mufti schrieb: > I have an Addon in Java and using the ProtocolHandler scheme I start a > Socket Server. Once the protocol handler is executed the server is created > inside a Thread and left on the jvm to be executed but I think I lose a > reference to this server as the ProtocolHandler will just execute a > function > and return. > > Is this behaviour ok or is the server a zombie process now which can exit > anytime the garbage collector comes and picks up the server object. > ProtocolHandler are designed to be multi-instance UNO components. Means: everytime an URL (where a ProtocolHandler is registered for) is triggered by the UI a new instance of such handler will be created, used and released. There is a special hint inside the DevelopersGuide ... saying: "A protocol handler can be implemented as a singleton, but this poses multithreading difficulties. In a multithreaded environment it is most unlikely that the initial frame context matches every following dispatch request. So you have to be prepared for calls to initialize() by multiple threads for multiple frames. A dispatch object can also be used more then once, but must be bound to the target frame that was specified in the original queryDispatch()call. A change of the frame context can cause trouble if the protocol handler returns itself as a dispatch object. A protocol handler singleton must return new dispatch objects for every request, which has to be initialized with the current context of the protocol handler, and you have to synchronize between initialize() and queryDispatch(). The protocol handler would have to serve as a kind of factory for specialized dispatch objects. You can avoid these problems, if you write your protocol handler as a multi-instance service." If you create a thread and return from the dispatch() nobody inside OOo knows your implementation any longer. Only the Java VM hold your thread alive. So it can happen that the office trys to terminate and your VM will be terminated also (hardly!). Solution: implement an asynchronous job (where the job execution service make sure that OOo doesnt terminate) ... or register a listener inside OOo to be notified in case the frame or the whole office will be closed. Regards Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
