Tất cả câu hỏi

Đáp án đúng: "doGet(HttpServletRequest request, HttpServletResponse response)". Một liên kết trên trang khi được bấm sẽ khiến trình duyệt phát yêu cầu GET tới đường dẫn trong thuộc tính href, tham số đi kèm nằm trong query string; container nhận yêu cầu, gọi service() và service() căn cứ vào phương thức HTTP để phân phát, nên đúng nhánh doGet() được gọi và đọc tham số bằng request.getParameter(). Lựa chọn dùng "doPost(HttpServletRequest request, HttpServletResponse response)" chỉ chạy khi form khai method là post hoặc khi mã phía người dùng tự phát yêu cầu POST, bấm liên kết không sinh ra POST. Lựa chọn dùng "doPut(HttpServletRequest request, HttpServletResponse response)" tương ứng với phương thức PUT, trình duyệt không phát PUT từ liên kết hay form thường. Lựa chọn dùng "doDelete(HttpServletRequest request" tương ứng với DELETE, cũng không phải thứ sinh ra khi bấm một liên kết, nếu không ghi đè thì container trả về lỗi phương thức không được hỗ trợ.

Đáp án đúng: "Database table schema". Deployment descriptor là nơi khai những gì container cần biết để chạy ứng dụng web, còn cấu trúc bảng của cơ sở dữ liệu thuộc về chính cơ sở dữ liệu và được tạo bằng câu lệnh DDL hoặc công cụ migration; container không đọc và cũng không hiểu định nghĩa bảng. "Servlet and URL mapping" là nội dung điển hình của tệp này, cặp khai servlet và mẫu đường dẫn chính là cách container định tuyến yêu cầu. "Initialization parameters" cũng được khai ở đây, dưới dạng tham số riêng của một servlet hoặc tham số chung của toàn ứng dụng, rồi đọc lại bằng getInitParameter(). "Filter configuration" cũng thuộc tệp này: khai lớp filter và mẫu đường dẫn mà nó chặn, thứ tự khai còn quyết định thứ tự các filter nối thành chuỗi.

Đáp án đúng: "The deployment descriptor is located in the WEB-INF directory of the web application.". Tên thư mục này là một phần của khuôn dạng ứng dụng web nên viết đúng từng ký tự mới có hiệu lực: container tìm tệp cấu hình ở đúng WEB-INF, đồng thời chặn mọi yêu cầu từ trình duyệt vào thư mục đó nên cấu hình và lớp biên dịch không bị tải về. Lựa chọn ghi "WEB-INFS directory of the web application" sai vì thêm chữ S, container coi đây là một thư mục thường, cấu hình sẽ không được đọc mà lại nằm trong vùng công khai. Lựa chọn ghi "WEBS-INF directory of the web application" sai tương tự, phần đầu phải là WEB chứ không phải WEBS. Lựa chọn ghi "WEBS directory of the web application" sai vì mất hẳn phần INF, cái tên đó không có nghĩa gì với container và tệp cấu hình sẽ bị bỏ qua hoàn toàn.

Đáp án đúng: "Executing server-side Java code (Servlets)". Việc chính của servlet container là quản vòng đời và chạy mã Java phía server: nạp lớp servlet, gọi init(), cấp luồng cho từng yêu cầu rồi gọi service() để phân phát sang doGet() hay doPost(), dựng đối tượng request và response, quản phiên, và gọi destroy() khi tháo ứng dụng. "Handling static resources like HTML and CSS" là việc một web server thuần cũng làm được và container có làm kèm, nhưng đó là phần phụ chứ không phải lý do container tồn tại. "Managing database connections" là việc của mã ứng dụng hoặc của một pool được khai báo riêng, container chỉ cung cấp chỗ tra cứu chứ không phải nhiệm vụ chính. "Running JavaScript code on the client-side" sai hẳn về nơi chạy: mã phía người dùng do trình duyệt thực thi, server không can dự.

Đáp án đúng: "/WEB-INF". Deployment descriptor phải nằm ngay trong WEB-INF của ứng dụng web vì đây là thư mục mà container đọc để lấy cấu hình servlet, filter, listener và tham số khởi tạo, đồng thời là thư mục trình duyệt không thể yêu cầu trực tiếp nên tệp cấu hình không bị phơi ra ngoài. "/META-INF" là nơi giữ thông tin đóng gói của tệp nén, ví dụ manifest và cấu hình ngữ cảnh của một số container, chứ không phải nơi đặt descriptor của ứng dụng web. "/WEB-INF/classes" là nơi chứa lớp đã biên dịch cùng tệp tài nguyên như properties, nếu đặt descriptor ở đây container sẽ không tìm thấy. "Root directory" sai vì thư mục gốc chứa những thứ phục vụ công khai như trang JSP, HTML, ảnh và CSS, đặt tệp cấu hình ở đó là để lộ cấu hình cho người dùng tải về.

Đáp án đúng: "Attributes are lost". sendRedirect() trả cho trình duyệt một phản hồi chuyển hướng kèm header Location, trình duyệt tự mở một yêu cầu HTTP thứ hai tới result.jsp, và container dựng một đối tượng HttpServletRequest hoàn toàn mới cho yêu cầu đó; attribute vừa đặt chỉ sống trong đối tượng yêu cầu cũ nên trang đích không đọc được. Muốn giữ dữ liệu thì forward để ở lại trong cùng một yêu cầu, hoặc đặt vào session, hoặc nối vào query string. "Attributes are retained" là hành vi của forward qua RequestDispatcher chứ không phải của chuyển hướng. "They are automatically sent to the next page" sai vì phản hồi chuyển hướng chỉ mang địa chỉ mới, không mang theo attribute nào. "They are converted to session attributes" sai vì container không bao giờ tự nâng phạm vi của attribute, muốn lên phiên thì phải tự gọi setAttribute() trên session.

Đáp án đúng: "GET exposes sensitive data in the URL.". Với GET, tham số được nối vào query string nên chúng hiện trên thanh địa chỉ và còn đọng lại trong lịch sử trình duyệt, trong bookmark, trong header Referer và trong log của web server hay proxy; đó là lý do không đặt mật khẩu hoặc số thẻ vào GET. "GET encrypts data, ensuring secure transmission." sai vì không phương thức HTTP nào tự mã hoá dữ liệu, việc mã hoá do lớp TLS của HTTPS làm và nó bảo vệ GET với POST như nhau. "POST is more suitable for secure data transfer." có phần hợp lý ở chỗ POST đặt dữ liệu trong body nên không phơi ra URL, nhưng nó nói về POST chứ không trả lời cách GET xử lý dữ liệu nhạy cảm, và bản thân POST cũng không mã hoá gì. "GET can handle larger data volumes than POST." sai vì ngược lại: độ dài URL bị trình duyệt và server giới hạn, còn POST đặt dữ liệu trong body nên chứa được nhiều hơn.

Đáp án đúng: "Both A and D is true". Một phản hồi HTTP gồm dòng trạng thái mang mã kết quả, khối header, rồi phần body, nên hai mô tả về mã kết quả cùng header và về body cùng header đều đúng một phần và chỉ lựa chọn gộp cả hai mới kể đủ cấu trúc. "A result code and Header fields" đúng ở mã kết quả và header nhưng bỏ mất body, nơi chứa nội dung thật sự trả về. "Body and Header fields" đúng ở body và header nhưng bỏ mất mã kết quả, thứ cho trình duyệt biết yêu cầu thành công, bị chuyển hướng hay lỗi. "A request code and response code" sai vì phản hồi không mang mã của yêu cầu, bản thân yêu cầu cũng không có mã mà chỉ có phương thức và đường dẫn. "Body and ACK flag" sai vì ACK là cờ của tầng vận chuyển TCP, nằm ngoài khuôn dạng thông điệp HTTP. "All of above" sai vì nó gộp luôn cả hai mô tả không đúng vừa nêu.

Đáp án đúng: "The variable to store the formatted message". Thuộc tính var của thẻ định dạng thông điệp đổi hành vi xuất: thay vì in ngay chuỗi đã tra được ra trang, thẻ cất chuỗi đó vào một biến phạm vi theo tên đã đặt để sau đó đọc lại bằng Expression Language hoặc truyền sang thẻ khác, và thuộc tính scope đi kèm quyết định biến nằm trong page, request, session hay application. "The name of the internationalization bundle" là việc của thẻ nạp bundle hoặc của cấu hình bundle mặc định, không phải của var. "The message key to look up in the resource bundle" là vai trò của thuộc tính key, tức chuỗi dùng để tra trong tệp properties. "The scope of the message variable" là vai trò của thuộc tính scope, nó chỉ có nghĩa khi đã có var và không tự nó quyết định tên biến.

Đáp án đúng: "stmt.executeUpdate()". Với các câu lệnh làm thay đổi dữ liệu như INSERT, UPDATE hay DELETE, JDBC dùng executeUpdate() và chính nó trả về một số nguyên là số dòng bị ảnh hưởng, nên không cần hỏi thêm phương thức nào khác; executeQuery() thì dành cho SELECT và trả về ResultSet, còn execute() trả về boolean cho biết kết quả là bảng dữ liệu hay là số đếm. "stmt.getAffectedRows()" không tồn tại trong giao diện Statement, số dòng đã nằm ngay trong giá trị trả về của lệnh thực thi. "stmt.countRows()" cũng không có; muốn đếm dòng trong bảng thì phải tự viết một câu SELECT COUNT chứ không có phương thức sẵn. "stmt.getRowCount()" là tên nghe hợp lý nhưng không thuộc giao diện Statement; con số dòng đọc được của một ResultSet cũng phải tự đếm khi duyệt.

Đáp án đúng: "Context initialization". ServletContextListener là listener của phạm vi ứng dụng: contextInitialized() chạy một lần sau khi container dựng xong ServletContext và trước khi yêu cầu đầu tiên được phục vụ, contextDestroyed() chạy khi ứng dụng bị tháo, nên các việc như nạp cấu hình chung hay mở pool kết nối được đặt ở đây. "Session creation" là sự kiện của phạm vi phiên, do HttpSessionListener nghe qua sessionCreated(). "Request handling" thuộc phạm vi một yêu cầu, do ServletRequestListener hoặc chính servlet và filter xử lý, không phải việc của listener ứng dụng. "Form submission" là hành vi phía trình duyệt, tới server nó chỉ là một yêu cầu GET hay POST bình thường và không sinh ra sự kiện listener riêng nào. "None of the others" sai vì khởi tạo ngữ cảnh đúng là sự kiện mà giao diện này nghe.

Đáp án đúng: "HttpSessionAttributeListener". Đây là listener nghe trên dữ liệu đặt trong phiên: container gọi attributeAdded() khi một thuộc tính được đặt lần đầu, attributeReplaced() khi giá trị cũ bị ghi đè và attributeRemoved() khi thuộc tính bị gỡ, nên muốn theo dõi giá trị của biến trong session đổi ra sao thì dùng đúng giao diện này. "HttpSessionListener" chỉ nghe việc phiên được tạo và bị phá qua sessionCreated() và sessionDestroyed(), tức là vòng đời của phiên chứ không phải nội dung bên trong nó. "ServletContextListener" nghe vòng đời của toàn ứng dụng, chạy lúc ServletContext khởi tạo và lúc bị tháo, không liên quan tới phiên. "ServletRequestListener" nghe một yêu cầu vào và ra khỏi phạm vi xử lý, phạm vi này ngắn hơn phiên và cũng không báo gì về thay đổi giá trị trong session.

Đáp án đúng: "request.getSession(true)". Phương thức này tìm định danh phiên mà trình duyệt gửi kèm trong cookie JSESSIONID hoặc trong đường dẫn; nếu phiên còn hợp lệ thì trả về đúng phiên đó, nếu không thì container tạo phiên mới và gắn cookie trả về, nên dạng không tham số getSession() hành xử y như vậy còn getSession(false) trả về null thay vì tạo mới. "request.newSession(true)" không tồn tại trong HttpServletRequest, và cái tên này còn ngụ ý luôn tạo phiên mới nên sẽ làm mất dữ liệu phiên đang có. "request.getHttpSession()" cũng không có trong giao diện; HttpSession là tên kiểu trả về chứ không nằm trong tên phương thức. "sessionManager.get()" giả định ứng dụng tự giữ một đối tượng quản lý phiên, trong khi vòng đời phiên do container quản và chỉ truy cập được thông qua đối tượng yêu cầu.

Đáp án đúng: "UPDATE". Tập phương thức mà HTTP 1.1 định nghĩa gồm GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE và CONNECT; không có phương thức nào tên UPDATE, việc sửa dữ liệu trên server được làm bằng PUT khi thay trọn tài nguyên hoặc bằng POST khi gửi dữ liệu cho server tự xử lý. "GET" là phương thức đọc tài nguyên và là mặc định của trình duyệt nên chắc chắn thuộc tập chuẩn. "HEAD" cũng có trong đặc tả, hành xử như GET nhưng chỉ trả về phần header mà không có body, thường dùng để kiểm tra tài nguyên còn sống hay đã đổi. "PUT" có trong đặc tả, dùng để ghi hoặc thay thế tài nguyên tại đúng đường dẫn đã chỉ. "POST" có trong đặc tả, đặt dữ liệu trong body để server xử lý và là phương thức của form gửi dữ liệu. "DELETE" cũng có trong đặc tả, yêu cầu xoá tài nguyên tại đường dẫn đó.

Đáp án đúng: "CallableStatement". CallableStatement là nhánh con của PreparedStatement dành riêng cho thủ tục và hàm trong cơ sở dữ liệu: câu lệnh viết theo cú pháp gọi thủ tục với dấu chấm hỏi làm chỗ giữ, prepareCall() tạo ra đối tượng, registerOutParameter() khai các tham số trả ra, rồi đọc giá trị ra sau khi thực thi. "Statement" chỉ gửi đi một câu SQL đã ghép sẵn thành văn bản, không có chỗ giữ tham số và không khai được tham số trả ra nên không gọi được thủ tục có tham số OUT. "PreparedStatement" có chỗ giữ tham số và được biên dịch trước, nhưng chỉ phục vụ câu SQL thường và cũng không khai báo được tham số trả ra. "ResultSet" không phải câu lệnh mà là con trỏ để đọc bảng kết quả sau khi một câu lệnh đã chạy xong.

Đáp án đúng: "Both of the above.". Câu hỏi gộp hai mệnh đề về cùng một phương thức và cả hai đều đứng vững: ở phía server, service() nhận yêu cầu rồi gọi lại doGet() để servlet xử lý yêu cầu GET; ở phía client, GET là phương thức mặc định khi trình duyệt mở một liên kết hoặc gửi form không khai thuộc tính method, nên chỉ lựa chọn gộp mới trả lời trọn vẹn. "Called by the server (via the service method)to allow a servlet to handle a GET request." chỉ mô tả nửa phía container và bỏ mất hành vi mặc định của trình duyệt. "The GET method is the default method to pass information from browser to web server." chỉ mô tả nửa phía client, không nói gì tới cách servlet nhận được yêu cầu đó. "None of the above." sai vì hai mệnh đề trên đều là mô tả đúng của GET.

Đáp án đúng: "init()". Filter có vòng đời ba bước do container điều khiển: init(FilterConfig) được gọi đúng một lần ngay sau khi container tạo thực thể filter và trước khi yêu cầu đầu tiên đi qua, doFilter() chạy cho từng yêu cầu khớp mẫu ánh xạ, destroy() chạy khi ứng dụng bị tháo; vì vậy nơi đọc tham số khởi tạo hay mở tài nguyên dùng lâu dài chính là init(). "initFilter()" không nằm trong giao diện Filter, đặt tên này thì container không bao giờ gọi tới và tham số khởi tạo sẽ không được đọc. "initialize()" cũng không thuộc hợp đồng của Filter, đây là tên quen thấy ở nơi khác chứ không phải trong đặc tả servlet. "setupFilter()" tương tự là tên tự đặt; container chỉ gọi đúng chữ ký khai trong giao diện mà lớp filter cài đặt nên một tên gần nghĩa vẫn bị bỏ qua hoàn toàn.

Đáp án đúng: "String getInitParameter(String name)". Cả ServletConfig và ServletContext đều khai getInitParameter(String) trả về String, đọc giá trị khai trong phần tử init-param của một servlet hoặc trong context-param dùng chung cho toàn ứng dụng; mọi tham số khởi tạo đều là văn bản nên kiểu trả về luôn là String, muốn số thì phải tự chuyển kiểu, và phương thức đi kèm để liệt kê tên là getInitParameterNames(). "String getInitializedParameter(String name)" sai tên vì đặc tả dùng dạng viết tắt Init, container không có phương thức nào tên như vậy nên lời gọi sẽ không biên dịch được. "String getContextParameter(String name)" sai vì đổi phạm vi không đổi tên phương thức, tham số của toàn ứng dụng vẫn đọc bằng getInitParameter() nhưng gọi trên ServletContext. "String getBoolParameter(String name)" sai hai chỗ: không có phương thức này và tham số khởi tạo không hề có biến thể theo kiểu dữ liệu.

Đáp án đúng: "contextInitialized()". Giao diện ServletContextListener chỉ có hai phương thức: contextInitialized(ServletContextEvent) chạy sau khi container dựng xong ServletContext và trước khi servlet hay filter nào phục vụ yêu cầu đầu tiên, còn contextDestroyed() chạy lúc ứng dụng bị tháo; vì vậy đây là chỗ hợp lý để nạp cấu hình chung hoặc mở sẵn pool kết nối. "contextCreated()" không có trong giao diện, đặt tên này kèm chú giải ghi đè thì mã không biên dịch được, còn nếu bỏ chú giải thì container không bao giờ gọi tới. "initContext()" cũng không thuộc hợp đồng của listener; chữ init ở đây dễ bị lẫn với init() của servlet và filter, hai phương thức thuộc vòng đời thành phần khác hẳn. "initializeContext()" tương tự là tên tự đặt; container chỉ gọi đúng chữ ký khai trong giao diện đã đăng ký nên một tên gần đúng vẫn bị bỏ qua.