> > > I can try and simplify the requirements a little: Is there any way to > link all file:// sources read to the original request?
You can extend/replace the factory associated with "file". That way, you could find all used resources by file on hte firsts request (on the second, you already might run into problems because you are then using compiled styleshtees which wont be fetched again) > > Basically, cocoon is not driving our site, but a lot of our content > relies on a dispatcher to cocoon. Our site caches the > contents of each > page unless a Source linked to that particular page is marked as > 'changed', at which point, the page's cache entry is cleared. > Therefore, we need some way of linking files to a particular request. > The default cocoon approach of using timestamps has bit us in the past > as for some reason, certain files' timestamps were out of sync between > our stage and production environments and certain files were therefore > never updated. You cannot let the cacing be done by cocoon? That the site fetches cached content from cocoon, or is that already too slow? Normally, we cache in front of cocoon as well, but also in cocoon. We use mod_cache, which just serves the same page for 5 minutes for example. After 5 min, it fetches a new cocoon generated page. mod_cache is never triggered from cocoon (it might be from the browser with ctrl-f5) Anyway, if you can explain a little more, perhaps I can help you find a better solution, Regards Ard > > I'm working on another approach right now, but I would still > really like > to know if this approach is possible; it would greatly > simplify my work. > > Thanks, > -Danny > > -----Original Message----- > From: Ard Schrijvers [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 16, 2007 8:49 AM > To: [email protected] > Subject: RE: linking excalibur sources to request > > > > > A simplified version of the problem I'm working on: > > > > I need to be able to associate all (Excalibur) Sources used during a > > pipeline with the initial request. That is: > > > > 1) Request comes in through the Servlet > > 2) The pipeline executes > > 3) The servlet, upon completion, can output the URI for each > > Source read > > from during the pipeline. > > > > A strange requirement. Do you realizee that cocoon:/ and cocoon:// and > context:/ and file://, upload:// etc would all classify as your > (Excalibar) sources. Actually, what you ask is to register within one > request, all things that are resolved by the excalibur sourceresolver. > But, quite a lot of calls might be done only once, and afterwards > cached, like a file://import in an xsl. Afterwards, this one > is cached, > and the location for checking its validity wont be resolved by the > sourceresolver. Context does not make any sense, because it > is the same > for all request. Then you should bind them to a session, but > you really > dont want this. > > I really don't understand why you want this, and i do not think it is > possible > > Ard > > > I tried implementing this by making my SourceFactory > Contextualizable, > > but this didn't end up working in the end because > concurrent requests > > would come in and set a different context before processing had > > completed on the prior request. > > > > Is there a way to accomplish this? It's actually very > important I be > > able to track each Source read throughout the pipeline. > > > > Thanks a lot, > > -Danny Robert > > [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
