[
https://issues.apache.org/jira/browse/TIKA-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Schmidt updated TIKA-4988:
----------------------------------
Description:
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).
was:
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).
> 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)
