Salesforce Certified MuleSoft Developer free question 5 / 10 · Domain 4: Structuring Mule Applications
An operations team keeps extra system properties for an on-premises Mule instance in an include file of the Java Service Wrapper, as wrapper.java.additional.<n> entries, instead of editing wrapper.conf itself. What does the documentation say to do with these entries?
- Write each property as -M-D<name>=<value>, the same way as on the mule command line
- Give them a high <n> outside the standard sequence and set wrapper.ignore_sequence_gaps
- Reuse the <n> of an existing entry, so the value in the include file replaces that one
- Number them right after the last entry in wrapper.conf, leaving no gap in the sequence
Show the answer and explanation
Answer: B
Why this is correct
On an on-premises Mule instance, system properties can be passed on the command line, for example mule start -M-Dmule.myEnv=prod, or written into the Java Service Wrapper configuration as wrapper.java.additional.<n> entries in wrapper.conf under the conf directory, with each property name prefixed by -D. The page adds two considerations. First, every <n> must be a new number that is not used yet; otherwise Java does not parse the properties correctly. Second, when the entries are placed in an include file, configure a high <n> value so the numbers sit outside the standard sequence, and make sure wrapper.ignore_sequence_gaps is set to true. Its example uses 1900 and 1901 together with wrapper.ignore_sequence_gaps=TRUE. The high numbers keep the include file from colliding with the main file.
Why the other options are wrong
"Number them right after the last entry in wrapper.conf, leaving no gap in the sequence" … For entries in an include file the advice is the opposite of closing the sequence: use a high <n> so the numbers stay outside the standard sequence, and let the Wrapper accept the gap through wrapper.ignore_sequence_gaps.
"Reuse the <n> of an existing entry, so the value in the include file replaces that one" … Each <n> must be a number that is not already in use. The page warns that otherwise Java does not parse the properties correctly, so reusing a number does not override the earlier entry in a reliable way.
"Write each property as -M-D<name>=<value>, the same way as on the mule command line" … The -M- prefix belongs to the mule or mule start command line. Inside the Wrapper configuration the entries carry the Java form, -D followed by the name, as in wrapper.java.additional.999=-Dmule.encoding=ISO-8859-1.
Command line or Wrapper file
Properties given on the command line apply to that start of Mule. Wrapper entries are read every time the instance starts, which suits values that should stay in place. In both cases the values are system properties, so they take precedence over the app's configuration properties with the same name.