The longer I think about this, the more I get the ugly feeling that we somehow should think about the question if all the singletones in WebBeansFinder are a good idea?
If we have more than 1 Manager in the system, we have to tell _every_ call which Manager to use. I'm not sure if 11.6 is really precise enough to understand all the complexity in it. So I'll let this rest till the very evening and head over to OpenEJB integration once again ;) LieGrue, strub --- Gurkan Erdogdu <[email protected]> schrieb am Mo, 27.4.2009: > Von: Gurkan Erdogdu <[email protected]> > Betreff: Re: ChildActivityManager problems > An: [email protected] > Datum: Montag, 27. April 2009, 8:44 > Hi Mark, > > >>So we have to change this to first get the current > Manager and then get > the NotificationManager from there. > I think same. > > Gurkan > > 2009/4/26 Mark Struberg <[email protected]> > > > > > Hmm, got stuck again and have to go offline too now. > > > > The problem I spot now is in the > > DefinitionUtil#defineObserverMethods line 1077: > > > > > NotificationManager manager = > NotificationManager.getInstance(); > > > > So we have to change this to first get the current > Manager and then get the > > NotificationManager from there. > > I will be online again in the evening ~20:00 CEST. > > > > LieGrue, > > strub > > > > --- Gurkan Erdogdu <[email protected]> > schrieb am Sa, 25.4.2009: > > > > > Von: Gurkan Erdogdu <[email protected]> > > > Betreff: Re: ChildActivityManager problems > > > An: [email protected] > > > Datum: Samstag, 25. April 2009, 21:05 > > > 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 > > > > > > > > > > > > > > > > > > > > -- > Gurkan Erdogdu > http://gurkanerdogdu.blogspot.com >
