Tất cả câu hỏi

Ngân hàng câu hỏi trắc nghiệm có giải thích chi tiết.

620/11.885 câuCòn 11.265
ABy making the service() method synchronized
BBy creating a new thread for each request
CBy using the Singleton design pattern
DBy using the wait() and notify() methods
Lời giải
Đáp án đúng: "By creating a new thread for each request". Container chỉ nạp một thực thể duy nhất của mỗi servlet, nhưng mỗi yêu cầu HTTP đi vào lại được cấp một luồng lấy từ thread pool để chạy service() rồi phân phát sang doGet() hay doPost(), nhờ vậy nhiều yêu cầu chạy song song trên cùng thực thể đó, biến cục bộ trong phương thức là riêng của từng luồng và chỉ biến thực thể hay dữ liệu đặt trong ServletContext mới phải tự đồng bộ. "By making the service() method synchronized" làm điều ngược lại: thực thể servlet duy nhất trở thành chốt chung nên các yêu cầu phải xếp hàng chờ nhau, đó là cách hy sinh tính đồng thời chứ không phải cách tạo ra nó. "By using the Singleton design pattern" chỉ nói tới việc có đúng một thực thể, không giải thích bằng cơ chế nào mà một thực thể phục vụ được nhiều yêu cầu cùng lúc. "By using the wait() and notify() methods" là cặp lệnh để các luồng do lập trình viên tự tạo chờ và báo nhau trong mã nghiệp vụ, container không dùng chúng để tiếp nhận yêu cầu mới.
Mở trang câu hỏi này →
ACookies
BWeb server
CApplication server
DDatabase server
Lời giải
Đáp án đúng: "Cookies". Dữ liệu phiên thật sự nằm phía máy chủ, nhưng thứ được giữ trên máy khách là mẩu dữ liệu nhỏ mà máy chủ gửi về rồi trình duyệt lưu lại và gửi kèm mỗi lượt yêu cầu sau đó, điển hình là mã định danh phiên; trong các lựa chọn, đây là thứ duy nhất nằm ở phía người dùng. Lựa chọn "Web server" nói về phía máy chủ: đối tượng phiên nằm trong bộ nhớ của tiến trình máy chủ web, người dùng không giữ bản nào. Lựa chọn "Application server" cũng ở phía máy chủ, là nơi container quản lý vòng đời và thời gian chờ của phiên. Lựa chọn "Database server" có thể được dùng để lưu bền hoặc nhân bản phiên trong hệ thống nhiều máy, nhưng đó vẫn là lưu trữ phía máy chủ, hoàn toàn không phải phía máy khách.
Mở trang câu hỏi này →
Đề bài
<a href="logoutServlet">Logout</a>

When the client clicks the logout link, the following code in the logoutServlet runs:

Đề bài
  HttpSession session = request.getSession();
//TODO
  response.sendRedirect("login.jsp");

What is the best code to write in the TODO section to complete the logout function?

Asession.removeAll();
Bsession.getAttribute(“USER”).remove();
Csession.removeAttribute(“USER”);
Dsession.invalidate();
Eif(session.getAtriibute(“USER”)!=null) session.remove(“USER”);
Fsession.remove();
Lời giải

Đáp án đúng: "session.invalidate(); ". Lời gọi này huỷ cả phiên phía máy chủ: mọi thuộc tính bị bỏ và mã định danh cũ không còn hiệu lực, nên sau khi chuyển hướng về trang đăng nhập thì các trang như trang hồ sơ hay trang lịch sử đơn không đọc lại được dữ liệu người dùng cũ, kể cả khi người dùng bấm nút lùi. Lời gọi "session.removeAll(); " không biên dịch được vì giao diện phiên không có phương thức tên đó. Lời gọi "session.getAttribute(“USER”).remove(); " sai hai lẽ: thứ trả về là một vật thể chung không có phương thức này, và khi chưa đăng nhập thì giá trị rỗng sẽ gây ngoại lệ con trỏ rỗng. Lời gọi "session.removeAttribute(“USER”); " chạy được nhưng chỉ bỏ một thuộc tính, phiên vẫn sống cùng các thuộc tính khác nên chưa phải đăng xuất dứt điểm. Dòng "

Lời giải
if(session.getAtriibute(“USER”)!=null) session.remove(“USER”);

" dùng hai tên hàm không có trong giao diện phiên, lại viết sai chính tả, nên không biên dịch được. Lời gọi "session.remove(); " cũng vậy, không tồn tại trong giao diện phiên.

Mở trang câu hỏi này →
Arequest
Bresponse
Csession
Dapplication
Lời giải
Đáp án đúng: "request". Đối tượng ẩn này do container truyền vào mỗi lượt gọi trang, đại diện cho chính lượt yêu cầu của máy khách, nhờ đó trang đọc được tham số, tiêu đề, phương thức HTTP và cả những thuộc tính mà servlet đặt vào trước khi chuyển tiếp sang trang. Đối tượng "response" đi cùng nhưng ở chiều ngược lại: nó dùng để đặt kiểu nội dung, tiêu đề và ghi dữ liệu trả về cho máy khách. Đối tượng "session" đại diện cho phiên làm việc của một người dùng, sống qua nhiều lượt yêu cầu, nên không phải hình ảnh của một lượt gọi cụ thể. Đối tượng "application" ứng với ngữ cảnh của cả ứng dụng, dùng chung cho mọi người dùng và mọi lượt gọi, là phạm vi rộng nhất trong các đối tượng ẩn của trang.
Mở trang câu hỏi này →
A${product.stockPerStore["store101"]}
B${product.stockPerStore.store101}
C${product.stockPerStore.get("store101")}
D${product.stockPerStore["store101"].value}
Lời giải

Đáp án đúng: "${product.stockPerStore["store101"]}". Trong EL, toán tử ngoặc vuông là cách tổng quát để tra một bản đồ: giá trị trong ngoặc được coi là khoá, nên biểu thức này lấy đúng phần tử ứng với khoá đã nêu rồi in ra số lượng tồn. Cách viết "${product.stockPerStore.store101}" cũng tra được bản đồ, nhưng chỉ khi tên khoá là một định danh hợp lệ, nên nó phụ thuộc hình dạng khoá chứ không phải lối truy cập chung cho mọi khoá, ví dụ khoá có dấu cách hoặc mở đầu bằng chữ số. Cách viết "${

Lời giải
product.stockPerStore.get("store101")
}
"

gọi thẳng phương thức Java, chỉ chạy trên bản EL có hỗ trợ gọi phương thức, lại đi đường vòng qua chính toán tử tra khoá đã có sẵn. Cách viết "${product.stockPerStore["store101"].value}" thêm một bước đọc thuộc tính trên giá trị trả về, mà giá trị đó là một số nguyên bọc, không có hàm đọc thuộc tính mang tên ấy, nên biểu thức không ra kết quả.

Mở trang câu hỏi này →
Đề bài
<context-param> tag in the web.xml file?
  <web-app>
    <context-param>
      <param-name>studentName</param-name>
      <param-value>abcJhn</param-value>
    </context-param>

</web-app>

Arequest.getParameter("studentName");
BServletContext sc = getServletContext(); String serverName = sc.getInitParameter("studentName");
CServletConfig sc = getServletConfig(). String serverName = sc.getInitParameter("studentName");
Dresponse.getParameter("studentName");
Lời giải

Đáp án đúng: "ServletContext sc = getServletContext(); String serverName = sc.getInitParameter("studentName"); ". Khai báo tham số nằm trực tiếp trong phần tử gốc của mô tả triển khai, không lồng trong khai báo của một servlet nào, nên nó là tham số khởi tạo của cả ứng dụng và chỉ vật thể ngữ cảnh ứng dụng đọc được, lấy bằng lời gọi trong servlet rồi hỏi theo tên. Dòng "request.getParameter("studentName"); " đọc tham số của lượt yêu cầu, tức dữ liệu từ chuỗi truy vấn hay biểu mẫu, nên luôn trả về giá trị rỗng với tham số khai trong tệp cấu hình. Đoạn "ServletConfig sc = getServletConfig()." sai hai lẽ: vật thể cấu hình chỉ thấy tham số khởi tạo khai riêng bên trong khai báo của chính servlet đó, và dòng lại kết thúc bằng dấu chấm nên mã không biên dịch được. Dòng "response.getParameter("studentName"); " sai vì đối tượng phản hồi chỉ dùng để ghi kết quả trả về, nó không có hàm đọc tham số nào.

Mở trang câu hỏi này →
ASet custom error pages for specific exceptions
BDefine error codes for server-side exceptions
CConfigure error log settings
DRedirect errors to the homepage
Lời giải
Đáp án đúng: "Set custom error pages for specific exceptions". Phần tử này trong mô tả triển khai nối một điều kiện lỗi với một trang hiển thị riêng: điều kiện có thể là kiểu ngoại lệ nêu theo tên lớp, hoặc một mã trạng thái HTTP, và khi điều kiện xảy ra container chuyển tiếp nội bộ sang trang đã chỉ định. Mô tả "Define error codes for server-side exceptions" nói ngược chiều: mã lỗi là mã của giao thức, khai báo chỉ dùng lại mã có sẵn để nhận diện tình huống, chứ không định nghĩa mã mới. Mô tả "Configure error log settings" thuộc cấu hình ghi log của máy chủ hoặc của thư viện ghi log, nằm ngoài mô tả triển khai ứng dụng. Mô tả "Redirect errors to the homepage" sai cả đích lẫn cơ chế: đích là trang lỗi do người triển khai chỉ định, và container chuyển tiếp bên trong máy chủ chứ không bắt trình duyệt gọi lại địa chỉ khác.
Mở trang câu hỏi này →
ABy extending the BodyTagSupport class.
BBy implementing the BodyTag interface directly.
CBy extending the TagSupport class.
DBy implementing the Tag interface directly.
Lời giải
Đáp án đúng: "By extending the BodyTagSupport class.". Lớp tiện ích này đã hiện thực sẵn giao diện xử lý thân thẻ cùng các phương thức vòng đời và hai hàm nhận ngữ cảnh trang, lại giữ hộ vật thể chứa thân thẻ, nên người viết thẻ chỉ cần ghi đè vài phương thức như xử lý khi mở thẻ, sau mỗi lượt đọc thân và khi đóng thẻ. Cách "By implementing the BodyTag interface directly." về nguyên tắc cũng dẫn tới đúng giao diện đó nhưng buộc tự viết đủ mọi phương thức, kể cả phần nhận ngữ cảnh trang và thẻ cha, nên là lối làm thủ công chứ không phải cách thông thường mà câu hỏi nhắm tới. Cách "By extending the TagSupport class." không đạt vì lớp đó chỉ hiện thực nhánh giao diện lặp, thiếu hẳn các phương thức nhận và xử lý thân thẻ. Cách "By implementing the Tag interface directly." còn thiếu hơn nữa: giao diện gốc này không khai phương thức nào để nhận nội dung thân thẻ.
Mở trang câu hỏi này →
A${param.user}
B${requestScope.user}
C${sessionScope.user}
D${applicationScope.user}
E${request.user}
F${request.param.user}
Lời giải
Đáp án đúng: "${param.user}". EL có sẵn một bản đồ ẩn tên param, mỗi khoá là tên tham số của lượt yêu cầu và giá trị là chuỗi đầu tiên tương ứng, nên viết như vậy tương đương việc gọi hàm đọc tham số trên đối tượng yêu cầu. Biểu thức "${requestScope.user}" tra vùng thuộc tính của lượt yêu cầu, tức thứ do mã đặt vào bằng lệnh gán thuộc tính, chứ không phải tham số gửi lên. Biểu thức "${sessionScope.user}" tra thuộc tính lưu trong phiên, sống qua nhiều lượt gọi. Biểu thức "${applicationScope.user}" tra thuộc tính ở phạm vi toàn ứng dụng, dùng chung cho mọi người dùng. Biểu thức "${request.user}" không chạy vì EL không có đối tượng ẩn mang tên đó, muốn tới đối tượng yêu cầu phải đi qua ngữ cảnh trang. Biểu thức "${request.param.user}" sai vì cả hai lẽ trên: tên mở đầu không phải đối tượng ẩn của EL, và bản đồ tham số không phải thuộc tính của đối tượng yêu cầu.
Mở trang câu hỏi này →
610Consider the following code:4 lựa chọncó code
Đề bài
protected void doPost(HttpServletRequest req,
                      HttpServletResponse res)
               throws ServletException, IOException {
         String user = req.getParameter("username");
         res.getWriter().println("User: " + user);
}

Which of the following statements is the most incorrect?

AThe code handles POST requests.
BThe code may return "User: null" if the username parameter is not provided.
CgetParameter("username") retrieves the value from the URL query string.
DgetWriter().println() is used to send a response back to the client.
Lời giải
Đáp án đúng: "getParameter("username") retrieves the value from the URL query string.". Hàm đọc tham số không phân biệt nguồn: nó gộp tham số trong chuỗi truy vấn của địa chỉ với tham số nằm trong thân yêu cầu đã mã hoá theo dạng biểu mẫu; đoạn mã ở đây phục vụ lượt gửi dữ liệu lên, nơi dữ liệu biểu mẫu nằm trong thân, nên khẳng định giá trị được lấy từ chuỗi truy vấn là chỗ sai nhất. Nhận định "The code handles POST requests." lại đúng, vì phương thức được viết chính là phương thức phục vụ lượt gửi dữ liệu. Nhận định "The code may return "User: null" if the username parameter is not provided." cũng đúng: không có tham số thì hàm trả về giá trị rỗng và phép nối chuỗi in ra chữ null. Nhận định "getWriter().println() is used to send a response back to the client." đúng nữa, vì bộ ghi lấy từ phản hồi ghi thẳng vào thân phản hồi trả về cho máy khách.
Mở trang câu hỏi này →
ARedirects all errors to error.jsp
BHandles errors by including error.jsp
CDeclares a default error page for the entire application
DHas no effect in JSP
Lời giải
Đáp án đúng: "Redirects all errors to error.jsp". Chỉ thị này khai cho riêng trang chứa nó một trang nhận lỗi: khi trang sinh ra ngoại lệ không được bắt, container dừng việc dựng phản hồi và đưa lượt yêu cầu sang trang đã khai, nơi thường bật thuộc tính tự nhận là trang lỗi để đọc được vật thể ngoại lệ, nên nói nó dồn mọi lỗi của trang sang trang kia là mô tả sát nhất. Mô tả "Handles errors by including error.jsp" nói sai cơ chế: chèn thì nội dung trang lỗi được ghép vào phản hồi đang dở, còn ở đây trang lỗi thay hẳn kết quả. Mô tả "Declares a default error page for the entire application" nhầm phạm vi: chỉ thị page chỉ có hiệu lực trong một trang, muốn áp cho toàn ứng dụng thì phải khai trang lỗi trong mô tả triển khai. Mô tả "Has no effect in JSP" sai hẳn vì đây là một thuộc tính chuẩn của chỉ thị page.
Mở trang câu hỏi này →
A@WebServlet
B@ServletMapping
C@RequestMapping
D@ServletConfig
Lời giải
Đáp án đúng: "@WebServlet". Từ bản đặc tả có hỗ trợ chú giải, đặt chú giải này trên lớp servlet kèm mẫu đường dẫn là đủ để container quét lúc khởi động rồi tự đăng ký ánh xạ, nên không cần khai cặp phần tử khai báo servlet và phần tử ánh xạ trong mô tả triển khai nữa. Chú giải "@ServletMapping" không tồn tại trong đặc tả; phần ánh xạ nằm luôn trong thuộc tính giá trị hoặc thuộc tính mẫu đường dẫn của chú giải đúng. Chú giải "@RequestMapping" là của khung Spring MVC, dùng để nối phương thức trong lớp điều khiển với đường dẫn, không phải cơ chế của đặc tả servlet. Còn "@ServletConfig" chỉ là tên nhái theo giao diện cấu hình servlet vốn dùng để đọc tham số khởi tạo; giao diện đó không phải chú giải và không khai được ánh xạ nào.
Mở trang câu hỏi này →
Ainit()
Bservice()
Cdestroy()
DdoGet()
EdoPost()
Lời giải
Đáp án đúng: "service()". Đây là điểm vào duy nhất mà container gọi cho mỗi lượt yêu cầu tới servlet; nó chạy lại trong từng lượt rồi mới đọc phương thức HTTP để phân nhánh, nên số lần chạy của nó bằng tổng số lượt yêu cầu và luôn lớn hơn hoặc bằng mọi phương thức khác. Phương thức "init()" chỉ chạy đúng một lần trong cả vòng đời, lúc container nạp và khởi tạo servlet. Phương thức "destroy()" cũng chỉ một lần, khi servlet bị tháo khỏi bộ nhớ. Phương thức "doGet()" chạy nhiều lần nhưng chỉ cho những lượt yêu cầu dùng phương thức đọc, nên luôn ít hơn tổng số lượt. Phương thức "doPost()" cũng vậy, chỉ nhận phần lượt gửi dữ liệu lên, mà phần này trong ứng dụng thường còn nhỏ hơn phần đọc.
Mở trang câu hỏi này →
ATo define the structure of a web page.
BTo handle HTTP requests and responses.
CTo specify the default error page for the entire web application.
DTo map a specific HTTP error code to a designated error page.
Lời giải
Đáp án đúng: "To map a specific HTTP error code to a designated error page.". Trong mô tả triển khai, một khai báo trang lỗi nhận diện tình huống theo một trong hai lối: theo mã trạng thái hoặc theo kiểu ngoại lệ; phần tử được hỏi chính là lối thứ nhất, nó ghi một mã cụ thể rồi gắn mã đó với đường dẫn trang mà container sẽ chuyển tới khi phản hồi mang mã ấy. Mô tả "To define the structure of a web page." thuộc việc của HTML và trang hiển thị, không phải của cấu hình triển khai. Mô tả "To handle HTTP requests and responses." là việc của servlet; cấu hình chỉ nói cho container biết phải làm gì khi có lỗi, bản thân nó không xử lý lượt gọi nào. Mô tả "To specify the default error page for the entire web application." lại bỏ mất chính vai của mã lỗi: khai bao trùm cho cả ứng dụng thì phải nhận diện theo kiểu ngoại lệ chung, còn khai theo mã thì chỉ áp cho đúng mã đã ghi.
Mở trang câu hỏi này →
A/WEB-INF/lib
B/WEB-INF/classes
C/META-INF
DRoot directory
Lời giải
Đáp án đúng: "/WEB-INF/lib". Container tự đưa mọi tệp jar nằm trong thư mục này vào đường nạp lớp của ứng dụng khi triển khai, nên đây là chỗ đặt thư viện ngoài như trình điều khiển JDBC hay thư viện thẻ, và vì nằm dưới WEB-INF nên trình duyệt không tải về được. Thư mục "/WEB-INF/classes" cũng thuộc đường nạp lớp nhưng dành cho lớp đã biên dịch của chính ứng dụng, xếp theo cây gói, không phải cho gói jar. Thư mục "/META-INF" giữ siêu dữ liệu của gói như tệp kê khai hay cấu hình ngữ cảnh riêng của máy chủ, và không được nạp vào đường nạp lớp. Còn "Root directory" là gốc nội dung web, nơi đặt trang và tài nguyên tĩnh phục vụ trực tiếp cho trình duyệt; để jar ở đó thì vừa không được nạp vừa có nguy cơ bị tải xuống.
Mở trang câu hỏi này →
AdoGet
BdoPost
CdoFilter
Dservice
Einit
Lời giải
Đáp án đúng: "doFilter". Mọi bộ lọc đều phải hiện thực phương thức này vì đó là chỗ container trao cặp yêu cầu, phản hồi cùng tham chiếu chuỗi bộ lọc; cho chuỗi đi tiếp thì lượt yêu cầu đi sâu vào bộ lọc sau rồi tới servlet, còn không gọi thì bộ lọc chặn lại ngay. Phương thức "doGet" nằm trong servlet HTTP và chỉ chạy cho lượt yêu cầu dùng phương thức đọc, nó không có trong giao diện bộ lọc. Phương thức "doPost" cũng của servlet HTTP, dành riêng cho lượt gửi dữ liệu lên. Phương thức "service" là điểm vào của servlet, nơi phân nhánh theo phương thức HTTP, đứng sau toàn bộ chuỗi bộ lọc. Phương thức "init" có trong vòng đời bộ lọc nhưng mang thân mặc định nên không buộc phải viết lại, và nó chỉ chạy một lần lúc khởi tạo chứ không xử lý yêu cầu.
Mở trang câu hỏi này →
A<c:import url="header.jsp"/>
B<c:include file="header.jsp"/>
C<c:forward page="header.jsp"/>
D<c:redirect url="header.jsp"/>
Lời giải
Đáp án đúng: "<c:import url="header.jsp"/>". Thẻ này nạp nội dung của một tài nguyên theo địa chỉ rồi ghép vào trang đang dựng; vì làm việc theo địa chỉ nên nó đọc được cả tài nguyên trong ứng dụng và tài nguyên ngoài, lại có thể hứng kết quả vào một biến thay vì in ra ngay. Cách viết "<c:include file="header.jsp"/>" không tồn tại trong thư viện lõi: việc chèn theo lối đó là hành động chuẩn của JSP và dùng tên thuộc tính khác. Cách viết "<c:forward page="header.jsp"/>" cũng không có trong thư viện lõi; chuyển tiếp là hành động chuẩn của JSP và nó trao hẳn quyền dựng phản hồi cho trang đích. Cách viết "<c:redirect url="header.jsp"/>" có thật nhưng gửi mã chuyển hướng về trình duyệt để nó gọi trang khác, tức thay cả trang chứ không chèn nội dung vào trang hiện tại.
Mở trang câu hỏi này →
A200
B404
C500
D201
Lời giải
Đáp án đúng: "200". Mã này nghĩa là máy chủ đã nhận, hiểu và xử lý xong lượt yêu cầu, thân phản hồi chứa nội dung được yêu cầu; với servlet thì đây là mã mặc định khi mã lệnh không tự đặt mã trạng thái khác và không ném ngoại lệ ra ngoài. Mã "404" nói máy chủ chạy bình thường nhưng không có tài nguyên ứng với đường dẫn, thường do sai ánh xạ servlet hoặc sai tên trang. Mã "500" báo lỗi phát sinh phía máy chủ, trong ứng dụng Java web thường là một ngoại lệ không được bắt thoát ra khỏi servlet hay trang JSP. Mã "201" cũng thuộc nhóm thành công nhưng mang nghĩa đã tạo mới một tài nguyên, nên nó gắn với lượt gửi dữ liệu lên chứ không phải lượt đọc bằng phương thức GET.
Mở trang câu hỏi này →
AdoFilter
Bservice
Cexecute
DinitFilter
Lời giải
Đáp án đúng: "doFilter". Giao diện bộ lọc đặt toàn bộ phần việc chặn tại phương thức này: nó nhận cặp yêu cầu, phản hồi và tham chiếu chuỗi bộ lọc, làm việc trước khi cho chuỗi đi tiếp, rồi còn có thể làm thêm việc sau khi lượt gọi quay về; không cho chuỗi đi tiếp thì lượt yêu cầu dừng ngay tại đó. Phương thức "service" thuộc servlet, là nơi container đẩy yêu cầu vào sau khi mọi bộ lọc đã cho qua, nên không nằm trong giao diện bộ lọc. Phương thức "execute" không có trong giao diện này, đó là tên quen thuộc ở các khung khác chứ không phải phần của đặc tả servlet. Phương thức "initFilter" là tên sai: vòng đời bộ lọc dùng hàm khởi tạo nhận cấu hình và hàm dọn khi tháo, mà hai hàm đó lại có thân mặc định nên không buộc phải viết.
Mở trang câu hỏi này →
A<filter> and <filter-mapping>
B<filter-definition> and <filter-mapping>
C<filter> and <application-filter>
D<servlet-filter> and <filter-mapping>
Lời giải

Đáp án đúng: "<filter> and <filter-mapping> ". Khai một bộ lọc cần hai phần: phần tử đầu đặt tên bộ lọc rồi chỉ ra lớp hiện thực cùng tham số khởi tạo, phần tử sau nối tên đó với mẫu đường dẫn hoặc tên servlet mà bộ lọc phải chặn, và thứ tự các phần tử nối chính là thứ tự chuỗi bộ lọc chạy. Cặp "<filter-definition> and <filter-mapping> " dùng một tên phần tử không có trong lược đồ của mô tả triển khai, nên máy chủ báo lỗi ngay khi đọc tệp. Cặp "<filter> and <application-filter> " đúng nửa đầu nhưng nửa sau là tên tự đặt, không tồn tại, nên bộ lọc được khai mà chẳng gắn vào đường dẫn nào. Cặp "<servlet-filter> and <filter-mapping> " cũng vậy: phần tử khai báo bộ lọc không mang tiền tố servlet, lược đồ không nhận tên này.

Mở trang câu hỏi này →