OTN Developer Day Enterprise Java

Oracle WebLogic Server Development with Eclipse, Maven, and Hudson

Oracle Technology Network. Its code for sharing expertise.

Come to the best place to collaborate with other IT professionals.
Oracle Technology Network is the worlds largest community of developers, administrators, and architects using industrystandard technologies with Oracle products. Sign up for a free membership and youll have access to: Discussion forums and hands-on labs Free downloadable software and sample code Product documentation Member-contributed content Take advantage of our global network of knowledge.

JOIN TODAY

Go to: oracle.com/technetwork

Copyright 2010, Oracle and/or its afliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its afliates. Other names may be trademarks of their respective owners. 10039688

Lab and User Details

Operating Sytem User: User Home Directory: WebLogic Home: WebLogic Domain: WebLogic Administrator: WebLogic Console URL: WebLogic Port: Oracle Database: Oracle SID: Oracle Port: Oracle Administrator: Subversion URL: Subversion User: WLS Dev Lab: WLS Maven Lab: WLS OEPE Lab: oracle/welcome1 /home/oracle /labs/wls1035 /labs/wls1035/user_projects/domain/auctionDev weblogic/welcome1 http://localhost:7001/console 7001 Oracle XE Universal Database 10.2 XE 1521 system/welcome1 svn://localhost/otnvdd/obay/trunk oracle/welcome1 /home/oracle/labs/Dev_labs/labHome /home/oracle/labs/Dev_labs/labHome/WLS_Maven /home/oracle/labs/Dev_labs/labHome/WLS_DEV_OEPE

Introduction
In this lab, you will be simulating working in a development environment that consists of the following software components: Oracle WebLogic Server 11g R1 (10.3.5) Oracle XE Universal Database 10.2 Apache Maven 3.0.1 Subversion Eclipse 3.6 (Helios) with Oracle Enterprise Pack for Eclipse 11gR1 (11.1.1.7.3) Hudson 1.3.x

In this lab today, you will be performing the following: Using Maven to build a multi-module Java EE application and deploy it to WebLogic Server Using Oracle Enterprise Pack for Eclipse (OEPE) and the M2 Plug-in for Eclipse, to build the same multi-module Java EE application and deploy to WebLogic Server, from a typical IDE environment Install and configure Hudson to run on WebLogic Server and create a Maven 2/3 job to build the oBay projectmvn Use Hudson with Subversion to perform continuous integration testing of the Java EE application

In this lab, you will be working with a Java EE application called oBay which has been developed to provide an online auction/bidding system. The oBay application consists of a set of modules that have been developed using a combination of Java EE technologies, combined with Oracle Coherence and supplemented with open-source frameworks such as Spring and Spring-MVC to handle various aspects of the overall application. Subversion is used as a source control management system for the development environment. The oBay project is stored in a local subversion repository, and has been checked out for use in this lab. The oBay application has been developed as a multi-module Maven project. Each individual module is described using a project description file (pom.xml) and corresponding Maven plug-ins are used to compile and package the artifact. A parent project defines the project settings and identifies the set of child modules that the project is composed from. Maven is used to compile, package and manage the overall project. In this lab, the new Oracle WebLogic Maven Plug-in is used to both deploy and undeploy the EAR file artifact produced from the project, to a WebLogic Server domain. An example is shown of binding the deployment goals of the Oracle WebLogic Maven Plug-in to the Maven integration-test lifecycle phase, so that the application is automatically deployed, tested and undeployed as part of the standard Maven install lifecycle. Eclipse/OEPE is used to show how the same environment and Maven operations can be used directly from a development environment. The Hudson continuous integration server is used to demonstrate how continuous integration operations can be performed. The Hudson application is deployed to WebLogic Server. Using the Hudson console, a new job is created directly from the oBay project stored in its Subversion location, with the job natively understanding the Maven nature of the project. Upon a signal to conduct a build, the Hudson job will check out (or update) the oBay project directly from Subversion repository, conduct a build using the Maven project descriptions and report the results on its dashboard. Using the Oracle WebLogic Maven Plug-in, the build will ultimately incorporate an automatic deployment of the application to a WebLogic Server domain, the execution of an Integration Test to validate the application deploys successfully, and an undeployment operation to leave the WebLogic Server domain in a clean state. The results of the Integration Test will be used to create the overall result of the job execution.

Explore Maven and WebLogic Maven Plug-in

In this section you will explore the oBay Maven project using the command line. Open a terminal using the WLS Terminal launcher on the desktop:

Apache Maven 3.0.1 has been installed in the directory /opt/apache-maven-3.0.1 and the bin directory placed in $PATH. In the terminal you should be able to run mvn version and get something like:
[oracle@localhost obay-ee]$ mvn -version Apache Maven 3.0.1 (r1038046; 2010-11-23 02:58:32-0800) Java version: 1.6.0_24 Java home: /labs/wls1035/jdk160_24/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux" version: "2.6.18-194.el5" arch: "i386" Family: "unix"

If you get an error when running the mvn version command and you are unsure how to set up your environment correctly, please ask your instructor for help.

Apache Maven Configuration

By default the user specific Maven are stored in the users home directory in the .m2/settings.xml file. For this lab this will be /home/oracle/.m2/settings.xml. You may need to edit the settings.xml to configure Maven to use an appropriate proxy server to access the internet. This should not be necessary as the local Maven repository in the lab environment is fully populated with all specified dependencies and plugins. If you find it necessary to specify the proxy server to resolve any later dependencies, use the following as a template:
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> <proxies> <proxy> <active>true</active> <protocol>http</protocol> <host>www-proxy.us.oracle.com</host> <port>80</port> <nonProxyHosts>localhost</nonProxyHosts> </proxy> </proxies> <pluginGroups> <pluginGroup>com.oracle.weblogic</pluginGroup> </pluginGroups> </settings>

The default Maven local repository location is used with this lab, which maps to /home/oracle/.m2/repository. All artifacts that are either downloaded from remote repositories or built and installed from this project are stored here. The plug-ins are also stored here. Explore the directory if you have an interest.

Building WLS Projects with Maven

In your lab folder, you will find a WebLogic Server Maven project called OBay, which you will build using Maven and deploy to a WebLogic Server 10.3.5 domain called auctionServer.
4

The auctionDev domain has already been created for you and you should start the Admin Server for the auctionDev domain using the WLS Auction Dev Server desktop launcher:

You should see a message in the console output <Server started in RUNNING mode> to indicate that the server has been started successfully if you do not see this message, please ask your instructor for help making sure your environment is correct:

Using the link on the desktop, open the obay-ee folder:

This folder hosts oBay application and represents the top level Maven project.

Open the top-level pom for the oBay project (obay-ee/pom.xml) by right mouse clicking on it and opening it in the text-editor. Review the contents of the file and its settings. Note the properties highlighted in bold, which will be used to specify the deployment target for the WebLogic Maven plug-in. Since this is the parent POM for the oBay project, all the child modules will inherit these property settings.
<?xml version="1.0" encoding="UTF-8"?> <project> <modelVersion>4.0.0</modelVersion> <groupId>oracle.demo.appgrid.obay</groupId> <artifactId>obay</artifactId> <name>OBay :: App Grid Application Sample</name> <packaging>pom</packaging> <version>1.0</version> <description>Maven version of oBay</description> <inceptionYear>2009</inceptionYear> <url>http://scythe.ocsprojects.com</url> ... <modules> <module>AuctionModel</module> <module>AuctionSecurity</module> <module>AuctionUtils</module> <module>AuctionServices</module> <module>AuctionWeb</module> <module>AuctionEAR</module> <module>AuctionWebSvcClient</module> </modules>

... <properties> <wls.application.home>/labs/wls1035/user_projects/applications</wls.application.home> <wls.domain.name>auctionDev</wls.domain.name> <wls.adminurl>t3://localhost:7001</wls.adminurl> <wls.user>weblogic</wls.user> <wls.password>welcome1</wls.password> </properties> </project>

You should also take a look at the AuctionEAR/pom.xml, which is configured to use the weblogic-mavenplug-in with the properties set in the top-level pom:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>oracle.demo.appgrid.obay</groupId> <artifactId>AuctionEAR</artifactId> <packaging>ear</packaging> <name>AuctionEAR</name> <version>1.0</version> ... <plugin> <groupId>com.oracle.weblogic</groupId> <artifactId>weblogic-maven-plugin</artifactId> <version>${wls.version}</version> <configuration> <adminurl>${wls.adminurl}</adminurl> <user>${wls.user}</user> <password>${wls.password}</password> <name>${project.build.finalName}</name> <remote>false</remote> <upload>false</upload> </configuration> ... <executions> <execution> <id>deploy</id> <phase>pre-integration-test</phase> <goals> <goal>deploy</goal> </goals> <configuration> <source> ${project.build.directory}/${project.build.finalName}.${project.packaging} </source> </configuration> </execution>

http://maven.apache.org/maven-

<execution> <id>undeploy</id> <phase>post-integration-test</phase> <goals> <goal>undeploy</goal> </goals> </execution> </executions> </plugin> ... </project>

From the WLS Terminal, change directory into the WLS_Maven lab: > cd /home/oracle/labs/Dev_labs/labHome/WLS_Maven/obay-ee Build the entire oBay application using the parent project with the Maven commands mvn clean followed by mvn package. > mvn clean

> mvn package

The execution of these two Maven commands will cause the overall oBay Maven project to build, which will in turn build each of the child projects. For this project, this will result in seven child projects to be built that represent different aspects of the application; for instance the domain model (AuctionModel); the JPA/EJB service layer (AuctionServices) and the Web front end (AuctionWeb). The AuctionEAR project is then used to assemble the separate child projects into a deployable artifact in the form of an EAR file. To deploy the AuctionEAR application for testing to a WebLogic Server domain, you can use the weblogic-maven-plugin and perform the operation directly from Maven. Change directory to the AuctionEAR project folder and issue the following command: > cd AuctionEAR > mvn com.oracle.weblogic:weblogic-maven-plugin:deploy -Dsource=target/AuctionEAR.ear

The Dsource=target/AuctionEAR.ear property specifies the deployment artifact for the weblogic-mavenplug-in deployment operation to use. The rest of the properties the weblogic-maven-plugin uses are obtained via property settings in the parent Maven project. After the deployment has completed, you can verify the application was successfully deployed. Open a Web browser from the menu bar and test the application using the URL: http://localhost:7001/obay

10

Once you have confirmed the application was deployed successfully, you can then close the browser window and undeploy the application using the weblogic-maven-plugin with the command: > mvn com.oracle.weblogic:weblogic-maven-plugin:undeploy

11

To observe the automatic binding of the Maven phases with the weblogic-maven-goal bindings, you can execute the mvn install command at the oBay project level, or on the AuctionEAR module. This will build, package, and install the artifacts that the overall oBay project is composed from. As part of this lifecycle, the integration-test phase will be called, which will in turn execute the weblogic-maven-plugin deploy and undeploy goals. The Maven SureFire plug-in is used in the project to execute a very simple HtmlUnit based test case, which validates that the application can be accessed successfully by checking the title of the home page. > cd /home/oracle/labs/Dev_labs/labHome/WLS_Maven/obay-ee > mvn install The screen shots below show the output from this command split across several screens. You will observe that the Maven project is built and packaged as previously seen. However you will now additionally see automatic execution of the weblogic-maven-plugin deploy goal to deploy the application; the execution of the SureFire plug-in to run the oracle.demo.auction.ear.SimpleITCheck test case to validate the deployed application; and finally the execution of the weblogic-maven-plugin undeploy goal to undeploy the application from the WebLogic Server domain you are using. This is what you should see when you execute mvn install on the oBay parent project. This causes each child module to be executed, including the AuctionEAR module in which the weblogic-maven-plugin is bound to the Maven pre/post-integration-test phases.

12

Followed by the following screen.

When the install lifecycle of the AuctionEAR is called, the integration-test phase will be executed and will result in the application being deployed, the integration test case (SimplePageCheckIT) being executed and the application being undeployed.

13

This type of project configuration can be useful when combined with Continuous Integration testing, as we will see later on with the use of Hudson. Before continuing with the lab, please shutdown the running WebLogic Server auctionDev domain. (just type Control-C in the window where you see the output from the server).

14

Using Maven in Eclipse/OEPE

The easiest way to use Maven from within Eclipse/OEPE today is to use the popular third-party m2eclipse plug-in; this has already been installed in the copy of OEPE 11.1.1.7.3 Helios that you will find in the lab image. Start Eclipse by clicking the OEPE 11gR1 (Eclipse) desktop launcher:

And selecting the WLS_DEV_OEPE workspace:

Take a few minutes to explore the project using the Oracle Enterprise Pack for Eclipse (OEPE) environment with the m2eclipse plug-in. Note the Maven Repositories view at the bottom of the workspace, where you can explore the contents of the local repository. Also take a look at the various POM files that exist in the modules, such as obay/pom.xml, using the editors available in OEPE.

15

Open the POM editing dialog by selecting the AuctionEAR/pom.xml file and the Open with Maven POM Editor option. Here you can see the POM configuration, including the plug-in configurations that specify the weblogic-maven-plugin execution bindings to the Maven phases:

16

For this lab, we will be starting and stopping the target WebLogic Server instances from within OEPE using the WebLogic Server plug-in, so before starting please make sure that any WebLogic Server instances from the previous exercise have been shutdown (just type Control-C in the window where you see the output from the server). The workspace already contains a WebLogic Server domain configured for the lab. Start the server by selecting the Servers view (at the bottom of the workspace), right-click on the server icon and select Start.

After a few seconds you will see the output from the server appear in the Console view and you should soon see a message indicating that the server is up and running:

17

To get started with the project, execute a maven clean operation to remove any traces of previous builds. To this, open the top-level obay project and right-click on pom.xml, then select Run As -> Maven clean and you will see the Maven output in the Console view:

18

Once the clean lifecycle has completed, you can build and package the application. This is done using the Maven package lifecycle. You can run mvn package by selecting the top-level pom.xml, rightclicking and selecting Run As -> Maven package:

19

The WebLogic Server administration console is useful for developers as well as administrators it can be used to deploy/undeploy graphically, create server side resources like JDBC connection pools, JMS Destinations, etc, To use it, simply open the WebLogic Server admin console either inside OEPE by going to the server tab right clicking on the WebLogic Server icon clicking on the option to start the admin console, or from a browser on your desktop by opening the URL: http://localhost:7001/console. Log on as weblogic/welcome1 and go to the deployments tab:

If, as many developers do, you prefer to deploy the oBay application without leaving Eclipse, you can now use the WebLogic Maven plug-in directly from within Eclipse. Open the AuctionEAR project, right-click on pom.xml, select Run As -> Maven Build (Shift+Alt+X M) and then select the AuctionEAR:deploy option. Make sure to choose the correct pom.xml:

20

You should see the WebLogic Maven plug-in deploying the application refresh the admin console window to see the new application listed in the deployments tab.

21

Follow the same process to undeploy the oBay application from within Eclipse, using Run As -> Maven Build (Shift+Alt+X M) and then the AuctionEAR:undeploy option:

22

Before going on to the next lab, please now shutdown Eclipse. This will automatically stop the WebLogic Server instance that Eclipse has started.

23

Using the Hudson CI Server with WebLogic Server

In this lab, you will see how easy it is to configure Oracle WebLogic Server to host Hudson CI, a popular continuous integration system designed specifically for Java and Maven development. In this simulated environment, you will use the existing WebLogic Server domain auctionDev and deploy the Hudson web application (hudson.war) to the Admin Server. You will then configure Hudson for your lab environment, create a new Maven/23 job directly from the Subversion location of the oBay project, and run a build to validate the job. Finally, you will make an update to the project in Subversion and observe how Hudson is automatically notified and a new build job kicks off. Note: this configuration is not ideal since the CI server is running on the same server that is used to test the deployed application. In a typical architecture, these servers would be separate from one another with the CI server assigned to a separate server that was not used to deploy test applications and experience possible outages if restarts were ever required. Step 1 Start the WebLogic Server auctionDev Domain The auctionDev domain has already been created for you and you should start the Admin Server for the auctionDev domain using the WLS Auction Dev Server desktop launcher:

You should a message in the console output <Server started in RUNNING mode> to indicate that the server has been started successfully if you do not see this message, please ask your instructor for help to make sure your environment is correct:

24

Step 2 Deploy the Hudson web application (hudson.war) When you see that the auctionDev Admin Server has started, open a browser session and access the WebLogic Admin Console at http://localhost:7001/console Login to the admin console as: weblogic/welcome1.

25

Open the Deployments tab in the admin console window and click on Install to begin the deployment process. Select the hudson.war web archive from the /labs/wls1035/user_projects/applications/hudson directory and click Next:

26

Select Install this deployment as an application and click Next:

27

Then click Finish to complete the deployment:

28

Step 3: Configure Hudson CI Server When you have finished deploying the Hudson CI Server to WebLogic Server, you can access the Hudson web application from a browser at http://localhost:7001/hudson

29

Click on Manage Hudson to configure the Hudson CI Server and then click the Configure System link. To configure Hudson, you need to specify the locations of the JDK and Maven installations you wish it to use. For the JDK: Click the Add JDK button and enter the name JDK 1.6.0_24. Specify JAVA_HOME location as /labs/wls1035/jdk160_24. Ensure you uncheck the Install automatically box to specify an existing installation. For Maven: Click the Add Maven button and enter the name Maven 3.0.1. Specify the MAVEN_HOME location to be /opt/apache-maven-3.0.1. Ensure you uncheck the Install automatically box to specify an existing installation.

30

Scroll to the bottom of the configuration page and click the Save button. Step 4: Create a Hudson Job for oBay From the Hudson Dashboard, click on the New Job link. Specify the name the job as oBay Project Build, select the Build as maven2/3 project option and click OK.

31

Select Subversion as the Source Code Management system. Specify the SVN Repository URL as: svn://localhost/otnvdd/obay/trunk/obay-ee.

32

Scroll down and select the Poll SCM option. Enter @annually in the schedule field. Scroll down and enter clean install in the Goals and options field, to specify the Maven lifecycle for this job. Save the configuration.

33

From the Project oBay project build page, click on the Modules link to create the new Hudson workspace. Click the perform a build link to start the build process.

34

In the Build History pane, there is a link to the current build in progress. Click on this link and then click Console Output to view the progress of the build. You should see Hudson create a workspace for the project and download the project files from the SVN server:

35

This may take a short while. When Hudson has finished checking out the files to the project workspace, you should see a Maven build started (mvn clean install). When this has finished successfully, you will see the status of the Hudson build change to success (a blue icon):

36

37

Scrolling through the console output, you will see that the weblogic-maven-plugin is executing to automatically deploy and undeploy the application as part of the Maven install lifecycle, as well as the execution of the SimplePageCheckIT test case. This is exactly the same as what you had seen earlier using Maven directly from the command line. However now it is being managed entirely from an automated Hudson job.

38

Scroll to the top of the page and click the Back to DashBoard link to return to the project dashboard. From here click the link for oBay Project Build then Latest Test Result. Here you will see the results displayed from the same integration test case that we explored earlier.

39

Drill down through the links to see the actual test cases that were executed and the results.

40

When you have finished exploring, click the Hudson link from the bread crumbs at the top of the page to go back to the overall Hudson job page. The current overall project status should be displayed, which provides you with an immediate view of the current status of the project based on the contents of the Subversion repository.

41

Step 5: Observing Automated Hudson Builds After Subversion Check-ins When the Hudson workspace was created for the oBay Project job, it was populated with the project contents directly from the Subversion repository that hosts the oBay Project source code. Since Hudson has Subversion knowledge, it is able to be notified when changes are made to the originating projects in Subversion. When a change event is received for a project for which Hudson has a job, Hudson will initiate a new build job that checks out the latest contents from Subversion, then builds, tests and reports a status for the current state of the project. This enables Hudson to continually monitor a project over time as check-ins are performed by developers. To observe this behavior, you will now make a change to a file in the oBay project, and commit the change back to the Subversion repository. This will cause Hudson to initiate a new build job that you will be able to observe directly from the Hudson dashboard. Open the WLS Terminal from the desktop launcher.

42

Change directory to the Maven project in your labs directory: > cd /home/oracle/labs/Dev_labs/labHome/WLS_Maven/obay-ee Using vi, make a change to the FILE_TO_UPDATE file and save the file. This file has no bearing on the project and just provides a way to simulate a developer change. You can change or add anything to the contents of the file and save it. Edit the file using an editor such as vi, or the GUI driven Gnome text editor (Linux OS menu, Applications -> Accessories -> Text editor: >vi FILE_TO_UPDATE Now issue a Subversion command to check the status of the project: >svn status where you should see that the FILE_TO_UPDATE has been locally modified: M FILE_TO_UPDATE

With the change successfully done, you will now commit the change back to the Subversion repository and then quickly switch to the web browser to watch for changes in the Hudson dashboard. >svn commit m Testing subversion change with Hudson Troubleshooting tip: Do not copy and paste the above command. In the web browser, click on the root Hudson link in the upper left corner. You should see a new build job appear momentarily. This build job was initiated from Subversion by using a post-commit trigger to HTTP post a notification to Hudson telling it about the change to the project.

43

Click the oBay Project Build link to drill down into the project details. Here you will see a list of the recent builds that have occurred as well as the status and other aspects of the job.

44

Click the Last Build link to see more details of that specific build. Here you will see details of what caused the job to be started, as well as information about the changes that were discovered in the Subversion repository. Following steps above you should see that the Changes description matches the message you used to commit the change to the FILE_TO_UPDATE to the Subversion repository. This indicates that the build is based on the revision of the project that you caused through the change and commit of the file.

45

This simple final example demonstrates that Hudson was able to immediately update its version of the project and build, test and report on the status of the project in a fully automated manner. As part of this automated build, the exact same weblogic-maven-plugin deployment operations and integration test runs were conducted as part of the Maven install lifecycle that was executed by the Hudson job. If changes were made to the actual application code that resulted in real tests failing, then Hudson would be able to provide very quick feedback that the project has been broken. If you click through the links Latest Build/Modules/AuctionEAR you will see a link to view the set of Executed Mojos. This displays the sequence of Maven Mojos that were used during the M<aven lifecycle that was executed. Here you will see that a sequence of Mojo executions that includes weblogic:deploy, integration-test, weblogic:undeploy. This shows the execution of the weblogic-mavenplugin goals that were configured to execute automatically as part of the Maven install lifecycle.

46

If you wish to explore further, click back to the latest build of the project to view the test results. View the console output to verify the execution of the deployment and integration test operations. Should you wish to dive in deeper, and observe the effects of an Integration Test failure, you could make a change to the SimplePageCheckIT.java test case so that the expected result is different. Or you could locate the source of the page that is rendered as the home page and update the title. Then check the changes back into Subversion and observe what happens on the Hudson dashboard.

Summary
In this lab, you have experienced using WebLogic Server with a relatively complex, multi-module Maven project. You have built the overall oBay application using the various Maven project descriptions that are provided by the modules, and used several Maven lifecycle options to perform operations. You have used the WebLogic Maven Plug-in to perform deployment operations of the project artifact to a running WebLogic Server domain. You have seen the binding of the WebLogic Maven Plugin deployment goals to a Maven phase so that the deployment operations are automatically executed as part of Maven install lifecycle, allowing Integration Tests to be conducted against the current build of the application running on a server. You then deployed and configured the Hudson CI server to run on a WebLogic Server domain. You created a new Hudson job to automate the testing of the oBay project and observed the results of initiating a manual build. Finally you observed how Hudson could be integrated with Subversion so that changes checked in to the project can be continuously and automatically monitored.
47