DEVELOPING APPLICATIONS WITH
XPAGES JAKARTA EEJESSE GALLAGHERCTO - I KNOW SOME GUYS
IP MANAGER - OPENNTF
HTTPS://FROSTILLIC.US@JESSE@PUB.FROSTILLIC.USAgendaWhat are Jakarta EE and MicroPro le?
What is the XPages Jakarta EE Support project?
Shared Components:
Expression Language
Managed Beans (CDI)
Data access (Jakarta NoSQL)

fi

UI Development ModesPrerequisites
Comfort with (or willingness to learn) Java
Familiarity with annotations and Java 8 constructs (Optional, etc.) a plus
Ability to install plugins into Designer and Domino
YOU DO NOT NEED:
Knowledge of OSGi
To start a new app from scratch

JAKARTA EE AND MICROPROFILE

What is Jakarta EE?
The current form of Java EE
Originally run by Sun, then Oracle, and now
the Eclipse Foundation
Now fully open-source
Releases 8 and 9 focused on opensourcing and moving to jakarta.*
Jakarta EE 10 made new spec changes
and moved to Java 11 - we'll get that when
Domino 14 is out
https://jakarta.ee

What is MicroPro le?
Eclipse project started during JEE'sstagnation
Now serves as a sort of focusedincubator
Targeted for microservice architectures,but most tools are useful generally

fifi

https://micropro le.io/

The Standards And This Project
Jakarta EE and MicroPro le are normally deployed in a server like GlassFish or
Liberty as .war or .ear les
They're not needed here: Domino is our server and NSFs are our packages
This project implements a large subset of both, but not all of either
Some specs - like Authentication - are largely inapplicable on Domino
Some - like EJB - are on the way out
Some - like WebSocket - face technical limitations

fifi

Some I just haven't gotten around to yetNote on Naming
With the move from Java EE to Jakarta EE, many specs changed their names, like:
JSP -> Jakarta Pages
JSF -> Jakarta Faces
JAX-RS -> Jakarta REST
JPA -> Jakarta Persistence
I'll likely (and do in this slide deck) use the names interchangeably, out of habitfl

In the short term, it's often useful to search by the old names when looking for
documentation and Stack Over ow answers, but that is shifting over time

XPAGES JAKARTA EE SUPPORTXPages Jakarta EE Support
Began as adding a few utility specs: CDI for managed beans and JAX-RSfor REST
Grown to encompass a ton of specs, such as JSON-B, JSP, and Jakarta
NoSQLIt further expanded to include a selection of MicroPro le specs useful for
DominoPrimarily focuses on in-NSF development in Designerfi

Has some support for OSGi-based apps, but that takes extra knowledge

UsageDownload from OpenNTF
Install the plugins in Designer and theserver
Enable the libraries in the "Xsp
Properties" editor
There's a ton - this will likely besimpli ed in 3.xfiGet to coding! (in Java, mostly)Examples
The project has been gradually accumulating examples
The "examples" directory in the repository and distribution ZIP
contains ODPs for them
For this presentation, I created a series of To-Do apps - more on thatlater
The eclipse/nsfs directory contains "example" NSFs that serve aspart of the integration-test suite. They're not useful as apps, but show
a lot of capabilities in a technical way

SHARED COMPONENTS

Shared Components
Regardless of your UI toolkit of choice, some components will beshared:
CDI for sure - "managed beans" but much better
Expression Language - a newer version than XPages ships withREST - even in XPages or JSF apps, REST services come in handy
JSON-P and JSON-B - read/write JSON and convert objectsfiMicroPro le components - the Rest Client is a big one

EXPRESSION LANGUAGEExpression Language
Our old friend!
The current spec grew out of what started in JSF (as in XPages)
Existing EL expressions will still work in XPages, including SSJSThis EL interpreter is stricter about nulls, which is actually useful
No con guration necessary: enable the library and it will take over inXPages

fiEL also shows up in JSP, JSF, and other places (like more-esoteric CDI)

What you getAll the same stu as before!
#{foo.bar}, #{foo[bar]}, etc.
Function calls${el:messages.format('helloMessage', session.effectiveUserName)}
The "el:" prefix avoids an error marker in Designer - this is not needed in JSP orJSF
String concatenationff${'hi ' += session.effectiveUserName += '; good to see you!'}Examples<xp:text value="#{managedBeanGuy.message}"/><xp:text value="#{el:functionClass.doFoo('I am from XPages')}"/><xp:dataTable id="issueList" value="#{el:issuesBean.get(viewScope.owner, viewScope.repo)}" var="issue"><!-- snip --></xp:dataTable>

Resources

https://jakarta.ee/speci cations/expression-language/4.0/

fi

https://www.baeldung.com/jsf-expression-language-el-3

CDI (MANAGED BEANS)CDI (Managed Beans)
The spec covering managed beans is CDI: Components & Dependency
Injection
You don't have to care about why it's called thatYou also don't have to care about EJB (don't ask if you don't know)
Uses annotations instead of XML con guration (for our needs)
Cooperates with EL and general XPages variable resolutionfifi

You can (and should) replace beans in faces-con g.xml entirely

Example Bean
@ApplicationScoped@Named("markdown")
public class MarkdownBean {private Parser markdown = Parser.builder().build();
private HtmlRenderer markdownHtml = HtmlRenderer.builder().build();public String toHtml(final String text) {Node parsed = markdown.parse(text);
return markdownHtml.render(parsed);}}Example Bean - Injection@RequestScoped@Named("encoder")public class EncoderBean {@Inject @Named("dominoSession")
private Session session;}

public String abbreviateName(String name) throws NotesException {Name dominoName = session.createName(name);try {return dominoName.getAbbreviated();} finally {dominoName.recycle();}}Example Bean - Events and Scopes@RequestScoped@Named("requestGuy")public class RequestGuy {@Inject
private ApplicationGuy applicationGuy;
private final long time = System.currentTimeMillis();public String getMessage() {return "I'm request guy at " + time + ", using applicationGuy: " + applicationGuy.getMessage();}@PostConstructpublic void postConstruct() { System.out.println("Created requestGuy!"); }@PreDestroy
public void preDestroy() { System.out.println("Destroying requestGuy!");}}CDI Beyond BeansManaged beans are the "basic" case for CDI and most of what we'll use
It goes beyond that, providing foundational layers for other techs:
Jakarta REST
MVC
Jakarta NoSQLPretty much all of MicroPro lefi

Things get... weird when you dive in, but normal apps don't need thatResources

https://jakarta.ee/speci cations/cdi/3.0/
https://www.baeldung.com/java-ee-cdi

fi

https://openliberty.io/guides/cdi-intro.html

JAKARTA NOSQLJakarta NoSQL

Data access layer similar to JPA for SQL databases

ffi

Maps between Domino data and normal Java objects reasonably
e ciently

Some Caveats
The version of Jakarta NoSQL included in this project is speci cally abeta version
Newer versions have had several major changes:
They require Java versions higher than 8
The “Repository” concept moved to a new spec: Jakarta Datafi

The plan is to move to a version of these when Domino 14 is outModel Objects
Models are “plain” Java objects(POJOs)@Entity("To-Do") // Form namepublic class ToDo {// Enums are stored as strings
public enum State {Incomplete, Complete}@Id // Maps to UNID
private String documentId;@Column("Title") // Field names
private String title;@Column("Created")
private OffsetDateTime created;@Column("Status")
private State status;

The driver handles mapping between
NSF documents and these objects
There’s usually a one-to-one mapping
between a form and a model object/* snip: getters/setters */}Repositories
Repositories are just interfaces - you
don’t provide the implementation
The NoSQL layer parses method
names and arguments to translate
methods to queries

public interface ToDoRepository extends
DominoRepository<ToDo, String> {The driver uses DQL and QRP
internally to make this e cient

Stream<ToDo> findByStatus(State status,Sorts sorts);

fiffiViews and other Domino-speci cbehaviors (e.g. compute-with-form) areavailable

Stream<ToDo> findAll(Sorts sorts);}

UsageUse CDI to inject a repository
Can be injected into CDI beans andREST resources@ApplicationScoped@Named("ToDos") // Access by name in XPages
public class ToDosBean {@Inject
private ToDoRepository repository;

With XPages, you'll likely use a"broker" bean between XPages-type
code and Jakarta-type

public List<ToDo> getAll() {return repository.findAll(Sorts.sorts().asc("created")).collect(Collectors.toList());}

Can also be resolved
programmatically, but not prettily

public ToDo saveToDo(ToDo todo) {return repository.save(todo);}}THE UI PATHSExample Apps: To-Do
I made four versions of a bare-bones To-Do application:
XPagesREST with a basic HTML/JS UI
MVC with Jakarta Pages
Jakarta Faces
Available at https://github.com/OpenNTF/org.openntf.xsp.jakartaee/tree/develop/examples/todoWill be included in future distribution builds
I'll also add a README when I get a chanceExample Apps: To-Do
Each uses Jakarta NoSQL for its data accessSingle "To-Do" form with a few properties
Repository using DQL to load documents
Just basic functionality: CRUD with "Complete" and "Incomplete"statesDon't take these as examples of fully-built apps, but rather juststarting points

Preliminaries
Though these are four apps, the mechanisms can be interwoven
For example, you can add REST services to an XPages app, or doan "admin" UI in MVC in an app that's otherwise just REST
Even XPages and Faces can mix, if you're careful
These don't cover all the shared capabilities you'd likely use, such as
the Rest Client and"XPAGES PLUS"

"XPages Plus"In this case, XPages remains your UI toolkit of choice
Pros:
Retains the bene ts of existing XSP markup, plus the tooling provided byDesigner
EL and CDI bring direct improvements to the XPages experience
Can still mix with other types
Cons:fiXPages itself remains the same, and remains non-portable

Structure
The structure here will be very similar
to normal old XPages apps
"Normal", at least, if you write a lot ofJava
The "ToDosBean" here is a CDI beanthat injects the Jakarta NoSQLrepository
This is because XPages isn't "CDInative" the way some others areDevelopment Experience
Pretty much the same as you're used to when it comes to the UI
The main change in XSP markup is that you can use newer EL syntax
Business logic will be very heavily on the Java side
If you're not already doing this, it'll be a big change
If you are doing this, you can expect big improvements in convenience andcapability
Can also still use existing XPages constructs not available elsewhere, likexp:dominoDocument and xp:dominoView

REST SERVICESREST Services
In this case, you focus primarily on writing REST services to be consumed by something else
The "something else" would likely be a JavaScript app written in React or other toolkit
Pros:
Jakarta REST (JAX-RS) provides very clean, declarative annotations for writing REST services
You get an OpenAPI spec "for free"
Scales very well for larger/split teams with front-end and back-end separationCons:
A split app design like this is more complicated than a full-server-side toolkit
It introduces security/data-leakage concerns when you design your API

Structure
Here, there are no XPages, but there are stillJava classes
ToDosResource de nes the REST endpoints
and needs no "broker" to access NoSQLPage UI les are in File Resources
These would likely be the build output
from React/etc. in WebContent in a larger
project

fifi

Could also potentially be a whollyseparate app

Development Experience
Will depend heavily on how you're writing the UI (or if you are at all)
UI aside, all work will happen in Java, via model objects, beans, andREST services
Designer will help with the Java syntax and source availability, but
has no special knowledge of REST endpoints or CDI beans like e.g.
IntelliJ does

MVC AND JAKARTA PAGES (JSP)MVC and Jakarta Pages
In this case, you use the MVC spec on top of REST services and write your UI in Jakarta Pages (JSP)This is very well-suited to certain app types, such as document repositories, discussions, and blogs
Pros:
Builds on the clean foundation of Jakarta REST
Pairs very well with a REST-based API for non-browser clients"Back to basics" focus on HTML and HTTPCons:No server-side state makes complex forms di cultffi

Designer considers JSP pages HTML, so provides no help for JSP tags

Structure
Looks similar to the REST version
Here, "controller" refers to the MVC@Controller annotation
They are special kinds of REST
resources
Again, pages are in File Resources, butwould likely be in WebContent in larger
projects

Development Experience
Writing JSP in Designer is okay - it knows about HTML well enough,but will not help with JSP tags
JSP is small enough that you'll likely quickly memorize the basics
The Java side will be very similar to writing "normal" REST services

JAKARTA FACES (JSF)Jakarta Faces
In this case, you write Jakarta Faces (JSF) pages and access them similar to XPages
Pros:
Very similar to XPages: individual pages with server-side state and a shared heritage
Very good for complex forms and other ddly work
Faces is being actively developed
Can also use actively-developed third-party libraries like PrimeFaces
Lots of existing examples
Cons:
Like JSP, Designer considers JSF pages HTML, so provides no help for JSF tags

flfifiThird-party libraries can require manual ddling to avoid con icts with the XPages runtime

Structure
Same general idea as the XPages
versionHere, "controller" refers to a bean usedto act like a controller as in XPages, notan o cial concept
Like in XPages, Faces has an implicit
controller you don't writefiffi

Faces les generally use ".xhtml", but
can also use ".jsf"

PROJECT INFORMATION

Project Information
https://github.com/OpenNTF/org.openntf.xsp.jakartaee/
https://www.openntf.org/main.nsf/project.xsp?r=project/
XPages%20Jakarta%20EE%20SupportYouTube series: https://www.youtube.com/playlist?list=PLaDSIoofi96Nhho68wFsacBwwkCAmmVhRequirements and Compatibility
Domino 9.0.1FP10 for most pieces, Domino 12.0.1+ with FPs forNoSQL
Should work with most or all existing libraries
Used in production alongside ODA and POI4XPages
Can be used in OSGi bundles with some knowledge

Getting Involved
Try it out!
Talk about it in the OpenNTF Discord: https://openntf.org/discord
Report bugs and request features
Documentation: guides, speci c feature details, etc.
Example applications
https://github.com/OpenNTF/org.openntf.xsp.jakartaee/issues/307

fi

Chip in on the code directly

THANK YOU+ QUESTIONS