quick follow-up to my previous post. >Hello there, > >it seems that service invocation over an RMI binding in Tuscany 1.6 does not go >with the best practice of loading contributions through a dedicated >ClassLoader, >and not putting them on the local application classpath. > >This is a severe problem that I am afraid could make the RMI binding almost >useless.
I retract that unnecessarily strong wording. Let’s say “awkward to work with”. [snip] >I guess a way to make this work correctly would be for Tuscany to use its own >RMI registry implementation, instead of >sun.rmi.registry.RegistryImpl. But that seems pretty radical. Another approach >might be to change the RMIReferenceInvoker >so that it does not use Class.getMethod() directly but implements a modified >sort of reflection where the >parameter types are compared by name and not by identity. That second suggestion would not work, as there would not be a way to convert the actual parameters from one class to the other. I’ll have to split up my contributions and put every class that occurs as a method parameter on the application classpath. I think that’s a restriction worth pointing out. It’s not really to do with Tuscany, but as far as I can see just a consequence of how RMI works. n Sebastian IDS Scheer Consulting GmbH Geschäftsführer/Managing Directors: Kamyar Niroumand, Ivo Totev Sitz/Registered office: Altenkesseler Straße 17, 66115 Saarbrücken, Germany - Registergericht/Commercial register: Saarbrücken HRB 19681 http://www.softwareag.com
