What support is needed to run with logback.groovy configuration?
I switched my application from using logback.xml to using logback.groovy. I just wanted to try it but off the bat, I much prefer scanning through an easily alphabetized list of loggers in the groovy file to the mess that you get with XML and lots of loggers. However, my hopes for a quick success were dashed when I saw: Groovy classes are not available on the class path. ABORTING INITIALIZION. What must I do to my application classpath to allow logback configuration via groovy? The manual does not seem to have any information on this. Also, I noticed via goggling the issue that JSON causes an issue with groovy. This will also impact me as our application makes use of JSON. Thanks to anyone who can provide this information. Steve Cohen
On 07/27/2012 10:54 AM, Steve Cohen wrote:
I switched my application from using logback.xml to using logback.groovy. I just wanted to try it but off the bat, I much prefer scanning through an easily alphabetized list of loggers in the groovy file to the mess that you get with XML and lots of loggers.
However, my hopes for a quick success were dashed when I saw:
Groovy classes are not available on the class path. ABORTING INITIALIZION.
What must I do to my application classpath to allow logback configuration via groovy? The manual does not seem to have any information on this.
Also, I noticed via goggling the issue that JSON causes an issue with groovy. This will also impact me as our application makes use of JSON.
Thanks to anyone who can provide this information.
Steve Cohen _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
I don't think groovy is going to work for me. If I have to work this hard to get it to work, that's too hard for now. Tried importing various groovy jars that are available via Maven, none of them got me over the hump, plus there would still be the issue of how to turn that off in production, etc. I need something seamless. So here's a question: The one advantage I hoped to gain from Groovy is easier searching/alphabetizing a large list of loggers. Is anyone using an XML tool that allows stuff like this to be done easily, as opposed to the relative skimpily-featured XML editor that comes with Eclipsez/ I would like a view that showed the names of all the loggers and alphabetized based on name.
Hi Steve, Have you tried adding the following? <dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-all</artifactId> <version>1.7.2</version> </dependency> It's the groovy dependency that logback-classic uses. HTH, On 27.07.2012 17:54, Steve Cohen wrote:
I switched my application from using logback.xml to using logback.groovy. I just wanted to try it but off the bat, I much prefer scanning through an easily alphabetized list of loggers in the groovy file to the mess that you get with XML and lots of loggers.
However, my hopes for a quick success were dashed when I saw:
Groovy classes are not available on the class path. ABORTING INITIALIZION.
What must I do to my application classpath to allow logback configuration via groovy? The manual does not seem to have any information on this.
Also, I noticed via goggling the issue that JSON causes an issue with groovy. This will also impact me as our application makes use of JSON.
Thanks to anyone who can provide this information.
Steve Cohen
-- Ceki http://tinyurl.com/proLogback
No, I hadn't, thanks! That works. I made groovy a runtime dependency and it works. My repo mirror only showed me groovy up to 1.6.3, but when I changed it to 1.7.2, it found it and it works. On 07/27/2012 05:09 PM, ceki wrote:
Hi Steve,
Have you tried adding the following?
<dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-all</artifactId> <version>1.7.2</version> </dependency>
It's the groovy dependency that logback-classic uses.
HTH,
On 27.07.2012 17:54, Steve Cohen wrote:
I switched my application from using logback.xml to using logback.groovy. I just wanted to try it but off the bat, I much prefer scanning through an easily alphabetized list of loggers in the groovy file to the mess that you get with XML and lots of loggers.
However, my hopes for a quick success were dashed when I saw:
Groovy classes are not available on the class path. ABORTING INITIALIZION.
What must I do to my application classpath to allow logback configuration via groovy? The manual does not seem to have any information on this.
Also, I noticed via goggling the issue that JSON causes an issue with groovy. This will also impact me as our application makes use of JSON.
Thanks to anyone who can provide this information.
Steve Cohen
Sorry. My previous positive reply about your suggestion was erroneous. I had neglected to tell my app to use the groovy configuration file. When I did that, I got the same error as I did using the earlier version of groovy: 10:18:14,490 |-INFO in ch.qos.logback.classic.gaffer.ConfigurationDelegate@1f0aecc - Adding aforementioned turbo filter to context Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: groovy.lang.MissingPropertyException: No such property: files for class: Script1 at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:49) at org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:49) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetProperty(AbstractCallSite.java:241) at Script1.run(Script1.groovy:39) at Script1$run.call(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:121) at ch.qos.logback.classic.gaffer.GafferConfigurator.run(GafferConfigurator.groovy:59) at ch.qos.logback.classic.gaffer.GafferConfigurator$run.callCurrent(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:143) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:151) at ch.qos.logback.classic.gaffer.GafferConfigurator.run(GafferConfigurator.groovy:37) at ch.qos.logback.classic.gaffer.GafferUtil.runGafferConfiguratorOn(GafferUtil.java:43) at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:65) at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:148) at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84) at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:54) at org.slf4j.LoggerFactory.bind(LoggerFactory.java:128) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:108) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:279) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:252) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:265) ... On 07/28/2012 12:20 PM, Steve Cohen wrote:
No, I hadn't, thanks! That works. I made groovy a runtime dependency and it works.
My repo mirror only showed me groovy up to 1.6.3, but when I changed it to 1.7.2, it found it and it works.
On 07/27/2012 05:09 PM, ceki wrote:
Hi Steve,
Have you tried adding the following?
<dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-all</artifactId> <version>1.7.2</version> </dependency>
It's the groovy dependency that logback-classic uses.
HTH,
On 27.07.2012 17:54, Steve Cohen wrote:
I switched my application from using logback.xml to using logback.groovy. I just wanted to try it but off the bat, I much prefer scanning through an easily alphabetized list of loggers in the groovy file to the mess that you get with XML and lots of loggers.
However, my hopes for a quick success were dashed when I saw:
Groovy classes are not available on the class path. ABORTING INITIALIZION.
What must I do to my application classpath to allow logback configuration via groovy? The manual does not seem to have any information on this.
Also, I noticed via goggling the issue that JSON causes an issue with groovy. This will also impact me as our application makes use of JSON.
Thanks to anyone who can provide this information.
Steve Cohen
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Maybe this got lost over the weekend? What does this exception thrown when trying to use a logback.groovy configuration indicate? Groovy.1.7.2 is on the classpath as indicated by ceki. On 07/29/2012 10:25 AM, Steve Cohen wrote:
Sorry. My previous positive reply about your suggestion was erroneous. I had neglected to tell my app to use the groovy configuration file. When I did that, I got the same error as I did using the earlier version of groovy:
10:18:14,490 |-INFO in ch.qos.logback.classic.gaffer.ConfigurationDelegate@1f0aecc - Adding aforementioned turbo filter to context Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: groovy.lang.MissingPropertyException: No such property: files for class: Script1 at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:49)
at org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:49)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetProperty(AbstractCallSite.java:241)
at Script1.run(Script1.groovy:39) at Script1$run.call(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:121)
at ch.qos.logback.classic.gaffer.GafferConfigurator.run(GafferConfigurator.groovy:59)
at ch.qos.logback.classic.gaffer.GafferConfigurator$run.callCurrent(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:143)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:151)
at ch.qos.logback.classic.gaffer.GafferConfigurator.run(GafferConfigurator.groovy:37)
at ch.qos.logback.classic.gaffer.GafferUtil.runGafferConfiguratorOn(GafferUtil.java:43)
at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:65)
at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:148)
at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84) at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:54) at org.slf4j.LoggerFactory.bind(LoggerFactory.java:128) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:108) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:279) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:252) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:265) ...
On 07/28/2012 12:20 PM, Steve Cohen wrote:
No, I hadn't, thanks! That works. I made groovy a runtime dependency and it works.
My repo mirror only showed me groovy up to 1.6.3, but when I changed it to 1.7.2, it found it and it works.
On 07/27/2012 05:09 PM, ceki wrote:
Hi Steve,
Have you tried adding the following?
<dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-all</artifactId> <version>1.7.2</version> </dependency>
It's the groovy dependency that logback-classic uses.
HTH,
On 27.07.2012 17:54, Steve Cohen wrote:
I switched my application from using logback.xml to using logback.groovy. I just wanted to try it but off the bat, I much prefer scanning through an easily alphabetized list of loggers in the groovy file to the mess that you get with XML and lots of loggers.
However, my hopes for a quick success were dashed when I saw:
Groovy classes are not available on the class path. ABORTING INITIALIZION.
What must I do to my application classpath to allow logback configuration via groovy? The manual does not seem to have any information on this.
Also, I noticed via goggling the issue that JSON causes an issue with groovy. This will also impact me as our application makes use of JSON.
Thanks to anyone who can provide this information.
Steve Cohen
_______________________________________________ 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
After upgrading to logback-1.0.7 and groovy 2.0.0, the problem below continues to be an issue and I am unable to make progress with it. The error messages are the same. Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: groovy.lang.MissingPropertyException: No such property: files for class: Script1 I am no groovy expert. I want to use groovy only because it offers a terser notation than xml configuration that would enable me to more easily manage my configuration on the fly. But I can't get past this error or know what it even means. No such property: files for class: Script1 I have no clue how to solve this. Can someone please help? What is it trying to tell me? I know of no "Script1" Steve On 07/31/2012 07:24 AM, Steve Cohen wrote:
Maybe this got lost over the weekend? What does this exception thrown when trying to use a logback.groovy configuration indicate? Groovy.1.7.2 is on the classpath as indicated by ceki.
On 07/29/2012 10:25 AM, Steve Cohen wrote:
Sorry. My previous positive reply about your suggestion was erroneous. I had neglected to tell my app to use the groovy configuration file. When I did that, I got the same error as I did using the earlier version of groovy:
10:18:14,490 |-INFO in ch.qos.logback.classic.gaffer.ConfigurationDelegate@1f0aecc - Adding aforementioned turbo filter to context Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: groovy.lang.MissingPropertyException: No such property: files for class: Script1 at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:49)
at org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:49)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetProperty(AbstractCallSite.java:241)
at Script1.run(Script1.groovy:39) at Script1$run.call(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:121)
at ch.qos.logback.classic.gaffer.GafferConfigurator.run(GafferConfigurator.groovy:59)
at ch.qos.logback.classic.gaffer.GafferConfigurator$run.callCurrent(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:143)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:151)
at ch.qos.logback.classic.gaffer.GafferConfigurator.run(GafferConfigurator.groovy:37)
at ch.qos.logback.classic.gaffer.GafferUtil.runGafferConfiguratorOn(GafferUtil.java:43)
at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:65)
at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:148)
at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84) at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:54) at org.slf4j.LoggerFactory.bind(LoggerFactory.java:128) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:108) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:279) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:252) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:265) ...
On 07/28/2012 12:20 PM, Steve Cohen wrote:
No, I hadn't, thanks! That works. I made groovy a runtime dependency and it works.
My repo mirror only showed me groovy up to 1.6.3, but when I changed it to 1.7.2, it found it and it works.
On 07/27/2012 05:09 PM, ceki wrote:
Hi Steve,
Have you tried adding the following?
<dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-all</artifactId> <version>1.7.2</version> </dependency>
It's the groovy dependency that logback-classic uses.
HTH,
On 27.07.2012 17:54, Steve Cohen wrote:
I switched my application from using logback.xml to using logback.groovy. I just wanted to try it but off the bat, I much prefer scanning through an easily alphabetized list of loggers in the groovy file to the mess that you get with XML and lots of loggers.
However, my hopes for a quick success were dashed when I saw:
Groovy classes are not available on the class path. ABORTING INITIALIZION.
What must I do to my application classpath to allow logback configuration via groovy? The manual does not seem to have any information on this.
Also, I noticed via goggling the issue that JSON causes an issue with groovy. This will also impact me as our application makes use of JSON.
Thanks to anyone who can provide this information.
Steve Cohen
_______________________________________________ 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
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
I haven't used the groovy config, but it sounds to me like you effectively have a compile error in your config - you are using the word "files" as an identifier somewhere where the Logback groovy config is not expecting it. Groovy DSLs tend to work by doing a lot of clever stuff around syntax, building on the fact that at compile time Groovy doesn't know what properties may be available on a class at runtime. Consequently you don't get compile time indicators as to whether you are getting the syntax of the DSL right; instead it fails at runtime, complaining that a property was not present. Rob On 24 Aug 2012, at 20:00, Steve Cohen <scohen@javactivity.org> wrote:
After upgrading to logback-1.0.7 and groovy 2.0.0, the problem below continues to be an issue and I am unable to make progress with it. The error messages are the same.
Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: groovy.lang.MissingPropertyException: No such property: files for class: Script1
I am no groovy expert. I want to use groovy only because it offers a terser notation than xml configuration that would enable me to more easily manage my configuration on the fly.
But I can't get past this error or know what it even means.
No such property: files for class: Script1
I have no clue how to solve this. Can someone please help? What is it trying to tell me? I know of no "Script1"
Steve
On 07/31/2012 07:24 AM, Steve Cohen wrote:
Maybe this got lost over the weekend? What does this exception thrown when trying to use a logback.groovy configuration indicate? Groovy.1.7.2 is on the classpath as indicated by ceki.
On 07/29/2012 10:25 AM, Steve Cohen wrote:
Sorry. My previous positive reply about your suggestion was erroneous. I had neglected to tell my app to use the groovy configuration file. When I did that, I got the same error as I did using the earlier version of groovy:
10:18:14,490 |-INFO in ch.qos.logback.classic.gaffer.ConfigurationDelegate@1f0aecc - Adding aforementioned turbo filter to context Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: groovy.lang.MissingPropertyException: No such property: files for class: Script1 at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:49)
at org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:49)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetProperty(AbstractCallSite.java:241)
at Script1.run(Script1.groovy:39) at Script1$run.call(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:121)
at ch.qos.logback.classic.gaffer.GafferConfigurator.run(GafferConfigurator.groovy:59)
at ch.qos.logback.classic.gaffer.GafferConfigurator$run.callCurrent(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:143)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:151)
at ch.qos.logback.classic.gaffer.GafferConfigurator.run(GafferConfigurator.groovy:37)
at ch.qos.logback.classic.gaffer.GafferUtil.runGafferConfiguratorOn(GafferUtil.java:43)
at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:65)
at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:148)
at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84) at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:54) at org.slf4j.LoggerFactory.bind(LoggerFactory.java:128) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:108) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:279) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:252) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:265) ...
On 07/28/2012 12:20 PM, Steve Cohen wrote:
No, I hadn't, thanks! That works. I made groovy a runtime dependency and it works.
My repo mirror only showed me groovy up to 1.6.3, but when I changed it to 1.7.2, it found it and it works.
On 07/27/2012 05:09 PM, ceki wrote:
Hi Steve,
Have you tried adding the following?
<dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-all</artifactId> <version>1.7.2</version> </dependency>
It's the groovy dependency that logback-classic uses.
HTH,
On 27.07.2012 17:54, Steve Cohen wrote:
I switched my application from using logback.xml to using logback.groovy. I just wanted to try it but off the bat, I much prefer scanning through an easily alphabetized list of loggers in the groovy file to the mess that you get with XML and lots of loggers.
However, my hopes for a quick success were dashed when I saw:
Groovy classes are not available on the class path. ABORTING INITIALIZION.
What must I do to my application classpath to allow logback configuration via groovy? The manual does not seem to have any information on this.
Also, I noticed via goggling the issue that JSON causes an issue with groovy. This will also impact me as our application makes use of JSON.
Thanks to anyone who can provide this information.
Steve Cohen
_______________________________________________ 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
_______________________________________________ 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
Thanks, Robert, now we are getting somewhere. Indeed, my logback.groovy contains the line def logdir = ${files.root}/logdir This came from a translation of my logback.xml by ceki's handy converter webpage. Logback.xml had <property name="logdir" value = "${files.root}/logdir" /> where files.root is the name of a System property. So the question is, is there a way to express a system property name in groovy and what is it? Steve Indeed On 08/24/2012 02:50 PM, Robert Elliot wrote:
I haven't used the groovy config, but it sounds to me like you effectively have a compile error in your config - you are using the word "files" as an identifier somewhere where the Logback groovy config is not expecting it.
Groovy DSLs tend to work by doing a lot of clever stuff around syntax, building on the fact that at compile time Groovy doesn't know what properties may be available on a class at runtime. Consequently you don't get compile time indicators as to whether you are getting the syntax of the DSL right; instead it fails at runtime, complaining that a property was not present.
Rob
On 24 Aug 2012, at 20:00, Steve Cohen <scohen@javactivity.org> wrote:
After upgrading to logback-1.0.7 and groovy 2.0.0, the problem below continues to be an issue and I am unable to make progress with it. The error messages are the same.
Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: groovy.lang.MissingPropertyException: No such property: files for class: Script1
I am no groovy expert. I want to use groovy only because it offers a terser notation than xml configuration that would enable me to more easily manage my configuration on the fly.
But I can't get past this error or know what it even means.
No such property: files for class: Script1
I have no clue how to solve this. Can someone please help? What is it trying to tell me? I know of no "Script1"
Steve
If I understand correctly, removing the line "def logdir==..." allows the logback.groovy script to be successfully parsed ? On 25.08.2012 01:08, Steve Cohen wrote:
Thanks, Robert, now we are getting somewhere.
Indeed, my logback.groovy contains the line def logdir = ${files.root}/logdir
This came from a translation of my logback.xml by ceki's handy converter webpage. Logback.xml had <property name="logdir" value = "${files.root}/logdir" />
where files.root is the name of a System property.
So the question is, is there a way to express a system property name in groovy and what is it?
Steve
Indeed On 08/24/2012 02:50 PM, Robert Elliot wrote:
I haven't used the groovy config, but it sounds to me like you effectively have a compile error in your config - you are using the word "files" as an identifier somewhere where the Logback groovy config is not expecting it.
Groovy DSLs tend to work by doing a lot of clever stuff around syntax, building on the fact that at compile time Groovy doesn't know what properties may be available on a class at runtime. Consequently you don't get compile time indicators as to whether you are getting the syntax of the DSL right; instead it fails at runtime, complaining that a property was not present.
Rob
On 24 Aug 2012, at 20:00, Steve Cohen <scohen@javactivity.org> wrote:
After upgrading to logback-1.0.7 and groovy 2.0.0, the problem below continues to be an issue and I am unable to make progress with it. The error messages are the same.
Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: groovy.lang.MissingPropertyException: No such property: files for class: Script1
I am no groovy expert. I want to use groovy only because it offers a terser notation than xml configuration that would enable me to more easily manage my configuration on the fly.
But I can't get past this error or know what it even means.
No such property: files for class: Script1
I have no clue how to solve this. Can someone please help? What is it trying to tell me? I know of no "Script1"
Steve
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
-- Ceki http://tinyurl.com/proLogback
Yes, that is right. I changed it to def logdir = System.properties.getProperty('files.root')+"/logdir" and it works. there's probably a "groovier" way of handling that but I don't know what that is. Perhaps the translator might be improved to handle such occurrences. On 08/24/2012 06:16 PM, ceki wrote:
If I understand correctly, removing the line "def logdir==..." allows the logback.groovy script to be successfully parsed ?
On 25.08.2012 01:08, Steve Cohen wrote:
Thanks, Robert, now we are getting somewhere.
Indeed, my logback.groovy contains the line def logdir = ${files.root}/logdir
This came from a translation of my logback.xml by ceki's handy converter webpage. Logback.xml had <property name="logdir" value = "${files.root}/logdir" />
where files.root is the name of a System property.
So the question is, is there a way to express a system property name in groovy and what is it?
Steve
Indeed On 08/24/2012 02:50 PM, Robert Elliot wrote:
I haven't used the groovy config, but it sounds to me like you effectively have a compile error in your config - you are using the word "files" as an identifier somewhere where the Logback groovy config is not expecting it.
Groovy DSLs tend to work by doing a lot of clever stuff around syntax, building on the fact that at compile time Groovy doesn't know what properties may be available on a class at runtime. Consequently you don't get compile time indicators as to whether you are getting the syntax of the DSL right; instead it fails at runtime, complaining that a property was not present.
Rob
On 24 Aug 2012, at 20:00, Steve Cohen <scohen@javactivity.org> wrote:
After upgrading to logback-1.0.7 and groovy 2.0.0, the problem below continues to be an issue and I am unable to make progress with it. The error messages are the same.
Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: groovy.lang.MissingPropertyException: No such property: files for class: Script1
I am no groovy expert. I want to use groovy only because it offers a terser notation than xml configuration that would enable me to more easily manage my configuration on the fly.
But I can't get past this error or know what it even means.
No such property: files for class: Script1
I have no clue how to solve this. Can someone please help? What is it trying to tell me? I know of no "Script1"
Steve
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
In summary, the issue here is that logback configuration with XML automatically looks at System.properties in trying to resolve an expression of the form ${property_name}, whereas Groovy requires an explicit initial def statement from "System.properties" to create an initial definition in the groovy namespace. Once "property" is defined in the Groovy namespace, "${property}" can be resolved. But groovy will not automatically resolve "${property}" when "property" is the key of a system property. On 08/24/2012 06:30 PM, Steve Cohen wrote:
Yes, that is right.
I changed it to
def logdir = System.properties.getProperty('files.root')+"/logdir"
and it works.
there's probably a "groovier" way of handling that but I don't know what that is.
Perhaps the translator might be improved to handle such occurrences.
On 08/24/2012 06:16 PM, ceki wrote:
If I understand correctly, removing the line "def logdir==..." allows the logback.groovy script to be successfully parsed ?
On 25.08.2012 01:08, Steve Cohen wrote:
Thanks, Robert, now we are getting somewhere.
Indeed, my logback.groovy contains the line def logdir = ${files.root}/logdir
This came from a translation of my logback.xml by ceki's handy converter webpage. Logback.xml had <property name="logdir" value = "${files.root}/logdir" />
where files.root is the name of a System property.
So the question is, is there a way to express a system property name in groovy and what is it?
Steve
Indeed On 08/24/2012 02:50 PM, Robert Elliot wrote:
I haven't used the groovy config, but it sounds to me like you effectively have a compile error in your config - you are using the word "files" as an identifier somewhere where the Logback groovy config is not expecting it.
Groovy DSLs tend to work by doing a lot of clever stuff around syntax, building on the fact that at compile time Groovy doesn't know what properties may be available on a class at runtime. Consequently you don't get compile time indicators as to whether you are getting the syntax of the DSL right; instead it fails at runtime, complaining that a property was not present.
Rob
On 24 Aug 2012, at 20:00, Steve Cohen <scohen@javactivity.org> wrote:
After upgrading to logback-1.0.7 and groovy 2.0.0, the problem below continues to be an issue and I am unable to make progress with it. The error messages are the same.
Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: groovy.lang.MissingPropertyException: No such property: files for class: Script1
I am no groovy expert. I want to use groovy only because it offers a terser notation than xml configuration that would enable me to more easily manage my configuration on the fly.
But I can't get past this error or know what it even means.
No such property: files for class: Script1
I have no clue how to solve this. Can someone please help? What is it trying to tell me? I know of no "Script1"
Steve
_______________________________________________ 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
participants (3)
-
ceki -
Robert Elliot -
Steve Cohen