Actually an implementer of Distributed can create a SerialObjectFactory that contains itself, but there's no logical reason to do so.
Peter. ----- Original message ----- > ----- Original message ----- > > 1. I understand "Memento" is an interface and "ReflectiveMemento" - an > > implementation > > > > 2. Isn't just "Memento" too generic? > > > > DistributedObjectMemento? > > SerializableMemento? (to indicate implementations should support > > standard serialization)? > > It's a final class, there's only one implementation. Objects that > implement Distributed are required to create one during serialization, > when Distributed's method is called. > > > > > > > 3. A little different issue - did u find a way to serialize cycles in > > the object graph? Right now SerialReflectionFactory has the same > > issues as writeReplace()/ readResolve() > > Yes and no, let me explain. > > A SerialReflectionFactory cannot refer to itself, however it can contain > another SerialReflectionFactory it is equal to, in which case it will > refer to itself during deserialization, however in order to be equal, > each SerialReflactionFactory must also contain an equal > SerialReflectionfactory, in an infinite recursion, however because one > object instance can't occur in this structure more than once, an attempt > to create this structure will result in an OOME, with the exception of a > hand crafted stream, read on... > > Every instance of a particular Distributed object implementation will be > replaced in the Serialization stream by SerialReflectionFactory. Unlike > readResolve() the ObjectInputStream replaces all instances of a > SerialReflectionFactory with the object it creates, having established > that a SerialReflectionFactory could only refer to itself in a hand > crafted serialization stream, it still provides the Distributed object > with an opportunity to check its invarients during construction, the > Distributed object shouldn't throw an exception after calling an Object > superclass constructor to avoid creating a partially constructed object > an attacker can use, so it's important to check invarients using a > static method before Object superclass constructor is called. > > So yes, it's reasonably safe if you want it to be. > > Distributed objects don't implement Serializable and because they aren't > serialized, a Distributed object implementation can refer to itself, but > it's up to the implementation to wire up dependencies when its > constructor is called. > > It's quite a corner case though. > > You're welcome, cheers, > > Peter. > > > > > > Thanks, > > Michal > > > > On Thursday 26 of June 2014 20:53:03 Peter wrote: > > > Any objections to calling it Momento? > > > > > > ----- Original message ----- > > > > > > > You're sharp, so it is, that's a good one. > > > > > > > > ----- Original message ----- > > > > > > > > > It really is a Memento. Isn't it? > > > > > > > > > > Michal > > > > > > > > > > 23 cze 2014 13:24 "Peter Firmstone" <j...@zeus.net.au> > > > > > napisał(a): > > > > > > Distributed object use SerialReflectionFactory to recreate > > > > > > themselves remotely using one of their public constructors, a > > > > > > static factory method or builder object, however one thing > > > > > > about SerialReflectionFactory bothers me. > > > > > > > > > > > > SerialReflectionFactory is named after it's implementation, > > > > > > that is, it uses reflection. At some point in time, we > > > > > > might decide we want to use something other than reflection, > > > > > > in that case, the name would be inappropriate. > > > > > > > > > > > > How does DistributedObjectFactory sound? > > > > > > > > > > > > Has anyone got a better name? > > > > > > > > > > > > Regards, > > > > > > > > > > > > Peter. > > > > -- > > >
