You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Daniel L. Rall" <dl...@finemaltcoding.com> on 2003/10/23 17:57:59 UTC
Resource cache configuration parameters
Geir Magnusson Jr. wrote:
>
> 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 {@link
* 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: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Nathan Bubna wrote:
> Geir Magnusson Jr. said:
>
>>On Thursday, October 23, 2003, at 05:09 PM, Daniel Rall wrote:
>>
>>>Geir Magnusson Jr. wrote:
>>>...
>>>
>>>>You might have some legs to stand on for the second one, as that
>>>>allows you to override the cache class, which I think is the general
>>>>operation, but the third is clearly targeted for the default
>>>>implementation.
>>>
>>>Yes, the third does apply to the default implementation. Bounding of
>>>caches should is encouraged behavior. Having a cache which grows
>>>without bound is a memory leak waiting to happen, easy to trigger in
>>>environments with a high fixed or variable number of resources.
>>
>>I can't see what anything but the first sentence is relevant.
>
> i believe the point is that other implementations of ResourceCache are both
> able and encouraged to use that same property. they are not, however,
> required to make use of it. if the property name/key is changed to indicate
> that it is only to be used for the default implementation (as you suggest),
> then other ResourceCache implementations that wish to have a bound on the
> cache size will likely end up implementing their own property name/key. why
> not just leave the property as is and let any implementation make use of it
> that so chooses?
>
> if i understand Dan correctly on this, then i agree with what he's saying.
Nathan, that was what I was trying to say. Thanks for clearing things up.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Geir Magnusson Jr. wrote:
>
> On Thursday, October 23, 2003, at 06:40 PM, Nathan Bubna wrote:
...
>> i believe the point is that other implementations of ResourceCache are
>> both
>> able and encouraged to use that same property. they are not, however,
>> required to make use of it. if the property name/key is changed to
>> indicate
>> that it is only to be used for the default implementation (as you
>> suggest),
>> then other ResourceCache implementations that wish to have a bound on the
>> cache size will likely end up implementing their own property
>> name/key. why
>> not just leave the property as is and let any implementation make use
>> of it
>> that so chooses?
>
> Because whether it has an effect is then arbitrary.
Yes, that is the intent -- whether or not to limit size should be left up to
the use case of the ResourceCache implementor.
> If it's something specific to the default implementation, then we should
> make that clear in the name. That way, if they switch the
> configuration, they aren't surprised when the 'size' property has zero
> effect. And the developer of the new cache impl shouldn't be required
> to support a velocity-implementation defined property.
The "size" property happens to be acknowledged by the only ResourceCache
implementation shipped with Velocity, yes. However, if someone configures a
different cache implementation, they're in a a very different class of users,
and are much more likely to read documentation because they're either a)
implementing their own cache or b) using someone else's implementation which
is likely to provide some degree of documentation since it's reusable.
> If we want to force the notion of settable size to be respected, or at
> least make the implementing programmer aware of the concept, we should
> put it in the interface, rather than have it off in some piece of
> documentation that lists the velocity properties.
I wouldn't be against putting it in the interface. It's more work from an
implementor's perspective when they don't want a maximum size (something I was
originally trying to avoid), but maybe that's what we want after all? Setting
a maximum cache size should certainly be encouraged.
Removing the constant from the public API entirely or moving it to
ResourceCacheImpl is another reasonable option, if you continue to feel that
it's specific to ResourceCacheImpl. If the cache size was removed from
RuntimeConstants, I'd care a lot less about its name and semantics.
- Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Geir Magnusson Jr. wrote:
>
> On Thursday, October 30, 2003, at 12:32 AM, Daniel L. Rall wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>> On Tuesday, October 28, 2003, at 10:45 PM, Daniel L. Rall wrote:
>>>
>>>> Geir Magnusson Jr. wrote:
>>>>
>>>>> FYI : I'm not trying to be argumentative. I just was reminded of
>>>>> lingering things when slapping myself today about the fact that our
>>>>> [] returns an ArrayList and not a List. It's a subtle issue, but
>>>>> boy I wish we made it a List...
>>>>
>>>> What do you say about that happening in 2.x?
>>>>
>>>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24203
>>>
>>> Well, it was just an aesthetic objection. I'm 100% sure we'd break
>>> people if we did that. I guess the question is if it's worth it.
>>
>> Yeah, we might break some people. But looking at the type of breakage
>> (compile-time 99.9% of the time) and the degree of difficulty of
>> fixing (trivial search and replace), doing it as part of a major
>> version number bump is reasonable.
>
> I don't believe it would be compile time at all, because the compiler
> has no clue what is going to happen in a case like :
>
> #set($foo = [0..10])
>
> $thingy.myMethod($foo)
Indeed, that doesn't occur until runtime, after parsing of the AST. But I
wasn't suggesting we alter the underlying returned ArrayList implementation of
List. Like you say below, people will only be hosed if we change that.
> If we returned a List w/ ArrayList as impl, I think we're still ok
> though. For cases where you exploit the knowledge of an ArrayList, you
> might do something like :
>
> $thingy.myMethod($foo.toArray())
>
> In which case you are hosed if we change the impl underneath. I don't
> know if changing to List now, and jumping up and down in the docs about
> assuming the impl would solve it.
Agreed, but even then backwards compatibility can be preserved transparently.
If there's ever a desire to move to a List implementation other than ArrayList,
use of a marker interface for special-casing the methods of ArrayList which
extend what's provided by the List API could be provided. Making the List
implementation pluggable would be slightly more difficult, but still possible.
Do you like the color of my sky today?
- Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Thursday, October 30, 2003, at 12:32 AM, Daniel L. Rall wrote:
> Geir Magnusson Jr. wrote:
>> On Tuesday, October 28, 2003, at 10:45 PM, Daniel L. Rall wrote:
>>> Geir Magnusson Jr. wrote:
>>>
>>>> FYI : I'm not trying to be argumentative. I just was reminded of
>>>> lingering things when slapping myself today about the fact that our
>>>> [] returns an ArrayList and not a List. It's a subtle issue, but
>>>> boy I wish we made it a List...
>>>
>>>
>>> What do you say about that happening in 2.x?
>>>
>>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24203
>> Well, it was just an aesthetic objection. I'm 100% sure we'd break
>> people if we did that. I guess the question is if it's worth it.
>
> Yeah, we might break some people. But looking at the type of breakage
> (compile-time 99.9% of the time) and the degree of difficulty of
> fixing (trivial search and replace), doing it as part of a major
> version number bump is reasonable.
I don't believe it would be compile time at all, because the compiler
has no clue what is going to happen in a case like :
#set($foo = [0..10])
$thingy.myMethod($foo)
If we returned a List w/ ArrayList as impl, I think we're still ok
though. For cases where you exploit the knowledge of an ArrayList, you
might do something like :
$thingy.myMethod($foo.toArray())
In which case you are hosed if we change the impl underneath. I don't
know if changing to List now, and jumping up and down in the docs about
assuming the impl would solve it.
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Geir Magnusson Jr. wrote:
>
> On Tuesday, October 28, 2003, at 10:45 PM, Daniel L. Rall wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>> FYI : I'm not trying to be argumentative. I just was reminded of
>>> lingering things when slapping myself today about the fact that our
>>> [] returns an ArrayList and not a List. It's a subtle issue, but boy
>>> I wish we made it a List...
>>
>>
>> What do you say about that happening in 2.x?
>>
>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24203
>
>
> Well, it was just an aesthetic objection. I'm 100% sure we'd break
> people if we did that. I guess the question is if it's worth it.
Yeah, we might break some people. But looking at the type of breakage
(compile-time 99.9% of the time) and the degree of difficulty of fixing
(trivial search and replace), doing it as part of a major version number bump
is reasonable.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Tuesday, October 28, 2003, at 10:45 PM, Daniel L. Rall wrote:
> Geir Magnusson Jr. wrote:
>> FYI : I'm not trying to be argumentative. I just was reminded of
>> lingering things when slapping myself today about the fact that our
>> [] returns an ArrayList and not a List. It's a subtle issue, but boy
>> I wish we made it a List...
>
> What do you say about that happening in 2.x?
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24203
Well, it was just an aesthetic objection. I'm 100% sure we'd break
people if we did that. I guess the question is if it's worth it.
geir
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Geir Magnusson Jr. wrote:
> FYI : I'm not trying to be argumentative. I just was reminded of
> lingering things when slapping myself today about the fact that our []
> returns an ArrayList and not a List. It's a subtle issue, but boy I
> wish we made it a List...
What do you say about that happening in 2.x?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24203
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
FYI : I'm not trying to be argumentative. I just was reminded of
lingering things when slapping myself today about the fact that our []
returns an ArrayList and not a List. It's a subtle issue, but boy I
wish we made it a List...
geir
On Thursday, October 23, 2003, at 06:56 PM, Geir Magnusson Jr. wrote:
>
> On Thursday, October 23, 2003, at 06:40 PM, Nathan Bubna wrote:
>
>> Geir Magnusson Jr. said:
>>> On Thursday, October 23, 2003, at 05:09 PM, Daniel Rall wrote:
>>>> Geir Magnusson Jr. wrote:
>>>> ...
>>>>> You might have some legs to stand on for the second one, as that
>>>>> allows you to override the cache class, which I think is the
>>>>> general
>>>>> operation, but the third is clearly targeted for the default
>>>>> implementation.
>>>>
>>>> Yes, the third does apply to the default implementation. Bounding
>>>> of
>>>> caches should is encouraged behavior. Having a cache which grows
>>>> without bound is a memory leak waiting to happen, easy to trigger in
>>>> environments with a high fixed or variable number of resources.
>>>
>>> I can't see what anything but the first sentence is relevant.
>>
>> i believe the point is that other implementations of ResourceCache
>> are both
>> able and encouraged to use that same property. they are not, however,
>> required to make use of it. if the property name/key is changed to
>> indicate
>> that it is only to be used for the default implementation (as you
>> suggest),
>> then other ResourceCache implementations that wish to have a bound on
>> the
>> cache size will likely end up implementing their own property
>> name/key. why
>> not just leave the property as is and let any implementation make use
>> of it
>> that so chooses?
>
> Because whether it has an effect is then arbitrary.
>
> If it's something specific to the default implementation, then we
> should make that clear in the name. That way, if they switch the
> configuration, they aren't surprised when the 'size' property has zero
> effect. And the developer of the new cache impl shouldn't be required
> to support a velocity-implementation defined property.
>
> If we want to force the notion of settable size to be respected, or at
> least make the implementing programmer aware of the concept, we should
> put it in the interface, rather than have it off in some piece of
> documentation that lists the velocity properties.
>
> geir
>
>>
>> Nathan Bubna
>> nathan@esha.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>
>>
> --
> Geir Magnusson Jr 203-247-1713(m)
> geirm@optonline.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Thursday, October 23, 2003, at 06:40 PM, Nathan Bubna wrote:
> Geir Magnusson Jr. said:
>> On Thursday, October 23, 2003, at 05:09 PM, Daniel Rall wrote:
>>> Geir Magnusson Jr. wrote:
>>> ...
>>>> You might have some legs to stand on for the second one, as that
>>>> allows you to override the cache class, which I think is the
>>>> general
>>>> operation, but the third is clearly targeted for the default
>>>> implementation.
>>>
>>> Yes, the third does apply to the default implementation. Bounding of
>>> caches should is encouraged behavior. Having a cache which grows
>>> without bound is a memory leak waiting to happen, easy to trigger in
>>> environments with a high fixed or variable number of resources.
>>
>> I can't see what anything but the first sentence is relevant.
>
> i believe the point is that other implementations of ResourceCache are
> both
> able and encouraged to use that same property. they are not, however,
> required to make use of it. if the property name/key is changed to
> indicate
> that it is only to be used for the default implementation (as you
> suggest),
> then other ResourceCache implementations that wish to have a bound on
> the
> cache size will likely end up implementing their own property
> name/key. why
> not just leave the property as is and let any implementation make use
> of it
> that so chooses?
Because whether it has an effect is then arbitrary.
If it's something specific to the default implementation, then we
should make that clear in the name. That way, if they switch the
configuration, they aren't surprised when the 'size' property has zero
effect. And the developer of the new cache impl shouldn't be required
to support a velocity-implementation defined property.
If we want to force the notion of settable size to be respected, or at
least make the implementing programmer aware of the concept, we should
put it in the interface, rather than have it off in some piece of
documentation that lists the velocity properties.
geir
>
> Nathan Bubna
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr. said:
> On Thursday, October 23, 2003, at 05:09 PM, Daniel Rall wrote:
> > Geir Magnusson Jr. wrote:
> > ...
> >> You might have some legs to stand on for the second one, as that
> >> allows you to override the cache class, which I think is the general
> >> operation, but the third is clearly targeted for the default
> >> implementation.
> >
> > Yes, the third does apply to the default implementation. Bounding of
> > caches should is encouraged behavior. Having a cache which grows
> > without bound is a memory leak waiting to happen, easy to trigger in
> > environments with a high fixed or variable number of resources.
>
> I can't see what anything but the first sentence is relevant.
i believe the point is that other implementations of ResourceCache are both
able and encouraged to use that same property. they are not, however,
required to make use of it. if the property name/key is changed to indicate
that it is only to be used for the default implementation (as you suggest),
then other ResourceCache implementations that wish to have a bound on the
cache size will likely end up implementing their own property name/key. why
not just leave the property as is and let any implementation make use of it
that so chooses?
if i understand Dan correctly on this, then i agree with what he's saying.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Thursday, October 23, 2003, at 05:09 PM, Daniel Rall wrote:
> Geir Magnusson Jr. wrote:
> ...
>> You might have some legs to stand on for the second one, as that
>> allows you to override the cache class, which I think is the general
>> operation, but the third is clearly targeted for the default
>> implementation.
>
> Yes, the third does apply to the default implementation. Bounding of
> caches should is encouraged behavior. Having a cache which grows
> without bound is a memory leak waiting to happen, easy to trigger in
> environments with a high fixed or variable number of resources.
I can't see what anything but the first sentence is relevant.
>
> Abstractly, consider cache sizing as part of the interface, which
> implementations can implement as a no-op if they choose (by not using
> or ignoring the parameter). I would've added a new API method
> directly to the ResourceCache Java interface, but that would require
> additional work for users upgrading their custom implementations.
>
I'm not arguing about the size. I think it's great. What I do think
is that we should fix these property names while we have a chance...
> - Dan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Geir Magnusson Jr. wrote:
...
> You might
> have some legs to stand on for the second one, as that allows you to
> override the cache class, which I think is the general operation, but
> the third is clearly targeted for the default implementation.
Yes, the third does apply to the default implementation. Bounding of caches
should is encouraged behavior. Having a cache which grows without bound is a
memory leak waiting to happen, easy to trigger in environments with a high fixed
or variable number of resources.
Abstractly, consider cache sizing as part of the interface, which
implementations can implement as a no-op if they choose (by not using or
ignoring the parameter). I would've added a new API method directly to the
ResourceCache Java interface, but that would require additional work for users
upgrading their custom implementations.
- Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Thursday, October 23, 2003, at 11:57 AM, Daniel L. Rall wrote:
> Geir Magnusson Jr. wrote:
>> 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 {@link
> * 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.
No they don't.
The first allows you to replace the resource manager class. You might
have some legs to stand on for the second one, as that allows you to
override the cache class, which I think is the general operation, but
the third is clearly targeted for the default implementation.
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org