"Roytman, Alex" <[EMAIL PROTECTED]> wrote:
> One part which is sensitive to thread origin in my opinion is Extensions
> In extensions people can do all sorts of things.
Yep, I can see that. It sounds like we should at least provide a property
to turn off the threading, which we should probably do in any case. I'm
not sure I can do this in time for our upcoming 2.0 release, as it feels a
little destabilizing, but let me sleep on it.
The best solution for this is to have some sort of discoverable interface
for Xalan to create threads with. You would think that the EJB stuff could
somehow override thread construction globally, so this stuff would all be
hidden. But I'm sure there are good reasons it can not.
> Do extension run on the second (created by Xalan) thread?
Yes. The main thread is the parser event thread. The second thread, which
I call the transform thread, performs the transformation, executing
extensions as it goes, and sends parse events to the Result interface,
which is probably a serializer. If the main thread finishes before the
transform thread, it 'joins' with the transform thread. If you chain
several Transformers or XMLReaders together you get another thread for each
pipe. This is good and bad, since the number of threads increases, but the
pipeline tends to keep moving along... pipe number three can be getting
bytes to the wire while pipe number 1 is just getting started.
The transform thread's run method is to be found in
org.apache.xalan.transformer.TransformerImpl#run(), and the thread is
created in org.apache.xalan.stree.SourceTreeHandler#startDocument(), and
does the join in org.apache.xalan.stree.SourceTreeHandler#endDocument().
If you are using a DOM as the source, you are not running the second
thread... this only happens when Xalan can create it's own source tree.
-scott
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
