5:50 a.m.
Detect parameters being inconsistent with log message template
--------------------------------------------------------------
Key: JBLOGGING-64
URL: https://issues.jboss.org/browse/JBLOGGING-64
Project: JBoss Logging
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Sanne Grinovero
Assignee: David Lloyd
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
10:24 a.m.
New subject: [JBoss JIRA] Moved: (LOGTOOL-20) Detect parameters being inconsistent with log message template
[
https://issues.jboss.org/browse/LOGTOOL-20?page=com.atlassian.jira.plugin...
]
David Lloyd moved JBLOGGING-64 to LOGTOOL-20:
---------------------------------------------
Project: Log Tool (was: JBoss Logging)
Key: LOGTOOL-20 (was: JBLOGGING-64)
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: David Lloyd
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
10:24 a.m.
New subject: [JBoss JIRA] Assigned: (LOGTOOL-20) Detect parameters being inconsistent with log message template
[
https://issues.jboss.org/browse/LOGTOOL-20?page=com.atlassian.jira.plugin...
]
David Lloyd reassigned LOGTOOL-20:
----------------------------------
Assignee: James Perkins (was: David Lloyd)
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
10:24 a.m.
New subject: [JBoss JIRA] Updated: (LOGTOOL-20) Detect parameters being inconsistent with log message template
[
https://issues.jboss.org/browse/LOGTOOL-20?page=com.atlassian.jira.plugin...
]
David Lloyd updated LOGTOOL-20:
-------------------------------
Fix Version/s: 1.0.0.Beta8
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
5:09 p.m.
New subject: [JBoss JIRA] Commented: (LOGTOOL-20) Detect parameters being inconsistent with log message template
[
https://issues.jboss.org/browse/LOGTOOL-20?page=com.atlassian.jira.plugin...
]
James Perkins commented on LOGTOOL-20:
--------------------------------------
We will definitely add parameter count checking. I'm currently looking into the best
approach to deal with type consistency. My guess is it's not impossible, but might
take some time to implement.
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
5:33 p.m.
New subject: [JBoss JIRA] Commented: (LOGTOOL-20) Detect parameters being inconsistent with log message template
[
https://issues.jboss.org/browse/LOGTOOL-20?page=com.atlassian.jira.plugin...
]
Sanne Grinovero commented on LOGTOOL-20:
----------------------------------------
Hi James, thanks a lot. If that takes more time could you split the issue (or if you
prefer I can open another one?), as having this one solved already would be very nice:
I'm confident that many projects would quickly identify some untested log statement as
we just mass-converted some and so log statements are mostly untested even on mature
codebases, and when this happens it's quite bad as the (original) statement is
hidden/lost.
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
5:33 p.m.
New subject: [JBoss JIRA] Issue Comment Edited: (LOGTOOL-20) Detect parameters being inconsistent with log message template
[
https://issues.jboss.org/browse/LOGTOOL-20?page=com.atlassian.jira.plugin...
]
Sanne Grinovero edited comment on LOGTOOL-20 at 6/14/11 6:33 PM:
-----------------------------------------------------------------
Hi James, thanks a lot. If that takes more time could you split the issue (or if you
prefer I can open another one?), as having this one solved already would be very nice:
I'm confident that many projects would quickly identify some untested log statement as
we just mass-converted some project to use the new logging and so log statements are
mostly untested even on mature codebases, and when this happens it's quite bad as the
(original) statement is hidden/lost.
was (Author: sannegrinovero):
Hi James, thanks a lot. If that takes more time could you split the issue (or if you
prefer I can open another one?), as having this one solved already would be very nice:
I'm confident that many projects would quickly identify some untested log statement as
we just mass-converted some and so log statements are mostly untested even on mature
codebases, and when this happens it's quite bad as the (original) statement is
hidden/lost.
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
6:05 p.m.
New subject: [JBoss JIRA] Commented: (LOGTOOL-20) Detect parameters being inconsistent with log message template
[
https://issues.jboss.org/browse/LOGTOOL-20?page=com.atlassian.jira.plugin...
]
James Perkins commented on LOGTOOL-20:
--------------------------------------
Hello Sanne,
Yes, I'll be releasing the parameter check minimally check in the next release. If I
don't get to the type validation, I'll create a new JIRA for it.
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
11:01 a.m.
New subject: [JBoss JIRA] Resolved: (LOGTOOL-20) Detect parameters being inconsistent with log message template
[
https://issues.jboss.org/browse/LOGTOOL-20?page=com.atlassian.jira.plugin...
]
James Perkins resolved LOGTOOL-20.
----------------------------------
Resolution: Done
Currently only validating the parameters required for the message and the parameters
available in the method. Moved the validation of parameter types to LOGTOOL-22.
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
11:01 a.m.
New subject: [JBoss JIRA] Closed: (LOGTOOL-20) Detect parameters being inconsistent with log message template
[
https://issues.jboss.org/browse/LOGTOOL-20?page=com.atlassian.jira.plugin...
]
James Perkins closed LOGTOOL-20.
--------------------------------
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
12:19 p.m.
New subject: [JBoss JIRA] Commented: (LOGTOOL-20) Detect parameters being inconsistent with log message template
[
https://issues.jboss.org/browse/LOGTOOL-20?page=com.atlassian.jira.plugin...
]
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
12:44 p.m.
New subject: [JBoss JIRA] Commented: (LOGTOOL-20) Detect parameters being inconsistent with log message template
[
https://issues.jboss.org/browse/LOGTOOL-20?page=com.atlassian.jira.plugin...
]
Sanne Grinovero commented on LOGTOOL-20:
----------------------------------------
I didn't send a pull request as I don't know if the approach is correct: it's
using System.out and it's not aborting the build in case of issues.
But it helped to identify some issues already, so this is what I'm using temporarily:
https://github.com/Sanne/jboss-logging-tools/commit/3069cfa3997a283e92cbb...
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
12:52 p.m.
New subject: [JBoss JIRA] Commented: (LOGTOOL-20) Detect parameters being inconsistent with log message template
[
https://issues.jboss.org/browse/LOGTOOL-20?page=com.atlassian.jira.plugin...
]
James Perkins commented on LOGTOOL-20:
--------------------------------------
Thanks Sanne. I'll throw that code in. The main issue I think though is an invalid
format somewhere in the validation. I'm digging through now trying to find it.
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
1 p.m.
New subject: [JBoss JIRA] Commented: (LOGTOOL-20) Detect parameters being inconsistent with log message template
[
https://issues.jboss.org/browse/LOGTOOL-20?page=com.atlassian.jira.plugin...
]
Sanne Grinovero commented on LOGTOOL-20:
----------------------------------------
FYI, this is the output with my patch: those are clearly invalid messages from Infinispan,
not in your validation. Or feel free to use them as tests.
{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
Format specifier 's' Parameter count does not match for format 'Could not
register object with name: %s (%s)'. Required: 2 Provided: 1
Format specifier 's' Parameter count does not match for format 'Found
WebSphere TransactionManager factory class [%s], but couldn't invoke its static
'getTransactionManager' method'. Required: 1 Provided: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
{quote}
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
1:06 p.m.
New subject: [JBoss JIRA] Commented: (LOGTOOL-20) Detect parameters being inconsistent with log message template
[
https://issues.jboss.org/browse/LOGTOOL-20?page=com.atlassian.jira.plugin...
]
James Perkins commented on LOGTOOL-20:
--------------------------------------
Ah, thanks. I do think I will add that. I did find the cause of the error. I was passing
the invalid strings to a different String.format() and it obviously didn't have the
correct number of arguments. I'm going to try to fix the error and add you change to
be safe. Thanks for the help on this!
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
11:48 a.m.
New subject: [JBoss JIRA] Commented: (LOGTOOL-20) Detect parameters being inconsistent with log message template
[
https://issues.jboss.org/browse/LOGTOOL-20?page=com.atlassian.jira.plugin...
]
James Perkins commented on LOGTOOL-20:
--------------------------------------
Sanne,
While not released or in upstream yet here is a link to the what changed for the fix
https://github.com/jamezp/jboss-logging-tools/commit/7f129cc2da0104c237ef....
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
5517
days inactive
5521
days old
15 comments
3 participants
participants (3)
-
David Lloyd (JIRA) -
James Perkins (JIRA)
-
Sanne Grinovero (JIRA)