Need Help Defining/Understanding the Java EE "Stack"
That diagram is NOT a Java EE stack.
This may be helpful (or not:):
Java EE is a managed runtime system. (LAMP has no such concerns.)
Java EE uses a component-container general architecture (LAMP does not define an explicit component container API)
Application servers such as JBoss, Glassfish, etc. provide the Java EE container. (Tomcat does not support the full Java EE stack. Tomcat and Jetty provide only the web container (or the web profile per latest specs.))
Note that Java EE web containers (Servlets) are much simpler than the full blown Java EE stack, but are based on the same architectural approach.
Web components of Java EE are (fundamentally) Servlets, and Filters. Various higher order frameworks (such as Faces) are built on top of this architecture. The Java EE Web container is both relatively simple and very effective. It is the closest thing to LAMP.
Enterprise components of Java EE (supported by Java EE Application Servers such as GlassFish) are various flavors of stateless, stateful, and persistent components (known as "Beans" in Java land).
Hibernate is an ORM and is redundant in context of full Java EE (e.g. EntityBeans). Typically, JPA is used with Web-Container "Java EE" systems to connect to a backend JDBC compliant RDMBS. Oracle, MySQL, whatever.
you (and/or some 3rd party library) provide the components.
The managed runtime is primary concerned with taking care of "orthogonal" "enterprise" "concerns" such as transactional integrity, and you, the component/application writer, are supposed to be focused on the "business logic".
Java EE manages references, transaction boundaries, connectivity, and life-cycle of your components.
References: Using semantic references looked up at runtime via a namespace mechanism aka JNDI and RMI; and dependency injection via declarative deployment descriptors.
Life-cycle: your components will have proper startup, work, and shutdown phases. You can hook into these LC events and participate if necessary (typically not necessary). This formalized LC allows for the distribution and scaling of the architecture.
Connectivity: broadly addresses incoming (clients) and internal (EIS) integration points. For clients you have the web/RMI/JMS, etc. This gives you sync req/rep semantics and async fire and forget. For backend (in general) the JCA specifies connectors to other systems. JPA is a specialization of JCA (in theory not practice) that specifically addresses database EISs with JDBC user API.
Transactions: declarative means to apply transaction semantics to specific methods of a component. This can be done at design time (via annotations) or at deploy time (via XML).
Deployment packages
Java EE systems are typically packaged as either WAR (for the web only) or EAR (for the full stack).
Deployment descriptors
The latest specs of Java EE favor zero-config operations with sensible defaults (or trivial mappings). But it is important for you to wrap your head around what this is all about and at some point, any serious Java EE app will require dealing with these artifacts at some level. (It is much easier for the web.xml, so don't freak out.) It is a key aspect of the architecture. Understand this and everything else is very clear.
Java EE uses indirection to make its magic happen. This is the problem that is being addressed here:
We have components written by some 3rd party (some time ago) and we need to use them in our application. The deployment descriptors allow mapping of your application specific semantics e.g. name of component or its transaction semantics to the components generic semantics. For example, you may wish to expose a "Acme-Logger" as "My-Very-Own-Logger". You accomplish this by mapping the desired environment name to the class of the component. (Original component may have had an annotation declaring its generic name to be simply "the-logger").
Spring, in effect, came about because of the serious pain of the creation and maintenance of these mapping descriptors. Again, Spring is an alternative approach to container based systems.
Containers
Theoretically you should be able to plug an entire container into a compliant server, but the general idea is that you are writing your components for a universal container e.g. the Java EE container. In any event, as you can imagine, vendors of Java EE app servers were not too keen on having a pluggable container API for the stack as it would make their product a complete commodity.
Spring
Spring is actually a counter-thesis to Java EE. It is (or was) a light-weight container system to address the pain points of J2EE (which was entirely unreasonable without effective tooling, given the elaborate architecture and ceremony of deployment). In effect, a Servlet front end and Spring container are an alternative to a full blown Java EE stack. That said, they can co-exist.
Maven
Maven is a build tool. There is also ant. Or you can jump on the Gradle. Maven archetypes exist that allow you to get started with a basic Java EE project with little effort.
Suggestion:
Start with (and stick with) Web-container subset. Jetty or Tomcat are fine choices for the container/server.
Get to know WEB-INF/ and web.xml. Write a simple HTTPServlet extension, and play around with features of the web.xml. Try setting up a filter, or, bind some parameters into the web-app context. Master these fundamentals. Everything else is built on top of these. Everything.
In the servlet, explore the API provided. Get to know the difference between application, session, and request "contexts". A key matter in the web-tier. Learn how to redirect requests. Get http headers, etc. Everything else is built on these. Master these fundamentals.
Lets say you have your HelloWorld web-app up at this point. Next step, try JPA and add persistence to your project. Here is where you can try a Spring/Hibernate/Tomcat tutorial example. Spring will setup the non-Java EE container for your business components (classes). Hibernate will take care of persisting your data. Couple of new artifacts are introduced when you do this. Spring related xml files and the JPA/Hibernate mappings. Get to know these and what it is all about.
You're almost done. Finally, lets turn to the view or presentation concerns. This is where Java (imo) sucks as it is far too verbose and this tier is all about mindless repetition of put widget here, put widget there, etc.
At its simplest (and out of box), you have the basic HTTPServlet and ability to send back whatever you feel like it. You can write your html in your code (a very bad idea), or use a template approach (Velocity, FreeMarker), or step up to the specialized components for presentation: JSP, Faces, etc. There are literally dozens of frameworks (and approaches) out there for the presentation tier.
Hope this helped.
Yes, the diagram you posted is intimidating, but you need not use all that stuff. It's not all necessary.
If you're new, keep it simple and build up.
Here's the rock-bottom, must-have items to start with:
- Servlets and JSPs. This means deploying on a servlet/JSP engine like Tomcat or Jetty. Servlets are HTTP listeners that handle incoming requests, collaborate with back-end classes to fulfill them, and route the responses to the appropriate next view.
- JSPs are a templating solution for generating HTML. You should only write these using JSTL, the JSP standard tag library. No scriptlets.
- HTML, CSS, and JavaScript for the UI. You need these for web-based UIs.
- JDBC for relational database access.
That's it. You can go a very long way just with these.
I love Spring, but it's a lot to swallow the first time. Do a site or two without it. You'll understand things better and appreciate what Spring does for you more.
You don't need JSF. I'd argue that it's a technology on the decline. The one JSF/Faces app that I saw personally absolutely s*cked. You could time the page load with a sundial. I don't see it as a big winner, in spite of the fact that it's touted as a Java EE standard. Are you gonna run JSF on a mobile UI? I don't think so.
UIs are written using HTML, CSS, and JavaScript talking to services on the back end. Those services can be REST-ful servlets.
Hibernate is an object-relational mapping technology. If you don't have an object model, you don't need Hibernate. If you have simple one-to-one relationships between objects and tables, you don't need Hibernate. If you like stored procedures as an interface into your relational database, you don't need Hibernate. If you don't mind writing a little SQL and mapping the results, you don't need Hibernate. Ditto for JPA - Hibernate is one way to implement JPA, which took a great deal from Hibernate.
Begin with these and build up. If you try to learn all the stuff you cited all at once you'll never get anywhere.