[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] [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 ${counter.
[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] [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&focusedCommentId=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] [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)
[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&focusedCommentId=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-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&focusedCommentId=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)
[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] [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-5471) Add "indy" option to Groovy Console
[ https://issues.apache.org/jira/browse/GROOVY-5471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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&focusedCommentId=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. ---