logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: Configurator questions
Date Mon, 19 May 2003 06:44:51 GMT
At 11:01 AM 5/18/2003 -0400, you wrote:
>I am working on a JNDI-based ConnectionSource for the 
>PreparedStatementAppender I have been working on and I have a couple of 
>questions concerning the configurator:
>1)  The PreparedStatementAppender contains objects that are also 
>configured.  E.g.
><appender name="X" class="org.apache.log4j.jdbc.PreparedStatementAppender">
>     <connectionSource class="org.apache.log4j.jdbc.UrlConnectionSource">
>         <param name="driver" value="com.mysql.jdbc.Driver" />
>         <param name="url" value="jdbc:mysql://localhost:3306/bjea" />
>         <param name="username" value="bjea" />
>         <param name="password" value="bjea" />
>     </connectionSource>
>The UrlConnectionSource implements ConnectionSource, which extends 
>OptionHandler.  PreparedStatementAppender also extends OptionHandler. All 
>of the properties are set as expected.  However, I noticed that while 
>PreparedStatementAppender.activateOptions() is called by the configurator, 
>ConnectionSource.activateOptions() is not.  That is, I had to explicitly 
>add a call to ConnectionSource.activateOptions() in 
>PreparedStatementAppender.activateOptions().  I was wondering if I am 
>doing something wrong, or if this was the desired behavior of the 
>configurator and I wanted to propose changing it so that the 
>activateOptions() is always called by the configurator.

While I was coding the new file rollover code, a similar question came
up. The reason why the activateOptions method of a sub-component is
not called is probably because I forgot to do it. However, omission
aside, that is likely to be the correct thing to do because the order
of invocation of the activateOptions method might matter (parent
component first or sub-component first?). Leaving this responsibility
to the parent component is quite adequate because the parent component
knows its subcomponents and can determine in which order to call them.

In summary, the way you have done is correct.

>2)  In the JNDI-based ConnectionSource I will need to construct an 
>InitialContext.  Usually an application doesn't set any properties for the 
>InitialContext explicitly and simply depends on there being a 
>jndi.properties file or the like.  However, it may be that whatever JNDI 
>settings are appropriate for the application are not appropriate for the 
>logging piece of the application.  So I have the following questions:
>         a) Is there a mechanism already set up for setting the JNDI 
> properties for use within log4j separately from the main app?
>         b) Assuming the answer to a) is no, is there a way to set 
> properties using the configurator where name of the property is not fixed 
> at compile time?  That is, my class will contain a java.util.Properties 
> object and I would like for the end-user to be able to add any property 
> they wish into the properties.  I can think of a couple of ways to do this:
>                 i) Many <param> tags with the same name attribute:
><appender name="X" class="org.apache.log4j.jdbc.PreparedStatementAppender">
>     <connectionSource class="org.apache.log4j.jdbc.JNDIConnectionSource">
>         <param name="property" value="foo=bar" />
>         <param name="property" value="abc=xyz" />
>         <param name="property" value="time=now" />
>     </connectionSource>
>                 ii) One <param> tag with large value:
><appender name="X" class="org.apache.log4j.jdbc.PreparedStatementAppender">
>     <connectionSource class="org.apache.log4j.jdbc.JNDIConnectionSource">
>         <param name="property">
><!-- Does the configurator support having the value as contents? -->
>         </param>
>     </connectionSource>
>                 iii) Many <param> tags with multiple values:
><appender name="X" class="org.apache.log4j.jdbc.PreparedStatementAppender">
>     <connectionSource class="org.apache.log4j.jdbc.JNDIConnectionSource">
>         <param name="property" arg1="foo" arg2="bar" />
>         <param name="property" arg1="abc" arg2="xyz" />
>         <param name="property" arg1="time" arg2="now" />
>     </connectionSource>
>I'm not sure that any of these are supported; perhaps there is another way?

None of the variants are supported. This is where dynamic rules come in 
handy as opposed to compile time rules we have now.


Ceki  For log4j documentation consider "The complete log4j manual"
       ISBN: 2970036908  http://www.qos.ch/shop/products/clm_t.jsp 

To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

View raw message