OpenLiberty maven filtering on server.xml

Question

I am following example on git . Trying to run it with mvn liberty:run and got

[ERROR ] CWWKF0001E: A feature definition could not be found for jsonb-3.0 [ERROR ] CWWKF0001E: A feature definition could not be found for restfulws-3.1

I figured doesn't matter but when I consume REST service with http://localhost:9080/LibertyProject/system/properties Firefox show blank page : "Unable to connect" , web tools tell me "refused" .

I think this is due to non maven filtering variable in src/main/liberty/config/server.xml that was translated to guide-rest-intro/finish/target/guide-rest-intro/WEB-INF/classes with maven variables non resolved :

<server description="Intro REST Guide Liberty server">
<!-- tag::featureManager[] -->
<featureManager>
  <feature>restfulWS-3.1</feature>
  <feature>jsonb-3.0</feature>
</featureManager>
<!-- end::featureManager[] -->

<!-- tag::httpEndpoint[] -->
<httpEndpoint httpPort="${default.http.port}" httpsPort="${default.https.port}"
            id="defaultHttpEndpoint" host="*" />
<!-- end::httpEndpoint[] -->

<!-- tag::webApplication[] -->
<webApplication location="guide-rest-intro.war" contextRoot="${app.context.root}"/>
<!-- end::webApplication[] -->
</server>

Then I add this to the original pom :

<build>
    <resources>
        <resource>
            <directory>src/main/liberty/config</directory>
            <filtering>true</filtering>
        </resource>
    </resources>

but this doesn't work as normally do for maven java project , why ??? How I can filtering the server.xml ?

Answer 1

FILTERING WORKS BUT CURRENTLY BUT YOU CAN'T WRITE FILTER FILES

You can actually enable some of the usage patterns you get in general with Maven resource filtering in working with server.xml with the liberty-maven-plugin.

The simplest way is to use the liberty-maven-plugin mapping of Maven project properties to Liberty server config, describe here.

So:

<properties>
 <liberty.var.port>123</liberty.var.port>
</properties>

is mapped to Liberty server config variable "port=123" and so resolves server XML substitution:

    httpPort="${port}"

to httpPort="123"

Likewise project property

456

is mapped to Liberty bootstrap property abc=456, and so on ...

(See here for a reference on Liberty server config which provides an intro for the different types of configuration properties/variables/etc.)

ALL THE CONVENIENCES OF MAVEN PROJECT PROPERTIES

As Maven project properties, these provide all the typical conveniences:

• They can be inherited from parents
• They can be activated (or not) via Maven profiles
• They can be overridden by command-line sys props -Dliberty.var.xyz=789
• They can be referenced elsewhere in your pom.xml (e.g. your IT/failsafe config)

For some users, this will be all the key portions of "filtering" they're interested in.

NOT YET SUPPORTED

What's not supported though is to place a set of properties in a "filter" file, configured in pom.xml like:

<filters>
    <filter>src/main/filters/${filter.properties}</filter>
</filters>

and use this with Liberty server config.

A nice thing about such an approach is that, at best, not only the resources plugin but other plugins will be able to use this same set of property definitions to do "filtering" (substitutions). But, unfortunately, liberty-maven-plugin does not support this at the moment, though we have an issue open for enhancing this in the future.

WORKAROUND

I might recommend working around this by extracting a copy of the properties for use with the Maven project properties mapping described above (based on the naming convention defined by liberty-maven-plugin).

So e.g. if had wanted to do server XML variable substitution with a filter that looked like this:

prop1=value1

I would just create a Maven project property:

<properties>
   <liberty.var.prop1>value1</liberty.var.prop1>
</properties>

You might need to repeat yourself, if you were hoping to use that same property with another filtering-enabled Maven plugin. But you could group sets of values via profile, all the same.

OTHER WORKAROUND

I had written up another workaround approach treating server.xml as a filtered resource, managed by the resources plugin, rather than using the normal path where this Liberty file is specially managed by the liberty-maven-plugin. However, I think this is maybe likely to lead to trouble, since liberty-maven-plugin wants to manage this file, so I won't recommend it now, but I'll link it for reference in case and it helps anyone understand the situation better too: https://github.com/scottkurz/lmp-issue-587/