Deploying patches in your Flex application

OK, your Flex application is already deployed in production. How are you planning to deploy patches to your code? I mean bug fixes or enhancements to specific MXML components or ActionScript classes? Of course, you can recompile the entire application with hundreds of classes just to deploy a new version of the class MyGreatCreation.as. Let’s see if there is a way to deploy just MyGreatCreation leaving the rest of your application intact.

In Java world, the solution to this issue is pretty simple. A typical Java application consists of a number of .jar files (think libraries or swc) and there is a concept of a class path. If a program needs to use a class MyGreatCreation, the Java class loader tries to find it based on the classes or jars listed in the classpath. If there is more than one version of this class in the path, the class loader will grab the first one. This greatly simplifies deploying any patches in Java production applications. Just make changes to your class and place it in the jar that is listed first in the classpath. Then deploy just this jar in production, and the loader will be happy to pick up the brand new version of MyGreatCreation.

Luckily, we can use the same techniques in Flex, which also has concepts of classpath, class loaders and libraries.

Go to the Properties window of your Flex Builder project and check the build path of your application. At a minimum, you’ll find there a number of libraries (compiled swc files) that represent the Flex framework itself. The chances are that you’ve added more swc’s there that contain your application-specific code.

In any event, create a new Flex Library project called patches or something of this nature. To be able to compile this project into an swc, add an empty ActionScript class there. We’ll be using the patches.swc as a first item in the build path of our main project.
Importantly, we’ll link this library to the main project as a Resource Shared Library (RSL), which means that the objects from patches,swc will not be merged into the code of the main application, but will be loaded during the run time. Add the compiler option -debug=false to your library project to avoid these annoying Flash Player’s messages asking where the debugger for this RSL is located.

Now go to the build path of the main Flex project and add patches.swc to the top of the list. Select the RSL linkage type as shown below (TestPatch there is the name of the main Flex project).

Go again to the properties of your main Flex project and add the library patches project in the list of your project’s references.

Run your main project – you should not see any differences because patches.swc does not contain any useful code yet.

Then, copy one of your classes from the main application it to the patches library project, modify it there and rebuild the patches.swc. Now we have two versions of this class – the new one in the patches.swc and the old one in the main application.

Re-run the main application. You’ll see that the new version of the modified class is being used. The class loader picked the new version since patches.swc is located at the top of the classpath of your application. That’s all there is to it.

Every time you need to make minor changes in your production application, just put them in patches.swc and upload it to the production machine.

Happy New Year!
Yakov Fain

2 thoughts on “Deploying patches in your Flex application

  1. I can see how that works fine for small changes, but what about changes that have dependencies? where you’re needing to update a bunch of classes that are from different parts of an application (eg a new minor feature that adds UI, processing, code from different parts of the application, etc). I can just see that lumping all that into a “patches” swc may be a bridge too far.

    thoughts?

  2. A patch is a patch. It’s a temp solution between scheduled releases. Many enterprises have pretty strict and formal release procedures, and releasing just one patches.swc, even if it has a bunch of classes, can be a viable solution. Italso may be easier to approve an emergency release that consists of replacing just one file patches.swc with another one.

    Needless to say that you are implementing the same changes in the original classes located where they’re supposed to be, and on the next scheduled release you empty patches.swc.

Comments are closed.