GlassFish Embedded – a simple way to run Jakarta EE apps(omnifish.ee)
omnifish.ee
GlassFish Embedded – a simple way to run Jakarta EE apps
https://omnifish.ee/2023/09/15/glassfish-embedded-a-simple-way-to-run-jakarta-ee-apps/
5 comments
Glassfish and Java gets an undeservadly bad wrap, IMO. It comes with so much enterprise goodies out of the box - TLS, load balancing, DB connection mgmt, monitoring with Grafana, scalability over multiple cores, good performance in general, easy filters for API calls, and more. Slow load time, yes. But it's worth it for the other features, imo.
I cannot speak for anyone else, but when I was pretty young in my career, my first "real" job was doing ColdFusion. Even at the time (early 2012), ColdFusion was largely dead, and PHP had sucked up most of its potential audience, and I was looking to learn a new platform to future-proof myself and make more money.
I had learned the core Java language years before and I knew Java was "enterprise", so I figured that might be a good spot to start, so I bought a book on J2EE development with GlassFish, downloaded all the appropriate SDKs, and after multiple days of spending nearly every minute I could on it, I got something not quite as good as something I could have whipped together in ColdFusion (or Railo/OpenBlueDragon) at the time.
I thought that maybe I was just stupid, and I suppose the jury's still out on that, but shortly after that experience I found a Django tutorial series on YouTube and went through that, and felt like I was productive almost immediately. I was able to build "real" stuff in a matter of a few hours instead of days, and it didn't feel like it was more chaotic than the stuff I had done with J2EE. I then did a similar experiment with Rails, and had the same effect: me being an idiot is not solely to blame for me not really grokking J2EE. Eventually I learned Node.js and did that for a few years, until I was able to (thankfully) transition out of "web development" entirely.
Personally, while I'm sure the Glassfish server, and maybe J2EE has its merits, I don't think they're worth the headaches I went through to try learning it. Java has plenty of cool frameworks now (e.g. Play, vert.x), but I've never even tried using those with Glassfish.
I had learned the core Java language years before and I knew Java was "enterprise", so I figured that might be a good spot to start, so I bought a book on J2EE development with GlassFish, downloaded all the appropriate SDKs, and after multiple days of spending nearly every minute I could on it, I got something not quite as good as something I could have whipped together in ColdFusion (or Railo/OpenBlueDragon) at the time.
I thought that maybe I was just stupid, and I suppose the jury's still out on that, but shortly after that experience I found a Django tutorial series on YouTube and went through that, and felt like I was productive almost immediately. I was able to build "real" stuff in a matter of a few hours instead of days, and it didn't feel like it was more chaotic than the stuff I had done with J2EE. I then did a similar experiment with Rails, and had the same effect: me being an idiot is not solely to blame for me not really grokking J2EE. Eventually I learned Node.js and did that for a few years, until I was able to (thankfully) transition out of "web development" entirely.
Personally, while I'm sure the Glassfish server, and maybe J2EE has its merits, I don't think they're worth the headaches I went through to try learning it. Java has plenty of cool frameworks now (e.g. Play, vert.x), but I've never even tried using those with Glassfish.
If you used J2EE in 2012, did you happen to get that idea from a very old book?
J2EE ended in 2005. So if you used it in 2012 it may explain something.
J2EE ended in 2005. So if you used it in 2012 it may explain something.
Sorry, I'm using J2EE when I really meant JavaEE. A lot of message boards and whatnot at the time still called it "J2EE" so that's what I remembered it as. I think the version was 6 at the time?
Java EE 6 was pretty decent really. It came with JAXRS, CDI, Bean Validation and JSF 2.
I'm sure it's fine once you learn it all, and I'd probably be able to pick it up quicker now since I have a decade more of experience, but my difficulties with it was not for lack of trying on my end. I found a lot of the terminology difficult to work with, and it felt like doing anything required me to touch a million files across a thousand folders.
As I said, I don't really do web stuff anymore; when I need HTTP nowadays I generally want something a bit quicker and lower level than a full-on web framework.
As I said, I don't really do web stuff anymore; when I need HTTP nowadays I generally want something a bit quicker and lower level than a full-on web framework.
I think bad rep is partly because Spring (and Spring Boot), Quarkus, etc. don’t need any Glassfish or Websphere and can be deployed barebones or run in Docker containers without hassles of having to manage “application servers”.
Isn't this very article about directly running GlassFish from Java SE?
You could also say btw that GlassFish doesn't need any WebSphere or JBoss. Or you could say that WebSphere doesn't need a JBoss or GlassFish.
Also, WebSphere is legacy within IBM. Their new and much much better server for some time is called Open Liberty. It uses some components from WebSphere, but in a highly modularised way, and the overal runtime is totally different.
You could also say btw that GlassFish doesn't need any WebSphere or JBoss. Or you could say that WebSphere doesn't need a JBoss or GlassFish.
Also, WebSphere is legacy within IBM. Their new and much much better server for some time is called Open Liberty. It uses some components from WebSphere, but in a highly modularised way, and the overal runtime is totally different.
Maybe you are right. But to me, JavaEE somehow associates with managing applications through the Application Server’s admin panel, registering EJBs with deployment descriptors, etc.
> JavaEE somehow associates with managing applications through the Application Server’s admin panel,
That is a wrong association really.
Even in the really old versions of GlassFish and JBoss such an admin panel was just an extra (I hate them too, btw).
You could always, Tomcat style, just copy your .war to a deployment folder. If you wanted, you could also zip up GlassFish with the war already in that folder and deploy that.
> registering EJBs with deployment descriptors
That was required for the last time in J2EE 1.4, from 2003 or so. Already in Java EE 5 from 2005 that wasn't necessary anymore. Also don't forget that spring beans needed to be registered in very similar deployment descriptors (huge xml files) just as well.
That is a wrong association really.
Even in the really old versions of GlassFish and JBoss such an admin panel was just an extra (I hate them too, btw).
You could always, Tomcat style, just copy your .war to a deployment folder. If you wanted, you could also zip up GlassFish with the war already in that folder and deploy that.
> registering EJBs with deployment descriptors
That was required for the last time in J2EE 1.4, from 2003 or so. Already in Java EE 5 from 2005 that wasn't necessary anymore. Also don't forget that spring beans needed to be registered in very similar deployment descriptors (huge xml files) just as well.
Why would you ever run Jakarta EE nowadays instead of the defacto standard Spring Boot or it‘s high performance alternatives (vertx, etc.)?
How do you compete with the amount and quality of resources for spring, the wealth of spring integrated third party libraries and its sheer battletestedness and constant updates?
The upcoming spring boot 3.2 already has first class virtual thread support out of the box and you can AOT compile it with graal!
How do you compete with the amount and quality of resources for spring, the wealth of spring integrated third party libraries and its sheer battletestedness and constant updates?
The upcoming spring boot 3.2 already has first class virtual thread support out of the box and you can AOT compile it with graal!
Tomcat and Jetty are, still, the largest Servlet providers and actively maintained.
Glassfish, Wildfly (what was JBoss), Apache TomEE, Payara (Glassfish fork), Open Liberty are all active and maintained OSS EE servers.
Then there are the commercial only servers Weblogic and WebSphere and likely others.
The Jakarta EE world is vibrant and robust, with a lot of the activity at the Mircoprofile and container level, since most of the core capabilities are quite mature. It's no longer some monster EE server running everything, necessarily. It supports all sorts of scenarios. After the name fork from Java EE to Jakarta EE, and the transfers of everything to Eclipse, the paperwork is finally slowing down and momentum building back up.
Having written EE code for over 20 years, across servers, platforms, porting code, I have long appreciated what JEE brought to the table.
Spring is a powerhouse, make no mistake. They have done a lot of innovation, and the EE standards are absolutely a reflection on things they brought to the table first along with insights from other parties.
But they're just one implementation. The core JEE services have a wide array of implementations all with their own quirks and benefits.
The folks working within the JEE standard track help lift all boats as, in time, all of the implementations catch up to the latest specifications. So it's a bustling and competitive space, without necessarily being completely wild west. The gives a lot of power to folks developing on top of it, with a platform offering reasonable stability while still offering diversity of implementations.
Glassfish, Wildfly (what was JBoss), Apache TomEE, Payara (Glassfish fork), Open Liberty are all active and maintained OSS EE servers.
Then there are the commercial only servers Weblogic and WebSphere and likely others.
The Jakarta EE world is vibrant and robust, with a lot of the activity at the Mircoprofile and container level, since most of the core capabilities are quite mature. It's no longer some monster EE server running everything, necessarily. It supports all sorts of scenarios. After the name fork from Java EE to Jakarta EE, and the transfers of everything to Eclipse, the paperwork is finally slowing down and momentum building back up.
Having written EE code for over 20 years, across servers, platforms, porting code, I have long appreciated what JEE brought to the table.
Spring is a powerhouse, make no mistake. They have done a lot of innovation, and the EE standards are absolutely a reflection on things they brought to the table first along with insights from other parties.
But they're just one implementation. The core JEE services have a wide array of implementations all with their own quirks and benefits.
The folks working within the JEE standard track help lift all boats as, in time, all of the implementations catch up to the latest specifications. So it's a bustling and competitive space, without necessarily being completely wild west. The gives a lot of power to folks developing on top of it, with a platform offering reasonable stability while still offering diversity of implementations.
It's the same thing with Hibernate.
Hibernate is an (extended) implementation of JPA. But that's because Hibernate innovated so much that they forced JPA to be better.
Leaving aside the ORM-love-hate discussion, you will do fine if you go with a JPA approach using Hibernate as the implementation. You should (theoretically) painlessly switch to another implementation.
Hibernate is an (extended) implementation of JPA. But that's because Hibernate innovated so much that they forced JPA to be better.
Leaving aside the ORM-love-hate discussion, you will do fine if you go with a JPA approach using Hibernate as the implementation. You should (theoretically) painlessly switch to another implementation.
Actually, a friend just went through this. A long time user of Glassfish/Payara and EclipseLink. But he wanted to do some specific things with multi-tenancy that had better support in Hibernate for the way he wanted to do it. EclipseLink has multi-tenant extensions as well, but didn't support exactly what he wanted to do. So he switched. He didn't have to toss out his platform implementation (Payara Microprofile I believe) just the JPA implementation it was using.
All of his other JPA stuff ported over, the multi-tenancy is on the edge of it. The whole point is most of his code is ignorant of the multi-tenant aspect. But, also, the JPA spec itself is silent on multi-tenancy, so it's no surprise that the implementors are trying their own approaches. I have to assume that whenever the next JPA spec comes out, it will take inspiration from all of these different implementations and come up with a mechanism to standardize support for them.
So, while he's now "locked in" to the Hibernate implementation of JPA, he didn't have to toss out JPA itself, or his platform. If/when JPA catches up, he may well be able to have the option to switch away from Hibernate if he chooses.
All of his other JPA stuff ported over, the multi-tenancy is on the edge of it. The whole point is most of his code is ignorant of the multi-tenant aspect. But, also, the JPA spec itself is silent on multi-tenancy, so it's no surprise that the implementors are trying their own approaches. I have to assume that whenever the next JPA spec comes out, it will take inspiration from all of these different implementations and come up with a mechanism to standardize support for them.
So, while he's now "locked in" to the Hibernate implementation of JPA, he didn't have to toss out JPA itself, or his platform. If/when JPA catches up, he may well be able to have the option to switch away from Hibernate if he chooses.
Spring is using Jakarta. And not everyone prefers a horribly over-engineered and slow consultantware, so there’s room for other frameworks.
Agree. And not everyone is fan of converting compile time errors into runtime exceptions which spring considers as great benefit.
Thank you for term consultantware. I am hearing it first time and it is great.
Thank you for term consultantware. I am hearing it first time and it is great.
Well yes, but that's because Spring is built on top of Java Servlets.
I wonder if other Java frameworks have a different approach to serve web content without the need of servlets.
I wonder if other Java frameworks have a different approach to serve web content without the need of servlets.
Servlets and other Jakarta standards.
Most Java frameworks are at least compatible with the micro-profile subset.
Most Java frameworks are at least compatible with the micro-profile subset.
> Why would you ever run Jakarta EE nowadays instead of the defacto standard Spring Boot
Didn't that exact thinking got us into trouble over and over?
Why would you ever use any other browser instead of browser X? What follows is the browser X getting 99% of the market, and the vendor of X becoming lazy and ruining X completely.
> and you can AOT compile it with graal!
You can do that already (and have been able to do so for some time) with Quarkus (a partial EE implementation, related to JBoss/WildFly) and things like Piranha Cloud.
Helidon (another partial EE implementation) has been working on virtual thread support with a custom HTTP engine build in cooperation with the JDK team.
Didn't that exact thinking got us into trouble over and over?
Why would you ever use any other browser instead of browser X? What follows is the browser X getting 99% of the market, and the vendor of X becoming lazy and ruining X completely.
> and you can AOT compile it with graal!
You can do that already (and have been able to do so for some time) with Quarkus (a partial EE implementation, related to JBoss/WildFly) and things like Piranha Cloud.
Helidon (another partial EE implementation) has been working on virtual thread support with a custom HTTP engine build in cooperation with the JDK team.
I haven't read the article but if they are referring to https://microprofile.io/ then it's a sensible choice. But if you're going down that route I would recommend something like Micronaut/Quarkus/Helidon/etc with native image compilation. Spring does native image compilation now too, but I personally would lean towards more the more lightweight frameworks
From where I stand Spring Boot is slow and buggy piece of crap. Now Jakarta EE could be same as I can't even open the posted link. Perhaps site is made on JakartaEE.
Constant update is needed because constant security issues keep popping up and crappy APIs need constant refactoring. See RestTemplate vs WebClient vs RestClient. Writing a decent HTTP client seems impossible for them and keep getting replaced with new API and its not even like HTTP is changing every few months.
Constant update is needed because constant security issues keep popping up and crappy APIs need constant refactoring. See RestTemplate vs WebClient vs RestClient. Writing a decent HTTP client seems impossible for them and keep getting replaced with new API and its not even like HTTP is changing every few months.
I've never appreciated the need for Spring. I'm told it is something enterprise-y. The typical response here will claim that for anything other than a hobby project you need it.
The JVM is still a great platform for web backends. Most everything I need can be accomplished with a few libs, the base Servlet api and JSTL. The rest of the front end stuff can be handled by providing JSON versions of the same Objects used in the project. A little vanilla JS to re-populate the relevant elements isn't a big deal. Yes, there is a little duplication here if you want the JSP/JSTL version of the page to render directly. As an alternative, you can render from JS with the inlined JSON blob of the page state.
Like this I can consistently deliver performant sites which are 1/100th to 1/10th page size of the latest hype framework. Resource usage is tiny. Time to first byte is instant, even from the DB. Context reloads are fast and there's no mile long Spring stack traces.
It is unfortunate, because many people equate Spring and Spring Boot with Java webdev. Overall it has given the tech a bad name. Jetty is less of an xml config hell than GlassFish as well. KISS principles avoid most of these problems.
The JVM is still a great platform for web backends. Most everything I need can be accomplished with a few libs, the base Servlet api and JSTL. The rest of the front end stuff can be handled by providing JSON versions of the same Objects used in the project. A little vanilla JS to re-populate the relevant elements isn't a big deal. Yes, there is a little duplication here if you want the JSP/JSTL version of the page to render directly. As an alternative, you can render from JS with the inlined JSON blob of the page state.
Like this I can consistently deliver performant sites which are 1/100th to 1/10th page size of the latest hype framework. Resource usage is tiny. Time to first byte is instant, even from the DB. Context reloads are fast and there's no mile long Spring stack traces.
It is unfortunate, because many people equate Spring and Spring Boot with Java webdev. Overall it has given the tech a bad name. Jetty is less of an xml config hell than GlassFish as well. KISS principles avoid most of these problems.
Exactly, I believe almost all of the Jakarta EE standard is supported on Spring Boot. Micronauts is another framework.
I do know some enterprises that still run JBoss so it’s not entirely like no one would use this. However, they are all in the process of refactoring for the cloud off of JBoss JEE.
I do know some enterprises that still run JBoss so it’s not entirely like no one would use this. However, they are all in the process of refactoring for the cloud off of JBoss JEE.
It feels very much like the spring framework does its best to hide JEE/Jakarta being its base since ages. Most JEE/Jakarta interfaces are completely wrapped in layers of Spring libraries.
The average, modern and new Spring Boot developer probably doesn't even know what an application server, servlets and jsp are anymore. And that's ok.
The average, modern and new Spring Boot developer probably doesn't even know what an application server, servlets and jsp are anymore. And that's ok.
Yes, platform/vendor lock in is a staple of the Java ecosystem. Why @Get when you can @RequestMapping? I actually prefer Spring's style here as the annotations in JEE are too generalized to be of use in a large codebase without having type conflicts due to naming.
Exactly :D people today don't even realize Spring was born as a Java beans implementation and still implements much of JEE (e.g. https://docs.spring.io/spring-framework/reference/core/beans..., https://docs.spring.io/spring-framework/reference/core/valid...), but kept adding features on top (many of which were incorporated in JEE later, to their credit) to the point people don't even know that.
From Wikipedia: "The first version was written by Rod Johnson, who released the framework with the publication of his book Expert One-on-One J2EE Design and Development in October 2002"
From Wikipedia: "The first version was written by Rod Johnson, who released the framework with the publication of his book Expert One-on-One J2EE Design and Development in October 2002"
Just goes to show, if you start a software project, by the time it turns 10, an entire ecosystem around it will form. By the time it turns 20, people will forget why it was started in the first place, knowing it only as their Tao.
Also, for a very long time, Spring Security had native integration connectors for JBoss and maybe some other EE servers. They only removed these much later.
I would say that application servers with EJB and JMS are a good environment for implementing microservices. Everything uses less resources (memory) and communication is much more efficient, plus everything is written in Java, which makes it easier to maintain consistency.
Websphere 5 in 2005 is a pleasure versus yaml spaghetti of Kubernetes with WASM containers.
Nah, the old EJBs had a terrible programming interface. JavaEE 6 introduced a lot of good changes, but it was too late to convince people to switch back from Spring. To me it's like people abandoned JavaEE because it was hard to write fairly simple applications using EJBs (because it was) and switched to Spring, and then started writing large monoliths in Spring and realized they need to break them up into modules, so they invented microservices, but implemented them as standalone Spring Boot instances... when now it would be easier to go back to EJB + JMS. Microsoft has quite a similar "technology" called Microsoft Orleans, but it doesn't get much attention.
> Last worked in EJBs in 2002. There’s still a bad taste in my mouth.
Although EJBs got improved so much in 2006 it was nearly a different technology, EJBs by themselves have been largely deemphasized in Jakarta EE. The main bean model is CDI and has been for some time.
Although EJBs got improved so much in 2006 it was nearly a different technology, EJBs by themselves have been largely deemphasized in Jakarta EE. The main bean model is CDI and has been for some time.
By my earlier statement I meant that the old JavaEE application servers with standalone EJBs deployed as ejb-jars and JMS were good infrastructure while now JavaEE tries to become the next SpringBoot.
In .Net I would prefer to have application servers instead of an operating system performing the same function. Blazor is nicer to use than JSF and Entity Framework than JPA.
Because it's tries to follow trends.
The tech is not driving sales guys, they are driving the tech.
Except Spring also has its own way of doing beans, people keep forgeting about it.
By the way, Orleans powers Halo servers.
I stand by my comment, rather Websphere than Kubernets/YAML/WASM.
By the way, Orleans powers Halo servers.
I stand by my comment, rather Websphere than Kubernets/YAML/WASM.
> Except Spring also has its own way of doing beans, people keep forgeting about it.
“Bean” is a broad term. It certainly didn't have a container to run standalone modules as ejb-jars. Spring is just a framework, not an application server with isolated classloaders that the JaveEE application servers were based on.
> I stand by my comment, rather Websphere than Kubernets/YAML/WASM. Agree Agree
“Bean” is a broad term. It certainly didn't have a container to run standalone modules as ejb-jars. Spring is just a framework, not an application server with isolated classloaders that the JaveEE application servers were based on.
> I stand by my comment, rather Websphere than Kubernets/YAML/WASM. Agree Agree
> Spring is just a framework, not an application server with isolated classloaders that the JaveEE application servers were based on.
But Spring Boot with its embedded HTTP server and internal infrastructure is certainly more than just a framework. It has its own class loade (launchedurlclassloader). See https://dzone.com/articles/spring-boot-classloader-and-class...
Piranha Cloud on the other hand runs Jakarta EE code without any class loader of its own. See https://blogs.oracle.com/javamagazine/post/you-dont-always-n...
But Spring Boot with its embedded HTTP server and internal infrastructure is certainly more than just a framework. It has its own class loade (launchedurlclassloader). See https://dzone.com/articles/spring-boot-classloader-and-class...
Piranha Cloud on the other hand runs Jakarta EE code without any class loader of its own. See https://blogs.oracle.com/javamagazine/post/you-dont-always-n...
Last worked in EJBs in 2002. There’s still a bad taste in my mouth.
For starters, many of the Spring stuff is actually based on Jakarta EE as well.
Java's been my bread and butter for three decades now, and I often wonder this myself. Virtually all of the job postings that I ever see are using Spring, and I don't have a single known person in my professional network who is using Jakarta EE anywhere. MAYBE some proof-of-concepts here and there with Quarkus, which I believe is technically a spin on Jakarta EE "microprofile". But no one is running an old-school WebLogic, WebSphere, Glassfish, etc application server. My sense is that this is confined to legacy systems in very large companies, and MAYBE a bit of greenfield popularity in Europe.
This question gets very confusing though, because I believe that a lot of developers love to purposefully obfuscate it. The terms "Java EE" and now "Jakarta EE" can be looked at in two different ways:
1. A collection of various API standards, that may be implemented to some degree and/or extended by various libraries.
2. Developing against an all-inclusive application server such as WebLogic, WebSphere, Glassfish, etc... that comes with implementations of all those API's. Where your application is configured to rely on those implementations that come with the application server, rather than bundling up its own dependencies itself.
The thing is, when people ask "Who uses Jakarta EE?", they are almost always thinking about #2 there. Who in 2023 is still developing to WebLogic, WebSphere, Glassfish etc as a target environment, and relying on the library implementations that come with that server?
I THINK the answer to that is "pretty few people".
However, people who have pinned their careers to those stacks, and/or sticklers who love to be contrarian, often bait-and-switch with the #1 definition above. They will point out that Spring uses some implementations of some of those Jakarta EE specs, and therefore "Spring IS Jakarta EE" or at least "Spring depends on Jakarta EE".
That's not really good faith, though. One of Spring's strengths is that it can INTEGRATE with virtually everything. But that doesn't mean that much of anything is a requirement for using Spring. For example:
* By default, a Spring Boot application with the "web" starter pack embeds Tomcat for HTTP services. So people can say that's "using the Servlet spec". Except that Spring doesn't necessarily have to use Servlets. You can override that Tombcat dependency with Netty, which is not Servlet-based and not part of Jakarta EE at all, and probably not even have to change any of your code. The old-school Servlet spec is neither here nor there to writing a modern Spring controller class.
* By default, if you use Spring Data with the "JPA" starter, then you are using Hibernate, which is an implementation of the JPA spec. However, you certainly don't HAVE to. There are flavors of Spring Data that provide similar functionality, backed by plain JDBC. Not to mention spins for MongoDB, Redis, and other databases that are completely outside the scope of Jakarta EE.
So on and so forth. A Spring application MIGHT be using a Jakarta EE API somewhere, but by no means does it HAVE to, and they often don't. So in my opinion, it's extremely disingenuous to take that "#1" definition, of Jakarta EE being a loose basket of API's, and use that to give people the impression that the "#2" definition of Jakarta EE as an old school fully-integrated app server is more widely used today than it actually is.
This question gets very confusing though, because I believe that a lot of developers love to purposefully obfuscate it. The terms "Java EE" and now "Jakarta EE" can be looked at in two different ways:
1. A collection of various API standards, that may be implemented to some degree and/or extended by various libraries.
2. Developing against an all-inclusive application server such as WebLogic, WebSphere, Glassfish, etc... that comes with implementations of all those API's. Where your application is configured to rely on those implementations that come with the application server, rather than bundling up its own dependencies itself.
The thing is, when people ask "Who uses Jakarta EE?", they are almost always thinking about #2 there. Who in 2023 is still developing to WebLogic, WebSphere, Glassfish etc as a target environment, and relying on the library implementations that come with that server?
I THINK the answer to that is "pretty few people".
However, people who have pinned their careers to those stacks, and/or sticklers who love to be contrarian, often bait-and-switch with the #1 definition above. They will point out that Spring uses some implementations of some of those Jakarta EE specs, and therefore "Spring IS Jakarta EE" or at least "Spring depends on Jakarta EE".
That's not really good faith, though. One of Spring's strengths is that it can INTEGRATE with virtually everything. But that doesn't mean that much of anything is a requirement for using Spring. For example:
* By default, a Spring Boot application with the "web" starter pack embeds Tomcat for HTTP services. So people can say that's "using the Servlet spec". Except that Spring doesn't necessarily have to use Servlets. You can override that Tombcat dependency with Netty, which is not Servlet-based and not part of Jakarta EE at all, and probably not even have to change any of your code. The old-school Servlet spec is neither here nor there to writing a modern Spring controller class.
* By default, if you use Spring Data with the "JPA" starter, then you are using Hibernate, which is an implementation of the JPA spec. However, you certainly don't HAVE to. There are flavors of Spring Data that provide similar functionality, backed by plain JDBC. Not to mention spins for MongoDB, Redis, and other databases that are completely outside the scope of Jakarta EE.
So on and so forth. A Spring application MIGHT be using a Jakarta EE API somewhere, but by no means does it HAVE to, and they often don't. So in my opinion, it's extremely disingenuous to take that "#1" definition, of Jakarta EE being a loose basket of API's, and use that to give people the impression that the "#2" definition of Jakarta EE as an old school fully-integrated app server is more widely used today than it actually is.
I don't know, but maybe these application servers are certified in some way so that they can be used in the right places that require certification (I'm guessing, not sarcastic)? Which would make sense, but some people host applications written in Spring on JavaEE application servers, which is like adding ketchup to a Greek salad.
For me, Java EE standardization makes absolutely no sense. You code to common programming interfaces when you need to break them down to use the underlying implementations.
Now I code in .Net and at least I don't have such dilemmas.
There's a 3. really, which are products using Jakarta EE APIs extensively (maybe even all of them), but aren't application servers.
Oracle themselves (they create such runtime, called Helidon) have a blog post out about just that:
https://blogs.oracle.com/javamagazine/post/you-dont-always-n...
Oracle themselves (they create such runtime, called Helidon) have a blog post out about just that:
https://blogs.oracle.com/javamagazine/post/you-dont-always-n...
[deleted]
> Error establishing a database connection
Can't tell if is some kind of meta humor ...
Fortunately, some kind soul submitted it to Wayback: http://web.archive.org/web/20230915132938/https://omnifish.e...
Can't tell if is some kind of meta humor ...
Fortunately, some kind soul submitted it to Wayback: http://web.archive.org/web/20230915132938/https://omnifish.e...
[deleted]
LOL - I wondered if I had just travelled back to 2001 when I saw this.
In 2001 package names were different…
And instead of annotations, you had to write lots of XML to build an application.
> LOL - I wondered if I had just travelled back to 2001 when I saw this.
In 2001 the product wasn't called GlassFish yet, and even the Sun ONE Application Server name wasn't there yet.
The name GlassFish wasn't introduced until 2005 and had its first release the year after that.
In 2001 the product wasn't called GlassFish yet, and even the Sun ONE Application Server name wasn't there yet.
The name GlassFish wasn't introduced until 2005 and had its first release the year after that.
[deleted]