[
https://issues.apache.org/jira/browse/TIKA-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110057#comment-18110057
]
Hudson commented on TIKA-4864:
------------------------------
SUCCESS: Integrated in Jenkins build Tika ยป tika-main-jdk17 #1603 (See
[https://ci-builds.apache.org/job/Tika/job/tika-main-jdk17/1603/])
TIKA-4864: resolve the default plugins dir against the install layout and make
it absolute (#3107) (github:
[https://github.com/apache/tika/commit/3b6fd2436b70cb9216bfcbd07694d6c492ec8ce6])
* (edit)
tika-server/tika-server-core/src/main/java/org/apache/tika/server/core/TikaServerProcess.java
* (edit)
tika-pipes/tika-async-cli/src/main/java/org/apache/tika/async/cli/PluginsWriter.java
* (add)
tika-pipes/tika-pipes-core/src/main/java/org/apache/tika/pipes/core/config/DefaultPluginsDir.java
* (edit) tika-server/docker-build/full/Dockerfile
* (edit)
tika-pipes/tika-pipes-fork-parser/src/main/java/org/apache/tika/pipes/fork/PipesForkParser.java
* (edit) tika-server/docker-build/minimal/Dockerfile
* (edit) CHANGES.txt
* (add)
tika-pipes/tika-pipes-core/src/test/java/org/apache/tika/pipes/core/config/DefaultPluginsDirTest.java
* (edit)
tika-pipes/tika-async-cli/src/main/java/org/apache/tika/async/cli/TikaAsyncCLI.java
> 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
> Fix For: 4.1.0
>
>
> 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)
