在 CentOS 上的 Apache FOP 中无限扫描字体 [英] Infinite scan for fonts in Apache FOP on CentOS

问题描述

我在其中一个项目中使用 Apache Batik 将 SVG 转换为 PDF.该项目是在 Tomcat 7 中运行的 Spring 应用程序.在 Ubuntu 下运行的开发机器上一切正常，Tomcat 使用 $CATALINA_HOME/bin/startup.sh 启动.但是，当我尝试使用 CentOS 6 在生产服务器上运行该应用程序并且 Tomcat 开始使用 service tomcat7 start 命令时，该应用程序在转换时陷入无限循环.我已经尝试调试问题并找到了这段代码:

I use Apache Batik to convert SVG into PDF in one of the projects. The project is Spring application running in Tomcat 7. Everything works OK on development machine which runs under Ubuntu with Tomcat being started using $CATALINA_HOME/bin/startup.sh. But when I try to run the app on production server with CentOS 6 and Tomcat started using service tomcat7 start command the app falls into infinite loop on convertation. I've tried to debug the problem and found this piece of code:

/**
 * Creates the {@link FontInfo} instance for the given configuration.
 * @param cfg the configuration
 * @param useComplexScriptFeatures true if complex script features enabled
 * @return the font collection
 * @throws FOPException if an error occurs while setting up the fonts
 */
public static FontInfo createFontInfo(Configuration cfg, boolean useComplexScriptFeatures)
    throws FOPException {
    FontInfo fontInfo = new FontInfo();
    final boolean strict = false;
    if (cfg != null) {
        URI thisUri = new File(".").getAbsoluteFile().toURI();
        InternalResourceResolver resourceResolver
                = ResourceResolverFactory.createDefaultInternalResourceResolver(thisUri);
        //TODO The following could be optimized by retaining the FontManager somewhere
        FontManager fontManager = new FontManager(resourceResolver, FontDetectorFactory.createDefault(),
                FontCacheManagerFactory.createDefault());

        //TODO Make use of fontBaseURL, font substitution and referencing configuration
        //Requires a change to the expected configuration layout

        DefaultFontConfig.DefaultFontConfigParser parser
                = new DefaultFontConfig.DefaultFontConfigParser();
        DefaultFontConfig fontInfoConfig = parser.parse(cfg, strict);
        DefaultFontConfigurator fontInfoConfigurator
                = new DefaultFontConfigurator(fontManager, null, strict);
        List<EmbedFontInfo> fontInfoList = fontInfoConfigurator.configure(fontInfoConfig);
        fontManager.saveCache();
        FontSetup.setup(fontInfo, fontInfoList, resourceResolver, useComplexScriptFeatures);
    } else {
        FontSetup.setup(fontInfo, useComplexScriptFeatures);
    }
    return fontInfo;
}

在 PDFDocumentGraphics2DConfigurator 类中.当我在开发人员机器上运行应用程序时，行 URI thisUri = new File(".").getAbsoluteFile().toURI(); 结果与 thisUri 被分配与 ~/tomcat/bin/. 文件夹.当应用在生产机器上运行时，它被分配了 /. 值.我认为这是主要问题，因为 thisUri 的值是 FOP 开始字体搜索的文件夹，而在生产机器上，这是文件系统的根目录，对整个 FS 结构的递归搜索是非常慢.我尝试将 fop.xconf 文件添加到带有字体配置的 WEB-INF 目录中，但这并没有影响 FOP 的行为.而且我无法像在开发机器上启动一样在生产服务器上启动 Tomcat.有没有人对如何配置 FOR 字体扫描的基本目录有任何想法?还是我做错了什么?

in PDFDocumentGraphics2DConfigurator class. When I'm running the app on developer machine the line URI thisUri = new File(".").getAbsoluteFile().toURI(); results with thisUri being assigned with ~/tomcat/bin/. folder. When the app is running on production machine it is assigned with /. value. I think that this is the main problem because the value of thisUri is the folder in which FOP starts fonts search and on the production machine this is the root of file system and recursive search on the whole FS structure is very slow. I tried to add fop.xconf file to the WEB-INF directory with fonts configuration but it didn't affected the behavior of FOP. And I can't start Tomcat on production server the same way as I start on the dev machine. Has anyone ideas on how to configure the base directory for font scan of FOR? Or am I doing something wrong?

推荐答案

我已经找到了解决问题的方法.我不确定做这样的事情是对还是错，但它确实有效.解决方法基于 File.getAbsolutFile() 默认返回根据 user.dir 选项定义的目录解析的目录.所以我需要某种方式在 Tomcat 服务启动时传递这个选项.我发现这样做的唯一方法是将 -Duser.dir=/%CATALINA_HOME/ 添加到 %CATALINA_HOME/bin/setenv.sh 中定义的 CATALINA_OPTS 变量文件.之后，字体扫描过程花费了正常的时间，我的应用开始正常运行.

I've found the workaround for the problem. I'm not sure if its wright or wrong to do stuff like that but it works. The workaround is based on the fact that File.getAbsolutFile() by default returns the directory resolved against the directory defined by user.dir option. So I need some way to pass this option on Tomcat service start. The only way I've found to do this is to add -Duser.dir=/%CATALINA_HOME/ to the CATALINA_OPTS variable defined in %CATALINA_HOME/bin/setenv.sh file. After that the font scan process took normal amount of time and my app started to work fine.

这篇关于在 CentOS 上的 Apache FOP 中无限扫描字体的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！