Announcement Announcement Module
Collapse
No announcement yet.
Chaining application domains AND application contexts Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Chaining application domains AND application contexts

    Hi, all.

    It appears that a child context uses its parent context's applicationDomain instead of it's own. This is a problem if the child application's application domain is a child of the parent's application domain. In this situation the child context can't find the classes it uses in the parent application domain and an error gets thrown. Is this expected behavior?

    I've looked through the forums and can't find something on my use case though there are a bunch of posts on chaining application domains and SpringAS application contexts.

    Here are more details about the use case:

    SWF A is a pure actionscript application, with no Flex dependencies. It is basically a complete application with no view, but the ability to generate a model and communicate with external JS.

    When SWF A is done setting up and interacting with JS, it needs to load a Flex-based UI. This UI is located in SWF B, which is a Flex application.

    For file size and startup performance reasons, SWF A cannot contain any of SWF B's classes or Flex framework classes.

    SWF B, being the view, naturally has dependencies on SWF A's model, but not the reverse.

    I'm using Spring AS in both SWFs, each SWF having its own context. Mirroring the dependencies, SWF B's context has dependencies on SWF A's context, but not the reverse.

    SWF B sets its context's parent to SWF A's context before calling load().

    SWF A loads SWF B using flash.display.Loader.

    If SWF A sets Loader's application domain to ApplicationDomain.currentDomain, the contexts work fine with no problems EXCEPT that none of the default framework resource bundles appear to be available after SWF B loads. I think this is because SWF A's resource manager is first in, so SWF B's doesn't get used.

    Anyway, this problem lead me to trying setting Loader's application domain to new ApplicationDomain(ApplicationDomain.currentDomain) . With this setup, SWF A's context has no problems. But SWF B's context throws an error saying it cannot find the classes in SWF B's applicationContext.xml. I AM making sure to include references to SWF B's classes in SWF B so that they get compiled in.

    It appears that, when one application context is the parent of another, and the child context is in a SWF whose application domain is the child of the parent SWF's domain, the child context cannot use classes that are NOT in the parent SWF's application domain. Is this a correct description of SpringAS's behavior? I was expecting that each context would look in it's own application domain. That if I request an object from the child context it will look in it's own application domain, not its parents. And if it can't find what it needs, then it will look in the parent context, and the parent context, would similarly look in its own domain. Am I wrong?

    Thanks much.

    Julian
    Last edited by jaabio; Oct 9th, 2010, 06:43 PM.

  • #2
    Viable solution?

    After some experimentation, I discovered I don't get penalized by casting the child application context to AbstractObjectFactory and manually setting the applicationDomain to the child's domain. Now the child context is not using the parent application's application domain and all's well with the world in all other respects. But did I commit a no-no with this solution? I don't want to be using SpringAS in some way that it's not intended.

    Thanks much.

    Comment


    • #3
      Hey Julian,

      normally an application context will either use the ApplicationDomain.currentDomain, or,if its been assigned an owner module, it will use the application domain of its owner module.
      So this is Flex specific behaviour, since Modules are Flex only. You setting the applicationDomain property manually on your context is not a problem at all, its perfectly legal
      In the future I'm planning to refactor the ownerModule functionality so that a context doesn't need a Module, but any kind of view, that way it'll be more usable for pure actionscript projects.

      cheers,

      Roland

      Comment


      • #4
        might help

        Hi Guys,

        I'm building a framework on top of SAS container and had the same problem.
        for me getting the right applicationdomain for subapplications works like this:

        context.applicationDomain = (document["moduleFactory"].info) ? document["moduleFactory"].info().currentDomain as ApplicationDomain : document.loaderInfo.applicationDomain;

        where document is a DisplayObject. It's type unsave but generic and doesn't require Flex classes. Thought this might help with the refactoring Roland.

        Arnoud

        Comment

        Working...
        X