JavaRush /وبلاگ جاوا /Random-FA /برنامه وب در جاوا

مرحله

28 February 2021
48 views
0 comments

برنامه وب در جاوا

معرفی

روزی روزگاری جاوا به دلیل انتخاب برنامه های وب به عنوان اولویت، جایگاه خود را تقویت کرد. جاوا از همان روزهای اولیه خود در تلاش برای یافتن راه خود بوده است. ابتدا اپلت ها را پیشنهاد دادم. این فرصت های زیادی را برای توسعه دهندگان فراهم کرده است تا محتوای پویا در صفحات HTML ایستا ایجاد کنند. با این حال، اپلت ها به دلایل زیادی انتظارات را برآورده نکردند: امنیت، سربار و موارد دیگر. سپس توسعه دهندگان زبان جاوا یک جایگزین را پیشنهاد کردند - Servlet API . و معلوم شد که تصمیم درستی بوده است. Servlet API مشخصاتی است که هر برنامه وب جاوا بر اساس آن ساخته شده است، خواه یک برنامه مبتنی بر وب باشد یا یک وب سرویس که اطلاعات را مطابق درخواست برمی گرداند. بنابراین، مسیر درک نحوه عملکرد برنامه های وب جاوا با درک Servlet API آغاز می شود.

Servlet API

بنابراین، Servlet API همان چیزی است که توسعه دهندگان زبان به توسعه دهندگان جاوا ارائه کردند. Servlet API مشخصاتی است که باید به سوالات اصلی ما پاسخ دهد. شما می توانید آن را در اینجا پیدا کنید: " JSR-000340 JavaTM Servlet 3.1 Final Release for Evaluation ". فصل " 1.1 Servlet چیست؟ " می گوید که یک servlet یک مؤلفه وب مبتنی بر فناوری جاوا است که محتوای پویا (یعنی محتوا) ایجاد می کند. "مبتنی بر جاوا" به این معنی است که یک servlet یک کلاس جاوا است که در بایت کد کامپایل شده است . Servlet ها توسط یک کانتینر servlet مدیریت می شوند که گاهی اوقات Servlet Engine نامیده می شود. کانتینر servlet یک برنامه افزودنی وب سرور است که عملکرد سرولت را ارائه می دهد. به نوبه خود، servlet ها تعامل با مشتری را در پارادایم درخواست/پاسخ فراهم می کنند که توسط ظرف سرولت پیاده سازی می شود. در فصل " 1.2 کانتینر Servlet چیست؟ " گفته می شود که یک کانتینر سرولت بخشی از یک وب سرور یا سرور برنامه است که خدمات شبکه ای را ارائه می دهد که از طریق آن درخواست ها و پاسخ ها ارسال می شود، درخواست ها و پاسخ های مبتنی بر MIME تولید و پردازش می شوند. . علاوه بر این، کانتینرهای سرولت، چرخه زندگی سرولت‌ها را مدیریت می‌کنند (یعنی تصمیم می‌گیرید چه زمانی آنها را ایجاد کنید، آنها را حذف کنید و غیره). همه کانتینرهای سرور باید از پروتکل HTTP برای دریافت درخواست ها و ارسال پاسخ ها پشتیبانی کنند. در اینجا می خواهم اضافه کنم که MIME یک استاندارد است، مشخصاتی که می گوید چگونه اطلاعات باید کدگذاری شوند و پیام ها به گونه ای قالب بندی شوند که بتوانند از طریق اینترنت ارسال شوند.

وب سرور

وب سرور سروری است که درخواست‌های HTTP مشتریان را می‌پذیرد و پاسخ‌های HTTP (معمولاً همراه با صفحه HTML، تصویر، فایل یا سایر داده‌ها) را در اختیار آنها قرار می‌دهد. منابع درخواستی توسط URL ها شناسایی می شوند. یکی از محبوب ترین وب سرورهای با پشتیبانی Servlet API Apache Tomcat است . اکثر وب سرورها ماشین های پیچیده ای هستند که از اجزای مختلفی تشکیل شده اند که هر کدام وظایف خاصی را انجام می دهند. مثلا:

اتصال دهنده ها

- در ورودی ما رابط‌هایی داریم (یعنی کانکتورها) که درخواست‌های دریافتی از مشتریان را می‌پذیرند. رابط HTTP در تامکت با استفاده از مولفه "Coyote" پیاده سازی می شود. اتصال دهنده ها داده ها را از مشتری دریافت می کنند و به موتور Tomcat منتقل می کنند. Servlet Container - موتور Tomcat به نوبه خود درخواست دریافتی از مشتری را با استفاده از کامپوننت "Catalina" که یک ظرف سرولت است پردازش می کند. برای جزئیات بیشتر به مستندات تامکت مراجعه کنید: " نمای کلی معماری ". وب سرورهای دیگری نیز وجود دارند که از مشخصات Servlet API پشتیبانی می کنند. به عنوان مثال، " Jetty " یا " Undertow ". معماری آنها مشابه است، بنابراین با درک اصل کار با یک ظرف سرولت، می توانید به کار با دیگری تغییر دهید.

برنامه تحت وب

بنابراین، برای اینکه بتوانیم یک برنامه وب را اجرا کنیم، به وب سروری نیاز داریم که از Servlet API پشتیبانی کند (یعنی سروری که دارای یک جزء افزونه باشد که پشتیبانی Servlet API را برای وب سرور اجرا کند). خوب. به هر حال وب اپلیکیشن چیست؟ با توجه به فصل " 10 برنامه های کاربردی وب " از مشخصات Servlet API، یک برنامه وب مجموعه ای از servlet ها، صفحات HTML، کلاس ها و سایر منابع است که یک برنامه نهایی را در یک وب سرور تشکیل می دهند. طبق فصل " فایل بایگانی برنامه وب 10.6 "، یک برنامه وب را می توان در Web ARchive (آرشیو با پسوند WAR) بسته بندی کرد. همانطور که در صفحه " واژه نامه 219 " آمده است:

یعنی WAR به جای JAR ساخته شده تا نشان دهد که این یک برنامه وب است. واقعیت مهم بعدی: ما باید یک ساختار دایرکتوری خاصی در آرشیو WAR خود داشته باشیم. در مشخصات Servlet API در فصل " ساختار فهرست راهنمای 10.5 ". این فصل می گوید که یک دایرکتوری خاص به نام "WEB-INF" وجود دارد. این دایرکتوری از این جهت خاص است که برای کلاینت قابل مشاهده نیست و مستقیماً به آن نشان داده نمی شود، اما برای کد servlet قابل دسترسی است. همچنین می گوید دایرکتوری WEB-INF چه چیزی می تواند داشته باشد:

از کل این لیست، اکنون موردی را در مورد برخی از فایل‌های web.xml به نام Deployment Descriptor نمی‌دانیم و نمی‌فهمیم . چیست؟ فصل " 14. توصیفگر استقرار " به توصیفگر استقرار اختصاص دارد. به طور خلاصه، Deployment Descriptor یک فایل xml است که نحوه استقرار (یعنی اجرای) برنامه وب ما را در یک وب سرور توضیح می دهد. به عنوان مثال، توصیفگر استقرار نشان می دهد که از کدام URL ها باید برای دسترسی به برنامه ما استفاده شود، تنظیمات امنیتی مربوط به برنامه ما و غیره نشان داده شده است. فصل " 14.2 قوانین برای پردازش استقرار " می گوید که قبل از اینکه برنامه ما پیکربندی و راه اندازی شود، web.xml مطابق طرح اعتبارسنجی می شود (یعنی بررسی می شود که محتوای web.xml به درستی نوشته شده باشد. به طرحواره). و در فصل " 14.3 Deployment Descriptor " نشان داده شده است که نمودار اینجاست: http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd اگر به محتویات فایل نگاه کنیم، می بینیم:

طرحواره برای فایل های XML چیست؟ طرحواره ها نحوه پر کردن صحیح یک سند XML را نشان می دهند: از چه عناصری می توان استفاده کرد، چه نوع داده هایی را می توان در عناصر مشخص کرد، عناصر باید به چه ترتیبی بروند، چه عناصری مورد نیاز هستند و غیره. شما می توانید طرح یک سند XML را با یک رابط در جاوا مقایسه کنید، زیرا طرحواره در جاوا همچنین مشخص می کند که چگونه کلاس هایی که یک اینترفیس معین را برآورده می کنند (یعنی یک رابط مشخص را پیاده سازی می کنند) باید نوشته شوند. بنابراین، ما به دانش مخفی مسلح شده ایم و آماده ایجاد اولین برنامه وب خود هستیم!

ایجاد یک وب اپلیکیشن

تصور کار با یک برنامه مدرن جاوا بدون استفاده از سیستم های ساخت پروژه خودکار دشوار است. برخی از محبوب ترین سیستم ها Maven و Gradle هستند . ما برای این بررسی از Gradle استفاده خواهیم کرد. نصب Gradle در وب سایت رسمی توضیح داده شده است . برای ایجاد یک برنامه جدید، به یک پلاگین داخلی در Gradle نیاز داریم: " Build Init Plugin ". برای ایجاد یک برنامه جاوا باید دستور زیر را اجرا کنید: gradle init --type java-application

پس از ایجاد پروژه، باید فایل build.gradle را ویرایش کنیم . این به اصطلاح Build Script است (برای جزئیات بیشتر به مستندات Gradle مراجعه کنید: " Writing Build Scripts "). این فایل نحوه مونتاژ پروژه و سایر جنبه های کار با پروژه جاوا را شرح می دهد. بلوک پلاگین ها توضیح می دهد که کدام " افزونه های Gradle " باید برای پروژه Gradle فعلی استفاده شوند. پلاگین ها قابلیت های پروژه ما را گسترش می دهند. به عنوان مثال، پلاگین پیش فرض " java " است. اگر به پشتیبانی جاوا نیاز داشته باشیم همیشه از این افزونه استفاده می شود. اما ما به پلاگین " برنامه " نیاز نداریم ، زیرا ... توضیحات آن بیان می کند که برای ایجاد یک "برنامه اجرایی JVM" استفاده می شود، یعنی. اجرای برنامه های JVM ما باید یک برنامه وب در قالب یک آرشیو WAR ایجاد کنیم. و اگر در مستندات Gradle به دنبال کلمه WAR بگردیم، " Plugin War " را پیدا خواهیم کرد. بنابراین پلاگین های زیر را مشخص می کنیم:

plugins {
    id 'java'
    id 'war'
}

همچنین در « تنظیمات پیش‌فرض افزونه جنگ » گفته می‌شود که دایرکتوری با تمام محتویات برنامه تحت وب باید «src/main/webapp» باشد، باید همان فهرست WEB-INF وجود داشته باشد که web.xml باید در آن باشد. واقع شده. بیایید چنین فایلی بسازیم. کمی بعد آن را پر می کنیم زیرا ... ما هنوز اطلاعات کافی برای این موضوع نداریم. در بلوک "وابستگی ها" ما وابستگی های پروژه خود را نشان می دهیم، یعنی آن کتابخانه ها/فریم ورک هایی که بدون آنها برنامه ما نمی تواند کار کند. در این مورد، ما در حال نوشتن یک برنامه وب هستیم، به این معنی که نمی توانیم بدون Servlet API کار کنیم:

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

provideCompile به این معنی است که وابستگی لازم نیست در آرشیو WAR برنامه وب ما گنجانده شود: فقط برای کامپایل کردن مورد نیاز است. و هنگام اجرا، این وابستگی توسط شخص دیگری (یعنی وب سرور) ارائه می شود. خوب، ما اطلاعاتی را در مورد مخزن وابستگی که می خواهیم استفاده کنیم در اسکریپت ساخت باقی می گذاریم - همه وابستگی های مشخص شده از آن دانلود می شوند:

repositories {
    jcenter()
}

بقیه موارد را از فایل اسکریپت ساخت حذف می کنیم. حالا بیایید کلاس src\main\java\App.java را ویرایش کنیم. بیایید یک سرولت از آن بسازیم. مشخصات Servlet API در فصل " فصل 2. رابط Servlet " بیان می کند که رابط Servlet دارای یک پیاده سازی پایه از HttpServlet است که در بیشتر موارد باید کافی باشد و توسعه دهندگان فقط باید از آن به ارث ببرند. و در فصل " 2.1.1 روش های رسیدگی به درخواست خاص HTTP " روش های اصلی که درخواست های دریافتی را پردازش می کنند نشان داده شده است. بنابراین، بیایید کلاس 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();
 	}
}

بنابراین، به نظر می رسد که ما همه چیز را آماده کرده ایم. تنها چیزی که باقی می ماند این است که توصیفگر استقرار را به درستی بنویسید. از نمودار، متن زیر را در 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>

و همچنین مسیر طرحواره ای که در آن نشان داده شده است: http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd حالا بیایید به مثالی نگاه کنیم که چگونه web.xml باید در مشخصات Servlet API باشد. این مثال در فصل " 14.5.1 یک مثال اساسی " آورده شده است. بیایید آنچه در نمودار نشان داده شده است را با مثال نشان داده شده در مشخصات ترکیب کنیم. موارد زیر را دریافت می کنیم:

<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>

همانطور که می بینید، ما از schema و schemaLocation که قبلا مشخص شده بود استفاده کردیم. و شرح خود عناصر از مثال فصل 14.5.1 گرفته شده است. اگر همه چیز را به درستی انجام دادیم، وظیفه جنگ gradle را بدون خطا اجرا خواهیم کرد:

راه اندازی یک برنامه تحت وب

برنامه وب چگونه راه اندازی می شود؟ بیایید ابتدا به گزینه پیچیده تر بپردازیم. قبلاً گفتیم که یک وب سرور Apache Tomcat وجود دارد که از Servlet API پشتیبانی می کند. این بدان معنی است که ما می توانیم آرشیو جنگ جمع آوری شده خود را (آنها همچنین می گویند "استقرار") را در این سرور مستقر کنیم. در صفحه " دانلود Tomcat "، نوع تحویل "Core" را در قالب zip از بخش "توزیعات باینری" دانلود کنید. و آرشیو دانلود شده را در فهرستی باز کنید، به عنوان مثال در C:\apache-tomcat-9.0.14. قبل از راه اندازی سرور، فایل را برای ویرایش باز کرده conf\tomcat-users.xmlو خط زیر را به آن اضافه می کنیم: <user username="tomcat" password="tomcat" roles="tomcat,manager-gui,admin-gui"/> اکنون در خط فرمان، به پوشه bin رفته و اجرا کنید catalina.bat start. به طور پیش فرض، کنسول سرور در دسترس خواهد بود http://localhost:8080/manager. لاگین و رمز عبور همان هایی هستند که در tomcat-users.xml مشخص کردیم. تامکت یک فهرست "webapps" دارد که شامل برنامه های کاربردی وب است. اگر می‌خواهیم خودمان را مستقر کنیم، باید آرشیو جنگ خود را در آنجا کپی کنیم. هنگامی که قبلاً فرمان gradle war را اجرا می کردیم، \build\libs\یک آرشیو جنگ در فهرست ایجاد شد. این چیزی است که باید کپی کنیم. پس از کپی کردن، صفحه را Refresh کنید http://localhost:8080/managerو ببینید:

پس از تکمیل http://localhost:8080/javaweb/app، ما به servlet خود روی می آوریم، زیرا ما قبلاً درخواست /app را به App servlet "نگاشت" کردیم (یعنی نقشه برداری کردیم). یک راه سریعتر برای بررسی نحوه عملکرد برنامه وجود دارد. و سیستم مونتاژ دوباره در این مورد به ما کمک می کند. در اسکریپت ساخت پروژه Gradle خود، می‌توانیم یک پلاگین جدید " Gretty " را به بخش افزونه‌ها اضافه کنیم: id "org.gretty" version "2.3.1" و اکنون می‌توانیم یک کار gradle را برای اجرای برنامه خود انجام دهیم:gradle appRun

برای جزئیات بیشتر به " افزودن افزونه gretty و اجرای برنامه " مراجعه کنید.

Spring and Servlet API

سرولت ها اساس همه چیز هستند. و حتی فریم‌ورک محبوب اکنون بهار چیزی بیش از یک افزونه برای Servlet API نیست. برای شروع، Spring Framework یک وابستگی جدید برای پروژه ما است. بنابراین، اجازه دهید آن را به اسکریپت ساخت در بلوک وابستگی ها اضافه کنیم: در اسناد Spring Framework یک فصل " 1.1. DispatcherServletcompile 'org.springframework:spring-webmvc:5.1.3.RELEASE' " وجود دارد . می گوید که Spring Framework بر روی الگوی "Front Controller" ساخته شده است - این زمانی است که یک سرور مرکزی به نام " DispatcherServlet " وجود دارد. تمام درخواست‌ها به این سرورلت می‌آیند و فراخوانی‌ها را به اجزای لازم واگذار می‌کند. می بینید، حتی در اینجا سرولت ها وجود دارد. شما باید یک شنونده به توصیفگر استقرار اضافه کنید:

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

این شنونده رویداد servlet context است. یعنی زمانی که Context Servlet شروع می شود، زمینه Spring (WebApplicationContext) نیز شروع می شود. Servlet Context چیست؟ در مشخصات Servle API در فصل " فصل 4. زمینه Servlet " توضیح داده شده است. یک servlet context یک "نمای" servlet از برنامه وب است که در آن سرولت ها در حال اجرا هستند. هر برنامه وب دارای Context Servlet مخصوص به خود است. در مرحله بعد، برای فعال کردن Spring Framework، باید context-param را مشخص کنید - پارامتر مقداردهی اولیه برای زمینه servlet.

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

و تعریف DispatcherServlet پیکربندی را تکمیل می کند :

<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>

و اکنون فقط باید فایل مشخص شده در contextConfigLocation را پر کنیم. نحوه انجام این کار در مستندات Spring Framework در فصل "1.3.1. Declaration" توضیح داده شده است:

<?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>

در اینجا نه تنها مشخص کردن بسته‌ای که باید اسکن شود، مهم است، بلکه همچنین می‌خواهیم حاشیه‌نویسی محور باشد، یعنی کنترل حاشیه‌نویسی‌ها در مورد نحوه عملکرد Spring. تنها چیزی که باقی می ماند ایجاد بسته ru.javarush.javaweb و قرار دادن کلاس Spring controller در آن است:

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.";
    }
}

حالا با اجرای gradle appRun و رفتن به آدرس، http://127.0.0.1:8080/javaweb/appهمان Hello World را دریافت می کنیم. همانطور که می بینید، Spring Framework با Servlet API در هم تنیده شده است و از آن برای کار در بالای آن استفاده می کند.

حاشیه نویسی ها

همانطور که دیدیم، حاشیه نویسی راحت است. و ما تنها کسانی نبودیم که اینطور فکر می کردیم. بنابراین، در مشخصات Servlet API، با شروع نسخه 3.0، فصل " فصل 8 حاشیه نویسی و قابلیت اتصال " ظاهر شد، که مشخص می کند کانتینرهای servlet باید از توانایی تعیین آنچه قبلاً در Deployment Descriptor از طریق حاشیه نویسی مشخص شده است پشتیبانی کنند. بنابراین، web.xml می تواند به طور کامل از پروژه حذف شود، و در بالای کلاس servlet می توانید حاشیه نویسی WebServlet@ را مشخص کنید و مشخص کنید که سرولت به کدام مسیر نگاشت شود. اینجا همه چیز واضح به نظر می رسد. اما اگر Spring را به پروژه وصل کنیم که به تنظیمات پیچیده تری نیاز دارد چه؟ در اینجا همه چیز کمی پیچیده تر است. ابتدا، اسناد Spring می گوید که برای پیکربندی Spring بدون web.xml، باید از کلاس خود استفاده کنید که WebApplicationInitializer را پیاده سازی می کند. برای جزئیات بیشتر، به بخش " 1.1. DispatcherServlet " مراجعه کنید. معلوم شد که این کلاس بهار است. پس چگونه Servlet API در اینجا استفاده می شود؟ در واقع ServletContainerInitializer به Servlet API 3.0 اضافه شد . Spring با استفاده از یک مکانیسم خاص در جاوا (به نام SPI )، مقدار اولیه کانتینر سرولت خود را به نام SpringServletContainerInitializer. به نوبه خود، قبلاً به دنبال پیاده سازی WebApplicationInitializer می گردد و متدهای لازم را فراخوانی می کند و تنظیمات لازم را انجام می دهد. برای جزئیات بیشتر به " Container servlet چگونه پیاده سازی های WebApplicationInitializer را می یابد " مراجعه کنید. تنظیمات فوق را می توان به صورت زیر انجام داد:

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);
    }
}

اکنون، با استفاده از " پیکربندی مبتنی بر جاوا " نشان می‌دهیم که کدام بسته را اسکن کنیم + حاشیه‌نویسی را فعال کنیم:

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 {
}

و SpringController خود به منتقل شد ru.javarush.javaweb.controllers، تا هنگام اسکن، پیکربندی خودش را پیدا نکند، بلکه فقط به دنبال کنترلرها باشد.

خلاصه کردن

امیدوارم این مرور کلی به نحوه عملکرد برنامه های وب در جاوا روشن کرده باشد. این فقط نوک کوه یخ است، اما بدون درک اصول اولیه، درک چگونگی عملکرد فناوری های مبتنی بر این پایه دشوار است. Servlet API بخش مرکزی هر برنامه وب جاوا است، و ما به نحوه تناسب فریمورک های دیگر در آن نگاه کرده ایم. برای ادامه، می توانید مطالب زیر را مشاهده کنید:

Gradle : ساخت برنامه های کاربردی وب جاوا
" خدمات وب RESTful با چارچوب Spring - یک شروع سریع "
" هسته فنری "
" معرفی JEE "

#ویاچسلاو

نظرات

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