Re: fop-0.92.beta: Thread safety issues with FOP instance construction

[Simon Pepping <sp...@leverkruid.eu>]

On Mon, May 15, 2006 at 09:33:49AM +0200, Jeremias Maerki wrote:
> I'm sure everyone has seen this thread on fop-users. Any particular
> preferences on one of the two options I listed below? The first will
> require coordination with Batik as they are supposed to migrate to that
> class and it's basically their version. We used a modified version of
> theirs. The second is probably cleaner but since the change is
> backwards-incompatible for any ElementMapping implementation (Barcode4J,
> for example), this is not to be taken lightly. I think the first is
> easier, should not have any side-effects but feels more like patchwork.

The first option sounds fine with me.

> > I see two possible routes:
> > 1. Adding an optional parameter to the Service class' providers() method
> > which allows to return class names instead of instances. This will
> > restore the previous behaviour and maintain backwards compatibility with
> > the existing ElementMapping implementations.
> > 2. Change ElementMapping's constructor to accept the namespace URI as a
> > parameter and call initialize() right after that. Drawback: It's a
> > backwards-incompatible change.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.eu