I am trying to debug a Spring boot project with IntelliJ. Suddenly, my lines do not debug after working for last few years.
It will debug through the class, but when i try to run a method, it will not see the breakpoint. I got an application context message earlier, which I fixed, but its still not working. https://www.jetbrains.com/help/idea/2021.2/spring-support.html#spring-file-set
It will see/execute these lines in the background (like its one another thread), but not will debug/catch the method lines.
#Autowired
public EncounterFacade(SuperbillRepository superbillRepository, EncounterRepository encounterRepository) {
this.superbillRepository = superbillRepository;
this.encounterRepository = encounterRepository;
}
Currently using a Mac system. It was already running Local host port in the background,
Ran npx kill-port 8080 to resolve the issue and it worked.
Related
I finally reached the point where my Elastic Beanstalk Instance / Environment got launched. (Java Corretto 11 Platform) Now it fails starting up the provided .jar file.
In the eb-engine.log file, I am not able to find any more error than this:
2021/05/27 11:36:25.889735 [INFO] Executing instruction: StageJavaApplication
2021/05/27 11:36:25.889871 [ERROR] An error occurred during execution of command [app-deploy] - [StageJavaApplication]. Stop running the command. Error: staging java app failed due to invalid zip file
The jar file is a Spring Boot application built with mvn -B package.
Locally the whole thing starts, but crashes afterwards because of not given environment variables (Expected behaviour).
But it seems AWS is not even starting the application..
Any suggestions on this?
Spring Boot apps run nicely on Elastic Beanstalk. However, you do need to set some variables. For example, have you set server-port variable to 5000?
And as you stated, to successfully use a Service Client, you can set environment variables for your creds. Here is an end to end walkthrough that shows how to successfully put a Spring BOOT app that invokes several AWS Services on Elastic Beanstalk.
Creating your first AWS Java web application
PS - your log file mentions a ZIP file. Be sure to create the JAR properly as discussed in the above example.
Just in case someone arrive here looking for an answer about this guy:
Error: staging java app failed due to invalid zip file
I was renaming my service jar in Gradle, using:
tasks.withType<org.springframework.boot.gradle.tasks.bundling.BootJar> {
archiveFileName.set("service.jar")
launchScript()
}
And ElasticBeanstalk was not happy about the renaming.
When I let it have the default name, then no zip issues and all worked like a charm.
We have a desktop JavaFX application (well, TornadoFX) that downloads an archive, extracts another app from it and launches this app with macOS open command.
Simplified kotlin code looks like:
ProcessBuilder(listOf("open", "/path/to/app.app", "arg")).start()
This has worked for years on older versions of macOS (10.15 and earlier) but now with macOS 11 Big Sur launching the app sometimes succeeds and sometimes fails.
In the mac Console.app following error can be seen:
OSStatus _LSCopyApplicationNodeFromOpenState(LSOpenState *): Returning kLSNoExecutableErr because node is a directory but we failed to register with error -10814
We extended the logic to check if all the files are really there before launching the app, and the files existed.
There is an assumption that maybe Launch Services database is not updated fast enough.
Following ways of trying to log what might be happening, didn't reveal any errors:
lsappinfo listen +all forever
log stream --debug --predicate 'subsystem == "com.apple.coreservices.launchservices"'
Does anybody have a clue if there is a way to avoid this behavior and to be always able to launch the app?
After a lot of research and debugging, what seem to have worked for us, was to force Launch Services to register the app in its database by executing command like:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -f /path/to/app.app
and afterwards we could launch the app.
The idea for such solution was found in this answer.
Attempting to run Appium automation scripts on iOS (simulator) on a Mac Mini (M1 chip, if that's relevant). When I run the tests, they work just fine when the Appium server is started manually (typing "appium" into the terminal and starting it that way). However, when I attempt to start the appium server programmatically, the application under test fails to launch, with the following error:
2021-02-17 03:41:27:256 [W3C] WebDriverAgentRunner-Runner.app (19077) encountered an error (Failed to load the test bundle. If you believe this error represents a bug, please attach the result bundle at /Users/sagolGoru20/Library/Developer/Xcode/DerivedData/WebDriverAgent-gkbkvswlszzhhbevpokpwtrjdxxq/Logs/Test/Test-WebDriverAgentRunner-2021.02.16_22-41-22--0500.xcresult. (Underlying Error: **The bundle “WebDriverAgentRunner” couldn’t be loaded because it doesn’t contain a version for the current architecture. The bundle doesn’t contain a version for the current architecture. Try installing a universal version of the bundle.** dlopen_preflight(/Users/sagolGoru20/Library/Developer/Xcode/DerivedData/WebDriverAgent-gkbkvswlszzhhbevpokpwtrjdxxq/Build/Products/Debug-iphonesimulator/WebDriverAgentRunner-Runner.app/PlugIns/WebDriverAgentRunner.xctest/WebDriverAgentRunner): no suitable image found. Did find:
2021-02-17 03:41:27:256 [W3C] /Users/sagolGoru20/Library/Developer/Xcode/DerivedData/WebDriverAgent-gkbkvswlszzhhbevpokpwtrjdxxq/Build/Products/Debug-iphonesimulator/WebDriverAgentRunner-Runner.app/PlugIns/WebDriverAgentRunner.xctest/WebDriverAgentRunner: mach-o, but wrong architecture))
Here's the full appium log: https://gist.githubusercontent.com/fida10/44344b223874310cf296d38a95d4268f/raw/316855b619129680eeaa6519a446a436d0699cd6/failedLog.txt
I originally thought that this was an issue with xcode or WDA, but if that were the case, the tests would fail no matter how Appium was started, and as mentioned previously, the tests pass perfectly fine when Appium is started manually (via terminal), so it might be an issue with the PATH or environment variables upon execution from Java, not sure though.
Here is the code I am using to start the server programmatically:
HashMap<String, String> environment = new HashMap();
environment.put("PATH", "/usr/local/bin:" + System.getenv("PATH"));
AppiumDriverLocalService server = AppiumDriverLocalService
.buildService(new AppiumServiceBuilder()
.withEnvironment(environment)
.usingDriverExecutable(new File("//opt/homebrew/Cellar/node/15.8.0/bin/node"))
.withAppiumJS(new File("//Users/sagolGoru20/.npm-packages/lib/node_modules/appium/build/lib/main.js"))
.usingAnyFreePort()
.withArgument(GeneralServerFlag.SESSION_OVERRIDE)
.withLogFile(new File("//Users/sagolGoru20/Programming/JavaProjects/MavenProjects/MobileAutomationProjects/firstAppiumProject/appiumLog.txt"))
);
server.start();
As the appium log shows, the server seems to be started fine but then throws the above error, so I think the issue may be with how I'm building the AppiumDriverLocalService object.
I followed this tutorial in building AppiumDriverLocalService: https://appiumpro.com/editions/71-starting-an-appium-server-programmatically-using-appiumservicebuilder
Here is the project code. It's a simple project, I'm just clicking on an "Allow" button (line 26): https://gist.github.com/fida10/bec187a516fc32f907f97725263a7206
When I comment out the AppiumDriverLocalService server object (lines 46 to 58) and instead launch by uncommenting line 60, the test runs properly.
Any help would be greatly appreciated.
Was able to solve it by setting all options under "Build Active Architecture only" to "no", in XCode build settings. Details: https://github.com/appium/java-client/issues/1444#issuecomment-781078298
Hopefully this helps someone trying to run XCUITests on Mac devices with the new M1 chip.
i have this line code in my java program to load openCV
static {
nu.pattern.OpenCV.loadShared();
}
When I first deploy to tomcat hosted on linux server it works fine. But on subsequent redeploys, I get an error message saying the library has already been loaded. I have to shutdown and startup tomcat again to get it to work.
What should I do in this situation?
I can debug a Java application in NetBeans and have debugged other projects in NetBeans. However, when deploying a Singleton in Glassfish and setting a breakpoint on the #PostConstruct annotation I am unable to debug. I have set the target server to debug on and I set the breakpoint where the debugger should debug from and I start the server in debug mode. However, I am still unable to debug in NetBeans. Below is the code:
#Startup
#Singleton
public class Listener {
#PostConstruct
public void init() {
System.out.println("init");
}
}
I set the breakpoint on the System.out.println("init") statement. The steps that I follow are:
1) Build Jar file
2) Start Glassfish server
3) Deploy the Jar file
4) Start the server in Debug mode
5) The "init" is printed in the Console in NetBeans but I am unable to debug.
I have tried attaching a debugger on many different ports, but I either get connection refused or it can't debug.
I am using NetBeans 1.7.2. I have tried the same with other versions of NetBeans but still the same problem.
The above is only a sample code, but there is more code but I am unable to debug. I can't find any solution on Google.
Could you give this a try?
You have to:
Start server in debug mode (when it start's dt_socket port is printed)
Attach debugger Debug -> Attach Debugger...
Set breakpoint
Deploy your app
#PostConstruct is called during deployment, so the order of steps you provided is incorrect, because the code is invoked before you attached to debugger.
Did you try this with eclipse?
As I remember, I had no problem in debugging the #PostConstruct method in eclipse.
On more thing to mention:
- A #Singleton bean lives as long as your application lives on the server... So if you want to debug its #PostConstruct, I would suggest opening the glassfish server console, and using the disable application option from console... until that, the #PostConstruct won't be called, since the bean is container managed...