Hi Jos, the most important thing is IMHO having the XSLT transformer dependencies-less as much as we can - I suggest to define a "cache" interface (with a basic implementation) provided to XSLT transformer (via constructor), then users are free to use whatever implementation they need/prefer.
Having a default implementation would be a strict constraint, while users should be able to plug their integration module depending to their use case. Does it sound reasonable? I have ~0 spare cycles to OSS ATM, but I promise to have a look at your patch during the WE, so I can at least provide you more feedbacks. Have a nice day, all the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Tue, Jul 2, 2013 at 11:19 AM, Jos Snellings <jos.snelli...@upperware.biz> wrote: > Hi Francesco et al, > > I proposed a patch for COCOON3-126, on the configurability of using an LRU > cache for > xslt transformations. I am not too happy with it though. > > I would like to have a member function to set "isCacheEnabled", or to set > this at setup. > However, the resource is loaded in the constructor. > Would it be better to add a boolean "isCacheEnabled' to a constructor, > leaving the default > to "yes"? > > What do you think? > > Kind regards, > Jos > > -- > We should be careful to get out of an experience only the wisdom that is > in it - and stay there, lest we be like the cat that sits down on a hot > stove-lid. She will never sit down on a hot stove-lid again - and that > is well; but also she will never sit down on a cold one any more. > -- Mark Twain
