CodeGym /Java blogg /Slumpmässig /Del 6. Servletbehållare

Nivå

San Francisco

21 July 2023
175 views
0 comments

Del 6. Servletbehållare

Detta material är en del av serien "Introduktion till företagsutveckling". Tidigare artiklar:

I den förra artikeln bekantade vi oss med servlets och lärde oss hur man använder dem för att skapa webbapplikationer. Det är dags att titta närmare på en väsentlig del av detta roliga: servletbehållare.

Innehållsförteckning:

Vad är en servletbehållare?

Det är ett program som körs på en server och kan interagera med servletarna vi skapat. Med andra ord, om vi vill köra vår webbapplikation på en server distribuerar vi först en servletbehållare och lägger sedan servlets i den. Arbetsflödet är enkelt: när klienten kommer åt servern, bearbetar behållaren sin begäran, bestämmer vilken servlet som ska behandla den och skickar sedan begäran vidare. Del 6. Servletbehållare - 2

Hur används servletbehållare?

Förutom routingbegäranden utför en servletbehållare andra funktioner:

Den genererar dynamiskt HTML-sidor från JSP-filer.
Den krypterar/dekrypterar HTTPS-meddelanden.
Det ger begränsad åtkomst för servletadministration.

I allmänhet låter det här bra. Nu behöver vi bara ta reda på hur vi ska omsätta allt i praktiken. Tja, för att lära sig hur man använder något är det bara att dyka in och försöka använda det :) Så idag ska vi träna! Den mest populära servletbehållaren är Apache Tomcat . Det är öppen källkod och kan användas gratis. Ladda ner Tomcat för ditt operativsystem här så kommer vi att utforska arbetet med behållare "in action".

Installera och starta Tomcat

För att installera Tomcat, packa helt enkelt upp det nedladdade arkivet till önskad katalog.
Observera att Tomcat kräver Java version 8 eller högre för att starta och köra. Kontrollera att miljövariabeln JAVA_HOME refererar till den aktuella versionen av JDK.
Därefter måste du konfigurera användaråtkomst till Tomcat . Detta görs i filen tomcat-users.xml, som finns i mappen conf.

Det finns fyra förinställda roller i Tomcat:
- manager-gui — Tillgång till det grafiska gränssnittet och statussidan
- manager-script — Åtkomst till textgränssnittet och statussidan
- manager-jmx — Tillgång till JMX och statussidan
- manager-status — Åtkomst endast till statussidan
Inuti taggen <tomcat-users> specificerar vi dessa roller uttryckligen och tilldelar dem till vår användare:
```
<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<role rolename="manager-jmx"/>
<role rolename="manager-status"/>
<user username="user" password="password"
    roles="manager-gui, manager-script, manager-jmx, manager-status"/>
```
Nu är allt klart för lansering!
Kör filen startup.bat (startup.sh på Linux) i bin-mappen.
Efter några sekunder öppnar du länken http://localhost:8080/ i din webbläsare. Du kommer att se en grafisk instrumentpanel:

Om du ser en meny som denna är Tomcat igång.
Om den inte körs, kontrollera manuellt miljövariablerna JAVA_HOME och CATALINA_HOME:
- JAVA_HOME — Detta måste referera till den aktuella versionen av Java 8+.
- CATALINA_BASE — Detta måste referera till Tomcat eller vara frånvarande (det bör inte referera till en annan version av Tomcat).

Distribuera en applikation i Tomcat

Vi lyckades lansera Tomcat, så det är nu dags att distribuera något projekt i den. Låt oss använda servlets från föregående artikel . MainServlet:


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

@WebServlet("/hello")
public class MainServlet extends HttpServlet {

   @Override
   protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
       HttpSession session = req.getSession();
       Integer visitCounter = (Integer) session.getAttribute("visitCounter");
       if (visitCounter == null) {
           visitCounter = 1;
       } else {
           visitCounter++;
       }
       session.setAttribute("visitCounter", visitCounter);
       String username = req.getParameter("username");
       resp.setContentType("text/html");
       PrintWriter printWriter = resp.getWriter();
       if (username == null) {
           printWriter.write("Hello, Anonymous" + "
");
       } else {
           printWriter.write("Hello, " + username + "
");
       }
       printWriter.write("Page was visited " + visitCounter + " times.");
       printWriter.close();
   }
}

IndexServlet:


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("/")
public class IndexServlet extends HttpServlet {

   @Override
   protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
       resp.sendRedirect(req.getContextPath() + "/hello");
   }
}

Innan vi distribuerar måste vi paketera våra servlets i en WAR-fil. Maven används vanligtvis för att göra detta, men för att skapa en WAR-fil behöver du en web.xml-fil som har en mappning för alla servlets. Vi använde den nya @WebServlet-anteckningen för att skriva servletarna, så vi har ingen web.xml-fil. Lyckligtvis kan IDEA göra det smutsiga arbetet åt oss genom att slå in vårt projekt i en WAR-fil. För att göra detta, öppna projektstrukturen (Ctrl+Skift+Alt+S) -> Artefakter -> Välj önskad WAR-fil -> Markera kryssrutan bredvid "Inkludera i projektbygget" -> Klicka på "OK". Del 6. Servletbehållare - 4

Låt oss bygga projektet med hjälp av tangentkombinationen Ctrl+F9. Nu finns vår WAR-fil i målkatalogen. Del 6. Servletbehållare - 5

Filen kan döpas om till något enklare, t.ex. servlet.war, och flyttas till en mer bekväm plats, t.ex. C:\\my\\.vi lägger den i en behållare . Det finns två sätt att göra detta.

Använder det grafiska gränssnittet

För att göra detta, följ denna länk: http://localhost:8080/manager/html . Tomcat bör be om ett användarnamn och lösenord.

Om du följt med mig fram till denna punkt är användarnamnet "användare" och lösenordet är "lösenord" .

När du har loggat in kommer du att se Tomcat Web Application Manager. Avsnittet "Applikationer" innehåller redan 5 applikationer — dessa är Tomcat-verktyg som gör Tomcat lättare att arbeta med. De kan raderas i framtiden.

Nedan finns avsnittet "Distribuera". Här kan du välja WAR-arkivet att distribuera. Låt oss ange sökvägen och sammanhanget manuellt:

Klicka på "Distribuera" och vi ser att vår applikation har dykt upp i avsnittet "Applikationer":
Med hjälp av Tomcats grafiska gränssnitt kan vi stoppa, starta om och ta bort en session, samt ställa in sessionslängden. Vid distributionen angav vi /demo-kontexten, vilket innebär att vår applikation nås med http://localhost:8080/demo . Kolla upp det. Allt ska fungera.
Genom filsystemet

För att distribuera programmet på detta sätt måste du öppna katalogen där Tomcat packades upp. Gå sedan till mappen "webapps". Här hittar du de verktyg vi redan har stött på:

Allt som krävs är att vi flyttar vår servlet.war-fil hit.

Vi väntar några sekunder och ser sedan att en ny "servlet"-mapp har dykt upp. Det betyder att vår applikation är utplacerad. Gå till Application Manager-gränssnittet på http://localhost:8080/manager/ . Här ser vi att vår applikation är distribuerad i /servlet-kontexten:

När den distribueras på detta sätt tilldelas kontexten automatiskt baserat på namnet på den distribuerade WAR-filen. För att ändra sammanhanget kan du byta namn på den nyskapade mappen som innehåller programmet, men innan du gör det måste du ta bort WAR-filen. Annars kommer Tomcat att distribuera om applikationen med arkivnamnet.

Som du kan se är det mycket lättare att distribuera applikationer i Tomcat än det kan verka. Men dess andra funktioner är också lätta att använda. Låt oss kolla.

Använder HTTPS istället för HTTP

Om du kommer ihåg så tittade vi på skillnaden mellan HTTP och HTTPS i en separat artikel . HTTPS är samma protokoll som HTTP, men det krypterar data som överförs. På klientsidan ansvarar webbläsaren för kryptering, men vi måste tillhandahålla krypteringen på serversidan. Eftersom Tomcat accepterar och dirigerar HTTP-förfrågningar, är det vettigt att delegera kryptering till den. För att göra detta måste vi:

Skapa ett självsignerat certifikat
Gör ytterligare serverinställningar

Låt oss öva på att göra detta.

Skapar ett certifikat

Oavsett version innehåller JDK ett stort antal verktyg. En av dem är keytool . Detta är ett verktyg för att generera och arbeta med krypteringsnycklar. För att använda den, på kommandoraden, gå till katalogen C:\\Program Files\\Java\\jdk1.8.0_181\\bin och kör kommandot keytool -genkey -alias tomcat -keyalg RSA .

keytool — Namnet på verktyget som vi kör med kommandoradsalternativ
-genkey — Indikerar att vi vill generera en ny nyckel
-alias tomcat — Skapa ett nyckelalias
-keyalg RSA — Välj RSA som nyckelgenereringsalgoritm

Efter att ha utfört kommandot startar verktyget en dialog med oss: Del 6. Servletbehållare - 11

Ange nödvändig information. Nu har vi skapat ett nyckellager i vår hemkatalog (för Windows är detta C:\\Users\\{användarnamn}\\.keystore) och en tomcat-nyckel i den. Vi genererade ett enkelt certifikat som de flesta webbläsare kommer att klaga på. Ett sådant certifikat är inte lämpligt för kommersiella tillämpningar: det kan endast användas för teständamål. På en produktionsserver måste du använda ett certifikat från en certifieringsmyndighet (till exempel https://letsencrypt.org/ ).

Konfigurera servern

Nu när certifikatet är klart måste vi justera serverinställningarna, nämligen SSL-anslutningen. Detta görs i filen server.xml, som finns i apache-tomcat-9.0.30/conf/ . I den hittar vi block så här:


<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
               maxThreads="150" SSLEnabled="true">
        <SSLHostConfig>
            <Certificate certificateKeystoreFile="conf/localhost-rsa.jks"
                         type="RSA" />
        </SSLHostConfig>
 </Connector>

och vi lägger vår konfiguration bredvid dem:


    <Connector
           protocol="org.apache.coyote.http11.Http11NioProtocol"
           port="8443" maxThreads="200"
           scheme="https" secure="true" SSLEnabled="true"
           keystoreFile="C:\Users\user\.keystore" keystorePass="mypass"
           clientAuth="false" sslProtocol="TLS"/>

Vi tilldelar de senaste värdena till parametrarna keystoreFile och keystorePass, sparar filen och startar sedan om Tomcat med filerna shutdown.bat och startup.bat. Nu är servern redo att behandla HTTPS-förfrågningar. Adressen har bara ändrats lite: https://localhost:8443/demo/hello . När du klickar på länken får du en varning om certifikatets tillförlitlighet, vilket inte är förvånande. Som vi sa lite tidigare måste du använda en av certifieringsmyndigheternas tjänster för att få ett vanligt certifikat. Men för nu har vi uppnått vårt mål: applikationen körs med HTTPS-protokollet, och det är viktigt!

Dynamiskt generera HTML-sidor

Nu ska vi fortsätta vår översikt över servletbehållare genom att överväga en annan funktion: dynamisk generering av HTML-sidor. Föreställ dig en perfekt värld där du istället för tråkig statisk HTML-kod kan skriva Java-kod med hjälp av variabler, loopar, arrayer och andra språkkonstruktioner. Kunde du föreställa dig det? Den goda nyheten är att något liknande finns. Den dåliga nyheten är att den inte helt uppnår denna fantasi. Om du inte har gissat så pratar vi om JavaServer Pages (JSP). Kort sagt, detta är teknik som låter dig infoga bitar av Java-kod på en HTML-sida. Visserligen konverteras den här Java-koden fortfarande till HTML innan den skickas till klienten, men den HTML-koden kommer att genereras dynamiskt, med hänsyn till olika faktorer. Till exempel, du kan använda villkorliga uttalanden och returnera olika innehåll beroende på något tillstånd. Exempel på JSP-sida:


<%@ page language="java"" %>
<html>
<head>
<title>JSP</title>
</head>

<body>
<%
String firstName="name";
String secondName="surname";
    
    if (firstName.equals("name")){
      out.print("Hello: "+firstName+"<br>");
    }

    if (firstName.equals("name") && secondName.equals("surname"))
    {
      out.print("Hello, my dear friend! <br>");
    }
    else
    {
      out.print("I don't know you. Go away! <br>");
    }
%>
</body>
</html>

Du kan läsa mer om JSP här. I slutändan handlar den här artikeln inte om JSP – vi är här för att prata om servletbehållare! Så varför nämnde vi JSP? Det är enkelt: en servletbehållare är det som konverterar Java-kod från JSP till HTML. När en servlet ska returnera JSP-innehåll som ett svar, noterar behållaren det och konverterar det först till en webbläsarvänlig HTML-sida innan sådant innehåll skickas till klienten. Idag finns det många analoger till JSP-teknik - Thymeleaf, FreeMarket, Mustache och andra. De fungerar alla på ett liknande sätt. Vilken av dem du ska välja för ditt arbete är en smaksak. Detta gäller även vid val av servletbehållare. I dessa exempel använde vi Tomcat, den vanligaste behållaren, men vissa projekt använder andra behållare. Det är värt att kortfattat granska de mest populära och överväga hur de skiljer sig från Tomcat.

Alternativ till Tomcat

GlassFish är en öppen källkodsbehållare vars utveckling stöds av Oracle.

Till skillnad från Tomcat är det en fullfjädrad webbserver, som förutom servlets kan fungera med andra komponenter från JavaEE-ramverket. Som sagt, den använder mycket mer RAM. Det finns större flexibilitet vid finjustering av servern, vilket komplicerar användningen. Det bör användas vid utveckling av applikationer på JavaEE-ramverket.
WildFly var tidigare känd som JBoss . Det är också öppen källkod. Den är utvecklad av Red Hat. Namnet ändrades för att undvika förväxling med en annan av företagets produkter - JBoss Enterprise Application Platform.

Liksom GlassFish är WildFly en fullfjädrad webbserver. För övrigt, under huven använder WildFly Tomcat som en servletbehållare. Till skillnad från GlassFish är WildFly mer lätt och lätt att konfigurera.
Jetty , liksom de tidigare, är öppen källkod. Den är utvecklad av Eclipse.

Liksom Tomcat är det en enkel servletbehållare, utan stöd för alla komponenter i JavaEE-ramverket. Samtidigt är den mer lätt och kan till och med köras på en mobiltelefon. Den startar och stannar snabbt och skalar bra. Till skillnad från Tomcat har den en mindre gemenskap och kunskapsbas.
WebLogic är licensierad programvara som måste köpas innan användning. Den tillhör Oracle.

Den har något bredare funktionalitet än Tomcat. Det kan fungera med FTP-protokollet. Men det är inte så flexibelt när man utvecklar och testar applikationer.
WebSphere (WebSphere Application Server, för att vara exakt) är betald programvara. Den är utvecklad av IBM. I likhet med WildFly och GlassFish är det en komplett applikationsserver. Men den har ett vänligare konfigurationsgränssnitt, plus hög driftsäkerhet.

Dess brister inkluderar det faktum att det använder mycket resurser och tar lång tid att starta och stoppa, vilket inte är särskilt bekvämt när man utvecklar små projekt.

Valet av rätt servletbehållare eller applikationsserver beror på det specifika projektet. Det finns projekt där även en tydlig underdog kan visa sig vara ett utmärkt val, men till en början är det bäst att göra en djupgående studie av en servletbehållare. Tomcat är förmodligen den perfekta kandidaten för denna studie. Och vi har redan tagit de första stegen i att studera det, men härifrån är det upp till dig! I de sista artiklarna i serien "Introduktion till företagsutveckling" kommer vi att lära känna MVC-mönstret. Del 7. Introduktion av MVC-mönstret (Model-View-Controller).

Kommentarer

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