[WFCORE-4369] Fixing JDK 13 test issue

[ropalka]

https://issues.jboss.org/browse/WFCORE-4369

[ropalka]

Please review @darranl

[wildfly-ci]

Core - Full Integration Build 8408 outcome was FAILURE using a merge of 95e2cfe
Summary: Exit code 1 (Step: Build & test core (Maven)) (new) Build time: 00:01:13

[darranl]

This seems to be suffering from a lot of CI problems.

[ropalka]

All should be OK now @darranl

[darranl]

@mchoma Do you have an IBM environment available to double check this one? I would like to get it merged but our CI doesn't cover the IBM JDK.

[bstansberry]

@darranl

JDK8 -- https://ci.wildfly.org/viewLog.html?buildId=143971&tab=buildResultsDiv&buildTypeId=WildFlyCore_MasterLinuxIbmJdk

We don't seem to have an IBM JDK11 in our CI.

[mchoma]

we dont have ibm jdk11 neither.

[mchoma]

so that is only one change compared to tls-sun.xml. Could be tls-sun.xml parametrized?

[ropalka]

I'm not that familiar with WildFly configuration mock test support @mchoma .
@darranl @bstansberry @kabir is it possible to parametrize subsystem test configurations
based on condition comparing 'java.specification.version' JVM property?

[bstansberry]

If the attribute supports expressions you can put an expression in the xml and then set a system property before running the test; e.g. the code you have now that's selecting which config file could instead set a property.

I haven't looked, but these may not support expressions. Historically we didn't for 'class name' attributes. For no great reason really. This is the first good use case for using them in that kind of attribute that I've seen.

[ropalka]

@mchoma I'm not going to investigate this. Let's leave the proposed changes as they are - it's all just about tests and not implementation.

[mchoma]

Ok I dont insist. Setting /elytron/provider-loader/class-names/expressions-allowed = true would help. But as Brian said it is everywhere else false. So we should be consistent.

[bstansberry]

I don't mind changing an expressions-allowed setting if that's what Darran/Farah/Jeff Mesnil prefer. There's really not a good reason for having those as false and if there's a reasonable, understandable use case for true for a particular attribute I don't think we have to enforce a rule against it.

I agree a change like that is beyond the scope of this PR though.

[mchoma]

Thinking again. Shouldn't it work without provider-loader name="ManagerProviderLoader" by default?. So by default using just system providers? Or is specifying provider loader what is tested here?

[darranl]

Off topic for this PR but when we started defining attributes with expression support enabled and disabled it was primarily to avoid references to other parts of the model being handled as an expression, but at the time we didn't have support for capabilities.

I wonder if we are getting nearer to a point where expression support is enabled unless the attribute is a capability reference.

[bstansberry]

I've commented on this PR as part of general discussing but am not approving or disapproving, so don't wait for me. Looks like @darranl is reviewing.

The custom IBM JDK 8 test job I ran against this branch (link above) produced the same results as the normal nightly runs. We get 13 failures, which would be good to sort, but that's out of scope for this PR. No failures in the elytron subsystem tests.