我来逐个拆解你遇到的问题，给出实际可操作的解决方案：

问题1：自动生成artifactory.home_IS_UNDEFINED目录 #

这个问题通常是环境变量未正确生效或挂载目录权限/配置冲突导致的，按以下步骤排查：

• 先检查你的Docker Compose配置里的环境变量是否正确设置，确保JF_ARTIFACTORY_HOME直接定义在服务的environment块中，示例：

  services:
    artifactory:
      image: releases.jfrog.io/jfrog-docker-registry/artifactory-pro:7.3.2
      environment:
        - JF_ARTIFACTORY_HOME=/var/opt/jfrog/artifactory
      volumes:
        - /opt/artifactory:/var/opt/jfrog/artifactory
  

• 清理本地挂载目录/opt/artifactory下的旧文件（包括那个自动生成的错误目录），之前未正确配置启动时生成的文件可能干扰后续启动。
• 确保本地/opt/artifactory目录的权限是uid=1030（容器内Artifactory进程的用户ID），执行命令：

  chown -R 1030:1030 /opt/artifactory
  

  权限不匹配会导致Artifactory无法正确读取配置，从而 fallback 到默认的未定义路径。

问题2：pluginsConfig.groovy和requestRouting.groovy加载失败 #

这类插件加载错误通常和文件位置、权限或语法有关：

• 确认两个文件是否放在正确路径：容器内的$JF_ARTIFACTORY_HOME/etc/plugins（对应本地挂载目录的/opt/artifactory/etc/plugins），路径不对的话Artifactory会找不到文件。
• 检查文件权限：确保这两个文件的所有者是1030:1030，否则Artifactory进程没有读取权限。
• 排查语法错误：Groovy语法严格，缺少分号、括号不匹配、未定义变量都会导致加载失败。可以先把这两个文件临时移走，重启容器看是否能正常启动——如果启动正常，再逐个放回文件并检查日志，定位具体的语法问题。
• 注意版本兼容性：Artifactory 7.x的插件系统和旧版本有差异，如果你用的是从旧版本迁移来的插件，可能需要调整代码适配7.3.2版本。

问题3：移除URL中的"artifactory"上下文路径 #

完全可行，有两种常用方案：

方案1：修改容器内Tomcat配置（需持久化） #

• 先启动一个临时容器，导出默认的Tomcat配置文件：

  docker run --rm releases.jfrog.io/jfrog-docker-registry/artifactory-pro:7.3.2 cat /var/opt/jfrog/artifactory/tomcat/conf/server.xml > ./server.xml
  

• 编辑server.xml，找到<Context>标签，把path="/artifactory"改成path="/"。
• 在Docker Compose中添加挂载，把修改后的配置文件挂载到容器内：

  volumes:
    - /opt/artifactory:/var/opt/jfrog/artifactory
    - ./server.xml:/var/opt/jfrog/artifactory/tomcat/conf/server.xml
  

• 重启容器后，登录Artifactory后台，进入Admin > General Configuration，把Base URL改成https://node.org.local/。

方案2：用反向代理（推荐，更灵活） #

如果用Nginx做反向代理，可以添加如下配置，通过路径重写实现：

server {
    listen 443 ssl;
    server_name node.org.local;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    location / {
        proxy_pass http://artifactory:8081/artifactory/;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Prefix /;
    }
}

这种方式不需要修改容器内的配置，后续升级Artifactory也不会丢失配置，更推荐生产环境使用。

问题4：--add-opens ...=ALL-UNNAMED参数的作用 #

这些是Java 9+模块化系统的兼容参数：

• Java 9引入了模块系统（JPMS），默认会限制对JDK内部API的访问。
• Artifactory依赖的部分第三方库是传统的非模块化JAR包（属于"UNNAMED"模块），它们需要访问JDK内部的一些API（比如java.lang.reflect、java.util等包）。
• --add-opens <module>/<package>=ALL-UNNAMED的作用就是打开指定JDK模块的包，允许未命名模块的代码访问，如果没有这些参数，Artifactory启动时会抛出IllegalAccessError之类的权限异常，无法正常运行。
• 这些参数是Artifactory官方为了兼容Java模块化系统而添加的，不需要手动修改，保持默认即可。

内容的提问来源于stack exchange，提问作者Hemant Manwani