| Lesson 10 | Add-ons for non-servlet servers |
| Objective | Describe the use of add-ons. |
Add-ons for non-servlet Servers
For some developers, there is no choice with respect to which application server you will be using.
If you want to add servlets to an existing site, and you cannot change the server software you are using, there are several options available.
If a Java Developer does not want to pay a premium for a corporate Java Server such as WebLogic or Websphere,
he can select an open source Java Container such as Tomcat 10.
During the "dotcom era" a developer could use an add-on to an existing Web Server, such as Apache JServ to run Java Servlets on the server.
Has this practice been phased out, and do any web servers still make use of this practice?
The practice of using add-ons like **Apache JServ** to enable Java Servlet functionality on a web server has largely been phased out in favor of fully integrated Java Servlet containers such as **Apache Tomcat** or **Jetty**. This transition reflects changes in technology standards, developer needs, and server architecture trends.
Why This Practice Was Phased Out
Are Any Web Servers Still Using This Practice?
Most modern web servers no longer rely on add-ons to support Java Servlets directly. However, there are scenarios where integration still exists in specific contexts:
Conclusion: The practice of using add-ons like Apache JServ is obsolete. Developers now rely on servlet containers (Tomcat, Jetty, etc.) or application servers (WildFly, Payara) for Java web applications. While some web servers act as front-end proxies to servlet containers, the direct add-on model is no longer relevant in contemporary web development.
Why This Practice Was Phased Out
-
Integration of Servlet Containers:
- Over time, servlet containers like Tomcat and Jetty became standard for running Java web applications. They integrated the Servlet API, JSP, and other Java EE features in a lightweight, standalone manner, eliminating the need for additional modules like Apache JServ.
-
Advancements in Java EE:
- The evolution of Java EE (now Jakarta EE) provided standardized, robust, and feature-complete implementations for building and running Java-based web applications, reducing reliance on external add-ons.
-
Performance and Scalability:
- Dedicated servlet containers are optimized for performance and scalability. They handle Java-specific tasks more efficiently than general-purpose web servers augmented with add-ons.
-
Ease of Deployment:
- With dedicated Java application servers or servlet containers, developers gained simplified deployment using WAR (Web Application Archive) files. This was more straightforward than configuring an add-on module for a general-purpose web server.
-
Security and Maintenance:
- Over time, maintaining the security and compatibility of add-ons like Apache JServ became challenging. Integrated solutions like Tomcat provided better support, regular updates, and security patches.
Are Any Web Servers Still Using This Practice?
Most modern web servers no longer rely on add-ons to support Java Servlets directly. However, there are scenarios where integration still exists in specific contexts:
Conclusion: The practice of using add-ons like Apache JServ is obsolete. Developers now rely on servlet containers (Tomcat, Jetty, etc.) or application servers (WildFly, Payara) for Java web applications. While some web servers act as front-end proxies to servlet containers, the direct add-on model is no longer relevant in contemporary web development.
What were add-ons?
Using an add-on meant that you did not have to convince someone else in your company to leave the Web server they are using now. You could stay with the same hosting provider, or host parts of your Web site on different servers. You would just add servlets to what you are using now. Some common Java Servlet add-ons which existed during the dotcom era are listed below.
Using an add-on meant that you did not have to convince someone else in your company to leave the Web server they are using now. You could stay with the same hosting provider, or host parts of your Web site on different servers. You would just add servlets to what you are using now. Some common Java Servlet add-ons which existed during the dotcom era are listed below.
Add-on Servlet Engines
An add-on servlet engine functions as a plug-in to an existing server. The add-on servlet adds servlet support to a server that was not originally designed with servlets in mind. Add-on servlet engines have been written for many servers including Apache, Netscape's FastTrack Server and Enterprise Server, Microsoft's Internet Information Server and Personal Web Server, and Apple's AppleShare IP. This type of engine acts as a stopgap solution until a future server release incorporates servlet support.
A plug-in also can be used with a server that provides a poor or outdated servlet implementation. Some common Add-on servlet engines are described below.
A plug-in also can be used with a server that provides a poor or outdated servlet implementation. Some common Add-on servlet engines are described below.
- Macromedia's JRun as a Servlet Container and Java Server has been sunset. Adobe Systems announced the discontinuation of sales and new feature development for JRun on August 3, 2007. Although Adobe continued to provide updates for its underlying Java engine for ColdFusion up to version 9, JRun was officially replaced by Apache Tomcat starting with ColdFusion 10.
- As of the most recent information available, New Atlanta's ServletExec has not been explicitly declared as deprecated, but there are strong indications that it has been discontinued or at least not actively maintained since around 2007. The last significant news or release update from New Atlanta regarding ServletExec was in 2005, and there have been no recent mentions of updates, new versions, or active development on their official website or forums. No current news or updates are available from New Atlanta's official site or product forums since the early 2000s, suggesting a lack of ongoing development or support.
The technical documentation and download links available are from 2012 or earlier, indicating that the software has not seen updates for a considerable time.
Security issues were identified and reported in 2010, and there's no record of patches or updates being released after that date.
Given these points, although there isn't an official "deprecation" statement, in practical terms, ServletExec can be considered deprecated or at least no longer supported for modern use, especially considering the evolution of web technologies and security standards since then. If you require up-to-date Java servlet container functionality, you would typically look at more actively maintained solutions like Apache Tomcat or Jetty.
What was Apache JServ?
There are some non-trivial overhead to parsing http headers on requests and creating them on responses. If you are fronting your app server with a web proxy server, (AJP) Apache JServ Protocol allows you to skip that extra parsing and just pass efficient binary representations of the headers between the proxy server and the app server.
The Apache JServ Protocol (AJP) is a binary protocol that can proxy inbound requests from a web server through to an application server that sits behind the web server. It also supports some monitoring since the web server can ping the application server. Web implementors typically use (AJP) Apache JServ Protocol in a load-balanced deployment where one or more front-end web servers feed requests into one or more application servers.
Sessions are redirected to the correct application server using a routing mechanism wherein each application server instance gets a name (called a route). In this scenario the web server functions as a reverse proxy for the application server.
The Apache JServ Protocol (AJP) is a binary protocol that can proxy inbound requests from a web server through to an application server that sits behind the web server. It also supports some monitoring since the web server can ping the application server. Web implementors typically use (AJP) Apache JServ Protocol in a load-balanced deployment where one or more front-end web servers feed requests into one or more application servers.
Sessions are redirected to the correct application server using a routing mechanism wherein each application server instance gets a name (called a route). In this scenario the web server functions as a reverse proxy for the application server.