1. Can I get the tc-config.xml that goes with this
2. Terracotta TIMs can do almost anything we need to do here. We can
replace a method on class load. We can probably pain $SerializedPage
inner class to implement the IClusterable interface as well. I dunno
about removing Serializable though. Would we have to?
Anyways, if you ship me a list of what your ideal TIM would do I will
get it configured, bundled in OSGi and back to you by Monday.
I agree though. The TIM could live at Terracotta's forge but should
live with Wicket as it needs to be maintained with changes in Wicket
moreso than changes in Terracotta.
--Ari
On Jul 10, 2008, at 1:58 AM, richardwilko wrote:
to use the new class you would put something like this in your
application
class:
@Override
public ISessionStore newSessionStore() {
return new SecondLevelCacheSessionStore(this, new
TerracottaPageStore(100));
}
where the 100 is number of pages to keep as history, which is user
defined
(please feel free comment on if you think we need a limit or not, or
what a
sensible number is). There is also a default constructor which
doesn't
impose a limit (it will store every page in the page map). This
configurable limit means that we cant really override this method
with the
asm stuff terracotta uses as is done currently.
This means to use terracotta the user will need to add the wicket
tim jar
file as a dependency to their project, so they can compile their code.
However the main reason I thought it might be useful to add it into
the
wicket source is because this page store may have other uses apart
from
terracotta, it would be useful in any instance where DiskPageStore
is not
suitable (disk access too slow or not allowed? Probably not ever
going to
be an issue I know and i'm certainly not suggesting that it should
replace
DiskPageStore). If we had called it HttpSessionPageStore, then it
might
have been clearer what the class actually is. you could also pretty
easily
modify it to be able to optionally store non-serialized Page objects
so that
people who, for whatever reason, cannot serialize their pages would
not have
to use the old HttpSessionStore (which i believe has some other
problems).
Having said that if you don't feel that it should go into wicket
core, then
it can quite happily live in the wicket tim and im not going to say
any more
on it :)
However it still would be useful if
org.apache.wicket.protocol.http.pagestore.AbstractPageStore
$SerializedPage
could implement IClusterable rather than Serializable as this will
make the
terracotta config simpler.
Cheers,
Richard
--
View this message in context:
http://www.nabble.com/Terracotta-integration-tp18168616p18378657.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
