I am working with a buildr project using IntelliJ IDEA and I want to get JRebel working. This is a Spring MVC project.
I have my rebel.xml configured and I created an ant script to re-package the application:
buildr package test=no
JRebel says it redeployed, but Spring seems to not be running after the redeploy.
The best you could do is to enable JRebel logging by adding -Drebel.log=true to JVM arguments and send the log file to support.
Do you see any messages in console that JRebel is actually started and is monitoring the directories? Maybe the license is missing?
Related
I have a Spring Boot project. I created the following two configurations:
Spring Boot Configuration
JAR Application Configuration
Can someone tell me what is the difference? They both run as expected.
Thank you.
Running via Spring Boot configuration will allow hot swapping of the changes during debugging which is very useful during development as you don't have to rebuild all the files and package the jar on every change.
Jar Application is handy when you want to verify that your production jar works as expected.
I have a java EE 5 project. I'm building a project with maven. I use IntelliJ IDEA 2018.2.5 x64.I use weblogic 12.1.3. In the Department of deployment( edit configuration -> Deployment ) specify the ear file. Why doesn't IDEA put ear file in localhost:port/console -> deployments when running ?
Make sure the Runtime Server is added correctly in IntelliJ. Once Added Correctly,You should see the Application servers Tab, where you could Add/Remove Applications effectively.
The Status of the deployment can be seen as Module with a tick Mark in Application Servers Tab.
The answer was simple, the ear file did not deploy due to the fact that I did not enter the domain name and password in the configuration
I have a IntelliJ Community Edition with Gradle 4.3.1 and com.bmuschko.tomcat plugin running. My application will be deployed currently and its working, now I want to enable JRebel for this. So that changes on my webapp folder will be hot-deployed.
At the plugin site is a description for this
Edit your Gradle startup script and add the following line to it to
tell Gradle to use the JRebel agent. Please make sure to set the
environment variable REBEL_HOME that points to your JRebel
installation directory.
JAVA_OPTS="-javaagent:$REBEL_HOME/jrebel.jar $JAVA_OPTS"
Currenty its not clear for me where do I need to change this? Obiously JRebel is not active when I start my tomcat with the pluging.
What I did:
installed the jrebel plugin in intellij
enabled the jrebel functionality with the ide
manually added a rebel.xml file (as described on the plugin site) in the build/classes/main folder
Where do I need to edit the gradle start up so that jrebel is active for gradle builds?
There are two ways you can run gradle that will affect how to add the arguments, with the daemon and without.
If you run gradle tomcatRun --no-daemon the arguments for JRebel must be added via JAVA_OPTS or GRADLE_OPTS environment variables. So this means either running as GRADLE_OPTS=-agentpath:/path/to/jrebel/lib/libjrebel64.so gradle tomcatRun --no-daemon or specifying the variable in a script(gradlew if you are using it). If you run the gradle task directly from IntelliJ, you can specify environment variables there.
If you run with the daemon, the GRADLE_OPTS variable will set JVM arguments for the launcher process, not the daemon. This will mean that JRebel is included in the wrong process and your changes aren't monitored. One way to set JVM arguments for the daemon is by adding the following to your gradle.properties
org.gradle.jvmargs='-agentpath:/path/to/jrebel/lib/libjrebel64.so'
Running with the daemon will mean that the JRebel banner is not displayed so don't be alarmed as the changes will still be monitored.
Also since JRebel 7.0 the folder structure was changed and the jrebel.jar located in installation root is the new core which requires additional bootstrapping provided by the included native agents in the jrebel/lib dir. It is suggested to use the corresponding native agent for your OS/arch using the agentpath argument and not the javaagent argument as in the tomcat plugin docs.
Today I've install IntelliJ Ultimate version 2016.1.1 build 145.597. What I did later, was import of may project from IntelliJ Community Edition. This project is based on spring-boot 1.3.3. The problem is that when I want to run my application in IntelliJ Ultimate somehow application.properties file is ignored and it starts with default spring settings. When I'm running the same project in IntelliJ Community Edition or from command line everything works fine. Problem exists only in Ultimate edition when I'm adding and running spring boot run configuration, if I use gradle configuration and bootRun task it works.
I didn't use before IntelliJ Ultimate.
Does anyone know what could be wrong? I wasted 2 hours googling for solution of my problem but I didn't find anything.
Content of src/main/resources/application.properties:
server.port=2081
server.ssl.key-store=cfg/certs/keystore.p12
server.ssl.key-store-password=dev
server.ssl.key-alias=alias
server.ssl.key-store-type=PKCS12
spring.datasource.url=jdbc:h2:file:./cfg/db/app;DB_CLOSE_ON_EXIT=FALSE
spring.datasource.driverClassName=org.h2.Driver
spring.datasource.username=sa
spring.datasource.password=
spring.jpa.database-platform=org.hibernate.dialect.H2Dialect
spring.jpa.hibernate.ddl-auto=none
Project structure:
I had same issue for IntelliJ Ultimate 2016.1.1
Reimporting the project and deleting existing project worked for me.
I believe the issue is pertinent with 1.1 version. Didn't had issue with IntelliJ IDEA 2016.1.4
check if file application.properties is directly under target/classess after compiled, maybe the wrong settings copy it to other directory that spring boot cannot know
one simple thing to fix the problem.
If you already open the IntelliJ idea, close the project and remove it from IntelliJ
idea.
navigate to your project directory (ex: F:\dev\my-project) and remove the .idea
folder from it.
then open the IntelliJ idea again. open your project from File -> Open.
then run the project.
this is the simplest solution.
thanks!
I had a similar problem with my spring boot application running from IntelliJ Ultimate Version 2020.3 . I had a Connection.properties configured in spring-config.xml file as below and got the FileNotFoundException for my Connection.properties file even after placing the file under src/main/resources folder in my gradle project
<context:property-placeholder location="file:Connection.properties" />
It worked after changing it to
<context:property-placeholder location="classpath:Connection.properties" />
Note the "file:" to "classpath:" in "location" attribute
I' starting to use ServiceMix and Camel and I've run through many examples.
It seems that the examples that are OSGi can be deployed in ServiceMix via hot deploy or via console, but I don't know how to deploy a project that is not an OSGI. Can it be done?
For example, I'm looking at the example project from Camel 2.10.0 called camel-example-cxf-proxy. I did some alterations and now I wanted to load it in ServiceMix. If I copy/paste to the deploy directory it is loaded but when I try to run it via osgi:start id it fails.
However if I run it from the IDE as a standalone it runs just fine and I can send and receive requests via SoapUI.
When I'm done with the examples I'll want to create my own project in eclipse and do tests in the IDE and in ServiceMix. I don't really understand the advantage of OSGi yet. SO I'm not too compelled to use OSGi for my project.
My main question is: Can I deploy a non-OSGi non-JBI compliant project in servicemix? Something like the camel-example-cxf-proxy. If yes, how can I do it? If no, how can I OSGi-fy the camel-example-cxf-proxy?
Thank you :)
Apache ServiceMix which uses Apache Karaf as its kernel, support pluggable deployment units. Though OSGi is the main unit.
You can deploy JBI artifacts (eg JBI was used as deployment units for Apache ServiceMix 3.x). So we offer that as a migration path to run JBI in SMX 4.x.
A plain WAR file can be deployed as well. You can for example just drop a .war file in the deploy directory. If you deploy from the shell, you need to prefix the deployer with war so it knows to use the war deployer.
There is some documentation about the various pluggable deployers here
http://fusesource.com/docs/esbent/7.0/esb_deploy_osgi/UrlHandlers.html
For example to install an Apache Wicket WAR example using Maven you can do from the shell:
osgi:install war:mvn:org.apache.wicket/wicket-examples/1.4.7/war?Web-ContextPath=wicket
The Apache documentation about deployer is mainly documented at Apache Karaf
http://karaf.apache.org/manual/2.2.9/users-guide/deployer.html
Now to deploy OSGi applications can be a bit of pain to assemble. And that is why FuseSource created FAB to make it much easier. I blogged about this a bit, which references to videos and more material: http://www.davsclaus.com/2012/08/osgi-deployment-made-easy-with-fab.html
With FAB you can just deploy regular Maven projects out of the box without any OSGi pain.
If your project is a maven project, you can try :
mvn install
Then start your servicemix, and in servicemix command line :
install mvn:groupId/artifactId/version
This will prompt a bundle ID. Then, juste start the bundle :
start <bundle_id>
You can check the state of your bundle with command "list"
The project has to be a bundle to be installed in servicemix / karaf. So the steps to make a camel project work in OSGi are the following.
Use the maven bundle plugin in the pom and configure it to import / export the necessary packages if necessary.
Make sure your camel context is defined in a way that OSGi can start. This is either in the activator of the bundle or in a spring config in the right location or with a blueprint config in the right location.
See two of my karaf tutorials for the details:
CXF: http://www.liquid-reality.de/x/EoBk
Camel: http://www.liquid-reality.de/x/G4Bk