For the most part, maybe like 99%, the Jakarta APIs are agnostic of what the deployment model is. They are APIs to validate input, service HTTP requests, store data in databases, look up roles, connect to identity providers, etc etc.
> I thought that was Tomcat or was Tomcat just the servlet reference implementation
Tomcat itself has never been an official reference implementation of anything.
Tomcat implements various Jakarta EE APIs, most centrallly Servlet indeed, but also JSP (Jakarta Pages) and JSTL (Jakarta Tags), WebSockets and Jakarta Authentication.
The initial Tomcat was donated to Apache, then used back in GlassFish. GlassFish WAS the reference implementation of Servlet (among others), so indirectly Tomcat kinda was the reference implementation indeed. But just a fork of its code via GlassFish.
Yes please, though this is largely driven by my personal dislike of Spring Boot. The bloat and magic sucks so much of the joy out of programming to me. That said, I never lived in Spring Boot exclusively. I've heard people say that it's an "all in" kind of thing and once you go all in and learn the thing really well, you start to like it.
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?
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.
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.
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.
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.
> 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.
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.
EE doesn't exclude that model at all.
For the most part, maybe like 99%, the Jakarta APIs are agnostic of what the deployment model is. They are APIs to validate input, service HTTP requests, store data in databases, look up roles, connect to identity providers, etc etc.
reply