Category Archives: Uncategorized

WLST Test Maven Plugin

Over the past few years, I have found myself working on projects that rely heavily on the WebLogic Scripting Tool, aka., WLST.  The problem we always faced on these projects was that there was no easy way to test these scripts as part of our normal build process.  As such, we relied heavily on integration testing to test our WLST scripts.  While integration testing is a critical, it tends to be expensive to build, and requires more time and resources to setup and run than unit tests.  To address this problem, I created the WLST Test Maven Plugin (see https://github.com/rpatrick00/wlst-test-maven-plugin).

The WLST Test Maven Plugin doesn’t do anything that couldn’t be accomplished by cobbling together executions of multiple standard Maven plugins (e.g., the Maven Dependency Plugin, the Maven Resources Plugin, the Exec Maven Plugin) and some Jython code that gathers the tests, create the Python unittest.TestSuite, and runs the tests.  Doing this requires a significant amount of configuration and adding the Jython driver script to every project.  What the WLST Test Maven Plugin does is make this easier by having a single, special purpose Maven plugin that is both configurable and has reasonable defaults for almost all of its configuration.  In addition, the plugin packages the driver script so that there is no need to add a driver script to your project.  Let’s look at an example project and usage of the plugin.

The example project is called wlst-test-test and consists of 3 files:

  • src/main/python/create_domain.py – a simple Python class that creates a minimal WLS domain,
  • src/test/python/create_domain_test.py – a test case that defines one or more test functions, base on the Python unittest module, and
  • pom.xml = the Maven POM used to build the project.

When creating test cases to use with the WLST Test Maven Plugin, there are a few things to keep in mind:

  1. All test case filenames must end with “test.py”.  If not, the file will be assumes to be a supporting file and will not be included in the TestSuite.
  2. All test case files must live under a common directory tree; by default, /src/test/python.
  3. All python files being tested must live under a common directory tree; by default, src/main/python.
  4. Any Java classes or resources that are part of the project will automatically placed on the WLST classpath during test execution.  Any other dependencies on other files in the classpath, on environment variables, or Java system properties in the WLST execution environment must be configured explicitly in the WLST Test Maven Plugin.

The create_domain.py source code is as follows:

import os

import wlstModule as wlst

class DomainCreator(object):

    def __init__(self, domain_name, domain_parent_directory):
        self.domain_name = domain_name
        self.domain_parent_directory = domain_parent_directory
        self.domain_home = os.path.join(domain_parent_directory, domain_name)

    def create_wls_domain(self):
        wlst.selectTemplate('Basic WebLogic Server Domain')
        wlst.loadTemplates()
        self.__set_domain_name()
        self.__set_admin_password()
        self.__writeDomain()
        wlst.closeTemplate()

    def __set_domain_name(self):
        wlst.cd('/')
        wlst.set('Name', self.domain_name)

    def __set_admin_password(self):
        admin_user_path = '/Security/%s/User/weblogic' % self.domain_name
        wlst.cd(admin_user_path)
        wlst.set('Password', 'welcome1')

    def __writeDomain(self):
        wlst.setOption('OverwriteDomain', 'true')
        wlst.writeDomain(self.domain_home)

The create_domain_test.py file contains the following:

import os
import unittest

import wlstModule as wlst

from create_domain import DomainCreator

class DomainCreatorTest(unittest.TestCase):

    def setUp(self):
        if not os.path.isdir('target/domains'):
            os.makedirs('target/domains')

    def test_create_domain(self):
        name = 'mydomain'
        parent_dir = 'target/domains'

        creator = DomainCreator(name, parent_dir)
        creator.create_wls_domain()

        domain_home = os.path.join(parent_dir, name)
        wlst.readDomain(domain_home)
        expected = ['AdminServer']
        servers = wlst.ls('/Server', returnMap='true', returnType='c')
        self.assertEqual(len(servers), len(expected))
        self.assertEqual(servers[0], expected[0])

And finally, the POM for the project is:

<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 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>test</groupId>
    <artifactId>wlst-test-test</artifactId>
    <packaging>jar</packaging>
    <version>1.0</version>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <build>
        <plugins>
            <plugin>
                <groupId>io.rhpatrick.mojo</groupId>
                <artifactId>wlst-test-maven-plugin</artifactId>
                <version>1.0.2</version>
                <configuration>
                    <wlstScriptDirectory>/opt/wls12213/oracle_common/common/bin</wlstScriptDirectory>
                </configuration>
                <executions>
                    <execution>
                        <id>WLST Unit Tests</id>
                        <goals>
                            <goal>test</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

Once the files are created in the right locations, simply open a Terminal window, change to the directory containing pom.xml, and run “mvn test” to run the test.  The output should look something like the following:

[INFO] Scanning for projects...
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] Building wlst-test-test 1.0.2
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ wlst-test-test ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /Users/rpatrick/tmp/wlst-test/src/main/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ wlst-test-test ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ wlst-test-test ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /Users/rpatrick/tmp/wlst-test/src/test/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ wlst-test-test ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ wlst-test-test ---
[INFO] No tests to run.
[INFO] 
[INFO] --- wlst-test-maven-plugin:1.0.2:test (WLST Unit Tests) @ wlst-test-test ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

drw-   AdminServer
test_create_domain (create_domain_test.DomainCreatorTest) ... ok

----------------------------------------------------------------------
Ran 1 test in 7.293s

OK
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 19.471 s
[INFO] Finished at: 2018-01-29T19:33:35-06:00
[INFO] Final Memory: 20M/406M
[INFO] ------------------------------------------------------------------------

That’s all there is to it.  In the next article, we will look at some of the more advanced configuration possible with the WLST Test Maven Plugin.

Advertisements

Restoring SOA 12.2.1.1 Maven Functionality

With the release of Oracle SOA Suite 12.2.1.1, the ability to create and build SOA projects with Maven has been broken.  Customers who want an official fix should contact Oracle Support and reference Bug 24710353.  For those that choose this official path, you should stop reading now.  For anyone else interested in a temporary workaround, keep reading.

As with any of my posts, this post should not be construed as an official, Oracle-supported way of fixing the product.  This post simply represents what I did to restore the functionality for my Oracle SOA Suite 12.2.1.1.0 Quick Start installation.  The high-level steps are:

  • Fix the SOA 12.2.1.1 Maven metadata
  • Sync the Maven repository with the updated Oracle Home
  • Recreate the SOA applications and projects

Fixing the SOA 12.2.1.1 Maven Metadata

The first thing we need to do to fix the Maven metadata in the SOA 12.2.1.1 Oracle Home.  I am using an Oracle Home created by the SOA 12.2.1.1 Quick Start installer, though the steps should be similar for any Oracle Home containing SOA Suite 12.2.1.1.

The high-level steps are:

  • Fix the parent POM
  • Fix the archetypes
  • Remove the extra, unnecessary Maven metadata files (optional)

Fixing the sar-common Parent POM

The SOA archetypes create Maven projects with their parent set to the com.oracle.soa:sar-common parent POM.  Unfortunately, the SOA 12.2.1.1 version of this POM has a version of 12.2.1-0-0 so the first fix is to set its version to 12.2.1-1-0.

To correct the metadata, do the following steps:

  1. In the $ORACLE_HOME/soa/plugins/maven/com/oracle/soa/sar-common/ directory, make a copy of the 12.2.1-0-0 directory and name it 12.2.1.
  2. In the $ORACLE_HOME/soa/plugins/maven/com/oracle/soa/sar-common/12.2.1/ directory, rename the sar-common-12.2.1-0-0.pom to sar-common-12.2.1.pom.
  3. Open the sar-common-12.2.1.pom in a text editor and change the <version> element value from 12.2.1-0-0 to 12.2.1-1-0.

When finished, the top portion of the sar-common-12.2.1.pom file should look what is shown below.  The change made to the file is highlighted in red.

 <modelVersion>4.0.0</modelVersion>
 <groupId>com.oracle.soa</groupId>
 <artifactId>sar-common</artifactId>
 <version>12.2.1-1-0</version>
 <packaging>pom</packaging>

 <parent>
   <groupId>com.oracle.maven</groupId>
   <artifactId>oracle-common</artifactId>
   <version>12.2.1-1-0</version>
   <relativePath></relativePath>
 </parent>

At this point, you have made all the changes needed for this artifact.  Optionally, you can delete the following directories as they are not needed:

  • $ORACLE_HOME/soa/plugins/maven/com/oracle/soa/sar-common/12.2.1-0-0
  • $ORACLE_HOME/soa/plugins/maven/com/oracle/soa/sar-common/12.2.2-0-0

Next, you need to update the two SOA archetypes.

Fixing the SOA Archetypes

SOA has two main archetypes:

  • oracle-soa-project
  • oracle-soa-application

Fixing the archetypes is a bit more involved since we need to edit files inside of the archetype JAR in addition to its POM.

Fixing the oracle-soa-project Archtetype

Again, we need to change the version numbers from 12.2.1-0-0 to 12.2.1-1-0 so that the archetype references the proper artifacts that exist in the Oracle Home.  To correct the archetype’s metadata, do the following steps:

  1. In the $ORACLE_HOME/soa/plugins/maven/com/oracle/soa/archetype/oracle-soa-project directory, make a copy of the 12.2.1-0-0 directory and name it 12.2.1.
  2. In the $ORACLE_HOME/soa/plugins/maven/com/oracle/soa/archetype/oracle-soa-project/12.2.1/ directory, rename the JAR and POM files to:
    • oracle-soa-project-12.2.1.jar
    • oracle-soa-project-12.2.1.pom
  3. Open oracle-soa-project-12.2.1.pom in a text editor and change the <version> element value from 12.2.1-0-0 to 12.2.1-1-0.

When finished, the top portion of the oracle-soa-project-12.2.1.pom file should look what is shown below.  The change made to the file is highlighted in red.

 <modelVersion>4.0.0</modelVersion>

 <groupId>com.oracle.soa.archetype</groupId>
 <artifactId>oracle-soa-project</artifactId>
 <version>12.2.1-1-0</version>
 <packaging>jar</packaging>

Now, we are ready to edit the files in the oracle-soa-project-12.2.1.jar by doing the following steps:

  1. Open a shell in the $ORACLE_HOME/soa/plugins/maven/com/oracle/soa/archetype/oracle-soa-project/12.2.1/ directory.
  2. Make a directory called temp and change into the newly created directory.
  3. Extract the JAR contents by running the following command:jar xf ../oracle-soa-project-12.2.1.jar
  4. In the temp/archetype-resources/ directory, open pom.xml in a text editor and change:
    1. The <parent> stanza’s <version> from 12.2.1-0-0 to 12.2.1-1-0.
    2. In the <Build> section, change the oracle-soa-plugin <version> from 12.2.1-0-0 to 12.2.1-1-0.
  5. In the temp/META-INF/maven/com.oracle.soa.archetype/oracle-soa-project/ directory, open pom.properties in a text editor and change the version property value from 12.2.1-0-0 to 12.2.1-1-0.
  6. In the temp/META-INF/maven/com.oracle.soa.archetype/oracle-soa-project/ directory, open pom.xml in a text editor and change the <version> element’s value from 12.2.1-0-0 to 12.2.1-1-0.
  7. From the temp directory, run the following commands to replace the oracle-soa-project-12.2.1.jar with its updated contents:
    1. rm ../oracle-soa-project-12.2.1.jar
    2. jar cf ../oracle-soa-project-12.2.1.jar *
    3. cd ..
    4. rm -rf temp

At this point, you have made all the changes needed for this archetype.  Optionally, you can delete the following directories as they are not needed:

  • $ORACLE_HOME/soa/plugins/maven/com/oracle/soa/archetype/oracle-soa-project/12.2.1-0-0
  • $ORACLE_HOME/soa/plugins/maven/com/oracle/soa/archetype/oracle-soa-project/12.2.2-0-0

Fixing the oracle-soa-application Archetype

Again, we need to change the version numbers from 12.2.1-0-0 to 12.2.1-1-0 so that the archetype references the proper artifacts that exist in the Oracle Home.  The steps required are very similar to the oracle-soa-project archetype.  To correct the archetype’s metadata, do the following steps:

  1. In the $ORACLE_HOME/soa/plugins/maven/com/oracle/soa/archetype/oracle-soa-application directory, make a copy of the 12.2.1-0-0 directory and name it 12.2.1.
  2. In the $ORACLE_HOME/soa/plugins/maven/com/oracle/soa/archetype/oracle-soa-application/12.2.1/ directory, rename the JAR and POM files to:
    • oracle-soa-application-12.2.1.jar
    • oracle-soa-application-12.2.1.pom
  3. Open oracle-soa-application-12.2.1.pom in a text editor and change the <version> element value from 12.2.1-0-0 to 12.2.1-1-0.

When finished, the top portion of the oracle-soa-project-12.2.1.pom file should look what is shown below.  The change made to the file is highlighted in red.

 <modelVersion>4.0.0</modelVersion>

 <groupId>com.oracle.soa.archetype</groupId>
 <artifactId>oracle-soa-application</artifactId>
 <version>12.2.1-1-0</version>
 <packaging>jar</packaging>

Now, we are ready to edit the files in the oracle-soa-application-12.2.1.jar by doing the following steps:

  1. Open a shell in the $ORACLE_HOME/soa/plugins/maven/com/oracle/soa/archetype/oracle-soa-application/12.2.1/ directory.
  2. Make a directory called temp and change into the newly created directory.
  3. Extract the JAR contents by running the following command:jar xf ../oracle-soa-application-12.2.1.jar
  4. In the temp/archetype-resources/__projectName__/ directory, open pom.xml in a text editor and change:
    1. The <parent> stanza’s <version> from 12.2.1-0-0 to 12.2.1-1-0.
    2. In the <Build> section, change the oracle-soa-plugin <version> from 12.2.1-0-0 to 12.2.1-1-0.
  5. In the temp/META-INF/maven/com.oracle.soa.archetype/oracle-soa-application/ directory, open pom.properties in a text editor and change the version property value from 12.2.1-0-0 to 12.2.1-1-0.
  6. In the temp/META-INF/maven/com.oracle.soa.archetype/oracle-soa-application/ directory, open pom.xml in a text editor and change the <version> element’s value from 12.2.1-0-0 to 12.2.1-1-0.
  7. From the temp directory, run the following commands to replace the oracle-soa-project-12.2.1.jar with its updated contents:
    1. rm ../oracle-soa-application-12.2.1.jar
    2. jar cf ../oracle-soa-application-12.2.1.jar *
    3. cd ..
    4. rm -rf temp

At this point, you have made all the changes needed for this archetype.  Optionally, you can delete the following directories as they are not needed:

  • $ORACLE_HOME/soa/plugins/maven/com/oracle/soa/archetype/oracle-soa-application/12.2.1-0-0
  • $ORACLE_HOME/soa/plugins/maven/com/oracle/soa/archetype/oracle-soa-application/12.2.2-0-0

At this point, all required editing of the SOA 12.2.1.1 Maven metadata is complete.  Before moving on, let’s look at one last optional step for removing soem extra baggage that is not needed.

Removing Unnecessary Maven Metadata

The last step is to remove extra versions of the oracle-soa-plugin that are not needed.  Simple do the following steps:

  • Delete the $ORACLE_HOME/soa/plugins/maven/com/oracle/soa/plugin/oracle-soa-plugin/12.2.1-0-0/ directory
  • Delete the $ORACLE_HOME/soa/plugins/maven/com/oracle/soa/plugin/oracle-soa-plugin/12.2.2-0-0/ directory
  • Rename the $ORACLE_HOME/soa/plugins/maven/com/oracle/soa/plugin/oracle-soa-plugin/12.2.1-1-0/ directory to $ORACLE_HOME/soa/plugins/maven/com/oracle/soa/plugin/oracle-soa-plugin/12.2.1/
  • Rename the files within the $ORACLE_HOME/soa/plugins/maven/com/oracle/soa/plugin/oracle-soa-plugin/12.2.1/ directory as follows:
    • oracle-soa-plugin-12.2.1.jar
    • oracle-soa-plugin-12.2.1.pom

At this point, we are ready to repopulate the Maven repository with the corrected artifacts.

Syncing the Maven Repository

Now that the SOA 12.2.1.1 Oracle Home’s Maven metadata is correct, we simply need to push it into the Maven repository using the oracle-maven-sync plugin.

Before doing this, make sure that the oracle-maven-sync plugin is installted in the Maven repository by doing the following steps:

  1. Open a shell in the $ORACLE_HOME/oracle_common/plugins/maven/com/oracle/maven/oracle-maven-sync/12.2.1/ directory.
  2. Run the command
    mvn install:install-file -Dfile=oracle-maven-sync-12.2.1.jar -DpomFile=oracle-maven-sync-12.2.1.pom

Now, run the oracle-maven-sync plugin to push the corrected Maven artifacts into the Maven repository like this:

mvn com.oracle.maven:oracle-maven-sync:12.2.1-1-0:push -DoracleHome=/path/to/soa/oracle/home

If you happen to get a failure from the oracle-maven-sync plugin because of duplicate POMs, simply re-run the command above after adding the -DpushDuplicates=true argument.

At this point, we are ready to test the work we have done.

Create a New SOA Application

While creating or fixing broken SOA applications and projects is beyond the scope of this article, we do need a simple way to test that our fix was successful.  As such, we will use the oracle-soa-application archetype to create a new SOA application and then package the resulting SAR to make sure that the oracle-soa-plugin is able to find all of its dependencies.

To test our work, open a shell somewhere (e.g., /tmp) and run the following commands

  1. mvn archetype:crawl -Dcatalog=~/.m2/archetype-catalog.xml
  2. mvn archetype:generate -DinteractiveMode=false
    -DarchetypeGroupId=com.oracle.soa.archetype
    -DarchetypeArtifactId=oracle-soa-application
    -DarchetypeVersion=12.2.1-1-0
    -DgroupId=test
    -DartifactId=soa-test
    -Dversion=1.0
    -DprojectName=soa-project
  3. cd soa-test
  4. mvn  package

In this article, we learned about a problem in the Oracle SOA Suite 12.2.1.1 Maven functionality and how to restore functionality ourselves.  Remember, this is not an official Oracle-supported solution and anyone looking for such needs to contact Oracle Support to obtain an official patch.

Restoring OSB 12.2.1 Maven Functionality

It seems that testing of the Oracle Service Bus (OSB) Maven functionality in the new 12.2.1 release failed to catch a few issues that make the OSB Maven plugin unusable out of the box.  Oracle is aware of the issue and working to create a patch for this.  In the meantime, users can work around the problem with a few simple changes.  This blog documents those changes.

Fixing the com.oracle.servicebus:client POM

The first change we need to make is to edit the com.oracle.servicebus:client POM.  This POM can be found at ${ORACLE_HOME}/osb/plugins/maven/com/oracle/servicebus/client/12.2.1/client-12.2.1.pom.  Open this file in a text editor and make the following changes.

  1. Delete the <dependency> stanza for the com.oracle.weblogic:wlthint3client.  This artifact does not exist.  Fortunately, it is is not needed since the weblogic-server-pom dependency provides all of the connectivity to WebLogic Server that is required.
  2. In the weblogic-server-pom dependency, change the <version> element’s value from “LATEST” to “[12.2.1,12.2.2)” (without the double quotes).
  3. In the com-bea-core-xml-xmlbeans dependency, change the <artifactId> element’s value from “com-bea-core-xml-xmlbeans” to “com.bea.core.xml.xmlbeans” (without the double quotes).
  4. In the com-bea-core-xml-xmlbeans dependency, change the <version> element’s value from “LATEST” to “[12.2.1,12.2.2)” (without the double quotes).

After making these changes, the relevant section of the file should look like the one shown here.

...
<dependencies>
    <dependency>
        <groupId>com.oracle.weblogic</groupId>
        <artifactId>weblogic-server-pom</artifactId>
        <version>[12.2.1,12.2.2)</version>
        <type>pom</type>
    </dependency>
    <dependency>
        <groupId>com.oracle.weblogic</groupId>
        <artifactId>com.bea.core.xml.xmlbeans</artifactId>
        <version>[12.2.1,12.2.2)</version>
    </dependency>
    <dependency>
        <groupId>com.oracle.osb.common</groupId>
        <artifactId>oracle.servicebus.common</artifactId>
        <version>[12.2.1,12.2.2)</version>
    </dependency>
    ...

Fixing the com.oracle.servicebus:sbar-project-common Parent POM

The next change we need to make is to edit the com.oracle.servicebus:sbar-project-common POM.  This POM can be found at ${ORACLE_HOME}/osb/plugins/maven/com/oracle/servicebus/sbar-project-common/12.2.1/sbar-project-common-12.2.1.pom.  Open this file in a text editor and make the following change.

  1. Change the <parent> section’s <version> element value from “12.1.4-0-0” to “12.2.1-0-0” (without the double quotes).

After making these changes, the relevant section of the file should look like the one shown here.

... 
<parent>
    <groupId>com.oracle.maven</groupId>
    <artifactId>oracle-common</artifactId>
    <version>12.2.1-0-0</version>
</parent>
...

Fixing the com.oracle.servicebus:sbar-system-common Parent POM

The last change we need to make is to edit the com.oracle.servicebus:sbar-system-common POM.  This POM can be found at ${ORACLE_HOME}/osb/plugins/maven/com/oracle/servicebus/sbar-system-common/12.2.1/sbar-system-common-12.2.1.pom.  Open this file in a text editor and make the following change.

  1. Change the <parent> section’s <version> element value from “12.1.4-0-0” to “12.2.1-0-0” (without the double quotes).

After making these changes, the relevant section of the file should look like the one shown here.

... 
<parent>
    <groupId>com.oracle.maven</groupId>
    <artifactId>oracle-common</artifactId>
    <version>12.2.1-0-0</version>
</parent>
...

Populating the Maven Repository with the Changes

Now that you have made all of the required changes, simply run the com.oracle.maven:oracle-maven-sync plug-in to synchronize your Maven repository with the changed artifacts.  If you are unfamiliar with the Oracle Maven Sync plug-in, please refer to the documentation here.  If you already have the plug-in installed, simply run the command shown below (replacing the “${ORACLE_HOME}” with the actual path to your OSB 12.2.1 installation directory).

mvn com.oracle.maven:oracle-maven-sync:12.2.1-0-0:push -DoracleHome=${ORACLE_HOME}

At this point, the OSB Maven functionality should be restored for the local machine. If you have a Maven Repository Manager, you can use the Oracle Maven Sync plug-in to populate it with the corrected artifacts.