On Thu, 6 Dec 2001, Gerhard Froehlich wrote: > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > > > > > >Sylvain Wallez wrote: > >> > >> Sebastien Koechlin a écrit : > >> > > >> > Here is a patch against cocoon_20_branch, I don't know if you can apply > >> > it on HEAD (I did not test). > >> > > >> > Please, do NOT include it into cocoon_20_branch CVS on apache.org, it's > >> > working, but eat huge quantity of memory, and displayed data are raw. > >> > This is not for final administrators yet. > >> > >> Applied to 2.1, thanks. > >> I modified it a bit to output SAX events directly instead of building > >> large lists. > > > >Ok, I was not really proud of thoses lists. > > > > > >> HEY, TEAM, can a cache guru look at this ? Why are there 3 stores with > >> the same keys in them ? > > > >First : > > > >There is something wrong in my code, I have in logs: > >DEBUG ... DefaultComponentFactory: ComponentFactory creating new > >instance of org.apache.cocoon.generation.StatusGenerator. > >DEBUG ... DefaultComponentFactory: no logger attribute available, using > >standard logger > >WARN ... ExcaliburComponentManager: Looking up component on an > >uninitialized ComponentManager: > >org.apache.cocoon.components.store.StoreJanitor > > > >So I probably do not have the main StoreJanitor. > > There is only one impl, yet ;-). > On my machine the StoreJanitorImpl initialize proper. > > >I'm going to write a static (synchronized) StoreJanitor to > >record any in-memory Store created. > >Is it a good solution, or is there something better ? > > Why, the actual StoreJanitorImpl does this already. But maybe > I understood your question wrong. > > > > >Second: > > > >Everybody want to know what is inside, isn't it? > >Here is another patch to display classname of cached object... > > > >And surprise, there is nothing in our Stores! > >When I request an Object by his key, I have nothing most of the > >time! > > Yes because default we're using the NonCachingxxxPiplines (I don't > know the reason, really!).
It seems that the CM is not using the class mentioned in the cocoon.xconf. Insted it sticks this the default-class in the sitemap.roles file. Why is this?? Does anybody know why the default-class is preferred over the class in the config? Shouldn't it be the other way around? > Change in the cocoon.roles the roles for StreamPipline and EventPipeline > to CachingStreamPipeline and CachingEventPipeline. Then it should > work proper. In my oppinion we should have to do that. The 2.0 branch does correctly select the expected classes. Is it the newer avalon jar? Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
