Java JSP / Servlet Tomcat Server HTTP Output Tools and Persistent file Cache add-in

Link: Strategy of How To use this utility and library set

(not released at this time - experiment - although you can download and try it)

The server source code add-in (DIY) is a set of classes and interfaces to store files indexed as a binary array, and files indexed as Base 64 encoded in persistent machine memory as an object reference.
This allows strategies such as dynamic jsp page base 64 text to image insertion to be sent on the one connection request for the page rather than multiple requests for each resource that is part of the page.

Expires headers for individual images can be managed and set sending the image as raw bytes through a servlet. With this is also the need to adjust time in an acceptable format for internet and NTP protocol.

This modification has been tested minimally in
X64 environment on [ Tomcat 9 and 10 ] , in [ Windows 10 , 7 (x86 / X64) ] WITH [ Oracle JDK 8 , openJDK-11 , openJDK-15 ]

* note: Most of its' development has been in X32 - i586

You can download it and try it. (most recent changes Saturday, 19-12-20 14:35:45 GMT) [ ! * reset all the image and file paths in the project for your (test / dev) machine ]
Link (download ZIP): Ramfiling HTTP tools System     Link (download tar.gz): Linux Netbeans X64Ramfiling HTTP tools (Netbeans Project)
Mild Warning note: The RAMStringB64Array.java class , the RamStringB64.java interface and RamStringB64Extensible.java class now use the "Java core" Base 64 library and the method arguments have changed for the below listed.
The test .war applications were re-loaded of their reference libraries in the IDE and recompiled and were successful.
RamStringB64 interface:
public String convertToStandardB64(int chunklength,String enctostr);
public String convertToUrlSafeB64(String enctostr);
public String convertToStandardB64(int chunklength,byte[] encto);
public String convertToUrlSafeB64(byte[] encto);
public Base64.Encoder newb64EncoderObject(int lineLength, byte[] lineCRLF,boolean uarelSafe);

* note: When the server source has been compiled successfully and you have taken all the jar libraries from the /output/build/lib folder and swapped them into your setup used binary version of Tomcat's /lib folder (after switching it off first), you can open the Netbeansproject projects "RAMFileLoader" and "WebApplication3"(WebApplication3.war must be loaded first to Tomcat before the other application) in either Netbeans 8.3 or Netbeans 12.0 to compile them.

However, to do this also requires obtaining all the .jar libraries in the Tomcat server's /lib folder as "referenced dependencies" for the applications to successfully compile.

On the main project icon in the left panel of the Netbeans IDE , right click on the project icon name and a menu list appears, go to its "properties" and click it and a rectangular interface appears with some tabs along its top, go to the tab that shows a button "add jar files" with a square area showing the computer file structure and navigate it to the Tomcat server /lib folder then click on one of the .jar files, then press "control and A" keys to select all .jars in the /lib.
Do this for both projects each, then the project will not need much organization to compile the .war files to load into the server.

My online docs

Tomcat Server add in Persistent Ready to output (after compiling the server binaries with the add-in) indexed file storage class system for web application and servlet,

Requirements (match for OS and platform system):

Oracle JDK 1.8.0_202       open JDK 11       GraalVM Community 20.3.0       IBM SDK Java

Apache Ant compiler 1.10.9

Apache Tomcat Source code distribution (src)

Other software used with Tomcat:

OpenSSL For windows

OpenSSL Tomcat

Integration to other servers

At present, i have only had enough time to quickly view the wildfly-21.0.1.Final source code, their latest that incorporates JBoss and EJB.
wildfly-21.0.1 does not have the same structure for "Application Context package classes and associate interfaces" internally as the simple Jakarta Tomcat.

wildfly-21.0.1 uses Undertow-io webserver socket API in which the required "initial class to modify" , ServletContextImpl class , is the same location to insert these seven modification class files.
jboss-servlet-api_spec-jboss-servlet-api_4.0_spec-1.0.0.Final is a separate download for source code and is where to modify the source in ServletContext interface to insert methods to signify the override methods for the add-in interfaces as with the present Tomcat version of the same file, in the same package as the ServletContext is the location for the add-in interface files.

Finally, the tricky piece to figure is , the "below add-in code (textarea)" used in Tomcat to initialize the main class files and hook the interfaces into the ServletContext needs to be refitted to the structure of the ServletContextImpl class and its constructor (not actually difficult).

What is difficult is finding ALL classes that implement javax.servlet.ServletContext throughout all the Wildfly containers and adding the three methods to obtain interfaces among the other ServletContext implementation methods in thosee classes.

There remains the requirement to change the base 64 system to a java core library rather than the apache tomcat so it can be inserted into any server source.

WinRAR , i have found excellent for such a purpose with its "find" interface (as you will remember a .jar is actually a zip).
search: find string "implements ServletContext" in *.java (you may need to open each jar and do the search from that level).
Too, the batch file to compile the server will throw errors saying which class (to the effect) ..."class that implements ServletContext does not have overriding method"... in compile failure output.
If there is no output capture file take a look at the present compile ,bat in this add-in Tomcat zip above.

Links for Wildfly re-compile parts:

WildFly 21 final , 22 Beta (and "src")

Undertow io source

Undertow info (old)

jboss-servlet-api_4.0_spec-1.0.0.Final source

Other undertow-io repositories

Wildfly docs

HTTP file output UA cache control, time zoning, time editing and charset text tools

This project started in August 2020.

1. Caches files as persistent binary Arrays (persistent on the JVM object stack) ready for faster throughput handling in a servlet.

2. Caches files as persistent Base 64 encoded Strings (persistent) ready for faster throughput handling in a JSP servlet for <IMG> tags with data src.

3. Has easier handling of constant requested output files in servlet code.

4. Text formatting tools for Locale and charsets (note: usually is UTF-8 in web servers).

5. Integration of commonly used http coding schemes and utility class methods , e.g. Base 64 and URL encoding.

6. HTTP User Agent cookie creation and management for output by server header.

7. HTTP header String and String parts storage array for management for servlet output.

8. HTTP header Strings construction Array (command list array) for HTTP 1.1 CACHE-CONTROL commands.
[ Tomcat has some header systems and filters in its own API : Tomcat Expires Filter ]

9. World Timezone clock construction and handling for UTC and GMT Date-Time specification output formats.

The below table shows a list of classes with their corresponding interface to the right of its name.
One class "UserAgentServedHTTPCookie" does not have an interace but is used as an obtainable separate object
through the "UserAgentServedHTTPCookieManager" interface UAhttpCookie.
User Agent (e.g. Internet browser program) cookies are not quite used the same way server side cookies or server auto-set tracking cookies are used.
This class is oriented to user cookies through JSP and Servlet.

Click on a name to view the API document at present
org.apache.catalina.corejakarta.servlet / javax.servlet
CLASSINTERFACE
RAMfilingHTTPtools.java     src fileRamHttpTools.java     src file
RAMfileArray.java     src fileRamfile.java     src file
RAMStringB64Array.java     src fileRamStringB64.java     src file
UserAgentServedHTTPCookieManager.java     src fileUAhttpCookie.java     src file
UserAgentServedHTTPCookie.java     src file       
RAMfileExtensibleArray.java     src fileRamfileExtensible.java     src file
RAMfileB64ExtensibleArray.java     src fileRamStringB64Extensible.java     src file


The following are the methods that connect the add-in to the Tomcat server source code

Tomcat 9 must use packaging "javax" name in the source code

Tomcat 10 M9 "is a release" , M7 uses "jakarta" not "javax" packaging name in the source code (ALL OK in X64 or X86).

To use the NETBEANS projects with "Tomcat 9 OR earlier" replace all references of "jakarta" package in the source code with the "javax" package name.

The following source code is ready for Apache Tomcat 10

To use in Tomcat 9 or earlier the package name
"jakarta" must be changed to be "javax"

Strategy of How To use this utility and library set

First, there is a huge difference in an X86 capability compared an X64.
An X64 OS-CPU is only limited by "total RAM" quantity, an X86 can only have 1GB of RAM maximum allocated to the server object stack.
This library is some tactical help to the X86 systems but only in the context of a small cheap old second hand P3 or P4 with a fast network card and router for a small business that needs some attachment file serving and may reach connection request quantities that are maximum of the default or actual edited setting in the server.xml .

Perhaps too, such a small business could have videos they wish to stream by a player file segment menu list, such a video is broken to a large number of shorter byte files (with special segmenting software that places the codec in each section) and the player is sent the list of them to the client video player, However, the client may skip to a section of the video on the timeline rather than load the whole video (a good economic bandwidth solution at video serving) , this cancels loading of the segment that was in use so the player finds the matching time point the user set on the player and the appropriate file segment to start to send. Rather than each actual filename, each referenced URL in the player list is to a byte output servlet with the index parameter of the persistent array loaded video file segment to obtain through the Ramfile interface.

Too, the X86 could have problems with connection numbers and complex pages with many images, each image in the one page request is another connection to serve, so use of repeated images readied to embed and show by Base 64 image tag embedding can be obtained for the JSP page from the RamStringB64 interface.
However, if the page has an image or two that is specially updated regularly (such as a company current news page), it would need to be placed into the page with a byte output servlet and sent with an "expires header" to both cache store the image and expre it e.g. in a "week when a new image of the same name is placed into the server".
The use of RamHttpTools interface assists time calculations to be created and the page can compare dates through the java.time API for successive days of setting correct quantity of cache time to count down to renewing the image.
(*note: The set of time tools in RamHttpTools interface is suited for international business sites that database international client logins and forums and can assist with SMTP time)

For anyone wanting to serve files with a dedicated server-machine , the advice would vaguely run to get a m-board with most RAM possible and use an X64 kernal. AFAIK the largest RAM possible on a server board with one CPU is 512GB and with two CPU 1024 GB RAM (year 2020).