[jira] [Closed] (LOG4J2-1842) Expand SystemPropertiesLookup syntax
[
https://issues.apache.org/jira/browse/LOG4J2-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihhail Lapushkin closed LOG4J2-1842.
-
Resolution: Workaround
> Expand SystemPropertiesLookup syntax
>
>
> Key: LOG4J2-1842
> URL: https://issues.apache.org/jira/browse/LOG4J2-1842
> Project: Log4j 2
> Issue Type: Improvement
> Components: Lookups
>Reporter: Mihhail Lapushkin
>Priority: Minor
>
> I've been using a modified version of {{SystemPropertiesLookup}} in my
> project. Maybe it could be part of the library.
> The idea is to allow a series of property keys to be specified. If one of the
> properties is present, then it is used. If none are present, then the default
> value is used. For example:
> {code}
> level="${sys:myapp.log.level|myapp.log.level.dao|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.service|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.controller|warn}"/>
> {code}
> This allows me to quickly rerun the app with different log levels without
> fiddling with the configuration file or JConsole. Defaults represent
> production settings, so that nothing extra needs to be specified to run the
> app.
> This work nice in other places as well:
> {code}
>
> {code}
> Disables colors by default (for production build), but leaves an easy way to
> turn them on for development.
> When no pipes are present in the expression, then the standard property
> lookup is used, so the change is backwards-compatible.
> Can be a separate lookup if needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1842) Expand SystemPropertiesLookup syntax
[
https://issues.apache.org/jira/browse/LOG4J2-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906591#comment-15906591
]
Mihhail Lapushkin edited comment on LOG4J2-1842 at 3/12/17 5:13 PM:
Hm, that's a nice discovery. The syntax is actually:
{{$sys:some.property:-defaultValue}} (note the dash). Maybe it
would be enough for me ATM.
However, I am opened to refactor this to be part of {{StrSubstitutor}} or just
update the docs.
was (Author: mlap):
Hm, that's a nice discovery. The syntax is actually:
{{$sys:some.property:-defaultValue}} (note the dash). Maybe it
would be enough for me ATM.
However, I am opened to refactor this to be part of {{StrSubstitutor}}.
> Expand SystemPropertiesLookup syntax
>
>
> Key: LOG4J2-1842
> URL: https://issues.apache.org/jira/browse/LOG4J2-1842
> Project: Log4j 2
> Issue Type: Improvement
> Components: Lookups
>Reporter: Mihhail Lapushkin
>Priority: Minor
>
> I've been using a modified version of {{SystemPropertiesLookup}} in my
> project. Maybe it could be part of the library.
> The idea is to allow a series of property keys to be specified. If one of the
> properties is present, then it is used. If none are present, then the default
> value is used. For example:
> {code}
> level="${sys:myapp.log.level|myapp.log.level.dao|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.service|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.controller|warn}"/>
> {code}
> This allows me to quickly rerun the app with different log levels without
> fiddling with the configuration file or JConsole. Defaults represent
> production settings, so that nothing extra needs to be specified to run the
> app.
> This work nice in other places as well:
> {code}
>
> {code}
> Disables colors by default (for production build), but leaves an easy way to
> turn them on for development.
> When no pipes are present in the expression, then the standard property
> lookup is used, so the change is backwards-compatible.
> Can be a separate lookup if needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1842) Expand SystemPropertiesLookup syntax
[
https://issues.apache.org/jira/browse/LOG4J2-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906591#comment-15906591
]
Mihhail Lapushkin edited comment on LOG4J2-1842 at 3/12/17 5:13 PM:
Hm, that's a nice discovery. The syntax is actually:
{{$sys:some.property:-defaultValue}} (note the dash). Maybe it
would be enough for me ATM.
However, I am opened to refactor this to be part of {{StrSubstitutor}} or just
update the docs to include {{:-}}.
was (Author: mlap):
Hm, that's a nice discovery. The syntax is actually:
{{$sys:some.property:-defaultValue}} (note the dash). Maybe it
would be enough for me ATM.
However, I am opened to refactor this to be part of {{StrSubstitutor}} or just
update the docs.
> Expand SystemPropertiesLookup syntax
>
>
> Key: LOG4J2-1842
> URL: https://issues.apache.org/jira/browse/LOG4J2-1842
> Project: Log4j 2
> Issue Type: Improvement
> Components: Lookups
>Reporter: Mihhail Lapushkin
>Priority: Minor
>
> I've been using a modified version of {{SystemPropertiesLookup}} in my
> project. Maybe it could be part of the library.
> The idea is to allow a series of property keys to be specified. If one of the
> properties is present, then it is used. If none are present, then the default
> value is used. For example:
> {code}
> level="${sys:myapp.log.level|myapp.log.level.dao|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.service|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.controller|warn}"/>
> {code}
> This allows me to quickly rerun the app with different log levels without
> fiddling with the configuration file or JConsole. Defaults represent
> production settings, so that nothing extra needs to be specified to run the
> app.
> This work nice in other places as well:
> {code}
>
> {code}
> Disables colors by default (for production build), but leaves an easy way to
> turn them on for development.
> When no pipes are present in the expression, then the standard property
> lookup is used, so the change is backwards-compatible.
> Can be a separate lookup if needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1842) Expand SystemPropertiesLookup syntax
[
https://issues.apache.org/jira/browse/LOG4J2-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906591#comment-15906591
]
Mihhail Lapushkin edited comment on LOG4J2-1842 at 3/12/17 5:11 PM:
Hm, that's a nice discovery. The syntax is actually:
{{$sys:some.property:-defaultValue}} (note the dash). Maybe it
would be enough for me ATM.
However, I am opened to refactor this to be part of {{StrSubstitutor}}.
was (Author: mlap):
Hm, that's a nice discovery. The syntax is actually:
{{$sys:some.property:-defaultValue}} (note the dash). Maybe it
would be enough for me ATM.
However, I am opened to refactor this to be part of `StrSubstitutor`.
> Expand SystemPropertiesLookup syntax
>
>
> Key: LOG4J2-1842
> URL: https://issues.apache.org/jira/browse/LOG4J2-1842
> Project: Log4j 2
> Issue Type: Improvement
> Components: Lookups
>Reporter: Mihhail Lapushkin
>Priority: Minor
>
> I've been using a modified version of {{SystemPropertiesLookup}} in my
> project. Maybe it could be part of the library.
> The idea is to allow a series of property keys to be specified. If one of the
> properties is present, then it is used. If none are present, then the default
> value is used. For example:
> {code}
> level="${sys:myapp.log.level|myapp.log.level.dao|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.service|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.controller|warn}"/>
> {code}
> This allows me to quickly rerun the app with different log levels without
> fiddling with the configuration file or JConsole. Defaults represent
> production settings, so that nothing extra needs to be specified to run the
> app.
> This work nice in other places as well:
> {code}
>
> {code}
> Disables colors by default (for production build), but leaves an easy way to
> turn them on for development.
> When no pipes are present in the expression, then the standard property
> lookup is used, so the change is backwards-compatible.
> Can be a separate lookup if needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1842) Expand SystemPropertiesLookup syntax
[
https://issues.apache.org/jira/browse/LOG4J2-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906591#comment-15906591
]
Mihhail Lapushkin edited comment on LOG4J2-1842 at 3/12/17 5:11 PM:
Hm, that's a nice discovery. The syntax is actually:
{{$sys:some.property:-defaultValue}} (note the dash). Maybe it
would be enough for me ATM.
However, I am opened to refactor this to be part of `StrSubstitutor`.
was (Author: mlap):
Hm, that's a nice discovery. The syntax is actually: {{
${sys:some.property:-defaultValue} }} (note the dash). Maybe it would be enough
for me ATM.
However, I am opened to refactor this to be part of `StrSubstitutor`.
> Expand SystemPropertiesLookup syntax
>
>
> Key: LOG4J2-1842
> URL: https://issues.apache.org/jira/browse/LOG4J2-1842
> Project: Log4j 2
> Issue Type: Improvement
> Components: Lookups
>Reporter: Mihhail Lapushkin
>Priority: Minor
>
> I've been using a modified version of {{SystemPropertiesLookup}} in my
> project. Maybe it could be part of the library.
> The idea is to allow a series of property keys to be specified. If one of the
> properties is present, then it is used. If none are present, then the default
> value is used. For example:
> {code}
> level="${sys:myapp.log.level|myapp.log.level.dao|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.service|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.controller|warn}"/>
> {code}
> This allows me to quickly rerun the app with different log levels without
> fiddling with the configuration file or JConsole. Defaults represent
> production settings, so that nothing extra needs to be specified to run the
> app.
> This work nice in other places as well:
> {code}
>
> {code}
> Disables colors by default (for production build), but leaves an easy way to
> turn them on for development.
> When no pipes are present in the expression, then the standard property
> lookup is used, so the change is backwards-compatible.
> Can be a separate lookup if needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1842) Expand SystemPropertiesLookup syntax
[
https://issues.apache.org/jira/browse/LOG4J2-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906591#comment-15906591
]
Mihhail Lapushkin edited comment on LOG4J2-1842 at 3/12/17 5:09 PM:
Hm, that's a nice discovery. The syntax is actually: {{
${sys:some.property:-defaultValue} }} (note the dash). Maybe it would be enough
for me ATM.
However, I am opened to refactor this to be part of `StrSubstitutor`.
was (Author: mlap):
Hm, that's a nice discovery. The syntax is actually:
{{${sys:some.property:-defaultValue}}} (note the dash). Maybe it would be
enough for me ATM.
However, I am opened to refactor this to be part of `StrSubstitutor`.
> Expand SystemPropertiesLookup syntax
>
>
> Key: LOG4J2-1842
> URL: https://issues.apache.org/jira/browse/LOG4J2-1842
> Project: Log4j 2
> Issue Type: Improvement
> Components: Lookups
>Reporter: Mihhail Lapushkin
>Priority: Minor
>
> I've been using a modified version of {{SystemPropertiesLookup}} in my
> project. Maybe it could be part of the library.
> The idea is to allow a series of property keys to be specified. If one of the
> properties is present, then it is used. If none are present, then the default
> value is used. For example:
> {code}
> level="${sys:myapp.log.level|myapp.log.level.dao|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.service|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.controller|warn}"/>
> {code}
> This allows me to quickly rerun the app with different log levels without
> fiddling with the configuration file or JConsole. Defaults represent
> production settings, so that nothing extra needs to be specified to run the
> app.
> This work nice in other places as well:
> {code}
>
> {code}
> Disables colors by default (for production build), but leaves an easy way to
> turn them on for development.
> When no pipes are present in the expression, then the standard property
> lookup is used, so the change is backwards-compatible.
> Can be a separate lookup if needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1842) Expand SystemPropertiesLookup syntax
[
https://issues.apache.org/jira/browse/LOG4J2-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906591#comment-15906591
]
Mihhail Lapushkin edited comment on LOG4J2-1842 at 3/12/17 5:09 PM:
Hm, that's a nice discovery. The syntax is actually:
{{${sys:some.property:-defaultValue}}} (note the dash). Maybe it would be
enough for me ATM.
However, I am opened to refactor this to be part of `StrSubstitutor`.
was (Author: mlap):
Hm, that's a nice discovery. The syntax is actually:
`${sys:some.property:-defaultValue}` (note the dash). Maybe it would be enough
for me ATM.
However, I am opened to refactor this to be part of `StrSubstitutor`.
> Expand SystemPropertiesLookup syntax
>
>
> Key: LOG4J2-1842
> URL: https://issues.apache.org/jira/browse/LOG4J2-1842
> Project: Log4j 2
> Issue Type: Improvement
> Components: Lookups
>Reporter: Mihhail Lapushkin
>Priority: Minor
>
> I've been using a modified version of {{SystemPropertiesLookup}} in my
> project. Maybe it could be part of the library.
> The idea is to allow a series of property keys to be specified. If one of the
> properties is present, then it is used. If none are present, then the default
> value is used. For example:
> {code}
> level="${sys:myapp.log.level|myapp.log.level.dao|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.service|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.controller|warn}"/>
> {code}
> This allows me to quickly rerun the app with different log levels without
> fiddling with the configuration file or JConsole. Defaults represent
> production settings, so that nothing extra needs to be specified to run the
> app.
> This work nice in other places as well:
> {code}
>
> {code}
> Disables colors by default (for production build), but leaves an easy way to
> turn them on for development.
> When no pipes are present in the expression, then the standard property
> lookup is used, so the change is backwards-compatible.
> Can be a separate lookup if needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1842) Expand SystemPropertiesLookup syntax
[
https://issues.apache.org/jira/browse/LOG4J2-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906591#comment-15906591
]
Mihhail Lapushkin commented on LOG4J2-1842:
---
Hm, that's a nice discovery. The syntax is actually:
`${sys:some.property:-defaultValue}` (note the dash). Maybe it would be enough
for me ATM.
However, I am opened to refactor this to be part of `StrSubstitutor`.
> Expand SystemPropertiesLookup syntax
>
>
> Key: LOG4J2-1842
> URL: https://issues.apache.org/jira/browse/LOG4J2-1842
> Project: Log4j 2
> Issue Type: Improvement
> Components: Lookups
>Reporter: Mihhail Lapushkin
>Priority: Minor
>
> I've been using a modified version of {{SystemPropertiesLookup}} in my
> project. Maybe it could be part of the library.
> The idea is to allow a series of property keys to be specified. If one of the
> properties is present, then it is used. If none are present, then the default
> value is used. For example:
> {code}
> level="${sys:myapp.log.level|myapp.log.level.dao|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.service|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.controller|warn}"/>
> {code}
> This allows me to quickly rerun the app with different log levels without
> fiddling with the configuration file or JConsole. Defaults represent
> production settings, so that nothing extra needs to be specified to run the
> app.
> This work nice in other places as well:
> {code}
>
> {code}
> Disables colors by default (for production build), but leaves an easy way to
> turn them on for development.
> When no pipes are present in the expression, then the standard property
> lookup is used, so the change is backwards-compatible.
> Can be a separate lookup if needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1842) Expand SystemPropertiesLookup syntax
[
https://issues.apache.org/jira/browse/LOG4J2-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihhail Lapushkin updated LOG4J2-1842:
--
Description:
I've been using a modified version of {{SystemPropertiesLookup}} in my project.
Maybe it could be part of the library.
The idea is to allow a series of property keys to be specified. If one of the
properties is present, then it is used. If none are present, then the default
value is used. For example:
{code}
{code}
This allows me to quickly rerun the app with different log levels without
fiddling with the configuration file or JConsole. Defaults represent production
settings, so that nothing extra needs to be specified to run the app.
This work nice in other places as well:
{code}
{code}
Disables colors by default (for production build), but leaves an easy way to
turn them on for development.
When no pipes are present in the expression, then the standard property lookup
is used, so the change is backwards-compatible.
Can be a separate lookup if needed.
was:
https://github.com/apache/logging-log4j2/pull/64
I've been using a modified version of {{SystemPropertiesLookup}} in my project.
Maybe it could be part of the library.
The idea is to allow a series of property keys to be specified. If one of the
properties is present, then it is used. If none are present, then the default
value is used. For example:
{code}
{code}
This allows me to quickly rerun the app with different log levels without
fiddling with the configuration file or JConsole. Defaults represent production
settings, so that nothing extra needs to be specified to run the app.
This work nice in other places as well:
{code}
{code}
Disables colors by default (for production build), but leaves an easy way to
turn them on for development.
When no pipes are present in the expression, then the standard property lookup
is used, so the change is backwards-compatible.
Can be a separate lookup if needed.
> Expand SystemPropertiesLookup syntax
>
>
> Key: LOG4J2-1842
> URL: https://issues.apache.org/jira/browse/LOG4J2-1842
> Project: Log4j 2
> Issue Type: Improvement
> Components: Lookups
>Reporter: Mihhail Lapushkin
>Priority: Minor
>
> I've been using a modified version of {{SystemPropertiesLookup}} in my
> project. Maybe it could be part of the library.
> The idea is to allow a series of property keys to be specified. If one of the
> properties is present, then it is used. If none are present, then the default
> value is used. For example:
> {code}
> level="${sys:myapp.log.level|myapp.log.level.dao|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.service|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.controller|warn}"/>
> {code}
> This allows me to quickly rerun the app with different log levels without
> fiddling with the configuration file or JConsole. Defaults represent
> production settings, so that nothing extra needs to be specified to run the
> app.
> This work nice in other places as well:
> {code}
>
> {code}
> Disables colors by default (for production build), but leaves an easy way to
> turn them on for development.
> When no pipes are present in the expression, then the standard property
> lookup is used, so the change is backwards-compatible.
> Can be a separate lookup if needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1842) Expand SystemPropertiesLookup syntax
[
https://issues.apache.org/jira/browse/LOG4J2-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihhail Lapushkin updated LOG4J2-1842:
--
Description:
https://github.com/apache/logging-log4j2/pull/64
I've been using a modified version of {{SystemPropertiesLookup}} in my project.
Maybe it could be part of the library.
The idea is to allow a series of property keys to be specified. If one of the
properties is present, then it is used. If none are present, then the default
value is used. For example:
{code}
{code}
This allows me to quickly rerun the app with different log levels without
fiddling with the configuration file or JConsole. Defaults represent production
settings, so that nothing extra needs to be specified to run the app.
This work nice in other places as well:
{code}
{code}
Disables colors by default (for production build), but leaves an easy way to
turn them on for development.
When no pipes are present in the expression, then the standard property lookup
is used, so the change is backwards-compatible.
Can be a separate lookup if needed.
was:
https://github.com/apache/logging-log4j2/pull/64
I've been using a modified version of {{SystemPropertiesLookup}} in my project.
Maybe it could be part of the library.
The idea is to allow a series of property keys to be specified. If one of the
properties is present, then it is used. If none are present, then the default
value is used. For example:
{code}
{code}
This allows me to quickly rerun the app with different log levels without
fiddling with the configuration file or JConsole. Defaults represent production
settings, so that nothing extra needs to be specified to run the app.
This work nice in other places as well:
{code}
{code}
Disables colors by default (for production build), but leaves an easy way to
turn them on for development.
When no pipes are present in the expression, then the standard property lookup
is used, so the change is backwards-compatible.
Can be a separate lookup if needed.
Here is the possible implementation:
{code}
@Plugin(name = "sys", category = StrLookup.CATEGORY)
public class SystemPropertiesLookup extends AbstractLookup {
private static final Logger LOGGER = StatusLogger.getLogger();
private static final Marker LOOKUP = MarkerManager.getMarker("LOOKUP");
/**
* @param event The current LogEvent.
* @param expression the expression to be looked up.
* @return The value resolved by expression.
*/
@Override
public String lookup(final LogEvent event, final String expression) {
try {
if (expression.indexOf('|') < 0) {
return System.getProperty(expression);
}
String[] expressionElements = expression.split("\\|");
for (int i = 0; i < expressionElements.length - 1; i++) {
String propertyValue =
System.getProperty(expressionElements[i]);
if (propertyValue != null) {
return propertyValue;
}
}
return expressionElements[expressionElements.length - 1];
} catch (final Exception ex) {
LOGGER.warn(LOOKUP, "Error while resolving system property by
expression [{}].", expression, ex);
return null;
}
}
}
{code}
> Expand SystemPropertiesLookup syntax
>
>
> Key: LOG4J2-1842
> URL: https://issues.apache.org/jira/browse/LOG4J2-1842
> Project: Log4j 2
> Issue Type: Improvement
> Components: Lookups
>Reporter: Mihhail Lapushkin
>Priority: Minor
>
> https://github.com/apache/logging-log4j2/pull/64
> I've been using a modified version of {{SystemPropertiesLookup}} in my
> project. Maybe it could be part of the library.
> The idea is to allow a series of property keys to be specified. If one of the
> properties is present, then it is used. If none are present, then the default
> value is used. For example:
> {code}
> level="${sys:myapp.log.level|myapp.log.level.dao|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.service|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.controller|warn}"/>
> {code}
> This allows me to quickly rerun the app with different log levels without
> fiddling with the configuration file or JConsole. Defaults represent
> production settings, so that nothing extra needs to be specified to run the
> app.
> This work nice in other places as well:
> {code}
>
> {code}
> Disables colors by default (for production build), but leaves an easy way to
> turn them on for development.
> When no pipes are present in the expression, then the standard property
> lookup is used, so the change is backwards-compatible.
> Can be a separate lookup if needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (LOG4J2-1842) Expand SystemPropertiesLookup syntax
[
https://issues.apache.org/jira/browse/LOG4J2-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihhail Lapushkin updated LOG4J2-1842:
--
Description:
https://github.com/apache/logging-log4j2/pull/64
I've been using a modified version of {{SystemPropertiesLookup}} in my project.
Maybe it could be part of the library.
The idea is to allow a series of property keys to be specified. If one of the
properties is present, then it is used. If none are present, then the default
value is used. For example:
{code}
{code}
This allows me to quickly rerun the app with different log levels without
fiddling with the configuration file or JConsole. Defaults represent production
settings, so that nothing extra needs to be specified to run the app.
This work nice in other places as well:
{code}
{code}
Disables colors by default (for production build), but leaves an easy way to
turn them on for development.
When no pipes are present in the expression, then the standard property lookup
is used, so the change is backwards-compatible.
Can be a separate lookup if needed.
Here is the possible implementation:
{code}
@Plugin(name = "sys", category = StrLookup.CATEGORY)
public class SystemPropertiesLookup extends AbstractLookup {
private static final Logger LOGGER = StatusLogger.getLogger();
private static final Marker LOOKUP = MarkerManager.getMarker("LOOKUP");
/**
* @param event The current LogEvent.
* @param expression the expression to be looked up.
* @return The value resolved by expression.
*/
@Override
public String lookup(final LogEvent event, final String expression) {
try {
if (expression.indexOf('|') < 0) {
return System.getProperty(expression);
}
String[] expressionElements = expression.split("\\|");
for (int i = 0; i < expressionElements.length - 1; i++) {
String propertyValue =
System.getProperty(expressionElements[i]);
if (propertyValue != null) {
return propertyValue;
}
}
return expressionElements[expressionElements.length - 1];
} catch (final Exception ex) {
LOGGER.warn(LOOKUP, "Error while resolving system property by
expression [{}].", expression, ex);
return null;
}
}
}
{code}
was:
I've been using a modified version of {{SystemPropertiesLookup}} in my project.
Maybe it could be part of the library.
The idea is to allow a series of property keys to be specified. If one of the
properties is present, then it is used. If none are present, then the default
value is used. For example:
{code}
{code}
This allows me to quickly rerun the app with different log levels without
fiddling with the configuration file or JConsole. Defaults represent production
settings, so that nothing extra needs to be specified to run the app.
This work nice in other places as well:
{code}
{code}
Disables colors by default (for production build), but leaves an easy way to
turn them on for development.
When no pipes are present in the expression, then the standard property lookup
is used, so the change is backwards-compatible.
Can be a separate lookup if needed.
Here is the possible implementation:
{code}
@Plugin(name = "sys", category = StrLookup.CATEGORY)
public class SystemPropertiesLookup extends AbstractLookup {
private static final Logger LOGGER = StatusLogger.getLogger();
private static final Marker LOOKUP = MarkerManager.getMarker("LOOKUP");
/**
* @param event The current LogEvent.
* @param expression the expression to be looked up.
* @return The value resolved by expression.
*/
@Override
public String lookup(final LogEvent event, final String expression) {
try {
if (expression.indexOf('|') < 0) {
return System.getProperty(expression);
}
String[] expressionElements = expression.split("\\|");
for (int i = 0; i < expressionElements.length - 1; i++) {
String propertyValue =
System.getProperty(expressionElements[i]);
if (propertyValue != null) {
return propertyValue;
}
}
return expressionElements[expressionElements.length - 1];
} catch (final Exception ex) {
LOGGER.warn(LOOKUP, "Error while resolving system property by
expression [{}].", expression, ex);
return null;
}
}
}
{code}
> Expand SystemPropertiesLookup syntax
>
>
> Key: LOG4J2-1842
> URL: https://issues.apache.org/jira/browse/LOG4J2-1842
> Project: Log4j 2
> Issue Type: Improvement
> Components: Lookups
>Reporter: Mihhail Lapushkin
>Priority: Minor
[jira] [Created] (LOG4J2-1842) Expand SystemPropertiesLookup syntax
Mihhail Lapushkin created LOG4J2-1842:
-
Summary: Expand SystemPropertiesLookup syntax
Key: LOG4J2-1842
URL: https://issues.apache.org/jira/browse/LOG4J2-1842
Project: Log4j 2
Issue Type: Improvement
Components: Lookups
Reporter: Mihhail Lapushkin
Priority: Minor
I've been using a modified version of {{SystemPropertiesLookup}} in my project.
Maybe it could be part of the library.
The idea is to allow a series of property keys to be specified. If one of the
properties is present, then it is used. If none are present, then the default
value is used. For example:
{code}
{code}
This allows me to quickly rerun the app with different log levels without
fiddling with the configuration file or JConsole. Defaults represent production
settings, so that nothing extra needs to be specified to run the app.
This work nice in other places as well:
{code}
{code}
Disables colors by default (for production build), but leaves an easy way to
turn them on for development.
When no pipes are present in the expression, then the standard property lookup
is used, so the change is backwards-compatible.
Can be a separate lookup if needed.
Here is the possible implementation:
{code}
@Plugin(name = "sys", category = StrLookup.CATEGORY)
public class SystemPropertiesLookup extends AbstractLookup {
private static final Logger LOGGER = StatusLogger.getLogger();
private static final Marker LOOKUP = MarkerManager.getMarker("LOOKUP");
/**
* @param event The current LogEvent.
* @param expression the expression to be looked up.
* @return The value resolved by expression.
*/
@Override
public String lookup(final LogEvent event, final String expression) {
try {
if (expression.indexOf('|') < 0) {
return System.getProperty(expression);
}
String[] expressionElements = expression.split("\\|");
for (int i = 0; i < expressionElements.length - 1; i++) {
String propertyValue =
System.getProperty(expressionElements[i]);
if (propertyValue != null) {
return propertyValue;
}
}
return expressionElements[expressionElements.length - 1];
} catch (final Exception ex) {
LOGGER.warn(LOOKUP, "Error while resolving system property by
expression [{}].", expression, ex);
return null;
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
