ہیلو ورلڈ سے لے کر اسپرنگ ویب ایم وی سی تک اور سرولیٹس کا اس سے کیا تعلق ہے۔

تعارف

جیسا کہ ہم جانتے ہیں، جاوا کی کامیابی واضح طور پر سافٹ ویئر کے ارتقاء کی بدولت آئی ہے جو نیٹ ورک سے جڑنے کی کوشش کرتا ہے۔ لہذا، ہم عام کنسول ایپلیکیشن " ہیلو ورلڈ " کو بنیاد کے طور پر لیں گے اور سمجھیں گے کہ کنسول ایپلیکیشن سے نیٹ ورک ایپلیکیشن بننے کے لیے اسے کیا ضرورت ہے۔ لہذا، پہلے آپ کو جاوا پروجیکٹ بنانے کی ضرورت ہے۔ پروگرامرز سست لوگ ہیں۔ پراگیتہاسک زمانے میں، جب کچھ میمتھ کا شکار کر رہے تھے، دوسروں نے بیٹھ کر کوشش کی کہ جاوا لائبریریوں اور ڈائریکٹری ڈھانچے کی پوری قسم میں الجھن میں نہ پڑے۔ تاکہ ڈویلپر ایپلی کیشن بنانے کے عمل کو کنٹرول کر سکے، تاکہ وہ صرف یہ لکھ سکے کہ "مجھے فلاں اور فلاں ورژن 2 کی لائبریری چاہیے،" وہ خصوصی ٹولز - بلڈ سسٹمز کے ساتھ آئے۔ دو سب سے مشہور ماون اور گریڈل ہیں ۔ اس مضمون کے لیے ہم Gradle استعمال کریں گے۔ اگر پہلے ہمیں ڈائرکٹری کا ڈھانچہ خود بنانا ہوتا، اب گریڈل، Gradle Init پلگ ان کا استعمال کرتے ہوئے، ہمیں جاوا پروجیکٹ بنانے کی اجازت دیتا ہے جس میں ڈائریکٹری ڈھانچہ اور ایک کمانڈ میں بیس مین کلاس ہے: gradle init --type java-application یہ کمانڈ اس کے لیے ابتداء (init) انجام دیتی ہے۔ ہمیں کنسول ہیلو ورلڈ کے ساتھ جاوا ایپلی کیشن (جاوا ایپلی کیشن)۔ تکمیل کے بعد، ایک فائل ڈائریکٹری میں ظاہر ہوگی - build.gradle ۔ یہ ہماری تعمیر کی اسکرپٹ ہے - یعنی ایپلیکیشن بنانے کے لیے ایک مخصوص اسکرپٹ جس میں اس کی تفصیل ہے کہ اس کے لیے کن اقدامات کرنے کی ضرورت ہے۔ آئیے اسے کھولیں اور اس میں لائن شامل کریں: jar.baseName = 'webproject' Gradle آپ کو ایک پروجیکٹ پر مختلف اعمال انجام دینے کی اجازت دیتا ہے اور ان اعمال کو tasks کہا جاتا ہے ۔ کمانڈ (ٹاسک) پر عمل کرنے سے /build/libsgradle build ڈائریکٹری میں ایک JAR فائل بن جائے گی ۔ اور، جیسا کہ آپ نے اندازہ لگایا، اب اس کا نام ہوگا webproject.jar ۔ لیکن اگر ہم عمل کرتے ہیں تو ہمیں ایک غلطی ملے گی: ۔ اس کی وجہ یہ ہے کہ جاوا ایپلیکیشن کے لیے آپ کو مینی فیسٹ منسلک کرنے کی ضرورت ہے - یہ اس بات کی تفصیل ہے کہ ایپلیکیشن کے ساتھ کیسے کام کیا جائے، اسے کیسے محسوس کیا جائے۔ پھر JVM، جو جاوا ایپلیکیشن کو عمل میں لائے گا، جان لے گا کہ پروگرام اور دیگر معلومات (مثال کے طور پر، کلاس پاتھ) میں کون سی کلاس انٹری پوائنٹ ہے۔ اگر ہم بلڈ اسکرپٹ کے مشمولات پر گہری نظر ڈالیں تو ہم پلگ ان کو منسلک ہوتے دیکھیں گے۔ مثال کے طور پر: اگر ہم گریڈل جاوا پلگ ان صفحہ پر جائیں تو ہم دیکھ سکتے ہیں کہ ہم مینی فیسٹ کو ترتیب دے سکتے ہیں: java -jar ./build/libs/webproject.jarno main manifest attributeapply plugin: 'java'

jar {
    manifest {
        attributes 'Main-Class': 'App'
    }
}

مرکزی کلاس، پروگرام کا انٹری پوائنٹ، ہمارے لیے گریڈل انیٹ پلگ ان کے ذریعے تیار کیا گیا تھا۔ اور یہاں تک کہ یہ mainClassName پیرامیٹر میں بھی بیان کیا گیا ہے۔ لیکن یہ ہمارے لیے مناسب نہیں تھا، کیونکہ... اس ترتیب سے مراد ایک اور پلگ ان ہے، گریڈل ایپلیکیشن پلگ ان ۔ لہذا، ہمارے پاس جاوا ایپلی کیشن ہے جو سکرین پر ہیلو ورلڈ دکھاتی ہے۔ یہ جاوا ایپلیکیشن ایک JAR (جاوا آرکائیو) میں پیک کیا گیا ہے۔ یہ سادہ، کنسول پر مبنی ہے، اپ ٹو ڈیٹ نہیں۔ اسے ویب ایپلیکیشن میں کیسے تبدیل کیا جائے؟

سرولیٹ API

جاوا کے نیٹ ورک کے ساتھ کام کرنے کے قابل ہونے کے لیے، Servlet API نامی ایک تصریح قدیم زمانے میں ظاہر ہوئی ۔ یہ وہ تصریح ہے جو کلائنٹ سرور کے تعامل کو بیان کرتی ہے، کلائنٹ سے پیغام وصول کرنا (مثال کے طور پر، ایک براؤزر) اور جواب بھیجنا (مثال کے طور پر، صفحہ کے متن کے ساتھ)۔ قدرتی طور پر، اس کے بعد سے بہت کچھ بدل چکا ہے، لیکن بات یہ ہے کہ جاوا ایپلی کیشن کو ویب ایپلیکیشن بننے کے لیے، Servlet API استعمال کیا جاتا ہے۔ بے بنیاد قیاس آرائیاں نہ کرنے کے لیے، آئیے اسی تصریح کو اٹھاتے ہیں: JSR-000340 JavaTM Servlet 3.1 ۔ سب سے پہلے، ہم " باب 1: جائزہ " میں دلچسپی رکھتے ہیں۔ یہ ان بنیادی تصورات کو بیان کرتا ہے جنہیں ہمیں سمجھنا چاہیے۔ سب سے پہلے، ایک سرولیٹ کیا ہے؟ باب " 1.1 سرولیٹ کیا ہے؟ " کہتا ہے کہ سرولیٹ جاوا کا ایک جزو ہے جس کا انتظام کنٹینر کے ذریعے کیا جاتا ہے اور جو متحرک مواد تیار کرتا ہے۔ جاوا کے دوسرے اجزاء کی طرح، ایک سرولیٹ ایک جاوا کلاس ہے جسے بائیک کوڈ میں مرتب کیا جاتا ہے اور جاوا ٹیکنالوجی کا استعمال کرتے ہوئے ویب سرور میں لوڈ کیا جا سکتا ہے۔ یہ ضروری ہے کہ سرولیٹس ویب کلائنٹ (مثال کے طور پر، ایک براؤزر) کے ساتھ درخواست/جواب کی تمثیل کے فریم ورک کے اندر تعامل کریں، جسے سرولیٹ کنٹینر کے ذریعے لاگو کیا جاتا ہے۔ یہ پتہ چلتا ہے کہ سرولیٹ کسی قسم کے سرولیٹ کنٹینر میں رہتے ہیں۔ یہ کیا ہے؟ باب " 1.2 سرولیٹ کنٹینر کیا ہے؟ " میں کہا گیا ہے کہ سرولیٹ کنٹینر ویب سرور یا ایپلیکیشن سرور کا کچھ حصہ ہے جو نیٹ ورک کی خدمات فراہم کرتا ہے جس کے ذریعے درخواستیں بھیجی جاتی ہیں اور جوابات بھیجے جاتے ہیں۔ یہ بہت ہی سرولیٹ کنٹینر سرولیٹس کے لائف سائیکل کا انتظام کرتا ہے۔ تمام سرولیٹ کنٹینرز کو کم از کم HTTP پروٹوکول کی حمایت کرنے کی ضرورت ہے، لیکن دوسروں کی مدد کر سکتے ہیں۔ مثال کے طور پر، HTTPS. یہ بھی ضروری ہے کہ سرولیٹ کنٹینر اس ماحول پر حفاظت سے متعلق کوئی پابندیاں لگا سکتا ہے جس میں سرولیٹس کو انجام دیا جاتا ہے۔ یہ بھی ضروری ہے کہ " 10.6 ویب ایپلیکیشن آرکائیو فائل " کے مطابق ویب ایپلیکیشن کو WAR (ویب آرکائیو) فائل میں پیک کیا جانا چاہیے۔ یعنی، اب ہمیں اپنے جار اور ایپلیکیشن پلگ ان کو کسی اور چیز کے لیے ہٹانے کی ضرورت ہے۔ اور یہ گریڈل وار پلگ ان ہے ۔ اور jar.baseName کے بجائے war.baseName کی وضاحت کریں کیونکہ چونکہ ہم مزید جار پلگ ان کا استعمال نہیں کرتے، ہم نے مینی فیسٹ سیٹنگز کو بھی ہٹا دیا ہے۔ جب ہم نے JAR لانچ کیا تو جاوا ورچوئل مشین (JVM) کو مینی فیسٹ کے ذریعے بتانے کی ضرورت تھی کہ ہماری درخواست کے ساتھ کیسے کام کرنا ہے۔ کیونکہ جے وی ایم اسے چلا رہی تھی۔ ویب ایپلیکیشن، بظاہر، کسی قسم کے ویب سرور کے ذریعے عمل میں لایا جاتا ہے۔ یہ پتہ چلتا ہے کہ اسے کسی نہ کسی طرح اسے بتانا ہوگا کہ ہماری ویب ایپلیکیشن کے ساتھ کیسے کام کرنا ہے؟ اور یہ پتہ چلتا ہے کہ ہاں۔ ویب ایپلیکیشنز کا اپنا خاص منشور ہوتا ہے۔ اسے Deployment Descriptor کہتے ہیں ۔ ایک پورا حصہ اس کے لیے وقف ہے: " 14. تعیناتی کی وضاحت کرنے والا "۔ ایک اہم حصہ ہے: " باب 10:". یہ اس بارے میں بات کرتا ہے کہ Servlet API کے نقطہ نظر سے ویب ایپلیکیشن کیا ہے۔ مثال کے طور پر، باب " 10.5 ڈائریکٹری ڈھانچہ " میں اس بات کی نشاندہی کی گئی ہے کہ تعیناتی ڈسکرپٹر کہاں ہونا چاہئے: /WEB-INF/web.xmlWEB-INF کو کہاں رکھنا ہے؟ جیسا کہ Gradle WAR پلگ ان میں بتایا گیا ہے، یہ ایک نیا لے آؤٹ شامل کرتا ہے : src/main/webappلہذا، آئیے ایسی ڈائرکٹری بنائیں، اس کے اندر ہم ایک WEB-INF ڈائرکٹری بنائیں گے، اور اس کے اندر ایک web.xml فائل بنائیں گے۔ یہ ضروری ہے کہ ڈائریکٹری اسے WEB-INF کہا جاتا ہے، نہ کہ META-INF! آئیے اسے " 14.5.1 ایک بنیادی مثال " XML مثال سے نقل کرتے ہیں: جیسا کہ ہم دیکھ سکتے ہیں، ایک XML دستاویز کنفیگریشن کے لیے استعمال ہوتی ہے۔ ایک XML دستاویز، درست (درست) مانے جانے کے لیے، کچھ "اسکیما" کے مطابق ہونا چاہیے۔ آپ اسے XML دستاویز کے لیے ایک قسم کے انٹرفیس کے طور پر سوچ سکتے ہیں۔ اسکیما یہ بتاتا ہے کہ XML دستاویز میں کون سے عناصر ہو سکتے ہیں، کس قسم کا ڈیٹا عنصر، ترتیب، ضرورت اور دیگر پہلوؤں کی وضاحت کر سکتا ہے۔ دستاویزات سے نقل کی گئی مثال ورژن 2.5 کی نشاندہی کرتی ہے، لیکن ہم ورژن 3.1 استعمال کرنا چاہتے ہیں۔ فطری طور پر، تصریحات تبدیل ہوتے ہی ورژن بدلتے گئے، اور نئی خصوصیات شامل کی گئیں۔ لہذا، آپ کو ورژن 2.5 (web-app_2_5.xsd) کے لیے استعمال کردہ اسکیما کے علاوہ ایک اسکیما استعمال کرنے کی ضرورت ہے۔ مجھے ورژن 3.1 کے لیے کون سی اسکیم استعمال کرنی چاہیے؟ دستاویزات اس میں ہماری مدد کرے گی، باب “ 14.3 ڈیپلائمنٹ ڈسکرپٹر ”، جس میں کہا گیا specification is available at http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd ہے کہ ہمیں اسکیما کے لنک کو ہر جگہ مخصوص xsd کے ساتھ تبدیل کرنے کی ضرورت ہے، اسے version="2.5"3.1 میں تبدیل کرنا نہیں بھولنا، اور ہر جگہ نام کی جگہ کو بھی تبدیل کرنا ہوگا ( xmlns اور xsi میں: schemaLocation)۔ وہ اس بات کی نشاندہی کرتے ہیں کہ ہم کس نام کی جگہ کے اندر کام کریں گے (بہت آسان الفاظ میں، ہم کون سے عنصر کے نام استعمال کر سکتے ہیں)۔ اگر آپ اسکیما فائل کھولتے ہیں، تو targetNamespace میں وہی نام کی جگہ ہوگی جس کی ہمیں وضاحت کرنی چاہیے: جیسا کہ ہمیں یاد ہے، جار فائل کے مینی فیسٹ میں ہم نے لکھا تھا کہ ہم کون سی کلاس استعمال کرنا چاہتے ہیں۔ یہاں کیا کرنا ہے؟ یہاں ہمیں یہ بتانے کی ضرورت ہے کہ جب ہمیں کسی ویب کلائنٹ سے درخواست موصول ہوتی ہے تو ہم کون سی سرولیٹ کلاس استعمال کرنا چاہتے ہیں۔ تفصیل باب " 14.4 تعیناتی ڈسکرپٹر ڈایاگرام " میں پڑھی جا سکتی ہے۔ یہ اس طرح نظر آئے گا: یہاں سب کچھ آسان ہے۔ سرورلیٹ کا اعلان کیا جاتا ہے، اور پھر اسے ایک مخصوص ٹیمپلیٹ پر نقشہ بنایا جاتا ہے۔ اس صورت میں، on /app۔ جب ٹیمپلیٹ کو عمل میں لایا جائے گا، تو سرولیٹ کا طریقہ کار انجام دیا جائے گا۔ خوبصورتی کے لیے، ایپ کلاس کو پیکیج میں منتقل کیا جانا چاہیے، xml کنفیگریشن کو درست کرنا نہ بھولیں۔ لیکن یہ سب کچھ نہیں ہے۔ ایپ کو ایک سرولیٹ ہونا چاہیے۔ سرولیٹ ہونے کا کیا مطلب ہے؟ اس کا مطلب ہے کہ ہمیں HttpServlet سے وراثت میں لینا چاہیے ۔ ایک مثال باب " 8.1.1 @WebServlet " میں دیکھی جا سکتی ہے۔ اس کے مطابق، ہماری ایپ کلاس اس طرح نظر آئے گی:

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

public class App extends HttpServlet {
    public String getGreeting() {
        return "Hello world.";
    }

	public void doGet(HttpServletRequest request, HttpServletResponse response) {
		response.setContentType("text/html");
		try {
			response.getWriter().println(getGreeting());
		} catch (IOException e) {
			throw new IllegalStateException(e);
		}
	}
}

لیکن ہمارا منصوبہ ابھی تک تیار نہیں ہوا۔ کیونکہ اب ہم Servlet API ورژن 3.1 پر انحصار کرتے ہیں۔ اس کا مطلب یہ ہے کہ ہماری تعمیر اسکرپٹ میں ہمیں Servlet API پر انحصار کی نشاندہی کرنے کی ضرورت ہے۔ JVM کو یہ جاننے کی ضرورت ہے کہ آپ نے کوڈ میں جو لکھا ہے وہ درست ہے اور اسے کیسے استعمال کیا جائے۔ جیسا کہ ہمیں یاد ہے، تصریح بنیادی طور پر صرف انٹرفیس ہے جو بیان کرتی ہے کہ یہ سب کیسے کام کرنا چاہیے۔ اور نفاذ ویب سرور کی طرف ہے۔ لہذا، Servlet API کے بغیر Maven Central پر مطلوبہ لائبریری تلاش کریں: javax.servlet-api ۔ اور انحصار بلاک میں ایک اندراج شامل کریں ۔ Maven ذخیرہ میں، جیسا کہ آپ نے دیکھا، یہ فراہم کردہ کہتا ہے۔ انحصار استعمال کرنے سے پہلے، آپ کو دائرہ کار کی وضاحت کرنی ہوگی۔ گریڈل کے پاس "فراہم کردہ" نام کا کوئی دائرہ کار نہیں ہے، لیکن اس میں " صرف مرتب " گنجائش ہے۔ لہذا، ہم اشارہ کریں گے: providedCompile 'javax.servlet:javax.servlet-api:3.1.0' اوہ، سب کچھ ٹھیک ہے؟ Gradle Build ہمارے پروجیکٹ کو WAR فائل میں بنائے گا۔ اور ہمیں اس کے ساتھ آگے کیا کرنا چاہئے؟ سب سے پہلے، ہمیں ایک ویب سرور کی ضرورت ہے۔ گوگل میں ہم " web server java list " لکھتے ہیں اور ویب سرورز کی فہرست دیکھتے ہیں۔ آئیے اس فہرست میں سے انتخاب کریں، مثال کے طور پر، TomCat ۔ Apache Tomcat ویب سائٹ پر جائیں ، تازہ ترین ورژن (فی الحال ورژن 9) کو زپ آرکائیو کے طور پر ڈاؤن لوڈ کریں (اگر ونڈوز کے لیے)۔ اسے کسی ڈائرکٹری میں کھولیں۔ ہیرے، ہمارے پاس ایک ویب سرور ہے۔ بن سب ڈائرکٹری میں ویب سرور ڈائرکٹری سے ، ہم کمانڈ لائن سے کیٹالینا کو چلاتے ہیں اور دستیاب اختیارات کو دیکھتے ہیں۔ چلو کرتے ہیں: catalina start. ہر ویب سرور کی ایک ڈائرکٹری ہوتی ہے جس کی نگرانی ویب سرور کرتا ہے۔ اگر کوئی ویب ایپلیکیشن فائل وہاں ظاہر ہوتی ہے، تو ویب سرور اسے انسٹال کرنا شروع کر دیتا ہے۔ اس تنصیب کو تعیناتی یا تعیناتی کہا جاتا ہے ۔ ہاں ہاں، اسی لیے " تعیناتی بیان کنندہ "۔ یعنی ایپلیکیشن کو صحیح طریقے سے کیسے لگایا جائے۔ Tomcat میں یہ ڈائریکٹری webapps ہے ۔ آئیے اس جنگ کو کاپی کرتے ہیں جو ہم نے وہاں گریڈل بلڈ کا استعمال کرتے ہوئے کی تھی۔ اس کے بعد، لاگ میں ہمیں کچھ ایسا نظر آئے گا: Deployment of web application archive [tomcat\webapps\webproject.war] has finished in [время] ms مزید بہتر طور پر سمجھنے کے لیے، tomcat ڈائرکٹری میں ہم فائل کو ایڈٹ کریں گے \conf\tomcat-users.xml، درج ذیل لائنوں کو شامل کرتے ہوئے: اب ہم سرور کو ری سٹارٹ کرتے ہیں (کیٹلینا سٹاپ، کیٹلینا سٹارٹ) اور ایڈریس پر جاتے ہیں۔یہاں http://127.0.0.1:8080/manager ہم تمام ایپلی کیشنز کے راستے دیکھیں گے۔ ہمارے ویب پروجیکٹ کو غالباً پاتھ/ویب پروجیکٹ دیا گیا تھا۔ یہ راستہ کیا ہے؟ باب " 10.1 ویب ایپلیکیشنز کے اندر ویب سرورز " میں تفصیلات بتاتی ہیں کہ ایک ویب ایپلیکیشن ایپلی کیشن کے اندر کسی راستے سے منسلک ہوتی ہے (اس صورت میں، /webproject)۔ اس راستے کے ذریعے تمام درخواستیں اسی ServletContext سے منسلک ہوں گی۔ اس راستے کو contextRoot بھی کہا جاتا ہے ۔ اور " 10.2 Relationship to ServletContext " کے مطابق سرولیٹ کنٹینر ویب ایپلیکیشن اور ServletContext کو ایک سے ایک کرتا ہے۔ یعنی ہر ویب ایپلیکیشن کا اپنا ServletContext ہوتا ہے۔ ایک ServletContext کیا ہے ؟ جیسا کہ تصریح میں کہا گیا ہے، ایک ServletContext ایک ایسی چیز ہے جو سرولیٹس کو " درخواست کا منظر " فراہم کرتی ہے جس میں وہ چل رہے ہیں۔ Servlet سیاق و سباق کو Servlet API تفصیلات کے باب 4 میں مزید تفصیل سے بیان کیا گیا ہے۔ حیرت انگیز طور پر، ورژن 3.1 میں Servlet API کو اب web.xml کے موجود ہونے کی ضرورت نہیں ہے۔ مثال کے طور پر، آپ تشریحات کا استعمال کرتے ہوئے ایک سرولیٹ کی وضاحت کر سکتے ہیں:

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

    public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
        response.setContentType("text/html");
        response.getWriter().println("app2");
    }
}

اس موضوع پر بھی تجویز کیا گیا: " Java EE انٹرویو - JEE Servlet API (سوالات اور جوابات) "۔ لہذا، ہمارے پاس ایک Servlet ہے - یہ ذمہ دار ہے کہ ویب کلائنٹ کو کیا جواب دینا ہے۔ ہمارے پاس ایک ServletContainer ہے جو صارف سے درخواستیں وصول کرتا ہے، اس راستے سے میل کھاتا ہے جس تک رسائی حاصل کی گئی تھی servlet کے راستے سے، اور اگر کوئی مماثلت پائی جاتی ہے، تو Servlet کو انجام دیتا ہے۔ ٹھیک. دنیا کی اس تصویر میں بہار کا کون سا مقام ہے ؟

اسپرنگ ویب ایم وی سی

بہت اچھا، ہمارے پاس ایک ویب ایپلیکیشن ہے۔ اب ہمیں بہار کو جوڑنے کی ضرورت ہے۔ ہم یہ کیسے کر سکتے ہیں؟ سب سے پہلے، آپ کو یہ معلوم کرنے کی ضرورت ہے کہ بہار کو اپنے پروجیکٹ سے کیسے جوڑنا ہے۔ اس سے پتہ چلتا ہے کہ اس سے قبل اسپرنگ پلیٹ فارم پروجیکٹ کی دستاویزات کے مطابق ایسا کرنا ممکن تھا ، لیکن اب " پلیٹ فارم 9 اپریل 2019 کو اپنی معاون زندگی کے اختتام کو پہنچ جائے گا "، یعنی ایسا کرنا مناسب نہیں ہے۔ اس کا استعمال کریں، کیونکہ جلد ہی اس کی حمایت نہیں کی جائے گی۔ اس سے نکلنے کا واحد راستہ یہ ہے کہ " پلیٹ فارم کے صارفین کی حوصلہ افزائی کی جاتی ہے کہ وہ اسپرنگ بوٹ کے انحصار کے انتظام کو استعمال کرنا شروع کریں "۔ لہذا، آئیے اسپرنگ بوٹ دستاویزات کی طرف چلتے ہیں ۔ میں واضح کرتا چلوں کہ ہم خود اسپرنگ بوٹ استعمال نہیں کرتے ہیں بلکہ اسپرنگ بوٹ سے صرف انحصاری انتظام کرتے ہیں۔ یعنی، اسپرنگ بوٹ پروجیکٹ اس بارے میں علم فراہم کر سکتا ہے کہ لائبریریوں کے کون سے ورژن استعمال کیے جائیں (بشمول اسپرنگ ایم وی سی)۔ وہاں ہمیں 3.2 ملے گا ۔ اسپرنگ بوٹ کے انحصار کے انتظام کو تنہائی میں استعمال کرنا ۔ دستاویزات کے مطابق، بلڈ اسکرپٹ میں درج ذیل شامل کریں:

plugins {
    id 'org.springframework.boot' version '2.0.4.RELEASE' apply false
}
apply plugin: 'io.spring.dependency-management'

اور

dependencyManagement {
    imports {
        mavenBom org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES
    }
}

جیسا کہ آپ دیکھ سکتے ہیں، ہم نے اشارہ کیا apply false، یعنی ہم خود اسپرنگ بوٹ استعمال نہیں کرتے ہیں، لیکن ہم وہاں سے انحصار کا انتظام استعمال کرتے ہیں۔ انحصار کے اس انتظام کو BOM - " مادی کا بل " بھی کہا جاتا ہے۔ اب ہم Spring Web MVC پروجیکٹ کو جوڑنے کے لیے تیار ہیں۔ Spring Web MVC Spring Framework پروجیکٹ کا حصہ ہے اور ہم " Web Servlet " سیکشن میں دلچسپی رکھتے ہیں۔ آئیے بلڈ اسکرپٹ میں انحصار شامل کریں: compile 'org.springframework:spring-webmvc'. جیسا کہ ہم دیکھ سکتے ہیں، ہم اسکوپ کمپائل سیٹ کرتے ہیں، کیونکہ ویب سرور ہمیں بہار فراہم نہیں کرتا ہے۔ ہمارا پروجیکٹ سپرنگ لائبریری کو اپنے اندر شامل کرنے پر مجبور ہے۔ اس کے بعد، ہمارے لیے سیکشن " 1.2. DispatcherServlet " کو پڑھنا ضروری ہے، جہاں یہ کہا جاتا ہے کہ Spring MVC " فرنٹ کنٹرولر " پیٹرن کے ارد گرد بنایا گیا ہے ، جہاں ایک قسم کا مرکزی سرولیٹ ہے جو دوسرے اجزاء کو ترتیب اور وفد فراہم کرتا ہے۔ . ڈسپیچر کا ترجمہ ڈسپیچر کے طور پر کیا جا سکتا ہے۔ لہذا، سب سے پہلے، web.xml میں ہم اعلان کرتے ہیں: جیسا کہ ہم دیکھ سکتے ہیں، یہ دراصل ایک باقاعدہ سننے والا ہے جس کی تعریف Servlet API تفصیلات میں کی گئی ہے۔ زیادہ درست ہونے کے لیے، یہ ایک ServletContextListener ہے، یعنی یہ ہماری ویب ایپلیکیشن کے لیے Servlet سیاق و سباق کو شروع کرنے کے لیے متحرک ہوتا ہے۔ اگلا، آپ کو ایک ترتیب بتانے کی ضرورت ہے جو بہار کو بتائے گی کہ اس کی ترتیبات کے ساتھ اس کی خصوصی ایکس ایم ایل تشکیل کہاں واقع ہے: جیسا کہ آپ دیکھ سکتے ہیں، یہ صرف ایک باقاعدہ ترتیب ہے جو Servlet سیاق و سباق کی سطح پر محفوظ کی جاتی ہے، لیکن جسے Application سیاق و سباق شروع کرتے وقت Spring کے ذریعے استعمال کیا جائے گا۔ اب آپ کو تمام سرولیٹس کے بجائے ایک واحد ڈسپیچر کا اعلان کرنے کی ضرورت ہے جو دیگر تمام درخواستوں کو تقسیم کرتا ہے۔ اور یہاں کوئی جادو نہیں ہے۔ اگر ہم دیکھیں تو یہ ایک HttpServlet ہے، جہاں بہار بہت ساری چیزیں کرتی ہے جو اسے ایک فریم ورک بناتی ہے۔ جو کچھ باقی ہے وہ سرولیٹ کے ساتھ ایک مخصوص URL ٹیمپلیٹ کو جوڑنا (نقشہ) ہے: سب کچھ ویسا ہی ہے جیسا کہ ہم پہلے کرتے تھے۔ اب آئیے کچھ ایسا بناتے ہیں جو ہمارے ویب سرور کو دکھانا چاہیے۔ مثال کے طور پر، آئیے اپنے WEB-INF میں صفحات کی ذیلی ڈائرکٹری بنائیں، اور وہاں ایک فائل hello.jsp ہوگی۔ مواد سب سے قدیم ہو سکتا ہے. مثال کے طور پر، ایچ ٹی ایم ایل ٹیگز کے اندر ایک h1 ٹیگ ہے جس میں " ہیلو ورلڈ " لکھا ہوا ہے۔ اور اس فائل کو بنانا نہ بھولیں applicationContext.xmlجس کی ہم نے پہلے وضاحت کی تھی۔ آئیے اسپرنگ دستاویزات سے ایک مثال لیتے ہیں: " 1.10.3۔ کلاسوں کا خود بخود پتہ لگانا اور بین کی تعریفیں رجسٹر کرنا "۔ کیونکہ ہم اس طریقے سے آٹو ڈیٹیکشن کو فعال کرتے ہیں، اب ہم 2 کلاسز بنا سکتے ہیں (اسپرنگ کی خصوصی تشریحات کے استعمال کی وجہ سے انہیں اسپرنگ بینز سمجھا جائے گا)، جو اسپرنگ اب خود بنائے گی اور ان کی مدد سے ہماری ایپلیکیشن کو اپنی مرضی کے مطابق بنائے گی:

1. ویب کنفیگریشن مثال کے طور پر جاوا اسٹائل کنفیگریشن:

   @Configuration
   @EnableWebMvc
   public class WebConfig implements WebMvcConfigurer {
       @Override
       public void configureViewResolvers(ViewResolverRegistry registry) {
           registry.jsp("/WEB-INF/pages/", ".jsp");
       }
       @Override
       public void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) {
           configurer.enable();
       }
   }

   اس مثال کو اسپرنگ فریم ورک دستاویزات میں بیان کیا گیا ہے: " 1.11. MVC کنفیگ "۔

   یہاں ہم ایک ViewResolver رجسٹر کرتے ہیں، جو اس بات کا تعین کرنے میں مدد کرے گا کہ jsp صفحات کہاں واقع ہیں۔ دوسرا طریقہ اس بات کو یقینی بناتا ہے کہ " ڈیفالٹ سرولیٹ " فعال ہے۔

   آپ اس کے بارے میں یہاں مزید پڑھ سکتے ہیں: " default-servlet-handler کی ضرورت اور استعمال کیا ہے "۔

2. HelloController ایک مخصوص JSP کو درخواستوں کی میپنگ کی وضاحت کرنے کے لیے کنٹرولر

   @Controller
   public class HelloController {
       @GetMapping("/hello")
       public String handle(Model model) {
           return "hello";
       }
   }

   یہاں ہم نے باب " 1.4. تشریح شدہ کنٹرولرز " میں دستاویزات میں بیان کردہ @Controller تشریح کا استعمال کیا ہے۔

اب، جب ہماری ایپلیکیشن ڈیپلائی ہو جائے گی، جب ہم کوئی درخواست بھیجیں گے /webproject/hello(جہاں /webproject سیاق و سباق کی جڑ ہے)، پہلے DispatcherServlet پر کارروائی کی جائے گی۔ وہ، بطور مرکزی ڈسپیچر، اس بات کا تعین کرے گا کہ ہم /* موجودہ درخواست سے میل کھاتے ہیں، جس کا مطلب ہے کہ DispatcherServlet کو کچھ کرنا چاہیے۔ پھر یہ ان تمام نقشوں سے گزرے گا جو اسے ملے گی۔ یہ دیکھے گا کہ ہینڈل کے طریقہ کار کے ساتھ ایک HelloController ہے جو /hello پر میپ کیا گیا ہے اور اسے انجام دے گا۔ یہ طریقہ "ہیلو" متن کو واپس کر دے گا۔ یہ متن ViewResolver کے ذریعہ موصول ہوگا، جو سرور کو بتائے گا کہ jsp فائلوں کو کہاں تلاش کرنا ہے جنہیں کلائنٹ کو دکھانے کی ضرورت ہے۔ اس طرح، کلائنٹ کو بالآخر وہ بہت پیارا صفحہ ملے گا۔

نتیجہ

مجھے امید ہے کہ مضمون سے یہ واضح ہو جائے گا کہ لفظ "سیاق و سباق" خوفناک نہیں ہے۔ یہ وضاحتیں بہت مفید ثابت ہوتی ہیں۔ اور دستاویزات ہمارا دوست ہے، دشمن نہیں۔ مجھے امید ہے کہ یہ واضح ہو جائے گا کہ بہار کس چیز پر مبنی ہے، یہ کیسے جوڑتا ہے، اور Servlet API کا اس سے کیا تعلق ہے۔