Prior to SE 5, this was accomplished by specifying the aliases to be
handled by each ASI in a file that contains the adapter's configurations.
Depending on which webserver you were using, that file was:
- servletexec.properties (for IIS)
- httpd.conf (for Apache)
- obj.conf (for SunONE/iPlanet)
With SE 5 the way that the adapter is configured has been normalized
across the various supported webservers to make ongoing maintenance of a
multi-ASI setup easier, and also to increase webserver uptime.
Beginning with SE 5 AS, the native adapter's configurations go in
webadapter.properties no matter which supported webserver is used.
The adapter first learns about the hostnames and ASI's by reading
It then uses that information to open a TCP socket to each ASI and ask each one what it's
webapp context paths (i.e. aliases) are.
So with SE 5.0 the aliases information is no longer recorded in any file for use by the native adapter.
Some general facts about SE 5.x AS to keep in mind while attempting to understand
the remainder of this FAQ:
- *Everything* (i.e. all your servlets, JSPs, html files, etc... ALL resources)
will reside (and be executed) within the context of some webapp (WEB-INF folder, web.xml).
That may be the default-app that comes with each ASI or it may be some custom webapp that you have deployed.
- There is no "Legacy" (i.e. non-webapp) context anymore (as there was with SE 4.x and older).
Even the SE Admin UI is now in a webapp named "servletexec" whose context path is "/servletexec" by default.
- Each ASI that you install will automatically create and auto-deploy
(see the SE User Guide for details on auto-deployment) it's own private copies/versions of the following 2 webapps:
- default-app [whose context path is a single forward slash. "/"]
- servletexec admin UI webapp [whose context path is "/servletexec" by default]
- When the SE AS 5 native adapter gets the opportunity to look at a request
and decide *if* the request is meant for an ASI, and if so *which* ASI:
it will use the combination of hostname[:port] PLUS application context path of the request in order to make that decision (this is true for ALL versions of SE AS).
The adapter learns the hostname portion of the routing rules from webadapter.properties.
The Adapter learns the context path (alias) portion of the routing rules by using a socket to speak to the ASI and
ask it "What are all the context paths for all the webapps that you have deployed?"
This "pinging" is configurable via the aliasCheckInterval property in
So... if you intend to have more than 1 ASI and you wish to use the EXACT same hostname to access any/all of them then here is what you must do:
- Get all your ASI's installed, start each of them once, and then turn each of them off.
- Go find the top-level folder for each ASI's servletexec webapp on the hard-drive.
This will be in the auto-deploy folder for each ASI, For example:
C:\Program Files\New Atlanta\ServletExec AS\se-1\webapps\default\servletexec\
C:\Program Files\New Atlanta\ServletExec AS\se-2\webapps\default\servletexec\
You'll need to rename each of those folders to signify to which ASI it belongs.
C:\Program Files\New Atlanta\ServletExec AS\se-1\webapps\default\servletexec1\
C:\Program Files\New Atlanta\ServletExec AS\se-2\webapps\default\servletexec2\
- Now startup your ASI's again.
- Now if you request:
http://<hostname>/servletexec1/admin you'll be accessing the admin UI for instance #1
and if you request:
http://<hostname>/servletexec2/admin you'll be accessing the admin UI for instance #2
Basically since hostame is the same, the context paths must be unique.
The combination of hostname[:port] PLUS context path must be unique in order for the adapter to route the request to the right ASI.
- Since ASI #1 is the only ASI that has a webapp whose context path is "/servletexec1" and since ASI #2 is the only
ASI that has a webapp whose context path is "/servletexec2", the adapter knows which ASI should get the request.
- Once you can access each individual admin UI, then you can deploy "/myWebapp1" onto one of the ASI's and
deploy "/myWebapp2" onto one of the other ASI's. And there is no need to make edits to any properties file
(easier to maintain) and no need to bounce the webserver (more webserver uptime).
Note: If you were wanting to use a unique hostname for each ASI, then you would NOT need to change the context path of the
servletexec admin UI webapp as step #2 above says. Or more generally, you would NOT need to ensure that context paths
were unique across all ASI's. Instead you would edit webadapter.properties and change the "hosts"
value for every ASI listed there, from "all" to a specific hostname such as www.mydomain1.com or www.mydomain2.com depending on which hostname you want which ASI to handle.
You'd then save the change and bounce the webserver (so that the adapter would read in changes).
This would satisfy the requirement that hostname[:port] PLUS context path be unique, and would allow you to use the exact
same context paths in ASI #1 as are used in ASI #2.
Here are 2 relevant SE interest list postings:
If you startup your 2nd instance of SE 5.x AS, then it will create and deploy it's own default-app and servletexec webapps.
But you will most likely be unable to access the SE Admin UI webapp for that 2nd instance (or any other webapp deployed inside it) without first configuring the SE AS native adapter and then bouncing your webserver. You configure that adapter by configuring the webadapter.properties file.
This is because most likely your adapter configuration file (webadapter.properties) is currently configured to route ALL requests (no matter what hostname is used) to the 1st instance.
For more details about this, please read the previous sections of this FAQ.
If you wish to use unique hostnames to access each ASI, then here is a guideline for the structure of your webadapter.properties file:
servletexec.instance1.hosts=hostNameA, hostNameB:port, ipAddressA, ipAddressB
You don't ever have to use
.hosts=all if you don't want to.
But if you do use it, then it only makes sense for it to be used in the last group of properties (i.e. the last instance listed in that file).
Also, note that if you wish the webapp named "default-app" which is deployed on each of your ASI's to know which document root to use for each given hostname, then you must make use of the
-root parameter in each ASI's Start script.
Good resources for learning about the
-root parameter and how to use it include:
If you want your default-app(s) to know about any Virtual Directory mappings that might be defined in your IIS website(s) then you'd need to make use of the
-addl parameter in your ASI's Start script, similar to how the
-root parameter is used.
UPDATE about the -root and -addl parameters mentioned above:
They are obsolete as of the SE 6.0 September 2009 hotfix. Please see the release notes of that hotfix for more details.
Those using multiple instances of SE AS (5.x or higher) may also find SE FAQ #359 to be of interest.