[
https://issues.apache.org/jira/browse/LOG4J2-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13723469#comment-13723469
]
Ralph Goers edited comment on LOG4J2-326 at 7/30/13 6:26 AM:
-
[
https://issues.apache.org/jira/browse/LOG4J2-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13723469#comment-13723469
]
Ralph Goers commented on LOG4J2-326:
I'm not entirely sure an enhancement is required.
[
https://issues.apache.org/jira/browse/LOG4J2-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13723448#comment-13723448
]
Sudharma Puranik commented on LOG4J2-314:
-
Ok Thank you [[email protected]]. I wil
Sudharma Puranik created LOG4J2-326:
---
Summary: request to improve the RoutingAppender
Key: LOG4J2-326
URL: https://issues.apache.org/jira/browse/LOG4J2-326
Project: Log4j 2
Issue Type: Impr
I thought about this a little more in the context of avoiding Logger
becoming a kitchen sink.
This is today already a mini-leak in toward kitchen sink-ness due to the
(good IMO) addition of the printf APIs.
The way I see it, if I am a 'classic' programmer, I will not use the fluent
API, and vice-
It is unfortunate that you've already put a lot of work into this.
For me, I am firmly in the "don't do this" camp. (Sorry Nick)
I think a fluent interface would add unnecessary complexity that does not add
any value.
We currently have a single method call that does a bunch of work.
IMO, splitti
Well that's unfortunate. I just finished it. :-( Haven't committed it yet...
I'm not sure what the advantage is to delaying it to 2.1. Is it just to study
it further? I understand "do it" and "don't do it," but I don't understand "do
it later."
I've heard a few "I don't like it fluent" and "I d
I don't see the benefit either...
The goal of a fluent interface is to be able to combine many calls (usually on
different objects) into a chained call that can be on a single line and reads
like English.
The canonical example is: (before)
{code}
private void makeNormal(Customer customer) { Orde
Whoever said this is a 2.1 feature, I concur.
On Mon, Jul 29, 2013 at 5:45 PM, Ralph Goers wrote:
> I actually started to work on this myself several weeks ago and came to
> the conclusion that I just couldn't grasp how it is better - with one
> exception. You can reuse the MessageBuilder and re
I actually started to work on this myself several weeks ago and came to the
conclusion that I just couldn't grasp how it is better - with one exception.
You can reuse the MessageBuilder and replace the message or arguments, etc. But
that seems dangerous as it wouldn't be thread safe.
Ralph
On
On Mon, Jul 29, 2013 at 4:54 PM, Paul Benedict wrote:
> Flogger. Very nice... or painful.
>
It was just shorthand, but I'm not a fan of a fluent interface here, so I
would not want it to clutter the API, especially when I think of crowding
an auto-complete pop-up in an IDE.
I am wondering how n
On Jul 29, 2013, at 3:54 PM, Paul Benedict wrote:
> Flogger. Very nice... or painful.
Depends on your preferences I suppose. ;-)
> On Jul 29, 2013 3:48 PM, "Gary Gregory" wrote:
> On Mon, Jul 29, 2013 at 4:39 PM, Nick Williams
> wrote:
> I'm working on LOG4J2-242 to add the ability to log flu
Flogger. Very nice... or painful.
On Jul 29, 2013 3:48 PM, "Gary Gregory" wrote:
> On Mon, Jul 29, 2013 at 4:39 PM, Nick Williams <
> [email protected]> wrote:
>
>> I'm working on LOG4J2-242 to add the ability to log fluently. It's going
>> to work something like this:
>>
>> interface
On Mon, Jul 29, 2013 at 4:39 PM, Nick Williams <
[email protected]> wrote:
> I'm working on LOG4J2-242 to add the ability to log fluently. It's going
> to work something like this:
>
> interface Logger:
> + MessageBuilder trace();
> + MessageBuilder debug();
> + MessageBuil
I'm working on LOG4J2-242 to add the ability to log fluently. It's going to
work something like this:
interface Logger:
+ MessageBuilder trace();
+ MessageBuilder debug();
+ MessageBuilder info();
+ MessageBuilder warn();
+ MessageBuilder error();
+ MessageBuilder fatal();
[
https://issues.apache.org/jira/browse/LOG4J2-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved LOG4J2-325.
-
Resolution: Fixed
{noformat}
commit -m "[LOG4J2-325] Update JDBC tests to use H2 database 1.3.173
Gary Gregory created LOG4J2-325:
---
Summary: Update JDBC tests to use H2 database 1.3.173 from 1.3.172
Key: LOG4J2-325
URL: https://issues.apache.org/jira/browse/LOG4J2-325
Project: Log4j 2
Issue
[
https://issues.apache.org/jira/browse/LOG4J2-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-317:
Description:
FastFileAppender and FastRollingFileAppender need more descriptive names.
Suggestions
[
https://issues.apache.org/jira/browse/LOG4J2-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-317:
Summary: Rename FastFileAppender and FastRollingFileAppender to
RandomAccessFileAppender and Rollin
[
https://issues.apache.org/jira/browse/LOG4J2-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved LOG4J2-317.
-
Resolution: Fixed
Assignee: Gary Gregory
{noformat}
commit -m "[LOG4J2-317] Rename FastFile
ah! good one Paul! In progress...
Gary
On Mon, Jul 29, 2013 at 11:18 AM, Paul Benedict wrote:
> The only rule is that you have to rename the class fast.
>
>
> On Mon, Jul 29, 2013 at 10:03 AM, Remko Popma wrote:
>
>> Ok. (Phew :-))
>> It'd be great if you could take care of that one, thanks!
>
The only rule is that you have to rename the class fast.
On Mon, Jul 29, 2013 at 10:03 AM, Remko Popma wrote:
> Ok. (Phew :-))
> It'd be great if you could take care of that one, thanks!
>
> --
> * From: * Gary Gregory ;
> * To: * Log4J Developers List ;
> * Subject
Ok. (Phew :-))
It'd be great if you could take care of that one, thanks!
Arg! You are correct!
Gary
On Mon, Jul 29, 2013 at 10:51 AM, Remko Popma wrote:
> Surely you mean RandomAccessFileAppender?
> (The Fast*Appenders have nothing to do with sync/async.)
>
> --
> * From: * Gary Gregory ;
> * To: * Log4J Developers List ;
> * Subject: *
Surely you mean RandomAccessFileAppender?
(The Fast*Appenders have nothing to do with sync/async.)
I think it's been long enough, I plan on renaming "Fast*" to "Async*"
Gary
On Mon, Jul 22, 2013 at 3:54 PM, Gary Gregory wrote:
> A JIRA is tracking the list of new candidate class names.
>
> Gary
>
>
> On Mon, Jul 22, 2013 at 2:47 PM, Paul Benedict wrote:
>
>> Was there any conclusion to this?
What a mess :( it seem unlikely new APIs will be added to Java 8 to help
us, at least based on comments like
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019110.html
We might be left with documenting our side with "if you use features x and
y in this context then the speed will d
Jörn,
Thanks for chiming in with that very useful information. I have passed it on to
the core-libs-dev list.
I am doing my best to stay on top of these guys and try to get a solution
agreed upon. The thing that concerns me is that we have already passed "Feature
Complete" (which, of course, h
I'm highly concerned about speed.
The workaround in the logback pull-request has some benchmarks regarding
alternative ways to get the required info and those are quite shocking:
> This solution was found from
> http://stackoverflow.com/questions/421280/in-java-how-do-i-find-the-caller-of-a-met
[
https://issues.apache.org/jira/browse/LOG4J2-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1371#comment-1371
]
Remko Popma edited comment on LOG4J2-324 at 7/29/13 7:14 AM:
-
[
https://issues.apache.org/jira/browse/LOG4J2-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1371#comment-1371
]
Remko Popma commented on LOG4J2-324:
I see. In that case the statusLevel idea is still
31 matches
Mail list logo
