[
https://issues.apache.org/jira/browse/TIKA-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109994#comment-18109994
]
Dominik Schmidt commented on TIKA-4864:
---------------------------------------
Yes, and plugin-roots stays authoritative; the PR does not touch the configured
path. It only fixes the default for the zero-config case, which is what the
shipped docker image and an unpacked distribution run with: they have no
plugin-roots in their config, and the default resolves the relative literal
"plugins" against whatever the working directory happens to be. That works
today because the container starts in /, and silently breaks the moment an
orchestrator sets a different workdir (docker run -w; Woodpecker does this for
service containers): the registry comes up empty and every parse fails with
"Unknown fetcher type ... Available types: []". The second half is that the
parent and the forked PipesServer each resolved the relative default against
their own working directory, so they could disagree; an absolute default keeps
them on the same directory. So: plugin-roots for anyone who configures, this
fix so the stock image does not depend on where it was started.
> Default plugins directory resolution depends on the working directory
> ---------------------------------------------------------------------
>
> Key: TIKA-4864
> URL: https://issues.apache.org/jira/browse/TIKA-4864
> Project: Tika
> Issue Type: Bug
> Affects Versions: 4.0.0
> Reporter: Dominik Schmidt
> Priority: Major
>
> The 4.0.0 docker image (and any classpath-launched tika-server) loses all
> pipes plugins when the process working directory is not the install
> directory. The server starts fine, but the first parse fails:
> org.apache.tika.exception.TikaConfigException: Unknown fetcher type:
> 'file-system-fetcher'
> for instance id '__tika-server'. Available types: []
> Reproduce with the released image; the only difference is the working
> directory:
> docker run -p 9998:9998 apache/tika:4.0.0-full # parses fine
> docker run -w /somewhere -p 9998:9998 apache/tika:4.0.0-full # first parse
> fails as above
> This is not a synthetic case: any orchestrator that sets the container
> working directory hits it, for example Woodpecker CI service containers
> (workspace as workdir), Kubernetes workingDir, or compose working_dir.
> Cause, in TikaServerProcess.resolveDefaultPluginsDir() (introduced with
> TIKA-4682):
> 1. It looks for plugins next to "the running jar", taken from the CodeSource
> of TikaServerProcess. In the docker image that class lives in
> lib/tika-server-core-4.0.0.jar, so the check probes
> /opt/tika-server/lib/plugins, which does not exist. The actual plugins sit
> next to the standard jar in /opt/tika-server/plugins.
> 2. It then falls back to plugins relative to the CWD. In the image that only
> works because WORKDIR /opt/tika-server happens to match.
> 3. If neither exists, the literal relative string plugins is passed on, and
> the forked PipesServer resolves it against its own CWD, ending with an empty
> plugin registry and the error above.
> The javadoc says "The plugin-roots will default to a 'plugins' directory at
> the same level as the server jar", which is what one would expect, but step 1
> checks the level of the wrong jar. There is also no CLI or environment
> override in 4.0.0, only the plugin-roots config key, so the image cannot be
> fixed from the outside without shipping a config file.
> Suggested fix: also probe the parent of the code-source directory (covers the
> lib/ layout), or resolve against the jar named on the command line rather
> than the CodeSource, and resolve the final result to an absolute path before
> handing it to the pipes fork so the fork's CWD stops mattering.
> Independently, the docker image could pin plugin-roots absolutely instead of
> relying on its WORKDIR.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
