Yea there is lots that is instrumented that now wont need to be.
There are only 4 classes that need instrumenting for the page store; the 3
inner classes of TerrcottaPageStore, and $SerializedPage. But im not sure
what classes are needed for the other stuff thats stored in httpsession,
like the actual Session (or user defined subclass) and the
SessionBindingListener
Johan Compagner wrote:
>
> 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.
>>>
>>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Terracotta-integration-tp18168616p18380772.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
