Internal AbstractController State

[adrian.brock]

I can see having the abstract controller state protected is a bit dangerous
given the recent changes for the Scoped Kernels.

So I've changed all the state to private with documented protected methods
for subclasses to use.

The reason I say it is dangerous is because there is more to updating a context's
state than allContexts. There are other "indexes" where the context could exist.

Besides this new api looks wrong to me anyway, I documented it in a TODO

 // TODO This api looks broken and unsafe
 // 1) It should not be public
 // 2) There should be parameter checking for public methods
 // 3) There should be locking when updating state
 // 4) Error handling?
 public void addControllerContext(ControllerContext context)

The way to make more dangerous operations available to subclasses
would be through some helper class that is only protected accesible.

e.g.

private UnsafeInterface unsafe = new UnsafeImplementation();

protected UnsafeInterface getUnsafe()
{
 return unsafe;
}

protected interface UnsafeInterface
{
 // Methods intended for subclasses that know what they are doing here
 // Properly documented to explain requirements, e.g. locking
}

private class UnsafeImplementation implements UnsafeInterface
{
 // Implementation of potentially unsafe methods, but still does some checking
 // like null parameters or reasonable error handling so we don't end up
 // with a subclass breaking the whole system.
}

There is a similar trick that is the reverse where you define a wrapper interface
that only exposes safe methods and make the real implementation
unreachable (you always hand out the wrapper externally).

[adrian.brock]

The reason I say it is dangerous is because there is more to updating a context's
state than allContexts. There are other "indexes" where the context could exist.

I'm actually currently changing it so you can have a name->context
in the allContexts which doesn't exist anywhere else.

These will be aliases.

So that will be even more work do in the scoped kernel,
i.e. move the aliases as well as the main name/context.

This says to me that we need a well defined api for these operations
(register/unregisterControllerContext) where this, future enhancements
and subclasses can plugin their new knowledge.

[adrian.brock]

I've added a protected [un]registerControllerContext(ControllerContext)
for the alias handling.

This works when invoked from the [un]installed methods,
but it does not handle maintinaing or clearing up the other internal state
for the context (there is none for aliases).