XPages JEE 2.13.0
Fri Jul 21 11:51:52 EDT 2023
- Updating The XPages JEE Support Project To Jakarta EE 9, A Travelogue
- JSP and MVC Support in the XPages JEE Project
- Migrating a Large XPages App to Jakarta EE 9
- XPages Jakarta EE Support 2.2.0
- DQL, QueryResultsProcessor, and JNoSQL
- Implementing a Basic JNoSQL Driver for Domino
- Video Series On The XPages Jakarta EE Project
- JSF in the XPages Jakarta EE Support Project
- So Why Jakarta?
- XPages Jakarta EE 2.5.0 And The Looming Java-Version Wall
- Adding Concurrency to the XPages Jakarta EE Support Project
- Adding Transactions to the XPages Jakarta EE Support Project
- XPages Jakarta EE 2.9.0 and Next Steps
- XPages JEE 2.11.0 and the Javadoc Provider
- The Loose Roadmap for XPages Jakarta EE Support
- XPages JEE 2.12.0: JNoSQL Views and PrimeFaces Support
- XPages JEE 2.13.0
- XPages JEE 2.14.0
- XPages JEE 2.15.0 and Plans for JEE 10 and 11
Today, I released version 2.13.0 of the XPages Jakarta EE Support project. Though there's not a single big banner feature, this one brings a number of good enhancements in a bunch of areas.
Domino 14
The first thing it brings is compatibility with Domino 14 EAP1. The goal here is to just bring the same features to that version - it doesn't bump the individual components to their Jakarta EE 10 versions yet, since that will come with breaking changes and prevent use on 12.0.2 and before.
There remains a caveat here, which is that EAP1 doesn't include a Java compiler, and so JSP doesn't work unless you shim in parts of a JDK into a Domino installation. If you're not using JSP, though, you should be able to run your apps on 14 using this new build.
JSF
It turns out that Faces support is a popular feature, which makes sense: it's the most direct analogue to writing XPages, while bringing in a lot of new features. While Faces has always been tricky to keep working, this build includes some fixes for stability and usability. I'd still consider this route to be the least-proven way to do UIs with this project, but it's shaping up really nicely.
JavaSapi
Speaking of experimental features, this release comes with a new feature that builds on the JavaSapi bridge I added a bit ago: you can now specify extensions within an NSF that will participate in JavaSapi pre-processing of requests.
To do this, you can make a file named META-INF/services/org.openntf.xsp.jakartaee.jasapi.JavaSapiExtension
in your NSF's Java classpath (e.g. the Code/Java folder) and have it name a JavaSapiExtension
class. For example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | package javasapi; import org.openntf.xsp.jakartaee.jasapi.JavaSapiContext; import org.openntf.xsp.jakartaee.jasapi.JavaSapiExtension; public class TestJavaSapiExtension implements JavaSapiExtension { @Override public Result rawRequest(JavaSapiContext context) { // Add a custom header to all responses context.getResponse().setHeader("X-InNSFCustomHeader", "Hello from NSF"); return Result.SUCCESS; } @Override public Result authenticate(JavaSapiContext context) { // Custom authentication mechanism. If you use this, do it more securely! String overrideName = context.getRequest().getHeader("X-OverrideName"); if(overrideName != null && !overrideName.isEmpty()) { context.getRequest().setAuthenticatedUserName(overrideName, "Basic"); return Result.REQUEST_AUTHENTICATED; } return JavaSapiExtension.super.authenticate(context); } } |
As with any time I do anything with JavaSapi, I can't stress enough how unsupported this is. It's not even officially a feature of Domino, and I've found it fairly easy to crash the server by doing the wrong thing here. On the other hand, it's neat and fun, so... feel free to tinker with it.
NoSQL
Finally, I added some methods to DominoRepository
instances to access profile and named notes:
1 2 3 4 | SomeEntity profile = repository.findProfileDocument("SomeProfile", "Your Username") .orElseThrow(() -> new NotFoundException("Could not find profile for user")); SomeEntity named = repository.findNamedDocument("Some Name", "Your Username") .orElseThrow(() -> new NotFoundException("Could not find named doc for user")); |
I made them return Optional
for safety's sake - I think they'll in general create the documents if they don't exist, but I wanted to leave room in the API for a future ability to only return them if they haven't previously been explicitly created.
Anyway, that's one more step in making the driver useful as a general-purpose Domino access mechanism. My goal is to make it so that you'd only need lotus.domino
, ODA, or another Domino-specific API in specific edge cases. I can already do almost everything I need to, and now I'm just working down the list of less-critical features.
Next Steps
As I've been working on 2.13.0, I've also been working on the 3.0 branch, including an early beta last month. That's the branch that breaks pre-Domino-14 compatibility and bumps most components up to their Jakarta EE 10 versions. Since I can't realistically have a proper release of that until Domino 14 is out, my plan is to keep tinkering with the side branch and releasing betas from time to time.
In the mean time, I wouldn't be surprised if there's a 2.14.0. There are some tweaks and efficiency improvements I want to make particularly for JSF, so I expect I'll have enough on my plate before Domino 14's release to get another current-line release out.