Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/properties PositionShorthandParser.java
Hi Finn, good to see you working on FOP. One request, though: This code seems to be new. If this is true, please change the copyright year to "2004" only. Thx. On 07.09.2004 14:38:13 bckfnn wrote: > bckfnn 2004/09/07 05:38:13 > > Added: src/java/org/apache/fop/fo/properties > PositionShorthandParser.java > Log: > Initial version of a shorthand parser for the 'position' property. > > Revision ChangesPath > 1.1 > xml-fop/src/java/org/apache/fop/fo/properties/PositionShorthandParser.java > > Index: PositionShorthandParser.java > === > /* >* Copyright 1999-2004 The Apache Software Foundation. Jeremias Maerki
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: > >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. > 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
