Hard-coded endpoint port numbers in services-config.xml

[iancackett]

Is it possible to remove hard-coded port numbers in
services-config.xml and replace them with variables? I'd like to
deploy the same Flex application War file (including
services-config.xml within it) to our Dev, UAT and then Production
environments, for which the endpoints and port numbers must vary.
Re-building the app for each environment isn't desirable.



Has anyone else achieved this?

[aBill]

Hi,



{server.port} token can be used in non rtmp channel. It is
the same number as your http swf request's url port.



William Chan

[iancackett]

Thanks William, I'm thinking specifically of the RTMP and
secure AMF ports. If we run multiple instances of FDS on one host
(which happens in our Dev and QA environments) we need to change
ports to avoid clashes.

[bal_logicmanage]

Did you ever get an answer on this? I have the same
concern.

[Former Community Member]

{server.port} is the only thing you can do right now which
will be replaced with the port that swf was loaded from. There's an
open bug for having more generic tokens that can be replaced when
the server starts up or something like that.

[Robert_Hirst]

If I understand rightly the issue is that service-config.xml
is used to hard code port information into the swf, so if this
information can't be changed at run-time without a recompile. I
imagine that the swf determining the server.port would be pretty
trivial, since it can just look at the url it was requested from.
Other ports, not so simple, since they could be absolutely
anything.



Just throwing this out there, it could do with a more little
thought and other people opinions, but as a stop gap until the new
tokens arrive (or if they never do):



What if you compiled the swf with a config file set
containing 2 copies of every destination and port, and used a flash
param flag or try and detect if you are running in debug mode (not
sure how to do that yet) and set one of the two destinations which
the swc knows about at runtime.



Then on each deployment remove some declarations from the
config file, so that only one of each pair of dest/channels is
running in each instance, and no port conflict exists. By "same
war" I assume config file changes are acceptable, since they would
be required to change the port anyway.



This might be too complex depending on how many destinations
there are, and there might be practical barriers I haven't thought
of, so any feedback is welcome. And as I say, haven't tried this,
just throwing it out there.

[Former Community Member]

You have an idea that might work in some cases but not
always. Consider this scenario: say on one machine you want port
2038 for an RTMP channel but on another machine, say you want port
2039. You could technically have 2 RTMP channels defined in
services-config.xml and 1 one of them can use 2038 (call this one
my-rtmp1) and the other 2039 (my-rtmp2). Then you'll need 2
destinations as well. One destination will use my-rtmp1 channel
(call this one my-destination1), and the other will use my-rtmp2
(my-destination2). Then in your client code (Actionscript/MXML),
you will need to implement some logic where you'd choose to use
my-destination1 vs. my-destination2.



A lot of work and you're doubling your channel and
destination definitions just to choose a different port but it is a
solution if both ports 2038 and 2039 are available on the two
machines that you think you'll run the application. If these ports
are not available on a machine, then even this solution won't work
because RTMP server won't be able to start up correctly.



As I said before, there's an open enhancement request for
this and hopefully it'll get into the next release.

[Robert_Hirst]

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.

[thovan03]

Does this issue still exist? Am encountering the same hurdle
and need to recompile for each environment. Has any work around or
fix been produced yet? thanks.

[SujitG]

Hi all,



You can try creating channel sets at run time. In one of the
projects we did we created a XML file which had list of channels
and end points to be used. When the application is loaded we used
to read that XML and then create channel sets based on the
information in that XML. Once the channel sets are created you need
to set the created channel sets to your
RemoteObject/Consumer/Producer. Please find code for creating
channel sets attached.



You need not recompile your applications as the channel sets
are created when the XML is read and not when the application is
compiled. You need not even include your services-config.xml in
your compiler arguments using -services argument.



Hope this helps.



Code:



//retrieving channel details from configuration file

var channels:XMLList = confXml.channels.channel;

for each(var channel:XML in channels)

{

if (channel.type == "rtmp")

{

_rtmpChannel = new RTMPChannel(channel.@id,
channel.endpoint);



}

else if (channel.type == "amf-polling")

{

_amfPollingChannel = new AMFChannel(channel.@id,
channel.endpoint);

_amfPollingChannel.pollingEnabled = true;

_amfPollingChannel.pollingInterval = channel.interval;

}

else if(channel.type == "amf")

{

_amfChannel = new AMFChannel(channel.@id, channel.endpoint);

}

}



//creating channel sets

var rtmpChannelSet:ChannelSet = new ChannelSet();

rtmpChannelSet.addChannel(_rtmpChannel);



var rtmpChannelSetWithFallBack:ChannelSet = new ChannelSet();

rtmpChannelSetWithFallBack.addChannel(_rtmpChannel);

rtmpChannelSetWithFallBack.addChannel(_amfPollingChannel);



//now we need to set these channel sets to the remote objects

var cons:Consumer = new Consumer();

cons.channelSet = rtmpChannelSetWithFallBack;

[bal_logicmanage]

Please Adobe we need something done about this. It is not
feasible to require a recompile of our product every time we need
to deploy/redeploy for the many instances that we host of our
product for our customers.