- uws.service.UWS.VERSION  (static final)
  - tap.resource.TAP.VERSION (static final)

Dealing with several protocol versions in the same time is quite difficult and
may significantly alter the libraries API in an unstable way. That's why, for
the TAP and UWS libraries, only one version is implemented (i.e. the last one).
To use a older version of the protocol, one must use an older version of the
corresponding library.

About the versioning of the ADQL standard, there is no need to set any version
number somewhere because a different ADQL version implies a different grammar.
It means that a different parser is required for each ADQL version. For the
moment, there is only one version, so no need to change anything to the ADQL
library about ADQL version. Later, ADQLParser should become an interface and
a factory will have to be used in order to get the parser corresponding to the
desired ADQL version.

in TAP_SCHEMA.

RegTAP is detected successfully if the schema 'rr' exists (case sensitive)
and contains at least the following tables (names also case sensitive):
	- capability
	- interface
	- intf_param
	- relationship
	- res_date
	- res_detail
	- res_role
	- res_schema
	- res_subject
	- res_table
	- resource
	- table_column
	- validation

The table name can be prefixed by 'rr' (case sensitive) or not. For instance:
'rr.capability' and 'capability' are both detected successfully.

All these constraints (including the case sensitive one) are based on the
requirements of the RegTAP-1.0 standard document. They are set in order
to not declare the RegTAP DM by accident AND to provide a first low
validation of the RegTAP schema and tables. Low validation because
columns (as well as datatype, utypes, indices and UDF functions) are
never checked.

This commit resolves the GitHub issue #51

The previous fix was made against the ObsCore-DM 1.1 because the given
IVO-ID was rejected by EuroVO registry. Now that EuroVO registry has
fixed its IVO-ID rule, the IVO-ID of ObsCore 1.1 is accepted.
Hence this commit.

TAP capabilities resource content.

TAP capabilities resource content.

Execution duration should be expressed in seconds in this TAP endpoint,
but the TAP Library was returning its internal value which is expressed in
milliseconds.

request which has initiated the job creation. Actually the HTTP request is
generated as before, and then, if a job is created, it is set to the ID of the
HTTP request. This modification aims to greatly help the log analysis.

[UWS,TAP] Errors and log management improvements. Particularly, now TAP and UWS are able to manage correctly HTTP request abortions (i.e. when the user stop the request before the response has been fully sent, or when there is a connection problem or a time-out). Such abortions are considered by UWS and TAP merely as job abortion/cancel. No error is logged any more. In addition of this correction, log entries concerning the execution of a TAP sync/async job have been modified so that having more coherents messages. And stack traces of exception that occurred when executing a job (sync or async, tap or uws) are displayed just once: at the JOB END log entry, and not by the HTTP RESPONSE_SENT entry. And finally, output flush and interruption detection are made more often when writing a query result (the flush is particularly important when combining with fetch-size > 0 in synchronous mode....the sync response is then a streaming output).

[UWS,TAP] Set the user who submits the request in an HttpServletRequest attribute. Thus, every TAP and UWS resources can get it without extracting the information every time from the HttpServletRequest.

[TAP] Add a new database access method in the configuration file: get a Datasource from JNDI. & Better support of connection pooling (TAPFactory.countFreeConnections() has been removed ; when the creation of a database connection fails with an SQLException, it is considered that no connection are momentarily available...async jobs will be queued and all sync requests will be rejected).

[UWS,TAP] Add clean release of all resources (e.g. Threads, Timers, DB connections) allocated in a UWS and a TAP service. Small changes of the UWS API...but only if ExecutionManager, DestructionManager and UWS have been implemented by library users rather than using the default implementation.

[UWS,TAP] Review some log messages (in the log file but also in the error summary of a job) ; particularly stack traces are added into the error summary, but are displayed just once in the logs.

[TAP,UWS] Addition to the last commit: the TAP resource /sync did not yet use the RequestParser to get its parameters, and so it did not worked as before the last commit.

[TAP] Make TAP and UWSService use the same ServiceErrorWriter AND make DefaultTAPErrorWriter use the same VOTableFormat as the one declared as OutputFormat in the ServiceConnection.

[ADQL,TAP] Add STC-S and UDFs support in the ADQL parser. Now, it is possible to provide a list of allowed UDFs, regions and coordinate systems. The ServiceConnection of TAP is now able to provide these lists and to propagate them to the ADQLExecutor. UDFs and allowed regions are now listed automatically in the /capabilities resource of TAP. The type 'geometry' is now fully supported in ADQL. That's why the new function 'isGeometry()' has been added to all ADQLOperand extensions. Now the DBChecker is also able to check roughly types of columns and UDFs (unknown when parsing syntactically a query). The syntax of STC-S regions (expressed in the REGION function) are now checked by DBChecker. However, for the moment, geometries are not serialized in STC-S in the output....but it should be possible in some way in the next commit(s).

[TAP,UWS] Fix a problem with the format of the error details returned by the parameter .../error/details. In TAP a VOTable document is expected, but a text/plain description was returned (default behavior in the UWS lib.). Now, a ServiceErrorWriter is used to format the error details correctly.

[UWS,TAP] Review the exceptions and logs management + Add log file rotation (with a configurable rotation frequency)

[TAP] Remake TAPFactory into an abstract class + let limit the number of jobs (async and sync) by allowing the TAPFactory to communicate with a connection pool

[TAP] Remove all generic types + Delete specific (for ResultSet) output formatters + Modify the main output formatter

TAP: Fix incorrect XML format: the INFO for PROVIDER was not ended properly => an error was raised by TOPCAT when a Java error was occuring in TAP or in a query execution.