Migration from GWT

This page maps GWT viewer concepts to their React UI equivalents. Use it as a reference when evaluating or planning a migration. Features marked "Not yet available" are on the React UI roadmap.

Concept mapping

GWT viewer	React UI	Notes
Standalone application (arender-ui-springboot)	npm package embedded as Web Component	See Getting started
<iframe> embed	<arender-element> Web Component	See Web Component
Document parameters in the iframe URL (?nodeRef=…, ?url=…, ?uuid=…)	document attribute or openDocument(params), taking the same query string	The address bar no longer opens documents. See Opening documents
window.arender.jsapi	window.ARender / element.ARender	See Web Component — JavaScript API
.properties files	HTML attributes, JavaScript API	See Configuration
Connector JARs (bundled in viewer)	Provider microservices (separate containers)	See Providers
Visual profiles	Not yet available	—
Plugins	Not yet available	—
XML bean configuration	Not applicable	React UI has no Spring context in the frontend
ARender.html customization	CSS variables	Light DOM, standard CSS applies
arender-custom-js.js	window.ARender API	—
/arendergwt/ servlet endpoints	Broker API directly	No viewer-side servlet layer
Server-side annotation storage config	Same (backend is shared)	XFDF, JDBC, or REST storage
Rendition properties	Same (backend is shared)	Broker and rendition services are unchanged

What stays the same

The entire backend stack is shared between both viewers:

• Document Service Broker — same image, same configuration
• Document Converter, Document Renderer, Document Text Handler — unchanged
• Annotation storage — XFDF files, JDBC, or REST, configured on the backend
• Rendition properties — all document processing settings
• Licensing — same license file

You do not need to change your backend deployment when switching viewers.

What changes

• Delivery model: The GWT viewer is a standalone Spring Boot application; the React UI is an npm package embedded in your application
• Embedding: <iframe> pointing to the viewer URL becomes <arender-element> in the host page DOM
• JavaScript API: arender.jsapi.* namespace becomes window.ARender.*, with a single method to open a document: openDocument(params)
• Document requests: the parameters you used to put in the iframe URL query string are passed to openDocument() (or the document attribute) as the same query string, forwarded verbatim to the backend. The address bar of the host page never opens a document
• Configuration: .properties files become HTML attributes and JavaScript calls
• Connector model: Java JARs in the viewer classpath become standalone provider microservices
• Network: The host application must proxy or allow cross-origin requests to the broker (see CORS and reverse proxy)

Migration checklist

1. Install the arender-ui npm package (or a framework wrapper) in your host application
2. Replace <iframe> embeds with <arender-element> Web Component
3. Set up a reverse proxy or CORS configuration for the broker API routes
4. Update JavaScript integrations to use the window.ARender / element.ARender API, moving the document parameters out of the iframe URL and into openDocument(params) — URL-encoding every value
5. If using repository connectors (Alfresco, FileNet), deploy the corresponding provider microservice and register it in the broker
6. Test core workflows: viewing, annotation, search, redaction
7. Verify features you depend on are available in the React UI (see key capabilities)