CWWKG0090E seen when using include that worked in previous version

[msmigiel]

Describe the bug
I am on Windows 10. In OpenLiberty 20.0.0.2, I had the following in my server.xml:

<server description="OMS server">
	<include location="${env.ROOT_HOME}/oms_local/properties/server-oms.xml"/>
</server>

This was working fine and it was being read:

[AUDIT ] CWWKG0028A: Processing included configuration resource: C:\Users\user\Downloads\tools\oms_local\properties\server-oms.xml

However, when I moved to 20.0.0.3, I started seeing the following error.

[ERROR ] CWWKG0090E: The C:\Users\user\Downloads\tools/oms_local/properties/server-oms.xml configuration resource does not exist or cannot be read.

I have both 20.0.0.2 and 20.0.0.3 running with identical configurations and v2 works but not v3. I've tried various slashes - however replacing the variable with its value does work, for example:

<server description="OMS server">
	<include location="C:\Users\user\Downloads\tools\oms_local\properties\server-oms.xml"/>
</server>

This is strange because in the log, the variable is getting resolved but it seems that what the log is printing and what Liberty is doing are not the same.

This seems to be a regression. One recent change I see is this - I'm not sure if it is related: #10992

Steps to Reproduce
1.) Have a server.xml reference another XML configuration with a variable as the path (in my case, prefixed with env.)
2.) Start Liberty, observer the error above.

Expected behavior
The file should be found.

Diagnostic information:

• OpenLiberty Version: 20.0.0.3
• Windows 10 (latest version)
• Java Version: Java(TM) SE Runtime Environment (build 8.0.6.0 - pwa6480sr6-20191107_01(SR6))
• server.xml configuration (please see above)

Additional context
NA

[brenthdaniel]

Thanks for the report. My guess is that the path was formerly getting normalized into a value that Windows would recognize and now it is not. Does it work for you if you change the forward slashes in the original configuration to backslashes? It does seem to still be working on *nix platforms.

[msmigiel]

Thank you for taking a look. Here are the results of various permutations of server files.

Original: (worked in 20.0.0.2, ROOT_HOME is set in a shell script I called from wlp.cmd):

<server description="OMS server">
	<include location="${env.ROOT_HOME}/oms_local/properties/server-oms.xml"/>
</server>

Error in 20.0.0.3:
[ERROR ] CWWKG0090E: The C:\Users\user\Downloads\tools/oms_local/properties/server-oms.xml configuration resource does not exist or cannot be read.

Permutation 1: (fails, variable with Windows slashes)

<server description="OMS server">
	<include location="${env.ROOT_HOME}\oms_local\properties\server-oms.xml"/>
</server>

[ERROR ] CWWKG0090E: The C:\Users\user\Downloads\tools\oms_local\properties\server-oms.xml configuration resource does not exist or cannot be read.

Permutation 2: (works, hard coded with Windows slashes)

<server description="OMS server">
	<include location="C:\Users\user\Downloads\tools\oms_local\properties\server-oms.xml"/>
</server>

[AUDIT ] CWWKG0028A: Processing included configuration resource: C:\Users\user\Downloads\tools\oms_local\properties\server-oms.xml

Permutation 3: (works, hard coded with Unix slashes)

<server description="OMS server">
	<include location="C:/Users/user/Downloads/tools/oms_local/properties/server-oms.xml"/>
</server>

[AUDIT   ] CWWKG0028A: Processing included configuration resource: C:\Users\user\Downloads\tools\oms_local\properties\server-oms.
xml

[brenthdaniel]

OK, I think I see the problem. On windows the path will be interpreted as relative, so it will prepend the home directory. As a workaround, you can change C:\ to C:/ in the environment variable and it should work.

[jhanders34]

#regression

[msmigiel]

I have the variable defined as:

set ROOT_HOME=%HOMEDRIVE%%HOMEPATH%\Downloads\tools

You are correct, hard coding the values and setting it like this does indeed work and is something I can use for a temporary workaround.

set ROOT_HOME=C:/Users\user\Downloads\tools

[msmigiel]

Is there any estimate as to when this might be fixed? As a simple regression I would think the fix would also be simple. Due to this I now have to hard code paths in all my scripts, which makes things harder to maintain.

[brenthdaniel]

Sorry, it was fixed some time ago but I neglected to link the PR to the issue