I wish I had a good and short explanation why generics do not make sense
here. As mentioned a little earlier, DBNameResolver provides a service
to DBAppender. DBAppender has a DBNameResolver but does not store a
collection of DBNameResolvers or process DBNameResolvers. Besides that,
generics in Java are quite clumsy to use. More to the point and as you
probably know already, generics get erased (type erasure) as explained in
http://java.sun.com/docs/books/tutorial/java/generics/erasure.html
One cannot do much with java generics really. To be honest, I don't see
the point of generics here. Anyway, what's your second idea?
On 26.02.2010 14:01, Durchholz, Joachim wrote:
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
