Hi Jeremias, > Looks like you're still using one of the deprecated Fop > constructors. Please be aware that they will be remove for > the next release. Furthermore, you're giving a way > performance by not reusing the FopFactory. See [1] for the > documentation on the new finalized API.
Thanks! I was not aware of this, I was just helping my colleague debug the problem. I will inform him about this. We're looking for ways to crank out more performance as it is! > Obviously, that's not an excuse for the exception but at least I'm > pretty sure it's the solution for your current problem. I'm confused > myself why this exception occurs in the first place. By means of > static code analysis I cannot find any evidence of poor use of > static variables that could lead to this exception. The "Service" > stuff is properly synchronized and the FOElementMapping stuff is > purely non-static. Does anyone have an idea what's wrong here? There are multiple threads using the same ElementMapping instances (provided by the static cache in the "Service"). The ElementMapping classes are not thread-safe. A non-exhaustive list of solutions include: 1) The construction and initalization of the ElementMappings should be done in the relative thread-saftey of the static cache part of the code (e.g. in the Service), and they would need to be used in an immutable fashion after that. 2) If (1) is not possible, the ElementMapping objects have to made thread-safe themselves. What strikes your fancy? Thanks, Ryan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
