Unable to highlight file,5731 is not a valid offset for file
zhanghqgit opened this issue · comments
Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.0.1:sonar (default-cli) on project PMS: Unable to analyze file: /Users/zhanghengqiang/workspace/pms/webapp/WEB-INF/classes/config/log4j.properties: Unable to highlight file [moduleKey=com.xiaojiuwo:PMS, relative=webapp/WEB-INF/classes/config/log4j.properties, basedir=/Users/zhanghengqiang/workspace/pms] from offset 5695 to offset 5731: 5731 is not a valid offset for file [moduleKey=com.xiaojiuwo:PMS, relative=webapp/WEB-INF/classes/config/log4j.properties, basedir=/Users/zhanghengqiang/workspace/pms]. Max offset is 5724 -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.0.1:sonar (default-cli) on project PMS: Unable to analyze file: /Users/zhanghengqiang/workspace/pms/webapp/WEB-INF/classes/config/log4j.properties
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
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:116)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Unable to analyze file: /Users/zhanghengqiang/workspace/pms/webapp/WEB-INF/classes/config/log4j.properties
at org.sonarsource.scanner.maven.bootstrap.ExceptionHandling.handle(ExceptionHandling.java:36)
at org.sonarsource.scanner.maven.bootstrap.RunnerBootstrapper.execute(RunnerBootstrapper.java:81)
at org.sonarsource.scanner.maven.SonarQubeMojo.execute(SonarQubeMojo.java:112)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 20 more
Caused by: org.sonar.squidbridge.api.AnalysisException: Unable to analyze file: /Users/zhanghengqiang/workspace/pms/webapp/WEB-INF/classes/config/log4j.properties
at org.sonar.squidbridge.AstScanner.scanFiles(AstScanner.java:127)
at org.sonar.plugins.jproperties.JavaPropertiesSquidSensor.analyse(JavaPropertiesSquidSensor.java:86)
at org.sonar.batch.phases.SensorsExecutor.executeSensor(SensorsExecutor.java:58)
at org.sonar.batch.phases.SensorsExecutor.execute(SensorsExecutor.java:50)
at org.sonar.batch.phases.PhaseExecutor.execute(PhaseExecutor.java:102)
at org.sonar.batch.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:185)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:120)
at org.sonar.batch.scan.ProjectScanContainer.scan(ProjectScanContainer.java:264)
at org.sonar.batch.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:259)
at org.sonar.batch.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:249)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
at org.sonar.batch.scan.ProjectScanContainer.startComponents(ProjectScanContainer.java:127)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:120)
at org.sonar.batch.task.ScanTask.execute(ScanTask.java:55)
at org.sonar.batch.task.TaskContainer.doAfterStart(TaskContainer.java:86)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:120)
at org.sonar.batch.bootstrap.GlobalContainer.executeTask(GlobalContainer.java:122)
at org.sonar.batch.bootstrapper.Batch.executeTask(Batch.java:119)
at org.sonar.runner.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.sonar.runner.impl.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:61)
at com.sun.proxy.$Proxy23.execute(Unknown Source)
at org.sonar.runner.api.EmbeddedRunner.doExecute(EmbeddedRunner.java:274)
at org.sonar.runner.api.EmbeddedRunner.runAnalysis(EmbeddedRunner.java:165)
at org.sonar.runner.api.EmbeddedRunner.runAnalysis(EmbeddedRunner.java:152)
at org.sonarsource.scanner.maven.bootstrap.RunnerBootstrapper.execute(RunnerBootstrapper.java:78)
... 23 more
Caused by: java.lang.IllegalArgumentException: Unable to highlight file [moduleKey=com.xiaojiuwo:PMS, relative=webapp/WEB-INF/classes/config/log4j.properties, basedir=/Users/zhanghengqiang/workspace/pms] from offset 5695 to offset 5731
at org.sonar.api.batch.sensor.highlighting.internal.DefaultHighlighting.highlight(DefaultHighlighting.java:85)
at org.sonar.batch.source.DefaultHighlightable$DefaultHighlightingBuilder.highlight(DefaultHighlightable.java:79)
at org.sonar.jproperties.ast.visitors.SyntaxHighlighterVisitor.visitToken(SyntaxHighlighterVisitor.java:100)
at com.sonar.sslr.impl.ast.AstWalker.visitToken(AstWalker.java:107)
at com.sonar.sslr.impl.ast.AstWalker.visit(AstWalker.java:86)
at com.sonar.sslr.impl.ast.AstWalker.visitChildren(AstWalker.java:99)
at com.sonar.sslr.impl.ast.AstWalker.visit(AstWalker.java:87)
at com.sonar.sslr.impl.ast.AstWalker.walkAndVisit(AstWalker.java:69)
at org.sonar.squidbridge.AstScanner.scanFiles(AstScanner.java:106)
... 53 more
Caused by: java.lang.IllegalArgumentException: 5731 is not a valid offset for file [moduleKey=com.xiaojiuwo:PMS, relative=webapp/WEB-INF/classes/config/log4j.properties, basedir=/Users/zhanghengqiang/workspace/pms]. Max offset is 5724
at org.sonar.api.internal.google.common.base.Preconditions.checkArgument(Preconditions.java:148)
at org.sonar.api.batch.fs.internal.DefaultInputFile.newPointer(DefaultInputFile.java:267)
at org.sonar.api.batch.fs.internal.DefaultInputFile.newRange(DefaultInputFile.java:262)
at org.sonar.api.batch.sensor.highlighting.internal.DefaultHighlighting.highlight(DefaultHighlighting.java:83)
... 61 more
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
sorry, i note your notes after created this issue.
java properties file can only be encoded with iso-8859-1? for some countries, some charactor can not encoded with iso-8859-1, or they intend to use utf-8
sonarqube-5.4
org.sonarsource.scanner.maven:sonar-maven-plugin:3.0.1
maven- 3.2.5
java properties plugin - 1.7
Hi @zhanghqgit, in this case you should use XML properties file that can be encoded in UTF-8: http://docs.oracle.com/javase/8/docs/api/java/util/Properties.html
Because "standard" properties files must be encoded in ISO 8859-1: see also http://docs.oracle.com/javase/8/docs/api/java/util/Properties.html
@racodond seems like the plugin should REPORT this incorrect encoding as an issue rather than crashing the scanner.
As discussed at https://groups.google.com/d/msg/sonarqube/m22M4ABo7jA/6dJRV2RpBAAJ, there's no way to accurately get to know the encoding of a file. Thus I prefer to make the scanner crash when highlighting the file because there's no way to know if the issue really comes from an encoding issue or something else.
Hm, that's unfortunate. I know my properties files are encoded as utf8, so no guessing would be required by the plugin. Even though we know it's not correct, for a variety of reasons we're unable to use the XML type or convert the files to ISO-8859-1.
Would it be unacceptable to allow users to enter an encoding on the Java Properties settings page?
I don't want to (re)introduce the ability to set the encoding because:
- It goes against the Java Properties Standards even if you may have strong reasons to not follow them
- Many corner cases (more or less complex) would have to be supported, such as potential Byte Oder Mark usage in UTF-8 files. I want to keep the plugin simple and maintainable.
Hello and first of all thanks for your hard work.
Since you exposed your point of view on this subject, please agree to let me write mine which I share with a lot of people I've met personaly and on the internet.
Yes the Properties files "standard" clearly tell us to use ISO-8859-1 in properties file we all agree with that.
However let's just be a little bit pramatic :
1 - The world we know count only for 17% native users of ISO-8859-1 (if you consider french is fully supported which isn't the case and if you don't look at the country zone official language)
2 - ISO-8859-1 doesn't support the euro symbol wich is the currency of 21% of earth GDP
3 - XML properties files are a HUGE pain in the @ss to produce and maintain (and i don't speak of the tags overhead)
4 - Using XML UTF-8 escapes entities like told in the "standard" is a ASTRONOMICAL pain in the @ss to produce and maintain
5 - The java team created and explicitly tell you how to use ResourceBundle Control and ControlProvider to tweak your languages files by your needs : https://docs.oracle.com/javase/tutorial/i18n/serviceproviders/resourcebundlecontrolprovider.html
6 - The fact that a majority of users doesn't use UTF-8 properties files isn't to respect a "standard" but simply because they think it is not possible to do othewise
7 - Even the java class file's encoding can be defined ffs !!!
So, as a person whom language isn't fully suported by the defined "standard", wich result in an untold form of SEGREGATIONISM by imposing an harder way of doing things for those that by their culture or native country doesn't fit into it, I will strongly oppose you a "de facto standard" by considering the use of UTF-8 in properties files totally legit and respectuf of people cultural differences.
By such consideration, your decision not to allow people defining the encoding of properties files and making it break the sonar analysis just make it useless for thousands of people like me and on a personal level it also hurts my feelings to see my language specificities just being stomped by a foreign "standard" consideration.
For this reason, and until you agree to review your judgement, our administration will stop using your plugin on our sonar server.
Have a good day.
Best Regards
Y. Savanier
Hi,
Thank you all for your input!
After having discussed with you through this channel and with others through other channels, I created an issue to add the ability to define file encoding in the upcoming version: #35
Hi
First of all thank you for your understanding of our concern.
I'm sorry if my previous message felt like a bit emotionnal. However, while, as a french speaker, my case doesn't seems as critical as zhanghqgit's, I've been hit regulary by this non compliant character encoding nonsense for about all my computer engeener life until UTF-8 sets itself as the only acceptable way of ever storing human readable text.
As for this .properties file encoding problem, it is a remanence of a decision made in the jdk 1.1 back in 1997 while UTF-8 was only standardized in its first version by RFC 2279 in 1998 and since now 19 years it has been a thorn stuck in the java code of non fully latin language speakers though mainwhile even the ISO group maintaining the 8859 parts was disbanded in 2004...
Anyway I'm looking forward your next version with eager anticipation :)
Have a nice day and good luck with your coding.
Best Regards
Y. Savanier
No problem @YSavanier :-)
Feedback is always more than welcome!
Hi all,
A release candidate that fixes your issue is available: https://groups.google.com/d/msg/sonarqube/HIaI_obeWOY/YdZ-gwn1BQAJ
Your feedback is more than welcome!
Thank you