webfirmframework for Java Experts
New features in wffweb 12
wffweb 12 includes all features of wffweb 3 plus the features below. Please know that Java 17 or later is required to run wffweb 12 and Java 21 or later is the recommended version.
URL rewriting/routing
Support for BrowserPageSession, now no need to depend on Java server's HttpSession for session tracking.
Support for LocalStorage to set/remove tokens/items. Now, the authentication/authorization can be handled using token instead of cookie.
Inbuilt multi node support. Now, the wffweb app can be scaled without any additional effort.
For that, the Java server's
session should be disabled for wffweb BrowserPage & use a custom
httpSessionId when adding BrowserPage to the BrowserPageContext and handle the authentication/authorization using token instead of cookie.
Deployment Architecture Eg: deploy wffweb app in multiple domain nodes like node1.webfirmframework.com, node2.webfirmframework.com, node3.webfirmframework.com etc... Now create a load balancer in the main domain webfirmframework.com and point it to those subdomain nodes. That's all! No need to configure sticky sessions to the load balancer.
NB: The websocket connection should be publicly accessible in the subdomain nodes. The access to http connection in the subdomain nodes may be limited to the load balancer, to do that, the load balancer should route request to the nodes along with an app key, this app key may be checked in the wffweb app.
Now, you may have this question, we usually save some user data in HttpSession object,
if we have disabled Java server's HttpSession where can we store such data?
There is a BrowserPageSession.userProperties() which returns a map, you can store in it but it is not shared across multiple nodes.
If you want to share data (that we usually save in HttpSession object)
across multiple nodes you can use
LocalStorage
at server side. The
LocalStorage
object can be obtained from
BrowserPageSession
object, eg:
LocalStorage localStorage =
browserPageSession.localStorage()
.
The purpose of BrowserPageSession.userProperties() map is to store some temporary data in the same node.
Support for Virtual Thread
It fully supports Java Virtual Thread, it doesn't use
synchronized
keyword anywhere in the code. We know that Virtual Thread is a
preview feature (at least till Java 20) so we have to explicitly
enable it by JVM argument
--enable-preview
or
--enable-virtual-thread
if it is a preview feature. If Virtual Thread is enabled the framework will use Virtual
Thread to do their internal operations where appropriate. If you
are using Java 21 or later then no need to
explicitly enable it by this VM argument, it will automatically
use Virtual Thread for its internal operations. If you are using GraalVM
native image to run your application you have to set system
property
virtualThread.enable
with
true
, i.e.
-DvirtualThread.enable="true"
from command line or
System.setProperty("virtualThread.enable",
"true");
by Java code if GraalVM Java version is less than 21 otherwise nothing to do.
Oracle GraalVM is recommended rather than community edition.
Lossless browser page communication since 12.0.0
Buffer limit configurations for BrowserPage since 12.0.0
Checkout this sample code here.