[GitHub] groovy pull request #325: GROOVY-7646 - Classes generated by Eval() never co...
Github user jwagenleitner closed the pull request at: https://github.com/apache/groovy/pull/325 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (GROOVY-7646) Classes generated by Eval() never collected from Permgen/Metaspace
[
https://issues.apache.org/jira/browse/GROOVY-7646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833664#comment-15833664
]
ASF GitHub Bot commented on GROOVY-7646:
Github user jwagenleitner closed the pull request at:
https://github.com/apache/groovy/pull/325
> Classes generated by Eval() never collected from Permgen/Metaspace
> --
>
> Key: GROOVY-7646
> URL: https://issues.apache.org/jira/browse/GROOVY-7646
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.5
> Environment: Oracle jdk8u51 and jdk8u66
>Reporter: Isaac Dooley
>
> It seems classes generated by Eval() are never collected, thus causing
> PermGen or Metaspace to fill up and the JVM to hang/crash.
> Reproduce by running the following code, after setting java option
> {{-XX:MaxMetaspaceSize=50m}}.
> {code}
> 10.times{ x -> assert 10 == Eval.x(2, 'x * 4 + 2;') }
> {code}
> After about 2700 calls to Eval the program will crash with OutOfMemoryError,
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-5471) Add "indy" option to Groovy Console
[ https://issues.apache.org/jira/browse/GROOVY-5471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833647#comment-15833647 ] ASF GitHub Bot commented on GROOVY-5471: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/475 > Add "indy" option to Groovy Console > --- > > Key: GROOVY-5471 > URL: https://issues.apache.org/jira/browse/GROOVY-5471 > Project: Groovy > Issue Type: Bug > Components: Groovy Console >Affects Versions: 2.0-beta-3 >Reporter: Cédric Champeau > > If "invokedynamic" support is available, the groovy console should show an > option allowing the scripts written in the console to be compiled with indy > support too. > Otherwise, the user might think that because he's using a "indy" jar, the > Groovy Console will compile scripts with indy activated, but in reality, only > core groovy classes will use indy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] groovy pull request #475: GROOVY-5471: Add "indy" option to Groovy Console (...
Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/475 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (GROOVY-5471) Add "indy" option to Groovy Console
[
https://issues.apache.org/jira/browse/GROOVY-5471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833655#comment-15833655
]
John Wagenleitner commented on GROOVY-5471:
---
{quote}Just commenting on this issue, this is a more general problem for indy,
which is also how to run tests while being sure that indy is on despite they
use things like assertScript.{quote}
It looks like since this comment [commit
40b02bca|https://github.com/apache/groovy/commit/40b02bcadce3c3d0768bcc35b3920f04322ea004]
added the {{groovy.target.indy}} System property to provide a mechanism to
ensure indy is enabled for such things as {{assertScript}}.
> Add "indy" option to Groovy Console
> ---
>
> Key: GROOVY-5471
> URL: https://issues.apache.org/jira/browse/GROOVY-5471
> Project: Groovy
> Issue Type: Bug
> Components: Groovy Console
>Affects Versions: 2.0-beta-3
>Reporter: Cédric Champeau
>
> If "invokedynamic" support is available, the groovy console should show an
> option allowing the scripts written in the console to be compiled with indy
> support too.
> Otherwise, the user might think that because he's using a "indy" jar, the
> Groovy Console will compile scripts with indy activated, but in reality, only
> core groovy classes will use indy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GROOVY-5471) Add "indy" option to Groovy Console
[ https://issues.apache.org/jira/browse/GROOVY-5471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Wagenleitner resolved GROOVY-5471. --- Resolution: Fixed Assignee: John Wagenleitner Fix Version/s: 2.5.0-beta-1 > Add "indy" option to Groovy Console > --- > > Key: GROOVY-5471 > URL: https://issues.apache.org/jira/browse/GROOVY-5471 > Project: Groovy > Issue Type: Bug > Components: Groovy Console >Affects Versions: 2.0-beta-3 >Reporter: Cédric Champeau >Assignee: John Wagenleitner > Fix For: 2.5.0-beta-1 > > > If "invokedynamic" support is available, the groovy console should show an > option allowing the scripts written in the console to be compiled with indy > support too. > Otherwise, the user might think that because he's using a "indy" jar, the > Groovy Console will compile scripts with indy activated, but in reality, only > core groovy classes will use indy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GROOVY-8056) GroovyCodeSource(URL) can leak a file handler
[
https://issues.apache.org/jira/browse/GROOVY-8056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833694#comment-15833694
]
John Wagenleitner commented on GROOVY-8056:
---
I think {{getContentEncoding()}} is not correct since we are looking for a
charset but it returns how the content is compressed (i.e., gzip, deflate) that
is specified in the [Content-Encoding HTTP
Header|https://tools.ietf.org/html/rfc7231#section-3.1.2.2].
To obtain a charset it's the {{getContentType()}} value and it's in the form
(when it's present) {{text/html; charset=UTF-8}}. Futher, I think we could
skip this call completely if {{"file".equals(url.getProtocol())}} since no
Content-Type header will be available.
> GroovyCodeSource(URL) can leak a file handler
> -
>
> Key: GROOVY-8056
> URL: https://issues.apache.org/jira/browse/GROOVY-8056
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.8
>Reporter: Andy Wilkinson
>
> When {{GroovyCodeSource}} is created from a {{URL}} it calls
> {{url.openConnection.getContentEncoding()}}. When it's a {{file:}} URL, this
> causes a {{FileInputStream}} to be opened and never closed. The stack trace
> for it being opened is:
> {noformat}
> at java.io.FileInputStream.(Unknown Source)
> at java.io.FileInputStream.(Unknown Source)
> at sun.net.www.protocol.file.FileURLConnection.connect(Unknown Source)
> at
> sun.net.www.protocol.file.FileURLConnection.initializeHeaders(Unknown Source)
> at sun.net.www.protocol.file.FileURLConnection.getHeaderField(Unknown
> Source)
> at java.net.URLConnection.getContentEncoding(Unknown Source)
> at groovy.lang.GroovyCodeSource.(GroovyCodeSource.java:176)
> at
> groovy.text.markup.MarkupTemplateEngine$MarkupTemplateMaker.(MarkupTemplateEngine.java:222)
> at
> groovy.text.markup.MarkupTemplateEngine.createTemplateByPath(MarkupTemplateEngine.java:145)
> {noformat}
> I believe that keeping a local reference to the {{URLConnection}} and then
> calling {{getInputStream().close()}} on it will fix the problem.
> For reference
> [this|https://github.com/spring-projects/spring-boot/issues/7892] is the
> Spring Boot issues where the problem was originally reported.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-6932) @Log annotation does not check logging enablement inside closures
[
https://issues.apache.org/jira/browse/GROOVY-6932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15834009#comment-15834009
]
Paul King commented on GROOVY-6932:
---
[~mwkohout] You are correct, closures defined inline as arguments to a method
call weren't being handled. I've cloned the issue to cover that case.
> @Log annotation does not check logging enablement inside closures
> -
>
> Key: GROOVY-6932
> URL: https://issues.apache.org/jira/browse/GROOVY-6932
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.2.0, 2.3.3
> Environment: Windows 7, Groovy 2.3.3, JDK 1.8.0_05
>Reporter: Shorn
>Assignee: Paul King
>Priority: Minor
> Fix For: 2.4.8
>
> Attachments: LogAstProblem.groovy, LoggingSpec.groovy
>
>
> Groovy doesn't do a check for whether the log level is enabled when the log
> statement is made from inside a closure.
> I believe the attached script should not print "called with 3".
> Result on my machine is:
> Groovy version: 2.3.3
> Java version: 1.8.0_05-b13
> OS: Windows 7
> called with 1
> 12:03:30.119 [main] INFO TestCode - blah: 1
> called with 3
> Script:
> {code}
> @Grapes([
> @Grab(group='org.slf4j', module='slf4j-api', version='1.7+'),
> @Grab(group='ch.qos.logback', module='logback-classic', version='1.+')])
> import groovy.util.logging.Slf4j
> new TestCode().doSomethingThatLogs()
> @Slf4j
> class TestCode {
> void doSomethingThatLogs(){
> println "Groovy version: ${GroovySystem.version}"
> println "Java version: ${System.properties["java.runtime.version"]}"
> println "OS: ${System.properties["os.name"]}"
> println ""
> log.info createLogString(1)
> log.trace createLogString(2)
> Closure c = { log.trace createLogString(3) }
> c()
> }
> String createLogString(int p){
> println "called with $p"
> return "blah: $p"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-8060) @Log annotation does not check logging enablement inside closures which are arguments to methods
[
https://issues.apache.org/jira/browse/GROOVY-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-8060:
--
Description:
Groovy doesn't do a check for whether the log level is enabled when the log
statement is made from inside a closure.
I believe the attached script should not print "called with 3".
>From cloned issue for an additional case:
{code}
import groovy.util.logging.Slf4j
import spock.lang.Specification
@Slf4j
class LoggingSpec extends Specification {
def "makes sure groovy isn't building the string inside inactive log
levels"() {
assert log.isDebugEnabled() == false, "set the log level for this class
to INFO to see the horror"
assert log.isInfoEnabled() == true, "set the log level for this class
to INFO to see the horror"
CountingDoIt counter = new CountingDoIt()
//http://docs.groovy-lang.org/docs/groovy-2.4.5/html/documentation/#_logging_improvements
when: "we shouldn't evaluate"
log.debug("this shouldn't happen ${counter.call()}".toString())
then:
counter.count == 0
when: "we should evaluate"
counter = new CountingDoIt()
log.info("this should happen ${counter.call()}".toString())
then:
counter.count == 1
when: "we're inside a closure and groovy is failing..so beware"
counter = new CountingDoIt()
1.times({ ignore ->
log.debug(counter.call())
})
then:
counter.count == 0//debug isn't enabled so this string should never
be evaluated but it is
when: "we're inside a closure that calls a method. it's OK"
counter = new CountingDoIt()
1.times({ ignore ->
log.debug("this shouldn't happen ${doIt(counter)}".toString())
})
then:
counter.count == 0
}
String doIt(CountingDoIt countingDoIt) {
log.debug("this shouldn't happen ${countingDoIt.call()}".toString())
"blah"
}
static class CountingDoIt {
int count = 0
String call() {
count = count + 1
"doneDidIt"
}
}
}
{code}
was:
Groovy doesn't do a check for whether the log level is enabled when the log
statement is made from inside a closure.
I believe the attached script should not print "called with 3".
Result on my machine is:
Groovy version: 2.3.3
Java version: 1.8.0_05-b13
OS: Windows 7
called with 1
12:03:30.119 [main] INFO TestCode - blah: 1
called with 3
Script:
{code}
@Grapes([
@Grab(group='org.slf4j', module='slf4j-api', version='1.7+'),
@Grab(group='ch.qos.logback', module='logback-classic', version='1.+')])
import groovy.util.logging.Slf4j
new TestCode().doSomethingThatLogs()
@Slf4j
class TestCode {
void doSomethingThatLogs(){
println "Groovy version: ${GroovySystem.version}"
println "Java version: ${System.properties["java.runtime.version"]}"
println "OS: ${System.properties["os.name"]}"
println ""
log.info createLogString(1)
log.trace createLogString(2)
Closure c = { log.trace createLogString(3) }
c()
}
String createLogString(int p){
println "called with $p"
return "blah: $p"
}
}
{code}
> @Log annotation does not check logging enablement inside closures which are
> arguments to methods
>
>
> Key: GROOVY-8060
> URL: https://issues.apache.org/jira/browse/GROOVY-8060
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.3.3, 2.4.8
> Environment: Windows 7, Groovy 2.3.3, JDK 1.8.0_05
>Reporter: Shorn
>Assignee: Paul King
>Priority: Minor
>
> Groovy doesn't do a check for whether the log level is enabled when the log
> statement is made from inside a closure.
> I believe the attached script should not print "called with 3".
> From cloned issue for an additional case:
> {code}
> import groovy.util.logging.Slf4j
> import spock.lang.Specification
> @Slf4j
> class LoggingSpec extends Specification {
> def "makes sure groovy isn't building the string inside inactive log
> levels"() {
> assert log.isDebugEnabled() == false, "set the log level for this
> class to INFO to see the horror"
> assert log.isInfoEnabled() == true, "set the log level for this class
> to INFO to see the horror"
> CountingDoIt counter = new CountingDoIt()
>
> //http://docs.groovy-lang.org/docs/groovy-2.4.5/html/documentation/#_logging_improvements
> when: "we shouldn't evaluate"
> log.debug("this shouldn't happen ${counter.call()}".toString())
> then:
> counter.count == 0
> when: "we should evaluate"
> counter = new CountingDoIt()
> log.info("this should happen
[jira] [Updated] (GROOVY-8060) @Log annotation does not check logging enablement inside closures which are arguments to methods
[
https://issues.apache.org/jira/browse/GROOVY-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-8060:
--
Description:
>From cloned issue for an additional case:
{code}
import groovy.util.logging.Slf4j
import spock.lang.Specification
@Slf4j
class LoggingSpec extends Specification {
def "makes sure groovy isn't building the string inside inactive log
levels"() {
assert log.isDebugEnabled() == false, "set the log level for this class
to INFO to see the horror"
assert log.isInfoEnabled() == true, "set the log level for this class
to INFO to see the horror"
CountingDoIt counter = new CountingDoIt()
//http://docs.groovy-lang.org/docs/groovy-2.4.5/html/documentation/#_logging_improvements
when: "we shouldn't evaluate"
log.debug("this shouldn't happen ${counter.call()}".toString())
then:
counter.count == 0
when: "we should evaluate"
counter = new CountingDoIt()
log.info("this should happen ${counter.call()}".toString())
then:
counter.count == 1
when: "we're inside a closure and groovy is failing..so beware"
counter = new CountingDoIt()
1.times({ ignore ->
log.debug(counter.call())
})
then:
counter.count == 0//debug isn't enabled so this string should never
be evaluated but it is
when: "we're inside a closure that calls a method. it's OK"
counter = new CountingDoIt()
1.times({ ignore ->
log.debug("this shouldn't happen ${doIt(counter)}".toString())
})
then:
counter.count == 0
}
String doIt(CountingDoIt countingDoIt) {
log.debug("this shouldn't happen ${countingDoIt.call()}".toString())
"blah"
}
static class CountingDoIt {
int count = 0
String call() {
count = count + 1
"doneDidIt"
}
}
}
{code}
was:
Groovy doesn't do a check for whether the log level is enabled when the log
statement is made from inside a closure.
I believe the attached script should not print "called with 3".
>From cloned issue for an additional case:
{code}
import groovy.util.logging.Slf4j
import spock.lang.Specification
@Slf4j
class LoggingSpec extends Specification {
def "makes sure groovy isn't building the string inside inactive log
levels"() {
assert log.isDebugEnabled() == false, "set the log level for this class
to INFO to see the horror"
assert log.isInfoEnabled() == true, "set the log level for this class
to INFO to see the horror"
CountingDoIt counter = new CountingDoIt()
//http://docs.groovy-lang.org/docs/groovy-2.4.5/html/documentation/#_logging_improvements
when: "we shouldn't evaluate"
log.debug("this shouldn't happen ${counter.call()}".toString())
then:
counter.count == 0
when: "we should evaluate"
counter = new CountingDoIt()
log.info("this should happen ${counter.call()}".toString())
then:
counter.count == 1
when: "we're inside a closure and groovy is failing..so beware"
counter = new CountingDoIt()
1.times({ ignore ->
log.debug(counter.call())
})
then:
counter.count == 0//debug isn't enabled so this string should never
be evaluated but it is
when: "we're inside a closure that calls a method. it's OK"
counter = new CountingDoIt()
1.times({ ignore ->
log.debug("this shouldn't happen ${doIt(counter)}".toString())
})
then:
counter.count == 0
}
String doIt(CountingDoIt countingDoIt) {
log.debug("this shouldn't happen ${countingDoIt.call()}".toString())
"blah"
}
static class CountingDoIt {
int count = 0
String call() {
count = count + 1
"doneDidIt"
}
}
}
{code}
> @Log annotation does not check logging enablement inside closures which are
> arguments to methods
>
>
> Key: GROOVY-8060
> URL: https://issues.apache.org/jira/browse/GROOVY-8060
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.3.3, 2.4.8
> Environment: Windows 7, Groovy 2.3.3, JDK 1.8.0_05
>Reporter: Shorn
>Assignee: Paul King
>Priority: Minor
>
> From cloned issue for an additional case:
> {code}
> import groovy.util.logging.Slf4j
> import spock.lang.Specification
> @Slf4j
> class LoggingSpec extends Specification {
> def "makes sure groovy isn't building the string inside inactive log
> levels"() {
> assert log.isDebugEnabled() == false, "set the log level for
[jira] [Updated] (GROOVY-8060) @Log annotation does not check logging enablement inside closures which are arguments to methods
[
https://issues.apache.org/jira/browse/GROOVY-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-8060:
--
Affects Version/s: (was: 2.2.0)
2.4.8
> @Log annotation does not check logging enablement inside closures which are
> arguments to methods
>
>
> Key: GROOVY-8060
> URL: https://issues.apache.org/jira/browse/GROOVY-8060
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.3.3, 2.4.8
> Environment: Windows 7, Groovy 2.3.3, JDK 1.8.0_05
>Reporter: Shorn
>Assignee: Paul King
>Priority: Minor
>
> From cloned issue for an additional case:
> {code}
> import groovy.util.logging.Slf4j
> import spock.lang.Specification
> @Slf4j
> class LoggingSpec extends Specification {
> def "makes sure groovy isn't building the string inside inactive log
> levels"() {
> assert log.isDebugEnabled() == false, "set the log level for this
> class to INFO to see the horror"
> assert log.isInfoEnabled() == true, "set the log level for this class
> to INFO to see the horror"
> CountingDoIt counter = new CountingDoIt()
>
> //http://docs.groovy-lang.org/docs/groovy-2.4.5/html/documentation/#_logging_improvements
> when: "we shouldn't evaluate"
> log.debug("this shouldn't happen ${counter.call()}".toString())
> then:
> counter.count == 0
> when: "we should evaluate"
> counter = new CountingDoIt()
> log.info("this should happen ${counter.call()}".toString())
> then:
> counter.count == 1
> when: "we're inside a closure and groovy is failing..so beware"
> counter = new CountingDoIt()
> 1.times({ ignore ->
> log.debug(counter.call())
> })
> then:
> counter.count == 0//debug isn't enabled so this string should
> never be evaluated but it is
> when: "we're inside a closure that calls a method. it's OK"
> counter = new CountingDoIt()
> 1.times({ ignore ->
> log.debug("this shouldn't happen ${doIt(counter)}".toString())
> })
> then:
> counter.count == 0
> }
> String doIt(CountingDoIt countingDoIt) {
> log.debug("this shouldn't happen ${countingDoIt.call()}".toString())
> "blah"
> }
> static class CountingDoIt {
> int count = 0
> String call() {
> count = count + 1
> "doneDidIt"
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-8060) @Log annotation does not check logging enablement inside closures which are arguments to methods
[
https://issues.apache.org/jira/browse/GROOVY-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-8060:
--
Fix Version/s: (was: 2.4.8)
> @Log annotation does not check logging enablement inside closures which are
> arguments to methods
>
>
> Key: GROOVY-8060
> URL: https://issues.apache.org/jira/browse/GROOVY-8060
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.3.3, 2.4.8
> Environment: Windows 7, Groovy 2.3.3, JDK 1.8.0_05
>Reporter: Shorn
>Assignee: Paul King
>Priority: Minor
>
> From cloned issue for an additional case:
> {code}
> import groovy.util.logging.Slf4j
> import spock.lang.Specification
> @Slf4j
> class LoggingSpec extends Specification {
> def "makes sure groovy isn't building the string inside inactive log
> levels"() {
> assert log.isDebugEnabled() == false, "set the log level for this
> class to INFO to see the horror"
> assert log.isInfoEnabled() == true, "set the log level for this class
> to INFO to see the horror"
> CountingDoIt counter = new CountingDoIt()
>
> //http://docs.groovy-lang.org/docs/groovy-2.4.5/html/documentation/#_logging_improvements
> when: "we shouldn't evaluate"
> log.debug("this shouldn't happen ${counter.call()}".toString())
> then:
> counter.count == 0
> when: "we should evaluate"
> counter = new CountingDoIt()
> log.info("this should happen ${counter.call()}".toString())
> then:
> counter.count == 1
> when: "we're inside a closure and groovy is failing..so beware"
> counter = new CountingDoIt()
> 1.times({ ignore ->
> log.debug(counter.call())
> })
> then:
> counter.count == 0//debug isn't enabled so this string should
> never be evaluated but it is
> when: "we're inside a closure that calls a method. it's OK"
> counter = new CountingDoIt()
> 1.times({ ignore ->
> log.debug("this shouldn't happen ${doIt(counter)}".toString())
> })
> then:
> counter.count == 0
> }
> String doIt(CountingDoIt countingDoIt) {
> log.debug("this shouldn't happen ${countingDoIt.call()}".toString())
> "blah"
> }
> static class CountingDoIt {
> int count = 0
> String call() {
> count = count + 1
> "doneDidIt"
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (GROOVY-8060) @Log annotation does not check logging enablement inside closures which are arguments to methods
Paul King created GROOVY-8060:
-
Summary: @Log annotation does not check logging enablement inside
closures which are arguments to methods
Key: GROOVY-8060
URL: https://issues.apache.org/jira/browse/GROOVY-8060
Project: Groovy
Issue Type: Bug
Components: groovy-runtime
Affects Versions: 2.2.0, 2.3.3
Environment: Windows 7, Groovy 2.3.3, JDK 1.8.0_05
Reporter: Shorn
Assignee: Paul King
Priority: Minor
Fix For: 2.4.8
Groovy doesn't do a check for whether the log level is enabled when the log
statement is made from inside a closure.
I believe the attached script should not print "called with 3".
Result on my machine is:
Groovy version: 2.3.3
Java version: 1.8.0_05-b13
OS: Windows 7
called with 1
12:03:30.119 [main] INFO TestCode - blah: 1
called with 3
Script:
{code}
@Grapes([
@Grab(group='org.slf4j', module='slf4j-api', version='1.7+'),
@Grab(group='ch.qos.logback', module='logback-classic', version='1.+')])
import groovy.util.logging.Slf4j
new TestCode().doSomethingThatLogs()
@Slf4j
class TestCode {
void doSomethingThatLogs(){
println "Groovy version: ${GroovySystem.version}"
println "Java version: ${System.properties["java.runtime.version"]}"
println "OS: ${System.properties["os.name"]}"
println ""
log.info createLogString(1)
log.trace createLogString(2)
Closure c = { log.trace createLogString(3) }
c()
}
String createLogString(int p){
println "called with $p"
return "blah: $p"
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
