[jira] [Commented] (TIKA-4988) Activate catalog presets from the command line and environment (TIKA_PRESETS)

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TIKA-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18129602#comment-18129602 ] 

ASF GitHub Bot commented on TIKA-4988:
--------------------------------------

dschmidt opened a new pull request, #3383:
URL: https://github.com/apache/tika/pull/3383

   A catalog preset could only be activated through the config file (`"presets": {"thumbnail": true}` plus `-c`), so the Docker image needed a mounted file for a single boolean. tika-server now takes `--preset <name>`, repeatable, and the environment variable `TIKA_PRESETS` as a comma-separated list; either is the equivalent of `"<name>": true` and never defines preset content.
   
   The names go through `ConfigOverrides`/`ConfigMerger` into the `presets` object of the startup config, once for the front end's `TikaLoader` (which builds the `PresetRegistry` the preset routes check) and once in `createServerConfig` for the forks, so the workers keep receiving the resolved config over stdin and never read the environment. A name the config file already has keeps the file's value, including `false`; a name the catalog does not know fails startup as before. The startup log names the source of each activation.
   
   Tests: `ConfigMergerTest` (merge semantics), `TikaServerConfigTest` (option and env parsing, deduplication), and `PresetActivationIntegrationTest`, which starts the real server with `--preset` and with `TIKA_PRESETS` against a test catalog entry and checks the preset route end to end, plus the unknown-name startup failure. `IntegrationTestBase` can now pass environment variables to the server process.
   
   Docs: server page (presets section, options table), Docker page, CHANGES. tika-grpc has no preset routes; tika-app is out of scope.
   
   https://issues.apache.org/jira/browse/TIKA-4988
   




> Activate catalog presets from the command line and environment (TIKA_PRESETS)
> -----------------------------------------------------------------------------
>
>                 Key: TIKA-4988
>                 URL: https://issues.apache.org/jira/browse/TIKA-4988
>             Project: Tika
>          Issue Type: New Feature
>            Reporter: Dominik Schmidt
>            Priority: Major
>
> A catalog preset such as thumbnail can only be activated through the config file: "presets": {"thumbnail": true} plus -c. In the Docker image that means mounting a config file for a single boolean, and there is no way to activate a preset without a config file at all.
> Proposal: tika-server accepts --preset <name>, repeatable, and the environment variable TIKA_PRESETS as a comma-separated list, e.g. docker run -e TIKA_PRESETS=thumbnail,render-thumbnail apache/tika. Both only activate catalog presets, the equivalent of "name": true, and never define preset content. The names are added to the presets object of the startup config before the front end and the forked workers load it, so the forks keep receiving the resolved config over stdin and never read the environment. A name the catalog does not know fails startup, as "name": true does today. Where the config file already names the same preset, the file wins. The startup log says where an activation came from.
> Docs: the server page's "every active preset is a visible line in the operator's config" becomes config, command line or environment; the command line options table and the Docker page get the one-liner. tika-grpc has no preset routes, so nothing changes there; tika-app is out of scope.
> Related: TIKA-4856 (/unpack/thumbnail), TIKA-4909 (${env:} interpolation).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)