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.

580/11.885 câuCòn 11.305
Asession.getParameter(String name)
Bsession.getValue(String name) )
Csession.getAttribute(String name)
Dsession.fetchAttribute(String name)
Lời giải
Đáp án đúng: "session.getAttribute(String name)". HttpSession lưu dữ liệu theo cặp tên và giá trị: ghi bằng setAttribute, đọc lại bằng getAttribute; phương thức này trả về Object nên ở chỗ dùng thường phải ép kiểu lại, và trả về null khi tên đó chưa từng được đặt. "session.getParameter(String name)" sai vì getParameter là phương thức của request, dùng để đọc tham số client gửi lên qua query string hoặc biểu mẫu, HttpSession không có phương thức này. "session.getValue(String name) )" sai vì getValue là tên cũ đã bị đánh dấu loại bỏ và không còn nằm trong API HttpSession hiện hành. "session.fetchAttribute(String name)" sai vì đặc tả servlet không định nghĩa phương thức nào tên fetchAttribute; gọi nó thì mã không biên dịch được.
Mở trang câu hỏi này →
AUser Interface App Layer
BApplication Logic Layer
CData Layer
DConnection Layer
Lời giải
Đáp án đúng: "Application Logic Layer". Trong mô hình nhiều tầng, tầng logic ứng dụng là nơi đặt luật nghiệp vụ: kiểm tra dữ liệu đầu vào, tính toán, quyết định thứ tự các bước, rồi mới yêu cầu tầng dữ liệu đọc ghi; trong ứng dụng Java web thì servlet điều phối cùng các lớp nghiệp vụ nằm ở tầng này. "User Interface App Layer" sai vì tầng đó chỉ nhận thao tác của người dùng và hiển thị kết quả, nó không được chứa luật nghiệp vụ nếu muốn thay giao diện mà không viết lại nghiệp vụ. "Data Layer" sai vì nó chỉ chịu trách nhiệm lưu trữ và truy xuất, trả về dữ liệu thô cho tầng trên quyết định. "Connection Layer" sai vì việc mở, giữ và trả kết nối chỉ là chi tiết kỹ thuật bên trong tầng dữ liệu, không phải một tầng mang logic ứng dụng.
Mở trang câu hỏi này →
ADatabase
BModel
CView
DController
Lời giải
Đáp án đúng: "Database". Mẫu kiến trúc này chỉ gồm ba vai: phần mô hình giữ dữ liệu và nghiệp vụ, phần hiển thị dựng giao diện, phần điều khiển điều phối yêu cầu. Cơ sở dữ liệu là một hệ thống lưu trữ bên ngoài mà phần mô hình kết nối tới qua JDBC hoặc JPA; nó có thể bị thay bằng tệp hay dịch vụ khác mà kiến trúc không đổi, nên nó nằm ngoài ranh giới của mẫu. "Model" là thành phần chuẩn, chính nó mang các lớp thực thể và lớp truy cập dữ liệu. "View" là thành phần chuẩn, đảm nhiệm việc kết xuất HTML từ dữ liệu được truyền sang. "Controller" là thành phần chuẩn, trong Java web chính là servlet đọc tham số, gọi nghiệp vụ rồi chọn trang để forward tới.
Mở trang câu hỏi này →
564Given the code below:4 lựa chọncó code
Đề bài
HttpSession session = request.getSession();
session.setAttribute("username", "HuyNM");

Which of the following is incorrect?

AThe session must exist or be created automatically
BThe attribute "username" can be retrieved later using the same session
CThe attribute will persist across multiple HTTP requests
DThe attribute is stored in the client browser's local storage
Lời giải
Đáp án đúng: "The attribute is stored in the client browser's local storage". Dữ liệu đặt bằng setAttribute nằm trong đối tượng HttpSession do container giữ trong bộ nhớ của server; thứ duy nhất đi về phía trình duyệt là định danh phiên, thường là cookie JSESSIONID, nên không có mẩu dữ liệu nào tên username được ghi vào kho lưu trữ của trình duyệt. "The session must exist or be created automatically" là mệnh đề đúng, vì request.getSession() không tham số trả về phiên đang có hoặc tạo mới nếu chưa có, nhờ vậy dòng mã luôn có chỗ để ghi. Mệnh đề nói giá trị "can be retrieved later using the same session" cũng đúng, vì getAttribute với cùng tên trong cùng phiên sẽ lấy lại được đối tượng đã đặt. "The attribute will persist across multiple HTTP requests" đúng nốt, bởi phiên tồn tại xuyên nhiều yêu cầu cho tới khi hết thời gian chờ hoặc bị invalidate, đó chính là lý do người ta dùng phiên thay cho phạm vi request.
Mở trang câu hỏi này →
AModel
BView
CController
DService
Lời giải
Đáp án đúng: "View". Trong MVC, thành phần hiển thị là nơi nhận dữ liệu đã được chuẩn bị sẵn rồi dựng nó thành giao diện trả cho người dùng; ở Java web vai trò này thường do trang JSP đảm nhiệm, nó chỉ đọc các thuộc tính mà tầng điều khiển đặt vào request hay session rồi sinh ra HTML, không tự truy vấn cơ sở dữ liệu. "Model" sai vì nó chỉ giữ dữ liệu và quy tắc nghiệp vụ, tức các lớp thực thể và lớp truy cập dữ liệu, hoàn toàn không biết gì về cách trình bày. "Controller" sai vì nó là servlet tiếp nhận yêu cầu, đọc tham số, gọi tầng nghiệp vụ rồi chọn trang để forward tới: nó điều phối chứ không vẽ giao diện. "Service" sai vì đây không phải một trong ba thành phần của MVC; lớp service chỉ là cách tổ chức nghiệp vụ nằm bên trong phần mô hình, và dù có hay không có nó thì việc trình bày dữ liệu vẫn thuộc tầng hiển thị.
Mở trang câu hỏi này →
AExplicit transaction management by invoke con.beginTrans()
BTurn off auto commit mode from DBSM for implicit transaction
CIt is automatically managed by DBMS
DInvoke con.commit() or con,rollback()
Lời giải
Đáp án đúng: "Invoke con.commit() or con,rollback()". Trong JDBC, giao dịch được điều khiển trên chính đối tượng Connection: đặt setAutoCommit(false) để nhiều câu lệnh gộp vào một giao dịch, rồi kết thúc bằng commit() khi mọi việc trôi chảy hoặc rollback() trong khối bắt lỗi để trả dữ liệu về trạng thái trước đó; chính cặp lệnh kết thúc này là chỗ lập trình viên quyết định giao dịch, nên nó là câu trả lời sát nhất. "Explicit transaction management by invoke con.beginTrans()" sai vì Connection không có phương thức nào tên như vậy, giao dịch tường minh bắt đầu bằng việc tắt chế độ tự commit chứ không bằng một lệnh mở. "Turn off auto commit mode from DBSM for implicit transaction" sai chỗ: chế độ tự commit được tắt từ phía mã JDBC trên Connection, và tắt nó là bước mở đầu cho giao dịch tường minh chứ không tự kết thúc giao dịch. "It is automatically managed by DBMS" sai vì khi để nguyên chế độ tự commit thì mỗi câu lệnh là một giao dịch riêng, không có cách nào gộp nhiều câu lệnh lại.
Mở trang câu hỏi này →
AWhen there is a static SQL query that does not change
BWhen executing the same query multiple times with different parameters
CWhen a stored procedure needs to be called
DWhen the query has no parameters
Lời giải
Đáp án đúng: "When executing the same query multiple times with different parameters". Câu lệnh được chuẩn bị gửi phần SQL có chỗ giữ tham số đi một lần để máy chủ phân tích và lập kế hoạch thực thi, sau đó mỗi lượt chỉ cần gán giá trị mới rồi chạy lại, nên vừa nhanh hơn vừa chặn được chèn mã SQL vì giá trị luôn được truyền như dữ liệu chứ không ghép vào văn bản câu lệnh. "When there is a static SQL query that does not change" không phải lý do để chọn nó: câu lệnh cố định không tham số thì lớp câu lệnh thường đã đủ, điểm mạnh của dạng chuẩn bị nằm ở chỗ có tham số thay đổi. "When a stored procedure needs to be called" là việc của lớp câu lệnh gọi thủ tục, lớp đó mới khai báo được tham số trả ra. "When the query has no parameters" cũng không phải tình huống cần nó, vì không có chỗ giữ nào để gán thì lợi thế chính không được dùng tới.
Mở trang câu hỏi này →
AData can be lost
BThe application will automatically release the connection
CThe number of connections to the database can be exhausted (Connection Leak)
DNothing happens
Lời giải
Đáp án đúng: "The number of connections to the database can be exhausted (Connection Leak)". Mỗi kết nối là một tài nguyên của cả tiến trình Java lẫn của máy chủ cơ sở dữ liệu và số lượng luôn có hạn; không đóng thì kết nối vẫn bị giữ, đến lúc pool cạn hoặc server đạt giới hạn phiên thì mọi yêu cầu sau phải chờ rồi hết thời gian và ứng dụng tắc ở chỗ xin kết nối. Vì vậy phải đóng trong khối finally hoặc dùng cú pháp tự đóng tài nguyên. "Data can be lost" là hệ quả gián tiếp chứ không phải điều xảy ra do việc không đóng; dữ liệu đã commit vẫn còn, chỉ phần chưa commit mới bị bỏ khi phiên bị cắt. "The application will automatically release the connection" sai vì bộ thu gom rác không bảo đảm đóng kết nối và cũng không chạy đúng lúc ta cần. "Nothing happens" sai vì hậu quả chỉ chưa thấy khi tải thấp, dưới tải thật thì số kết nối bị giữ tăng dần tới khi cạn.
Mở trang câu hỏi này →
AJSTL improves readability over scriptlets
BJSTL completely replaces servlets for business logic
CJSTL requires importing core and optional tag libraries
DJSTL provides tags for iteration, conditionals, and internationalization
Lời giải
Đáp án đúng: "JSTL completely replaces servlets for business logic". Thư viện thẻ chuẩn chỉ là lớp trình bày: nó thay cho các đoạn mã Java nhúng trong trang để lặp, rẽ nhánh, định dạng và quốc tế hoá, chứ không nhận yêu cầu, không điều phối luồng xử lý, không gọi lớp truy cập dữ liệu hay quản phiên; những việc đó vẫn thuộc servlet, nên mệnh đề này là mệnh đề không đứng được. "JSTL improves readability over scriptlets" là nhận định đúng, thẻ có cấu trúc rõ ràng giúp trang dễ đọc và dễ bảo trì hơn mã Java chen trong HTML. "JSTL requires importing core and optional tag libraries" cũng đúng, phải có chỉ thị taglib khai không gian tên và tiền tố thì trình dịch trang mới hiểu thẻ, thiếu nó thì thẻ bị trả nguyên văn ra trình duyệt. "JSTL provides tags for iteration, conditionals, and internationalization" đúng, đó chính là các nhóm thẻ mà thư viện cung cấp.
Mở trang câu hỏi này →
Aparams
Brequest
Cinput
DgetParameters
Lời giải
Đáp án đúng: "request". Tham số gửi tới trang, dù nằm trong query string của một liên kết hay trong body của form gửi theo POST, đều do container gom vào đối tượng yêu cầu; trong JSP đối tượng đó lộ ra dưới tên request và đọc bằng getParameter() cho một giá trị hoặc getParameterValues() cho nhiều giá trị cùng tên, mọi giá trị trả về đều là chuỗi nên muốn số thì phải tự chuyển kiểu. "params" không phải đối tượng ngầm định của JSP; trong Expression Language có một map tên gần giống để tra tham số, nhưng đó là biến của biểu thức chứ không phải đối tượng ngầm định như câu hỏi nói tới. "input" không tồn tại trong JSP, đây là tên thẻ nhập liệu bên HTML. "getParameters" là tên nghe như một phương thức chứ không phải một đối tượng, và cũng không có phương thức nào tên như vậy để lấy tham số.
Mở trang câu hỏi này →
ApageContext
Brequest
Capplication
Dsession
Lời giải
Đáp án đúng: "application". Đối tượng ngầm định này chính là ServletContext của ứng dụng, mỗi ứng dụng web chỉ có một, nên dữ liệu đặt vào bằng setAttribute() sống suốt thời gian ứng dụng chạy và mọi servlet cùng mọi trang JSP của mọi người dùng đều đọc được; cũng qua nó mà trang đọc tham số khai chung và ghi log của ứng dụng. "pageContext" chỉ gói ngữ cảnh của riêng trang đang chạy và là đường đi tới các phạm vi khác, bản thân nó hết hiệu lực khi trang xử lý xong nên không giữ được dữ liệu toàn ứng dụng. "request" gắn với một yêu cầu, dữ liệu đặt trong đó mất ngay khi phản hồi được trả về. "session" gắn với một người dùng cụ thể và sống qua nhiều yêu cầu, nhưng dữ liệu của người này không hiện ra cho người khác nên không phải chỗ giữ thông tin dùng chung cho cả ứng dụng.
Mở trang câu hỏi này →
A<var>
B<declare>
C<scriptlet>
D<%! %>
Lời giải

Đáp án đúng: "<%! %>". Khối khai báo được dịch thành thành viên của lớp servlet mà container sinh ra từ trang JSP, nên biến đặt ở đây là biến mức lớp và phương thức đặt ở đây nằm ngoài phương thức phục vụ; chính vì vậy chúng tồn tại qua nhiều yêu cầu và dùng chung cho mọi người dùng, khác với đoạn mã nhúng thường rơi vào thân phương thức phục vụ và chỉ là biến cục bộ. "<var> " không phải thẻ của JSP, trình dịch trang coi nó là thẻ lạ và gửi nguyên văn ra cho trình duyệt. "<declare> " cũng không tồn tại trong JSP, không có thư viện chuẩn nào định nghĩa thẻ này nên nó không khai báo được gì. "<scriptlet> " không phải cú pháp hợp lệ; dạng tài liệu XML của đoạn mã nhúng có tên thuộc không gian jsp, và dù viết đúng thì mã trong đoạn nhúng vẫn nằm trong thân phương thức phục vụ nên không tạo được thành viên của lớp.

Mở trang câu hỏi này →
Atext/xml
Btext/plain
Ctext/html
Dapplication/json
Lời giải
Đáp án đúng: "text/html". Chỉ thị page khai contentType để JSP đặt header Content-Type trên phản hồi, và chỉ với kiểu này trình duyệt mới dựng cây DOM rồi vẽ trang kèm CSS cùng mã phía người dùng; thường viết kèm charset để dấu tiếng Việt không bị vỡ, và phải khai trước khi nội dung đầu tiên được ghi ra vì header đi trước body. "text/xml" khiến trình duyệt coi nội dung là tài liệu XML, nó sẽ kiểm cú pháp chặt và không vẽ trang như HTML, gặp thẻ không đóng là báo lỗi phân tích. "text/plain" khiến mọi thẻ hiện ra đúng dạng văn bản thô, người dùng đọc thấy cả dấu ngoặc nhọn thay vì thấy trang được vẽ. "application/json" dành cho dữ liệu trả về cho mã phía người dùng gọi nền, trình duyệt sẽ hiển thị hoặc tải về chuỗi JSON chứ không dựng trang.
Mở trang câu hỏi này →
Đề bài
var="x" value="10" /> <c:set var="y" value="5" /> ${
  x + y
}

What is the incorrect output produced by the JSP page above?

A15
B10+5
C510
D105
Lời giải
Đáp án đúng: "15". Chỉ thị taglib đã nạp thư viện lõi nên hai thẻ đặt biến tạo ra hai biến phạm vi page mang chuỗi mười và năm; khi gặp biểu thức có toán tử cộng, Expression Language không nối chuỗi mà ép cả hai toán hạng về kiểu số rồi mới tính, vì vậy con số mà trang thực sự in ra là 15 và ba giá trị còn lại là những kết quả trang này không bao giờ sinh ra. "10+5" chỉ xuất hiện nếu biểu thức bị viết thành văn bản thuần, chẳng hạn thiếu cú pháp mở biểu thức, khi đó container in nguyên văn chứ không tính. "510" là kết quả của phép ghép chuỗi với thứ tự đảo lại, điều mà toán tử cộng của Expression Language không làm. "105" là kết quả ghép chuỗi theo đúng thứ tự hai biến, cũng chỉ xảy ra nếu dùng toán tử nối chuỗi của Java trong một đoạn mã nhúng thay vì toán tử cộng của Expression Language.
Mở trang câu hỏi này →
ATo define the servlet's class name
BTo specify the context path of the web application
CTo set the URL address that maps to a servlet
DTo configure filter mappings
Lời giải
Đáp án đúng: "To set the URL address that maps to a servlet". Trong một khai báo ánh xạ servlet, phần tử này chứa mẫu đường dẫn mà container so khớp với phần URL sau context path để quyết định yêu cầu đi vào servlet nào; mẫu có thể là đường dẫn chính xác, dạng tiền tố kết thúc bằng dấu sao, hoặc dạng theo phần mở rộng. "To define the servlet's class name" là việc của phần tử khai lớp servlet, nơi ghi tên lớp đầy đủ kèm gói để container nạp lên. "To specify the context path of the web application" sai vì context path không nằm trong tệp cấu hình của ứng dụng, nó do tên tệp triển khai hoặc cấu hình của container quyết định. "To configure filter mappings" nằm ngoài phạm vi câu hỏi: khai báo ánh xạ filter cũng dùng một phần tử cùng tên để chỉ đường dẫn bị chặn, nhưng phần tử trong ánh xạ servlet thì không cấu hình gì cho filter.
Mở trang câu hỏi này →
ATo store data that can be shared across multiple servlets within the same request.
BTo store data that can be shared only within the same servlet.
CTo store data that can be shared across multiple servlets in the same session.
DTo store data that can be accessed by any servlet in the application.
Lời giải
Đáp án đúng: "To store data that can be shared across multiple servlets within the same request.". Attribute của request là ô chứa dữ liệu gắn với đúng một đối tượng HttpServletRequest: servlet đặt dữ liệu bằng setAttribute() rồi forward sang servlet hay trang JSP khác, nơi đó đọc lại bằng getAttribute() vì vẫn là cùng một yêu cầu; hết yêu cầu thì đối tượng bị bỏ và dữ liệu mất, nhờ vậy không có chuyện dữ liệu của người này lẫn sang người khác. "To store data that can be shared only within the same servlet." bó hẹp quá mức, nếu chỉ dùng trong một servlet thì biến cục bộ đã đủ và không cần tới attribute. "To store data that can be shared across multiple servlets in the same session." là mô tả phạm vi phiên, dữ liệu ở đó sống qua nhiều yêu cầu của cùng người dùng. "To store data that can be accessed by any servlet in the application." là mô tả phạm vi ứng dụng, dữ liệu ở đó dùng chung cho mọi người dùng.
Mở trang câu hỏi này →
AgetServletConfig().getInitParameter("paramName")
BgetServletContext().getInitParameter("paramName")
CgetInitParameter("paramName")
DgetConfig().getParameter("paramName")
Lời giải
Đáp án đúng: "getServletConfig().getInitParameter("paramName")". Tham số khởi tạo riêng của một servlet được khai trong phần tử init-param bên trong khai báo servlet, và đối tượng giữ chúng là ServletConfig mà container truyền vào lúc gọi init(); lấy đúng đối tượng đó rồi đọc theo tên là cách nêu rõ nguồn dữ liệu. "getServletContext().getInitParameter("paramName")" đọc trên phạm vi khác: nó lấy tham số khai trong context-param dùng chung cho cả ứng dụng, nên với tham số riêng của servlet nó trả về null. "getInitParameter("paramName")" là dạng viết tắt mà lớp cha GenericServlet cung cấp bằng cách uỷ nhiệm lại cho chính ServletConfig, nên nó chỉ dùng được khi đang ở trong thân servlet và không chỉ ra được đối tượng nào đang giữ tham số. "getConfig().getParameter("paramName")" sai cả hai tên: servlet không có getConfig(), và tham số khởi tạo không đọc bằng getParameter(), đó là phương thức đọc tham số do người dùng gửi lên.
Mở trang câu hỏi này →
ASends a permanent redirect to the browser
BIncludes another JSP page's content during request processing
CTransfers request control to another resource on the server
DReturns the response to the calling servlet
Lời giải
Đáp án đúng: "Transfers request control to another resource on the server". Hành động chuyển tiếp của JSP chạy hoàn toàn trong một yêu cầu: container lấy RequestDispatcher của tài nguyên đích và trao quyền xử lý cho nó, trang gọi dừng phát nội dung, phần đã ghi vào bộ đệm bị bỏ, còn đối tượng request và mọi attribute trong đó vẫn giữ nguyên nên trang đích đọc lại được; trình duyệt không hay biết gì và địa chỉ trên thanh URL không đổi. "Sends a permanent redirect to the browser" sai vì chuyển hướng là một phản hồi gửi về trình duyệt để nó phát yêu cầu thứ hai, địa chỉ đổi và attribute của yêu cầu cũ mất. "Includes another JSP page's content during request processing" là việc của hành động nhúng, nó chèn kết quả của trang khác rồi trả quyền về cho trang gọi để tiếp tục, chứ không trao hẳn quyền đi. "Returns the response to the calling servlet" sai vì quyền xử lý đi một chiều sang tài nguyên đích và không quay lại trang gọi.
Mở trang câu hỏi này →
Đề bài
public class ShowParamsServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        ServletContext ctx = getServletContext();
        PrintWriter out = response.getWriter();
        Enumeration<String> paramNames = ctx.getInitParameterNames();
        while(paramNames.hasMoreElements()) {
            String name = paramNames.nextElement();
            out.println(name + ": " + ctx.getInitParameter(name));
        }
    }
}

If web.xml has the following entries:

Đề bài
<context-param>
    <param-name>settingOne</param-name>
    <param-value>foo</param-value>
</context-param>
<context-param>
    <param-name>settingTwo</param-name>
    <param-value>bar</param-value>

</context-param> What will the servlet output?

Afoo bar
BsettingOne: foo settingTwo: bar
CsettingTwo: bar settingOne: foo
DsettingOne settingTwo
Lời giải

Đáp án đúng: "settingOne: foo settingTwo: bar". Vòng lặp đi qua Enumeration do ctx.getInitParameterNames() trả về, và mỗi lần lặp out.println() in ra chuỗi được nối từ name, dấu hai chấm kèm khoảng trắng, rồi ctx.getInitParameter(name); vì vậy mỗi dòng mang cả tên tham số lẫn giá trị của nó, lần lượt theo thứ tự hai phần tử context-param được khai trong web.xml. Lưu ý getInitParameter() ở đây gọi trên ServletContext nên đọc tham số dùng chung cho toàn ứng dụng, khác với tham số riêng của từng servlet. Lựa chọn "foo bar" bỏ mất phần name và dấu hai chấm mà biểu thức nối chuỗi luôn in kèm. Lựa chọn "settingTwo: bar settingOne: foo" đảo thứ tự so với thứ tự khai trong tệp cấu hình mà vòng lặp đi theo. Lựa chọn "settingOne settingTwo" chỉ in tên, tức là kết quả của việc in name mà không gọi getInitParameter().

Mở trang câu hỏi này →
AdoPost(HttpServletRequest request, HttpServletResponse response)
BdoPut(HttpServletRequest request, HttpServletResponse response)
CdoGet(HttpServletRequest request, HttpServletResponse response)
DdoDelete(HttpServletRequest request, HttpServletResponse response)
Lời giả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ợ.
Mở trang câu hỏi này →