Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to troubleshoot problems that cannot be accessed by Spring-boot JSP pages

2025-02-28 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >

Share

Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about how to troubleshoot the problems that can not be accessed on the Spring-boot JSP page. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

The Spring-boot JSP page cannot be accessed for troubleshooting

Some time ago, I encountered a problem during the replacement of the company's project framework. The company project originally used springMVC, but did not use spring-boot, but encountered some problems when it was replaced by spring-boot. Spring-boot can package the project as an executable jar/war package, and for web projects, embedded tomcat can be used instead of tomcat, which can also be directly executed without being deployed to an external tomcat container. And that's what went wrong.

problem

Because the previous projects I worked on were separated from the front and back ends, and this project required JSP, the problem occurred, that is, the JSP page could not be accessed.

Preliminary investigation

First, to find information from the Internet, the most important thing is to add the following configuration

Spring.mvc.view.suffix=.jspspring.mvc.view.prefix=/WEB-INF/jsp/

But I already have the configuration in the project, and my colleague can run it after packing, and I run it as a main method directly in IDE (the IDE I use is IDEA). Does it have anything to do with this? I packaged the project locally, and after running it, I found that the JSP page is accessible, while when running in IDE, although the JSP page cannot be accessed, the interface can be accessed normally. It seems that the problem lies in the project running in IDEA.

Source code analysis

Preliminary positioning of source code

After preliminary investigation, the problem has been located, it is in the mode of operation, when running in IDEA, the JSP page will report 404, and the error indicates that the program did not find the JSP page, so why can't you find the JSP page? If you want to know the answer to this question, you need to know how to find the embedded tomcat in spring-boot, so how does the embedded container in spring-boot know where the JSP page is located? By looking at API, we found the void setDocumentRoot (File documentRoot) method in the org.springframework.boot.context.embedded.ConfigurableEmbeddedServletContainer interface. From the description of this method, we can see that the root directory of static resources is set by this method. As long as you set this method, you can let the container find static resources, including JSP, but the question is why the JSP page can find it when packaging. What if you can't find it when you run it in IDEA without packaging? It seems that you also need to take a closer look at how the program locates documentRoot when it is not set up.

Drill down into the source code

From the above analysis, it can be concluded that users can set documentRoot themselves, and if they do not set up the program, they can use the default value, but how do you get the default value of the program? It must be difficult to find the source code a little bit, but since the user can set it through the setDocumentRoot method, when the program determines documentRoot, it must first determine whether the value has been set. Now the problem is very simple. We only need to find out where the set documentRoot is called to find out how the program generates the default value when the value is empty, by looking at the source code method call relationship. It was soon found that there was only one place where the value was used, that is,

Org.springframework.boot.context.embedded.AbstractEmbeddedServletContainerFactory 's getValidDocumentRoot method, which is as follows: File file = getDocumentRoot (); / / If document root not explicitly set see if we are running from a war archivefile = file! = null? File: getWarFileDocumentRoot (); / / If not a war archive maybe it is an exploded warfile = file! = null? File: getExplodedWarFileDocumentRoot (); / / Or maybe there is a document root in a well-known locationfile = file! = null? File: getCommonDocumentRoot (); if (file = = null & & this.logger.isDebugEnabled ()) {this.logger.debug ("None of the document roots" + Arrays.asList (COMMON_DOC_ROOTS) + "point to a directory and will be ignored.");} else if (this.logger.isDebugEnabled ()) {this.logger.debug ("Document root:" + file);} return file

The first line is to get the documentRoot set by the user, and when the value is null, the getWarFileDocumentRoot method is called to determine whether it is currently running in the form of a war package, which is why it can be found by running the JSP page after being packaged into a war package, and if not, it will determine whether the war package is currently unzipped and run. This method will get the location of the class, which exists in the jar package of spring-boot when running in IDEA. The jar package is in the maven local cache, and the maven local cache is different from the project's workspace, so the path you get is naturally the wrong path, which is why you can find the JSP page after packaging and cannot find the JSP page when running with the main method in IDEA directly.

Solve the problem

Solution

Now that the problem has been found, the solution is simple. You only need to determine whether the main method is running directly in IDE, as follows:

/ * * doc-root * / private static final String DEFAULT_DOC_ROOT = Thread.currentThread () .getContextClassLoader () .getResource ("") .getFile () under classpath; / * * doc-root * / private static final String LOCAL_DOC_ROOT = DEFAULT_DOC_ROOT.replace ("target/classes", "src/main/webapp") of the local workspace / * this method takes effect when the user runs the system in IDE * * @ return doc-root * / public static File getIDEDocumentRoot () {File docRoot = new File (LOCAL_DOC_ROOT); if (docRoot.exists ()) {log.debug ("currently running in IDE and workspace found"); return docRoot } else if ((docRoot = new File (DEFAULT_DOC_ROOT)) .exists () {log.debug ("currently running in IDE, no workspace found, but found doc-root under classpath"); return docRoot;} else {log.debug ("not currently running in IDE"); return null;}}

The above method returns documentRoot when running in IDE, but not after packaging. With this method, you only need to get the ConfigurableEmbeddedServletContainer in the current context when the spring container is initialized, and then call the setDocumentRoot method to set the documentRoot obtained by the above method, so that documentRoot can find it correctly when the program runs directly as the main method in IDE, and when it is packaged, the getIDEDocumentRoot method will return null. Although the setDocumentRoot method is called at this point, because null is set, subsequent programs will still look for the default documentRoot, so that JSP can also find it.

Detailed description

In the above getIDEDocumentRoot method, you can see that the LOCAL_DOC_ROOT is found first, and the DEFAULT_DOC_ROOT is found only when it cannot be found. This is because static resources do not need to be compiled (JSP can also be dynamically compiled and loaded at run time), and most programs are being debugged when running directly with the main method in IDE, while debugging of static resources such as JSP is very troublesome, because the default DEFAULT_DOC_ROOT points to the current classpath at this time. Run in IDE without restarting, even if the source file modifies something in classpath, generally speaking, it will not be modified immediately, so when debugging JSP, it will cause a little modification and restart, and if the project is very large or the host configuration is not enough, restart will have to wait a long time, which is not conducive to debugging, so by default these static resources will give priority to them to find the source code path. If you can't find it (the path here is the maven project structure used, the default is that users use maven and use this structure, and if you don't use this directory structure, you won't find it), you're using DEFAULT_DOC_ROOT.

The parameters replaced by JSP dynamic loading are as follows (which have a great impact on performance and are not recommended in production environments):

Server.jsp-servlet.init-parameters.development=true above is the editor for you to share how to troubleshoot the problem that the Spring-boot JSP page cannot be accessed, if you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Internet Technology

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report