December 24, 2025 • 19 mins
A comprehensive guide for developing web, cloud, and microservices applications using Java MVC. It introduces the fundamental Model-View-Controller (MVC) design pattern, tracing its history and adaptation for web applications, especially within the Java EE/Jakarta EE ecosystem utilizing JSR-371. The text covers practical aspects of setting up a development environment with Eclipse and Gradle, building "Hello World" applications, and understanding core Java MVC components like controllers, views (JSP and Facelets), and model data handling through CDI (Context and Dependency Injection). Furthermore, it addresses advanced topics such as bean validation, state persistence, AJAX integration, internationalization, EJB (Enterprise JavaBeans) communication, and database connectivity using JPA (Java Persistence API), concluding with an elaborate example application called BooKlubb.
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cyber_security_summary
Get the Book now from Amazon:
https://www.amazon.com/Beginning-Java-MVC-1-0-Microservices/dp/1484262794?&linkCode=ll1&tag=cvthunderx-20&linkId=bfdd0202b803e280aa16eee4759c26df&language=en_US&ref_=as_li_ss_tl
Discover our free courses in tech and cybersecurity, Start learning today:
https://linktr.ee/cybercode_academy
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cyber_security_summary
Get the Book now from Amazon:
https://www.amazon.com/Beginning-Java-MVC-1-0-Microservices/dp/1484262794?&linkCode=ll1&tag=cvthunderx-20&linkId=bfdd0202b803e280aa16eee4759c26df&language=en_US&ref_=as_li_ss_tl
Discover our free courses in tech and cybersecurity, Start learning today:
https://linktr.ee/cybercode_academy
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Okay, let's untack this. Welcome to the deep dive. We're
all about taking complex topics, cutting through the noise, and
really giving you those vital insights quickly, thoroughly, and hopefully
without that feeling of being overwhelmed. Exactly today we're diving
deep into Java MVC one point zero. It's well, it's
a pretty foundational design pattern, really critical if you're building
(00:22):
modern web apps, cloud services, even micro services. And our
guy for this is Peter Spieth's excellent book Beginning Java
Mvc one point zero.
Speaker 2 (00:32):
Yeah, it's exciting stuff because we're not just looking at,
you know, a technology, We're digging into a fundamental design pattern,
one with some serious history behind it. Our goal here
is to give you a clear, kind of structured understanding
of Java mvc. What are the core pieces? How does
it fit into the whole Java enterprise world. Yeah, and
you should walk away with some practical insights, not just
the what, but the why? Why does this pattern even matter?
(00:55):
What does the lit developers actually do?
Speaker 1 (00:57):
Absolutely? So, let's start big picture model. You control NBC.
It's not just Java, right, it's this fundamental software design pattern.
Speaker 2 (01:04):
Oh yeah, fundamental.
Speaker 1 (01:05):
It breaks down complex apps into three distinct roles, three
interconnected pieces. Think of it like I don't know a
well oiled machine, where each part has a specific job.
Speaker 2 (01:17):
A good analogy.
Speaker 1 (01:18):
So at the core you've got the model. This is
all about the application data, specifically the data the user
sees and might change. Right the state and the key
thing is the model is totally ignorant. It has no
idea how that data gets presented or how the application flows.
It's just the data, the source of truth.
Speaker 2 (01:36):
Agnostic that's the word often used. It's data centric, not
presentation aware.
Speaker 1 (01:42):
Then you have the view, Its job is purely presentation.
How does the model's data look to the user? All
the interactive bits, inputs, buttons, menus. That's the view.
Speaker 2 (01:51):
Could be a desktop gooi, a mobile app screen, or
most often for us, a webpage.
Speaker 1 (01:56):
It's the user's window basically exactly. And finally, the controller.
This is the coordinator, the brains. Maybe it handles user input,
It talks to the model to get or update data,
contains the application logic, calculations, data transformations, that kind of.
Speaker 2 (02:10):
Thing, And crucially it decides how data gets stored or retrieved,
maybe from a database.
Speaker 1 (02:16):
Right, But it doesn't care about how the view looks.
Its job is managing the flow, not painting.
Speaker 2 (02:22):
The picture precisely keeps things separate.
Speaker 1 (02:25):
Okay, to make this more concrete, let's use this book
club example application from the book. We'll keep coming back
to it.
Speaker 2 (02:30):
Good idea.
Speaker 1 (02:31):
So in book Club, the books themselves, their rental status,
member details. All that stuff lives in the model.
Speaker 2 (02:39):
The core entities.
Speaker 1 (02:40):
The web page is showing search results, the member sign
up form, the menus that's all view, the user interface,
and the controller that's the logic that takes your search
request or updates a book status when you rent. It
fetches member info from the database and then decides which
view to show next.
Speaker 2 (02:56):
It handles the doing part based on user actions.
Speaker 1 (02:59):
Exactly the logic behind it all.
Speaker 2 (03:01):
And if you connect this to the bigger picture, like
you said, NBC isn't new. It goes way back.
Speaker 1 (03:06):
Yeah, you mentioned history, right back.
Speaker 2 (03:08):
To the nineteen seventies small talk. Originally, it didn't get
the explicit MVC name until the late.
Speaker 1 (03:14):
Eighties wow, seventies.
Speaker 2 (03:16):
But it's real power. Well that became obvious in the
nineties with the Internet boom. The pattern adapted surprisingly well
to web applications, even though AHGTP is inherently stateless.
Speaker 1 (03:26):
That statelessness is always the challenge, isn't it always?
Speaker 2 (03:29):
And it led to specific Web NBC challenges like how
do you keep track of a user across multiple requests?
That's where sessions came in, usually managed by frameworks using
cookies okay? Or how do you cleanly get modeled data
into the view. Templating engines solve that thing things like
user dot first.
Speaker 1 (03:47):
Name right, accessing the data easily, and.
Speaker 2 (03:49):
How do you update the page? We moved from reloading
the entire page to partial updates using scripts like ajax,
much smoother. And while other patterns like MVVM came along,
often adding more automation for data binding, they still build
on that core MVC idea of separating concerns.
Speaker 1 (04:05):
That's a great historical context. So if MVC is that old,
what makes Java MVC this JSR three seventy one the
modern choice for enterprise JABA.
Speaker 2 (04:14):
Good question. Java MVC is the dedicated standardized framework for
Java EE eight and now Deakarta E eight and later.
It filled the gap many developers felt.
Speaker 1 (04:23):
Was there a standard was needed?
Speaker 2 (04:25):
Kind of yeah, And it's important to remember JSR three
to seventy one defines the interface. You need an implementation
like eclips Crazo to actually use it.
Speaker 1 (04:33):
Okay, So it's a spec needs a library exactly.
Speaker 2 (04:35):
And what's clever is how it extends JXRS, Java's RES technology.
It's built on jxrs.
Speaker 1 (04:42):
Ah, so it leverages RES right.
Speaker 2 (04:44):
That makes it lean, gives it a concise style, and
it means it plays really nicely with ajx out of
the box. Because it's already using JXRS for handling requests.
Speaker 1 (04:52):
That JXRS connection seems key. Does that feed into the
pros and cons?
Speaker 2 (04:57):
Definitely? The pros well. Being closer to HTT means potentially
less memory overhead compared to some component based framework that
build big UI trees in memory like JSF Maybe potentially, Yeah,
it can have a smaller footprint. Plus being part of
the Jakarta EE spec means reliability, maintenance, community support, okay, stability,
and if you've used older frameworks like struts, the action
(05:19):
based approach of Java MBC will feel pretty familiar.
Speaker 1 (05:22):
Makes sense.
Speaker 2 (05:22):
What about the downsides, Well, it doesn't totally hide HGTP.
You still need some awareness of requests response as.
Speaker 1 (05:28):
Headers, so not quite as much abstraction.
Speaker 2 (05:31):
Right, and it doesn't typically offer two way data binding
out of the box. If a user types in a
form you the developer usually need to write code in
the controller to explicitly update the model.
Speaker 1 (05:43):
Ah okay, so a more manual work there compared to
some other frameworks.
Speaker 2 (05:47):
Potentially, Yes, it's a trade off more control, maybe a
bit more boilerplate. In some cases. It's about balancing that
abstraction versus control over HTTP.
Speaker 1 (05:56):
So when would that extra control be a real advantage
and when might it just be extra work?
Speaker 2 (06:02):
Great point. You benefit most when you need really fine
grain control over the HTTP request response. Maybe you're building
complex rest APIs that also serve htmail pages or highly
optimize micro services. The flexibility is powerful. Then the drawback
if you just want something super high level where the
framework does almost everything automatically. Maybe for simpler cru'd apps.
(06:22):
It depends on the project control versus speeded development.
Speaker 1 (06:24):
Sometimes that makes a lot of sense. Okay, let's talk
about the foundation. Java NVC doesn't just run anywhere, right,
It needs that Java Enterprise Edition Server environment Java EE
or Jakarta E.
Speaker 2 (06:37):
Absolutely, it relies on that infrastructure.
Speaker 1 (06:39):
And Java itself. Well, it's been the go to for
enterprise apps, for ages, stability, database connections, talking to other systems,
handling complex logic. It's built for that scale and just
for context. Java started with Sun, went through j to EE,
then JG and now Jakarta E under the Eclipse Foundation.
We're focusing on Jakarta E eight and Java eight features
(06:59):
here right.
Speaker 2 (07:00):
And the key is that Jakarta E provides this whole
ecosystem Java MVC plugs into. It's not standalone.
Speaker 1 (07:06):
What are the key pieces it relies on Well.
Speaker 2 (07:08):
JXRS, as we said, innovational, then JPA, the Java Persistence
API for database access handles all the tricky SQL stuff.
Speaker 1 (07:16):
Usually OHRM right, Object relational mapping.
Speaker 2 (07:19):
Exactly and critically CDI context and dependency injection. That's how
Java MVC manages beans their life cycles. It's core.
Speaker 1 (07:26):
CDI sounds important.
Speaker 2 (07:27):
It is plus being validation for data integrity and for learning.
The book recommends GlassFish Server version five point one, open source,
free group.
Speaker 1 (07:37):
Of development, and you can manage GlassFish different ways.
Speaker 2 (07:39):
Yeah, command line, a Sadman, WEBGUI, even Arrest API pretty flexible.
Speaker 1 (07:45):
Okay, foundation set. Let's dive back into the MVC components,
but specifically the Java MVC way, starting with the model
and that CDI thing you mentioned.
Speaker 2 (07:55):
Right, So Java MVC uses CDI two point zero to
manage your model classes. Yeah, you typically don't do new
my model. CDI handles creating and providing instances.
Speaker 1 (08:05):
How does it know which classes to manage?
Speaker 2 (08:07):
Usually annotate them. The simplest is that named You put
it named on your Java being, say your book class,
and CDI takes over makes it available to your views.
Speaker 1 (08:15):
Okay, annotation magic pretty much.
Speaker 2 (08:17):
And CDI manages the lifespan of these objects through scopes.
Speaker 1 (08:20):
This is really important to the copes, like how long the
data lasts exactly.
Speaker 2 (08:23):
There's request scope, a new instance for every single HTTP
request lives only for that request response cycle. Good perfect
for temporary stuff like the data submitted in a form.
Then session scope, the instance sticks around for the user's
entire browser session. Great for things like user login information, shopping.
Speaker 1 (08:41):
Cards, data that needs to persist across pages for one
user precisely.
Speaker 2 (08:45):
Then there's redirect scope. This one's need. It supports that
post redirect get pattern.
Speaker 1 (08:50):
Ah to stop double form submission exactly.
Speaker 2 (08:53):
The object lives across the post request and the following
get t redirect super useful.
Speaker 1 (08:58):
It definitely needed that before.
Speaker 2 (08:59):
Oh yeah, there's also application scope for data shared across
all users living until the app stops, and dependent scope
the default, which just inherits the scope of whatever injects it.
Speaker 1 (09:10):
Lots of options. What if you need something really simple.
Speaker 2 (09:12):
For quick things, there's a built in Javacs dot mvc
dot model's object you can inject into your controller. Just
add key value pairs to it and they're available in
the view. No need for a dedicated class.
Speaker 1 (09:22):
Sometimes handy for simple cases. Okay, so CDI managed the
model data in its life, Now how do we show
it the view?
Speaker 2 (09:28):
Right? The view layer. Java MVC mainly uses two templating
technologies here, JSPS, Java server pages and facelets.
Speaker 1 (09:37):
JSPS are the older ones, right.
Speaker 2 (09:39):
Yeah, classic. You mix HTML with dynamic bits the modern way,
and what the source recommends is using expression language el
that syntax.
Speaker 1 (09:47):
Like dumb butt title exactly.
Speaker 2 (09:49):
Access is your CDI beans cleanly. You should also use
JSDL tags like CT ORH for loops set to different conditions.
Avoid embedding raw javascriptlets percent jsps. If you can keep
logic out of the view, keep it clean definitely, and
the source really advises against using implicit objects like param
directly in the view that mixes controller responsibilities with presentation.
(10:12):
Bad idea, Got it?
Speaker 1 (10:13):
What about facelts.
Speaker 2 (10:14):
Facelits is newer xmail based came from the JSF world
Livesten webi nfus. Its strength is templating reasonable layouts using
tags like EI dot composition, uid, define, UI dot insert
really good for consistent page structure.
Speaker 1 (10:28):
Sounds powerful any catches yes, a.
Speaker 2 (10:30):
Big one for Java MBC. While facelts is great for templates.
You should avoid mixing in actual JSF components or using
JSS specific expression language. Why is that paradigm mismatch? JSF
has its own life cycling component model. Trying to shoehorn
that into Java mvc's request driven model can cause weird
issues in instability. Stick to facelets for templating, use standard
(10:51):
EEL for data access in Java mvc.
Speaker 1 (10:53):
Okay, noted, keep JSF stuff out of Java mvc.
Speaker 2 (10:57):
Facelts Right now, the controller, how do you make one annotations?
Speaker 1 (11:00):
Again?
Speaker 2 (11:00):
You bet at controller on the class, usually paired with
at path to define the base URL like at path books.
Speaker 1 (11:07):
Okay, and methods handle requests YEP.
Speaker 2 (11:11):
For a get request, say to show a list of books.
A method might return a string the name of the
JSP or Facebook file like booklist dot jsp simple, or
for more control, it can return a response object that
lets you set h GDP status codes, headers, cookies explicitly.
Speaker 1 (11:26):
Ah more power there, and.
Speaker 2 (11:28):
The final URL path is built up application path class
at path method at path all cancatenated makes sense.
Speaker 1 (11:34):
How does the controller prepared data for the view?
Speaker 2 (11:37):
It injects the needed CDI beans the model objects using
it inject that, it calls methods on them, sets values
whatever is needed before the view gets rendered.
Speaker 1 (11:44):
Okay, and post requests like.
Speaker 2 (11:47):
Forms handled similarly, but you use annotations like at form
paarent book title within the method arguments to grab the
submitted data directly.
Speaker 1 (11:57):
Okay, that covers the core components. What about making is
more robust handling user input validation crucial stuff?
Speaker 2 (12:03):
So you capture data from forms or query parameters. Now
what if the user types letters into a number field
or leave something blank.
Speaker 1 (12:13):
Errors happen?
Speaker 2 (12:14):
Right? Java MBC uses binding result. You audit as a
parameter to your controller method. It automatically catches conversion errors
or validation failures, and then you can check binding result
for errors. If there are any. You typically add the
air messages to the model's object and return to the
same view showing the user what went wrong.
Speaker 1 (12:32):
Nice keeps them on the form.
Speaker 2 (12:33):
Exactly and being validation makes this even better. You put
annotations right on your controller method parameters or on your
model bean fields at notinal at size and five at
pattern Reex built in rules loads of them, and you
can create custom ones too. Plus you can easily internationalize
the error messages using validation messages dot properties files, so
error messages appear in the user's language.
Speaker 1 (12:54):
Very professional. Okay, what about state you mentioned sessions earlier.
Speaker 2 (12:57):
Yeah, persisting state. HTTP is stateless, but web apps aren't.
We need to remember things about a user between requests.
HTTP session is the standard.
Speaker 1 (13:08):
Javaway managed by the server YEP.
Speaker 2 (13:10):
Usually via cookies behind the scenes. Java MBC makes this
easy with at session scope CDI beans. Just inject your
ad session scope user preferences being and its data sticks
around for that user. Session. Seems convenient, it is, but
big caveat. Don't stuff everything into the session, especially large
objects or lots of data per user. If you have
(13:31):
thousands of users.
Speaker 1 (13:32):
Online, memory usage explodes exactly.
Speaker 2 (13:34):
It can kill your server's performance and stability. Use session
scope judiciously only for data that truly needs to persist
for the session duration.
Speaker 1 (13:42):
Good warning. What about making the UI more dynamic? You
mentioned AJX.
Speaker 2 (13:46):
Right AGX asynchronous JavaScript in XML, though nowadays it's off
in JSON not XML. The idea is the browser uses
JavaScript to make background requests to the server without a
full page reload.
Speaker 1 (13:57):
Smoother experience, much smoother.
Speaker 2 (14:00):
Mber Is like jQuery made this easier, but modern JavaScript
has fetch api built in Your Java mvc controller can
handle these AJAX requests. Instead of returning a full page name,
it might return just an h T Mel fragment or
maybe Jason data.
Speaker 1 (14:13):
Okay, so the controller can serve both full pages and
AJX snippets.
Speaker 2 (14:18):
Absolutely. The JavaScript on the front end then takes that
response and updates just the relevant part of the page,
maybe updates account, refreshes, a list, shows a status message.
Speaker 1 (14:27):
Very cool. You also mentioned observers.
Speaker 2 (14:28):
Yeah, CD observers. This is a really elegant way to
handle cross cutting concerns, things like logging, performance monitoring, security checks.
Stuff that needs to happen in response to events, but
isn't core business logic.
Speaker 1 (14:40):
How does it work.
Speaker 2 (14:41):
You create a method in a cdibing and annotate it
with at observes. You specify the event type you're interested in,
like maybe an event fired just before a controller method
runs bore controller event from javax dobc dot event ah.
Speaker 1 (14:55):
So it listens for specific points in the process.
Speaker 2 (14:57):
Exactly when that event happens, automatically calls your observer method.
It keeps that logging or monitoring code completely separate from
your controller logic. Really improves maintainability.
Speaker 1 (15:09):
That separation of concerns again seems to be a running theme.
Speaker 2 (15:12):
It's the theme of good architecture really, which brings us
to bigger enterprise integration like databases.
Speaker 1 (15:18):
Right, how does Java MBC talk to a database JPA.
Speaker 2 (15:22):
YEP JPA, Java persistence API the standard way in Jakarta EE.
It abstracts away most of the raw sequel uses orim
object relational mapping.
Speaker 1 (15:31):
So your Java book object maps to a books table precisely.
Speaker 2 (15:34):
You define this mapping using annotations at entity table at
iocolumn right on your Java class and you can figure
the database connection details in a persistence dot XML file.
Speaker 1 (15:43):
And how do you actually interact with the data through.
Speaker 2 (15:46):
The entity manager. You inject it, and it has methods
like find, persist, merge, remove. It handles translating those calls
into SQL. You'll also need to set up a database
like apatchy Derby and can figure a data source in
glass Fish okay.
Speaker 1 (16:01):
So JPA handles the database mapping and interaction. What about
EJBs Enterprise Java beans EJBs.
Speaker 2 (16:07):
Are components for business logic. They run in a container
that provides services like transactions, security, concurrency management automatically.
Speaker 1 (16:15):
More than just plan Java objects right.
Speaker 2 (16:17):
There are different types, mainly session EJBs. Stateless ones are common.
They don't hold client specific state between calls. Good for
service operations like processing a book rental okay. Stateful EJBs
do maintain state across multiple calls from the same client.
Useful for multi step processes like a Wizard or complex
checkout Singleton. EJBs ensure only one instance exists for the
(16:38):
whole application. Good for cases or coordinating tasks.
Speaker 1 (16:41):
How does your MBC controller use an EJB?
Speaker 2 (16:44):
Usually just inject it Using an EJB, the container handles
providing the instance. EJBs also have cool features like at
asynchronous for background tasks and its schedule for time, jobs.
Speaker 1 (16:54):
Powerful stuff and managing all this complexity, Logging must be vital.
Speaker 2 (16:58):
Absolutely critical, and enterprise apps for debugging, auditing, just understanding
what's going on. GlassFish uses the standard JSR forty seven
logging API.
Speaker 1 (17:08):
By default, where did the logs go?
Speaker 2 (17:10):
Typically to server dot log. You have different levels severe warning, info, fine,
finer finance. You configure the level to control how much
detail you get.
Speaker 1 (17:18):
Can you use other logging frameworks?
Speaker 2 (17:20):
Yes. Log forg is a very popular, powerful alternative. It
separates the logging API from the implementation, can reload its
configuration without restarting the server. Lots of advantages. You can
integrate at server wide or just for your application.
Speaker 1 (17:33):
Choosing the right logging level seems important.
Speaker 2 (17:35):
It is too little, you can't debug too much. It
impacts performance. You need a strategy. What stands out here
is just how essential good logging is for maintaining complex systems.
Speaker 1 (17:46):
Definitely so bringing it all together, this book club example
really uses all these pieces.
Speaker 2 (17:52):
Doesn't it. It really does. It uses Derby as the
database configured in glass Fish. It has internationalization for messages,
It uses APA entities for member book rental. It uses
stateless EJBs as data access objects baos to handle the database.
Speaker 1 (18:08):
Operations, okay, EJB's for the data logic.
Speaker 2 (18:11):
Then it has simple CDI beans acting as the model
for the views. A central Java MVC controller manages all
the web interactions, and the views are jsps using fragments
and some JavaScript for those dynamic updates.
Speaker 1 (18:23):
It's quite a good demonstration of how these seemingly separate
technologies MBC, CDI, JPA, EJB all integrate cleanly within the
Jakarta E platform.
Speaker 2 (18:32):
Exactly. You see how a complex system gets built from
these well defined modular parts.
Speaker 1 (18:36):
Okay, well, that feels like a pretty third journey through
Java Mvc one point zero. We started with the basic
MBC pattern, looked at Java NBC specifics under JSR three
seventy one, touched on its Jakarta E foundations.
Speaker 2 (18:48):
Cover the component's model with CDI scopes, view a JSP
and facelooks, caveats, controller handling requests right.
Speaker 1 (18:55):
And then validations, state management with sessions, AJAX observers, integrating
with JPA databases and EJBs, and finally logging strategies.
Speaker 2 (19:05):
A comprehensive look.
Speaker 1 (19:06):
So hopefully you now have a really solid grasp of
how Java NBC works and how you can use it
to build robust, scalable, maintainable applications, web cloud, micro services,
the lot.
Speaker 2 (19:18):
And maybe this raises an important question for you, the listener,
to think about as patterns evolve, How does understanding something
foundational like MVC help you adapt?
Speaker 1 (19:27):
Hmmm, good question.
Speaker 2 (19:28):
Think about how these core ideas, separation of concerns, defined
roles for data logic presentation might show up even in
newer frameworks, maybe just with different names or syntax. How
does this foundation empower you? What stands out to you
about how these architectural patterns really help developers build better software.
Speaker 1 (19:45):
That's fantastic thought to leave things on something to definitely
mull over. Thank you so much for joining us on
this deep dive. We hope you found it valuable.
Okay, let's untack this. Welcome to the deep dive. We're
all about taking complex topics, cutting through the noise, and
really giving you those vital insights quickly, thoroughly, and hopefully
without that feeling of being overwhelmed. Exactly today we're diving
deep into Java MVC one point zero. It's well, it's
a pretty foundational design pattern, really critical if you're building
(00:22):
modern web apps, cloud services, even micro services. And our
guy for this is Peter Spieth's excellent book Beginning Java
Mvc one point zero.
Speaker 2 (00:32):
Yeah, it's exciting stuff because we're not just looking at,
you know, a technology, We're digging into a fundamental design pattern,
one with some serious history behind it. Our goal here
is to give you a clear, kind of structured understanding
of Java mvc. What are the core pieces? How does
it fit into the whole Java enterprise world. Yeah, and
you should walk away with some practical insights, not just
the what, but the why? Why does this pattern even matter?
(00:55):
What does the lit developers actually do?
Speaker 1 (00:57):
Absolutely? So, let's start big picture model. You control NBC.
It's not just Java, right, it's this fundamental software design pattern.
Speaker 2 (01:04):
Oh yeah, fundamental.
Speaker 1 (01:05):
It breaks down complex apps into three distinct roles, three
interconnected pieces. Think of it like I don't know a
well oiled machine, where each part has a specific job.
Speaker 2 (01:17):
A good analogy.
Speaker 1 (01:18):
So at the core you've got the model. This is
all about the application data, specifically the data the user
sees and might change. Right the state and the key
thing is the model is totally ignorant. It has no
idea how that data gets presented or how the application flows.
It's just the data, the source of truth.
Speaker 2 (01:36):
Agnostic that's the word often used. It's data centric, not
presentation aware.
Speaker 1 (01:42):
Then you have the view, Its job is purely presentation.
How does the model's data look to the user? All
the interactive bits, inputs, buttons, menus. That's the view.
Speaker 2 (01:51):
Could be a desktop gooi, a mobile app screen, or
most often for us, a webpage.
Speaker 1 (01:56):
It's the user's window basically exactly. And finally, the controller.
This is the coordinator, the brains. Maybe it handles user input,
It talks to the model to get or update data,
contains the application logic, calculations, data transformations, that kind of.
Speaker 2 (02:10):
Thing, And crucially it decides how data gets stored or retrieved,
maybe from a database.
Speaker 1 (02:16):
Right, But it doesn't care about how the view looks.
Its job is managing the flow, not painting.
Speaker 2 (02:22):
The picture precisely keeps things separate.
Speaker 1 (02:25):
Okay, to make this more concrete, let's use this book
club example application from the book. We'll keep coming back
to it.
Speaker 2 (02:30):
Good idea.
Speaker 1 (02:31):
So in book Club, the books themselves, their rental status,
member details. All that stuff lives in the model.
Speaker 2 (02:39):
The core entities.
Speaker 1 (02:40):
The web page is showing search results, the member sign
up form, the menus that's all view, the user interface,
and the controller that's the logic that takes your search
request or updates a book status when you rent. It
fetches member info from the database and then decides which
view to show next.
Speaker 2 (02:56):
It handles the doing part based on user actions.
Speaker 1 (02:59):
Exactly the logic behind it all.
Speaker 2 (03:01):
And if you connect this to the bigger picture, like
you said, NBC isn't new. It goes way back.
Speaker 1 (03:06):
Yeah, you mentioned history, right back.
Speaker 2 (03:08):
To the nineteen seventies small talk. Originally, it didn't get
the explicit MVC name until the late.
Speaker 1 (03:14):
Eighties wow, seventies.
Speaker 2 (03:16):
But it's real power. Well that became obvious in the
nineties with the Internet boom. The pattern adapted surprisingly well
to web applications, even though AHGTP is inherently stateless.
Speaker 1 (03:26):
That statelessness is always the challenge, isn't it always?
Speaker 2 (03:29):
And it led to specific Web NBC challenges like how
do you keep track of a user across multiple requests?
That's where sessions came in, usually managed by frameworks using
cookies okay? Or how do you cleanly get modeled data
into the view. Templating engines solve that thing things like
user dot first.
Speaker 1 (03:47):
Name right, accessing the data easily, and.
Speaker 2 (03:49):
How do you update the page? We moved from reloading
the entire page to partial updates using scripts like ajax,
much smoother. And while other patterns like MVVM came along,
often adding more automation for data binding, they still build
on that core MVC idea of separating concerns.
Speaker 1 (04:05):
That's a great historical context. So if MVC is that old,
what makes Java MVC this JSR three seventy one the
modern choice for enterprise JABA.
Speaker 2 (04:14):
Good question. Java MVC is the dedicated standardized framework for
Java EE eight and now Deakarta E eight and later.
It filled the gap many developers felt.
Speaker 1 (04:23):
Was there a standard was needed?
Speaker 2 (04:25):
Kind of yeah, And it's important to remember JSR three
to seventy one defines the interface. You need an implementation
like eclips Crazo to actually use it.
Speaker 1 (04:33):
Okay, So it's a spec needs a library exactly.
Speaker 2 (04:35):
And what's clever is how it extends JXRS, Java's RES technology.
It's built on jxrs.
Speaker 1 (04:42):
Ah, so it leverages RES right.
Speaker 2 (04:44):
That makes it lean, gives it a concise style, and
it means it plays really nicely with ajx out of
the box. Because it's already using JXRS for handling requests.
Speaker 1 (04:52):
That JXRS connection seems key. Does that feed into the
pros and cons?
Speaker 2 (04:57):
Definitely? The pros well. Being closer to HTT means potentially
less memory overhead compared to some component based framework that
build big UI trees in memory like JSF Maybe potentially, Yeah,
it can have a smaller footprint. Plus being part of
the Jakarta EE spec means reliability, maintenance, community support, okay, stability,
and if you've used older frameworks like struts, the action
(05:19):
based approach of Java MBC will feel pretty familiar.
Speaker 1 (05:22):
Makes sense.
Speaker 2 (05:22):
What about the downsides, Well, it doesn't totally hide HGTP.
You still need some awareness of requests response as.
Speaker 1 (05:28):
Headers, so not quite as much abstraction.
Speaker 2 (05:31):
Right, and it doesn't typically offer two way data binding
out of the box. If a user types in a
form you the developer usually need to write code in
the controller to explicitly update the model.
Speaker 1 (05:43):
Ah okay, so a more manual work there compared to
some other frameworks.
Speaker 2 (05:47):
Potentially, Yes, it's a trade off more control, maybe a
bit more boilerplate. In some cases. It's about balancing that
abstraction versus control over HTTP.
Speaker 1 (05:56):
So when would that extra control be a real advantage
and when might it just be extra work?
Speaker 2 (06:02):
Great point. You benefit most when you need really fine
grain control over the HTTP request response. Maybe you're building
complex rest APIs that also serve htmail pages or highly
optimize micro services. The flexibility is powerful. Then the drawback
if you just want something super high level where the
framework does almost everything automatically. Maybe for simpler cru'd apps.
(06:22):
It depends on the project control versus speeded development.
Speaker 1 (06:24):
Sometimes that makes a lot of sense. Okay, let's talk
about the foundation. Java NVC doesn't just run anywhere, right,
It needs that Java Enterprise Edition Server environment Java EE
or Jakarta E.
Speaker 2 (06:37):
Absolutely, it relies on that infrastructure.
Speaker 1 (06:39):
And Java itself. Well, it's been the go to for
enterprise apps, for ages, stability, database connections, talking to other systems,
handling complex logic. It's built for that scale and just
for context. Java started with Sun, went through j to EE,
then JG and now Jakarta E under the Eclipse Foundation.
We're focusing on Jakarta E eight and Java eight features
(06:59):
here right.
Speaker 2 (07:00):
And the key is that Jakarta E provides this whole
ecosystem Java MVC plugs into. It's not standalone.
Speaker 1 (07:06):
What are the key pieces it relies on Well.
Speaker 2 (07:08):
JXRS, as we said, innovational, then JPA, the Java Persistence
API for database access handles all the tricky SQL stuff.
Speaker 1 (07:16):
Usually OHRM right, Object relational mapping.
Speaker 2 (07:19):
Exactly and critically CDI context and dependency injection. That's how
Java MVC manages beans their life cycles. It's core.
Speaker 1 (07:26):
CDI sounds important.
Speaker 2 (07:27):
It is plus being validation for data integrity and for learning.
The book recommends GlassFish Server version five point one, open source,
free group.
Speaker 1 (07:37):
Of development, and you can manage GlassFish different ways.
Speaker 2 (07:39):
Yeah, command line, a Sadman, WEBGUI, even Arrest API pretty flexible.
Speaker 1 (07:45):
Okay, foundation set. Let's dive back into the MVC components,
but specifically the Java MVC way, starting with the model
and that CDI thing you mentioned.
Speaker 2 (07:55):
Right, So Java MVC uses CDI two point zero to
manage your model classes. Yeah, you typically don't do new
my model. CDI handles creating and providing instances.
Speaker 1 (08:05):
How does it know which classes to manage?
Speaker 2 (08:07):
Usually annotate them. The simplest is that named You put
it named on your Java being, say your book class,
and CDI takes over makes it available to your views.
Speaker 1 (08:15):
Okay, annotation magic pretty much.
Speaker 2 (08:17):
And CDI manages the lifespan of these objects through scopes.
Speaker 1 (08:20):
This is really important to the copes, like how long the
data lasts exactly.
Speaker 2 (08:23):
There's request scope, a new instance for every single HTTP
request lives only for that request response cycle. Good perfect
for temporary stuff like the data submitted in a form.
Then session scope, the instance sticks around for the user's
entire browser session. Great for things like user login information, shopping.
Speaker 1 (08:41):
Cards, data that needs to persist across pages for one
user precisely.
Speaker 2 (08:45):
Then there's redirect scope. This one's need. It supports that
post redirect get pattern.
Speaker 1 (08:50):
Ah to stop double form submission exactly.
Speaker 2 (08:53):
The object lives across the post request and the following
get t redirect super useful.
Speaker 1 (08:58):
It definitely needed that before.
Speaker 2 (08:59):
Oh yeah, there's also application scope for data shared across
all users living until the app stops, and dependent scope
the default, which just inherits the scope of whatever injects it.
Speaker 1 (09:10):
Lots of options. What if you need something really simple.
Speaker 2 (09:12):
For quick things, there's a built in Javacs dot mvc
dot model's object you can inject into your controller. Just
add key value pairs to it and they're available in
the view. No need for a dedicated class.
Speaker 1 (09:22):
Sometimes handy for simple cases. Okay, so CDI managed the
model data in its life, Now how do we show
it the view?
Speaker 2 (09:28):
Right? The view layer. Java MVC mainly uses two templating
technologies here, JSPS, Java server pages and facelets.
Speaker 1 (09:37):
JSPS are the older ones, right.
Speaker 2 (09:39):
Yeah, classic. You mix HTML with dynamic bits the modern way,
and what the source recommends is using expression language el
that syntax.
Speaker 1 (09:47):
Like dumb butt title exactly.
Speaker 2 (09:49):
Access is your CDI beans cleanly. You should also use
JSDL tags like CT ORH for loops set to different conditions.
Avoid embedding raw javascriptlets percent jsps. If you can keep
logic out of the view, keep it clean definitely, and
the source really advises against using implicit objects like param
directly in the view that mixes controller responsibilities with presentation.
(10:12):
Bad idea, Got it?
Speaker 1 (10:13):
What about facelts.
Speaker 2 (10:14):
Facelits is newer xmail based came from the JSF world
Livesten webi nfus. Its strength is templating reasonable layouts using
tags like EI dot composition, uid, define, UI dot insert
really good for consistent page structure.
Speaker 1 (10:28):
Sounds powerful any catches yes, a.
Speaker 2 (10:30):
Big one for Java MBC. While facelts is great for templates.
You should avoid mixing in actual JSF components or using
JSS specific expression language. Why is that paradigm mismatch? JSF
has its own life cycling component model. Trying to shoehorn
that into Java mvc's request driven model can cause weird
issues in instability. Stick to facelets for templating, use standard
(10:51):
EEL for data access in Java mvc.
Speaker 1 (10:53):
Okay, noted, keep JSF stuff out of Java mvc.
Speaker 2 (10:57):
Facelts Right now, the controller, how do you make one annotations?
Speaker 1 (11:00):
Again?
Speaker 2 (11:00):
You bet at controller on the class, usually paired with
at path to define the base URL like at path books.
Speaker 1 (11:07):
Okay, and methods handle requests YEP.
Speaker 2 (11:11):
For a get request, say to show a list of books.
A method might return a string the name of the
JSP or Facebook file like booklist dot jsp simple, or
for more control, it can return a response object that
lets you set h GDP status codes, headers, cookies explicitly.
Speaker 1 (11:26):
Ah more power there, and.
Speaker 2 (11:28):
The final URL path is built up application path class
at path method at path all cancatenated makes sense.
Speaker 1 (11:34):
How does the controller prepared data for the view?
Speaker 2 (11:37):
It injects the needed CDI beans the model objects using
it inject that, it calls methods on them, sets values
whatever is needed before the view gets rendered.
Speaker 1 (11:44):
Okay, and post requests like.
Speaker 2 (11:47):
Forms handled similarly, but you use annotations like at form
paarent book title within the method arguments to grab the
submitted data directly.
Speaker 1 (11:57):
Okay, that covers the core components. What about making is
more robust handling user input validation crucial stuff?
Speaker 2 (12:03):
So you capture data from forms or query parameters. Now
what if the user types letters into a number field
or leave something blank.
Speaker 1 (12:13):
Errors happen?
Speaker 2 (12:14):
Right? Java MBC uses binding result. You audit as a
parameter to your controller method. It automatically catches conversion errors
or validation failures, and then you can check binding result
for errors. If there are any. You typically add the
air messages to the model's object and return to the
same view showing the user what went wrong.
Speaker 1 (12:32):
Nice keeps them on the form.
Speaker 2 (12:33):
Exactly and being validation makes this even better. You put
annotations right on your controller method parameters or on your
model bean fields at notinal at size and five at
pattern Reex built in rules loads of them, and you
can create custom ones too. Plus you can easily internationalize
the error messages using validation messages dot properties files, so
error messages appear in the user's language.
Speaker 1 (12:54):
Very professional. Okay, what about state you mentioned sessions earlier.
Speaker 2 (12:57):
Yeah, persisting state. HTTP is stateless, but web apps aren't.
We need to remember things about a user between requests.
HTTP session is the standard.
Speaker 1 (13:08):
Javaway managed by the server YEP.
Speaker 2 (13:10):
Usually via cookies behind the scenes. Java MBC makes this
easy with at session scope CDI beans. Just inject your
ad session scope user preferences being and its data sticks
around for that user. Session. Seems convenient, it is, but
big caveat. Don't stuff everything into the session, especially large
objects or lots of data per user. If you have
(13:31):
thousands of users.
Speaker 1 (13:32):
Online, memory usage explodes exactly.
Speaker 2 (13:34):
It can kill your server's performance and stability. Use session
scope judiciously only for data that truly needs to persist
for the session duration.
Speaker 1 (13:42):
Good warning. What about making the UI more dynamic? You
mentioned AJX.
Speaker 2 (13:46):
Right AGX asynchronous JavaScript in XML, though nowadays it's off
in JSON not XML. The idea is the browser uses
JavaScript to make background requests to the server without a
full page reload.
Speaker 1 (13:57):
Smoother experience, much smoother.
Speaker 2 (14:00):
Mber Is like jQuery made this easier, but modern JavaScript
has fetch api built in Your Java mvc controller can
handle these AJAX requests. Instead of returning a full page name,
it might return just an h T Mel fragment or
maybe Jason data.
Speaker 1 (14:13):
Okay, so the controller can serve both full pages and
AJX snippets.
Speaker 2 (14:18):
Absolutely. The JavaScript on the front end then takes that
response and updates just the relevant part of the page,
maybe updates account, refreshes, a list, shows a status message.
Speaker 1 (14:27):
Very cool. You also mentioned observers.
Speaker 2 (14:28):
Yeah, CD observers. This is a really elegant way to
handle cross cutting concerns, things like logging, performance monitoring, security checks.
Stuff that needs to happen in response to events, but
isn't core business logic.
Speaker 1 (14:40):
How does it work.
Speaker 2 (14:41):
You create a method in a cdibing and annotate it
with at observes. You specify the event type you're interested in,
like maybe an event fired just before a controller method
runs bore controller event from javax dobc dot event ah.
Speaker 1 (14:55):
So it listens for specific points in the process.
Speaker 2 (14:57):
Exactly when that event happens, automatically calls your observer method.
It keeps that logging or monitoring code completely separate from
your controller logic. Really improves maintainability.
Speaker 1 (15:09):
That separation of concerns again seems to be a running theme.
Speaker 2 (15:12):
It's the theme of good architecture really, which brings us
to bigger enterprise integration like databases.
Speaker 1 (15:18):
Right, how does Java MBC talk to a database JPA.
Speaker 2 (15:22):
YEP JPA, Java persistence API the standard way in Jakarta EE.
It abstracts away most of the raw sequel uses orim
object relational mapping.
Speaker 1 (15:31):
So your Java book object maps to a books table precisely.
Speaker 2 (15:34):
You define this mapping using annotations at entity table at
iocolumn right on your Java class and you can figure
the database connection details in a persistence dot XML file.
Speaker 1 (15:43):
And how do you actually interact with the data through.
Speaker 2 (15:46):
The entity manager. You inject it, and it has methods
like find, persist, merge, remove. It handles translating those calls
into SQL. You'll also need to set up a database
like apatchy Derby and can figure a data source in
glass Fish okay.
Speaker 1 (16:01):
So JPA handles the database mapping and interaction. What about
EJBs Enterprise Java beans EJBs.
Speaker 2 (16:07):
Are components for business logic. They run in a container
that provides services like transactions, security, concurrency management automatically.
Speaker 1 (16:15):
More than just plan Java objects right.
Speaker 2 (16:17):
There are different types, mainly session EJBs. Stateless ones are common.
They don't hold client specific state between calls. Good for
service operations like processing a book rental okay. Stateful EJBs
do maintain state across multiple calls from the same client.
Useful for multi step processes like a Wizard or complex
checkout Singleton. EJBs ensure only one instance exists for the
(16:38):
whole application. Good for cases or coordinating tasks.
Speaker 1 (16:41):
How does your MBC controller use an EJB?
Speaker 2 (16:44):
Usually just inject it Using an EJB, the container handles
providing the instance. EJBs also have cool features like at
asynchronous for background tasks and its schedule for time, jobs.
Speaker 1 (16:54):
Powerful stuff and managing all this complexity, Logging must be vital.
Speaker 2 (16:58):
Absolutely critical, and enterprise apps for debugging, auditing, just understanding
what's going on. GlassFish uses the standard JSR forty seven
logging API.
Speaker 1 (17:08):
By default, where did the logs go?
Speaker 2 (17:10):
Typically to server dot log. You have different levels severe warning, info, fine,
finer finance. You configure the level to control how much
detail you get.
Speaker 1 (17:18):
Can you use other logging frameworks?
Speaker 2 (17:20):
Yes. Log forg is a very popular, powerful alternative. It
separates the logging API from the implementation, can reload its
configuration without restarting the server. Lots of advantages. You can
integrate at server wide or just for your application.
Speaker 1 (17:33):
Choosing the right logging level seems important.
Speaker 2 (17:35):
It is too little, you can't debug too much. It
impacts performance. You need a strategy. What stands out here
is just how essential good logging is for maintaining complex systems.
Speaker 1 (17:46):
Definitely so bringing it all together, this book club example
really uses all these pieces.
Speaker 2 (17:52):
Doesn't it. It really does. It uses Derby as the
database configured in glass Fish. It has internationalization for messages,
It uses APA entities for member book rental. It uses
stateless EJBs as data access objects baos to handle the database.
Speaker 1 (18:08):
Operations, okay, EJB's for the data logic.
Speaker 2 (18:11):
Then it has simple CDI beans acting as the model
for the views. A central Java MVC controller manages all
the web interactions, and the views are jsps using fragments
and some JavaScript for those dynamic updates.
Speaker 1 (18:23):
It's quite a good demonstration of how these seemingly separate
technologies MBC, CDI, JPA, EJB all integrate cleanly within the
Jakarta E platform.
Speaker 2 (18:32):
Exactly. You see how a complex system gets built from
these well defined modular parts.
Speaker 1 (18:36):
Okay, well, that feels like a pretty third journey through
Java Mvc one point zero. We started with the basic
MBC pattern, looked at Java NBC specifics under JSR three
seventy one, touched on its Jakarta E foundations.
Speaker 2 (18:48):
Cover the component's model with CDI scopes, view a JSP
and facelooks, caveats, controller handling requests right.
Speaker 1 (18:55):
And then validations, state management with sessions, AJAX observers, integrating
with JPA databases and EJBs, and finally logging strategies.
Speaker 2 (19:05):
A comprehensive look.
Speaker 1 (19:06):
So hopefully you now have a really solid grasp of
how Java NBC works and how you can use it
to build robust, scalable, maintainable applications, web cloud, micro services,
the lot.
Speaker 2 (19:18):
And maybe this raises an important question for you, the listener,
to think about as patterns evolve, How does understanding something
foundational like MVC help you adapt?
Speaker 1 (19:27):
Hmmm, good question.
Speaker 2 (19:28):
Think about how these core ideas, separation of concerns, defined
roles for data logic presentation might show up even in
newer frameworks, maybe just with different names or syntax. How
does this foundation empower you? What stands out to you
about how these architectural patterns really help developers build better software.
Speaker 1 (19:45):
That's fantastic thought to leave things on something to definitely
mull over. Thank you so much for joining us on
this deep dive. We hope you found it valuable.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
The Burden
The Burden is a documentary series that takes listeners into the hidden places where justice is done (and undone). It dives deep into the lives of heroes and villains. And it focuses a spotlight on those who triumph even when the odds are against them. Season 5 - The Burden: Death & Deceit in Alliance On April Fools Day 1999, 26-year-old Yvonne Layne was found murdered in her Alliance, Ohio home. David Thorne, her ex-boyfriend and father of one of her children, was instantly a suspect. Another young man admitted to the murder, and David breathed a sigh of relief, until the confessed murderer fingered David; “He paid me to do it.” David was sentenced to life without parole. Two decades later, Pulitzer winner and podcast host, Maggie Freleng (Bone Valley Season 3: Graves County, Wrongful Conviction, Suave) launched a “live” investigation into David's conviction alongside Jason Baldwin (himself wrongfully convicted as a member of the West Memphis Three). Maggie had come to believe that the entire investigation of David was botched by the tiny local police department, or worse, covered up the real killer. Was Maggie correct? Was David’s claim of innocence credible? In Death and Deceit in Alliance, Maggie recounts the case that launched her career, and ultimately, “broke” her.” The results will shock the listener and reduce Maggie to tears and self-doubt. This is not your typical wrongful conviction story. In fact, it turns the genre on its head. It asks the question: What if our champions are foolish? Season 4 - The Burden: Get the Money and Run “Trying to murder my father, this was the thing that put me on the path.” That’s Joe Loya and that path was bank robbery. Bank, bank, bank, bank, bank. In season 4 of The Burden: Get the Money and Run, we hear from Joe who was once the most prolific bank robber in Southern California, and beyond. He used disguises, body doubles, proxies. He leaped over counters, grabbed the money and ran. Even as the FBI was closing in. It was a showdown between a daring bank robber, and a patient FBI agent. Joe was no ordinary bank robber. He was bright, articulate, charismatic, and driven by a dark rage that he summoned up at will. In seven episodes, Joe tells all: the what, the how… and the why. Including why he tried to murder his father. Season 3 - The Burden: Avenger Miriam Lewin is one of Argentina’s leading journalists today. At 19 years old, she was kidnapped off the streets of Buenos Aires for her political activism and thrown into a concentration camp. Thousands of her fellow inmates were executed, tossed alive from a cargo plane into the ocean. Miriam, along with a handful of others, will survive the camp. Then as a journalist, she will wage a decades long campaign to bring her tormentors to justice. Avenger is about one woman’s triumphant battle against unbelievable odds to survive torture, claim justice for the crimes done against her and others like her, and change the future of her country. Season 2 - The Burden: Empire on Blood Empire on Blood is set in the Bronx, NY, in the early 90s, when two young drug dealers ruled an intersection known as “The Corner on Blood.” The boss, Calvin Buari, lived large. He and a protege swore they would build an empire on blood. Then the relationship frayed and the protege accused Calvin of a double homicide which he claimed he didn’t do. But did he? Award-winning journalist Steve Fishman spent seven years to answer that question. This is the story of one man’s last chance to overturn his life sentence. He may prevail, but someone’s gotta pay. The Burden: Empire on Blood is the director’s cut of the true crime classic which reached #1 on the charts when it was first released half a dozen years ago. Season 1 - The Burden In the 1990s, Detective Louis N. Scarcella was legendary. In a city overrun by violent crime, he cracked the toughest cases and put away the worst criminals. “The Hulk” was his nickname. Then the story changed. Scarcella ran into a group of convicted murderers who all say they are innocent. They turned themselves into jailhouse-lawyers and in prison founded a lway firm. When they realized Scarcella helped put many of them away, they set their sights on taking him down. And with the help of a NY Times reporter they have a chance. For years, Scarcella insisted he did nothing wrong. But that’s all he’d say. Until we tracked Scarcella to a sauna in a Russian bathhouse, where he started to talk..and talk and talk. “The guilty have gone free,” he whispered. And then agreed to take us into the belly of the beast. Welcome to The Burden.