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

["Dominik Schmidt (Jira)" <ji...@apache.org>]

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