|
Problem(Abstract) |
I am running WebSphere Application Server 5.x Base and I
can't start or stop an app server I created. The applications I deployed
on my new app server show they are unavailable. Is this a defect? |
|
|
|
Resolving the
problem |
Please note the following instructions are only applicable
to WebSphere Application Server 5.x. They do not apply to 6.x.
When running WebSphere Application Server 5.x Base, you are running a
stand-alone server. This means that for each application server you
create, you must also have a separate console to control the server. Where
the confusion comes in is when looking at server1's console, you can see
all the app servers and their applications. In reality you're using the
same configuration files for each server, which is why you can see the
other app servers and their applications and create new app servers and
deploy applications on them. A 5.x Base server, because it is stand-alone,
doesn't know the status of other servers and their applications. This is
why you cannot start or stop servers and why the applications show up as
unavailable.
If you need the functionality of being able to manage all of your servers
from one console you need to use WebSphere Application Server Network
Deployment, or ND. This does allow you to stop and start servers, and
allows you to see accurate status displays.
In the meantime if you are not using ND, you need to deploy the console
application to your new application servers. There's a number of steps
involved in doing this. You'll need to create new virtual host entries and
deploy the application. To do this, follow the steps listed here.
For illustrative purposes I'll use the name testserv as my new
application server's name.
1. When you initially created a new app server, you had to create new
ports for that server. Usually this is done by selecting the option
"Generate unique Http ports" when you create the server. You'll need to
know some of the critical ports. Most of these can be found in two places,
but the ones you're most interested in will be found here:
Servers -> Application Servers -> testserv -> Additional
Properties / Web Container -> Additional Properties / HTTP Transports
(If you're interested the others may be found here: Servers ->
Application Servers -> testserv -> Additional Properties / End
Points)
2. Make a note of the ports. Keep in mind the console will normally be a
909x number, with its corresponding secured version being 904x. WebSphere
App Server's internal HTTP server will normally be a 908x number, with its
corresponding secured version being 944x. If you have created 10+ app
servers this may vary some.
3. Select Environment -> Virtual Hosts.
4. As a guideline you'll want to create a new virtual host for the
console. To do this, select the New button, and on the subsequent screen
enter a name for your virtual host. The name that server1 uses for its
admin console ports is admin_host. You'll want to make your new virtual
host descriptive enough to know it belongs to your new server. In my case,
I created admin_host_testserv.
5. Select your new virtual host. On the next screen under Additional
Properties select Host Aliases. There will be no entries for your new
virtual host, which is expected.
6. Select the New button, and enter an * for the Host Name and one of the
two console ports in the Port field (overtype the default of 80). There
should be one entry for each of the two ports 909x and 904x.
7. Select the default_host virtual host. Under Additional Properties
select Host Aliases, and using the New button add the two HTTP ports to
the list of entries currently there. This should be ports 908x and 944x.
8. Once you have the new virtual host created and the default_host
virtual host updated, select Servers -> Application Servers ->
testserv -> Additional Properties / Web Container
9. Change the Default virtual host entry to default_host if necessary.
10. Deploy the adminconsole.ear file on your new app server by selecting
Applications -> Install New Application. You'll want to point to the
adminconsole.ear file in the installableApps directory. Don't bother to
Generate Default Bindings.
For Step 1: Provide options to perform the installation, enter an
Application Name. I like to keep it descriptive once again, so I chose
adminconsole-testserv.
For Step 2: Map virtual hosts for web modules, select your new admin
console virtual host, in my case admin_host_testserv.
For Step 3: Map modules to application servers, select your new app
server, in my case testserv. Don't forget to check the adminconsole Module
and hit the Apply button. You should see an updated entry that shows your
server name.
Unless you want to set security roles you can ignore Step 4, and once you
hit Step 5 you can review it and then click Finish.
11. Don't forget to update the plugin through Environment -> Update
Web Server Plugin and follow the standard procedure to copy it to your
HTTP server if necessary. Recycle the HTTP server.
12. I like to stop and start my new server if it's executing. When you've
started your server, you should be able to use the 909x address you
entered in the admin virtual host group for the server. For example, if my
new app server's admin port is 9091:
('http://myhost:9091/admin') |
|
|
|
|
Cross Reference information |
Segment |
Product |
Component |
Platform |
Version |
Edition |
Application Servers |
Runtimes for Java Technology |
Java SDK |
|
|
|
|
|
|