by Jesse Gallagher
Concept Proven: A Complex Production XPages App Running Outside Domino 
By Jesse Gallagher | 10/8/19, 12:55 AM | - | Added by John Oldenburger
Around the start of the year, I took a little time to see if I could get XPages as it exists today running outside of a Domino server, specifically inside Open Liberty. I met with a good deal of success, finding that I could run stripped-down apps "freely" inside a normal WAR web app.
Medium-Term Ways to Improve XPages
By Jesse Gallagher | 8/29/19, 1:06 AM | - | Added by John Oldenburger
Following up on my jeremiad the other day, I've been thinking about some of the short- to medium-term ways that XPages could be improved. I'm not fully sold on the idea that it should be massively improved in-place due to some of the systemic decisions and the general goal of future-proofing.
What Makes XPages "Not Modern"?
By Jesse Gallagher | 8/25/19, 10:43 AM | - | Added by John Oldenburger
A big part of figuring out how to move past XPages is discussing what makes it no longer modern in the first place. Some of these reasons will be gimmes - out-of-date or outright-missing features - while some will be less about what XPages is strictly capable of and instead more about how XPages development and deployment works.
Developing Open Liberty Features, Part 2
By Jesse Gallagher | 8/19/19, 12:07 AM | - | Added by John Oldenburger
In my earlier post, I went over the tack I took when developing a couple extension features for Open Liberty, and specifically the way I came at it with Tycho. Shortly after I posted that, Alasdair Nottingham, the project lead for Open Liberty, dropped me a line to mention how programmatic service registration isn't preferred.
Developing an Open/WebSphere Liberty UserRegistry with Tycho
By Jesse Gallagher | 8/17/19, 11:10 AM | - | Added by John Oldenburger
In my last post, I put something of a stick in the ground and announced a multi-blog-post project to discuss the process of making an XPages app portable for the future. In true season-cliffhanger fashion, though, I'm not going to start that immediately, but instead have a one-off entry about something almost entirely unrelated.
How Do You Solve a Problem Like XPages? Redux
By Jesse Gallagher | 8/13/19, 3:49 PM | - | Added by Oliver Busse
The better part of a year ago, I mused about what to do about the XPages problem. For better or for worse, I'm still musing about it to this day, without a good answer. The nice part for me is that it's not actually my job to come up with a real plan to "solve" XPages in a grand scale, but I do have my own set of clients I'm responsible for, and I've been personally invested in it for so long that I'd like to be involved in bringing it to a safe landing.
How the ODP Compiler Works, Part 7
By Jesse Gallagher | 7/9/19, 12:01 AM | - | Added by John Oldenburger
In this probably-final entry in the series, I'd like to muse a bit about possible future improvements and additions to the compiler and the NSF ODP Tooling generally. For the most part, the big-ticket future additions seek to answer one question: Could this be used to replace Designer?
How the ODP Compiler Works, Part 6
By Jesse Gallagher | 7/8/19, 12:03 AM | - | Added by John Oldenburger
In this post, I'd like to go over another main component of the NSF ODP Tooling project, the ODP Exporter. The exporter is significantly simpler than the compiler, but still had a surprising number of gotchas of its own. My goal in writing the exporter was to replace the need to use Designer to create an on-disk project out of an NSF.
How the ODP Compiler Works, Part 5
By Jesse Gallagher | 7/6/19, 9:23 AM | - | Added by John Oldenburger
One of the things that came up frequently when writing both the compiler and exporter portions of the NSF ODP Tooling was rationalizing the multiple ways an NSF is viewed, and determining which aspects are reified in the design notes themselves and which are entirely runtime conjurations.
How the ODP Compiler Works, Part 4
By Jesse Gallagher | 7/3/19, 11:35 AM | - | Added by John Oldenburger
In today's post, I'd like to go over a bit of how the NSF ODP Tooling project is organized, and specifically how I structured it to support both server-based and local compilation.
Setting aside the feature, update site, and distribution modules, the tooling consists of seventeen code-bearing components.
How the ODP Compiler Works, Part 3
By Jesse Gallagher | 7/3/19, 12:43 AM | - | Added by John Oldenburger
In the first two posts in this series, I focused on the XPages compilation and runtime environment, independent of anything to do with an NSF specifically. I'll return to the world of OSGi and servlets in later entries, but I'd like to take a bit of time to talk about some specifics of grafting the compiled XPage results and the rest of the on-disk project's contents into an actual NSF.
How the ODP Compiler Works, Part 2
By Jesse Gallagher | 7/2/19, 12:02 AM | - | Added by John Oldenburger
In yesterday's post, I briefly touched on how the XPages runtime sees its environment by way of a FacesProject and related components. Today, I'd like to expand on that a bit, since it's useful to understand the various layers of what makes up an "XPages app" at compilation and runtimes. Designer and Domino largely take two paths to try to arrive at the same location in how they view an NSF.
How the ODP Compiler Works, Part 1
By Jesse Gallagher | 7/1/19, 12:15 AM | - | Added by John Oldenburger
A year ago, I started a project to compile NSFs - and particularly large XPages projects - independently of Designer. Since the initial releases, the project has grown, gaining an ODP exporter, extra Eclipse UI integration, and the ability to run without installing components on a remote server. It's become an integral part of my workflow with several projects, where I include the NSFs as part of a large Maven build alongside OSGi plugins and a final distribution.
My Slides From Engage 2019 - De04. Java With Domino After XPages
By Jesse Gallagher | 5/20/19, 7:36 AM | - | Added by Oliver Busse
Engage 2019 has come and gone, and I had an excellent time. I also quite enjoyed presenting my "group therapy" session on some options that XPages developers have for the future. In a lot of ways, it was similar to my presentation at CollabSphere last year, mixed with the various new developments I've talked about on here since then
Java With Domino After XPages
By Jesse Gallagher | 3/14/19, 1:45 PM | - | Added by John Oldenburger
IBM and HCL held a webcast today to detail some plans for Notes/Domino V11. There were some interesting tidbits elaborating on things like the pub/sub support, and it'll be worth tracking down a recording of the event when it's available. What's important for this series, though, is that this event served as the long-promised "roadmap" announcement for XPages.
XPages to Java EE, Part 13: Why Do This, Anyway?
By Jesse Gallagher | 3/1/19, 10:28 AM | - | Added by John Oldenburger
In the introductory post to this series, I started by saying that I've come around to the idea that Java EE (and its kindred technologies) is the future for Java development with Domino, and I think it's worth taking some time to make the case that you should think so too. A lot of it starts with a nagging question: Is XPages Dead?
AbstractCompiledPage, Missing Plugins, and MANIFEST.MF in FP10 and V10
By Jesse Gallagher | 2/25/19, 11:20 AM | - | Added by John Oldenburger
Since 9.0.1 FP 10, and including V10 because it's largely identical for this purpose, I've encountered and seen others encountering a couple strange problems with compiling XPages projects. This is a perfect opporunity for me to spin a tale about the undergirding frameworks, but I'll start out with the immediate symptoms and their fixes.
XPages to Java EE, Part 12: Container Authentication
By Jesse Gallagher | 2/20/19, 11:45 AM | - | Added by John Oldenburger
Coming from Domino, we're both spoiled by the way it handles users and authentication. The server comes with an implicit directory far removed from the app, and so we just use that. Moreover, the HTTP "container" handles authentication for us: we configure whether we want HTTP Basic auth, simple session auth, LTPA, or SAML (I guess) authentication at the server/web site level, also far from the app.
XPages to Java EE, Part 11: Mixing MVC and an API
By Jesse Gallagher | 2/16/19, 12:10 PM | - | Added by John Oldenburger
When we set up our MVC controller classes, we put the @Controller annotation at the class level, which tells the environment that the entire class is dedicated to running the UI. However, we don't necessarily always want to do that - JAX-RS is the way to build REST APIs, after all, and so we should also add JSON versions of our Person methods.
XPages to Java EE, Part 10: Data Storage
By Jesse Gallagher | 2/15/19, 12:00 PM | - | Added by John Oldenburger
How you store your data in an application is a potentially-huge topic, which is one of the reasons I've pushed it off for a while. This is particularly the case because of the habits we learned over the years as Domino developers. One of the most grievous wounds Domino inflicted on us was an encouragement to always write directly to the data-storage implementation objects - forms and views for Notes client design or the lsxbe/lotus.domino classes for LotusScript and Java.
XPages to Java EE, Part 9: IDE Features Grab Bag
By Jesse Gallagher | 2/13/19, 10:58 AM | - | Added by John Oldenburger
In today's post, I'm going to go over a handful of features that IDEs, particularly Eclipse, bring to the table to improve the development experience. Some of these aren't unique to EE development, but our use of Maven and standardized technology makes them better than their equivalents in XPages development.
XPages to Java EE, Part 8: IDE Server Integration
By Jesse Gallagher | 2/12/19, 10:37 AM | - | Added by John Oldenburger
I said that the next post was going to be about authentication or databases, but I'm turning that into a filthy lie. Instead, we're going to take a bit of a detour to talk about a couple ways to let the IDE help you out in development. I'll be talking about Eclipse specifically, but I know that at least the paid version of IntelliJ IDEA has similar features. The first feature on the docket is having the IDE manage an app server for you.
XPages to Java EE, Part 7: MVC
By Jesse Gallagher | 2/12/19, 1:32 AM | - | Added by John Oldenburger
I mentioned in the last post that the rest of this tutorial is going to involve making some technology choices that are less universal than the ones up until this point. While pretty much every new EE app is going to involve CDI and JAX-RS, things will start to diverge once you decide on how you're going to handle authentication, your UI, and your data storage. We're going to dip into the the second one of those today.
XPages to Java EE, Part 6: Dependencies
By Jesse Gallagher | 2/1/19, 1:45 AM | - | Added by Oliver Busse
This is going to be a quick post, but I think it's useful to treat the topic of third-party dependencies on its own because of how much nicer it is with a Maven-based app than an NSF or OSGi plugin.
Historically, we've handled dependencies primarily by downloading a Jar and either plunking it in jvm/lib/ext on the server, stashing it in a Java agent or script library, or importing it into the NSF as a Jar design element for XPages. With OSGi plugins, that remained the simplest way to do it too: just drop the Jar into the plugin and add it to the bundle classpath.
XPages to Java EE, Part 5: Web Pages
By Jesse Gallagher | 1/24/19, 11:23 AM | - | Added by Oliver Busse
Once upon a time, web pages were easy: you'd write some HTML directly or, if you're fancy, use some Server Side Includes or PHP. Now, though, it's a rat's nest of decisions and stacks - fortunately for me, going into the pros and cons of each approach is beyond the scope of this series. Suffice it to say that Java EE can cover your needs whatever approach you take: it can do basic dynamic HTML generation, server-persisted frameworks like JSF, and work splendidly as a backend for a client JS app thanks to JAX-RS.
XPages to Java EE, Part 4: Application Servers
By Jesse Gallagher | 1/23/19, 5:15 PM | - | Added by Oliver Busse
I mentioned in the terminology post that one of the new things to get used to in Java EE is the concept of a "Servlet Container" or "Application Server", and I think that this concept is worth a bit of going in to.
In a general sense, we've been working with this concept for a good while now: Domino is an application server in several senses, and (for the most part) the NSFs are the applications it houses. It blurs the lines in a couple ways by virtue of NSFs also being data stores, but an XPages application is a pretty direct match for a .war file deployed to an application server, code-wise.
XPages to Java EE, Part 3: Hello, World
By Jesse Gallagher | 1/22/19, 1:40 AM | - | Added by Oliver Busse
I expect that I'll have some more theory and explanation to get to in future posts, but I think it will be useful to run through a quick example project. Unlike with my XPages/OSGi examples, there won't be anything in this one that you wouldn't find in any old Java EE tutorial - indeed, I'll be piggybacking on some existing ones to speed things along.
XPages to Java EE, Part 2: Terminology
By Jesse Gallagher | 1/18/19, 12:36 PM | - | Added by Oliver Busse
Much like with my earlier series, I think it'll be useful to take a minute to go over some of the terms that we'll need to know for dealing with Java EE, beyond just the many names of the platform. Additionally, I think it'll be useful to go over some of the things we specifically need to not know when it comes to non-OSGi development.
XPages to Java EE, Part 1: Overview
By Jesse Gallagher | 1/18/19, 2:08 AM | - | Added by Oliver Busse
I've definitely come around to the idea that the future for Java with Domino involves Java/Jakarta EE. HCL apparently feels the same way, though what that "J2EE" bit on their slide means remains unspecified. Regardless, I think that it's important for the XPages community to at least dip our toes into JEE proper, and I plan to share some of my experiences with doing so.
Letting Madness Take Hold: XPages Outside Domino
By Jesse Gallagher | 1/8/19, 7:35 AM | - | Added by Oliver Busse
Since I've been on a real Open Liberty kick lately, over the weekend I decided to go another step further and test something I'd been wondering for a while: whether it'd be possible to run the current form XPages outside of the Domino HTTP stack.