Cum aplicația overflow stiva Java web în limba rusă

Poate cineva să explice modul în care aplicația Java web cu adnotări și de primăvară-MVC, împreună cu serverul de aplicație? (În cazul meu GlassFish 4)

Când lucrăm cu o java aplicație consolă, semnalăm echipa skomilirovannogo numele clasei Java. După cum am înțeles, JRE caută în această metodă de clasă statice void main (String args []) publice și se execută. Și această metodă este considerat principalul punct de intrare în program.

Iar atunci când avem aplicație web, avem un fel de punct de intrare? M-am gândit la început că punctul de intrare este web.xml. Dar, dacă vom folosi de primăvară-MVC și configura folosind adnotări, am înțeles web.xml pot fi chiar goale.

Când glassfishu war'nik hrănite, am înțeles în memorie sunt exemple de clase care sunt marcate și adnotate @Service @Controller. dar cine le creează? Am citit că face primăvară, în IoC său. DI și rolul său container, dar, de primăvară, de asemenea, cineva are nevoie pentru a rula?

În mod logic, inițializarea de primăvară trebuie să aibă loc într-o provocare explicită sau implicită pentru designeri de la punctul de intrare, dar în cazul în care este ea? Sau inițializa face serverul de aplicații? Dar cum putem să-l dea să facă acest lucru?

Aici este SpringInitializer meu. Am înțeles magia de bază se întâmplă aici?

Acest cod nu Glassfish? El a înțeles că această clasă ar trebui să fie executați?

Am scotocit în Shildt Tutorialul de Java, și în primăvară în acțiune, și câteva săptămâni, încercați interogări diferite pe un subiect în Google. Sau în aceste cărți nu au fost răspunsuri clare la aceste întrebări și le-am pierdut, sau nu au înțeles.

Am scotocit în Shildt manual pe Java, precum și în primăvară în acțiune

Dacă doriți să înțeleagă mecanismele de bază ale aplicației web ar trebui să înceapă cu specificația Servlet API (3.0. 3.1).

  1. Iar atunci când avem aplicație web, avem un fel de punct de intrare?

Ca atare, nu există nici un punct de intrare. Există un container servlet care ia WAR si daca totul este bine, începe ciclul de viață al aplicației web: setează parametrii, notifică ascultătorii redirecționează cererile de servlet-uri, le trece prin filtre. De fapt, containerul servlet este angajată în care operează cu obiecte care pot fi descrise în web.xml. și, începând cu a treia versiune a caietului de sarcini, ar trebui să fie în măsură să le caute și fără web.xml.

  1. . dar cine le creează? Am citit că face primăvară, în IoC său, DI și rolul său container, dar, de asemenea, de primăvară cineva trebuie să ruleze?

Bine, de primăvară IoC-recipient (și anume AnnotationConfigWebApplicationContext în cazul dumneavoastră) scanează CLASSPATH vizibile și de a crea boabele, ghidate de adnotări. Rămâne să înțelegem care creează o instanță a ApplicationContext și începe ciclul de viață al acestuia (a se vedea. De mai jos).

  1. În mod logic, inițializarea de primăvară trebuie să aibă loc într-o provocare explicită sau implicită pentru designeri de la punctul de intrare, dar în cazul în care este ea? Sau inițializa face serverul de aplicații? Dar cum putem să-l dea să facă acest lucru?

Sunteți raționament foarte corect. Începând cu Servlet API 3.0 caietul de sarcini nu are posibilitatea de a utiliza web.xml. Dar containerul servlet trebuie să găsească într-un fel în cazul în care codul pe care inițializează aplicația Web. Aici ajută un mecanism cunoscut sub numele de Furnizorul de servicii. Pe scurt, el caută în CLASSPATH pentru containerul servlet fișier descriptor META-INF / servicii / javax.servlet.ServletContainerInitializer. ceea ce indică faptul că interfața de implementare ServletContainerInitializer. În cazul de primăvară-și va clasa SpringServletContainerInitializer.

Sub containerul de interfață ServletContainerInitializer contractul este obligat să transfere punerea în aplicare specifică în colecția metodei sale unice onStartup de clase care se încadrează în @HandlesTypes enumerate în rezumat. Aici am enumerat doar interfață WebApplicationInitializer. GlassFish asa ca da toate realizare găsit WebApplicationInitializer. Pentru fiecare realizare a instanței și a apela metoda onStartup vor fi create:

Și este dvs. SpringInitializer o astfel de punere în aplicare. În plus, SpringInitializer moștenește AbstractDispatcherServletInitializer. Și este această AbstractDispatcherServletInitializer și „lansează de primăvară“, crearea WebApplicationContext. Totul s-a.

Versiunile anterioare ale JEE 6, când a fost introdus Servlet 3.0 API, este necesară această specificație pentru a plasa configurația dvs. descriptor de implementare a aplicației - web.xml. Începând cu Servlet 3.0 API, acest fișier nu este necesară, în schimb, aplicația poate utiliza interfata ServletContainerInitializer. Când implementați un web-aplicație, containerul servlet scanează classpath implementării aplicației pentru prezența a interfeței specificate, iar atunci când constată una, se execută onStartup metoda (). în care inițializează aplicația trebuie efectuată.

Deoarece Web-ul de primăvară este construit pe servlet, tot ceea ce este scris mai sus se referă la el în modul cel mai direct. Config pe adnotările disponibile în versiunea de primăvară Servlet 3.0+ API. Punerea în aplicare interfață ServletContainerInitializer este în modulul de primăvară-ul web. primite se conecteaza imediat Maven de dependență corespunzătoare sau gradle. Aruncati o privire la ceea ce face codul. Extras din documentația:

Interfață care permite o bibliotecă / runtime pentru a fi notificat de faza de pornire o aplicație web și de a efectua orice înregistrare programatic necesar servletelor, filtre și ascultători ca răspuns la ea.

El devine toate clasele care sunt marcate adnotare WebApplicationInitializer și le inițializează. AbstractAnnotationConfigDispatcherServletInitializer. Dacă te uiți la ierarhia lui, este doar o astfel de clasă.

Apoi, îmi pare rău, eu citez doar răspunsul pe site-ul parallenogo. în cazul în care aceleași etape pictate:

  1. Un război aplicație web este implementat de către utilizator.
  2. container de servlet (Tomcat) citește web.xml.
  3. context servlet ascultător ContextLoaderListener este instantiat (în cazul în care este definit ca în interiorul web.xml) prin container servlet.
    1. ContextLoaderListener creează noi WebApplicationContext cu configurație context aplicație XML.
    2. ROOT dvs. fasole context sunt înregistrate și instantiate de BeanFactory în interiorul contextului de aplicare.
  4. DispatcherServlet este instanțiat de container servlet.
    1. DispatcherServlet creează propria WebApplicationContext (WEB-INF / -servlet.xml implicit) cu Rădăcină de context ca societatea-mamă.
    2. boabele de servlet sunt înregistrate și instantiate de BeanFactory în interiorul contextului de aplicare.
    3. DispatcherServlet înregistrează unele boabe standard în cazul în care nu le-ar oferi-te.

Aceasta este posibil cu Servlet 3 caracteristici.

  1. Un război aplicație web este implementat de către utilizator.
  2. Cautari servlet container pentru clasele de punere în aplicare prin intermediul ServletContainerInitializer ServiceLoader Java.
  3. SpringServletContainerInitializer de primăvară este găsit și instantiat de container servlet.
  4. citește Spring initializare clasa-cale și căutări aplicație web pentru implementări WebApplicationInitializer.
  5. WebApplicationInitializer este găsit (BTW. Verificați Javadoc sale.) Și instanțiat de SpringServletContainerInitializer.
    1. WebApplicationInitializer dvs. creează noi WebApplicationContext ROOT cu XML sau configurație @Configuration pe bază.
    2. WebApplicationInitializer dvs. creează noi WebApplicationContext servlet cu XML sau configurație @Configuration pe bază.
    3. WebApplicationInitializer dvs. creează și înregistrează noi DispatcherServlet cu contextul din etapa anterioară.
  6. container de servlet termină inițializarea aplicație web și instanțiază componente care au fost înregistrate de clasa lor în etapele anterioare (nici unul în exemplul meu).

astfel pentru a rula aplicația pe primăvară, folosind adnotări, aveți nevoie pentru a pune în aplicare interfață WebApplicationInitializer - poate fi atât directe, cât și moștenit de la una din clasele abstracte care există în furnizarea și se transferă fișierul de configurare există (în exemplul SpringConfiguration). În primăvara viitoare iese din ea anntotatsii @EnableWebMvc. @ComponentScan (aceasta este cea mai de bază) și trage restul configurației.

Toți împreună formează ApplicationContext (în ciuda faptului că este scris la singular, pot exista mai multe) - descrierea aplicării mediului, care oferă doar o oportunitate de a aplica silozurilor, variabile, și alte resurse pentru aplicații folosind adnotări.

Răspuns 6 martie '16 la 18:38

Punctul de intrare este accesat foarte web.xml de servlet container atunci când deploe, care, în cazul dumneavoastră este glasfish. Când deploite de preparare a cafelei sau a începe un proiect în mediul de dezvoltare, glazfish ridică toate Servleturi configurația web.xml.

1) web.xml în primăvară nu rămâne goală, doar munca lui cu servlete ia de primăvară servlet dispecer, web.xml dar încă specifica Configuration Manager.

2) Problema am re-citit de mai multe ori și nu pot să înțeleg esența ei. Ce și în cazul în care sunt operatori și servicii de adnotări Varnik? un arc nu ar trebui să ruleze, aceasta este doar o versiune simplificată a recipientului pentru boabe, care folosește adnotări pentru proiectare rapidă și clară. În memoria creează un bob care utilizează adnotări sau Autowired Injectare Injectare nu poate crea noi instanțe ale acestei clase, iar în cazul mai multor implementări de fasole, puteți alege exact ceea ce doriți să utilizați prin adăugarea unei adnotări Qualifier (name = „“).

3) În exemplul dvs. arată, după cum am înțeles, fișierul de configurare, care, de asemenea trebuie să fie înregistrate în web.xml dumneavoastră. Dacă utilizați de configurare XML, atunci ele sunt clar specificate în veb.hml aproximativ în forma următoare:

Dacă utilizați clase, în timp ce glazfish înțelege că el trebuie să se tragă cusute în adnotări dezvoltatorii de primăvară și de ce este atât de lucrări, pentru a da un răspuns, nu pot.

Răspuns 6 martie '16 la 18:53

dar în web.xml vom preciza în continuare și Configuration Manager. - Nu, a treia versiune a servlet nu mai este necesară. - Nofate ♦ 06 martie '16 la 18:56

alerga de primăvară nu ar trebui - el nu a început magic. Cineva are undeva pentru a crea un nou AnnotationConfigWebApplicationContext (). - Nofate ♦ 06 martie '16 la 19:04

articole similare