Thread: Re: [Webwork-devel] loading log4j.properties
Brought to you by:
baldree,
rickardoberg
Menu
▾
▴
webwork-devel
|
From: Victor S. <vsa...@ho...> - 2002-01-08 04:59:57
|
Matt, that's great... Although my suggestion would be to create a "ant
skeleton" target, that builds a bare-bones, no frills webwork dir structure.
A new user can take this structure and use it to build an app. Out of my
evangelizing process, the biggest problem people have encountered is setting
up initially. By making a skeleton, that burden is removed.
/V
>From: "Matt Baldree" <ma...@sm...>
>To: "Webwork-Developer" <web...@li...>
>Subject: [Webwork-devel] loading log4j.properties
>Date: Mon, 7 Jan 2002 19:40:40 -0600
>
>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
_________________________________________________________________
Join the worlds largest e-mail service with MSN Hotmail.
http://www.hotmail.com
|
|
From: Mike Cannon-B. <mi...@at...> - 2002-01-09 05:31:06
|
Bill,
Yes - this does make a lot of sense to me and I think I suggested it a while
back (see ServletLoggingDispatcher or something close ;)). It's a trivial
code edition to add an init-param to the dispatcher servlet with the name of
the log4j config file. (If the file ends .xml, use DOMConfigurator,
otherwise use the PropertiesConfigurator).
This is the most elegant solution I think. By default this turns logging off
though (ie no init parameter) which is OK by me. If others don't want this,
perhaps have the string "none" be special to mean turn logging off?
-mike
8/1/02 3:48 PM, "Bill Burton" <bi...@pr...> wrote:
> 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
>
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webwork-devel
Sent using the Entourage X Test Drive.
|
|
From: Mike Cannon-B. <mi...@at...> - 2002-01-09 05:37:57
|
Usually Victors ideas are good - this time I think he's spent a little too
much time in the Puerto Rican sun ;)
The concept of a bare bones structure is ok, but the problem is as you
pointed out - what it should actually contain given that people's needs are
so different. (ie maybe it's a full J2EE app, maybe just a WAR, maybe it's
adding WW to an existing WAR)
However I do think having a much 'simpler' sample app is a good idea. I'd
keep all the complex stuff in there that's already there - it's quite good
for reference but very daunting to newbies who aren't sure where to start.
Then make a new 'newbie' WAR that's just a few simple (perhaps a series of)
actions which do form posts and the like, and show off the most common tags
(iterator, property, ui tags etc).
My $0.02.
-mike
On 8/1/02 8:02 PM, "Matt Baldree" <ma...@sm...> wrote:
> I could see how a bare bones project structure would be helpful for newbies
> to WW and web apps in general. What if we provided a bare bones sample
> project that would be part of the "dist" target. So as part of the
> distribution, this project structure would be built and moved under the
> example folder; i.e., example/projects/webapp. Do you think this would work?
> I guess one concern would be do we provide a sample bare bones project for
> JSP, Velocity, etc. or do we let them work this out for themselves using the
> examples and the documentation?
>
> -Matt
>
> ----- Original Message -----
> From: "Victor Salaman" <vsa...@ho...>
> To: <ma...@sm...>; <web...@li...>
> Sent: Monday, January 07, 2002 10:59 PM
> Subject: Re: [Webwork-devel] loading log4j.properties
>
>
>> Matt, that's great... Although my suggestion would be to create a "ant
>> skeleton" target, that builds a bare-bones, no frills webwork dir
> structure.
>> A new user can take this structure and use it to build an app. Out of my
>> evangelizing process, the biggest problem people have encountered is
> setting
>> up initially. By making a skeleton, that burden is removed.
>>
>> /V
>>
>>
>>> From: "Matt Baldree" <ma...@sm...>
>>> To: "Webwork-Developer" <web...@li...>
>>> Subject: [Webwork-devel] loading log4j.properties
>>> Date: Mon, 7 Jan 2002 19:40:40 -0600
>>>
>>> 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.prope
> r
>>> ties"));
>>> ---
>>>> try
>>>> {
>>>>
>>
>> PropertyConfigurator.configure(classLoader.getResource("log4j.properties"))
> ;
>>>> log.info("Custom log4j property file loaded.");
>>>> } catch (Exception e)
>>>> {
>>>>
>>
>> PropertyConfigurator.configure(classLoader.getResource("webwork/log4j.prope
> r
>>> ties"));
>>>> log.info("Default log4j property file loaded.");
>>>> }
>>>
>>> Thoughts?
>>>
>>> -Matt
>>>
>>>
>>>
>>> _______________________________________________
>>> Webwork-devel mailing list
>>> Web...@li...
>>> https://lists.sourceforge.net/lists/listinfo/webwork-devel
>>
>>
>>
>>
>> _________________________________________________________________
>> Join the world's largest e-mail service with MSN Hotmail.
>> http://www.hotmail.com
>>
>>
>> _______________________________________________
>> Webwork-devel mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/webwork-devel
>>
>>
>
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webwork-devel
Sent using the Entourage X Test Drive.
|
|
From: Rickard <ri...@mi...> - 2002-01-09 17:34:21
|
in...@sm... wrote: > Ok. I made the change so WW looks for a log4j configuration property that > points to a configuration file to configure itself. This can be a .properties > or .xml file or you can null it and it will assume appenders are already setup. > I will commit this tonight when I get a chance. Great, but you did do this by adding a conf parameter to webwork.properties right? /Rickard -- Rickard Öberg |
|
From: matt b. <mat...@ho...> - 2002-01-09 17:46:27
|
>Great, but you did do this by adding a conf parameter to >webwork.properties right? > >/Rickard yes. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com |
|
From: Matt B. <ma...@sm...> - 2002-01-09 01:02:26
|
I could see how a bare bones project structure would be helpful for newbies
to WW and web apps in general. What if we provided a bare bones sample
project that would be part of the "dist" target. So as part of the
distribution, this project structure would be built and moved under the
example folder; i.e., example/projects/webapp. Do you think this would work?
I guess one concern would be do we provide a sample bare bones project for
JSP, Velocity, etc. or do we let them work this out for themselves using the
examples and the documentation?
-Matt
----- Original Message -----
From: "Victor Salaman" <vsa...@ho...>
To: <ma...@sm...>; <web...@li...>
Sent: Monday, January 07, 2002 10:59 PM
Subject: Re: [Webwork-devel] loading log4j.properties
> Matt, that's great... Although my suggestion would be to create a "ant
> skeleton" target, that builds a bare-bones, no frills webwork dir
structure.
> A new user can take this structure and use it to build an app. Out of my
> evangelizing process, the biggest problem people have encountered is
setting
> up initially. By making a skeleton, that burden is removed.
>
> /V
>
>
> >From: "Matt Baldree" <ma...@sm...>
> >To: "Webwork-Developer" <web...@li...>
> >Subject: [Webwork-devel] loading log4j.properties
> >Date: Mon, 7 Jan 2002 19:40:40 -0600
> >
> >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.prope
r
> >ties"));
> >---
> > > try
> > > {
> > >
>
>PropertyConfigurator.configure(classLoader.getResource("log4j.properties"))
;
> > > log.info("Custom log4j property file loaded.");
> > > } catch (Exception e)
> > > {
> > >
>
>PropertyConfigurator.configure(classLoader.getResource("webwork/log4j.prope
r
> >ties"));
> > > log.info("Default log4j property file loaded.");
> > > }
> >
> >Thoughts?
> >
> >-Matt
> >
> >
> >
> >_______________________________________________
> >Webwork-devel mailing list
> >Web...@li...
> >https://lists.sourceforge.net/lists/listinfo/webwork-devel
>
>
>
>
> _________________________________________________________________
> Join the world's largest e-mail service with MSN Hotmail.
> http://www.hotmail.com
>
>
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webwork-devel
>
>
|
|
From: Rickard <ri...@mi...> - 2002-01-09 07:47:23
|
Matt Baldree wrote: > I could see how a bare bones project structure would be helpful for newbies > to WW and web apps in general. What if we provided a bare bones sample > project that would be part of the "dist" target. So as part of the > distribution, this project structure would be built and moved under the > example folder; i.e., example/projects/webapp. Do you think this would work? But what *is* a barebones example? Does it include utilities for best-practice stuff? And what is best-practice anyway, since that depends on the project? There are many tricky issues with doing minimalist stuff. What is minimal?... > I guess one concern would be do we provide a sample bare bones project for > JSP, Velocity, etc. or do we let them work this out for themselves using the > examples and the documentation? That's also a good question. 1/3 JSP, 1/3 Velocity, 1/XSLT :-) But then, what to do when another technology is integrated? *sigh* /Rickard |
×
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