The first piece of code is doing almost exactly the same thing as the second one. But the hierarchal propagation of Log record is different. Can someone please explain why its happening. Thanks
Logger log1 = Logger.getLogger("Test1");
Logger log2 = Logger.getLogger("Test1.Test2");
Logger log3 = Logger.getLogger("Test1.Test2.Test3");
log2.setLevel(Level.WARNING);
log3.setLevel(Level.INFO);
log2.addHandler(new ConsoleHandler());
log3.addHandler(new ConsoleHandler());
log1.log(Level.INFO, "Message By: {0}",log1.getName());
log2.log(Level.INFO, "Message By: {0}",log2.getName());
log3.log(Level.INFO, "Message By: {0}",log3.getName());
OUTPUT: Nov 27, 2014 8:32:51 PM Test main
INFO: Message By: Test1
Nov 27, 2014 8:32:51 PM Test main
INFO: Message By: Test1.Test2.Test3
Nov 27, 2014 8:32:51 PM Test main
INFO: Message By: Test1.Test2.Test3
Nov 27, 2014 8:32:51 PM Test main
INFO: Message By: Test1.Test2.Test3
Logger logger = Logger.getLogger("d");
Logger logger1 = Logger.getLogger("d.1");
Logger logger1_2 = Logger.getLogger("d.1.2");
logger1 .setLevel(Level.WARNING);
logger1_2.setLevel(Level.INFO);
logger .info("msg:");
logger1 .info("msg: 1");
logger1_2 .info("msg: 1.2");
OUTPUT:
Nov 27, 2014 8:33:34 PM Test main
INFO: msg:
Nov 27, 2014 8:33:34 PM Test main
INFO: msg: 1.2
The lowest logger INFO message should not have propagated to the top as the middle one is set to Warning
That assumption is the source of your confusion. Record propergation is decsribed in the java.util.logging.Logger class documentation. Per the documentation:
By default, loggers also publish to their parent's Handlers, recursively up the tree.
The child logger is directly logging to the parent handler not the parent logger. So the level of the parent handler is what comes in to play not the level of the parent logger in this case.
Related
We have Java application with client Server architecture where client and server communicate with the help of RMI connection.
We have currently used Java 8 it working properly and respond quickly.
But we now planning to move on the Java 11 here also application working properly but comparatively slow as compare to java 8
we took the RMI logs where I can see sun.rmi.transport.DGCImpl_Stub dirty class taking time in Java 11.
Java 11 RMI logs
loadClass FINE: main: name = "java.rmi.server.UID", codebase = "",
defaultLoader =
jdk.internal.loader.ClassLoaders$AppClassLoader#4b85612c Nov 21, 2018
7:25:12 PM java.rmi.server.RMIClassLoader$2 loadClass FINER: main:
class "java.rmi.server.UID" found via defaultLoader, defined by null
Nov 21, 2018 7:25:12 PM sun.rmi.transport.DGCImpl_Stub dirty FINE:
main: free connection (reuse = true) Nov 21, 2018 7:27:31 PM
java.rmi.server.RemoteObjectInvocationHandler$MethodToHash_Maps$1 get
Java 8 RMI logs
FINE: main: name = "[B", codebase = "", defaultLoader =
sun.misc.Launcher$AppClassLoader#d716361 Nov 21, 2018 7:39:29 PM
sun.rmi.server.LoaderHandler loadClass FINER: main: class "[B" found
via defaultLoader, defined by null Nov 21, 2018 7:39:29 PM
sun.rmi.server.LoaderHandler loadClass FINE: main: name =
"java.rmi.server.UID", codebase = "", defaultLoader =
sun.misc.Launcher$AppClassLoader#d716361 Nov 21, 2018 7:39:29 PM
sun.rmi.server.LoaderHandler loadClass FINER: main: class
"java.rmi.server.UID" found via defaultLoader, defined by null Nov 21,
2018 7:39:29 PM sun.rmi.server.UnicastRef done FINE: main: free
connection (reuse = true) Nov 21, 2018 7:39:30 PM sun.rmi.server.Util
computeMethodHash
I am developing a java application that executes ssh commands using Ganymed SSH-2
I need to produce full logs for each sequence of commands, e.g. zip file transfer, unzipping, zipping etc..
Having searched the source code for ch.ethz.ssh2.log.Logger i can set the boolean public static volatile boolean enabled = false; to true
this provides the following output
Mar 05, 2015 10:17:25 AM ch.ethz.ssh2.log.Logger info
INFO: kex_algo=diffie-hellman-group-exchange-sha1
Mar 05, 2015 10:17:25 AM ch.ethz.ssh2.log.Logger info
INFO: server_host_key_algo=ssh-rsa
Mar 05, 2015 10:17:25 AM ch.ethz.ssh2.log.Logger info
INFO: enc_algo_client_to_server=aes128-ctr
Mar 05, 2015 10:17:25 AM ch.ethz.ssh2.log.Logger info
INFO: enc_algo_server_to_client=aes128-ctr
Mar 05, 2015 10:17:25 AM ch.ethz.ssh2.log.Logger info
INFO: mac_algo_client_to_server=hmac-sha1-96
Mar 05, 2015 10:17:25 AM ch.ethz.ssh2.log.Logger info
INFO: mac_algo_server_to_client=hmac-sha1-96
Mar 05, 2015 10:17:25 AM ch.ethz.ssh2.log.Logger info
INFO: comp_algo_client_to_server=none
Mar 05, 2015 10:17:25 AM ch.ethz.ssh2.log.Logger info
INFO: comp_algo_server_to_client=none
However I also require ALL level logging for command execution including file transfers.
How do i configure the Logger to produce all the information available?
A little late answer but maybe someone still needs this info.
I managed to get the debug statements visible like this:
public void enableFineLogging() {
try {
ch.ethz.ssh2.log.Logger.enabled = true;
String name = "myDynamicFileNamePart";
FileHandler fileHandler = new FileHandler("./logs/"
+ name + "_SFTP.log", 10000000, 1000, true);
fileHandler.setLevel(Level.FINE);
fileHandler.setFormatter(new SimpleFormatter());
final Logger app = Logger.getLogger("ch.ethz");
app.setLevel(Level.FINE);
app.addHandler(fileHandler);
app.setUseParentHandlers(false);
} catch (Exception e) {
// Catchalog
}
}
With result in file with:
marras 15, 2017 12:16:56 IP. org.slf4j.impl.JCLLoggerAdapter info
INFO: Client identity string: SSH-2.0-SSHJ_0.19.1
marras 15, 2017 12:16:56 IP. org.slf4j.impl.JCLLoggerAdapter info
INFO: Server identity string: SSH-2.0-OpenSSH_6.6.1
marras 15, 2017 12:16:56 IP. org.slf4j.impl.JCLLoggerAdapter debug
FINE: Setting <> to null
marras 15, 2017 12:16:56 IP. org.slf4j.impl.JCLLoggerAdapter debug
FINE: Sending SSH_MSG_KEXINIT
marras 15, 2017 12:16:56 IP. org.slf4j.impl.JCLLoggerAdapter debug
FINE: Setting <> to SOME
marras 15, 2017 12:16:56 IP. org.slf4j.impl.JCLLoggerAdapter debug
FINE: Awaiting <>
marras 15, 2017 12:16:56 IP. org.slf4j.impl.JCLLoggerAdapter debug
FINE: Received SSH_MSG_KEXINIT
Use ConsoleHandler if you wish logs in console.
Also closing the log file needs to be considered with fileHandler.close() after you quit logging.
Tune the log level by choosing from SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST, ALL
I am getting this error:
Feb 11, 2014 10:32:34 AM org.apache.catalina.core.ApplicationContext log
Information: ContextListener: contextInitialized()
Feb 11, 2014 10:32:34 AM org.apache.catalina.core.ApplicationContext log
Information: SessionListener: contextInitialized()
Feb 11, 2014 10:32:34 AM org.apache.catalina.core.ApplicationContext log
Information: ContextListener: attributeAdded('org.apache.jasper.compiler.TldLocationsCache', 'org.apache.jasper.compiler.TldLocationsCache#6b2c636d')
Feb 11, 2014 10:43:04 AM org.apache.catalina.core.ApplicationContext log
Information: No Spring WebApplicationInitializer types detected on classpath
Feb 11, 2014 10:43:05 AM org.apache.catalina.core.ApplicationContext log
Information: Initializing Spring root WebApplicationContext
Feb 11, 2014 10:43:06 AM org.apache.catalina.core.StandardContext listenerStart
Schwerwiegend: Exception sending context initialized event to listener instance of class org.codehaus.groovy.grails.web.context.GrailsContextLoaderListener
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'grailsApplication' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Invocation of init method failed; nested exception is java.lang.VerifyError: (class: elektrova/UserController, method: $tt__index signature: (Ljava/lang/Integer;Lorg/springframework/transaction/TransactionStatus;)Ljava/lang/Object;) Stack size too large
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
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)
Caused by: java.lang.VerifyError: (class: elektrova/UserController, method: $tt__index signature: (Ljava/lang/Integer;Lorg/springframework/transaction/TransactionStatus;)Ljava/lang/Object;) Stack size too large
at java.lang.Class.forName(Class.java:270)
... 5 more
In this method:
def index(Integer max) {
params.max = Math.min(max ?: 10, 100)
if(!session.isAdmin){
Hauler haul = Hauler.get(session.haulerID)
println haul
if(params.firstName)
respond User.findAllWhere([hauler:haul,firstName:params.firstName]), model:[userInstanceCount: User.count()]
else if(params.lastName)
respond User.findAllWhere([hauler:haul,lastName:params.lastName]), model:[userInstanceCount: User.count()]
else if(params.role)
respond User.findAllWhere([hauler:haul,role:params.role]), model:[userInstanceCount: User.count()]
else
respond User.findAllByHauler(haul), model:[userInstanceCount: User.count()]
}else{
if(params.firstName){
model:[userInstanceList: User.findAllByFirstName(params.firstName),userInstanceCount: User.count()]
}else if(params.lastName)
model:[userInstanceList: User.findAllByLastName(params.lastName),userInstanceCount: User.count()]
else if(params.role)
model:[userInstanceList: User.findAllByRole(params.role),userInstanceCount: User.count()]
else
model:[userInstanceList: User.list(params),userInstanceCount: User.count()]
}
}
I found this thread, that solves the problem imho:
VerifyError: Stack size too large (what does it mean?)
but I don't quite get how to calculate and declare the stack size. And I don't understand either, why I have to declare it, since other methods don't need it.
Thanks for any help!
The problem disappeared without me changing anything, I have no idea why
I have two virtual machines in a private
cloud, and I want to execute Jade both of them. They can access each
other without problems. I started in one of them the Main Container, and
in the other a Container which would connect to the main. However, I get
a Dispatcher exception when this connection tries to take place:
--------
INFO: Adding node <Container-1> to the platform
Jun 22, 2011 12:54:34 PM jade.core.messaging.MessagingService
clearCachedSlice
INFO: Clearing cache
Jun 22, 2011 12:54:34 PM jade.core.messaging.MessagingService
$CommandTargetSink handleNewSlice
WARNING: Error notifying current information to new Messaging-Slice
Container-1
jade.core.IMTPException: Dispatcher error [nested
jade.imtp.leap.DispatcherException: DispatcherException in remote site.
No skeleton for object-id 3447152]
at jade.imtp.leap.NodeStub.accept(NodeStub.java:91)
at jade.core.messaging.MessagingProxy.addRoute(MessagingProxy.java:257)
at jade.core.messaging.MessagingService
$CommandTargetSink.handleNewSlice(MessagingService.java:993)
at jade.core.messaging.MessagingService
$CommandTargetSink.consume(MessagingService.java:906)
at jade.core.CommandProcessor
$SinksFilter.accept(CommandProcessor.java:253)
at jade.core.Filter.filter(Filter.java:89)
at jade.core.Filter.filter(Filter.java:90)
at jade.core.Filter.filter(Filter.java:90)
at
jade.core.CommandProcessor.processIncoming(CommandProcessor.java:229)
at
jade.core.PlatformManagerImpl.issueNewSliceCommand(PlatformManagerImpl.java:744)
at
jade.core.PlatformManagerImpl.localAddSlice(PlatformManagerImpl.java:445)
at
jade.core.PlatformManagerImpl.localAddNode(PlatformManagerImpl.java:293)
at jade.core.PlatformManagerImpl.addNode(PlatformManagerImpl.java:245)
at
jade.imtp.leap.PlatformManagerSkel.executeCommand(PlatformManagerSkel.java:73)
at jade.imtp.leap.Skeleton.processCommand(Skeleton.java:51)
at
jade.imtp.leap.CommandDispatcher.handleCommand(CommandDispatcher.java:949)
at jade.imtp.leap.JICP.JICPServer
$ConnectionHandler.run(JICPServer.java:439)
Nested Exception:
jade.imtp.leap.DispatcherException: DispatcherException in remote site.
No skeleton for object-id 3447152
at
jade.imtp.leap.CommandDispatcher.checkRemoteExceptions(CommandDispatcher.java:516)
at
jade.imtp.leap.CommandDispatcher.dispatchSerializedCommand(CommandDispatcher.java:418)
at
jade.imtp.leap.CommandDispatcher.dispatchCommand(CommandDispatcher.java:343)
at jade.imtp.leap.NodeStub.accept(NodeStub.java:83)
at jade.core.messaging.MessagingProxy.addRoute(MessagingProxy.java:257)
at jade.core.messaging.MessagingService
$CommandTargetSink.handleNewSlice(MessagingService.java:993)
at jade.core.messaging.MessagingService
$CommandTargetSink.consume(MessagingService.java:906)
at jade.core.CommandProcessor
$SinksFilter.accept(CommandProcessor.java:253)
at jade.core.Filter.filter(Filter.java:89)
at jade.core.Filter.filter(Filter.java:90)
at jade.core.Filter.filter(Filter.java:90)
at
jade.core.CommandProcessor.processIncoming(CommandProcessor.java:229)
at
jade.core.PlatformManagerImpl.issueNewSliceCommand(PlatformManagerImpl.java:744)
at
jade.core.PlatformManagerImpl.localAddSlice(PlatformManagerImpl.java:445)
at
jade.core.PlatformManagerImpl.localAddNode(PlatformManagerImpl.java:293)
at jade.core.PlatformManagerImpl.addNode(PlatformManagerImpl.java:245)
at
jade.imtp.leap.PlatformManagerSkel.executeCommand(PlatformManagerSkel.java:73)
at jade.imtp.leap.Skeleton.processCommand(Skeleton.java:51)
at
jade.imtp.leap.CommandDispatcher.handleCommand(CommandDispatcher.java:949)
at jade.imtp.leap.JICP.JICPServer
$ConnectionHandler.run(JICPServer.java:439)
Jun 22, 2011 12:54:34 PM jade.core.PlatformManagerImpl$1 nodeAdded
INFO: --- Node <Container-1> ALIVE ---
Jun 22, 2011 12:54:34 PM
jade.core.nodeMonitoring.BlockingNodeFailureMonitor run
INFO: PING from node Container-1 exited with exception. Dispatcher error
[nested jade.imtp.leap.DispatcherException: DispatcherException in
remote site. No skeleton for object-id 3447152]
Jun 22, 2011 12:54:34 PM jade.core.PlatformManagerImpl$1 nodeUnreachable
WARNING: --- Node <Container-1> UNREACHABLE ---
Jun 22, 2011 12:54:34 PM jade.core.PlatformManagerImpl
removeTerminatedNode
INFO: --- Node <Container-1> TERMINATED ---
Jun 22, 2011 12:54:34 PM jade.core.messaging.MessagingService
clearCachedSlice
---------
In the other node I get the following:
--------
Jun 22, 2011 12:55:35 PM jade.core.AgentContainerImpl joinPlatform
SEVERE: Some problem occurred while joining agent platform.
jade.core.ServiceException: An error occurred during service booting
[nested java.lang.NullPointerException]
at
jade.core.AgentContainerImpl.bootAllServices(AgentContainerImpl.java:465)
at jade.core.AgentContainerImpl.startNode(AgentContainerImpl.java:408)
at
jade.core.AgentContainerImpl.joinPlatform(AgentContainerImpl.java:485)
at jade.core.Runtime.createAgentContainer(Runtime.java:133)
at BookBuyTest2.main(BookBuyTest2.java:25)
Exception in thread "main" java.lang.NullPointerException
at BookBuyTest2.main(BookBuyTest2.java:35)
------
Any ideas about what I am doing wrong?
Thank you very much in advance,
The problem was that in the node I put:
local-host:127.0.0.1
This was solved by putting
local-host: <actual IP of the machine\>
To me, this worked
String[] container = {
"-gui",
"-local-host 127.0.0.1",
"-container",
"Agent1:jogo.agents.Agent1;Agent2:jogo.agents.Agent2" // <- Your custom agents
};
Boot.main(container);
I'm developing a Java application that uses java.util.logging for its logging needs. This application uses a multitude of external libraries (JDBC, JMS clients, JSR-160 implementation, etc), some of which also use java.util.logging.
I want to set the log level for my Loggers to ALL when I specify a flag on the command line, but so far I have only found ways to set the level for all loggers, not just mine.
My loggers are all called "com.mycompany.myapp.SomeClass" and when I set the level for "com.mycompany.myapp" to ALL, no extra information is logged. When I set the level for the root logger to ALL, all information for all loggers is logged to the console, which is way too much information!
How can I set my own loggers to ALL without having all those other loggers flood my logfiles?
Actually, I'm not sure why your having the problems you've described. I've created a simple JUnit test (below) and setting the log levels works exactly as I expect (which also seems inline with the way you expected them to work).
Are you trying to log messages with levels set below INFO in your custom logger? As you can see from the tests I've included, the default logging handler is set to INFO by default. You need to change that Handler's level to see FINE messages (also shown).
import java.util.logging.Handler;
import java.util.logging.Level;
import java.util.logging.Logger;
import org.junit.Test;
public class SimpleLoggerTest {
private void logMessages(Logger logger) {
logger.warning(getLoggerName(logger) + ": warning message");
logger.info(getLoggerName(logger) + ": info message");
logger.fine(getLoggerName(logger) + ": fine message");
}
private String getLoggerName(Logger logger) {
String loggerName = logger.getName();
if (loggerName.isEmpty()) {
return "[root logger]";
}
return loggerName;
}
private void listHandlerLevels(Logger logger) {
for (Handler handler : logger.getHandlers()) {
logger.info(getLoggerName(logger) + ": handler level = " + handler.getLevel());
}
Logger parentLogger = logger.getParent();
if (null != parentLogger) {
for (Handler handler : parentLogger.getHandlers()) {
logger.info("parent logger handler (" + getLoggerName(parentLogger) + "): handler level = " + handler.getLevel());
}
}
}
private void setHandlerLevels(Logger logger, Level level) {
for (Handler handler : logger.getHandlers()) {
handler.setLevel(level);
}
Logger parentLogger = logger.getParent();
if (null != parentLogger) {
for (Handler handler : parentLogger.getHandlers()) {
handler.setLevel(level);
}
}
}
#Test
public void testLoggingLevel() {
Logger myLogger = Logger.getLogger(SimpleLoggerTest.class.getName());
Logger rootLogger = myLogger.getParent();
// list the default handler levels
listHandlerLevels(myLogger);
listHandlerLevels(rootLogger);
// log some messages
logMessages(myLogger);
logMessages(rootLogger);
// change the logger levels
myLogger.setLevel(Level.ALL);
rootLogger.setLevel(Level.WARNING);
// list the handler levels again
listHandlerLevels(myLogger);
listHandlerLevels(rootLogger);
// log some messages (again)
logMessages(myLogger);
logMessages(rootLogger);
// change Handler levels to FINE
setHandlerLevels(myLogger, Level.FINE);
// list the handler levels (last time)
listHandlerLevels(myLogger);
listHandlerLevels(rootLogger);
// log some messages (last time)
logMessages(myLogger);
logMessages(rootLogger);
}
}
Produces this output...
May 13, 2009 10:46:53 AM SimpleLoggerTest listHandlerLevels
INFO: parent logger handler ([root logger]): handler level = INFO
May 13, 2009 10:46:53 AM java.util.logging.LogManager$RootLogger log
INFO: [root logger]: handler level = INFO
May 13, 2009 10:46:53 AM SimpleLoggerTest logMessages
WARNING: SimpleLoggerTest: warning message
May 13, 2009 10:46:53 AM SimpleLoggerTest logMessages
INFO: SimpleLoggerTest: info message
May 13, 2009 10:46:53 AM java.util.logging.LogManager$RootLogger log
WARNING: [root logger]: warning message
May 13, 2009 10:46:53 AM java.util.logging.LogManager$RootLogger log
INFO: [root logger]: info message
May 13, 2009 10:46:53 AM SimpleLoggerTest listHandlerLevels
INFO: parent logger handler ([root logger]): handler level = INFO
May 13, 2009 10:46:53 AM SimpleLoggerTest logMessages
WARNING: SimpleLoggerTest: warning message
May 13, 2009 10:46:53 AM SimpleLoggerTest logMessages
INFO: SimpleLoggerTest: info message
May 13, 2009 10:46:53 AM java.util.logging.LogManager$RootLogger log
WARNING: [root logger]: warning message
May 13, 2009 10:46:53 AM SimpleLoggerTest listHandlerLevels
INFO: parent logger handler ([root logger]): handler level = FINE
May 13, 2009 10:46:53 AM SimpleLoggerTest logMessages
WARNING: SimpleLoggerTest: warning message
May 13, 2009 10:46:53 AM SimpleLoggerTest logMessages
INFO: SimpleLoggerTest: info message
May 13, 2009 10:46:53 AM SimpleLoggerTest logMessages
FINE: SimpleLoggerTest: fine message
May 13, 2009 10:46:53 AM java.util.logging.LogManager$RootLogger log
WARNING: [root logger]: warning message
This is what I was trying to convey in my other response.
Yeah, the JDK’s own logging framework can be a real bitch sometimes. As you correctly noticed the log levels of the root logger’s handlers are the problem. The solution you are proposing in your question is almost a good one:
Logger logger = Logger.getLogger("com.mycompany.myapp");
Handler handler = new ConsoleHandler(); /* or whatever you like. */
handler.setLevel(Level.ALL);
logger.addHandler(handler);
logger.setLevel(Level.ALL);
logger.setUseParentHandlers(false); /* <- important. */
When you create logger “below” that logger, i.e. with names like “com.mycompany.myapp.foo.Foo", they will log only to the logger you created. The parent logger of that logger (the root logger) will not get any log messages from your application but will receive messages from other parts of the JDK such as Swing or AWT.
Each Logger has a Handler with it's own log Level.
Is it possible that the Handler for your logger is not also set to ALL and is ignoring the messages? (This is messy, I know).
Here's a 2002 article on Java logging from O'Reilly.
Setting the property
com.mycompany.myapp.level = ALL
should do what you want.
But all the loggers will need to be named correcly with the relevant class names! E.g.
package com.mycompany.myapp;
public class MyClass{
private static Logger theLogger =
Logger.getLogger(MyClass.class.getName());
...
}
Another possible explanation is that your configurations aren't being passed correctly to the logging framework. Try feeding
LogManager.getLogManager().readConfiguration(InputStream);
your logging configuration right at startup. That is what I do and this works for me.