I appreciate the input although considering that DBNameResolver is a mere component of DBAppender, using generics in this case is probably not the best design one can come up with.
The generic design allows subclasses of DBAppender to require (and be guaranteed to get) additional column names. E.g. LBCLASSIC-187 "extend table definition with columns for message parameters" will work with this. Enums won't, you can't extend the list of values in a subclass. The generics solution would also allow extensions in other directions. E.g. to provide additional table names, such as a separate table to normalize out message parameter values. Hope the feedback is still useful Jo P.S.: I've got a last proposal up my sleeve that's geared towards simplicity. But one at a time :)