B4J Code Snippet JavaObject Jetty API access changes from jServer 4 (Jetty 11) to jServer 5 (Jetty 12)

I propose this thread to be a list of changes needed in JavaObject calls to Jetty APIs when moving from jServer 4 (Jetty 11) to jServer 5 (Jetty 12).

Please add any that you find, posting both the original jServer 4 compatible version and the new jServer 5 compatible version. A brief note on what you're using it for might be useful too. Thanks.

To start us off....
jServer 4:

JO.InitializeNewInstance("org.eclipse.jetty.client.dynamic.HttpClientTransportDynamic", Array(ClientConnector, Infos))

JServer 5:

JO.InitializeNewInstance("org.eclipse.jetty.client.transport.HttpClientTransportDynamic", Array(ClientConnector, Infos))

This is used when forcing the client to accept all SSL certifcates (see here).

 

[b4x-de]

ServletRequest.GetMultipartData: target folder is no longer created automatically

This is not strictly a JavaObject API/package change, but it is a behavioral difference I encountered while migrating from jServer 4 / Jetty 11 to jServer 5.02 / Jetty 12.1.10, so it might be useful to document it here as well.

Consider code that uses a separate upload folder for each HTTP session:

Dim UploadFolder As String = File.Combine(Main.UploadFolder, Session.Id)
Dim Parts As Map = req.GetMultipartData(UploadFolder, 10000000)

Assume that Main.UploadFolder exists, but the session-specific subfolder does not yet exist.

jServer 4 / Jetty 11

This worked without explicitly creating the session-specific folder. The Jetty 11 multipart implementation created the configured temporary directory when it did not exist:

if (!Files.exists(_tmpDir))
    Files.createDirectories(_tmpDir);

Source:
Jetty 11 MultiPartFormInputStream

jServer 5.02 / Jetty 12.1.10

With jServer 5, the same call fails if the supplied folder does not already exist:

java.nio.file.NoSuchFileException:
...\upload\<session-id>\MultiPart...

    at java.base/java.nio.file.Files.createTempFile(...)
    at anywheresoftware.b4j.object.JServlet$ServletRequestWrapper.GetMultipartData(JServlet.java:309)

The jServer 5 implementation uses the new Jetty multipart parser. When an uploaded file part is still held in memory, GetMultipartData converts it to a temporary file with:

Path f = Files.createTempFile(Path.of(Folder), "MultiPart", "");

At this point the supplied folder is not created first.

Source:
jServer JServlet.GetMultipartData

Workaround for jServer 5

Explicitly create the folder before calling GetMultipartData:

Dim UploadFolder As String = File.Combine(Main.UploadFolder, Session.Id)

If File.IsDirectory(UploadFolder, "") = False Then
    File.MakeDir(UploadFolder, "")
End If

Dim Parts As Map = req.GetMultipartData(UploadFolder, 10000000)

This preserves session-specific upload directories and works independently of whether the multipart implementation creates the destination folder internally.

The behavior appears to come from the new implementation of GetMultipartData in jServer 5 rather than being a general Jetty 12 restriction.

Would it make sense for GetMultipartData to create the supplied folder, restoring the behavior seen with jServer 4?