[
https://issues.apache.org/jira/browse/TIKA-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18129612#comment-18129612
]
ASF GitHub Bot commented on TIKA-4988:
--------------------------------------
tballison commented on PR #3383:
URL: https://github.com/apache/tika/pull/3383#issuecomment-6315897708
Couple of nits from my :robot: I don't agree with the bot's choice of
overrides. I think commandline should be allowed to override the config.json as
long as the logging is clear that that is what is happening.
I didn't look closely, does this PR throw if a requested preset doesn't
exist?
```
Maintainer decision
- Should the CLI/env override an inline definition? The second commit
(aee135edd5) makes --preset X / TIKA_PRESETS=X replace the file's entry with
true, including an inline object. Two consequences:
- Silent: say the file defines its own thumbnail object and
TIKA_PRESETS=thumbnail is set, e.g. baked into a derived image or Helm values.
The
operator's content is quietly swapped for the catalog's. The log line
says "activated by", not "replaced".
- Confusing: naming a preset that exists only inline (--preset mine)
fails startup with "true activates a catalog preset…", a true the user never
wrote.
I'd recommend: an object entry in the file wins, or fail startup on that
conflict. A false/null/absent entry becomes true, which keeps "the CLI
wins over false". Either way the docs and
testPresetsOverrideTheConfigsOwnEntries change.
Edge cases
1. /async doesn't see CLI/env presets. TikaServerProcess.java:552 builds
AsyncResource(tikaServerConfig.getConfigPath()) from the raw file, and the
tuple deserializer accepts a preset field. So --preset thumbnail plus
an /async tuple with preset=thumbnail gets PRESET_NOT_FOUND, which
contradicts "the same as "name": true". Fix it by feeding /async the
merged config, or document that /async only reads the file.
2. A malformed presets value is now silently accepted. If the file has
"presets": "thumbnail" or an array, startup used to fail ("must be an
object"). With any --preset, getOrCreateObject overwrites it with an
object instead. Throw in ConfigMerger when presets exists and isn't an
object.
```
> 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. The
> command line and the environment win over the file. 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)
