1. اطلاعات عمومی

نسخه PDF سند در |ICI| موجود است.

1.1. اهداف

هدف در اینجا بررسی روشی برای توسعه به نام STRUTS است. جاکارتا استراژ (Jakarta Struts) پروژه‌ای از بنیاد نرم‌افزار آپاچی (Apache Software Foundation) (www.apache.org) است که هدف آن ارائه یک چارچوب استاندارد برای توسعه برنامه‌های وب جاوا مطابق با معماری موسوم به MVC (مدل-نما-کنترل‌کننده) است.

1.2. مدل MVC

مدل MVC در پی تفکیک لایه‌های ارائه، پردازش و دسترسی به داده‌ها است. یک برنامه وب که از این مدل پیروی می‌کند، به شکل زیر ساختار خواهد داشت:

چنین معماری به عنوان معماری سه‌لایه یا سه‌سطحی شناخته می‌شود:

رابط کاربری V (ویو) است
منطق برنامه C (کنترل‌کننده) است
منابع داده، M (مدل) هستند

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

هنگام تلاش برای پیاده‌سازی این مدل با استفاده از سرولت‌ها و صفحات JSP، معماری زیر حاصل می‌شود:

در داخل بلوک [Logique Applicative]، می‌توانیم تمایز قائل شویم

سرولتی که به‌عنوان نقطهٔ ورود برنامه عمل می‌کند و همچنین به‌عنوان کنترل‌کننده شناخته می‌شود
بلوک [Classes métier] که شامل کلاس‌های جاوا مورد نیاز برای منطق برنامه است.
بلوک [Classes d'accès aux données]، که حاوی کلاس‌های جاوا مورد نیاز برای بازیابی داده‌های لازم برای سرولت است، که اغلب داده‌های پایدار هستند (BD، فایل‌ها، سرویس WEB و غیره).
بلوک صفحه JSP که نماهای برنامه را تشکیل می‌دهد.

1.3. یک رویکرد توسعه MVC با استفاده از سرولت‌ها و صفحات JSP

ما یک روش‌شناسی برای توسعهٔ برنامه‌های وب جاوا مطابق با مدل MVC که در بالا توضیح داده شد، تعریف کرده‌ایم. در اینجا آن را خلاصه می‌کنیم.

ما با تعریف تمامی نماهای برنامه شروع می‌کنیم. این‌ها صفحات وبی هستند که به کاربر ارائه می‌شوند. بنابراین هنگام طراحی نماها دیدگاه کاربر را در نظر می‌گیریم. سه نوع نما وجود دارد:
- فرم ورودی، که برای دریافت اطلاعات از کاربر طراحی شده است. این معمولاً شامل دکمه‌ای برای ارسال اطلاعات وارد شده به سرور است.
- صفحه پاسخ، که تنها برای ارائه اطلاعات به کاربر است. این صفحه اغلب شامل پیوندی است که به کاربر امکان می‌دهد با رفتن به صفحه دیگر، به استفاده از برنامه ادامه دهد.
- صفحه ترکیبی: سرویس‌لت یک صفحه حاوی اطلاعاتی را که تولید کرده است برای کلاینت ارسال می‌کند. همین صفحه توسط کلاینت برای ارائه اطلاعات بیشتر به سرویس‌لت استفاده خواهد شد.

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

ما می‌توانیم ورودی/خروجی هر نما را به‌صورت نموداری نمایش دهیم

ورودی‌ها داده‌هایی هستند که سرولت باید به صفحه JSP، چه در درخواست و چه در جلسه، ارائه دهد.
خروجی‌ها داده‌هایی هستند که صفحه JSP باید در اختیار سرولت قرار دهد. این داده‌ها بخشی از یک فرم HTML را تشکیل می‌دهند و سرولت آن‌ها را از طریق عملیاتی از نوع request.getparameter(...) بازیابی خواهد کرد.

ما کد Java/JSP را برای هر نما خواهیم نوشت. این کد اغلب به شکل زیر خواهد بود:

<%@ page ... %>    // واردات کلاس‌های پرکاربردترین
<%!
     //متغیرهای نمونهٔ صفحهٔ JSP (=جهانی)
     // فقط در صورتی لازم است که صفحه JSP متدهایی داشته باشد که متغیرها را به اشتراک می‌گذارند (ندرتاً)     
    ...    
%>
<%
     //بازیابی داده‌های ارسال‌شده توسط سرولت
     // یا در درخواست یا در جلسه
    ...
%>

<html>
...
         // در اینجا، هدف ما به حداقل رساندن کد جاوا خواهد بود
</html>

اکنون می‌توانیم به تست‌های اولیه بپردازیم. روش استقرار توضیح‌داده‌شده در زیر مختص سرور Tomcat است:

محتوای application context باید در فایل server.xml در Tomcat ایجاد شود. می‌توانیم با آزمایش این محتوا شروع کنیم. بگذارید C این محتوا و DC پوشهٔ مرتبط با آن باشد. یک فایل ایستا با نام test.html ایجاد کرده و آن را در پوشه DC قرار می‌دهیم. پس از راه‌اندازی تام‌کت، با استفاده از یک مرورگر، http://localhost:8080/DC/test.html را درخواست خواهیم کرد.
هر صفحه JSP قابل آزمایش است. اگر صفحه‌ای JSP با formulaire.jsp فراخوانی شود، ما از طریق مرورگر، URL http://localhost:8080/DC/formulaire.jsp را درخواست خواهیم کرد. صفحه JSP انتظار مقادیری را از سرولتی که آن را فراخوانی می‌کند دارد. در اینجا ما آن را مستقیماً فراخوانی می‌کنیم، بنابراین پارامترهای مورد انتظار را دریافت نخواهد کرد. برای اطمینان از اینکه تست هنوز هم امکان‌پذیر است، پارامترهای مورد انتظار را به‌صورت دستی با ثابت‌ها در صفحه JSP مقداردهی اولیه خواهیم کرد. این تست‌های اولیه به ما امکان می‌دهند تا صحت نحوی صفحات JSP را تأیید کنیم.

سپس کد سرولت را می‌نویسیم. این سرولت دو متد متمایز دارد:

متد `init`، که برای انجام کار زیر استفاده می‌شود:
- بازیابی پارامترهای پیکربندی برنامه از فایل web.xml آن
- ایجاد نمونه‌هایی از کلاس‌های کسب‌وکار که ممکن است بعداً به آن‌ها نیاز داشته باشد
- پردازش هر فهرستی از خطاهای راه‌اندازی که به کاربران آیندهٔ برنامه بازگردانده خواهد شد. این پردازش خطا ممکن است حتی شامل ارسال ایمیل به مدیر برنامه برای آگاه‌سازی او از یک نقص عملکرد باشد.
متد doGet یا doPost، بسته به نحوه دریافت پارامترها توسط سرولت از کلاینت‌ها. اگر سرولت چندین فرم را مدیریت می‌کند، توصیه می‌شود که هر یک از آن‌ها اطلاعاتی را ارسال کنند که به طور منحصربه‌فرد آن‌ها را شناسایی کند. این کار را می‌توان با استفاده از یک ویژگی پنهان در فرم، مانند <input type="hidden" name="action" value="..."> انجام داد. سرولت می‌تواند با خواندن مقدار این پارامتر شروع کرده و سپس پردازش درخواست را به یک متد خصوصی داخلی که مسئول رسیدگی به این نوع درخواست است، واگذار کند.
منطق کسب‌وکار باید در داخل سرولت به حداقل ممکن کاهش یابد. این سرولت برای این منظور طراحی نشده است. سرولت مانند یک رهبر تیم (کنترل‌کننده) عمل می‌کند که درخواست‌ها را از مشتریان خود (مشتریان وب) دریافت کرده و آنها را توسط مناسب‌ترین واحدها (کلاس‌های کسب‌وکار) اجرا می‌سازد. هنگام نوشتن سرولت، شما رابط کلاس‌های کسب‌وکار را که باید ایجاد شوند (سازنده‌ها، متدها) تعریف خواهید کرد. این در صورتی اعمال می‌شود که این کلاس‌های کسب‌وکار نیاز به ایجاد شدن داشته باشند. اگر آن‌ها از قبل وجود داشته باشند، سرولت باید خود را با رابط موجود تطبیق دهد.
کد سرولت کامپایل خواهد شد.

ما اسکلت کلاس‌های کسب‌وکار مورد نیاز سرولت را خواهیم نوشت. برای مثال، اگر سرولت از یک شیء از نوع proxyArticles استفاده کند و این کلاس باید متدی به نام getCodes داشته باشد که یک لیست (ArrayList) از رشته‌های کاراکتری را بازگرداند، در ابتدا می‌توانیم به سادگی بنویسیم:

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

سپس می‌توانیم به تست سرولت بپردازیم.

فایل پیکربندی برنامه، web.xml، باید ایجاد شود. این فایل باید شامل تمام اطلاعات مورد نیاز متد init سرولت (<init-param>) باشد. علاوه بر این، ما URL را که از طریق آن به سرولت اصلی دسترسی پیدا می‌شود (<servlet-mapping>) تنظیم می‌کنیم.
تمام کلاس‌های لازم (سرولت، کلاس‌های کسب‌وکار) در WEB-INF/classes قرار می‌گیرند.
تمام کتابخانه‌های کلاسی (.jar) لازم در WEB-INF/lib قرار می‌گیرند. این کتابخانه‌ها ممکن است حاوی کلاس‌های کسب‌وکار، درایورهای JDBC و غیره باشند.
ویوهای JSP در دایرکتوری ریشهٔ برنامه یا در یک پوشهٔ اختصاصی قرار می‌گیرند. همین امر در مورد سایر منابع (HTML، تصاویر، صدا، ویدئو و غیره) نیز صدق می‌کند.
پس از انجام این کار، برنامه آزمایش شده و خطاهای اولیه اصلاح می‌شوند. در پایان این فاز، معماری برنامه عملیاتی است. این فاز آزمایشی می‌تواند دشوار باشد، زیرا هیچ ابزار عیب‌یابی با Tomcat در دسترس نیست. برای این کار، Tomcat باید در یک ابزار توسعه (مانند JBuilder Developer، Sun One Studio و غیره) یکپارچه شود. می‌توانیم از دستورهای System.out.println("....") که در پنجره Tomcat خروجی می‌گیرند، استفاده کنیم. اولین چیزی که باید بررسی شود این است که متد init با موفقیت تمام داده‌ها را از فایل web.xml بازیابی کند. برای این کار، می‌توانید مقادیر این پارامترها را در کنسول Tomcat خروجی بگیرید. به همین ترتیب، بررسی کنید که متدهای doGet و doPost پارامترها را از فرم‌های مختلف HTML در برنامه به درستی بازیابی می‌کنند.

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

1.4. رویکرد توسعه STRUTS

سازندگان متدولوژی STRUTS در پی تعریف یک روش توسعه استاندارد بودند که با معماری MVC برای برنامه‌های وب نوشته شده به زبان جاوا مطابقت داشته باشد. پروژه STRUTS دو جنبه دارد:

روش توسعه. خواهیم دید که این روش تا حد زیادی مشابه روشی است که پیش‌تر برای servletها و صفحات JSP توصیف شد.
ابزارهایی که امکان اجرای این روش توسعه را برای ما فراهم می‌کنند. این‌ها کتابخانه‌های کلاس جاوا هستند که در وب‌سایت بنیاد آپاچی (www.apache.org) در دسترس قرار دارند.

1.4.1. روش توسعه

معماری MVC که توسط STRUTS استفاده می‌شود به شرح زیر است:

کنترلر قلب برنامه است. تمام درخواست‌های کلاینت از آن عبور می‌کنند. این یک سرولت عمومی است که توسط STRUTS ارائه می‌شود. در برخی موارد، ممکن است لازم باشد آن را گسترش داد. برای موارد ساده، این کار ضروری نیست. این سرولت عمومی اطلاعات مورد نیاز خود را از فایلی با نام معمول struts-config.xml بازیابی می‌کند.
اگر درخواست مشتری شامل پارامترهای فرم باشد، این پارامترها در یک شی Bean قرار داده می‌شوند. یک کلاس زمانی از نوع Bean محسوب می‌شود که از قوانین ساختاری خاصی پیروی کند، که ما بعداً به تفصیل به آنها خواهیم پرداخت. شی‌های Bean که به این روش ایجاد می‌شوند، به مرور زمان در جلسه (session) یا درخواست (request) مشتری ذخیره می‌شوند. این قابلیت قابل پیکربندی است. اگر قبلاً ایجاد شده باشند، نیازی به ایجاد مجدد آنها نیست.
در فایل پیکربندی struts-config.html، اطلاعات خاصی با هر URL که باید توسط یک برنامه پردازش شود مرتبط می‌شود (و بنابراین با یک نمای JSP که می‌تواند مستقیماً درخواست شود مطابقت ندارد):
- نام کلاس Action مسئول رسیدگی به درخواست. در اینجا نیز، شیء Action نمونه‌سازی‌شده ممکن است در جلسه (session) یا درخواست (request) نگهداری شود.
- اگر URL درخواستی پارامتریک باشد (مانند زمانی که یک فرم به کنترلر ارسال می‌شود)، نام بین (bean) مسئول ذخیره داده‌های فرم مشخص می‌شود.
کنترل‌کننده، با در دست داشتن این اطلاعات که توسط فایل پیکربندی آن فراهم شده است، هنگام دریافت درخواستی برای URL از یک کلاینت، می‌تواند تشخیص دهد که آیا نیاز به ایجاد یک بین (bean) وجود دارد و اگر وجود دارد، کدام یک. پس از ایجاد نمونه، بین می‌تواند بررسی کند که آیا داده‌های ذخیره‌شده توسط آن - که از فرم منشأ گرفته است - معتبر هستند یا خیر. یک متد در بین با نام `validate` به طور خودکار توسط کنترلر فراخوانی می‌شود. بین توسط توسعه‌دهنده ایجاد می‌شود، بنابراین توسعه‌دهنده کد بررسی اعتبار داده‌های فرم را در داخل متد `validate` قرار می‌دهد. اگر داده‌ها نامعتبر تشخیص داده شوند، کنترلر به کار خود ادامه نخواهد داد. کنترل را به یک ویو واگذار می‌کند که نام آن را در فایل پیکربندی خود پیدا می‌کند. در این صورت تعامل کامل می‌شود. شایان ذکر است که توسعه‌دهنده می‌تواند مشخص کند که فرم نباید اعتبارسنجی شود. این کار نیز در فایل struts-config.html انجام می‌شود. در این صورت، کنترلر متد `validate` بیان را فراخوانی نمی‌کند.
اگر داده‌های بین صحیح باشند، یا اگر نیازی به اعتبارسنجی نباشد، یا اگر بین وجود نداشته باشد، کنترلر کنترل را به شیء از نوع Action که با URL مرتبط است، واگذار می‌کند. این کار را با فراخوانی متد `execute` این شیء انجام می‌دهد که در آن ارجاع به بین (bean) ساخته‌شده را به آن پاس می‌دهد. در اینجا توسعه‌دهنده وظایف لازم را انجام می‌دهد: ممکن است نیاز باشد که کلاس‌های منطق کسب‌وکار یا کلاس‌های دسترسی به داده‌ها را فراخوانی کند. در پایان پردازش، شیء Action نام ویوی (view) را که باید در پاسخ به کلاینت ارسال کند، به کنترلر بازمی‌گرداند.
کنترل‌کننده این پاسخ را ارسال می‌کند. تعامل با مشتری کامل می‌شود.

روش‌شناسی توسعه STRUTS در حال شکل‌گیری است:

تعریف نماها. تفاوتی بین نماهایی که فرم هستند و آنهایی که نیستند قائل می‌شوند.
- هر ویوی فرم منجر به یک تعریف در فایل struts-config.xml می‌شود. اطلاعات زیر در آنجا تعریف شده است:
  - نام کلاس Bean که حاوی داده‌های فرم خواهد بود، و همچنین نشانه‌ای مبنی بر اینکه آیا داده‌ها نیاز به اعتبارسنجی دارند یا خیر. اگر نیاز به اعتبارسنجی داشته باشند و نامعتبر تشخیص داده شوند، ویوی که در این حالت باید برای کلاینت ارسال شود باید مشخص گردد.
  - نام کلاس Action مسئول پردازش فرم.
  - نام تمام ویوهایی که ممکن است پس از پردازش درخواست به کلاینت بازگردانده شوند. کلاس Action بسته به نتیجه پردازش، یکی از آنها را انتخاب خواهد کرد.
- هر ویو با یک صفحه JSP مطابقت دارد. خواهیم دید که در ویوها—به‌ویژه ویوهای فرم—گاهی اوقات از کتابخانه‌ای از تگ‌های مخصوص Struts استفاده می‌شود.
نوشتن کلاس‌های JavaBean متناظر با ویوهای فرم
نوشتن کلاس‌های Action مسئول پردازش فرم‌ها
نوشتن هرگونه منطق کسب‌وکار یا کلاس‌های دسترسی به داده‌ها

1.4.2. ابزارهای توسعه STRUTS

پروژه STRUTS یکی از پروژه‌های بنیاد نرم‌افزار آپاچی است. چندین مورد از این پروژه‌ها تحت نام جاکارتا گروه‌بندی شده‌اند و در URL http://jakarta.apache.org در دسترس هستند:

خواندن این صفحه توصیه می‌شود. بسیاری از این پروژه‌ها برای توسعه‌دهندگان جاوا جالب هستند. اگر لینک Struts بالا را دنبال کنیم، به صفحهٔ اصلی پروژه می‌رسیم:

در اینجا نیز توصیه می‌شود صفحهٔ اصلی را مطالعه کنید. برای دانلود کتابخانه‌های جاوا Struts، پیوند «Binaries» در بالا را دنبال کنید:

برای کاربران ویندوز، از لینک 1.1.zip و برای کاربران یونیکس (نوامبر ۲۰۰۳) از لینک 1.1.tar.gz استفاده کنید. پس از خارج کردن فایل 1.1.zip، ساختار دایرکتوری زیر باقی می‌ماند:

این ساختار دایرکتوری شامل کتابخانه‌های کلاس جاوا مورد نیاز برای توسعه است: STRUTS. این کتابخانه‌ها در فایل‌های .jar یا .war قرار دارند که مشابه فایل‌های .zip هستند. می‌توان آن‌ها را با استفاده از همان ابزارها باز کرد. بیشتر کتابخانه‌های مورد نیاز در پوشه «lib» که در بالا ذکر شد، قرار دارند:

علاوه بر کتابخانه‌های کلاسی .jar، فایل‌های .dtd (تعریف نوع سند) حاوی قواعد اعتبارسنجی برای فایل‌های XML نیز وجود دارند. یک فایل XML ممکن است در محتوای خود به چنین فایل DTD اشاره کند. برنامه‌ای (که به آن پارسر گفته می‌شود) که محتوای فایل XML را تحلیل می‌کند، از قواعد اعتبارسنجی موجود در فایل مرجع DTD برای تعیین صحت دستوری فایل XML استفاده خواهد کرد. برای مثال، فایل struts-config_1_1.dtd قواعد ساخت فایل پیکربندی struts-config.xml را برای نسخهٔ ۱.۱ Struts تعریف می‌کند.

اکنون بیایید ببینیم که برای استقرار یک برنامه Struts روی سرور Tomcat، عناصر مختلف ساختار دایرکتوری Struts را در کجا قرار دهیم.

1.5. راه‌اندازی یک برنامه Struts

یک برنامه Struts مانند هر برنامه وب دیگری است. بنابراین از قوانین استقرار کانتینری که در آن اجرا می‌شود پیروی می‌کند. در اینجا، یک برنامه – که آن را **strutspersonne** می‌نامیم – بر روی سرور Tomcat نسخه 4.x اجرا خواهد شد. رویه استقرار برای Tomcat نسخه 5.x در ضمیمه ارائه شده است. در اینجا، ما از قوانین استقرار Tomcat که در 4.x تشریح شده است، پیروی می‌کنیم:

ما کانکست `strutspersonne` را در فایل پیکربندی Tomcat تعریف می‌کنیم server.xml:

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

پس از انجام این کار، در صورت لزوم تام‌کت را مجدداً راه‌اندازی می‌کنیم تا زمینه جدید را تشخیص دهد. می‌توانیم با درخواست کردن http://localhost:8080/strutspersonne URL بررسی کنیم که زمینه معتبر است:

اگر صفحه خطا دریافت نکنیم، زمینه صحیح است.

در پوشه فیزیکی مرتبط با کانکست strutspersonne، زیرپوشه WEB-INF را ایجاد می‌کنیم.
در پوشه WEB-INF برنامه، فایل پیکربندی برنامه web.xml را تعریف می‌کنیم:

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

کلاس کنترل‌کننده (سرولت) برنامه یک کلاس از پیش تعریف‌شده Struts به نام ActionServlet است. این کلاس در فایل struts.jar قرار دارد. برای اطمینان از اینکه تام‌کت بتواند این کلاس را پیدا کند، فایل struts.jar را در پوشه <tomcat>\common\lib قرار می‌دهیم، که یکی از پوشه‌هایی است که تام‌کت هنگام جستجو برای کلاس‌ها بررسی می‌کند. در واقع، ما تمام فایل‌های .jar یافت‌شده در پوشه <struts>\lib را در آنجا قرار خواهیم داد، که در آن <struts> پوشه ریشه ساختار دایرکتوری Struts است.

ما همچنین فایل‌های struts-el.jar و jstl.jar را که در <struts>\contrib\struts-el\lib قرار دارند، قرار خواهیم داد:

در اینجا ما به سرور وب دسترسی داریم. این همیشه صادق نیست. اگر یک برنامه وب/جاوا را در یک کانتینر وب که خودتان مدیریت نمی‌کنید مستقر می‌کنید، ترجیحاً بهتر است که برنامه تمام کتابخانه‌های مورد نیاز خود را همراه داشته باشد. این کتابخانه‌ها باید در پوشه WEB-INF/lib قرار داده شوند، پوشه‌ای که باید خودتان ایجاد کنید.
ما اشاره کرده‌ایم که کنترلر به مقدار مشخصی اطلاعات نیاز دارد که معمولاً آن را در فایلی به نام struts-config.xml که در همان پوشه web.xml قرار دارد، پیدا می‌کند. در واقع، نام این فایل قابل پیکربندی است. پارامتر 'config' که در بالا نشان داده شده است، این نام را تعیین می‌کند.
تگ <servlet-mapping> مشخص می‌کند که به کنترلر از طریق تمام فایل‌های URL که با پسوند .do پایان می‌یابند، دسترسی پیدا خواهد شد. این نگاشت توسط Struts الزامی است. سپس این فایل‌های URL توسط کنترلر فیلتر می‌شوند، که تنها فایل‌های URL را که در فایل پیکربندی آن، struts-config.xml، اعلام شده‌اند، می‌پذیرد.

فعلاً فایل web.xml ما کافی است.

ما URL /main.do را از برنامه strutspersonne درخواست خواهیم کرد. بر اساس فایل قبلی web.xml، این URL بنابراین به servlet org.apache.struts.action ارسال خواهد شد. کلاس ActionServlet instantiate شده و متد init آن فراخوانی می‌شود. این متد تلاش می‌کند فایل پیکربندی مشخص‌شده توسط پارامتر config را بخواند. بنابراین این فایل باید وجود داشته باشد. ما فایل زیر struts-config.xml را ایجاد می‌کنیم:

<?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 از struts-config.xml با فایل web.xml یکسان نیست، که نشان می‌دهد ساختار یکسانی ندارند. برای هر URL که کنترل‌کننده باید آن را مدیریت کند، باید یک تگ <action> تعریف کنیم. این تگ به کنترل‌کننده می‌گوید که وقتی برای این URL درخواست داده می‌شود، چه کاری انجام دهد. در اینجا، موارد زیر را مشخص می‌کنیم:

path="/main": نام URL پیکربندی‌شده توسط تگ <action> را مشخص می‌کند. پسوند .do به‌طور ضمنی در نظر گرفته می‌شود.
type="org.apache.struts.actions.ForwardAction": نام کلاس Action را که باید درخواست را مدیریت کند، تعریف می‌کند. در اینجا، ما از یک کلاس Action از پیش تعریف‌شده در Struts استفاده می‌کنیم. این کلاس به خودی خود کاری انجام نمی‌دهد و درخواست کلاینت را به URL مشخص‌شده در ویژگی parameter فوروارد می‌کند.
parameter="/main.html": نام URL است که درخواست به آن ارجاع داده می‌شود. در اینجا، این یک فایل HTML ایستا است.

خلاصه اینکه، وقتی کاربر URL /main.do را درخواست می‌کند، URL /main.html را دریافت خواهد کرد.

فایل main.html به شرح زیر خواهد بود:

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

این فایل در پوشهٔ برنامهٔ strutspersonne/vues قرار دارد:

شما می‌توانید مستقیماً با استفاده از URLhttp://localhost:8080/strutspersonne/main.html درخواست دهید:

در این مورد، کنترل‌کننده Struts برنامه مداخله نکرد، زیرا تنها زمانی مداخله می‌کند که درخواستی برای URL از نوع *.do ارسال شود. با این حال، در این مورد، درخواستی برای URL /vues/main.html ارسال شده بود.

فایل struts-config.xml که قبلاً ایجاد شده است باید در همان پوشه WEB-INF که فایل web.xml در آن قرار دارد، قرار داده شود:

اکنون با درخواست فایل‌های URL /main.do پس از راه‌اندازی مجدد Tomcat، در صورت لزوم، بررسی می‌کنیم که کنترل‌کننده application strutspersonne به درستی کار می‌کند.

در اینجا، کنترلر Struts وارد عمل شده است زیرا ما یک URL از نوع *.do را درخواست کردیم. ما در واقع صفحه مورد انتظار (main.html) را دریافت کرده‌ایم. بنابراین ما اجزای اصلی عملکرد برنامهٔ خود را داریم: کانکست strutspersonne، فایل‌های پیکربندی web.xml و struts-config.xml، و کتابخانه‌های Struts.

اگر ما یک URL از نوع /toto.do را درخواست می‌کردیم چه اتفاقی می‌افتاد؟ طبق فایل web.xml در برنامه strutspersonne، کنترلر Struts برای پردازش آن فراخوانی می‌شود. سپس فایل پیکربندی خود struts-config.html را بررسی می‌کند و هیچ پیکربندی‌ای برای URL /toto پیدا نمی‌کند. در این صورت چه می‌کند؟ بیایید امتحان کنیم:

یک صفحهٔ خطا دریافت می‌کنیم که طبیعی به نظر می‌رسد. اکنون می‌توانیم به نوشتن یک برنامه بپردازیم.