- empty file
- not a valid VOTable document

In such cases, the following error message is returned:
  "The input file is not a valid VOTable document!"
A cause with more detais (especially the line and column numbers)
may be appended.

Cases handled with no error:

  - If the VOTable document has no rows, an empty table
    is uploaded. No error has to be returned.

  - If a row has a different number of columns than the number
    of declared FIELDs, additional values are ignored and missing
    values are replaced by NULL. This is actually nicely handled by
    STIL.

ResultSetTableIterator (i.e. functions returning unknown numeric values
were not set with the right datatype but char* instead).

Date and Time are converted into a string with the following resp.
formats: 'yyyy-MM-dd' and 'HH:mm:ss'.

68666ccb
It happens that the JDBC driver returned an Integer instead of a Short for a
Postgres SMALLINT column. This is not a problem for all formats because of
implicit cast, except for FITS which requires an exact correct type. This
commit ensure that columns declared as SMALLINT in the metadata are always
casted as Short.

c5cba4ba. The cast into a Short object is
absolutely required for the FITS format.

If a BOOLEAN database column is encountered, its datatype will be considered
as SMALLINT (because TAP 1.0 does not support BOOLEAN) and its values will
be converted into 0 for FALSE and 1 for TRUE. This last part was missing
in the TAP library before this commit.

This is particularly annoying for numeric functions like sqrt(...)
(example query: SELECT TOP 1 sqrt(2) as s2 FROM whatever_table).
This bug has been raised by M. Taylor.

See the commit bd621842,
for the first part of the fix (which actually did not really
fixed the problem: connections "idle in transaction" were
still in the database ; the connection being inside an opened transaction,
it generates lock issues in the database in addition of probably taking
some memory resources).

The transaction and Statement were closed too early before.
  - Fetching the row was not possible once the first bunch of fetched
rows was over.
  - The problem of "statement is aborted" preventing the re-use of
a same DB connection was apparently still there, but occurred less often.

  Now, any transaction potentially started in a DB connection is always
closed after one of the public functions of JDBCConnection is called ;
except executeQuery(ADQLQuery) whose the call MUST be wrapped inside a
try...catch block in which DBConnection.cancel(true) MUST be called
in case of error (in order to effectively end any started transaction).

1) [TAP & UWS] ]MAJOR BUG FIX: The abortion of an SQL query is now correctly
implemented. Before this fix, 2 mistakes prevented this clean abortion:
  a/ The thread was not cancelled because the SQL query execution was
blocking the thread. Then the thread could not treat the interruption though
it was flagged as interrupted.
  b/ The function UWSJob.isStopped() considered the job as stopped because
the interrupted flag was set, even though the thread was still processing
(and the database too). Because of that it returned true and the job phase
was ABORTED though the thread was still running.
  NOW:
  a/ TAPJob calls the function Statement.cancel() (if supported) in order
to cancel the SQL query execution properly inside the database.
  b/ The function UWSJob.isStopped() does not test any more the interrupted flag
and returns true only if the thread is really stopped.
  IN BRIEF: It is now sure that a job in the phase ABORTED is really stopped
(that's to say: thread stopped AND DB query execution stopped).

2) [TAP] BUG FIX: When the writing of a result is abnormaly interrupted for any
reason, the file which was being written is deleted.

function ResultSetTableIterator.nextCol(). The formatting is now performed
in ResultSetTableIterator.formatColValue(Object).

format. A ClassCastException was thrown about an impossible cast from String to
Character.

(merge with branch 'unknownFctType')

[TAP] Fix unterminated thread after a failed UPLOAD. This bug happened when an uploaded VOTable reading was interrupted by an exception (like a ParseException)....the streaming thread was not stopped and was still waiting for a notification in order to read the next row.

[TAP] Add an XML TableSet parser. The main modification done in JDBCConnection is about the schema prefix of table when the DBMS does not support schemas: now, only standard tables are expected with the prefix 'TAP_SCHEMA_' and the upload tables also with 'TAP_UPLOAD_'.

[UWS,TAP] Fix UPLOAD bug (the last line of the table to upload was ignored). Fix an improbable NullPointerException in the MultipartParser.

[TAP] Fix bug in VOTable reading. The STIL consumer must be in a different thread. OnceRowPipe has been then replaced by a new internal static class re-doing the same work plus some adaptations, particularly to stop properly the stream reading before reaching the end of the VOTable.

[ADQL,TAP] Add geometry format in output and correct upload of STC-S regions. Geometrical type conversion from and into a DB type is now required in all JDBCTranslator. This allows formatting of geometrical column value coming from the database, but also the translation of STC-S expressions provided in uploaded table into geometrical column values.

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

[UWS,TAP] Fix timestamp format. Now, each returned date will expressed in UTC and using the ISO8601 format. Any given date is also expected in UTC (or with a time zone offset) and in ISO8601Format. These rules apply also for uploaded tables and for timestamp columns in a query result.

[TAP] Check ADQLExecutor behavior + Review/Add/Complete Javadoc in all classes of this commit except AsyncThread and TAPParameters + Remake the upload management

[TAP,ADQL] Improve and remake a part of the database connection. Missing javadoc has been added when missing in the modified tables.

[TAP] Replace Savot by STIL + Change datatype management in TAPColumn (vot-type is no more available from here), TAPType (no votable type inside it) and VotType (can now be created from a TAPType instance + a VotType instance can be converted easily in a TAPType object)

[TAP] Improve TableIterator + Adapt ResultSetTableIterator (particularly because of the last commit about TAPType and VotType) + Add a TableIterator for VOTable input: VOTableIterator + Add its JUnit test case

[TAP] Add the interface TableIterator (whose implementations let iterate over any kind of table data set) and its first implementation for ResultSet + JUnit test case