JavaRush /Java Blog /Random-TL /Web application sa Java

Antas

28 February 2021
47 views
0 comments

Web application sa Java

Panimula

Noong unang panahon, pinalakas ng Java ang posisyon nito dahil sa pagpili nito ng mga web application bilang priyoridad. Mula noong mga unang araw nito, ang Java ay nagpupumilit na makahanap ng paraan. Una, nagmungkahi ako ng mga applet. Nagbigay ito ng maraming pagkakataon para sa mga developer na lumikha ng dynamic na nilalaman sa mga static na HTML na pahina. Gayunpaman, hindi naabot ng mga applet ang mga inaasahan sa maraming dahilan: seguridad, overhead, at iba pa. Pagkatapos ay iminungkahi ng mga developer ng wikang Java ang isang alternatibo - Servlet API . At ito ay naging tamang desisyon. Ang Servlet API ay ang detalye kung saan binuo ang anumang Java web application, ito man ay isang web-based na application o isang web service na nagbabalik ng impormasyon ayon sa hinihiling. Samakatuwid, ang landas sa pag-unawa kung paano gumagana ang mga Java web application ay nagsisimula sa pag-unawa sa Servlet API.

Servlet API

Kaya, ang Servlet API ay ang inaalok ng mga developer ng wika sa mga developer ng Java. Ang Servlet API ay isang detalye na dapat sumagot sa aming mga pangunahing tanong. Makikita mo ito dito: " JSR-000340 JavaTM Servlet 3.1 Final Release for Evaluation ". Ang kabanata na " 1.1 Ano ang isang Servlet? " ay nagsasabi na ang isang servlet ay isang bahagi ng web batay sa teknolohiya ng Java na lumilikha ng dynamic na nilalaman (iyon ay, nilalaman). "Batay sa Java" ay nangangahulugan na ang isang servlet ay isang klase ng Java na pinagsama-sama sa bytecode . Ang mga servlet ay pinamamahalaan ng isang servlet container, kung minsan ay tinatawag na Servlet Engine. Ang servlet container ay isang web server extension na nagbibigay ng servlet functionality. Sa turn, ang mga servlet ay nagbibigay ng pakikipag-ugnayan sa kliyente sa paradigm ng kahilingan/tugon, na ipinapatupad ng lalagyan ng servlet. Sa kabanata na " 1.2 Ano ang isang Servlet Container? " sinasabing ang isang servlet container ay bahagi ng isang web server o application server na nagbibigay ng mga serbisyo sa network kung saan ipinapadala ang mga kahilingan at tugon, ang mga kahilingan at tugon na batay sa MIME ay nabuo at pinoproseso. . Bilang karagdagan, pinamamahalaan ng mga servlet container ang life cycle ng mga servlet (ibig sabihin, magpasya kung kailan gagawin ang mga ito, tanggalin ang mga ito, atbp.). Dapat suportahan ng lahat ng servlet container ang HTTP protocol upang makatanggap ng mga kahilingan at magpadala ng mga tugon. Dito nais kong idagdag na ang MIME ay isang pamantayan, isang detalye na nagsasabi kung paano dapat i-encode ang impormasyon at i-format ang mga mensahe upang maipadala ang mga ito sa Internet.

Web-server

Ang web server ay isang server na tumatanggap ng mga kahilingan sa HTTP mula sa mga kliyente at nagbibigay sa kanila ng mga tugon sa HTTP (karaniwan ay kasama ang isang HTML na pahina, larawan, file, o iba pang data). Ang mga hiniling na mapagkukunan ay tinutukoy ng mga URL. Ang isa sa pinakasikat na web server na may suporta sa Servlet API ay ang Apache Tomcat . Karamihan sa mga web server ay mga kumplikadong makina na binubuo ng iba't ibang bahagi, na ang bawat isa ay gumaganap ng mga partikular na function. Halimbawa:

Mga konektor

— Sa input mayroon kaming Mga Konektor (i.e. mga konektor) na tumatanggap ng mga papasok na kahilingan mula sa mga kliyente. Ang HTTP connector sa Tomcat ay ipinatupad gamit ang "Coyote" component. Ang mga konektor ay tumatanggap ng data mula sa kliyente at ipinapasa ito sa Tomcat Engine. Servlet Container - Tomcat Engine, sa turn, ay nagpoproseso ng kahilingang natanggap mula sa kliyente gamit ang "Catalina" component, na isang servlet container. Tingnan ang dokumentasyong Tomcat: " Pangkalahatang-ideya ng Arkitektura " para sa higit pang mga detalye. Mayroong iba pang mga web server na sumusuporta sa detalye ng Servlet API. Halimbawa, " Jetty " o " Undertow ". Ang kanilang arkitektura ay magkatulad, kaya ang pag-unawa sa prinsipyo ng pagtatrabaho sa isang servlet container, maaari kang lumipat sa pagtatrabaho sa isa pa.

Web Application

Kaya, para makapagpatakbo kami ng web application, kailangan namin ng web server na sumusuporta sa Servlet API (iyon ay, isa na mayroong extension component na nagpapatupad ng suporta ng Servlet API para sa web server). ayos lang. Ano pa rin ang isang web application? Ayon sa " 10 Web Applications " chapter ng Servlet API specification, ang Web application ay isang koleksyon ng mga servlet, HTML page, klase, at iba pang mapagkukunan na bumubuo ng panghuling aplikasyon sa isang Web server. Ayon sa kabanata na " 10.6 Web Application Archive File ", ang isang web application ay maaaring i-package sa Web ARchive (isang archive na may extension ng WAR). Gaya ng nakasaad sa pahina ng " Glossary-219 ":

Ibig sabihin, ginawa ang WAR sa halip na JAR para ipakita na isa itong web application. Ang susunod na mahalagang katotohanan: dapat tayong magkaroon ng isang tiyak na istraktura ng direktoryo sa ating WAR archive. Sa detalye ng Servlet API sa kabanata " 10.5 Direktoryo Structure ". Sinasabi ng kabanatang ito na mayroong isang espesyal na direktoryo na tinatawag na "WEB-INF". Espesyal ang direktoryo na ito dahil hindi ito nakikita ng kliyente at hindi direktang ipinapakita dito, ngunit naa-access ito sa servlet code. Sinasabi rin nito kung ano ang maaaring nilalaman ng direktoryo ng WEB-INF:

Mula sa buong listahang ito, hindi na namin alam at hindi nauunawaan ang item tungkol sa ilang web.xml file na tinatawag na deployment descriptor . Ano ito? Ang kabanata na " 14. Deployment Descriptor " ay nakatuon sa deployment descriptor. Sa madaling salita, ang deployment descriptor ay isang xml file na naglalarawan kung paano i-deploy (iyon ay, patakbuhin) ang aming web application sa isang web server. Halimbawa, isinasaad ng deployment descriptor kung aling mga URL ang dapat gamitin para ma-access ang aming application, ang mga setting ng seguridad na nauugnay sa aming application, atbp. ay ipinahiwatig. Ang kabanata na " 14.2 Rules for Processing the Deployment " ay nagsasabi na ang web.xml ay mapapatunayan ang schema bago ang aming application ay i-configure at ilunsad (iyon ay, isang pagsisiyasat na ang mga nilalaman ng web.xml ay nakasulat nang tama ayon sa schema) . At sa kabanata na " 14.3 Deployment Descriptor " ay ipinahiwatig na ang diagram ay narito: http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd Kung titingnan natin ang mga nilalaman ng file, makikita natin:

Ano ang schema na ginagamit para sa mga XML file? Ang mga schema ay nagpapahiwatig kung paano wastong punan ang isang XML na dokumento: anong mga elemento ang maaaring gamitin, anong uri ng data ang maaaring tukuyin sa mga elemento, sa anong pagkakasunud-sunod ang mga elemento ay dapat pumunta, kung anong mga elemento ang kinakailangan, atbp. Maaari mong ihambing ang schema ng isang XML na dokumento sa isang interface sa Java, dahil ang schema sa Java ay tumutukoy din kung paano dapat isulat ang mga klase na nakakatugon sa isang ibinigay na interface (iyon ay, na nagpapatupad ng isang ibinigay na interface). Kaya, armado kami ng lihim na kaalaman at handa kaming lumikha ng aming unang web application!

Paglikha ng Web Application

Mahirap isipin na nagtatrabaho sa isang modernong Java application nang hindi gumagamit ng mga awtomatikong sistema ng pagbuo ng proyekto. Ang ilan sa mga pinakasikat na system ay ang Maven at Gradle . Gagamitin namin ang Gradle para sa pagsusuring ito. Ang pag-install ng Gradle ay inilarawan sa opisyal na website . Para gumawa ng bagong application, kailangan namin ng plugin na nakapaloob sa Gradle: " Build Init Plugin ". Upang lumikha ng isang Java application kailangan mong patakbuhin ang sumusunod na command: gradle init --type java-application

Pagkatapos gawin ang proyekto, kakailanganin naming i-edit ang build.gradle file . Ito ang tinatawag na Build Script (para sa higit pang mga detalye, tingnan ang dokumentasyon ng Gradle: " Writing Build Scripts "). Inilalarawan ng file na ito kung paano i-assemble ang proyekto at iba pang aspeto ng pagtatrabaho sa isang proyekto ng Java. Inilalarawan ng bloke ng mga plugin kung aling mga " Gradle plugin " ang dapat gamitin para sa kasalukuyang proyekto ng Gradle. Pinapalawak ng mga plugin ang mga kakayahan ng aming proyekto. Halimbawa, ang default na plugin ay " java ". Palaging ginagamit ang plugin na ito kung kailangan namin ng suporta sa Java. Ngunit hindi namin kailangan ang " application " na plugin, dahil... ang paglalarawan nito ay nagsasaad na ito ay ginagamit upang lumikha ng isang "executable JVM application", i.e. nagpapatakbo ng mga aplikasyon ng JVM. Kailangan nating lumikha ng isang Web application sa anyo ng isang archive ng WAR. At kung hahanapin natin ang salitang WAR sa dokumentasyon ng Gradle, makikita natin ang " War Plugin ". Samakatuwid, tutukuyin namin ang mga sumusunod na plugin:

plugins {
    id 'java'
    id 'war'
}

Gayundin sa " War Plugin Default Settings " sinasabing ang direktoryo na may lahat ng nilalaman ng web application ay dapat na "src/main/webapp", dapat mayroong parehong WEB-INF na direktoryo kung saan dapat ang web.xml matatagpuan. Gumawa tayo ng ganoong file. Pupunan natin ito mamaya, dahil... wala pa kaming sapat na impormasyon para dito. Sa block na "dependencies" ipinapahiwatig namin ang mga dependency ng aming proyekto, iyon ay, ang mga library/framework na kung wala ang aming application ay hindi gagana. Sa kasong ito, sumusulat kami ng isang web application, na nangangahulugang hindi kami maaaring gumana nang wala ang Servlet API:

dependencies {
    providedCompile 'javax.servlet:javax.servlet-api:3.1.0'
    testCompile 'junit:junit:4.12'
}

ProvidedCompile ay nangangahulugan na ang dependency ay hindi kailangang isama sa aming WAR archive ng web application: ito ay kailangan lamang para sa compilation. At kapag naisakatuparan, ang dependency na ito ay ibibigay ng ibang tao (iyon ay, ang web server). Well, nag-iiwan kami ng impormasyon sa build script tungkol sa kung aling dependency repository ang gusto naming gamitin - lahat ng tinukoy na dependencies ay mada-download mula dito:

repositories {
    jcenter()
}

Inalis namin ang lahat ng iba pa sa build script file. Ngayon, i-edit natin ang klase src\main\java\App.java. Gumawa tayo ng isang servlet mula dito. Ang detalye ng Servlet API sa kabanata na " CHAPTER 2. The Servlet Interface " ay nagsasaad na ang Servlet Interface ay may batayang pagpapatupad ng HttpServlet , na dapat ay sapat sa karamihan ng mga kaso at kailangan lang ng mga developer na magmana mula dito. At sa kabanata na " 2.1.1 HTTP Specific Request Handling Methods " ang mga pangunahing pamamaraan na nagpoproseso ng mga papasok na kahilingan ay ipinahiwatig. Kaya, muling isulat natin ang klase ng App.java:

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.PrintWriter;
import java.io.IOException;

public class App extends HttpServlet {
    public String getGreeting() {
        return "Hello world.";
    }

    public void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
 		// https://www.oracle.com/technetwork/java/servlet-142430.html
 		PrintWriter out = resp.getWriter();
 		out.println(this.getGreeting());
 		out.close();
 	}
}

So, mukhang handa na ang lahat. Ang natitira na lang ay isulat nang tama ang deployment descriptor. Mula sa diagram, kopyahin ang sumusunod na teksto sa web.xml:

<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="..."
      version="3.1">
      ...
</web-app>

At gayundin ang landas patungo sa schema na nakasaad dito: http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd Ngayon tingnan natin ang isang halimbawa kung ano ang dapat na hitsura ng web.xml sa detalye ng Servlet API. Ang halimbawang ito ay ibinigay sa kabanata " 14.5.1 Isang Pangunahing Halimbawa ". Pagsamahin natin ang ipinahiwatig sa diagram sa halimbawang ipinahiwatig sa detalye. Nakukuha namin ang sumusunod:

<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
      http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
      version="3.1">
      <display-name>A Simple Web Application</display-name>
      <servlet>
		<servlet-name>app</servlet-name>
		<servlet-class>App</servlet-class>
	  </servlet>
	  <servlet-mapping>
		<servlet-name>app</servlet-name>
		<url-pattern>/app</url-pattern>
	  </servlet-mapping>
</web-app>

Gaya ng nakikita mo, ginamit namin ang schema at schemaLocation na tinukoy kanina. At ang paglalarawan ng mga elemento mismo ay kinuha mula sa halimbawa mula sa Kabanata 14.5.1. Kung ginawa namin nang tama ang lahat, isasagawa namin ang gawain ng gradle war nang walang mga pagkakamali:

Paglulunsad ng isang web application

Paano naglulunsad ang isang web application? Harapin muna natin ang mas kumplikadong opsyon. Nauna naming sinabi na mayroong Apache Tomcat web server na sumusuporta sa Servlet API. Nangangahulugan ito na maaari naming i-deploy ang aming nakolektang archive ng digmaan (sinasabi rin nilang "deploy") sa server na ito. Sa page na " I-download ang Tomcat ", i-download ang "Core" na uri ng paghahatid sa format na zip mula sa seksyong "Binary Distributions." At i-unpack ang na-download na archive sa ilang direktoryo, halimbawa sa C:\apache-tomcat-9.0.14. Bago simulan ang server, buksan natin ang file para sa pag-edit conf\tomcat-users.xmlat idagdag ang sumusunod na linya dito: <user username="tomcat" password="tomcat" roles="tomcat,manager-gui,admin-gui"/> Ngayon, sa command line, pumunta sa direktoryo ng bin at i-execute catalina.bat start. Bilang default, magiging available ang server console sa http://localhost:8080/manager. Ang login at password ay pareho sa mga tinukoy namin sa tomcat-users.xml. Ang Tomcat ay may "webapps" na direktoryo, na naglalaman ng mga web application. Kung gusto nating i-deploy ang sarili natin, dapat nating kopyahin ang archive ng digmaan doon. Noong dati naming pinatakbo ang gradle war command, \build\libs\isang war archive ang ginawa sa direktoryo. Ito ang kailangan nating kopyahin. Pagkatapos kopyahin, i-refresh ang pahina http://localhost:8080/managerat tingnan ang:

Kapag nakumpleto na http://localhost:8080/javaweb/app, babalik tayo sa ating servlet, dahil Dati naming "na-map" (iyon ay, na-map) ang kahilingan sa /app sa App servlet. Mayroong isang mas mabilis na paraan upang suriin kung paano gumagana ang application. At ang sistema ng pagpupulong ay tumutulong sa amin muli dito. Sa build script ng aming Gradle project, maaari kaming magdagdag ng bagong plugin na " Gretty " sa seksyon ng mga plugin: id "org.gretty" version "2.3.1" At ngayon ay maaari na kaming magsagawa ng gradle na gawain upang patakbuhin ang aming application:gradle appRun

Tingnan ang " Idagdag ang gretty plugin at patakbuhin ang app " para sa mga detalye.

Spring at Servlet API

Servlets ang batayan ng lahat. At kahit na ang sikat na ngayong Spring Framework ay hindi hihigit sa isang add-on sa Servlet API. Upang magsimula, ang Spring Framework ay isang bagong dependency para sa aming proyekto. Samakatuwid, idagdag natin ito sa build script sa block ng dependencies: compile 'org.springframework:spring-webmvc:5.1.3.RELEASE' Sa dokumentasyon ng Spring Framework mayroong isang kabanata " 1.1. DispatcherServlet ". Sinasabi nito na ang Spring Framework ay binuo sa pattern na "front controller" - ito ay kapag mayroong isang sentral na servlet na tinatawag na " DispatcherServlet ". Dumating ang lahat ng mga kahilingan sa servlet na ito, at nagde-delegate ito ng mga tawag sa mga kinakailangang bahagi. Kita mo, kahit dito may mga servlet. Kailangan mong magdagdag ng tagapakinig sa descriptor ng deployment:

<listener>
	&ltlistener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

Ito ay isang tagapakinig ng kaganapan sa konteksto ng servlet. Ibig sabihin, kapag nagsimula ang Servlet Context, magsisimula din ang Spring context (WebApplicationContext). Ano ang Servlet Context? Ito ay inilalarawan sa detalye ng Servle API sa kabanata na " CHAPTER 4. Servlet Context ". Ang konteksto ng servlet ay "view" ng servlet ng web application kung saan tumatakbo ang mga servlet. Ang bawat web application ay may sariling Servlet Context. Susunod, upang paganahin ang Spring Framework, kailangan mong tukuyin ang context-param - ang initialization parameter para sa servlet context.

<context-param>
	<param-name>contextConfigLocation</param-name>
	<param-value>/WEB-INF/app-context.xml</param-value>
</context-param>

At kinukumpleto ng kahulugan ng DispatcherServlet ang pagsasaayos :

<servlet>
	<servlet-name>app</servlet-name>
	<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
	<init-param>
		<param-name>contextConfigLocation</param-name>
 		<param-value></param-value>
	</init-param>
	<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
	<servlet-name>app</servlet-name>
	<url-pattern>/</url-pattern>
</servlet-mapping>

At ngayon kailangan lang nating punan ang file na tinukoy sa contextConfigLocation. Paano ito gawin ay inilarawan sa dokumentasyon ng Spring Framework sa kabanata "1.3.1. Deklarasyon":

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:p="http://www.springframework.org/schema/p"
    xmlns:mvc="http://www.springframework.org/schema/mvc"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="
        http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/context
        http://www.springframework.org/schema/context/spring-context.xsd
        http://www.springframework.org/schema/mvc
        http://www.springframework.org/schema/mvc/spring-mvc.xsd">

    <context:component-scan base-package="ru.javarush.javaweb"/>
    <mvc:annotation-driven/>
</beans>

Mahalaga dito hindi lamang upang ipahiwatig kung aling package ang ii-scan, kundi pati na rin ang gusto naming batay sa anotasyon, iyon ay, upang makontrol ang mga anotasyon kung paano gagana ang Spring. Ang natitira na lang ay lumikha ng ru.javarush.javaweb package at ilagay ang Spring controller class dito:

package ru.javarush.javaweb;

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.ResponseBody;

@Controller
public class SpringController {

    @GetMapping("/app")
    @ResponseBody
    public String getGreeting() {
        return "Hello world.";
    }
}

Ngayon ay tumatakbo ang gradle appRun at pumunta sa address, http://127.0.0.1:8080/javaweb/appmakukuha natin ang parehong Hello World. Gaya ng nakikita mo, ang Spring Framework ay malapit na nauugnay sa Servlet API at ginagamit ito upang gumana sa ibabaw nito.

Mga anotasyon

Gaya ng nakita natin, maginhawa ang mga anotasyon. At hindi lang kami ang nag-isip. Samakatuwid, sa detalye ng Servlet API, simula sa bersyon 3.0, lumitaw ang kabanata na " CHAPTER 8 Annotation and pluggability ", na tumutukoy na dapat suportahan ng mga servlet container ang kakayahang tukuyin kung ano ang dating tinukoy sa Deployment Descriptor sa pamamagitan ng mga anotasyon. Kaya, ang web.xml ay maaaring ganap na maalis mula sa proyekto, at sa itaas ng servlet class maaari mong tukuyin ang @WebServlet annotation at ipahiwatig kung saang path imamapa ang servlet. Mukhang malinaw ang lahat dito. Ngunit paano kung ikinonekta namin ang Spring sa proyekto, na nangangailangan ng mas kumplikadong mga setting? Narito ang lahat ay medyo mas kumplikado. Una, sinasabi ng dokumentasyon ng Spring na para i-configure ang Spring nang walang web.xml, kailangan mong gumamit ng sarili mong klase na magpapatupad ng WebApplicationInitializer. Para sa higit pang mga detalye, tingnan ang kabanata " 1.1. DispatcherServlet ". Spring class pala ito. Paano kung gayon ginagamit ang Servlet API dito? Sa katunayan, ang ServletContainerInitializer ay idinagdag sa Servlet API 3.0 . Gamit ang isang espesyal na mekanismo sa Java (tinatawag na SPI ), tinukoy ng Spring ang servlet container initializer nito na tinatawag na SpringServletContainerInitializer. Sa turn, naghahanap na ito ng mga pagpapatupad ng WebApplicationInitializer at tinatawag ang mga kinakailangang pamamaraan at ginagawa ang mga kinakailangang setting. Tingnan ang " Paano nahahanap ng servlet container ang mga pagpapatupad ng WebApplicationInitializer " para sa higit pang mga detalye. Ang mga setting sa itaas ay maaaring gawin tulad nito:

package ru.javarush.javaweb.config;

import org.springframework.web.WebApplicationInitializer;
import org.springframework.web.context.ContextLoaderListener;
import org.springframework.web.context.support.AnnotationConfigWebApplicationContext;
import org.springframework.web.servlet.DispatcherServlet;

import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.ServletRegistration;

public class AppInitializer implements WebApplicationInitializer {
    @Override
    public void onStartup(ServletContext servletContext) throws ServletException {
        AnnotationConfigWebApplicationContext ctx = new AnnotationConfigWebApplicationContext();
        // регистрируем конфигурацию созданую высше
        ctx.register(AppConfig.class);
        // добавляем в контекст слушателя с нашей конфигурацией
        servletContext.addListener(new ContextLoaderListener(ctx));

        ctx.setServletContext(servletContext);

        // настраиваем маппинг Dispatcher Servlet-а
        ServletRegistration.Dynamic servlet =
                servletContext.addServlet("dispatcher", new DispatcherServlet(ctx));
        servlet.addMapping("/");
        servlet.setLoadOnStartup(1);
    }
}

Ngayon, gamit ang " Java-based na configuration " ay ipahiwatig namin kung aling pakete ang ii-scan + paganahin ang mga anotasyon:

package ru.javarush.javaweb.config;

import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.EnableWebMvc;

@Configuration
@EnableWebMvc
@ComponentScan(basePackages = "ru.javarush.javaweb.controllers")
public class AppConfig {
}

At ang SpringController mismo ay inilipat sa ru.javarush.javaweb.controllers, upang kapag nag-scan, ang configuration ay hindi mahanap ang sarili nito, ngunit maghahanap lamang ng mga controllers.

Pagbubuod

Umaasa ako na ang pangkalahatang-ideya na ito ay nagbigay ng kaunting liwanag sa kung paano gumagana ang mga web application sa Java. Ito ay dulo lamang ng malaking bato ng yelo, ngunit nang walang pag-unawa sa mga pangunahing kaalaman, mahirap maunawaan kung paano gumagana ang mga teknolohiya batay sa pundasyong ito. Ang Servlet API ay ang gitnang bahagi ng anumang Java web application, at tiningnan namin kung paano umaangkop dito ang ibang mga frameworks. Upang magpatuloy, maaari mong tingnan ang mga sumusunod na materyales:

#Viacheslav

Mga komento

TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION