JSP debugging in IntelliJ IDEA - debugging

Does anyone know how to debug JSP in IntelliJ IDEA?
When I set breakpoint in my JSP files, those breakpoints never seem to take effect. The debugger never hits them. IDEA seems to think that the breakpoints are valid. I do see a red dot placed to the left of the line where I place my breakpoint.
I read in IntelliJ forum in this post that JSP files need to be under web-inf for debugging to work.
But then I also read that JSP files placed under web-inf won't be directly accessible by the user.
I am not sure who's really right.

For JSP debugging in Intellij there are some configurations that must be in order. The fact that Intellij always allows you to add a breakpoint on a JSP line does not necessarily imply that you’ve configured JSP debugging. In the following I refer to Intellij 8 configuration, w.r.t. previous versions you will need to do similar operations as the concepts are the same.
In order to enable JSP debugging you must do two steps: set a web application configuration in your project and add a web application server configuration.
Web application Configuration: in order to have JSP debugging, you must have a “web” facet in your project structure, pointing to the correct web.xml file. Depending on the kind of web application structure you are using, the facet may be detected automatically by Intellij (go anyway to check what it has done) or you may have to add it manually. Remember in the “Java EE build settings” tab to set as anable “Create web facet exploded directory”; if you don’t want duplications, a trick is just to enable it and point to your already existing directory.
(Web) Application server: Go to “edit configurations”, there you have to add to configurations an application server, not launch the web server as an application like any other. In this way Intellij will be able to intercept JSP calls. In the list of application servers, you should have the default one, Tomcat. Be sure to have a local Tomcat installation before you do this, and point to that when adding the web application server. The last trick is going to the “Deployment” tab and selecting as “Deployment source” the same facet that you configured in the previous step.
The same configuration works if you want to use another web application server, I tested it with the latest Caucho Resin releases and debugging works fine (it didn’t with the previous Intellij and Resin combinations).
If you don’t see Tomcat in the list of available application servers to add, check the plugins in the general Intellij settings pane: in the latest releases, more and more functionality has become “pluggable”, and even very basic functions may be disabled; this plugin is called “Tomcat integration”.
Finally, it is surely not true that JSP files need to be under WEB-INF to be under debugging.

For remote JSP debugging (which also applies to localhost) you'll need to install the JSR45 support plugin. Please note this feature is only supported in the Ultimate edition of IntelliJ, not the community edition.
Go to Preferences > Plugins, search for the JSR45 plugin, and
enable it.
Create a run configuration: Run > Run Configuration > click the + button, and pick JSR45 Compatible Server, and then in the dialog that opens, select Remote, and set server host and port. Setting Application Server: Generic should work fine.
Make sure you set the correct port in Startup/Configuration > Debug.
Open the module settings (F3 on the project folder), and add a Web Facet under Facets, and under Web Resource Directories specify your JSP root folder.
Click the Configuration... button, and select the folders with the beans, classes and libraries that your JSPs depend on.
Now JSP breakpoints should work, provided that you started your server with the proper debug arguments.
If you have a maven project with auto-import enabled then you might want to disable auto-import because every time the auto-import is triggered your library settings will be reset.
Also see:
https://www.jetbrains.com/help/idea/run-debug-configuration-jsr45-compatible-server.html

Anyway, you need to launch the Tomcat in IDEA, not from a remote Tomcat.

Please make sure, that in you tomcat's conf/web.xml suppressSmap is not enabled as support of JSR45 is required by IntelliJ's debugger.
It should look like this:
<init-param>
<param-name>suppressSmap</param-name>
<param-value>false</param-value>
</init-param>
From https://tomcat.apache.org/tomcat-7.0-doc/jasper-howto.html
suppressSmap - Should the generation of SMAP info for JSR45 debugging be suppressed? true or false, default false.

If you are using the Intellij debugger you can get the value of an individual attribute by putting a breakpoint inside JSP and evaluating the expression this.jspContext.request.getAttribute("attributeName").
Note that this may return a Java Object type, and you may have to cast it to the correct type. Also if you launch a remote Tomcat the IDEA won't hit any breakpoints, so you need to launch the Tomcat in debug mode from inside the IDEA.

For the second part of your question ("jsp files placed under web-inf won't be directly accessible by user") that is correct. To allow users to access JSP files in the WEB-INF folder servlet and servlet-mapping entries need to be made in the web.xml file for each JSP page.

Related

url after spring maven deployment

I have a basic question about deployment but I can't seem to find an answer on google...
I am working on a jakarta project and it's the first time I do the deployment.
Since I am using Spring-boot maven, I know there is an embedded tomcat that will launch with the jar.
My issue is, I don't know what url to use to check my project is working...
Before, I used the address http://localhost:9091/contextPath/endpoint, but now, I only get a whiteScreen...
So my question is, what url should I use ? Also, is there something else to do after packaging ?
Thank you for your answers.
EDIT:
Alright, so I tried actuator but that didn't help me...
With /actuator/mappings, I could see that my endpoints are correctly configured but when I use the executable jar, http://localhost:9091/contextPath/endpoint odes not work while it does if I compile with my IDE...
I don't know what url to connect to just to see the index... I'm using a very basic spring framework (boot and mvc) and my IDE is intellij community if this helps anyone
EDIT 2:
I tried to deploy the app on a local Tomcat9 to see if something would change but the connexion is reinitialized everytime I try to deploy a war using the manager, and there was no trace of error in the logs.
I tried using ./mvnw and it did work, endpoint and all, but it implies working with IDE environment
I tried using java (openjdk 13) and it compiled, but i couldn"t acces my own endpoint. I could still access the actuator endpoints so i don't know what to make of it.
Should the url be different depending on whether we are using IDE environment or just the jar?
EDIT 3:
Ok, I think have a lead but I have no idea how to resolve this:
when I began the web part of the application, I created a WEB-INF folder where I put all my jsp. My js and css files were in the resources/static folder. I tried once to put the jsp in the resources folder but it didn't work so I didn't push too hard.
Now, when I unzip the jar, i find my css and js files, but not my jsp.
When I unzip my war file, I have everything, but when I try to deploy it on a separate tomcat server, the connexion resets and I don't know why because nothing is written in the logs.
The issue then becomes:
Right now, I have
└──src
└──main
├──java
├──resources
| ├──static
| | ├──css
| | └──js
| └──template
└──webapp
└──WEB-INF
└──classes
└──jsp
What is the standard tree in intellij with jsp ?
By default Spring Boot apps are on port 8080.
Can you try http://localhost:8080?
Port can be changed in application.properties (or application.yml, application-profile.properties etc.) via server.port property (e.g. server.port=8888).
Ok, I managed to make it work.
I'm going to describe here everything of note that I encountered.
First, when I called my app to the usual url, there was no response (whiteLabel).
I added test logs and i found that I indeed called m controller.
I unzipped the jar and war i produced and came to the conclusion that the issue was architectural. I couldn't use jar, I had to use the war file.
I tried to deploy on a local tomcat server using the manager, but it always resetted the connection, so I took the manual approach - copy pasting the war file in the webapp directory.
Finally, the web pages were accessible in the browser.
Thank you for all the tips given during my research!
`http://endpoint:{PORT}/actuator/health` or `http://endpoint:{PORT}/actuator/status`
it should help but it must require spring-boot-actuator as a dependency in your pom/gradle file.

can spring auto reload changes like grails?

One of the main benefits of grails, which is based on Spring, is that you dont need to rebuild and re-run the entire application (which takes minutes) each time you change a line of code, it just recopiles that one file and auto-loads the changes.
Following this tutorial:
https://spring.io/guides/gs/spring-boot/
To run the app, you have to use the command line and do this outside of intellij:
./gradlew build && java -jar build/libs/gs-spring-boot-0.1.0.jar
If you change a line of code, e.g. in a controller, you have to kill the application, rebuild it and restart it, which takes a while.
I came across something called automatic restart in dev tools. Is this something to do with auto-reloading of changes, and if so, how is it used?
If a class is changed , I am sorry that Spring boot devtools will not just reload that changed classes but it will restart the whole application automatically . But this restart should be faster than the normal cold start based on what the docs said :
The restart technology provided by Spring Boot works by using two
classloaders. Classes that do not change (for example, those from
third-party jars) are loaded into a base classloader. Classes that you
are actively developing are loaded into a restart classloader. When
the application is restarted, the restart classloader is thrown away
and a new one is created. This approach means that application
restarts are typically much faster than “cold starts”, since the base
classloader is already available and populated.
If you need to just reload the changed classes , you may consider to use JRebel which is not free.
To use spring boot devtools , just includes its dependency and then start the application as usual using IDE.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<optional>true</optional>
</dependency>
It will the monitor the classpath folders and then restart the application if there are any changes in these folders.
In case of Eclipse , what you need is to ensure Project ➡️ Build Automatically is selected. Once the source codes are changed , Eclipse will then just compiled that changed sources codes to the classes in the classpath folders automatically which trigger devtools to restart the application.
Based on the #Ken Chan answer but very briefly
For Eclipse - click in the menu "Project" -> select "Build Automatically"
In my case I was running some spring boot server - I had to stop the server, enable "Build Automatically" like on the picture, then start the server again and on every change - the code recompiled.

How to debug a Spring Boot Web Application in STS?

I am new to the Spring Framework and so I started with the Spring Boot projects.
In particular, I took the https://github.com/spring-projects/spring-boot/tree/master/spring-boot-samples/spring-boot-sample-web-secure-jdbc project and modified the pom.xml so that it becomes self contained (replaced spring-boot-samples with spring-boot-starter-parent in the parent->artifactId tag, removed properties node, added in repositories and pluginRepositories from http://docs.spring.io/spring-boot/docs/1.2.2.BUILD-SNAPSHOT/reference/htmlsingle/#getting-started-maven-installation).
I successfully built and ran this application outside of STS first with 'mvn spring-boot:run', then imported the Maven project into STS and it builds and runs there successfully.
I am able debug this application by right-clicking on the project folder and choosing Run->Debug As ...->Spring Boot App and the debugger does stop at the breakpoints I've set in the ApplicationSecurity class methods. However, the browser window does not automatically pop-up in STS nor the system browser (which I expect - is this correct?).
When I browse to localhost (port 8080) using the 'Internal Web Browser' within STS/Eclipse the HTML pages render out but the breakpoints that I've set in the #RequestMapping("/") methods do not get hit (I suspect that this is probably due to the fact that the browser is in a separate process to the debugger).
So, how do I debug #RequestMapping methods within STS - this would help me to understand the Spring framework better.
I have limited knowledge of Eclipse/STS, so could there be a problem with my installation?
You don't need to use the embedded browser to debug a server (the browser is a separate process). If your #RequestMapping breakpoints are not hit then I suspect Spring didn't dispatch to those routes for whatever reason (maybe security?).

File Set Not Configured For The File Intellij IDEA

When I open a Spring configuration files at my application on Intellij IDEA sometimes it says
File Set Not Configured For The File
and gives me a link
Configure File Set
When I click it it says:
MVC dispatcher servlet
Create New File Set
or opens a new window cnd let me check some files.
What happens when I click them and what is this for? I click MVC dispatcher Servlet and check the code but doesn't see any changes.
What it is for?
this is for IDEA to help you out with dependencies between different files.
For example you have "service-spring-config.xml" and "mvc-spring-config.xml", where the MVC config uses some beans from the Service config. If you add these both files to the "File Set", IDEA will know that these two files represent a single application context.
By knowing that, it will help you autocomplete beans in XML + will inform you if something is not resolvable without you having to actually run the app.
I click MVC dispatcher Servlet and check the code but don't see any changes
This is because you only have a single file (for now). Later on, you can add some other configs that use/reference beans from each other => then it'll become REALLY helpful
From IDEA File Sets documentation:
By combining Spring XML configuration files in a file set you tell IntelliJ IDEA that these files are mutually related. In this way you form a common editing context for these configuration files and get all the associated coding assistance.
Spring file sets on IntelliJ are for grouping related files.
IntelliJ could autodetect some of this groups, for example files that are loaded with ContextLoaderListener on web.xml or default files for DispatcherServlet (That seems to be your case)
When IntelliJ asks to configure a File Set for a Spring file, is 'cause IntelliJ couldn't detect a default way to include in a group, for example files that are loaded within the ApplicationContext's constructor Ex:
new ClasspathXmlApplicationContext("somefile.xml","anotherfile.xml");
When file sets are correctly configured IntelliJ could bring many goodies like auto-complete, navigation, validation, dependency graphs and others

Websphere App Server 6.1: Redeploy after web.xml change required?

In WebSphere Application Server 6.1, is it necessary to redeploy the application (WAR/EAR) every time a change is made to a web.xml descriptor file?
Depends on what you refer to by "a change is made to a web.xml descriptor file".
If you made a change to the web.xml file inside your IDE, then obviously this change has to somehow make it to the application server's world. Repackage your WAR file and deploy to WebSphere, for changes to take effect.
If you made a change to the web.xml file inside WebSphere's internal directories (the installedApps directory somewhere underneath the profile) - a practice I'd advise against - then a server restart would be sufficient for the changes to take effect. It goes without saying though, that your changes will disappear next time the application is deployed.

Resources