Level of knowledge required to understand the article: you have already more or less understood Java Core and would like to look at JavaEE technologies and web programming. It makes the most sense if you are currently studying the Java Collections quest, which covers topics close to the article.
I'm currently using IntelliJ IDEA Enterprise Edition (this is a paid advanced version of the IDE, it is usually used in professional development -
editor's note ). It is much easier to work with web projects than the free Community Edition. So, in the Enterprise Edition, literally with one click of the mouse, the project is assembled, poured into a servlet container, the server starts, and even a page with the running project opens in the browser. In the free version of the idea, much of this would have to be done independently, so to speak, “by hand.” I use Apache Maven to build the project and manage its lifecycle. In this I used only a small fraction of its capabilities (package/dependency management). I chose Apache Tomcat version 9.0.0.M4 as the servlet container/Application server. I know that there are already newer versions, but this is the one I have installed.
Let's get started
First, let's open IntelliJ IDEA and create an empty Maven project.
Here on the left we select Maven, check that the JDK for the project is indicated at the top. If it is not there, select the one you need from the list, or click New... and select directly from your computer. In the middle of the window I have an animation of loading the list of archetypes. We don’t need them, so without waiting for the download, feel free to click Next at the bottom of the window.
In this window you need to specify
GroupId and ArtifactId . GroupId refers to the unique identifier of the company that produces the project. It is common practice to use the company's domain name, but in reverse order. Not in the sense of a mirror, but if, for example, the domain name of a company
is maven.apache.org , then its GroupId will be
org.apache.maven . That is, first we write the first-level domain, separate it with a dot, write the name of the second-level domain, and so on. This is the generally accepted approach. In the event that you are “cutting” a project on your own, and not as part of a company, write your personal domain name here (also in reverse order!). If you have it, of course :). If not, don't be upset. In fact, you can write
anything here .
For a company with the domain name vasya.pupkin.org, the GroupId will be org.pupkin.vasya. This approach to names is needed in order to separate projects with the same name, but which were released by different companies. |
In this example, I will use the fictitious domain name
fatfaggy.info.javarush.ru . Accordingly, I enter
ru.javarush.info.fatfaggy in the GroupId field .
ArtefactId is simply the name of our project. You can use letters and some symbols (hyphens, for example) to separate words. Our “artifact” will be called exactly as we write here. In this example, I write
my-super-project . We don’t touch the version field for now, we leave it as is.
Well, the standard IDEA window when creating a new project.
Let's call it my-super-project according to tradition .
The project has been created!
The pom.xml file immediately opened in front of us. This is a file with Maven settings. If we want to “tell” Maven what and how to do or where to get something from, we describe all this in this very pom.xml file. It is located at the root of the project. |
We see that it now contains exactly the data that we entered when creating the Maven project:
groupId ,
artifactId and
version (we did not touch the latter).
Our project structure
This Maven project has a certain structure.
As we can see, at the root lie:
- the .idea directory , which contains the idea settings for the current project;
- the src directory in which we create our sources;
- my-super-project.iml file , a project file created by IDEA;
- pom.xml file , the same Maven project file that I talked about just above, which we now have open. If I mention pom.xml or “pom” somewhere, I will mean this particular file.
The src folder in turn contains two subfolders:
- main - for our code;
- test - for tests for our code.
Both
main and
test have a
java folder . Consider that these are the same folder, only the one in
main is for the source code, and the one in
test is for the test code, respectively.
We don’t need the resources folder at all for now, we won’t use it. But let him lie down.
Turning into a web project
It's time for us to convert our Maven project into a web project. To do this, right-click on the project name in this tree and select
Add framework support...
A window will open where we can add support for all sorts of different frameworks for our project. But we only need one:
Web Application . We choose him.
We check that there is a checkmark next to
Web Application , and in the main part of the window it is noted that we want a
web.xml file to be created for us immediately (I recommend checking the box if it is not there). After this, we will see that the structure of our project has been supplemented with the
web folder .
This is the root of our web project at
/ . That is, if we enter the localhost address in the browser (when we launch it, of course), then it will be accessed exactly here, to the root of the web project. If we enter
localhost/addUser , then the web folder will look for a resource called
addUser .
The main thing is to understand that the web folder is the root of our project when we upload it to Tomcat. Now we have a certain folder structure, but in the finished project that we will upload, it will be slightly different, and the web folder will be the root there. |
In
web there is a required folder called
WEB-INF , where the
web.xml file is located , which we asked to create in the previous step. Let's open it.
As you can see, there is nothing interesting in it yet, just the “hat”. By the way, if we had not asked to create it, we might have had to create it manually, that is, type this entire “header” by hand, or, in extreme cases, look for a ready-made version on the Internet. What is
web.xml for ? For mapping. Here we will tell Tomcat which URL requests to send to which servlets. But that’s all later, for now we’ll leave it empty. There is also a file
index.jsp in the
web folder . Let's open it.
This is the file that will be executed by default, so to speak. That is, when we launch the project, this is exactly what we will see. In essence,
jsp is a regular html file, with the difference that you can execute java code in it.
A little about static and dynamic content
Static content is content that does not change over time. Everything that we wrote in the html file will be displayed without changes. If we wrote hello world, then this inscription will be displayed as soon as we open the page, and in 5 minutes, and tomorrow, and in a week, and in a year. She won't change. But what if we want to display the current date on the page? If we simply write “October 27, 2017,” then tomorrow we will see the same date, and in a week, and in a year. But I would like this date to still be relevant. This is where the ability to execute some code directly inside the page comes to our aid. We can get a date object, convert it to the form we need and display it on the page. Then every day, whenever we open the page, the date will always be relevant. If we only need static content, then a regular web server and html files are enough for us. We don’t need any Java, Maven, or Tomcat. But if we want to use dynamic content, this is where all this will come in handy. But for now let's return to our
index.jsp . Let's indicate something of our own instead of the standard header, for example, “My super web-app!”, and in the body we’ll write, for example, “I’m alive!” We are almost ready to launch our project! But, unfortunately, the usual green triangle for launching the program is not active.
Let's click on the button to the left of it (indicated on the screen with a red arrow) and select
Edit configurations... A window will open where we are asked to click on the green plus sign to add some kind of configuration. Click on it, it is located in the upper left corner of the window.
Select the
Tomcat Server item and the
Local sub-item. A window will open with many different parameters, but we are happy with almost everything and the default one.
We can somehow nicely name our configuration instead of the standard
Unnamed (at the very top).
It is also necessary to check that the idea successfully found Tomcat in our system (you already downloaded and installed it before , right?). If you can’t find it (which is unlikely), click the down arrow and select where we have it installed, or another version if you have several of them. I have one and it’s already installed, so everything looks like on the screenshot. And at the very bottom of the window we see that there is a warning that there is not a single artifact intended for deployment to the server. And to the right of this inscription there is a button that offers to correct this defect. We click on it and see that the idea itself found everything, created everything itself, what it was missing, and made all the settings itself.
We see that we were transferred from
the Server tab to the Deployment tab , in the
Deploy at the server startup section we already have the artifact that needs to be deployed, and below it is indicated that this artifact will be built before deployment.
Apply, Ok. And we see that firstly, at the bottom of the window a section has appeared with our local Tomcat server, into which our artifact will be placed. You can collapse this section by clicking on the corresponding button on the right side of the window.
We also see that the green triangle for launch is already active. For those who want to check everything, you can click on the button with the project settings (to the right of the launch buttons, marked with a red arrow), go to the
Artifacts section and make sure that the artifact has really been created. It wasn't there until we pressed that
Fix button , but now everything is ok. And this configuration suits us quite well. In a nutshell, the difference between
my-super-project:war and
my-super-project:war exploded is that
my-super-project:war will create only one war file (which is just an archive), and the option with
exploded is simply
an “unpacked” war . And this option is personally more convenient for me, as it allows me to quickly deploy small changes to the server. In fact, the artifact is our project, only already compiled, and in which the folder structure has been changed so that it can be uploaded directly to Tomcat. It will look something like this:
Well, now everything is ready to launch our project.
We press the coveted green start button and enjoy the result! :)
GO TO FULL VERSION