Michael Hunger wrote: > 2) So I noticed the real bug which was the duplicate instantiation of a > service, that ocurred during the passivation phase. > > The current service (ServerRemoteEntityStoreMixin) unbinds in the passivate > the Registry which is the problematic > service under observation. The problem is the registry was already passivated > so the serviceInstance instance variable > inside ServiceReferenceInstance was already null. So on invocation of the > unbind() method a new registry was created on > which the unbind was called - which then failed because in a newly created > Registry there is nothing bound to be unbound. > > Problems to be solved: > > 1) handle the object methods (equals, hashCode, wait, notify(All), toString) > not by directing them to the proxied > service (or in other cases entity) but rather have the CompositeInstance or > ServiceReferenceInstance handle them. > > 2) Have the passivation sorted out somehow. Either raise Exceptions on calls > on passivated composites. Or sort the > passivation that way that the higher level components can still access their > dependencies. Funny to get around with > cyclic dependencies. The problem is you never know which cleanup operations > are performed on services. Or have all > services be self-contained to that no external cleanup / resource release is > necessary.
I've been working on this one too, and it's not trivial to figure out how to do. I think the theoretically correct way to do it is to let both the entity store AND the registry do the unbind, at least if passivation is supposed to be happening not only on application passivatio, but anytime during the application lifecycle (i.e. parts of it can be activated/passivated many times). Requires more thinking. /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
