I am running a simple Maven web application using spring. My project structure is as following
src-main-java
src-main-webapp
My HTML file in the webapp folder. When I do update class and resource in debug mode it updates my Java classes but not my HTML files.
How to fix this?
There is a known issue. You may need disable cache in your view resolver. then it should work just fine.
e.g. resolver.setCacheable(false); for Spring or ThymeLeaf application.
Use exploded artifact which name ends with .war or .ear.
See more here:
IntelliJ hot swapping classes, but not JSF pages
Related
I have written a subclass of Jetty's WebAppClassLoader. I wrote a context XML file to configure the web app context with my classloader, enabled the ext module, and added my classloaders to $JETTY_BASE/lib/ext. This all works when I run my program outside of IntelliJ.
What I need to do though is run my program within IntelliJ. I have it working with the Jetty maven plugin, but this is not ideal because it forces the maven build to run each time I want to start the program which is quite slow.
As far as I can tell the only thing preventing this from working is that I can see no way to tell Jetty about my context XML file when I run it through the IntelliJ Jetty Run/Debug configuration.
Is there a way around this problem?
i am using idea ultimate 2020.3
i created a maven web project.
when i changed java or jsp files and choose update class and resources, they can be hot deploy.
however, if i changed files under src/main/resources, e.g. mybatis xml file under src/main/resouces/config/mapper, they cannot be hot deploy.
how can i fix it?
Make sure you are deploying an exploded artifact, see Update applications on application servers
Also make sure the module has configured Web resources (has the Web facet with Web Resource Directories and Source Roots configured:
I have created a Spring Boot Microservice using IntelliJ-Idea and Gradle as the build engine. I have made no changes to the initial Spring Boot configuration. I also have made no modifications to the build.gradle file provided. I built the application using starter.spring.io through IntelliJ-Idea and have the following dependencies:
compile('org.springframework.boot:spring-boot-starter-data-jpa')
compile('org.springframework.boot:spring-boot-devtools')
compile('org.springframework.boot:spring-boot-starter-web')
runtime('org.postgresql:postgresql')
testCompile('org.springframework.boot:spring-boot-starter-test')
The application currently contains 12 classes and 2 interfaces and is a Web Service provider. It runs fine on my system but when I build with Gradle, the Manifest.MF contains no Main-Class entry.
I created a very simple Hello World app and tried several combinations of IDE’s and build tools(Gradle and Maven)
and got the following results:
Interestingly, I was able to produce executable jars in Eclipse which has a separate Runnable JAR Export process.
I'm fairly new to IntelliJ and Gradle. Has anyone see this behavior before? Any ideas what I might be doing wrong in IntelliJ? I have my Hello World project zipped up if anyone needs it.
I took the advise of M. Denium and I did the Gradle build from the Command Line. The jars created were formatted correctly to be executable. Everything worked like a charm. In fact the Main-Class is a Spring Boot class called org.springframework.boot.loader.JarLauncher and the main class for my app was in a property called Start-Class. The IDE totally misses this.
Looks like you will need to include spring boot plugin for gradle - org.springframework.boot:spring-boot-gradle-plugin
More details in the gradle section of the getting started guide
I have built a Spring 3 MVC driven RESTful web service app. I use Maven 2 to manage the application lifecycle including packaging up the WAR for distribution. As part of the end solution, I filter application requests through Apache to handle some of the GET requests for static content. This of course requires that I have several custom configurations in Apache configuration files.
My question is this, I would like to package and version these Apache configurations with ( not inside) the WAR, is there a clean way to do this? (using maven?)
Currently, the configuration changes are just included as installation instructions.
My question is this, I would like to package and version these Apache configurations with (not inside) the WAR, is there a clean way to do this? (using maven?)
I'd put such files in a dedicated module (with a pom packaging) and use the Maven Assembly Plugin to create a .zip archive to be unzipped on the target machine(s) and that would be part of the delivery.
Worked pretty well in the past.
My shop has been running Oracle's Application Server for several years. As such, before we knew better, we have developed a norm of having application config files stored outside of the WAR file and the app-specific config directory is added to each application using an Oracle-specific deployment descriptor. This deployment descriptor allows us to add classpath elements at the application layer rather than having to include all dependencies in the WAR.
Now we are faced with upgrading to WebLogic 10.3 and I need to find an alternative for our applications that depend on external configs.
Is there a way in WebLogic to add external jars or directories to the classloader at the application level? I've found ways to add them to the system classloader, but I'd prefer to add them to the application level to avoid having to re-work the applications beyond modifying deployment descriptors.
Is such a thing possible in WebLogic 10?
After further research, we've learned about WebLogic's Generic File Loading Overrides feature.
This feature allows us to use a Deployment Plan for our application and specify a "config-root" for the application. Within the config-root, we can create a directory called "AppFileOverrides" and override any file in the WEB-INF/classes or WEB-INF/lib directories.
This feature works by injecting a classloader just in front of the Web Application classloader, thus any resource loaded from the classpath will be found in this classloader before anything bundled into the web application archive.
Using this feature, we are able to add configuration files (and in theory, classes) that don't exist in the war file at all. Thus, we are able to mimic the functionality of keeping configuration files outside the war.
Moving forward, I'm encouraging our developers to include the configurations inside the war file, but this will work nicely for legacy apps and for situations where we need to change the configuration for a given deployment target (dev vs production)
External jars can be referenced by deployments using the shared libraries.
Roughly, the external jars should be 'deployed' as libraries. Then they can be referenced from your app's weblogic-application.xml using library-ref descriptors.
refer to this doc.
Though, I dont think you can provide external directories/config files other than by using system classpath.
To my knowledge, this is not possible with Weblogic. External configuration files need indeed to be added to the system classpath. You can tweak a bit the classloader (see filtering and loading order) but there is nothing allowing to add dependencies at the "application level" a la OAS. For this, you'll have to run separated domains if the scenario mentioned above is not an option.