[
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)
