jetty upgrade 8 to 9 missing classes

Question

I previously asked this question -> Upgrading Jetty 8 to Jetty 9 which helped for a particular upgrade with some of the missing packages/classes.

I have a slightly older version being upgraded now, and it has packages and classes that are no longer in Jetty, and I cant find any documentation to see what or where/if they have been replaced.

The following no longer exist:

import org.eclipse.jetty.io.Buffer;
import org.eclipse.jetty.util.thread.Timeout;
import org.eclipse.jetty.server.AbstractHttpConnection;

The HttpURI.getCompletePath no longer exists can I use getPath() or getDecodedPath() HttpClient no longer has:

setThreadPool 
setMaxConnectionsPerAddress 
setTimeout 
setRequestHeaderSize 
setResponseHeaderSize

I can use QueuedThreadPool on HttpConfiguration, and most of the above methods are also on HTTPConfiguration, but is setTimeout(httpClient), now setIdleTimeout(HttpConfiguration)?

HttpExchange() no longer has a public default constructor and therefore I cant override it with a default constructor. In the new HttpExchange(9.4) it requires the following three arguments in construtctor:

 HttpDestination destination, HttpRequest request, List<Response.ResponseListener> listeners 

What class are they on now? I only have access to the HttpClient _client, ServletConfig and ServletContext

The following methods no longer exist either:

onResponseContent
onResponseHeaderComplete
onResponseStatus
onResponseHeader
onConnectionFailed
setRequestHeader
exchange.setScheme(HttpScheme.HTTPS.equals(request.getScheme())?HttpScheme.HTTPS_BUFFER:HttpScheme.HTTP_BUFFER);
exchange.setMethod(request.getMethod());
exchange.setURL(url.toString());
exchange.setVersion(request.getProtocol());
addRequestHeader

Is there a replacement for HttpExchange or another class with these methods?

IO.copyThread(InputStream, OutputStream) no longer exists

org.eclipse.jetty.server.RequestRequest no longer has getConnection();

Answer 1

import org.eclipse.jetty.io.Buffer;

Does not exist, we use java.nio.ByteBuffer now.

import org.eclipse.jetty.util.thread.Timeout;

No replacement, idle timeout is handled in-line with the various places that need it.

import org.eclipse.jetty.server.AbstractHttpConnection;

No replacement, the entire Connector layer has been completely rewritten about 6 years ago.

HttpURI.getCompletePath no longer exists can I use getPath() or getDecodedPath()

Use java.net.URI.

The HttpURI of Jetty 9 has no relationship with what you used in Jetty 8.

We use java.net.URI internally for many things, and only use HttpURI to piece together a URI for purposes of HTTP/2 physical connection vs logical channel request.

HttpClient no longer has:

HttpClient was rewritten about 6 years ago to satisfy the updated HTTP/1.1 RFCs, and HTTP/2, and FastCGI, and Proxy usages.

From the types of questions you are asking, you might want to look into the entire extensible proxy layer that Jetty has built-in

setThreadPool

Use setExecutor()

Note: this is not a wise thing to mess around with, especially with the huge differences in connection processing between Jetty 8 and Jetty 9.

A single request can be handled (during its lifetime) from [1..n] threads.

The most common reason stated for messing with the executor (threadpool) is to artificially limit resource utilization. Messing with the executor is the wrong place to limit resource utilization.

setMaxConnectionsPerAddress

Connections are now pooled.

You can choose your connection pool implementation, and also set a few generic connection pool behaviors on the HttpClient.

See setMaxConnectionsPerDestination​ and setMaxRequestsQueuedPerDestination​

setTimeout

There are many timeouts now.

• HttpClient.setIdleTimeout
• HttpClient.setConnectTimeout
• Request.setIdleTimeout
• Connection idle timeout
• Connection pool idle timeout

setRequestHeaderSize setResponseHeaderSize

Does not exist for jetty-client, these are server side concepts.

I can use QueuedThreadPool on HttpConfiguration, and most of the above methods are also on HTTPConfiguration, but is setTimeout(httpClient), now setIdleTimeout(HttpConfiguration)?

HttpClient and HttpConfiguration are unrelated.

HttpExchange() no longer has a public default constructor and therefore I cant override it with a default constructor. In the new HttpExchange(9.4) it requires the following three arguments in construtctor: What class are they on now? I only have access to the HttpClient _client, ServletConfig and ServletContext

The following methods no longer exist either:

onResponseContent onResponseHeaderComplete onResponseStatus onResponseHeader onConnectionFailed setRequestHeader exchange.setScheme(HttpScheme.HTTPS.equals(request.getScheme())?HttpScheme.HTTPS_BUFFER:HttpScheme.HTTP_BUFFER); exchange.setMethod(request.getMethod()); exchange.setURL(url.toString()); exchange.setVersion(request.getProtocol()); addRequestHeader Is there a replacement for HttpExchange or another class with these methods?

HttpExchange is an internal class and is not meant for you to use/access/configure or generally mess with.

I suspect you are looking at an ancient codebase that had an HttpExchange concept for the jetty-client.

That entire concept does not exist for HttpClient anymore in Jetty 9.

You create a org.eclipse.jetty.client.api.Request (see the various HttpClient.newRequest() methods), hook into various listeners on the request, and Request.send() it. Responding to the various listener events that you are interested in.

I would suggest you start with Response.CompleteListener only at first, looking closely at the Result object passed to you in its onComplete(Result) method.

IO.copyThread(InputStream, OutputStream) no longer exists

No longer exists, no replacement (it was the source of many bugs/issues)

org.eclipse.jetty.server.RequestRequest no longer has getConnection();

DANGER WILL ROBINSON - this indicates a seriously bad/dangerous codebase. The codebase that does that should never have existed in the first place.

While there are internal ways to access the connection/endpoint/channel/httpinput/httpoutput/interceptors, all of those concepts have to be taken into account for any hope of success, not just the connection.

Your questions are screaming "I have an old proxy i'm attempting to update". Jetty is now 100% Async, the older InputStream/OutputStream behaviors from Servlet 2.x days are long gone. If you don't develop a proxy solution with Async I/O in mind you are doomed to endless errors/issues/failures until you update it for Servlet 3.1 Async I/O features.

Do yourself a favor and read up on entire org.eclipse.jetty.proxy package.

You'll wind up either extending AsyncProxyServlet (for typical proxy behaviors) or AsyncMiddleManServlet (for proxy with content modification behaviors), with the servlet side Async I/O implementation hooked into the Async I/O behaviors of the HttpClient intelligently.