[
https://issues.apache.org/jira/browse/LOG4J2-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962606#comment-13962606
]
Ralph Goers commented on LOG4J2-598:
I would have to look at the plugins we have creat
The 1.2 api is for compatibility with code using the Log4j 1.2 library.
It's a way to transition to 2.0. The other one is the main Log4j 2 API.
log4j-core is the main implementation of said API.
The log4j-osgi module is a parent project to several OSGi bundles that
break up log4j-core into a few p
[
https://issues.apache.org/jira/browse/LOG4J2-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-598:
---
Priority: Minor (was: Major)
> Support more data types in plugin attributes
> --
Hi All
Few things to clarify,
1) What is the difference between log4j-1.2-api and log4j-api modules.
2) What is the expectation of log4j-osgi module.
-Thanks
Nishantha
On Tue, Apr 8, 2014 at 9:08 AM, Nishantha Pradeep wrote:
> Working on it.
>
> Thanks
> Nishantha
>
>
> On Mon, Apr 7, 2014
[
https://issues.apache.org/jira/browse/LOG4J2-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962577#comment-13962577
]
Matt Sicker commented on LOG4J2-598:
There's absolutely no question as to the awesome
Working on it.
Thanks
Nishantha
On Mon, Apr 7, 2014 at 9:06 PM, Matt Sicker wrote:
> I would agree on following the call path in the Logger classes. Start at
> the API section, then follow where that goes in the core implementation
> classes.
>
>
> On 7 April 2014 07:08, Ralph Goers wrote:
>
[
https://issues.apache.org/jira/browse/LOG4J2-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962532#comment-13962532
]
Gary Gregory commented on LOG4J2-598:
-
YW. It would be nice to piggyback on top of Bea
[
https://issues.apache.org/jira/browse/LOG4J2-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962491#comment-13962491
]
Ralph Goers commented on LOG4J2-598:
Thanks Gary. I agree improvements should be made
Sorry. Your message could not be delivered to:
internet,PackerCollegiate (The name was not found at the remote site.
Check that the name has been entered correctly.)
[
https://issues.apache.org/jira/browse/LOG4J2-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962409#comment-13962409
]
Remko Popma edited comment on LOG4J2-578 at 4/8/14 12:09 AM:
-
Sorry. Your message could not be delivered to:
internet,PackerCollegiate (The name was not found at the remote site.
Check that the name has been entered correctly.)
[
https://issues.apache.org/jira/browse/LOG4J2-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962422#comment-13962422
]
Gary Gregory commented on LOG4J2-598:
-
Let's start off by saying that Ralph has done a
Sorry. Your message could not be delivered to:
internet,PackerCollegiate (The name was not found at the remote site.
Check that the name has been entered correctly.)
[
https://issues.apache.org/jira/browse/LOG4J2-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962409#comment-13962409
]
Remko Popma commented on LOG4J2-578:
Which version of Tomcat are you using when you se
[
https://issues.apache.org/jira/browse/LOG4J2-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker reassigned LOG4J2-598:
--
Assignee: Matt Sicker
> Support more data types in plugin attributes
>
Matt Sicker created LOG4J2-598:
--
Summary: Support more data types in plugin attributes
Key: LOG4J2-598
URL: https://issues.apache.org/jira/browse/LOG4J2-598
Project: Log4j 2
Issue Type: Improvem
[
https://issues.apache.org/jira/browse/LOG4J2-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962398#comment-13962398
]
Remko Popma commented on LOG4J2-406:
This ticket only mentions the stopgap solution. A
[
https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962390#comment-13962390
]
Matt Sicker commented on LOG4J2-400:
It might be useful to add annotations to packages
Alright, so far, it looks like the list of things we want to get done for
RC2 are:
* XML and JSON socket receivers
* Marker API changes
* LoggerStream/LoggerWriter API and implementation
* LifeCycle states
And in general, things that are blocking 2.0:
* Memory leaks due to shutdown thread and JMX
I think we should address LOG4J-547 to at least some degree. Minimally, I
head some support for removing streams from log4j-api. I can submit a more
complete patch if I can have some questions answered (e.g. should we switch
walking the call stack to be bottom-up instead of top-down, should it go i
[
https://issues.apache.org/jira/browse/LOG4J2-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-596:
---
Attachment: Proposed_lifecycle_refactor1.patch
Here's an updated patch. Most of the lifecycles are co
And I want to get make the Marker API changes.
Also, we need to finish the logo contest.
Ralph
On Apr 7, 2014, at 8:48 AM, Matt Sicker wrote:
> I think that would be good. I'd like to see what we all think about a more
> comprehensive life cycle state machine that works more like how LoggerCo
I think that would be good. I'd like to see what we all think about a more
comprehensive life cycle state machine that works more like how
LoggerContext does. I'm working on a patch proposal for that, but it is a
non-trivial change that affects lots of classes in log4j-core. If this
seems like a go
I've just figured out how to workaround a Jackson bug in order to do XML
and JSON server socket receivers.
We can wait for me to get this in this week (hopefully) for RC2, or not :)
Gary
On Mon, Apr 7, 2014 at 11:35 AM, Matt Sicker wrote:
> There's been a bunch of work done since RC1. It migh
I would agree on following the call path in the Logger classes. Start at
the API section, then follow where that goes in the core implementation
classes.
On 7 April 2014 07:08, Ralph Goers wrote:
> If it was me I would start by looking at what happens when someone calls
> Logger.info() or Logge
There's been a bunch of work done since RC1. It might be a good idea to get
another release candidate going.
--
Matt Sicker
So if the a "parent" of a marker is detected with the isInstaceOf API, we
can explain that this is similar to detecting that a class implements an
interface with instanceOf. Sounds OK.
Gary
On Mon, Apr 7, 2014 at 9:39 AM, Ralph Goers wrote:
> Yes, you can always find your Marker by calling get
Yes, you can always find your Marker by calling get Marker("Marker1"). Yes,
other Markers are like extends or implements because when you are filtering the
filter will Match on any of the Markers associated with the Marker, which is
why I think isInstanceOf is an appropriate name for the compar
Since we are not GA, I am all for changing the API names to make the API as
easy to understand as possible.
Gary
On Mon, Apr 7, 2014 at 9:31 AM, Ralph Goers wrote:
> I believe SLF4j may have changed the name from getChildren because that
> name doesn't match how Markers really work. It is just
I believe SLF4j may have changed the name from getChildren because that name
doesn't match how Markers really work. It is just wired to test anything to see
if it gets attributes from its children or grandchildren. I always thought of
the relationship to be more like Java's extend or implements
As I think about it more, I like the fluent idea better. This way I would
get to choose if I wanted my parents to add to or replace the existing
parents. So make both setParents and add methods return "this".
Actually, there is one thing about the current marker implementation that
thoroughly conf
I would be happy with a solution that looked like this:
private static final Marker m =
MarkerManager.getMarker("m").setParents("p");
Where setParents is fluent by simply returning "this". Other names would be
possible: .parents(...), .withParents(...). I really dislike the slf4j
method where I h
On Mon, Apr 7, 2014 at 3:04 AM, Ralph Goers wrote:
> Gary, Markers are not Loggers. People don’t use them to represent Java
> classes but to represent states, categories or extensions to logging
> levels. Would you prefer that the logging levels be “
> org.apache.logging.log4j.INFO” instead of j
If it was me I would start by looking at what happens when someone calls
Logger.info() or Logger.debug() and follow that code path. Starting from
LogManager is going to involve both creating a Logger as well as initializing
the whole framework, which will get quite complicated.
Ralph
On Apr
Gary, Markers are not Loggers. People don’t use them to represent Java classes
but to represent states, categories or extensions to logging levels. Would you
prefer that the logging levels be “org.apache.logging.log4j.INFO” instead of
just INFO? In addition, having to specify the full hierarc
Hi All
I downloaded the log4j2 source and trying to read and and understand how it
works. I would be very thankful if someone could let me know a better place
to start reading the source.
For example, the first lines of code of log4j2 executes.
I thought the LogManager contains the first lines o
36 matches
Mail list logo
