You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Carsten Ziegeler (JIRA)" <ji...@apache.org> on 2007/11/15 16:24:43 UTC

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

Log4j configuration is loaded to late with Spring Configurator
--------------------------------------------------------------

                 Key: COCOON-2147
                 URL: https://issues.apache.org/jira/browse/COCOON-2147
             Project: Cocoon
          Issue Type: Bug
          Components: * Cocoon Core
    Affects Versions: 2.2-dev (Current SVN)
            Reporter: Carsten Ziegeler


The spring configurator provides a bean for configuring log4j through a spring bean. This bean is initialized as soon as spring is finding the definition and starts up the container. Obviously this is too late as all log messages happening before this init are send "somewhere else".

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
c) Remove the logging configuration at all and leave it up to the users to configure everything properly (more or less Spring does the same)


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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-----

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

Posted by Vadim Gritsenko <va...@reverycodes.com>.
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 Carsten Ziegeler <cz...@apache.org>.
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?


Carsten


-- 
Carsten Ziegeler
cziegeler@apache.org

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

Posted by Carsten Ziegeler <cz...@apache.org>.
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.

Yes, but with b) still this can be too late as you don't catch logging
statements from Spring happening before our logging tag is read.
Personally I could live with that.

Thinking about this, I have the feeling that it's not Cocoon's task to
configure logging. It's not our concern, it should more be the concern
of Spring as the core framework underneath everything.
But the interesting part is that even Spring has only partial support
for that. And I'm wondering why noone has complained about this yet.

> 
> 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.
Strange, I think this happened a year ago with another jetty release as
well. It was afaik some changes in class loading hierarchy and provided
jars from jetty.

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

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

Posted by Vadim Gritsenko <va...@reverycodes.com>.
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.

Vadim

[jira] Updated: (COCOON-2147) Log4j configuration is loaded too late with Spring Configurator

Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/COCOON-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carsten Ziegeler updated COCOON-2147:
-------------------------------------

    Summary: Log4j configuration is loaded too late with Spring Configurator  (was: Log4j configuration is loaded to late with Spring Configurator)

> Log4j configuration is loaded too late with Spring Configurator
> ---------------------------------------------------------------
>
>                 Key: COCOON-2147
>                 URL: https://issues.apache.org/jira/browse/COCOON-2147
>             Project: Cocoon
>          Issue Type: Bug
>          Components: * Cocoon Core
>    Affects Versions: 2.2-dev (Current SVN)
>            Reporter: Carsten Ziegeler
>
> The spring configurator provides a bean for configuring log4j through a spring bean. This bean is initialized as soon as spring is finding the definition and starts up the container. Obviously this is too late as all log messages happening before this init are send "somewhere else".
> 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
> c) Remove the logging configuration at all and leave it up to the users to configure everything properly (more or less Spring does the same)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.