Hi Anton, It looks like the I.2 seems to be more elegant. I think I will go in that direction.
Thanks for your reply, it is very constructive and appreciated. Dominique Paquin >>-----Original Message----- >>From: Anton Tagunov [mailto:[EMAIL PROTECTED] >>Sent: Wednesday, May 28, 2003 2:42 AM >>To: Avalon framework users >>Subject: Re: Question on the general implementation of Fortress..... >>again. >> >>Hello Dominique! >> >>Here's a short answer from me, I will probably address only a part of >>your question :-) >> >>Hope that others will complement my answer, and especially >>point out which is preferred I.1 or I.2 (Berin? ;-) >> >>Wednesday, May 28, 2003, 12:04:56 AM, you wrote: >> >>DP> 3) What puzzles me, in the example above, is that I see that we simply >>DP> do the getContainer()!?!?! (shouldn't it be named a getService() or >>DP> something like that??? ) with absolutely no parameter to select the >>one >>DP> that I want and then do a run on the returned Object. What I need is >>to >>DP> be able to select a particular service based in a parameter to the >>DP> getContainer and then call the getA or getB from one another with the >>DP> returned reference and system.out.println the result. >> >>I. As I understand Fortress spirit and design you have two alternatives: >> >>I.1 Implement a custom contianer deriving it from the DefaultContainer. >> This custom container will have method >> >> doSomething() >> { >> MyServiceA msa = (MyServiceA) m_manager.lookup( MyServiceA.ROLE >>); >> msa.doSomething(); >> m_manager.release( msa ); >> } >> >> Then, after you do >> >> fortressConfig.setContainerClass( "MyContianerClass" ) or >> fortressConfig.setContainerClass( MyContianerClass.class ) >> >> And after getContainer you coerse (did I misspell this ? :-) >> it to the exact class you're expecting like >> >> MyContainerClass myContainer = >> (MyContainerClass)cm.getContainer() >> >> Now you do >> >> myContainer.doSomething(); >> >>I.2 There's another way. It seems I have also seen that in some of >> the examples. >> >> >> DefaultContainer dc = cm.getContainer(); >> ServiceManager manager = dc.getServiceManager(); >> >> MyServiceA msa = (MyServiceA) manager.lookup( MyServiceA.ROLE ); >> msa.doSomething(); >> manager.release( msa ); >> >>II Swing-specific >> >>All the above applies to Fortress in general. >>The specifics of Swing is that you have to manage to >>dispose() you container in the right time - >>when your app shuts down. >> >>The swing example says there are generally two ways to do that. >>It demonstrates one way. And the other way, as it says, is >>to do it in the shutdown routing associated with the main >>window of your Swing app (Sorry, it's been half-a-year after >>I have written my last bit of swing code, can't supply an >>example right away, but there's a way to make some cleanup >>code execute when a window shuts down, and if its the main >>window of the app, then the main application shutdown code >>should go there.) I think its the best place to deinitialize >>Fortress. >> >>WBR, Anton >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
