Help Desk Ticket Reference: https://na7.salesforce.com/500A000000BfC5g Steps to Reproduce: 1. add the lines in standalone.xml:- {code} <system-properties> <property name="javax.net.ssl.trustStore" value="/dir/truststore.jks"/> <property name="javax.net.ssl.trustStorePassword" value="${VAULT::blk::attr::MTBlYWUzNDEtMjI2MC00NWYzLWFiZmUtM2EyYjZkNDgyZWM4TElORV9CUkVBS215YWxpYXM=}" /> </system-properties> <vault> <vault-option name="KEYSTORE_URL" value="/opt/jboss-eap-6.0/standalone/configuration/vault.jks"/> <vault-option name="KEYSTORE_PASSWORD" value="MASK-2gTQPnrWJaqrh0pURMKAOw"/> <vault-option name="KEYSTORE_ALIAS" value="myalias"/> <vault-option name="SALT" value="12345678"/> <vault-option name="ITERATION_COUNT" value="44"/> <vault-option name="ENC_FILE_DIR" value="/opt/jboss-eap-6.0/standalone/configuration/"/> </vault> {code} 2. start EAP6 in standalone mode project_key: JBPAPP6 Usage of vault for system-properties throws java.lang.SecurityException. boot.log:- {code} 20:35:30,267 ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("add") failed - address: ([("system-property" => "javax.net.ssl.trustStorePassword")]): java.lang.SecurityException: JBAS013322: Vault is not initialized at org.jboss.as.security.vault.RuntimeVaultReader.retrieveFromVault(RuntimeVaultReader.java:98) [jboss-as-security-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.server.RuntimeExpressionResolver.resolvePluggableExpression(RuntimeExpressionResolver.java:45) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressionsRecursively(ExpressionResolverImpl.java:58) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressions(ExpressionResolverImpl.java:40) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.controller.ModelControllerImpl.resolveExpressions(ModelControllerImpl.java:455) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.controller.OperationContextImpl.resolveExpressions(OperationContextImpl.java:689) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.controller.operations.common.SystemPropertyAddHandler.execute(SystemPropertyAddHandler.java:112) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:175) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:191) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.server.ServerService.boot(ServerService.java:295) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.server.ServerService.boot(ServerService.java:270) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:156) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37] {code}
Changing how this works may have far reaching affects. I think it's too late in the 6.1 cycle to consider this.
There's a chicken and egg problem here. If we defer system property processing until after the vault is initialized, system properties cannot be used in the vault configuration itself. (It would also impact path configuration.) Solving this would require something clever (aka hacky) like having the handler for the system property add using an OperationContext attachment to signal the handler for the vault add to store the system property. But only if the handler for the system property add can't do it due to the missing vault. Add a step to fail if the signal isn't received (i.e. there's no vault add in the set of ops.)
Could this not be solved like in domain mode where a system property has an attribute "boot-time" ? I have vaulted system properties set in <server-group> with "boot-time=false" and they work fine.
Tom, please send me an example config where this works. I don't see why it would, so perhaps your config will give me a nice clue! In standalone, all system properties in standalone.xml have "boot-time=false" semantics.
@Brian: In domain mode, in host.xml I have the vault as per normal Then in domain.xml, I have: <server-groups> <server-group name="idpgroup" profile="default"> <socket-binding-group ref="standard-sockets"/> <deployments> <deployment name="ShowSystemProperties.war" runtime-name="ShowSystemProperties.war"/> </deployments> <system-properties> <property name="testvault" value="${VAULT::system::property::NjQ0Njg1MmUtYzdjMy00NjkwLWE3OWItMmM3OTc5M2I3YTM4TElORV9CUkVBS3ZhdWx0}" boot-time="false"/> </system-properties> </server-group> </server-groups> My deployment just loops over all system props and print them... and it shows the decoded "testvault" property. The main difference that can be observed, is that "ps -auxww" will show this instance with the -Dtestvault=${...} when using boot-time=true while with boot-time=false, the -Dtestvault=${...} does not show on ps -auxww
@Tom: With 6.1, when server-group config includes a system property with an expression, I see it getting resolved either way, e.g. <system-properties> <property name="testprop" value="${foo:hello}" boot-time="false"/> </system-properties> will result in testprop having a value of "hello" regardless of the value of boot-time. This matches what I expect from reading the code. This works because the HostController process actually resolves the expression before feeding it to the server process. That's arguably a bug in the boot-time=false case, since the server process should really be allowed to resolve it itself. In practice it's fine since the HC's resolution process is going to match what the server process would do anyway. In EAP 6.0, the expression wasn't resolved no matter what the value of boot-time was. The resolution we see in 6.1 was the result of fixing a different bug. In any case, this doesn't help with standalone, where there is no separate process to do the resolution.
Looks the request for inclusion to EAP6.2.0 is missed the deadline. I want to request inclusion to EAP 6.3.0.
Customer requesting this fix in https://c.na7.visual.force.com/apex/Case_View?id=500A000000HoP8k&sfdc.override=1 as well.
Verified in EAP 6.3.0.DR2
Replace <programlisting> tag with tick (`) to fix Bug 1096865