You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Donald Ball <ba...@webslingerZ.com> on 2001/04/03 20:55:30 UTC

question on getLogger()

i thought i'd try my hand at a little LoggingEntityResolver so that we can
try to track file/uri dependencies for the various sitemap components.
unfortunately, i'm having trouble getting access to the Logger -
getLogger() returns null. here's my sample code:

package org.apache.cocoon.xml;

import org.xml.sax.EntityResolver;
import org.xml.sax.InputSource;
import org.xml.sax.SAXException;
import java.io.IOException;
import org.apache.log.Logger;
import org.apache.avalon.AbstractLoggable;
import org.apache.avalon.configuration.Configurable;
import org.apache.avalon.configuration.Configuration;
import org.apache.avalon.configuration.ConfigurationException;

public class LoggingEntityResolver extends AbstractLoggable implements
EntityResolver,Configurable {

  protected EntityResolver resolver;

  public LoggingEntityResolver(EntityResolver resolver) {
    this.resolver = resolver;
  }

  public void configure(Configuration conf) throws ConfigurationException
{}

  public InputSource resolveEntity(String public_id, String system_id)
throws SAXException,IOException {
    InputSource input_source =
resolver.resolveEntity(public_id,system_id);
    StringBuffer sb = new StringBuffer();
    sb.append("Resolving entity: ");
    if (public_id != null) {
      sb.append("public_id: "+public_id);
    }
    if (system_id != null) {
      sb.append("system_id: "+system_id);
    }
    if (input_source != null) {
      sb.append("input_source: "+input_source.toString());
    }
    getLogger().debug(sb.toString());
    return input_source;
  }

}

what's the most succinct way of configuring the class so that getLogger()
is valid and doesn't return null?

- donald


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: question on getLogger()

Posted by Berin Loritsch <bl...@apache.org>.
Donald Ball wrote:
> 
> On Wed, 4 Apr 2001, Giacomo Pati wrote:
> 
> > > On Wed, 4 Apr 2001, Giacomo Pati wrote:
> > >
> > > > 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.
> > >
> > > that's a very good point. on what variables can you have the proxy vary
> > > its cache?
> >
> > I don't think I get what you mean. The Reader components we have uses
> > parameters like
> >
> >   <param name="expires" value="100"/>
> >
> > which means for the proxy which is requesting the resource that it at
> > least can proxy it for 100 seconds. Another thing is if the proxy (or
> > the client browser) is asking with a header "if-modified-since" then the
> > Readers will response with a HTTP-Code without producing the resource if
> > it is not modified since.
> 
> but the proxy needs to know if the response varies on the user agent, or
> request variables, or http request type, or cookie values, etc.... right?

For more info on what a proxy can and can't do, I'd suggest reading up on
Squid Proxy server (you can find a link on www.freshmeat.net).  I friend
of mine set this up at our church to force all computer access to the net
through the proxy.  It was mainly done for two purposes: make sure
inappropriate sites are blocked and logged, and ease administration.
You can use many settings to cache access to the net for the performance
gain that Giacomo was talking about.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: question on getLogger()

Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 4 Apr 2001, Giacomo Pati wrote:

> > On Wed, 4 Apr 2001, Giacomo Pati wrote:
> >
> > > 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.
> >
> > that's a very good point. on what variables can you have the proxy vary
> > its cache?
>
> I don't think I get what you mean. The Reader components we have uses
> parameters like
>
>   <param name="expires" value="100"/>
>
> which means for the proxy which is requesting the resource that it at
> least can proxy it for 100 seconds. Another thing is if the proxy (or
> the client browser) is asking with a header "if-modified-since" then the
> Readers will response with a HTTP-Code without producing the resource if
> it is not modified since.

but the proxy needs to know if the response varies on the user agent, or
request variables, or http request type, or cookie values, etc.... right?

- donald


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: question on getLogger()

Posted by Giacomo Pati <gi...@apache.org>.
Donald Ball wrote:
> 
> On Wed, 4 Apr 2001, Giacomo Pati wrote:
> 
> > 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.
> 
> that's a very good point. on what variables can you have the proxy vary
> its cache?

I don't think I get what you mean. The Reader components we have uses
parameters like 

  <param name="expires" value="100"/>

which means for the proxy which is requesting the resource that it at
least can proxy it for 100 seconds. Another thing is if the proxy (or
the client browser) is asking with a header "if-modified-since" then the
Readers will response with a HTTP-Code without producing the resource if
it is not modified since.

Giacomo

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: question on getLogger()

Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 4 Apr 2001, Giacomo Pati wrote:

> 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.

that's a very good point. on what variables can you have the proxy vary
its cache?

- donald


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: question on getLogger()

Posted by Giacomo Pati <gi...@apache.org>.
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


Re: question on getLogger()

Posted by Donald Ball <ba...@webslingerZ.com>.
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...

- donald


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: question on getLogger()

Posted by Giacomo Pati <gi...@apache.org>.
On Tue, Apr 03, 2001 at 05:38:53PM -0400, Donald Ball wrote:
> On Tue, 3 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.

Giacomo 

> 
>             while ( transformerItt.hasNext() ) {
>                 Transformer trans = (Transformer)transformerItt.next();
>                 LoggingEntityResolver resolver = new
> LoggingEntityResolver((EntityResolver)environment);
>                 resolver.setLogger(log);
>                 trans.setup(
>                     resolver,
>                     environment.getObjectModel(),
>                     (String)transformerSourceItt.next(),
>                     (Parameters)transformerParamItt.next()
>                 );
>             }
> 
> and it works like a charm. the idea being that the ResourcePipeline can
> check not only the freshness of the original InputSource (if any) for a
> sitemap component, but the other resources upon which it depends. nothing
> fancy, but it does solve a long-standing problem.
> 
> - donald
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> 

-- 
PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1  856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1  856 2201
Hintereichenstrasse 7                     Mobil: +41 (0)78 759 7703
CH-8166 Niederweningen                    Mailto:Giacomo.Pati@pwr.ch
                                          Web:   http://www.pwr.ch

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: question on getLogger()

Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 3 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:

            while ( transformerItt.hasNext() ) {
                Transformer trans = (Transformer)transformerItt.next();
                LoggingEntityResolver resolver = new
LoggingEntityResolver((EntityResolver)environment);
                resolver.setLogger(log);
                trans.setup(
                    resolver,
                    environment.getObjectModel(),
                    (String)transformerSourceItt.next(),
                    (Parameters)transformerParamItt.next()
                );
            }

and it works like a charm. the idea being that the ResourcePipeline can
check not only the freshness of the original InputSource (if any) for a
sitemap component, but the other resources upon which it depends. nothing
fancy, but it does solve a long-standing problem.

- donald


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: question on getLogger()

Posted by Giacomo Pati <gi...@apache.org>.
Donald Ball wrote:
> 
> i thought i'd try my hand at a little LoggingEntityResolver so that we can
> try to track file/uri dependencies for the various sitemap components.
> unfortunately, i'm having trouble getting access to the Logger -
> getLogger() returns null. here's my sample code:
> 
> package org.apache.cocoon.xml;
> 
> import org.xml.sax.EntityResolver;
> import org.xml.sax.InputSource;
> import org.xml.sax.SAXException;
> import java.io.IOException;
> import org.apache.log.Logger;
> import org.apache.avalon.AbstractLoggable;
> import org.apache.avalon.configuration.Configurable;
> import org.apache.avalon.configuration.Configuration;
> import org.apache.avalon.configuration.ConfigurationException;
> 
> public class LoggingEntityResolver extends AbstractLoggable implements
> EntityResolver,Configurable {
> 
>   protected EntityResolver resolver;
> 
>   public LoggingEntityResolver(EntityResolver resolver) {
>     this.resolver = resolver;
>   }
> 
>   public void configure(Configuration conf) throws ConfigurationException
> {}
> 
>   public InputSource resolveEntity(String public_id, String system_id)
> throws SAXException,IOException {
>     InputSource input_source =
> resolver.resolveEntity(public_id,system_id);
>     StringBuffer sb = new StringBuffer();
>     sb.append("Resolving entity: ");
>     if (public_id != null) {
>       sb.append("public_id: "+public_id);
>     }
>     if (system_id != null) {
>       sb.append("system_id: "+system_id);
>     }
>     if (input_source != null) {
>       sb.append("input_source: "+input_source.toString());
>     }
>     getLogger().debug(sb.toString());
>     return input_source;
>   }
> 
> }
> 
> 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?

Giacomo

> 
> - donald
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: question on getLogger()

Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 3 Apr 2001, Berin Loritsch wrote:

> Donald Ball wrote:
> >
> > i thought i'd try my hand at a little LoggingEntityResolver so that we can
> > try to track file/uri dependencies for the various sitemap components.
> > unfortunately, i'm having trouble getting access to the Logger -
> > getLogger() returns null. here's my sample code:
>
> How is this being instantiated?  All components in Cocoon are created by a
> ComponentFactory that takes care of alot of implementation details for you.
> If you are creating the EntityResolver like this:
>
> EntityResolver resolver = new LoggingEntityResolver(realResolver);
>
> then you can't forget to do the lifecycle management functions:
>
> resolver.setLogger(this.getLogger());
> resolver.configure(conf);

i see now, thanks. okay, i just checked in a simple LoggingEntityResolver
which may help somewhat in caching.

- donald


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: question on getLogger()

Posted by Berin Loritsch <bl...@apache.org>.
Donald Ball wrote:
> 
> i thought i'd try my hand at a little LoggingEntityResolver so that we can
> try to track file/uri dependencies for the various sitemap components.
> unfortunately, i'm having trouble getting access to the Logger -
> getLogger() returns null. here's my sample code:

How is this being instantiated?  All components in Cocoon are created by a
ComponentFactory that takes care of alot of implementation details for you.
If you are creating the EntityResolver like this:

EntityResolver resolver = new LoggingEntityResolver(realResolver);

then you can't forget to do the lifecycle management functions:

resolver.setLogger(this.getLogger());
resolver.configure(conf);

> package org.apache.cocoon.xml;
> 
> import org.xml.sax.EntityResolver;
> import org.xml.sax.InputSource;
> import org.xml.sax.SAXException;
> import java.io.IOException;
> import org.apache.log.Logger;
> import org.apache.avalon.AbstractLoggable;
> import org.apache.avalon.configuration.Configurable;
> import org.apache.avalon.configuration.Configuration;
> import org.apache.avalon.configuration.ConfigurationException;
> 
> public class LoggingEntityResolver extends AbstractLoggable implements
> EntityResolver,Configurable {
> 
>   protected EntityResolver resolver;
> 
>   public LoggingEntityResolver(EntityResolver resolver) {
>     this.resolver = resolver;
>   }
> 
>   public void configure(Configuration conf) throws ConfigurationException
> {}
> 
>   public InputSource resolveEntity(String public_id, String system_id)
> throws SAXException,IOException {
>     InputSource input_source =
> resolver.resolveEntity(public_id,system_id);
>     StringBuffer sb = new StringBuffer();
>     sb.append("Resolving entity: ");
>     if (public_id != null) {
>       sb.append("public_id: "+public_id);
>     }
>     if (system_id != null) {
>       sb.append("system_id: "+system_id);
>     }
>     if (input_source != null) {
>       sb.append("input_source: "+input_source.toString());
>     }
>     getLogger().debug(sb.toString());
>     return input_source;
>   }
> 
> }
> 
> what's the most succinct way of configuring the class so that getLogger()
> is valid and doesn't return null?
> 
> - donald
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org