`fix_on_fail` in the configuration file. By default, this feature is disabled.

_With 15cd5944, this commit finishes the resolution of the GitHub issue #104 ._

_This commit fixes the GitHub issue #97 ._

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.

Until now, the generated VOTable file was un-readable even by
STIL/STILTS/TOPCAT. To fix this, it was needed to temporary store the table to
format into FITS so that STIL can read it at least 2 times.

_This commit fixes the GitHub issue #43 ._

_This commit completes the GitHub issue #106 ._

commit.

`upload_max_file_size` and `upload_default_db_limit`.

The previous text formatting process was storing the entire table in memory....
hence OutOfMemoryError when dealing with large table.

Now, this process is done entirely in memory only for a table having less than
1000 lines. For a larger table, its content is stored in a temporary file. This
file is deleted after usage or in case of error.

This formatting process has been tested under JVM monitoring (both JConsole and
VisualVM) and tables larger than 3,000,000 rows, with success.

This commit fixes the GitHub issue #40

Before this fix, cancelling a TAP job (async or not) which was formatting the
result in ASCII may failed, especially for large results. This was due to a
non interruptible alignment process. This process is now checking whether a
cancellation has been requested before formatting a new result line/row ; if so,
the process is immediately stopped and the job can be cleaning declared as
aborted.

(see previous commit).

When defining in the configuration file a different name for TAP_SCHEMA content,
the service implementor was also forced to define the same mapping in the
database with the column `dbName`.

This is no longer necessary. From now on, the `dbName` column will be ignored
for all standard TAP_SCHEMA content. Instead, the name specified in the
configuration file (if any) will be used instead. This way, the mapping for
standard TAP_SCHEMA content is only specified once and at only one place:
the configuration file.

_This commit resolves the GitHub issue #98_

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

Before correction, if two uploaded tables have been submitted by the user with
the same name, or if one uploaded table contained duplicated column names, an
obscure error message coming from the database was returned to the user.

Now, duplicated items (tables and columns) are searched before ingestion in the
database. When one is detected, an error is immediately returned to the user and
the query is aborted.

Files uploaded by the user when creating/executing a synchronous job were never
deleted after the job execution.

The same problem applied for the tables already uploaded in the database (in
`TAP_UPLOAD`) when an error occurred before the end of the UPLOAD process.

Now, in case of error when uploading one or more files, or in case of success of
the job, all uploaded files and their corresponding database tables are deleted
after the end of the job.

Then, UWS or TAP implementors are free to use whatever logging system they want
(e.g. log4j, logback, ...).

forwarding toward a JSP file in the WebContent directory.

The name of the attribute is merely `tap`.

While waiting for a clean ADQL-2.1 implementation, the BOOLEAN datatype will
be still considered as SMALLINT. But at least, the TableSetParser (used in the
ADQL-Library Online Validator) won't reject tables.xml with a BOOLEAN datatype.

The end of the description of a UDF was not detected when this UDF was followed
by another UDF definition. This was due to an incorrect double quote escape in
the regular expression of a UDF's definition.

and ALWAYS_ARCHIVE.

When archiving a job, its former phase is stored in jobInfo under the name
'oldPhase' if no jobInfo is already set.

Archiving a job means that all input files and results are destroyed ; the
error summary and jobInfo (even if it is a file) are kept.

Each archive operation ends with a log message ; in ERROR if failed or in
INFO if successful.

This commit also includes the following things:

    - reformat on 80 characters width the Javadoc of all modified classes

	- fix a bug with the phase transitions: since it is not possible any more
	  to go from PENDING to EXECUTING directly, UWSJob.start(...) must first
	  ensure to be on QUEUED phase. This bug has also been fixed in TAPJob.
	  Similarly, before going into ARCHIVED phase the job must be set into
	  ABORTED phase if not already in a final phase.

This property is displayed in the XML and JSON serialization of a job item.
It is also backuped and restored from a UWS backup file.

/!\ WARNING: Small modification of the API! Since creationTime must be
             set by the UWS service at creation of a job, this date must also
             be imported at backup restoration. Hence the modification of the
             interface uws.service.UWSFactory and its implementations
             (particularly tap.AbstractTAPFactory). Similarly the class
             uws.job.UWSJob and tap.job.TAPJob have underwent exactly the same
             modification in one of their constructors.

This commit also adds the new optional jobRef items: creationTime, runID and
ownerID in the XML and JSON serializations.

Although the Java code allowed the specification of a description of a User
Defined Function, it was not possible to set one in the UDFs listed in the
configuration file.

This commit fixes a typo introduced in the commit
09ee79c4 ; because of that the VOTable's COOSYS
was not added anymore in query results.

in the TAP configuration file.

Now, JDBCConnection is fully capable to test the existence of schemas, tables
and columns of a MySQL database. Thanks to @zonia3000 for solving this issue.

The order of its children was incorrect according to the XSD schema:
the 'fkColumn' must be written before 'description' and 'utype'.

  - 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

standard table. The same for the additional column
TAP_SCHEMA.columns.coosys_id.

in the TAP metadata.

This help will be later used in the complete documentation of the TAPLibrary.

This commit resolves partially the issue #28

Ideally, there should be an implementation of UWSLog and TAPLog working with
Log4j and another for SLF4J (and eventually for other logging mechanism).
Additionally, an implementation storing log messages in database would be
interesting. All these ideas may be implemented in UWSLib and TAPLib in a
future version.

and HashMap more generic by returning resp. a List and Map instead.

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.

On the contrary to other DBMS, MySQL supports schemas, but as databases.
Which means that JDBCConnection gets from the JDBC driver that MySQL does
not support schemas and so it tries to access TAP_SCHEMA tables with a
'TAP_SCHEMA_' prefix instead of 'TAP_SCHEMA.' one. Since MySQL does
behave like it supports schemas, JDBCConnection.supportsSchema must be
set to 'true' if the DBMS is MySQL.

Besides, since no schemas are returned by the JDBC driver
(cf DatabaseMetadata.listSchema(...)), the function
JDBCConnection.isSchemaExisting(String, DatabaseMetaData) must always assume
that the specified schema exists if the DBMS is MySQL. This is particularly
important when the existence of 'TAP_UPLOAD' must be checked, because if the
function returns 'false' the library will attempt to create the database/schema
'TAP_UPLOAD' and will obviously fail due to a lack of permissions. Of course,
it means that the TAP implementor must create manually the schema/database
'TAP_UPLOAD' him-/her-self.

The second particularity of MySQL is the quote character for identifiers.
It is a back-quote (`) instead of a double quote ("). To reflect this
difference, JDBCTranslator.appendIdentifier(...) has been overwritten in a new
JDBCTranslator extension: MySQLTranslator.

The translation of all SQL types and mathematical functions have been adapted to
MySQL according to the online documentation. Few tests have been done locally
with a tiny database. This seems to work but further testing should be
performed in order to ensure the stability of this implementation.