J.Pietschmann wrote:
Glen Mazza wrote:
I believe the same logger reference would just be used with each
thread instead,
es, and this is exactly the problem. It is conceivable that
different loggers might be used for different processors which
run in concurrent threads. A static logger reference
Glen Mazza wrote:
I believe the same logger reference would just be used with each thread
instead,
es, and this is exactly the problem. It is conceivable that
different loggers might be used for different processors which
run in concurrent threads. A static logger reference prohibits
this.
J.Piets
J.Pietschmann wrote:
Mutable static data, like a static logger reference, interferes
severely with using FOP in an MT environment, because this means
"one thread rendering globally" rather than "one thread per FO
processor rendering, perhaps using multiple processors, each one
in a separate thread
Simon Pepping wrote:
I like Joerg's idea of a Global Context object. It seems to have a
wider scope than FOUserAgent. An FOUserAgent object could be part of
it.
From the maintenance code's configuration it would need to have
baseDir, fontBaseDir, hyphenation-dir and strokeSVGText. Font
information
On Sun, May 09, 2004 at 11:52:31AM -0400, Glen Mazza wrote:
>
> Joerg I believe just recommended storing the user configuration in
> FOUserAgent, which is already getting passed around everywhere. Using
> my favorite design pattern, Moving Part Reduction, I also think it would
> be ideal if we
Glen Mazza wrote:
BTW, what other things besides hyphenation needs to go into
user configuration/fo user agent, say for 1.0?
Various strategy parameters, once they are implemented, like
line breaking strategy; furthermore callbacks for redrawing
pages in a GUI renderer, font management, base URL f
Glen Mazza wrote:
Should FOP itself multithread, or would it be better to let whatever
would call FOP do the multithreading?
I don't understand this. Even if the main processing methods
of the FO processing object are synchronizend, which is probaly
what you understand by "FOP isn't MT safe itself
Glen Mazza wrote:
I don't know what Xalan does with their translets, I suspect they just
rely on the caller to implement it.
Oops--my error--the translets just generate Java code. My comment was
in general for the need of XML processors such as Xalan and FOP to
implement MT internally.
Glen
Jeremias Maerki wrote:
The first two frames are in static context. The LMs share a reference
to a user agent object, of type
layoutmgr.AbstractLayoutManager.userAgent. Would this be the right
object to hold a reference to the user configuration?
On first thought, yes. But I feel the scope of
J.Pietschmann wrote:
Static objects are bad because of the usual MT issues (yeah,
even for logging).
Should FOP itself multithread, or would it be better to let whatever
would call FOP do the multithreading? I don't know what Xalan does with
their translets, I suspect they just rely on the call
Simon Pepping wrote:
But
hyphenation is done deep down in the process, where any reference to
the start-up objects is lost. How can I configure it?
The idea is to use an object which represents some global context
and is reachable from nearly anywhere in the FO tree and LM tree.
I'd think the user
On 08.05.2004 23:04:40 Simon Pepping wrote:
> I am trying to enable user configuration of the directory of
> hyphenation files, like in the maintenance code. Configuration of the
> renderers is easy, because they are instantiated in Fop.main(). But
> hyphenation is done deep down in the process, w
Hi,
I am trying to enable user configuration of the directory of
hyphenation files, like in the maintenance code. Configuration of the
renderers is easy, because they are instantiated in Fop.main(). But
hyphenation is done deep down in the process, where any reference to
the start-up objects is lo
13 matches
Mail list logo
