RE: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java
-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
- 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
FW: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Hi, Modified:src/java/org/apache/fop/fo/pagination Root.java Log: changed 'bookmarks' to 'outline' to avoid ValidateException for bookmarks extension Hope the use of the bookmarks extension wasn't meant to be changed in HEAD. If so, I'll revert to the original. Just got an error running some test files, hence the change... Greetz, Andreas
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... 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
-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
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
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
--- 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
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
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
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
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
[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
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
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)
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
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
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
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
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
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
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
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
cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java
vmote 2003/08/15 23:43:51
Modified:src/java/org/apache/fop/apps Driver.java
src/java/org/apache/fop/fo FONode.java FOTreeBuilder.java
FObjMixed.java PropertyManager.java XMLObj.java
src/java/org/apache/fop/fo/flow InstreamForeignObject.java
src/java/org/apache/fop/fo/pagination Root.java
Log:
1. tie Document to fo.FOTreeBuilder and fo.pagination.Root
2. add getDocument() method to FONode (using this.parent for all nodes except Root)
3. start using getDocument() to gain access to font collections stored in Document
Revision ChangesPath
1.26 +1 -0 xml-fop/src/java/org/apache/fop/apps/Driver.java
Index: Driver.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/apps/Driver.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- Driver.java 15 Aug 2003 20:37:51 - 1.25
+++ Driver.java 16 Aug 2003 06:43:50 - 1.26
@@ -601,6 +601,7 @@
if (foInputHandler instanceof FOTreeHandler) {
currentDocument.setLayoutStrategy(new LayoutManagerLS());
}
+treeBuilder.document = currentDocument;
try {
if (foInputHandler instanceof FOTreeHandler) {
FOTreeHandler foTreeHandler = (FOTreeHandler)foInputHandler;
1.6 +6 -0 xml-fop/src/java/org/apache/fop/fo/FONode.java
Index: FONode.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FONode.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- FONode.java 29 Jul 2003 18:42:31 - 1.5
+++ FONode.java 16 Aug 2003 06:43:51 - 1.6
@@ -61,6 +61,7 @@
// FOP
import org.apache.fop.apps.FOPException;
+import org.apache.fop.control.Document;
import org.apache.fop.util.CharUtilities;
/**
@@ -209,5 +210,10 @@
protected boolean isMarker() {
return false;
}
+
+public Document getDocument() {
+return parent.getDocument();
+}
+
}
1.10 +7 -2 xml-fop/src/java/org/apache/fop/fo/FOTreeBuilder.java
Index: FOTreeBuilder.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FOTreeBuilder.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- FOTreeBuilder.java29 Jul 2003 19:33:29 - 1.9
+++ FOTreeBuilder.java16 Aug 2003 06:43:51 - 1.10
@@ -54,6 +54,8 @@
import java.util.HashMap;
import java.util.Map;
import java.util.Set;
+import org.apache.fop.control.Document;
+import org.apache.fop.fo.pagination.Root;
// SAX
import org.apache.avalon.framework.logger.Logger;
@@ -110,7 +112,7 @@
/**
* The root of the formatting object tree
*/
-protected FONode rootFObj = null;
+protected Root rootFObj = null;
/**
* The class that handles formatting and rendering to a stream
@@ -120,6 +122,8 @@
private FOUserAgent userAgent;
+public Document document;
+
/**
* Default constructor
*/
@@ -290,7 +294,8 @@
+ be fo:root, not
+ fobj.getName()));
}
-rootFObj = fobj;
+rootFObj = (Root)fobj;
+rootFObj.setDocument(document);
} else {
currentFObj.addChild(fobj);
}
1.7 +2 -2 xml-fop/src/java/org/apache/fop/fo/FObjMixed.java
Index: FObjMixed.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FObjMixed.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- FObjMixed.java14 Aug 2003 07:42:58 - 1.6
+++ FObjMixed.java16 Aug 2003 06:43:51 - 1.7
@@ -104,8 +104,8 @@
if (textInfo == null) {
// Really only need one of these, but need to get fontInfo
// stored in propMgr for later use.
-propMgr.setFontInfo(fontInfo);
-textInfo = propMgr.getTextLayoutProps(fontInfo);
+propMgr.setFontInfo(getDocument());
+textInfo = propMgr.getTextLayoutProps(getDocument());
}
FOText ft = new FOText(data, start, length, textInfo, this);
1.7 +16 -16xml-fop/src/java/org/apache/fop/fo/PropertyManager.java
Index: PropertyManager.java
===
RCS file:
cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java
pietsch 2003/06/26 17:16:28 Modified:src/java/org/apache/fop/fo/pagination Root.java Log: Test commit from Eclipse: removed unused import. Revision ChangesPath 1.3 +3 -5 xml-fop/src/java/org/apache/fop/fo/pagination/Root.java Index: Root.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/pagination/Root.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- Root.java 25 Mar 2003 23:34:11 - 1.2 +++ Root.java 27 Jun 2003 00:16:28 - 1.3 @@ -51,12 +51,10 @@ package org.apache.fop.fo.pagination; // FOP -import org.apache.fop.fo.FObj; -import org.apache.fop.fo.FONode; -import org.apache.fop.fo.FOText; - -// Java import java.util.List; + +import org.apache.fop.fo.FONode; +import org.apache.fop.fo.FObj; /** * The fo:root formatting object. Contains page masters, page-sequences. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java
vmote 2003/03/25 15:34:11 Modified:src/codegen foproperties.xml src/java/org/apache/fop/fo FOText.java FObjMixed.java PropertyManager.java TextInfo.java src/java/org/apache/fop/fo/pagination Root.java Log: Add support for text-transform. Revision ChangesPath 1.37 +7 -1 xml-fop/src/codegen/foproperties.xml Index: foproperties.xml === RCS file: /home/cvs/xml-fop/src/codegen/foproperties.xml,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- foproperties.xml 29 Nov 2002 23:18:51 - 1.36 +++ foproperties.xml 25 Mar 2003 23:34:10 - 1.37 @@ -1277,7 +1277,13 @@ property nametext-transform/name inheritedtrue/inherited -datatypeToBeImplemented/datatype +datatypeEnum/datatype +enumeration + value const=NONEnone/value + value const=CAPITALIZEcapitalize/value + value const=UPPERCASEuppercase/value + value const=LOWERCASElowercase/value +/enumeration defaultnone/default /property property 1.2 +323 -17 xml-fop/src/java/org/apache/fop/fo/FOText.java Index: FOText.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FOText.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- FOText.java 11 Mar 2003 13:05:19 - 1.1 +++ FOText.java 25 Mar 2003 23:34:11 - 1.2 @@ -3,34 +3,34 @@ * *The Apache Software License, Version 1.1 * - * + * * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved. - * + * * Redistribution and use in source and binary forms, with or without modifica- * tion, are permitted provided that the following conditions are met: - * + * * 1. Redistributions of source code must retain the above copyright notice, *this list of conditions and the following disclaimer. - * + * * 2. Redistributions in binary form must reproduce the above copyright notice, *this list of conditions and the following disclaimer in the documentation *and/or other materials provided with the distribution. - * + * * 3. The end-user documentation included with the redistribution, if any, must *include the following acknowledgment: This product includes software *developed by the Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowledgment may appear in the software itself, if *and wherever such third-party acknowledgments normally appear. - * + * * 4. The names FOP and Apache Software Foundation must not be used to *endorse or promote products derived from this software without prior *written permission. For written permission, please contact *[EMAIL PROTECTED] - * + * * 5. Products derived from this software may not be called Apache, nor may *Apache appear in their name, without prior written permission of the *Apache Software Foundation. - * + * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE @@ -42,12 +42,12 @@ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * - * + * * This software consists of voluntary contributions made by many individuals * on behalf of the Apache Software Foundation and was originally created by * James Tauber [EMAIL PROTECTED]. For more information on the Apache * Software Foundation, please see http://www.apache.org/. - */ + */ package org.apache.fop.fo; // Java @@ -60,15 +60,20 @@ import org.apache.fop.layoutmgr.TextLayoutManager; import org.apache.fop.apps.StructureHandler; import org.apache.fop.fo.properties.WhiteSpaceCollapse; +import org.apache.fop.fo.flow.Block; +import org.apache.fop.fo.pagination.Root; +import org.apache.fop.fo.properties.TextTransform; /** * A text node in the formatting object tree. * - * Modified by Mark Lillywhite, [EMAIL PROTECTED] * Unfortunately the BufferManager implementatation holds * onto references to the character data in this object * longer than the lifetime of the object itself, causing * excessive memory consumption and OOM errors. + * + *
