I guess your answer will be that is that Microprofile and
Glassfish are different things ;-)
Well, not exactly ;) The reason is more that MicroProfile 5 is needed for Jakarta EE 9, since Jakarta EE 9 has the namespace change (javax to jakarta), and MicroProfile 4 is javax. MicroProfile 5 is jakarta, but MicroProfile 5 APIs were released only weeks ago, and at the moment only Open Liberty has implemented them. SmallRye and Helidon, for instance, have recent PRs or snapshots, but no release out yet.
In other words, it's still not really possible to actually bundle (and integrate) MicroProfile with GlassFish, since there simply are no official MicroProfile 5 components out yet.
Sure, but how can we improve
the situation for new developers who want to test Jakarta EE 9? In
my eyes this is an unsatisfactory situation now that they can't
find a Docker image.
It looks to me that Wildfly wildfly-preview-26.0.0-final is
currently the only runtime providing the new namespaces and
delivering all the promised features (including microprofile 3.2).
But also Wildfly is not offering a Docker Image for the preview
version.
To be clear, I don't blame you or the Glassfish project here. I
just want to point out that the situation is really strange. You
all did so much great work behind the scene. But for nearly one
year now we (the normal Jakarta EE developers who are migrating
there Java EE projects) have no chance to get a working Jakarta EE
9 Docker image out of the box.
It's more or less as intended, as Jakarta EE 9 is as mentioned an intermediate release so tools and libraries can get their support for the jakarta.* namespace done. Now it maybe wasn't expected that something like MicroProfile would be so slow to adopt this, but here we are.
Also, some of servers you mentioned are actually still on Jakarta EE 8, which makes it hard for them to release a Jakarta EE 9 docker image.
You mentioned that EE 9 is just an intermediate version. But
what did this mean? Will it take much more time now until 9.1 is
available? Or will be version 10 the goal? It doesn't make sense
to push the specification if there are no runtime environments
available.
The intermediate version means Jakarta EE 9/9.1 is essentially Jakarta EE 8 with ONLY the namespace change. The difference between Jakarta EE 9 and 9.1 is JDK 11 support. It weren't supposed to be two versions, but we ran out of time for Jakarta EE 9 to have the TCK support JDK 11, to postponed that to an extra release that we called 9.1.
Jakarta EE 9 was released ahead of Jakarta EE 10 to prepare people (mostly library and tool vendors) for the namespace change. For instance, OmniFaces has been using it to prepare a Jakarta namespace version, and we've been pushing other projects. Some of them are older and mature projects that don't move as fast anymore, but one by one jakarta namespace versions are dripping in. So by the time EE 10 turns around, the hope is that most projects will have had a chance to release a jakarta namespace version.
Had we introduced the namespace change together with a whole lot of new features, then the feeling was that many users would not have been able to use them, since tools and libraries would not have been prepared.
Why I'm riding around on it has the following practical reason. I
am currently in a larger enterprise project in which the question
is asked whether microservices should be developed with SpringBoot
or with Jakarta EE. What would you advise here? Go ahead with
Jakarta EE 8 (meaning Java EE8)?
I'm of course very biased ;) For a project that has to start *now* and has to use MicroProfile it's indeed mostly Jakarta EE 8, though you could look at Open Liberty which has the 22.0.0.1-beta out and assume that by the time your product goes to production a final version of Liberty will be out (as well as, likely, other products implementing MicroProfile 5).
In the meantime we'll be looking at getting the GlassFish docker image up at the expected location.
I wonder why there is no Docker image for Glassfish
available? Docker makes it more convenient for users to
get started. The official Docker repo is totally outdated
(https://hub.docker.com/_/glassfish).
Ok, there are Jakarta EE8 images from Payara and Wildfly
available, but still only for Jakarta 8 and nothing
working with Jakarta EE9 (including JAX-RS and EJBs)
Within the Eclipse Jakarta EE project ther is one version
after the other being discussed - we are already at Jakarta
EE 10 - but there is still no official server for Jakarta
EE9 available. If Payara and Wildfly are for what reason
ever not allowed to publish Jakarta EE9 Severs on Docker Hub
than at least a Glassfish Server would be great.
If you want to start a new Project with Jakarta EE9 you
have no official Docker Image at all. Why?? It looks like
the community wants to do everything to ensure that
Jakarta 9 does not establish itself as a new platform.
What is your opinion about this situation?
p.s:
The only way I solved this for my current dev project, is
building my own Jakarta EE9 Docker image by downloading
the wildfly-preview-26.0.0.Final :
###################################################################
# We are building our own jakarta 9 sever
#
# See: https://github.com/jboss-dockerfiles/wildfly
FROM jboss/base-jdk:11
# Set the WILDFLY_VERSION env variable
ENV WILDFLY_VERSION 26.0.0.Final
ENV JBOSS_HOME /opt/jboss/wildfly
USER root
# Add the WildFly distribution to /opt, and make wildfly
the owner of the extracted tar content
# Make sure the distribution is available from a
well-known place
RUN cd $HOME \
&& curl -L -O
https://github.com/wildfly/wildfly/releases/download/$WILDFLY_VERSION/wildfly-preview-$WILDFLY_VERSION.tar.gz
\
&& tar xf
wildfly-preview-$WILDFLY_VERSION.tar.gz \
&& mv $HOME/wildfly-preview-$WILDFLY_VERSION
$JBOSS_HOME \
&& rm wildfly-preview-$WILDFLY_VERSION.tar.gz
\
&& chown -R jboss:0 ${JBOSS_HOME} \
&& chmod -R g+rw ${JBOSS_HOME}
# Ensure signals are forwarded to the JVM process
correctly for graceful shutdown
ENV LAUNCH_JBOSS_IN_BACKGROUND true
USER jboss
# Expose the ports in which we're interested
EXPOSE 8080
EXPOSE 9990
COPY ./target/*.war
/opt/jboss/wildfly/standalone/deployments/
# Run with microprofiles
CMD ["/opt/jboss/wi
###################################################################
Regards
Ralph
--
Imixs Software Solutions GmbH Web:www.imixs.comPhone: +49 (0)89-452136 16 Timezone: Europe/Berlin - CET/CEST Office: Agnes-Pockels-Bogen 1, 80992 München
Registergericht: Amtsgericht Muenchen, HRB 136045
Geschaeftsführer: Gaby Heinle u. Ralph Soika
Imixs is an open source company, read more: www.imixs.org