Grosse MàJ

This commit is contained in:
olivier
2008-11-25 22:11:16 +01:00
parent 53195fdfcd
commit 3e719157ea
2980 changed files with 343846 additions and 0 deletions

View File

@ -0,0 +1,497 @@
<!--
General purpose build script for web applications and web services,
including enhanced support for deploying directly to a Tomcat 6
based server.
This build script assumes that the source code of your web application
is organized into the following subdirectories underneath the source
code directory from which you execute the build script:
docs Static documentation files to be copied to
the "docs" subdirectory of your distribution.
src Java source code (and associated resource files)
to be compiled to the "WEB-INF/classes"
subdirectory of your web applicaiton.
web Static HTML, JSP, and other content (such as
image files), including the WEB-INF subdirectory
and its configuration file contents.
$Id: build.xml.txt 525818 2007-04-05 13:16:43Z remm $
-->
<!-- A "project" describes a set of targets that may be requested
when Ant is executed. The "default" attribute defines the
target which is executed if no specific target is requested,
and the "basedir" attribute defines the current working directory
from which Ant executes the requested task. This is normally
set to the current working directory.
-->
<project name="My Project" default="compile" basedir=".">
<!-- ===================== Property Definitions =========================== -->
<!--
Each of the following properties are used in the build script.
Values for these properties are set by the first place they are
defined, from the following list:
* Definitions on the "ant" command line (ant -Dfoo=bar compile).
* Definitions from a "build.properties" file in the top level
source directory of this application.
* Definitions from a "build.properties" file in the developer's
home directory.
* Default definitions in this build.xml file.
You will note below that property values can be composed based on the
contents of previously defined properties. This is a powerful technique
that helps you minimize the number of changes required when your development
environment is modified. Note that property composition is allowed within
"build.properties" files as well as in the "build.xml" script.
-->
<property file="build.properties"/>
<property file="${user.home}/build.properties"/>
<!-- ==================== File and Directory Names ======================== -->
<!--
These properties generally define file and directory names (or paths) that
affect where the build process stores its outputs.
app.name Base name of this application, used to
construct filenames and directories.
Defaults to "myapp".
app.path Context path to which this application should be
deployed (defaults to "/" plus the value of the
"app.name" property).
app.version Version number of this iteration of the application.
build.home The directory into which the "prepare" and
"compile" targets will generate their output.
Defaults to "build".
catalina.home The directory in which you have installed
a binary distribution of Tomcat 6. This will
be used by the "deploy" target.
dist.home The name of the base directory in which
distribution files are created.
Defaults to "dist".
manager.password The login password of a user that is assigned the
"manager" role (so that he or she can execute
commands via the "/manager" web application)
manager.url The URL of the "/manager" web application on the
Tomcat installation to which we will deploy web
applications and web services.
manager.username The login username of a user that is assigned the
"manager" role (so that he or she can execute
commands via the "/manager" web application)
-->
<property name="app.name" value="myapp"/>
<property name="app.path" value="/${app.name}"/>
<property name="app.version" value="0.1-dev"/>
<property name="build.home" value="${basedir}/build"/>
<property name="catalina.home" value="../../../.."/> <!-- UPDATE THIS! -->
<property name="dist.home" value="${basedir}/dist"/>
<property name="docs.home" value="${basedir}/docs"/>
<property name="manager.url" value="http://localhost:8080/manager"/>
<property name="src.home" value="${basedir}/src"/>
<property name="web.home" value="${basedir}/web"/>
<!-- ==================== External Dependencies =========================== -->
<!--
Use property values to define the locations of external JAR files on which
your application will depend. In general, these values will be used for
two purposes:
* Inclusion on the classpath that is passed to the Javac compiler
* Being copied into the "/WEB-INF/lib" directory during execution
of the "deploy" target.
Because we will automatically include all of the Java classes that Tomcat 6
exposes to web applications, we will not need to explicitly list any of those
dependencies. You only need to worry about external dependencies for JAR
files that you are going to include inside your "/WEB-INF/lib" directory.
-->
<!-- Dummy external dependency -->
<!--
<property name="foo.jar"
value="/path/to/foo.jar"/>
-->
<!-- ==================== Compilation Classpath =========================== -->
<!--
Rather than relying on the CLASSPATH environment variable, Ant includes
features that makes it easy to dynamically construct the classpath you
need for each compilation. The example below constructs the compile
classpath to include the servlet.jar file, as well as the other components
that Tomcat makes available to web applications automatically, plus anything
that you explicitly added.
-->
<path id="compile.classpath">
<!-- Include all JAR files that will be included in /WEB-INF/lib -->
<!-- *** CUSTOMIZE HERE AS REQUIRED BY YOUR APPLICATION *** -->
<!--
<pathelement location="${foo.jar}"/>
-->
<!-- Include all elements that Tomcat exposes to applications -->
<fileset dir="${catalina.home}/bin">
<include name="*.jar"/>
</fileset>
<pathelement location="${catalina.home}/lib"/>
<fileset dir="${catalina.home}/lib">
<include name="*.jar"/>
</fileset>
</path>
<!-- ================== Custom Ant Task Definitions ======================= -->
<!--
These properties define custom tasks for the Ant build tool that interact
with the "/manager" web application installed with Tomcat 6. Before they
can be successfully utilized, you must perform the following steps:
- Copy the file "lib/catalina-ant.jar" from your Tomcat 6
installation into the "lib" directory of your Ant installation.
- Create a "build.properties" file in your application's top-level
source directory (or your user login home directory) that defines
appropriate values for the "manager.password", "manager.url", and
"manager.username" properties described above.
For more information about the Manager web application, and the functionality
of these tasks, see <http://localhost:8080/tomcat-docs/manager-howto.html>.
-->
<taskdef resource="org/apache/catalina/ant/catalina.tasks"
classpathref="compile.classpath"/>
<!-- ==================== Compilation Control Options ==================== -->
<!--
These properties control option settings on the Javac compiler when it
is invoked using the <javac> task.
compile.debug Should compilation include the debug option?
compile.deprecation Should compilation include the deprecation option?
compile.optimize Should compilation include the optimize option?
-->
<property name="compile.debug" value="true"/>
<property name="compile.deprecation" value="false"/>
<property name="compile.optimize" value="true"/>
<!-- ==================== All Target ====================================== -->
<!--
The "all" target is a shortcut for running the "clean" target followed
by the "compile" target, to force a complete recompile.
-->
<target name="all" depends="clean,compile"
description="Clean build and dist directories, then compile"/>
<!-- ==================== Clean Target ==================================== -->
<!--
The "clean" target deletes any previous "build" and "dist" directory,
so that you can be ensured the application can be built from scratch.
-->
<target name="clean"
description="Delete old build and dist directories">
<delete dir="${build.home}"/>
<delete dir="${dist.home}"/>
</target>
<!-- ==================== Compile Target ================================== -->
<!--
The "compile" target transforms source files (from your "src" directory)
into object files in the appropriate location in the build directory.
This example assumes that you will be including your classes in an
unpacked directory hierarchy under "/WEB-INF/classes".
-->
<target name="compile" depends="prepare"
description="Compile Java sources">
<!-- Compile Java classes as necessary -->
<mkdir dir="${build.home}/WEB-INF/classes"/>
<javac srcdir="${src.home}"
destdir="${build.home}/WEB-INF/classes"
debug="${compile.debug}"
deprecation="${compile.deprecation}"
optimize="${compile.optimize}">
<classpath refid="compile.classpath"/>
</javac>
<!-- Copy application resources -->
<copy todir="${build.home}/WEB-INF/classes">
<fileset dir="${src.home}" excludes="**/*.java"/>
</copy>
</target>
<!-- ==================== Dist Target ===================================== -->
<!--
The "dist" target creates a binary distribution of your application
in a directory structure ready to be archived in a tar.gz or zip file.
Note that this target depends on two others:
* "compile" so that the entire web application (including external
dependencies) will have been assembled
* "javadoc" so that the application Javadocs will have been created
-->
<target name="dist" depends="compile,javadoc"
description="Create binary distribution">
<!-- Copy documentation subdirectories -->
<mkdir dir="${dist.home}/docs"/>
<copy todir="${dist.home}/docs">
<fileset dir="${docs.home}"/>
</copy>
<!-- Create application JAR file -->
<jar jarfile="${dist.home}/${app.name}-${app.version}.war"
basedir="${build.home}"/>
<!-- Copy additional files to ${dist.home} as necessary -->
</target>
<!-- ==================== Install Target ================================== -->
<!--
The "install" target tells the specified Tomcat 6 installation to dynamically
install this web application and make it available for execution. It does
*not* cause the existence of this web application to be remembered across
Tomcat restarts; if you restart the server, you will need to re-install all
this web application.
If you have already installed this application, and simply want Tomcat to
recognize that you have updated Java classes (or the web.xml file), use the
"reload" target instead.
NOTE: This target will only succeed if it is run from the same server that
Tomcat is running on.
NOTE: This is the logical opposite of the "remove" target.
-->
<target name="install" depends="compile"
description="Install application to servlet container">
<deploy url="${manager.url}"
username="${manager.username}"
password="${manager.password}"
path="${app.path}"
localWar="file://${build.home}"/>
</target>
<!-- ==================== Javadoc Target ================================== -->
<!--
The "javadoc" target creates Javadoc API documentation for the Java
classes included in your application. Normally, this is only required
when preparing a distribution release, but is available as a separate
target in case the developer wants to create Javadocs independently.
-->
<target name="javadoc" depends="compile"
description="Create Javadoc API documentation">
<mkdir dir="${dist.home}/docs/api"/>
<javadoc sourcepath="${src.home}"
destdir="${dist.home}/docs/api"
packagenames="*">
<classpath refid="compile.classpath"/>
</javadoc>
</target>
<!-- ====================== List Target =================================== -->
<!--
The "list" target asks the specified Tomcat 6 installation to list the
currently running web applications, either loaded at startup time or
installed dynamically. It is useful to determine whether or not the
application you are currently developing has been installed.
-->
<target name="list"
description="List installed applications on servlet container">
<list url="${manager.url}"
username="${manager.username}"
password="${manager.password}"/>
</target>
<!-- ==================== Prepare Target ================================== -->
<!--
The "prepare" target is used to create the "build" destination directory,
and copy the static contents of your web application to it. If you need
to copy static files from external dependencies, you can customize the
contents of this task.
Normally, this task is executed indirectly when needed.
-->
<target name="prepare">
<!-- Create build directories as needed -->
<mkdir dir="${build.home}"/>
<mkdir dir="${build.home}/WEB-INF"/>
<mkdir dir="${build.home}/WEB-INF/classes"/>
<!-- Copy static content of this web application -->
<copy todir="${build.home}">
<fileset dir="${web.home}"/>
</copy>
<!-- Copy external dependencies as required -->
<!-- *** CUSTOMIZE HERE AS REQUIRED BY YOUR APPLICATION *** -->
<mkdir dir="${build.home}/WEB-INF/lib"/>
<!--
<copy todir="${build.home}/WEB-INF/lib" file="${foo.jar}"/>
-->
<!-- Copy static files from external dependencies as needed -->
<!-- *** CUSTOMIZE HERE AS REQUIRED BY YOUR APPLICATION *** -->
</target>
<!-- ==================== Reload Target =================================== -->
<!--
The "reload" signals the specified application Tomcat 6 to shut itself down
and reload. This can be useful when the web application context is not
reloadable and you have updated classes or property files in the
/WEB-INF/classes directory or when you have added or updated jar files in the
/WEB-INF/lib directory.
NOTE: The /WEB-INF/web.xml web application configuration file is not reread
on a reload. If you have made changes to your web.xml file you must stop
then start the web application.
-->
<target name="reload" depends="compile"
description="Reload application on servlet container">
<reload url="${manager.url}"
username="${manager.username}"
password="${manager.password}"
path="${app.path}"/>
</target>
<!-- ==================== Remove Target =================================== -->
<!--
The "remove" target tells the specified Tomcat 6 installation to dynamically
remove this web application from service.
NOTE: This is the logical opposite of the "install" target.
-->
<target name="remove"
description="Remove application on servlet container">
<undeploy url="${manager.url}"
username="${manager.username}"
password="${manager.password}"
path="${app.path}"/>
</target>
</project>

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

View File

@ -0,0 +1,497 @@
<!--
General purpose build script for web applications and web services,
including enhanced support for deploying directly to a Tomcat 6
based server.
This build script assumes that the source code of your web application
is organized into the following subdirectories underneath the source
code directory from which you execute the build script:
docs Static documentation files to be copied to
the "docs" subdirectory of your distribution.
src Java source code (and associated resource files)
to be compiled to the "WEB-INF/classes"
subdirectory of your web applicaiton.
web Static HTML, JSP, and other content (such as
image files), including the WEB-INF subdirectory
and its configuration file contents.
$Id: build.xml.txt 525818 2007-04-05 13:16:43Z remm $
-->
<!-- A "project" describes a set of targets that may be requested
when Ant is executed. The "default" attribute defines the
target which is executed if no specific target is requested,
and the "basedir" attribute defines the current working directory
from which Ant executes the requested task. This is normally
set to the current working directory.
-->
<project name="My Project" default="compile" basedir=".">
<!-- ===================== Property Definitions =========================== -->
<!--
Each of the following properties are used in the build script.
Values for these properties are set by the first place they are
defined, from the following list:
* Definitions on the "ant" command line (ant -Dfoo=bar compile).
* Definitions from a "build.properties" file in the top level
source directory of this application.
* Definitions from a "build.properties" file in the developer's
home directory.
* Default definitions in this build.xml file.
You will note below that property values can be composed based on the
contents of previously defined properties. This is a powerful technique
that helps you minimize the number of changes required when your development
environment is modified. Note that property composition is allowed within
"build.properties" files as well as in the "build.xml" script.
-->
<property file="build.properties"/>
<property file="${user.home}/build.properties"/>
<!-- ==================== File and Directory Names ======================== -->
<!--
These properties generally define file and directory names (or paths) that
affect where the build process stores its outputs.
app.name Base name of this application, used to
construct filenames and directories.
Defaults to "myapp".
app.path Context path to which this application should be
deployed (defaults to "/" plus the value of the
"app.name" property).
app.version Version number of this iteration of the application.
build.home The directory into which the "prepare" and
"compile" targets will generate their output.
Defaults to "build".
catalina.home The directory in which you have installed
a binary distribution of Tomcat 6. This will
be used by the "deploy" target.
dist.home The name of the base directory in which
distribution files are created.
Defaults to "dist".
manager.password The login password of a user that is assigned the
"manager" role (so that he or she can execute
commands via the "/manager" web application)
manager.url The URL of the "/manager" web application on the
Tomcat installation to which we will deploy web
applications and web services.
manager.username The login username of a user that is assigned the
"manager" role (so that he or she can execute
commands via the "/manager" web application)
-->
<property name="app.name" value="myapp"/>
<property name="app.path" value="/${app.name}"/>
<property name="app.version" value="0.1-dev"/>
<property name="build.home" value="${basedir}/build"/>
<property name="catalina.home" value="../../../.."/> <!-- UPDATE THIS! -->
<property name="dist.home" value="${basedir}/dist"/>
<property name="docs.home" value="${basedir}/docs"/>
<property name="manager.url" value="http://localhost:8080/manager"/>
<property name="src.home" value="${basedir}/src"/>
<property name="web.home" value="${basedir}/web"/>
<!-- ==================== External Dependencies =========================== -->
<!--
Use property values to define the locations of external JAR files on which
your application will depend. In general, these values will be used for
two purposes:
* Inclusion on the classpath that is passed to the Javac compiler
* Being copied into the "/WEB-INF/lib" directory during execution
of the "deploy" target.
Because we will automatically include all of the Java classes that Tomcat 6
exposes to web applications, we will not need to explicitly list any of those
dependencies. You only need to worry about external dependencies for JAR
files that you are going to include inside your "/WEB-INF/lib" directory.
-->
<!-- Dummy external dependency -->
<!--
<property name="foo.jar"
value="/path/to/foo.jar"/>
-->
<!-- ==================== Compilation Classpath =========================== -->
<!--
Rather than relying on the CLASSPATH environment variable, Ant includes
features that makes it easy to dynamically construct the classpath you
need for each compilation. The example below constructs the compile
classpath to include the servlet.jar file, as well as the other components
that Tomcat makes available to web applications automatically, plus anything
that you explicitly added.
-->
<path id="compile.classpath">
<!-- Include all JAR files that will be included in /WEB-INF/lib -->
<!-- *** CUSTOMIZE HERE AS REQUIRED BY YOUR APPLICATION *** -->
<!--
<pathelement location="${foo.jar}"/>
-->
<!-- Include all elements that Tomcat exposes to applications -->
<fileset dir="${catalina.home}/bin">
<include name="*.jar"/>
</fileset>
<pathelement location="${catalina.home}/lib"/>
<fileset dir="${catalina.home}/lib">
<include name="*.jar"/>
</fileset>
</path>
<!-- ================== Custom Ant Task Definitions ======================= -->
<!--
These properties define custom tasks for the Ant build tool that interact
with the "/manager" web application installed with Tomcat 6. Before they
can be successfully utilized, you must perform the following steps:
- Copy the file "lib/catalina-ant.jar" from your Tomcat 6
installation into the "lib" directory of your Ant installation.
- Create a "build.properties" file in your application's top-level
source directory (or your user login home directory) that defines
appropriate values for the "manager.password", "manager.url", and
"manager.username" properties described above.
For more information about the Manager web application, and the functionality
of these tasks, see <http://localhost:8080/tomcat-docs/manager-howto.html>.
-->
<taskdef resource="org/apache/catalina/ant/catalina.tasks"
classpathref="compile.classpath"/>
<!-- ==================== Compilation Control Options ==================== -->
<!--
These properties control option settings on the Javac compiler when it
is invoked using the <javac> task.
compile.debug Should compilation include the debug option?
compile.deprecation Should compilation include the deprecation option?
compile.optimize Should compilation include the optimize option?
-->
<property name="compile.debug" value="true"/>
<property name="compile.deprecation" value="false"/>
<property name="compile.optimize" value="true"/>
<!-- ==================== All Target ====================================== -->
<!--
The "all" target is a shortcut for running the "clean" target followed
by the "compile" target, to force a complete recompile.
-->
<target name="all" depends="clean,compile"
description="Clean build and dist directories, then compile"/>
<!-- ==================== Clean Target ==================================== -->
<!--
The "clean" target deletes any previous "build" and "dist" directory,
so that you can be ensured the application can be built from scratch.
-->
<target name="clean"
description="Delete old build and dist directories">
<delete dir="${build.home}"/>
<delete dir="${dist.home}"/>
</target>
<!-- ==================== Compile Target ================================== -->
<!--
The "compile" target transforms source files (from your "src" directory)
into object files in the appropriate location in the build directory.
This example assumes that you will be including your classes in an
unpacked directory hierarchy under "/WEB-INF/classes".
-->
<target name="compile" depends="prepare"
description="Compile Java sources">
<!-- Compile Java classes as necessary -->
<mkdir dir="${build.home}/WEB-INF/classes"/>
<javac srcdir="${src.home}"
destdir="${build.home}/WEB-INF/classes"
debug="${compile.debug}"
deprecation="${compile.deprecation}"
optimize="${compile.optimize}">
<classpath refid="compile.classpath"/>
</javac>
<!-- Copy application resources -->
<copy todir="${build.home}/WEB-INF/classes">
<fileset dir="${src.home}" excludes="**/*.java"/>
</copy>
</target>
<!-- ==================== Dist Target ===================================== -->
<!--
The "dist" target creates a binary distribution of your application
in a directory structure ready to be archived in a tar.gz or zip file.
Note that this target depends on two others:
* "compile" so that the entire web application (including external
dependencies) will have been assembled
* "javadoc" so that the application Javadocs will have been created
-->
<target name="dist" depends="compile,javadoc"
description="Create binary distribution">
<!-- Copy documentation subdirectories -->
<mkdir dir="${dist.home}/docs"/>
<copy todir="${dist.home}/docs">
<fileset dir="${docs.home}"/>
</copy>
<!-- Create application JAR file -->
<jar jarfile="${dist.home}/${app.name}-${app.version}.war"
basedir="${build.home}"/>
<!-- Copy additional files to ${dist.home} as necessary -->
</target>
<!-- ==================== Install Target ================================== -->
<!--
The "install" target tells the specified Tomcat 6 installation to dynamically
install this web application and make it available for execution. It does
*not* cause the existence of this web application to be remembered across
Tomcat restarts; if you restart the server, you will need to re-install all
this web application.
If you have already installed this application, and simply want Tomcat to
recognize that you have updated Java classes (or the web.xml file), use the
"reload" target instead.
NOTE: This target will only succeed if it is run from the same server that
Tomcat is running on.
NOTE: This is the logical opposite of the "remove" target.
-->
<target name="install" depends="compile"
description="Install application to servlet container">
<deploy url="${manager.url}"
username="${manager.username}"
password="${manager.password}"
path="${app.path}"
localWar="file://${build.home}"/>
</target>
<!-- ==================== Javadoc Target ================================== -->
<!--
The "javadoc" target creates Javadoc API documentation for the Java
classes included in your application. Normally, this is only required
when preparing a distribution release, but is available as a separate
target in case the developer wants to create Javadocs independently.
-->
<target name="javadoc" depends="compile"
description="Create Javadoc API documentation">
<mkdir dir="${dist.home}/docs/api"/>
<javadoc sourcepath="${src.home}"
destdir="${dist.home}/docs/api"
packagenames="*">
<classpath refid="compile.classpath"/>
</javadoc>
</target>
<!-- ====================== List Target =================================== -->
<!--
The "list" target asks the specified Tomcat 6 installation to list the
currently running web applications, either loaded at startup time or
installed dynamically. It is useful to determine whether or not the
application you are currently developing has been installed.
-->
<target name="list"
description="List installed applications on servlet container">
<list url="${manager.url}"
username="${manager.username}"
password="${manager.password}"/>
</target>
<!-- ==================== Prepare Target ================================== -->
<!--
The "prepare" target is used to create the "build" destination directory,
and copy the static contents of your web application to it. If you need
to copy static files from external dependencies, you can customize the
contents of this task.
Normally, this task is executed indirectly when needed.
-->
<target name="prepare">
<!-- Create build directories as needed -->
<mkdir dir="${build.home}"/>
<mkdir dir="${build.home}/WEB-INF"/>
<mkdir dir="${build.home}/WEB-INF/classes"/>
<!-- Copy static content of this web application -->
<copy todir="${build.home}">
<fileset dir="${web.home}"/>
</copy>
<!-- Copy external dependencies as required -->
<!-- *** CUSTOMIZE HERE AS REQUIRED BY YOUR APPLICATION *** -->
<mkdir dir="${build.home}/WEB-INF/lib"/>
<!--
<copy todir="${build.home}/WEB-INF/lib" file="${foo.jar}"/>
-->
<!-- Copy static files from external dependencies as needed -->
<!-- *** CUSTOMIZE HERE AS REQUIRED BY YOUR APPLICATION *** -->
</target>
<!-- ==================== Reload Target =================================== -->
<!--
The "reload" signals the specified application Tomcat 6 to shut itself down
and reload. This can be useful when the web application context is not
reloadable and you have updated classes or property files in the
/WEB-INF/classes directory or when you have added or updated jar files in the
/WEB-INF/lib directory.
NOTE: The /WEB-INF/web.xml web application configuration file is not reread
on a reload. If you have made changes to your web.xml file you must stop
then start the web application.
-->
<target name="reload" depends="compile"
description="Reload application on servlet container">
<reload url="${manager.url}"
username="${manager.username}"
password="${manager.password}"
path="${app.path}"/>
</target>
<!-- ==================== Remove Target =================================== -->
<!--
The "remove" target tells the specified Tomcat 6 installation to dynamically
remove this web application from service.
NOTE: This is the logical opposite of the "install" target.
-->
<target name="remove"
description="Remove application on servlet container">
<undeploy url="${manager.url}"
username="${manager.username}"
password="${manager.password}"
path="${app.path}"/>
</target>
</project>

View File

@ -0,0 +1,150 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<!-- General description of your web application -->
<display-name>My Web Application</display-name>
<description>
This is version X.X of an application to perform
a wild and wonderful task, based on servlets and
JSP pages. It was written by Dave Developer
(dave@mycompany.com), who should be contacted for
more information.
</description>
<!-- Context initialization parameters that define shared
String constants used within your application, which
can be customized by the system administrator who is
installing your application. The values actually
assigned to these parameters can be retrieved in a
servlet or JSP page by calling:
String value =
getServletContext().getInitParameter("name");
where "name" matches the <param-name> element of
one of these initialization parameters.
You can define any number of context initialization
parameters, including zero.
-->
<context-param>
<param-name>webmaster</param-name>
<param-value>myaddress@mycompany.com</param-value>
<description>
The EMAIL address of the administrator to whom questions
and comments about this application should be addressed.
</description>
</context-param>
<!-- Servlet definitions for the servlets that make up
your web application, including initialization
parameters. With Tomcat, you can also send requests
to servlets not listed here with a request like this:
http://localhost:8080/{context-path}/servlet/{classname}
but this usage is not guaranteed to be portable. It also
makes relative references to images and other resources
required by your servlet more complicated, so defining
all of your servlets (and defining a mapping to them with
a servlet-mapping element) is recommended.
Servlet initialization parameters can be retrieved in a
servlet or JSP page by calling:
String value =
getServletConfig().getInitParameter("name");
where "name" matches the <param-name> element of
one of these initialization parameters.
You can define any number of servlets, including zero.
-->
<servlet>
<servlet-name>controller</servlet-name>
<description>
This servlet plays the "controller" role in the MVC architecture
used in this application. It is generally mapped to the ".do"
filename extension with a servlet-mapping element, and all form
submits in the app will be submitted to a request URI like
"saveCustomer.do", which will therefore be mapped to this servlet.
The initialization parameter namess for this servlet are the
"servlet path" that will be received by this servlet (after the
filename extension is removed). The corresponding value is the
name of the action class that will be used to process this request.
</description>
<servlet-class>com.mycompany.mypackage.ControllerServlet</servlet-class>
<init-param>
<param-name>listOrders</param-name>
<param-value>com.mycompany.myactions.ListOrdersAction</param-value>
</init-param>
<init-param>
<param-name>saveCustomer</param-name>
<param-value>com.mycompany.myactions.SaveCustomerAction</param-value>
</init-param>
<!-- Load this servlet at server startup time -->
<load-on-startup>5</load-on-startup>
</servlet>
<servlet>
<servlet-name>graph</servlet-name>
<description>
This servlet produces GIF images that are dynamically generated
graphs, based on the input parameters included on the request.
It is generally mapped to a specific request URI like "/graph".
</description>
</servlet>
<!-- Define mappings that are used by the servlet container to
translate a particular request URI (context-relative) to a
particular servlet. The examples below correspond to the
servlet descriptions above. Thus, a request URI like:
http://localhost:8080/{contextpath}/graph
will be mapped to the "graph" servlet, while a request like:
http://localhost:8080/{contextpath}/saveCustomer.do
will be mapped to the "controller" servlet.
You may define any number of servlet mappings, including zero.
It is also legal to define more than one mapping for the same
servlet, if you wish to.
-->
<servlet-mapping>
<servlet-name>controller</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>graph</servlet-name>
<url-pattern>/graph</url-pattern>
</servlet-mapping>
<!-- Define the default session timeout for your application,
in minutes. From a servlet or JSP page, you can modify
the timeout for a particular session dynamically by using
HttpSession.getMaxInactiveInterval(). -->
<session-config>
<session-timeout>30</session-timeout> <!-- 30 minutes -->
</session-config>
</web-app>

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

View File

@ -0,0 +1,497 @@
<!--
General purpose build script for web applications and web services,
including enhanced support for deploying directly to a Tomcat 6
based server.
This build script assumes that the source code of your web application
is organized into the following subdirectories underneath the source
code directory from which you execute the build script:
docs Static documentation files to be copied to
the "docs" subdirectory of your distribution.
src Java source code (and associated resource files)
to be compiled to the "WEB-INF/classes"
subdirectory of your web applicaiton.
web Static HTML, JSP, and other content (such as
image files), including the WEB-INF subdirectory
and its configuration file contents.
$Id: build.xml.txt 525818 2007-04-05 13:16:43Z remm $
-->
<!-- A "project" describes a set of targets that may be requested
when Ant is executed. The "default" attribute defines the
target which is executed if no specific target is requested,
and the "basedir" attribute defines the current working directory
from which Ant executes the requested task. This is normally
set to the current working directory.
-->
<project name="My Project" default="compile" basedir=".">
<!-- ===================== Property Definitions =========================== -->
<!--
Each of the following properties are used in the build script.
Values for these properties are set by the first place they are
defined, from the following list:
* Definitions on the "ant" command line (ant -Dfoo=bar compile).
* Definitions from a "build.properties" file in the top level
source directory of this application.
* Definitions from a "build.properties" file in the developer's
home directory.
* Default definitions in this build.xml file.
You will note below that property values can be composed based on the
contents of previously defined properties. This is a powerful technique
that helps you minimize the number of changes required when your development
environment is modified. Note that property composition is allowed within
"build.properties" files as well as in the "build.xml" script.
-->
<property file="build.properties"/>
<property file="${user.home}/build.properties"/>
<!-- ==================== File and Directory Names ======================== -->
<!--
These properties generally define file and directory names (or paths) that
affect where the build process stores its outputs.
app.name Base name of this application, used to
construct filenames and directories.
Defaults to "myapp".
app.path Context path to which this application should be
deployed (defaults to "/" plus the value of the
"app.name" property).
app.version Version number of this iteration of the application.
build.home The directory into which the "prepare" and
"compile" targets will generate their output.
Defaults to "build".
catalina.home The directory in which you have installed
a binary distribution of Tomcat 6. This will
be used by the "deploy" target.
dist.home The name of the base directory in which
distribution files are created.
Defaults to "dist".
manager.password The login password of a user that is assigned the
"manager" role (so that he or she can execute
commands via the "/manager" web application)
manager.url The URL of the "/manager" web application on the
Tomcat installation to which we will deploy web
applications and web services.
manager.username The login username of a user that is assigned the
"manager" role (so that he or she can execute
commands via the "/manager" web application)
-->
<property name="app.name" value="myapp"/>
<property name="app.path" value="/${app.name}"/>
<property name="app.version" value="0.1-dev"/>
<property name="build.home" value="${basedir}/build"/>
<property name="catalina.home" value="../../../.."/> <!-- UPDATE THIS! -->
<property name="dist.home" value="${basedir}/dist"/>
<property name="docs.home" value="${basedir}/docs"/>
<property name="manager.url" value="http://localhost:8080/manager"/>
<property name="src.home" value="${basedir}/src"/>
<property name="web.home" value="${basedir}/web"/>
<!-- ==================== External Dependencies =========================== -->
<!--
Use property values to define the locations of external JAR files on which
your application will depend. In general, these values will be used for
two purposes:
* Inclusion on the classpath that is passed to the Javac compiler
* Being copied into the "/WEB-INF/lib" directory during execution
of the "deploy" target.
Because we will automatically include all of the Java classes that Tomcat 6
exposes to web applications, we will not need to explicitly list any of those
dependencies. You only need to worry about external dependencies for JAR
files that you are going to include inside your "/WEB-INF/lib" directory.
-->
<!-- Dummy external dependency -->
<!--
<property name="foo.jar"
value="/path/to/foo.jar"/>
-->
<!-- ==================== Compilation Classpath =========================== -->
<!--
Rather than relying on the CLASSPATH environment variable, Ant includes
features that makes it easy to dynamically construct the classpath you
need for each compilation. The example below constructs the compile
classpath to include the servlet.jar file, as well as the other components
that Tomcat makes available to web applications automatically, plus anything
that you explicitly added.
-->
<path id="compile.classpath">
<!-- Include all JAR files that will be included in /WEB-INF/lib -->
<!-- *** CUSTOMIZE HERE AS REQUIRED BY YOUR APPLICATION *** -->
<!--
<pathelement location="${foo.jar}"/>
-->
<!-- Include all elements that Tomcat exposes to applications -->
<fileset dir="${catalina.home}/bin">
<include name="*.jar"/>
</fileset>
<pathelement location="${catalina.home}/lib"/>
<fileset dir="${catalina.home}/lib">
<include name="*.jar"/>
</fileset>
</path>
<!-- ================== Custom Ant Task Definitions ======================= -->
<!--
These properties define custom tasks for the Ant build tool that interact
with the "/manager" web application installed with Tomcat 6. Before they
can be successfully utilized, you must perform the following steps:
- Copy the file "lib/catalina-ant.jar" from your Tomcat 6
installation into the "lib" directory of your Ant installation.
- Create a "build.properties" file in your application's top-level
source directory (or your user login home directory) that defines
appropriate values for the "manager.password", "manager.url", and
"manager.username" properties described above.
For more information about the Manager web application, and the functionality
of these tasks, see <http://localhost:8080/tomcat-docs/manager-howto.html>.
-->
<taskdef resource="org/apache/catalina/ant/catalina.tasks"
classpathref="compile.classpath"/>
<!-- ==================== Compilation Control Options ==================== -->
<!--
These properties control option settings on the Javac compiler when it
is invoked using the <javac> task.
compile.debug Should compilation include the debug option?
compile.deprecation Should compilation include the deprecation option?
compile.optimize Should compilation include the optimize option?
-->
<property name="compile.debug" value="true"/>
<property name="compile.deprecation" value="false"/>
<property name="compile.optimize" value="true"/>
<!-- ==================== All Target ====================================== -->
<!--
The "all" target is a shortcut for running the "clean" target followed
by the "compile" target, to force a complete recompile.
-->
<target name="all" depends="clean,compile"
description="Clean build and dist directories, then compile"/>
<!-- ==================== Clean Target ==================================== -->
<!--
The "clean" target deletes any previous "build" and "dist" directory,
so that you can be ensured the application can be built from scratch.
-->
<target name="clean"
description="Delete old build and dist directories">
<delete dir="${build.home}"/>
<delete dir="${dist.home}"/>
</target>
<!-- ==================== Compile Target ================================== -->
<!--
The "compile" target transforms source files (from your "src" directory)
into object files in the appropriate location in the build directory.
This example assumes that you will be including your classes in an
unpacked directory hierarchy under "/WEB-INF/classes".
-->
<target name="compile" depends="prepare"
description="Compile Java sources">
<!-- Compile Java classes as necessary -->
<mkdir dir="${build.home}/WEB-INF/classes"/>
<javac srcdir="${src.home}"
destdir="${build.home}/WEB-INF/classes"
debug="${compile.debug}"
deprecation="${compile.deprecation}"
optimize="${compile.optimize}">
<classpath refid="compile.classpath"/>
</javac>
<!-- Copy application resources -->
<copy todir="${build.home}/WEB-INF/classes">
<fileset dir="${src.home}" excludes="**/*.java"/>
</copy>
</target>
<!-- ==================== Dist Target ===================================== -->
<!--
The "dist" target creates a binary distribution of your application
in a directory structure ready to be archived in a tar.gz or zip file.
Note that this target depends on two others:
* "compile" so that the entire web application (including external
dependencies) will have been assembled
* "javadoc" so that the application Javadocs will have been created
-->
<target name="dist" depends="compile,javadoc"
description="Create binary distribution">
<!-- Copy documentation subdirectories -->
<mkdir dir="${dist.home}/docs"/>
<copy todir="${dist.home}/docs">
<fileset dir="${docs.home}"/>
</copy>
<!-- Create application JAR file -->
<jar jarfile="${dist.home}/${app.name}-${app.version}.war"
basedir="${build.home}"/>
<!-- Copy additional files to ${dist.home} as necessary -->
</target>
<!-- ==================== Install Target ================================== -->
<!--
The "install" target tells the specified Tomcat 6 installation to dynamically
install this web application and make it available for execution. It does
*not* cause the existence of this web application to be remembered across
Tomcat restarts; if you restart the server, you will need to re-install all
this web application.
If you have already installed this application, and simply want Tomcat to
recognize that you have updated Java classes (or the web.xml file), use the
"reload" target instead.
NOTE: This target will only succeed if it is run from the same server that
Tomcat is running on.
NOTE: This is the logical opposite of the "remove" target.
-->
<target name="install" depends="compile"
description="Install application to servlet container">
<deploy url="${manager.url}"
username="${manager.username}"
password="${manager.password}"
path="${app.path}"
localWar="file://${build.home}"/>
</target>
<!-- ==================== Javadoc Target ================================== -->
<!--
The "javadoc" target creates Javadoc API documentation for the Java
classes included in your application. Normally, this is only required
when preparing a distribution release, but is available as a separate
target in case the developer wants to create Javadocs independently.
-->
<target name="javadoc" depends="compile"
description="Create Javadoc API documentation">
<mkdir dir="${dist.home}/docs/api"/>
<javadoc sourcepath="${src.home}"
destdir="${dist.home}/docs/api"
packagenames="*">
<classpath refid="compile.classpath"/>
</javadoc>
</target>
<!-- ====================== List Target =================================== -->
<!--
The "list" target asks the specified Tomcat 6 installation to list the
currently running web applications, either loaded at startup time or
installed dynamically. It is useful to determine whether or not the
application you are currently developing has been installed.
-->
<target name="list"
description="List installed applications on servlet container">
<list url="${manager.url}"
username="${manager.username}"
password="${manager.password}"/>
</target>
<!-- ==================== Prepare Target ================================== -->
<!--
The "prepare" target is used to create the "build" destination directory,
and copy the static contents of your web application to it. If you need
to copy static files from external dependencies, you can customize the
contents of this task.
Normally, this task is executed indirectly when needed.
-->
<target name="prepare">
<!-- Create build directories as needed -->
<mkdir dir="${build.home}"/>
<mkdir dir="${build.home}/WEB-INF"/>
<mkdir dir="${build.home}/WEB-INF/classes"/>
<!-- Copy static content of this web application -->
<copy todir="${build.home}">
<fileset dir="${web.home}"/>
</copy>
<!-- Copy external dependencies as required -->
<!-- *** CUSTOMIZE HERE AS REQUIRED BY YOUR APPLICATION *** -->
<mkdir dir="${build.home}/WEB-INF/lib"/>
<!--
<copy todir="${build.home}/WEB-INF/lib" file="${foo.jar}"/>
-->
<!-- Copy static files from external dependencies as needed -->
<!-- *** CUSTOMIZE HERE AS REQUIRED BY YOUR APPLICATION *** -->
</target>
<!-- ==================== Reload Target =================================== -->
<!--
The "reload" signals the specified application Tomcat 6 to shut itself down
and reload. This can be useful when the web application context is not
reloadable and you have updated classes or property files in the
/WEB-INF/classes directory or when you have added or updated jar files in the
/WEB-INF/lib directory.
NOTE: The /WEB-INF/web.xml web application configuration file is not reread
on a reload. If you have made changes to your web.xml file you must stop
then start the web application.
-->
<target name="reload" depends="compile"
description="Reload application on servlet container">
<reload url="${manager.url}"
username="${manager.username}"
password="${manager.password}"
path="${app.path}"/>
</target>
<!-- ==================== Remove Target =================================== -->
<!--
The "remove" target tells the specified Tomcat 6 installation to dynamically
remove this web application from service.
NOTE: This is the logical opposite of the "install" target.
-->
<target name="remove"
description="Remove application on servlet container">
<undeploy url="${manager.url}"
username="${manager.username}"
password="${manager.password}"
path="${app.path}"/>
</target>
</project>

View File

@ -0,0 +1,2 @@
This is a dummy README file for the sample
web application.

View File

@ -0,0 +1,30 @@
<html>
<head>
<meta name="author" content="Ben Souther" />
<title>Sample Application</title>
</head>
<body>
<h2>Sample Application</h2>
<p>
The example app has been packaged as a war file and can be downloaded
<a href="sample.war">here</a> (Note: make sure your browser doesn't
change file extension or append a new one).
</p>
<p>
The easiest way to run this application is simply to move the war file
to your <b>CATALINA_HOME/webapps</b> directory. Tomcat will automatically
expand and deploy the application for you. You can view it with the
following URL (assuming that you're running tomcat on port 8080
as is the default):
<br />
<a href="http://localhost:8080/sample">http://localhost:8080/sample</a>
</p>
<p>
If you just want to browse the code you can unpack the war file
with the <b>jar</b> command.
<source>
jar -xvf sample.war
</source>
</p>
</body>
</html>

View File

@ -0,0 +1,83 @@
/*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package mypackage;
import java.io.IOException;
import java.io.PrintWriter;
import java.util.Enumeration;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
/**
* Simple servlet to validate that the Hello, World example can
* execute servlets. In the web application deployment descriptor,
* this servlet must be mapped to correspond to the link in the
* "index.html" file.
*
* @author Craig R. McClanahan <Craig.McClanahan@eng.sun.com>
*/
public final class Hello extends HttpServlet {
/**
* Respond to a GET request for the content produced by
* this servlet.
*
* @param request The servlet request we are processing
* @param response The servlet response we are producing
*
* @exception IOException if an input/output error occurs
* @exception ServletException if a servlet error occurs
*/
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
response.setContentType("text/html");
PrintWriter writer = response.getWriter();
writer.println("<html>");
writer.println("<head>");
writer.println("<title>Sample Application Servlet Page</title>");
writer.println("</head>");
writer.println("<body bgcolor=white>");
writer.println("<table border=\"0\">");
writer.println("<tr>");
writer.println("<td>");
writer.println("<img src=\"images/tomcat.gif\">");
writer.println("</td>");
writer.println("<td>");
writer.println("<h1>Sample Application Servlet</h1>");
writer.println("This is the output of a servlet that is part of");
writer.println("the Hello, World application.");
writer.println("</td>");
writer.println("</tr>");
writer.println("</table>");
writer.println("</body>");
writer.println("</html>");
}
}

View File

@ -0,0 +1,23 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
<display-name>Hello, World Application</display-name>
<description>
This is a simple web application with a source code organization
based on the recommendations of the Application Developer's Guide.
</description>
<servlet>
<servlet-name>HelloServlet</servlet-name>
<servlet-class>mypackage.Hello</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>HelloServlet</servlet-name>
<url-pattern>/hello</url-pattern>
</servlet-mapping>
</web-app>

View File

@ -0,0 +1,23 @@
<html>
<head>
<title>Sample Application JSP Page</title>
</head>
<body bgcolor=white>
<table border="0">
<tr>
<td align=center>
<img src="images/tomcat.gif">
</td>
<td>
<h1>Sample Application JSP Page</h1>
This is the output of a JSP page that is part of the Hello, World
application.
</td>
</tr>
</table>
<%= new String("Hello!") %>
</body>
</html>

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.4 KiB

View File

@ -0,0 +1,28 @@
<html>
<head>
<title>Sample "Hello, World" Application</title>
</head>
<body bgcolor=white>
<table border="0">
<tr>
<td>
<img src="images/tomcat.gif">
</td>
<td>
<h1>Sample "Hello, World" Application</h1>
<p>This is the home page for a sample application used to illustrate the
source directory organization of a web application utilizing the principles
outlined in the Application Developer's Guide.
</td>
</tr>
</table>
<p>To prove that they work, you can execute either of the following links:
<ul>
<li>To a <a href="hello.jsp">JSP page</a>.
<li>To a <a href="hello">servlet</a>.
</ul>
</body>
</html>

File diff suppressed because one or more lines are too long

View File

@ -0,0 +1,150 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<!-- General description of your web application -->
<display-name>My Web Application</display-name>
<description>
This is version X.X of an application to perform
a wild and wonderful task, based on servlets and
JSP pages. It was written by Dave Developer
(dave@mycompany.com), who should be contacted for
more information.
</description>
<!-- Context initialization parameters that define shared
String constants used within your application, which
can be customized by the system administrator who is
installing your application. The values actually
assigned to these parameters can be retrieved in a
servlet or JSP page by calling:
String value =
getServletContext().getInitParameter("name");
where "name" matches the <param-name> element of
one of these initialization parameters.
You can define any number of context initialization
parameters, including zero.
-->
<context-param>
<param-name>webmaster</param-name>
<param-value>myaddress@mycompany.com</param-value>
<description>
The EMAIL address of the administrator to whom questions
and comments about this application should be addressed.
</description>
</context-param>
<!-- Servlet definitions for the servlets that make up
your web application, including initialization
parameters. With Tomcat, you can also send requests
to servlets not listed here with a request like this:
http://localhost:8080/{context-path}/servlet/{classname}
but this usage is not guaranteed to be portable. It also
makes relative references to images and other resources
required by your servlet more complicated, so defining
all of your servlets (and defining a mapping to them with
a servlet-mapping element) is recommended.
Servlet initialization parameters can be retrieved in a
servlet or JSP page by calling:
String value =
getServletConfig().getInitParameter("name");
where "name" matches the <param-name> element of
one of these initialization parameters.
You can define any number of servlets, including zero.
-->
<servlet>
<servlet-name>controller</servlet-name>
<description>
This servlet plays the "controller" role in the MVC architecture
used in this application. It is generally mapped to the ".do"
filename extension with a servlet-mapping element, and all form
submits in the app will be submitted to a request URI like
"saveCustomer.do", which will therefore be mapped to this servlet.
The initialization parameter namess for this servlet are the
"servlet path" that will be received by this servlet (after the
filename extension is removed). The corresponding value is the
name of the action class that will be used to process this request.
</description>
<servlet-class>com.mycompany.mypackage.ControllerServlet</servlet-class>
<init-param>
<param-name>listOrders</param-name>
<param-value>com.mycompany.myactions.ListOrdersAction</param-value>
</init-param>
<init-param>
<param-name>saveCustomer</param-name>
<param-value>com.mycompany.myactions.SaveCustomerAction</param-value>
</init-param>
<!-- Load this servlet at server startup time -->
<load-on-startup>5</load-on-startup>
</servlet>
<servlet>
<servlet-name>graph</servlet-name>
<description>
This servlet produces GIF images that are dynamically generated
graphs, based on the input parameters included on the request.
It is generally mapped to a specific request URI like "/graph".
</description>
</servlet>
<!-- Define mappings that are used by the servlet container to
translate a particular request URI (context-relative) to a
particular servlet. The examples below correspond to the
servlet descriptions above. Thus, a request URI like:
http://localhost:8080/{contextpath}/graph
will be mapped to the "graph" servlet, while a request like:
http://localhost:8080/{contextpath}/saveCustomer.do
will be mapped to the "controller" servlet.
You may define any number of servlet mappings, including zero.
It is also legal to define more than one mapping for the same
servlet, if you wish to.
-->
<servlet-mapping>
<servlet-name>controller</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>graph</servlet-name>
<url-pattern>/graph</url-pattern>
</servlet-mapping>
<!-- Define the default session timeout for your application,
in minutes. From a servlet or JSP page, you can modify
the timeout for a particular session dynamically by using
HttpSession.getMaxInactiveInterval(). -->
<session-config>
<session-timeout>30</session-timeout> <!-- 30 minutes -->
</session-config>
</web-app>