Mark cjb> SPECIFIC: The Excel files are [...] accessed only cjb> once. They don't need to be cached. Is it cjb> possible to declare only the Excel reports output cjb> folder as non-cache-able but leave the (default) cjb> context cache setting as-is so everything else cjb> can be cached in the default way? That is, set cjb> up the Excel report output folder as a separate cjb> "resource" with an independent cache setting? cjb> Right now the Excel folder is embedded in the app cjb> file system: TC/webapps/app/excel.
mt> At the moment, no. No reason why we couldn't extend mt> the resources implementation and either add a few mt> more options (based on path and/or filename and/or mt> mime-type and/or whatever). Where we draw the line mt> between 'standard' options and what requires a mt> custom CacheSelector (ideas for better name welcome) mt> is open to debate. Something for an enhancement request? A bare-minimum approach that might work could be a new Resources attribute "cacheNotFoundResults" (default=true). However... [LONG] Something more robust might meet community needs better, depending on what folks require, rather than a one-off fix. Need to specify what the cache implementation applies to. By folder? By file type? What other folks want? I vote for an implementation by folder. How to implement? Move all caching specifications to a new CacheHandler class that the Resource references. The 8.5 Resources docs list these attributes: allowLinking, cacheMaxSize, cacheObjectMaxSize, cacheTtl, cachingAllowed, className, trackLockedFiles (is tLF cache-related?). The decoupled specs of Resources(a) and Cache(b) would start with: a. Resources: allowLinking, className, trackLockedFiles, cacheMaxSize(D), cacheObjectMaxSize(D), cacheTtl(D), CacheSelector(new). - (D): cacheMaxSize, cacheObjectMaxSize, cacheTtl would be deprecated but remain in existing TC implementations (7, 8, 9) to maintain backwards-compatibility. New versions of TC (10+) would not support those options. - CacheSelector would default to the default cache implementation if not specified. Specifying an empty string "" would equate to "none" (no caching), or maybe a no-op canned class of CacheNone could be selected. b. Cache: cacheMaxSize, cacheObjectMaxSize, cacheTtl, cacheNotFoundResults(new), cachedFolder(new). - We could remove the prefix of "cache" to avoid the Smurf syndrome since it applies to cache anyway. - cachingAllowed would be removed since that would be the Cache implementation class itself. - cachedFolder would default to the app deployment folder. The default cache handler CacheHandlerDefault class manages the cache for the app deploy folder(s) by default without changing the TC config. You could specify a canned or custom cache handler at any depth for a different cache implementation for a specific folder set that would override the default. That is, a bunch of folders would have the default cache handler by default, but a special (sub)folder could have a different cache implementation. Questions / Observations: - How to specify different cache handlers for different folders? - What are the implications of having multiple caches? - A cache chain or hierarchy? (override) - Multiple CacheSelector's allowed per resource? - One cache handler per resource? - Nested or split Resources with one cache per sub-resource to in effect have multiple cache handlers? - Cache by folder couples the TC context config to the application folder structure. Meh, sounds rather complex, and my brain is tired. :-\ -- Cris Berneburg CACI Lead Software Engineer
