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

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.

_This commit aims to fix the issue #47_

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

Additionally when an XML document is submitted in an HTTP POST request
(i.e. with the Content-Type = (text|application)/(.+-)?xml), this is
immediately set as a jobInfo in the created job.

This class is using static attributes of type DecimalFormat.
Unfortunately this type of objects can NOT be accessed by multiple
threads simultaneously: it is not thread-safe. Parsing errors,
mostly during TAP uploads, have been experienced for this reason.

To solve quickly this issue, the main static public functions of
ISO8601Format have been synchronized.

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.

set.

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.

ID set by the TAP library was replaced by the one of the TAP library. The
consequence was a possible bad logging and since the ID is a timestamp, the
ID of the request was indicating a time posterior to a job creation.

UWS service.

dates with no seconds, but also with no day or month. Representations in
days of year or weeks of year were not possible as well. Check out the
ISO8601Format class' Javadoc for more details.

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.

when the content-type was not exactly 'application/x-www-form-urlencoded'
for normal POST requests, no parameter was read by the UWS/TAP library.
This content-type test has now been modified from a strict equality to a
startsWith test.
(Note: This bug only concerned the form encoded requests,
not the multipart ones)

in the log output. For that the function UWSToolBox.getParamsMap(...)
had to be modified.

[UWS] Fix bug in UWSServlet: the destroyJob action in POST must be tested before the setJobParam action....otherwise the setJobParam action is always applied which leads to a Forbidden error when trying to destroy a job.

[UWS,TAP] Add the origin of the main exception after the exception class name in the log entries. This origin includes the class, the method, the file and the line where the exception has been thrown.

[UWS,TAP] Fix regression: the log message for the event REQUEST_RECEIVED was not displayed any more.

[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] Change the default log and backup files name. Before it was 'uws.*', but since the same FileManager is used for both services, this default name has been replaced by 'service.*'.

[UWS] Add a log message filter: only messages whose the level is greater or equal to a given one are displayed. This level is by default DEBUG (meaning all messages are always written).

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

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

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

[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 standard parameters checking. Particularly, because before, the default value was never used while no value was specified by the user.

[UWS] Cancel last commit. The UWSException was thrown intentionnaly: if an error occurs while just creating the thread, this error should not impact the job ; it is an internal server error, not an error due to the job execution or of a wrong parameter. This error MUST be thrown AND the job MUST stay PENDING (so that it can be restarted later when the server bug will be fixed). Job parameters checks MUST be done either in the job execution (JobThread.jobWork()) or at the job creation (using an InputParamController).

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