Thread: [Webwork-devel] loading log4j.properties
Brought to you by:
baldree,
rickardoberg
Menu
▾
▴
webwork-devel
|
From: Matt B. <ma...@sm...> - 2002-01-08 01:41:24
|
I was working on the JSP documentation and realized we need a configuration
document to describe how to configure WW. I wrote this today and added it to
CVS. One section in configuration talks about configuring WW's logger. I
think the developer should be able to substitute the default
log4j.properties under webwork/ with their own if they so choose. This means
they could provide a log4j.properties under WEB-INF/classes that WW would
first check before loading its default under webwork/. This allows the
developer a clean log4j.properties substitution without having to
programmatically do it somewhere else. To allow this capability, I propose
changing the ServletDispatcher as follows:
84c84,92
<
PropertyConfigurator.configure(classLoader.getResource("webwork/log4j.proper
ties"));
---
> try
> {
>
PropertyConfigurator.configure(classLoader.getResource("log4j.properties"));
> log.info("Custom log4j property file loaded.");
> } catch (Exception e)
> {
>
PropertyConfigurator.configure(classLoader.getResource("webwork/log4j.proper
ties"));
> log.info("Default log4j property file loaded.");
> }
Thoughts?
-Matt
|
|
From: Mike Cannon-B. <boo...@ya...> - 2002-01-08 04:16:29
|
Matt,
I brought this up a while ago because I have a
different issue. I always use xml configuration files
in log4j (easier to manipulate, generate etc) and
there's no way to do that.
What I'd suggest is abstract the log loading into
separate class that's easily extendable. The default
behaviour as below is good, and also if log4j is
already configured it should not touch it at all. (I
configure logging at the EAR level).
-mike
--- Matt Baldree <ma...@sm...> wrote:
> I was working on the JSP documentation and realized
> we need a configuration
> document to describe how to configure WW. I wrote
> this today and added it to
> CVS. One section in configuration talks about
> configuring WW's logger. I
> think the developer should be able to substitute the
> default
> log4j.properties under webwork/ with their own if
> they so choose. This means
> they could provide a log4j.properties under
> WEB-INF/classes that WW would
> first check before loading its default under
> webwork/. This allows the
> developer a clean log4j.properties substitution
> without having to
> programmatically do it somewhere else. To allow this
> capability, I propose
> changing the ServletDispatcher as follows:
>
> 84c84,92
> <
>
PropertyConfigurator.configure(classLoader.getResource("webwork/log4j.proper
> ties"));
> ---
> > try
> > {
> >
>
PropertyConfigurator.configure(classLoader.getResource("log4j.properties"));
> > log.info("Custom log4j property file
> loaded.");
> > } catch (Exception e)
> > {
> >
>
PropertyConfigurator.configure(classLoader.getResource("webwork/log4j.proper
> ties"));
> > log.info("Default log4j property file
> loaded.");
> > }
>
> Thoughts?
>
> -Matt
>
>
>
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
>
https://lists.sourceforge.net/lists/listinfo/webwork-devel
__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
|
|
From: Matt B. <ma...@sm...> - 2002-01-09 00:45:42
|
For now I made the proposed change but I agree with your point. I need to
finish the JSP doc and I will look at this next.
-Matt
----- Original Message -----
From: "Mike Cannon-Brookes" <boo...@ya...>
To: "Matt Baldree" <ma...@sm...>; "Webwork-Developer"
<web...@li...>
Sent: Monday, January 07, 2002 10:16 PM
Subject: Re: [Webwork-devel] loading log4j.properties
> Matt,
>
> I brought this up a while ago because I have a
> different issue. I always use xml configuration files
> in log4j (easier to manipulate, generate etc) and
> there's no way to do that.
>
> What I'd suggest is abstract the log loading into
> separate class that's easily extendable. The default
> behaviour as below is good, and also if log4j is
> already configured it should not touch it at all. (I
> configure logging at the EAR level).
>
> -mike
>
> --- Matt Baldree <ma...@sm...> wrote:
> > I was working on the JSP documentation and realized
> > we need a configuration
> > document to describe how to configure WW. I wrote
> > this today and added it to
> > CVS. One section in configuration talks about
> > configuring WW's logger. I
> > think the developer should be able to substitute the
> > default
> > log4j.properties under webwork/ with their own if
> > they so choose. This means
> > they could provide a log4j.properties under
> > WEB-INF/classes that WW would
> > first check before loading its default under
> > webwork/. This allows the
> > developer a clean log4j.properties substitution
> > without having to
> > programmatically do it somewhere else. To allow this
> > capability, I propose
> > changing the ServletDispatcher as follows:
> >
> > 84c84,92
> > <
> >
>
PropertyConfigurator.configure(classLoader.getResource("webwork/log4j.proper
> > ties"));
> > ---
> > > try
> > > {
> > >
> >
>
PropertyConfigurator.configure(classLoader.getResource("log4j.properties"));
> > > log.info("Custom log4j property file
> > loaded.");
> > > } catch (Exception e)
> > > {
> > >
> >
>
PropertyConfigurator.configure(classLoader.getResource("webwork/log4j.proper
> > ties"));
> > > log.info("Default log4j property file
> > loaded.");
> > > }
> >
> > Thoughts?
> >
> > -Matt
> >
> >
> >
> > _______________________________________________
> > Webwork-devel mailing list
> > Web...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/webwork-devel
>
>
> __________________________________________________
> Do You Yahoo!?
> Send FREE video emails in Yahoo! Mail!
> http://promo.yahoo.com/videomail/
>
>
|
|
From: Bill B. <bi...@pr...> - 2002-01-09 05:15:50
|
Hello,
Would it make sense to modify the servlet so it takes a Log4J
configuration parameter?
- If not specified, logging is assumed to already be initialized.
- Specify a properties file name
- Specify an XML file name
If either a properties file or XML file are specified for the parameter,
the appropriate one will be used to initialized Log4J.
-Bill
Mike Cannon-Brookes wrote:
>
> Matt,
>
> I brought this up a while ago because I have a
> different issue. I always use xml configuration files
> in log4j (easier to manipulate, generate etc) and
> there's no way to do that.
>
> What I'd suggest is abstract the log loading into
> separate class that's easily extendable. The default
> behaviour as below is good, and also if log4j is
> already configured it should not touch it at all. (I
> configure logging at the EAR level).
>
> -mike
>
> --- Matt Baldree <ma...@sm...> wrote:
> > I was working on the JSP documentation and realized
> > we need a configuration
> > document to describe how to configure WW. I wrote
> > this today and added it to
> > CVS. One section in configuration talks about
> > configuring WW's logger. I
> > think the developer should be able to substitute the
> > default
> > log4j.properties under webwork/ with their own if
> > they so choose. This means
> > they could provide a log4j.properties under
> > WEB-INF/classes that WW would
> > first check before loading its default under
> > webwork/. This allows the
> > developer a clean log4j.properties substitution
> > without having to
> > programmatically do it somewhere else. To allow this
> > capability, I propose
> > changing the ServletDispatcher as follows:
> >
> > 84c84,92
> > <
> >
> PropertyConfigurator.configure(classLoader.getResource("webwork/log4j.proper
> > ties"));
> > ---
> > > try
> > > {
> > >
> >
> PropertyConfigurator.configure(classLoader.getResource("log4j.properties"));
> > > log.info("Custom log4j property file
> > loaded.");
> > > } catch (Exception e)
> > > {
> > >
> >
> PropertyConfigurator.configure(classLoader.getResource("webwork/log4j.proper
> > ties"));
> > > log.info("Default log4j property file
> > loaded.");
> > > }
> >
> > Thoughts?
> >
> > -Matt
|
|
From: Rickard <ri...@mi...> - 2002-01-09 07:44:52
|
Bill Burton wrote: > Hello, > > Would it make sense to modify the servlet so it takes a Log4J > configuration parameter? Why add a parameter when we already have a configuration strategy for WebWork? Why not use that? > - If not specified, logging is assumed to already be initialized. > - Specify a properties file name > - Specify an XML file name > > If either a properties file or XML file are specified for the parameter, > the appropriate one will be used to initialized Log4J. Works for me. /Rickard -- Rickard Öberg |
|
From: Rickard <ri...@mi...> - 2002-01-08 08:18:02
|
Matt Baldree wrote:
> I was working on the JSP documentation and realized we need a configuration
> document to describe how to configure WW. I wrote this today and added it to
> CVS. One section in configuration talks about configuring WW's logger. I
> think the developer should be able to substitute the default
> log4j.properties under webwork/ with their own if they so choose. This means
> they could provide a log4j.properties under WEB-INF/classes that WW would
> first check before loading its default under webwork/. This allows the
> developer a clean log4j.properties substitution without having to
> programmatically do it somewhere else. To allow this capability, I propose
> changing the ServletDispatcher as follows:
>
> 84c84,92
> <
> PropertyConfigurator.configure(classLoader.getResource("webwork/log4j.proper
> ties"));
> ---
>
>> try
>> {
>>
>>
> PropertyConfigurator.configure(classLoader.getResource("log4j.properties"));
>
>> log.info("Custom log4j property file loaded.");
>> } catch (Exception e)
>> {
>>
>>
> PropertyConfigurator.configure(classLoader.getResource("webwork/log4j.proper
> ties"));
>
>> log.info("Default log4j property file loaded.");
>> }
>>
>
> Thoughts?
This sounds like a good first step, then accompanied with what Mike
proposed.
/Rickard
--
Rickard Öberg
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X