Hi Mark; I understand from the spec is that child managers can access to the parent's bean and observer instances but not its siblings. So we have to separate their NotificationManagers via "new" keyword. Because, NotificationManager class has some instance variables that hold managers observer instances.
But as for InjectionResolver, it does not define any instance variables and its sole purpose is to find components using the Manager. So it is not necessary to create new InjectionResolvers for child managers. Thanks; Gurkan ________________________________ From: Mark Struberg <[email protected]> To: [email protected] Sent: Saturday, April 25, 2009 2:59:56 PM Subject: ChildActivityManager problems Hi folks, need your help :) I'm not sure if my implementation of the ChildActivityManager leads into the right direction, so I need a bit reflection about this! The basic idea behind the creation of child activities is to form a 'tree' of Manager instances where every child Manager derives information from the parent Manager, but isolates it's own specialities from it's parent. The implementation trick behind the ChildActivityManager was to keep references 2 a freshly generated ManagerImpl (self) and to the parent Manager, and then doe some kind of 'conditional' delegation pattern. What I didn't thought off was the fact that ManagerImpl currently has notificationManager and injectionResolver not via new() but as singletons. injectionResolver = InjectionResolver.getInstance(); notificationManager = NotificationManager.getInstance(); which means that we currently have no chance to isolate information between child and parent Mangers, isn't? Imho ManagerImpl itself is a singleton, so it should be no problem to change this to 'new InjectionResolver()' and 'new NotificationManager()', but I'd like to have your ok before I change this very basic parts! txs and LieGrue, strub
