Java EE - Why are there so few .jsp extensions for public sites?

Question

I read many articles saying that Java EE is the most popular enterprise solution these days. Let's not argue whether this is the most popular or the second most popular or something.

The fact is that I see almost all web pages with the extension, for example .html, .php and .aspx. Why (almost) not. JSP? Why is it so easy to find ASP.NET pages if they should be less popular?

Please, I do not program Java EE (yet), so do not blame me if I am completely mistaken. The answer with patience will be very grateful!

Answer 1

The most common answer to why you don’t see the .jsp extension in URLs is that ( at least with well-developed Java EE sites ) is that JSP pages are never directly accessible. They form templates or extension points associated with the URI and are resolved using some form of controller or filter.

This used to be in the early years (the era of the predecessor), when you published JSP suffix URLs, but nothing more.

Standard Java EE practice now -

• there are all JSP files in WEB-INF (thus their un-referenciable with urls)
• Define one or more controllers that process URL requests.
• define a mapping to each resource set URL (JSP pages for instance)

Then the controller (s) know how to collect all these resources, put them together and spit out the HTTP response for the HTTP request.

The reason for this is to separate the URL from the actual artifacts used to create the resource. If the bookmarking user is on a JSP page, you cannot move it or rename it unless you break your bookmark or submit an HTTP redirect. But if you hide your JSPs, you can manage them at any time without breaking the URL.

This is largely the application of compilation and encapsulation rules to URLs.

For example, imagine you have a URL, / hello.

Then you have header.jsp, footer.jsp and the body.jsp file under WEB-INF (hidden from the public).

When you send an HTTP request for / hello, the controller behind it will do its magic by composing the HTML page using the header, footer, and jsp body pages.

If you need to add a navigation bar on the left (for example, navbar.jsp in the WEB-INF section), you configure your controller to create a new HTML body using navbar.jsp to create a navigation bar.

The URL remains the same even if you added a JSP to its new file.

Another reason for this is information hiding and security . There is no reason to advertise the outside world (or even users within the corporate intranet) about the technology of your web application. If you give the JSP suffix URLs, you tell the world that Java EE is behind the scenes. Even if such knowledge poses no risk, you will never want to do it.

Finally, what happens if you ever want to change technology but don’t want to break existing URLs? You may have a contractual obligation to keep them alive. Separating URLs from specialized file extensions will help to do this.

Hope this helps.

- Change -

Regarding the following statements, I made:

If you need to add a navigation bar on the left (say navbar.jsp under WEB-INF), you configure your controller to create a new body HTML code, using navbar.jsp to create a navigation bar.

The URL remains the same even if you add a new JSP file to your composition.

If you referred directly to JSP files, you could still achieve the same encapsulation (hiding the navigation changes) by specifying a link to the main jsp page link, which in itself is a navigation bar, header and footer JSP components. However, your URL schemes will still be tied to the technology that activates them.

In addition, I forgot to mention this before: what happens if a user accidentally or maliciously accesses a footer or navbar jsp directly? It can be harmless, otherwise it can be. This may need to be resolved, otherwise it may not be so. Regardless of the fact that this is an additional variable that needs to be considered. This is another decision (among many, which will inevitably cause the construction of any complex system), a decision that must be made or which can be made by mistake or ignored by mistake (until an unexpected error occurs).

So, hiding this behind technological agnostic URLs * you delete this variable, this is a design decision outside the table *. This one solution is less to make or worry. So you can imagine this (hiding the JSP behind agnostic URLs) as an architecture solution. And the purpose of architecture is not to multiply the number of ways to create software. On the contrary, its goal is to reduce it, take into account the number of design decisions, reduce permutations and combinations in software (ergo, minimizing cracks due to which errors occur).

Thus, this will be a different angle that may explain the rationale for hiding JSP pages (or any web page template technology).

Answer 2

Most enterprise solutions would be intranets or extranets and would not be open to the public, so you would not know about them.

All this suggests that you have not seen relatively many public websites written using jsp.

Answer 3

JSP has disadvantages, especially with JSF. The latest version of Java EE recommends using facelets with JSF instead of JSP (and the frequent suffix for this is -.jsf). Another common structure is Struts, which use .do as a suffix.

Answer 4

If JSP pages are used directly, they are often mapped to the URLs in the deployment descriptor, hiding this part of the web application implementation, so you cannot say that it is a Java EE-based web application.

(on request) For example, I can write a JSP page and save it in my web application as /mypage.jsp . Then I could define the mapping of the (arbitrary) URL /action.do to this JSP page in my deployment descriptor (web.xml) as follows:

 <servlet> <servlet-name>mypage</servlet-name> <jsp-page>/mypage.jsp</jsp-page> </servlet> <servlet-mapping> <servlet-name>mypage</servlet-name> <url-pattern>/action.do</url-pattern> </servlet-mapping> 

In addition, developers writing Java-based web applications use the Model-View-Controller project, in which requests are sent to Controller servlets that do heavy work (checking request parameters, interacting with other code and services) before sending JSPs to create the response (view) that the user will receive. This way, the incoming request maps to the servlet, not to the JSP directly. Official certification by the Sun Certified Web Component promotes this approach, and uses web frameworks such as Struts and JSF for this approach.

Answer 5

Good Java web development practice usually means not exposing JSP pages directly, but rather using them as the presentation layer underlying the MVC pattern in a device in which they are accessible only from the controller.

The resulting URLs are thus quite universal, which suggests little below.