WhiteCat: a little octopus merge with several features

Today I pushed a little octopus merge (three branches) I have developed during last nights. This commit introduces a new set of features in the WhiteCat framework; such changes are for a long term view of the project and do not touch heavily the user's interface.

First of all now there are a few JUnit tests that, besides testing the framework, can be used as examples for understanding how WhiteCat internally works and how facilities and APIs should be used.

Then comes the support for a customizable proxy cloning. In the past, when a role manipulation was completing, WhiteCat invoked the updateProxy method on a proxy handler in order to copy the proxy status from the old instance to the new one. This works fine if the proxy and the proxy handler are tied together, since the proxy handler will not copy any "extended" status it is not aware of. This is fine for WhiteCat to work, but is not useful for a developer that wants to develop its own proxy class. To solve the problem a new interface has been added, ICloneableAgentProxy, that if applied to a proxy instrument WhiteCat to clone the old proxy instance. Please note that the cloning is manual, that is on the proxy developer, since it is not possible to use the standard Java cloning methodology since this will not allow WhiteCat to work and manipulate proxy classes. To summarize, if you have defined a new proxy and want to keep its internal status, use the ICloneableAgentProxy interface and implement the cloneAgentProxyState(..) method to control the copy field by field.

But how can a developer install his own proxies in the system? Here comes another interesting new feature: WhiteCat now can be fully configured using Spring! This means that the old configuration, based on properties, is no more used (and is deprecated) and it is possible to specify exactly which classes instances should be used as proxy handlers, agents, and even as role booster (so this means you can implement your own!). Of course, introducing Spring lead to a deep refactoring of the main internal structures in order to support dependency injection. The result is that now there are a lot of different interfaces, one for each configurable component.

There is now also a unique factory, implemented by the WhiteCat class. This is not a way to remove factories for configurable objects, but to have a single entry point to get an object instance. The idea is that each object should be created by its factory, and the factory itself should rely on Spring, while the WhiteCat class exposes a common interface to all the factories.

Finally, the most difficult change, is the introduction of a RoleOperation, a wrapper around all role manipulation informations (which agent, which proxy, which role, etc.). This is deeply used by the current role booster implementation, and this means that the booster is now instrumented by such role operation. This is a not fully completed implementation of the Command Pattern; it is lacking the execute command way, that could be added in the future. The adoption of the role operation abstraction opens new ways: it will be possible to fully implement a command pattern, to queue and manage multiple role operations, and to keep a track about who asked for what and what was the result.