B4J Question jServer v4.0 - declarations required when using the standalone packager?

[bdunkleysmith]

This post jServer v4.0 - Based on Jetty 11 says that these declarations need to be made when using the standalone packager:

#PackagerProperty: AdditionalModuleInfoString = provides org.slf4j.spi.SLF4JServiceProvider with org.eclipse.jetty.logging.JettyLoggingServiceProvider;
#PackagerProperty: AdditionalModuleInfoString = provides org.eclipse.jetty.io.ssl.ALPNProcessor.Server with org.eclipse.jetty.alpn.java.server.JDK9ServerALPNProcessor;
#PackagerProperty: AdditionalModuleInfoString = provides org.eclipse.jetty.http.HttpFieldPreEncoder with org.eclipse.jetty.http2.hpack.HpackFieldPreEncoder, org.eclipse.jetty.http.Http1FieldPreEncoder;
#PackagerProperty: AdditionalModuleInfoString = uses org.eclipse.jetty.util.security.CredentialProvider;
#PackagerProperty: AdditionalModuleInfoString = uses org.eclipse.jetty.io.ssl.ALPNProcessor.Server;

However I have added a web server function to an existing UI project using JServer and re-packaged it using the Integrated B4JPackager11 without adding these declarations, and found the resultant installed application performs as expected. I note that having to add those declarations is not included as one of the tips in the post Integrated B4JPackager11 - The simple way to distribute standalone UI apps.

Have circumstances changed and those declarations are no longer required or will I have some limited functionality?

 

[Erel]

They are still required. I've added it to the list of special cases.

Note that it is not recommended to use jServer in a UI project.

Most of these declarations are related to SSL/TLS connections (https).

 

[bdunkleysmith]

Thank you @Erel, but can you please advise why "it is not recommended to use jServer in a UI project."?

For instance what problems am I likely to encounter, noting that in this application the server just serves a simple html page containing some buttons and resultant posts from the client web browser triggers actions that have to date, been triggered by buttons in the UI?

After a few days of testing, even without those declarations, I've been very happy with the functionality/performance and not noticed any impact on the existing functionality of my app which is MQTT based.

 

[Erel]

1. If you tested it thoroughly and it works properly for your use case, then it is probably fine. And make sure to test it in release mode.

2. jServer uses a different and more complicated threading model. I only tested it in non-ui apps as this is the common usage for jServer.

 

[bdunkleysmith]

Thank you for the explanation @Erel. Yes, I've done extensive testing in release mode in the IDE and also the resultant standalone installer, and have not encountered any issue. I'll continue to monitor.

The desired functionality is that of a remote controller and to date I have achieved that using UDP with a B4A app as the client. However I have found on some WiFi networks the UDP packets don't arrive. I assume AP isolation must be enabled or similar to cause that. Therefore I implemented this simple HTML server solution, which hopefully overcomes that and has the additional benefit of not requiring a client to be installed on the mobile (remote control) device. However the webserver is not started by default and only started if necessary, ie. UDP solution not working or control via a non-Android device is required.