1. Genel Bilgiler

Belgenin PDF dosyası, |BURADA| adresinde mevcuttur.

1.1. Hedefler

Burada, STRUTS adlı bir geliştirme yöntemini keşfetmeyi amaçlıyoruz. Jakarta Struts, Apache Software Foundation’ın (www.apache.org) bir projesidir ve MVC (Model-Görünüm-Denetleyici) olarak adlandırılan mimariye uygun, Java tabanlı web uygulamaları geliştirme için standart bir çerçeve sağlamayı amaçlamaktadır.

1.2. MVC modeli

MVC modeli, sunum, işleme ve veri erişim katmanlarını birbirinden ayırmayı amaçlamaktadır. Bu modele uygun bir web uygulaması şu şekilde yapılandırılacaktır:

Bu tür bir mimariye 3 katmanlı veya 3 seviyeli mimari denir:

kullanıcı arayüzü V'dir (görünüm)
uygulama mantığı C'dir (denetleyici)
veri kaynakları ise M'dir (Model)

Kullanıcı arayüzü genellikle bir web tarayıcısıdır, ancak ağ üzerinden web hizmetine HTTP istekleri gönderen ve web hizmetinin geri gönderdiği sonuçları biçimlendiren bağımsız bir uygulama da olabilir. Uygulama mantığı, kullanıcı isteklerini işleyen komut dosyalarından oluşur. Veri kaynağı genellikle bir veritabanıdır, ancak basit düz dosyalar, bir LDAP dizini, uzak bir web hizmeti vb. de olabilir. Geliştiricinin, bu üç varlık arasında büyük bir bağımsızlık sağlaması önemlidir; böylece bunlardan biri değiştiğinde, diğer ikisinin değişmesi gerekmez veya çok az değişir.

Bu modeli servletler ve JSP sayfalarıyla uygulamaya çalıştığımızda, aşağıdaki mimari ortaya çıkar:

[Logique Applicative] bloğunda şunlar ayırt edilir:

uygulamanın giriş kapısı olan ve denetleyici olarak da adlandırılan servlet
uygulamanın mantığı için gerekli Java sınıflarını bir araya getiren [Classes métier] bloğu.
servlet için gerekli verileri elde etmek üzere kullanılan, genellikle kalıcı veriler içeren Java sınıflarını barındıran [Classes d'accès aux données] bloğu (BD, dosyalar, WEB hizmeti, ...)
Uygulamanın görünümlerini oluşturan JSP sayfalar bloğu.

1.3. Servletler ve sayfalar kullanılarak MVC geliştirme yaklaşımı

Yukarıdaki MVC modeline uygun Java web uygulamaları geliştirmek için bir süreç tanımladık. Bu süreci burada tekrar hatırlatıyoruz.

İlk olarak, uygulamanın tüm görünümlerini tanımlayacağız. Bunlar, kullanıcıya sunulan web sayfalarıdır. Dolayısıyla, görünümleri tasarlarken kendimizi kullanıcının yerine koyacağız. Üç tür görünüm ayırt edilir:
- Kullanıcıdan bilgi toplamayı amaçlayan giriş formu. Bu formda genellikle girilen bilgileri sunucuya göndermek için bir düğme bulunur.
- Yalnızca kullanıcıya bilgi vermek amacıyla kullanılan yanıt sayfası. Bu sayfada genellikle kullanıcının uygulamaya başka bir sayfayla devam etmesini sağlayan bir bağlantı bulunur.
- karma sayfa: servlet, oluşturduğu bilgileri içeren bir sayfayı istemciye göndermiştir. Aynı sayfa, istemcinin servlete başka bilgiler sağlaması için de kullanılacaktır.

Her görünüm, JSP adlı bir sayfa oluşturacaktır. Bunların her biri için:
- sayfanın görünümü tasarlanacak
- sayfanın hangi kısımlarının dinamik olduğu belirlenecektir:
  - kullanıcıya yönelik bilgiler; bunlar, servlet tarafından JSP görünümüne parametreler olarak sağlanmalıdır
  - işlenmek üzere servlet'e iletilmesi gereken giriş verileri. Bunlar, HTML formunun bir parçası olmalıdır.

Her bir görünümün G/Ç işlemlerini şematik olarak gösterebiliriz

Girişler, servletin JSP sayfasına ister istek (request) ister oturum (session) yoluyla sağlaması gereken verilerdir.
Çıkışlar ise JSP sayfasının servlete sağlaması gereken verilerdir. Bunlar HTML formunun bir parçasıdır ve servlet bunları request.getparameter(...) türünde bir işlemle alacaktır.

Her bir görünümün Java/JSP kodunu yazacağız. Bu kod genellikle şu şekilde olacaktır:

<%@ page ... %>    // en sık kullanılan sınıf içe aktarmaları
<%!
     // JSP sayfasının örnek değişkenleri (=genel)
     // sadece JSP sayfasında değişkenleri paylaşan yöntemler varsa gereklidir (nadir)     
    ...    
%>
<%
     // servlet tarafından gönderilen verilerin alınması
     // ister istek (request) içinde ister oturum (session) içinde olsun
    ...
%>

<html>
...
         // burada Java kodunu en aza indirmeye çalışacağız
</html>

Artık ilk testlere geçebiliriz. Aşağıda açıklanan dağıtım yöntemi, Tomcat sunucusuna özeldir:

uygulama bağlamı, Tomcat'in server.xml dosyasında oluşturulmalıdır. Öncelikle bu bağlamı test edebiliriz. Bu bağlamı C, buna ait klasörü ise DC olarak alalım. test.html adlı statik bir dosya oluşturup bunu DC klasörüne yerleştireceğiz. Tomcat'i başlattıktan sonra, bir tarayıcıdan URL adresine http://localhost:8080/DC/test.html şeklinde erişeceğiz.
Her bir JSP sayfası test edilebilir. Eğer JSP adlı bir sayfa formulaire.jsp olarak adlandırılırsa, bir tarayıcıyla URL adresinden http://localhost:8080/DC/formulaire.jsp sayfasına erişilir. JSP sayfası, kendisini çağıran servlet'ten değerler bekler. Burada servlet doğrudan çağrıldığı için beklenen parametreleri almayacaktır. Yine de testlerin yapılabilmesi için, JSP sayfasında beklenen parametreleri sabitlerle kendimiz başlatacağız. Bu ilk testler, JSP sayfalarının sözdizimsel olarak doğru olduğunu doğrulamamıza olanak tanır.

Ardından servlet kodunu yazıyoruz. Bu servletin birbirinden tamamen farklı iki yöntemi vardır:

init yöntemi şu amaçla kullanılır:
- uygulamanın web.xml dosyasındaki yapılandırma parametrelerini almak
- daha sonra kullanacağı iş sınıflarının örneklerini oluşturmak
- uygulamanın gelecekteki kullanıcılarına geri gönderilecek olası bir başlatma hataları listesini yönetmek. Bu hata yönetimi, bir arızayı bildirmek amacıyla uygulama yöneticisine e-posta gönderilmesine kadar uzanabilir
servletin müşterilerinden parametreleri alma şekline bağlı olarak doGet veya doPost yöntemi. Servlet birden fazla form yönetiyorsa, her birinin kendisini benzersiz bir şekilde tanımlayan bir bilgi göndermesi uygun olur. Bu, formda <input type="hidden" name="action" value="..."> türünde gizli bir öznitelik kullanılarak yapılabilir. Servlet, öncelikle bu parametrenin değerini okuyabilir ve ardından isteğin işlenmesini, bu tür istekleri işlemekle görevli özel bir iç yönteme devredebilir.
Servlet'e iş mantığı kodunu eklemekten mümkün olduğunca kaçınılmalıdır. Servlet bu amaçla tasarlanmamıştır. Servlet, müşterilerinden (web istemcileri) gelen talepleri alan ve bunları en uygun kişiler (iş sınıfları) tarafından yürütülmesini sağlayan bir tür ekip lideri (denetleyici) gibidir. Servlet yazılırken, yazılacak iş sınıflarının arayüzü (yapıcılar, yöntemler) belirlenir. Tabii bu, söz konusu iş sınıflarının henüz oluşturulmamış olması durumunda geçerlidir. Eğer bu sınıflar zaten mevcutsa, servlet mevcut arayüze uyum sağlamalıdır.
Servlet kodu derlenecektir.

Servlet için gerekli iş sınıflarının iskeleti yazılacaktır. Örneğin, servlet proxyArticles türünde bir nesne kullanıyorsa ve bu sınıfın bir karakter dizisi listesi (ArrayList) döndüren getCodes yöntemine sahip olması gerekiyorsa, ilk etapta şunu yazmak yeterli olabilir:

public ArrayList getCodes(){
    String[] codes= {"code1","code2","code3"};
    ArrayList aCodes=new ArrayList();
    for(int i=0;i<codes.length;i++){
        aCodes.add(codes[i]);
    }
        return aCodes;
}

Ardından servlet testlerine geçilebilir.

Uygulamanın web.xml yapılandırma dosyası oluşturulmalıdır. Bu dosya, servletin init yönteminin beklediği tüm bilgileri (<init-param>) içermelidir. Ayrıca, ana servlete erişim sağlanacak olan URL dosyası da ayarlanmalıdır (<servlet-mapping>).
Gerekli tüm sınıflar (servlet, iş sınıfları) WEB-INF/classes dizinine yerleştirilir.
Gerekli tüm sınıf kütüphaneleri (.jar) WEB-INF/lib dizinine yerleştirilir. Bu kütüphaneler iş sınıfları, JDBC sürücüleri vb. içerebilir.
JSP görünümleri, uygulamanın kök dizinine veya ayrı bir klasöre yerleştirilir. Diğer kaynaklar (html, resimler, ses, videolar, ...) için de aynı işlem yapılır.
Bu işlem tamamlandıktan sonra, uygulama test edilir ve ilk hatalar düzeltilir. Bu aşamanın sonunda, uygulamanın mimarisi çalışır hale gelir. Tomcat’ta hata ayıklama aracı bulunmadığı için bu test aşaması biraz zorlu olabilir. Bunun için Tomcat’ın bir geliştirme aracına (JBuilder Developer, Sun One Studio, ...) entegre edilmesi gerekir. Tomcat penceresine yazdırma yapan System.out.println("....") komutlarından yararlanılabilir. İlk olarak, init yönteminin web.xml dosyasından gelen tüm verileri doğru bir şekilde aldığını kontrol etmek gerekir. Bunun için bu verilerin değerlerini Tomcat penceresine yazabiliriz. Aynı şekilde, doGet ve doPost yöntemlerinin, uygulamanın çeşitli HTML formlarının parametrelerini doğru bir şekilde aldığını da kontrol ederiz.

Servletin ihtiyaç duyduğu iş sınıfları yazılır. Burada genellikle, çoğu zaman herhangi bir web uygulamasından bağımsız olan klasik bir Java sınıfı geliştirilir. Bu sınıf, öncelikle bu ortamın dışında, örneğin bir konsol uygulaması ile test edilir. Bir iş sınıfı yazıldıktan sonra, onu web uygulamasının dağıtım mimarisine entegre edebilir ve bu mimariye doğru bir şekilde entegre olup olmadığını test edebiliriz. Her iş sınıfı için bu şekilde ilerlenir.

1.4. STRUTS Geliştirme Yaklaşımı

STRUTS metodolojisinin yaratıcıları, Java ile yazılmış web uygulamaları için MVC mimarisine uygun standart bir geliştirme yöntemi tanımlamayı amaçlamışlardır. STRUTS projesinin iki yönü vardır:

geliştirme yöntemi. Bu yöntemin, yukarıda servletler ve sayfalar için açıklanan yönteme oldukça yakın olduğunu göreceğiz; JSP
bu geliştirme yöntemini uygulamamızı sağlayan araçlar. Bunlar, Apache Vakfı'nın web sitesinde (www.apache.org) bulunan Java sınıf kütüphaneleridir.

1.4.1. Geliştirme yöntemi

STRUTS tarafından kullanılan MVC mimarisi şöyledir:

Denetleyici, uygulamanın kalbidir. İstemciden gelen tüm istekler bu denetleyiciden geçer. Bu, STRUTS tarafından sağlanan genel bir servlettir. Bazı durumlarda bu servleti türetmek gerekebilir. Basit durumlarda ise buna gerek yoktur. Bu genel servlet, ihtiyaç duyduğu bilgileri genellikle struts-config.xml olarak adlandırılan bir dosyadan alır.
Müşterinin isteği form parametreleri içeriyorsa, bunlar bir Bean nesnesine yerleştirilir. Bir sınıf, biraz sonra ele alacağımız oluşturma kurallarına uyuyorsa Bean türü olarak adlandırılır. Zaman içinde bu şekilde oluşturulan Bean nesneleri, oturumda veya müşterinin isteğinde depolanır. Bu ayar değiştirilebilir. Daha önce oluşturulmuşlarsa yeniden oluşturulmaları gerekmez.
struts-config.html yapılandırma dosyasında, program tarafından işlenmesi gereken her URL'e (dolayısıyla doğrudan talep edilebilecek bir JSP görünümüne karşılık gelmeyen) belirli bilgiler atanır:
- isteği işlemekle görevli Action türü sınıfın adı. Burada da, örneklendirilmiş Action nesnesi oturumda veya istekte saklanabilir.
- Talep edilen URL parametrelerle donatılmışsa (örneğin, denetleyiciye bir formun gönderilmesi durumu), form bilgilerini depolamaktan sorumlu bean'in adı belirtilir.
Yapılandırma dosyası tarafından sağlanan bu bilgilerle donatılmış olan denetleyici, bir istemciden URL isteği aldığında, oluşturulacak bir bean olup olmadığını ve hangisi olduğunu belirleyebilir. Oluşturulduktan sonra, bean, depoladığı ve formdan gelen verilerin geçerli olup olmadığını kontrol edebilir. Bean’in validate adlı yöntemi, denetleyici tarafından otomatik olarak çağrılır. Bean, geliştirici tarafından oluşturulur. Geliştirici, form verilerinin geçerliliğini kontrol eden kodu validate yöntemine yerleştirir. Veriler geçersiz çıkarsa, denetleyici işlemi daha ileriye götürmez. Denetleyici, yapılandırma dosyasında adını bulduğu bir görünüme kontrolü devreder. Böylece işlem tamamlanmış olur. Geliştiricinin, formun geçerliliğinin kontrol edilmemesini talep edebileceği unutulmamalıdır. Bunu, struts-config.html dosyasında da yapmaktadır. Bu durumda, denetleyici bean'in validate yöntemini çağırmaz.
Bean verileri doğruysa, doğrulama yapılmıyorsa veya bean yoksa, denetleyici kontrolü URL ile ilişkili Action türündeki nesneye devreder. Bunu, söz konusu nesnenin `execute` yönteminin çalıştırılmasını talep ederek yapar ve bu yöntemine, gerekirse oluşturduğu Bean'in referansını iletir. Geliştirici, bu aşamada yapması gerekenleri gerçekleştirir: gerekirse iş logiği sınıflarını veya veri erişim sınıflarını çağırması gerekebilir. İşlem tamamlandığında, Action nesnesi, kontrolöre müşteriye yanıt olarak göndermesi gereken görünümün adını bildirir.
Denetleyici bu yanıtı gönderir. İstemciyle olan iletişim sona erer.

STRUTS geliştirme metodolojisi şekillenmeye başlar:

Görünümlerin tanımlanması. Form niteliğindeki görünümler ile diğerleri birbirinden ayrılır.
- Her form görünümü, struts-config.xml dosyasında bir tanım oluşturur. Burada aşağıdaki bilgiler tanımlanır:
  - Form verilerini içerecek Bean sınıfının adı ve verilerin doğrulanması gerekip gerekmediğine dair bilgi. Verilerin doğrulanması gerekiyorsa ve geçersiz olduğu tespit edilirse, bu durumda müşteriye yanıt olarak gönderilecek görünüm belirtilmelidir.
  - Formu işlemekle görevli Action sınıfının adı.
  - İstek işlendikten sonra müşteriye yanıt olarak gönderilebilecek tüm görünümlerin adı. Action sınıfı, işleme sonucuna göre bunlardan birini seçecektir.
- Her görünüm, JSP sayfası kapsamındadır. Görünümlerde, özellikle de form görünümlerinde, bazen Struts'a özgü bir etiket kütüphanesinin kullanıldığını göreceğiz.
Form görünümlerine karşılık gelen Javabean sınıflarının yazılması
Formları işlemekle görevli Action sınıflarının yazılması
Gerekirse iş mantığı veya veri erişim sınıflarının yazılması

1.4.2. STRUTS geliştirme araçları

STRUTS projesi, Apache Yazılım Vakfı'nın projelerinden biridir. Bu projelerin birçoğu Jakarta adı altında bir araya getirilmiştir ve URL http://jakarta.apache.org adresinde bulunabilir:

Bu sayfayı okumanız tavsiye edilir. Java geliştiricileri için ilgi çekici birçok proje bulunmaktadır. Yukarıdaki Struts bağlantısını takip edersek, projenin ana sayfasına ulaşırız:

Burada da ana sayfayı okumanız tavsiye edilir. Struts'un Java kütüphanelerini indirmek için yukarıdaki Binaries bağlantısını takip ediyoruz:

Windows kullanıcıları için 1.1.zip bağlantısını, Unix kullanıcıları için ise 1.1.tar.gz bağlantısını kullanacağız (Kasım 2003). 1.1.zip dosyasını açtıktan sonra şu dizin yapısını elde ederiz:

Bu dizin yapısında, STRUTS geliştirme için gerekli olan Java sınıf kütüphaneleri bulunur. Bunlar, .zip dosyalarına benzer olan .jar veya .war dosyaları içindedir. Bu dosyalar aynı yardımcı programlarla açılabilir. Gerekli kütüphanelerin çoğu yukarıdaki lib klasöründedir:

.jar sınıf kütüphanelerinin yanı sıra, XML dosyalarının geçerlilik kurallarını içeren .dtd (Belge Türü Tanımı) dosyaları da bulunur. Bir XML dosyası, içeriğinde bu tür bir DTD dosyasına referans verebilir. XML dosyasının içeriğini analiz eden program (parser olarak adlandırılır), XML dosyasının sözdizimsel olarak doğru olup olmadığını belirlemek için, atıfta bulunulan DTD dosyasında bulunan geçerlilik kurallarını kullanacaktır. Örneğin, struts-config_1_1.dtd dosyası, Struts 1.1 sürümü için struts-config.xml yapılandırma dosyasının oluşturulmasına ilişkin kuralları belirler.

Şimdi, bir Struts uygulamasını Tomcat sunucusunda dağıtmak için Struts dizin yapısındaki çeşitli öğelerin nereye yerleştirilmesi gerektiğini inceleyelim.

1.5. Bir Struts Uygulamasının Dağıtımı

Bir Struts uygulaması, diğer web uygulamaları gibidir. Dolayısıyla, çalıştırıldığı konteynerin dağıtım kurallarına uyar. Burada, strutspersonne adını vereceğimiz bir uygulama, Tomcat 4.x sürümü bir sunucu tarafından çalıştırılacaktır. Ek'te, Tomcat 5.x sürümü için dağıtım yöntemi yer almaktadır. Burada, Tomcat 4.x dağıtım kurallarını takip ediyoruz:

Tomcat’ın server.xml yapılandırma dosyasında strutspersonne bağlamını tanımlıyoruz:

                <Context path="/strutspersonne" docBase="e:/data/serge/web/struts/personne" />

Bu işlem tamamlandıktan sonra, yeni bağlamın dikkate alınması için gerekirse Tomcat'i yeniden başlatıyoruz. URL http://localhost:8080/strutspersonne adresini çağırarak bağlamın geçerliliğini kontrol edebiliriz:

Bir hata sayfası almazsak, bağlam doğrudur.

Strutspersonne bağlamıyla ilişkili fiziksel klasörde, WEB-INF alt klasörünü oluşturuyoruz.
Uygulamanın WEB-INF klasöründe, uygulamanın web.xml yapılandırma dosyasını tanımlıyoruz:

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE web-app
    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
    "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>
    <servlet>
      <servlet-name>action</servlet-name>
    <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
    <init-param>
        <param-name>config</param-name>
      <param-value>/WEB-INF/struts-config.xml</param-value>
    </init-param>
  </servlet>

  <servlet-mapping>
      <servlet-name>action</servlet-name>
    <url-pattern>*.do</url-pattern>
  </servlet-mapping>

</web-app>

Uygulamanın denetleyici (servlet) sınıfı, ActionServlet adlı, Struts'un önceden tanımlanmış bir sınıfıdır. Bu sınıf, struts.jar dosyasında bulunur. Tomcat'in bu sınıfı bulabilmesi için, struts.jar dosyasını, Tomcat'in sınıf ararken taradığı klasörlerden biri olan <tomcat>\common\lib klasörüne yerleştireceğiz. Aslında, <struts>\lib klasöründe bulunan tüm .jar dosyalarını buraya yerleştireceğiz; burada <struts>, Struts dizin yapısının kök klasörüdür.

Ayrıca, <struts>\contrib\struts-el\lib dizininde bulunan struts-el.jar ve jstl.jar dosyalarını da buraya yerleştireceğiz:

Burada web sunucusuna erişimimiz var. Ancak bu her zaman böyle olmayabilir. Kendimizin yönetmediği bir web konteynerine bir web/Java uygulaması dağıtırsak, uygulamanın ihtiyaç duyduğu tüm kütüphaneleri beraberinde getirmesi tercih edilir. Bu durumda, bu kütüphaneler, oluşturulması gereken WEB-INF/lib klasörüne yerleştirilmelidir.
Kontrolörün, normalde web.xml ile aynı klasörde bulunan struts-config.xml dosyasında bulunan belirli bilgilere ihtiyaç duyduğunu belirtmiştik. Aslında bu dosyanın adı yapılandırılabilir. Bu adı belirleyen, yukarıdaki config parametresidir.
<servlet-mapping> etiketi, denetleyicinin .do son ekiyle biten tüm URL dosyaları aracılığıyla erişileceğini belirtir. Bu eşleştirme, Struts tarafından zorunlu kılınmaktadır. Bu URL dosyaları daha sonra denetleyici tarafından filtrelenecek ve denetleyici, yalnızca kendi yapılandırma dosyasında (struts-config.xml) bildirilen URL dosyalarını kabul edecektir.

Şu an için web.xml dosyamız yeterlidir.

strutspersonne uygulamasından URL /main.do'i talep edeceğiz. Önceki web.xml dosyasına göre, bu URL dosyası org.apache.struts.action servletine iletilecektir. ActionServlet sınıfı örneklenecek ve init yöntemi çağrılacaktır. Bu yöntem, config parametresiyle tanımlanan yapılandırma dosyasını okumaya çalışır. Dolayısıyla bu dosyanın mevcut olması gerekir. Aşağıdaki struts-config.xml dosyasını oluşturuyoruz:

<?xml version="1.0" encoding="ISO-8859-1" ?>

<!DOCTYPE struts-config PUBLIC
          "-//Apache Software Foundation//DTD Struts Configuration 1.1//EN"
          "http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">

<struts-config>
    <action-mappings>
      <action
          path="/main"
          parameter="/main.html"
          type="org.apache.struts.actions.ForwardAction"
      />
    </action-mappings>
</struts-config>

DTD dosyasının struts-config.xml dosyasındaki dosya ile aynı olmadığına dikkat edelim; bu da, bu dosyaların aynı yapıya sahip olmadıklarını gösterir. Denetleyicinin yönetmesi gereken her URL dosyası için bir <action> etiketi tanımlamamız gerekir. Bu etiket, denetleyiciye bu URL dosyası istendiğinde ne yapması gerektiğini belirtmek için kullanılır. Burada şu öğeleri belirtiriz:

path="/main": <action> etiketiyle yapılandırılan URL'in adını tanımlar. .do son eki varsayılan olarak eklenir.
type="org.apache.struts.actions.ForwardAction": isteği işleyecek Action sınıfının adını tanımlar. Burada, Struts'ta önceden tanımlanmış bir Action sınıfı kullanıyoruz. Bu sınıf kendi başına hiçbir işlem yapmaz ve istemcinin isteğini parameter özniteliğinde belirtilen URL'e iletir.
parameter="/main.html": İsteğin iletilmesi gereken URL'in adı. Burada statik bir HTML dosyası söz konusudur.

Özetle, kullanıcı URL /main.do dosyasını talep ettiğinde, URL /main.html dosyasını alacaktır.

main.html dosyası şu şekilde olacaktır:

<html>
    <head>
      <title>Application strutspersonne</title>
  </head>
  <body>
      Application strutspersonne active ....
  </body>
</html>

Bu dosya, strutspersonne/vues uygulama klasörüne yerleştirilir:

Bunu doğrudan URL http://localhost:8080/strutspersonne/main.html ile talep edebilirsiniz:

Burada, uygulamanın Struts denetleyicisi devreye girmedi; çünkü bu denetleyici yalnızca *.do türündeki URL dosyası talep edildiğinde devreye girer. Oysa burada URL /vues/main.html dosyası talep edildi.

Daha önce oluşturulan struts-config.xml dosyası, web.xml dosyasıyla aynı WEB-INF klasörüne yerleştirilmelidir:

Şimdi, gerekirse Tomcat'i yeniden başlattıktan sonra URL /main.do dosyasını çağırarak strutspersonne uygulamasının denetleyicisinin düzgün çalışıp çalışmadığını kontrol edeceğiz.

Burada, *.do türünde bir URL talebinde bulunduğumuz için Struts denetleyicisi devreye girdi. Beklediğimiz sayfayı (main.html) aldık. Böylece uygulamamızın işleyişinin temel unsurlarına sahibiz: strutspersonne bağlamı, web.xml ve struts-config.xml yapılandırma dosyaları, Struts kütüphaneleri.

Peki, /toto.do türünde bir URL isteseydik ne olurdu? strutspersonne uygulamasının web.xml dosyasına göre, bu durumda işlemi gerçekleştirmek üzere Struts denetleyicisi çağrılır. Kontrolör, struts-config.html yapılandırma dosyasını inceler ve /toto için herhangi bir yapılandırma bulamaz. Peki ne yapar? Şunu deneyelim:

Bir hata sayfası alıyoruz, bu normal görünüyor. Artık bir uygulama yazmaya başlayabiliriz.