Class ConfigFileValidator

java.lang.Object
org.frontcache.io.ConfigFileValidator
public class ConfigFileValidator extends Object
Dry-parses a candidate config file before set-config writes it.

Why validate at all, rather than write and let the reload cope

Every one of these loaders is deliberately tolerant: a line it cannot use is logged and skipped, and the rest of the file keeps working. That is right for startup - a node must come up - and it is exactly wrong as the only feedback an operator gets from a Save button, because the outcome is a node running configuration that does not match its own config file. That mismatch is what the Configs screens exist to make visible, and this is the same problem one step earlier. The cost of getting it wrong is on record: GuardRuleParser.splitFields documents a production node where the naive split("\\|") silently disabled 5 of 19 rules - every anti-scraper redirect - and nothing said so.

A parse error refuses the whole save

All of it, not just the bad line, and every bad line is listed so they can be fixed in one pass. This does mean a file that already contains a broken line cannot be saved until that line is fixed too. That is deliberate: the operator is right there, the message names the line, and the alternative is a Save button that quietly keeps a rule dead.

Nothing here touches live state

No rule swap, no resolver reload, no counter reset, no pool. Everything parsed is thrown away.

  • Method Details

    • validate

      public static List<String> validate(ConfigFile configFile, String content)
      Returns:
      one message per unusable line, "line N: ..."; empty when the file is usable