Capture server-side import logs

[jamoore]

The thread(s) which perform the server-side import should have their log4j output redirected to files which can be stored for later evaluation. This will allow users to download their own import logs as well as prevent the server log from filling up with 2012-10-12 11:24:16,180 WARN [l.model.enums.handlers.MediumEnumHandler] (l.Server-5) Unknown Medium value 'null' will be stored as "Other".

Further, it may be of benefit to capture a partial client-side log of the upload and transmit that to the server for safe storage.

Both of these files then should be available, either via the API as original files under /OMERO/Files or be stored in the managed repository beside the other files. (NB: If pyramid files are also stored in the managed repo, then it might be nice to keep them all together. See #4873).

Implementation details: it's not entirely clear how this information will be captured unless the import happens in a separate Java process. The major barrier to using a separate Java process is the memory usage issue with Java. If we do perform the import in the server process, then either we will need something like a thread-local loggers, or (worst case) we will need to modify how all the import classes obtain their logger.

[jmoore]

One option may be to use logback's ​SiftingAppender which would log to a file var/log/import-${THREADNUMBER}.log. The file could be copied after the import and then nulled.

This may requiring changing all use of commons-logging to logback (via slf4j) throughout OMERO. Bio-Formats is already solely slf4j-based.

[jmoore]

Not included in fs demo 2 tag. Removing from sprint

[cblackburn]

See: ​http://github.com/openmicroscopy/openmicroscopy/pull/1062

Further configuration, refactoring and clean-up may be needed. These will be done under new tickets.