headers
Gunnar Wagenknecht | 1 Sep 2010 09:01
Favicon
Gravatar

Logback Refactoring Ideas

Greetings Logback developers,

I'm regularly packaging Logback OSGi bundles for Eclipse Orbit. The
other day I was wondering if the current core vs. classic split of
Logback is really useful for people, i.e. is anybody out there using
_just_ Logback core without any of the classic pieces?

For example, PatternLayout is classic but the file appenders are in
core. Isn't PatternLayout an essential logging element? Also, when an
issue in the XML/Groofvy configuration implementation is detected, a
full new release of core+classic is required. Wouldn't it be better if
the parts could evolve independent?

Thus, I was thinking of a more fine grained split based on functional
units. For example like this:

-> Logback Logging Essentials
All the essential logging related stuff form core+classic (logger,
levels, (turbo) filters, console appender, encoders, layouts, basic
configurator)

-> Logback SLF4J Logger
The native SLF4J logger.

-> Logback XML/Groovy Configuration Pack
The advanced configuration functionality based on Joran for XML + Groovy.

-> Logback File Logging Extension Pack
File appenders
(Continue reading)

Permalink | Reply | 3 comments |
headers
Chad La Joie | 1 Sep 2010 12:50

Re: Logback Refactoring Ideas

Maybe I just haven't encountered them but I've never seen a case where 
projects would have benefited from this type of fine grained packaging. 
  So at the very least I would think that the first four packages you 
identify should be one package.

As far as the versioning goes, I would recommend against independent 
versions unless you are going to establish a consistent and rigid 
versioning policy dealing with API changes and backwards/forwards 
compatibility.  To date logback has not had that and if it doesn't in 
the future you'll end up having to describe exactly which versions of 
which packages work with exactly which versions of other packages.  That 
would be very cumbersome and messy I think.

On 9/1/10 3:01 AM, Gunnar Wagenknecht wrote:
> Greetings Logback developers,
>
> I'm regularly packaging Logback OSGi bundles for Eclipse Orbit. The
> other day I was wondering if the current core vs. classic split of
> Logback is really useful for people, i.e. is anybody out there using
> _just_ Logback core without any of the classic pieces?
>
> For example, PatternLayout is classic but the file appenders are in
> core. Isn't PatternLayout an essential logging element? Also, when an
> issue in the XML/Groofvy configuration implementation is detected, a
> full new release of core+classic is required. Wouldn't it be better if
> the parts could evolve independent?
>
> Thus, I was thinking of a more fine grained split based on functional
> units. For example like this:
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gunnar Wagenknecht | 1 Sep 2010 20:04
Favicon
Gravatar

Re: Logback Refactoring Ideas

Am 01.09.2010 12:50, schrieb Chad La Joie:
> Maybe I just haven't encountered them but I've never seen a case where 
> projects would have benefited from this type of fine grained packaging.

I put the ideas together because we would benefit from them. Our project
just need the logging essentials but not the XML/Groovy configuration
stuff or any of the other appenders. However, there were releases in the
past that just contained modifications in those area and we were
confronted with requests to updated an "outdated" version for Logback
which actually wasn't outdated.

I can also see some benefits on embedded devices which look for ever kB
they could save.

> As far as the versioning goes, I would recommend against independent 
> versions unless you are going to establish a consistent and rigid 
> versioning policy dealing with API changes and backwards/forwards 
> compatibility.  To date logback has not had that and if it doesn't in 
> the future you'll end up having to describe exactly which versions of 
> which packages work with exactly which versions of other packages.  That 
> would be very cumbersome and messy I think.

I don't really see this as an issue. There are well established best
practices for versioning as well as defining requirements, etc. Maybe
I'm wrong but to me it seems that Ceki already started adopting them for
SLF4J and also for Logback (that's why it's still pre-1.0 to allow
evolution of the API).

Another benefit is that Logback Essentials could be declared 1.0
independent from other packages. IMHO this would also be a positive
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralph Goers | 2 Sep 2010 02:24
Picon
Favicon

Re: Logback Refactoring Ideas

Ceki created core so that he could build logback-classic, logback-access and logback-audit on top of
them. I'm not a particular fan of this myself.  If you look at access and classic you will notice that both
have a PatternLayout, DBAppender, SMTPAppender, SocketAppender, etc. Also, the Context used in
classic isn't the same as the context used in access.

I'm not sure that at this point Logback can be refactored as you would like.

I would like to point out that Log4j is in the early phase of 2.0 and could really use people to work on
suggestions like this.  

Ralph

On Sep 1, 2010, at 12:01 AM, Gunnar Wagenknecht wrote:

> Greetings Logback developers,
> 
> I'm regularly packaging Logback OSGi bundles for Eclipse Orbit. The
> other day I was wondering if the current core vs. classic split of
> Logback is really useful for people, i.e. is anybody out there using
> _just_ Logback core without any of the classic pieces?
> 
> For example, PatternLayout is classic but the file appenders are in
> core. Isn't PatternLayout an essential logging element? Also, when an
> issue in the XML/Groofvy configuration implementation is detected, a
> full new release of core+classic is required. Wouldn't it be better if
> the parts could evolve independent?
> 
> Thus, I was thinking of a more fine grained split based on functional
> units. For example like this:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jose David Barrio (JIRA | 2 Sep 2010 13:37
Picon

[JIRA] Created: (LBCORE-166) RenameUtil not truncating file if delete fails during rollover

RenameUtil not truncating file if delete fails during rollover
--------------------------------------------------------------

                 Key: LBCORE-166
                 URL: http://jira.qos.ch/browse/LBCORE-166
             Project: logback-core
          Issue Type: Bug
          Components: Rolling
    Affects Versions: 0.9.24
         Environment: Microsoft Windows XP SP2
OAS 10.1.3.4
Java 1.5.0_14
            Reporter: Jose David Barrio
            Assignee: Logback dev list
            Priority: Minor
         Attachments: RenameUtil.patch

When using logback under Windows over Oracle Application Server, if you redeploy the web application, the
log file is keep open by some reason so when a new rollover happens it fails to rename the log file.

Currently RenameUtil does:
- Try to rename log file.
- If rename fails then rename by copy (copy plus delete).

If for some reason deletion fails the log file keeps all its content so I just added a truncate if deletion fails:
- Try to rename log file.
- If rename fails then rename by copy (copy plus delete).
- If delete fails then truncate file.

I do have a patch file if it's useful.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Jose David Barrio (JIRA | 2 Sep 2010 13:37
Picon

[JIRA] Updated: (LBCORE-166) RenameUtil not truncating file if delete fails during rollover


     [
http://jira.qos.ch/browse/LBCORE-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jose David Barrio updated LBCORE-166:
-------------------------------------

    Attachment: RenameUtil.patch

> RenameUtil not truncating file if delete fails during rollover
> --------------------------------------------------------------
>
>                 Key: LBCORE-166
>                 URL: http://jira.qos.ch/browse/LBCORE-166
>             Project: logback-core
>          Issue Type: Bug
>          Components: Rolling
>    Affects Versions: 0.9.24
>         Environment: Microsoft Windows XP SP2
> OAS 10.1.3.4
> Java 1.5.0_14
>            Reporter: Jose David Barrio
>            Assignee: Logback dev list
>            Priority: Minor
>         Attachments: RenameUtil.patch
>
>
> When using logback under Windows over Oracle Application Server, if you redeploy the web application,
the log file is keep open by some reason so when a new rollover happens it fails to rename the log file.
> Currently RenameUtil does:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ceki Gulcu (JIRA | 3 Sep 2010 14:56
Picon

[JIRA] Moved: (LBACCESS-15) TeeFilter should be disabled in productions systems


     [
http://jira.qos.ch/browse/LBACCESS-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ceki Gulcu moved LBAUDIT-1 to LBACCESS-15:
------------------------------------------

    Project: logback-access  (was: logback-audit)
        Key: LBACCESS-15  (was: LBAUDIT-1)

> TeeFilter should be disabled in productions systems
> ---------------------------------------------------
>
>                 Key: LBACCESS-15
>                 URL: http://jira.qos.ch/browse/LBACCESS-15
>             Project: logback-access
>          Issue Type: New Feature
>            Reporter: Ceki Gulcu
>            Assignee: Logback dev list
>
> Given that TeeFilter is part of web.xml it transpires into production which can be highly undesirable.
> Example:
> <filter>
>   <filter-name>TeeFilter</filter-name>  
>   <filter-class>ch.qos.logback.access.servlet.TeeFilter</filter-class> 
>    <init-param>
>       <param-name>ignoreOnHost</param-name>
>       <param-value>prodHost0, prodHost1</param-value>
>    </init-param>
> </filter>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pavel Mikhalchuk (JIRA | 10 Sep 2010 20:21
Picon

[JIRA] Created: (LBCORE-167) An exception is thrown during the web application startup.

An exception is thrown during the web application startup.
----------------------------------------------------------

                 Key: LBCORE-167
                 URL: http://jira.qos.ch/browse/LBCORE-167
             Project: logback-core
          Issue Type: Bug
          Components: Appender
    Affects Versions: 0.9.24
         Environment: Ubuntu 9.04
            Reporter: Pavel Mikhalchuk
            Assignee: Logback dev list

Appender is configurated the next way:

<appender name="appender class="ch.qos.logback.classic.net.SMTPAppender">
        <SMTPHost>some_host</SMTPHost>
        <BufferSize>10</BufferSize>
        <To>some@...</To>
        <From>som@...</From>
        <Subject>Some subject</Subject>
        <layout class="ch.qos.logback.classic.html.HTMLLayout"/>
        <evaluator class="ch.qos.logback.classic.boolex.OnMarkerEvaluator">
            <marker>Some Marker</marker>
        </evaluator>
        <filter class="ch.qos.logback.core.filter.EvaluatorFilter">
            <evaluator name="MARKER">
                <expression>marker != null &amp;&amp; event.getLevel().toInt() >= WARN</expression>
            </evaluator>
            <OnMatch>ACCEPT</OnMatch>
(Continue reading)

Permalink | Reply | 3 comments |
headers
added by portage for gitosis-gentoo | 10 Sep 2010 22:11
Picon

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.24-13-gbf373eb

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Logback: the generic, reliable, fast and flexible logging framework.".

The branch, master has been updated
       via  bf373eb4461e45e92f26f417bc63cdb1dd2b60e8 (commit)
      from  91b5a954630b626d18bb9cf131490814e63a999d (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=bf373eb4461e45e92f26f417bc63cdb1dd2b60e8
http://github.com/ceki/logback/commit/bf373eb4461e45e92f26f417bc63cdb1dd2b60e8

commit bf373eb4461e45e92f26f417bc63cdb1dd2b60e8
Author: Ceki Gulcu <ceki@...>
Date:   Thu Sep 2 21:33:54 2010 +0200

    Use the correct value for TRACE_INTEGER. This value is used currently
    used only by JaninoEvaluator.

diff --git a/logback-classic/src/main/java/ch/qos/logback/classic/Level.java b/logback-classic/src/main/java/ch/qos/logback/classic/Level.java
index 7a3798e..0cf3246 100644
--- a/logback-classic/src/main/java/ch/qos/logback/classic/Level.java
+++ b/logback-classic/src/main/java/ch/qos/logback/classic/Level.java
 <at>  <at>  -37,7 +37,7  <at>  <at>  public final class Level implements java.io.Serializable {
   public static final Integer WARN_INTEGER = new Integer(WARN_INT);
   public static final Integer INFO_INTEGER = new Integer(INFO_INT);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ceki Gulcu (JIRA | 10 Sep 2010 22:33
Picon

[JIRA] Commented: (LBCORE-167) An exception is thrown during the web application startup.


    [
http://jira.qos.ch/browse/LBCORE-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11823#action_11823
] 

Ceki Gulcu commented on LBCORE-167:
-----------------------------------

You seem to be confusing the documentation for GEventEvaluator with that of JaninoEventEvaluator. The
latter clearly specifies that level is of type int.

> An exception is thrown during the web application startup.
> ----------------------------------------------------------
>
>                 Key: LBCORE-167
>                 URL: http://jira.qos.ch/browse/LBCORE-167
>             Project: logback-core
>          Issue Type: Bug
>          Components: Appender
>    Affects Versions: 0.9.24
>         Environment: Ubuntu 9.04
>            Reporter: Pavel Mikhalchuk
>            Assignee: Logback dev list
>
> Appender is configurated the next way:
> <appender name="appender class="ch.qos.logback.classic.net.SMTPAppender">
>         <SMTPHost>some_host</SMTPHost>
>         <BufferSize>10</BufferSize>
>         <To>some@...</To>
>         <From>som@...</From>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane