Download Android App in your Android Device from Google Play Store
- Search for "Withoutbook Practice Exam Test" in Mobile/Tablet Play Store
Practice InterviewNew Search by Name or Email

Exams Attended

Make Homepage

Bookmark this page

Subscribe Email Address

Tomcat Interview Questions and Answers

Ques 1. How do you create multiple virtual hosts?

Ans. If you want tomcat to accept requests for different hosts e.g. then you must

  • Create ${catalina.home}/www/appBase , ${catalina.home}/www/deploy, and ${catalina.home}/conf/Catalina/
  • Add a host entry in the server.xml file 
  • Create the the following file under conf/Catalina/ 
  • Add any parameters specific to this hosts webapp to this context file 
  • Put your war file in ${catalina.home}/www/deploy 
  • When tomcat starts, it finds the host entry, then looks for any context files and will start any apps with a context.
To add more sites just repeat and rinse, all webapps can share the same war file location and appbase.

Is it helpful? Add Comment View Comments
Ques 2. How will you load properties file?
  • Use a ResourceBundle. See the Java docs for the specifics of how the ResourceBundle class works. Using this method, the properties file must go into the WEB-INF/classes directory or in a jar file contained in the WEB-INF/lib directory. 
  • Another way is to use the method getResourceAsStream() from the ServletContext class. This allows you update the file without having to reload the webapp as required by the first method. Here is an example code snippet, without any error trapping: 
// Assuming you are in a Servlet extending HttpServlet
// This will look for a file called "/more/" relative
// to your servlet Root Context
InputStream is = getServletContext().getResourceAsStream("/more/");
Properties p = new Properties();

Is it helpful? Add Comment View Comments
Ques 3. Can I set Java system properties differently for each webapp?
Ans. No. If you can edit Tomcat's startup scripts, you can add "-D" options to Java. But there is no way to add such properties in web.xml or the webapp's context.
Is it helpful? Add Comment View Comments
Ques 4. How do I configure Tomcat to work with IIS and NTLM?
Ans. Follow the standard instructions for when the isapi_redirector.dll
  • Configure IIS to use "integrated windows security"
  • In server.xml, make sure you disable tomcat authentication: 
<Connector port="8009" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" tomcatAuthentication="false" />
Is it helpful? Add Comment View Comments
Ques 5. How can I access members of a custom Realm or Principal?
Ans. When you create a custom subclass of RealmBase or GenericPrincipal and attempt to use those classes in your webapp code, you'll probably have problems with ClassCastException. This is because the instance returned by request.getUserPrincipal() is of a class loaded by the server's classloader, and you are trying to access it through you webapp's classloader. While the classes maybe otherwise exactly the same, different (sibling) classloaders makes them different classes.

This assumes you created a My Principal class, and put in Tomcat's server/classes (or lib) directory, as well as in your webapp's WEB-INF/classes (or lib) directory. Normally, you would put custom realm and principal classes in the server directory because they depend on other classes there.

Here's what you would like to do, but it throws ClassCastException:
MyPrincipal p = request.getUserPrincipal();

String emailAddress = p.getEmailAddress();

Here are 4 ways you might get around the classloader boundary:
  • Reflection
Principal p = request.getUserPrincipal(); 
String emailAddress = p.getClass().getMethod("getEmailAddress", null).invoke(p, null);
  • Move classes to a common classloader
You could put your custom classes in a classloader that is common to both the server and your webapp - e.g., either the "common" or bootstrap classloaders. To do this, however, you would also need to move the classes that your custom classes depend on up to the common classloader, and that seems like a bad idea, because there a many of them and they a core server classes. 
  • Common Interfaces 
Rather than move the implementing custom classes up, you could define interfaces for your customs classes, and put the interfaces in the common directory. You\'re code would look like this: 
public interface MyPrincipalInterface extends { 
public String getEmailAddress();
public class MyPrincipal implements MyPrincipalInterface { 
public String getEmailAddress() {
return emailAddress;
public class MyServlet implements Servlet { 
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws
ServletException, IOException {
MyPrincipalInterface p = (MyPrincipalInterface)request.getUserPrincipal();
String emailAddress = p.getEmailAddress();

Notice that this method gives you pretty much the webapp code you wanted in the first place
  • Serializing / Deserializing
You might want to try serializing the response of 'request.getUserPrincipal()' and deserialize it to an instance of [webapp]MyPrincipal.
Is it helpful? Add Comment View Comments

Most helpful rated by users:

©2018 WithoutBook