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.
Saturday, November 21, 2009
Someone's blog about Hopper .. gud one
Hopper: Start Menu Dead!
Some of you may be testing with Hopper now for certification and/or being asked to meet Mean Time To Failure (MTTF) bars as part of a relationship with a device maker. In order to be labeled a Windows Mobile powered device, the unit must pass a series of tests which are collectively known as the LTK (Logo Test Kit). If you ship your software in-ROM then your app becomes part of the stability tests they have to pass before release. There is nothing worse then to be sitting on a huge opportunity to ship in-ROM and find yourself as the focus of a failed Hopper test and holding up the device release.
Hopper isn't very smart, but he's surprisingly effective at exposing MTTF issues. Lately, I've had several partner become the subject of "Start Menu Dead" failures so I thought it might make a useful post.
For those of you unfamiliar with Hopper, it's a simple little app that basically simulates a 5 year old, jacked up on sugar that has taken over your mobile device. Tapping like crazy-- switching apps-- doing all kinds of things that a normal user might never do. Maybe that's not a completely fair description-- but think of a lot of random events that are periodically paused to make sure basic system functionality is still responsive-- like the START MENU.
Hopper runs for a period of time and reports a number of failure scenarios. Examples:
- Default system crash; this is where Hopper is not able to send keystrokes and mouse events.
- Start menu not responding. this is where Hopper is able to send keystrokes and mouse events but is not able to switch to any other application.
- Stuck in the same window, this is where Hopper is able to send keystrokes and mouse events but it detects that it is stuck in the same window for more than 15 minutes. Once this happens Hopper will attempt to dismiss the current foreground window by sending ENTER keys, sending simulated screen taps around the 4 corners and the center of the window, sending ESCAPE keys, try to find a button to click, and finally it will also try to switch away by clicking the Start menu. If none of the above attempts change the foreground window, it will quit and report a hang.
Applications that run in full screen (using SHFullScreen) can sometimes create problems for Hopper. Since Hopper likes to jump around, switch apps, and test the Start Menu-- it needs to be able to get out of an application running in full screen mode. Many full screen apps like games, navigation software, etc., will use a custom UI to take over the display and omit standard exit controls and window messages that Hopper uses. Once Hopper gets into a full screen app like this, it can get stuck and then report failures when it can't get out or access the Start Menu. When it does, your failure log will often look something like this:
Build = 15342 (OS 318)(Hop 2.0.15.7472).
Random Seed = 55592.
Previous runtime = 21 mins (0 hrs 21 mins).
Ended by: Start menu dead, not responding!
Boot count (prev): 3 (0)
ACTIONS/min = 149
Total States = 10
…
ACTIONS/min = 149; Total States = 10
FREE MEMORY: 75620 KB
FREE DISK: 25894 KB
EndType = Start menu dead, not responding
The important stuff
If you have an application that runs in fulls screen mode, be sure that Hopper can get out and access the Start Menu. If it sends a VK_THOME,it should always take you to the Home Screen. If it sends a VK_LWIN then it should always bring up the Start Menu. If you do anything to hold focus or prevent those mess ages from activating another window, then you will have problems. If Hopper cannot get out, it will try to dismiss your application by issuing a VK_ESCAPE and VK_RETURN on PPC (Classic/Pro). On Standard (Smartphone) it will attempt to dismiss by trying variations of the softkeys and sending a VK_TBACK. Make sure you handle those messages to close your app or release screen control in order to avoid the Start Menu Dead failure in Hopper.
Subscribe to:
Posts (Atom)