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
