aguibert / openliberty-cheat-sheet

Concise tips and examples for using Open Liberty

Open Liberty Cheat Sheet

View it on github pages here: https://aguibert.github.io/openliberty-cheat-sheet/

To contribute or build it locally:

$ brew install asciidoctor
$ ./build.sh
$ open docs/index.html

openliberty-cheat-sheet's Issues

Maven: add shared resources to liberty:dev maven goal

Hi Andy,

as you probably have noticed on twitter, there currently seems to be no elegant way to supply shared resources to the liberty:dev maven goal. So I thought you might want to add how to do this?

Expected outcome

Use a library from the ${shared.resource.dir}.

Relevant part from src/main/liberty/config/server.xml:

  <jdbcDriver id="h2" javax.sql.DataSource="org.h2.jdbcx.JdbcDataSource">
    <library description="H2 Database" name="h2">
      <fileset dir="${shared.resource.dir}/h2" includes="h2*.jar" />
    </library>
  </jdbcDriver>

  <dataSource jdbcDriverRef="h2" jndiName="jdbc/oracledb" type="javax.sql.DataSource">
    <connectionManager maxPoolSize="5" minPoolSize="2" />
    <properties URL="jdbc:h2:mem:oracledb;MODE=oracle;LOG=1;USER=sa;password=" password="" user="sa" />
  </dataSource>

Hassle with the liberty-maven-plugin

liberty:dev currently does not support copying artefacts to the ${shared.resource.dir} itself. That's okay, the liberty-maven-plugin should probably only manage liberty.

But there is a caveat:

Suppose you execute mvn dependency:copy@goal liberty:dev.

• The maven-dependency-plugin will copy the mentioned h2 artefact to ${project.output.directory}/liberty/wlp/usr/share/resources/h2/ as expected.
• But then, running liberty:dev will delete the directory ${project.output.directory}/liberty/wlp and unzip a fresh copy of liberty. The h2 library is gone, the server will not start.
  Also, there is no option to have the liberty-maven-plugin not clean up the folder beforehand.
• The second time you execute mvn dependency:copy@goal liberty:dev (without clean!), it works fine -- but that is not a reliable nor desirable solution.

Working solution

So I came up with this configuration in my pom.xml which redefines wlp.usr.dir/WLP_USR_DIR. I think this could possible be added to the cheat sheet.

1. Define two new properties:

      <wlp.usr.dir>${project.build.directory}</wlp.user.dir>
      <wlp.shared.resource.dir>${wlp.usr.dir}/shared/resources</wlp.shared.resource.dir>

2. Copy to that new directory:

      <plugin>
        <groupId>io.openliberty.tools</groupId>
        <artifactId>liberty-maven-plugin</artifactId>
        <configuration>
          <userDirectory>${wlp.usr.dir}</userDirectory>
        </configuration>
      </plugin>

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-dependency-plugin</artifactId>
        <version>3.1.1</version>
        <executions>
          <execution>
            <id>copy-shared-resources</id>
            <goals>
              <goal>copy</goal>
            </goals>
            <configuration>
              <artifactItems>
                <artifactItem>
                  <groupId>com.h2database</groupId>
                  <artifactId>h2</artifactId>
                  <version>${dependency.h2.version}</version>
                  <outputDirectory>${wlp.shared.resource.dir]/h2</outputDirectory>
                  <destFileName>h2-${dependency.h2.version}.jar</destFileName>
                </artifactItem>
              </artifactItems>
            </configuration>
          </execution>
        </executions>
      </plugin>

Maybe this solution can be added to the examples? I figured out having wlp.usr.dir (or env WLP_USR_DIR in a subdirectory of a liberty installation is (almost) never a good idea. I have a few (open)liberty versions on my machines, and I use the same WLP_USR_DIR for all of them.

Adding content

Very nice initiative @aguibert!

Some initial content that we might want to add, especially what is not obvious in the docs:

• Datasource and driver example for Postgres, MySQL/Maria, DB2, maybe others
• Configuration examples with server.xml, defaults, and override location
• liberty-maven-plugin dev mode
• Injecting secret values into properties, similar to this example
• MicroProfile Metrics and monitor-1.0 example with Liberty-specific metrics
• MicroProfile OpenTracing example with JAX-RS endpoints, client and usr:opentracingZipkin, similar to this example
• Getting started JAX-RS with JPA example (instead of servlet)

Check if integration test methods from ibm.com should be added

Hi,

I found out that https://developer.ibm.com/wasdev/docs/writing-functional-tests-liberty/ has some more methods of starting an integration test.

While the current cheat sheet contains microshed and arquillian, there seem to be other methods:

• Starting Liberty from a Junit test directly.
• Starting Liberty from a build script which is executed before the test phase starts.

The document is written by Iain Duncan and was written back in 2015. It is hosted on ibm.com (License?).
If the Junit approach still might be reasonable today, maybe even create a new repo under https://github.com/OpenLiberty and host Junit4 rules/runners and Junit5 Extensions?

If this approach is not reasonable, maybe even document as well ("not recommended, because …").

I would also like to see the disadvantages and advantages listed for each method.