So far, we’ve covered Maven deployment of Java EE EAR to Glassfish 3.x, JBoss 5.x & 6.x. In this article, I’m going to show you how to deploy the EAR through Maven to Oracle’s WebLogic (both 10.3.x and 12.x). I truly have to give credit to the WebLogic team as regardless of the area of Maven deployment or Maven Java EE project dependency, WebLogic is by far the easiest and the simplest among all of the Application Servers that I have dealt with in terms of Maven. Although the production licenses are a little pricy, but remember this, what you pay is what you get.

For those who are new to this series, this article is already the 5th part of the series of Building and Deploying Java EE EAR with Maven to Java EE Application Server. You may gain access to all the articles in this series by scrolling down to the bottom of this page, you should be able to see all the links to the rest of the articles. However, you don’t have to follow all of them. If you are only interested in deploying the EAR to Oracle’s WebLogic, all you need to read is Part 1, Part 2 and Part 5 (which is this).

Warning On Compatibility

The contents outlined in this article was only tested on WebLogic 10.3.x and WebLogic 12c. Please proceed at your own risk.


Creating the WebLogic Server Domain

I always love to get the WebLogic server installation files in the form of .zip from Oracle’s download page. So, assuming that you have the server files in .zip, please extract the files to your preferred directory and this directory shall be call MW_HOME. before moving forward, it is a must to create an environment variable of MW_HOME which points to the server directory.

Moving forward, we need to create the domain directory for the server. To do this, follow the below:

  1. Open the terminal, and make sure that the MW_HOME environment variable was properly defined in the OS.
  2. Change the directory to <MW_HOME>/wlserver/common/bin. Execute the command for Linux/Unix or config.cmd for Windows. This will bring out the UI for WebLogic domain creation.
  3. Just follow through the screen and for the purpose of this article, just assign the domain name as DummyDemoDomain and the domain directory/location as somewhere other than MW_HOME (Please note that the domain directory must not be the same location as MW_HOME).
  4. Just assign the username as “weblogic” and password as “wlpasswd1234” for now.
  5. Select “development” mode for now and select the JDK.
  6. In the optional configuration page, just select all.
  7. For the rest, just accept the default and click through the screens until you reach the summary page. Just the “create” button to create the domain.
  8. To start the server, go the the terminal and change the directory to <DummyDemoDomain_path> and execute for Linux/Unix or startWebLogic.cmd for Windows.

Configuring the WebLogic Domain

First time console login and DB data source setup (MySQL specific):

To configure the WebLogic domain, follow the below:

  1. Through the web browser, go to http://<your_IP>:7001/console/ (e.g. http://localhost:7001/console/). Login to the console by providing the username and password that you’ve assigned during domain creation. You should be able to see the home page with all the domain configuration links.
  2. The first thing that we need to do is to setup the data source. Just click on the Data Sources link under the “Services” section.
  3. Click “New” and select “Generic Data Sources“. For the purpose of this article, assign the name as “MySQL DB Data Source“, the JNDI as “jndi/DummyDemoMySQLDB” and select the Database Type as “MySQL“. Click “Next“.
  4. Accept the Database Driver as: “MySQL’s Driver (Type 4) Versions: using com.mysql.jdbc.Driver“. Click “Next“.
  5. In the Transaction Options section, enable “Supports Global Transaction” and select “Emulate Two-Phase Commit“. Click “Next” to proceed.
  6. In the Connection Properties section, just key in the relevant details (e.g. Database Name -> DUMMY_DEMO_DB, Host -> localhost, Port -> 3306, etc.). Click “Next“.
  7. In the Test Database Connection section, just click on the “Test Configuration” to see if the DB is functioning. Click “Finish” when done.

Configuring the JMS:

The DummyDemoJavaEE5 app requires a JMS Queue and a Connection Factory. To setup a separate connection factory and a queue, just perform the below:

  1. If you are not back to the “Home” page, just click on the “Home” link of the WebLogic Admin Console.
  2. Under the section Services -> Messaging, click on “JMS Server“.
  3. Now we are about to create a new JMS Server, click on the “New” button and start filling the blanks. Assign the name of the server as “DummyDemo JMS Server” and accept the Persistent Store as “(none)” (You may experiment with the persistent store in later as it allows JDBC or File as a storage avenue). Click “Next“.
  4. In the Select targets section, just select the default, which is “AdminServer” for now. Click “Finish” when done.

Next, we need to create a separate JMS Module. To do this, perform the following:

  1. Back to the “Home” page, select “JMS Modules” in the section of Services -> Messaging.
  2. Click on the “New” button, in the Name field, just type “DummyDemo JMS Module“. Click “Next“.
  3. As for the target servers, select “AdminServer” for now. Click “Next“.
  4. Here, it will ask you whether to add resources to the JMS system module? Enable it and click “Finish“.
  5. Then, you’ll be leaded to the resources page. Click on the “New” button.
  6. Let’s add a connection factory by selecting the Connection Factory radio button and click “Next“.
  7. Assign these values to the fields and leave the rest as default:
    • name: “TestQueueConnectionFactory
    • JNDI: “jms/TestQueueConnectionFactory

    Click “Next“.

  8. Select “AdminServer” as the target server. Click “Finish“.
  9. Now, you are brought back to the resources page, click on the “New” button again, this time, we’ll create the queue.
  10. Select the “Queue” radio button and click “Next“.
  11. Assign these values to the fields and leave the rest as default:
    • Name: “TestQueue
    • JNDI Name: “jms/TestQueue

    Click “Next“.

  12. In the subdeployment section, click on the “Create a New Subdeployment” button. Accept the default name and click “Ok”.
  13. Then, the list of targets will appear at the bottom of the page. Select the “DummyDemo JMS Server” that we’ve created just now, and click on the “Finish” button.

and…that’s it for the WebLogic config.

Compiling & Making The WebLogic Maven Plugin Available

You must be thinking…”WHAT?! Do I need to do this myself??? Isn’t there any public repository for downloading the plugin?”, well…actually, you can’t find the WebLogic Maven Plugin in any of the public Maven repositories…not at the moment. Oracle did not publish any of their intellectual properties to be made available in any 3rd party public repository, which I believe it has something to do with their licensing restriction. But, anyway, it shouldn’t stop you from getting things up and running.

The below steps are necessary to get the WebLogic Maven Plugin jar file created and be made available to your Maven’s local repository, so that it could be made as a dependency for any of your own Maven projects.

Compiling the WebLogic Maven Plugin

You may read more about the WebLogic Maven Plugin from Oracle’s documentation site here. But for the sake of getting things done as fast as possible, I’ll just outline the step-by-step guide in doing this.

  1. Again make sure the MW_HOME system variable defined and the java command is in the path.
  2. In the terminal, change the directory to <MW_HOME>/wlserver/server/lib/ and execute the command:
    java -jar wljarbuilder.jar -profile weblogic-maven-plugin
  3. Once the jar file is produced in the same directory, we need to extract the pom.xml file that was packaged inside the jar file so that it could be used as a plugin install descriptor for Maven. To do this, just type:
    jar xvf weblogic-maven-plugin.jar \
  4. The pom.xml file was extracted with all of the subdirectories. Now, you just have to copy the pom.xml out from the subdirectories of META-INF/maven/ to the same directory as the weblogic-maven-plugin.jar.

Now if were to take a look at the extracted pom.xml, it will look like this:

It is important to take note of the <version> value. This is the version number that identifies every WebLogic Maven Plugin for specific WebLogic Server version. So, every time when you need to deploy to a new WebLogic server which is of a different version, you will need to recompile the WebLogic Plugin again with a different version number and install into the your own local Maven repository or the shared Sonatype’s Nexus or the JFrog’s Artifactory repository if you have any (which is recommended). For those that need guidance in installing the jar to your local Maven’s repository, just read on.

Installing the WebLogic Maven Plugin to Maven’s Local Repository

In the same directory as the weblogic-maven-plugin.jar and the pom.xml file, execute the following command:

mvn install:install-file -Dfile=weblogic-maven-plugin.jar -DpomFile=pom.xml

Using and Configuring the WebLogic-Maven-Plugin

After installing the weblogic-maven-plugin.jar to your Maven repository, it is easy to use it off the shelf. Looking back to the DummyDemo-ear module written in Part 1 and Part 2 of the series, please edit/replace the <path>/DummyDemoJavaEE5/project/DummyDemo-ear/pom.xml to the below:

pom.xml Explained
Looking at the modified pom.xml, the WebLogic Maven Pluging will be used at the <plugin> section. We will still tie the deployment to the Application Server at the “package” build phase and the undeploy from the Application Server at the “clean” build phase. For the configuration section, there are many options available as documented in Oracle’s website, but the above is sufficient for now.

However, I still need to highlight to you that the <version> value of the plugin must match the version of the plugin installed to the Maven repository and the WebLogic Server version used by you. For example, if you are developing on WebLogic Server Version 12.1.1, the weblogic-maven-plugin version and the plugin used in the pom.xml of DummyDemo-ear must be 12.1.1.

A brief explanation on the config options used here (I’ll just explain the important ones):

adminurlThis is the URL to the running WebLogic server, with the “t3” protocol as prefix and the default port of 7001. If you run on your local machine, the URL should be t3://localhost:7001/
usernameThe WebLogic admin username
passwordThe WebLogic admin password
remoteIf the target deployment server is located remotely, please set the value to “true“. But if you are just deploying it on a local server, set it to “false“.
sourceThe location of the target EAR file for deployment.
nameName of the deployed application (not necessary to be the name of the EAR file).

The Right Dependency For Integration Test

One of the beautiful things about running integration test against WebLogic is that the dependencies are clean and you mostly likely only require the weblogic-maven-plugin.jar for all the necessary Java EE libraries. Since the jar is already present in the local Maven repository, it doesn’t need to perform a remote download through the net during compilation and the process is speedier.

Please edit the pom.xml in <path>/DummyDemoJavaEE5/integration-test/ with the below contents:

Some changes in JNDI names for calling Session Beans

Calling remote session beans from WebLogic is some what weird as compare to Glassfish 3.x or JBoss 5.x & 6.x. Taking the com.developerscrappad.ejb.BMPFacade for example in the DummyDemo-ejb module as an example, the bean class has annotations like the below:

In both Glassfish and JBoss, we could just get the remote bean instance through a simple JNDI name of “ejb/BMPFacade” and cast it to IBMPFacadeRemote. But for WebLogic, the calling JNDI name would have to be appended with the full package class name of the remote interface, e.g. “ejb/BMPFacade#com.developerscrappad.intf.IBMPFacadeRemote“.

So, in order to accomodate this behaviour, we’ll have to change the JNDI_NAME static variable in the remote interfaces as it is used to be accessed by integration test classes for conveniently invoking the remote bean.

Please edit the below classes in <path>DummyDemoJavaEE5/project/DummyDemo-ejb/src/main/java to the below:

Codes for com.developerscrappad.intf.IBMPFacadeRemote:

Codes for com.developerscrappad.intf.ICMPFacadeRemote:

Some changes in integration test codes:

Not forgetting the context environment properties in the integration test classes, we have to change the environment properties of the below files at the constructor. I have place the modified unit test files found in <path>/DummyDemoJavaEE/integration-test/src/test/com/developerscrappad/itest/ at the below:

Codes for

Codes for

Codes for com.developerscrappad.itest.MDBIntegrationTest

Bug Alert !!!

Before you proceed any further, there is a bug that affects entity classes when being deploy to WebLogic 10.3.x. Please read this article on Quick Fix: Weblogic 10.3.x – How To Solve “org.apache.openjpa.persistence.InvalidStateException: Detected reentrant flush…” and attend to the change on the Entity classes before moving forward.

WebLogic 12c is fine.

EAR Deployment Step-By-Step

Ok, now that you’ve gotten everything in order and the WebLogic server is assumed to be running. Just follow the below steps to deploy the EAR file.

Step 1: Deploying the EAR File to the WebLogic Application Server

If anything goes wrong from here, I would highly suggest that you revisit all procedures mentioned above or back track Part 1 and Part 2 of the series. Anyway, to deploy the EAR file, follow the steps below:

Full Deployment Including Running The Integration Test

  1. Please change the working directory to <path>/DummyDemoJavaEE5/.
  2. Execute the “mvn install” command. This command will deploy the EAR to the application server, and then, it will run the integration tests within the integration-test module.
  3. Just wait for Maven to download the dependencies through the internet. But if things broke down due to network failure or if you have difficult resolving dependencies, I’ll use the “-U” flag to perform this again, e.g. “mvn install -U
  4. If it deploys properly, you should be able to see the below in the terminal:
    [INFO] Reactor Summary:
    [INFO] DummyDemoJavaEE5 .............................. SUCCESS [0.090s]
    [INFO] project ....................................... SUCCESS [0.006s]
    [INFO] DummyDemo-api ................................. SUCCESS [0.023s]
    [INFO] DummyDemo-ejb ................................. SUCCESS [0.033s]
    [INFO] DummyDemo-web ................................. SUCCESS [0.035s]
    [INFO] DummyDemo-appclient ........................... SUCCESS [0.052s]
    [INFO] DummyDemo-ear ................................. SUCCESS [3.529s]
    [INFO] integration-test .............................. SUCCESS [0.018s]
    [INFO] ----------------------------------------------------------------
    [INFO] ----------------------------------------------------------------

    If you have successfully completed this step, CONGRATULATIONS, your EAR file had been deployed and tested!

For Development Deployment (Without Running The Integration Test)

During development, we don’t need to always run the integration test for every single deployment, to achieve this while at your development with the WebLogic Server running, just perform the following:

  1. Change the working directory to <path>/DummyDemoJavaEE5/project/.
  2. For first time deployment of the EAR, just execute the command “mvn package” or “mvn install“.

Step 2: How to Undeploy or Redeploy the EAR to WebLogic Server

In the midst of development, there will always be time when we need to redeploy the application again and again. To do that, just execute this at the <path>/DummyDemoJavaEE5/project/ working directory:

Just use the command: “mvn clean“. Since the the “undeploy” plugin goal was tagged with “clean” build-phase (just check on <path>/DummyDemoJavaEE5/project/DummyDemo-ear/pom.xml), when ever you execute the “clean” build cycle, it will perform the undeployment.

** Please take note that this command will fail if there is nothing to be undeploy on the WebLogic Server.

To RE-DEPLOY (only when there is an existing deployment in the WebLogic server):
Execute “mvn clean install” or “mvn clean package” at the terminal.

Summary on Part 5

Besides the part in getting WebLogic Maven Plugin to be compiled and loaded into the Maven’s repository, I love the straight forward and clean dependency of using the WebLogic Maven Plugin as it is not only a plugin for communicating with the Application Server for deployment, it consists of many Java EE depending libraries to be used as one jar in the Java EE project. Unlike Glassfish or JBoss, which we have to define stacks of repositories and dependencies, WebLogic’s way of doing things is clean, neat and worked out of the box.

I hope you’ve find this article useful and glad to have you reading.

To Be Continue…

From this point onwards, I should be able to find time to document the way to deploy the Java EE EAR file to IBM’s WebSphere through Maven. So stay tune and thank you for reading.

Related Articles:

Max Lam
About the Author

Born and currently resides in Malaysia, a seasoned Java developer whom had held positions as Senior Developer, Consultant and Technical Architect in various enterprise software development companies.

Related Posts

(adsbygoogle = window.adsbygoogle || []).push({}); I was performing a Java EE App migration to...

We’ve discussed the Deployment to Glassfish 3.x in Part 3 of the series. In this article, we’ll do...

In Part 1 and Part 2 of this series, we have discussed about the directory layout and the Java EE...