You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Endre Stølsvik <En...@Stolsvik.com> on 2004/04/27 15:36:54 UTC
DOMConfigurator.props
The field "props" in DOMConfigurator would be -marvelous- to be able to
set. But there aren't any accessors, thus (it seems like) the only option
is to extend this class and then set it (the field is protected!). It
really seems like it has been the intention to be able to set this, but
then no-one has gotten around to make a setter.
Suggesting to make this setter.
--
Mvh,
Endre Stølsvik M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS - http://www.coretrek.com/
CoreTrek corporate portal / EIP - http://www.corelets.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DOMConfigurator.props
Posted by Ceki Gülcü <ce...@qos.ch>.
At 04:56 PM 4/27/2004, Endre Stølsvik wrote:
>|
>| The code in DOMConfigurator will not survive in 1.3beta.
>
>But the idea, then? A setProperties(Properties props) method?
Definitely. The idea will survive.
>|
>| >The point is that the DOMConfigurator already do perform -general-
>| >variable substitution, but since the "props" reference in DOMConfigurator
>| >is highly null (there are only -one- reference to it ever, that is when
>| >it's passed to the substituter!), all substitutions are done using only
>| >System.getProperty().
>|
>| I know. I just did not want to waste time implementing it given the bleak
>| future awaiting DOMConfigurator.
>
>Huh? "Waste time": it's a -three line- addition! I can give you a patch!!
>:)
It is not about adding 3 lines to DOMConfigurator but about the releasing
the next version of lgo4j.
--
Ceki Gülcü
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@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DOMConfigurator.props
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Tue, 27 Apr 2004, Ceki Gülcü wrote:
| At 04:18 PM 4/27/2004, Endre Stølsvik wrote:
| >On Tue, 27 Apr 2004, Ceki Gülcü wrote:
| >
| >|
| >| Endre,
| >|
| >| Here are a few hints that you might find useful.
| >
| >Thanks ..
| >
| >But will you -remove- DOMConfigurator?
|
| Yes! DOMConfigurator will eventually be reduced to
|
| /**
| * @deprecated Use JoranConfigurator instead.
| */
| class DOMConfigurator extends JoranConfigurator {
| }
|
| to provide backward compatibility and then it will be simply removed.
Well, good.
|
| > I mean, it is -just- a simple
| >setter, and a very natural one that is. If you're about to deprecate it,
| >why not just add it, and deprecate it in the same go - it is really "a
| >missing feature".
|
| The code in DOMConfigurator will not survive in 1.3beta.
But the idea, then? A setProperties(Properties props) method?
|
| >The point is that the DOMConfigurator already do perform -general-
| >variable substitution, but since the "props" reference in DOMConfigurator
| >is highly null (there are only -one- reference to it ever, that is when
| >it's passed to the substituter!), all substitutions are done using only
| >System.getProperty().
|
| I know. I just did not want to waste time implementing it given the bleak
| future awaiting DOMConfigurator.
Huh? "Waste time": it's a -three line- addition! I can give you a patch!!
:)
|
| >Btw: the javadocs there says that it first tries system props, then the
| >supplied props - this is not true reading the code.
|
| Yes. That is the indented behavior.
Eh.. I pointed out an inconsistency there: the docs says something, then
the code does something else: -what- is the intended (I assume you meant?)
behavior?
|
| >The code is even cooler than I knew; there is recursive substitution!
| >
| >The Joran stuff: shouldn't this also have this -amazing- feature that
| >property-substituion really is from start of? It is really magic - it
| >solved all my problems! I earlier had a script that reg-exped through the
| >log4j.xml file for some stupid delimiter, before starting tomcat. Now,
| >when I found this (undocumented?) feature, I only use the -D options to
| >the java-invoker!
|
| The idea is to be able to use either -D options (system properties) or a
| property file as described in the javadocs.
Where is this described, you say?
Endre.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DOMConfigurator.props
Posted by Ceki Gülcü <ce...@qos.ch>.
At 04:18 PM 4/27/2004, Endre Stølsvik wrote:
>On Tue, 27 Apr 2004, Ceki Gülcü wrote:
>
>|
>| Endre,
>|
>| Here are a few hints that you might find useful.
>
>Thanks ..
>
>But will you -remove- DOMConfigurator?
Yes! DOMConfigurator will eventually be reduced to
/**
* @deprecated Use JoranConfigurator instead.
*/
class DOMConfigurator extends JoranConfigurator {
}
to provide backward compatibility and then it will be simply removed.
> I mean, it is -just- a simple
>setter, and a very natural one that is. If you're about to deprecate it,
>why not just add it, and deprecate it in the same go - it is really "a
>missing feature".
The code in DOMConfigurator will not survive in 1.3beta.
>The point is that the DOMConfigurator already do perform -general-
>variable substitution, but since the "props" reference in DOMConfigurator
>is highly null (there are only -one- reference to it ever, that is when
>it's passed to the substituter!), all substitutions are done using only
>System.getProperty().
I know. I just did not want to waste time implementing it given the bleak
future awaiting DOMConfigurator.
>Btw: the javadocs there says that it first tries system props, then the
>supplied props - this is not true reading the code.
Yes. That is the indented behavior.
>The code is even cooler than I knew; there is recursive substitution!
>
>The Joran stuff: shouldn't this also have this -amazing- feature that
>property-substituion really is from start of? It is really magic - it
>solved all my problems! I earlier had a script that reg-exped through the
>log4j.xml file for some stupid delimiter, before starting tomcat. Now,
>when I found this (undocumented?) feature, I only use the -D options to
>the java-invoker!
The idea is to be able to use either -D options (system properties) or a
property file as described in the javadocs.
>Endre.
--
Ceki Gülcü
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@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DOMConfigurator.props
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Tue, 27 Apr 2004, Ceki Gülcü wrote:
|
| Endre,
|
| Here are a few hints that you might find useful.
Thanks ..
But will you -remove- DOMConfigurator? I mean, it is -just- a simple
setter, and a very natural one that is. If you're about to deprecate it,
why not just add it, and deprecate it in the same go - it is really "a
missing feature".
The point is that the DOMConfigurator already do perform -general-
variable substitution, but since the "props" reference in DOMConfigurator
is highly null (there are only -one- reference to it ever, that is when
it's passed to the substituter!), all substitutions are done using only
System.getProperty().
Btw: the javadocs there says that it first tries system props, then the
supplied props - this is not true reading the code.
The code is even cooler than I knew; there is recursive substitution!
The Joran stuff: shouldn't this also have this -amazing- feature that
property-substituion really is from start of? It is really magic - it
solved all my problems! I earlier had a script that reg-exped through the
log4j.xml file for some stupid delimiter, before starting tomcat. Now,
when I found this (undocumented?) feature, I only use the -D options to
the java-invoker!
Endre.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DOMConfigurator.props
Posted by Ceki Gülcü <ce...@qos.ch>.
Endre,
Here are a few hints that you might find useful.
1) Create a java.util.properties instance using a PropertiesAction (or some
other name) similar to the <property> task in Ant.
2) Place this java.util.properties instance in the joran execution
context's objectMap under a key, say "props".
3) All other Actions can access that properties instance and perform
variable substitution.
That's it...
Note that you do not need to modify the classes under org.apache.joran at
all. Only org.apache.log4j.joran need to be modified.
At 03:48 PM 4/27/2004, Ceki Gülcü wrote:
>Endre,
>
>DOMConfigurator will be replaced by JoranConfigurator. Adding props to
>JoranConfigurator should not be hard.
>
>See http://www.qos.ch/logging/joran.pdf
>
>there are bunch of examples/tutorial under
>
>http://cvs.apache.org/viewcvs.cgi/logging-log4j/examples/src/joran/
>
>I'll gladly add a PropertiesRule if you have the time to contribute it.
>
>Don't hesitate to contact me if you need help.
>
>At 03:36 PM 4/27/2004, Endre Stølsvik wrote:
>>The field "props" in DOMConfigurator would be -marvelous- to be able to
>>set. But there aren't any accessors, thus (it seems like) the only option
>>is to extend this class and then set it (the field is protected!). It
>>really seems like it has been the intention to be able to set this, but
>>then no-one has gotten around to make a setter.
>>
>>Suggesting to make this setter.
>>
>>--
>>Mvh,
>>Endre Stølsvik M[+47 93054050] F[+47 51625182]
>>Developer @ CoreTrek AS - http://www.coretrek.com/
>>CoreTrek corporate portal / EIP - http://www.corelets.com/
--
Ceki Gülcü
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@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DOMConfigurator.props
Posted by Ceki Gülcü <no...@qos.ch>.
Endre,
DOMConfigurator will be replaced by JoranConfigurator. Adding props to
JoranConfigurator should not be hard.
See http://www.qos.ch/logging/joran.pdf
there are bunch of examples/tutorial under
http://cvs.apache.org/viewcvs.cgi/logging-log4j/examples/src/joran/
I'll gladly add a PropertiesRule if you have the time to contribute it.
Don't hesitate to contact me if you need help.
At 03:36 PM 4/27/2004, Endre Stølsvik wrote:
>The field "props" in DOMConfigurator would be -marvelous- to be able to
>set. But there aren't any accessors, thus (it seems like) the only option
>is to extend this class and then set it (the field is protected!). It
>really seems like it has been the intention to be able to set this, but
>then no-one has gotten around to make a setter.
>
>Suggesting to make this setter.
>
>--
>Mvh,
>Endre Stølsvik M[+47 93054050] F[+47 51625182]
>Developer @ CoreTrek AS - http://www.coretrek.com/
>CoreTrek corporate portal / EIP - http://www.corelets.com/
--
Ceki Gülcü
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@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DOMConfigurator.props
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Tue, 27 Apr 2004, Ceki Gülcü wrote:
|
| Why not write code that will make it into 1.3 and learn something useful in
| the process? Of course that is the ideal approach, one does not always have
| time to spend on such things...
It ain't released - I'm shipping this stuff now!
I have learnt something in the process!
Endre
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DOMConfigurator.props
Posted by Ceki Gülcü <ce...@qos.ch>.
Why not write code that will make it into 1.3 and learn something useful in
the process? Of course that is the ideal approach, one does not always have
time to spend on such things...
At 04:34 PM 4/27/2004, Endre Stølsvik wrote:
>On Tue, 27 Apr 2004, Endre Stølsvik wrote:
>
>| The field "props" in DOMConfigurator would be -marvelous- to be able to
>| set. But there aren't any accessors, thus (it seems like) the only option
>| is to extend this class and then set it (the field is protected!).
>
>ARGH! The field has package-access!
>
>Grr..
>
>Gotta override "String subst(String var)" instead then!..
>
>Endre.
--
Ceki Gülcü
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@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DOMConfigurator.props
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Tue, 27 Apr 2004, Endre Stølsvik wrote:
| The field "props" in DOMConfigurator would be -marvelous- to be able to
| set. But there aren't any accessors, thus (it seems like) the only option
| is to extend this class and then set it (the field is protected!).
ARGH! The field has package-access!
Grr..
Gotta override "String subst(String var)" instead then!..
Endre.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org