The intention of the solution that I proposed was to solve the problem of:
whitelisting both the IPv4 (127.0.0.1) and the IPv6 (::1) for localhost;
ensuring that Jetty (in the Add-On service) will restart afterwards.
The solution makes use of the configuration files \jetty\etc\jetty-inetaccess.xml and \jetty\etc\jetty-http.xml. For the purposes of the solution, it is not necessary, let alone required, to explicitly enable any Jetty modules. I shall explain why.
A Jetty module consists of the various components that are wired to work together to implement a Jetty feature. For example, the HTTP module consists of the components that are wired to work together to implement an HTTP connection in Jetty. Here the feature is an HTTP connection and the HTTP module provides the HTTP-relevant Java components for host, port, connection-timeout, queue-size, acceptedTcpNoDelay, buffer-size, and so on.
The modules are therefore one level of abstraction higher than the features. Since a module consists of different components wired to work together, the interaction within a module and between modules can be quite complex. Therefore, if you explicitly enable a module, you will have to map out all the possible dependencies within it and between it and other modules. Failure to do so may lead to errors. For example, when Charlie explicitly enabled the InetAccess module prior to testing the solution I had proposed, the file jetty-inetaccess.xml apparently failed to load. There is yet another reason for caution when explicitly enabling Jetty modules: security. Best-practice from modular architecture says:
Explicitly enable only the modules you need. Don't just enable modules out of convenience. Audit your application's requirements and enable only the bare minimum.
When Adobe's ColdFusion engineers integrated Jetty in ColdFusion, they made sure of the following:
all the modules that ColdFusion applications would likely need are enabled;
each enabled module is configured with the appropriate default settings.
This ensures that the ColdFusion developer would rarely have any need to tinker with the modules. After all, it is preferable for the physician to test for the knee-jerk reflex by tapping on the knee, rather than by tinkering with the synapses in the brain. How then would the ColdFusion developer have some control of the implemented Jetty feaures?
Answer: by means of Jetty's XML configuration files! (location: /jetty/etc/)
These XML configuration files ensure that you usually won't need to explicitly enable Jetty modules. For example, my solution uses jetty-inetaccess.xml and jetty-http.xml without needing to explicitly enable Jetty's InetAccess module. The configuration files themselves, jetty-inetaccess.xml and jetty-http.xml, already contain the necessary instructions and configuration settings to enable and use the features provided by the InetAccess module.
When you specify XML configuration files in your Jetty server setup, you are essentially providing the configuration that the module would otherwise provide when explicitly enabled. The ColdFusion Add-On Service's architecture handles the integration of these configuration files, making the explicit module command redundant. In this context, the XML files serve as the primary configuration method, and they inherently pull in the required functionality for the feature or features you wish to implement.
... View more
AdChoices