-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 André,
I think it will help to give you perl analogies to everything. Here goes. On 3/11/2009 6:00 AM, André Warnier wrote: > - we have a JVM This is the 'perl' binary. > - "inside" the JVM, we have a Tomcat This is the perl script you're executing. If you ran 'perl tomcat.pl' from the command line, this is roughly what you'd get. > - then inside Tomcat, we have webapps Here's where the analogy breaks down a bit, and why it may be a bit confusing for you. Let's say that tomcat.pl can run arbitrary /other/ scripts for you. These arbitrary scripts are long-running (days, months, etc.), and then communicate their status back to tomcat.pl (through whatever means) and can accept commands (like 'stop' or 'handle this request') from tomcat.pl. You could also think of a webapp like a set of perl scripts deployed into httpd, except that they are always loaded into memory, even when not actively servicing requests (you can ignore mod_perl's likelihood of being cached, etc.). > It's already getting more > mysterious there for me, but I resolve this intellectually by imagining > that a webapp is just a "subroutine" which Tomcat runs from time to > time, in response to a HTTP request for example. Essentially, yes. In our perl analogy, tomcat.pl "owns" all the network connections and accepts all the requests. Once it decides which script should be the target, it does some housekeeping and then delegates the handling of the request to one of these long-running scripts. Folks from the LAMP world sometimes get tripped up here because of the threading involved. With httpd, a request it typically handled by an httpd process, a script is started (perl, php, whatever), and runs to completion, at which point the script dies and httpd goes back to waiting for a request. The webapp equivalent is roughly equivalent except that the script continues to live-on in memory along with all the other scripts that are part of the webapp. They can share data and even communicate (through app-created threads) when there are no requests to be processed. A Java webapp is a much more cohesive and dynamic beast than a collection of scripts that mostly do not interact with each other (other than maybe sharing a database). > So a webapp in fact "is" Tomcat, in the sense that when it runs it > does so as an integral part of the Tomcat process. So much so that > if a webapp were to execute a "system.exit()", it would take the > whole Tomcat (and JVM) with it. Yes ? I would agree that your conclusion is correct (i.e. System.exit takes down the whole JVM, excepting Mark's comments) but I think your summary is not: Tomcat "is" /not/ the webapp. Tomcat is a webapp /container/ (that's the technical term, actually). Saying that Tomcat "is" the webapp is like saying that Microsoft Windows /is/ dwm.exe because its the thing that you interact with (and dwm can ask the OS to shut down). Actually, the dwm example is pretty good because you /can/ kill dwm and still have the OS run. dwm is like the manager app: it can start other webapps (double-click an icon to launch), shut them down (click the X button), and even kill itself (try killing dwm.exe). If it commits suicide, the other webapps stay running. You can even restart the manager app (not sure exactly how to do this, but it's possible in theory) just like you can restart dwm. The analogy gets better because dwm accepts much of the input from the user (like requests from remote users of webapps) and delegates most of it to the running application. Okay, I'll put an end to this because I'm sure it will get out of hand pretty soon. > My next question in this rubrique will be about what individual webapps > really "share" at the deep-down level, considering that they are all in > the end issued from the same JVM process. This is all done using standard Java stuff and it pretty much all comes down to ClassLoaders (gasp!). Without using JNI, you can't do anything that's outside of the ClassLoader and the heap. When Tomcat deploys a webapp, it creates a ClassLoader for that webapp that tries to load all classes from that webapp's WEB-INF/classes filter and JAR files within WEB-INF/lib. Anything not found will be delegated /up/ the ClassLoader hierarchy until it gets back to the root ClassLoader (which loads things like java.lang.Object, etc.). Classes loaded in this ClassLoader are only visible to this webapp. Static data (class members with the keyword "static") is separate from any other webapp's same static data, even with the same class name. An example is a "singleton" (a class that should only have a single object created from it at runtime). If you have a singleton class and it's in both webappA/WEB-INF/classes /and/ webappB/WEB-INF/classes, then the two singletons are distinct, cannot communicate, etc. Technically, they are different classes because a class is defined by: a) the ClassLoader that loaded it and b) its fully-qualified class name, including package. Classes loaded from parent ClassLoaders (like the common classloader) are shared across whatever components are appropriate. If you put your JDBC driver into Tomcat's CATALINA_BASE/lib directory, then Tomcat itself or any webapp deployed into it will always use the same class (and static data, etc.). Java's main intra-process communication mechanism is through method calls. Usually listeners (sometimes called publisher-subscriber or observable-observer) are used to communicate event information from the source of the event to those interested in hearing about it. Er... does that help? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAkm6dkIACgkQ9CaO5/Lv0PDQ7QCYh9iQ9qnv/xHYhhU+9VMcg0F7 ggCfRyPOcsBpj1OuYadUiOopBVUToaI= =Fv4u -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
