ModuleLoader is a kind of strange API that is really just intended to look like SwfLoader for modules that contain a single visual component, and hides most of the module loading infrastructure, which is all about class factories.
What I mean by "only loaded once" is that if you have several places in the code that call the ModuleManager.getModule("url").load() call, it will only ever get loaded over the wire and interpreted once, subsequent "loads" will just re-dispatch pseudo-load events to the new client. In other words, the class factory is a singleton for a given url. Unloading is a totally different story. As you note, not everything is truly unloadable, because there may be lots of references to stuff in
the module that will keep it alive and un-GC'ed.
I suggest playing with the low-level API so that you understand the backing implementation, and this should help you understand the limits of ModuleLoader.
The main difference between modules and applications is that modules have lower overhead, and they only ever get loaded once, no matter how many times you load them. If you're using the ModuleLoader API, keep in mind that you're losing about half the functionality of the module system. I will assume that you are, because otherwise it would be obvious where to expose methods. You might want to play around with the lower level ModuleManager API just to get a hang of what's going on - ModuleLoader is a pretty thin veneer over the lower API.
Basically, what you want to do is to have your module implement an interface, say IModuleWhatever.
Also try and refer to this link which was previously discussed in this forum..
Thanks for quick reply....