Extend deployer to build generic proxy for beans in a "foreign" application context

[dsyer]

In the deployer we have some utilities for executing code reflectively in a "foreign" application context (i.e. one in a different classloader). We use SpEL and that's a pretty nice way to execute code, given that we can't actually use the Java APIs of the foreign objects directly. E.g. (from FunctionCreatorConfiguration):

Object catalog = this.runner.getBean(FunctionCatalog.class.getName());
Set<String> functions = (Set<String>) runner.evaluate("getNames(#type)", catalog, "type", Function.class);

What would be really cool, though, would be if you could just as for an object of a specific type, and then call its methods locally. E.g.

FunctionCatalog catalog = this.runner.getBean(FunctionCatalog.class);
Set<String> functions = catalog.getNames(Function.class);

To do this we would need a new method getBean() that builds a proxy for the type passed in. In the proxy we have to do type conversion between the two classloaders, e.g. in the call to getNames() above we would have to convert the Function.class to the class with the same name in the foreign class loader. The conversion mechanism remains to be implemented, but it could start with a few well-known patterns (like classes) and be extended later.

Ultimately we would like to be able to "borrow" services like MessageConverters from the foreign (user-defined) ApplicationContext and apply them to objects in the runner's context.

[olegz]

Interesting, I actually have experimented with similar idea on one of my branches from a while back, although I think I did it a bit differently. Basically extended implementation of the existing FunctionCatalog where "foreign" FC is injected into it and when lookup is performed it is performed in both returning you a function. Perhaps it's time to dig it up