Announcement Announcement Module
No announcement yet.
Runtime Class Loading Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Runtime Class Loading


    I have a project, a substantial part of which needs to vary accross 5 deployments. The elements that vary are accessed through a class that impliments an interface (Services), so that the application is expecting a class of type Services of which there are 5 variations.

    Obviously I could include references to all 5 implimentations to force their inclusions into the application when it is complied, then use Spring to inject the implimentation I want in each case, but this means that each version of the application has 4 implimentations compiled into it that it will never use.

    Is there any way of using Spring to load the classes themselves at runtime into the application's ApplicationDomain prior to injecting the implimentation?


  • #2
    This is exactly what's bothering me too. Unless we have run-time loading of AS classes, I'd rather create a different Main.mxml with each using the appropriate impl of Services and completely do away with requiring a context.xml


    • #3
      maybe an open door...

      Hi just wondered. can't you use property files to inject the different server addresses / destinations etc? Or are the implementations of the services really different? Of course you can't fix it with property files if one of them is a webservice and another one is a RemoteObject.

      Anyway for our DTAP environment property files work great.



      • #4

        there have been some experiments with class loading but we have not included support in the container so far.

        If you really need class loading, you can implement it yourself by overriding the parse() method of the FlexXMLApplicationContext and loading in the appropriate service implementation prior to the actual parsing. Note that this will only work with the latest SVN version.

        I'm pretty sure this will work, but I'm wondering if the cost of doing this (slower startup and more man hours) will be beneficial to the increased size of the application. In general I would not do such an optimization unless of course you have good reasons to.



        • #5
          Sorry for opening up an old thread, but did not get back to experimenting with SAS until recently.

          The reason I did not like listing classes in a separate file is because it is prone to forgetting to include a class and not knowing about it until runtime. I agree this is not a big deal because you should catch it while testing, but still it is an extra thing that you don't expect to have to do.

          I have found using MXMLApplicationContext as a good middle ground. I create separate Config files (composing_mxml_based_configuration_metadata) for real and test delegates and services and load them in the Main and TestHarness apps respectively.


          • #6


            there are some ways to generate a compiler config file from the XML configuration, it involves some extra setup work but works like a charm afterwards, here's a doc section that describes it:

            Spring Actionscript documentation