My apologies. You are correct. When creating my config-files long
ago, I used the approach of starting with a xml template file
(server-log4j.xml.template) and running a sed script on it to perform
variable substitution and create the actual xml config file
(server-log4j.xml). My command line was:
java org.apache.log4j.net.SimpleSocketServer \
12345 server-log4j.xml
When I upgraded to version 1.2.8, I tried to see if I could do variable
substitution via system properties directly on the xml template file,
but the following failed:
java -Dlog4j.configuratorClass=org.apache.log4j.xml.DOMConfigurator \
-Dlog4j.server.OUTPUT_DIR=data/log \
org.apache.log4j.net.SimpleSocketServer \
12345 server-log4j.xml.template
BTW log4j.server.OUTPUT_DIR was a variable used in my template.
Your message prompted me to investigate further, and it turns out that
the cause was that a third-party jar in my classpath contained a
log4j.properties file. This log4j.properties was being loaded up
before main by the SimpleSocketServer's static 'cat' variable. And of
course the DOMConfigurator failed to parse that properties file. It
worked once I added to my command line a system property
(-Dlog4j.configuration=file:server-log4j.xml.template) to load my xml
file rather than the third-party library's properties file. BTW
now that I look at the source code, I'm puzzled why this works, either,
since I see in SimpleSocketServer.java:
if(configFile.endsWith(".xml")) {
new DOMConfigurator().configure(configFile);
} else {
new PropertyConfigurator().configure(configFile);
}
Which would presumably cause the main program to interpret my
config-file as a property file. Could you help me understand why this
works?
Regardless, thanks for helping me get variable substitution working on
my system -- no more ugly sed scripts!
Thanks,
--Ian
--- Jacob Kjome <[EMAIL PROTECTED]> wrote:
> You are purely speculating here. I have just stated below that, in
> fact,
> log4j.xml *does* support referencing system variables. You can
> disbelieve me
> and not use them yourself or you can test as to whether what I am
> saying is
> actually true or not, but please don't post stuff like this and
> spread
> misinformation when you aren't sure of the facts. I currently use
> the
> following in a FileAppender and it sure works for me...
>
> <param name="File" value="${myapp.log.home}/main.log" />
>
> I set up a system variable named "myapp.log.home" in a servlet
> context listener
> at application startup with the path to the log file. The file fills
> up with
> logging statements as expected.
>
> Also I may be mistaken here since I don't use properties files much
> with log4j,
> but I'm pretty sure properties files *do* support creation of local
> variables
> in the properties file to reference later in the same file in
> addition to
> reading system variables. You'll have to get verification of this
> since I'm
> not positive, but I'm pretty sure it is true.
>
> Jake
>
> Quoting [EMAIL PROTECTED]:
>
> > Actually, I don't believe that log4j.xml supports either creation
> or
> > reference of variables. log4j.properties, on other hand, supports
> > reference of variables, but not creation of them.
> >
> > --Ian
> >
> > --- Jacob Kjome <[EMAIL PROTECTED]> wrote:
> > > At 06:45 AM 12/24/2003 -0800, you wrote:
> > > >The only downside is that (at least as of 1.2.8) variable
> > > interpolation
> > > >is only available in the PropertyConfigurator, not in the
> > > >DOMConfigurator. But if your config files are relatively
> simple,
> > > then
> > > >variable interpolation is definitely the way to go.
> > > >
> > > >--Ian
> > >
> > > Just to clarify (maybe I'm misunderstanding what you just said).
> > > Although
> > > you can't create variables in log4j.xml to reference later in
> > > log4j.xml,
> > > you can reference system properties like ${my.system.variable} in
> > > log4j.xml.
> > >
> > > Jake
> > >
> > >
> > > >--- Steve Ebersole <[EMAIL PROTECTED]> wrote:
> > > > > Another great option is the variable interpolation available
> in
> > > > > log4j, which
> > > > > allows you to do something like:
> > > > >
> > > > > log4j.appender.daily.File=${log.dir}/coldev.log
> > > > >
> > > > > where the variable "log.dir" (or whatever you want to name
> it) is
> > > a
> > > > > java
> > > > > system property.
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Wendy Smoak [mailto:[EMAIL PROTECTED]
> > > > > Sent: Tuesday, December 23, 2003 1:02 PM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: Configuring Log4j for testing vs. development vs.
> > > deployment
> > > > >
> > > > >
> > > > >
> > > > > I figured out that this problem:
> > > > > [junit] log4j:ERROR setFile(null,true) call failed.
> > > > > [junit] java.io.FileNotFoundException:
> > > > > \opt\hpws\tomcat\logs\coldev.log
> > > > > (The system cannot find the path specified)
> > > > >
> > > > > Is caused by log4j.properties saying:
> > > > > # Configure the name of the logout for the daily appender
> > > > > log4j.appender.daily.File=/opt/hpws/tomcat/logs/coldev.log
> > > > >
> > > > > That path belongs on the HPUX web server. In an attempt to
> avoid
> > > > > changing log4j.properties for deployment, I created a
> > > > > c:\opt\hpws\tomcat\logs directory on my Windows development
> > > machine.
> > > > > But now that .properties file doesn't work for me when I run
> > > junit
> > > > > tests
> > > > > from the mapped network drive "G" where the source code
> lives.
> > > > >
> > > > > So... Do you have a separate log4j.properties for running
> tests?
> > > How
> > > > > do
> > > > > you handle configuring log4j for tests? (In the most
> automated
> > > way
> > > > > possible!)
> > > > >
> > > > > Thank you,
> > > > > --
> > > > > Wendy Smoak
> > > > > Application Systems Analyst, Sr.
> > > > > ASU IA Information Resources Management
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > 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]
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
