On 12/20/06, Matt L. <[EMAIL PROTECTED]> wrote:
Thanks for the lightning quick reply!
You've supplied the missing ingredient. I couldn't figure out how to get a
handle to the Tool for the requestCleanup method.
I have a few follow on questions. I hope you're not too busy.
If I wanted to add non-brittle cleanup functionality could I do something
like this (in pseudocode)?
requestCleanup { //override VelocityViewServlet method
context.getKeys;
foreach (key in keys) {
Object obj = context.get(key)
if (obj.instanceOf(CleanableTool)) {//CleanableTool is an Interface
that Tools needing cleanup would implement
CleanableTool cleanTool = (CleanableTool) obj;
cleanTool.cleanup(); //method of CleanableTool Interface
}
}
}
Ideally the servlet wouldn't need to know if it had cleanable tools or not,
nor how many, or which ones. Do you see any pitfalls with my approach?
looks fine to me.
More generally, how are the tools are loaded. Are they automatically
instantiated when listed in the toolbox.xml or are they instantiated when
explicitly referenced in the Velocity template? If it's the former then
there would seem to be performance ramifications with how the <request-path>
tags are used in toolbox.xml.
tools are instantiated/init'ed differently depending on their scope.
application scoped tools are instantiated once on servlet init and put
in the context for every request. you have to reload the whole app to
reload application-scoped tools.
session-scoped tools are instantiated once per session and put in the
context for every request in that session.
request-scoped tools are instantiated once per request. in the
upcoming 1.3 version, these may be subject to request-path
restrictions and will only be instantiated if they either have no
restriction specified or the request-path matches the specified one.
all of these are entirely independent of whether or not the template
references the tools.
I think that it would be the most intuitive if you had an Interface you
could implement that specified a method to be called when the tool goes out
of scope. I think that's essentially what I've outlined above. Is there a
gotcha there that I am not taking into account?
with such an interface, session-scoped tools are the tricky part.
they should only be cleaned up upon session invalidation.
Lastly, I noticed that the next release is doing away with the Interfaces
and going with what I would call "duck-typing". I assume this means your
using reflection to examine the object and call the method if it exists.
What was your reasoning by going with this approach? I can see a few
downsides in that it seems less self-documenting (no explicit placeholder
for this functionality) and also possibly less performant because of
reflection. I'm sure you guys have a good reason, and I'd love to find out
if for no other reason than to expand my java knowledge.
The method lookup happens on servlet init when the toolbox.xml is
converted to ToolInfo for the ToolboxManager to work with. When it
comes time to init() or configure() a tool, then only a method
invocation is necessary, the method is already cached in the ToolInfo.
This makes the performance impact quite negligible.
The motivation is to allow more POJO development, allowing us to shift
class packages and make tools in the GenericTools jar configurable and
init'able without creating a dependency on VelocityView. Basically,
we dropped the interfaces to give more development freedom to users
developing tools and to us in developing and enhancing VelocityTools.
You've already helped me a great deal. I hope I'm not imposing.
Thanks again,
Matt
Nathan Bubna wrote:
>
> If your tool is request-scoped, then you will need to extend the
> VelocityViewServlet and override the requestCleanup(request, response,
> context) method. You can retrieve the tool from the context using its
> key and perform your cleanup there.
>
> If the tool is session-scoped, then you'll pretty much need to do the
> same thing, but watch for when the session becomes invalidated. I
> can't remember offhand the best way to do this.
>
> I spent some time looking into ways to make tools poolable in order to
> build this ability into the tool itself rather than the servlet, but
> it would require changes too big for the 1.x series. That's something
> we can look at once we begin 2.x (which should be early next year).
>
> On 12/20/06, Matt L. <[EMAIL PROTECTED]> wrote:
>>
>> I have resource that needs to be explicitly cleaned up at when the tool
>> goes
>> out of scope. Is there a clean way to do this. I've figured out some work
>> arounds, but they are so ugly.
>>
>> TIA,
>>
>> Matt
>> --
>> View this message in context:
>> http://www.nabble.com/Velocity-Tool-Cleanup-tf2861863.html#a7996679
>> Sent from the Velocity - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Velocity-Tool-Cleanup-tf2861863.html#a7998017
Sent from the Velocity - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
