I like it. And if i use terracotta i wouldn't mind such a marker interface anyway. I don't really find it ugly Especially if terracotta can use this for subtype matching then it would be sooo much easier..
Only one problem that is see.. Still lists or maps that are used by use are ofcourse not marked like that. i do agree that the current configuration could be a drive with no real end and very error prone. (or at least a cycle of try and error) when using it for a large project. johan On 2/28/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Hi, I'm making an inventory of classes that should be instrumented by Terracotta if you deploy for them. I have a whole bunch of classes and interfaces like PopupSettings and IPageable and IPagingLabelProvider that are serializable which typically means in the context of Wicket that they should be available for serializing. Now, just telling Terracotta to instrument everything that implements Serializable isn't gonna work as that is way to course and touches classes outside the scope of Wicket easily (think of all the hibernate classes etc you might use). I'd like to propose introducing an interface like 'Clusterable' that simply extends Serializable and replacing all the classes in Wicket that implement Serializable to implement that instead. Not only would that communicate our intend a little bit better, but it would also mean that we could just tell the Terracotta config file to instrument all implementations of that interface and be done with it. Thats easier to get to a good configuration for Terracotta now *and* if we keep on playing by those rules for the Wicket projects, we can refactor what we want without ever having to be worried about breaking a Terracotta configuration (not to mention having to maintain several versions of that configuration). Any grave objections to this? Eugene, will that work? Regards, Eelco
