[jira] Commented: (LOG4J2-6) log4j 2.0 should support all capabilities of java.util.logging.
[ https://issues.apache.org/jira/browse/LOG4J2-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867818#action_12867818 ] Ralph Goers commented on LOG4J2-6: -- In my experimental branch I provide the methods such as entry, exit, etc that JUL supports. I also support the class, method and line number. > log4j 2.0 should support all capabilities of java.util.logging. > --- > > Key: LOG4J2-6 > URL: https://issues.apache.org/jira/browse/LOG4J2-6 > Project: Log4j 2 > Issue Type: Wish > Components: Core >Reporter: Curt Arnold > > Applications that use the java.util.logging API with log4j 2.0 appenders et > al should not lose any capabilities that the would have if they had used a > native java.util.logging.Handler. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] Commented: (LOG4J2-7) Java 5 idioms should be used in preference to earlier Java idioms
[ https://issues.apache.org/jira/browse/LOG4J2-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867817#action_12867817 ] Ralph Goers commented on LOG4J2-7: -- In my experimental branch I make heavy use of Java 5 constructs. > Java 5 idioms should be used in preference to earlier Java idioms > - > > Key: LOG4J2-7 > URL: https://issues.apache.org/jira/browse/LOG4J2-7 > Project: Log4j 2 > Issue Type: Wish >Reporter: Curt Arnold > > Typed collections should be used in preference to untyped collections, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [jira] Commented: (LOG4J2-33) Support Annotations
Den 15/05/10 08.29, Ralph Goers (JIRA) skrev: My experimental branch uses annotations for Logj components, but still does not address my desire to allow applications to inject logging. Annotations are just meta-information. You will need the classloader to take special action on them for anything to happen. I am cracking the nut of how to get "@Inject Logger log" to work properly with slf4j in a JEE 6 setting - I believe it is a case of a correctly placed @Producer. Is this similar to what you want to solve? -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!" - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] Commented: (LOG4J2-9) log4j 2.0 should leverage existing (preferably ASF) configuration frameworks
[ https://issues.apache.org/jira/browse/LOG4J2-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867816#action_12867816 ] Ralph Goers commented on LOG4J2-9: -- In my experimental branch the configuration is pluggable. I investigated using other frameworks but adding a dependency really isn't worth the cost (and risk that the framework will somehow create a circularity problem). In the end the configuration I implemented is extremely simple. > log4j 2.0 should leverage existing (preferably ASF) configuration frameworks > > > Key: LOG4J2-9 > URL: https://issues.apache.org/jira/browse/LOG4J2-9 > Project: Log4j 2 > Issue Type: Wish > Components: Configurators >Reporter: Curt Arnold > > log4j 2.0 should avoid implementing its own configuration framework in > preference to being compatible with commonly used configuration frameworks > and services. Compatibility with existing log4j 1.2 configuration files > might be accomplished by XSLT transforms that convert the legacy format into > the equivalent with the selected configuration framework. log4j 2.0 should > be readily configurable with JMX and a JMX centric design for configuration > may be desirable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] Commented: (LOG4J2-14) log4j 2.0 development initation
[ https://issues.apache.org/jira/browse/LOG4J2-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867815#action_12867815 ] Ralph Goers commented on LOG4J2-14: --- Isn't this done? > log4j 2.0 development initation > --- > > Key: LOG4J2-14 > URL: https://issues.apache.org/jira/browse/LOG4J2-14 > Project: Log4j 2 > Issue Type: Task >Reporter: Curt Arnold > > Start of log4j/branches/BRANCH_2_0_EXPERIMENTAL from sandbox pattern-layout > experiment from 2007 and other project initiation tasks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] Commented: (LOG4J2-17) Provide enhanced logger filtering support.
[ https://issues.apache.org/jira/browse/LOG4J2-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867814#action_12867814 ] Ralph Goers commented on LOG4J2-17: --- In my experimental branch I have enhanced Filters so that they can be configured globally as well as on a logger in addition to on an appender. The branch contains a couple of example filters. > Provide enhanced logger filtering support. > -- > > Key: LOG4J2-17 > URL: https://issues.apache.org/jira/browse/LOG4J2-17 > Project: Log4j 2 > Issue Type: New Feature > Components: Core >Reporter: Ralph Goers > > We wrote our own logging framework primarily because log4j didn't provide > some of the features we needed. Our software runs on behalf of many > companies, products and users all in the same JVM. We have a requirement to > be able to enable logging based on some of these factors. For example, we > might want to enable debug logging only for a specific company or even a > specific user. All our requests store attributes, such as the companyId, > product name and userid in the MDC. > So the real requirement here is to be able to filter log records early based > on more information than just the log level. For example, our requirement > could be met by a filter that could be configured to associate a log level > with a company id. Then when debug is called a check would first be done to > see if debug was enabled for that company id and then whether debug was > enabled for that logger. These checks cannot be done as filters on Appenders > as the performance of the system is dramatically impacted as isDebugLogging > really needs to return false for all company ids other than the one that is > enabled. > This feature is similar to LogBack's TurboFilter, except I would like it > implemented differently. I would recommend that the filter be specified > globally but referenced on each logger to which it applies, much as the > specification of Appenders is done. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] Commented: (LOG4J2-19) Provide looser coupling of PatternConverters
[ https://issues.apache.org/jira/browse/LOG4J2-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867813#action_12867813 ] Ralph Goers commented on LOG4J2-19: --- In my experimental branch I used plugins to accomplish this. A converter provides to annotations, one to declare it as a converter plugin and one to identify the keys that it matches on. > Provide looser coupling of PatternConverters > > > Key: LOG4J2-19 > URL: https://issues.apache.org/jira/browse/LOG4J2-19 > Project: Log4j 2 > Issue Type: Improvement > Components: Layouts >Reporter: Ralph Goers > > Currently, PatternLayout calls PatternParser which knows about the various > PatternConverters, many of which are imbedded in it. This makes it difficult > for users to add their own Converters. > In the logging framework I created each converter identified the conversion > characters it supported. Each PatternConverter was required to supply a > getKeys() method that returned this list. The equivalent of the PatternLayout > contained an array of PatternConverters. During initialization each of these > would be called and the list of keys recorded along with the associated > converter. To add your own converter all that was necessary was to extend the > class and add your new keys to the list of recorded keys along with their > converters. The base PatternLayout would then take care of calling the > correct converters as necessary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] Commented: (LOG4J2-20) log4j 2 should have clean separation of configuration from function
[ https://issues.apache.org/jira/browse/LOG4J2-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867812#action_12867812 ] Ralph Goers commented on LOG4J2-20: --- In my experimental branch the configuration is separate from the loggers returned via LogManager.getLogger(). Once the configuration is active new Loggers (actually LoggerConfig objects) cannot be added to the configuration. Creating a new configuration is done in such a way that Loggers are never in an unconfigured state. However, adding a new Appender or Filter can be done as these operations can be performed safely. > log4j 2 should have clean separation of configuration from function > --- > > Key: LOG4J2-20 > URL: https://issues.apache.org/jira/browse/LOG4J2-20 > Project: Log4j 2 > Issue Type: Test >Reporter: Curt Arnold > > log4j 1.2 does not enforce a clean separation between configuration and > service provision. Some configuration changes take effect immediately, some > only on a call to activateOptions and rarely are they appropriately > synchronized with the service provision. log4j 2.0 should have services > provided by immutable or at least not externally immutable objects and keep > configuration in distinct classes that construct the service providing > instance and then replace the existing service with proper synchronization. > This is related to prefer immutable classes -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] Commented: (LOG4J2-21) LoggingEvent message lost on serialization
[ https://issues.apache.org/jira/browse/LOG4J2-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867811#action_12867811 ] Ralph Goers commented on LOG4J2-21: --- In my experimental branch the log message is an object that implements the Message interface. Message objects extend Serializable. > LoggingEvent message lost on serialization > -- > > Key: LOG4J2-21 > URL: https://issues.apache.org/jira/browse/LOG4J2-21 > Project: Log4j 2 > Issue Type: Wish > Components: Appenders >Reporter: Curt Arnold > > log4j bug 42023 complained that the LoggingEvent serialization did not > attempt to serialize the message object, but only serialized the rendered > message. Whatever serialized forms are supported in log4j 2.0 should provide > the option to transmit a serialized form of the message object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] Commented: (LOG4J2-23) log4j 2.0 should work without an explicit configuration file
[ https://issues.apache.org/jira/browse/LOG4J2-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867810#action_12867810 ] Ralph Goers commented on LOG4J2-23: --- My experimental branch provides a default configuration. In addition, any number of custom configuration implementations can be added via a plugin mechanism. > log4j 2.0 should work without an explicit configuration file > > > Key: LOG4J2-23 > URL: https://issues.apache.org/jira/browse/LOG4J2-23 > Project: Log4j 2 > Issue Type: Wish > Components: log4j 1.2 emulation >Reporter: Curt Arnold > > log4j 1.2 will display a warning and ignores log requests if no configuration > file is found and no explicit configuration is performed. JDK 1.4 logging > has a last-chance configuration file installed in the JDK. log4j 2.0 should > consider delegating to JDK 1.4 logging when no configuration is available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] Commented: (LOG4J2-24) Have an API method that does a deeper evaluation than Logger.isDebugEnabled() of whether logging will occur
[ https://issues.apache.org/jira/browse/LOG4J2-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867809#action_12867809 ] Ralph Goers commented on LOG4J2-24: --- If I understand the issue correctly, this can be addressed by using Filters as implemented in my experimental branch. Filters can be global, on a logger or on an appender. > Have an API method that does a deeper evaluation than Logger.isDebugEnabled() > of whether logging will occur > --- > > Key: LOG4J2-24 > URL: https://issues.apache.org/jira/browse/LOG4J2-24 > Project: Log4j 2 > Issue Type: Wish >Reporter: Curt Arnold > > See https://issues.apache.org/bugzilla/show_bug.cgi?id=45368 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] Commented: (LOG4J2-30) Author tags
[ https://issues.apache.org/jira/browse/LOG4J2-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867808#action_12867808 ] Ralph Goers commented on LOG4J2-30: --- I have removed author tags for the classes in my experimental branch. > Author tags > --- > > Key: LOG4J2-30 > URL: https://issues.apache.org/jira/browse/LOG4J2-30 > Project: Log4j 2 > Issue Type: Wish >Reporter: Curt Arnold >Priority: Minor > > Logging this as a bug so that it eventually gets resolved. > From log4j-dev thread "Future development of log4j 2.0" > On 20/02/2010 12:42 AM, Christian Grobmeier wrote: > there might be other discussions which could > lead to frustrations on several sides. I think on discussions like > having author tags and such. > On Feb 19, 2010, at 5:57 PM, Ceki Gülcü wrote: > Author tags is a way of recognizing contributors. Recognition is a > very important aspect of oss. > --- > Author tags have been discouraged by the board, > http://www.apache.org/foundation/records/minutes/2004/board_minutes_2004_02_18.txt > (section D) > This statement by Dirk-Wlllem van Gulik, then president of the ASF, expands > on the rationale: > http://marc.info/?l=xml-cocoon-dev&m=107787986409413&w=2 > Don't think we need to tackle the issue until there is code someone wants to > tag. I'm not planning on tagging any code that I initially develop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] Commented: (LOG4J2-32) Create a Layout and SyslogAppender that support RFC 5424.
[ https://issues.apache.org/jira/browse/LOG4J2-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867806#action_12867806 ] Ralph Goers commented on LOG4J2-32: --- My experimental branch provides the layout for RFC 5424. I have not added the SyslogAppender yet. > Create a Layout and SyslogAppender that support RFC 5424. > - > > Key: LOG4J2-32 > URL: https://issues.apache.org/jira/browse/LOG4J2-32 > Project: Log4j 2 > Issue Type: New Feature > Components: Appenders >Reporter: Ralph Goers > Fix For: 0.1 > > > RFC 5424 (http://tools.ietf.org/html/rfc5424) was made a standard in March of > 2009. Log4j 2.0 should provide a Layout and SyslogAppender that implements > this standard. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] Commented: (LOG4J2-31) The Logging API should support a Message object
[ https://issues.apache.org/jira/browse/LOG4J2-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867807#action_12867807 ] Ralph Goers commented on LOG4J2-31: --- This is implemented on my experimental branch > The Logging API should support a Message object > --- > > Key: LOG4J2-31 > URL: https://issues.apache.org/jira/browse/LOG4J2-31 > Project: Log4j 2 > Issue Type: New Feature > Components: API >Reporter: Ralph Goers > Fix For: 0.1 > > > RFC 5424 defines StructuredData. While implementing this for Logback it was > found that making SLF4J support a Message interface and then providing > Message definitions for a "SimpleMessage" (message text only), > "ParamaterizedMessage" (message plus substitution parameters) and > StructuredDataMessage (a message that allows the formatted message to conform > to RFC 5424) allows the API to be easily extendable with new Message types > and makes it more efficient to pass them through the logging implementation. > Log4j 2.0 should incorporate this into both the API and the implementation. > This will allow for easy implementation of a SyslogAppender that conforms > with the new Syslog specification (see http://tools.ietf.org/html/rfc5424) as > well as using the RFC 5424 as a standard layout that can be used to transport > messages via JMS or other protocols. > See http://github.com/rgoers/slf4j and http://github.com/rgoers/logback for > examples of how I accomplished this for slf4j & logback. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] Commented: (LOG4J2-33) Support Annotations
[ https://issues.apache.org/jira/browse/LOG4J2-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867805#action_12867805 ] Ralph Goers commented on LOG4J2-33: --- My experimental branch uses annotations for Logj components, but still does not address my desire to allow applications to inject logging. > Support Annotations > --- > > Key: LOG4J2-33 > URL: https://issues.apache.org/jira/browse/LOG4J2-33 > Project: Log4j 2 > Issue Type: New Feature > Components: API >Reporter: Ralph Goers > Fix For: 0.1 > > > The Log4j API should support using annotations as provided in Java 6 so > applications can use them instead of calls to logger APIs. This is especially > useful for entering & exiting type of events, but could be used wherever > annotations are allowed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: companions release
I think I'm in the home stretch of the features I'd like to get in to this Chainsaw release, so I have cycles to help get companions out the door if needed. Anything I can help with? Scott On Tue, May 4, 2010 at 7:16 PM, Curt Arnold wrote: > Need to back port some of the later fixes in the log4j 1.2.16 release back > into the extras companion. Other than that I don't know of anything. > > I've got some evenings free later this week and was going to try to clean > up some post 1.2.16 issues. > > > On May 4, 2010, at 12:04 AM, Scott Deboy wrote: > > > Are there any outstanding issues preventing us from moving forward with a > release of the companions? > > > > Scott > > > - > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > >
Re: svn commit: r943816 [1/9] - in /logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers: ./ log4j12-api/ log4j12-api/src/ log4j12-api/src/main/ log4j12-api/src/main/java/ log4j12-api/src/main/java/o
On May 14, 2010, at 8:41 PM, Ralph Goers wrote: > See below. > > On May 14, 2010, at 7:07 AM, Curt Arnold wrote: > >> Could you review the "bugs" in the log4j2 JIRA and give a quick comments >> about your submission and the bug. > > Sure. I'll try to do this asap but my time to work on Log4j isn't very > consistent. Same here. > >> >> If there are any significant design decisions or requirements that came out >> from this work, could you file them as new bugs. > > Be happy to. >> >> Did you use or consider the earlier pattern layout stuff I did in the >> sandbox? > > As I mentioned in my earlier email, I used the EnhancedPatternLayout that is > in the experimental branch as a starting point. I changed the name back to > PatternLayout and made that a plugin and made all the converters plugins. I > also modified a couple of the converters where it was neeed. > I didn't recall naming it EnhancedPatternLayout, been a long time since I looked at it. - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: svn commit: r943816 [1/9] - in /logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers: ./ log4j12-api/ log4j12-api/src/ log4j12-api/src/main/ log4j12-api/src/main/java/ log4j12-api/src/main/java/o
See below. On May 14, 2010, at 7:07 AM, Curt Arnold wrote: > Could you review the "bugs" in the log4j2 JIRA and give a quick comments > about your submission and the bug. Sure. I'll try to do this asap but my time to work on Log4j isn't very consistent. > > If there are any significant design decisions or requirements that came out > from this work, could you file them as new bugs. Be happy to. > > Did you use or consider the earlier pattern layout stuff I did in the sandbox? As I mentioned in my earlier email, I used the EnhancedPatternLayout that is in the experimental branch as a starting point. I changed the name back to PatternLayout and made that a plugin and made all the converters plugins. I also modified a couple of the converters where it was neeed. > > Do you have or want to suggest a code name for this submission? I wanted to > avoid ever calling my earlier stuff "log4j2" while it was still highly > experimental. I'm not sure why that is a problem. It isn't like anyone is going to confuse this for a releasable code base being in a branch named "EXPERIMENTAL" and in a subdirectory named ralph. If it does get pulled up to a real dev branch then we won't have to go through the busy work of package renaming. Referencing it in emails as "Ralph's Log4j2" vs "Curt's Log4j2" should be enough to avoid any confusion. And hopefully, the experimentation phase won't last too long before creating a common code base (although I'd still expect people to fork that while they try new things - this is one of the areas where using github would really help). Ralph - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: svn commit: r943816 [1/9] - in /logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers: ./ log4j12-api/ log4j12-api/src/ log4j12-api/src/main/ log4j12-api/src/main/java/ log4j12-api/src/main/java/o
Could you review the "bugs" in the log4j2 JIRA and give a quick comments about your submission and the bug. If there are any significant design decisions or requirements that came out from this work, could you file them as new bugs. Did you use or consider the earlier pattern layout stuff I did in the sandbox? Do you have or want to suggest a code name for this submission? I wanted to avoid ever calling my earlier stuff "log4j2" while it was still highly experimental. - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: svn commit: r943816 [1/9] - in /logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers: ./ log4j12-api/ log4j12-api/src/ log4j12-api/src/main/ log4j12-api/src/main/java/ log4j12-api/src/main/java/o
On May 14, 2010, at 2:01 AM, Thorbjørn Ravn Andersen wrote: > Den 14/05/10 09.22, Ralph Goers skrev: >> 2. I don't like the way Logback binds to the implementation. I used a >> technique I had used in a previous logging framework and used a file to >> define the implementation class. In theory, the API could be modified to >> support multiple logging implementation simultaneously, although I have no >> plans to implement that. >> > You mean slf4j binding to logback? Technically, SLF4J binding to any implementation. But yes, Logback is usually the implementaion. Ralph - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: svn commit: r943816 [1/9] - in /logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers: ./ log4j12-api/ log4j12-api/src/ log4j12-api/src/main/ log4j12-api/src/main/java/ log4j12-api/src/main/java/o
Den 14/05/10 09.22, Ralph Goers skrev: 2. I don't like the way Logback binds to the implementation. I used a technique I had used in a previous logging framework and used a file to define the implementation class. In theory, the API could be modified to support multiple logging implementation simultaneously, although I have no plans to implement that. You mean slf4j binding to logback? I think the work done with standardizing the Seam approach in JEE 6 (which I am reading up on) will benefit also slf4j, since it will basically handle the API->implementation binding, so that the logging framework will not have to. 7, All internal components use the logger API for status reporting. A specific StatusLogger provides the implementation. I like that. It is nice that you can use logging even if you are coding stuff inside a logger. -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!" - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: svn commit: r943816 [1/9] - in /logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers: ./ log4j12-api/ log4j12-api/src/ log4j12-api/src/main/ log4j12-api/src/main/java/ log4j12-api/src/main/java/o
Thanks for trying it out. I hadn't actually built from the root - I've built
the api and core separately - so I'm glad you were able to fix those problems.
I didn't want to commit code until I had the core of something that actually
functioned. I struggled for a couple of weeks over how to attack
XMLConfiguration. I don't like the way Logback does it, I didn't want to bring
in baggage from a third party framework, JAXB isn't a good fit either. In
short, I wanted something that can be extended without needing to add "rules"
to the XML processor. See below for what I came up with.
First, while I looked at Log4j and somewhat at Logback, most of the core code
is completely new. The exception to this is with the Converters for the
PatternLayout. I took the EnhancedPatternLayout and modified it.
1. I first created an API that had the features I was looking for. That is in
log4j2-api. While it supports logging a String or an Object it really uses a
Message interface which is valuable as it allows users to log self-describing
objects in a convenient manner.
2. I don't like the way Logback binds to the implementation. I used a technique
I had used in a previous logging framework and used a file to define the
implementation class. In theory, the API could be modified to support multiple
logging implementation simultaneously, although I have no plans to implement
that.
3. Logback suffers from a serious architectural problem that is rooted in
Log4j. The configured loggers are mixed with the loggers returned from the
Logger factory. This makes it impossible to reconfigure atomically. With
Logback the reset method is called on the context which essentially causes the
system to be in an undefined state until the new configuration is completed
(log records that should be logged are lost). To solve this I used a design
that I again borrowed from my previous framework. The configuration is
separated and on a reconfiguration the new configuration will be created and
then all the loggers will be updated to use it. While there will be a period
where some loggers are using the old configuration and some the new there is
never a point where loggers aren't configured at all.
4. Similar to Logback I added support for Markers and global filters. In
addition, filters on Loggers are also supported. Unlike Logback, there is only
a single Filter interface used for global filters, logger filters and appender
filters.
5. The XMLConfiguration is extremely simple. All it does is read the XML and
convert the DOM structure to internal Node elements, which contain the node
attributes, child node references and placeholders for the real object when it
is constructed. It uses the XML element name to match to a Plugin, so instead
of writing:
you write:
%-5p %c{1} - %m%n
Note that it also would support
console
SYSTEM_OUT
%-5p %c{1} - %m%n
if you prefer using elements over attributes.
5. I implemented a "Plugin" concept. All core components use annotations to
describe their name and type. This is used by the XML configuration to
determine the element names that are used in the configuration file.
a) Plugins are used for Logger, Appenders, Filters, etc. The BaseConfiguration
processes the nodes created by XMLConfiguration and saves the resulting Objects
as appropriate.
b) PatternLayout uses plugins for the converters. To add a new converter an end
user just needs to create the class with the correct annotation and add the
package name to the XML configuration as an attribute.
c) Configuration uses plugins to determine the Configuration implementation to
use. The XMLConfiguration and DefaultConfiguration will always be present, but
a weight can be specified to allow the new Configuration to take precedence.
Again, simply placing the Configuration class (with the appropriate
annotations) in the classpath will cause it to be used. However, if it is in a
different package that package will have to be registered to be searched either
by calling a static method on the PluginManager or via a system property (which
hasn't been implemented yet).
6. java.util.concurrent is used where appropriate. Accordingly, minimal locking
takes place. No lock is held while Appenders are called which is a serious bug
in Log4j 1.x as it causes deadlocks.
7, All internal components use the logger API for status reporting. A specific
StatusLogger provides the implementation.
8. Layouts return a byte array. In Logback Ceki recently came up with the idea
of using encoders to allow binary data streams to be sent and received. While
the requirement seems valid it seemed awkward to wrap a Layout in an encoder.
9. Obviously, everything leverages Java 5 (and might possibly require Java 6
since that is the JVM I've been using).
The API is not compatible with log4j 1.x. My intention would be to create a
compatible API (to the degree possible) in a log4j12-api packag
