logback.groovy configuration throws errors
Hi, I am trying to use logback.groovy instead of logback.xml in my groovy project but I might be missing something: $ cat HelloWorld.groovy @Grab('org.slf4j:slf4j-api:1.6.1') @Grab('ch.qos.logback:logback-core:1.0.0') @Grab('ch.qos.logback:logback-classic:1.0.0') @Grab('ch.qos.logback:logback-examples:1.0.0') import org.slf4j.Logger import org.slf4j.LoggerFactory public class HelloWorld1 { public static void main(String[] args) { Logger logger = LoggerFactory.getLogger( "HelloWorld1" ) logger.warn("Hello world.") } } If I put the first example from http://logback.qos.ch/manual/configuration.html of sample0.xml as logback.xml, it seems to work perfect. If I put the logback.groovy equivalent instead, I get various errors, like : $ groovy HelloWorld.groovy Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'ch.qos.logback.core.ConsoleAppender[null]' with class 'ch.qos.logback.core.ConsoleAppender' to class 'ch.qos.logback.core.Appender' at org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:331) If I only go with the simplest: root(DEBUG) then I get groovy.lang.MissingMethodException: No signature of method: Script1.root() is applicable for argument types: (ch.qos.logback.classic.Level) values: [DEBUG] Possible solutions: wait(), run(), run(), wait(long), print(java.lang.Object), print(java.lang.Object) Below is logback.groovy, could you enlighten me what I am doing wrong? Thanks, Tamas ============================ @Grab('ch.qos.logback:logback-core:1.0.0') @Grab('ch.qos.logback:logback-classic:1.0.0') @Grab('ch.qos.logback:logback-examples:1.0.0') import ch.qos.logback.classic.encoder.PatternLayoutEncoder import ch.qos.logback.core.ConsoleAppender import static ch.qos.logback.classic.Level.DEBUG //appender("STDOUT", ConsoleAppender) { // encoder(PatternLayoutEncoder) { // pattern = "%d{HH:mm:ss.SSS} XXX [%thread] %-5level %logger{36} - %msg%n" // } //} root(DEBUG) <http://logback.qos.ch/manual/configuration.html>
The logback.groovy files are meant to be executed by GafferConfigurator. They are not standalone groovy applications. HTH, On 09.11.2011 16:20, Tompi Mat wrote:
Hi,
I am trying to use logback.groovy instead of logback.xml in my groovy project but I might be missing something:
$ cat HelloWorld.groovy @Grab('org.slf4j:slf4j-api:1.6.1') @Grab('ch.qos.logback:logback-core:1.0.0') @Grab('ch.qos.logback:logback-classic:1.0.0') @Grab('ch.qos.logback:logback-examples:1.0.0') import org.slf4j.Logger import org.slf4j.LoggerFactory
public class HelloWorld1 {
public static void main(String[] args) {
Logger logger = LoggerFactory.getLogger( "HelloWorld1" ) logger.warn("Hello world.") } }
If I put the first example from http://logback.qos.ch/manual/configuration.html of sample0.xml as logback.xml, it seems to work perfect.
If I put the logback.groovy equivalent instead, I get various errors, like :
$ groovy HelloWorld.groovy Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'ch.qos.logback.core.ConsoleAppender[null]' with class 'ch.qos.logback.core.ConsoleAppender' to class 'ch.qos.logback.core.Appender' at org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:331)
If I only go with the simplest:
root(DEBUG)
then I get
groovy.lang.MissingMethodException: No signature of method: Script1.root() is applicable for argument types: (ch.qos.logback.classic.Level) values: [DEBUG] Possible solutions: wait(), run(), run(), wait(long), print(java.lang.Object), print(java.lang.Object)
Below is logback.groovy, could you enlighten me what I am doing wrong?
Thanks,
Tamas
============================ @Grab('ch.qos.logback:logback-core:1.0.0') @Grab('ch.qos.logback:logback-classic:1.0.0') @Grab('ch.qos.logback:logback-examples:1.0.0') import ch.qos.logback.classic.encoder.PatternLayoutEncoder import ch.qos.logback.core.ConsoleAppender
import static ch.qos.logback.classic.Level.DEBUG
//appender("STDOUT", ConsoleAppender) { // encoder(PatternLayoutEncoder) { // pattern = "%d{HH:mm:ss.SSS} XXX [%thread] %-5level %logger{36} - %msg%n" // } //} root(DEBUG)
-- Ceki http://twitter.com/#!/ceki
Hi Thanks a lot for the prompt reply! What I don't quite understand at this point is users are encouraged to use them or not. It looks like logback.groovy files are in the way, anyhow - I am not explicitly executing it but it is picked up by the HelloWorld.groovy just to throw the error I mentioned. I much prefer groovy DSL to XML but I have not found any clues as to how logback.groovy is to be used and it puzzles me what the benefit of the XML->groovy translators are? Thanks a lot Tamas On 11/09/2011 04:23 PM, ceki wrote:
The logback.groovy files are meant to be executed by GafferConfigurator. They are not standalone groovy applications.
HTH,
On 09.11.2011 16:20, Tompi Mat wrote:
Hi,
I am trying to use logback.groovy instead of logback.xml in my groovy project but I might be missing something:
$ cat HelloWorld.groovy @Grab('org.slf4j:slf4j-api:1.6.1') @Grab('ch.qos.logback:logback-core:1.0.0') @Grab('ch.qos.logback:logback-classic:1.0.0') @Grab('ch.qos.logback:logback-examples:1.0.0') import org.slf4j.Logger import org.slf4j.LoggerFactory
public class HelloWorld1 {
public static void main(String[] args) {
Logger logger = LoggerFactory.getLogger( "HelloWorld1" ) logger.warn("Hello world.") } }
If I put the first example from http://logback.qos.ch/manual/configuration.html of sample0.xml as logback.xml, it seems to work perfect.
If I put the logback.groovy equivalent instead, I get various errors, like :
$ groovy HelloWorld.groovy Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'ch.qos.logback.core.ConsoleAppender[null]' with class 'ch.qos.logback.core.ConsoleAppender' to class 'ch.qos.logback.core.Appender' at org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:331)
If I only go with the simplest:
root(DEBUG)
then I get
groovy.lang.MissingMethodException: No signature of method: Script1.root() is applicable for argument types: (ch.qos.logback.classic.Level) values: [DEBUG] Possible solutions: wait(), run(), run(), wait(long), print(java.lang.Object), print(java.lang.Object)
Below is logback.groovy, could you enlighten me what I am doing wrong?
Thanks,
Tamas
============================ @Grab('ch.qos.logback:logback-core:1.0.0') @Grab('ch.qos.logback:logback-classic:1.0.0') @Grab('ch.qos.logback:logback-examples:1.0.0') import ch.qos.logback.classic.encoder.PatternLayoutEncoder import ch.qos.logback.core.ConsoleAppender
import static ch.qos.logback.classic.Level.DEBUG
//appender("STDOUT", ConsoleAppender) { // encoder(PatternLayoutEncoder) { // pattern = "%d{HH:mm:ss.SSS} XXX [%thread] %-5level %logger{36} - %msg%n" // } //} root(DEBUG)
You just place logback.groovy file on your class path and it will be picked up by logback to configure itself much in the same way as logback.xml files are picked up for configuration. I hope this helps, -- Ceki On 09.11.2011 18:57, Tompi Mat wrote:
Hi
Thanks a lot for the prompt reply! What I don't quite understand at this point is users are encouraged to use them or not.
It looks like logback.groovy files are in the way, anyhow - I am not explicitly executing it but it is picked up by the HelloWorld.groovy just to throw the error I mentioned.
I much prefer groovy DSL to XML but I have not found any clues as to how logback.groovy is to be used and it puzzles me what the benefit of the XML->groovy translators are?
Thanks a lot
Tamas
Hi Well, this is exactly what does not work as I intended to show in my original email. Unless I massively misunderstood something Tamas On 11/09/2011 07:20 PM, ceki wrote:
You just place logback.groovy file on your class path and it will be picked up by logback to configure itself much in the same way as logback.xml files are picked up for configuration. I hope this helps, -- Ceki On 09.11.2011 18:57, Tompi Mat wrote:
Hi
Thanks a lot for the prompt reply! What I don't quite understand at this point is users are encouraged to use them or not.
It looks like logback.groovy files are in the way, anyhow - I am not explicitly executing it but it is picked up by the HelloWorld.groovy just to throw the error I mentioned.
I much prefer groovy DSL to XML but I have not found any clues as to how logback.groovy is to be used and it puzzles me what the benefit of the XML->groovy translators are?
Thanks a lot
Tamas
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
The following lines from your logback.groovy file are most probably not be needed and look rather suspicious. (I am aware of what @Grab does.) @Grab('ch.qos.logback:logback-core:1.0.0') @Grab('ch.qos.logback:logback-classic:1.0.0') @Grab('ch.qos.logback:logback-examples:1.0.0') What happens when you remove them? On 09.11.2011 19:26, Tompi Mat wrote:
Hi
Well, this is exactly what does not work as I intended to show in my original email.
Unless I massively misunderstood something Tamas
On 11/09/2011 07:20 PM, ceki wrote:
You just place logback.groovy file on your class path and it will be picked up by logback to configure itself much in the same way as logback.xml files are picked up for configuration. I hope this helps, -- Ceki On 09.11.2011 18:57, Tompi Mat wrote:
Hi
Thanks a lot for the prompt reply! What I don't quite understand at this point is users are encouraged to use them or not.
It looks like logback.groovy files are in the way, anyhow - I am not explicitly executing it but it is picked up by the HelloWorld.groovy just to throw the error I mentioned.
I much prefer groovy DSL to XML but I have not found any clues as to how logback.groovy is to be used and it puzzles me what the benefit of the XML->groovy translators are?
Thanks a lot
Tamas
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
-- Ceki http://twitter.com/#!/ceki
After removing the @Grabs: $ groovy HelloWorld.groovy Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: Script1.groovy: 1: unable to resolve class ch.qos.logback.classic.encoder.PatternLayoutEncoder @ line 1, column 1. import ch.qos.logback.classic.encoder.PatternLayoutEncoder ^ Script1.groovy: 2: unable to resolve class ch.qos.logback.core.ConsoleAppender @ line 2, column 1. import ch.qos.logback.core.ConsoleAppender ^ Script1.groovy: 4: unable to resolve class ch.qos.logback.classic.Level @ line 4, column 1. import static ch.qos.logback.classic.Level.DEBUG ^ On 11/09/2011 07:38 PM, ceki wrote:
The following lines from your logback.groovy file are most probably not be needed and look rather suspicious. (I am aware of what @Grab does.)
@Grab('ch.qos.logback:logback-core:1.0.0') @Grab('ch.qos.logback:logback-classic:1.0.0') @Grab('ch.qos.logback:logback-examples:1.0.0')
What happens when you remove them?
On 09.11.2011 19:26, Tompi Mat wrote:
Hi
Well, this is exactly what does not work as I intended to show in my original email.
Unless I massively misunderstood something Tamas
On 11/09/2011 07:20 PM, ceki wrote:
You just place logback.groovy file on your class path and it will be picked up by logback to configure itself much in the same way as logback.xml files are picked up for configuration. I hope this helps, -- Ceki On 09.11.2011 18:57, Tompi Mat wrote:
Hi
Thanks a lot for the prompt reply! What I don't quite understand at this point is users are encouraged to use them or not.
It looks like logback.groovy files are in the way, anyhow - I am not explicitly executing it but it is picked up by the HelloWorld.groovy just to throw the error I mentioned.
I much prefer groovy DSL to XML but I have not found any clues as to how logback.groovy is to be used and it puzzles me what the benefit of the XML->groovy translators are?
Thanks a lot
Tamas
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Have you tried placing logback-core.jar and logback-classic.jar on your class path in the same way that slf4j-api.jar is. On 09.11.2011 19:42, Tompi Mat wrote:
After removing the @Grabs:
$ groovy HelloWorld.groovy Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: Script1.groovy: 1: unable to resolve class ch.qos.logback.classic.encoder.PatternLayoutEncoder @ line 1, column 1. import ch.qos.logback.classic.encoder.PatternLayoutEncoder ^
Script1.groovy: 2: unable to resolve class ch.qos.logback.core.ConsoleAppender @ line 2, column 1. import ch.qos.logback.core.ConsoleAppender ^
Script1.groovy: 4: unable to resolve class ch.qos.logback.classic.Level @ line 4, column 1. import static ch.qos.logback.classic.Level.DEBUG ^
-- Ceki http://twitter.com/#!/ceki
Hi, In the examples I have shown so far, nothing has been on my classpath except for the directory containing logback.groovy. I.e. slf4j-api was @Grab-bed in HelloWorld.groovy. Removing all the @Grabs from both HelloWorld.groovy and logback.groovy and placing all the jars on the classpath indeed works. Of course this is not a path I want to go, while I would love to use logback.groovy instead of logback.xml, the latter beats having jars around instead of @Grabs While this is a serious problem for me I am surprised that noone else is running into this? Thanks a lot for the discussion, I am looking forward to news that this may some day be fixed. Cheers, I really appreciate your work Tamas On 11/09/2011 07:51 PM, ceki wrote:
Have you tried placing logback-core.jar and logback-classic.jar on your class path in the same way that slf4j-api.jar is.
On 09.11.2011 19:42, Tompi Mat wrote:
After removing the @Grabs:
$ groovy HelloWorld.groovy Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: Script1.groovy: 1: unable to resolve class ch.qos.logback.classic.encoder.PatternLayoutEncoder @ line 1, column 1. import ch.qos.logback.classic.encoder.PatternLayoutEncoder ^
Script1.groovy: 2: unable to resolve class ch.qos.logback.core.ConsoleAppender @ line 2, column 1. import ch.qos.logback.core.ConsoleAppender ^
Script1.groovy: 4: unable to resolve class ch.qos.logback.classic.Level @ line 4, column 1. import static ch.qos.logback.classic.Level.DEBUG ^
Being that the code that loads logback.groovy is within logback.jar, I don't see any way around having at least that jar on the classpath. (*Chris*) On Wed, Nov 9, 2011 at 12:09 PM, Tompi Mat <thauer.spam@gmail.com> wrote:
Hi,
In the examples I have shown so far, nothing has been on my classpath except for the directory containing logback.groovy. I.e. slf4j-api was @Grab-bed in HelloWorld.groovy.
Removing all the @Grabs from both HelloWorld.groovy and logback.groovy and placing all the jars on the classpath indeed works.
Of course this is not a path I want to go, while I would love to use logback.groovy instead of logback.xml, the latter beats having jars around instead of @Grabs
While this is a serious problem for me I am surprised that noone else is running into this?
Thanks a lot for the discussion, I am looking forward to news that this may some day be fixed.
Cheers, I really appreciate your work
Tamas
On 11/09/2011 07:51 PM, ceki wrote:
Have you tried placing logback-core.jar and logback-classic.jar on your class path in the same way that slf4j-api.jar is.
On 09.11.2011 19:42, Tompi Mat wrote:
After removing the @Grabs:
$ groovy HelloWorld.groovy Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: Script1.groovy: 1: unable to resolve class ch.qos.logback.classic.encoder.PatternLayoutEncoder @ line 1, column 1. import ch.qos.logback.classic.encoder.PatternLayoutEncoder ^
Script1.groovy: 2: unable to resolve class ch.qos.logback.core.ConsoleAppender @ line 2, column 1. import ch.qos.logback.core.ConsoleAppender ^
Script1.groovy: 4: unable to resolve class ch.qos.logback.classic.Level @ line 4, column 1. import static ch.qos.logback.classic.Level.DEBUG ^
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
I don't know much about classloading but is not logback.xml loaded by logback.jar as well? (@Grab puts the jars on the classpath, too - I am completely happy with @Grab-bing logback dependencies from HelloWorld.groovy, see the original post) Tamas On 11/09/2011 09:13 PM, Chris Pratt wrote:
Being that the code that loads logback.groovy is within logback.jar, I don't see any way around having at least that jar on the classpath. (*Chris*)
On Wed, Nov 9, 2011 at 12:09 PM, Tompi Mat <thauer.spam@gmail.com <mailto:thauer.spam@gmail.com>> wrote:
Hi,
In the examples I have shown so far, nothing has been on my classpath except for the directory containing logback.groovy. I.e. slf4j-api was @Grab-bed in HelloWorld.groovy.
Removing all the @Grabs from both HelloWorld.groovy and logback.groovy and placing all the jars on the classpath indeed works.
Of course this is not a path I want to go, while I would love to use logback.groovy instead of logback.xml, the latter beats having jars around instead of @Grabs
While this is a serious problem for me I am surprised that noone else is running into this?
Thanks a lot for the discussion, I am looking forward to news that this may some day be fixed.
Cheers, I really appreciate your work
Tamas
On 11/09/2011 07:51 PM, ceki wrote: > > Have you tried placing logback-core.jar and logback-classic.jar on > your class path in the same way that slf4j-api.jar is. > > On 09.11.2011 19:42, Tompi Mat wrote: >> After removing the @Grabs: >> >> $ groovy HelloWorld.groovy >> Failed to instantiate [ch.qos.logback.classic.LoggerContext] >> Reported exception: >> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup >> failed: >> Script1.groovy: 1: unable to resolve class >> ch.qos.logback.classic.encoder.PatternLayoutEncoder >> @ line 1, column 1. >> import ch.qos.logback.classic.encoder.PatternLayoutEncoder >> ^ >> >> Script1.groovy: 2: unable to resolve class >> ch.qos.logback.core.ConsoleAppender >> @ line 2, column 1. >> import ch.qos.logback.core.ConsoleAppender >> ^ >> >> Script1.groovy: 4: unable to resolve class ch.qos.logback.classic.Level >> @ line 4, column 1. >> import static ch.qos.logback.classic.Level.DEBUG >> ^ > >
_______________________________________________ Logback-user mailing list Logback-user@qos.ch <mailto:Logback-user@qos.ch> http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
participants (3)
-
ceki -
Chris Pratt -
Tompi Mat