By “load module 2” did you actually load a second module or is it a second instance of an already loaded module and thus the WebService instance is the same. Hopefully it is the latter as I wouldn’t have an explanation for the former.
For the latter, I believe (and I am not the expert on web-services) that every send() method returns an AsyncToken and you can save that away and decide whether to respond to the result event based on the AsyncToken referenced in the result event. Alex Harui Flex SDK Developer Adobe Systems Inc.<http://www.adobe.com/> Blog: http://blogs.adobe.com/aharui From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Brendan Meutzner Sent: Sunday, May 17, 2009 8:26 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Duplicate Module Loads - applicationDomain / Shared Code Issues Alex, That definitely did the trick. However... I'm using DataService calls inside the modules, and now when event listeners get set for result/fault/conflict events on them, they carry over to the other modules. So if I open module 1, load it up and make a data call, then load module 2, the result event on module 1 & 2 get fired. I can't exactly remove the event listeners on these (which would be the simplest answer) because of the fact that data synchronization is happening through LiveCycle DS. I have yet to look into trying to identify the calling module which causes the result event to see if I can single them out and ignore other multiple instances (which I will do tomorrow), but thought I'd post to see if there was an easier solution. Thanks very much for your original answer on this... it really helped out :-) Brendan --- In flexcoders@yahoogroups.com<mailto:flexcoders%40yahoogroups.com>, Alex Harui <aha...@...> wrote: > > In theory, you simply put all shared VO’s in the main app and don’t mess > with applicationDomains. > > Also in theory, if it is the same module class there is no need to load it > twice, you should instantiate it twice (via factory.create()) and pass it > parameters it needs to make different backend calls. Should take less memory > this way, and might avoid this shared code issue. > > Modules don’t work if you use “new ApplicationDomain()†as there must > be shared interfaces between the loader and loadee, and using > applicationDomain.currentDomain will lock the module into memory. > > Alex Harui > Flex SDK Developer > Adobe Systems Inc.<http://www.adobe.com/> > Blog: http://blogs.adobe.com/aharui > > From: flexcoders@yahoogroups.com<mailto:flexcoders%40yahoogroups.com> > [mailto:flexcoders@yahoogroups.com<mailto:flexcoders%40yahoogroups.com>] On > Behalf Of Brendan Meutzner > Sent: Saturday, May 16, 2009 3:48 PM > To: flexcoders@yahoogroups.com<mailto:flexcoders%40yahoogroups.com> > Subject: [flexcoders] Duplicate Module Loads - applicationDomain / Shared > Code Issues > > > > > > Hi All, > > I'm having trouble wrapping my head around an issue I'm facing while loading > the same module twice into my main application. > > I've got a module which takes a few arguments to load up property data. If I > ask for a different set of data, the same Module class gets loaded, it just > makes different back end calls to populate its data. My module is located in > a different project from my main application, so optimizing to application > isn't an option. However, I am generating a link-report from the main > application, and then using load-externs on the module's compile. > > 1) I load up an instance of the module, and it retrieves data just fine. > 2) I load up a second instance of the same module, but when the data is > returned, I get errors relating to the fact it's trying to set my data > response to a local VO Class which has already been instantiated from the > first module call. > > > I know I've got a shared code issue going on here, but can't figure this out. > I've tried the following: > > 1) Placed all re-used VO files inside main application, generated > link-report, and referenced that link-report via load-externs on the modules > compilation.... then I set applicationDomain on module load to be > Application.currentDomain. > > 2) Placed all VO files inside module where they are actually used, and then > set applicationDomain to a "new ApplicationDomain()" instance to try and > sandbox their use. > > > Neither of these worked.... which is suffice to say, why this post is being > written. > > > Thanks in advance for help. > > > Brendan >
