0

I'm familiar with Tomcat/TomEE and testing applications using Arquillian. Now were are switching to Open Liberty. I see there is a module for Arquillian using embedded Open Liberty but it seems to require an existing Open Liberty installation whose path is provided in the configuration. This makes it non-portable and therefore unsuitable for automated testing since the installation has to be present at the exact same path. Arquillian and TomEE are self-contained, no installation required. Therefore my question is why this isn't also possible with Open Liberty? And is this planned for the future?

For reference this is how you use Arquillian with TomEE/Tomcat:

<arquillian xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://jboss.org/schema/arquillian"
    xsi:schemaLocation="http://jboss.org/schema/arquillian http://www.jboss.org/schema/arquillian/arquillian_1_0.xsd">
    <container qualifier="tomee" default="true">
        <configuration>
            <property name="httpPort">-1</property>
            <property name="stopPort">-1</property>
            <property name="users">user=pass</property>
        </configuration>
    </container>
</arquillian>

As you can see, there is no path to a local installation required to run the tests. The only thing you need to do is a add a couple of Maven dependencies in test scope that pull in TomEE (embedded). If the same would work for Open Liberty that would be great.

sithmein
  • 437
  • 3
  • 11
  • Can you provide a bit more information about the embedded Open Liberty container you're talking about? Officially we only offer a managed and remote container: https://github.com/openliberty/liberty-arquillian If by "present at the same exact path" you mean that it has to be accessible through the file system, that is correct in the case of the managed container. For the remote container you can host Liberty elsewhere and connect/run the tests using JMX. – Charles Jan 28 '19 at 18:39

3 Answers3

1

If you have a look at https://github.com/OpenLiberty/open-liberty/blob/integration/dev/com.ibm.ws.microprofile.config.1.2_fat_tck/publish/tckRunner/tck/src/test/resources/arquillian.xml you will see an example arquillian.xml that sets $wlpHome

 <property name="wlpHome">${wlp}</property>

from an environment variable $wlp. ('wlp' is short for Websphere Liberty Profile)

The wlpHome variable is used in the managed/local container here: https://github.com/OpenLiberty/liberty-arquillian/blob/42cb523b8ae6596a00f2e1793e460a910d863625/liberty-managed/src/main/java/io/openliberty/arquillian/managed/WLPManagedContainer.java#L224

An example that does this dynamically is the setting of the system property ${wlp} here: https://github.com/OpenLiberty/open-liberty/blob/95c266d4d6aa57cf32b589e7c9d8b39888176e91/dev/fattest.simplicity/src/componenttest/topology/utils/MvnUtils.java#L161

If you have any more queries please post them... and hope you love OpenLiberty - it rocks!

Gordon

1

Going further..so the above is how we do automated testing but it still uses the location.

I see, regarding not needing any location specified at all, you say: "The only thing you need to do is a add a couple of Maven dependencies in test scope that pull in TomEE (embedded). If the same would work for Open Liberty that would be great."

So, thinking, maven will put a bunch of classes on the classpath due to the TomEE dependancies and then the test run will find the appropriate container to run the tests on.

I will raise an issue over on https://github.com/OpenLiberty/liberty-arquillian/issues/39 to cover the requirement please feel free to add remarks etc.

1

The result you seem to be trying to achieve is a embedded runtime for liberty using arquillian. However, all as far as I can see, the openliberty team only provides a remote container adapter and a managed container adapter at the moment.

With us having a similar need, wanting to run automated integration tests where we wouldnt necessarily have a Openliberty server in-place. We managed to work-around this using liberty-maven-plugin.

The build/testing process would then be:

  1. Running mvn verify, liberty-maven-plugin would generate the specified openliberty which we want to run our tests against.
                    <plugin>
                        <groupId>net.wasdev.wlp.maven.plugins</groupId>
                        <artifactId>liberty-maven-plugin</artifactId>
                        <version>${version.liberty-maven-plugin}</version> <!-- plugin version -->
                        <configuration>
                            <assemblyArtifact> <!-- Liberty server to run test against -->
                                <groupId>io.openliberty</groupId>
                                <artifactId>openliberty-runtime</artifactId>
                                <version>18.0.0.4</version>
                                <type>zip</type>
                            </assemblyArtifact>
                            <configDirectory>src/liberty/${env}/</configDirectory>
                            <configFile>src/liberty/server.xml</configFile>
                            <serverName>defaultServer</serverName>
                        </configuration>
                        <executions>
                            <execution>
                                <phase>prepare-package</phase>
                                <goals>
                                    <goal>create-server</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
  1. As liberty-maven-plugin per default adds the Liberty server to the target/folder
<arquillian xmlns="http://jboss.org/schema/arquillian">
    <container qualifier="liberty-managed" default="true">
        <configuration>
            <property name="wlpHome">target/liberty/wlp</property>
            <property name="serverName">defaultServer</property>
        </configuration>
    </container>
</arquillian>

This way we can assure that a runnable liberty server according to our liking is always existant in our local environment or e.g. our Jenkins CI/CD Server, essentially getting the same effect as having a embedded container.

Hassan Nazar
  • 69
  • 10