> 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 :) _______________________________________________ logback-dev mailing list [email protected] http://qos.ch/mailman/listinfo/logback-dev
