[CCCLL]

zkCli keeps a single AddWatchCommand instance for the whole session, and parse() only assigned mode when -m was given. After addWatch -m PERSISTENT /a, a later addWatch /b in the same session silently registered a PERSISTENT watch instead of the default PERSISTENT_RECURSIVE.

parse() now falls back to the default mode when -m is absent, the same way ReconfigCommand.parse() resets its per-invocation fields.

Testing

• New ZooKeeperTest#testAddWatchWithoutModeUsesDefaultMode runs addWatch -m PERSISTENT /a and then addWatch /b through one ZooKeeperMain; it fails without the fix (/b shows up among the persistent watches) and passes with it.
• org.apache.zookeeper.cli.*Test, ZooKeeperTest, RemoveWatchesCmdTest, ZooKeeperQuotaTest, EnforceQuotaTest and the persistent watcher tests pass; checkstyle and spotbugs report no issues.
• Manually with bin/zkCli.sh against a standalone server: after addWatch -m PERSISTENT /w1, addWatch /w2 followed by create /w2/c now fires NodeCreated path:/w2/c (before the fix it fired NodeChildrenChanged path:/w2).

[anmolnar]

Thanks for the contribution. Please create Jira tickets. We cannot accept patches without associated Jira tickets.

[CCCLL]

Thanks, I'll create Jira tickets for this PR and for #2479 and #2480 as soon as my Jira account request is approved, and update the titles.

[CCCLL]

Created ZOOKEEPER-5105 for this PR, ZOOKEEPER-5106 for #2479 and ZOOKEEPER-5107 for #2480, and updated the titles.