sboag       01/01/09 14:41:39

  Modified:    java/src/org/apache/xalan/transformer TransformerImpl.java
  Log:
  At least for now, I commented out the m_reportInPostExceptionFromThread stuff 
altogether.  I'm a little worried that this could cause problems with 
diagnostics from piped transforms, but hopefully the call to setExceptionThrown 
to the input handler should cover this.  In any case, the setting of 
m_reportInPostExceptionFromThread seemed pretty funky to me.
  Response to note sent by Nicola Brown <[EMAIL PROTECTED]>
  01/08/2001 08:36 AM
  
  =====
  Get the transformer thread via createTransformerThread.  From email
  on this subject:
  
  In response to this I've created the following method in 
org.apache.xalan.TransformerImpl:
  
    /**
     * Create a thread for the transform.  This can be overridden by derived
     * implementations to provide their own thread, for thread pooling and the
     * like.
     *
     * @return thread suitable to use for the transformation.
     */
    public Thread createTransformThread()
    {
      return new Thread(this);
    }
  
  Someone who is using XalanJ2 in an EJB environment or the like can set the 
javax.xml.transform.TransformerFactory system property to provide a derivation 
from TransformerImpl, and provide a thread suitable for the environment.
  
  I don't know if this will do the trick.  Please advise.
  
  -scott
  
        "Roytman, Alex" <[EMAIL PROTECTED]> 01/07/2001 12:14 AM Please respond 
to xalan-dev        To: "'[email protected]'" <[email protected]> 
 cc: "'[email protected]'" <[email protected]>, (bcc: 
Scott Boag/CAM/Lotus)  Subject: Xalan2 in server environment (was Xalan2 Stree 
Module spans sec ond thread to do transform?)
  
  Scott,
  Thank you very much for your reply.
  One part which is sensitive to thread origin in my opinion is Extensions
  In extensions people can do all sorts of things. I am not very experienced
  with EJB implementation but I can imagine that many things (transactional
  context, bean environment, etc.) depend on threads and some static variables
  which helps with setting /switching context for beans being managed by the
  server.
  
  Example: in J2EE it is recommended to create JNDI initial context using
  default constructor InitialContext(). The result of the instantiation
  depends on the context where it was executed and the context is set by the
  server for the thread on which your component is running. So if you call new
  InitialContext() in your extension (in sql extension to get JDBC DataSource
  for example ) it might fail.
  
  Do extension run on the second (created by Xalan) thread?
  
  I will forward your message to Tomcat news group lets see what Tomcat
  developers think.
  
  Alex
  
  -----Original Message-----
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
  Sent: Saturday, January 06, 2001 11:39 PM
  To: [email protected]
  Subject: Re: Xalan2 Stree Module spans second thread to do transform?
  
  > In many
  > cases component should not attempt to create its own threads.
  > For example thread's ContextClassLoader or ThreadLocal variables might
  need
  > to be initialized by the server.
  > Also it defeats thread pooling done by the server etc.
  >
  > Could you please comment on this issue
  
  Yeah, I've been a bit worried about this.  However, I've not yet heard of
  any problems that have been caused by it, and XalanJ1 has long had a two
  threaded system (though not as effective as in XalanJ2).   Ultimately, I
  would rather use a pull model for this, and only have one thread, but a)
  there is no standard "pull" API for XML parsers, and b) this doesn't work
  anyway when SAX events are used, for whatever reason.
  
  I'm open to any input to how Xalan might request the thread from the
  servlet environment, though it has to be able to be run outside a servlet
  environment too.  Also, it would be good if someone with deep knowledge of
  EJB's and the like could comment.  I talked this over in a hallway
  conversation with someone who is fairly familiar with EJB's, and he didn't
  think there was a problem, though I forget why.  It seems insane/crazy to
  me that a component can't use a thread in it's internal modules.
  
  -scott
  
                      "Roytman,
  
                      Alex"                 To:
  "'[email protected]'" <[email protected]>
                      <[EMAIL PROTECTED]        cc:     (bcc: Scott
  Boag/CAM/Lotus)
                      etech.com>            Subject:     Xalan2 Stree Module
  spans second thread to do transform?
  
                      01/06/2001
  
                      10:48 PM
                      Please respond
  
                      to xalan-dev
  
  Dear Xalan developers,
  I have a question about using upcoming Xalan2 in server env.
  
  In Xalan2 design specs it is said:
  
  "The Stree module implements the default Source Tree for Xalan, that is to
  be transformed. It implements read-only DOM2 interfaces, and provides some
  information needed for fast transforms, such as document order indexes. It
  also attempts to allow a streaming transform by launching the transform on
  a
  secondary thread as soon as the SAX2 StartDocument event has occurred."
  
  In server environment server usually controls threads creation. In many
  cases component should not attempt to create its own threads.
  For example thread's ContextClassLoader or ThreadLocal variables might need
  to be initialized by the server.
  Also it defeats thread pooling done by the server etc.
  
  Could you please comment on this issue
  
  Thank you very much in advance
  
  Alex Roytman
  
  Revision  Changes    Path
  1.73      +32 -17    
xml-xalan/java/src/org/apache/xalan/transformer/TransformerImpl.java
  
  Index: TransformerImpl.java
  ===================================================================
  RCS file: 
/home/cvs/xml-xalan/java/src/org/apache/xalan/transformer/TransformerImpl.java,v
  retrieving revision 1.72
  retrieving revision 1.73
  diff -u -r1.72 -r1.73
  --- TransformerImpl.java      2001/01/09 18:14:42     1.72
  +++ TransformerImpl.java      2001/01/09 22:41:38     1.73
  @@ -231,15 +231,17 @@
       m_textformat = new OutputProperties(Method.Text);
     }
     
  -  /**
  -   * Flag to let us know if an exception should be reported inside the 
  -   * postExceptionFromThread method.  This is needed if the transform is 
  -   * being generated from SAX events, and thus there is no central place 
  -   * to report the exception from.  (An exception is usually picked up in 
  -   * the main thread from the transform thread in [EMAIL PROTECTED] 
#transform(Source source)} 
  -   * from [EMAIL PROTECTED] #getExceptionThrown()}. )
  -   */
  -  private boolean m_reportInPostExceptionFromThread = true;
  +  // Commenteded out in response to problem reported by 
  +  // Nicola Brown <[EMAIL PROTECTED]>
  +//  /**
  +//   * Flag to let us know if an exception should be reported inside the 
  +//   * postExceptionFromThread method.  This is needed if the transform is 
  +//   * being generated from SAX events, and thus there is no central place 
  +//   * to report the exception from.  (An exception is usually picked up in 
  +//   * the main thread from the transform thread in [EMAIL PROTECTED] 
#transform(Source source)} 
  +//   * from [EMAIL PROTECTED] #getExceptionThrown()}. )
  +//   */
  +//  private boolean m_reportInPostExceptionFromThread = false;
     
     /** A node vector used as a stack to track the current 
      * ElemTemplateElement.  Needed for the 
  @@ -393,7 +395,7 @@
       // For now, reset the document cache each time.
       getXPathContext().getSourceTreeManager().reset();
       
  -    m_reportInPostExceptionFromThread = false;
  +//    m_reportInPostExceptionFromThread = false;
     }
   
     // ========= Transformer Interface Implementation ==========
  @@ -574,8 +576,8 @@
             }
             else
             {
  -            Thread t = new Thread(this);
  -            m_reportInPostExceptionFromThread = true;
  +            Thread t = createTransformThread();
  +//            m_reportInPostExceptionFromThread = false;
               t.start();
               transformNode(doc);
             }
  @@ -2697,6 +2699,18 @@
     ////////////////////////
     // Implement Runnable //  
     ////////////////////////
  +  
  +  /**
  +   * Create a thread for the transform.  This can be overridden by derived 
  +   * implementations to provide their own thread, for thread pooling and the 
  +   * like.
  +   * 
  +   * @return thread suitable to use for the transformation.
  +   */
  +  public Thread createTransformThread()
  +  {
  +    return new Thread(this);
  +  }
   
     /**
      * Get the exception thrown by the secondary thread (normally 
  @@ -2740,11 +2754,12 @@
      */
     void postExceptionFromThread(Exception e)
     {
  -    if(m_reportInPostExceptionFromThread)
  -    {
  -      // Consider re-throwing the exception if this flag is set.
  -      e.printStackTrace();
  -    }
  +    // Commented out in response to problem reported by Nicola Brown <[EMAIL 
PROTECTED]>
  +//    if(m_reportInPostExceptionFromThread)
  +//    {
  +//      // Consider re-throwing the exception if this flag is set.
  +//      e.printStackTrace();
  +//    }
         
       if (m_inputContentHandler instanceof SourceTreeHandler)
       {
  
  
  

Reply via email to