Project

General

Profile

Introduction

Being a long-term Eclipse Foundation project Jetty is a Java web server and Java Servlet container providing support for Java Servlet API, HTTP/1.1, HTTP/2, Web Socket and FastCGI. Additionally it provides support for OSGi, JMX, JNDI, JAAS and others.

Golden Code chose Jetty as the HTTP backend as it is easily full-featured and standard based, flexible and extensible, asynchronous, enterprise scalable and has small footprint.

FWD uses Jetty in version 12.0.22.

Integration

Jetty is embedded in the FWD server process. FWD server is fully responsible for its life time. It is initialized and started during FWD server bootstrap and shut down during FWD server tear down. FWD uses the Jetty API.

The main Jetty API class is org.eclipse.jetty.server.Server. It aggregates a thread pool of HTTP request receivers and request handlers. The incoming HTTP requests are dispatched with the receivers and eventually passed to one or more registered handlers. For better illustration see a simple example of an embedded Jetty in a Java process.

public class HelloWorld
extends AbstractHandler
{
    @Override
    public void handle(String target,
                       Request baseRequest,
                       HttpServletRequest request,
                       HttpServletResponse response)
    throws IOException,
           ServletException
    {
        // Declare response encoding and types
        response.setContentType("text/html; charset=utf-8");

        // Declare response status code
        response.setStatus(HttpServletResponse.SC_OK);

        // Write back response
        response.getWriter().println("<h1>Hello World</h1>");

        // Inform Jetty that this request has now been handled
        baseRequest.setHandled(true);
    }

    public static void main(String[] args) 
    throws Exception
    {
        Server server = new Server(8080);
        server.setHandler(new HelloWorld());
        server.start();
        server.join();
    }
}

FWD integrates Jetty in a similar way. It initializes a set of handlers and passes them to a created Server instance.

Handlers are the main integration point in the Jetty API. They implement the "business logic" for every particular request. A handler class is any class implementing the interface org.eclipse.jetty.server.Handler. There are many ready made Jetty API classes implementing various types of handlers. From the simplest ones providing the basic request needs (org.eclipse.jetty.server.handler.AbstractHandler) to the more complex ones like org.eclipse.jetty.server.handler.ContextHandler for handling only a particular subset of the request paths or org.eclipse.jetty.webapp.WebAppContext used to programmatically create a full-featured Java web application. For all the Jetty API details please refer to the Jetty documentation.

Endpoints

There are several built-in services exposed by the embedded Jetty instance. These implement some of the 4GL services to support the converted native applications and also extend the capabilities of the converted applications. FWD also allows deploying any compliant Java web application.

Built-in services

Name Context (base URL path) Handler Class Description
Admin /admin see below FWD administration UI.
Web UI (ChUI) /chui com.goldencode.p2j.main.WebHandler The login page for the character based user interface (FWD client).
Web UI (GUI) /gui com.goldencode.p2j.main.WebHandler The login page for the graphic based user interface (FWD client).
Embedded Web GUI /embedded com.goldencode.p2j.main.EmbeddedPageHandler The login page for FWD client running in embedded mode.
REST /rest com.goldencode.p2j.rest.RestHandler Processes the REST requests and delegates the calls to the mapped service.
SOAP /ws com.goldencode.p2j.soap.SoapHandler Processes SOAP service requests and delegate the calls to the mapped service.
Web Service /web com.goldencode.p2j.main.WebServiceHandler Processes the HTTP requests and delegates them to the mapped WebHandler legacy classes.

All the built-in services run on the same port number configured in the directory in the hive adminPort.

Configuration

There are several parameters exposed in the server directory altering the embedded Jetty instance behavior.

Name Type Default Value Description
adminPort integer 9443 The port number Jetty will listen on for the incoming HTTPS requests of all the build-in services.
maxOutputBufferSize integer 1048576 The size in bytes of the output buffer used to aggregate HTTP output.
maxOutputAggregationSize integer 8192 The maximum size in bytes for HTTP output to be aggregated.
maxIdleTimeout integer -1 The idle timeout in ms for I/O operations during the handling of an HTTP request. -1 is interpreted as an infinite timeout.
maxResponseHeaderSize integer 8192 The maximum allowed size in bytes for an HTTP response header.
maxRequestHeaderSize integer 8192 The maximum allowed size in bytes for an HTTP request header.

Security

All the endpoints by default use HTTPS protocol (HTTP over SSL) or can be configured to use HTTPS. FWD supports Conscrypt, Bouncy Castle or the default SSL provider bundled with the Java runtime environment in use.

On top of the channel security protocol all the endpoints integrate with the standard security mechanism provided by FWD server.

The authentication mechanism, which integrates with FWD server security, is implemented in LegacyServiceHandler. Any handler extending this class will also benefit from its security features. These include com.goldencode.p2j.rest.RestHandler, com.goldencode.p2j.soap.SoapHandler and com.goldencode.p2j.main.WebServiceHandler.

If authentication is enabled for the particular handler in server directory (see below the list of security related directory parameters) LegacyServiceHandler will authenticate all the requests in its handle method. It passes the request to one of the subclasses of com.goldencode.p2j.main.WebServiceAuth. Each subclass implements a single authentication mechanism. Currently only BasicAuth is implemented where the client of the service must pass the authentication credentials. BasicAuth uses the credentials and passes them to SecurityManager.authWebRequest. authWebRequest checks the credentials and if it finds a match it considers the request authenticated (the caller successfully identified). In the second step BasicAuth does an authorization of the request by the call to SecurityManager.createWebRequestContext. createWebRequestContext will create an access token, a corresponding security context and will return the access token to BasicAuth. BasicAuth will
check whether the target request is authorized with a call to WebServiceResource and if the authorization is successful stores the access token in the response header. Subsequent requests having this access token will succeed.

Security related directory parameters

Hive Type Default Value Description
<type>/authentication/enabled boolean false When set to true enables authentication on the service.
<type>/authentication/type string "basic" Allows to change the type of authentication. Currently only "basic" is supported.
<type>/authentication/timeout integer 0 Session security context timeout in seconds. After the timeout expires the access token used by the clients of the service and the related security context will no longer be valid. If set to 0 the context will be expired only after an explicit logout.
<type>/authentication/login_path string null The login path recognized by BasicAuth class. Request with this path will authenticate the request.
<type>/authentication/logout_path string "/fwdlogout" Invalidates the access token established during authorization and the related security context.

<type> in the table above can be interpreted as the handler type. It is one of "rest", "soap" and "WebHandler" for RestHandler, SoapHandler and WebServiceHandler classes respectively.


© 2004-2026 Golden Code Development Corporation. ALL RIGHTS RESERVED.