On Sep 19, 2005, at 7:15 AM, Yoav Shapira wrote:
Back to the main point of this thread: do we really need
JoranConfigurator at
all? I agree it can be modified to work with log4j 1.3, but I
wonder if it's
necessary at all. It has some advantages over the DOMConfigurator,
sure, but
perhaps we can leave the Joran one out of the core, make it available
separately, and see how much demand there is?
Yoav (who is in anti-scope-creep, anti-feature-creep, anti-bloat
mode this
morning)
I've been meaning to do a thorough review of Joran Real Soon Now for
a long time. My big motivation is that using a DOM-based
configurator complicates log4cxx and migrating to an functionally
equivalent configurator that used an event-based parser would
eliminate all sorts of platform-specific code and configuration issues.
I have several concerns about XML configuration in general and
JoranConfigurator in particular that I'd like to eventually address.
The primary issue is the existing XML configuration language is
undocumented and loosely constrained. The existing configuration
language added an unnecessary level of indirection and by doing so
made it very difficult to effectively validate the configuration
using established XML technologies. For example, these two fragments
have the same information, but the latter form could be checked by an
schema-aware XML editor and identify, for example, that the file name
was not specified:
<appender name="A1" class="org.apache.log4j.FileAppender">
<param name="File" value="output/temp.A1" />
<param name="Append" value="false" />
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%-5p %c{2} - %m%n"/>
</layout>
</appender>
<FileAppender xmlns="http://logging.apache.org/configuration";
file="output/temp.A1" append="false">
<layout>
<PatternLayout conversionPattern=""%-5p %c{2} - %m%n"/>
</layout>
</FileAppender>
Obviously, the established XML syntax must be supported for
compatibility. But it would be nice if the "native" configuration
language was well-designed and documented and if the legacy format
was identified and translated to the native form before processing
with a common back-end. It would be ideal if a similar approach
could be used with the property file configurator. If an direct
mapping from the property file representation to the equivalent XML
representation was made, then a translater could read the property
file and fire off the equivalent XML parsing events and utilize a
common back end.
There is already a complaints that some appenders that can't be
configured using PropertyConfigurator. I'm guessing that if the v1.2
DOMConfigurator was resurrected that it would have some of the same
issues.
It may be necessary to resurrect DOMConfigurator anyway if the 1.2
exposed extension points and there was a significant possibility that
users could have defined derived classes. The same type of issue
confronts us with the RFA's where we exposed too much. It may be
appropriate to consider create distinct jars one with the older,
buggier (or at least feature poor) but fully compatible
implementations and another with compatibility wrappers over the new
implementations which should be less buggy but would not support
classes derived from the earlier implementations.
I have lots of questions, not many answers yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
