Introduction
 |
Java is a base of j2ee. Let's dive into it. Welcome to tutorial related to j2ee. |
J2EE stands for Java Enterprise edition.J2ee applications are made up of components such as JavaServer Pages (JSP), Java servlets, and Enterprise JavaBeans (EJB) modules. These components enable software developers to build large-scale, distributed applications. Developers package J2EE applications in Java Archive (JAR) files (similar to zip files), which can be distributed to production sites. Administrators install J2EE applications onto the Application Server by deploying J2EE JAR files onto one or more server instances (or clusters of instances).
Containers
The J2EE application model divides enterprise applications into three fundamental parts: components, containers, and connectors. Components are the key focus of application developers, while system vendors implement containers and connectors to conceal complexity and promote portability. Containers intercede between clients and components, providing services transparently to both, including transaction support and resource pooling. Container mediation allows many component behaviors to be specified at deployment time, rather than in program code.In the Application Server, each server instance includes two containers: web and EJB. A container is a runtime environment that provides services such as security and transaction management to J2EE components. Web components, such as Java Server Pages and servlets, run within the web container. Enterprise JavaBeans run within the EJB container.
J2EE Services
The J2EE platform services simplify application programming and allow components and applications to be customized at deployment time to use resources available in the deployment environment. This section gives a brief overview of the J2EE platform naming, deployment, transaction, and security services.The J2EE platform provides services for applications, including:Naming -A naming and directory service binds objects to names. A J2EE application can locate an object by looking up its Java Naming and Directory Interface (JNDI) name.
Security - The Java Authorization Contract for Containers (JACC) is a set of security contracts defined for the J2EE containers. Based on the client’s identity, containers can restrict access to the container’s resources and services.
Transaction management - A transaction is an indivisible unit of work. For example, transferring funds between bank accounts is a transaction. A transaction management service ensures that a transaction is either completed, or is rolled back.
Message Service - Applications hosted on separate systems can communicate with each other by exchanging messages using the Java™ Message Service (JMS). JMS is an integral part of the J2EE platform and simplifies the task of integrating heterogeneous enterprise applications.
Web Services
Clients can access a J2EE 1.4 application as a remote web service in addition to accessing it through HTTP, RMI/IIOP, and JMS. Web services are implemented using the Java API for XML-based RPC (JAX-RPC). A J2EE application can also act as a client to web services, which would be typical in network applications.
Web Services Description Language (WSDL) is an XML format that describes web service interfaces. Web service consumers can dynamically parse a WSDL document to determine the operations a web service provides and how to execute them. The Application Server distributes web services interface descriptions using a registry that other applications can access through the Java API for XML Registries (JAXR).
Client Access
Clients can access J2EE applications in several ways. Browser clients access web applications using hypertext transfer protocol (HTTP). For secure communication, browsers use the HTTP secure (HTTPS) protocol that uses secure sockets layer (SSL).Rich client applications running in the Application Client Container can directly lookup and access Enterprise JavaBeans using an Object Request Broker (ORB), Remote Method Invocation (RMI) and the internet inter-ORB protocol (IIOP), or IIOP/SSL (secure IIOP). They can access applications and web services using HTTP/HTTPS, JMS, and JAX-RPC. They can use JMS to send messages to and receive messages from applications and message-driven beans.
Clients that conform to the Web Services-Interoperability (WS-I) Basic Profile can access J2EE web services. WS-I is an integral part of the J2EE standard and defines interoperable web services. It enables clients written in any supporting language to access web services deployed to the Application Server.
The best access mechanism depends on the specific application and the anticipated volume of traffic. The Application Server supports separately configurable listeners for HTTP, HTTPS, JMS, IIOP, and IIOP/SSL. You can set up multiple listeners for each protocol for increased scalability and reliability.
J2EE applications can also act as clients of J2EE components such as Enterprise JavaBeans modules deployed on other servers, and can use any of these access mechanisms.
Installing the software:
Requirements
Java EE 8 SDK distributions require JDK 8 Update 144 or higher. Oracle recommends using the latest JDK that is available. Please note: Java SE 9 is not supported at this time.
Ensure that the required JDK software is installed on your system and that the JAVA_HOME environment variable points to the JDK installation directory, not the Java Runtime Environment (JRE) software.
Please refer to the Installation Guide for GlassFish Server, OSE for additional details regarding installation of GlassFish, the Java EE Reference Implementation.
To Install the Software
The following procedure describes how to install the SDK distributions using the ZIP file.
- Download the distribution file for your platform from the Java EE 8 SDK Downloads page.
- Navigate to the directory where you downloaded the file.
- Unzip the file.
Windows systems: Unzip using your favorite file compression utility.
To download software, click here.
3 Tier Application
A 3-tier application is an application program that is organized into three major parts, each of which is distributed to a different place or places in a network. The three parts are:
- The workstation or presentation interface
- The business logic
- The database and programming related to managing it
 |
| three tier application |
Business logic is located on a local area network (LAN) server or other shared computer. The business logic acts as the server for client requests from workstations. In turn, it determines what data is needed (and where it is located) and acts as a client in relation to a third tier of programming that might be located on a mainframe computer.
The third tier includes the database and a program to manage read and write access to it. While the organization of an application can be more complicated than this, the 3-tier view is a convenient way to think about the parts in a large-scale program.
A 3-tier application uses the client/server computing model. With three tiers or parts, each part can be developed concurrently by different team of programmers coding in different languages from the other tier developers. Because the programming for a tier can be changed or relocated without affecting the other tiers, the 3-tier model makes it easier for an enterprise or software packager to continually evolve an application as new needs and opportunities arise. Existing applications or critical parts can be permanently or temporarily retained and encapsulated within the new tier of which it becomes a component.
MVC Architecture
In object-oriented programming development, model-view-controller (MVC) is the name of a methodology or design pattern for successfully and efficiently relating the user interface to underlying data models. The MVC pattern is widely used in program development with programming languages such as Java, Smalltalk, C, and C++.The MVC pattern has been heralded by many developers as a useful pattern for the reuse of object code and a pattern that allows them to significantly reduce the time it takes to develop applications with user interfaces.
The model-view-controller pattern proposes three main components or objects to be used in software development:
- A Model , which represents the underlying, logical structure of data in a software application and the high-level class associated with it. This object model does not contain any information about the user interface.
- A View , which is a collection of classes representing the elements in the user interface (all of the things the user can see and respond to on the screen, such as buttons, display boxes, and so forth)
- A Controller , which represents the classes connecting the model and the view, and is used to communicate between classes in the model and view.
 |
| MVC |
A 3-tier application is an application program that is organized into three major parts, each of which is distributed to a different place or places in a network. The three parts are:
- The workstation or presentation interface
- The business logic
- The database and programming related to managing it
Business logic is located on a local area network (LAN) server or other shared computer. The business logic acts as the server for client requests from workstations. In turn, it determines what data is needed (and where it is located) and acts as a client in relation to a third tier of programming that might be located on a mainframe computer.
The third tier includes the database and a program to manage read and write access to it. While the organization of an application can be more complicated than this, the 3-tier view is a convenient way to think about the parts in a large-scale program.
A 3-tier application uses the client/server computing model. With three tiers or parts, each part can be developed concurrently by different team of programmers coding in different languages from the other tier developers. Because the programming for a tier can be changed or relocated without affecting the other tiers, the 3-tier model makes it easier for an enterprise or software packager to continually evolve an application as new needs and opportunities arise. Existing applications or critical parts can be permanently or temporarily retained and encapsulated within the new tier of which it becomes a component.
Difference between MVC and 3 Tier Architecture:
At first glance, the three tiers may seem similar to the model-view-controller (MVC) concept; however, topologically they are different. A fundamental rule in a three tier architecture is the client tier never communicates directly with the data tier; in a three-tier model all communication must pass through the middle tier. Conceptually the three-tier architecture is linear. However, the [model-view-controller] MVC architecture is triangular: the view sends updates to the controller, the controller updates the model, and the view gets updated directly from the model.
Windows
Installing Tomcat on Windows can be done easily using the Windows installer. Its interface and functionality is similar to other wizard based installers, with only a few items of interest.
Installation as a service: Tomcat will be installed as a Windows service no matter what setting is selected. Using the checkbox on the component page sets the service as "auto" startup, so that Tomcat is automatically started when Windows starts. For optimal security, the service should be run as a separate user, with reduced permissions (see the Windows Services administration tool and its documentation).
Java location: The installer will provide a default JRE to use to run the service. The installer uses the registry to determine the base path of a Java 6 or later JRE, including the JRE installed as part of the full JDK. When running on a 64-bit operating system, the installer will first look for a 64-bit JRE and only look for a 32-bit JRE if a 64-bit JRE is not found. It is not mandatory to use the default JRE detected by the installer. Any installed Java 6 or later JRE (32-bit or 64-bit) may be used.
Tray icon: When Tomcat is run as a service, there will not be any tray icon present when Tomcat is running. Note that when choosing to run Tomcat at the end of installation, the tray icon will be used even if Tomcat was installed as a service.
Defaults: The defaults used by the installer may be overridden by use of the /C=<config file> command line argument. The configuration file uses the format name=value with each pair on a separate line. The names of the available configuration options are:
By using /C=... along with /S and /D= it is possible to perform fully configured unattended installs of Apache Tomact.
Refer to the Windows Service HOW-TO for information on how to manage Tomcat as a Windows service.
Introduction
For administrators and web developers alike, there are some important bits of information you should familiarize yourself with before starting out. This document serves as a brief introduction to some of the concepts and terminology behind the Tomcat container. As well, where to go when you need help.
Terminology
In the course of reading these documents, you will run across a number of terms; some specific to Tomcat, and others defined by the Servlet and JSP specifications.
Context - In a nutshell, a Context is a web application.
That is it. If you find any more terms we need to add to this section, please do let us know.
Directories and Files
These are some of the key tomcat directories:
/bin - Startup, shutdown, and other scripts. The *.sh files (for Unix systems) are functional duplicates of the *.bat files (for Windows systems). Since the Win32 command-line lacks certain functionality, there are some additional files in here.
/conf - Configuration files and related DTDs. The most important file in here is server.xml. It is the main configuration file for the container.
/logs - Log files are here by default.
/webapps - This is where your webapps go.
CATALINA_HOME and CATALINA_BASE
Throughout the documentation, there are references to the two following properties:
CATALINA_HOME: Represents the root of your Tomcat installation, for example /home/tomcat/apache-tomcat-9.0.10 or C:\Program Files\apache-tomcat-9.0.10.
CATALINA_BASE: Represents the root of a runtime configuration of a specific Tomcat instance. If you want to have multiple Tomcat instances on one machine, use the CATALINA_BASE property.
If you set the properties to different locations, the CATALINA_HOME location contains static sources, such as .jar files, or binary files. The CATALINA_BASE location contains configuration files, log files, deployed applications, and other runtime requirements.
Why Use CATALINA_BASE
By default, CATALINA_HOME and CATALINA_BASE point to the same directory. Set CATALINA_BASE manually when you require running multiple Tomcat instances on one machine. Doing so provides the following benefits:
Easier management of upgrading to a newer version of Tomcat. Because all instances with single CATALINA_HOME location share one set of .jar files and binary files, you can easily upgrade the files to newer version and have the change propagated to all Tomcat instances using the same CATALINA_HOME directory.
Avoiding duplication of the same static .jar files.
The possibility to share certain settings, for example the setenv shell or bat script file (depending on your operating system).
Contents of CATALINA_BASE
Before you start using CATALINA_BASE, first consider and create the directory tree used by CATALINA_BASE. Note that if you do not create all the recommended directories, Tomcat creates the directories automatically. If it fails to create the necessary directory, for example due to permission issues, Tomcat will either fail to start, or may not function correctly.
Consider the following list of directories:
The bin directory with the setenv.sh, setenv.bat, and tomcat-juli.jar files.
Recommended: No.
Order of lookup: CATALINA_BASE is checked first; fallback is provided to CATALINA_HOME.
The lib directory with further resources to be added on classpath.
Recommended: Yes, if your application depends on external libraries.
Order of lookup: CATALINA_BASE is checked first; CATALINA_HOME is loaded second.
The logs directory for instance-specific log files.
Recommended: Yes.
The webapps directory for automatically loaded web applications.
Recommended: Yes, if you want to deploy applications.
Order of lookup: CATALINA_BASE only.
The work directory that contains temporary working directories for the deployed web applications.
Recommended: Yes.
The temp directory used by the JVM for temporary files.
Recommended: Yes.
We recommend you not to change the tomcat-juli.jar file. However, in case you require your own logging implementation, you can replace the tomcat-juli.jar file in a CATALINA_BASE location for the specific Tomcat instance.
We also recommend you copy all configuration files from the CATALINA_HOME/conf directory into the CATALINA_BASE/conf/ directory. In case a configuration file is missing in CATALINA_BASE, there is no fallback to CATALINA_HOME. Consequently, this may cause failure.
At minimum, CATALINA_BASE must contain:
conf/server.xml
conf/web.xml
That includes the conf directory. Otherwise, Tomcat fails to start, or fails to function properly.
For advanced configuration information, see the RUNNING.txt file.
How to Use CATALINA_BASE
The CATALINA_BASE property is an environment variable. You can set it before you execute the Tomcat start script, for example:
On Unix: CATALINA_BASE=/tmp/tomcat_base1 bin/catalina.sh start
On Windows: CATALINA_BASE=C:\tomcat_base1 bin/catalina.bat start
Configuring Tomcat
This section will acquaint you with the basic information used during the configuration of the container.
All of the information in the configuration files is read at startup, meaning that any change to the files necessitates a restart of the container.
Where to Go for Help
While we've done our best to ensure that these documents are clearly written and easy to understand, we may have missed something. Provided below are various web sites and mailing lists in case you get stuck.
As Tomcat 7 is a new release of Tomcat, keep in mind that some of the issues and solutions vary between the major versions of Tomcat (6.x versus 7.x). As you search around the web, there will be some documentation that is not relevant to Tomcat 7, but 6.x, 5.x or earlier versions. Doing 3.x or 4.x things to 7 will probably not work in most cases as the server.xml files are very different.
Current document - most documents will list potential hangups. Be sure to fully read the relevant documentation as it will save you much time and effort. There's nothing like scouring the web only to find out that the answer was right in front of you all along!
Tomcat FAQ
Tomcat WIKI
Tomcat FAQ at jGuru
Tomcat mailing list archives - numerous sites archive the Tomcat mailing lists. Since the links change over time, clicking here will search Google.
The TOMCAT-USER mailing list, which you can subscribe to here. If you don't get a reply, then there's a good chance that your question was probably answered in the list archives or one of the FAQs. Although questions about web application development in general are sometimes asked and answered, please focus your questions on Tomcat-specific issues.
The TOMCAT-DEV mailing list, which you can subscribe to here. This list is reserved for discussions about the development of Tomcat itself. Questions about Tomcat configuration, and the problems you run into while developing and running applications, will normally be more appropriate on the TOMCAT-USER list instead.
And, if you think something should be in the docs, by all means let us know on the TOMCAT-DEV list.
The installer will create shortcuts allowing starting and configuring Tomcat. It is important to note that the Tomcat administration web application can only be used when Tomcat is running.
 |
| Pictorical representation of mvc and 3 tier applicatiion. |
What is the UNIFIED MODELING LANGUAGE:
- It is a visual language with symbols to represent classes and databases.
- We use UML to design our algorithm before we start coding.
- It gives you a visual framework to make good design decisions before you start writing code or designing databases.
UML Design elements
 |
| Design elements |
Java Infrastructure
J2EE Stands for Java 2 Enterprise Edition. J2EE is an environment for developing and deploying enterprise applications. J2EE specification is defined by Sun Microsystems Inc. The J2EE platform is one of the best platform for the development and deployment of enterprise applications. The J2EE platform is consists of a set of services, application programming interfaces (APIs), and protocols, which provides the functionality necessary for developing multi-tiered, web-based applications. You can download the J2EE SDK and development tools from Oracle Technology Network for Java Developers.
Future articles will subsequently take a look at some of the core J2EE technologies such as Java Servlets, JavaServer Pages (JSP), Enterprise JavaBeans (EJB) and the Java Message Service (JMS). Following on from this, we'll move on to take a look at J2EE from an architecture and design perspective, covering topics like best practices and design patterns.
Enterprise applications can be run on different platforms supporting the Java 2 platform.
Enterprise applications are portable between application servers supporting the J2EE specification.
What does J2EE comprise?
J2EE is comprised of many APIs that can be used to build enterprise applications. Although the total list of APIs initially seems overwhelming, it is worth bearing in mind that some are primarily used by the J2EE environment in which your application executes, while some provide services that your specific application may not require. Therefore, it is worth remembering that you don't have to use all of them in order to build J2EE applications. For completeness, however, the full list of technologies that make up J2EE is as follows:
From a developer perspective, the main technologies are EJB, JSP, Java Servlets, JDBC and JMS, although JNDI is used for locating EJBs and other enterprise resources. For the moment, let's take a quick look at some of these technologies before moving on to see how to get started with J2EE.
What are Java Servlets?
At a high level, Java Servlets are the Java equivalent of CGI scripts that can be used to perform processing and the servicing of client requests on a web server. From an implementation perspective, servlets are simply Java classes that implement a predefined interface. One use for servlets is that they can be used to dynamically generate content for presentation to the user, and this is achieved by embedding markup language (e.g. HTML) inside the Java code. As Servlets are written in Java, they have access to the rich library of features provided by Java, including access to databases and other enterprise resources such as EJB.
What are JavaServer Pages (JSP)?
JSP is another technology for presenting information to the user over the web and uses a paradigm where Java code is embedded into the HTML - the opposite of servlets, and much like Microsoft ASP. Pages are written as HTML files with embedded Java source code known as scriptlets.
One of the pitfalls in using JSP is that it is very easy to build large pages containing lots of embedded Java code and business logic. For this reason, JSPs provide easy integration with JavaBeans and another feature called JSP tag extensions. These custom tags (also known as custom actions) allow re-usable functionality to be encapsulated into XML-like tags that can be easily used on the pages by both page developers and designers.
What are Enterprise JavaBeans?
EJB is a major part of the J2EE specification and defines a model for building server-side, reusable components. There are three types of enterprise beans currently supported by J2EE - session beans, entity beans and message-driven beans.
Session beans can be seen as extensions to the client application and are typically used to model business processes. There are two types of session bean - stateful and stateless. Stateful session beans are typically used to record conversational state for a single client between requests, whereas stateless session beans are shared between any number of clients at any one time.
Entity beans are typically used to model persistent business entities and, in particular, data in a database. A common mapping is to model an entity bean on a table, there being one instance of that bean for every row in the table. There are two ways that persistence can be achieved - container managed and bean managed persistence. In container managed persistence, a mapping is defined at deployment time between the persistent properties in the bean and the columns in the table. With bean managed persistence, developers write the JDBC code that performs the create, read, update and delete operations.
Finally, message-driven beans allow functionality to be executed on an asynchronous basis, typically triggered by JMS messages from message-oriented middleware.
What is the Java Message Service (JMS)?
JMS is Java API that presents an interface into message-oriented middleware such as IBM MQSeries, SonicMQ and so on. Like JDBC, JMS provides Java applications a mechanism to integrate with such systems by presenting a common programming interface irrespective of the underlying messaging system. Functionally, JMS allows messages to be sent and received using a point-to-point or publish/subscribe paradigm.
Introduction
This article, the first in a series, will introduce J2EE and present an overview of what it is and what it can do. In addition to this, we'll also take a look at how to get started with J2EE by presenting the steps necessary to download, install and start developing J2EE applications.Future articles will subsequently take a look at some of the core J2EE technologies such as Java Servlets, JavaServer Pages (JSP), Enterprise JavaBeans (EJB) and the Java Message Service (JMS). Following on from this, we'll move on to take a look at J2EE from an architecture and design perspective, covering topics like best practices and design patterns.
What is J2EE?
Using the Java 2 Platform, Standard Edition (J2SE) as a basis, Java 2 Platform, Enterprise Edition (J2EE) builds on top of this to provide the types of services that are necessary to build large scale, distributed, component based, multi-tier applications. Essentially, J2EE is a collection of APIs that can be used to build such systems, although this is only half of the picture. J2EE is also a standard for building and deploying enterprise applications, held together by the specifications of the APIs that it defines and the services that J2EE provides. In other words, this means that the "write once, run anywhere" promises of Java apply for enterprise applications too:Enterprise applications can be run on different platforms supporting the Java 2 platform.
Enterprise applications are portable between application servers supporting the J2EE specification.
What does J2EE comprise?
J2EE is comprised of many APIs that can be used to build enterprise applications. Although the total list of APIs initially seems overwhelming, it is worth bearing in mind that some are primarily used by the J2EE environment in which your application executes, while some provide services that your specific application may not require. Therefore, it is worth remembering that you don't have to use all of them in order to build J2EE applications. For completeness, however, the full list of technologies that make up J2EE is as follows:
- Java Servlets
- JavaServer Pages (JSP)
- Enterprise JavaBeans (EJB)
- Java Message Service (JMS)
- Java Naming and Directory Interface (JNDI)
- Java Database Connectivity (JDBC)
- JavaMail
- Java Transaction Service (JTS)
- Java Transaction API (JTA)
- J2EE Connector Architecture (J2EE-CA, or JCA)
 |
| Technologies offered by j2ee along with their applications. |
From a developer perspective, the main technologies are EJB, JSP, Java Servlets, JDBC and JMS, although JNDI is used for locating EJBs and other enterprise resources. For the moment, let's take a quick look at some of these technologies before moving on to see how to get started with J2EE.
What are Java Servlets?
At a high level, Java Servlets are the Java equivalent of CGI scripts that can be used to perform processing and the servicing of client requests on a web server. From an implementation perspective, servlets are simply Java classes that implement a predefined interface. One use for servlets is that they can be used to dynamically generate content for presentation to the user, and this is achieved by embedding markup language (e.g. HTML) inside the Java code. As Servlets are written in Java, they have access to the rich library of features provided by Java, including access to databases and other enterprise resources such as EJB.
What are JavaServer Pages (JSP)?
JSP is another technology for presenting information to the user over the web and uses a paradigm where Java code is embedded into the HTML - the opposite of servlets, and much like Microsoft ASP. Pages are written as HTML files with embedded Java source code known as scriptlets.
One of the pitfalls in using JSP is that it is very easy to build large pages containing lots of embedded Java code and business logic. For this reason, JSPs provide easy integration with JavaBeans and another feature called JSP tag extensions. These custom tags (also known as custom actions) allow re-usable functionality to be encapsulated into XML-like tags that can be easily used on the pages by both page developers and designers.
What are Enterprise JavaBeans?
EJB is a major part of the J2EE specification and defines a model for building server-side, reusable components. There are three types of enterprise beans currently supported by J2EE - session beans, entity beans and message-driven beans.
Session beans can be seen as extensions to the client application and are typically used to model business processes. There are two types of session bean - stateful and stateless. Stateful session beans are typically used to record conversational state for a single client between requests, whereas stateless session beans are shared between any number of clients at any one time.
Entity beans are typically used to model persistent business entities and, in particular, data in a database. A common mapping is to model an entity bean on a table, there being one instance of that bean for every row in the table. There are two ways that persistence can be achieved - container managed and bean managed persistence. In container managed persistence, a mapping is defined at deployment time between the persistent properties in the bean and the columns in the table. With bean managed persistence, developers write the JDBC code that performs the create, read, update and delete operations.
Finally, message-driven beans allow functionality to be executed on an asynchronous basis, typically triggered by JMS messages from message-oriented middleware.
What is the Java Message Service (JMS)?
JMS is Java API that presents an interface into message-oriented middleware such as IBM MQSeries, SonicMQ and so on. Like JDBC, JMS provides Java applications a mechanism to integrate with such systems by presenting a common programming interface irrespective of the underlying messaging system. Functionally, JMS allows messages to be sent and received using a point-to-point or publish/subscribe paradigm.
Setting up Server
Setting up Server
Introduction
There are several ways to set up Tomcat for running on different platforms. The main documentation for this is a file called RUNNING.txt. We encourage you to refer to that file if the information below does not answer some of your questions.Windows
Installing Tomcat on Windows can be done easily using the Windows installer. Its interface and functionality is similar to other wizard based installers, with only a few items of interest.
Installation as a service: Tomcat will be installed as a Windows service no matter what setting is selected. Using the checkbox on the component page sets the service as "auto" startup, so that Tomcat is automatically started when Windows starts. For optimal security, the service should be run as a separate user, with reduced permissions (see the Windows Services administration tool and its documentation).
Java location: The installer will provide a default JRE to use to run the service. The installer uses the registry to determine the base path of a Java 6 or later JRE, including the JRE installed as part of the full JDK. When running on a 64-bit operating system, the installer will first look for a 64-bit JRE and only look for a 32-bit JRE if a 64-bit JRE is not found. It is not mandatory to use the default JRE detected by the installer. Any installed Java 6 or later JRE (32-bit or 64-bit) may be used.
Tray icon: When Tomcat is run as a service, there will not be any tray icon present when Tomcat is running. Note that when choosing to run Tomcat at the end of installation, the tray icon will be used even if Tomcat was installed as a service.
Defaults: The defaults used by the installer may be overridden by use of the /C=<config file> command line argument. The configuration file uses the format name=value with each pair on a separate line. The names of the available configuration options are:
- JavaHome
- TomcatPortShutdown
- TomcatPortHttp
- TomcatPortAjp
- TomcatMenuEntriesEnable
- TomcatShortcutAllUsers
- TomcatServiceDefaultName
- TomcatServiceName
- TomcatServiceFileName
- TomcatServiceManagerFileName
- TomcatAdminEnable
- TomcatAdminUsername
- TomcatAdminPassword
- TomcatAdminRoles
Refer to the Windows Service HOW-TO for information on how to manage Tomcat as a Windows service.
Introduction
For administrators and web developers alike, there are some important bits of information you should familiarize yourself with before starting out. This document serves as a brief introduction to some of the concepts and terminology behind the Tomcat container. As well, where to go when you need help.
Terminology
In the course of reading these documents, you will run across a number of terms; some specific to Tomcat, and others defined by the Servlet and JSP specifications.
Context - In a nutshell, a Context is a web application.
That is it. If you find any more terms we need to add to this section, please do let us know.
Directories and Files
These are some of the key tomcat directories:
/bin - Startup, shutdown, and other scripts. The *.sh files (for Unix systems) are functional duplicates of the *.bat files (for Windows systems). Since the Win32 command-line lacks certain functionality, there are some additional files in here.
/conf - Configuration files and related DTDs. The most important file in here is server.xml. It is the main configuration file for the container.
/logs - Log files are here by default.
/webapps - This is where your webapps go.
CATALINA_HOME and CATALINA_BASE
Throughout the documentation, there are references to the two following properties:
CATALINA_HOME: Represents the root of your Tomcat installation, for example /home/tomcat/apache-tomcat-9.0.10 or C:\Program Files\apache-tomcat-9.0.10.
CATALINA_BASE: Represents the root of a runtime configuration of a specific Tomcat instance. If you want to have multiple Tomcat instances on one machine, use the CATALINA_BASE property.
If you set the properties to different locations, the CATALINA_HOME location contains static sources, such as .jar files, or binary files. The CATALINA_BASE location contains configuration files, log files, deployed applications, and other runtime requirements.
Why Use CATALINA_BASE
By default, CATALINA_HOME and CATALINA_BASE point to the same directory. Set CATALINA_BASE manually when you require running multiple Tomcat instances on one machine. Doing so provides the following benefits:
Easier management of upgrading to a newer version of Tomcat. Because all instances with single CATALINA_HOME location share one set of .jar files and binary files, you can easily upgrade the files to newer version and have the change propagated to all Tomcat instances using the same CATALINA_HOME directory.
Avoiding duplication of the same static .jar files.
The possibility to share certain settings, for example the setenv shell or bat script file (depending on your operating system).
Contents of CATALINA_BASE
Before you start using CATALINA_BASE, first consider and create the directory tree used by CATALINA_BASE. Note that if you do not create all the recommended directories, Tomcat creates the directories automatically. If it fails to create the necessary directory, for example due to permission issues, Tomcat will either fail to start, or may not function correctly.
Consider the following list of directories:
The bin directory with the setenv.sh, setenv.bat, and tomcat-juli.jar files.
Recommended: No.
Order of lookup: CATALINA_BASE is checked first; fallback is provided to CATALINA_HOME.
The lib directory with further resources to be added on classpath.
Recommended: Yes, if your application depends on external libraries.
Order of lookup: CATALINA_BASE is checked first; CATALINA_HOME is loaded second.
The logs directory for instance-specific log files.
Recommended: Yes.
The webapps directory for automatically loaded web applications.
Recommended: Yes, if you want to deploy applications.
Order of lookup: CATALINA_BASE only.
The work directory that contains temporary working directories for the deployed web applications.
Recommended: Yes.
The temp directory used by the JVM for temporary files.
Recommended: Yes.
We recommend you not to change the tomcat-juli.jar file. However, in case you require your own logging implementation, you can replace the tomcat-juli.jar file in a CATALINA_BASE location for the specific Tomcat instance.
We also recommend you copy all configuration files from the CATALINA_HOME/conf directory into the CATALINA_BASE/conf/ directory. In case a configuration file is missing in CATALINA_BASE, there is no fallback to CATALINA_HOME. Consequently, this may cause failure.
At minimum, CATALINA_BASE must contain:
conf/server.xml
conf/web.xml
That includes the conf directory. Otherwise, Tomcat fails to start, or fails to function properly.
For advanced configuration information, see the RUNNING.txt file.
How to Use CATALINA_BASE
The CATALINA_BASE property is an environment variable. You can set it before you execute the Tomcat start script, for example:
On Unix: CATALINA_BASE=/tmp/tomcat_base1 bin/catalina.sh start
On Windows: CATALINA_BASE=C:\tomcat_base1 bin/catalina.bat start
Configuring Tomcat
This section will acquaint you with the basic information used during the configuration of the container.
All of the information in the configuration files is read at startup, meaning that any change to the files necessitates a restart of the container.
Where to Go for Help
While we've done our best to ensure that these documents are clearly written and easy to understand, we may have missed something. Provided below are various web sites and mailing lists in case you get stuck.
As Tomcat 7 is a new release of Tomcat, keep in mind that some of the issues and solutions vary between the major versions of Tomcat (6.x versus 7.x). As you search around the web, there will be some documentation that is not relevant to Tomcat 7, but 6.x, 5.x or earlier versions. Doing 3.x or 4.x things to 7 will probably not work in most cases as the server.xml files are very different.
Current document - most documents will list potential hangups. Be sure to fully read the relevant documentation as it will save you much time and effort. There's nothing like scouring the web only to find out that the answer was right in front of you all along!
Tomcat FAQ
Tomcat WIKI
Tomcat FAQ at jGuru
Tomcat mailing list archives - numerous sites archive the Tomcat mailing lists. Since the links change over time, clicking here will search Google.
The TOMCAT-USER mailing list, which you can subscribe to here. If you don't get a reply, then there's a good chance that your question was probably answered in the list archives or one of the FAQs. Although questions about web application development in general are sometimes asked and answered, please focus your questions on Tomcat-specific issues.
The TOMCAT-DEV mailing list, which you can subscribe to here. This list is reserved for discussions about the development of Tomcat itself. Questions about Tomcat configuration, and the problems you run into while developing and running applications, will normally be more appropriate on the TOMCAT-USER list instead.
And, if you think something should be in the docs, by all means let us know on the TOMCAT-DEV list.
The installer will create shortcuts allowing starting and configuring Tomcat. It is important to note that the Tomcat administration web application can only be used when Tomcat is running.
Comments
Post a Comment