+1
Eelco Hillenius 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 > > -- View this message in context: http://www.nabble.com/proposal%3A-Clusterable-instead-of-Serializable-tf3321735.html#a9243253 Sent from the Wicket - Dev mailing list archive at Nabble.com.