[
https://issues.apache.org/jira/browse/FOP-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 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)
