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.

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.

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

[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] 3 MAJOR DEPENDENT FIX: improve significantly the parameters extraction from HTTP request in UWS (1) AND move the file-upload ability into the UWS library (2) AND the modification of parameters in UWS is now conform with the standard (3). (1) Only application/x-form-urlencoded content-type was supported. However a UWS must accept a request body containing only an XML document as a single byReference parameter. It is now done when the content-type is not known. (2) Besides multipart/form-data is now fully supported in UWS and so is still possible in TAP. (3) In the UWS standard, parameters can not be added after creation: they can just be modified. This rule is now respected in the UWS library.

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