WebSphere Studio Application Developer Version 5 Programming Guide part 58 pot

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-gener

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)

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

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

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

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

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:

http://www.ibm.com/software/webservers/appserv/support/index.html 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

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

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

– 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

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