cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <a.schrijv...@hippo.nl>
Subject RE: Moving reduced version of CachingSource to core | Configuration issues
Date Tue, 27 Mar 2007 10:44:31 GMT
Hello,

regarding the cache-expires and async thing in the cachingsource block, there are some things
that are strange and seem bugs to me:

1) The expires value is always -1 (eternal), no matter what you define in the queryString.
You can see this happen in getSource of the CachingSourceFactory. I think the 

if (name.startsWith("cocoon:cache")) {
                    params.setParameter(name.substring("cocoon:".length()), sp.getParameter(name));
                    remainingParameters.removeParameter(name);
   }

should also get an else:

else{
    params.setParameter(name,sp.getParameter(name));
}

because all parameters are neglected in the current way. 

Then, when I do have my expires accounted for correctly, I do not understand why while the
cached object is not expired, there is still a call for the remote source. This doesn't make
sense to me. Also, when the expires is set correctly, and the object is expired, I am getting
a NullPointerException, but it might be because we use an old version...?

Anyway, think to start with is to correct the getSource() above, or do I miss something?

Ard


> 
> 
> > Vadim Gritsenko wrote:
> > > Oops, should have read it in full...
> > > 
> > > Reinhard Poetz wrote:
> > > 
> > >> I can think of setting the expires parameter to -1 and using a
> > >> background-refresher but this seems to be overly complex 
> for this 
> > >> simple task.
> > > 
> > > Yes async will do the trick. And IMHO it should be Ok to 
> alter sync 
> > > implementation to keep previous response if new one can't 
> > be obtained.
> > 
> > sounds easier than Ard's proposal (no offense ;-) ), or do I 
> > overlook something?
> 
> That certainly is a *lot* easier and I was not aware of this 
> part in the cachingsource! Might be useful for me as well :-) 
> 
> Ard
> 
> > 
> > >> I would also like to move the basic functionality of the 
> > CachingSource 
> > >> into some core module and only have an extended versions 
> > (event-cache 
> > >> support, async updating) of it in the reposistory block. I 
> > seems odd 
> > >> to me that I have to add a dependency to the repository 
> block, the 
> > >> event-cache block, the jms block and the cron block
> > > 
> > > I do not think it has any dependencies on cron, where do 
> you see it?
> > 
> > either it comes through a transitive dependency or I did 
> > something wrong with my 
> > setup. I will check where it comes from.
> > 
> > >> just for this. Any comments before I start a vote on this?
> > > 
> > > Async is a basic functionality which must be in core, IMHO. But I 
> > > completely agree that event-cache and jms should be 
> optional. I was 
> > > planning on doing this refactoring but did not manage to do 
> > it so far.
> > 
> > It would be great if you could help me with the design of the 
> > refactoring: If 
> > you did it, into which parts would you split it up?
> > 
> > -- 
> > Reinhard Pötz           Independent Consultant, Trainer & 
> (IT)-Coach 
> > 
> > {Software Engineering, Open Source, Web Applications, Apache Cocoon}
> > 
> >                                         web(log): 
http://www.poetz.cc
> --------------------------------------------------------------------
> 

Mime
View raw message