[
https://issues.apache.org/jira/browse/TIKA-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109995#comment-18109995
]
ASF GitHub Bot commented on TIKA-4864:
--------------------------------------
tballison commented on PR #3107:
URL: https://github.com/apache/tika/pull/3107#issuecomment-5482180068
I _think_ I now get why you'd want this. There are actually four places
where this should be fixed.
Could you hoist your resolveDefaultPluginsDir(codeSourceDir, cwd) into
tika-pipes-core next to ConfigMerger, maybe?
||Module / class||Current default resolution||Bug||Action||
||{{TikaServerProcess}} (tika-server-core)|jar dir only, then
CWD-relative|misses lib/ layout
(TIKA-4864)|fixed by PR #3107; route through shared helper|
||{{PipesForkParser}} (tika-pipes-fork-parser)|jar dir only, then
CWD-relative|same miss of lib/
layout|replace copy with shared helper|
||{{TikaAsyncCLI}} (tika-async-cli)|parent of jar dir only, then
CWD-relative|misses jar-adjacent layout;
also used by {{PluginsWriter}}|replace copy with shared helper|
||{{TikaGrpcServerImpl}} (tika-grpc)|none — requires config/--plugin-roots;
on missing plugin-roots falls
back to bare pf4j {{DefaultPluginManager}} (CWD-relative)|fallback
contradicts its own WARN text ("next to
tika-grpc.jar")|optional: use shared helper in the fallback|
> 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)
