WebSphere Studio Application Developer Version 5 Programming Guide part 58 pot

544 WebSphere Studio Application Developer Version 5 Programming Guide
Customizing server configurations
Each server configuration can be customized by double-clicking either the server
configuration itself or a server using it. If you double-click a server, you will see an
extra tab, Server, with configuration information for that server instance.
Figure 15-30 shows the window for our WebSphere 5.0 on vertex (Copy) server
using a WebSphere Application Server 5.0 configuration. We double-clicked the
server, thus the extra Server tab is shown.
We will not explain all the options available in this server configuration, only
highlight some of the less obvious ones. If you make any changes, be sure to
press Ctrl-S to save them before starting a server using the configuration.
Figure 15-30 WebSphere remote server settings
Server page
On the Server page (Figure 15-30) you can select if you want to generate the
HTTP server plug-in configuration. Doing so re-generates and publishes the
plugin-cfg.xml file allowing you to test using the IBM HTTP Server on the
remote machine (and not only the application server’s built-in HTTP server). The
plugin-cfg.xml file will be published to the config directory under the
WebSphere remote deployment directory (Figure 15-7 on page 523).
Chapter 15. Servers and server configurations 545
Configuration page
On the Configuration page (Figure 15-31) you can enable and disable the
administration console and the universal test client (UTC). If you have limited
memory in your machine and do not need these features, you can turn them off
to save some valuable memory and also reduce the bring-up time for the server.
Figure 15-31 Server configuration settings
You can also change the Application class loader policy for the server, which
controls the isolation between the applications (EARs) deployed to the server.
The application class loader is the class loader that loads the EJB JARs, utility
JARs and RARs (resource archives) contained in an EAR:


SINGLE
policy means that there is only one such class loader in the server.
This means that there is no isolation between the EARs in the server and that
classes in an EAR can see classes in the other EARs.

MULTIPLE
policy, on the other hand, gives each EAR its own application
class loader which then isolates the EARs from each other. This is the
recommended setting and follows the J2EE 1.3 class loading specification.
Applications page
On the Applications page (Figure 15-32) you can also change the application
class loader mode. This determines how the application class loader should
delegate the loading of classes.
546 WebSphere Studio Application Developer Version 5 Programming Guide
Figure 15-32 Server applications settings
 When
PARENT_FIRST
(which is the default and the recommended setting) is
used, the application class loader delegates the loading of classes to its
parent class loader (which is the WebSphere extension class loader) and only
if the parent class loader fails to load the class does the application class
loader attempt to load it.
 When using
PARENT_LAST
, the application class loader first attempts to
load the class and only if it fails will it delegate the loading of the class to its
parent. This can be used to give JARs packaged in the root of an EAR file
precedence over JARs on the WebSphere extension classpath. Examples of
such JARs could be JDBC drivers or other common, stable classes.
The WebSphere Extension class loader uses the ws.ext.dirs classpath to

locate classes. On the Paths tab you can add folders and JARs to this
classpath and they will then be visible to the whole server.
The Applications tab also allows you to change the WAR class loader policy,
which affects the isolation between the Web modules in an EAR:
 When using
MODULE
policy, each Web module gets its own class loader and
the Web modules are isolated from each other. This is the default and
recommended setting.
 When using
APPLICATION
policy, the classes in all Web modules in the EAR
are loaded by the application class loader and there is no isolation between
the Web modules.
Chapter 15. Servers and server configurations 547
Environment page
On the Environment page (Figure 15-33) you can supply environment properties
to the JVM.
Figure 15-33 Server environment settings
 By default the IBM Java Virtual Machine used by Application Developer sets
its maximum heap size to half the amount of RAM installed in the machine.
For a machine with 512MB of RAM, this means that the JVM of Application
Developer has a maximum heap size of 256MB.
 When a built-in server environment is started, Application Developer starts a
new JVM for the server. By default, this JVM also has a maximum heap size
setting of half the amount of RAM installed in the machine, so on a 512MB
machine this JVM also uses a maximum heap size of 256MB.
 When the heaps in these two JVMs reach their maximum size, they have in
total consumed 512MB of RAM, equal to the total amount of RAM installed in
the machine.

 As the JVM processes themselves require more RAM than just their heap and
the operating system and other processes on the machine also require RAM,
this can lead to excessive swapping, slowing the whole machine down.
 By adding the -Xms and -Xmx options (Figure 15-33) to set the initial and
maximum heap sizes of the built-in test server JVM you can limit the amount
of ram this process will consume. Lowering this setting, however, leads to
more frequent garbage collection, but it can improve performance anyway
since swapping to disk is really slow.
 These settings can be tuned together with the -Xms and -Xmx settings for the
JVM of Application Developer (see “Memory consideration” on page 25) to
achieve a system that performs well even in a memory constrained
environment.
548 WebSphere Studio Application Developer Version 5 Programming Guide
Setting the values too low, however, may cause an out-of-memory condition
and freeze Application Developer or the built-in server. If you encounter such
conditions, revert to the default value for Application Developer, which is
-xms=64M (and no -Xmx value).
 Also, debugging and profiling an application requires more RAM than simply
running it. Therefore, it can be good to have multiple server configurations
tuned for their purposes and then simply switch between them.
On a 512 MB machine, we have been able to find a sweet spot for our
environment by using the following values:
 Application Developer JVM: -Xms128M -Xmx128M
 Built-in test server JVM: -Xms96M -Xmx96M
Using these values, we have been able to keep our Windows 2000 installation
with Application Developer 5.0 and some applications running within the 512MB
limit without too much swapping.
Administrative console
If you enable the administration console (Figure 15-30 on page 544) and start a
server using the configuration you can launch the administration console for the

server by selecting the server in the Servers view and then select
Run
administrative console
from its context menu (Figure 15-34).
Figure 15-34 Launching administrative console
This brings up the administrative console for the server (Figure 15-35), allowing
you to perform administrative tasks and change settings not available in the
server configuration.
Chapter 15. Servers and server configurations 549
Figure 15-35 WebSphere Application Server 5.0 administrative console
Applying Fix Packs to the WebSphere test environment
You can apply WebSphere Application Server Fix Packs (previously called
eFixes) to Application Developer’s built-in test environments to keep them
up-to-date and synchronized with your production environment.
The trick to applying the Application Server Fix Packs to Application Developer is
first to get the right Fix Pack, and then to know where to install it.
Fix Packs for Application Server can be downloaded from:
/>Application Developer 5.0 comes with support for the following Application
Server built-in test environments:
 WebSphere Application Server 5.0
 WebSphere Application Server 5.0 Express
 WebSphere Application Server 4.0 Advanced Edition Single Server
The Fix Pack to download must therefore be for one of these products.
550 WebSphere Studio Application Developer Version 5 Programming Guide
Once the Fix Pack is downloaded, you must to know where to install it.
WebSphere Application Server’s default installation directory is C:\Program
Files\WebSphere\AppServer. However, in Application Developer the run-times
are located in the following directories:
 WebSphere Application Server 5.0:
<wsad_home>\runtimes\base_v5

 WebSphere Application Server 5.0 Express:
<wsad_home>\runtimes\express_v5
 WebSphere Application Server 4.0 Advanced Edition Single Server:
<wsad_home>\runtimes\aes_v4
When prompted for the
Application Server Home
directory during fixpack
installation, you should enter the corresponding directory above.
At the time of writing, there are no Fix Packs available for Application Server 5.0,
so in this example we update the Version 4.0 test environment to Fix Pack 5
(4.0.5).
Perform the following steps:
 Download the correct Fix Pack and unzip it to a temporary directory. The file
we downloaded was called was40_aes_ptf_5.zip and we unzipped it to
C:\temp\was40ptf5.
 Run install.bat from the directory.
 At the prompts, reply with the following answers:
– Update the Application Server (yes/no)? yes
– Enter the Application Server Home:[Example: C:\WebSphere\AppServer]
C:\WSAD5\runtimes\aes_v4
– Use the Application Server JDK (yes/no)? yes
– Perform update of the JDK (yes/no)? yes
– Update iPlanet Web server configuration for support by WebSphere
(yes/no)? no
– Perform update of the IBM HTTP Server (yes/no)? no
– Perform update of the Apache Web server (yes/no)? no
Note: If applying a Fix Pack to a WebSphere v4.0 test environment, make
sure to download the Fix Pack for the WebSphere Application Server 4.0
Advanced Edition
Single Server

product.
Chapter 15. Servers and server configurations 551
– Use the Application Server Logs directory (yes/no)? yes
– Place backups under the WebSphere Application Server Home (yes/no)?
yes
When the Fix Pack is applied, you can start the server in Application Developer
and verify that it was successfully updated. When starting our server the
following message was displayed, indicating a successful update:
*** Starting the server ***
IBM WebSphere Application Server, Release 4.0.5
Advanced Single Server Edition for Multiplatforms
Copyright IBM Corp., 1997-2001
Summary
In this chapter we have shown you how to use the server tools feature of
Application Developer to test Web and EJB applications. We set up both a
built-in test environment and a remote WebSphere Application Server, and we
published and tested an application.
We examined the server configurations and gave you some tips on how to
improve performance.
The TCP/IP Monitor server was also covered. Finally, we showed you how to
update the internal test environment by applying WebSphere Fix Packs.
552 WebSphere Studio Application Developer Version 5 Programming Guide
© Copyright IBM Corp. 2003. All rights reserved. 553
Chapter 16. Testing and debugging
In this chapter, we explain how to use the debugger included within Application
Developer to test Web applications. We also detail how to debug on a remote
server.
This chapter describes the following topics:
 Debugging a Web application
 Debugging on a remote WebSphere Application Server

16