Ceki Gülcü wrote:
>
> Anders.
>
> Jin's request can be answered satisfactorily by variable substitution as another
>user suggested earlier.
Variable substitution can remove the need to modify the config file in
more than one place when the layout configuration changes but you'd
still have to configure a separate layout for each appender.
I don't think users care about how log4j achieves thread safety. From a
users point of view it's odd that [s]he has to have <n> identically
configured Layouts when one would apparently do the job. Jins question
supports this view.
>
> A very important point to keep in mind is that layout instances are not intended to
>be used by multiple appenders, but a given appender can be attached to multiple
>categories. (Synchronization is done at the appender.doAppend level.) Layout code
>relied on the fact that its environment is thread safe so that it doesn't need to
>worry about thread-safety itself.
>
Fair enough, but it's not clear to me that it wouldn't be better to
synchronize individual components on an as-needed basis. log4j also
supports programmatic configuration and it's very easy to get this
wrong.
> References to layouts is a bad idea even if it can be supported with new
>configurator syntax. Regards, Ceki
The point is not syntax but modeling.
Best regards,
Anders
>
> At 19:51 21.03.2001 +0100, Anders Kristensen wrote:
> >Jin,
> >
> >I think what you ask for makes a lot of sense but that it might be part
> >of a more thoroughly reworked property configurator, which also handles
> >configuration of Categories, Appenders, Layouts, ErrorHandlers and
> >Filters in a consistent, simple, and powerful manner.
> >
> >Let me try and outline how I think this can be done in an extension of
> >the JavaBeans style configuration recently introduced. In the scheme
> >described below the configurator doesn't even know about the specifics
> >of these log4j components but just knows how to configure arbitrary
> >objects.
> >
> >As an example, an appender might have a property "layout" with value
> >"${mylayout}" and a corresponding setter of the form
> >
> > public void setLayout(Layout)
> >
> >The configurator would see this and would try and create the "mylayout"
> >object according to the properties file, e.g.
> >
> >log4j.mylayout=org.apache.log4j.PatternLayout
> >log4j.mylayout.ConversionPattern=%-5p - %c{2}: %m%n
> >log4j.mylayout.DateFormat=ISO8601
> >
> >so it would load the class "org.apache.log4j.PatternLayout", instantiate
> >it and check that it matches the argument to the setter (Layout). It
> >does match as PatternLayout extends Layout, so the configurator
> >continues to configure the mylayout object recursively. When $mylayout
> >is fully configured the configurator passes it to setLayout() on the
> >appender.
> >
> >The beauty of this scheme is that it's generic - there needs to be very
> >little log4j specific code, if any. This also makes it simple.
> >Configuration of error handlers, filters comes for free. The file format
> >would have to change, though, to make the syntax more uniform. For this
> >reason I think this is a new and separate configurator rather than a fix
> >of the existing one.
> >
> >Cheers,
> >Anders
> >
> >
> >Jin Zhao wrote:
> >>
> >> I meet such a condition when configure log4j using an extended
> >> PropertyConfigurator.
> >> There are more than two dozens of Appenders use one same layout.
> >> What I did is just copy and paste them. However, everytime I make
> >> changes to the layout, I need to copy and paste again.
> >>
> >> Can we configure layout in the similar way as for appenders ? We may
> >> define a layout first and let appenders to make reference to that
> >> layout, just like we define an appender first and let categories to
> >> reference it.
> >>
> >> It seems need to change the current log4j source.
> >>
> >> Or any work around for the condition I meet?
> >>
> >> Any responses are appreciated.
> >>
> >> Jin
> >>
> >> ---------------------------------------------------------------------
> >> 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]
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
>
> I hope to see you at my ApacheCon 2001 presentation
> entitled "Log4j, A Logging Package for Java".
>
> See http://ApacheCon.Com/2001/US/ for more details.
>
> ----
> Ceki Gülcü Web: http://qos.ch
> av. de Rumine 5 email: [EMAIL PROTECTED] (preferred)
> CH-1005 Lausanne [EMAIL PROTECTED]
> Switzerland Tel: ++41 21 351 23 15
>
> ---------------------------------------------------------------------
> 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]