Hello World dan Spring Web MVC ga va servletlarning bunga qanday aloqasi bor

Kirish

Ma'lumki, Java-ning muvaffaqiyati aynan tarmoqqa ulanishga intilayotgan dasturiy ta'minotning evolyutsiyasi tufayli keldi. Shuning uchun biz odatiy konsol ilovasi " Salom dunyo " ni asos qilib olamiz va konsol ilovasidan tarmoq ilovasi bo'lish uchun nima kerakligini tushunamiz. Shunday qilib, avval siz Java loyihasini yaratishingiz kerak. Dasturchilar dangasa odamlardir. Tarixdan oldingi davrlarda, ba'zilari mamontlarni ovlayotganda, boshqalari Java kutubxonalari va katalog tuzilmalarining xilma-xilligida o'tirib, adashmaslikka harakat qilishdi. Ishlab chiquvchi dastur yaratish jarayonini boshqarishi va shunchaki "Men 2-versiyadagi kutubxonani xohlayman" deb yozishi uchun ular maxsus vositalarni - tizimlarni qurishni taklif qilishdi. Ikkita eng mashhurlari - Maven va Gradle . Ushbu maqola uchun biz Gradle-dan foydalanamiz. Agar ilgari biz katalog tuzilmasini o'zimiz yaratishimiz kerak bo'lgan bo'lsa, endi Gradle Gradle Init plaginidan foydalanib, bitta buyruqda katalog tuzilmasi va asosiy asosiy sinfga ega Java loyihasini yaratishga imkon beradi: gradle init --type java-application Bu buyruq ishga tushirishni (init) amalga oshiradi. bizga Hello World konsoli bilan Java ilovasi (java-ilovasi). Tugatgandan so'ng, katalogda fayl paydo bo'ladi - build.gradle . Bu bizning qurish skriptimiz - ya'ni buning uchun qanday harakatlar bajarilishi kerakligi tavsiflangan dastur yaratish uchun ma'lum bir skript. Keling, uni ochamiz va unga qator qo'shamiz: jar.baseName = 'webproject' Gradle sizga loyihada turli xil amallarni bajarishga imkon beradi va bu harakatlar deyiladi vazifalar . Buyruqni (topshiriqni) bajarish orqali JAR fayli /build/libsgradle build katalogida yaratiladi . Va siz taxmin qilganingizdek, endi uning nomi webproject.jar bo'ladi . Ammo biz ni bajarsak , xatoga duch kelamiz: . Buning sababi, java ilovasi uchun ma'lum bir manifestni biriktirishingiz kerak - bu dastur bilan qanday ishlash, uni qanday qabul qilishning tavsifi. Shunda java ilovasini bajaradigan JVM qaysi sinf dasturga kirish nuqtasi ekanligini va boshqa ma'lumotlarni bilib oladi (masalan, classpath). Qurilish skriptining mazmunini batafsil ko'rib chiqsak, plaginlarning ulanganligini ko'ramiz. Masalan: Agar biz Gradle Java Plugin sahifasiga o'tsak , biz manifestni sozlashimiz mumkinligini ko'ramiz: java -jar ./build/libs/webproject.jarno main manifest attributeapply plugin: 'java'

jar {
    manifest {
        attributes 'Main-Class': 'App'
    }
}

Asosiy sinf, dasturga kirish nuqtasi biz uchun Gradle Init Plugin tomonidan yaratilgan. Va u hatto mainClassName parametrida ham ko'rsatilgan. Ammo bu bizga mos kelmadi, chunki ... bu sozlama boshqa plaginga, Gradle Application Pluginga tegishli . Shunday qilib, bizda ekranda Hello World-ni ko'rsatadigan Java ilovasi mavjud. Ushbu Java ilovasi JAR (Java ARchive) da paketlangan. Bu oddiy, konsolga asoslangan, zamonaviy emas. Qanday qilib uni veb-ilovaga aylantirish mumkin?

Servlet API

Java-ning tarmoq bilan ishlashi uchun, qadimgi davrlarda Servlet API deb nomlangan spetsifikatsiya paydo bo'lgan . Aynan mana shu spetsifikatsiya mijoz-server o'zaro ta'sirini, mijozdan xabar olish (masalan, brauzer) va javob yuborishni (masalan, sahifa matni bilan) tavsiflaydi. Tabiiyki, o'shandan beri ko'p narsa o'zgardi, ammo gap shundaki, Java ilovasi veb-ilovaga aylanishi uchun Servlet API-dan foydalaniladi. Asossiz taxmin qilmaslik uchun, keling, ushbu spetsifikatsiyani ko'rib chiqaylik: JSR-000340 JavaTM Servlet 3.1 . Avvalo, bizni " 1-bob: Umumiy ko'rinish " qiziqtiradi. Bu biz tushunishimiz kerak bo'lgan asosiy tushunchalarni tavsiflaydi. Birinchidan, servlet nima? " 1.1 Servlet nima? " bo'limida aytilishicha, Servlet - bu konteyner tomonidan boshqariladigan va dinamik tarkibni yaratuvchi Java komponenti. Boshqa Java komponentlari singari, servlet ham bayt-kodga kompilyatsiya qilingan va Java texnologiyasidan foydalangan holda veb-serverga yuklanishi mumkin bo'lgan Java sinfidir. Servlet konteyneri tomonidan amalga oshiriladigan so'rov/javob paradigmasi doirasida servletlar veb-mijoz (masalan, brauzer) bilan o'zaro aloqada bo'lishi muhimdir. Ma'lum bo'lishicha, Servletlar qandaydir Servlet konteynerida yashaydi. Nima bu? " 1.2 Servlet konteyneri nima? " bo'limida aytilishicha, Servlet konteyneri so'rovlar yuboriladigan va javoblar yuboriladigan tarmoq xizmatlarini taqdim etadigan veb-server yoki dastur serverining bir qismidir. Ushbu Servlet konteyneri servletlarning hayot aylanishini boshqaradi. Barcha Servlet konteynerlari HTTP protokolini kamida qo'llab-quvvatlashi kerak, ammo boshqalarni qo'llab-quvvatlashi mumkin. Masalan, HTTPS. Servlet konteyneri servletlar bajariladigan muhitga xavfsizlik bilan bog'liq har qanday cheklovlarni o'rnatishi ham muhimdir. Shuningdek, “ 10.6 Veb-ilovalar arxivi fayli ” ga muvofiq veb-ilova WAR (Web ARchive) faylida to'plangan bo'lishi ham muhimdir . Ya'ni, endi biz boshqa narsa uchun jar va dastur plaginlarini olib tashlashimiz kerak. Va bu Gradle WAR plaginidir . Va o'rniga jar.baseName war.baseName belgilang Chunki Biz endi jar plaginidan foydalanmayotganimiz uchun manifest sozlamalarini ham olib tashladik. JAR-ni ishga tushirganimizda, Java Virtual Machine (JVM) bizning ilovamiz bilan qanday ishlashni manifest orqali aytib berishimiz kerak edi. Chunki JVM uni boshqarayotgan edi. Veb-ilova, aftidan, qandaydir veb-server tomonidan bajariladi. Ma'lum bo'lishicha, u qandaydir tarzda unga bizning veb-ilovamiz bilan qanday ishlashni aytishi kerak? Va shunday bo'lib chiqdi. Veb-ilovalar o'zlarining maxsus manifestiga ega. U Deployment Descriptor deb ataladi . Unga butun bo'lim bag'ishlangan: “ 14. Deployment Descriptor ”. Muhim bo'lim bor: " 10-bob:". U Servlet API nuqtai nazaridan veb-ilova nima ekanligi haqida gapiradi. Masalan, " 10.5 Katalog tuzilmasi " bobida joylashtirish deskriptori qayerda bo'lishi kerakligi ko'rsatilgan: /WEB-INF/web.xml. WEB-INFni qayerga joylashtirish kerak? Gradle WAR plaginida aytilganidek, u yangi maketni qo'shadi : src/main/webapp.Shuning uchun shunday katalog yaratamiz, ichida biz WEB-INF katalogini yaratamiz va ichida biz web.xml faylini yaratamiz.Katalog bo'lishi muhim. META-INF emas, WEB-INF deb ataladi! Keling, uni " 14.5.1 Asosiy misol " XML misolidan ko'chirib olaylik: Ko'rib turganimizdek, konfiguratsiya uchun XML hujjatidan foydalaniladi. XML hujjati haqiqiy (Valid) deb hisoblanishi uchun ba'zi "sxema" ga mos kelishi kerak. Buni XML hujjati uchun o'ziga xos interfeys deb hisoblashingiz mumkin. Sxema XML hujjatida qanday elementlar bo'lishi mumkinligini, qaysi turdagi ma'lumotlar elementni, tartibni, talabni va boshqa jihatlarni belgilashi mumkinligini belgilaydi. Hujjatlardan ko'chirilgan misol 2.5 versiyasini ko'rsatadi, ammo biz 3.1 versiyasidan foydalanmoqchimiz. Tabiiyki, versiyalar o'zgarganda spetsifikatsiya o'zgardi va yangi xususiyatlar qo'shildi. Shuning uchun, siz 2.5 versiyasi (web-app_2_5.xsd) uchun ishlatilgan sxemadan boshqa sxemadan foydalanishingiz kerak. 3.1 versiyasi uchun qanday sxemadan foydalanishim kerak? Hujjatlar bizga bu borada yordam beradi, " 14.3 Deployment Deskriptor " bo'limida, ya'ni specification is available at http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd biz sxemaga havolani hamma joyda belgilangan xsd bilan almashtirishimiz kerak, uni version="2.5"3.1 ga o'zgartirishni unutmang, shuningdek, hamma joyda nom maydonini o'zgartirishimiz kerak ( xmlns va xsi:schemaLocation da). Ular qaysi nomlar maydonida ishlashimizni ko'rsatadi (juda sodda qilib aytganda, qanday element nomlaridan foydalanishimiz mumkin). Agar siz sxema faylini ochsangiz, targetNamespace biz belgilashimiz kerak bo'lgan bir xil nom maydonini o'z ichiga oladi: Esda tutganimizdek, Manifest of Jar faylida biz qaysi sinfdan foydalanmoqchi ekanligimizni yozgan edik. Bu yerda nima qilish kerak? Bu erda biz veb-mijozdan so'rov olganimizda qaysi servlet sinfidan foydalanmoqchi ekanligimizni belgilashimiz kerak. Ta'rifni " 14.4 Joylashtirish deskriptori diagrammasi " bo'limida o'qishingiz mumkin . Bu shunday ko'rinadi: Bu erda hamma narsa oddiy. Serverlet e'lon qilinadi va keyin u ma'lum bir shablonga moslashtiriladi. Bunday holda, /app. Shablon bajarilganda, servlet usuli bajariladi. Go'zallik uchun Ilova sinfi xml konfiguratsiyasini to'g'rilashni unutmasdan, paketga o'tkazilishi kerak. Lekin bu hammasi emas. Ilova servlet bo'lishi kerak. Servlet bo'lish nimani anglatadi? Bu HttpServlet dan meros olishimiz kerakligini anglatadi . Misolni " 8.1.1 @WebServlet " bo'limida ko'rish mumkin . Unga ko'ra, bizning App sinfimiz quyidagicha ko'rinadi:

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

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

	public void doGet(HttpServletRequest request, HttpServletResponse response) {
		response.setContentType("text/html");
		try {
			response.getWriter().println(getGreeting());
		} catch (IOException e) {
			throw new IllegalStateException(e);
		}
	}
}

Lekin loyihamiz hali tayyor emas. Chunki biz hozir Servlet API 3.1 versiyasiga bog'liqmiz. Bu bizning qurish skriptimizda biz Servlet API-ga bog'liqlikni ko'rsatishimiz kerakligini anglatadi. JVM kodda yozgan narsangiz to'g'ri ekanligini va undan qanday foydalanishni bilishi kerak. Esda tutganimizdek, spetsifikatsiya aslida barchasi qanday ishlashini tavsiflovchi interfeyslardir. Va ilovalar veb-server tomonida joylashgan. Shuning uchun, Servlet APIsiz Maven Central da kerakli kutubxonani toping: javax.servlet-api . Va bog'liqliklar blokiga kirish qo'shing . Maven omborida, siz ko'rganingizdek, u taqdim etilgan deb aytilgan. Tobelikni ishlatishdan oldin siz qamrovni belgilashingiz kerak. Gradle-da "ta'minlangan" deb nomlangan qamrov yo'q, lekin u " faqat kompilyatsiya qilish " doirasiga ega. Shuning uchun biz aytamiz: providedCompile 'javax.servlet:javax.servlet-api:3.1.0' Uh, hammasi joyida? Gradle Build bizning loyihamizni WAR fayliga aylantiradi. Va bundan keyin nima qilishimiz kerak? Birinchidan, bizga veb-server kerak. Google'da biz " veb server java ro'yxati " deb yozamiz va veb-serverlar ro'yxatini ko'ramiz. Keling, ushbu ro'yxatdan tanlaylik, masalan, TomCat . Apache Tomcat veb-saytiga o'ting , so'nggi versiyani (hozirgi versiya 9) zip arxivi sifatida yuklab oling (agar Windows uchun). Uni biron bir katalogga oching. Huray, bizda veb-server bor. Bin pastki katalogidagi veb-server katalogidan biz buyruq satridan catalina-ni ishga tushiramiz va mavjud variantlarni ko'ramiz. Keling, qilaylik: catalina start. Har bir veb-serverda veb-server nazorat qiladigan katalog mavjud. Agar u yerda veb-ilova fayli paydo bo'lsa, veb-server uni o'rnatishni boshlaydi. Ushbu o'rnatish tarqatish yoki tarqatish deb ataladi . Ha, ha, shuning uchun " joylashtirish deskriptori ". Ya'ni, dasturni qanday qilib to'g'ri joylashtirish kerak. Tomcat-da bu katalog webapps hisoblanadi . Keling, u erda gradle build yordamida qilgan urushimizni ko'chirib olaylik. Shundan so'ng, jurnalda biz shunga o'xshash narsani ko'ramiz: Yaxshiroq tushunish uchun tomcat katalogida quyidagi qatorlarni qo'shib Deployment of web application archive [tomcat\webapps\webproject.war] has finished in [время] ms faylni tahrirlaymiz :\conf\tomcat-users.xml Endi biz serverni qayta ishga tushiramiz (catalina stop, catalina start) va manzilga o'tamiz.Bu http://127.0.0.1:8080/manager erda biz barcha ilovalarning yo'llarini ko'ramiz. Bizning veb-loyihamizga katta ehtimollik bilan yo'l/webloyiha berilgan. Bu qanday yo'l? " 10.1 Veb-serverlar ichidagi veb-ilovalar " bo'limidagi spetsifikatsiyada veb-ilova ilova ichidagi ba'zi yo'llar bilan bog'langanligini bildiradi (bu holda, /webproject). Ushbu yo'l orqali barcha so'rovlar bir xil ServletContext bilan bog'lanadi. Ushbu yo'l contextRoot deb ham ataladi . Va " 10.2 ServletContext bilan aloqasi " ga ko'ra, servlet konteyneri veb-ilova va ServletContext-ni birma-bir bog'laydi. Ya'ni, har bir veb-ilova o'z ServletContext-ga ega. ServletContext nima ? Spetsifikatsiyada aytilganidek, ServletContext bu servletlarga ular ishlayotgan " ilova ko'rinishi" bilan ta'minlovchi ob'ektdir . Servlet konteksti Servlet API spetsifikatsiyasining 4-bobida batafsil tavsiflangan. Ajablanarlisi shundaki, 3.1 versiyadagi Servlet API endi web.xml bo'lishini talab qilmaydi. Masalan, siz izohlar yordamida servletni belgilashingiz mumkin:

import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

@WebServlet("/app2")
public class App2 extends HttpServlet {

    public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
        response.setContentType("text/html");
        response.getWriter().println("app2");
    }
}

Shuningdek, mavzu bo'yicha tavsiya etiladi: " Java EE intervyu - JEE Servlet API (Savollar va javoblar) ". Shunday qilib, bizda Servlet bor - u veb-mijozga qanday javob berish uchun javobgardir. Bizda foydalanuvchidan so‘rovlarni qabul qiluvchi, servlet yo‘li bilan kirilgan yo‘lga mos keladigan va moslik topilsa, Servletni bajaradigan ServletContainer mavjud. Yaxshi. Bu dunyo rasmida bahor qaysi o'rinni egallaydi ?

Spring Web MVC

Ajoyib, bizda veb-ilova mavjud. Endi biz bahorni ulashimiz kerak. Buni qanday qilishimiz mumkin? Birinchidan, siz bahorni loyihangizga qanday qilib to'g'ri ulashni aniqlab olishingiz kerak. Ma'lum bo'lishicha, ilgari buni Bahor platformasi loyihasi hujjatlariga muvofiq amalga oshirish mumkin edi , ammo endi " Platforma qo'llab-quvvatlanadigan muddati 2019 yil 9 aprelda tugaydi ", ya'ni buni qilish tavsiya etilmaydi. foydalaning, chunki u tez orada qo'llab-quvvatlanmaydi. Yagona yo'l - " Platforma foydalanuvchilariga Spring Boot-ning qaramlik boshqaruvidan foydalanishni boshlash tavsiya etiladi ". Shuning uchun, keling, Spring Boot hujjatlariga o'tamiz . Aniqlik kiritamanki, biz Spring Boot-dan foydalanmaymiz, faqat Spring Boot-dan Dependency Management-dan foydalanamiz. Ya'ni, Spring Boot loyihasi kutubxonalarning qaysi versiyalaridan foydalanish (shu jumladan Spring MVC) haqida ma'lumot berishi mumkin. U erda biz 3.2 ni topamiz . Spring Boot-ning qaramlik boshqaruvidan alohida foydalanish . Hujjatlarga ko'ra, qurilish skriptiga quyidagilarni qo'shing:

plugins {
    id 'org.springframework.boot' version '2.0.4.RELEASE' apply false
}
apply plugin: 'io.spring.dependency-management'

Va

dependencyManagement {
    imports {
        mavenBom org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES
    }
}

Ko'rib turganingizdek, biz ko'rsatdik apply false, ya'ni. Biz Spring Boot-ning o'zidan foydalanmaymiz, lekin u erdan qaramlikni boshqarishdan foydalanamiz. Ushbu qaramlik boshqaruvi BOM - " Materiallar ro'yxati " deb ham ataladi . Endi biz Spring Web MVC loyihasini ulashga tayyormiz. Spring Web MVC Spring Framework loyihasining bir qismidir va biz " Web Servlet " bo'limiga qiziqamiz . Qurilish skriptiga qaramlikni qo'shamiz: compile 'org.springframework:spring-webmvc'. Ko'rib turganimizdek, biz kompilyatsiya hajmini o'rnatdik, chunki veb-server bizga bahorni taqdim etmaydi. Bizning loyihamiz Bahor kutubxonasini o'z ichiga kiritishga majbur. Keyinchalik, " 1.2. DispatcherServlet " bo'limini o'qish biz uchun juda muhim , bu erda Spring MVC " Front kontroller " sxemasi atrofida qurilgan , bu erda konfiguratsiya va boshqa komponentlarga vakolat berishni ta'minlaydigan markaziy servlet mavjud. . Dispetcherni dispetcher deb tarjima qilish mumkin. Shunday qilib, birinchi navbatda, web.xml da biz e'lon qilamiz: Ko'rib turganimizdek, bu aslida Servlet API spetsifikatsiyasida belgilangan oddiy tinglovchi. Aniqroq aytganda, bu ServletContextListener, ya'ni bizning veb-ilovamiz uchun Servlet kontekstini ishga tushirish uchun ishga tushirilgan. Keyinchalik, Spring-ga sozlamalari bilan maxsus xml konfiguratsiyasi qaerda joylashganligini ko'rsatadigan sozlamani belgilashingiz kerak: Ko'rib turganingizdek, bu oddiy sozlama bo'lib, u Servlet kontekst darajasida saqlanadi, lekin Spring tomonidan Ilova kontekstini ishga tushirishda foydalaniladi. Endi siz barcha servletlar o'rniga barcha boshqa so'rovlarni tarqatuvchi bitta dispetcherni e'lon qilishingiz kerak. Va bu erda hech qanday sehr yo'q. Agar qaraydigan bo'lsak, bu HttpServlet bo'lib, u erda Spring uni ramkaga aylantiradigan juda ko'p narsalarni qiladi. Faqat ma'lum bir URL shablonini servlet bilan bog'lash (xaritalash) qoladi: Hammasi avvalgidek bo'ladi. Endi veb-serverimiz ko'rsatishi kerak bo'lgan narsani yarataylik. Masalan, WEB-INF-da sahifalar kichik katalogini yarataylik, u erda hello.jsp fayli bo'ladi. Tarkib eng ibtidoiy bo'lishi mumkin. Masalan, html teglari ichida " Salom dunyo " matni bilan h1 tegi mavjud . applicationContext.xmlVa biz ilgari ko'rsatgan faylni yaratishni unutmang . Bahor hujjatlaridan misol keltiraylik: " 1.10.3. Sinflarni avtomatik aniqlash va loviya ta'riflarini ro'yxatdan o'tkazish ". Chunki biz shu tarzda avtomatik aniqlashni faollashtiramiz, endi biz 2 ta sinfni yaratishimiz mumkin (ular maxsus Bahor izohlari qo'llanilganligi sababli ular Bahor fasollari deb hisoblanadi), ularni Spring endi o'zi yaratadi va ularning yordami bilan ilovamizni moslashtiradi:

1. Veb-konfiguratsiya, masalan, Java uslubi konfiguratsiyasi:

   @Configuration
   @EnableWebMvc
   public class WebConfig implements WebMvcConfigurer {
       @Override
       public void configureViewResolvers(ViewResolverRegistry registry) {
           registry.jsp("/WEB-INF/pages/", ".jsp");
       }
       @Override
       public void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) {
           configurer.enable();
       }
   }

   Ushbu misol Spring Framework hujjatlarida tasvirlangan: " 1.11. MVC Config ".

   Bu erda biz jsp sahifalari qaerda joylashganligini aniqlashga yordam beradigan ViewResolver-ni ro'yxatdan o'tkazamiz. Ikkinchi usul " Standart servlet " yoqilganligini ta'minlaydi.

   Bu haqda ko'proq ma'lumotni bu erda o'qishingiz mumkin: " Default-servlet-handler nima kerak va undan foydalanish kerak ".

2. Muayyan JSP ga so'rovlar xaritasini tavsiflash uchun HelloController kontrolleri

   @Controller
   public class HelloController {
       @GetMapping("/hello")
       public String handle(Model model) {
           return "hello";
       }
   }

   Bu erda biz " 1.4. Izohlangan kontrollerlar " bo'limidagi hujjatlarda tasvirlangan @Controller izohidan foydalandik .

Endi, ilovamiz o'rnatilganda, so'rov yuborganimizda /webproject/hello(bu erda /webproject kontekst ildizi), DispatcherServlet birinchi bo'lib qayta ishlanadi. U asosiy dispetcher sifatida biz /* joriy so'rovga mos kelishini aniqlaydi, ya'ni DispatcherServlet biror narsa qilishi kerak. Keyin u topgan barcha xaritalardan o'tadi. U /hello ga moslashtirilgan tutqich usuliga ega HelloController mavjudligini ko'radi va uni bajaradi. Bu usul "salom" matnini qaytaradi. Ushbu matn ViewResolver tomonidan qabul qilinadi, u serverga mijozga ko'rsatilishi kerak bo'lgan jsp fayllarini qaerdan izlash kerakligini aytadi. Shunday qilib, mijoz oxir-oqibat o'sha juda qadrli sahifani oladi.

Xulosa

Umid qilamanki, maqoladan "kontekst" so'zi qo'rqinchli emasligi aniq bo'ladi. Bu spetsifikatsiyalar juda foydali bo'lib chiqdi. Hujjatlar bizning dushmanimiz emas, do'stimizdir. Umid qilamanki, Spring nimaga asoslanganligi, u qanday bog'lanishi va Servlet API-ning bunga qanday aloqasi borligi aniq bo'ladi.