You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Vadim Gritsenko <va...@reverycodes.com> on 2007/12/14 22:16:03 UTC

Re: Logging, Re: [jira] Created: (COCOON-2147) Log4j configuration is loaded to late with Spring Configurator

On Nov 15, 2007, at 12:13 PM, Carsten Ziegeler wrote:

> Vadim Gritsenko wrote:
>> Carsten Ziegeler (JIRA) wrote:
>>> Log4j configuration is loaded to late with Spring Configurator
>> ...
>>> There might be different solutions for this:
>>> a) Provide a configuration servlet/servlet listener (Spring provides
>>> one as well, but that's only usuable inside an expanded war file)
>>> b) Create an XML tag for spring configuration (like we do for the
>>> settings). This will ensure that logging is setup before beans are  
>>> setup
>>
>> I'd prefer either a or b. b is even better since you don't have to  
>> touch
>> web.xml.
>>
>> Speaking of logging, I think latest jetty maven plugin (or something
>> else?) broke all the logging and now everything is dumped to the
>> console, and log file is empty. It started doing this for me day or  
>> two
>> ago.
>>
> By default log4j loads the log4j.properties from the classpath.  
> Perhaps
> this is enough?

Brining this topic back up... We were providing built-in support for  
logging like... forever... dropping it would not add to the  
convenience of using Cocoon.

And since b) still would not catch some of Spring logging, a) seems  
like best option. I'd like to see it implemented - if I get chunk of  
time to do it, I'll try to...

Vadim

Re: Logging, Re: [jira] Created: (COCOON-2147) Log4j configuration is loaded to late with Spring Configurator

Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Vadim Gritsenko wrote:
> On Nov 15, 2007, at 12:13 PM, Carsten Ziegeler wrote:
> 
>> Vadim Gritsenko wrote:
>>> Carsten Ziegeler (JIRA) wrote:
>>>> Log4j configuration is loaded to late with Spring Configurator
>>> ...
>>>> There might be different solutions for this:
>>>> a) Provide a configuration servlet/servlet listener (Spring provides
>>>> one as well, but that's only usuable inside an expanded war file)
>>>> b) Create an XML tag for spring configuration (like we do for the
>>>> settings). This will ensure that logging is setup before beans are
>>>> setup
>>>
>>> I'd prefer either a or b. b is even better since you don't have to touch
>>> web.xml.
>>>
>>> Speaking of logging, I think latest jetty maven plugin (or something
>>> else?) broke all the logging and now everything is dumped to the
>>> console, and log file is empty. It started doing this for me day or two
>>> ago.
>>>
>> By default log4j loads the log4j.properties from the classpath. Perhaps
>> this is enough?
> 
> Brining this topic back up... We were providing built-in support for
> logging like... forever... dropping it would not add to the convenience
> of using Cocoon.
> 
> And since b) still would not catch some of Spring logging, a) seems like
> best option. I'd like to see it implemented - if I get chunk of time to
> do it, I'll try to...

Have a lock at
http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-webapp/src/main/java/org/apache/jackrabbit/j2ee/LoggingServlet.java

> 
> Vadim
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHZ2UNLNdJvZjjVZARAoaHAJwNMQFtO87XePaTGFb+f8+O5AY0zwCgx6Zy
pnm3kZl02pNIB4V/tWXFwH4=
=ABtH
-----END PGP SIGNATURE-----