Câu hỏi: PRJ301 Phát triển ứng dụng Java web – Bộ ôn tập cuối kỳ số 3

Đáp án đúng: "LoginServlet". Container định tuyến bằng bộ mô tả triển khai: mỗi khối ánh xạ nối một mẫu URL với một tên servlet, và tên đó lại trỏ tới lớp khai báo ở khối servlet tương ứng. Với đường dẫn /login, quy tắc khớp chính xác được xét trước khớp theo tiền tố, trước khớp theo phần mở rộng và trước servlet mặc định, nên servlet được khai báo cho mẫu /login chính là thứ được gọi. "HomeServlet" sai vì nó chỉ chạy khi yêu cầu khớp mẫu URL khai báo cho riêng nó, mà /login không phải mẫu đó. "MainServlet" sai vì kể cả khi nó nhận một mẫu bao trùm theo tiền tố thì khớp chính xác vẫn thắng, container không chọn nó cho đường dẫn này. "ErrorHandler" sai vì thành phần loại đó được gọi qua khai báo trang lỗi khi có mã lỗi hoặc ngoại lệ, nó không nằm trên đường đi bình thường của một yêu cầu.

Đáp án đúng: "Indicates that the requested resource is not available.". Mã 404 thuộc nhóm lỗi phía client và có nghĩa server hiểu được yêu cầu nhưng không tìm thấy tài nguyên ứng với đường dẫn đó, thường do sai đường dẫn, sai mẫu ánh xạ servlet hoặc tệp không được đóng gói vào ứng dụng khi triển khai. Lựa chọn "Indicates that the request requires HTTP authentication." mô tả mã 401, tức là tài nguyên có thật nhưng đòi xác thực trước khi phục vụ. Lựa chọn "Indicates an error inside the HTTP server which prevented it from fulfilling the request." mô tả mã 500, lỗi bên trong server, thường là ngoại lệ chưa được bắt trong servlet. Lựa chọn "Indicates that the HTTP server is temporarily overloaded, and unable to handle the request." mô tả mã 503, server tạm thời không phục vụ được; cả ba đều nói về tình huống khác với việc không tìm thấy tài nguyên.

Đáp án đúng: "Processes client requests and returns dynamic content". Web server nhận yêu cầu HTTP, tra xem thành phần nào phụ trách đường dẫn đó, chuyển cho nó xử lý rồi gói kết quả thành phản hồi gửi về trình duyệt; trong Java web thì chính container gọi servlet hoặc trang JSP, và nội dung sinh ra thay đổi theo tham số, theo phiên và theo dữ liệu, nên đó là nội dung động. "Hosts the website’s static content" tuy không sai hẳn, vì server cũng phát tệp tĩnh, nhưng đó chỉ là một phần việc nhỏ và không phải vai trò mà câu hỏi nhắm tới; nếu chỉ cần phát tệp tĩnh thì không cần tới một server có container. "Manages database connections" sai vì việc giữ và cấp phát kết nối thuộc tầng dữ liệu của ứng dụng, thường qua một nguồn dữ liệu được cấu hình sẵn. "Authenticates user sessions" sai vì xác thực là một chức năng cụ thể do servlet hay filter của ứng dụng cài đặt, không phải vai trò chung của web server.

Đáp án đúng: "init()". Vòng đời servlet do web container điều khiển: sau khi nạp lớp và tạo đúng một thể hiện, container gọi init() một lần duy nhất để servlet chuẩn bị tài nguyên dùng lâu dài, rồi mới chuyển các yêu cầu vào service(); muốn chạy mã khởi tạo thì phải ghi đè đúng móc này, thường là bản không tham số hoặc bản nhận ServletConfig. "doGet()" không phải móc khởi tạo mà là nơi xử lý từng yêu cầu GET, nó được gọi lại mỗi lần người dùng truy cập nên đặt mã khởi tạo ở đó sẽ chạy lặp vô ích và còn dễ sinh tranh chấp giữa các luồng. "doInit()" không tồn tại trong HttpServlet lẫn giao diện Servlet, viết tên này chỉ tạo ra một phương thức thường, container không bao giờ gọi tới. "start()" là quy ước của luồng trong Java, không thuộc hợp đồng servlet, nên ghi đè cũng không có hiệu lực nào trong vòng đời do container quản.

Đáp án đúng: "/WEB-INF". Bản mô tả triển khai nằm ngay trong /WEB-INF, cạnh hai thư mục chứa lớp biên dịch và thư viện; container đọc tệp này khi nạp ứng dụng. Thư mục đó được đặc tả bảo vệ: trình duyệt không lấy trực tiếp được nội dung bên trong, nhờ vậy cấu hình và lớp biên dịch không bị phơi ra, còn servlet thì vẫn chuyển tiếp tới trang JSP đặt trong đó được. Lựa chọn "/src" là nơi giữ mã nguồn trên máy lập trình viên, nó không được đóng vào gói chạy thật. Lựa chọn "/META-INF" giữ siêu dữ liệu đóng gói như tệp kê khai, và ở một số container là tệp khai báo ngữ cảnh, nhưng bản mô tả triển khai của ứng dụng web không đặt ở đây. Lựa chọn "/WEB-CONTENT" không phải tên do đặc tả quy định: thư mục nội dung web trong các bộ công cụ có nhiều tên khác nhau, và khi triển khai thì nội dung của nó trở thành gốc ứng dụng chứ không còn là một cấp đường dẫn.

Đáp án đúng: "Initializing global configuration parameters for the web application". Tham số khởi tạo mức ngữ cảnh được khai trong thẻ context-param của mô tả triển khai và đọc bằng getServletContext().getInitParameter(), nên nó là chỗ đặt cấu hình chung cho toàn ứng dụng: mọi servlet, filter và listener trong cùng ngữ cảnh đều thấy một giá trị giống nhau mà không phải sửa và dịch lại mã. "Controlling the user sessions and session attributes" lạc nhiệm vụ, vì phiên do container tạo riêng cho từng người dùng và truy cập qua HttpSession, còn tham số ngữ cảnh chỉ đọc và không mang trạng thái của ai. "Managing database connections and transactions" là việc của JDBC cùng nguồn dữ liệu; tham số ngữ cảnh nhiều lắm chỉ chứa chuỗi cấu hình như địa chỉ hay tên driver, bản thân nó không mở cũng không chốt giao dịch. "Controlling the server ports and protocols" thuộc cấu hình của chính máy chủ, nằm ngoài mô tả triển khai của một ứng dụng.

Đáp án đúng: "Minutes". Trong mô tả triển khai, thẻ session-timeout nằm trong thẻ session-config và nhận một số nguyên tính theo phút, nên ghi 30 nghĩa là phiên bị huỷ sau ba mươi phút không có yêu cầu nào. Đặt cùng việc này bằng mã thì gọi setMaxInactiveInterval(), và phương thức đó lại tính theo giây, nên hai nơi khác đơn vị chính là bẫy thường gặp. "Seconds" là đơn vị của setMaxInactiveInterval() chứ không phải của mô tả triển khai; nhầm chỗ này làm phiên sống ngắn hơn ý định sáu mươi lần. "Milliseconds" là đơn vị quen của các hàm đo thời gian trong Java nhưng không được dùng cho cấu hình phiên. "Hours" không có trong đặc tả, muốn một giờ thì phải ghi 60 theo phút chứ không ghi 1.

Đáp án đúng: ".war". Ứng dụng web Java được đóng thành gói lưu trữ web, bên trong có thư mục WEB-INF cùng mô tả triển khai, và container như Tomcat chỉ nhận dạng rồi tự bung đúng loại gói này thành một ngữ cảnh web có đường dẫn riêng. Đuôi ".jar" dùng cho thư viện hoặc ứng dụng Java thường, không mang cấu trúc WEB-INF nên máy chủ không triển khai nó như một ứng dụng web. Đuôi ".exe" là tệp thực thi của Windows, không chạy trên máy ảo Java và chẳng liên quan tới việc triển khai. Đuôi ".zip" chỉ là định dạng nén chung: gói web thực chất cũng là tệp nén, nhưng phải mang đúng đuôi quy định cùng cấu trúc bắt buộc thì máy chủ mới hiểu, đổi sang đuôi nén thường là máy chủ bỏ qua.

Đáp án đúng: "thread". Trang JSP được dịch thành một servlet, và trong phương thức phục vụ sinh ra sẵn các biến gọi là đối tượng ẩn: request, response, out, session, application, config, pageContext, page và exception. Không có biến nào tên thread; muốn làm việc với luồng đang chạy thì phải tự gọi phương thức lấy luồng hiện tại, chứ trang không khai sẵn cho bạn. "request" là đối tượng ẩn kiểu HttpServletRequest, dùng đọc tham số và thuộc tính phạm vi yêu cầu. "config" cũng là đối tượng ẩn, kiểu ServletConfig, cho trang đọc tham số khởi tạo của chính servlet sinh ra từ trang đó. "session" là đối tượng ẩn kiểu HttpSession, có mặt mặc định và chỉ biến mất khi chỉ thị trang đặt thuộc tính session thành false.

Đáp án đúng: "jsp:include includes the output dynamically at runtime". Thẻ hành động jsp:include được dịch thành lệnh gọi bộ phân phối yêu cầu lúc trang chạy, nên mỗi lần có yêu cầu thì tài nguyên được gọi đi chạy riêng và chỉ phần kết xuất của nó được nối vào dòng ra; trái lại, chỉ thị include dán nguyên mã nguồn của tệp vào trang ngay ở pha dịch, trước khi trang biến thành servlet. "jsp:include includes content at translation time, include at request time" đảo ngược đúng hai pha vừa nói, dẫn người đọc tới kết luận ngược hẳn về thời điểm nội dung được ghép. "Both include the resource statically" sai vì chỉ chỉ thị include mới tĩnh; nếu cả hai đều tĩnh thì thẻ jsp:param và việc gọi tới tài nguyên động như một servlet sẽ không thể có. "include supports parameters, jsp:include does not" lộn vai hai bên: jsp:param chỉ hợp lệ bên trong jsp:include, còn chỉ thị include không nhận tham số nào ngoài tên tệp.

Đáp án đúng: "[HTTP Version] [Response Code] [Status]". Dòng đầu của thông điệp phản hồi HTTP gồm ba phần theo thứ tự: phiên bản giao thức, mã trạng thái ba chữ số và cụm mô tả ngắn đi kèm mã đó, ví dụ dòng ghi HTTP/1.1 404 Not Found. Bộ ba này cho máy khách biết đang nói chuyện bằng phiên bản nào và kết quả xử lý ra sao trước khi đọc tiếp phần tiêu đề và thân. "[HTTP Method] [Protocol Version] [Requested Resource forming URI]" là khuôn của dòng đầu bên yêu cầu chứ không phải bên phản hồi, mà ngay cả bên yêu cầu thì thứ tự cũng là phương thức, đường dẫn rồi mới tới phiên bản. "[HTTP Version] [Response Code] [Http Method]" sai ở phần cuối: phản hồi không nhắc lại phương thức, chỗ đó phải là cụm mô tả trạng thái. "HTTP Version] [Protocol Code] [Http Method]" vừa thiếu dấu mở ngoặc, vừa gọi sai tên thành phần thứ hai, lại lặp lỗi đưa phương thức vào phản hồi.

Đáp án đúng: "To forward the request to another resource". Cơ chế này chuyển quyền xử lý sang một tài nguyên khác ngay trong cùng một chu trình phục vụ: lấy đối tượng điều phối theo đường dẫn đích rồi gọi forward, trang đích nhận đúng cặp request và response đang có, nên địa chỉ trên trình duyệt không đổi và mọi dữ liệu gắn bằng setAttribute vẫn đọc được bên kia; đó chính là mối nối giữa servlet và JSP trong kiến trúc MVC, và giao diện này còn có include để nhúng kết quả của tài nguyên khác vào phản hồi đang soạn. "To redirect the client to another web page" là việc của sendRedirect: nó trả mã chuyển hướng để trình duyệt tự đi tới địa chỉ mới bằng một yêu cầu khác, không phải chuyển tiếp trong máy chủ. "To handle HTTP POST requests" là nhiệm vụ của doPost trong lớp servlet. "To handle form submissions" là việc servlet đọc dữ liệu biểu mẫu bằng getParameter rồi xử lý, không liên quan tới việc điều phối giữa các tài nguyên.

Đáp án đúng: "/pages/*". Trong thẻ servlet-mapping, khuôn mở đầu bằng dấu gạch chéo và kết thúc bằng dấu sao là khuôn theo đường dẫn: container lấy phần đầu cố định làm tiền tố và khớp mọi yêu cầu nằm dưới thư mục đó cùng mọi mức con của nó, đúng với ý muốn cho một servlet gánh trọn một nhánh địa chỉ. "/*" cũng là khuôn đường dẫn nhưng phủ cả ứng dụng, kể cả tệp tĩnh và mọi khuôn khác, chứ không giới hạn vào một thư mục nào. "/servlet/*" có đúng dạng cần tìm nhưng gắn vào một thư mục mang nghĩa khác, nên nó chỉ là một ví dụ cùng kiểu, không phải cách diễn đạt ý định nêu trong câu hỏi. "*.html" là khuôn theo phần mở rộng: nó chọn tài nguyên theo đuôi tên bất kể nằm ở thư mục nào, vì vậy không diễn tả được ràng buộc gói gọn trong một thư mục và các thư mục con của thư mục ấy.

Đáp án đúng: "JSPs can use servlets to handle complex logic.". Hai công nghệ cùng chạy trong một container và sau pha dịch thì trang JSP cũng là một servlet, nên cách dùng chuẩn theo kiến trúc MVC là để servlet nhận yêu cầu, gọi tầng xử lý, đặt dữ liệu vào phạm vi yêu cầu rồi forward sang trang JSP; trang chỉ còn việc kết xuất, phần nghiệp vụ rắc rối nằm lại trong mã Java. "Servlets are outdated and replaced by JSP." sai vì chính trang JSP phải được dịch thành một servlet mới chạy được, không thể có chuyện cái sau thay thế nền tảng mà nó dựa vào. "JSP and servlets cannot interact." bị phản chứng ngay bởi bộ phân phối yêu cầu: forward và include là đường đi qua lại giữa hai bên, cộng với việc hai bên dùng chung đối tượng yêu cầu và phiên. "Servlets generate JSP pages dynamically." đảo chiều quy trình, vì container dịch tệp JSP thành mã servlet chứ servlet không sinh ra tệp JSP lúc chạy.

Đáp án đúng: "<jsp:directive.include file=" connect.jsp"/>". Mọi chỉ thị của JSP đều có dạng XML tương đương theo khuôn jsp:directive nối thêm tên chỉ thị sau dấu chấm, nên chỉ thị include viết bằng cú pháp XML là jsp:directive.include và giữ nguyên thuộc tính file; đây là dạng bắt buộc khi trang được viết thành tài liệu XML. "<jsp:include file=" connect.jsp"/>" sai cả hai mặt: jsp:include là thẻ hành động chạy lúc có yêu cầu chứ không phải chỉ thị, và nó không nhận thuộc tính file. "<jsp:include page=" connect.jsp"/>" tuy viết đúng thuộc tính của thẻ hành động nhưng vẫn không tương đương, vì nó gọi tài nguyên lúc chạy rồi nối kết xuất, còn chỉ thị include dán mã nguồn vào trang ở pha dịch. "There is no XML equivalent of include directive." trái với đặc tả, bởi dạng jsp:directive.include tồn tại đúng để làm việc đó.

Đáp án đúng: "To handle server-side logic and generate dynamic content.". Tệp JSP được container dịch thành một servlet rồi biên dịch; mã trong scriptlet, thẻ hành động, biểu thức EL và thẻ JSTL đều chạy trên máy chủ, còn thứ gửi về máy khách chỉ là văn bản đã sinh xong. Vì vậy lý do tồn tại của JSP là nhúng phần xử lý phía máy chủ vào khuôn trình bày để tạo nội dung đổi theo dữ liệu. "To define the structure and layout of a web page." mới là việc của HTML; trang JSP có thể chứa HTML nhưng nếu chỉ cần cấu trúc tĩnh thì chẳng cần tới pha dịch và biên dịch. "To execute client-side JavaScript code." sai phía thực thi, vì mã kịch bản do trình duyệt chạy sau khi nhận phản hồi, máy chủ chỉ coi nó là văn bản. "To define the styles and presentation of a web page." là phần việc của CSS, nằm ngoài mục đích của JSP.

Đáp án đúng: "To handle exceptions thrown by Java code in the JSP". Khi mã Java trong trang JSP ném một ngoại lệ không được bắt, ngoại lệ ấy thoát khỏi phương thức phục vụ và container tra khai báo trang lỗi để biết đưa người dùng tới đâu: khai theo loại ngoại lệ kèm vị trí trang xử lý, còn trang xử lý thường bật thuộc tính báo mình là trang lỗi để dùng được đối tượng ẩn exception mà in thông điệp hay ghi log. "To declare custom error pages for specific HTTP error codes" nói về nhánh khai theo mã trạng thái HTTP, tức lo các mã do container sinh ra như 404 hay 500; đó là một công dụng khác của cùng khai báo, không phải điều câu hỏi đang nhắm tới. "To define global error handling for the entire web application" chỉ nói về phạm vi khai báo chứ không nói việc gì được xử lý, hơn nữa từng trang JSP vẫn có thể tự trỏ trang lỗi riêng bằng thuộc tính trong chỉ thị page. "To include additional resources in the JSP page" sai hẳn vì việc nhúng thêm tài nguyên vào trang thuộc chỉ thị include hoặc thẻ hành động include.

Đáp án đúng: "<c:forEach>". Thẻ này thuộc thư viện lõi của JSTL, khai bằng chỉ thị taglib với tiền tố quy ước là chữ c, và lặp theo hai cách: cho thuộc tính items trỏ tới mảng, Collection, Map hay chuỗi phân tách để duyệt từng phần tử qua biến var, hoặc cho begin, end, step để lặp theo số. Nhờ nó, việc duyệt danh sách không cần scriptlet, giữ trang sạch mã Java. "<c:loop>" không tồn tại trong thư viện lõi; tên nghe hợp lý nhưng container sẽ báo lỗi ngay ở pha dịch vì bộ mô tả thư viện không có thẻ nào như vậy. "<jstl:repeat>" sai ở cả tiền tố và tên thẻ: tiền tố do người viết trang khai nhưng quy ước của thư viện lõi không phải chuỗi đó, và cũng không có thẻ repeat nào. "<core:for>" cũng là tên tự đặt; dù có khai tiền tố trỏ đúng địa chỉ thư viện lõi thì vẫn không có thẻ tên for để container tìm thấy.

Đáp án đúng: "To manage a pool of database connections". DataSource là lớp trừu tượng thay cho việc tự gọi DriverManager: ứng dụng tra đối tượng này qua JNDI rồi xin một kết nối, còn phía sau container giữ sẵn một tập kết nối đang mở, cho vay khi cần và nhận lại khi kết nối được đóng. Nhờ vậy mỗi lượt gọi không phải trả giá mở kết nối mới, và thông tin máy chủ cùng tài khoản nằm trong cấu hình chứ không rải trong mã. Lựa chọn "To store and retrieve session data" là việc của phiên và các thuộc tính trong đó, không dính tới tầng kết nối. Lựa chọn "To define the structure of a database table" thuộc các lệnh định nghĩa dữ liệu phía cơ sở dữ liệu, không phải của một đối tượng cấp kết nối. Lựa chọn "To execute SQL queries" chỉ sai đối tượng: câu lệnh chạy bằng Statement hoặc PreparedStatement lấy từ một Connection, mà Connection mới là thứ DataSource trả về.

Đáp án đúng: "BatchStatement". JDBC chỉ định nghĩa ba giao diện cho câu lệnh, kế thừa nhau theo thứ tự Statement, PreparedStatement rồi CallableStatement; không có giao diện nào mang tên gộp nhiều câu lệnh như vậy. Việc gửi nhiều câu lệnh trong một lượt cũng không cần kiểu riêng, nó là khả năng sẵn có của các giao diện trên qua addBatch() cùng executeBatch(). "PreparedStatement" là kiểu hợp lệ và được khuyên dùng, vì câu lệnh có tham số dấu hỏi nên được chuẩn bị trước và chặn được tiêm mã truy vấn. "CallableStatement" cũng hợp lệ, dành cho việc gọi thủ tục hay hàm trong cơ sở dữ liệu, có thêm tham số chiều ra. "Statement" là kiểu cơ bản nhất, nhận câu lệnh dạng chuỗi ghép sẵn, vẫn hợp lệ dù dễ gặp rủi ro khi ghép dữ liệu người dùng vào chuỗi.