Re: [glassfish-dev] migration from payara

[eduarddrenth@xxxxxxxxx]

Good to know, not very intuitive

On ma, 2025-06-02 at 16:45 +0200, Ondro Mihályi wrote:

Thanks for the explanation, Eduard. Now I understand.

To clarify, GlassFish provides full Jakarta Persistence 3.1, but this version doesn't introduce any new version of the schema document. So even with Jakarta Persistence 3.1, it's correct and portable to reference persistence_3_0.xsd and incorrect and non-portable to reference persistence_3_1.xsd, which officially doesn't exist. See the official list of schemas: https://jakarta.ee/xml/ns/persistence/

GlassFish is very strict and validates all descriptors against their schema during deployment, so it refuses to deploy an application that references a schema that doesn't exist. Payara also doesn't contain the persistence_3_1.xsd schema file: https://github.com/payara/Payara/tree/main/appserver/deployment/schemas/src/main/resources/glassfish/lib/schemas. But it's probably less strict about validation and allows deploying an app if it references it.

In the end, what you did is the correct approach with Jakarta Persistence 3.1. Not very intuitive, but it's correct to reference 3.0 schema. It doesn't mean that you downgrade Jakarta Persistence to 3.0, you still use 3.1, just the schema didn't change in 3.1 and the specification didn't produce a 3.1 version of the schema.

All the best,

Ondro Mihalyi

Director, Jakarta EE expert

OmniFish

On Mon, Jun 2, 2025 at 2:39 PM Eduard Drenth <eduarddrenth@xxxxxxxxx> wrote:

Thanks for you response and your your pointers. As for the persistence problem, if I have this in my persistence.xml:

sistence https://jakarta.ee/xml/ns/persistence/persistence_3_1.xsd"
version="3.1">

I get an exception, that disappears if I change into

sistence https://jakarta.ee/xml/ns/persistence/persistence_3_0.xsd"
version="3.0">

 

Regards, Eduard 

On Mon, Jun 2, 2025 at 1:58 PM Ondro Mihályi <mihalyi@xxxxxxxxxxx> wrote:

Hi Eduard,

Thanks for trying out GlassFish and providing us feedback. 

It looks like you hit some real issues with configuring GlassFish in Docker and we'd like to fix them ASAP. In one case, the equals sign in the ALIAS definition seems to conflict with the equals sign used to separate key and value in properties. Another case is that, naturally, the DB is not available when configuring the Docker image, and there's no point in validating the connection.

While we at OmniFish have already started looking into how to fix/improve these 2 issues, here's what I recommend:

• Create issues on GlassFish tracker for each of these problems: https://github.com/eclipse-ee4j/glassfish/issues. This will simplify tracking fixes/improvements for you and also for us
• Try out Embedded GlassFish instead of GlassFish server. It can be started from the same Docker image. IT allows configuring the server at startup, with a properties file, so you can create the datasource at startup, when the DB should be already available. Here's documentation and here's a 5-minute video explaining how to run and configure Embedded GlassFish: https://www.youtube.com/watch?v=Sri-D7LgcEo.

About Persistence 3.1 not available - I'm not sure what you mean. GlassFish 7 supports Jakarta EE 10, which includes Persistence 3.1. I'm curious why you think that Persistence 3.1 is not available in GlassFish 7.

All the best,

Ondro Mihalyi

Director, Jakarta EE expert

OmniFish

On Fri, May 30, 2025 at 3:13 PM eduarddrenth--- via glassfish-dev <glassfish-dev@xxxxxxxxxxx> wrote:

Dear all,

Don't know is this is the right list to post about migrating from payara to omnifish. Please point me to the right list in that case.

I am Eduard Drenth, working at the Fryske Akademy where we build jsf (primefaces) applications and graphql services.

We run these on payara server web profile community edition and are very satisfied with that. See also https://www.payara.fish/payara-vs-the-competition/#Glassfish

But it looks like payara is slowly but gradually moving paying less attention to the community edition. A good time to take a look at alternatives.

Since our applications do not depend on payara specific code, migrating to omnifish  should be doable. And so it was, in about a day I had one of the more complex apps running.

I noticed some things though that I am not very happy with, found my way around those, but perhaps there are better solutions.

- Persistence 3.1 not available => downgraded to 3.0

- When using the below script 

create-password-alias ldappw

create-auth-realm --classname=com.sun.enterprise.security.auth.realm.ldap.LDAPRealm --property='directory="ldap://${LDAPHOST}:389":assign-groups=gast:base-dn="DC=poartetaitfrysk,DC=fryske-akademy,DC=nl":jaas-context=ldapRealm:search-bind-dn="CN=read,DC=fryske-akademy,DC=nl":search-bind-password=${ALIAS=ldappw}:group-search-filter="(&(objectClass=groupOfNames)(member=%d))"' --target=server-config auth

-  ${LDAPHOST} isn't substituted by a system property from the environment

- the password alias gives a syntax error (\= solves that) and the alias is not substituted

- Password aliases in jdbc pool needs ugly escaping

- ${ALIAS\\=stdwdbpw}

- “--skipdsfailure” true not available so database needs to be running when deploying during docker build

Especially the second and the last issue are important for me. The second because it forces me to have passwords in my image, the last because it complicates building docker images.

I am curious to any comments or experiences.

Regards, Eduard

_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev