On Tue, 2008-09-16 at 14:32 +0100, Ross Gardler wrote: > Pablo Barrera wrote: > > ... > Then I can't help any further this is an issue with the dispathcer only.
Not sure about it. Sadly I need to meet a deadline so I cannot debug as I want. However I did a quick session on my work project. The caching of the DispatcherTransformer is controlling the structure file. Pablo said that changing the structurer file will be reflected instantly. I can confirm this. Meaning is not the DT but another component. Panels get imported in the generator stage via jx. That raises the question whether jx generator has changed its behavior. In my work project I am using a custom structurer that does not contain any jx cache key nor the cache-validity and I do not encounter the problem described. Try changing <forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0"; xmlns:jx="http://apache.org/cocoon/templates/jx/1.0"; jx:cache-key="#{$cocoon/parameters/getRequest}" jx:cache-validity="${Packages.org.apache.excalibur.source.impl.validity.NOPValidity()}"> to <forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0"; xmlns:jx="http://apache.org/cocoon/templates/jx/1.0";> and if you done with the development turn on the caching again. I reckon that will make all the difference. IMO it is the jx generator that does not test the validate of the <jx:import/> it is processing. You may want to use a other validity then the NOPValidity() since this seems to be the root of the problem you describe. The jx documentation will give you some hints (if not search in the cocoon dev ml for "jx caching"). Hope that helps and would be nice if it makes it into the documentation. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
