I have a JIRA account now.
At least, I hope I will have one for long, I am thinking of cancelling
my main account (email) for a short while to start over with a clean
slate. Including its domain ;-). Might get a lot of bounces for a LOT
of email services ;-).
But in any case... I was writing an email I guess. Let me just put it
down below:
=====================
I was writing this message but it didn't send: (My webmail logs me out
incessantly).
However, I found part of the answer.
I was wondering why the DefaultConfiguration doesn't have a factory,
but now I know.
The main methods of the ConfigurationFactory reference a default
Factory subclass within itself that loads every other factory it can
find based on filetype extension. When none is found, an error message
is departed and the DefaultConfiguration is returned.
I had been wondering how to get rid of that error message lol. I had
wanted to just take a DefaultConfiguration and just change it
(configure it) but maybe I should subclass ConfigurationFactory, throw
away every type of source argument it passes me, and then just return
the (Default)Configuration that I want :P.
Not sure how "plugins" work yet but I believe you can enable it easily
via e.g. the LogManager. I think I will write a PDF about this :P. But
I have no diagram-making skills yet. No mouse :(. Maybe have a mouse
in a week.
I had written this question:
private static ConfigurationFactory configFactory = new Factory();
^^ how come this works? There is no Factory class from what I can see.
---
But I saw it was down below.
I also wrote and write and will write this: ?.
===---===-
About Double Checked Locking. I don't really understand. If someone is
willing to answer.
Thread 1 begins and allocates an object.
It saves the reference and that code is synchronized on the class/lock.
Thread 2 comes in and apparentlty correctly identifies that the
instance variable (reference) has been written to and proceeds to
(outside of any synchronized block) return the instance reference at
which point mayhem ensues.
Now we are volatile. Thread 1 begins and allocates an object.
It saves the reference and that code is synchronized on the class/lock.
Thead 2 comes in ....
Oh, I get it. In the first case the write-address-to-instance-variable
can be a non-atomic operation. If the address is written before the
constructor/initialization code is completed then the other thread
might get in between and do bad stuff. With volatile the entire
(method)/constructor call and its subsequent assignment (or prior
assignment, but completion of the statement) are atomic (??).
Or rather, perhaps it is ensured that the final assignment is the very
/last/ operation?
After all, you might expect that the construction of an object works
as follows.
1. allocate memory
2. write to reference variable
3. call constructor on reference variable.
In between 2 and 3 a different thread can merge and incorrectly assume
that the object is fully accessible. If 2 and 3 are swapped so that
the final reference is only written after the constructor/method is
done no problem can I occur. I don't get it really.
Reference: http://www.javamex.com/tutorials/double_checked_locking.shtml
===--=-==-==
Anyway that was my email. A bit ... interspersed now I guess.
Bye.
Quoting Ralph Goers <[email protected]>:
Note: in case you didn't know, everyone who submits patches that are
applied gets "credit" for it. See the change log for any release.
Without a Jira ticket we can't do that.
Ralph
On Aug 9, 2015, at 2:28 AM, Gary Gregory <[email protected]> wrote:
Patch applied. TY. In the future, please create a JIRA for patches.
Keep them coming :-)
Cheers,
Gary
On Sun, Aug 9, 2015 at 1:11 AM, Xen <[email protected]> wrote:
I've seen the commit. I will check it out.
Offtopic: fixed a typo in the javadoc:
diff --git
a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/ConfigurationFactory.java
b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/ConfigurationFactory.java
index 3c8c44a..14ea97b 100644
---
a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/ConfigurationFactory.java
+++
b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/ConfigurationFactory.java
@@ -66,7 +66,7 @@ import org.apache.logging.log4j.util.Strings;
* </ol>
*
* If the ConfigurationFactory that was added returns null on a call to
- * getConfiguration the any other ConfigurationFactories found as plugins
will
+ * getConfiguration then any other ConfigurationFactories found as
plugins will
* be called in their respective order. DefaultConfiguration is always
called
* last if no configuration has been returned.
*/
"I will check it out." Now isn't that ambiguous :P.
Regards..
Quoting Gary Gregory <[email protected]>:
Pushed to Git master.
Xen: Please see the setLevel methods in Configurator.
Gary
On Sat, Aug 8, 2015 at 4:24 PM, Gary Gregory <[email protected]>
wrote:
Please see the patch in https://issues.apache.org/jira/browse/LOG4J2-1090
Gary
On Sat, Aug 8, 2015 at 4:05 PM, Ralph Goers <[email protected]>
wrote:
Yes.
Ralph
On Aug 8, 2015, at 4:03 PM, Gary Gregory <[email protected]>
wrote:
That's my bad, I misread Configurator for Configuration.
That said, the
method
org.apache.logging.log4j.core.config.AbstractConfiguration.getRootLogger()
is not in the Configuration interface. Is it OK to add it?
Gary
On Sat, Aug 8, 2015 at 3:42 PM, Ralph Goers <
[email protected]
wrote:
I just noticed you added this to AbstractConfiguration. Wouldn’t it
be
easier for users to do it as a method on Configurator?
Ralph
On Aug 8, 2015, at 12:55 PM, Gary Gregory <[email protected]>
wrote:
setLevel, setRootLevel; code review please, note the added check "
if
(!loggerConfig.getLevel().equals(level)) ..."
diff --git
a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AbstractConfiguration.java
b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AbstractConfiguration.java
index ada5900..7ee09ca 100644
---
a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AbstractConfiguration.java
+++
b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AbstractConfiguration.java
@@ -39,6 +39,7 @@
import org.apache.logging.log4j.core.Filter;
import org.apache.logging.log4j.core.Layout;
import org.apache.logging.log4j.core.LogEvent;
+import org.apache.logging.log4j.core.LoggerContext;
import org.apache.logging.log4j.core.appender.AsyncAppender;
import org.apache.logging.log4j.core.appender.ConsoleAppender;
import org.apache.logging.log4j.core.async.AsyncLoggerConfig;
@@ -829,4 +830,23 @@
return buffer.toByteArray();
}
+ @Override
+ public void setLevel(final String loggerName, final Level
level)
{
+ setLevel(getLoggerConfig(loggerName), level);
+ }
+
+ @Override
+ public void setRootLevel(final Level level) {
+ setLevel(getRootLogger(), level);
+ }
+
+ private void setLevel(final LoggerConfig loggerConfig, final
Level
level) {
+ if (!loggerConfig.getLevel().equals(level)) {
+ loggerConfig.setLevel(level);
+ final LoggerContext loggerContext = (LoggerContext)
LogManager.getContext(false);
+ loggerContext.updateLoggers();
+ }
+ }
+
+
}
diff --git
a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/Configuration.java
b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/Configuration.java
index c592b05..29fb7b2 100644
---
a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/Configuration.java
+++
b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/Configuration.java
@@ -137,4 +137,18 @@
* @return the custom levels defined in the current configuration
*/
List<CustomLevelConfig> getCustomLevels();
+
+ /**
+ * Sets the level of the given logger name.
+ *
+ * @param loggerName the logger name
+ * @param level the new level
+ */
+ void setLevel(String loggerName, Level level);
+
+ /**
+ * Sets the level of the root logger.
+ * @param level the new level
+ */
+ void setRootLevel(Level level);
}
Gary
On Sat, Aug 8, 2015 at 11:14 AM, Ralph Goers <
[email protected]
wrote:
Yup.
And while your at it you might want to add setRootLevel(Level
level);
Ralph
On Aug 8, 2015, at 10:19 AM, Gary Gregory <[email protected]
wrote:
Like this:
diff --git
a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AbstractConfiguration.java
b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AbstractConfiguration.java
index ada5900..bf01c3e 100644
---
a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AbstractConfiguration.java
+++
b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AbstractConfiguration.java
@@ -39,6 +39,7 @@
import org.apache.logging.log4j.core.Filter;
import org.apache.logging.log4j.core.Layout;
import org.apache.logging.log4j.core.LogEvent;
+import org.apache.logging.log4j.core.LoggerContext;
import org.apache.logging.log4j.core.appender.AsyncAppender;
import org.apache.logging.log4j.core.appender.ConsoleAppender;
import org.apache.logging.log4j.core.async.AsyncLoggerConfig;
@@ -788,6 +789,13 @@
return list;
}
+ public void setLevel(String loggerName, Level level) {
+ LoggerConfig loggerConfig = getLoggerConfig(loggerName);
+ loggerConfig.setLevel(level);
+ final LoggerContext loggerContext = (LoggerContext)
LogManager.getContext(false);
+ loggerContext.updateLoggers();
+ }
+
private void setParents() {
for (final Map.Entry<String, LoggerConfig> entry :
loggers.entrySet()) {
final LoggerConfig logger = entry.getValue();
?
On Fri, Aug 7, 2015 at 5:43 AM, Ralph Goers <
[email protected]>
wrote:
I'd recommend the Configurator class.
Ralph
On Aug 6, 2015, at 9:46 PM, Gary Gregory <
[email protected]>
wrote:
For the simple case where you want to update one level, I think
we
should
have a one method call for folks. Where would be the best place
to
hang
that?
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail:
[email protected]
For additional commands, e-mail:
[email protected]
--
E-Mail: [email protected] | [email protected]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail:
[email protected]
--
E-Mail: [email protected] | [email protected]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
E-Mail: [email protected] | [email protected]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
E-Mail: [email protected] | [email protected]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
--
E-Mail: [email protected] | [email protected]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
E-Mail: [email protected] | [email protected]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
