You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by "Peter Hull (Jira)" <ji...@apache.org> on 2024/03/30 08:43:00 UTC
[jira] [Comment Edited] (FOP-3172) image-loading configuration settings are not thread-safe
[ https://issues.apache.org/jira/browse/FOP-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17832411#comment-17832411 ]
Peter Hull edited comment on FOP-3172 at 3/30/24 8:42 AM:
----------------------------------------------------------
I had a little dig into this. As I understand it, creating a FopFactory creates a FopFactoryBuilder, which in turn creates a FopFactoryConfigImpl. FopFactoryConfigImpl creates an ImageManager. The ImageManager stores data, including the 'Additional Penalties' which are the issue here, in ImageImplRegistry, which is a singleton class. So ultimately it's this single instance that is responsible for the carry-over of properties from one FopFactory to the next, and it doesn't seem like there is a simple way to avoid that.
{code:java}
@Test
public void testCarryOver() throws Exception {
URI baseURI = URI.create("http://example.com/");
String className = SequentialTest.class.getName();
FopFactory fopFactory1 = FopFactory.newInstance(baseURI);
fopFactory1.getImageManager().getRegistry().setAdditionalPenalty(className, Penalty.toPenalty(1234));
FopFactory fopFactory2 = FopFactory.newInstance(baseURI);
Penalty expected = Penalty.ZERO_PENALTY;
Penalty actual = fopFactory2.getImageManager().getRegistry().getAdditionalPenalty(className);
// For a 'fresh' FopFactory, penalty should be the default, zero.
org.junit.Assert.assertEquals(expected, actual);
// in fact it fails because 1234 is carried over from fopFactory1 to fopFactory2.
}
{code}
For reference the classes are,
* org.apache.xmlgraphics.image.loader.spi.ImageImplRegistry in xmlgraphics-commons-2.9.jar
* org.apache.xmlgraphics.image.loader.ImageManager in in xmlgraphics-commons-2.9.jar
* org.apache.fop.apps.FopFactoryBuilder in fop-core-2.9.jar
* org.apache.fop.apps.FopConfParser in fop-core-2.9.jar
was (Author: peterhull90):
I had a little dig into this. As I understand it, creating a FopFactory creates a FopFactoryBuilder, which in turn creates a FopFactoryConfigImpl. FopFactoryConfigImpl creates an ImageManager. The ImageManager stores data, including the 'Additional Penalties' which are the issue here, in ImageImplRegistry, which is a singleton class. So ultimately it's this single instance that is responsible for the carry-over of properties from one FopFactory to the next, and it doesn't seem like there is a simple way to avoid that.
For reference the classes are,
* org.apache.xmlgraphics.image.loader.spi.ImageImplRegistry in xmlgraphics-commons-2.9.jar
* org.apache.xmlgraphics.image.loader.ImageManager in in xmlgraphics-commons-2.9.jar
* org.apache.fop.apps.FopFactoryBuilder in fop-core-2.9.jar
* org.apache.fop.apps.FopConfParser in fop-core-2.9.jar
> image-loading configuration settings are not thread-safe
> --------------------------------------------------------
>
> Key: FOP-3172
> URL: https://issues.apache.org/jira/browse/FOP-3172
> Project: FOP
> Issue Type: Bug
> Components: image/unqualified
> Affects Versions: 2.9
> Reporter: Martin Leitner
> Priority: Major
> Attachments: fop_3172.zip
>
>
> As a workaround for FOP-3171 I added an <image-loading> section to the config and noticed that the settings will take effect on all subsequent renderings in the same VM, even when they use a different config or none at all. When running two or more rendering processes with different configs in parallel, the result will basically be random.
> At the very least, this behaviour should be documented and warned about.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)