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 > > >
