You can use multiple jsp custom labels to achieve the processing effect close to servelt in JSP.

Original
Jsp allows Cainiao to directly write simple web programs (for some netizens), while servlet is less integrated and easy to maintain than jsp. The two cannot be simply replaced in the JAVA/BS system, but the coexistence of the two causes developers to fall into the most common traps in the past two years: you must maintain multiple program modes in a relatively simple project. Obviously, this is a high cost. This article considers and preliminarily tests the use of tag components to continuously complete the processing effect of servlet-like, so as to achieve the goal of both fish and bear's paw, it seems to have a certain effect.
In an environment where servlet is fully used, you can use servlet inheritance to obtain the set attributes of the upper-level servlet. You can also use servlet-chains to achieve classification processing, the whole WEB program is very similar to the actual application system, which is efficient and concise. In the servlet-jsp environment, servlet plays a role in centralized request processing, while jsp is responsible for displaying data picked in various forms. The latter is most troublesome because the numbers and variable processing methods in servlet/jsp are inconsistent, adding a lot of original work. Strutsr actionmapping solves this problem to some extent, but the solution is not too thorough. Therefore, the convenience of using servlet/jsp in large java BS applications will be offset to some extent by the inconsistency of such variables. After all, maintaining the two solutions is costly.
For this reason, I used to simply use servlet in the past, and I wrote a program to explain the nested html compiled by the web engineer to achieve the same purpose as JSP. This solution was effective before year 34, but today SUN chose JSP as the main development body, including JTL, TAG technology, and even jsdk1. The cacheResutlSet in step 5 is developed for this (I think it is backward) JSP random encoding. Therefore, it is unwise to stick to the servlet path alone, (See my article "choosing JSP as BS development direction is likely to be a fatal strategic mistake"). However, the same question won't disappear because SUN chose JSP: if JSP is fully used, SERVLET must be used for data submission and processing to simplify the processing logic, but it must also bear the negative effects described above.
The struts framework, one of the main JAVA/BS projects supported by SUN, fully reflects the confusions and trade-offs caused by this contradiction: struts-action/actionmapping is designed to overcome the preceding JSP deficiencies. It is hoped that both the fish and the bear's paw can be used to reduce the number of servelt programming by using ActionServlet. However, while the problem cannot be completely solved, developers must adopt one more framework for the purpose that this is not the requirement of the subject. To a certain extent, it is actually a failure.
If the above logic is true, just as I chose servlet a few years ago, now that I have chosen jsp as the main solution, I should consider completely abandoning servelt so that I can process the project with a set of solutions, avoid additional costs caused by maintaining two sets of systems. However, as everyone pointed out several years ago, JSP lacks effective code management methods and is not easy to form a basic framework system like servlet, in this way, it is no different from a simple web application such as ASP/PHP. The introduction of javabean (component, not a simple object-based data) can improve this situation to some extent. However, javabean lacks unified call specifications, however, such JSP is more troublesome than pure servelt development.