When you intend to use BlazeDS or LCDS in your App, you usually start a new project in FlexBuilder and set the Server Technology to LCDS and then Set the Root folder and Context root and validate the configuration to create the project as below.
At this point, FlexBuilder adds a -services option to the compiler and sets it to the services-config.xml where the end-points for the services are set.
You can then write code as below where the destination is now configured in the config file that’s set at the location in -services option.
<mx:RemoteObject id=”artJava” destination=”ArtGallery” fault=”errorHandler(event)” showBusyCursor=”true”>
<mx:method name=”getArts” result=”onArtResult(event)”/>
</mx:RemoteObject>
If you look into the services-config.xml you will see the following lines there
<channel-definition id=”my-amf” class=”mx.messaging.channels.AMFChannel”>
<endpoint url=”http://{server.name}:{server.port}/{context.root}/messagebroker/amf” class=”flex.messaging.endpoints.AMFEndpoint”/>
<properties>
<polling-enabled>false</polling-enabled>
</properties>
</channel-definition>
When you run the app in FlexBuilder, it substitues the {server.name} and other variables from the configuation that you set when you created a new project and compiles this into the application. This works like a charm, but this has a problem.
Yesterday, I did an application and bundled it into a war file and send it to my friend. But when he ran it, it did not work. This was because, I had my BlazeDS installed on port 8400 while he had it on port 8080. Since my Builder had substituted the {server.name} at compile time, the only option was to give him the whole project and get him to recompile it for his configuration.
Thanks to Sujit, I discovered that you can not go this way and make this generalized by injecting these values at runtime, rather that these being at compiletime.
The trick is Read the rest of this entry »
Posted by raghunt 
FLEXing My Muscle 