logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 44308] - [Patch] JMX component for managing Logger configurations
Date Fri, 08 Feb 2008 09:55:39 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44308>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44308





------- Additional Comments From stefan.fleiter@web.de  2008-02-08 01:55 -------
(In reply to comment #4)

> RollbackableLoggerManager
> 	Ordering of rollback, should this be stack based instead?

The intention of Rollback was only to get Log4j in the state it was initially
configured. Since Log4j itself does not offer such an operation I implemented
this myself.
The order of the modifications of the levels of the logger instances is
not important for this purpose since Log4j determines the effective Level
with every logging action.
Since we do not set the effective level (which is not even possible) the order
of the undo operations does not matter.

> 	Be nice to indicate the size of the rollback state (number of undos)
>       via jmx Operation to rollback just the most recent?

I can add a method to show the size of the rollback information, no problem.
The undo information can be smaller than the modifications made
since only for the first change of a logger its' initial level is saved.
I do not know if there is an advantage of doing partial undo.
The purpose of rollback was to have the possibility to change the log levels
of production machines for a debugging session and to have a single operation
which can undo all changes to get it in the same state as the other nodes.

Partial undo would require a complete changed implementation of the 
RollbackableLoggerManager since I do only save the initial states.
One could do this with a MultiMap but I do not see a usecase for partial undo.
What usecase did you think of?
 	
> LoggerManager
> 	getLevelByName - stylistic, but should that method declare the
>       RuntimeException?

It's only for documentation purposes, if you prefer not to declare 
RuntimeExceptions I have no problems removing those declarations.

> 	since this class is designed for extension, should some thought be made 
>       towards making some of the methods final? (Effective Java)

What methods have you thought of?
When I start to think about this I could rename doSetLogLevel
to setLogLevelInternal and call a doSetLogLevelInternal template method.
Then one could make setLogLevelInternal final.
But even that is difficult because the extending class could wish to veto
the modification.
I am not a big fan of the final keyword because there always is somebody
who wants to do something with your class you have never thought of.

But if you feel strongly for making some method(s) final I will do this.

> 	setRootLogLevel - declaring throwing RuntimeException?

See above, no problem removing the declaration.

> 	getConfiguredLoggers - is there an off-by-1 error there in the for loop 
>       with the ++i instead of i++  ?

I hope I understand you correctly, but Java language specification 3 states
explicitly under 14.14.1.2, that the update part of the for statement (third
part in parentheses) is executed after the body/statement.
Therefor ++i and i++ have the same effect.
I got used to prefer pre-increment to post-increment if there is no difference
in their effects when programming C++.
So this can be changed but I do not see the mentioned off by one bug.


> LoggerManagerModelMBean
> 	+        try {
> 	+            getDelegate().getClass().getMethod("rollbackLogConfiguration",
null);
> 	+            modelMBeanOperations.add(rollbackLogConfiguration);
> 	+        } catch (NoSuchMethodException expected) {
> 	+            // nothing to do
> 	+        }
> 	This seems a bit of a hack! :)   Given RollbackableLoggerManager extends 
>       from LoggerManager, perhaps the same thought could be done to having a
>       second RollbackableLoggerManagerModelMBean that has a 
>       doPostRegisterOtherSchtuff() style methods.

You got me there. :-)
That really is a hack.
RollbackableLoggerManagerModelMBean could easily override
createModelMBeanOperationInfos of LoggerManagerModelMBean which would
not register that method.

Thanks a lot for your kind review.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message