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
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
