Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FindBugs Security JSP can conflict with other plugins #67

Closed
vitormcruz opened this issue Nov 25, 2016 · 14 comments
Closed

FindBugs Security JSP can conflict with other plugins #67

vitormcruz opened this issue Nov 25, 2016 · 14 comments

Comments

@vitormcruz
Copy link

For example, in the WEB plugin I can change the file extensions used by it's scanner and put *.jsp. That way, any sonar execution will provide the following alike error:

[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.2:sonar (default-cli) on project testeSonar: Language of file 'src/main/webapp/index.jsp' can not be decided as the file matches patterns of both sonar.lang.patterns.jsp : /.jsp and sonar.lang.patterns.web : /.html,/.xhtml,/.rhtml,/.shtml,/.jsp -> [Help 1]

Problem is that FindBugs Security JSP do not provide an Administration Pane by which I can disable it's scanning, I should be able to choose from WEB plugin or FindBugs Security JSP without having to uninstall the entire Finbugs plugin.

@h3xstream
Copy link
Member

You can change the extensions in the web plugin.

This is a design problem of SonarQube. See: https://jira.sonarsource.com/browse/MMF-145

@h3xstream
Copy link
Member

The FindBugs plugin is also blocked because of this design see #28

@vitormcruz
Copy link
Author

Yes, I know, but I should be able to at least choose which one I want to disable, the way current Findbugs plugin is implemented I can either disable the scanning of jsp from the web plugin or disable the entire findbugs plugin.

This is a real pain of limitation of SonarQube platform.

@h3xstream
Copy link
Member

h3xstream commented Nov 25, 2016

My next big feature for the Sonar integration will be to add options to the plugin.
It should not be to hard to integrated (file suffixes).

@vitormcruz
Copy link
Author

Thanks, that is nice! I also voted up for the SonarQube issue.

@Thg-vinod-anandan
Copy link

Status: CLOSED
Resolution: Fixed
Fix Version/s: 6.3

@h3xstream
Copy link
Member

h3xstream commented Feb 13, 2017

Base on @Thg-vinod-anandan report, I will close this issue. If this is not the case, please let me know. There will be an option in the next version to configure extensions.

@icestari
Copy link

but i get this error @h3xstream
[INFO] SonarQube version: 6.3.0
[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.3.0.603:sonar (default-cli) on project HP: Language of file 'src/main/webapp/newsTemplate/newInfoT.jsp' can not be decided as the file matches patterns of both sonar.lang.patterns.jsp : /.jsp and sonar.lang.patterns.web : **/.html,/.xhtml,**/.rhtml,/*.shtml,/.htm,**/.jsp -> [Help 1]

@Thg-vinod-anandan
Copy link

Please go to Administration --> Web ---> Web - File suffixes and remove .jsp from the file suffixes field then click 'save' ( it's for the SonarQube webplugin , it may results conflict with the findsecbugs plugin).

@icestari
Copy link

icestari commented Apr 1, 2017

Thanks for your advice.
Temporarily I remove the .jsp surffix in findbug. I think SonarQube webplugin is more valuable.

@daneshg
Copy link

daneshg commented Sep 12, 2017

SonarQube version prior to < 6.3 (temporary solution)
sonar.language=web in sonar-project.properties will run only against web profile
same applies with findbug jsp profile also.

@RuralHunter
Copy link

We use Sonar 5.6.6 and it doesn't have "Administration" page. What can I do?

@h3xstream
Copy link
Member

@RuralHunter Edit the extensions for the web plugin.

@Birajpjpt
Copy link

I think this is a problem with Sonar HTML 3.1/3.2 and findbugs 3.9.x as the following error appears during the analysis

java.lang.IllegalArgumentException: Multiple entries with same key: jsp=JSP and jsp=JSP at com.google.common.collect.ImmutableMap.checkNoConflict(ImmutableMap.java:150) at com.google.common.collect.RegularImmutableMap.checkNoConflictInBucket(RegularImmutableMap.java:104) at com.google.common.collect.RegularImmutableMap.<init>(RegularImmutableMap.java:70) at com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:254) at com.google.common.collect.Maps.uniqueIndex(Maps.java:1166) at com.google.common.collect.Maps.uniqueIndex(Maps.java:1140) at org.sonar.server.computation.task.projectanalysis.language.LanguageRepositoryImpl.<init>(LanguageRepositoryImpl.java:46) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.picocontainer.injectors.AbstractInjector.newInstance(AbstractInjector.java:145) at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:342) at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:270) at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:364) at org.picocontainer.injectors.AbstractInjectionFactory$LifecycleAdapter.getComponentInstance(AbstractInjectionFactory.java:56) at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64) at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91) at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:699) at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:647) at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:632) at org.picocontainer.parameters.BasicComponentParameter$1.resolveInstance(BasicComponentParameter.java:118) at org.picocontainer.parameters.ComponentParameter$1.resolveInstance(ComponentParameter.java:136) at org.picocontainer.injectors.SingleMemberInjector.getParameter(SingleMemberInjector.java:78) at org.picocontainer.injectors.ConstructorInjector$CtorAndAdapters.getParameterArguments(ConstructorInjector.java:309) at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:335) at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:270) at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:364) at org.picocontainer.injectors.AbstractInjectionFactory$LifecycleAdapter.getComponentInstance(AbstractInjectionFactory.java:56) at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64) at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91) at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:699) at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:647) at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:678) at org.sonar.core.platform.ComponentContainer.getComponentByType(ComponentContainer.java:265) at org.sonar.server.computation.task.projectanalysis.step.AbstractComputationSteps.lambda$instances$0(AbstractComputationSteps.java:43) at com.google.common.collect.Iterators$8.transform(Iterators.java:799) at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48) at org.sonar.server.computation.task.step.ComputationStepExecutor.executeSteps(ComputationStepExecutor.java:62) at org.sonar.server.computation.task.step.ComputationStepExecutor.execute(ComputationStepExecutor.java:52) at org.sonar.server.computation.task.projectanalysis.taskprocessor.ReportTaskProcessor.process(ReportTaskProcessor.java:73) at org.sonar.ce.taskprocessor.CeWorkerImpl.executeTask(CeWorkerImpl.java:134) at org.sonar.ce.taskprocessor.CeWorkerImpl.findAndProcessTask(CeWorkerImpl.java:97) at org.sonar.ce.taskprocessor.CeWorkerImpl.withCustomizedThreadName(CeWorkerImpl.java:81) at org.sonar.ce.taskprocessor.CeWorkerImpl.call(CeWorkerImpl.java:73) at org.sonar.ce.taskprocessor.CeWorkerImpl.call(CeWorkerImpl.java:43) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)

When I downgraded sonarHTML to 3.0.x, the analysis worked fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants