So I'm running an integration test/spec using configuration for an ActiveMQ in-memory broker.
SomeSpec.groovy:
#SpringApplicationConfiguration(SomeApplication.class)
#WebIntegrationTest(randomPort = true)
class SomeSpec extends Specification {
application.properties
spring.activemq.in-memory=true
spring.activemq.pooled=false
The in memory broker starts up and runs fine when I do gradle test and
also runs fine when used with gradle bootRun at the command line. However when I run inside IntelliJ without explicitly having it run gradle test the in memory broker does not start and the tests fail.
How can I take and advantage of the nice test/spec running features in IntelliJ but still have it initialize the in memory queue properly? I know with Grails you could run with JUnit or Grails. Is there something similar with Spring/SpringBoot so everything starts up properly.
It's probably because your config files are not refreshed under project/out/production/config/ location.
When you run it from cmd line, it takes the latest application.properties, so every thing is fine.
But Idea takes the already compiled config files, and if they are not rebuilt inside Idea then it still loads the load configuration.
Related
First, important note: This is a project in which the Selenium/Cucumber test suite is working. It's working locally for the developers, and it's working in the Tekton environment.
Second: I have an identical IntelliJ environment as the developers. And other Selenium/Cucumber projects are running fine on my local machine.
When a try to run a fresh copy of the project in question locally, none of the tests start. And, there is no error message.
Normally, this will be cause by missing Glue parameters in the Run/Debug configuration, since IntelliJ for some reason often is unable to add these automatically. This is not the case here.
The test runner when I try to start a specific scenario:
Sorry for the language. The tests are all in Norwegian. But I don't think that matters for seeing the problem.
Normally, when there is an actual error regarding the test step - in the case "Gitt jeg er en vanlig søker" - there would be some info to the right of the steps overview. This is now blank, as can be seen. So, the test stes aren't even started.
The run/debug configuration:
e2e.cucumber.felles is the package where the Java file with the first step definition is located. So, that's not the reason.
Any ideas?
I work on a Kotlin-based cloud microservice. From time to time I need to run it in the IntelliJ debugger, but we often accidentally break the "local debug flow". There is no pipeline that checks if the IntelliJ run-configuration and the somewhat complex set of cloud-simulating proxies and mock-servers are in sync with the code base.
I would like to write a script that helps me check if the local debug flow works. The script should do the following:
build the project
start up the "mock cloud"
start the service locally using an IntelliJ run-configuration
run a Postman-collection against the locally running service
I need help with step 3 (and possibly step 1): How can I start the IntelliJ run-configuration via command line? I am using IntelliJ IDEA 2021.2 and MacOS 12.3.1.
There is no built-in way to start a Run Configuration from the command line. Instead, you should execute java/kotlin binary with classpath etc.
For example, for "Application" configuration it is needed to run the command like that:
I have an issue about continuously running Java Flight Recorder to monitor memory usage and other performance statistics of ActiveMQ.
Wrapper configuration file (wrapper.conf) is under this directory with nearside (wrapper, activemq, libwrapper.so) files;
../apache-activemq-5.12.1/bin/linux-x86-64/wrapper.conf
I added the lines below to run JFR;
wrapper.java.additional.13=-XX:+UnlockCommercialFeatures
wrapper.java.additional.14=-XX:+FlightRecorder
wrapper.java.additional.15=-XX:FlightRecorderOptions=defaultrecording=true,disk=true,repository=../jfr/jfrs_%WRAPPER_PID%,settings=profile
wrapper.java.additional.16=-XX:StartFlightRecording=filename=../jfr/jfrs_%WRAPPER_PID%/myrecording.jfr,dumponexit=true,compress=true
When I run wrapper file, expected output 'myrecording.jfr' is generated under specified path in wrapper.conf. But the problem is, I also want it to be happen automatically (without running wrapper file by hand).
What might be the possible solution for that?
I tried to follow the war generation instructions by changing the warName in build.gradle to moqui-plus-runtime.war and running gradle addRuntime and then gradle deployTomcat. There were no errors in the war build and I checked to see that the war file got installed as ROOT. I did not make any other changes (still using MoquiDevConf and I already had other system parameters in MoquiInit.properties.)
When I startup tomcat8, I don't see any errors in the log file and it says that it is loading moqui-plus-runtime, but when I make any request in the browser, the localhost_access... log shows 404 for any request.
Can you tell me what things I might of missed or how I would go about debugging this - there is very little info in the log files other than the 404 messages.
I followed the following steps to deploy to a Tomcat instance on the same machine. This is from memory as my production machine is currently offline for the next couple of weeks.
Edit tomcatHome to point to correct location
I personally run a gradle cleanAll first to remove old WARs etc
Run gradle build
Optionally run gradle loadProduction to load the production database, alternatively you can run java -Dmoqui.conf=conf/MoquiProductionConf.xml -jar moqui-1.5.3.war -load -types=seed,seed-initial so that you can pick which data types you want to load into production etc.
Stop Tomcat from running, probably optional but the next step deletes files & folders from a deployed tomcat instance.
Run gradle addRuntimeTomcat this task adds your runtime and also copies over the completed WAR into the Tomcat webapps directory if you set the location correctly in step 1.
Start Tomcat
Check Tomcat logs for any startup errors
Hope this helps
I am testing CXF REST services in Karaf using Pax Exam. The tests almost always run without a hitch on my machine. When run in Jenkins (under Maven build) they typically fail. The failures seem random and unpredictable. The error I receive during the failure deals with attempt to run a Karaf command. The commands are executed by the following snippet:
def byteArrayOutputStream = new ByteArrayOutputStream();
def printStream = new PrintStream(byteArrayOutputStream);
CommandProcessor commandProcessor = getOsgiService(CommandProcessor.class);
CommandSession commandSession = commandProcessor.createSession(System.in, printStream, System.err);
commandSession.put("APPLICATION", System.getProperty("karaf.name", "root"));
commandSession.put("USER", "karaf");
commandSession.execute(command)
These are the commands I am trying to execute in the tests setup method:
'features:addurl mvn:org.apache.cxf.karaf/apache-cxf/2.7.2/xml/features', 'features:install http', 'features:install cxf'
This is the exception:
org.apache.felix.gogo.runtime.CommandNotFoundException: Command not found: features:addurl
Apparently occasionally Karaf does not start correctly and cannot process these commands. The error like this one happen randomly in different tests on different Karaf commands. On my machine they are more likely to happen if the machine is under load.
What may cause Karaf to behave in such a manner? How to prevent these errors from happening?
Thank you,
Michael
There is is also pax-exam-karaf, it also has a feature installer which is usable from the configuration. If you want to stick to the "manual" installation you shoul make sure the features service is installed beforehand. For example let the service be injected.