[jboss-jira] [JBoss JIRA] Commented: (LOGTOOL-20) Detect parameters being inconsistent with log message template

[Sanne Grinovero (JIRA)]

    [ https://issues.jboss.org/browse/LOGTOOL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608927#comment-12608927 ] 

Sanne Grinovero commented on LOGTOOL-20:
----------------------------------------

Hi,
I've been trying it out on Infinispan, but now it fails without telling me which message is wrong.
Running the build from command line, this is the output:
{quote}
[INFO] --- maven-compiler-plugin:2.3.1:compile (default-compile) @ infinispan-core ---
[INFO] Compiling 613 source files to /home/sanne/workspaces/infinispan/infinispan/core/target/classes
java.util.MissingFormatArgumentException: Format specifier 's'
	at java.util.Formatter.format(Formatter.java:2432)
	at java.util.Formatter.format(Formatter.java:2367)
	at java.lang.String.format(String.java:2769)
	at org.jboss.logging.generator.ToolLogger.log(ToolLogger.java:252)
	at org.jboss.logging.generator.ToolLogger.error(ToolLogger.java:184)
	at org.jboss.logging.generator.LoggingToolsProcessor.process(LoggingToolsProcessor.java:126)
	at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:625)
	at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:554)
	at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:699)
	at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:981)
	at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:727)
	at com.sun.tools.javac.main.Main.compile(Main.java:353)
	at com.sun.tools.javac.main.Main.compile(Main.java:279)
	at com.sun.tools.javac.main.Main.compile(Main.java:270)
	at com.sun.tools.javac.Main.compile(Main.java:87)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacCompiler.java:549)
	at org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java:156)
	at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:605)
	at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
[ERROR] Failure executing javac, but could not parse the error:


An annotation processor threw an uncaught exception.
Consult the following stack trace for details.

[INFO] 1error
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.681s
{quote}

I had a look in the code, and just catching the exception in org.jboss.logging.generator.ToolLogger.log(Kind, Element, String, Object...) to log "exception.getMessage() + messageFormat" with System.out.println looked to work nicely and identified two wrong messages. I'm unsure how this should be output properly?

> Detect parameters being inconsistent with log message template
> --------------------------------------------------------------
>
>                 Key: LOGTOOL-20
>                 URL: https://issues.jboss.org/browse/LOGTOOL-20
>             Project: Log Tool
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sanne Grinovero
>            Assignee: James Perkins
>             Fix For: 1.0.0.Beta8
>
>
> In both Infinispan and Hibernate we had reports of issues following the same patterns, as in code like:
> {code}
> @LogMessage(level = ERROR)
> @Message(id = 21, value = "Unable to synchronize source of %s for entity %s")
> void unableToSynchronizeSource(String indexName, @Cause Exception e);
> {code}
> People might do mistakes in the string template, forget to pass enough parameters, or not use the positional _%1$s_ variants. We can hardly write tests to cover all log messages, while I think it would be quite cool if the annotation processor could verify messages consistency with parameters at compile time.
> It would be just awesome if it could check for type consistency as well.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira