Sonarqube MaxPermSize error - sonarqube

Sonarqube software of department, demo and learning.
StartSonar.bat does not start.
Error Log below:
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=160m; support was removed in 8.0
I’m studied the error:
Jira task number:SONAR-5204 this jira status:closed and resolution:fixed will set.
MaxPermSize line in wrapper.conf was romeved.
wrapper.config and sonar.log files click.
Thanks for your help.

You are trying to run SonarQube with a JDK 8, which is not supported (yet). Please revert to a previous version (JDK 7 is perfectly suitable).

I also came across the same error; However, the problem was not about Java version. As I went and looked into the logs, it was found that I copied new version of FindBug library and there was a conflict as two FindBug library existed. Thus, it may be good idea to look into sonar.log file which could be found in sonar_install_directory/logs folder.

Related

How to fix problem 'Unsupported major.minor version 52.0' when trying to start Logstash

I want to start service Logstash in my server, but when I trying to start, I got warning info log. Is it any problem solved for this issue?
All of my setting was same with information as on web, start from configuration on startup.option, jvm.option, logstash.yml and logstash-sample.conf but when I try to start, it thorws below error :
[root#CDS01~/logstash]$./bin/logstash -e warning: ignoring
JAVA_OPTS=-Dsysid=CTAG_WEB_SERVER -DCTAG_CONFIG=/app1/am/cds -server
-Xms2048m -Xmx2048m -XX:MaxPermSize=128m -XX:+UseParNewGC -XX:ParallelGCThreads=2 -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=50; pass JVM parameters via LS_JAVA_OPTS
This issue happens when some of your libraries are compiled using different JRE version, then your running JRE version.
You must be using some incompatible versions of JAR in your application. let me know which version of Logstash and which JDK you are using and any site which you are following to install and run your application?
Please refer this Unsupported major.minor version 52.0 SO question on detailed explanation about it.
Please check the Logstash site for the compatible JDK version based on your version.
Looks like you are using some of the jars which are compiled using JRE 8, while you are using the JRE 7 or lower which are causing the issue, Please refer How to fix java.lang.UnsupportedClassVersionError: Unsupported major.minor version of more information on different class versions of JRE and how to fix this exception.

SonarQube startup Error: log4j2 could not find a logging implementation. Please add log4j2 to the filepath

I resolved this issue, I did it by following the instructions found here:
Elasticsearch installation : Error missing 'server' JVM at ...jvm.dll
I was using SonarQube fine the day before, but today when I tried to start the program I'm getting a error.
I have not changed anything on SonarQube as far as I know, I did made a successful connection with SonarQube to Jenkins. But if I remember correctly, I didn't had to install/change files for SonarQube for this(I just made a project, and generated a user login token for Jenkins). Also, I'm sure I'm using the "vanilla" version of SonarQube.
Download and install Java
Go to
c:/program files/java/jre/bin
and create a folder called "server"
Now go into the
c:/program files/java/jre/bin/client
and copy all data of this folder to
c:/program files/java/jre/bin/Server
updating/reinstalling the target jre (jre-8u181-windows-x64 for sonarqube 6.7.x) resolved this for me
I copied these jar in this route and it worked:
path: sonarqube-6.7/lib
log4j-api
log4j-core
This is a side effect; your have a JRE in your Windows PATH.
You need a JDK in your %PATH% // see previous error log
jvm 1 | Error: missing `server' JVM at `C:\Program Files (x86)\Java\jre1.8.0_191\bin\server\jvm.dll'.
jvm 1 | Please install or use the JRE or JDK that contains these missing components.
Used JDK 15, had same issue
Installed OpenJDK 11 instead (https://jdk.java.net/java-se-ri/11)
opened "[path to sonarqube folder]\conf\wrapper.conf"
replaced "wrapper.java.command=java"
with "wrapper.java.command=C:\Program Files\Java\jdk-11\bin\java.exe"
worked for me.

no matter what i do sonar refused to go beyond Unsupported major.minor version 52.0 in jenkins

I am trying to set up devops and have reached up-to sonarQube integration in jenkins. Now its not moving beyond "Unsupported major.minor version 52.0". I had java 1.8 but i installed 1.7 to remove this error. Still coming. Changed java version (checked in command line as well). JAVA_HOME, PATH, all those variable point to java 1.7. Still coming. I can run analysis on sonarqube server, if i try separately (localhost:9000) but in jenkins it's just refusing to go beyond this message. I am not from java background so i might be missing something obvious. Any help is appreciated
The JVM used to run the job must be >=Java 8. Whether or not you had it installed, the error you're getting indicates that Java 8 wasn't being used by the job.

Having trouble getting started with SonarQube

I installed SonarQube and sonar-runner, and the web server seems to work just fine as I can browse it. I tried to keep things as simple as I could, I put the "sonar-project.properties" file in my project's source folder and gave . as the sonar.sources path. After doing so, the console output reported success and the web page listed my project and last analysis date, but when I went into the "Compare" tool to look at statistics it showed all items as blank, except for issues for which is displayed the number 0.
I edited the sonar-project.properties file to give the full path (instead of a relative current directory path of .) to my project's source code, replacing backslashes with forward slashes, and ran the sonar-runner command again from the command line while the working directory was the path of my source folder. It again reported success and when I reloaded the web page, it gave an updated last analysis date, but again no issues were reported and the statistics were all blank.
I have no idea what I'm doing wrong, the Sonar log only reports the installation and starting of the Windows service, and it doesn't indicate any problems. The StartNTService script starts the service without error, but the StartSonar script reports "jvm 1 | WrapperSimpleApp: Encountered an error running main: org.apache.catalina.LifecycleException: Failed to initialize component [StandardServer[-1]]". I don't know if that's relevant for the way I'm using SonarQube as a Windows service. I'm using pretty much all default configuration except I edited the sonar-runner.properties file by un-commented these lines:
sonar.host.url=http://localhost:9000
...
sonar.sourceEncoding=UTF-8
If anybody can help me figure out how to get this to work, I would greatly appreciate it. I am running Windows XP Pro x64 SP2 and Java 1.7.0_51 (32 bit). On my first attempt I did incorrectly use the 64 bit service install/launch scripts but when the console output indicated it didn't match the JVM architecture, I stopped and uninstalled the service and installed and launched the 32 bit service.
Edit: I'm using Sonarqube version 4.2 and Sonar-runner version 2.3.
By default, SonarQube is packaged with the Java ecosystem (Java, Checkstyle, PMD), but for C/C++ you will have to install one of the plugins that support analysis of these languages.
There is a commercial C++ plugin from SonarSource and a free Community Plugin.

"PWC6345: There is an error in invoking javac." error when using Jetty WTP plugin to deploy a JSP page on Jetty

I'm trying to deploy a JSP-page on Jetty, using the Jetty WTP plugin for Eclipse. But I get the error below. It looks like Jetty can't find javac. Is there any settings I have to do for the Jetty WTP plugin in Eclipse or how do I fix this?
The JSP page works fine if I export my project as a .war-file to jetty\webapps and then start Jetty manually using java -jar start.jar. But it doesn't work if I deploy using the Jetty WTP plugin for Eclipse as described.
I have my JAVA_HOME set to C:\Program Files (x86)\Java\jdk1.7.0_01 and I use Jetty 8.0.4 on Windows 7.
Servlets is working fine with the current setup. Any suggestions on how to solve this for JSP pages?
HTTP ERROR 500
Problem accessing /MyJavaWeb/formProcess. Reason:
PWC6345: There is an error in invoking javac. A full JDK (not just JRE) is required
Caused by:
org.apache.jasper.JasperException: PWC6345: There is an error in invoking javac. A full JDK (not just JRE) is required
at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:92)
at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:378)
at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:119)
at org.apache.jasper.compiler.Jsr199JavaCompiler.compile(Jsr199JavaCompiler.java:208)
at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:384)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:453)
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:625)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:492)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:378)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:558)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:488)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:973)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:417)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:907)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:271)
at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:98)
at com.example.FormProcessServlet.doPost(FormProcessServlet.java:39)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:558)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:488)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:483)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:973)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:417)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:907)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:346)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:442)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:941)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Unknown Source)
As Jan Bartel suggested, from Jetty: How to configure JSP:
by adding the line below in the start.ini-file in Eclipse, it works fine.
-Dorg.apache.jasper.compiler.disablejsr199=true
I too happened to suddenly get the org.apache.jasper.JasperException: PWC6345 with my Eclipse installation and the Jetty Maven Plugin (which I use to start up Jetty from within Eclipse).
The reason was that I updated my JDK installation shortly before. Inside Eclipse, this caused to change the "Installed JRE" to point to a plain JRE installation instead of a full-fledged JDK installation. A JDK installation is needed for Jasper, as Jasper needs javac (which is not provided by JRE).
In my case, the solution was to provide Eclipse with the JDK installation. To do so, select Window -> Preferences -> Java -> Installed JREs. Here, click Add..., then point to your JDK installation (in my case, JRE home should point to C:\Program Files (x86)\Java\jdk1.7.0_17). Click Finish. Then back in the Installed JREs overview, remove the old JRE reference and select the newly added JDK installation.
I got the PWC6345 error when running a webapp with Run-Jetty-Run plugin.
The fix was to change the Execution environments settings in Preferences.
Since I'm using java 7 I needed to change the setting for JavaSE-1.7.
Probably other execution environments will behave similarly.
Window -> Preferences -> Java -> Installed JREs -> Execution environments
Select JavaSE-1.7 on the left -> pick the *jdk*1.7.x_xx on the right hand side
Ok, solved this after a lot of searching around.
Download any jdk and point JAVA_HOME to this jdk.
Inside this jdk folder you will find ./bin and ./jre/bin
Copy the javac from ./bin and paste it in ./jre/bin [remember copy not cut]
Now in eclipse, Run->External-Tools->External-Tools-Configurations, select the build.xml for of your project in the left pane and click on the JRE tab in the right pane.
Click on installed JREs and add the jdk in the previous step.
Once done, select this new JRE (jdk1.6.0_31) as the 'Separate JRE', click on apply at the bottom and run.
This assumes you are doing a jetty:run using ant on eclipse.
Strange because this thread suggests:
The solution was to install the package jdk7-openjdk.
Perhaps this should be added to the list of dependencies (or maybe for jetty, and not solr itself)?
But that doesn't help much on Windows, where the binary for openjdk7 aren't easily available.
(In "OpenJDK availability for Windows OS" comments, eckes mentions having found some openjdk binaries for Windows, as part of the Build b146. However, said releases aren't maintained any more)
The bug report filled by the OP Jonas is closed with a simple reference to the Eclipse wiki page "Jetty/Howto/Configure JSP".
You have planty solutions guys but I thought that it exist a solution better than fix the start.ini
I lived the same problem and then I realize that it may be because I did have a JDK7 for 64bit while I should have a JDK7 for 32.
So I fixed my problem by downloading and use the JDK7 for 32Bit.
Also, you would still need to
Use the JDK and not the JRE
Set your JAVA_HOME
I am running on Windows by the way ...
I have the same problem. When I run where java, the output is:
C:\Windows\System32\java.exe
D:\Program Files\Java\jdk1.7.0_25\bin\java.exe
Of course the first one is incorrect. So my problem lies in the PATH. I can rectify this by either removing the java.exe in the directory C:\Windows\System32\ because I'm sure it's useless, or putting the second entry in front of the first one.
So When encountering this problem, please check your PATH for the jdk. I hope that my problem and my solution is helpful in some way.
I got the PWC6345 error when running jetty-runner 9.2.1 standalone from Windows 7 cmd (or batch file) with Oracle JDK 1.7.0_60, and none of the other suggestions in this or other forums worked. I'll leave my workaround here, in case it helps someone...
After installing the JDK, running 'where java' showed two different java.exe paths, the first being in the Windows system folder, and the second in the JDK folder (which is the one I added to the path manually). Both of these are actually installed by the same JDK installer. The java.exe in the system folder was taking precedence and causing the full JDK to go undetected.
Placing the JDK bin folder (e.g. "C:\Program Files\java\jdk1.7.0_60\bin") on the path before the other system paths fixed the issue.
In addition to updating the JAVA_HOME (see above)...
If you're encountering this error from command line (e.g. starting Jetty server from dos window), check where windows is finding the java.exe:
where java
If windows comes back with a path showing to your jre, then check your PATH. Chances are the %PATH% contains a path pointing to the jre instead of jdk.
if you set environment variable JRE_HOME , please unset or delete it
and start server again .
In liferay 7 : I got this error fixed by changing the runtime environment of the server from jre to jre with jdk
I got this error when deploy war package to our server.
My deploy command is (applied web container you may find):
java -jar jetty-runner.jar --port 8020 xx.war
I write this answer because it confused me almost one day. I tried some methods above but failed.
Finally I found there is only jre on my servers but not full jdk.
$ls /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-2.b11.el7_3.x86_64
jre
I fix it with searching available jdk and install one.
$yum search java | grep 'java-'
$sudo yum install java-1.8.0-openjdk-devel.x86_64
(Notice the -devel)
I added this line to 'eclipse.ini' file which is present inside eclipse folder.
-vm
C:\Program Files\Java\jdk1.8.0_131\bin\javaw.exe
and I also change the JRE path in eclipse
windows -> preferences -> java -> Installed JREs
and provided path upto jdk
C:\Program Files\Java\jdk1.8.0_131
I spent good amount of time on this issue, but it turned out to be very simple. All you have to do is:
choose the JDK instead of JRE while configuring the server runtime!
It worked like a champ, I had this issue with glassFish 4.0

Resources