| AW: [riena-dev] Race Condition on Client Startup |
Hi Christian,I have filed my issue as bug report: https://bugs.eclipse.org/bugs/show_bug.cgi?id=279303. But I am not sure, that it is really a bug.
Now to your questions:1. I am using the local protocol mainly for testing purpose. In our setup the Riena client is talking to remote services running as stateless session beans on a JBoss. During the development of a client dialog it is very annoying to always have a running JBoss. Therefore I introduced local services that mocks the remote services. The mocking is configured simply by adding another bundle that contains the mocks and declares them in the plugin.xml. My local protocol implementation detects all local services and then redirects any remote proxy call to the local mock -- very handy. 2. The service class that I am talking about is the interface to the remote service, the class that is proxied by the RemoteServiceFactory. Because I really don't like the idea of buddies (making every bundle that contains a remote service a buddy of hessian), I searched for another solution. I ended up with a new ClassLoader instance that combines two classloaders into one: the classloader of the bundle that contains the remote interface and the classloader of riena.communication.core. This classloader is used a context classloader during the call of proxyFactory.andStart(), allowing hessian to create a proxy object for the interface.
The more I think about it the more I am getting sure that your proposal of defining buddies would prevent the createLazyProxy method from failing, because then the class could be loaded. But I prefer my workaroud, because I do not need any buddies at all.
I think it would be a good idea to extend the ProxyFactory with a new method 'usingClassLoader' to be able to define the classloader that should be used during the creation of the proxy. That classloader could be given to hessian and that classloader could be given to the RemoteProxyFactory as well.
Best regards, Olaf