Me and mani were wondering what is tomcat and what is apache web server...Here is
an excerpt from Wikipedia about apache Tomcat and Apache web server
Apache Tomcat (or Jakarta Tomcat or simply Tomcat) is a servlet container developed by the Apache Software Foundation (ASF). Tomcat implements the Java Servlet and the JavaServer Pages (JSP) specifications from Sun Microsystems, and provides a "pure Java" HTTP web server environment for Java code to run.
Tomcat should not be confused with the Apache web server, which is a C implementation of an HTTP web server; these two web servers are not bundled together. Apache Tomcat includes tools for configuration and management, but can also be configured by editing XML configuration files
Members of the ASF and independent volunteers develop and maintain Tomcat. Users have free access to the source code and to the binary form of Tomcat under the Apache License. The initial Tomcat release appeared with versions 3.0.x (previous releases were Sun internal releases, and were not publicly released). Tomcat 6.0.20 is the latest production quality release of the 6.0.x trunk (the branch for the 2.5 servlet specification), as of 2009.
Components
Tomcat version 4.x was released with Jasper (a redesigned JSP engine), Catalina (a redesigned servlet container) and Coyote (an HTTP connector).
[edit] Catalina
Catalina is Tomcat's servlet container. Catalina implements Sun Microsystems' specifications for servlet and JavaServer Pages (JSP). The architect for Catalina was Craig McClanahan.
[edit] Coyote
Coyote is Tomcat's HTTP Connector component that supports the HTTP 1.1 protocol for the web server or application container. Coyote listens for incoming connections on a specific TCP port on the server and forwards the request to the Tomcat Engine to process the request and send back a response to the requesting client.
[edit] Jasper
Jasper is Tomcat's JSP Engine. Tomcat 5.x uses Jasper 2, which is an implementation of the Sun Microsystems's JavaServer Pages 2.0 specification. Jasper parses JSP files to compile them into Java code as servlets (that can be handled by Catalina). At runtime, Jasper is able to automatically detect JSP file changes and recompile them.
[edit] Jasper 2
From Jasper to Jasper 2, important features were added:
* JSP Tag library pooling - Each tag markup in JSP file is handled by a tag handler class. Tag handler class objects can be pooled and reused in the whole JSP servlet.
* Background JSP compilation - While recompiling modified JSP Java code, the older version is still available for server requests. The older JSP servlet is deleted once the new JSP servlet has been recompiled.
* Recompile JSP when included page changes - Pages can be inserted and included into a JSP at compile time. The JSP will not only be automatically recompiled with JSP file changes but also with included page changes.
* JDT Java compiler - Jasper 2 can use the Eclipse JDT Java compiler instead of Ant and javac.
Best regards
K.Rajasekaran
Wednesday, December 9, 2009
Thursday, December 3, 2009
Boot Persistence Terminology by sue loh
A post by sue loh in MSDN ...
Boot Persistence Terminology
Today I was describing what "warm boot," "cold boot," and "clean boot" mean to someone, and it turned out that it was a more complicated topic to understand than I had realized. So I figured I should share it. Luckily that "someone" was on the documentation team, so I expect this information will make its way into our docs too! Let’s see if I can make it clear. It’s not a trivial description.
Here’s part of the terminology problem. The word “RAM” is overloaded.
Here is what is technically going on underneath. This is why we distinguish between 3 boots instead of 2:
Warm = clears “program memory”, keeps “storage memory” (= “object store”)
Cold = clears both “program memory” and “storage memory”
Clean = clears all memory plus all persistent storage
What this maps to in terms of data persistence is,
If your device uses the object store to hold user data, then
Warm = user data persists
Cold = clean = user data is gone
Otherwise, if your device is not using the object store, then
Warm = no point, why would you do it
Cold = user data persists
Clean = user data is gone
An end user should only care about two kinds of boots: “boots that persist their data” and “boots that wipe their data.” An OEM may care about the 3 kinds of boots, to make sure that their device maps the underneath stuff to the 2 types of boots users care about.
In Windows Mobile before 5.0, the data was stored in the object store. So warm boots kept user data alive, and cold boots lost their data. So cold boots were the same as clean boots.
For Windows Mobile 5.0, we switched from storing data in the object store to storing the data in the persistent store. And switched from warm booting to cold booting. 99.9% of the time Windows Mobile 5.0 devices cold boot. If for some reason some awful problem has occurred and they need to wipe all of their data back to a factory reset, then they might pull some kind of CTRL-ALT-DELETE 3-finger salute to make the device clean boot. (There is no standard for such a thing, and of course CTRL, ALT, and DELETE don’t exist on a WM device.) I think most OEMs will build in a way to wipe if necessary. Otherwise the device will clean-boot on its very first boot, and cold boot forever after that unless the user does something special to force another clean boot. To a user it will look exactly the same as warm boots did back in the pre-Magneto days, because their data persists.
For general embedded (Windows CE devices that are not running Windows Mobile), all three options (clean, cold, warm) are still possible. It all comes down to whether there is any user data stored in the object store. If not, then they are the same as Windows Mobile 5.0, and only ever clean-boot or cold-boot. If yes, then they should be the same as Windows Mobile before 5.0, and only ever clean-boot or warm-boot. If they do all 3 kinds of boots then they have a wacky device and may be confused.
When I say “persistent” I just mean stuff that doesn’t go away when you turn off power. So removable storage cards also count as persistent. But you usually don’t – actually never, not without some serious finagling – put the registry onto a storage card, or use it as the root file system for your device. Because if you remove the card, the device can’t function. The “persistent store” is generally a non-removable storage device. I can imagine people doing crazy things like swap in a different flash card and get a different persistent store, but that is not for the faint of heart.
I’d expect a clean boot not to wipe removable storage, but in some cases people might want to. For example if they want to delete all data from the device for security purposes, to prevent it from falling into the wrong hands. In that case you might want to also wipe the storage card, if there was one. That is more of a special case though. Typically when we care about clean boot, we care about whether all the settings and files that the OS uses go back to factory-default.
When you clean-boot, you wipe all registry changes, total. Back to what was built into ROM when the device left the factory floor. Actually with Image Update that changes a bit, because Image Update updates the ROM. So to be truly correct, I can only say that clean-boot goes back to what is built into ROM.
Filed under: Author: Sue Loh, Registry & Databases
Boot Persistence Terminology
Today I was describing what "warm boot," "cold boot," and "clean boot" mean to someone, and it turned out that it was a more complicated topic to understand than I had realized. So I figured I should share it. Luckily that "someone" was on the documentation team, so I expect this information will make its way into our docs too! Let’s see if I can make it clear. It’s not a trivial description.
Here’s part of the terminology problem. The word “RAM” is overloaded.
Here is what is technically going on underneath. This is why we distinguish between 3 boots instead of 2:
Warm = clears “program memory”, keeps “storage memory” (= “object store”)
Cold = clears both “program memory” and “storage memory”
Clean = clears all memory plus all persistent storage
What this maps to in terms of data persistence is,
If your device uses the object store to hold user data, then
Warm = user data persists
Cold = clean = user data is gone
Otherwise, if your device is not using the object store, then
Warm = no point, why would you do it
Cold = user data persists
Clean = user data is gone
An end user should only care about two kinds of boots: “boots that persist their data” and “boots that wipe their data.” An OEM may care about the 3 kinds of boots, to make sure that their device maps the underneath stuff to the 2 types of boots users care about.
In Windows Mobile before 5.0, the data was stored in the object store. So warm boots kept user data alive, and cold boots lost their data. So cold boots were the same as clean boots.
For Windows Mobile 5.0, we switched from storing data in the object store to storing the data in the persistent store. And switched from warm booting to cold booting. 99.9% of the time Windows Mobile 5.0 devices cold boot. If for some reason some awful problem has occurred and they need to wipe all of their data back to a factory reset, then they might pull some kind of CTRL-ALT-DELETE 3-finger salute to make the device clean boot. (There is no standard for such a thing, and of course CTRL, ALT, and DELETE don’t exist on a WM device.) I think most OEMs will build in a way to wipe if necessary. Otherwise the device will clean-boot on its very first boot, and cold boot forever after that unless the user does something special to force another clean boot. To a user it will look exactly the same as warm boots did back in the pre-Magneto days, because their data persists.
For general embedded (Windows CE devices that are not running Windows Mobile), all three options (clean, cold, warm) are still possible. It all comes down to whether there is any user data stored in the object store. If not, then they are the same as Windows Mobile 5.0, and only ever clean-boot or cold-boot. If yes, then they should be the same as Windows Mobile before 5.0, and only ever clean-boot or warm-boot. If they do all 3 kinds of boots then they have a wacky device and may be confused.
When I say “persistent” I just mean stuff that doesn’t go away when you turn off power. So removable storage cards also count as persistent. But you usually don’t – actually never, not without some serious finagling – put the registry onto a storage card, or use it as the root file system for your device. Because if you remove the card, the device can’t function. The “persistent store” is generally a non-removable storage device. I can imagine people doing crazy things like swap in a different flash card and get a different persistent store, but that is not for the faint of heart.
I’d expect a clean boot not to wipe removable storage, but in some cases people might want to. For example if they want to delete all data from the device for security purposes, to prevent it from falling into the wrong hands. In that case you might want to also wipe the storage card, if there was one. That is more of a special case though. Typically when we care about clean boot, we care about whether all the settings and files that the OS uses go back to factory-default.
When you clean-boot, you wipe all registry changes, total. Back to what was built into ROM when the device left the factory floor. Actually with Image Update that changes a bit, because Image Update updates the ROM. So to be truly correct, I can only say that clean-boot goes back to what is built into ROM.
Filed under: Author: Sue Loh, Registry & Databases
Selecting the Internal File System for your Target Device(Windows MOBILE)
Selecting the Internal File System for your Target Device(Windows MOBILE)
The internal file system in your target device controls access to ROM. The file system can also provide file storage in the object store, which is in RAM. Two internal file system options are available: the RAM and ROM file system and the ROM-only file system. These have different properties and you will want to select the correct one for your target device. Both internal file systems provide the ability to mount additional external file systems, such as file allocation table (FAT).
The RAM and ROM file system provides file storage in the object store, as well as access to the ROM. The object store is the root of the file system, and all data under the root is stored in the object store, with the exception of external file systems, which are mounted as directories under the root. Data in ROM is accessible through the Windows directory. The RAM and ROM file system is most useful in target devices that continuously power RAM because the object store is lost when RAM is not refreshed.
The ROM-only file system does not allow applications to place files in the object store. Data in ROM is accessible through the Windows directory, and external file systems are again mounted as directories under the root. Additionally, with the ROM-only file system, you have the option of choosing an external file system to be placed at the root of the file system. If you mount a file system as the root, all data below the root directory is stored in that file system, with the exception of other external file systems.
The internal file system in your target device controls access to ROM. The file system can also provide file storage in the object store, which is in RAM. Two internal file system options are available: the RAM and ROM file system and the ROM-only file system. These have different properties and you will want to select the correct one for your target device. Both internal file systems provide the ability to mount additional external file systems, such as file allocation table (FAT).
The RAM and ROM file system provides file storage in the object store, as well as access to the ROM. The object store is the root of the file system, and all data under the root is stored in the object store, with the exception of external file systems, which are mounted as directories under the root. Data in ROM is accessible through the Windows directory. The RAM and ROM file system is most useful in target devices that continuously power RAM because the object store is lost when RAM is not refreshed.
The ROM-only file system does not allow applications to place files in the object store. Data in ROM is accessible through the Windows directory, and external file systems are again mounted as directories under the root. Additionally, with the ROM-only file system, you have the option of choosing an external file system to be placed at the root of the file system. If you mount a file system as the root, all data below the root directory is stored in that file system, with the exception of other external file systems.
Subscribe to:
Posts (Atom)