In the current terracotta module will terracotta not monitor/instrument also
pages, components and models?
If we have this page store.. Then terracotta should only work on that page
store class right?
The rest is something that shouldnt be touched
johan
On Thu, Jul 10, 2008 at 12:40 PM, Ari Zilka <[EMAIL PROTECTED]> wrote:
> 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.
>>
>>
>
