Hi Patric, Thanks for the bug fix. I have fixed it and made the changes to RMInvoker (with Encapsulating the StorageManager using protected methods ) as you have mentioned. As you pointed out, now the sub classes can use alternative implementations to monitor the queue and invoke services.
RMInvoker is only used in the server side and that is the reason why we instantiate a ServerStorageManager instead of passing it to the constructor. So far this seems to be ok. Hope you have customized Sandesha and it is working fine :) Thanks again for the feed back. Regards, Jaliya -----Original Message----- From: Patrick Collins [mailto:[EMAIL PROTECTED] Sent: Saturday, May 21, 2005 2:41 AM To: [email protected] Subject: Sandesha: RMInvoker Hi, I have attached a minor bug fix to the RMInvoker class. public void run() { while (true) { try { Thread.sleep(Constants.RMINVOKER_SLEEP_TIME); RMMessageContext rmMessageContext = ... // **** this will cause NPE is rmMessageContext is null AddressingHeaders addrHeaders = rmMessageContext.get... if (rmMessageContext != null) { rmMessageContext.getAddressingHeaders(); // **** should be here // AddressingHeaders addrHeaders = rmMessageContext.get... The attached file contains some refactoring of the run method to allow for subclassing. My issue is that I am not using the JavaProvider to handle my actual invokes. I also moved the Thread code into the class itself (startInvoker method). Running in a J2EE environment, I cannot always create new Thread objects. The startInvoker method would allow subclasses to use an alternative impl (ie: WorkManager) for watching the queue. Ideally, the RMInvoker wouldn't implement Runnable at all - but could certainly create one internally as needed. I have also attached the updated version of RMInitiator per this change. My other suggestion would be to pass the IStorageManager impl to the required server classes (as is done with the ClientStorageManager). So in this case, the RMInvoker would change to accept the IStorageManager in its constructor. I did not make this change (as it cuts across a number of other classes as well). In addition, I encapsulated field access to the storageManager member (via a protected getXXX method) so I could access it from my subclass (although alternatively, I could have just created a new ServerStorageManager instance in the subclass). Regards, Patrick
