Quote file separator to avoid backslash failures in reg-exp (especially on a Windows-OS)

tables.

Since commit 3d96c9d9 aliases put on a table
without double quotes are put in lower case and then double quoted. This
modification was not effective for ORDER BY's column identifiers.

The previous commit broke some JUnit tests. It was indeed not any more possible
to prefix a column with the fully qualified table name
(e.g. `"aSchema"."aTable"`) if the table was automatically aliased. If an alias
is set on a table, this table should be referenced only by this alias. The
previous commit was not able to replace fully qualified table names with their
corresponding alias....and doing that would probably introduce other unexpected
parsing/checking behaviors.

So, it is better to keep this part of the parsing as simple as now. Just for few
DB error messages showing real database names (and only if they are different
from the ADQL ones), it does not worth _yet_ making the parsing more complex.

_This commit ends the issue #108 ._

(i.e. not a subquery).

The idea is to avoid ambiguous error messages coming from the database when
raising an error on a table or column name having different DB and ADQL names.

This commit sets by default an alias on each table reference. This default
alias is the ADQL table name as it is used in the ADQL query.

_This commit fixes the GitHub issue #108 ._

As @vforchi said:

> The ANSI standard `||` is supported only by Oracle and Postgres: MySQL uses
> `CONCAT` and SQLServer uses `+`.

_This commit resolves the issue #70 ._

Merge pull request #107 from vforchi/fix_content_length

UWSToolBox).

_ See GitHub Issue #100 _

commit.

`upload_max_file_size` and `upload_default_db_limit`.

In Java 8, implementing the function remove() of the interface Iterator<E> is
no longer required if not implemented. But not in Java 7.

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_

file (actually, replaces the real backup file by the temporary one).

Sometimes a temporary backup file (i.e. a file named like `*.backup.temp-*`) is
not deleted. This means that the log rotation fails and that, potentially, some
jobs have not been updated/deleted. This commit is there is re-enforce the
replacement operation.

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

This bug occurred "just" due to an un-desired inverted test, since UWS-1.1 is
implemented (UWSLib-4.3 and TAPLib-2.2).

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

[UWS,TAP] Add the dependency SLF4J in `lib/`. Follow-up to 5f18ac69.

attribute.

In this way, it is possible to run two different instances of a UWS/TAP service
with a different temporary directory in the same JVM.

The attribute `version` in the node `job` is never restored ; it is just
informative. Thus, it is now silently ignored.

The attribute `length` of an upload was badly spelled.

The attribute `mime-type` of a result was backuped as `mime-type` but restored
as `mime`. Hence the absence of this piece of information when restoring a job.

_This latter will soon be removed from UWSLib._

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.

(possibly NULL) was used instead of the class variable (which is NEVER NULL).

passed by reference.

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

This error occurred generally during the backup process while trying to
backup the job list of a specific user. If several of his jobs were running
and changing state during the backup process, this
ConcurrentModificationException was thrown. This generally happens when the same
user submits a lot of shorts jobs in the same time.

This exception was due to a non thread-safe usage of
UWSParameters.additionalParams. To fix this issue, instead of creating it as a
normal HashMap, it is now created as a ConcurrentHashMap.

The same modification has also been applied to UWSParameters.params. In addition
of the replacement of HashMap into ConcurrentHashMap, all `synchronized` blocks
have been removed....there should not be needed any more.

When enabled, it was generating a file each minute on the day before the
specified day of week.

For instance: if the log rotation frequency was `W 1 0 0` (so, weekly on Sunday
at 00:00). The rotation was performed on Saturday midnight. But, because of a
bad index correction, the rotation kept going on the whole day of Saturday.
Since the rotated file is suffixed by the timestamp with hours and minutes
(no seconds), it actually generated a new log file for each minute of the
saturday. Of course, each time the file contained only one line (or 2 with some
luck)...which is pretty useless.

backup file.

The previous commit was only applied on the whole backup file.

Instead of writing the new backup content in the final backup file directly,
write it first in a temporary file and then change the files name.

This fix prevents incomplete backup files (particularly in case of one backup
file per user) when stopping/restarting by force.

When a custom key was encountered, the library tried to fetch its value as a
String...but it is not always a String. Instead, now it is fetch as an Object
(possibly a JSONObject or JSONArray).