Nick,
We are primarily Tomcat-based here too. It took us a while to address the issue with app portability but we are there now.
We use a database table on the server to store all the server-specific app settings. It's a simple property/value structure with the key being a unique ID by business application. The business app retrieves these at initialization.
Sounds simple but it's more complicated than that, right? Here are a few more details:
1. We use a web application to serve the properties. The individual business applications use the services of this properties-serving web application to get their properties instead of going directly to the database.
2. In order to know which server to go to get the web properties, the individual business apps start by pulling the server name out of the URL used to invoke the business app.
You can parse it out of this string:
urlString string = document.location;
3. Once we know the server where the business app was launched we pull the properties for the business app from the properties-serving web app on the same server. The properties-serving web app has the link to the database where the properties live. This is the most important aspect of the implementation. This is what allows use to have different settings in development and production or even on different instances of Tomcat running on the same server.
4. For development/testing an app inside the IDE we check the "egl.contextAware" flag (exposed with an external type function). If we determine that we are running inside the IDE we go directly to the properties-serving web app on our development server for our app properties instead of trying to parse out the server from the URL.
That external type function looks like this:
"inDevelopmentMode" : function() {
return egl.contextAware;
},
So this is what the code looks like in a RUI business app's initialization function:
host string = "http://www.developmentserver.com:8081/"; // The default testing/development server when inside IDE
if(!browserFunctions.inDevelopmentMode()) // Are we in the IDE or on a server?
dl string = document.location;
dlo int = strlib.indexof(dl, "/", strlib.indexof(dl, "//") + 2);
host = dl[1:dlo];
end
Properties.init(me, host); // Go get the properties
Properties.init calls a web service to retrieve properties. Once the properties have been retrieved, they are returned to this app via InfoBus. Until we get the properties the business app does nothing ... the successful retrieval of properties causes the business app to continue initializing.
The "me" on the Properties.init call is a unique ID for this business application. It is used as the key to retrieve the properties for this application and as a target for the InfoBus callback.
There is more code behind the scenes and implementation details of course but that's the basic idea. We like the abstraction of the properties retrieval into a web service so that we can change the whole back-end implementation (to use the WAS REEs perhaps) without changing business app logic.
Dan
dan_darnell