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-tp18168616p18279779.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
