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: 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 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 . environment by applying WebSphere Fix Packs. 55 2 WebSphere Studio Application Developer Version 5 Programming Guide © Copyright IBM Corp. 2003. All rights reserved. 55 3 Chapter 16. Testing and. Express WebSphere Application Server 4.0 Advanced Edition Single Server The Fix Pack to download must therefore be for one of these products. 55 0 WebSphere Studio Application Developer Version 5 Programming. Chapter 15. Servers and server configurations 54 9 Figure 15- 35 WebSphere Application Server 5. 0 administrative console Applying Fix Packs to the WebSphere test environment You can apply WebSphere Application