On Sat, 11 Aug 2001, Peter Donald wrote:
> Hi,
>
> When setting up logging system most of the prep work is implementation
> agnostic. First thing I would do is identify major components in system and
> identify which parts you *may* want to control logging for (ie by redirecting
> logging for that component or altering verbosity). Then create a hierarchy of
> component names like
>
> fop.renderer
> fop.renderer.img
> fop.renderer.text
> fop.parser
> fop.parser.sax
>
> or whatever is most appropriate for your system. Each different category in
> the above controls a possibly separate logging namespace.
>
> Next thing I would do is identify how your components will get access to your
> loggers. In all the APIs there is static style access where you place
> something like
>
> static Logger LOGGER = Hierarchy.getDefaultHierarchy().getLoggerFor( "fop" );
>
> at top of each class. This works fine as long as your application is the only
> thing in the JVM and there is only one instance of it. If this is not the
> case then I would instead create an interface that all your components can
> implement that allows you to pass a logger to them. Cocoon and Avalon allow
> you to do this via
>
> interface Loggable
> {
> void setLogger( Logger logger );
> }
>
> And then later on when setting up system you can go
>
> if( myComponent instanceof Loggable )
> {
> ((Loggable)myComponent).setLogger( logger );
> }
I would appreciate FOP could use the interface approach. This would
enable Cocoon to pass its own logger to the Driver class used in the
FOPSerializer.
Giacomo
>
> You will also want to identify where your output gets logged to. I would
> guess in your case it would be as simple as all to a console or file
> depending on an option.
>
> The rest that follows is implementation dependent. In LogKit you would do
> setup something like
>
> ........................
> Hierarchy hierarchy = new Hierarchy();
> PatternFormatter formatter = new PatternFormatter(
> "[%{priority}] %{category}: %{message}\n%{throwable}" );
>
> LogTarget target = null;
>
> if( doConsoleLogging )
> {
> target = new StreamTarget( System.out, formatter );
> }
> else
> {
> target = new FileTarget( myOutputFile, false, formatter );
> }
>
> hierarchy.setDefaultLogTarget( target );
> ........................
>
> Then for each separate component do something like
>
> myRenderer.setLogger( hierarchy.getLoggerFor("fop.renderer") );
> myImgRenderer.setLogger( hierarchy.getLoggerFor("fop.renderer.img") );
> myTextRenderer.setLogger( hierarchy.getLoggerFor("fop.renderer.text") );
> myParser.setLogger( hierarchy.getLoggerFor("fop.parser") );
> etc
>
> Hopefully that helps.
>
> On Fri, 10 Aug 2001 21:28, Sam Ruby wrote:
> > Perhaps someone here can help out?
> >
> > - Sam Ruby
> >
> > ---------------------- Forwarded by Sam Ruby/Raleigh/IBM on 08/10/2001
> > 07:27 AM ---------------------------
> >
> > Keiron Liddle <[EMAIL PROTECTED]> on 08/10/2001 02:18:10 AM
> >
> > Please respond to [email protected]
> >
> > To: [email protected]
> > cc: Sam Ruby/Raleigh/[EMAIL PROTECTED], [email protected]
> > Subject: Re: Public API Change in Driver
> >
> > On Fri, 10 Aug 2001 00:34:00 Sam Ruby wrote:
> > > My own personal crusade is to get projects to talk to one another. And
> > > to treat their public interfaces as contracts.
> >
> > Sam and others,
> >
> > If that is the case then maybe you can help us out.
> >
> > We want to put (better) logging into FOP.
> >
> > I am deciding right now to use avalon logkit. Unless someone has any real
> > serious objections.
> >
> > So this is where cocoon (and possibly others) can help out. Tell us what
> > needs to be done etc. or better yet write some of the code.
> >
> > This way not only can cocoon help us (with things they already know about)
> > but they can be a party to the api changes.
> >
> > Keiron <- trying not to waste any more of 4 hours a week development time.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
