Azul, the guys from the Zulu JDK, has aquired Payara.
I thought I'd mention it here, as I am using Payara in my hobby project.
There's a message on what it means for the Community version of Payara at [1] on https://foojay.io.
Just wanted to turn off hazelcast in my Payara Micro instance.
I've tried putting the following in my postboot file, but that doesn't work:
A quick google search found reference [1].
Just adding --nocluster as a commandline parameter when running Payara Micro does the trick.
Writing some notes here on what I had to do to get things running on Jakarta 10.
I've started upgrading as my application server (Payara) came out with a version that is Jakarta 10 compatible (release 6). See [1].
I'm using the Payara Micro to deploy my apps.
Here's a list of all the imports I had to change. It's likely not interesting, but sometimes I just like to write stuff down.
| Type | Javax import | Jakarta import |
|---|---|---|
| Jakarta Persistence | import javax.persistence.* | import jakarta.persistence.* |
| Jakarta Security | import javax.security.enterprise.credential.* | import jakarta.security.enterprise.credential.* |
| import javax.security.enterprise.* | import jakarta.security.enterprise.* | |
| import javax.security.enterprise.authentication.mechanism.http.* | import jakarta.security.enterprise.authentication.mechanism.http.* | |
| import javax.security.enterprise.credential.* | import jakarta.security.enterprise.credential.* | |
| import javax.security.enterprise.identitystore.* | import jakarta.security.enterprise.identitystore.* | |
| import javax.annotation.security.* | import jakarta.annotation.security.* | |
| Jakarta CDI | import javax.enterprise.context.* | import jakarta.enterprise.context.* |
| import javax.inject.* | import jakarta.inject.* | |
| import javax.annotation.* | import jakarta.annotation.* | |
| import javax.ejb.Singleton; | import jakarta.inject.Singleton; | |
| Jakarta Servlets | import javax.servlet.http.* | import jakarta.servlet.http.* |
| import javax.servlet.* | import jakarta.servlet.* | |
| import javax.servlet.annotation.*; | import jakarta.servlet.annotation.*; | |
| Jakarta Validation | import javax.validation.constraints.*; | import jakarta.validation.constraints.*; |
| Jakarta Rest | import javax.ws.rs.*; | import jakarta.ws.rs.*; |
| import javax.ws.rs.core.*; | import jakarta.ws.rs.core.*; | |
| import javax.ws.rs.ext.*; | import jakarta.ws.rs.ext.*; | |
| Jakarta XML bind | import javax.xml.bind.annotation.*; | import jakarta.xml.bind.annotation.*; |
| Jakarta Websockets | import javax.websocket.*; | import jakarta.websocket.*; |
The most changes are due to persistence as it kind of spreads throughout a lot of the code, mainly annotations on entities.
The old:
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd" bean-discovery-mode="annotated"> </beans>
The new:
<?xml version="1.0" encoding="UTF-8"?> <beans version="3.0" bean-discovery-mode="all" xmlns="https://jakarta.ee/xml/ns/jakartaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/beans_3_0.xsd"> </beans>
The old:
<?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee webapp_4_0.xsd" version="4.0"> <display-name>Mrbear Website</display-name> </web-app>
The new:
<?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="https://jakarta.ee/xml/ns/jakartaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd" version="5.0" metadata-complete="false" > <display-name>Mrbear Website</display-name> </web-app>
The old:
<?xml version="1.0" encoding="UTF-8"?> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"> <persistence-unit name="mrbearPU" transaction-type="JTA"> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider> <jta-data-source>jdbc/mrbear</jta-data-source> <exclude-unlisted-classes>true</exclude-unlisted-classes> <properties> <property name="javax.persistence.schema-generation.database.action" value="none"/> <property name="eclipselink.cache.shared.default" value="false"/> <property name="eclipselink.logging.level" value="INFO"/> <!-- line below is for logging of sql, set to FINE if you need to see it--> <property name="eclipselink.logging.level.sql" value="INFO"/> <property name="eclipselink.target-database" value="MySQL4"/> </properties> </persistence-unit> </persistence>
The new:
<?xml version="1.0" encoding="UTF-8"?> <persistence version="3.0" xmlns="https://jakarta.ee/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://jakarta.ee/xml/ns/persistence https://jakarta.ee/xml/ns/persistence/persistence_3_0.xsd" > <persistence-unit name="mrbearPU" transaction-type="JTA"> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider> <jta-data-source>jdbc/mrbear</jta-data-source> <exclude-unlisted-classes>true</exclude-unlisted-classes> <properties> <property name="jakarta.persistence.schema-generation.database.action" value="none"/> <property name="eclipselink.cache.shared.default" value="false"/> <property name="eclipselink.logging.level" value="INFO"/> <!-- line below is for logging of sql, set to FINE if you need to see it--> <property name="eclipselink.logging.level.sql" value="INFO"/> <property name="eclipselink.target-database" value="MySQL4"/> </properties> </persistence-unit> </persistence>
<properties> <maven.compiler.release>17</maven.compiler.release> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <project.encoding>UTF-8</project.encoding> <jakartaee.version>10.0.0</jakartaee.version> <!-- XmlRootElement and all that stuff --> <jakarta-xml-bind.version>4.0.0</jakarta-xml-bind.version> <microprofile.version>5.0</microprofile.version> <!-- used for EclipseLink extentions, for example Customizer/QueryHints --> <eclipselink.version>4.0.0</eclipselink.version> </properties> <dependencies> <dependency> <groupId>org.eclipse.microprofile</groupId> <artifactId>microprofile</artifactId> <version>${microprofile.version}</version> <type>pom</type> <scope>provided</scope> </dependency> <!-- used for EclipseLink extentions, for example Customizer/QueryHints --> <dependency> <groupId>org.eclipse.persistence</groupId> <artifactId>org.eclipse.persistence.jpa</artifactId> <version>${eclipselink.version}</version> <scope>provided</scope> </dependency> <dependency> <groupId>jakarta.platform</groupId> <artifactId>jakarta.jakartaee-web-api</artifactId> <version>${jakartaee.version}</version> <scope>provided</scope> </dependency> <dependency> <groupId>jakarta.xml.bind</groupId> <artifactId>jakarta.xml.bind-api</artifactId> <version>${jakarta-xml-bind.version}</version> </dependency> </dependencies>
Also upgraded the java compiler plugin to use Java 17:
<plugin> <artifactId>maven-compiler-plugin</artifactId> <version>3.8.1</version> <configuration> <release>17</release> </configuration> </plugin>
I've replaced them with POJOs that I just create using JsonbBuilder.create().fromJson(json, clazz) and jsonify using JsonbBuilder.create().toJson(object). Not everywhere yet, but I'm getting there.
| Javax import |
|---|
| import javax.xml.bind.annotation.XmlRootElement; |
| import javax.xml.bind.annotation.XmlTransient; |
Also means I could get rid of this in my pom files:
<dependency> <groupId>javax.xml.bind</groupId> <artifactId>jaxb-api</artifactId> <version>2.3.0</version> </dependency>
I've decided to get rid of all the EJB stuff.
This isn't related to the Jakarta 10 upgrade per se, but thought I'd mention it.
| Javax import |
|---|
| import javax.ejb.LocalBean; |
| import javax.ejb.Stateless; |
| import javax.ejb.Singleton; |
| import javax.security.enterprise.SecurityContext; |
| import javax.ejb.EJB; |
| import javax.ejb.EJBAccessException; |
| import javax.ejb.SessionContext; |
Replaced javax.security.enterprise.SecurityContext and javax.ejb.SessionContext with rs.core.SecurityContext. So using Rest functionality, instead of EJB functionality.
Apparently, the cookie spec no longer allowed special characters, like commas.
After some research, I found that GraalVM does not ship automatically with JavaScript since version 22. A separate GraalVM Component needs to be installed, like so:
Fixed by allowing access to public methods.
Also, direct access to properties using the .<name> convention no longer works, so for instance person.room must be replaced with person.getRoom().
So, yeah, let's make the key bigger, ey?
So I didn't want to import an implementation of Gson or Jackson, as Microprofile already has an implementation, (Yasson) and who cares about implementations, eh? Just use the API!
Luckily I found an article on the internet, on how to make your own Serializer and Deserializer.
One other thing I encountered, was when removing/replacing the EJB Beans with just @Inject, it is no longer allowed to create circular dependencies.
I didn't mind, as creating circular dependencies is a good thing to entirely avoid, so I was pleased with the error message.
Some moving around, and things worked properly.
So, yay, my homebrew hobby project is now Java 17 and Jakarta 10 and Microprofile 5 running on Payara Micro 2022.6.1.
I found a good writeup here on what actually Jakarta 10 is.
I also found something about what sort of Maven archetype to use.
I'll write a blog post on what I had to do to upgrade. It wasn't much, but I decided to make some changes unrelated to Jakarta as well.
I found a little script (that I changed a little) to accomodate me in automating SSL certificate renewals.
First of all, the script is executed using a crontab, every 73 days. Why every 73 days? Because that is 5 times a year. Any less, and we (just) go past the 90 days validation period1. (365/4 = 91.25)
The script that basically delegates everything to either other scripts or is dependent of other scripts:
For the script that automatically imports into keystore, see [2].
All righty then, time to get working with LetsEncrypt. Again.
So there are several different ways to have LetsEncrypt verify that the domain you wish to have a certificate for is actually yours.
I usually use the webroot version.
But in the past, I found it irksome that I had to let certbot spin up a http server to verify my domain.
What was easier was to have my application server have a part on the filesystem mapped to the Webpages1.
Then certbot could simply use that webroot directory. Which is option 2.
So let's try that.
It will put stuff in /home/jelastic/media/.well-known. Usually in the acme-challenge directory. It'll put some random file in there, for example 366_oWEFaizWeQqOts4KhuTBQcCsFH5dBgG7-jNX32k with a similar string inside, but usually a lot longer.
This file is accessed by the LetsEncrypt server, and if that works, the domain is yours and you get your certificate.
"certbot renew" is preferably easier, as it takes into account the previous configuration settings. Nice for cron jobs.
Also, I found this great script for importing the ssl certificates on the Forums of LetsEncrypt2 for my Java Application Server!
My Payara MicroProfile server uses the following commandline to access the new certificates:
Please pay special attention to the four "javax.net.ssl.*" properties that take care of the SSL properties.
And that's it!
Boy, that title was a mouth full.
Now if you want more information on Docker, you can check out reference [3]. Or if you're looking for Java 11 GraalVM Dockerimages suitable for Jelastic, you can check out [1] and [2].
This blog is more about the contents of the Dockerimage than Docker itself.
Well, I've been using Jelastic for a while now, and it suited my needs, until it didn't.
They provide GraalVM out of the box, but not the Java 11 version yet.
I was using a Payara Server image for Jelastic, and I had good results just installing GraalVM on the Image afterwards and run Payara using that, but I was looking for something a little more lean.
Sooo, in short, I used the GraalVM image used by Jelastic as a baseline in my Docker image (jelastic/javaengine:graalvm-21.0.0.2).
Then it was just install the JDK11 version of GraalVM and create my Image.
Less troublesome than I thought it would be.
So Payara Micro is awesome. The way this differs from Microprofile, is that Microprofile contains only Microprofile and the Payara Micro basically seems to be a small Payara server run from the command line. It is based off the Payara Embedded Web release. See [4].
So there's basically two things:
Let's try an example.
The example basically runs a Payara Micro instance, with some wars deployed and a JDBC library for connecting to a database.
All configuration of the database connection is done using the afore mentioned postboot file.
Some notes on the postboot file.
I added eclipselink.target-database to the jdbc string, otherwise the JDBC driver will identify itself as MariaDB driver, and it is unknown. You can immediately tell by the following error message in the log:
Not able to detect platform for vendor name [MariaDB[10.4.20-MariaDB, 10]]. Defaulting to [org.eclipse.persistence.platform.database.DatabasePlatform]. The database dialect used may not match with the database you are using. Please explicitly provide a platform using property "eclipselink.target-database".
There's a simple self signed SSL Certificate included in the Payara Micro, which works fine, unless, like me, you wish to use a genuine SSL Certificate.
The idea here is to expand on the command line (see above in run.sh) with SSL options, for example as follows:
I have a pressing need to allow files to be accessed that are static.
Unfortunately, there's a web application sitting on my root context ("/").
So I need to define alternate docroots1.
Unfortunately, this seems to be a specific Glassfish or Payara configuration.
As it is bad form, to put this in my code base (who knows where my wars will end up someday), it's better if I put it in the domain.xml file.
That way it's application server dependent, instead of war dependent.
However, I have found the following2:
virtual server's alternate docroots are considered only if a request does not map to any of the web modules deployed on that virtual server. A web module's alternate docroots are considered only once a request has been mapped to that web module.
Which means that an alternative docroot on the virtual server is basically unusable if you have a webapplication situated at your context root "/".
As an example consider the following:
Now, I don't much like putting pathnames in my web modules. So I was wondering if it's possible to change that by using Microprofile Config.
And it is3!
It will look something like this:
Other application servers have similar options (of which I know nothing).
In WildFly or the EAP4, it is possible to add another file handler and another location to the undertow subsystem in standalone.xml.
Interesting.
There's a tech preview in the latest Payara 5 application server1, that allows deploying Jakarta EE 9 applications.
The Eclipse Transformer basically auto transforms the classes and resource files back to the old packages, upon deployment.
So I decided to try running some of my stuff in the cloud, instead of having to hire a Virtual Machine type thing.
In order to have to limit my changes, I decided to go with Jelastic1.
I decided to try out hosting provider EAPPS2, because they are one of the providers of PaaS3 with Jelastic4.
They suggested I'd read up on [5].
Some requirements I'd like:
It supports all of those, and relieves me of some server administration and maintenance.
Just decided to do a followup on Adding MariaDB JDBC Connector to Payara 51.
I wanted to see if it was possibly very easy to do this using the command line.
The syntax:
Note the following:
Let's test it!
In case you wish to delete it, try:
Well, I already made a blogpost on letsencrypt certificates in payara1.
In this blogpost I mentioned a python script that automatically renews certificates for payara2. Unfortunately, it's not quite a perfect fit for me, as I do not run payara on port 80, which the script requires.
My setup has an nginx running on port 80, that basically forwards all requests to the https version of the website.
So I could simply turn off nginx, re-certify and turn nginx back on.
This simple bash script is as follows:
Running it will give you:
And your certificate is renewed. I am most pleased that this is soo easy in Payara/Glassfish.
In order to properly automate this, the master password must be stored somehow, and it's possible to do this via the --passwordfile=passwordfile.txt commandline parameter.
I found a good blogpost on how to do this at .Lost in Coding3.
And also the blogpost on [4] to get me started on how to do this.
Verifying that the keystore contains the appropriate stuff, can be done as follows:
To get more information, try:
Or for a specific alias:
Back from vacation.
Just quickly putting this in my notes:
How do I backup and restore my domain in Payara (or glassfish for that matter.)
It ends up in ~/mmud_backups/payara_backups/domain1/domain1_2019_01_27_v00001.zip
For automatic http->https redirection it is recommended to use Apache or Nginx in front of Payara to do the redirection, see [1].
I decided on using nginx for this2 3 4.
Before nginx, it looks like this:
Configuration is found in /etc/nginx/nginx.conf.
I changed it into something very simple:
Double checking:
Enabling automatic start and also starting nginx.
So, let's try seeing what the webserver now responds with:
In most cases the steps here are exactly the same as for the Glassfish application server1.
So, it might be a bit superfluous, but in the interest of being complete.
Bear in mind that when you change the master password, this password is also used to re-encrypt all your keystores!
I'm still using the Keystore Explorer for this. When you open up the cacerts.jks file, you'll see Let's Encrypt is already in there.
It's called 'letsencryptisrgx1 [jdk]'.
Interesting.
When attempting to restart the Payara domain, I used asadmin, and it immediately noticed that my keystore.jks file was changed. It showed me the certificate and asked:
Instead of having to restart your entire Payara Domain, apparently it is also possible to just turn your http-listeners on and off.
That's what this little bit here is all about.
The command "asadmin list-http-listeners", shows you the listeners.
In order to examine the http listeners fully, it is best to list the different properties, like so:
We can see which ones have ssl enabled, by using get:
As you've noticed above, the admin-listener has defined a redirect to sec-admin-listener.
Let's turn http-listener-2 off and on again. See if he picks up the new certificate.
Yes! We have a green lockicon in my Firefox bar! Success!
For some reason this little thing, also caused the new certificate to be picked up by the admin listener of the administration console.
Apparently it's possible to automate the whole thing, and there's a Python script in the Payara application server called payara5/bin/letsencrypt.py that let's you do that.
There's more information available on the website of Certbot on how to automate it, see in the references below.
It's as easy as pie.
The last part will probably require a payara application server reboot, though.
| Pool name | [obvious] |
| Resource Type | javax.sql.DataSource |
| Datasource classname | org.mariadb.jdbc.MariaDbDataSource |
Leave the rest as default.
| Name | Value |
|---|---|
| serverName | localhost |
| URL | jdbc:mariadb://localhost:3306/mmud |
| databaseName | mmud |
| user | username |
| password | itsasecret |
| Name | Value |
|---|---|
| JNDI Name | this is the name as the resource is defined in your application |
| Pool Name | the pool defined previously, it's a dropdown which is convenient. |
As written in my previous blogpost, I mentioned securing Glassfish.
Here are the steps I took. I plan to add more steps, if I find them.
so nobody can get shell access, unless you use another account1.
Also means if we need to access the account ourselves, we could run:
Go to Configuration -> server-config -> Network Config -> Network Listeners -> admin-listener.
Under the General tab, in the Address: field replace 0.0.0.0 to 127.0.0.1
Restart the server
You can access the admin console using an ssh tunnel6:
The first 4848 is the port of your homepc. The second 4848 is the remote port. And then connecting your browser to localhost:4848.
an application server has a very high number of open ports, many of them are only required for local access. Verifying this can be done with the following command:
| port | type | comments |
|---|---|---|
| 7676 | Message Queue Port | |
| 42853 | ||
| 44425 | ||
| 45613 | ||
| 8686 | Pure JMX Clients Port | |
| 4848 | the administration console | set it to localhost, and connect using ssh tunnel |
| 8080 | the normal http listener | this should be accessible from outside the server |
| 3700 | IIOP Port ("ORB listener 1") | |
| 8181 | the normal https listener | this should be accessible from outside the server |
| 41593 |
This can be either done by changing the ip address in the configuration of the glassfish server to 127.0.0.1 instead of 0.0.0.0.
But it could also be done by adding firewall rules, disallowing incoming traffic to ports you do not approve.
However, why not do both?
