[jira] [Commented] (LOG4J2-400) Provide Appender-Bundles
[
https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984125#comment-13984125
]
Łukasz Dywicki commented on LOG4J2-400:
---
4.3.0 is sufficient and widely used. 5.0.0 brings some new features but so far
they are not important from log4j point of view.
Provide Appender-Bundles
Key: LOG4J2-400
URL: https://issues.apache.org/jira/browse/LOG4J2-400
Project: Log4j 2
Issue Type: Improvement
Components: Appenders, Core
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: OSGi R4 / R5 (Apache Felix 4.x)
Reporter: Roland Weiglhofer
Priority: Critical
Labels: Appender, Core, Dependency, OSGi, PluginManager,
lightweight, optional
Fix For: 2.0
Attachments: Unbenannt.jpg
Instead of deploying all appenders in the core fragment, it would be much
better if the customer can choose which appender he wants to provide. (I want
a lightweight version without database and http stuff. I do not want to
install libraries, which I do not need. All the (transitiv)
log4j2-dependencies together are much bigger than my own application.)
It's easy to hive the appender off in a separate bundle fragment. The host
bundle is the API bundle. The Plugin Manager (core fragment) finds the
deployed appenders in the classpath of the host bundle. The PluginManager
should parse the class path in a separate thread (Startup-Hook) and only once
at the start of the host bundle, but not for each call (when a consumer
bundle aquires a logger). Make package-imports optional
(Import-Package*;resolution:=optional/Import-Package)
This reduces the number of dependencies and reduces the startup time of the
whole system.
One possible solution for the Plugin Manager is to use the reflections plugin
during the maven build process. This plugin lists all classes of a project
within a xml file. This file can be marked as a bundle resource and is stored
within the appender bundle fragment. The idea is that each appender fragment
has its own class list. Because the bundle host (log4j2 core) sees all
resources of its fragments it can load these class lists at runtime. Thus,
the Plugin Manager gets only those appenders that are installed within
deployed bundle fragements. The class list is created during the build
process, the plugin manager must not parse the classpath at runtime. Log4j2
uses a xml parser by default. An additional new dependency to a xml-parser
library is not required.
plugin
groupIdorg.reflections/groupId
artifactIdreflections-maven/artifactId
version0.9.8/version
executions
execution
goals
goalreflections/goal
/goals
phaseprocess-classes/phase
/execution
/executions
configuration
destinations${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml/destinations
/configuration
/plugin
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-252) SMTPAppender: send multiple events in one mail
[ https://issues.apache.org/jira/browse/LOG4J2-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984163#comment-13984163 ] Matej Vitásek commented on LOG4J2-252: -- Any idea whether this is considered for implementation? Any workarounds? SMTPAppender: send multiple events in one mail -- Key: LOG4J2-252 URL: https://issues.apache.org/jira/browse/LOG4J2-252 Project: Log4j 2 Issue Type: Wish Reporter: Matej Vitásek I am using Log4j 2 for a Tomcat web application to send me an e-mail whenever an ERROR occurs. Usually, more than one error is produced at one time, and I get a lot of e-mails over a period of a few seconds. It would be great if the SMTPAppender could cluster more events into one mail. Of course, one has to be sure that Log4j 2 is not waiting too long to send me the errors, which could be solved by a timeout setting. So I propose the following: add a new timeout setting to the SMTPAppender. Whenever an event that would trigger sending a mail occurs, wait for timeout seconds and bundle whatever else events occur into this mail. Only then send the mail. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-621) Pattern To Drop First X Package Parts
Lee Theobald created LOG4J2-621:
---
Summary: Pattern To Drop First X Package Parts
Key: LOG4J2-621
URL: https://issues.apache.org/jira/browse/LOG4J2-621
Project: Log4j 2
Issue Type: Wish
Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Lee Theobald
Priority: Trivial
Currently you can have a pattern that will print out the last X parts of you
package. So if my package was `uk.co.ltheobald.foo.bar`, then using
`%logger{2}` will print `foo.bar`. But when I have a number of different
package levels, this becomes less useful (in my opinion).
What I'd find more useful is the inverse where I can ditch the first X parts.
Something like `%logger{-3}` for example. That way I'd end up with:
`uk.co.ltheobald.Main logging` as `Main`
`uk.co.ltheobald.foo.MyClass` logging as `foo.MyClass`
`uk.co.ltheobald.foo.bar.MyOtherClass` logging as `foo.bar.MyOtherClass`
Removing from the start of the logger name allows me to consistently trim off
package names that I know are always the same.
I'll see if I can produce a code example for this if I get time but I wanted to
log it in the meanwhile.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-621) Pattern To Drop First X Package Parts
[
https://issues.apache.org/jira/browse/LOG4J2-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lee Theobald updated LOG4J2-621:
Description:
Currently you can have a pattern that will print out the last X parts of you
package. So if my package was {{uk.co.ltheobald.foo.bar}}, then using
{{%logger{2}}} will print {{foo.bar}}. But when I have a number of different
package levels, this becomes less useful (in my opinion).
What I'd find more useful is the inverse where I can ditch the first X parts.
Something like {{%logger{-3}}} for example. That way I'd end up with:
{{uk.co.ltheobald.Main logging}} as {{Main}}
{{uk.co.ltheobald.foo.MyClass}} logging as {{foo.MyClass}}
{{uk.co.ltheobald.foo.bar.MyOtherClass}} logging as {{foo.bar.MyOtherClass}}
Removing from the start of the logger name allows me to consistently trim off
package names that I know are always the same. I'll see if I can produce a
code example for this if I get time but I wanted to log it in the meanwhile.
was:
Currently you can have a pattern that will print out the last X parts of you
package. So if my package was `uk.co.ltheobald.foo.bar`, then using
`%logger{2}` will print `foo.bar`. But when I have a number of different
package levels, this becomes less useful (in my opinion).
What I'd find more useful is the inverse where I can ditch the first X parts.
Something like `%logger{-3}` for example. That way I'd end up with:
`uk.co.ltheobald.Main logging` as `Main`
`uk.co.ltheobald.foo.MyClass` logging as `foo.MyClass`
`uk.co.ltheobald.foo.bar.MyOtherClass` logging as `foo.bar.MyOtherClass`
Removing from the start of the logger name allows me to consistently trim off
package names that I know are always the same.
I'll see if I can produce a code example for this if I get time but I wanted to
log it in the meanwhile.
Pattern To Drop First X Package Parts
-
Key: LOG4J2-621
URL: https://issues.apache.org/jira/browse/LOG4J2-621
Project: Log4j 2
Issue Type: Wish
Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Lee Theobald
Priority: Trivial
Currently you can have a pattern that will print out the last X parts of you
package. So if my package was {{uk.co.ltheobald.foo.bar}}, then using
{{%logger{2}}} will print {{foo.bar}}. But when I have a number of different
package levels, this becomes less useful (in my opinion).
What I'd find more useful is the inverse where I can ditch the first X parts.
Something like {{%logger{-3}}} for example. That way I'd end up with:
{{uk.co.ltheobald.Main logging}} as {{Main}}
{{uk.co.ltheobald.foo.MyClass}} logging as {{foo.MyClass}}
{{uk.co.ltheobald.foo.bar.MyOtherClass}} logging as {{foo.bar.MyOtherClass}}
Removing from the start of the logger name allows me to consistently trim off
package names that I know are always the same. I'll see if I can produce a
code example for this if I get time but I wanted to log it in the meanwhile.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-621) Pattern To Drop First X Package Parts
[
https://issues.apache.org/jira/browse/LOG4J2-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lee Theobald updated LOG4J2-621:
Description:
Currently you can have a pattern that will print out the last X parts of you
package. So if my package was {{uk.co.ltheobald.foo.bar}}, then using
{{%logger{2} }} will print {{foo.bar}}. But when I have a number of different
package levels, this becomes less useful (in my opinion).
What I'd find more useful is the inverse where I can ditch the first X parts.
Something like {{%logger{-3}}} for example. That way I'd end up with:
{{uk.co.ltheobald.Main logging}} as {{Main}}
{{uk.co.ltheobald.foo.MyClass}} logging as {{foo.MyClass}}
{{uk.co.ltheobald.foo.bar.MyOtherClass}} logging as {{foo.bar.MyOtherClass}}
Removing from the start of the logger name allows me to consistently trim off
package names that I know are always the same. I'll see if I can produce a
code example for this if I get time but I wanted to log it in the meanwhile.
was:
Currently you can have a pattern that will print out the last X parts of you
package. So if my package was {{uk.co.ltheobald.foo.bar}}, then using
{{%logger{2}}} will print {{foo.bar}}. But when I have a number of different
package levels, this becomes less useful (in my opinion).
What I'd find more useful is the inverse where I can ditch the first X parts.
Something like {{%logger{-3}}} for example. That way I'd end up with:
{{uk.co.ltheobald.Main logging}} as {{Main}}
{{uk.co.ltheobald.foo.MyClass}} logging as {{foo.MyClass}}
{{uk.co.ltheobald.foo.bar.MyOtherClass}} logging as {{foo.bar.MyOtherClass}}
Removing from the start of the logger name allows me to consistently trim off
package names that I know are always the same. I'll see if I can produce a
code example for this if I get time but I wanted to log it in the meanwhile.
Pattern To Drop First X Package Parts
-
Key: LOG4J2-621
URL: https://issues.apache.org/jira/browse/LOG4J2-621
Project: Log4j 2
Issue Type: Wish
Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Lee Theobald
Priority: Trivial
Currently you can have a pattern that will print out the last X parts of you
package. So if my package was {{uk.co.ltheobald.foo.bar}}, then using
{{%logger{2} }} will print {{foo.bar}}. But when I have a number of
different package levels, this becomes less useful (in my opinion).
What I'd find more useful is the inverse where I can ditch the first X parts.
Something like {{%logger{-3}}} for example. That way I'd end up with:
{{uk.co.ltheobald.Main logging}} as {{Main}}
{{uk.co.ltheobald.foo.MyClass}} logging as {{foo.MyClass}}
{{uk.co.ltheobald.foo.bar.MyOtherClass}} logging as {{foo.bar.MyOtherClass}}
Removing from the start of the logger name allows me to consistently trim off
package names that I know are always the same. I'll see if I can produce a
code example for this if I get time but I wanted to log it in the meanwhile.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-621) Pattern To Drop First X Package Parts
[
https://issues.apache.org/jira/browse/LOG4J2-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lee Theobald updated LOG4J2-621:
Description:
Currently you can have a pattern that will print out the last X parts of you
package. So if my package was {{uk.co.ltheobald.foo.bar}}, then using
{{%logger\{2\}}} will print {{foo.bar}}. But when I have a number of different
package levels, this becomes less useful (in my opinion).
What I'd find more useful is the inverse where I can ditch the first X parts.
Something like {{%logger\{-3\}}} for example. That way I'd end up with:
{{uk.co.ltheobald.Main logging}} as {{Main}}
{{uk.co.ltheobald.foo.MyClass}} logging as {{foo.MyClass}}
{{uk.co.ltheobald.foo.bar.MyOtherClass}} logging as {{foo.bar.MyOtherClass}}
Removing from the start of the logger name allows me to consistently trim off
package names that I know are always the same. I'll see if I can produce a
code example for this if I get time but I wanted to log it in the meanwhile.
was:
Currently you can have a pattern that will print out the last X parts of you
package. So if my package was {{uk.co.ltheobald.foo.bar}}, then using
`%logger{2}` will print {{foo.bar}}. But when I have a number of different
package levels, this becomes less useful (in my opinion).
What I'd find more useful is the inverse where I can ditch the first X parts.
Something like `%logger{-3}` for example. That way I'd end up with:
{{uk.co.ltheobald.Main logging}} as {{Main}}
{{uk.co.ltheobald.foo.MyClass}} logging as {{foo.MyClass}}
{{uk.co.ltheobald.foo.bar.MyOtherClass}} logging as {{foo.bar.MyOtherClass}}
Removing from the start of the logger name allows me to consistently trim off
package names that I know are always the same. I'll see if I can produce a
code example for this if I get time but I wanted to log it in the meanwhile.
Pattern To Drop First X Package Parts
-
Key: LOG4J2-621
URL: https://issues.apache.org/jira/browse/LOG4J2-621
Project: Log4j 2
Issue Type: Wish
Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Lee Theobald
Priority: Trivial
Currently you can have a pattern that will print out the last X parts of you
package. So if my package was {{uk.co.ltheobald.foo.bar}}, then using
{{%logger\{2\}}} will print {{foo.bar}}. But when I have a number of
different package levels, this becomes less useful (in my opinion).
What I'd find more useful is the inverse where I can ditch the first X parts.
Something like {{%logger\{-3\}}} for example. That way I'd end up with:
{{uk.co.ltheobald.Main logging}} as {{Main}}
{{uk.co.ltheobald.foo.MyClass}} logging as {{foo.MyClass}}
{{uk.co.ltheobald.foo.bar.MyOtherClass}} logging as {{foo.bar.MyOtherClass}}
Removing from the start of the logger name allows me to consistently trim off
package names that I know are always the same. I'll see if I can produce a
code example for this if I get time but I wanted to log it in the meanwhile.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-621) Pattern To Drop First X Package Parts
[
https://issues.apache.org/jira/browse/LOG4J2-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lee Theobald updated LOG4J2-621:
Description:
Currently you can have a pattern that will print out the last X parts of you
package. So if my package was {{uk.co.ltheobald.foo.bar}}, then using
`%logger{2}` will print {{foo.bar}}. But when I have a number of different
package levels, this becomes less useful (in my opinion).
What I'd find more useful is the inverse where I can ditch the first X parts.
Something like `%logger{-3}` for example. That way I'd end up with:
{{uk.co.ltheobald.Main logging}} as {{Main}}
{{uk.co.ltheobald.foo.MyClass}} logging as {{foo.MyClass}}
{{uk.co.ltheobald.foo.bar.MyOtherClass}} logging as {{foo.bar.MyOtherClass}}
Removing from the start of the logger name allows me to consistently trim off
package names that I know are always the same. I'll see if I can produce a
code example for this if I get time but I wanted to log it in the meanwhile.
was:
Currently you can have a pattern that will print out the last X parts of you
package. So if my package was {{uk.co.ltheobald.foo.bar}}, then using
{{%logger{2} }} will print {{foo.bar}}. But when I have a number of different
package levels, this becomes less useful (in my opinion).
What I'd find more useful is the inverse where I can ditch the first X parts.
Something like {{%logger{-3}}} for example. That way I'd end up with:
{{uk.co.ltheobald.Main logging}} as {{Main}}
{{uk.co.ltheobald.foo.MyClass}} logging as {{foo.MyClass}}
{{uk.co.ltheobald.foo.bar.MyOtherClass}} logging as {{foo.bar.MyOtherClass}}
Removing from the start of the logger name allows me to consistently trim off
package names that I know are always the same. I'll see if I can produce a
code example for this if I get time but I wanted to log it in the meanwhile.
Pattern To Drop First X Package Parts
-
Key: LOG4J2-621
URL: https://issues.apache.org/jira/browse/LOG4J2-621
Project: Log4j 2
Issue Type: Wish
Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Lee Theobald
Priority: Trivial
Currently you can have a pattern that will print out the last X parts of you
package. So if my package was {{uk.co.ltheobald.foo.bar}}, then using
`%logger{2}` will print {{foo.bar}}. But when I have a number of different
package levels, this becomes less useful (in my opinion).
What I'd find more useful is the inverse where I can ditch the first X parts.
Something like `%logger{-3}` for example. That way I'd end up with:
{{uk.co.ltheobald.Main logging}} as {{Main}}
{{uk.co.ltheobald.foo.MyClass}} logging as {{foo.MyClass}}
{{uk.co.ltheobald.foo.bar.MyOtherClass}} logging as {{foo.bar.MyOtherClass}}
Removing from the start of the logger name allows me to consistently trim off
package names that I know are always the same. I'll see if I can produce a
code example for this if I get time but I wanted to log it in the meanwhile.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-252) SMTPAppender: send multiple events in one mail
[ https://issues.apache.org/jira/browse/LOG4J2-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984244#comment-13984244 ] Remko Popma commented on LOG4J2-252: Matej, no, I don't think anyone is working on this at the moment. If this is important to you, please consider submitting a patch. SMTPAppender: send multiple events in one mail -- Key: LOG4J2-252 URL: https://issues.apache.org/jira/browse/LOG4J2-252 Project: Log4j 2 Issue Type: Wish Reporter: Matej Vitásek I am using Log4j 2 for a Tomcat web application to send me an e-mail whenever an ERROR occurs. Usually, more than one error is produced at one time, and I get a lot of e-mails over a period of a few seconds. It would be great if the SMTPAppender could cluster more events into one mail. Of course, one has to be sure that Log4j 2 is not waiting too long to send me the errors, which could be solved by a timeout setting. So I propose the following: add a new timeout setting to the SMTPAppender. Whenever an event that would trigger sending a mail occurs, wait for timeout seconds and bundle whatever else events occur into this mail. Only then send the mail. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-622) RollingFileManager does not honour bufferedIO after first Rollover.
Farooq Khan created LOG4J2-622: -- Summary: RollingFileManager does not honour bufferedIO after first Rollover. Key: LOG4J2-622 URL: https://issues.apache.org/jira/browse/LOG4J2-622 Project: Log4j 2 Issue Type: Bug Components: Appenders, Core Affects Versions: 2.0-rc1 Reporter: Farooq Khan This seems to a simple bug. In the RollingFileManager::createManager() method when creating the OutputStream object based on if data.bufferedIO we wrap the outputstream into a BufferedOutputStream However after first rollover in the method RollingFileManager::createFileAfterRollover() we do not do the same. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
Mikael Ståldal created LOG4J2-623:
-
Summary: Better structure of Thread Context Map in JSONLayout
Key: LOG4J2-623
URL: https://issues.apache.org/jira/browse/LOG4J2-623
Project: Log4j 2
Issue Type: Improvement
Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Priority: Minor
Currently, the Thread Context Map looks like this in JSONLayout:
{quote}
Properties:[
{
name:UserName,
value:admin
},
{
name:OrgName,
value:test
}
]
{quote}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why name
it mdc rather than the quite vauge Properties?
{quote}
mdc: {
UserName:admin,
OrgName:test
}
{quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal updated LOG4J2-623:
--
Description:
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript}
Properties:[
{
name:UserName,
value:admin
},
{
name:OrgName,
value:test
}
]
{code:JavaScript}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why not
name it mdc rather than the quite vauge Properties?
{code:JavaScript}
mdc: {
UserName:admin,
OrgName:test
}
{code:JavaScript}
was:
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript}
Properties:[
{
name:UserName,
value:admin
},
{
name:OrgName,
value:test
}
]
{code:JavaScript}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why name
it mdc rather than the quite vauge Properties?
{code:JavaScript}
mdc: {
UserName:admin,
OrgName:test
}
{code:JavaScript}
Better structure of Thread Context Map in JSONLayout
Key: LOG4J2-623
URL: https://issues.apache.org/jira/browse/LOG4J2-623
Project: Log4j 2
Issue Type: Improvement
Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Priority: Minor
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript}
Properties:[
{
name:UserName,
value:admin
},
{
name:OrgName,
value:test
}
]
{code:JavaScript}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why not
name it mdc rather than the quite vauge Properties?
{code:JavaScript}
mdc: {
UserName:admin,
OrgName:test
}
{code:JavaScript}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal updated LOG4J2-623:
--
Description:
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript}
Properties:[
{
name:UserName,
value:admin
},
{
name:OrgName,
value:test
}
]
{code:JavaScript}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why name
it mdc rather than the quite vauge Properties?
{code:JavaScript}
mdc: {
UserName:admin,
OrgName:test
}
{code:JavaScript}
was:
Currently, the Thread Context Map looks like this in JSONLayout:
{quote}
Properties:[
{
name:UserName,
value:admin
},
{
name:OrgName,
value:test
}
]
{quote}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why name
it mdc rather than the quite vauge Properties?
{quote}
mdc: {
UserName:admin,
OrgName:test
}
{quote}
Better structure of Thread Context Map in JSONLayout
Key: LOG4J2-623
URL: https://issues.apache.org/jira/browse/LOG4J2-623
Project: Log4j 2
Issue Type: Improvement
Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Priority: Minor
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript}
Properties:[
{
name:UserName,
value:admin
},
{
name:OrgName,
value:test
}
]
{code:JavaScript}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why name
it mdc rather than the quite vauge Properties?
{code:JavaScript}
mdc: {
UserName:admin,
OrgName:test
}
{code:JavaScript}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal updated LOG4J2-623:
--
Description:
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript|title=Current}
Properties:[
{
name:UserName,
value:admin
},
{
name:OrgName,
value:test
}
]
{code}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why not
name it mdc rather than the quite vauge Properties?
{code:JavaScript|title=Suggested}
mdc: {
UserName:admin,
OrgName:test
}
{code}
was:
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript}
Properties:[
{
name:UserName,
value:admin
},
{
name:OrgName,
value:test
}
]
{code:JavaScript}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why not
name it mdc rather than the quite vauge Properties?
{code:JavaScript}
mdc: {
UserName:admin,
OrgName:test
}
{code:JavaScript}
Better structure of Thread Context Map in JSONLayout
Key: LOG4J2-623
URL: https://issues.apache.org/jira/browse/LOG4J2-623
Project: Log4j 2
Issue Type: Improvement
Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Priority: Minor
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript|title=Current}
Properties:[
{
name:UserName,
value:admin
},
{
name:OrgName,
value:test
}
]
{code}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why not
name it mdc rather than the quite vauge Properties?
{code:JavaScript|title=Suggested}
mdc: {
UserName:admin,
OrgName:test
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal updated LOG4J2-623:
--
Description:
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript|title=Current}
Properties:[
{
name:UserName,
value:admin
},
{
name:OrgName,
value:test
}
]
{code}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why not
name it mdc rather than the quite vauge Properties?
{code:JavaScript|title=Suggested}
mdc: {
UserName:admin,
OrgName:test
}
{code}
was:
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript|title=Current}
Properties:[
{
name:UserName,
value:admin
},
{
name:OrgName,
value:test
}
]
{code}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why not
name it mdc rather than the quite vauge Properties?
{code:JavaScript|title=Suggested}
mdc: {
UserName:admin,
OrgName:test
}
{code}
Better structure of Thread Context Map in JSONLayout
Key: LOG4J2-623
URL: https://issues.apache.org/jira/browse/LOG4J2-623
Project: Log4j 2
Issue Type: Improvement
Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Priority: Minor
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript|title=Current}
Properties:[
{
name:UserName,
value:admin
},
{
name:OrgName,
value:test
}
]
{code}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why not
name it mdc rather than the quite vauge Properties?
{code:JavaScript|title=Suggested}
mdc: {
UserName:admin,
OrgName:test
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Assigned] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers reassigned LOG4J2-623:
--
Assignee: Ralph Goers
Better structure of Thread Context Map in JSONLayout
Key: LOG4J2-623
URL: https://issues.apache.org/jira/browse/LOG4J2-623
Project: Log4j 2
Issue Type: Improvement
Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Assignee: Ralph Goers
Priority: Minor
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript|title=Current}
Properties:[
{
name:UserName,
value:admin
},
{
name:OrgName,
value:test
}
]
{code}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why not
name it mdc rather than the quite vauge Properties?
{code:JavaScript|title=Suggested}
mdc: {
UserName:admin,
OrgName:test
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-624) Better structure of Thread Context Stack in JSONLayout
Mikael Ståldal created LOG4J2-624:
-
Summary: Better structure of Thread Context Stack in JSONLayout
Key: LOG4J2-624
URL: https://issues.apache.org/jira/browse/LOG4J2-624
Project: Log4j 2
Issue Type: Improvement
Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Priority: Minor
The Thread Context Stack is currently represented like this in JSONLayout:
{code:JavaScript:title=Current}
ndc:[foo, bar]
{code}
This is not correct JSON syntax, and does not make proper use of the JSON data
format. The Thread Context Stack should be represented as a JSON array:
{code:JavaScript:title=Suggested}
ndc: [foo, bar]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984410#comment-13984410
]
Gary Gregory commented on LOG4J2-623:
-
I am reconsidering some details of the JSON layout as I work through the JSON
and XML receivers. This is WIP and I have been busy with other more urgent
matters. I hope to return to it soon.
Gary
Better structure of Thread Context Map in JSONLayout
Key: LOG4J2-623
URL: https://issues.apache.org/jira/browse/LOG4J2-623
Project: Log4j 2
Issue Type: Improvement
Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Assignee: Ralph Goers
Priority: Minor
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript|title=Current}
Properties:[
{
name:UserName,
value:admin
},
{
name:OrgName,
value:test
}
]
{code}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why not
name it mdc rather than the quite vauge Properties?
{code:JavaScript|title=Suggested}
mdc: {
UserName:admin,
OrgName:test
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984415#comment-13984415
]
Ralph Goers commented on LOG4J2-623:
I would expect that the JSONLayout would mimic the XMLLayout to some degree.
Better structure of Thread Context Map in JSONLayout
Key: LOG4J2-623
URL: https://issues.apache.org/jira/browse/LOG4J2-623
Project: Log4j 2
Issue Type: Improvement
Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Assignee: Ralph Goers
Priority: Minor
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript|title=Current}
Properties:[
{
name:UserName,
value:admin
},
{
name:OrgName,
value:test
}
]
{code}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why not
name it mdc rather than the quite vauge Properties?
{code:JavaScript|title=Suggested}
mdc: {
UserName:admin,
OrgName:test
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: Log4j Project Guidelines
Please keep in mind that synchronized is not fair. http://sourceforge.net/apps/trac/lilith/wiki/SynchronizedVsFairLock Yes, a fair ReentrantLock is way slower than an unfair one… but if starvation is caused by a logging framework then this is a serious issue in my opinion. Joern On 29. April 2014 at 01:05:26, Matt Sicker (boa...@gmail.com) wrote: I'll delegate my arguments to the SO post about it: http://stackoverflow.com/questions/442564/avoid-synchronizedthis-in-java In short, it's defensive programming. It's safer to synchronize on an internal object than on this. Plus, it aids in concurrency throughput instead of just using a synchronized method. On 28 April 2014 12:45, Ralph Goers wrote: Why are they not appropriate lock objects? Start a discussion before just changing them. Ralph On Apr 28, 2014, at 10:40 AM, Matt Sicker wrote: In that case, Item 69: prefer concurrency utilities to wait and notify. Sounds like we can just use a plain Object instance to lock (which is pretty much equivalent to using ReentrantLock) when doing normal locks, but instead of using .notifyAll() and .wait(), we should use the Condition interface (which would require using Lock as well). I agree that using synchronized(object) makes sense when it's all that's being done. However, I've been changing instances of synchronized(this) and synchronized(foo) where foo is not an appropriate lock object (e.g., a string, or a non-final object, things like that). On 28 April 2014 12:28, Ralph Goers wrote: Yes, guidelines called out by Effective Java are appropriate when they apply. As for concurrency, “New” isn’t always better than old. In a few places you changed synchronized(object) to use a Lock instead. There is little to no value in doing that and makes the code look a little more cluttered. However, if a ReadWriteLock can be used in place of synchronized that is a real benefit. The point of the guidelines are that when it comes to stuff like this, unless there is a guideline written down that says the current code is wrong discuss it on the list before making a change. Ralph On Apr 28, 2014, at 9:35 AM, Matt Sicker wrote: What about style things covered by Effective Java? These are pretty much all good ideas. Also, how about some guidelines on concurrency? I'd recommend not using the old concurrency stuff and instead using java.util.concurrent.* for more effective concurrency. This doesn't include the Thread vs Runnable thing, so that's still debatable. On 28 April 2014 08:46, Gary Gregory wrote: Perhaps if one breaks the build, it should be polite to revert that last commit... Gary On Mon, Apr 28, 2014 at 3:07 AM, Ralph Goerswrote: I think we need to develop and post some development “guidelines”, “best practices” or whatever you want to call it for Log4j 2. Here are some of the things I would definitely want on it. 1. Error on the side of caution. If you don’t understand it, don’t touch it and ask on the list. If you think you understand it read it again or ask until you are sure you do. Nobody will blame you for asking questions. 2. Don’t break the build - if there is the slightest chance the change you are making could cause unit test failures, run all unit tests. Better yet, get in the habit of always running the unit tests before doing the commit. 3. If the build breaks and you have made recent changes then assume you broke it and try to fix it. Although it might not have been something you did it will make others feel a lot better than having to fix the mistake for you. Everyone makes mistakes. Taking responsibility for them is a good thing. 4. Don’t change things to match your personal preference - the project has style guidelines that are validated with checkstyle, PMD, and other tools. If you aren’t fixing a bug, fixing a problem identified by the tools, or fixing something specifically called out in these guidelines then start a discussion to see if the change is something the project wants before starting to work on it. We try to discuss things first and then implement the consensus reached in the discussion. Of course, the actual coding conventions we follow should also be spelled out, such as indentation, braces style, import ordering and where to use the final keyword. Ralph - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- Matt Sicker
Re: Log4j Project Guidelines
Should we be using a fair lock? That's usually a lot slower than a typical one, but if it's more proper behavior, then it would make sense to go that route. On 29 April 2014 14:49, Jörn Huxhorn jhuxh...@googlemail.com wrote: Please keep in mind that synchronized is not fair. http://sourceforge.net/apps/trac/lilith/wiki/SynchronizedVsFairLock Yes, a fair ReentrantLock is way slower than an unfair one… but if starvation is caused by a logging framework then this is a serious issue in my opinion. Joern On 29. April 2014 at 01:05:26, Matt Sicker (boa...@gmail.com) wrote: I'll delegate my arguments to the SO post about it: http://stackoverflow.com/questions/442564/avoid-synchronizedthis-in-java In short, it's defensive programming. It's safer to synchronize on an internal object than on this. Plus, it aids in concurrency throughput instead of just using a synchronized method. On 28 April 2014 12:45, Ralph Goers wrote: Why are they not appropriate lock objects? Start a discussion before just changing them. Ralph On Apr 28, 2014, at 10:40 AM, Matt Sicker wrote: In that case, Item 69: prefer concurrency utilities to wait and notify. Sounds like we can just use a plain Object instance to lock (which is pretty much equivalent to using ReentrantLock) when doing normal locks, but instead of using .notifyAll() and .wait(), we should use the Condition interface (which would require using Lock as well). I agree that using synchronized(object) makes sense when it's all that's being done. However, I've been changing instances of synchronized(this) and synchronized(foo) where foo is not an appropriate lock object (e.g., a string, or a non-final object, things like that). On 28 April 2014 12:28, Ralph Goers wrote: Yes, guidelines called out by Effective Java are appropriate when they apply. As for concurrency, “New” isn’t always better than old. In a few places you changed synchronized(object) to use a Lock instead. There is little to no value in doing that and makes the code look a little more cluttered. However, if a ReadWriteLock can be used in place of synchronized that is a real benefit. The point of the guidelines are that when it comes to stuff like this, unless there is a guideline written down that says the current code is wrong discuss it on the list before making a change. Ralph On Apr 28, 2014, at 9:35 AM, Matt Sicker wrote: What about style things covered by Effective Java? These are pretty much all good ideas. Also, how about some guidelines on concurrency? I'd recommend not using the old concurrency stuff and instead using java.util.concurrent.* for more effective concurrency. This doesn't include the Thread vs Runnable thing, so that's still debatable. On 28 April 2014 08:46, Gary Gregory wrote: Perhaps if one breaks the build, it should be polite to revert that last commit... Gary On Mon, Apr 28, 2014 at 3:07 AM, Ralph Goerswrote: I think we need to develop and post some development “guidelines”, “best practices” or whatever you want to call it for Log4j 2. Here are some of the things I would definitely want on it. 1. Error on the side of caution. If you don’t understand it, don’t touch it and ask on the list. If you think you understand it read it again or ask until you are sure you do. Nobody will blame you for asking questions. 2. Don’t break the build - if there is the slightest chance the change you are making could cause unit test failures, run all unit tests. Better yet, get in the habit of always running the unit tests before doing the commit. 3. If the build breaks and you have made recent changes then assume you broke it and try to fix it. Although it might not have been something you did it will make others feel a lot better than having to fix the mistake for you. Everyone makes mistakes. Taking responsibility for them is a good thing. 4. Don’t change things to match your personal preference - the project has style guidelines that are validated with checkstyle, PMD, and other tools. If you aren’t fixing a bug, fixing a problem identified by the tools, or fixing something specifically called out in these guidelines then start a discussion to see if the change is something the project wants before starting to work on it. We try to discuss things first and then implement the consensus reached in the discussion. Of course, the actual coding conventions we follow should also be spelled out, such as indentation, braces style, import ordering and where to use the final keyword. Ralph - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail:
Re: New log4j-streams Module
Was there any support in creating any of these new modules? On Fri, Apr 18, 2014 at 5:59 PM, Bruce Brouwer bruce.brou...@gmail.comwrote: I'll put together a list of things that I think could be pulled out of log4j-core because they are integrations with other tools. Go ahead and throw darts, that's what my list is for. * log4j-jms * log4j-mail * log4j-web * log4j-jpa * log4j-mongodb * log4j-couchdb Some more questionable ones to pull out * log4j-json * log4j-yaml On Fri, Apr 18, 2014 at 12:39 PM, Gary Gregory garydgreg...@gmail.comwrote: On Fri, Apr 18, 2014 at 11:17 AM, Matt Sicker boa...@gmail.com wrote: I agree with all that as well. Part of the no more modules problem comes from all the unnecessary OSGi modules. I'll be deleting those soon as I'm porting over the OSGi metadata to the appropriate modules so that extra parallel modules are unneeded. That will be good :) Gary On 17 April 2014 23:48, Ralph Goers ralph.go...@dslextreme.com wrote: I agree with you completely. In fact, the items you have specifically identified are where I would start. Are there more? Ralph On Apr 17, 2014, at 3:21 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: This discussion about having modules or not having modules keeps coming up and I see different opinions here on the log4j team. Generally, the argument of please, no more modules has won. I wanted to present my perspective to see if I can sway anyone's opinion. There are plenty of reasons why projects decide to make more modules. Projects like Spring make plenty of modules. As some have noted, this can make it difficult to find things sometimes, and I agree. Although there are ways around this with search.maven.org, it is still a bit of a pain. Some of this can be solved with documentation, some of it is probably not necessary for log4j. The Spring guys like to break out different modules because of the different features (e.g. batch, security, ...). Log4j is probably not big enough to warrant breaking it up across feature lines. However, another very valid reason to break out modules is for integrations. This is where I think log4j should be allowing more modules to be created: log4j-camel, log4j-ng-flume, log4j-jms, log4j-web, log4j-mongodb, ... I think that this could help, rather than hinder, some of the discoverability related to log4j. I do quite frequently find myself seeing what is available in Maven central. If I found myself browsing around log4j, it could definitely spark some extra interest: Oh, they have something specific to JMS?, I'll have to look into that. I might discover aspects of log4j that I had not previously considered. Right now, most of those are buried inside of the code and the pom dependencies where I'm not as likely to investigate further. But having a list of modules named by their integration I may get more people excited to use log4j 2. It's about advertising. Now, maybe my argument doesn't work in my favor regarding log4j-streams, but it might if you consider Java's streams as an integration. In a way it is. In any case, I support the modularization of log4j along integration boundaries, which I think would help with osgi as well. On Thu, Apr 17, 2014 at 2:39 PM, Matt Sicker boa...@gmail.com wrote: Done. Deleted the two modules after branching to branches/experimental. On 17 April 2014 12:33, Matt Sicker boa...@gmail.com wrote: Thanks, Ralph. I'll move the experimental code to a feature branch. On 17 April 2014 12:27, Paul Benedict pbened...@apache.org wrote: If you want to retroactively create a branch, and you're doing Eclipse, simply show the project's SVN history; then select create a branch at the revision you want to split from. On Thu, Apr 17, 2014 at 1:16 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Google “svn move”. Ralph On Apr 17, 2014, at 10:33 AM, Matt Sicker boa...@gmail.com wrote: I know how to create one, but not retroactively. On 17 April 2014 10:11, Ralph Goers ralph.go...@dslextreme.comwrote: Matt, Creating a branch in subversion is trivial. A quick google would give you the answer to that. Everyone - Do we already have a sandbox? Ralph On Apr 17, 2014, at 6:29 AM, Matt Sicker boa...@gmail.com wrote: I'm not very good at subversion. I just put it in the trunk. If someone could move it to a branch, that would be great. Same goes for the experimental log4j-camel module I started yesterday. On 17 April 2014 06:49, Gary Gregory garydgreg...@gmail.comwrote: Now I am confused. I thought we decided to keep this in a branch, I could be wrong since there have been many back and forths. As of now, this means it will be released in 2.0. If so, why is it not in the core or api module? Gary On Mon, Apr 14, 2014 at 11:45 PM, mattsic...@apache.org wrote: Author: mattsicker Date: Tue Apr 15 03:44:59 2014 New Revision: 1587396 URL:
Re: New log4j-streams Module
I took care of it and added it to the experimental branch in svn (along with a log4j-camel module I was working on). On 29 April 2014 18:18, Bruce Brouwer bruce.brou...@gmail.com wrote: Was there any support in creating any of these new modules? On Fri, Apr 18, 2014 at 5:59 PM, Bruce Brouwer bruce.brou...@gmail.comwrote: I'll put together a list of things that I think could be pulled out of log4j-core because they are integrations with other tools. Go ahead and throw darts, that's what my list is for. * log4j-jms * log4j-mail * log4j-web * log4j-jpa * log4j-mongodb * log4j-couchdb Some more questionable ones to pull out * log4j-json * log4j-yaml On Fri, Apr 18, 2014 at 12:39 PM, Gary Gregory garydgreg...@gmail.comwrote: On Fri, Apr 18, 2014 at 11:17 AM, Matt Sicker boa...@gmail.com wrote: I agree with all that as well. Part of the no more modules problem comes from all the unnecessary OSGi modules. I'll be deleting those soon as I'm porting over the OSGi metadata to the appropriate modules so that extra parallel modules are unneeded. That will be good :) Gary On 17 April 2014 23:48, Ralph Goers ralph.go...@dslextreme.com wrote: I agree with you completely. In fact, the items you have specifically identified are where I would start. Are there more? Ralph On Apr 17, 2014, at 3:21 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: This discussion about having modules or not having modules keeps coming up and I see different opinions here on the log4j team. Generally, the argument of please, no more modules has won. I wanted to present my perspective to see if I can sway anyone's opinion. There are plenty of reasons why projects decide to make more modules. Projects like Spring make plenty of modules. As some have noted, this can make it difficult to find things sometimes, and I agree. Although there are ways around this with search.maven.org, it is still a bit of a pain. Some of this can be solved with documentation, some of it is probably not necessary for log4j. The Spring guys like to break out different modules because of the different features (e.g. batch, security, ...). Log4j is probably not big enough to warrant breaking it up across feature lines. However, another very valid reason to break out modules is for integrations. This is where I think log4j should be allowing more modules to be created: log4j-camel, log4j-ng-flume, log4j-jms, log4j-web, log4j-mongodb, ... I think that this could help, rather than hinder, some of the discoverability related to log4j. I do quite frequently find myself seeing what is available in Maven central. If I found myself browsing around log4j, it could definitely spark some extra interest: Oh, they have something specific to JMS?, I'll have to look into that. I might discover aspects of log4j that I had not previously considered. Right now, most of those are buried inside of the code and the pom dependencies where I'm not as likely to investigate further. But having a list of modules named by their integration I may get more people excited to use log4j 2. It's about advertising. Now, maybe my argument doesn't work in my favor regarding log4j-streams, but it might if you consider Java's streams as an integration. In a way it is. In any case, I support the modularization of log4j along integration boundaries, which I think would help with osgi as well. On Thu, Apr 17, 2014 at 2:39 PM, Matt Sicker boa...@gmail.com wrote: Done. Deleted the two modules after branching to branches/experimental. On 17 April 2014 12:33, Matt Sicker boa...@gmail.com wrote: Thanks, Ralph. I'll move the experimental code to a feature branch. On 17 April 2014 12:27, Paul Benedict pbened...@apache.org wrote: If you want to retroactively create a branch, and you're doing Eclipse, simply show the project's SVN history; then select create a branch at the revision you want to split from. On Thu, Apr 17, 2014 at 1:16 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Google “svn move”. Ralph On Apr 17, 2014, at 10:33 AM, Matt Sicker boa...@gmail.com wrote: I know how to create one, but not retroactively. On 17 April 2014 10:11, Ralph Goers ralph.go...@dslextreme.comwrote: Matt, Creating a branch in subversion is trivial. A quick google would give you the answer to that. Everyone - Do we already have a sandbox? Ralph On Apr 17, 2014, at 6:29 AM, Matt Sicker boa...@gmail.com wrote: I'm not very good at subversion. I just put it in the trunk. If someone could move it to a branch, that would be great. Same goes for the experimental log4j-camel module I started yesterday. On 17 April 2014 06:49, Gary Gregory garydgreg...@gmail.comwrote: Now I am confused. I thought we decided to keep this in a branch, I could be wrong since there have been many back and forths. As of now, this means it will be released in 2.0. If so, why is it not in the core or api
Re: Log4j Project Guidelines
I like the KISS approach for now as well. Gary On Tue, Apr 29, 2014 at 9:45 PM, Remko Popma remko.po...@gmail.com wrote: This should be a separate thread, but anyway... I would oppose using fair locks. Not only will throughput be much less, the benefits are debatable, since fairness of locks does not guarantee fairness of thread scheduling. So we would always pay a price in throughput without any guarantee of upside on the latency variance. Not a good trade-off. The solution here is not using different locking mechanisms but not using locking at all. That is, anyone who is concerned about latency variance (of which starvation is an extreme case) should be using asynchronous loggers. The numbers show that with the disruptor (Async Loggers) you get 3 to 5 *orders of magnitude* less latency. (Yes that means 1000x - 100,000x less latency.) And this is compared to AsyncAppender. Synchronous logging is not even in the picture here. I do agree that synchronizing on a String should be avoided, because Strings can be intern()-ed (and in the ConfigurationFactory case it was a String literal which is intern()ed by default), which means that our lock object is globally visible and other parts of the system could potentially synchronize on it and cause deadlock. That was a nice catch. However, I'm not convinced that java.util.concurrent.Lock is always better than the synchronized keyword. It is a more powerful API, and gives more low-level control, but it comes with more complexity and responsibility, the most obvious one being you need to manually unlock() it. With the synchronized keyword I don't need to worry if I or anyone refactoring the code still correctly unlock()s the lock in a finally clause. It just works. Nice and simple. It is only when I really need the more powerful API that I consider using Locks. For example when using separate read and write locks. Or if I need to use tryLock(). Things that I can't do with the synchronized keyword. Otherwise I prefer to keep it simple. My 2 cents. Remko On Wed, Apr 30, 2014 at 5:45 AM, Matt Sicker boa...@gmail.com wrote: Should we be using a fair lock? That's usually a lot slower than a typical one, but if it's more proper behavior, then it would make sense to go that route. On 29 April 2014 14:49, Jörn Huxhorn jhuxh...@googlemail.com wrote: Please keep in mind that synchronized is not fair. http://sourceforge.net/apps/trac/lilith/wiki/SynchronizedVsFairLock Yes, a fair ReentrantLock is way slower than an unfair one… but if starvation is caused by a logging framework then this is a serious issue in my opinion. Joern On 29. April 2014 at 01:05:26, Matt Sicker (boa...@gmail.com) wrote: I'll delegate my arguments to the SO post about it: http://stackoverflow.com/questions/442564/avoid-synchronizedthis-in-java In short, it's defensive programming. It's safer to synchronize on an internal object than on this. Plus, it aids in concurrency throughput instead of just using a synchronized method. On 28 April 2014 12:45, Ralph Goers wrote: Why are they not appropriate lock objects? Start a discussion before just changing them. Ralph On Apr 28, 2014, at 10:40 AM, Matt Sicker wrote: In that case, Item 69: prefer concurrency utilities to wait and notify. Sounds like we can just use a plain Object instance to lock (which is pretty much equivalent to using ReentrantLock) when doing normal locks, but instead of using .notifyAll() and .wait(), we should use the Condition interface (which would require using Lock as well). I agree that using synchronized(object) makes sense when it's all that's being done. However, I've been changing instances of synchronized(this) and synchronized(foo) where foo is not an appropriate lock object (e.g., a string, or a non-final object, things like that). On 28 April 2014 12:28, Ralph Goers wrote: Yes, guidelines called out by Effective Java are appropriate when they apply. As for concurrency, “New” isn’t always better than old. In a few places you changed synchronized(object) to use a Lock instead. There is little to no value in doing that and makes the code look a little more cluttered. However, if a ReadWriteLock can be used in place of synchronized that is a real benefit. The point of the guidelines are that when it comes to stuff like this, unless there is a guideline written down that says the current code is wrong discuss it on the list before making a change. Ralph On Apr 28, 2014, at 9:35 AM, Matt Sicker wrote: What about style things covered by Effective Java? These are pretty much all good ideas. Also, how about some guidelines on concurrency? I'd recommend not using the old concurrency stuff and instead using java.util.concurrent.* for more effective concurrency. This doesn't include the Thread vs Runnable
[jira] [Created] (LOG4J2-625) Serialization error with SocketAppender and Asynch Logger
Bryan Hsueh created LOG4J2-625:
--
Summary: Serialization error with SocketAppender and Asynch Logger
Key: LOG4J2-625
URL: https://issues.apache.org/jira/browse/LOG4J2-625
Project: Log4j 2
Issue Type: Question
Components: Appenders
Affects Versions: 2.0-rc1
Environment: Ubuntu 12.04, Java 7
Reporter: Bryan Hsueh
I'm testing a simple SocketAppender, which works fine until I switch to
asynchronous loggers. Once I turn on async logging, I get:
2014-04-29 21:17:26,029 ERROR Serialization of LogEvent failed.
java.io.NotSerializableException:
org.apache.logging.log4j.core.Logger$PrivateConfig
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1183)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1547)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1508)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1431)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1177)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1547)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1508)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1431)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1177)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
at
org.apache.logging.log4j.core.layout.SerializedLayout.toByteArray(SerializedLayout.java:64)
at
org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:118)
at
org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:97)
at
org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:425)
at
org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:406)
at
org.apache.logging.log4j.core.Logger$PrivateConfig.logEvent(Logger.java:275)
at
org.apache.logging.log4j.core.async.AsyncLogger.actualAsyncLog(AsyncLogger.java:289)
at
org.apache.logging.log4j.core.async.RingBufferLogEvent.execute(RingBufferLogEvent.java:99)
at
org.apache.logging.log4j.core.async.RingBufferLogEventHandler.onEvent(RingBufferLogEventHandler.java:43)
at
org.apache.logging.log4j.core.async.RingBufferLogEventHandler.onEvent(RingBufferLogEventHandler.java:28)
at
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
My client is configured with:
?xml version=1.0 encoding=UTF-8?
Configuration status=INFO
Appenders
Console name=MyConsole target=SYSTEM_OUT
PatternLayout pattern=%d{HH:mm:ss.SSS}{EST} %-5level- %msg%n/
/Console
Socket name=MySocket host=localhost port=
SerializedLayout /
/Socket
/Appenders
Loggers
Root level=INFO
AppenderRef ref=MyConsole/
AppenderRef ref=MySocket/
/Root
/Loggers
/Configuration
My server is configured with:
?xml version=1.0 encoding=UTF-8?
Configuration status=INFO
Appenders
Console name=MyConsole target=SYSTEM_OUT
PatternLayout pattern=%d{HH:mm:ss.SSS}{EST} %-5level- %msg%n/
/Console
/Appenders
Loggers
Root level=INFO
AppenderRef ref=MyConsole/
/Root
/Loggers
/Configuration
The client just does a LogManager.getLogger().info({}, hello).
The server just creates a SocketServer:
SocketServer server = new SocketServer();
server.run();
All works fine until I add this into the client:
System.setProperty(Log4jContextSelector,
org.apache.logging.log4j.core.async.AsyncLoggerContextSelector);
Am I missing something? Please advise.
Thanks
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: New log4j-streams Module
What do you mean “you took care of it?” jpa, jms, web as well as the json and yaml support are still in core. I don’t know that we have agreed to move them out yet. Ralph On Apr 29, 2014, at 4:28 PM, Matt Sicker boa...@gmail.com wrote: I took care of it and added it to the experimental branch in svn (along with a log4j-camel module I was working on). On 29 April 2014 18:18, Bruce Brouwer bruce.brou...@gmail.com wrote: Was there any support in creating any of these new modules? On Fri, Apr 18, 2014 at 5:59 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: I'll put together a list of things that I think could be pulled out of log4j-core because they are integrations with other tools. Go ahead and throw darts, that's what my list is for. * log4j-jms * log4j-mail * log4j-web * log4j-jpa * log4j-mongodb * log4j-couchdb Some more questionable ones to pull out * log4j-json * log4j-yaml On Fri, Apr 18, 2014 at 12:39 PM, Gary Gregory garydgreg...@gmail.com wrote: On Fri, Apr 18, 2014 at 11:17 AM, Matt Sicker boa...@gmail.com wrote: I agree with all that as well. Part of the no more modules problem comes from all the unnecessary OSGi modules. I'll be deleting those soon as I'm porting over the OSGi metadata to the appropriate modules so that extra parallel modules are unneeded. That will be good :) Gary On 17 April 2014 23:48, Ralph Goers ralph.go...@dslextreme.com wrote: I agree with you completely. In fact, the items you have specifically identified are where I would start. Are there more? Ralph On Apr 17, 2014, at 3:21 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: This discussion about having modules or not having modules keeps coming up and I see different opinions here on the log4j team. Generally, the argument of please, no more modules has won. I wanted to present my perspective to see if I can sway anyone's opinion. There are plenty of reasons why projects decide to make more modules. Projects like Spring make plenty of modules. As some have noted, this can make it difficult to find things sometimes, and I agree. Although there are ways around this with search.maven.org, it is still a bit of a pain. Some of this can be solved with documentation, some of it is probably not necessary for log4j. The Spring guys like to break out different modules because of the different features (e.g. batch, security, ...). Log4j is probably not big enough to warrant breaking it up across feature lines. However, another very valid reason to break out modules is for integrations. This is where I think log4j should be allowing more modules to be created: log4j-camel, log4j-ng-flume, log4j-jms, log4j-web, log4j-mongodb, ... I think that this could help, rather than hinder, some of the discoverability related to log4j. I do quite frequently find myself seeing what is available in Maven central. If I found myself browsing around log4j, it could definitely spark some extra interest: Oh, they have something specific to JMS?, I'll have to look into that. I might discover aspects of log4j that I had not previously considered. Right now, most of those are buried inside of the code and the pom dependencies where I'm not as likely to investigate further. But having a list of modules named by their integration I may get more people excited to use log4j 2. It's about advertising. Now, maybe my argument doesn't work in my favor regarding log4j-streams, but it might if you consider Java's streams as an integration. In a way it is. In any case, I support the modularization of log4j along integration boundaries, which I think would help with osgi as well. On Thu, Apr 17, 2014 at 2:39 PM, Matt Sicker boa...@gmail.com wrote: Done. Deleted the two modules after branching to branches/experimental. On 17 April 2014 12:33, Matt Sicker boa...@gmail.com wrote: Thanks, Ralph. I'll move the experimental code to a feature branch. On 17 April 2014 12:27, Paul Benedict pbened...@apache.org wrote: If you want to retroactively create a branch, and you're doing Eclipse, simply show the project's SVN history; then select create a branch at the revision you want to split from. On Thu, Apr 17, 2014 at 1:16 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Google “svn move”. Ralph On Apr 17, 2014, at 10:33 AM, Matt Sicker boa...@gmail.com wrote: I know how to create one, but not retroactively. On 17 April 2014 10:11, Ralph Goers ralph.go...@dslextreme.com wrote: Matt, Creating a branch in subversion is trivial. A quick google would give you the answer to that. Everyone - Do we already have a sandbox? Ralph On Apr 17, 2014, at 6:29 AM, Matt Sicker boa...@gmail.com wrote: I'm not very good at subversion. I just put it in the trunk. If someone could move it to a branch, that would be great. Same goes for the experimental log4j-camel module I
[jira] [Resolved] (LOG4J2-625) Serialization error with SocketAppender and Asynch Logger
[
https://issues.apache.org/jira/browse/LOG4J2-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved LOG4J2-625.
Resolution: Duplicate
Closed as a duplicate.
Serialization error with SocketAppender and Asynch Logger
-
Key: LOG4J2-625
URL: https://issues.apache.org/jira/browse/LOG4J2-625
Project: Log4j 2
Issue Type: Question
Components: Appenders
Affects Versions: 2.0-rc1
Environment: Ubuntu 12.04, Java 7
Reporter: Bryan Hsueh
I'm testing a simple SocketAppender, which works fine until I switch to
asynchronous loggers. Once I turn on async logging, I get:
2014-04-29 21:17:26,029 ERROR Serialization of LogEvent failed.
java.io.NotSerializableException:
org.apache.logging.log4j.core.Logger$PrivateConfig
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1183)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1547)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1508)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1431)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1177)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1547)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1508)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1431)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1177)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
at
org.apache.logging.log4j.core.layout.SerializedLayout.toByteArray(SerializedLayout.java:64)
at
org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:118)
at
org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:97)
at
org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:425)
at
org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:406)
at
org.apache.logging.log4j.core.Logger$PrivateConfig.logEvent(Logger.java:275)
at
org.apache.logging.log4j.core.async.AsyncLogger.actualAsyncLog(AsyncLogger.java:289)
at
org.apache.logging.log4j.core.async.RingBufferLogEvent.execute(RingBufferLogEvent.java:99)
at
org.apache.logging.log4j.core.async.RingBufferLogEventHandler.onEvent(RingBufferLogEventHandler.java:43)
at
org.apache.logging.log4j.core.async.RingBufferLogEventHandler.onEvent(RingBufferLogEventHandler.java:28)
at
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
My client is configured with:
?xml version=1.0 encoding=UTF-8?
Configuration status=INFO
Appenders
Console name=MyConsole target=SYSTEM_OUT
PatternLayout pattern=%d{HH:mm:ss.SSS}{EST} %-5level- %msg%n/
/Console
Socket name=MySocket host=localhost port=
SerializedLayout /
/Socket
/Appenders
Loggers
Root level=INFO
AppenderRef ref=MyConsole/
AppenderRef ref=MySocket/
/Root
/Loggers
/Configuration
My server is configured with:
?xml version=1.0 encoding=UTF-8?
Configuration status=INFO
Appenders
Console name=MyConsole target=SYSTEM_OUT
PatternLayout pattern=%d{HH:mm:ss.SSS}{EST} %-5level- %msg%n/
/Console
/Appenders
Loggers
Root level=INFO
AppenderRef ref=MyConsole/
/Root
/Loggers
/Configuration
The client just does a LogManager.getLogger().info({}, hello).
The server just creates a SocketServer:
SocketServer server = new SocketServer();
server.run();
All works fine until I add this into the client:
System.setProperty(Log4jContextSelector,
org.apache.logging.log4j.core.async.AsyncLoggerContextSelector);
Am I missing something? Please advise.
Thanks
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: New log4j-streams Module
I mean I split off log4j-streams and put it in a branch. It being the streams module. The web stuff actually makes sense to keep in core. JPA and JMS should probably be in their own modules. The syslog stuff could be at least in its own packages but still in log4j-core. I'm unsure about the JSON/YAML ones since they're strictly for configuration and don't really add many classes overall. On 29 April 2014 21:55, Ralph Goers ralph.go...@dslextreme.com wrote: What do you mean “you took care of it?” jpa, jms, web as well as the json and yaml support are still in core. I don’t know that we have agreed to move them out yet. Ralph On Apr 29, 2014, at 4:28 PM, Matt Sicker boa...@gmail.com wrote: I took care of it and added it to the experimental branch in svn (along with a log4j-camel module I was working on). On 29 April 2014 18:18, Bruce Brouwer bruce.brou...@gmail.com wrote: Was there any support in creating any of these new modules? On Fri, Apr 18, 2014 at 5:59 PM, Bruce Brouwer bruce.brou...@gmail.comwrote: I'll put together a list of things that I think could be pulled out of log4j-core because they are integrations with other tools. Go ahead and throw darts, that's what my list is for. * log4j-jms * log4j-mail * log4j-web * log4j-jpa * log4j-mongodb * log4j-couchdb Some more questionable ones to pull out * log4j-json * log4j-yaml On Fri, Apr 18, 2014 at 12:39 PM, Gary Gregory garydgreg...@gmail.comwrote: On Fri, Apr 18, 2014 at 11:17 AM, Matt Sicker boa...@gmail.com wrote: I agree with all that as well. Part of the no more modules problem comes from all the unnecessary OSGi modules. I'll be deleting those soon as I'm porting over the OSGi metadata to the appropriate modules so that extra parallel modules are unneeded. That will be good :) Gary On 17 April 2014 23:48, Ralph Goers ralph.go...@dslextreme.comwrote: I agree with you completely. In fact, the items you have specifically identified are where I would start. Are there more? Ralph On Apr 17, 2014, at 3:21 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: This discussion about having modules or not having modules keeps coming up and I see different opinions here on the log4j team. Generally, the argument of please, no more modules has won. I wanted to present my perspective to see if I can sway anyone's opinion. There are plenty of reasons why projects decide to make more modules. Projects like Spring make plenty of modules. As some have noted, this can make it difficult to find things sometimes, and I agree. Although there are ways around this with search.maven.org, it is still a bit of a pain. Some of this can be solved with documentation, some of it is probably not necessary for log4j. The Spring guys like to break out different modules because of the different features (e.g. batch, security, ...). Log4j is probably not big enough to warrant breaking it up across feature lines. However, another very valid reason to break out modules is for integrations. This is where I think log4j should be allowing more modules to be created: log4j-camel, log4j-ng-flume, log4j-jms, log4j-web, log4j-mongodb, ... I think that this could help, rather than hinder, some of the discoverability related to log4j. I do quite frequently find myself seeing what is available in Maven central. If I found myself browsing around log4j, it could definitely spark some extra interest: Oh, they have something specific to JMS?, I'll have to look into that. I might discover aspects of log4j that I had not previously considered. Right now, most of those are buried inside of the code and the pom dependencies where I'm not as likely to investigate further. But having a list of modules named by their integration I may get more people excited to use log4j 2. It's about advertising. Now, maybe my argument doesn't work in my favor regarding log4j-streams, but it might if you consider Java's streams as an integration. In a way it is. In any case, I support the modularization of log4j along integration boundaries, which I think would help with osgi as well. On Thu, Apr 17, 2014 at 2:39 PM, Matt Sicker boa...@gmail.comwrote: Done. Deleted the two modules after branching to branches/experimental. On 17 April 2014 12:33, Matt Sicker boa...@gmail.com wrote: Thanks, Ralph. I'll move the experimental code to a feature branch. On 17 April 2014 12:27, Paul Benedict pbened...@apache.org wrote: If you want to retroactively create a branch, and you're doing Eclipse, simply show the project's SVN history; then select create a branch at the revision you want to split from. On Thu, Apr 17, 2014 at 1:16 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Google “svn move”. Ralph On Apr 17, 2014, at 10:33 AM, Matt Sicker boa...@gmail.com wrote: I know how to create one, but not retroactively. On 17 April 2014 10:11, Ralph Goers
Re: Log4j Project Guidelines
If you want more than one condition monitor, it's also better to use Lock. I'll definitely agree on the simplicity of synchronizing on an internal Object instance, though. Locking on this, however, is generally a bad idea because any other code can synchronize on the object as well by accident and cause weird problems. On 29 April 2014 20:51, Gary Gregory garydgreg...@gmail.com wrote: I like the KISS approach for now as well. Gary On Tue, Apr 29, 2014 at 9:45 PM, Remko Popma remko.po...@gmail.comwrote: This should be a separate thread, but anyway... I would oppose using fair locks. Not only will throughput be much less, the benefits are debatable, since fairness of locks does not guarantee fairness of thread scheduling. So we would always pay a price in throughput without any guarantee of upside on the latency variance. Not a good trade-off. The solution here is not using different locking mechanisms but not using locking at all. That is, anyone who is concerned about latency variance (of which starvation is an extreme case) should be using asynchronous loggers. The numbers show that with the disruptor (Async Loggers) you get 3 to 5 *orders of magnitude* less latency. (Yes that means 1000x - 100,000x less latency.) And this is compared to AsyncAppender. Synchronous logging is not even in the picture here. I do agree that synchronizing on a String should be avoided, because Strings can be intern()-ed (and in the ConfigurationFactory case it was a String literal which is intern()ed by default), which means that our lock object is globally visible and other parts of the system could potentially synchronize on it and cause deadlock. That was a nice catch. However, I'm not convinced that java.util.concurrent.Lock is always better than the synchronized keyword. It is a more powerful API, and gives more low-level control, but it comes with more complexity and responsibility, the most obvious one being you need to manually unlock() it. With the synchronized keyword I don't need to worry if I or anyone refactoring the code still correctly unlock()s the lock in a finally clause. It just works. Nice and simple. It is only when I really need the more powerful API that I consider using Locks. For example when using separate read and write locks. Or if I need to use tryLock(). Things that I can't do with the synchronized keyword. Otherwise I prefer to keep it simple. My 2 cents. Remko On Wed, Apr 30, 2014 at 5:45 AM, Matt Sicker boa...@gmail.com wrote: Should we be using a fair lock? That's usually a lot slower than a typical one, but if it's more proper behavior, then it would make sense to go that route. On 29 April 2014 14:49, Jörn Huxhorn jhuxh...@googlemail.com wrote: Please keep in mind that synchronized is not fair. http://sourceforge.net/apps/trac/lilith/wiki/SynchronizedVsFairLock Yes, a fair ReentrantLock is way slower than an unfair one… but if starvation is caused by a logging framework then this is a serious issue in my opinion. Joern On 29. April 2014 at 01:05:26, Matt Sicker (boa...@gmail.com) wrote: I'll delegate my arguments to the SO post about it: http://stackoverflow.com/questions/442564/avoid-synchronizedthis-in-java In short, it's defensive programming. It's safer to synchronize on an internal object than on this. Plus, it aids in concurrency throughput instead of just using a synchronized method. On 28 April 2014 12:45, Ralph Goers wrote: Why are they not appropriate lock objects? Start a discussion before just changing them. Ralph On Apr 28, 2014, at 10:40 AM, Matt Sicker wrote: In that case, Item 69: prefer concurrency utilities to wait and notify. Sounds like we can just use a plain Object instance to lock (which is pretty much equivalent to using ReentrantLock) when doing normal locks, but instead of using .notifyAll() and .wait(), we should use the Condition interface (which would require using Lock as well). I agree that using synchronized(object) makes sense when it's all that's being done. However, I've been changing instances of synchronized(this) and synchronized(foo) where foo is not an appropriate lock object (e.g., a string, or a non-final object, things like that). On 28 April 2014 12:28, Ralph Goers wrote: Yes, guidelines called out by Effective Java are appropriate when they apply. As for concurrency, “New” isn’t always better than old. In a few places you changed synchronized(object) to use a Lock instead. There is little to no value in doing that and makes the code look a little more cluttered. However, if a ReadWriteLock can be used in place of synchronized that is a real benefit. The point of the guidelines are that when it comes to stuff like this, unless there is a guideline written down that says the current code is wrong discuss it on the list before making a change.
Re: Log4j Project Guidelines
Agreed that unless the synchronization is part of the public API it is better to lock on an internal object (e.g. private Object lock = new Object(); ). On the other hand, OutputStreamManager and subclasses have some synchronized public/protected methods and in this case the synchronization on this is part of the public API. On Wed, Apr 30, 2014 at 1:24 PM, Matt Sicker boa...@gmail.com wrote: If you want more than one condition monitor, it's also better to use Lock. I'll definitely agree on the simplicity of synchronizing on an internal Object instance, though. Locking on this, however, is generally a bad idea because any other code can synchronize on the object as well by accident and cause weird problems. On 29 April 2014 20:51, Gary Gregory garydgreg...@gmail.com wrote: I like the KISS approach for now as well. Gary On Tue, Apr 29, 2014 at 9:45 PM, Remko Popma remko.po...@gmail.comwrote: This should be a separate thread, but anyway... I would oppose using fair locks. Not only will throughput be much less, the benefits are debatable, since fairness of locks does not guarantee fairness of thread scheduling. So we would always pay a price in throughput without any guarantee of upside on the latency variance. Not a good trade-off. The solution here is not using different locking mechanisms but not using locking at all. That is, anyone who is concerned about latency variance (of which starvation is an extreme case) should be using asynchronous loggers. The numbers show that with the disruptor (Async Loggers) you get 3 to 5 *orders of magnitude* less latency. (Yes that means 1000x - 100,000x less latency.) And this is compared to AsyncAppender. Synchronous logging is not even in the picture here. I do agree that synchronizing on a String should be avoided, because Strings can be intern()-ed (and in the ConfigurationFactory case it was a String literal which is intern()ed by default), which means that our lock object is globally visible and other parts of the system could potentially synchronize on it and cause deadlock. That was a nice catch. However, I'm not convinced that java.util.concurrent.Lock is always better than the synchronized keyword. It is a more powerful API, and gives more low-level control, but it comes with more complexity and responsibility, the most obvious one being you need to manually unlock() it. With the synchronized keyword I don't need to worry if I or anyone refactoring the code still correctly unlock()s the lock in a finally clause. It just works. Nice and simple. It is only when I really need the more powerful API that I consider using Locks. For example when using separate read and write locks. Or if I need to use tryLock(). Things that I can't do with the synchronized keyword. Otherwise I prefer to keep it simple. My 2 cents. Remko On Wed, Apr 30, 2014 at 5:45 AM, Matt Sicker boa...@gmail.com wrote: Should we be using a fair lock? That's usually a lot slower than a typical one, but if it's more proper behavior, then it would make sense to go that route. On 29 April 2014 14:49, Jörn Huxhorn jhuxh...@googlemail.com wrote: Please keep in mind that synchronized is not fair. http://sourceforge.net/apps/trac/lilith/wiki/SynchronizedVsFairLock Yes, a fair ReentrantLock is way slower than an unfair one… but if starvation is caused by a logging framework then this is a serious issue in my opinion. Joern On 29. April 2014 at 01:05:26, Matt Sicker (boa...@gmail.com) wrote: I'll delegate my arguments to the SO post about it: http://stackoverflow.com/questions/442564/avoid-synchronizedthis-in-java In short, it's defensive programming. It's safer to synchronize on an internal object than on this. Plus, it aids in concurrency throughput instead of just using a synchronized method. On 28 April 2014 12:45, Ralph Goers wrote: Why are they not appropriate lock objects? Start a discussion before just changing them. Ralph On Apr 28, 2014, at 10:40 AM, Matt Sicker wrote: In that case, Item 69: prefer concurrency utilities to wait and notify. Sounds like we can just use a plain Object instance to lock (which is pretty much equivalent to using ReentrantLock) when doing normal locks, but instead of using .notifyAll() and .wait(), we should use the Condition interface (which would require using Lock as well). I agree that using synchronized(object) makes sense when it's all that's being done. However, I've been changing instances of synchronized(this) and synchronized(foo) where foo is not an appropriate lock object (e.g., a string, or a non-final object, things like that). On 28 April 2014 12:28, Ralph Goers wrote: Yes, guidelines called out by Effective Java are appropriate when they apply. As for concurrency, “New” isn’t always better than old. In a few places you changed synchronized(object) to use a Lock
[jira] [Commented] (LOG4J2-615) Why Rolling file appender writes to console also.
[
https://issues.apache.org/jira/browse/LOG4J2-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13985194#comment-13985194
]
sivan commented on LOG4J2-615:
--
Thanks for both advises. Now its working fine.
Why Rolling file appender writes to console also.
-
Key: LOG4J2-615
URL: https://issues.apache.org/jira/browse/LOG4J2-615
Project: Log4j 2
Issue Type: Bug
Environment: Java 7
Reporter: sivan
Priority: Critical
Rolling file appender writes to console also. java 7 is used. The
configuration is as below.
{code}
?xml version=1.0 encoding=UTF-8?
configuration
properties
property name=patternUMP${sys:logPattern}/property
property
name=filePattern${sys:logfilepath}//$${date:-MM}//${sys:oft.appserver}-out-%d{-MM-dd}.log/property
property
name=fileName${sys:logfilepath}//${sys:oft.appserver}-out.log/property
/properties
appenders
RollingFile name=RollingFile fileName=${fileName}
filePattern=${filePattern}
PatternLayout
pattern${patternUMP}/pattern
/PatternLayout
Policies
TimeBasedTriggeringPolicy /
SizeBasedTriggeringPolicy /
/Policies
DefaultRolloverStrategy compressionLevel=0 max=3/
/RollingFile
Async name=AsyncAppender includeLocation=true
AppenderRef ref=RollingFile/
/Async
/appenders
loggers
AsyncLogger name=sso level=info includeLocation=true
AppenderRef ref=AsyncAppender/
/AsyncLogger
AsyncLogger name=webservice level=info
includeLocation=true
AppenderRef ref=AsyncAppender/
/AsyncLogger
/loggers
/configuration
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-615) Why Rolling file appender writes to console also.
[
https://issues.apache.org/jira/browse/LOG4J2-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma closed LOG4J2-615.
--
Glad to hear that. I'll close this issue. Feel free to re-open or raise another
issue if necessary.
Why Rolling file appender writes to console also.
-
Key: LOG4J2-615
URL: https://issues.apache.org/jira/browse/LOG4J2-615
Project: Log4j 2
Issue Type: Bug
Environment: Java 7
Reporter: sivan
Priority: Critical
Rolling file appender writes to console also. java 7 is used. The
configuration is as below.
{code}
?xml version=1.0 encoding=UTF-8?
configuration
properties
property name=patternUMP${sys:logPattern}/property
property
name=filePattern${sys:logfilepath}//$${date:-MM}//${sys:oft.appserver}-out-%d{-MM-dd}.log/property
property
name=fileName${sys:logfilepath}//${sys:oft.appserver}-out.log/property
/properties
appenders
RollingFile name=RollingFile fileName=${fileName}
filePattern=${filePattern}
PatternLayout
pattern${patternUMP}/pattern
/PatternLayout
Policies
TimeBasedTriggeringPolicy /
SizeBasedTriggeringPolicy /
/Policies
DefaultRolloverStrategy compressionLevel=0 max=3/
/RollingFile
Async name=AsyncAppender includeLocation=true
AppenderRef ref=RollingFile/
/Async
/appenders
loggers
AsyncLogger name=sso level=info includeLocation=true
AppenderRef ref=AsyncAppender/
/AsyncLogger
AsyncLogger name=webservice level=info
includeLocation=true
AppenderRef ref=AsyncAppender/
/AsyncLogger
/loggers
/configuration
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
