How does JVM uniquely identify JSP's with same name in different folder across different applications

How does JVM uniquely identify JSP's with same name in different folder across different applications?

To be more clear Say two applications (war's) are deployed on server A1 and A2. Now A1 has Random.jsp in folder F11 and F12 (2 jsp with identical names but different code), similarly A2 has Random.jsp in F21 and F22.

When the code is deployed and jsp's are translated into Servlets I believe the Servlet name would be same as well for all 开发者_高级运维4 JSP's. So how does JVM identify them uniquely for respective requests?

Had it been limited to a single application, I would have assumed JVM would use folder names as packages during servlet translation but does it work across applications.

Also please enlighten, whether JVM takes care of this distinction by declaring different packages for the generated servlet or using some internal mapping structures of different classes (this second option sounds quite weird)

---

That is implementation dependent. The way TOMCAT does it, is using a work directory with separate folders for A1.war and A2.war. That way, despite "Random.jsp" generating the same servlet name same for both WARs, they're placed in different folders so there's no possible confusion.

Example:

/usr/java/tomcat/work/Catalina/localhost/A1/org/apache/jsp/Random_jsp.java
/usr/java/tomcat/work/Catalina/localhost/A2/org/apache/jsp/Random_jsp.java

---

The problem you are mentioning is not limited to JSP files (which get translated into classes). It is the Webcontainer's job to ensure that different Webapplications within the container do not interfere. And each application CAN have classfiles with the same package and the same name. Best example: Each Webapp has some common library like log4j but with different versions.

The solution is to use Java's ClassLoader in a very creative way. A class is only known to the classloader which loaded it and to all child-classloader (classloader form a tree-like hierarchy). The webcontainer basically opens a new classloader for each WebApp, each Classloader can load the same class - Bingo.

Note: As long as everything is done properly, this works quite well. But if instances of these classes "leak" into the other application, strange things happen... A message like

ClassCastException....instance of class xyz.Foo is not an instance of class xyz.Foo

is not uncommon in that case. The first time you see that you WILL scratch your head.