[Bug 1119] New - New thread created by Transformer causes problem in Servlet Container

[bu...@apache.org]

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1119

*** shadow/1119	Mon Mar 26 12:15:14 2001
--- shadow/1119.tmp.14971	Mon Mar 26 12:15:14 2001
***************
*** 0 ****
--- 1,65 ----
+ +============================================================================+
+ | New thread created by Transformer causes problem in Servlet Container      |
+ +----------------------------------------------------------------------------+
+ |        Bug #: 1119                        Product: XalanJ2                 |
+ |       Status: NEW                         Version: 2.0.1                   |
+ |   Resolution:                            Platform: PC                      |
+ |     Severity: Enhancement              OS/Version: Windows NT/2K           |
+ |     Priority:                           Component: org.apache.xalan.transf |
+ +----------------------------------------------------------------------------+
+ |  Assigned To: xalan-dev@xml.apache.org                                     |
+ |  Reported By: czhao@commonvision.com                                       |
+ |      CC list: Cc:                                                          |
+ +----------------------------------------------------------------------------+
+ |          URL:                                                              |
+ +============================================================================+
+ |                              DESCRIPTION                                   |
+ To support incremental output, Xalan-Java performs the transformation in a 
+ second thread while building the source tree in the main thread.  The output is 
+ written by the second thread.  This causes problem in some servlet containers.
+ 
+ In Weblogic 6.0 with Service Pack 1, when I do the following inside a servlet:
+ 
+         transformer.transform(new StreamSource(...), new StreamResult
+ (response.getWriter()));
+ 
+ I get the exception:
+ 
+ 	java.lang.ClassCastException: java.lang.Thread
+ 
+ What happens is that at the end of the transformation xalan will call flush() 
+ on the Writer and cause the underlying ServletOutputStream to flush. (See bug 
+ 1083.  Even if the bug is fixed, the xml output still can fill up the buffer of 
+ the ServletOutputStream and cause it to flush).  Before flushing the 
+ ServletOutputStream Weblogic needs to write out the HTTP headers first, so it 
+ needs to get the value for the date header.  Weblogic assumes the thread is 
+ Weblogic's internal ExecuteThread and tries to cast the thread as such, in 
+ order to get the date from it.  But the thread is a plain java.lang.Thread 
+ created by xalan, thus we get the java.lang.ClassCastException: java.lang.Thread
+ 
+ I do not consider this problem a weblogic bug, since the servlet container has 
+ the right to expect any thread inside it to be its own.  Serlvet 2.2 spec says:
+ 
+ 1.2 What is a Servlet Container?
+ ...
+ A Servlet Container may place security restrictions on the environment that a 
+ servlet executes in. In
+ a Java 2 Platform Standard Edition 1.2 (J2SE) or Java 2 Platform Enterprise 
+ Edition 1.2 (J2EE)
+ environment, these restrictions should be placed using the permission 
+ architecture defined by Java 2
+ Platform. For example, high end application servers may limit certain action, 
+ such as the creation of
+ a Thread object, to insure that other components of the container are not 
+ negatively impacted.
+ 
+ I would suggest Xalan to consider the following two enhancements:
+ 
+ 1. Give the user option to swap the two threads, i.e. build the source tree in 
+ a second thread but perform the transformation in the main thread.  In this 
+ way, the thread assigned by the servlet container is used to interact with the 
+ servlet container and write output, so there will be no problem.
+ 
+ 2. Give the user option to use only one thread.  In this way we sacrifice the 
+ incremental output, but we gain greater usability.  If I want to use xalan code 
+ inside an EJB container, creating a second thread is prohibited by the spec.