From cocoon-dev-return-12168-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org Wed Apr 04 19:28:27 2001 Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 10034 invoked by uid 500); 4 Apr 2001 19:28:23 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 10023 invoked from network); 4 Apr 2001 19:28:21 -0000 Sender: giacomo Message-ID: <3ACB7559.5F3E2463@apache.org> Date: Wed, 04 Apr 2001 21:26:17 +0200 From: Giacomo Pati Organization: Apache Software Foundation X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-4GB i686) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: question on getLogger() References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Donald Ball wrote: > > On Wed, 4 Apr 2001, Giacomo Pati wrote: > > > > > > what's the most succinct way of configuring the class so that getLogger() > > > > > is valid and doesn't return null? > > > > > > > > You need to put your class under the controll of a ComponentManager by > > > > defining it as a component in the cocoon.xconf file and getting it via > > > > the ComponentManager. This depends where you are instanciating your > > > > class. Can you elaborate more on the use case of your class? > > > > > > i was just playing around thinking about caching issues and decided to go > > > ahead and try using a LoggingEntityResolver to see if we can actually > > > track "extra" resources used by sitemap components (trax transformer, for > > > instance) using that method. i'm currently using it as follows in the > > > ResourcePipeline: > > > > be aware that I am currently refactoring the Resourcepieline class. > > oh, i am, i'm not committed to any of the code i'm writing, i'm just > playing around right now. i must confess, though, i don't see any way to > reliably cache the output from the serializers if they don't close the > output streams or signal completion in some other way... Well, the serializers IIRC come from the xerces or xalan projects (not sure which one) and I don't know whether there is a reason not to close it (probably there is one). My position is that caching the serializers output is less important. It can be easily done by a caching proxy infront of C2. The only thing is that some components will have to set HTTP headers to make the output proxy friendly. The Readers are already doing so. We've used proxies with amazing performance gain (at the client side) of Readers output and especially from images produced by the SVGSerializers. Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org