Verify reachability of three legacy factory query methods and decide whether to remove them #38013

Research Question

Three public static methods build their query by concatenating a caller-supplied value into the statement text:

They look removable, but the evidence is not yet conclusive. This spike establishes whether they are reachable and recommends what to do with them.

Timebox

4h

Acceptance Criteria

• Confirm whether a .jsp_nocomp file can be served or compiled in any supported deployment. WEB-INF/web.xml:698 maps the JSP servlet to *.jsp only, so the expectation is no — the deliverable is confirming it, including what the default servlet returns for a direct GET.
• Confirm whether any build, packaging or upgrade step renames .jsp_nocomp files back to .jsp.
• Establish whether the three methods have any reachable caller, searching with no file-extension filter across Java, enterprise, JSP, VTL, XML, JS and any other packaged resource.
• State whether MaintenanceUtil.DBSearchAndReplace (reached by POST /v1/maintenance/_searchAndReplace and by the DWR path AssetsSearchAndReplaceAjax) covers what the parked SearchAndReplace.jsp_nocomp did for links and containers, or whether something was lost in that migration.
• Review the remaining 8 .jsp_nocomp files (863 lines across all 9) and report whether any other production code exists only to serve them.
• Recommend one outcome per method, with its rationale: remove, deprecate for removal, or keep.
• If removal is recommended, state what happens to the parked JSPs that reference the methods, and whether the three packages being exported to OSGi (osgi-extra.conf lines 363, 373, 453) changes the recommendation.
• Record the findings and the decision on this issue. Any code change is follow-up work, not part of this spike.

Context

Found during a code audit of the database access layer.

What is known so far, and where the first pass was wrong:

• A first search reported the three methods as having no callers at all. That search filtered by file extension and missed .jsp_nocomp. SearchAndReplace.jsp_nocomp does call two of them: getLinkByCondition at line 424 and getContainerByCondition at line 437. Only deleteMultiTreesForInodes has no reference of any kind.
• web.xml:698 maps the JSP servlet to *.jsp, and there is no mapping for *.jsp_nocomp, so that file is not expected to compile or run. This is the assumption the spike has to verify rather than inherit.
• Search-and-replace exists today at MaintenanceResource.java:587 (/_searchAndReplace, calling MaintenanceUtil.DBSearchAndReplace at :614) and through AssetsSearchAndReplaceAjax, used by view_cms_maintenance.jsp. The parked JSP appears to predate that.
• The replacement APIs for the three methods are MenuLinkAPI.findLinks(...), ContainerAPI.findContainers(User, SearchParams) and MultiTreeAPI.deleteMultiTreesForIdentifiers(...). All three take a User; the factory methods take none and apply no permission filtering. MultiTreeAPI.deleteMultiTreesForIdentifiers is also @WrapInTransaction and evicts the multi-tree cache, which the factory method does not.
• Removing MultiTreeFactory.deleteMultiTreesForInodes would not remove the pattern from the codebase: MultiTreeAPIImpl.deleteMultiTreesForIdentifiers builds the same IN (...) lists by concatenation and is live, called from ESContentFactoryImpl. That is separate work.

Links

• Add Semgrep rules to catch SQL injection anti-patterns in PR scans #35547 (Semgrep rules for query-assembly anti-patterns)