10 Replies Latest reply on Jul 1, 2008 7:19 AM by SujitG

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

      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?
        • 1. Re: Hard-coded endpoint port numbers in services-config.xml
          aBill Level 1

          {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
          • 2. Re: Hard-coded endpoint port numbers in services-config.xml
            iancackett Level 1
            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.
            • 3. Re: Hard-coded endpoint port numbers in services-config.xml
              bal_logicmanager Level 1
              Did you ever get an answer on this? I have the same concern.
              • 4. Re: Hard-coded endpoint port numbers in services-config.xml
                Mete Atamel Level 1
                {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.
                • 5. Re: Hard-coded endpoint port numbers in services-config.xml
                  Robert Hirst Level 1
                  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.
                  • 6. Re: Hard-coded endpoint port numbers in services-config.xml
                    Mete Atamel Level 1
                    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.
                    • 7. Re: Hard-coded endpoint port numbers in services-config.xml
                      Robert Hirst Level 1
                      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.
                      • 8. Re: Hard-coded endpoint port numbers in services-config.xml
                        bal_logicmanager Level 1
                        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.
                        • 9. Re: Hard-coded endpoint port numbers in services-config.xml
                          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.
                          • 10. Hard-coded endpoint port numbers in services-config.xml
                            SujitG Level 2
                            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.


                            //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();

                            var rtmpChannelSetWithFallBack:ChannelSet = new ChannelSet();

                            //now we need to set these channel sets to the remote objects
                            var cons:Consumer = new Consumer();
                            cons.channelSet = rtmpChannelSetWithFallBack;