I am trying to set up debugging by this article:
https://www.jetbrains.com/help/idea/run-and-debug-a-spring-boot-application-using-docker-compose.html#35ea56fc
it works for me on the application from the article but does not work on real application.
I have noticed the difference is - in real application there is no target directory.
But in the article there is a line:
java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005 -Djava.security.egd=file:/dev/./urandom -jar /project/target/demo-0.0.1-SNAPSHOT.jar
so I assume it expects target directory. I do not see the demo-0.0.1-SNAPSHOT.jar file in the demo application. Is it created temporarily and deleted?
I see there is no target directory in the repository so something creates it - what? https://github.com/IdeaUJetBrains/SpringBootDockerDemoDebug
And probably this might be one of reasons why code does not stop at breakpoints?
And also how it works at all? Why there is project directory before target directory but project directory is not created and it still works in demo application?
Related
I'm working on small web app and I want to serve static files. I'm using application plugin. Part of it is distribution plugin which copies src/main/dist files into distribution zip. Running application with gradlew run uses project dir as working directory. For this reason static files are not found.
Is there a simple way to change working directory for run task?
Is there any other recommended structure for web app gradle project setup?
I have had a similar case when running './gradlew run' of a Kotlin (console) app. The default working directory is the application directory, but IntelliJ uses the root project directory by default.
I have managed to change the working directory by setting the workingDir property of the run task. The list of properties can be found on https://docs.gradle.org/current/dsl/org.gradle.api.tasks.Exec.html
application {
mainClass.set("myproject.HelloKt")
// Change the working directory for the run task. Here is an example:
tasks.run.get().workingDir = rootProject.projectDir
}
You need to add the following to your build.gradle file to modify the working directory of a gradle task.
File runningDir = new File('build/run/')
runningDir.mkdirs()
tasks.run.workingDir = runningDir
Check this thread for reference.
I'm trying to configure a SQLite database for an Spring Web App. The thing is that I'm not able to reach the database file that I've created in src/main/resources using a relative path.
I've tried several configurations for the jdbc url but none of them worked:
jdbc:sqlite:mydb.sqlite (here I changed the file location to the project root)
jdbc:sqlite:${jdbc.url} (here I passed the url as a parameter thru PropertyPlaceholderConfigurer)
jdbc:sqlite:src/main/resources/mydb.sqlite
A weird thing that I realized about is that the app is using Eclipse's directory as the directory to find the database file. I mean, when I put jdbc:sqlite:mydb.sqlite it creates an mydb.sqlite on Eclipse's directory not in project's root.
Check the JVM system property named "user.dir" and set the path relative to it. It is the "current dir" of your java app. It can be different if you run from eclipse or from cmd line or inside webserver(tomcat).
So, System.getPropery("user.dir") will tell you current dir of your running app. Set the path to db relative to that directory.
I would say eclipse does not run your app from the project dir, as it should by default. Check your "run" settings in the eclipse.
I am running jboss 7.1, maven 3, and a java ee6 application that generates an .ear
I am doing a mvn clean package jboss:as-deployand Jboss-as-maven-plugin 1.5 does its thing--I can view my app using http://localhost:8080...
just fine, but I want to know where the actual .ear is being put.
It is not in my jboss7.../standalone/deployments folder. So where is it? My app is obviously running in jboss 7.1 just fine, but I can't find the .ear file. I know that there is an .ear in Eclipse's 'target' directory, but that wasn't produced by jboss-as-maven-plugin is it? I hope you can understand my confusion--don't all .ear files need to be in the deployments directory? I also do see my .ear file inside my hidden .m2/repository directory, but does this have any interaction with jboss-as-maven-plugin? Maybe there is some hidden sym-linking between my Eclipse project's 'target' directory and the jboss7.1 standalone/deployment directory?
p.s. I am used to using a hard-deploy option with the other plugin jboss-maven that requires you to say jboss:hard-deploy which just copies the .ear to your deployments folder. Then jboss would pick up the new .ear and redeploy automatically. I get the sense that jboss-as-maven-plugin is the preferred plugin so that's why I am bothering.
The jboss-as-maven-plugin uses the deployment API so it doesn't copy the file to the deployments directory for the scanner to pick it up. It deploys just as if you deployed it from the web console or via CLI. The files should be located somewhere in the $JBOSS_HOME/standalone/data/ directory.
You're welcome to open an issue, for a discussion around it at least. I'm not sure how I feel about adding a goal for it, but here isn't the place to discuss that :)
I'm developing my first maven application and now i have this trouble, i performed the following commands
mvn compile
mvn package
mvn jboss-as-deploy
the deploy process ends without errors but in my JBOSS_HOME\standalone\deployments i don't find the .war
why?
Try to set targetDir option (maybe the default is overriden in your environoment?). See http://docs.jboss.org/jbossas/7/plugins/maven/latest/deploy-mojo.html.
The $JBOSS_HOME/standalone/deployments directory is not where deployments are stored. If you look in that directory there is a README file that explains it's what the directory is used for.
The jboss-as-maven-plugin uses the deployment API's to deploy the content to the server. This generally ends up in $JBOSS_HOME/standalone/data/content for a standalone server. Though you really shouldn't be doing anything with files in that directory.
I have an application which uses Equinox as an osgi framework for a while now. Until now I used the system property osgi.install.area to specify where my bundles are like so
${osgi.install.area}/
plugins/
org.eclipse.osgi_3.7.0.v20110613.jar
... my app bundles
Equinox then automatically uses ${osgi.install.area}/configuration as the configuration area.
Everything works fine.
Now I need to move the configuration area out of ${osgi.install.area} because that may be read-only and I thought it was as simple as setting ${osgi.configuration.area} to a suitable path but when I do this the application no longer starts and I have the following stack trace in the logs:
java.lang.IllegalStateException: Unable to acquire application service. Ensure that the org.eclipse.core.runtime bundle is resolved and started (see config.ini).
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:74)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at org.eclipse.core.runtime.adaptor.EclipseStarter.main(EclipseStarter.java:150)
...
The path is used because at that location the log file is created and a directory "org.eclipse.osgi".
Paths to bundles are referenced in my config.ini like so:
osgi.bundles=de.mycomp.app-0.6.0.20121116-1834.jar#start, ...
The error message does not really give a hint where to look. It must be something rather simple but I am rather clueless at the moment.
Thanks in advance,
Robert
I tested changing the configuration area an existing osgi app and it worked, with the following argument below in the .ini file in the root of the install. Are you sure you are setting the config param correctly like this:
-Dosgi.configuration.area=c:\mytest
After doing that and running the app again, it created the folder and a new configuration.
Here is a copy of my .ini file that works, also it's important that osgi params come after and vm args.
-loglevel=trace
-vmargs
-Dosgi.configuration.area=c:\mytest
-Dorg.osgi.service.http.port=8094
-Declipse.ignoreApp=true
-Dosgi.noShutdown=true
-Dequinox.ds.print=true