On Wednesday, October 22, 2003, at 02:34 PM, Daniel Rall wrote:
Geir Magnusson Jr. wrote:
On Wednesday, October 22, 2003, at 01:14 PM, Daniel L. Rall wrote:
Yes, you'd have to set the cache size to less than 1 to get the old greedy behavior. This is a feature, not a bug, as the old behavior retained memory based on the number of resources (templates, etc.) that were loaded and subsequently cached.
I documented that in the changes.xml file. Should we provide a more thorough example?
Well, we might want to doc, but the behavior seems to be benign.
To where should I add the additional documentation?
Thought about this. I threw the two params into the dev guide as I was in there for log4j update.
I also tweaked the name of the param to resource.manager.defaultcache.size to keep people from thinking it affected anything but the default cache. If you don't like, bellow :)
Okay, wooooof!! I dislike the inconsistency with the other default cache properties, which are all named using the "resource.manager.cache" prefix even though they refer to the default cache. Here's the relevant constants from RuntimeConstants:
-------------------------------------------------------------------------------
public static String RESOURCE_MANAGER_CLASS = "resource.manager.class"; /**
* The <code>resource.manager.cache.class</code> property
* specifies the name of the [EMAIL PROTECTED]
* org.apache.velocity.runtime.resource.ResourceCache}
* implementation to use.
*/
public static String RESOURCE_MANAGER_CACHE_CLASS =
"resource.manager.cache.class"; /**
* The <code>resource.manager.cache.size</code> property specifies
* the cache upper bound (if relevant).
*/
public static String RESOURCE_MANAGER_DEFAULTCACHE_SIZE =
"resource.manager.defaultcache.size";
-------------------------------------------------------------------------------This last one now sticks out like a sore thumb. Since all these parameters speak of the default implementation, they must be named consistently.
To the best of my knowledge we don't allow named caches, so even though the "size" parameter is not part of Velocity's ResourceCache interface like the "class" parameter is, they both still refer to configuration for the same instance. For an alternate ResourceCache implementation, the size parameter may not be relevant, but in such a case the developer of that alternate implementation is likely to read the JavaDoc for the corresponding constant, note the "if relevant" comment, and leave the parameter out from his class's configuration. For the casual user who doesn't implement their own cache (easily 90%+ of our user base), they needn't be confused by the parameter naming inconsistency.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
