[
https://issues.apache.org/jira/browse/LOG4J2-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma reassigned LOG4J2-500:
--
Assignee: Remko Popma
> Unloading one webapp unloads JMX MBeans for all webapps
> -
[
https://issues.apache.org/jira/browse/LOG4J2-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma reopened LOG4J2-492:
> MalformedObjectNameException: Invalid escape sequence... under Jetty
> --
[
https://issues.apache.org/jira/browse/LOG4J2-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13883867#comment-13883867
]
Remko Popma commented on LOG4J2-500:
Not yet. Should be fairly straight-forward. I'll
[
https://issues.apache.org/jira/browse/LOG4J2-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-452.
--
Resolution: Fixed
Fix Version/s: 2.0-rc1
The rest of this has been fixed with r1561958,
[
https://issues.apache.org/jira/browse/LOG4J2-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13883857#comment-13883857
]
Nick Williams commented on LOG4J2-500:
--
Remko, have you had a chance to look at this
[
https://issues.apache.org/jira/browse/LOG4J2-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-512.
--
Resolution: Fixed
Fix Version/s: 2.0-rc1
Fixed with r1561956. This exposes the web suppo
[
https://issues.apache.org/jira/browse/LOG4J2-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13883845#comment-13883845
]
Nick Williams commented on LOG4J2-452:
--
Partially fixed with r1561956 in that the fil
I've started to work on implementing a source code generator along the
lines described below.
Does anyone disagree with this approach?
I was thinking to name the tools Generate$ExtendedLogger and
Generate$CustomLogger and put the Generate class in the log4j-api project
under org.apache.logging.
[
https://issues.apache.org/jira/browse/LOG4J2-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13883793#comment-13883793
]
Ralph Goers commented on LOG4J2-410:
I don't consider it a blocker but it should be a
[
https://issues.apache.org/jira/browse/LOG4J2-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams reassigned LOG4J2-512:
Assignee: Nick Williams
> Log4j2 need to support Asynchronous Servlets/ Servlet 3.0 while a
[
https://issues.apache.org/jira/browse/LOG4J2-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13883792#comment-13883792
]
Nick Williams commented on LOG4J2-410:
--
Should we take some action on this before RC1
[
https://issues.apache.org/jira/browse/LOG4J2-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams reassigned LOG4J2-452:
Assignee: Nick Williams
> Log4j2 should not automatically start in Servlet 3.0
> --
[
https://issues.apache.org/jira/browse/LOG4J2-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-409.
--
Resolution: Fixed
Fix Version/s: 2.0-rc1
Thanks for the help identifying the problem and
[
https://issues.apache.org/jira/browse/LOG4J2-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-344.
--
Resolution: Fixed
Fix Version/s: 2.0-rc1
Sorry for the delay. This has been fixed with r
The @doubts were thoughts between Curt Arnold and me after I made the initial
code commits for Log4j 2. Unfortunately, we haven’t heard from Curt in a while
so I am afraid those won’t get resolved that way. At this point I think it
would be fair to say any @doubt comments that are remaining ca
More thoughts on CustomLogger/ExtendedLogger source code generation:
Perhaps I was overcomplicating things...
Why don't we generate source for a concrete class instead of an
interface+implementation?
If users want to /extend/ Logger, this class would extend
AbstractLoggerWrapper (which has the
[
https://issues.apache.org/jira/browse/LOG4J2-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-359.
--
Resolution: Fixed
This is fixed with r1561933. Unfortunately, WebLogic is simply not spec
comp
And here is the link from the last time you brought it up.
http://marc.info/?t=13778880756&r=1&w=2
My position hasn’t changed, leave them as they are.
Ralph
On Jan 27, 2014, at 5:47 PM, Gary Gregory wrote:
> Hi All,
>
> I think I brought this up a long time ago but I thought I'd give
[
https://issues.apache.org/jira/browse/LOG4J2-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams updated LOG4J2-242:
-
Attachment: LOG4J2-242.patch
I meant to attach this patch ages ago and never did it. These are my
The JavaDoc for Logger has "@doubt See LOG4J2-16" in it. Anybody know what this
is about? Can the doubt be removed?
N
-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: log4j-dev-h
Ok, that's how I thought it was used. I've seen some convoluted logging
frameworks before (eCommerce can suck it) that require logging guards for
level filters to even work in the first place.
On 27 January 2014 20:21, Paul Benedict wrote:
> Matt, it is not always necessary. The logic is only n
It's only necessary to guard logging statements like that when some additional
processing is required before the logging method is called. For example:
logger.info("Some info statement");
That's always efficient. But:
logger.info("Some info {} statement {}", request.getHeader("header1"),
reque
Matt, it is not always necessary. The logic is only needed is your method
call is doing preformatting or some other heavy calculation. There is no
need to incur the expense if the log level is disabled.
On Jan 27, 2014 8:06 PM, "Matt Sicker" wrote:
> I like the shorter version better. Is it alway
I like the shorter version better. Is it always absolutely necessary to
guard logging statements like that, though? Or only to save on the
unnecessary processing when that level is disabled?
On 27 January 2014 19:47, Gary Gregory wrote:
> Hi All,
>
> I think I brought this up a long time ago bu
[
https://issues.apache.org/jira/browse/LOG4J2-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13883655#comment-13883655
]
Matt Sicker commented on LOG4J2-33:
---
No, you're perfectly correct. I'm not sure how to go
Hi All,
I think I brought this up a long time ago but I thought I'd give it a
refresh since we have a lot more voices participating in conversations.
Yes, I am aware of making source compatibility simple for porting from
version 1 but this is a naming issue that's always displeased me.
I find the
[
https://issues.apache.org/jira/browse/LOG4J2-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13883628#comment-13883628
]
Gary Gregory edited comment on LOG4J2-33 at 1/28/14 1:41 AM:
-
W
[
https://issues.apache.org/jira/browse/LOG4J2-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13883628#comment-13883628
]
Gary Gregory commented on LOG4J2-33:
What I do not like about the patch is that it crea
I agree with that, but that doesn’t mean we can’t add new stuff to the API.
Ralph
On Jan 27, 2014, at 2:08 PM, Gary Gregory wrote:
> IMO: We cannot/should not break binary compatibility without a major release
> change (and accompanying package and Maven coordinate changes).
>
> Gary
>
>
>
That makes sense. Thanks Gary and Nick for clarifying my statement.
On Tue, Jan 28, 2014 at 7:21 AM, Nick Williams <
[email protected]> wrote:
> I'm fine with an RC this week and a GA one month later. I think that's
> perfect. I agree with Remko that we can have API /additions/ in 2.
I'm fine with an RC this week and a GA one month later. I think that's perfect.
I agree with Remko that we can have API /additions/ in 2.1 (or, at any time,
IMO), but I agree with Gary that we can't have binary compatibility-breaking
changes until 3.0.
N
On Jan 27, 2014, at 4:08 PM, Gary Grego
IMO: We cannot/should not break binary compatibility without a major
release change (and accompanying package and Maven coordinate changes).
Gary
On Mon, Jan 27, 2014 at 4:59 PM, Remko Popma wrote:
> How about an RC now (after showstoppers are fixed),
> then the GA release say one month later?
How about an RC now (after showstoppers are fixed),
then the GA release say one month later?
Keep in mind we can still have bugix releases in 2.0.1, etc, and even API
changes in 2.1 etc...
On Tuesday, January 28, 2014, Matt Sicker wrote:
> I agree on putting out an RC release. I think it might
I agree on putting out an RC release. I think it might help spur some 3rd
party development to integrate with the new version.
On 27 January 2014 12:37, Gary Gregory wrote:
> So, yes, the new level API needs to go through a non-GA release. Aside
> from that, I am behind in my Log4j2 homework to
On Mon, Jan 27, 2014 at 2:15 PM, Nick Williams <
[email protected]> wrote:
> I would veto such a change, and here is my technical justification:
>
> You will break EVERYTHING currently using the Log4j 2 API.
>
> EVERYTHING that EVERY Log4j 2 user has currently written will have to be
>
I would like to see SimpleLogger be where custom interfaces are extended.
Now you can't forget that if we provide a default implementation class,
that will already implement Logger. So it's very easy to cast directly to
Logger if necessary to access your standard methods.
On Mon, Jan 27, 2014 at
Okay, I see now. I got confused by what Gary said:
> That's brilliant! The Logger interface contains methods like log(Level, ...)
> and StandardLogger extends Logger to provide info(), warn() and so on.
>
> This let's me create a custom Logger (DEFCON example) AND an extension to
> StandardLogg
>
> On Jan 27, 2014, at 11:15 AM, Nick Williams
> wrote:
>
> However, what I WOULD be okay with is creating a SimpleLogger interface
> for things like log(Level, ...), etc. and having Logger extend SimpleLogger
> to provide info(), warn(), and so on. This would be backwards compatible
> and abide
Nick, I don't understand your objection. I was not proposing replacing
Logger. All I said was extract out a superinterface. Keep Logger usage how
it is now, if you want -- and what I am recommending.
On Mon, Jan 27, 2014 at 1:15 PM, Nick Williams <
[email protected]> wrote:
> I would
Yeah, I was thinking the same thing as you.
Ralph
On Jan 27, 2014, at 11:15 AM, Nick Williams
wrote:
> I would veto such a change, and here is my technical justification:
>
> You will break EVERYTHING currently using the Log4j 2 API.
>
> EVERYTHING that EVERY Log4j 2 user has currently writt
I would veto such a change, and here is my technical justification:
You will break EVERYTHING currently using the Log4j 2 API.
EVERYTHING that EVERY Log4j 2 user has currently written will have to be
changed to use StandardLogger instead of Logger. That's not even considering
the fact that Logg
On Mon, Jan 27, 2014 at 10:24 AM, Paul Benedict wrote:
> I propose this:
>
> 1) If you are willing to view standard levels as a type of DSL, then you
> should refactor the Logger interface to separate those concerns. Create a
> new superinterface that contains everything else. This is what custom
So, yes, the new level API needs to go through a non-GA release. Aside from
that, I am behind in my Log4j2 homework to see how much work it will be to
convert our Log4j1 code and extensions to v2. But that's just an issue on
my end that should not hold up everyone else.
I've been out of 100% commi
This part of the conversation should actually be happening in the "Using Custom
Levels with a Custom/Wrapper Interface" thread.
Nick
On Jan 27, 2014, at 12:17 PM, Gary Gregory wrote:
> Yes that's the idea.
>
> Gary
>
>
> Original message
> From: Ralph Goers
> Date:01/27/2
Yes that's the idea.
Gary
Original message
From: Ralph Goers
Date:01/27/2014 11:19 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Enums and Custom Levels - completed.
If the user creates a custom Logger Wrapper then they can just code against
that and not use an i
Brian created LOG4J2-518:
Summary: Logging of nested list uses incorrect charset
Key: LOG4J2-518
URL: https://issues.apache.org/jira/browse/LOG4J2-518
Project: Log4j 2
Issue Type: Bug
Compo
If people really thing that another non-GA release is necessary, please
label it RC.
Beta sounds as log4j2 is absolutely not ready but this isn't the case.
At least with a RC we show some confidence in what we do.
As additions are easier to make then removals, I would even sacrifice
something
It's OK for a custom logger interface to extend Logger as long as the
framework provides a stock implementation of the Logger interface. You want
your customers to easily subclass existing code and not create the entire
implementation from scratch. If you guys can make the Logger Implementation
par
Due to the API change I can agree with having another beta or an RC but the
reason I asked about GA is that I am not aware of very many showstopper issues
that need to be addressed. I am sensing that you have a real reluctance to
have Log4j 2 released as GA and I am trying to understand what th
If the user creates a custom Logger Wrapper then they can just code against
that and not use an interface, correct?
Ralph
On Jan 27, 2014, at 6:40 AM, Nick Williams
wrote:
> Wrapping a logger /implementation/ is fine. But the user needs an /interface/
> to program against. That interface sho
[
https://issues.apache.org/jira/browse/LOG4J2-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma closed LOG4J2-517.
--
> Switch in log4j-1.2-api Category.getEffectiveLevel misses FATAL, OFF
> --
[
https://issues.apache.org/jira/browse/LOG4J2-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved LOG4J2-517.
Resolution: Fixed
Fixed in revision 1561715.
> Switch in log4j-1.2-api Category.getEffectiveLevel
[
https://issues.apache.org/jira/browse/LOG4J2-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma reassigned LOG4J2-517:
--
Assignee: Remko Popma
> Switch in log4j-1.2-api Category.getEffectiveLevel misses FATAL, OFF
>
[
https://issues.apache.org/jira/browse/LOG4J2-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882901#comment-13882901
]
Remko Popma commented on LOG4J2-506:
Gregg, did you have a chance to try this? Any fee
I see...
I thought the most common use case would be adding custom levels, but I see
now that /taking away existing levels/ is also a use case. Perhaps that
should be a separate code-gen tool, which generates an interface (& impl)
that does not extend from Logger.
One advantage of having the custo
I propose this:
1) If you are willing to view standard levels as a type of DSL, then you
should refactor the Logger interface to separate those concerns. Create a
new superinterface that contains everything else. This is what custom
loggers will extend.
2) The customer loggers not only register a
The thing about OSGi support is that it may require API changes. I've
already submitted a patch that does just that (well, it's a
backwards-compatible change). OSGi has more esoteric class loader issues
that makes dynamic class loading a bit more difficult. When it comes to
packaging the individual
I also want to avoid extending Logger for domain specific applications. For
medical devices for example I could only have critical, warning, advisory.
Original message
From: Remko Popma
Date:01/27/2014 09:15 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Using Custom
Wrapping a logger /implementation/ is fine. But the user needs an /interface/
to program against. That interface should extend Logger rather than re-define
all of Logger's methods.
Nick
On Jan 27, 2014, at 8:24 AM, Gary Gregory wrote:
> Please note that in the case of domain specific logging (
Please note that in the case of domain specific logging (DSL!), I do not
want to extend, I want to wrap a logger. See my DEFCON example.
Gary
On Sun, Jan 26, 2014 at 6:51 PM, Nick Williams <
[email protected]> wrote:
> Generating a logger /interface/ is going to be hard. Sure, writi
I agree with Nick. Changing levels to be extensible warrants another Beta.
I'd like to see a stable API before we get into RC mode.
What about:
- Now: Another Beta
- +1 month, If the API is stable: RC1
- RCs until shows stoppers are fixed, pick a rhythm: once a week may be too
much, once a month
How about starting with something very simple at first?
We provide a tool that generates the source code for a custom logger
interface.
To invoke the tool the user passes it the fully qualified name of the
interface, and a list of NAME=INTLEVEL custom log levels.
The generated source code conta
Remko Popma created LOG4J2-517:
--
Summary: Switch in log4j-1.2-api Category.getEffectiveLevel misses
FATAL, OFF
Key: LOG4J2-517
URL: https://issues.apache.org/jira/browse/LOG4J2-517
Project: Log4j 2
I wouldn't necessarily vote against a GA, but given that we just MAJORLY
overhauled Level, I think a brief RC is in order. It would be a shame if
someone found a problem with Level a week after GA that caused us to need to
change the API to fix it.
Nick
On Jan 27, 2014, at 12:51 AM, Remko Popm
I think I'll attend, but I'd like to see if someone here can answer some
questions for me. I can direct my questions to someone at ApacheCon, but I
figured this would be a quick first-go.
I noticed the fee is normally $799 (until Friday, then $1099), but it's $275
for "committers." That means t
65 matches
Mail list logo
