Home › Forums › NexJ Studio › Tools › Take control of your console window in Studio
- This topic has 2 replies, 2 voices, and was last updated 4 years ago by shahzad.qureshi.
-
AuthorPosts
-
-
July 12, 2017 at 1:25 pm #8605Rob DudaParticipant
I found that Ed has already provide an article about this, here is the link.
I’m sure we all have run into the need to set the logging level of the Scheme Console to DEBUG, or worse, DUMP. It becomes a necessary evil when you need to find out just what is going on sometimes. Did you know, however, that you can target the loggers by adding VM arguments to the Scheme Console Settings?
In fact, by setting your own CONSOLE appender settings, you can make this process even easier.
By default the console will only give you the short name of the logger. This poses problems as you need to know the fully qualified name if you want to set the logging level for just that logger. If you use the following VM arguments, you can force the console appender to give the fully qualified name:
-Dlog4j.rootLogger=”INFO, CONSOLE”
-Dlog4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
-Dlog4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
-Dlog4j.appender.CONSOLE.layout.conversionPattern=”%d{yyyy-MM-dd HH:mm:ss} [%c] [%p] [%x] %m%n”I’m not going to give a log4j lesson here but the magic is in the layout.conversionPatten above.
What this does is convert the default output:
; 12:14:39,641 INFO [SysUtil] (Thread-0) Using configuration file “file:/D:/gitrepo/apex/apex/AD/env/LOCAL_MOCK_SERVER_OPAL.server”
; 12:14:39,641 INFO [GenericContainerContainer] (Thread-0) Starting container…
; 12:14:39,673 INFO [GenericContainerContainer] (Thread-0) No deployment directory; using internal RA modules only
; 12:14:39,719 INFO [MetadataLoaderDispatcher] (Thread-0) Using metadata loader “nexj.core.meta.xml.DefaultXMLMetadataLoader”
; 12:14:39,735 INFO [XMLMetadataLoader] (Thread-0) Metadata URL: “file:/D:/gitrepo/apex/apex/AD/meta/”Into:
2017-07-12 12:16:34 [nexj.core.util.SysUtil] [INFO] [] Using configuration file “file:/D:/gitrepo/apex/apex/AD/env/LOCAL_MOCK_SERVER_OPAL.server”
2017-07-12 12:16:34 [nexj.core.container.platform.teee.GenericContainerContainer] [INFO] [] Starting container…
2017-07-12 12:16:34 [nexj.core.container.platform.teee.GenericContainerContainer] [INFO] [] No deployment directory; using internal RA modules only
2017-07-12 12:16:34 [nexj.core.meta.MetadataLoaderDispatcher] [INFO] [] Using metadata loader “nexj.core.meta.xml.DefaultXMLMetadataLoader”Notice how SysUtil is now nexj.core.util.SysUtil, this is important because you can now bump up just the SysUtil logging if you wanted to by adding one more VM argument:
-Dlog4j.logger.nexj.core.util.SysUtil=INFO
Once you know the fully qualified name simply add another VM argument following this pattern:
-Dlog4j.logger.[fully qualified logger name]=[logging level]
Using this technique will enable you to quickly shrink the output to the console and show just what you want to see.
0 -
December 8, 2020 at 3:25 pm #14430shahzad.qureshiKeymaster
Thank you for the thread Rob, very helpful!
The above article by Ed doesn’t mention the ability to set debugging from the console without having to stop and restart the server. You can simply use the (debug args) function from debugScripts.scm (found in libraries/debug directory).
Examples: (debug ‘rpc) or (debug ‘rpc #f ‘sql #t) or (debug ‘Act ‘User)
The documentation for the function provides more examples. I will ask Ed if he can include this information in the article as well
0
-
-
AuthorPosts
- You must be logged in to reply to this topic.