This workshop will be retired on May 1, 2025.
Heads up! To view this whole video, sign in with your Courses Plus account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
In order to deploy our app to an existing application server, we'll need to build a Web Application ARchive (WAR) that let's the server know about our Spring components.
Structure of a WAR File
If you were to use an archive utility to view the contents of a WAR file, here's what you'd see:
weather-0.0.1-SNAPSHOT.war
├─ META-INF
| └─ MANIFEST.MF # empty except for version
├─ WEB-INF
| ├─ classes
| ├─ api.properties
| ├─ application.properties
| ├─ com
| ├─ teamtreehouse # our root package
| ├─ static/ # web app assets
| ├─ templates/ # Thymeleaf templates
| ├─ jboss-web.xml # context root definition
| └─ lib # JARs for dependencies
Java Platform, EE (Enterprise Edition)
Java EE defines a set of standards (APIs) for developing web and other enterprise applications. A Java EE application server is one that provides implementations of the Java EE APIs. For a look at all the packages, annotations, interfaces, enums, abstract classes and classes of Java EE 7, see the documentation here:
https://docs.oracle.com/javaee/7/api/
Setting the Active Profile(s)
At runtime
You can set the active profile at runtime, for example, when running your app from a JAR. For this option, you'll specify a system property using the -D option. For example:
java -Dspring.profiles.active=dev -jar build/libs/weather-0.0.1-SNAPSHOT.jar
In Application.java
You can set profiles programmatically using a SpringApplication object from your apps class that contains the main method. This class might look as follows:
@EnableAutoConfiguration
@ComponentScan
public class Application {
public static void main(String[] args) {
SpringApplication app = new SpringApplication(Application.class);
app.setAdditionalProfiles("dev");
app.run(args);
}
}
Using Github With This Course
You can complete this course by using the code I've made available to you in two ways:
- Use the Github repository I've made available (recommended), or
- Use the project files linked at the bottom of this page
If you choose the recommended option of using the Github repository, it can be found at
https://github.com/treehouse-projects/spring-deploy-weather
To utilize Github with this course, you can download the Github desktop client for your system or use the command line interface provided with Git.
Clone this repository to your machine using the Github desktop client, or using the following command:
git clone git@github.com:treehouse-projects/spring-deploy-weather.git
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
The approach we're going to tackle next,
0:00
is one of deploying your build to
an existing application server.
0:01
In order to deploy your app
to an application server,
0:05
you'll likely need a WAA file.
0:07
WAA stands for Web Application Archive and
it's kind of like a jar file, but
0:09
its contents have a different structure.
0:12
Check the teacher's notes for
details on WAA files.
0:14
The server all use for
demonstrating is WildFly.
0:17
Now, this is what used to be known
as the JBoss Community Edition.
0:20
JBoss is a flagship product
as an application server
0:24
that's a full implementation of
Java Enterprise Edition or Java EE.
0:26
This means that the server
provides implementations for
0:31
all Java EE interfaces.
0:33
For example,
JBoss implements dependency injection, or
0:35
a DI,
by leveraging the inject annotation, and
0:38
also implements the Java Persistence API,
or JPA, with Hibernate.
0:42
For more on Java EE, check out the
teachers notes as well In any case JBoss
0:47
was bought by Red Hat in 2006, but
the community edition of JBoss remains
0:52
open source and freely available and
in 2014 was renamed WildFly.
0:58
Before we do anything with WildFly,
we'll need to make some code changes to
1:04
our application can play nicely
with another web server.
1:07
Specifically, we need to configure
our app for a Servlet 3.0 container.
1:12
What is a servlet container you ask?
1:16
A servlet container is a component on
a web server that is configured to handle
1:19
HTTP requests that are process
by Java applications.
1:23
The container creates and maintains, what
are called servlets and these servlets
1:26
were the things that interact
directly with our application code.
1:30
For Spring weather applications typically
we'll need to Servlet container to create
1:33
Spring's DispatcherServlet
which will marshal a quests for
1:36
configured controllers.
1:40
To configure a Servlet 3.0 container
such as that provided by WildFly.
1:42
To bootstrap our application and create
this DispatcherServlet, we'll need to
1:46
implement the web application initializer
interface which is an interface
1:50
detected by the Servlet container
Spring has a handy way of doing this.
1:53
So let's go to the application class and
do that.
1:58
Spring-boot provides
an abstract class called
2:00
SpringBootServletInitializer that
we can extend right here.
2:04
So extends SpringbootServletInitializer
just like that.
2:09
Now this is an abstract class and
if you look at the source,
2:14
it implements that
WebApplicationInitializer interface.
2:18
Cool, now in this class we'll then
override the configure method right
2:22
here which allows us to add the sources
of all of our configuration classes.
2:28
Now, in this method, we'll just
add the application class since it
2:33
already includes an annotation to scan for
2:36
components in its package and
all sub-packages.
2:39
So let's do that now, I will use that
builder or parameter value there.
2:43
I will add the source
application that class, cool.
2:50
There are other things you
could do here in this method.
2:54
So check the teacher's notes for
an example.
2:57
Next, let's move to the data config
class In our application deployed
3:00
to WildFly we'll configure the data
source on the web server itself.
3:05
As you'll see on the web server we'll end
up giving our database an easy to look up
3:08
name using the Java naming and
directory interface or JNDI.
3:12
This is just a way for Java applications
to look up databases or objects by name.
3:16
What this means for us in our data config
class is that we'll need an alternate
3:23
data source bin to be used in our
application that's deployed to WildFly.
3:27
This one that's configured in
the application will no longer suffice
3:32
since that configuration will
now appear on WildFly itself.
3:35
So what we'll wanna do is create
another data source bean method.
3:40
Just like this.
3:44
Bean public datasource and
3:46
I'll call this jndiDataSource.
3:51
Now, we want this DataSource being
to be picked up sing the simple name
3:57
DataSource but this method name is
not data source in fact in order for
4:01
the Java code to compile a cannot be
DataSource that's a compiler error.
4:05
Two methods with the same signature and
same class cannot exist.
4:09
So let's specify that the name
of this being is DataSource.
4:13
Now the name of this bean up here is
already by default data source because by
4:19
default spring will use
the method name to name beans.
4:22
Now to be sure that our application only
has one unique data source being available
4:28
to it at run time, we need to specify
what are called profiles in spring.
4:35
For example we could use this being
here all specify the profile we
4:40
could use this bean in
production abbreviated prod and
4:45
this bean in will say a development
environment abbreviated dev.
4:50
Now, in any given deployment,
4:57
whether it's in a development environment
or in a production environment,
4:58
I want to make sure that exactly one of
these beans is available, this bean for
5:01
the production environment and
this bean for the development environment.
5:07
In order to do that,
I need to set the active profile in spring
5:11
If we don't set the active profiles,
spring will detect two dataSource beans
5:17
as injectable and when that happens and
5:22
a dataSource bean as needed, we will get
a no such bean definition exception.
5:25
Since bean definitions need to be
unique in any running application.
5:29
Now, there are a couple ways to do this,
I'll demonstrate one option here and leave
5:35
a couple other options in the teacher's
notes, so, be sure to check those out.
5:38
The optional show here, is setting the
active profile and application.properties.
5:41
This is a pretty speedy task for us,
we'll create a property at the top,
5:46
named spring.profiles .active and
5:51
set it to prod and that's it.
5:56
Now when an application has multiple
qualifying beings available as a lot of
6:00
wired or otherwise injected dependencies
assuming only one of those has been
6:03
annotated with the profile prod
that one will be chosen and
6:07
we can avoid that no such
being definition exception
6:12
the other thing this allows us
to do is pretty handy here.
6:16
It allows us to avoid the scenario where
we're commenting out one of these or
6:19
the other.
6:23
When we're switching between the two
environments, we can leave both intact and
6:23
set a profile for
each one of them, individually.
6:27
Pretty handy feature in spring.
6:30
Okay, let's implement this
jndiData Source method right here.
6:32
Do here is use Springs
6:38
jndidatasource to look up to grab
the name of the data source.
6:42
So that's new jndidatasourcelookup,
and since I don't want to
6:46
hard code configuration in my source code
I'll grab this from the properties file.
6:52
So getdatasource(end).
6:55
.get property and
6:58
I'll say it's Weather.jndi let me
stick my sim icon at the end and
7:01
of course we better add that
property to our properties file.
7:07
So let's go back to
application.properties and
7:11
I will add that right
here whether.jndi and
7:15
I will set that equal to
java colon slash weather.
7:20
Now, by convention, we begin a jndi name
with this URL scheme, java colon slash.
7:24
Cool, that should do it for
the properties put these file here.
7:32
But hey speaking of properties
we need to be careful with our
7:34
property source annotations.
7:37
Now, unless otherwise specified in
our app that's deployed to wild life
7:39
those properties file paths will be
considered relative to the root of our app
7:43
instead of the class path.
7:47
To make sure that our properties
are still found we need to indicate
7:48
that those are on the class path.
7:51
Now I'll use Control + Shift + F
to trigger a global search here.
7:53
We'll do PropertySource just like that,
and I see I have five locations
7:59
where I have the PropertySource
annotation referencing api.properties.
8:07
And you can see in each one of these,
that down here I just used api.properties
8:12
now to make sure that this is
relative to the class path.
8:16
I need to prepend this with class
path colon just like that and
8:21
I can do that in each one of these class
hath right from the search window,
8:26
course you could also go
in to those files directly.
8:32
Let me just copy that
8:35
there also.
8:39
So all of those have been
updated to include class path
8:49
in the path of the properties file.
8:53
So that wild fly doesn't give me an error
when I try to deploy the application.
8:56
Excellent let me close this window.
9:01
Our second and the last task before
creating a wire is to configure a great
9:04
I'll build file to use the war plot again.
9:07
So let me hop over to the build file and
under the apply plugin spring boot
9:09
I'll say apply plugin war excellent.
9:14
Then we should set a couple properties for
the grid wire task like this right here.
9:19
In fact, I'll just copy that and
paste it right here.
9:25
Changing this from a jar to war.
9:28
Cool.
9:31
Okay, before we address the issue
of the embedded web server.
9:33
I'm gonna to revert my code.
9:36
My dependencies here, so
that it uses the default.
9:38
That is the included Web server in
the Spring Boot start thymeleaf,
9:41
which is Tomcat.
9:45
So, I'm going to remove
jetty as a dependency, and
9:46
I'm gonna remove that line of code
that says exclude the Tomcat module.
9:51
So, if I were to run the boot run task
we'd have Tomcat up and running again.
9:56
Okay.
So now that we have Tomcat included by
10:00
default again, we want to make sure that
Tomcat Servlet container doesn't conflict
10:03
with Wildfly's Servlet container because
its Wildfly's Servlet container that would
10:06
be running our application.
10:10
So we'll need to mark Tomcat as
a provided dependency at runtime.
10:11
In order to do that,
I'll just stick that right here.
10:16
We use providedRuntime.
10:19
And then we just name that dependency
‘org.springframework.boot:spring-boot-
10:23
starter-tomcat’.
10:33
Excellent.
So, this will make sure that when
10:36
our war file is built it will not
include this imbedded web server here
10:39
because we are well we're deploying
the war file to an actual web server.
10:43
We don't need the embedded one and
even further,
10:48
it will conflict with wild
flies server like container.
10:50
Okay, almost there.
10:54
One final task before building.
10:56
If we want to specify the context
root of our application,
10:58
to be something other than
the name of our archive.
11:01
That is, we want a URL that isn't,
localhost:8080/whether-0.0.1-snapshot.
11:03
Well then we've got to add
11:07
a certain file to our application,
that WildFly can detect.
11:11
And this file has to be
named jboss-web.xml and
11:16
it's got to be located
in a certain directory.
11:20
What directory is that?
11:22
Well it's under source/main and
I'll create the other directories here.
11:24
/webapp/web-INF and then the file
11:28
there jboss-web.xml And
11:32
these directories will be created when I
click OK yes I will add that to get and
11:38
here is our X.M.L. file so again source
main web app web and and there's our file.
11:43
Now we' gonna need to
create a couple X.M.L.
11:50
elements here the first one
the top level one is J.
11:52
Boss web.
11:55
And then in order to specify
the context root will use
11:56
an XML element named just that.
12:00
We want it to be the single slash will it
will be the root of the Web Server and
12:02
that is all.
12:07
With that said let's build this thing.
12:09
So I'll open my terminal here.
12:11
All this up to give myself a little more
space and I will do .slash gradlew or
12:13
gradlew.bat and if you wanna build
here it'll run the unit tests and
12:19
then you'll get the war file as well.
12:24
If you want to skip unit
tests you could use war.
12:26
In the last video you
could have used ./gradlew
12:29
jar if you wanted to skip the unit tests.
12:32
So I'll just run the war here since I
know my unit tests are already passing.
12:34
You should see the code compiling and
12:43
hopefully you'll have
a successful build there.
12:45
So in the build directory
now what you should see yes,
12:47
you should see the original jar and
then you should see a war there as well.
12:52
Cool.
12:57
We're ready to deploy this to
wild fly in our next video.
12:58
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up