jalview

That looks good. I was almost going to do something similar (I was thinking jalview.log.Log, but jalview.bin.Console is just as good) so happy with this!

I'm abandoning this review for now (see my comments on the issue). For what its worth since this is a string literal you should at least follow convention JALVIEW_LOGGER rather than a generic 'LOGGER_NAME'. The code for routing logged content from other loggers should probably be a method on Cache... or even better, separate all this out into the jalview.util.Log4j class so Cache doesn't get polluted with log configuration cruft.

At the moment it is only used in jalview.bin.Cache, but it is used in separate places where appenders are added. Previous to this it was relying on the String name of the appender being correctly used. However the Strings that were being used were not the same so it was broken (I don't know how that manifested itself, but it definitely would not have worked the way it used to!).
Feasibly a separate logger made in the future (e.g. API logger?) will want to add this Appender and will likely not be made in jalview.bin.Cache, so putting a constant String somewhere generically connected with Log4j seemed sensible. Correct it needs documenting!

Does this really need to be a string constant ? (I'm not convinced) needs documenting as the log4j internal name for the log if it really needs to be external.

I know the problems you had with close() - you mentioned in the comments on the issue. However, you might have noticed that FileParse.close() is not called from many places, so changing its behaviour wouldn't have too many side effects.

The intended pattern for FileParse.close() was:

ParserThing pt;
try {
pt = new <? assignable to FileParse>(data spec..)
.. do whatever needed to trigger parsing
.. then check pt's error/warning status and report any problems.
} catch (IOException ..) {
.. handle read or parse errors 
}
finally {
if (pt!=null) {
pt.close();
} // catch and report any IOErrors if desired
}

I tried this first, but FileParse.close() deliberately leaves the FileParse in an error state, which caused problems later (I don't remember the specifics). I could not work out why the FileParse.close() was designed to do this but suspect changing this methos so it's (in general) not left in an error state will cause bigger problems. Also, since Jalview is used to having dataIn for the lifetime of the alignment, I wasn't sure if nulling the object would cause unforeseen errors (in e.g. filename etc).

Maybe it would be best to overload FileParse.close() to pass in an error value/message, then it would essentially be calling FileParse.closeDataIn() instead of FileParse.dataIn.close()

Agree with the finally {} – forgot that (not been a java programmer for quite long enough!). Presumably that should go in FileParse and not AlignFile too.

Ideally, any low level file ops should happen in the base class (FileParse) rather than here. AlignFile should call the FileParse.close() method rather than directly manipulate dataIn, which is managed by FileParse. Note that FileParse.close() nulls the dataIn reference so the stream can be garbage collected properly.

It's also good practice to try to close() in a finally {} clause, catching and reporting exceptions if needed... this is actually what the FileParse.close() method's design was intended for, since the caller should have already checked 'error' and 'errormessage' for parsing problems. Exceptions/Errors on close are not fatal for file import.