We’ve made a change in the August 2016 Liberty beta that alters the behavior associated with path normalization on values that are specified using variables.

In releases prior to this beta, Liberty performs path normalization on any value that is specified using a variable. For example, if your configuration references ${myDirectory} and you have defined myDirectory=/opt/IBM///myDirectory in bootstrap.properties, the configuration value is modified to be a valid path value (in this case, /opt/IBM/myDirectory).

Unfortunately, this can cause some problems if you are using a value that expects to have multiple ‘/’ characters such as a JDBC URL. For example, the JDBC URL jdbc:oracle:thin:@//myHost:1521/myDB would be normalized to the invalid value jdbc:oracle:thin:@/myHost:1521/myDB.

In the current beta, Liberty no longer normalizes these variable values in all cases. Liberty continues to modify the variable value if it is being used in a configuration attribute that expects a location value. For example, if your configuration has <application location="${myDirectory}" .../> the value of myDirectory would still be normalized.

We are introducing this change in the beta before including it in an official release so that we can determine if this will cause any problems for Liberty users. We have a zero migration policy in Liberty, which means that we are very strict about not releasing changes that could break existing configurations. We expect that it’s unlikely that any existing configurations will be affected by this change, but it is possible. If you are using a variable in a configuration attribute that is not a location and are currently relying on the normalization behavior, you may need to adjust your configuration.

If you are using a version of Liberty other than the beta and encounter this problem there are a couple of ways to work around it. One would be to remove the variable and use the value directly in the configuration. Liberty only normalizes values that come from variables, so the directly configured value would not be modified. If you need to continue using a variable, you can work around the problem by using two variables. For example, in the above example of a JDBC driver, you could have the following values defined as variables in bootstrap.properties:

jdbcFirstPart=jdbc:oracle:thin:@
jdbcSecondPart=myHost:1521/myDB

Then, in server.xml, you would use both variables to construct the URL value:

<dataSource>
   <properties.oracle url="${jdbcFirstPart}//${jdbcSecondPart}"/>
</dataSource>

Join The Discussion

Your email address will not be published. Required fields are marked *