```
RESTORATION Incorrect JSON format for the serialization of an uploaded file!
Caused by a org.json.JSONException: JSONObject["length"] not a string.
[...]

RESTORATION Incorrect JSON format for the DALIUpload labelled "xxx" of the job "xxxxxxxxx": "xxxxxxxx" is not pointing a job parameter representing a file!
[...]

RESTORATION Unexpected error while restoring the UWS!
Caused by a java.lang.NullPointerException: Missing UploadFile! => Can not build a DaliUpload instance.
[...]
```

Now, in case of grave error while restoring backup files, it will be just
disabled, instead of preventing start-up of the TAP service.
In case of non-grave error while restoring a job or a user, the failed job or
error won't be restored and then the restoration process will go on with the
other jobs/users.

The Gradle build file, the ANT build file and the README have also been updating
so that reflecting this upgrade as well as the migration from
com.oreilly.servlet to Apache Commons File Upload.

TAPLib versions of the former commit have also been fixed.

_This commit completes the GitHub issue #106 ._

The property `upload_default_db_limit` has been deprecated. Indeed, in the
current state of the TAP protocol, this makes no sense: the user can not change
the limit size (in bytes or rows) for uploaded tables.

The property `upload_max_file_size` has been deprecated. It is actually
duplicated: `upload_max_db_limit`, if expressed in bytes already lets put a
limit on the maximum size of an uploaded table/file.

The property `upload_max_request_size` has been added. It lets set a maximum
size for a whole HTTP Multipart Request. By default it is set to 250MB.

The default value of `upload_max_db_size` is now 1 million rows.

The UPLOAD feature is still disabled by default (i.e. `upload_enabled=false`).

Thus, the UPLOAD management is much more stable and relies on a well documented
and maintained library (but at the cost of the additionnal size of the final
JAR). The most important point is the capability to efficiently limit the size
of the incoming file and on the disk/memory management when uploading the
file(s) and in case of error during this process (i.e. files must be deleted).

forwarding toward a JSP file in the WebContent directory.

The name of the attribute is merely `tap`.

  - 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.

apply a quick space replacement (by %20) for few URIs of the configuration file
and remove duplicated entry (encoding) from the Gradle build script.

A special test has also been added in getFile(...) in order to deliver
a clear error message for users using a former version with URIs in their
configuration file (only for file_root_path and metadata_file).

47d36bfb
In the UWS and TAP configuration files the executionDuration has to be
provided into milliseconds. But the UWS parameter MUST be in seconds.
So now, UWS is still keeping this duration in seconds (in its
ExecutionDurationController) but TAP keeps it in milliseconds (in order
to avoid unexpected silent modification of the API) and converts it into
seconds for its controller (i.e. TAPExecutionDurationController), for the
default home page and for the Capabilities page.

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.

Can be enabled just by providing a file URI in the TAP configuration file using
the property "examples". It is also possible to add manually a TAP resource
whose the returned name must be "examples" like the new TAP resource is doing:
tap.resource.Examples. This latter take a file URI as the TAP configuration
file does. The referenced file must respect the DALI 1.0 or TAP Notes 1.0
syntax. No check of the file is performed by the library ; it is up to the
author of the referenced file (a XHTML/RDFa file) to write a correct "examples"
endpoint content. Check out the examples provided on the GitHub repository in
the directory examples/tap/examples_endpoint.

[TAP] Improve the default TAP service home page. Particularly, a form with a few basic javascript has been added.

[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).

[ALL] Update ANT build scripts to test all existings JUnit tests before compiling. In case of error, the compilation does not complete.

[TAP] Add home page configuration in the TAP configuration file. (missing file: tap.resource.HomePage)

[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.