Hi again, I have put together a second version which does away with the need to instrument TerracottaPageStore and AbstractPageStore, but not AbstractPageStore$SerializedPage (no getting away from that).
I have also improved the synchronisation stuff (i think, its not my strong point) and added a few more comments. In the end I did make the classes static inner classes; i moved all the code calls to the methods in AbstractPageStore, to other places. Please take a look and tell me what you think. Richard http://www.nabble.com/file/p18280052/TerracottaPageStore.java TerracottaPageStore.java richardwilko wrote: > > It does add a slight overhead but I dont think 2 extra classes wouldn't be > noticed. > > I can't use static inner classes because the methods in AbstractPageStore > aren't static. > > Your suggestion would work, with a slight modification: > > (TerracottaPageStore) > ((SecondLevelCacheSessionStore)Application.get().getSesssionStore()).getStore(); > > So I will have a look at implementing it that way instead. > > Cheers, > > Richard > > > > Stefan Fußenegger wrote: >> >> I don't understand the problem. Is it just the visibility of those >> methods? If yes, TerracottaPageStore could allow public access to any >> protected method if needed. Or you could use static inner classes to >> remove this (hidden) reference and use lazy property initialization to >> get your hands on the current JVM's TerracottaSessionStore using: >> >> <code> >> private transient TerracottaSessionStore _tss; >> >> public TerracottaSessionStore getTerracottaSessionStore() { >> if (_tss == null) _tss = (TerracottaSesssionStore) >> Application.get().getSesssionStore(); >> return _tss; >> } >> </code> >> >> However, doesn't instrumenting classes that aren't meant be shared sound >> like unnecessary overhead? >> >> best regards >> Stefan >> >> >> >> > > -- View this message in context: http://www.nabble.com/Terracotta-integration-tp18168616p18280052.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
