[Quickfix-users] Quickfix 1.3 - Classloader problems with RMI-based JMX call

[Steve B. <st...@te...>]

> We currently have a problem with the latest release of 
> QuickfixJ 1.3 and wonder if you could throw some light on this please.

Hello Matthew,

This should be posted to the QuickFIX/J list (which I've CC'd on this
message). Please send further replies only to that list since this
list is for the C++ implementation. Thanks.

> ...
> I looked at the 1.3 source, in quickfix.ListenerSupport the 
> following code is executed.  (You are creating a dynamic 
> proxy to override the toString
> implementation)

Just FYI, the dynamic proxy is used to do callback dispatching
without requiring separate methods to iterate over the listeners
for each callback method.

The "toString" related code in the invocation handler is only there 
to provide a reasonable printed representation of the dispatcher 
proxy.

> ...
> One other point, I notice that there is only one 
> implementation of SessionStateListener (namely SessionAdmin): 
>  is there a good reason to load this from the context of the 
> calling thread.  Can you not do
> this.getClass().getClassLoader() instead?  You cannot do this 
> from within the constructor, but maybe you could have a 
> postInit() type method where you would be able to do this.  
> Without this, other people will face the same issue we do.

Currently the ListenerSupport class is only used with 
SessionStateListener but it will be used more widely in the
future. However, since the ListenerSupport class will only be used 
with interfaces from QFJ it's reasonable to use the ListenerSupport's
classloader for creating the proxy.

Can you make that small modification and try it with your
application to be sure there are no other issues?

You may eventually run into this issue with other third party 
libraries. Other option would be to the thread context classloader 
in FixApplication.start() to be the classloader that loaded 
FixApplication.class.

Steve