Return-Path: Delivered-To: apmail-avalon-dev-archive@avalon.apache.org Received: (qmail 54555 invoked by uid 500); 23 May 2003 00:31:46 -0000 Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list dev@avalon.apache.org Received: (qmail 54531 invoked from network); 23 May 2003 00:31:45 -0000 Received: from out005pub.verizon.net (HELO out005.verizon.net) (206.46.170.143) by daedalus.apache.org with SMTP; 23 May 2003 00:31:45 -0000 Received: from verizon.net ([141.156.213.191]) by out005.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030523003153.PAGW25152.out005.verizon.net@verizon.net>; Thu, 22 May 2003 19:31:53 -0500 Message-ID: <3ECD6BF7.40703@verizon.net> Date: Thu, 22 May 2003 20:31:51 -0400 From: Vadim Gritsenko User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@avalon.apache.org CC: cocoon-dev@xml.apache.org Subject: [PATCH] Re: Problems with org.apache.excalibur.xml.xslt.XSLTProcessorImpl References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------070509000004080802040607" X-Authentication-Info: Submitted using SMTP AUTH at out005.verizon.net from [141.156.213.191] at Thu, 22 May 2003 19:31:53 -0500 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --------------070509000004080802040607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear Avaloners: Please take a second to look at/apply the supplied patch. It's short and pretty straightforward. Volker: volker.schmitt@basf-it-services.com wrote: >Hi, > >I found out a problem using >"org.apache.excalibur.xml.xslt.XSLTProcessorImpl". > >If use-store is true the stylesheet template is cached inside the store and >reused for the next transformation. The problem is, that the template and >the factory hold a reference to the URIResolver which is the >XSLTProcessorImpl itself. >Is the URIResolver only used while creating the template? > No, it's used to resolve xsl:import and document() too. >If yes the >current implementation works but we should set the URIResolver to null >after the template is created. > URIResolver is set to Transformer created on base of Templates, and not to Templates, see line 330 [1] >If no, we may be use an URIResolver >(XSLTProcessorImpl) which is already recycled and an other problem is that >the resolve method isn't ThreadSafe. > This can be fixed by adding setURIResolver() (as it is done in line 330) between lines 614-615 (patch attached) >This is an problem because the same >template is used from multible threads. > No, it's not. Templates is thread-safe object: "Templates must be threadsafe for a given instance over multiple threads running concurrently, and may be used multiple times in a given session." [2] >In Cocoon the template is automatic put into an persistent store if the >memory store is full. The XSLTProcessorImpl is not serializable which ends >in an java.io.NotSerializableException. I think it doesn't make sense to >store an XSLT-Template into an persistent store ? > > Vadim [1] http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/xmlutil/src/java/org/apache/excalibur/xml/xslt/XSLTProcessorImpl.java?annotate=1.31 [2] http://xml.apache.org/xalan-j/apidocs/javax/xml/transform/Templates.html >I also propose to make the Validity check configurable, this will improve >performance in productiv environments. > >Volker > --------------070509000004080802040607 Content-Type: text/plain; name="XSLTProcessorImpl.java.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="XSLTProcessorImpl.java.diff" Index: xmlutil/src/java/org/apache/excalibur/xml/xslt/XSLTProcessorImpl.java =================================================================== RCS file: /home/cvspublic/avalon-excalibur/xmlutil/src/java/org/apache/excalibur/xml/xslt/XSLTProcessorImpl.java,v retrieving revision 1.31 diff -u -r1.31 XSLTProcessorImpl.java --- xmlutil/src/java/org/apache/excalibur/xml/xslt/XSLTProcessorImpl.java 24 Apr 2003 12:39:15 -0000 1.31 +++ xmlutil/src/java/org/apache/excalibur/xml/xslt/XSLTProcessorImpl.java 23 May 2003 00:20:54 -0000 @@ -327,7 +327,7 @@ // Create transformer handler final TransformerHandler handler = m_factory.newTransformerHandler( template ); handler.getTransformer().setErrorListener( m_errorHandler ); - handler.getTransformer().setURIResolver( this ); + handler.getTransformer().setURIResolver( this ); // Create aggregated validity AggregatedValidity aggregated = null; @@ -612,6 +612,7 @@ TransformerHandler handler = m_factory.newTransformerHandler( (Templates)templateAndValidityAndIncludes[ 0 ] ); handler.getTransformer().setErrorListener( m_errorHandler ); + handler.getTransformer().setURIResolver( this ); return new TransformerHandlerAndValidity( handler, aggregated ); } --------------070509000004080802040607 Content-Type: text/plain; charset=us-ascii --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org For additional commands, e-mail: dev-help@avalon.apache.org --------------070509000004080802040607--