I have created a war file of birt-runtime-4.12.0-20221128 as in the instructions for POJO deploymnet. I am running weblogic 14.1.1 and I can successfully deploy it. Weblogic is running Java Version: 1.8.0_331. Is this sufficient?
When I browse to the following path: http://localhost:7001/birt/index.jsp
I get the following error: Error 404--Not Found
Any suggestions on how to make it work?
I tried building it many times and many ways and this is the only way that it successfully deployed but doesnt work.
Sorry, but BIRT 4.12 needs Java >= 11.
Related
I've gone through the steps at the below link to create a spring boot demo app and deploy to heroku, but I am getting an exception when pushing to heroku:
https://devcenter.heroku.com/articles/deploying-spring-boot-apps-to-heroku
The short exception is:
Could not resolve org.springframework.boot:spring-boot-gradle-plugin:3.0.2.
Any idea what's going on?
Found the answer. The error references java 8 some lines down. It turns out heroku configures java 8 by default. To change the java version, follow the steps here:
https://devcenter.heroku.com/articles/java-support#specifying-a-java-version
Basically, add a system.properties file to your project base directory and add:
java.runtime.version=17
To configure java 17.
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.
I'm working on a springboot 1.5.1 application that I'm trying to load a WSDL included in my resources directory in the wsdl directory. Depending on where my application executes I'm getting different results (command line, intellij, cloud foundry) and I can't seem to get all three to work at the same time.
I've tried several ways of locating the resource:
From prior to the migration to springboot we had this (worked in IntelliJ but not java -jar myboot.jar):
this.getClass().getResource("/wsdl/my.wsdl");
I switched it to the typically more correct version and got it to work in IntelliJ and java -jar but not Cloud Foundry:
this.getClass().getClassLoader().getResource("/wsdl/my.wsdl");
I switched it to use the Spring Resource Loader version and it worked in IntelliJ and CloudFoundry but not java -jar:
#Value("classpath:/wsdl/my.wsdl")
private Resource wsdlResource;
wsdlResource.getURL();
On the command line what I've noticed is that it seems to be thinking that BOOT-INF/classes is a JAR file (Note the ! after classes):
Caused by: javax.xml.ws.WebServiceException: Failed to access the WSDL at: jar:file:/C:/dev/redacted/build/libs/redacted.jar!/BOOT-INF/classes!/wsdl/my.wsdl. It failed with:
JAR entry BOOT-INF/classes!/wsdl/my.wsdl not found in C:\dev\redacted\build\libs\redacted.jar.
From looking at IntelliJ's URL, it's referring to the actual source folder which explains why it seems to always work.
What is causing this and how might I universally load these class path resources successfully with springboot?
I'm using the mule-maven-plugin as explained here: https://docs.mulesoft.com/mule-user-guide/v/3.7/mule-maven-plugin#running-integration-tests , using "mvn deploy" will donwload the mule 3.7.2 to the target folder but standalone won't fire up, instead it throws this error
The Mule Enterprise Edition service was launched, but failed to start.
If i manually trigger the mule.bat everything works as expected and standalone is able to run the projects on the app/ folder.
Logs: https://drive.google.com/folderview?id=0B-RSwLHJZLJqckJESVJpMEJqeUU&usp=sharing
Carlos, I see a couple of thigs in the logs:
Unable to install the Mule Enterprise Edition service - El servicio especificado ya existe. (0x431)
Probably you already have a Mule service running, can you try stopping it before running the plugin?
[INFO] Using MULE_HOME: C:\cygwin64\home\Carlos Parra\workspace\mule\dummy-project\target\mule-enterprise-standalone-3.7.2
If (1) doesn't solve the problem can you try to use a directory without spaces?
Please tell me if this works.
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.