RE: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-11-22 Thread Andreas L. Delmelle
 -Original Message-
 From: Glen Mazza [mailto:[EMAIL PROTECTED]

 1.0's bookmarks are different from 0.20.5's, the former has
 fox:bookmarks as the parent element.
 It's been that way in 1.0 for a long time,
 before I came on board I believe.


Yes, and it even has been discussed this summer. Silly me forgot to check
the archives *before* changing and committing :-)


 I don't like the nomenclature we have in FOP 1.0 that much.
 fox:outline comes from the PDF specification's term for a
 bookmark, but the PDF spec calls it an outline item,
 and fox:bookmarks (parent level, holding all the outline
 items) IIRC is called a document outline in the PDF
 spec.  I guess fox:bookmarks (top-level), and fox:bookmark(child
 elements) might be better, but better enough to warran switching
 what we currently have?  I'm unsure.

Well, some consistency would indeed look prettier, i.e.
   fox:bookmarks / fox:bookmark
or fox:outlines / fox:outline
or (more verbose) fox:document-outline / fox:outline-item

But for now, I think I can live with it.

Greetz,

Andreas



Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-11-21 Thread Glen Mazza

- Original Message - 
From: Andreas L. Delmelle [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, November 14, 2004 2:58 PM
Subject: RE: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination
Root.java


  -Original Message-
  From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
 
 snip /
  Hope the use of the bookmarks extension wasn't meant to be
  changed in HEAD.

 Oops. Just noticed that a Bookmarks class has been added to the extensions
 package...


1.0's bookmarks are different from 0.20.5's, the former has fox:bookmarks as
the parent element.  It's been that way in 1.0 for a long time, before I
came on board I believe.


 What's going to be the prescribed usage pattern for it?
 Is it going to be:
 lt;fox:bookmark
   lt;fox:outline internal-destination=...
 lt;fox:label...lt;/fox:label
   ...
   lt;/fox-outline
 lt;/fox:bookmark

 Seems rather awkward, since one fox:bookmark can contain the whole set of
 bookmarks for the entire document (?)


I don't like the nomenclature we have in FOP 1.0 that much.  fox:outline
comes from the PDF specification's term for a bookmark, but the PDF spec
calls it an outline item, and fox:bookmarks (parent level, holding all the
outline items) IIRC is called a document outline in the PDF spec.  I guess
fox:bookmarks (top-level), and fox:bookmark(child elements) might be better,
but better enough to warran switching what we currently have?  I'm unsure.

Glen



RE: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-11-14 Thread Andreas L. Delmelle
 -Original Message-
 From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]

snip /
 Hope the use of the bookmarks extension wasn't meant to be
 changed in HEAD.

Oops. Just noticed that a Bookmarks class has been added to the extensions
package...

What's going to be the prescribed usage pattern for it?
Is it going to be:
lt;fox:bookmark
  lt;fox:outline internal-destination=...
lt;fox:label...lt;/fox:label
  ...
  lt;/fox-outline
lt;/fox:bookmark

Seems rather awkward, since one fox:bookmark can contain the whole set of
bookmarks for the entire document (?)

 If so, I'll revert to the original. Just got an error running some test
 files, hence the change...

Just yell if you want me to change (or DIY if you insist :-) )

Greetz,

Andreas



RE: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-11-14 Thread Andreas L. Delmelle
 -Original Message-
 From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]


Ignore this thread. Found the answer in the archives...

Sorry for the nuisance.

Greetz,

Andreas


Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-23 Thread Glen Mazza
I guess I'm the guilty one here--but I have the
tabbing option shut off in JEdit, I'll be more careful
(and test at home what is happening.)

Sorry/Thanks,
Glen


--- [EMAIL PROTECTED] wrote:

 jeremias2004/09/23 03:04:36
 
   Modified:src/java/org/apache/fop/area
 StorePagesModel.java
src/java/org/apache/fop/fo/pagination
 Root.java
   Log:
   Removed illegal tab characters. Please, guys, pay
 attention to your IDE settings! Checkstyle in
 Eclipse, for example, does a very good job of
 uncovering things like that.
   



Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-13 Thread Simon Pepping
On Tue, Sep 07, 2004 at 08:47:07PM +0200, Jeremias Maerki wrote:
 
 Question to everyone: We currently don't have a multi-threaded design
 like Peter West's approach. Can anyone think of a reason that all the
 FO-building and layouting process for one processing run may run within
 more than one thread? I don't think threre is one if the SAX event
 delivery is always within one thread (big if). If there isn't I believe
 we could make use of a ThreadLocal to put some shared data that will be
 easily accessible from all involved components. Initialize the
 ThreadLocal in startDocument() and clear it in endDocument(). I realize
 there's a certain risk involved but it could really shorten the access
 ways for shared data especially for the FO tree, if that's really a
 problem (I'd also like to know if it really is. Anyone?).

PageLayoutManager has a seed for multithreading; it implements
Runnable. The idea is to let each page sequence run in its own
thread. It has not been worked out. Using a ThreadLocal for
FOInputHandler would make this more difficult. This is not a typical
usage case for ThreadLocal as mentioned in the java documentation. I
do not find it an attractive idea.

Regards, Simon

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



Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-13 Thread Glen Mazza
--- Simon Pepping [EMAIL PROTECTED] wrote:
 
 PageLayoutManager has a seed for multithreading; it
 implements
 Runnable. The idea is to let each page sequence run
 in its own
 thread. It has not been worked out. 

I'm uncertain of its benefit (that which calls FOP
should do the multithreading, not FOP itself, no? 
e.g., a servlet generating 10 reports, one on each
thread, rather than have the servlet and FOP both
multithreading at the same time.)  I'm inclined to
have it removed, lest it turn into another distraction
from our work.  Anyway, if Xalan isn't
multithreading--and I don't believe they are--then I'm
unsure that we should be.

Glen



Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-12 Thread Finn Bock

A (farfetched) argument against ThreadLocals would be that they 
prevent one FOP processing run to occur recursively during another 
independent processing run. Like an extension element that itself 
will attempt to process another fo document.
[Glen]
I think that restriction is implicit in the XSL Recommendation, because 
fo:instream-foreign-object [1], has the requirement that its child be 
from a *non-XSL* namespace.  If the rec intended FO documents to be 
processed recursively, they wouldn't have had a non-XSL namespace 
requirement (i.e., why bother to require users to have a 
finn:fodocument that would just wrap fo:root/, if you can just use 
the latter tag directly?)  Indeed, this restriction could be an argument 
*for* using ThreadLocals.
No, not really.
ThreadLocals should be used for storing data that is local to each 
thread (thread singletons). They are not a way to introduce global 
variables which just so happens to work in tomcat.

regards,
finn



Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-12 Thread Glen Mazza
I reverted it to the original recursive method, this
appears to be the best compromise for everyone's
wishes.  

Glen

--- Finn Bock [EMAIL PROTECTED] wrote:

 
  A (farfetched) argument against ThreadLocals
 would be that they 
  prevent one FOP processing run to occur
 recursively during another 
  independent processing run. Like an extension
 element that itself 
  will attempt to process another fo document.
 
 [Glen]
 
  I think that restriction is implicit in the XSL
 Recommendation, because 
  fo:instream-foreign-object [1], has the
 requirement that its child be 
  from a *non-XSL* namespace.  If the rec intended
 FO documents to be 
  processed recursively, they wouldn't have had a
 non-XSL namespace 
  requirement (i.e., why bother to require users to
 have a 
  finn:fodocument that would just wrap fo:root/,
 if you can just use 
  the latter tag directly?)  Indeed, this
 restriction could be an argument 
  *for* using ThreadLocals.
 
 No, not really.
 
 ThreadLocals should be used for storing data that is
 local to each 
 thread (thread singletons). They are not a way to
 introduce global 
 variables which just so happens to work in tomcat.
 
 regards,
 finn
 
 
 



Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-11 Thread Glen Mazza
Jeremias Maerki wrote:
On 07.09.2004 21:11:09 Finn Bock wrote:
 

[Jeremias Maerki]
   

Question to everyone: We currently don't have a multi-threaded design
like Peter West's approach. Can anyone think of a reason that all the
FO-building and layouting process for one processing run may run within
more than one thread? I don't think threre is one if the SAX event
delivery is always within one thread (big if). If there isn't I believe
we could make use of a ThreadLocal to put some shared data that will be
easily accessible from all involved components. Initialize the
ThreadLocal in startDocument() and clear it in endDocument(). I realize
there's a certain risk involved but it could really shorten the access
ways for shared data especially for the FO tree, if that's really a
problem (I'd also like to know if it really is. Anyone?).
 

A (farfetched) argument against ThreadLocals would be that they prevent 
one FOP processing run to occur recursively during another independent 
processing run. Like an extension element that itself will attempt to 
process another fo document.
   

 

I think that restriction is implicit in the XSL Recommendation, because 
fo:instream-foreign-object [1], has the requirement that its child be 
from a *non-XSL* namespace.  If the rec intended FO documents to be 
processed recursively, they wouldn't have had a non-XSL namespace 
requirement (i.e., why bother to require users to have a 
finn:fodocument that would just wrap fo:root/, if you can just use 
the latter tag directly?)  Indeed, this restriction could be an argument 
*for* using ThreadLocals.

[1] 
http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo_instream-foreign-object

Good point, actually. IMO FOP should support rendering documents
snippets. One use case for this is an FO paragraph or two within SVG (FO
embedded in SVG embedded in FO). 

I don't think we should be encouraging that use case or developing in 
that direction.  Shouldn't the standard be to write your document using 
FO, and incorporate images using SVG as you need them?  Or, if the text 
handling capability of SVG is too primitive, to have subsequent versions 
of the SVG recommendation improve upon it, rather than have users move 
to the FO namespace within their SVG?

We *could* code to have FOP embed SVG embed FOP embed SVG over and over 
again, but I'm not sure it would buy the user anything over proper 
document planning as described above.

I also don't like the idea of snippets--non portable divergences from 
the XSL standard of having fo:root be the top of all FO documents.  We 
should not be encouraging users to starting their work with fo:blocks 
(it is only speculative what such FO's would mean absent their parents 
anyway.)  Let's wait until the XSL rec defines snippets first--they 
might do that someday, actually.

And what a coincidence: I've had a
discussion exactly today where we talked about rendering FO snippets to
EMF (Windows enhanced metafile format) for inclusion in a Win32-based
reporting engine.
 

I would see another application calling FOP, providing a default 
fo:root-based structure around the snippet that the user provides (say, 
an fo:block).  But asking FOP to process a snippet with nothing else is 
kind of like asking javac to compile a class snippet (say, just an if 
statement.).  Too much to ask--compilers and FO Processors both have 
grammars to follow.

My preference would be to explicit pass the shared data (in this case 
the FOEventHandler) to the classes that needs it. If the recursion Glen 
discovered is deemed too slow, then store the FOEventHandler in an 
instance field for each FONode.
   

My preference, too. But having too much in FONode will generate a lot
memory consumption. Just the logger instance in the maintenance branch
takes up a lot of memory. As long as we can keep such a reference to
count one I don't think this is such a big problem, however.
 


The ThreadLocal was just an intriguing idea but your comment already lets
me dismiss it. It's probably more trouble than it's worth.
Jeremias Maerki
 

I'm not sure I would mind ThreadLocal here.  According to [2], it is 
kind of fast, at least in 1.4.  That, or returning to the old recursion 
method, appear to me to be the best options.

[2] http://www-106.ibm.com/developerworks/java/library/j-threads3.html
A third option, which may also have nice benefits, is getting rid of 
startElement() and endElement() within the FO's, and doing that all in 
FOTreeBuilder.

Glen


Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-07 Thread Jeremias Maerki

On 07.09.2004 00:20:18 Glen Mazza wrote:
 Jeremias Maerki wrote:
 
 On 06.09.2004 22:31:24 Glen Mazza wrote:
   
 
 Jeremias Maerki wrote:

snip/
 What is an application in your terminology? I don't think there is such
 a thing in Java. At least it's not a technical term but only a logical
 one. If you deploy fop.jar using the boot classloader in Tomcat and
 deploy two applications (each using a separate classloader for each
 WAR file). Both webapps are using FOP in a different way, you still have
 only one static foEventHandler variable which is shared between two
 applications. That's probably a non-realistic approach for FOP, but
 Xerces and Xalan are usually deployed this way.
   
 
 OK, from what you're saying then, Xerces and Xalan should have no (or 
 next to no) static variables because they are so heavily shared (i.e., 
 stored in Tomcat /common or /shared directories).  Correct?

That's not the precise reason but you're on the right track. They don't
even have to be in the /common or /shared directories. Even if you put
Xalan in the WEB-INF/lib of your webapp (assume JDK 1.3, and assume
Xalan would make use of static variables to hold XSLT variables, which
it probably doesn't) you would run into problems because your Servlet
will be called within several threads simultaneously.

Not every static variable is bad. But if static variables are used to
communicate between components this will almost always leed to trouble
in my experience. As I said they are seductive because they are easy to
program with and you will probably get away with it if you're only
programming a GUI application, but as soon as you do server-side
programming this gets bad.

snip/

 Let me take a look at your two links first (Tomcat classloader and 
 ThreadLocal).   We'll get this reverted (to something) soon.

Fair enough. We've got time. I will try to dig up my multi-threading
testbed I wrote for FOP maintenance branch a couple of years ago when we
were tracking down multi-threading problems. It will need a bit of
adjustment for HEAD but I think it makes sense to put it somewhere in
the test directory so we can easily stress-test FOP.

Question to everyone: We currently don't have a multi-threaded design
like Peter West's approach. Can anyone think of a reason that all the
FO-building and layouting process for one processing run may run within
more than one thread? I don't think threre is one if the SAX event
delivery is always within one thread (big if). If there isn't I believe
we could make use of a ThreadLocal to put some shared data that will be
easily accessible from all involved components. Initialize the
ThreadLocal in startDocument() and clear it in endDocument(). I realize
there's a certain risk involved but it could really shorten the access
ways for shared data especially for the FO tree, if that's really a
problem (I'd also like to know if it really is. Anyone?).


Jeremias Maerki



Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-07 Thread Finn Bock
[Jeremias Maerki]
Question to everyone: We currently don't have a multi-threaded design
like Peter West's approach. Can anyone think of a reason that all the
FO-building and layouting process for one processing run may run within
more than one thread? I don't think threre is one if the SAX event
delivery is always within one thread (big if). If there isn't I believe
we could make use of a ThreadLocal to put some shared data that will be
easily accessible from all involved components. Initialize the
ThreadLocal in startDocument() and clear it in endDocument(). I realize
there's a certain risk involved but it could really shorten the access
ways for shared data especially for the FO tree, if that's really a
problem (I'd also like to know if it really is. Anyone?).
A (farfetched) argument against ThreadLocals would be that they prevent 
one FOP processing run to occur recursively during another independent 
processing run. Like an extension element that itself will attempt to 
process another fo document.

My preference would be to explicit pass the shared data (in this case 
the FOEventHandler) to the classes that needs it. If the recursion Glen 
discovered is deemed too slow, then store the FOEventHandler in an 
instance field for each FONode.

regards,
finn


Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-07 Thread Jeremias Maerki

On 07.09.2004 21:11:09 Finn Bock wrote:
 [Jeremias Maerki]
 
  Question to everyone: We currently don't have a multi-threaded design
  like Peter West's approach. Can anyone think of a reason that all the
  FO-building and layouting process for one processing run may run within
  more than one thread? I don't think threre is one if the SAX event
  delivery is always within one thread (big if). If there isn't I believe
  we could make use of a ThreadLocal to put some shared data that will be
  easily accessible from all involved components. Initialize the
  ThreadLocal in startDocument() and clear it in endDocument(). I realize
  there's a certain risk involved but it could really shorten the access
  ways for shared data especially for the FO tree, if that's really a
  problem (I'd also like to know if it really is. Anyone?).
 
 A (farfetched) argument against ThreadLocals would be that they prevent 
 one FOP processing run to occur recursively during another independent 
 processing run. Like an extension element that itself will attempt to 
 process another fo document.

Good point, actually. IMO FOP should support rendering documents
snippets. One use case for this is an FO paragraph or two within SVG (FO
embedded in SVG embedded in FO). And what a coincidence: I've had a
discussion exactly today where we talked about rendering FO snippets to
EMF (Windows enhanced metafile format) for inclusion in a Win32-based
reporting engine.

 My preference would be to explicit pass the shared data (in this case 
 the FOEventHandler) to the classes that needs it. If the recursion Glen 
 discovered is deemed too slow, then store the FOEventHandler in an 
 instance field for each FONode.

My preference, too. But having too much in FONode will generate a lot
memory consumption. Just the logger instance in the maintenance branch
takes up a lot of memory. As long as we can keep such a reference to
count one I don't think this is such a big problem, however.

The ThreadLocal was just an intriguing idea but your comment already lets
me dismiss it. It's probably more trouble than it's worth.


Jeremias Maerki



Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-07 Thread Finn Bock
My preference would be to explicit pass the shared data (in this case 
the FOEventHandler) to the classes that needs it. If the recursion Glen 
discovered is deemed too slow, then store the FOEventHandler in an 
instance field for each FONode.
[Jeremias]
My preference, too. But having too much in FONode will generate a lot
memory consumption. 
Then maybe we can select some specific node types that will carry an 
actual reference to the FOEventHandler. Like fo:root (obviously), 
fo:flow and fo:block and all other node type will reference their 
parent. We can then pick the right tradeoff between memory and CPU.

It's just a thought.
regards,
finn


Multi-threading testbed (was: Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java)

2004-09-07 Thread Jeremias Maerki
I've done that already. It wasn't so much work but I had to get rid of
the Avalon Fortress container first. It still uses the Avalon
Framework, though.

That's how it works: There's a sample configuration file in
test/java/org/apache/fop/threading that shows how to configure the MT
testbed. The filename to the configuration file is given to the Main
class as a command line parameter. The rest should be pretty easy to
manage. You can specify how many threads you want to run, which FO or
XML/XSLT combinations and how many times the tasks should be run until
the thread dies.

There's still a lot of room for improvements. I haven't bothered with
adjusting to the different configuration in HEAD, yet. It's just a small
tool for reproducing multi-threading problems.

And to cater for the curious: FOP really fails as soon as you run two
threads ATM.

Have fun.

On 07.09.2004 20:47:07 Jeremias Maerki wrote:
 I will try to dig up my multi-threading
 testbed I wrote for FOP maintenance branch a couple of years ago when we
 were tracking down multi-threading problems. It will need a bit of
 adjustment for HEAD but I think it makes sense to put it somewhere in
 the test directory so we can easily stress-test FOP.


Jeremias Maerki



Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-06 Thread Jeremias Maerki
I'm sorry, Glen, but I think you will have to revisit that one. If I'm
not absolutely wrong, this will break multi-threading capabilities.

On 06.09.2004 20:28:17 gmazza wrote:
 gmazza  2004/09/06 11:28:17
 
   Modified:src/java/org/apache/fop/fo FONode.java FOTreeBuilder.java
src/java/org/apache/fop/fo/pagination Root.java
   Log:
   Switched to a static FOInputHandler object for the FOTree instead of relying on 
 recursion to get to the FOInputHandler object stored at pagination.Root.


Jeremias Maerki



Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-06 Thread Glen Mazza
Please elaborate.
Jeremias Maerki wrote:
I'm sorry, Glen, but I think you will have to revisit that one. If I'm
not absolutely wrong, this will break multi-threading capabilities.
On 06.09.2004 20:28:17 gmazza wrote:
 

gmazza  2004/09/06 11:28:17
 Modified:src/java/org/apache/fop/fo FONode.java FOTreeBuilder.java
  src/java/org/apache/fop/fo/pagination Root.java
 Log:
 Switched to a static FOInputHandler object for the FOTree instead of relying on recursion to get to the FOInputHandler object stored at pagination.Root.
   


Jeremias Maerki
 




Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-06 Thread Jeremias Maerki
Ok, the FOEventHandler is created in the FOTreeBuilder. One FO
TreeBuilder is instantiated per processing run. The FOEventHandler is
set on FONode's static variable during startDocument(). The
FOEventHandler keeps track of used fonts, number of pages, tracking IDs
etc. which are all relevant to one document run.

Now imagine a situation where multiple processing runs occur and just
after the TreeBuilder sets the FOEventHandler on FONode in
startDocument() and continues layout, another thread starts another
processing run and runs through FOTreeBuilder.startDocument() before the
whole layout process of the first processing run is finished. The second
run will replace the FOEventHandler on FONode with a new one and the
first thread will suddenly work on a different FOEventHandler because
both threads access the same static variable. The behaviour will be
non-deterministic.

Statics are often handy and seductive but are very dangerous in a
multi-threaded environment. FOP is expected to work this way as many
mails on fop-user prove. Statics are fine for constants and mostly ok
for singletons and a few other opportunities, but I made it a rule for
myself to be very catious when I think about using a static variable. I
try to avoid them whenever possible.

On 06.09.2004 21:45:34 Glen Mazza wrote:
 Please elaborate.
 
 Jeremias Maerki wrote:
 
 I'm sorry, Glen, but I think you will have to revisit that one. If I'm
 not absolutely wrong, this will break multi-threading capabilities.
 
 On 06.09.2004 20:28:17 gmazza wrote:
   
 
 gmazza  2004/09/06 11:28:17
 
   Modified:src/java/org/apache/fop/fo FONode.java FOTreeBuilder.java
src/java/org/apache/fop/fo/pagination Root.java
   Log:
   Switched to a static FOInputHandler object for the FOTree instead of relying on 
  recursion to get to the FOInputHandler object stored at pagination.Root.



Jeremias Maerki



Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-06 Thread Jeremias Maerki
To be a bit more positive and not just criticizing, this could probably
be solved using a ThreadLocal [1] which would make the whole thing
almost as handy as a normal static variable but thread-safe. But I've
never done this myself, yet, so I can't talk out of experience. Just an
additional 0.05 CHF.

[1] http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ThreadLocal.html

On 06.09.2004 22:01:27 Jeremias Maerki wrote:
 Ok, the FOEventHandler is created in the FOTreeBuilder. One FO
 TreeBuilder is instantiated per processing run. The FOEventHandler is
 set on FONode's static variable during startDocument(). The
 FOEventHandler keeps track of used fonts, number of pages, tracking IDs
 etc. which are all relevant to one document run.
 
 Now imagine a situation where multiple processing runs occur and just
 after the TreeBuilder sets the FOEventHandler on FONode in
 startDocument() and continues layout, another thread starts another
 processing run and runs through FOTreeBuilder.startDocument() before the
 whole layout process of the first processing run is finished. The second
 run will replace the FOEventHandler on FONode with a new one and the
 first thread will suddenly work on a different FOEventHandler because
 both threads access the same static variable. The behaviour will be
 non-deterministic.
 
 Statics are often handy and seductive but are very dangerous in a
 multi-threaded environment. FOP is expected to work this way as many
 mails on fop-user prove. Statics are fine for constants and mostly ok
 for singletons and a few other opportunities, but I made it a rule for
 myself to be very catious when I think about using a static variable. I
 try to avoid them whenever possible.
 
 On 06.09.2004 21:45:34 Glen Mazza wrote:
  Please elaborate.
  
  Jeremias Maerki wrote:
  
  I'm sorry, Glen, but I think you will have to revisit that one. If I'm
  not absolutely wrong, this will break multi-threading capabilities.
  
  On 06.09.2004 20:28:17 gmazza wrote:

  
  gmazza  2004/09/06 11:28:17
  
Modified:src/java/org/apache/fop/fo FONode.java FOTreeBuilder.java
 src/java/org/apache/fop/fo/pagination Root.java
Log:
Switched to a static FOInputHandler object for the FOTree instead of relying 
   on recursion to get to the FOInputHandler object stored at pagination.Root.



Jeremias Maerki



Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-06 Thread Glen Mazza
Jeremias Maerki wrote:
Ok, the FOEventHandler is created in the FOTreeBuilder. One FO
TreeBuilder is instantiated per processing run. The FOEventHandler is
set on FONode's static variable during startDocument(). The
FOEventHandler keeps track of used fonts, number of pages, tracking IDs
etc. which are all relevant to one document run.
 

Incidentally, I'd like to get the fonts out of FOEventHandler, I think 
they should be declared only within those subclasses of FOEventHandler 
that need them.  But we can take up that issue later.

Now imagine a situation where multiple processing runs occur and just
after the TreeBuilder sets the FOEventHandler on FONode in
startDocument() and continues layout, another thread starts another
processing run and runs through FOTreeBuilder.startDocument() before the
whole layout process of the first processing run is finished. 

But that would be another instance of the application, so that would be 
another instance's FOEventHandler that would be altered.  Statics are 
common to a running instance, not all running instances of the same 
application in general.  Please continue to elaborate.

Also, are you aware of why I switched to a static?  To end the 
continuous recursion to the fo:root each time any of the child nodes 
need to call getFOEventHandler().startThisFormattingObject() and/or 
getFOEventHandler().endSomeFormattingObject().

Glen


Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-06 Thread Jeremias Maerki

On 06.09.2004 22:31:24 Glen Mazza wrote:
 Jeremias Maerki wrote:
 
 Ok, the FOEventHandler is created in the FOTreeBuilder. One FO
 TreeBuilder is instantiated per processing run. The FOEventHandler is
 set on FONode's static variable during startDocument(). The
 FOEventHandler keeps track of used fonts, number of pages, tracking IDs
 etc. which are all relevant to one document run.
   
 
 Incidentally, I'd like to get the fonts out of FOEventHandler, I think 
 they should be declared only within those subclasses of FOEventHandler 
 that need them.  But we can take up that issue later.

Here you need to be more precise. Are you talking about the set of
available fonts or the set of used fonts within the document/processing
run? The former is not a problem in this matter, but the other is as are
the other examples I mentioned. They are specific to the rendering run.

 Now imagine a situation where multiple processing runs occur and just
 after the TreeBuilder sets the FOEventHandler on FONode in
 startDocument() and continues layout, another thread starts another
 processing run and runs through FOTreeBuilder.startDocument() before the
 whole layout process of the first processing run is finished. 
 
 But that would be another instance of the application, so that would be 
 another instance's FOEventHandler that would be altered.  Statics are 
 common to a running instance, not all running instances of the same 
 application in general.  Please continue to elaborate.

A static variable is unique within the same classloader. If you deploy
FOP as a servlet there is one classloader loading the FOP classes and
FONode's static foEventHandler variable is shared between all instances
of the Fop class and therefore between rendering runs. Now Tomcat can
initiate multiple FOP rendering runs in multiple threads and that's
where the trouble begins.

What is an application in your terminology? I don't think there is such
a thing in Java. At least it's not a technical term but only a logical
one. If you deploy fop.jar using the boot classloader in Tomcat and
deploy two applications (each using a separate classloader for each
WAR file). Both webapps are using FOP in a different way, you still have
only one static foEventHandler variable which is shared between two
applications. That's probably a non-realistic approach for FOP, but
Xerces and Xalan are usually deployed this way.

A figure showing Tomcat's classloader hierarchy:
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html

I think in your view of the things you'd have to provide a classloader
for each instance of Fop to they don't bump into each other, but that's
not what you will want.

 Also, are you aware of why I switched to a static?  To end the 
 continuous recursion to the fo:root each time any of the child nodes 
 need to call getFOEventHandler().startThisFormattingObject() and/or 
 getFOEventHandler().endSomeFormattingObject().

Yes, I realize that. That's why I proposed looking at ThreadLocal after
thinking some more about the problem. On the other side have you done
speed checks to figure out if the recursion is really a problem? Java
can optimize pretty well by itself and often it's not worth
breaking your head. Also something I learned on this list.


Jeremias Maerki (off to bed...)



Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-06 Thread Glen Mazza
Jeremias Maerki wrote:
On 06.09.2004 22:31:24 Glen Mazza wrote:
 

Jeremias Maerki wrote:
   

Ok, the FOEventHandler is created in the FOTreeBuilder. One FO
TreeBuilder is instantiated per processing run. The FOEventHandler is
set on FONode's static variable during startDocument(). The
FOEventHandler keeps track of used fonts, number of pages, tracking IDs
etc. which are all relevant to one document run.
 

Incidentally, I'd like to get the fonts out of FOEventHandler, I think 
they should be declared only within those subclasses of FOEventHandler 
that need them.  But we can take up that issue later.
   

Here you need to be more precise. Are you talking about the set of
available fonts or the set of used fonts within the document/processing
run? The former is not a problem in this matter, but the other is as are
the other examples I mentioned. They are specific to the rendering run.
 

Let's leave this for now.  My thoughts on it aren't complete anyway.
Now imagine a situation where multiple processing runs occur and just
after the TreeBuilder sets the FOEventHandler on FONode in
startDocument() and continues layout, another thread starts another
processing run and runs through FOTreeBuilder.startDocument() before the
whole layout process of the first processing run is finished. 

 

But that would be another instance of the application, so that would be 
another instance's FOEventHandler that would be altered.  Statics are 
common to a running instance, not all running instances of the same 
application in general.  Please continue to elaborate.
   

A static variable is unique within the same classloader. If you deploy
FOP as a servlet there is one classloader loading the FOP classes and
FONode's static foEventHandler variable is shared between all instances
of the Fop class and therefore between rendering runs. Now Tomcat can
initiate multiple FOP rendering runs in multiple threads and that's
where the trouble begins.
 

I see now.  This would indeed be a problem--we will probably need to 
revert my change.

What is an application in your terminology? I don't think there is such
a thing in Java. At least it's not a technical term but only a logical
one. If you deploy fop.jar using the boot classloader in Tomcat and
deploy two applications (each using a separate classloader for each
WAR file). Both webapps are using FOP in a different way, you still have
only one static foEventHandler variable which is shared between two
applications. That's probably a non-realistic approach for FOP, but
Xerces and Xalan are usually deployed this way.
 

OK, from what you're saying then, Xerces and Xalan should have no (or 
next to no) static variables because they are so heavily shared (i.e., 
stored in Tomcat /common or /shared directories).  Correct?

A figure showing Tomcat's classloader hierarchy:
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html
I think in your view of the things you'd have to provide a classloader
for each instance of Fop to they don't bump into each other, but that's
not what you will want.
 

I agree--that would not be desirable.
 

Also, are you aware of why I switched to a static?  To end the 
continuous recursion to the fo:root each time any of the child nodes 
need to call getFOEventHandler().startThisFormattingObject() and/or 
getFOEventHandler().endSomeFormattingObject().
   

Yes, I realize that. That's why I proposed looking at ThreadLocal after
thinking some more about the problem. On the other side have you done
speed checks to figure out if the recursion is really a problem? Java
can optimize pretty well by itself and often it's not worth
breaking your head. Also something I learned on this list.
 

Let me take a look at your two links first (Tomcat classloader and 
ThreadLocal).   We'll get this reverted (to something) soon.

Jeremias Maerki (off to bed...)
 

At only 6pm?  ;-)  Anyway, thanks for the education today.
Glen