Maybe I can clarify what I mean. I'm assuming that basically
the same war file needs to be deployed twice to the same app
server, as in the original example, excluding changes to config
files (e.g. editing xml=ok, recompiling jars/swf=not ok).
The problem arises because if you were to change the config
file to use another port, it wouldn't make a difference to the
client app, which has the port and destination compiled in. You
would need to compile the app twice, once with the first port, once
with the second.
So my workaround is to compile (not deploy) with a config
file containing two sets of destination channels, then in your
deployed config files you remove one of the sets.
Assuming you want to deploy two instances of an app into a
single app server, there will 3 different configs, one used just to
compile, and one for each of the two deployed instances.
Config A (compilation config files, used only to compile the
flex application, not used during server start up) contains:
my-rtmp1, my-rtmp2, my-destination1, my-destination2.
Config B (server 1-debug) contains: my-rtmp1, my-destination1
Config C (server 2-release) contains: my-rtmp2,
my-destination2
So when you deploy two instances with Config B and Config C,
there is no port conflict. The Flex app then has some parameter set
in the wrapper (or the absence of said parameter could be the
indicator) to tell it whether to use my-rtmp1 or my-rtmp2.
I just tested this and it worked. The way I tested was to add
two buttons to a the Flex app, one which connects to
destination1and performs a fill, one which connections to
destination2 and performs the same operation. This Flex application
was compiled with config A.
I start a server with config B, and the application starts
fine, and the first button gets the fill as expected. The second
button instantly crashes the entire browser with an illegal memory
access exception. The second set of dest/channels aren't listening,
since the server doesn't know anything about them in it's config
file.
So on the bright side, that confirms to me that you can
compile an app with redundant channels and destinations, then
choose which destination/channel you want to use at runtime.
On the down side, being able to consistently cause a crash
like that usually isn't a good sign. I'll look again on Monday, and
raise a Flash bug if it's still present in the latest version.