L01: Using the WebSphere Application Server Liberty Profile for lightweight, rapid development. Lab Exercise

(1)

L01: Using the WebSphere

Application Server Liberty

Profile for lightweight, rapid

development

(2)

(3)

Lab 1

Using the Liberty Profile for lightweight, rapid

development

In this lab, you are going to install the Liberty Profile in a disconnected mode, meaning the resources have already been downloaded from the internet and are available locally on the virtual image that has been provided. And, then use you will work with the Liberty profile server in Eclipse to do some simple application development. The Liberty Profile is a lightweight, composable application server runtime that is small to download, easy to install and configure, and very fast to start. Both the Liberty Profile and the Eclipse adapter to use this profile in your development environment are available at no charge for a single user to unit test your applications on the desktop.You can use this environment to develop applications against the lightweight Liberty Profile and then transfer your environment to a production Network Deployment server with full fidelity.

This lab uses a desktop virtual image, and the following components have been previously downloaded from the internet and are available on the virtual image:

__1. Eclipse 3.7.2 - Installed

__2. WebSphere Tools Plug-in for eclipse __3. Liberty Profile server

The Eclipse Java EE IDE for Web Developers version 3.7.2 (Indigo) platform has been pre-installed on the virtual image. However, it is available as a free download on WASDev at the following URL:

http://wasdev.net

The IBM JDK 1.6 has been pre-installed on the virtual image, and is set as the default JRE for the development environment.

(6)

Windows NOTE:

You may be prompted with a Windows security alert when launching the Liberty Server and deploying an application the server. Just select Unblock, and continue with the lab instructions.

(7)

• Install the WebSphere Application Server V8.5 Liberty Profile in a disconnected mode • Install the WebSphere tools plug-in for Eclipse in a disconnected mode

• Configure Eclipse to work with your Liberty Profile server

• Use the Eclipse workbench to modify your Liberty Profile server configuration • Use the Eclipse workbench to publish and modify an existing application • Customize the Liberty Server JVM Options

• Be introduced to the Liberty Server Bootstrap properties file • Be introduced to the Liberty Server environment configuration file

To run this lab, your workstation must meet the following requirements:

• Approximately 8GB of storage available for the Windows XP virtual image

• Approximately 1.5 GB of memory free to run the developer workbench and the server

• The lab files for this lab must be unzipped on your workstation; the instructions will refer to the location of the sample files using the <LAB_FILES> variable.

• Connectivity to the internet is NOT required

1.1 Configuring your development environment (Disconnected

Scenario)

The Liberty Profile, Eclipse, and the WebSphere Developer Tools to support the Liberty Profile in Eclipse are all available as no-charge downloads for development and evaluation without IBM support. This means that you can set up an end-to-end development environment at no cost!

1.1.1 Install the Liberty Profile in a disconnected mode

__1. Install the WebSphere Liberty profile from the package that has already been downloaded from the internet

__a. Locate the <WLP_JAR> file that has been provided by the instructor.

__i. Optionally, copy the LabFiles directory provided by the instructor to the C:\Student directory on the virtual image.

(8)

__b. Open a Windows command prompt. And, then change to the directory that contains the

wlp-developers-8.5.0.0.jar file.

__c. Run the following command to install the Liberty profile into C:\Student\LibertyWork directory:

java -jar wlp-developers-8.5.0.0.jar --acceptLicense "C:\Student\LibertyWork"

__d. You will be left with a folder called C:\Student\LibertyWork\wlp (this document will refer to this folder as <LIBERTY_ROOT>).

__e. That’s it! The Liberty Profile is installed and ready to use!

TIP: Alternatively, the Liberty package can be downloaded and installed from the internet. The basic steps are illustrated in Appendix A.

__f. Explore the content of <LIBERTY_ROOT>. This should be located at

C:\student\LibertyWork\wlp

__g. Open a file system browser or terminal session and go look at the content of the

(9)

__h. Use a text editor to open the README.TXT file. It explains how to install and start the server, and contains information about how to configure the server, install applications, and so forth. You can close the text file, or keep it open as a reference.

__i. A default server is NOT included in the Liberty package. In this step, you will create a new default server.

__i. Open a Windows command prompt. And, then change to the

<LIBERTY_ROOT>\bin directory. This directory contains the ‘server’ command that can be used to create, stop, and start the Liberty server. It can also be used to dump the configuration to aid in customer support.

__ii. Enter and execute the following command to create a new server named defaultServer.

server create defaultServer

__j. Using the Windows Explorer, Look under

<LIBERTY_ROOT>/usr/servers/defaultServer. The folder name defaultServer

indicates the server name. Initially, the server contains a server.xml file with the JSP feature enabled, and default HTTP(S) endpoints configured. You can open the server.xml file in a text editor and view it:

(10)

__a. In this exercise, you will not be modifying the server configuration files directly – rather, you will set up your server configuration in the next sections, using Eclipse.

__b. Notice that the server.xml file has the featureManager section with the jsp-2.2 feature enabled on this server. To see which feature options are available for the Liberty Profile, open the <LIBERTY_ROOT>/lib/features folder and look through the list of .mf files. These files represent all of the features that you can enable in your Liberty Profile server. __i. In terms of feature names, the string you need to include in the server.xml file to

enable a feature corresponds to the name portion of the feature’s .mf file. Consider the file jsp-2.2.mf. The feature name that you would add to the server.xml is jsp-2.2.

For example: <feature>jsp,2.2</feature>0

Of course, you can add features to the server.xml file using the Liberty tooling in eclipse, as shown below. But don’t worry; we will work with the Liberty Tools later in the lab.

__2. Start the server.

__a. Open a command prompt or terminal session and navigate to <LIBERTY_ROOT>/bin

__b. Use the run option to start your server so that you can see the timestamp messages; you will not specify a server name, so the default server will be used.

__i. On Windows: server.bat run

(11)

__c. The server will start very quickly; this sample output shows the server is ready to run. You should have noticed that the server started in just a few seconds.

__d. You will not be doing anything with the server now, so type CTRL+C in your command prompt to kill the server process.

__e. When prompted to terminate the batch job, type Yes.

1.1.2 Launch the Eclipse Indigo Development Environment

__1. Launch the Eclipse Indigo for Java EE Developers (3.7.2) that has already been installed in the virtual image.

TIP: the first time you launch the eclipse development environment, you may be presented with a dialog to upload Data usage. Just click the Cancel button and continue with the lab.

(12)

The Eclipse Indigo development environment is available as a free download, as a compressed archive file, from http://wasdev.net. The compressed archive is approximately 215 MB.

(13)

__a. Using the Windows Explorer, navigate to the eclipse directory,

C:\Student\LibertyWork\eclipse. The eclipse directory will be referred to in these instructions as <ECLIPSE_ROOT>.

__b. Inside of <ECLIPSE_ROOT>, locate the Eclipse application file and open it (for example, by double-clicking it in your file browser).

__c. When the Eclipse launcher prompts you to Select a workspace, ensure the workspace is set to C:\Student\LibertyWork\workspace. And then click OK.

(14)

__e. Your Eclipse IDE will open to the Welcome page. Click the Workbench icon in the upper right to continue to your workbench and begin using Eclipse.

(15)

TIP: As mentioned before, the Eclipse Indigo for Java EE Developers (3.7.2) can be downloaded from the internet. The basic steps are illustrated in Appendix B.

1.1.3 Configure your Liberty server in Eclipse in a disconnected mode

__1. Install the WebSphere Liberty Profile developer tools plug-in for Eclipse from a previously downloaded zip file.

__a. IBM provides a no-charge adapter so that you can easily use your Eclipse environment with the Liberty Profile

__b. Start your Eclipse workbench if it is not already started.

__i. Navigate to <ECLIPSE_ROOT> (C:\student\LibertyWork\eclipse) __ii. Double-click on eclipse.exe

__iii. Accept the default workspace location, when prompted __c. Within Eclipse, go to Help > Install New Software.

__d. If there is no internet connection, you may see an error indicating a problem connecting to the software sites. That is OK since we will be installing from a local repository. Just click the OK button and continue.

(16)

__e. On the Available Software page, click the Add button.

__f. In the Add Repository Dialog, click on the Archive button and browse to the

WebSphere Developer Tools zip archive file provided by the instructor. Then click the OK

button to begin the installation of the plug-ins.

X:\Student\LabFiles\Lab01\WebSphereDeveloperTools\wdt-update-site_8.5.0.WDT85-I20120530_0920.zip

__g. Install the Liberty Profile Server plug-in

__i. From the list of available software to install, select the following components:

(1) WebSphere Application Server V8.5 Tools – Liberty Profile. (2) WebSphere Application Server V8.5 Tools

__ii. Deselect the checkbox labeled Contact all update sites during install to find required software

(17)

NOTES:

• The Web Development Tools have been pre-installed on the virtual image.

• The WAS V8.5 Tools includes the WebSphere Persistence Editor which is needed in the lab.

(18)

__i. Accept the license terms. And then click Finish to install the tools. Again, this process may take several minutes.

(19)

__j. Your Eclipse environment will begin processing the plug-in components; this process may take a few minutes.

__k. If you are prompted with any security warnings, you can ignore the warning and click OK

(20)

__l. When the installation finishes, you will be prompted to restart Eclipse. Click the Restart Now button. When Eclipse restarts, if you are prompted for a workspace, accept the default and click OK to continue to the development workbench.

__2. Configure a Liberty server instance in Eclipse.

__a. At the bottom of the IDE workbench, select the Servers tab, then right-click in the server list area and choose New > Server from the context menu.

(21)

__b. In the Define a New Server dialog, expand the IBM folder, and select WebSphere Application Server V8.5 Liberty Profile. Keep the default host and server names, and click Next.

(22)

__c. In the WebSphere Runtime Environment dialog, click Browse… to open the file system browser. Navigate to your <LIBERTY_ROOT> directory,

C:\Student\LibertyWork\wlp. And, then click OK.

TIP: The virtual image has the IBM JDK 6 installed, and we will use that for the Liberty server. Liberty can also run with the IBM JDK 7 and the Oracle Hotspot JDK 6 or 7. Notice that, if you do not have the Liberty profile installed yet, you can easily download and install it using the links on this panel. Click Next to continue.

__d. In the WebSphere Server dialog, notice that the WebSphere server field is set to your defaultServer instance.

__i. For this exercise, create a new instance for your development environment by clicking the New… button.

(23)

__e. In the new server panel, locate the Server name field and type labServer. You will be using this server to run a simple servlet sample application. Click Finish.

__f. In the New Server dialog, click Finish.

You will notice that the server contains the jsp-2.2 feature enabled and a default HTTP Endpoint definition.

(24)

__g. Now your server is defined!

__3. Start the server.

__a. From the Servers view, select your labServer instance and click the Start the server

button ( ). Alternatively, you can also right-click the server name and choose the Start

option from the context menu.

(25)

__4. Modify the lab server configuration.

__a. In the Servers view, double-click on your labServer server to open the configuration editor (or right-click and select Open from the context menu).

__b. First, expand the Publishing section and notice that the server is set to automatically detect and publish changes. Keep this default setting.

(26)

__c. In this exercise, you will be deploying a simple servlet application, so try enabling the servlet feature on this server. On the Overview page, locate the Liberty Profile Settings

section, and click the Open server configuration link to open the server.xml editor.

__d. Start by providing a meaningful description for your server. In the Configuration

Structure area, highlight the Server Configuration item in the list. In the Configuration Details area on the right, delete the default description for your server and provide something more meaningful, such as Liberty server for labs.

__e. To add a feature, such as servlet-3.0, go back in the Configuration Structure area, and determine if the Feature Manager has already been added to the configuration.

__i. The Feature Manager will already exist in the configuration if the Liberty Server configuration already has features defined, such as jsp-2.2.

__ii. Review the Feature Manager settings. In this lab, the Feature Manager has already been added to the configuration profile because of the jsp-2.2 feature having been included in the labServer you created earlier.

(27)

__f. Add an additional feature (servlet-3.0)

__i. Select Feature Manager located under the ConfigurationStructure area.

__g. Highlight Feature Manager in the Server Configuration list. On the right side, in the

Feature Manager Details area, click the Add button. Then, use the menu to select the

servlet-3.0 feature.

__h. In the server.xml editor, switch to the Source tab at the bottom to see the XML source for this configuration file. You will see that a new featureManager element has been added, and that it contains the servlet-3.0 feature.

(28)

__i. Now you have a server that is configured to use the servlet-3.0 feature. Click the Save

(29)

__j. Switch to the Console panel at the bottom of the workbench and review the latest messages. These messages are showing that your Liberty server automatically detected the configuration update, processed the feature that you enabled, and is now listening for incoming requests.

__i. You will notice that the server configuration was automatically updated and the feature update was completed very quickly. In this example, it was one second.

__k. Now you are ready to start working with a sample application that uses the Servlet or JSP features.

(30)

1.2 Deploying a sample application to the Liberty Profile

1.2.1 Import a sample application into Eclipse

__1. A simple servlet WAR file has been provided for this exercise; import it into your workbench. __a. In Eclipse, go to File > Import. Expand the Web section, then select WAR file. Click

(31)

__b. In the WAR file field, select Browse. Navigate to

X:\Student\LabFiles\Lab01\Sample1.war and click Open.

__c. Set the Target runtime to WebSphere Application Server V8.5 Liberty Profile. Click

Finish

__d. Now, you have a Sample1 web project in your workspace. You can expand it in the

(32)

__2. Start the sample application.

__a. In the Enterprise Explorer pane, navigate to the SimpleServlet.java as shown below. __i. Sample1 -> Java resources -> src -> wasdev.sample -> SimpleServlet.java __b. Right-click on SimpleServlet.java.

(33)

__d. In the Run On Server dialog, verify that Choose an existing server is chosen. __i. Under localhost, select the WebSphere Application Server V8.5 Liberty

Profile server that you defined earlier. The server should be listed in Started

state.

__ii. Click Finish.

__e. After a moment, your application will be installed and started. See the Console pane for the corresponding messages.

(34)

__f. In the main panel of the workbench, a browser also opened, pointing to http://localhost:9080/Sample1/SimpleServlet.

__g. If you receive a 404 the first time, try to refresh the browser once the application is completely deployed and started.

__h. At this point, you should see the rendered HTML content generated by the simple servlet.

1.2.2 Modify the application

__1. Open the servlet source.

__a. In the Enterprise Explorer panel, expand the Sample1 project, then go to Sample1 > Servlets. Double-click the wasdev.sample.SimpleServlet entry to open the Java editor for the servlet.

(35)

(36)

__b. This is how the SimpleServlet.java source looks in the editor:

__c. This is a very simple servlet with a doGet() method that sends out an HTML snippet string as a response. Your doGet() method will look similar to this (some of the HTML tags might be a little different – that is ok).

0/**0

00*0@see0HttpServlet#doGet(HttpServletRequest0request,0HttpServletResponse0response)0 00*/0

0protected0void0doGet(HttpServletRequest0request,0HttpServletResponse0response)0throws0 ServletException,0IOException0{0

00 response.getWriter().print(0

00 0 "<h1><font0color=green>Simple0Servlet0ran0successfully</font></h1>"0 00 0 +0"Powered0by0WebSphere0Application0Server0V8.50Liberty0Profile");0

0}

__2. Modify the application and publish the change.

__a. In the doGet() method, Locate the <h1> heading element of the HTML string, and notice that it contains a font tag to set the color to green. Modify this string by changing the text green to purple, so your font tag will look read <font color=purple>.

0response.getWriter().print(0

00 0 "<h1><font0color=purple>Simple0Servlet0ran0successfully</font></h1>"0 00 0 +0"Powered0by0WebSphere0Application0Server0V8.50Liberty0Profile");0

(37)

__b. Save your changes to the Java source file by either clicking the Save button ( ) or using

CTRL+S.

__c. Recall that your server configuration is setup to automatically detect and publish application changes immediately. By saving the changes to your Java source file, you automatically triggered an application update on the server.

__d. To see this, go to the Console view at the bottom of the workbench. The application update started almost immediately after you saved the change to the application, and the update completed in seconds.

__3. Access the updated application.

__a. Refresh the browser in your workbench to see the application change. The title should now be rendered in purple text.

__b. Optionally continue to play around with application modifications and see how quickly those changes are available in the deployed application. Maybe put in some additional text to display on the page, or add extra HTML tags to see formatting changes (you could add a title tag to set the text displayed in the browser title bar, for example,

<head><title>Liberty Profile</title></head>).

(38)

1.2.3 Modify the server HTTP(s) ports

__1. Open the server configuration editor.

__a. In the Servers view, double-click on the labServer server to open the configuration

Overview page (or right-click the labServer server and choose Open).

__b. In the Liberty Profile Settings section, select the Open server configuration link to open the server.xml editor.

__c. Ensure you are in the Design mode by selecting the Design tab on the Server Configuration editor.

(39)

__d. Under the Configuration Structure section, Click on Feature Manager.

__e. Select the Application: Sample1 item in the Server Configuration and look at its configuration details. From here, you can set basic application parameters, including the context root for the application.

(40)

__f. Select the Application Monitoring item in the Server Configuration and look at its configuration details. You can see that the monitor polls for changes every 500ms using an mbean trigger. You did not add any JMX features to your server to support mbean notification – so how is that working?

__g. Select the Feature Manager item to see the features that are configured on your server. You added the servlet-3.0 feature because you knew that you were going to be running a servlet application. But the development tools automatically added the

localConnector-1.0. feature to your server to support notifications and application updates. In fact, you would not have needed to add the servlet feature to your server at the beginning at all – the tools would have automatically enabled that feature, based on the content of the application.

(41)

__2. Change the HTTP port.

__a. Using the default HTTP port (9080) is an easy way to quickly bring up an application, but it is common to want to use a different port. This is an easy thing to change.

__b. In the Configuration Structure area, select Server Configuration, then select HTTP Endpoint

(42)

__c. In the HTTP Endpoint Details area, Change the HTTP Port to 9580. __i. Update the Port field to 9580.

__d. Save your changes to the server configuration (CTRL+S).

__e. You can review your full server configuration in the server.xml source file. Back in the server configuration editor, switch to the Source tab at the bottom to view the full XML source for your server configuration.

0

0 __f. After you saved your configuration changes, the configuration of your running server was

automatically updated. The Console pane will show that the Sample1 servlet is now available on port 9580.

(43)

__g. Now, you can access your sample application using the new port. In the browser in your workbench, change the port from 9080 to 9580 and refresh the application.

(44)

1.2.4 Add INFO logging output to the Console

By default, the Liberty profile Server has the console log level set to AUDIT. In this section, you will change the level of log messages written to the console from AUDIT to INFO.

You will perform this activity in the server.xml file using the UI. It is also possible to set default logging options in the bootstrap.properties file. If the logging options are set in the bootstrap.properties file, the logging options will take effect for ALL servers that are defined.

__1. Open the server configuration editor.

__2. Add the Logging configuration option to the server

__a. Under the Configuration Structure section, Click on Server Configuration. And, then click the Add button.

(45)

__b. On the Add Item dialog, select Logging, And, then click the OK button.

__c. The logging page displays the properties for the logging configuration, such as the name of the log files, the maximum size of log files, and the maximum number of log files to retain.

Additional configuration information is displayed regarding tracing. Notice that the

(46)

__3. Change the Console log level to INFO using the pull down menu.

__a. Switch to the Source view for the server.xml file to see the configuration changes added to server.xml.

<logging consoleLogLevel="INFO"/>

__b. Save the configuration file.

__c. Stop and restart the server.

The changes you made are dynamic and take effect immediately. However, running the

SimpleServlet does not produce INFO messages because the Servlet has already been initialized in the environment. When you restart the server, you will immediately see INFO messages in the console.

1.2.5 Update Trace Specification

By default, the Liberty profile Server trace specification is set to *=info=enabled. This is the same for Traditional WAS.

Updating the trace specification for debugging is easily performed using the server configuration editor. You can specify the trace specification in the UI, or copy / paste the trace specification directly into the server.xml file. In this section, you will specify a trace specification using the configuration editor. And, then, you will look at the result in the servr.xml source file

(47)

__2. Update the Trace Specification under the logging configuration.

__a. Click on Logging under the Server Configuration section. This displays the logging and trace details.

__b. Update the Trace Specification field with the following trace string: webcontainer=all=enabled:*=info=enabled

__c. Switch to the Source tab on the configuration editor and view the logging configuration. :

(48)

__d. Save the configuration changes.

__3. Run the SimpleServlet to produce trace messages. __a. Navigate to SimpleServlet.java

__b. Using the menus, run the SimpleServlet on the Liberty Server

__4. Verify that the trace.log file contains trace data.

__a. From a Windows Explorer, navigate to the server logs directory. C:\Student\LibertyWork\wlp\usr\servers\labServer\logs

The trace.log file has been created and contains content.

(49)

Note: To open the trace.log file using Wordpad, you must first stop the Liberty server.

__5. Very importantly, reset the trace specification back to the defualt value.

__a. Switch to the Source tab on the configuration editor and update the logging configuration to:

logging consoleLogLevel="INFO" traceSpecification="*=info=enabled "/>

__b. Save the configuration.

1.3 Customizing the Liberty JVM Options

The generic JVM arguments are used to configure and adjust how the JVM executes.

The WebSphere Application Server Liberty profile is pre-configured with minimal settings defined. The following steps will direct you how to define custom generic JVM arguments such as heap settings for a Liberty server.

__1. Create a text file named jvm.options in the ${server.config.dir} directory.

TIP: On the virtual image for this lab, the ${server.config.dir} is “c:\Student\LibertyWork\wlp\usr\<servers>\<serverName>”

The built in environment variables in the Liberty profile are discussed I the next section of this lab.

__a. Open the Enterprise Explorer view in eclipse

__b. Navigate to WebSphere Application Server V8.5 Liberty profile ! Servers ! labServer.

__c. Right mouse click on the labServer folder. And, then select New ! File from the context menu.

(50)

__d. Create new file named jvm.options in the labServer folder

__2. Insert your generic JVM options, one per line, into the jvm.options file. __a. Double click to open the file in the eclipse text editor

__b. Enter the following two lines in the jvm.options file to set the minimum and maximum heap size for eth labServer server. The following options will set the min / max JVM heap size to 25 MB and 500 MB respectively.

-Xms25m -Xmx500m

(51)

TIP:

• The default minimum and maximum heap size values of the JVM heap size is:

–Xms4m and –Xmx488m

• VerboseGC can be enabled by specifying -verbose:gc in the jvm.options file. • Verbose GC output will be logged to the following location by default:

<wlp.install.directory>/usr/servers/<serverName>/logs/console.log

TIP: Depending on your preferences, you might configure a single JVM or all Liberty JVMs with your options file.

__a. To apply these settings to a single server, save jvm.optionsat: ${server.config.dir}/jvm.options

__b. To apply these settings to all Liberty Servers, save jvm.optionsat: ${wlp.install.dir}/etc/jvm.options

TIP: On the virtual image for this lab, the ${wlp.install.dir} is “c:\Student\LibertyWork\wlp”

The changes will take effect for all JVMs that do not have a locally defined jvm.options file. __3. Restart the server to enable changes.

This concludes the customization portion of the lab. In the next sections, you will be introduced to the Liberty configuration files for customizing the server initialization and environment settings.

1.4 Introducing the Liberty Environment Variable configuration

You can customize the Liberty profile environment using certain specific variables to support the

(52)

The Liberty environment variables are specified using server.env file.

You can use server.env file at the installation and server levels to specify environment variables such as JAVA_HOME, WLP_USER_DIR and WLP_OUTPUT_DIR.

NOTE: You will not modify the default environment configuration in this lab.

Review the information in this section to become familiar with the environment variables that are available for customizing the Liberty environment.

The following Liberty profile specific variables can be used to customize the Liberty profile environment: • ${wlp.install.dir}

This configuration variable has an inferred location. The installation directory is always set to the parent of the directory containing the launch script or the parent of the /lib directory containing the target jar files.

TIP: On the virtual image for this lab, the ${wlp.install.dir} is “c:\Student\LibertyWork\wlp” • WLP_USER_DIR

This environment variable can be used to specify an alternate location for ${wlp.install.dir}. This variable can only be an absolute path. If this is specified, the runtime environment looks for shared resources and server definition in the specified directory.

The ${server.config.dir} is equivalent to ${wlp.user.dir}/servers/serverName.

• WLP_OUTPUT_DIR

This environment variable can be used to specify an alternate location for server generated output such as logs, the workarea directory and generated files. This variable can only be an absolute path.

If this environment variable is specified, ${server.output.dir} is set to the equivalent of WLP_OUTPUT_DIR/serverName. If not, the ${server.output.dir} is the same as ${server.config.dir} .

TIP: On the virtual image for this lab, the ${server.output.dir} is

c:\Student\LibertyWork\wlp\usr\<servers>\<serverName>”, which is the same as ${server.config.dir}.

(53)

1.5 Introducing the Liberty Bootstrap Properties

In this section of the lab, you will gain an understanding of how and when bootstrap properties are required during environment initialization.

NOTE: You will not modify any of the default environment initialization. This information is provided in the lab for your reference.

Bootstrap properties are used to initialize the runtime environment for a particular server. Generally, they are attributes that affect the configuration and initialization of the runtime.

Bootstrap properties are set in a text file named bootstrap.properties. This file should be located in the server directory alongside the configuration root file server.xml.

By default, the server directory is usr/servers/server_name. The bootstrap.properties file contains two types of properties:

• A small, predefined set of initialization properties.

• Any custom properties you choose to define which you can then use as variables in other configuration files (that is, server.xml and included files).

You can edit the bootstrap.properties file using a text editor, or using the editor that is part of the Liberty profile developer tools.

Changes to the bootstrap.properties file are applied when the server is restarted.

TIP:

As an example, the logging service can be controlled through the server configuration (server.xml) file. Occasionally you need to set logging properties so they can take effect before the server configuration files are processed;

In this case you set them in the bootstrap.properties file instead of the server configuration. You do not usually need to do this to get logging from your own code, which is loaded after server configuration processing, but you might need to do this to analyze problems in early server start or configuration processing.

This completes the lab exercise.

1.6 Summary

In this exercise, you:

(54)

• Installed the Liberty Profile tools plug-in

• Configured a Liberty Profile server in your Eclipse environment and modified the server configuration

• Deployed a sample application and experienced the rapid edit / deploy cycle that is supported by this environment

• Added additional server features

• Modified the HTTP Endpoint configuration

• Customized the JVM options for the lab server to setup the min / max heap sizes for the lab server.

• Familiarized yourself with the environment initialization, (bootstrap.properties) file.

• Familiarized yourself with the environment configuration options, (server.env) file for the Liberty profile.

(55)

The Liberty package can be downloaded and installed from the internet. For your reference, the basic steps are illustrated below.

This is for your reference only. Do not download the resources from the internet in this lab.

__a. Open a web browser and go to http://wasdev.net __b. Go to the Download tab.

__c. In the main area at the top of the page, locate the Just want the Liberty Profile section, and click the button to download the Liberty Profile (the text here, shown below).

(56)

1.8 Appendix B: Downloading Eclipse from WasDev

As mentioned before, the Eclipse Indigo for Java EE Developers (3.7.2) can be downloaded from the internet using these simple steps.

This is for your reference only. Do not download the resources from the internet in this lab.

__a. In your browser, go back to http://wasdev.net and go to the Download section. __b. From the main download area at the top of the page, locate Step 1, to download and

install Eclipse. Click the link Eclipse Indigo for Java EE Developers (3.7.2). This will re-direct you to the Eclipse download page.

__c. The Eclipse package is approximately 200MB in size, and may take several minutes to download.

(57)

L02: Learn to Accelerate your

Web App Development with the

WebSphere Application Server

Liberty Profile

(58)

(59)

2.3! BLOG SERVLET APPLICATION ... 9! 2.3.1! THE JPA(JAVA PERSISTENCE)ENTITY ... 10! 2.3.2! SUMMARY ... 15! 2.4! REVIEWING THE WEB FRONT END FOR THE BLOG APPLICATION ... 15! 2.4.1! EXPLORING THE POSTBLOG SERVLET ... 16! 2.4.2! EXPLORING THE VIEWBLOG SERVLET ... 20! 2.4.3! EXPLORING THE CREATEBLOGPOST HTML ... 22! 2.4.4! SUMMARY ... 23! 2.5! CONFIGURING THE SERVER AND RUNNING THE APPLICATION ... 24! 2.5.1! CONFIGURING THE DATA SOURCE TO CONNECT TO THE DATABASE ... 24! 2.5.2! SUMMARY ... 37! 2.6! SECURING AN APPLICATION ... 37! 2.6.1! CONFIGURE THE LIBERTY SERVER FOR HTTPS SUPPORT ... 37! 2.6.2! SETUP A BASIC USER REGISTRY TO TEST ROLE BASED ACCESS TO THE BLOG APPLICATION ... 41! 2.6.3! SECURING THE BLOG APPLICATION RESOURCES ... 43! 2.6.4! TESTING USER ACCESS TO SECURE RESOURCES IN THE BLOG APPLICATION ... 51! 2.6.5! SUMMARY ... 54! 2.7! PACKAGING THE LIBERTY PROFILE SERVER USING THE DEVELOPER TOOLS ... 54! 2.7.1! PACKAGE THE LIBERTY SERVER, CONFIGURATION, AND APPLICATIONS ... 55! 2.7.2! SUMMARY ... 57! 2.8! CONCLUSION ... 57! 2.9! APPENDIX A:REVIEW OF JPAPROJECT CODE AND PERSISTENCE XML CONFIGURATION ... 58! 2.9.1! EXPLORING THE BLOGENTRY JPA CODE ... 58! 2.9.2! EXPLORING THE PERSISTENCE XML IN THE JPAPROJECT ... 60! 2.10! APPENDIX B:REVIEW OF POSTBLOG JAVA CODE IN THE BLOG PROJECT ... 63! 2.10.1! EXPLORING THE POSTBLOG SERVLET ... 63! 2.11! APPENDIX C:REVIEW OF VIEWBLOG JAVA CODE IN THE BLOG PROJECT ... 68! 2.11.1! EXPLORING THE VIEWBLOG SERVLET ... 68! 2.12! APPENDIX D:REVIEW OF CREATEBLOGPOST HTML CODE IN THE BLOG PROJECT ... 72! 2.12.1! EXPLORING THE CREATEBLOGPOST HTML ... 72!

(60)

(61)

Lab 2

Learn to Accelerate your web App development with the

WebSphere Application Server Liberty profile

In this lab, you are going to work with an existing Web application, and configure the Liberty Profile server and resources in order to run the application on the Liberty development server. The Blog Application requires a database. You will configure the data source needed to connect to the Derby database. The Blog application requires that some of its resource be accessed in a secure manner. You will setup the security of the Liberty server, and configure the user role mappings in order to provide role based access to the secure resources. The Blog application includes a JPA project (Java Persistence API) programming model for access to the backend database. You will add the necessary features to the Liberty profile to support the JPA programming model for Entity persistence.

The Blog application also uses Java Servlets to interact with the persistence layer, and to display the resulting HTML content. You will configure the Liberty server to include the necessary features to support the Servlet programming model.

In tis lab, you will be introduced to the debugger in order to learn how quickly you can get up and running in debug mode using the Liberty profile.

Finally, you will test the Blog application and export the Liberty profiler resources to a compressed archive file. The compressed archive file includes the Liberty Server configuration and the Blog

application. In subsequent labs, you will remotely deploy and manage the Blog application and Liberty Profile server using the remote management capabilities available for the Liberty profile.

This lab uses a desktop virtual image.

The completion of Lab 01 is required to begin this lab exercise. If you have not completed lab 1, you must compete the lab setup section of this lab before you begin the Lab 2 exercise.

In this exercise, you will learn:

• How to create and deploy a simple static Web application using the IBM WebSphere Application

Server V8.5 Liberty Profile Developer Tools

• How to create and deploy a simple blog Web application that makes use of Servlets, and

persistence (using JPA – Java persistence API)

• How to create and configure Shared Libraries • How to configure JDBC drivers and data sources

• How to configure a Web application to access to certain Servlets and web pages require

authentication

• How to configure the server to use SSL, to have a user registry to authenticate clients with, and how to define role mappings for a web Application

• How to package the Liberty server, configuration, and applications for deployment to other environments

(62)

• Approximately 8GB of storage available for the Windows XP virtual image

• Approximately 1.5 GB of memory free to run the developer workbench and the server • The sample files for this lab, unzipped on your workstation; the instructions will refer to the

location of the sample files using the <LAB_FILES> variable.

• Connectivity to the internet is NOT required

2.1 Lab Setup (Required only if you did not complete Lab 1)

This lab requires the completion of Lab 01. If you have not completed lab 01, it is recommended that you do so be before attempting this lab.

However, you may, instead, follow these simple instructions for importing the completed version of Lab 01.

The Lab1_Completed.zip file includes the following:

• LibertyWork: Thisdirectory is the root directory for the labs exercises to be performed. • eclipe: Eclipse installation (Indigo 3.7.2)

• wlp: Liberty Profile installation, configuration, and deployed apps.

• workspace: The eclipse workspace that includes the completed lab exercises.

NOTE: The completion of Lab 01, or the unzipping of this completed Lab 01 archive is required in order to begin Lab 02.

These steps required only if you did not complete Lab 01, and want to perform Lab 02.

__1. Locate the completed lab 01 archive in

X:\Student\CompletedLabs\Lab01\Lab1_Completed.zip

(63)

This will unzip everything under the c:\Student\LibertyWork folder which is where the lab exercises are performed.

__3. When prompted to replace files, select “Yes to All”.

__4. You are now ready to continue to the next section of Lab 02.

2.2 Blog Servlet Application

In this section of the exercise, you are going to import the resources for a simple Blog application. You will explore the application components in order to become familiar with the Web application that uses JPA to implement a simple blog. The Blog will consist of JPA entity, two servlets and an html file.

Here is the application model diagram and use case:

1. The user inputs a blog entry into an HTML form. 2. The form data is posted to the PostBlog Servlet,

3. The PostBlog Servlet uses the JPA persistence API to save the blog entry in the database via the JPA Entity.

4. Then the ViewBlog Servlet is invoked from the PostBlog Servlet

5. The ViewBlog Servlet uses the JPA persistence API to retrieve ALL the blog entries from the database and render them in HTML format.

(64)

View Blog Content

ViewBlog.java

Web Container

Retrieve Blog Entries

Input HTML form

cresteBlogPost.html

Post Blog Content

PostBlog.java

Add a Blog Entry

Blog Application Model Diagram

Derby DB

WebSphere Application Server - Liberty Profile V8.5 JPA Persistence BlogEntry.java Persist and retrieve blog records Post HTML form

data

Invoke Blog View

2.2.1 The JPA (Java persistence) Entity

Java Persistence API (JPA) provides a simple POJO based programming model for reading and writing data to a database. It is based around annotated POJOs called entities which are mapped into rows and tables in a relational database.

In this section, we will import and review the JPA Entity used to persist the blog data to the Derby database provisioned on the virtual image.

__1. Import the Blog JPA Project into the Workspace

__a. Launch Eclipse and ensure the selected Workpace is C:\Student\LibertyWork\workspace

__b. Select File ! Import ! General ! Existing Projects into Workspace from the menu bar. Then click the Next button.

(65)

__c. On the Import Projects dialog, click on the radio button labeled “Select Archive File”, and then click the Browse button to select the

“X:\Student\LabFiles\Lab02\BlogJPAProject_Archive_Import2.zip” file. Then click Open.

__d. Select the ‘JPA Project (JPA Project)’ from the archive. Then click the Finish button to import the archive file.

__2. At this point, you will notice an error in the persistence.xml file. The error appears to be a bug in the Web Developer Tools in Eclipse.

(66)

__a. To eliminate the error, simply edit the persistence.xml file in Eclipse.

__b. Add a space character or a blank line. __c. Then save the file. The errors will go away. __3. Review the BlogEntry java code in the JPA Project.

__a. In the Enterprise Explorer, navigate to JPA Project ! src ! lab.blog.jpa !

BlogEntry.java.

__b. Double click on BlogEntry.java to display the source code in the editor pane. You can take time here to review the code on your own.

TIP: You can refer to Appendix A for a guided tour of the JPA project code and persistence configuration in the JPA Project application.

(67)

__4. Review the persistence.xml in the JPA Project.

You can take time here to review the persistence XML on your own.

TIP: You can refer to Appendix A for a guided tour of the JPA Project code and persistence configuration in the JPA Project application.

A JPA Persistence Unit is a logical grouping of user defined persistable classes with related settings.

Persistence units are defined in a persistence.xml file, which has to be located in the META-INF directory in the classpath.

__a. In the Enterprise Explorer, navigate to JPA Project ! src ! META-INF !

persistence.xml.

__b. Right click on the persistence.xml. Then select open with ! Other from the context menu.

(68)

__c. Then select Persistence XML Editor (WebSphere) from the selection list. Then click OK.

__d. The persistence.xml file will open in the WebSphere persistence editor. Select the Design Tab to view the content.

(69)

2.2.2 Summary

Congratulations you have successfully reviewed the JPA project and the required JPA Entity that is used in the Blog application to persist blog entries into the database.

In this section you should have a high level understanding of the purpose and functionality of the JPA Entity and the associated persistence XML file.

In this section, you reviewed:

• The JPA project • The JPA entity • The persistence.xml

2.3 Reviewing the Web Front End for the Blog Application

In the next tasks, you will review and explore the Web Application project, two servlets and the html file that are part of the Blog application. One Servlet displays the blog posts and the other Servlet allows you to create new posts. The html file provides a form to submit the new blog post.

__1. For your reference, here is the html input form. There is no action to take on this step.

(70)

2.3.1 Exploring the PostBlog Servlet

The role of the PostBlog Servlet is to post the contents of the Blog entry and persist the data to the Derby database. The PostBlog Servlet is invoked by a simple HTML form that we will explore later in this lab.

__1. Import the Blog Web Project into the Workspace

__a. Select File ! Import ! General ! Existing Projects into Workspace from the menu bar. Then click the Next button.

__b. On the Import Projects dialog, click on the radio button labeled “Select Archive File”, and then click the Browse button to select the

(71)

__c. Select the ‘Blog (Blog)’ project from the archive. Then click the Finish button to import the archive file

__2. Add the JPA Project to the Blog application Deployment Assembly.

The Blog application needs to use the JPA entity, so we need to make it visible at runtime. NOTE: Ideally, this could be included in the archive when the project is imported. However, at the time of this writing, there is an issue at runtime if the Deployment Assembly is pre-configured in the archive that is imported during the lab.

__a. Right mouse click on the Blog project. __b. Select Properties from the context menu.

__c. Select Deployment Assembly from the Properties dialog. Then click the Add button. __d. Select Project from the dialog window. Then click the Next button.

(72)

__e. Select the JPA Project from the Projects dialog. And, then click the Finish button to complete the process.

(73)

__3. Navigate to the PostBlog Servlet

__a. Switch to the JavaEE perspective in eclipse.

__b. In the Project Explorer, navigate to Blog ! Java Resources ! src ! lab.blog.web !

PostBlog.java.

__c. Double click on PostBlog.java to display the source code in the editor pane.

(74)

You can take time here to review the code on your own.

TIP: You can refer to Appendix B for a guided tour of the PostBlog Servlet code in the Blog application.

2.3.2 Exploring the ViewBlog Servlet

TIP: You can refer to Appendix C for a guided tour of the ViewBlog Servlet code in the Blog application.

The role of the ViewBlog Servlet is to access the Blog database and query the Blog data. The Servlet generates a List of Blog entries in which the Servlet displays as HTML to render the output in a Web Browser.

__1. Now we will do a quick review of the ViewBlog.java. First, navigate to the ViewBlog Servlet __a. Switch to the JavaEE perspective in eclipse.

__b. In the Enterprise Explorer, navigate to Blog ! Java Resources ! src ! lab.blog.web

(75)

__c. Double click on ViewBlog.java to display the source code in the editor pane.

The ViewBlog.java is used to display the contents of the Blog as the user enters new blog entries.

__d. That’s it for the Servlet review for the Blog application. All that is left is to review the html page with a simple form so a blog can be posted.

In the next section, we will quickly review the content of the createBlogPost.html that serves this purpose.

(76)

__e. Close the ViewBlog java editor

2.3.3 Exploring the createBlogPost HTML

TIP: You can refer to Appendix D for a guided tour of the createBlogPost htmlcode in the Blog application.

The role of the createBlogPost HTML is to provide an input form for the user to enter a blog entry. The HTML form invokes the PostBlog Servlet which persists the blog entry to the database.

__1. Now we will do a quick review of the createBlogPost.html. First, navigate to the createBlogPost.html file

__a. Switch to the JavaEE perspective in eclipse.

__b. In the Enterprise Explorer, navigate to Blog ! WebContent ! createBlogPost.html.

__c. Open the createBlogPost.html using the Rich Page editor to display the source and design views of the html page.

__i. Right Mouse click on the createBlogPost.html file.

__ii. Select Open With ! Rich Page Editor from the context menu. And, then select the Source View.

(77)

__d. The body of the HLML file contains a simple HTML form that contains input fields for the Blog Title and Blog Body. The form invokes the PostBlog Servlet when the Submit button is pressed.

The HTML source for the createBlogPost.html should look similar to the illustration below

2.3.4 Summary

In this section of the lab, you have explored the components of the Web Application that makes use of the JPA project to access content from a database. You explored the following aspects of the Web Project:

• Configuration of the Web project to place the output of another project in the WEB-INF/lib. • How to create two Servlets that make use of JPA.

• How to configure a resource reference using annotations. • How to create a simple HTML based form.

(78)

2.4 Configuring the server and running the application

Congratulations your application review is now complete. Now the fun starts as you configure the server so it can connect to a database.

2.4.1 Configuring the Data Source to connect to the database

__1. In this lab, a simple embedded derby database is required. In this step, you will make the derby.jar available as a shared library for the Liberty Profile Server where the Derby library will be available to the runtime environment.

__a. To do this, you will use eclipse to import the derby.jar file, from the Lab Files directory, into the Liberty Server shared resources folder.

__b. If not already started, Launch Eclipse and open the Java EE perspective.

__c. In the Enterprise Explorer view, Navigate to the shared resources folder in the Liberty Server configuration: WebSphere Application Server V8.5 Liberty Profile ! shared !

resources

__d. Create a new folder named derby.

(79)

__ii. Enter derby in the folder name field. And then click Finish to create the new folder.

__e. Import the derby.jar into the Derby shard resources folder.

__i. Right mouse click on the derby folder. And then select Import from the context menu.

__ii. On the Import dialog, select General ! File System. And then click the Next button.

__iii. On the File System Import Dialog, use the Browse button, next to the From Directory field, and navigate to “X:\Student\LabFiles\Lab02\”.

(80)

__v. Click the Finish Button to import the derby.jar file.

__2. The server does not start the necessary components required for database access unless configured to do so. This means the server is currently unable to access databases. To enable the database support the jdbc-4.0 feature needs to be configured.

__a. In Eclipse, Switch to the Java EE Perspective. This perspective includes the Servers view.

__b. Navigate to the Servers view and expand WebSphere Application Server V8.5 Liberty Profile at localhost [labServer]

This item can be expanded to show a logical view of the configuration. However you need to edit rather than view the configuration.

(81)

__c. Right click Server Configuration [server.xml] Liberty Server for Labs and click open.

__d. Select the Design tab on the configuration editor.

__e. Click the Feature Manager option from the Configuration Structure section.

__f. On the right side of the editor the details are viewable. To add a new feature click Add... to add a new feature into the list.

(82)

__g. Click the down arrow and select jdbc-4.0.

__h. Save the file.

If the server is still running after the earlier activity, switch to the console view to see the server report that it has responded to the new feature being configured. The server can now support database access; however no DataSources have been configured.

__3. The next step is to configure the server so it can locate the database jar from the previous step. __a. In the Design tab of the server configuration editor, click Server Configuration and click

Add.

__b. Start typing Shared Library and when highlighted click OK.

__c. The shared library needs to have an

id

so it can be used elsewhere. In the Shared Library Details section in the id field enter derby.

(83)

__d. In the Configuration Structure section, click Shared Library. And, then click Add.

__e. Click Fileset Reference. And then click the OK button.

(84)

__g. Save the configuration

This has created a shared library that contains the derby jar. If you switch to the Source view it looks like this:

Notice that the Design view shows all the values, but the Source view only includes values which are different from the defaults.

__4. Back in the Design tab the next step is to define the JDBC driver. __a. Click ServerConfiguration and click Add.

__b. Type JDBC Driver and when selected click OK.

__c. On the JDBC Driver Details enter derbyDriver into the Id field. __d. In the Shared Libraries field select derby from the pull down menu.

(85)

__5. The next step is to define a DataSource

In the persistence.xml, this was created using the resource ref JNDI name java:comp/env/jdbc/blogDB.

By default, if no binding is provided, then the resource ref name of jdbc/blogDB is used to look up an object in JNDI.

__a. In the Design tab click Server Configuration and click Add. __b. Type Data Source and when highlighted click OK.

__c. In the JNDI name field on the Data Source Details enter jdbc/blogDB __d. In the JDBC driver field select derbyDriver from the pull down menu.

(86)

__6. Now, configure the derby specific properties:

__a. In the “Configuration Structure” click the DataSource and click Add. __b. Select Properties for Derby Embedded. And, thenclick OK.

__c. In the Properties forDerby Embedded Details, choose false from the Create Database pull down menu.

TIP: The Derby database required for the lab has already been created in the virtual image. Therefore, the create database flag should be set to false.

__d. In the Database name enter C:\Student\Derby\databases\blogDB

(87)

__e. Save the configuration.

Looking in the source view you should see the following:

<properties.derby.embedded createDatabase="false" databaseName="C:\Student\Derby\databases\blogDB"/>

</dataSource>

This configures a derby Data Source in JNDI at jdbc/blogDB and specifies the location of the blogDB database.

__7. Add the JPA-2.0 feature to the Liberty Server configuration. __a. Select the Design tab on the configuration editor.

(88)

__c. On the right side of the editor the details are viewable. To add a new feature click Add... to add a new feature into the list.

__d. Click the down arrow and select jpa-2.0.

(89)

__8. The application has now been created, and the server configured to support it. The next step is to run the application.

__a. If the server is running, Stop the Liberty Profile Server [labServer], using the STOP icon located on the Server view.

__b. Start the Liberty Profile Server. Use the Start icon in the Servers view to start the server if necessary.

__c. When the server starts, navigate to the createBlogPost.html file in the Blog Web Project.

__d. Right click createBlogPost.html file in the Enterprise Explorer view. __e. Select RunAs > Run on Server.

__f. Select the WebSphere Application Server V8.5 Liberty Profile andclick Finish. __g. The application is be added to the server and the web page opened.

(90)

__9. Test the Blog application

__a. Enter a title and body into the blog and click the Submit Query button. The post is written to the database and a list of the posts shown.

(91)

__b. To prove that the post was persisted, select the server in the servers view, rightclick on the server, and select restart.

__c. Then refresh the web browser to see the content remains unchanged.

2.4.2 Summary

In this exercise you have learned how to:

• Configure a Liberty profile server.

• Add features to the server configuration to enable additional capabilities. • Configure a library that contains a JDBC driver for database access.

• Configure a DataSource that can be used by applications, or JPA to persist data.

• Have a feature automatically added to the configuration based on the Liberty Profile’s intelligence

about features being used in the Blog application.

This demonstrates how little configuration is required to access a database.

2.5 Securing an Application

In this next section of the lab, you are going to secure access to the blog application. The Liberty Profile maintains security in a default install by ensuring that it only listens to requests from the local host. In this exercise you learn how to configure the server to listen for https requests, configure a basic user registry, and protect access so only authorized users can post to the blog.

2.5.1 Configure the Liberty server for https support

(92)

• Create self-signed SSL certificates

• Configuring the server to use these certificates for SSL

__1. Create a self-signed certificate

__a. The securityUtility command line tool needs to be used to create the SSL certificates: __b. First, minimize the eclipse workbench

__c. Open a Windows command prompt

__d. Navigate to the directory the liberty profile was installed to: C:\Student\LibertyWork\wlp __e. To create the certificate in the command prompt, type the following text as a single line:

bin\securityUtility createSSLCertificate server=labServer --password=passw0rd

This generates the keystore and places it in the server configuration directory.

The utility also produces output of the XML snippet that can be copied into the server.xml to use the keyStore.

__2. Update the server configuration with the ssl feature and keystore __a. Navigate to the server.xml file in the eclipse workbench.

L01: Using the WebSphere Application Server Liberty Profile for lightweight, rapid development. Lab Exercise