Should all users of SecuritySystem be given a Token

[jamoore]

or at least all users of those methods which (could) require tokens. For example, the method:

   securitySystem.addLog();

used by EventLogListener could take a Token that was injected into the EventLogListener instance.

However, before we go to far down this road, we may just want to use the Java SecurityManager.

[jmoore]

r786 introduces an extraordinarily simple Token class. Actually the simplest possible class:

   public class Token {}

It's completely inert (so even subclassing it should be harmless). Tokens can be instantiated but should be kept in a private field and never shared, and used to represent a loose form of ownership.

Do we need something more like this?
​http://java.sun.com/docs/books/tutorial/security1.2/userperm/index.html

[jmoore]

r812 takes this a step further an introduces a SecureAction which temporarily adds a token to an object.

[jmoore]

merge() causes a copy of our IObjects to be made. This breaks the token concept. Currently, quick-fixing by allowing a hook into SecuritySystem from MergeEventListener but this is becoming nasty. A ThreadLocal approach similar to SecurityManager maybe better (though there are issues with object identity on merge. Perhaps #54 UUIDs again? )

[jmoore]

Now treating this as the GraphHolder/Token umbrella: r823 fixes GraphHolder serialization. Can still be optimized to lazily load now that the final is gone.

[jmoore]

Rescheduling with #328, but closing with will not implement. The token functionality is sufficient as it stands, but there's no benefit to giving out more tokens ; the interfaces just need to be improved.