Commit 0e4a4a66 authored by aaime's avatar aaime
Browse files

Merge branch 'rel_2.2-RC3' into rel_2.2.x

parents 3e95fe6b dd4c2caa
......@@ -20,10 +20,10 @@
AXIS[&quot;Latitude&quot;, NORTH]]</nativeCRS>
<srs>EPSG:4326</srs>
<nativeBoundingBox>
<minx>147.2910004483</minx>
<maxx>147.2910004483</maxx>
<miny>-42.851001816890005</miny>
<maxy>-42.851001816890005</maxy>
<minx>145.19754</minx>
<maxx>148.27298000000002</maxx>
<miny>-43.423512</miny>
<maxy>-40.852802</maxy>
<crs>EPSG:4326</crs>
</nativeBoundingBox>
<latLonBoundingBox>
......@@ -85,4 +85,4 @@
</attributes>
<maxFeatures>0</maxFeatures>
<numDecimals>0</numDecimals>
</featureType>
\ No newline at end of file
</featureType>
......@@ -47,7 +47,7 @@ copyright = u'2011 GeoServer'
# The short X.Y version.
version = '2.2'
# The full version, including alpha/beta/rc tags.
release = '2.2-RC2'
release = '2.2-RC3'
# Users don't need to see the "SNAPSHOT" notation when it's there
if release.find('SNAPSHOT') != -1:
release = '2.2.x'
......
......@@ -14,6 +14,7 @@ Welcome to the GeoServer Developer Manual. The manual is for those who want to
eclipse-guide/index
findbugs-guide/index
programming-guide/index
release-schedule/index
release-guide/index
release-testing-checklist/index
cite-test-guide/index
......
......@@ -119,7 +119,7 @@ The following outlines the steps to be taken in order to add a new community mod
</profile>
</profiles>
#. Edit ``web/pom.xml`` and add the following inside of the ``<profiles>``
#. Edit ``web/app/pom.xml`` and add the following inside of the ``<profiles>``
element:
.. code-block:: xml
......@@ -250,7 +250,7 @@ Process
<module>myCommunityModule</module>
</modules>
#. Edit ``web/pom.xml`` and move the dependency on the community module
#. Edit ``web/app/pom.xml`` and move the dependency on the community module
into the main dependencies section of the pom. Then remove the profile
*Extensions*
......
.. _time_boxed_releases:
Release Schedule
================
Starting with version 2.2 GeoServer releases follow a time boxed model in which releases occur
at regular predictable frequencies rather than at ad-hoc dates. In a time boxed the software is
released at predictable frequencies with whatever fixes, improvements, and feature are available
at the time of release. This differs from the previous feature based model in which releases occur
when a certain number of key features have accumulated.
To compensate for the inherent unpredictability of the release contents the model includes strict
rules about what type of development is appropriate during specific periods of a branches life
cycle. These rules include a suitably long hardening period for the unstable branch to mature and
eventually become stable.
Release branches
----------------
At any given time GeoServer is undergoing two to three main branches of development.
#. The *stable* branch in which only bug fixing, and smaller scale feature development occurs on
#. The *unstable* (master) branch in which more experimental and larger scale feature development occurs
#. The *maintenance* branch which was the previously stable branch that is nearing end of life and sees
only the most stable development, typically mostly bug fixes.
Release cycle
-------------
On the stable branches release follow a monthly cycle in a which a new minor release occurs once a
month. On the unstable branch releases follow a 6 month cycle in which a new major release occurs
once every 6 months. The following diagram illustrates the cycle:
.. image:: timeboxed.png
Things to note:
* monthly releases on the stable branch
* a four month open development period followed by two months hardening period on the unstable branch
* beta releases are supposed to be released out of the unstable series on a monthly basis
across the switch between open development and hardening, followed by the first release candidate
* release candidates are pushed out every two weeks until we reach a stable code base, which will be released
as the new major stable release
* the first release candidate marks the branch off of a new trunk, on which open development starts again
The time of the first release candidate marks the origin of a new stable branch in which the unstable branch
becomes the stable branch, and the stable branches becomes a maintenance branch.
Every month, on the same day, a new release is issued from the stable branch using whatever revision of
GeoServer/Geotools passed the last CITE tests. The release is meant to improve upon the previous release in
both functionality and stability, so unless the project steering committee determines reasons to block the release
it will happen regardless of what bug reports are in Jira. Pending resourcing, they can be fixed in the next release
that comes out one month later.
At any given point in time there are two branches under the development, the stable branch and the master/unstable
branch. Once every six months when the creation of a new stable branch occurs a third active maintenance branch
is created. This branch is kept up to date with the stable stable for a period of one-month after which the final
release on that branch is created. That said there is nothing against a developer continuing to maintain the branch
or creating release from it, it is just not expected.
Development phases
------------------
The type of development that can occur on a branch is dictated by where the branch is in terms of its life cycle.
Stable branch
`````````````
The type of acceptable development on the stable branch does not change much over its lifetime. It is meant
for bug fixes and new features that do not affect the GeoServer API or significantly affect the stability.
A PSC vote (with eventual proposal) can be called in case a significant new feature or change needs
to be back ported to the stable branch overriding the above rules.
If, for any reason, a release is delayed the next release will be rescheduled 30 days after the last release
(that is, delaying the whole train of remaining releases).
Unstable branch
```````````````
The type of development on the master/unstable branch changes over its lifetime from four months of open
development to two months of stable/hardening development.
Open development phase
``````````````````````
The open development phase starts when the new stable release is branched off, and ends when hardening
starts, four months after the new stable release is made.
During this phase developers are free to commit stability undermining changes (even significant ones).
Those changes still need to be voted as GSIP anyways to ensure, as usual, resourcing checks, API consistency
and community review.
After three months from the release of the stable series a first beta will be released,
one month after that the second beta will be released and the branch will switch into hardening mode.
Hardening phase
```````````````
The hardening phase starts when the second beta is released and continues through all release candidate (RC)
releases. The first RC is released one month after the second beta, and then bi-weekly releases
will be issued until no major issues will be reported by the user base, at which point the last RC
will be turned into the new stable release.
During hardening only bug-fixes and new non core plugins can be developed
Commit rules
------------
The following are guidelines as to what types of commits can occur in any particular phase. While the PSC
reserves the right to vote and override the committing guidelines the following rules reflect the
current policies.
The **hardening phase**, and by extension the stable and open phases, can receive any of the following
types of commits:
* bug fixes
* documentation improvements
* new plugins contributed as community or extension modules (with a cautionary note that during
hardening the attention should be concentrated as much as possible on getting the new release stable)
In addition the **stable phase** can receive any of the following types of commits:
* new minor core functionality (e.g. new output format)
* new API that we can commit to for a long period of time (provided it's not a change to existing API unless the PSC votes otherwise).
GeoServer is not a library, so defining API can be hard, but any class that can be used by pluggable
extension points should be changed with care, especially so in a stable series
In addition to the above the **stable phase** can receive the following types of changes provided there are no
reservations or concerns about them from the PSC. Such changes may be subject to voting:
* promotion of extensions to core
* core changes that are unlikely to affect the stability of the upcoming release
(if the PSC is ok better land them right after a release to get as a large window for testing as possible)
* back port of larger changes that have proven to be working well on trunk for an extended period of time
During the **open development phase** all types of commits are fair game but of course large changes are still subject to proposals and reviews.
\ No newline at end of file
......@@ -47,7 +47,7 @@ copyright = u'2011 GeoServer'
# The short X.Y version.
version = '2.2'
# The full version, including alpha/beta/rc tags.
release = '2.2-RC2'
release = '2.2-RC3'
# Users don't need to see the "SNAPSHOT" notation when it's there
if release.find('SNAPSHOT') != -1:
release = '2.2.x'
......
......@@ -359,6 +359,7 @@ border-bottom: 0 none transparent;
#content img {
margin-bottom: 10px;
max-width:99%;
}
#content .figure img {
......
......@@ -16,7 +16,6 @@ officially part of the GeoServer releases. They are however built along with the
:maxdepth: 1
authkey/index
controlflow/index
css/index
dxf/index
dds/index
......
......@@ -69,18 +69,34 @@ Monitor Database
By default monitored request data is stored in an embedded H2 database located
in the ``monitoring`` directory. This can be changed by editing the
``db.properties`` file::
``db.properties`` and ``hibernate.properties`` file::
# default configuration is for h2
driver=org.h2.Driver
url=jdbc:h2:file:${GEOSERVER_DATA_DIR}/monitoring/monitoring
For example to store request data in an external PostgreSQL database::
For example to store request data in an external PostgreSQL database, set ``db.properties`` to::
driver=org.postgresql.Driver
url=jdbc:postgresql://192.168.1.124:5432/monitoring
username=bob
password=foobar
and ``hibernate.properties`` to::
hibernate.use_sql_comments=true
databasePlatform=org.hibernate.dialect.PostgreSQLDialect
generateDdl=true
hibernate.format_sql=true
showSql=false
hibernate.generate_statistics=true
hibernate.session_factory_name=SessionFactory
hibernate.hbm2ddl.auto=update
hibernate.bytecode.use_reflection_optimizer=true
database=POSTGRESQL
hibernate.show_sql=false
The maximum size of the request body that is logged is set in the ``monitor.properties`` and ``mappings.hbm.xml`` files. If the setting in ``monitor.properties`` is higher than that in ``mappings.hbm.xml`` any long requests will fail to be logged entirely. You can set it to be unbounded if your database supports it.
Request Filters
---------------
......
......@@ -25,6 +25,21 @@ Request information can be returned in CSV format, for easier post-processing::
GET http://localhost:8080/geoserver/rest/monitor/requests.csv
Request bodies containing newlines are handled with quoted text. If your CSV reader doesn't handle quoted newlines, it will not work correctly.
All requests as PKZip
^^^^^^^^^^^^^^^^^^^^^
A PKZip archive containing the CSV file above, with all the request bodies and errors as separate files::
GET http://localhost:8080/geoserver/rest/monitor/requests.zip
All requests as MS Excel
^^^^^^^^^^^^^^^^^^^^^^^^
A Microsoft Excel spreadsheet containing the same information as the CSV file::
GET http://localhost:8080/geoserver/rest/monitor/requests.xls
Requests during a time period
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Requests can be filtered by date and time range::
......@@ -66,6 +81,8 @@ and ``format`` specifies the representation of the returned result as one of:
* ``html`` - an HTML table.
* ``csv`` - a Comma Separated Values table.
* ``zip`` - PKZip archive containing CSV as above, plus plain text of errors and request body.
* ``xls`` - Microsoft Excel spreadsheet.
.. note::
......@@ -75,6 +92,8 @@ and ``format`` specifies the representation of the returned result as one of:
* ``text/html``
* ``application/csv``
* ``application/zip``
* ``application/vnd.ms-excel``
See the `HTTP specification <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html>`_
for more information about the ``Accept`` header.
......@@ -187,9 +206,9 @@ Specifies which request attribute to sort by, and optionally specifies the sort
* - ``order=<attribute>[;<ASC|DESC>]``
- requests.html?order=path
* -
- requests.html?order=startTime:DESC
- requests.html?order=startTime;DESC
* -
- requests.html?order=totalTime:ASC
- requests.html?order=totalTime;ASC
......
......@@ -25,7 +25,7 @@ import sys, os, string
# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
extensions = ['sphinx.ext.todo']
todo_include_todos = True
#todo_include_todos = True
# Add any paths that contain templates here, relative to this directory.
#templates_path = ['../../theme/_templates']
......@@ -39,7 +39,7 @@ master_doc = 'index'
# General substitutions.
project = u'GeoServer'
manual = u'User Manual'
copyright = u'2011 GeoServer'
copyright = u'GeoServer'
# The default replacements for |version| and |release|, also used in various
# other places throughout the built documents.
......@@ -47,7 +47,7 @@ copyright = u'2011 GeoServer'
# The short X.Y version.
version = '2.2'
# The full version, including alpha/beta/rc tags.
release = '2.2-RC2'
release = '2.2-RC3'
# Users don't need to see the "SNAPSHOT" notation when it's there
if release.find('SNAPSHOT') != -1:
release = '2.2.x'
......
......@@ -100,6 +100,7 @@ In order to restore the GeoServer 2.1 configuration:
geoserver.jceks
masterpw.xml
masterpw.digest
masterpw.info
auth/
filter/
masterpw/
......
......@@ -13,6 +13,7 @@ see the :ref:`data_vector`, :ref:`data_raster`, and :ref:`data_database` section
.. toctree::
:maxdepth: 2
controlflow/index
excel
geosearch
imagemap
......
.. _gwc_config:
GeoWebCache Configuration
=========================
Configuration
=============
GeoWebCache is automatically configured to be used with GeoServer with the most common options, with **no setup required**. All communication between GeoServer and GeoWebCache happens by passing messages inside the JVM.
By default, all layers served by GeoServer will be known to GeoWebCache. See the :ref:`gwc_demo` page to test the configuration.
By default, all layers served by GeoServer will be known to GeoWebCache. See the :ref:`webadmin_tilecaching_layers` page to test the configuration.
.. note:: Configuration of the integrated GeoWebCache changed significantly as of version 2.2.0.
Integrated user interface
-------------------------
GeoWebCache has a full integrated web-based configuration. See the :ref:`webadmin_tilecaching` section in the :ref:`web_admin`.
Determining tiled layers
------------------------
In versions of GeoServer prior to 2.2.0, the GeoWebCache integration was done in a such way that every GeoServer layer and layer group was forced to have an associated GeoWebCache tile layer. In addition, every such tile layer was forcedly published in the EPSG:900913 and EPSG:4326 gridsets with PNG and JPEG output formats.
Now, it is possible to selectively turn caching on or off for any layer served through GeoServer. This setting can be done on the :ref:`webadmin_tilecaching_layers` section in the :ref:`web_admin`.
Configuration files
-------------------
It is possible to configure most aspects of cached layers through the :ref:`webadmin_tilecaching` section in the :ref:`web_admin` or the :ref:`gwc_rest`.
GeoWebCache keeps the configuration for each GeoServer tiled layer separately, inside the :file:`<data_dir>/gwc-layers/` directory. There is one XML file for each tile layer. These files contain a different syntax from the ``<wmsLayer>`` syntax in the standalone version and are *not* meant to be edited by hand. Instead you can configure tile layers on the :ref:`webadmin_tilecaching_layers` page or through the :ref:`gwc_rest`.
Configuration for the defined gridsets still is saved in :file:`<data_dir>/gwc/geowebcache.xml`` so that the integrated GeoWebCache can continue to serve externally-defined tile layers from WMS services outside GeoServer.
If upgrading from a version prior to 2.2.0, a migration process is run which creates a tile layer configuration for all the available layers and layer groups in GeoServer with the old defaults. From that point on, you should configure the tile layers on the :ref:`webadmin_tilecaching_layers` page.
.. note:: The ``GEOSERVER_WMS_URL`` parameter in :file:`web.xml`, used in earlier versions of GeoServer, is deprecated and should not be used.
Changing the cache directory
----------------------------
......@@ -25,13 +49,9 @@ Change the path inside ``<param-value>`` to the desired cache path (such as :fil
.. note:: Make sure GeoServer has write access in this directory.
Custom configuration
--------------------
If you need to access more features than the automatic configuration offers, you can create a custom configuration file. Inside the GeoWebCache cache directory (see above), create a file named :file:`geowebcache.xml`. Please refer to the `GeoWebCache documentation <http://geowebcache.org/docs>`_ for how to customize this file. Restart GeoServer for the changes to take effect. You may also wish to check the logfiles after starting GeoServer to verify that this file has been successfully read.
GeoWebCache with multiple GeoServer instances
---------------------------------------------
For stability reasons, it is not recommended to use the embedded GeoWebCache with multiple GeoServer instances. If you want configure GeoWebCache as a front-end for multiple instances of GeoServer, we recommend using the `standalone GeoWebCache <http://geowebcache.org>`_.
......@@ -5,16 +5,16 @@ Caching with GeoWebCache
.. image:: geowebcache.png
GeoWebCache is a tiling server. It runs as a proxy between a map client and map server, caching (storing) tiles as they are requested, eliminating redundant request processing and thus saving large amounts of processing time. GeoWebCache has been integrated into GeoServer, although it is also available as a `standalone product <http://geowebcache.org>`_ for use with other map servers.
GeoWebCache is a tiling server. It runs as a proxy between a map client and map server, caching (storing) tiles as they are requested, eliminating redundant request processing and thus saving large amounts of processing time. GeoWebCache is integrated with GeoServer, though it is also available as a standalone product for use with other map servers.
This section will discuss the version of GeoWebCache embedded in GeoServer. For information about the standalone product, please see the `GeoWebCache homepage <http://geowebcache.org>`_.
This section will discuss the version of GeoWebCache integrated with GeoServer. For information about the standalone product, please see the `GeoWebCache homepage <http://geowebcache.org>`_.
.. toctree::
:maxdepth: 2
using
config
demopage
seeding
responseheaders
rest/index
troubleshooting
.. _gwc_responseheaders:
HTTP Response Headers
=====================
The GeoWebCache integrated with GeoServer employs special information stored in the header of responses. These headers are available either with direct calls to the :ref:`GeoWebCache endpoint <gwc_endpoint>` or with :ref:`direct WMS integration <gwc_directwms>`.
Custom response headers
-----------------------
GeoWebCache returns both standard and custom HTTP response headers when serving a tile request. This aids in the debugging process, as well as adhering to an HTTP 1.1 transfer control mechanism.
The response headers can be determined via a utility such as `cURL <http://curl.haxx.se>`_.
Example
~~~~~~~
.. note:: For all cURL commands below, make sure to replace ``>/dev/null`` with ``>nul`` if you are running on Windows.
This is a sample request and response using cURL:
.. code-block:: console
curl -v "http://localhost:8080/geoserver/gwc/service/wms?LAYERS=sde%3Abmworld&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&SRS=EPSG%3A4326&BBOX=-180,-38,-52,90&WIDTH=256&HEIGHT=256&tiled=true" > /dev/null
::
< HTTP/1.1 200 OK
< geowebcache-tile-index: [0, 1, 2]
< geowebcache-cache-result: HIT
< geowebcache-tile-index: [0, 1, 2]
< geowebcache-tile-bounds: -180.0,-38.0,-52.0,90.0
< geowebcache-gridset: GlobalCRS84Pixel
< geowebcache-crs: EPSG:4326
< Content-Type: image/png
< Content-Length: 102860
< Server: Jetty(6.1.8)
From this, one can learn that the tile was found in the cache (``HIT``), the requested tile was from the gridset called ``GlobalCRS84Pixel`` and had a CRS of ``EPSG:4326``.
List of custom response headers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following is the full list of custom response headers. Whenever GeoWebCache serves a tile request, it will write some or all of the following custom headers on the HTTP response.
.. list-table::
:header-rows: 1
* - Response Header
- Description
* - ``geowebcache-cache-result``
- Shows whether the GeoWebCache WMS was used. Options are:
* ``HIT``: Tile requested was found on the cache
* ``MISS``: Tile was not found on the cache but was acquired from the layer's data source
* ``WMS``: Request was proxied directly to the origin WMS (for example, for GetFeatureInfo requests)
* ``OTHER``: Response was the default white/transparent tile or an error occurred
* - ``geowebcache-tile-index``
- Contains the three-dimensional tile index in x,y,z order of the returned tile image in the corresponding grid space (e.g. ``[1, 0, 0]``)
* - ``geowebcache-tile-bounds``
- Bounds of the returned tile in the corresponding coordinate reference system (e.g. ``-180,-90,0,90``)
* - ``geowebcache-gridset``
- Name of the gridset the tile belongs to (see :ref:`webadmin_tilecaching_gridsets` for more information)
* - ``geowebcache-crs``
- Coordinate reference system code of the matching gridset (e.g. ``EPSG:900913``, ``EPSG:4326``, etc).
.. _gwc_lastmodifiedheaders:
Last-Modified and If-Modified-Since
-----------------------------------
Well behaved HTTP 1.1 clients and server applications can make use of ``Last-Modified`` and ``If-Modified-Since`` HTTP control mechanisms to know when locally cached content is up to date, eliminating the need to download the same content again. This can result in considerable bandwidth savings. (See HTTP 1.1 `RFC 2616 <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html>`_, sections 14.29 and 14.25, for more information on these mechanisms.)
GeoWebCache will write a ``Last-Modified`` HTTP response header when serving a tile image. The date is written as an RFC-1123 ``HTTP-Date``::
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Clients connecting to GeoWebCache can create a "conditional GET" request with the ``If-Modified-Since`` request header. If the tile wasn't modified after the date specified in the ``Last-Modified`` response header, GeoWebCache will return a ``304`` status code indicating that the resource was available and not modified.
Example
~~~~~~~
A query for a specific tile returns the ``Last-Modified`` response header:
.. code-block:: console
curl -v "http://localhost:8080/geoserver/gwc/service/wms?LAYERS=img%20states&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A4326&BBOX=-135,45,-90,90&WIDTH=256&HEIGHT=256" >/dev/null
::
> Host: localhost:8080
> Accept: */*
>
< HTTP/1.1 200 OK
...
< Last-Modified: Wed, 25 Jul 2012 00:42:00 GMT
< Content-Type: image/png
< Content-Length: 31192
This request has the ``If-Modified-Since`` header set to one second after what was returned by ``Last-Modified``:
.. code-block:: console
curl --header "If-Modified-Since: Wed, 25 Jul 2012 00:42:01 GMT" -v "http://localhost:8080/geoserver/gwc/service/wms?LAYERS=img%20states&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A4326&BBOX=-135,45,-90,90&WIDTH=256&HEIGHT=256" >/dev/null
::
> Host: localhost:8080
> Accept: */*
> If-Modified-Since: Wed, 25 Jul 2012 00:42:01 GMT
>
< HTTP/1.1 304 Not Modified
< Last-Modified: Wed, 25 Jul 2012 00:42:00 GMT
< Content-Type: image/png
< Content-Length: 31192
The response code is ``304``. As the file hasn't been modified since the time specified in the request, no content is actually transferred. The client is informed that its copy of the tile is up to date.
However, if you were to set the ``If-Modified-Since`` header to *before* the time stored in ``Last-Modified``, you will instead receive a ``200`` status code and the tile will be downloaded.
This example sets the ``If-Modified-Since`` header to one second before what was returned by ``Last-Modified``:
.. code-block:: console
curl --header "If-Modified-Since: Wed, 25 Jul 2012 00:41:59 GMT" -v "http://localhost:8080/geoserver/gwc/service/wms?LAYERS=img%20states&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A4326&BBOX=-135,45,-90,90&WIDTH=256&HEIGHT=256" >/dev/null
::
> Host: localhost:8080
> Accept: */*
> If-Modified-Since: Wed, 25 Jul 2012 00:41:59 GMT
>
< HTTP/1.1 200 OK
...
< Last-Modified: Wed, 25 Jul 2012 00:42:00 GMT
< Content-Type: image/png
< Content-Length: 31192
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment