Hogyan működik az internetes java verem túlcsordulás alkalmazás orosz

előző ◈ a következő

Tud valaki magyarázza el, hogyan java webes alkalmazás kommentárok és rugós MVC együtt az alkalmazás szerver? (Esetemben GlassFish 4)

Amikor dolgozunk egy konzolos alkalmazás java, rámutatunk a csapat skomilirovannogo java osztály nevét. Ha jól értem, a JRE keres ebben az osztályban módszer public static void main (String args []), és végrehajtja. És ezt a módszert tartják a fő belépési pont a program.

És amikor már webes alkalmazás, van egyfajta belépési pont? Azt hittem először, hogy a belépési pont web.xml. De ha az általunk használt rugós MVC, és állítsa be a jelöléseket, értem web.xml is lehet üres.

Amikor glassfishu táplált war'nik, megértem a memóriában olyan esetek, osztályok vannak jelölve és magyarázó @Service @Controller. de aki létrehozza őket? Azt olvastam, hogy ez teszi a tavaszi, saját NOB. DI és edényzetét szerepet, hanem tavasz is valakinek meg kell futtatni?

Logikusan, Spring inicializálás kell történnie explicit vagy implicit kihívást tervezői a belépési ponton, de akkor hol van? Vagy formázza teszi az alkalmazás szerver? De hogyan tudjuk adni neki erre?

Itt van a SpringInitializer. Megértem az alapvető mágikus folyik itt?

Ez a kód nem Glassfish? Megértette, hogy ez az osztály kell futtatni?

Azt beletúrt Shildt Java Tutorial és tavaszi akcióban, és egy pár hétig, próbáljon más lekérdezéseket a tárgyra Google. Vagy azokban a könyvekben nem volt egyértelmű választ ezekre a kérdésekre, és én nem értem őket, vagy nem érti.

I kotorászott a kézi Shildt Java, valamint tavaszi akcióban

Ha azt szeretnénk, hogy megértsék az alapvető mechanizmusa webalkalmazás kell kezdeni a Servlet API specifikáció (3.0. 3.1).

  1. És amikor már webes alkalmazás, van egyfajta belépési pont?

Mint ilyen, nincs belépési pont. Van egy servlet konténer, amely veszi a háború és ha minden rendben van, indítsa el a életciklusát a webalkalmazás: beállítja a paramétereket, értesíti hallgatók továbbítjuk kéréseket szervletek átadja azokat szűrőkön keresztül. Tény, hogy a servlet konténer foglalkozik, hogy működik tárgyakat lehet leírt web.xml. és, kezdve a harmadik változata a specifikáció, akkor képesnek kell lennie arra, hogy keressük meg őket, és nem web.xml.

  1. . de aki létrehozza őket? Azt olvastam, hogy ez teszi a tavaszi, saját NOB, DI és edényzetét szerepet, hanem tavasz is valaki futni?

Rendben, NOB-tartály Spring (azaz AnnotationConfigWebApplicationContext az Ön esetében) is ellenőrzi a látható CLASSPATH és hozza létre a babot, vezetett a jelölések. Továbbra is megérteni, aki létrehoz egy példány a ApplicationContext és elkezdi az életciklus (lásd. Alább).

  1. Logikusan, Spring inicializálás kell történnie explicit vagy implicit kihívást tervezői a belépési ponton, de akkor hol van? Vagy formázza teszi az alkalmazás szerver? De hogyan tudjuk adni neki erre?

Nagyon helyes érvelés. Kezdve Servlet API 3.0 specifikáció nem lehetősége van arra, hogy használja a web.xml. De a servlet konténer kell valahogy megtudja, ha a kód inicializálja a webes alkalmazás. Itt segít mechanizmus ismert a Szolgáltató. Röviden, ő keres a CLASSPATH a servlet konténer leíró fájl META-INF / services / javax.servlet.ServletContainerInitializer. ami azt jelzi, a végrehajtás ServletContainerInitializer felületen. Abban az esetben, tavaszi-és ez lesz SpringServletContainerInitializer osztályban.

A szerződés értelmében a ServletContainerInitializer interfész tartály köteles átadni a konkrét megvalósítására az egyedülálló módszer onStartup gyűjtemény osztályok, hogy ebbe @HandlesTypes felsorolt ​​az összefoglaló. Itt már szerepel csak WebApplicationInitializer felület. Glassfish így adja az összes talált megvalósítása WebApplicationInitializer. Minden megvalósítása a példány, és hívja a módszer onStartup jön létre:

És ez a SpringInitializer ilyen végrehajtás. Ezen kívül SpringInitializer örökli AbstractDispatcherServletInitializer. És ez AbstractDispatcherServletInitializer és „elindítja tavasz”, ami WebApplicationContext. Minden összejött.

Korábbi verzióit JEE 6, amikor bevezetésre került Servlet 3.0 API, ebben a leírásban köteles elhelyezni a konfiguráció az alkalmazás telepítési leíró - web.xml. Kezdve Servlet 3.0 API, ez a fájl nem szükséges, hanem az használhatja ServletContainerInitializer felületet. Amikor telepíteni egy webes alkalmazás, a servlet konténer beolvassa a classpath az alkalmazás végrehajtása a jelenléte a meghatározott felületet, és ha talál egyet, akkor végrehajtja onStartup () metódust. ahol inicializálása a kérelmet kell végezni.

Mivel a tavaszi Web épül servlet, minden, ami van írva a fenti kifejezés azt a legközvetlenebb módon. Config a kommentárok kapható a tavaszi változata Servlet API 3.0+. Megvalósítás ServletContainerInitializer felület a tavaszi-webmodul. kapja meg azonnal csatlakozik a megfelelő függőségi Maven vagy Gradle. Megnézzük, mi a kód nem. Részlet a dokumentáció:

Interface amely lehetővé teszi a könyvtár / futásidejű értesíteni kell a webes alkalmazás indítási fázis és végezze el a szükséges programozási regisztrációs servlet, szűrők és hallgatók válasz.

Ő kapja az összes osztály, amelynek jelölése kommentár WebApplicationInitializer és inicializálja azokat. AbstractAnnotationConfigDispatcherServletInitializer. Ha megnézzük a hierarchia, ez csak egy ilyen osztály.

Aztán, sajnálom, én csak idézem a választ parallenogo oldalon. ahol ugyanaz a festett lépéseket:

  1. A webes alkalmazás WAR helyeztek a felhasználó által.
  2. Servlet konténer (Tomcat) olvas web.xml.
  3. Servlet összefüggésben hallgató ContextLoaderListener van futtatását (ha definiált belül a web.xml) által servlet konténer.
    1. ContextLoaderListener újfajta WebApplicationContext alkalmazásával összefüggésben XML konfigurációs.
    2. A gyökér összefüggésben babot regisztrált és példányai által BeanFactory belül a kérelmet összefüggésben.
  4. DispatcherServlet van futtatását a servlet konténer.
    1. DispatcherServlet létrehozza a saját WebApplicationContext (WEB-INF / -servlet.xml alapértelmezés) a ROOT összefüggésben, mint a szülő.
    2. A servlet babot regisztrált és példányai által BeanFactory belül a kérelmet összefüggésben.
    3. DispatcherServlet regisztrál néhány alapértelmezett bab az esetre, ha nem biztosítja számukra magad.

Ez az egyik lehetséges Servlet 3 jellemzői.

  1. A webes alkalmazás WAR helyeztek a felhasználó által.
  2. Servlet konténer keres osztályok végrehajtási ServletContainerInitializer keresztül Java ServiceLoader.
  3. Tavaszi SpringServletContainerInitializer található, és példányai által szervlet konténer.
  4. Tavaszi inicializáló szól webalkalmazás osztály-path és megkeresi WebApplicationInitializer megvalósítások.
  5. A WebApplicationInitializer megtalálható (btw. Ellenőrizze a JavaDoc). És példányai által SpringServletContainerInitializer.
    1. Az WebApplicationInitializer újfajta ROOT WebApplicationContext XML vagy @Configuration alapú konfiguráció.
    2. Az WebApplicationInitializer teremt új servlet WebApplicationContext XML vagy @Configuration alapú konfiguráció.
    3. Az WebApplicationInitializer teremt, és regisztrálja új DispatcherServlet az összefüggésben a korábbi lépésben.
  6. Servlet konténer befejezi a webes alkalmazás inicializálása és példányosít komponensek vettek nyilvántartásba az osztály az előző lépésben (nincs az én például).

így Az alkalmazás futtatásához a tavaszi segítségével kommentárok, akkor kell végrehajtani WebApplicationInitializer felület - lehet a közvetlen és örökölt egyik absztrakt osztályok, hogy létezik a kínálat, és helyezzük a konfigurációs fájl létezik (a SpringConfiguration példa). Jövő tavasszal lesz belőle anntotatsii @EnableWebMvc. @ComponentScan (ez a legalapvetőbb), és húzza a többi konfiguráció.

Minden együtt alkotja az ApplicationContext (annak ellenére, hogy meg van írva a számban, lehet, hogy több) - leírás alkalmazásának környezet, hogy csak lehetőséget ad arra, hogy alkalmazni kell a ládákat, változók és egyéb alkalmazás-erőforrások használatával a kommentárokat.

Válaszol március 6. '16 at 18:38

A belépési pont nagyon web.xml hozzáfér servlet konténer, amikor deploe, ami az Ön esetében is glasfish. Ha deploite sört vagy indul egy projekt a fejlesztési környezetben, glazfish vet fel servleteket és konfigurálását web.xml.

1) web.xml tavaszán nem marad üresen, csak művét servletekkel veszi Spring diszpécser servlet, web.xml de még mindig adja meg a Configuration Manager.

2) A kérdés, amit újra olvasni többször is, és nem tudom megérteni a lényegét. Mit és hol vannak Varnik kommentárok vezérlők és szolgáltatások? Tavaszi nem szabad futni, ez csak egy egyszerűsített változata a kávé tartály, amely felhasználja jelölések a gyors és tiszta design. A memória létrehoz egy komponenst, amely segítségével kommentárok vagy Autowired Adja Adja nem hozhat létre új esetek ebbe az osztályba, és abban az esetben több implementációja a bab, akkor választhat, hogy pontosan mit szeretne használni hozzáadásával kommentár selejtező (name = „”).

3) Az a példa is mutatja, ha jól értem, akkor a konfigurációs fájl, amely szintén regisztrálni kell a web.xml. Ha az XML konfigurációs, akkor egyértelműen meghatározott veb.hml körülbelül a következő formában:

Ha osztályok, míg glazfish rájön, hogy kell húzni, ez varrt a kommentárok a fejlesztők tavaszi és miért működik úgy, hogy a válasz, nem tudom.

Válaszol március 6. '16 at 18:53

de a web.xml még mindig adja meg a Configuration Manager. - Nem, egy harmadik változata a servlet már nincs szükség. - Nofate ♦ március 6. '16 at 18:56

Tavaszi távon nem szabad - ő nem varázslatosan indul. Valaki valahol van egy új AnnotationConfigWebApplicationContext (). - Nofate ♦ március 6. '16 at 19:04

Kapcsolódó cikkek

előző ◈ a következő