logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: JoranConfigurator problems
Date Tue, 20 Sep 2005 18:36:26 GMT

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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message