Yesterday, I released version 3.7.0 of the XPages JEE project, which is another incremental release that improves a number of things for the apps I've been making with it, as well as just generally bumping implementation versions to keep up to date.

gzip Support

I added implicit gzip compression for REST services (when the result content type is text/*, JSON, or XML) and for similarly-identified static resources when using Jakarta Modules. This is always a nice to have, and it had been on my list for a while. Keeps things nice and zippy without (hopefully) imposing any problems on the developer.

Welcome Pages

In the previous version, I added some basic support for welcome-file-list in web.xml for Jakarta Modules, letting you specify a static page or Servlet/JSP/JSF as the base landing page for your app. Admittedly, I don't use this much, as my new apps tend to be MVC-based and use a REST endpoint as the root, but it's nice for JSF apps or when you use a client-JS-based UI.

Anyway, when I implemented this, what I didn't do was read the spec (shame on me), and so I didn't implement it for subdirectories beyond just the app root. That's in there now, though, so it should be up to code for apps designed that way.

MIME Mapping

On a similar note, my quest to make Jakarta Module apps more "real WAR-y", I added support for specifying file-extension-to-MIME rules in web.xml in mime-mapping elements. The code will first consult your File Resource for a per-file MIME type, then check this list, and then finally fall back to a routine that tries to guess the file type by name. Usually, the last is what you'll want, but this is handy for new types not supported by the stock discovery scheme.

NoSQL Improvements

As usual, I found another spate of things I wanted to improve in the Data/NoSQL driver side.

One of these is that I improved the implicit behavior of using base Jakarta Data and NoSQL classes/annotations. This means that you can specify a repository using just the built-in CrudRepository type and either stock methods or annotated ones without using any Domino-specific code. For performance or capability needs, you'll usually want to use some Domino-specific code somewhere (say, to mark things as Reader fields), but it's always nice when you can make code that's completely portable without changes.

But back to Domino-isms, I added a couple more things. For one, when you use a NoSQLConfigurationBean in your app, you can now dynamically decide whether the DQL engine should be told to refresh views and FT indexes as it goes. While this may slow things down slightly (I assume it's smart about it internally when no work needs to be done), it's important for cases where you're creating new documents and then immediately doing DQL calls that find those documents view index views.

I also added support for specifying items as being stored as User Data (called "custom data" in Notes.jar). I imagine this isn't very common, but it comes up sometimes. Specifically, I did it because I want my NSF Maven Repository projects to be able to read and write custom file attributes in the same was as the NSF File Server project does. That one uses User Data because attributes are provided as byte arrays, and that's a clean match. In NoSQL entities, you can do this with String, byte[], ByteBuffer, and any type that implements Serializable. For large objects, using "MIMEBean" storage is your way to go, but maybe this will be handy for other people.