Announcement Announcement Module
No announcement yet.
Multiple Application Contexts Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Multiple Application Contexts

    In the old forums, Garry asked about multiple Application Contexts ( but there were no answers. So I am repeating the question.

    Is there any technical reason you can't have multiple application contexts?

    For the project I am working on, I am using a dynamically generated application context file, generated by Grails. Among other things, it has the UI text and the "document" that the user will be working with in it. The context file comes to around 30 kb, and takes a couple of seconds to load. What I am considering is splitting this into 2 context files. In the first, I would have some basic configuration info, including the text for the start screen. While the user is reading that, I can then load the 2nd context file, which includes the rest of the UI, and the "document".

    This application is using Cairngorm, so what i figured is that both contexts can refer to the ModelLocator.getInstance(), and then set properties on the model. I will use some form of chained commands/event to load the first context file, and in it's responder, load the second context file.

    Any thoughts/concerns?

  • #2
    Hi johannz,

    I'm doing pretty much the same thing (small world). I have a 'BootStrapping' context and an 'ApplicationContext' that work together to make a generic shell.

    From here I can feasibly load any application xml, because the loading context configures a bulk loader than includes dependencies required by the application context.

    There was some talk about adding a <swf> tag to include the dependencies for you, but my version differs in that it also loads more generic items (such as fonts, css, assets etc) together so that you have everything you need to start your app.

    So I guess having separate contexts is not really an issue. You may have trouble with the ModelLocator pattern across Spring instances, I would delve into the XMLApplicationContext Class because I know the constructor accepts and array of files (not just one) so there may be a way to use the same context to load in the secondary file and manage 'beans' across the two (or three, or four!).

    If this is possible you could use the ref="" attribute (in the second file) to refer to 'beans' in the first file. That would be sweet.

    Alex Fell


    • #3
      Just a quick one, I just had a look at the XMLObjectFactory Class and had a look at loading process. It implements the following.

      * Use this method to add aditional configuration locations.
      * @param configLocation The location to add. This is the path to the configuration xml file
      function addConfigLocation(configLocation:String):void;

      * Use this method to add xml versions of configurations
      * @param config The xml configuration to add
      function addConfig(config:XML):void;

      So you could at the secondary file, and then call load again (this cause it to load the next in the queue).

      Haven't tested this, will let you know how it goes when I have time


      • #4
        example for multi-context

        here is an example,

        actually, this is the first thing i try when i download this framework, we happen to have the same situation where i need to load a secondary context after the first get loaded and processed.

        If you have a duplicated id defined in the second file, it will override the previous defination.
        my question is if this is configurable i.e. if it should throw an exception or pring an warnning rather than silently overwrite the existing object with new defination.

        also, i saw in source code, when it load a certain resource, it will unshit that resource path out of the loading queue, so when you load another context file, the first file will not get reloaded