Then the RPCMessageInterface class would parse this config file on startup. When a request comes in, it would invoke the run method as it does currently.
Ok I'm going to be once again umpopular...
[Q] Do we really need this? [A] Not now and maybe not at all.
I'd think about it actually, building a config-based XML-RPC layer is not hard at all, and it would allow for a much more flexible approach in the future. There is at least another very important concern that this approach might solve: security. I might not want a user to be able to mess around XML-RPC calls without the sysadm knowing about it. I (agreed, not now) might want to have an ACL-based system, where I can specify what calls can be made by a user and its role. Having a more robust XML-RPC interface, based on a configuration file and on a Factory pattern, would allow for security checks to be added later on, not to mention other cool stuff. :-)
As per your objections:
> - this solution is more complicated than simply referencing a method by its full path
Yes. But this is *really* dangerous too. Security wise any class could be loaded, since what is done is just a Class.forName(), with no checks at all. Find somehow your way to the server, put in the classpath i.will.hack.you.UA430wn3d with a bad execute(HashMap map) method (or don't really care about execute(), just use the default constructor to mess up things), call it via the XML-RPC interface and you're in. A bit too easy for my personal taste: there are too many Tomcats around running as root.
> - this solution requires the user to edit some config files (copy/paste errors).
> - this solution requires the user to take care of the uniqueness of the keys
The user in this case is a sysadm that is supposed to know what she's doing. And we are talking about a use case (extending the XML-RPC interface) which is pretty peculiar and won't happen that often, so I don't really think of this as an issue.
I hear another concern: "let's finish this stuff before delving into new subjects". Damn, I agree. But this is not a very complicate thing to do, it's just a matter of deciding where and how to set the configuration and hack on the RPC interface: the first implementation might be rough, but then we might easily switch to something more robust (Avalon?). But it might also save our butts later on. Heck, we'll have to think about security sooner or later, don't we? :-)
Opinions?
-- Gianugo Rabellino
